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.

Celesstin Project Alumni LinkedIn Group

Celesstin is a system that converts mechanical engineering drawings into a format suitable for CAD, that has been developed in the early nineties.

I encourage all alumni from the Celesstin Project (I, II, III and IV) to join this group.

WebSpring

In the recent announcement for Spring Framework 2.5, I have been struck by the following line:

Officially certified WebSphere support

I think this is a very positive unfoldment in the Spring and BEA joint adventure. From a technical standpoint, the Pitchfork project was already very appealing, thanks to the seamless integration of Spring with Weblogic, providing all the goodness of the first at the core of the latter (instead of the usual "on top of JEE" deployment model).

Moreover, for developers, being able to benefit from Spring was a good way to restore the somewhat tainted "coolness" of a such traditional platform like Weblogic. Moreover, it is interesting to compare BEA's move to the one of JBoss, the hippest application server of that time. Indeed, JBoss passive-aggressive relationship with Spring has been, and still is, instrumental in making developers reconsider their commitment to this application server.

This newly announced certified support will ring a bell at management level, especially in the risk-averse prime market of Weblogic (financial and insurance institutions), where using an open source framework, as excellent it is, is very often frown upon (on the other hand, pragmatism is also a characteristic of such a clientele, especially in the UK, explaining the successful commitment of VOCA to Spring).

How this official support will materialize will be critical to the eventual success of this partnership, especially knowing the usually poor support vendors offer to their clients compared to the one they can get from open source projects.

Eclipse Default Key Mapping Request

Every time I install Eclipse, I have to bind "Refactor > Extract Constant" to Control+Alt+C or the equivalent with the funny Mac keys.

This refactoring is really common and I think it ought to be in the default mappings of Eclipse.

Am I the only one thinking so?

Recently Read

I have read this book cover to cover in just a few commute trips: it is indeed a fascinating reading to discover the ingenuity that hackers employ to abuse on-line games, sometimes for profit, often for fun, and the privacy-invading counter-measures games companies put in place. An eye opener for anyone playing on-line games who would not be willing to share all his private information with vendors.

A very good introduction to Erlang, which really invites you to start building resilient and parallel applications. I was amazed to see the similarity between Erlang's pattern matching philosophy and RuleML's.

Moral Code 2.0?

Should software developers have a moral code about their coding? ThoughtWorks says yes, according to eWeek's "Toward a Discussion of Morality and Code" article.

Anything new here? Not for any member of the IEEE, as its Code of Ethics clearly puts forward values that constitute an inspiring moral code.

So is it worth mentioning ThoughtWorks position? Certainly, because our industry needs thought leaders that establish credible models to follow. Why is this? Maybe because software development is one of the rare professional field where someone can read a "Teach Yourself" book and proclaim to be a specialist the week after.

Nor surprisingly, this practice of over inflating skills is not rare and often even encouraged by software consulting firms, in order to seduce clients and secure contracts. Hence, an interesting question to ask Mr. Singham back is: Should software consulting firms have a moral code about their developers?

His answer might also teach a lesson for others.

Root of the Rot

I recently had to satisfy a pretty simple feature request for one my projects: to be able to reload part of its configuration at run time. Not a big deal, right? Well, not exactly. In fact, I have been amazed by the impact such a simple change had on the system, if not as a whole, at least in all the critical sections of it.

It is well known that applications tend to rot after time (i.e. after changes have been made to them) but, up to this recent feature request, I was unsure of the the actual cause of this rot.

Application rot comes from the chaotic relief of the tension created by changes that induce changes in fundamentals and invariants. This chaotic relief increases the software entropy, as software quality and maintainability principles get violated.

As I was implementing the aforementioned new feature, the tension on the application was causing its design, its thread safeness and its clarity to degrade at a distressing speed. I was going fast, but not. Fortunately, my alarm bell was ringing loud and clear and, after reverting to the latest head revision, I started again with a holistic plan that was taking care of not increasing the entropy of the application.

During this I have noted that nowadays:

• Tools are efficient in helping us keeping the entropy low (FindBugs and Checkstyle were shaking their heads about some bad stuff I was doing),
• Libraries are now rich enough to help mitigating changes that can compromise thread safety (think Java Concurrency or Intel Threading Building Blocks),
• Industry luminaries have preached the need of elevated professional standards enough to make us become conscious of software rot when it happens (the bell goes on).
  

Will Find Your Bugs... Tomorrow

I have just upgraded to the latest version of the Findbugs Eclipse Plugin (1.3.0.20071108) and landed in a terrible world of sluggishness.

The new version of the plug-in is so slow on my machine (a 10 months old Mac Book Pro with 2GB of RAM, running Eclipse Europa) that I had to reverse to the previous version of the plug-in (1.2.1.20070531). I did not consider canceling the auto-run feature of Findbugs because I do not want to forget to run it: this is one of the interesting aspects of this plugin (without this option, I would simply uninstall the plug-in a rely on the Maven report that contains the same information).

Maybe the issue is visible because my project has a little more than 80 dependencies (the joys of open source). But the previous version was fast enough so something has probably went bonkers in the latest release of this very useful plug-in.

Any other one out there facing the same issue?

Back to Humans

