Green or Bust!

WordWeb (Dictionary + Thesaurus + Word Finder) wants a better future for all of us.

Read their free version license agreement.

You might find it laughable but I think it is laudable.

(Still) Waiting For Java 5

After the recent release of the public review of JSR-283, discussions have mainly been focused on the demise of XPath support and the installment of a new query language model. One thing that shocked me, when I browsed through the API, was the complete lack of any Java 5 language constructs, like generics or enumerations.

Or take a look at a the parent POM of a project like Mule ESB: the target JVM is 1.4.

Hence "enterprise" Java is still a 1.4 world. Even if it is possible to run 1.4-compiled applications on recent JVMs, mainly to reap their performance benefits or management features, the Java community is dragged behind by this state of affair.

And this means, we have to carry on with pre-1.5 compatibility features, like erasure, until the corporate world leaves the 1.4 platform for something less retarded. The good thing is that this will inevitably happen.

Order Is Disorder

Eclipse offers the possibility to auto-sort the members of a class while formatting its code. After seeing the result of member sorting applied to code I have written, I must confess I find this "feature" totally useless at best, deeply asinine at worst because the cons totally outnumber the pros.

If this sounds too harsh, then here is a more polished point of view from this developerWorks article:

Sometimes it's nice to have members sorted alphabetically to better navigate in your code. Again, there may be arguments against it. Imagine you structure your code so that methods that call each other are located close together for code navigation. The sort would reorganize them, and they may not be in the wanted order.

Sorting members alphabetically is very often counter-intuitive. Let's take javax.servlet.Filter as an example. Which implementation do you prefer:

The alphabetic order
void destroy()
void doFilter()
void init()

The execution flow order
void init()
void doFilter()
void destroy()

The latter is of course the more natural one: time can not be factored out when reading and understanding source code. In this matter, the alphabetic ordering acts as a randomization of the time line of the source code.

On top of time-line ordering, programmers naturally organize related members in groups because it is easier to keep a visual context that covers several methods, hence it facilitates their comprehension. Using the previous example, I would opt to sort the members this way:

void init()
void destroy()
void doFilter()

keeping the lifecycle methods (init and destroy) visually grouped and time-line sorted.

Here again, alphabetic sorting damages another important factor for code understanding: the distance between related statements.

My conclusion is that member sorting is far beyond formatting concerns and should not be automatically applied. If some sort of sorting is needed, it is better to sort the hierarchical outline of the class, as explained in the aforementioned article:

The outline view offers a nice feature to sort members in the view, but not in the code. The specific settings and how members are sorted can be found in Preferences > Java > Appearance > Members Sort Order.

Agile For The Masses

Some Serious Tooling

To further promote Windows Developer Power Tools, O'Reilly has just released two badges to show off the work done on the tools and on the book.




I really like the circular saw: though software engineering is more like plumbing, there are some serious cutting job as well, so a saw like this one can be handy.

Anyway, I start using the badges in the NxBRE sites and documentations.

Content Rides The Bus

I have just released the very first version of the JCR Transport for Mule. This transport supports JCR 1.0 (Java Content Repository 1.0, as defined by JSR 170) repositories and is a receiver only. It leverages the asynchronous notification mechanism, named observation, to receive events whenever a change occurs in the repository and is not intended for storing nor reading messages from a content repository.

Indeed the use case for this connector is to monitor a content repository for particular events and to transform these events into fully-resolved serializable content-rich objects that Mule ESB can route to interested endpoints or components, enabling them to trigger actions like instantiating work-flow sequences or flushing caches.

Developing this connector using Mule's Transport Artifact was very easy, the biggest part of the code being in the (optional) augmentation of the JCR events with content from the repository. The development environment that MuleSource has opened to developers, named MuleForge, uses all the good tools of the moment like Subversion, Confluence, Jira, Bamboo and, of course, Maven ; with Xircles as the one platform to bind them all in a consistent dashboard.

