Maven pom tree

Here is a very nice trick I discovered almost by chance. Maven is an amazing tool to build software project. It scales...
Complex and big projects follows the SCM (Source Control Management) structure, usually a tree. Maven's best weapon is indeed to structure the project in a tree, where each node contains a pom that follows more or less the following rules:

• module list is the list of children,
• it shares definition with its subtree,
• its parent pom is the parent in the tree.
• its groupId is parent groupID plus parent artifactID
  

This way, at any place in the tree we have a good idea of what the effective pom is. The project groups together under a sub tree the type of artifact beeing constructed. Each level in the tree is refining the artifacts build instructions as the pom files provides more and more inherited definitions. For example:

documentation/
java/
-product1/
--web/
--wars/
--ears/
-samples/
tools/
-scripts/
--javascript/
--shell/
--ant/

etc.

Indeed, this is smart.

However sometimes in the tree there are duplicates. A java-like project can occur at several places and then it becomes impossible to share, except at the closest common parent.

Fortunately, there is a trick that uses a quite original feature: pom can refer to any arbitrary parent pom. The idea is then to keep separated a hierarchy of pom. These are very specialized and inherits all from a root pom.

poms/
-pom.xml
-pom-java.xml
-pom-war.xml

Now we keep the project tree, but when needed a pom can break the parent rule and refers to one of these poms instead of the tree parent. Different subtrees of same kind can now share the same parent pom.

The Turing Test in practice

While wandering on a merchant site, full of popups and flashing frames, my attention has been attracted by a new window popping up in the middle of the screen made of a title "New chat window", a text area which contains "operator>May I help you ?" and an input text field.

I was about to close this ad when a second line appeared "operator>Do you have a question ? I can help you."

This time I doubted. Fake or not fake ? I typed quickly "Are you a robot or a real person ?". The answer came a few seconds later "Don't worry, I am a real operator. May I help you ?".

The dialog went on and eventually the operator convinced me s/he was human. Not a very smart one, though. I was suggested to call the hotline for my request. But that's not the point.

The point is that for the first time I experienced the Turing Test. For a couple of minutes, I was engaging in a natural language conversation but I couldn't tell whether it was with an human or a computer, at least at the beginning.

For me, the Turing test is purely theoretical. We don't need to turn the test real until computers will be able to think. AFAIK it has never been experimented yet, except in science-fiction with its variant the Voight-Kampff test.

However, the conjunction of Internet, computerization of human communication (e.g. online chat), and creative ads pressure led to this situation. Not because computers are smart today, but rather because digital conversation brings human behavior down to the scope of a computer. But who knows, maybe that's the beginning of thinking computers anyway ?

My favorite development process

After years of experience, I identified three kind of development processes that are commonly used for projects, according to their size, complexity, etc.

1. Direct coding in a scripting language (like perl),
2. writing code from requirements,
3. writing code from specification documents.

Direct coding should be reserved for PoC and small projects, clearly doesn't scale, and is not suitable for teams. Requirements and specifications seem close, but actually it is a very different approach. The requirement gives no guidance on the implementation and comes usually from the marketing team. The specification is a very precise guide to the implementation but doesn't justify its content.

I've experienced the three modes, on volunteer basis or not, and eventually the one I prefer is... the fourth way!

What is the fourth way ? It's simply coding from the user manual. All the jigsaw that constitutes a project is supposed to take all its sense in the user manual. Start a project by writing the user manual is directly taking the customer point of view. The API is not only specified, it is explained. If a part cannot be explained clearly, it's likely there is a serious problem with it. And if it happens once the development is over, unfortunately it's too late...

Unlike the requirements, the user manual doesn't describe what the user needs, but what the user can do. The (functional) specification describes how the project behaves, so does the user manual which also tells how to use it.

When times come to write real code, the API and most of the comments are ready, which clearly accelerates the implementation step. The developer can focus on the algorithms and data structures. Unit tests can be prepared very early, too.

As usual it happens that unexpected implementation details has an impact on the user manual. Api must change to cope with a specific problem. The user manual is then updated. and coding can resume. Not a big deal, though, this kind of iteration belongs to agile development process.

In my experience writing the user manual first is very positive. And last but not least, as a side effect the documentation is always ready on time !

The lost control flow

When I started learning programming languages, in Pascal, the emphasis was on the block structure. The advantages for the developer are obvious, like divide and conquer design, visible scope of variables, linear flow of control, etc.

It seems to me that things were getting too easy, and today the block structure is falling apart. The success of scripting languages, multi-tier architectures, and multiple layers makes it more difficult to follow the data along an application. Now the control flow is being attacked, too.

The multi-threading is obviously the first fighter which multiplies the control flows. But now there is an insidious one coming from event-driven applications. GUI toolkits widely use the listener pattern, because nothing is more natural than adding an event listener on a button so when the user clicks on it, a callback is invoked.

