Mickaël’s Weblog

According to typealyzer, I (or my blog) am a member of the INTP:

Sometimes important decisions are made in agreement because there is undetected misunderstanding which makes the decision fulfilling the requirement. Double check in this case is often useful.

I’m working currently on some modeling exercise. The question has been raised about the support for the model: UML or a real database? We agree (including me) on using the database. My understanding was that we will use a real database using the model as structure.

Finally we have a database with 3 tables: Entities, Relationships, Attributes … this is far from what I thought !!

You can get a description there. This released was initialy planned for begining of 2007 and is finally out.

JBossAS 5 provides a healthy foundation and the most
advanced and fully extensible, cross component model, aspect integration, server runtime environment.

In this article, we learn that we can get a totally unlock Android G1 phone, i.e: works on any networks.

The Android Dev Phone 1 is available exclusively to those who register as developers on the Android Market site, after paying the $25 registration fee (seriously Google, do you really need the money?). After they have your details, you can order the phone for $399 and have a working, customizable Android G1 handset sent to you wherever you may be in the world, and free of charge if you live Stateside.
 

Agile sounds on the decline … in the practice as mass adopte it wrongly. This is what are saying James Shore in this post,Jonathan Kohls in this post. I think the Agile bubble start to explose, the question is: will it follow the hype curve that I described in that post.

G2One is the software company delivering open source projects Grails and Groovy. This company is made of 6 java experts. YOçu can find all the details in this article.

SpringSource expect to integrate Grails in dm server, the OSGi paltform.

Ruby on Rails has now a serioous competitor.

I bet on this as the major infrastructure component for software within near future.

Separation of Concern (SoC) is really important to me and goes beyond simple separation of layers os a software implementation. I should add “cohesive”, but this is part of the same idea: everythings doing the right thing in the rigth area.

This principle does apply obviously to the source code as a programming practice, useing a tool as maven that introduce some structure into the code organization. But it also apply to the architecture (SCA), the deliverables (DLL…and its hell), platform (OSGi / Spring DM server), components/framework (IoC, MEF), and methodologies (Agile).

The last one could be amazing, but I think the rational is the same: change adpoption. Kevlin Henney in his post Manage component dependencies for improved system quality says:

Another consideration in managing dependencies is the question of change. The dependency structure of a system can enable or discourage change, which makes dependency management a question of architecture, not merely one of fine-grained code quality

Having a system allowing effective depedency management at compile-time will ease test infrastructure setup (abaility to test a piece of code without having the entire system setup), hence quality…humm…be sure to automate your test to really ensure quality (doing manual repetive stuff is the best way to do it in a bad way over the time).

Having a system allowing effective depedency management at run-time will ease deployement as you will be able to do hotswapping of components even when they are running as for OSGi platforms.

Having a system allowing effective depedency management at run-time with version management, will allow multi-tenant applications and smooth upgrade…and probably start to solve the DLL’s hell.

I’m currently reviving a mobile application that I started a long time a go.

Since that time, I downloaded lots of useless software on my mobile phone…no more space to deploy my application. I tried to deploy directly on the storage card but the way to do so did not pop immediately. I googlized around this topic to get the tip and did not find anything. 

The tip is simple: go in the properties of your .Net mobile project, in the “Device” tab, you click on the button on the right of “Output file folder” and select “Root folder”, then enter the full path “\Storage Card\Program Files\MyApp”.

Today, I received a mail referencing this post from Llewellyn Faco.

My first though is: “does adding unit test on legacy code makes sense?”. I beleive it does not. You would like to refactore your code and be sure not to break any feature? Refactoring makes sense only to make your code evolve to change design or add feature and so on. Legacy code that support features you are not aware of (no unit test) … does not need to evolve…does need only to be replaced by other code (with test around this time). So I found this simply useless. 

The second issue I see is the feasibility of the solution proposed by Llewellyn. One nice side effect of unit testing is the decoupling. And usually, legacy code without tests around has a lot of coupling between classes, thrid parties and databases. Even if the legacy code was well written, you always have a damned coupling somewhere deep inside. So there is no way to instanciate the class you would like only for test purpose.

To summarize: you have some legacy code which works (new code has 99% of the bugs) but you don’t know what it does exactly. Why would you like to add test around? I usually add test to describe what I want tmy code to do and reuse these test to ensure evolution (refactoring, redesign…etc). In the case of legacy code: isolate it as much as possible, consider it as a black box and the only possible evolution is replacement!

I’m currently working on a modeling exercised for connected applications. Modeling an RDBMS schema for a standalone monolithic appliaction is not a real challenge. On top of a set of connected applications, this task start to raise some concept that requires some guidance.

The article Data on the outside vs. the inside from Pat Helland highlight some of this concept.

As I mentionned in this post about persistance, it’s very common to see RDBMS primary keys appearing in entity definition. This is a mistake for a couple of reasons. First, entities should be loosely coupled from the persistance type (RDMS, file, memoty…etc). Using a primary key is introducing technical details from the implementation in the model. The second reason I see is about the immutability of the key.

When i’m talking about key, it’s about the part of the reference of a business entity that identify it. For example, in a REST environement you could reference purchase orders using  this url : customer/C00123/PO/PO00112. In this case the key is the PO number (PO00112). 

The goal of a model (or schema) is to support business application in describing things. 2 things that may seam different are in fact the same from the business perspective. For example, from an asset management perspective, if a laptop already acquired is replaced by another one (of almost the same model) because of a technical problem/failure, the second laptop is concidered as the same. In this particular case, nothing change in the description of the laptop even if physically there are 2 distinc laptops.

So to define the key, you need to answer to this question: from the business perspective, what qualify/reference uniquely an entity type. In the case of laptop for AssetManagement it’s the AssetTag, in the case of employee in HR it will probably be the social number…etc.

Immutability of such key means that key of an entity can’t change. If you want to change it because you assigned a temporary one for example) that measn your application should expose a process for this and in fact you will create a new entity with the new key and look at all attributes and relationship to apply them on the new entity. And this process should trigger all audit system.