MuleForge has allowed me to develop, build, distribute and document this transport in a very efficient and professional way. For example, the wiki templates look exactly like the Mule ESB official guide, which is a great plus for the end-users who will experiment a consistent reading experience.

All in all, MuleForge is a smart initiative that fosters creativity and contribution around a powerful and well-established open source product. I vouch the efforts MuleSource has put in setting up this environment will pay: it will nurture projects contributed by a vibrant community of users and developers and will eventually enrich the overall Mule ESB offer.

DieSeL for the Engine

Thanks to ANTLR and ANTLRWorks, I have been able to make significant progress on the addition of Domain Specific Language (DSL) support for the Inference Engine of NxBRE. A usable version is available in the SVN repository on SourceForge.

NxBRE DSL, aka NxDSL, main goal is to allow rules authors to use their own natural language to write executable rules. Technically this feature is based on:

• a language-specific ANTLR grammar that strictly enforces the structure of a rule file: this file is not supposed to be edited by the implementer,
  
• a custom definition file that translates statements into RuleML atoms: this file must be created by the implementer to capture, with regular expressions, the natural language fragments and how they translate in RuleML atoms.
  

In the following example, the words in red are parsed by ANTLR while the ones in green are matched by the regular expression from the definition file.

rule "Discount for regular products"
if
The customer is rated premium
and
The product is a regular product
then deduct
The discount on this product for the customer is 5.0 %

The terms in italic are captured by ANTLR and the regular expressions to get values for labels, implication actions and atom values.

As you can see, the ANTLR grammar defines and enforces the structure of the rulebase, i.e. the skeleton of the rules, logical blocks and statements.

NxDSL comes with a grammar that allows using French terms for defining the rule structure, thus opening the door to consistently write the body of the rules in the same language, as shown hereafter:

règle "Remise pour les produits standards"
si
Le client est en catégorie premium
et
Le produit est de type standard
alors déduis
La remise pour ce produit pour ce client est de 5.0 %

While NxDSL adds extra work for the engine implementor, the positive impact for the rule writers will justify its usage for projects in need of letting non-technical users manage rules.

NxDSL also opens the possibility of writing a plain-text rule editor by leveraging the definition file to provide code assistance to the writer. Anyone feeling like contributing such an editor?

Lang for the Commons

I had to deal today with a class that contains an attribute of type java.io.Serializable. When I asked Eclipse to generate the equals and hashCode methods that I needed to be implemented, it warned me that the generated code will not work properly because Serializable does not mandate anything in term of implementation of these two methods.

And as expected, I started to get red lights when my test cases were stuffing byte[] in the Serializable attribute: the hash computation and equality algorithm used for this type was simply not working and two instances of my object containing the same sequence of bytes in two different byte arrays were bound to be different.

Since I was already Commons Lang for building the String representation of my object, I thought I should give a shot at the hashcode and equals builder it offers. Reading no doc and proceeding only by analogy with the toString method, I quickly typed this:

public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);
}

public boolean equals(Object obj) {
return EqualsBuilder.reflectionEquals(this, obj);
}

And it worked immediately! Not only it saved me a lot of lines of code but it worked exactly as I expected from the look at the name of the classes and the methods.

Nice API, nice library: you need it.

July And Still Jolting

DDJ has (finally) published the write-ups for the winners of this year's Jolt Product Excellence Awards.

There is no master page for the different categories, so here is a link that will provide you with search results showing all the relevant pages.

My own write-ups are in the Enterprise Tools and Libraries, Frameworks and Components categories.

Enjoy the reading!

Everything Is Happy (or Content?)

On this sunny Bastille Day, there is at least one good reason to rejoice: the public review of JSR-283 (aka JCR 2.0) has been published yesterday! Knowing that one of the most interesting Java APIs of the moment has just gotten better is a true source of (geeky) happiness and the promise that it will keep shaking and shaping the world of content repositories.