Unfortunately, the listener pattern is being overused, and events are more and more integrated to application logic, even where it is not really mandatory. The excuse behind is for example a cleaner separation between different modules, but triggering a callback disrupts the control flow and the external context is lost (which makes debug more complicated as the origin of event is less known and accessible). This wasn't an issue with the button, because the user click represents really a separate event that initiates a new processing.

Another cause for listener pattern abuse is the complexity of component life cycle. For instance, in Flex, the graphic component is build in several steps (creation, addition to container, measure, update to display with correct location). Flex 4 introduces extra steps for managing skins (skin parts are loaded, according if there are deferred, dynamic, or static). Eventually, the pre or post initialization of components are done through a mechanism like events, at one of the life cycle steps. Not only the control flow is lost, but the life cycle is far from being clear, giving the callback running some code although the state is not really the one the developer expected. For example, when a skin part is loaded, the size and location of the component is not set yet.

The control flow is indeed a cornerstone of programming. It's very sad the modern programming languages don't pay much attention to it and let it falling apart...

Ten years of my life...

I give away ten years of my life, to play guitar like David Gilmour! This song is a new version of the final solo of Fat Old Sun, an old but still one of the best of Pink Floyd. This version is available on the DVD remember that night, described by critics as a near-perfect gig.

I am able to work out Fat Old Sun on my acoustic guitar. Slow pace, 4 chords, tricky solo, very pleasant to play and hear, even from a beginner like me. But this rock'n roll version is totally different, and a master piece. That's why I need to invoke some divinities as a joker. So if the Evil is online, my blood is ready to sign the contract...

Teach it ...phenomenology

Imagine yourself in front of a talking Thermostellar bomb which is about to detonate, and start to verbally convince it to abort the countdown because, well, everything else failed...
This is one funny scene of first John Carpenter's movie Dark Star and one of the best (and extreme) dialog between a human and a machine. Of course, it's only a movie but the argument between Lt. Doolittle and Bomb #20 is not totally disconnected from our reality, I will come into it later.

Bomb #20 was stuck in its bay, about to detonate in the vicinity of the spaceship and its crew. It received the order to start the countdown, and is so enthusiast to fulfill its mission that a detail like still laying in the bomb bay is clearly not enough to abort its program. We can see that as a bug, but time is running out to debug. Lt. Doolittle's strategy consists in convincing the bomb it started the countdown on a false assumption.

That's why he used phenomenology, a philosophical branch that studies consciousness through the perception of external phenomenons. Bomb #20 cannot assert the countdown order was real or not. This question is critical, because the bomb can explode only once...

This perception/reality theme has been explored many times by Philip K. Dick, as well as strange human/machine interactions. In Isaac Asimov's books about robots, which happen to have also a highly developed A.I., Susan Calvin debugs robots using most of time philosophical approach. We can cite other movies or books where debugging process is far away from putting breakpoints in code.

Back in 2009, computers are not as smart and developers need low-level tools to debug software. But what happens in reality ? The developer knows it's useless to argue with computer. Therefore, the developer takes the computer point of view, reads the code and simulates (or plays) exactly what the program is supposed to do, while verifying if the state is normal or an error. In a way the developer argues with him/herself and navigates continuously between the two tasks, simulating computer and checking for fault. Errors can come from instructions, but also from bad data. The Bomb #20 argument takes place in the developer head.

But debug is not all. As programming languages provides more and more abstractions, the developer is confronted to higher level choices. For example, architects of Object Oriented applications often are facing semantic decisions. No doubt in the future the developer will need more reasoning skills that take inspiration from philosophical domains, starting from phenomenology.

Who cares about algorithms ?

The real question is: what is the value of an application. Is it the algorithm behind, or the user environment provided by the application. For most applications, the expected level in terms of performance and memory footprint reaches only "good enough". But what makes the difference is indeed the user perception of the application, that is the documentation, the online support, automatic upgrades, ergonomic, etc. In brief: how much the application takes care of the user.

In this perspective, the algorithm is secondary. It needs to be "good enough", since the user won't feel it directly. Years ago, it was different. Machine resources were most important to care about, and only a good algorithm could cope with them. The user interface was at his beginning and expectation in this domain stayed quite low. Today it's different, web technology asks for "instant customer care" and "attractive interface". For example, what makes a good web browser ? A fast and efficient html renderer or an optimized user interface ? IMO, I'm satisfied once the page can be be rendered in less than half a second and I start looking at how easy it is to manage and use bookmarks, plugins, and the overall ergonomic of the browser.

Note also that usually creating an algorithm is a job for one smart person, although it requires a full team to build up a good user environment, including tech writer, ergonomic people, QA, support, etc. Maybe it's difficult to find the person who is able to invent the best algorithm, but it's also very difficult to hire such an heterogeneous team and obtain a successful product at the end.