This month issue of Computer runs an article titled "Generation 3D: Living in Virtual Worlds", which ends up predicting that virtual 3D worlds could become pervasive in our lives by 2047. I must admit that, as cool as living a virtual life in an MMORPGs sounds to a geek like me, I am frightened by the implication for our societies.

If our avatars become the main mental projection of our psyches and if our disincarnate-selves become our main subject of concerns, what would happen to such fragile things like the environment, democracy or compassion ?

Will it matter to the "generation 3D" if the Earth must be over-exploited to produce enough energy for powering the zillions of servers hosting their fantasy worlds?

Will it matter to them if their countries turn into police states where their only liberties will be virtual, abandoning the ideals that founding fathers and thinkers of the past had for mankind?

And finally will it matter at all if others will be left out dying of cold or hunger at the fringe of the digital society?

Was Queen prophetic?

Geek Pride

Whatever the subject of his post entry is, Uncle Bob always ends up hammering the ultimate goal that should drive us, software developers:

"It is not good enough that a program work. A program must also be written well. As a programmer you should take pride in your work and never leave a mess under the hood. Remember, a product that works, but that has a bad internal structure is a bad product."

Thank you Uncle Bob. May you be read at all levels of management.

Software Patents Or Not?

This month issue of IEEE Canadian Review runs a very interesting article titled "Patenting Software Innovations: A brief overview of the situation in some jurisdictions of interest" (PDF available for download at the top left corner of this page).

In this article Alexandre Abecassis gives a short but informative overview of the reality of software patents in Canada, USA and Europe. A must read, if you want to have clear ideas on the subject.

Another One Rides The Bus

At a time when big brains start to wonder what an Enterprise Service Bus (ESB) is all about and have doubts about the health of Service Oriented Architecture (SOA), today's post of Uncle Bob is a refreshing pragmatic counterpoint, as we can expect from him.

Of course I can only concur, but I must say that scorning enterprise service buses, as he does, is not necessary (maybe it is, just for the purpose of counterbalancing vendors who try hard to push expensive ESBs on clients...).

For me, an ESB is a distributed intermediation middleware whose main goals are:

• Facilitating applications interoperability, and
• Reducing applications coupling, and
• Avoiding point to point communication, but also
• Favoring asynchronous messaging and eventing above synchronous remote invocation.

I believe that deploying an ESB does not imply to embrace the full canonical SOA gong show, but can, in fact, be a good occasion for preaching the values I listed above and alleviate the following inevitable traits of a mature software landscape:

• Applications tend to know too much about each other, with integration happening at data level, if not database level, and sometimes happening beyond the enterprise boundaries.
• Applications tend to wait too much for each other, engaging in long chains of synchronous requests while asynchronous messaging could be used to free up threads, hence resources.
  
• Applications tend to talk too much when they have nothing to say: polling mobilizes resources while efficient, yet simple, notification mechanisms have been around for a while.
  

As time passes, each change becomes more and more complex and risky, as it is hard to estimate what other application will go bonkers if you dare touching something. Nothing new here: this is just a macroscopic replay of what happens inside the applications, where components also tend to develop tight coupling.

So an ESB is not a golden hammer but is just an occasion, a driver, a extra reason for making things better. Presented like this, it is not surprising to find out that anyone who value what they do are willing to ride the bus.

Today is B.A.D.

Indeed, this is Blog Action Day and bloggers all around the world talk about the crucial subject that environment is.

What could I say that has not been said before? I do not know so here is the picture of a salmon I took yesterday afternoon in the creek that flows next to my house.

I wish many wild salmons to the next generations.

Yeah, Please Fix It!

I am tired of having my MacBook losing its Wifi connection, while my XP and Kubuntu boxes have no trouble with it.

The inspiring life of Eric Hahn

In the October 2007 issue of IEEE Spectrum, an article (The Codemaker) depicts the life of Eric Hahn, who "has been an executive, an entrepreneur, and an investigator. But he's happiest of all to call himself a programmer".

The life of Mr. Hahn can only intimately resonate with the life of the many whiz kids who started computing when this activity was only starting to become known to the public. Indeed, I started a few years after him and on a smaller scale of machines (Sinclair ZX-81 instead of a Digital PDP-8/m), writing tiny games instead of hard-core emulators. Living in the countryside of North-East France, the analogy stops here as Mr. Hahn had access to the more stimulating and responsive environments of New York and the Silicon Valley.

One very touching aspect of his life is the tension between making a career and remaining a programmer. Throughout the years he kept his passion writing code and has find enough will and talent to create himself opportunities to keep developing. This tension is symptomatic of our societies that respect more those who make others do than those of do, pushing people away from what they thrive to do to.

“I wonder,” Mr. Hahn says, “how many programmers are trapped in the bodies of Silicon Valley executives. We tend to leave programming jobs because they just don't pay enough to support kids and mortgages here in Silicon Valley. But increasingly, when people have some material independence, they revert.

The only thing I can teach Mr. Hahn is that this is not happening only in the Valley!

____
As a side note: if you are not already a reader of IEEE Spectrum and have any interest in technology, I can only strongly encourage you to subscribe, as this is the best magazine I happen to read nowadays and the only one I read cover to cover.