Indeed, JCR has been playing and will keep playing a fundamental role in opening the doors of a domain that used to be the private hunting field of a few mammoth vendors. Of course, this is not about getting great repositories for free, instead the main benefits are allowing users to be in control of their content assets and enabling developers to build innovative content-driven solutions.

I did not have time to dig deep in the specification, but I noticed that observations now produce richer events (source path and indentifiers) and that the previous version of SQL and XPath query languages have been deprecated in favor of an Abstract Query Model (AQM) that incarnates in a new SQL (JCR-SQL2) and a query object model (JCR-JQOM). I was convinced that XPath was a perfect fit for JCR searching but apparently I was wrong! I think JQOM will be the more appealing option for tool builders as mapping query features to this object model will be less clumsy than generating SQL.

Now to my little wish list! As a user of the API, here are the three changes I would like to see in the new version. Some are trivial, like:

• A Property object can be single or multi-valued hence offers getValue() and getValues(). I find logical that calling getValue() on a multi-valued property fails but I find deeply counter-intuitive that calling getValues() on a single-valued property fails. By allowing getValues() to return a unique value from a single-valued property, the code needed to read property content would be vastly unified, thus simplified. This would also be conform to the principle of least astonishment.
  
  
• An Event has a type property that defines the reason why it was raised. This is defined by a list of static integer while I think it would be better to use a type safe enumeration, as it is done for PropertyType. I can understand that this change would create an ascending compatibility challenge so at least adding an helper class that could render to / parse from String would be very helpful for translating event types to a human readable form (PropertyType offers such methods: nameFromValue and valueFromName). On top of that, making Event serializable would also facilitate its processing.
  
  
• A less trivial addition would be to offer a unified way of acquiring a repository. Currently each vendor can offer a different client factory: writing an application that connects to several repositories forces to write specific code (or to use SpringModules). A unified URI-driven repository factory mechanism a la JDBC would be very helpful.
  

Do not get me wrong: I am not grumpy about JCR! I am even working on some goodness based on it. If I would be grumpy about something, that would be about the fact that, thanks to Sun's policy on binaries redistribution, no JCR libraries are available in the central repository of Maven, making builds a little tricky (but feasible, as Day saves the day again).

Skeletons And Open Closets

Before it went to the printed publications paradise, Software Development Magazine was running an "Horror Stories" series for Halloween time every year. It was fun to write, instructive to read and pretty scary as well.

Nowadays, the "Daily WTF", prudishly renamed Worse Than Failure, brings us this kind of story everyday, if not several times per day. A common point between all these stories seems to be the universal existence of software skeletons in IT closets, waiting to jump on poor new programmers laps and make their life a nightmare.

Life being short, it can be desirable to avoid getting aboard a ship that carries such monsters but how to tell that a company is facing "legacy code issues" from a few interviews? This kind of risk might make working for an open source software company a desirable move. Skeletons dislike open closets.

Are open source companies free of monsters? Of course not: for all the pieces of software that are not public (think back office systems, web sites...), there is a risk of facing the ugly spawn of years of software rot. But at least all the public facing code will have to stand to some elevated standards and is "up to the challenge of 1000+ eyeballs reading [it] every day".

Should code skeletons be avoided at all cost? I do not think so. Most of us can not see dead people, similarly management can not see dead programs. IIABDFI is the golden rule but sometimes it becomes clear that there is only that much marathons a dead man can run. Then, if your job is to refactor such a monster so it becomes maintainable and versatile, it can be as challenging as fun.

What should be avoided at all cost is the summoning of new skeletons in closets. With all the knowledge we have now thanks luminaries in our industry, this should be possible.

Obfuscated by obfuscation

From time to time, I have to add in the list of dependencies of one my projects a library whose byte code has been obfuscated.

Who cares, would you ask? Well not me until I have to step debug into the said library because it is usually easier to follow an execution path than a technical guide. And then the pain begins: obfuscated library are (intentionally) a mess and you can not do anything in debug mode with them.

