Just Read: Best Kept Secrets of Peer Code Review

Though a company sponsored book, this collection of essays on code review is enlightening. Rooted in the real world, the book makes a clear point for a practice that tends to be overlooked in most of the software shops. A recommended reading for anyone who wants to learn about the state of the art of code review and how it can benefit an organization and its people.

Time To Run

Everybody loves re-use: no-one would like to re-invent the wheel (at least no-one worth calling a colleague). Re-use in action can be tricky, though, as the library or component you intend to leverage can come with strings attached under the form of runtime dependencies. These dependencies can take several forms, each with a different twist but all with the same promise to make your job a little more... intense!

• Framework dependencies are often the (incestuous?) children of configuration and reflection: when the latter gets driven by the former, the incertitude concerning what concrete classes your application will actually use, grows and can reach the point when it endangers your system. As an example, consider the way JAXP's concrete classes are determined at runtime: though you program to a unified API, which allows you to re-use existing parsers and processors, you must code your application defensively to ensure the runtime dependencies will provide the features you need.
  
  
• Data dependencies dependency will leverage your existing database, whatever its can be pulled into your application when you re-use a component that carries its own DAO layer. Provided the data layer is flexible enough to accommodate your choice of database engine, this can be managed easily. Things can get tricky if you have several applications re-using the same component on the same data source: you might well figure out the component was not designed for this particular deployment model. Things can get even trickier if several applications use different versions of this component on a shared database! A positive example here is jBPM, that you can embed in your application and which will require state persistence: thanks to Hibernate, this runtime dependency will speak the SQL dialect of your existing database, hence will not bring havoc to your application.
  
  
• Service dependencies differ from data ones from several of their characteristics: they promote sharing logic above data, they can encourage loose coupling (but not always: think about EJB clients) and they are generally more concerned with and capable of backwards compatibility. This kind of reusable components, which are often developed in-house, must be carefully crafted to evolve well in space (different deployment environments) and time (different versions). When the grand dream of service auto-discovery and auto-wiring will be fully materialized, these dependencies will become more predictable and manageable. SCA will also play a great role in improving the usability of service dependent components.
  

Though modern build tools, like Maven, do a great job in dealing with software dependencies, the domain of runtime dependencies is still not yet clearly formalized and fully standardized. Figuring out beforehand these hidden catches and their potential impact on the component reuse you envision can save you some pain.

Keep It SimpleDB

Now that Amazon SimpleDB is out, the open source competition has started and we can expect some pretty good stuff to come out soon and allow us to leverage this new cool tool from the AWS family.

I would personally be interested in a JCR adapter for SimpleDB: this would enable a semantically meaningful data storage layer to be plugged on top of the Amazon service. Think about massively distributed content management system...

Another cool idea, one that would really be dear to me, would be a RuleML fact base adapter for NxBRE. Since SimpleDB is built on Erlang, it naturally manipulates tuples, which are the essence of RuleML's atoms and facts. A fact base adapter would allow the rule engine to tap into a centralized knowledge base and make deductions out of it. Think about massively distributed expert system...

Precious Revisions

In his most recent post, Martin Fowler talks about the necessity to teach clients about the value that resides in the tests his company delivers with any software solution they ship (and how, without this recognition, tests will be altered and mangled by the client, thus will lose most of their intrinsic value).

Indeed, it is interesting to recognize that clients might consider that the only valuable outcomes of a software project are the software itself and its documentation, and consequently ignore other valuable resources.

In that matter, I think there is another valuable outcome that exists but is generally ignored by clients: the source control revision history. Understanding how a software has been built not only reveals a lot about the professionalism of the builder but also helps understanding how the application took form and reached its current incarnation, which can further help making it evolve gracefully.

As a software consulting client, the most convenient option is probably to open a dedicated source control repository for the consultants and grant them access both internally and externally (they will very often work off site). After the project has been completed, the source code and its history can then be moved from this repository to the client's private one. Similarly, an alternative option is to let the consulting firm use their own repository provided a export/import path exists between the consulting and the client source control tools.

To sum it up: cherish your code and its revisions! After all, this should come as no surprise since everybody knows there is a lot to learn from history: this is just a different context!

Jung Juggles Data Jungles

I am convinced that one of the tasks of a software architect consists in improving or building tools for software developers, so they can be more efficient in their daily dose of fun called "work". This of course includes visualization tools, a subject dear to Gregor Hohpe, who gives great insights on how and why visualization can help make sense of data whose amount or lack of order make hard to grasp.

Beginning of this year, I started to experiment with a very good library named JUNG, an acronym that means "Java Universal Network/Graph framework" and explains exactly what it is. So far I have built a pair of tools:

• A grapher that analyzes the JCR repository of a web CMS and represents the component and templates as graphs, by following the hierarchy of inheritance they engage into.
• A analyzer that parses a lenghty JavaEE web application deployment descriptor and represents as a tree the filters involved into processing HTTP requests.
  

Very easy and fast to develop, thanks to JUNG's clear API, these visualizers have been useful to find out discrepancies: for example graph disconnections or node duplications were nice visual clues that helped locating problems.

I invite you to explore the power of visualization on your own, with your own data and challenges.

Mule Meets Rabbit

I have just released version 1.1.0-M1 of the Mule JCR Transport.

This new version represents a major step forward, as the transport now supports both reading and writing content to a JCR repository. The transport can also handle standard and custom node types thanks to an extensible type handling framework.

Just go and read the user guide to learn more about the features of this milestone release. You can also download the packaged release or simply add the Maven artifact to your project.

Note that the support of transactions and streaming are scheduled for the M2 release.

I hope you will enjoy the new possibilities that occur when a Mule meets a Rabbit.