So here is my messages to vendors and other smart guys who think security by obscurity works: this is freaking retarded! You prevent legitimate users to do their business with your library the way experienced users do. No matter how good you think your user guides are, when something goes wrong, nothing replaces the ability to follow the actual execution of a program. As Bruce Schneier says it:

Security by obscurity: it doesn't work, and it's a royal pain to recover when it fails.

So please, do not obfuscate the libraries you distribute, no matter how proprietary you think they are. Your value, as a software company, does not reside in the heart of the few bytes that you try to hide. It lies in your people, your know-how and your services.

Let there be light!

Iconoclast

I am wondering how long this icon will keep meaning "Save" to anyone:


This icon does not mean anything for my kids already:


For them a phone is either cordless or cellular: no funny roundy thingy on it!

Coming back to my first example, the last time I have used a floppy disk was in 2005: is it time to overhaul our icons?

How To Always Look On Strike?

Follow the example of the world champion in the domain, i.e. SNCF.

Like them, implement some kind of lousy "not available" message to display if you hit your web site without typing www in the URL. Since many users now omit the dub-dub-dub prefix, your site (hence your company) will always appear under repair. Or on strike. Or both.

Try it! Click http://sncf.fr now!

Agitation On Demand

In my previous post, I talked about how sweet it is to push the limits of unit tests for the sake of increasing test coverage. During the testing frenzy I mentioned, I came to test a class whose most of the methods throw an UnsupportedOperationException.

Ugly? Well, this class is a subclass of javax.servlet.jsp.PageContext with a very narrow scope of usage, so this is why.

I wanted to generate calls to all these methods and catch the exception as the expected test result. My first thought was to use reflection to do this in a dynamic manner but before to opt for this approach I decided to Google for free unit test generators. This is how I came to discover JUnit Factory, a test generation service from Agitar. I already knew Agitar from Agitator, their award winning unit test generator. But their online generation service was unknown to me.

Needless to say that this service is very well done. The client I used is an Eclipse plug-in, that seamlessly installs on version 3.2 from a proper update site. To avoid uploading my whole project to their service, I isolated my troubled class in a temporary project and pushed the magic button.

A few seconds later, a test case was automatically added to my project, with all my problematic methods (and all the other ones) thoroughly test covered. Awesome: agitation on demand truly works! In other times, anarchists would have rejoiced.

When I decided to include this test case in my main project, I started to hit some issues. The unit test does not extend JUnit's TestCase but an Agitar custom one. Decided not to be stopped by such a minor issue, I promptly added their library to our Maven repository.

Then I pushed the execute button in Eclipse to run my tests and the Agitar test case complained because the launcher was the standard one from JUnit and not their own. This is when I called it quit. Of course, I could have modified my Eclipse start command to use their launcher. But with my Maven builds and reports?

That was a little too much to do and I decided to walk the path of reflection to systematically invoke the targets methods.

This is too bad because JUnit Factory is really a great concept. Try it, it might work very well for your needs.

Push Tests, Pull Cover !

I have nearly spent the whole day increasing the test coverage of one of my project. For traditional employers or ill educated project managers, this could sound like an incredible waste of time. For others, this could sound like pure geeky zealotry or a new mean of self satisfaction for IT nerds.

Indeed, seeing the coverage report display numbers above 80% is extremely satisfying but the true reason for this testing frenzy is elsewhere: this project being bound to play a critical role in the core of the business of my company, testing it thoroughly is simply the only option.

Beyond the assurance such a high coverage buys, the implicit documentation of the system's behavior that an extensive battery of test creates is worth the effort on its own. But there is more. As recently discussed by industry guru Andrew Binstock, writing tests will inevitably lead you to question both design and implementation. Hard to test classes full of not covered "blind spots" will cry for refactoring!

I was amazed to see my code getting simpler and more concise while I was struggling to push the limits of the test coverage. I wish you similar amazing moments!

Max Planck and the TCO

In "Pitching Agile to Senior Management" (DDJ June 2007), Scott Ambler presents tactics for introducing agile approaches to management. Besides the necessity of talking the right talk, Scott emphasizes the importance of avoiding an "us versus them" way of thinking and, for this, to recognize the virtues and values of management.

In this article, Scott presents how quickly agile software development starts to provide value and how this factor can help pitching the positive bottom line impact of agile. There is though a parameter that management will also consider in this board game: an agile team is significantly more expensive than a traditional one. Agile teams are usually staffed with seasoned developers who are generalizing specialists: these species are more expensive that the usual programmers and analysts traditionally managed projects are used to deal with. And this is without mentioning the folly of co-located teams when you can have cheap and qualified labor near or off management shores!

Hence the comparison graph of the total software project costs will probably look like this...
... with the green line showing the cost of agile approaches while the red one shows the cost of traditional ones. So this is good news: agile still beats traditional over time! Yes, but the big question is how far in the product life time line will management look when making their decision. It might sound obvious that the whole life time will be considered always but it is not.

There are situations where management will have a narrow sight on this:

• Organizational reasons: Maintenance of the product will be handed-off to a different unit, unconnected with the current managers. This happens in large structures and the point in the hierarchical pyramid where development and maintenance management chains meet is so high that no-one will look into how decisions on one side affects the other.
  
  
• Personal reasons: upcoming promotion or retirement can make a particular manager not inclined into looking too far in the future. Though this might sound unprofessional or rare, with the baby boomers now on the departure, this situation will occur more than you think.

In these situations, you might end-up hitting a wall harder than Planck's one. And if this wall happens to be before the point where agile starts to deliver its financial goodness, as shown here...
... your pitch might be very difficult! In that case, you will have to be agile and re-factor the pitch to focus it more on time to market or quality aspects rather than sticking to the money side.

ANTLRWorks Works For Me

Alright, so writing XML really put Uncle Bob in rage. Of course, he is right: XML should be limited to machine to machine exchanges and should never be forced down the throats of human beings, let alone geeks of all sorts. The natural consequence of that is I decided to start looking into adding DSL support to NxBRE, as writing RuleML is really not a fun task.

In my wildest dreams it will remotely be as good as the DSL support of Drools (including a code-assist driven full text editor). The harsh reality of (a busy) life will probably limit the scope of this addition to NxBRE but should anyway give the rules authors a better way of expressing themselves.

To build the grammar I decided to use ANTLR and its great companion tool: ANTLRWorks. I came to this choice thanks to Martin Fowler's current exploratory works on DSLs.

ANTLRWorks has proven really useful in this endeavor: the immediate testing and debugging of the grammar is complemented by a tree representation of the exploration graph that simplifies the detection of syntax goofs and other mistakes.

I have committed the embryo of a rules grammar in the trunk Misc directory. Capturing is still to implement. Then a translation table of plain English format blocks to RuleML atoms will have to be added.

ETA is obviously N/A ;-)

Meet The Real Brain

My cousin Manuel will be talking tomorrow at Nanotech 2007, in Santa Clara, CA.

The subject of his session will be: Near-Field Raman and Luminescence Spectroscopies to evidence chemical heterogeneity of surfaces with sub-wavelength spatial resolution.

Boy, I feel dizzy, proud and really like an educated plumber.

For French Readers Only

Sorry for the segregative title but, alas, this post only concerns those of you who can read French.

Indeed I am happy to invite those of you who can to subscribe to Zeskyizelimit, a witty blog from IT industry samurai Jean-Luc Ensch. Sometimes impertinent and always pertinent, this blog will give you a different view on what is going on in our beloved professional field and also on what happens in this part of the galaxy.

I am saying alas because, unfortunately, no translation tool will be able to provide English readers with a fair rendering of Jean-Luc's humor and bonts mots.

Enjoy the reading!