Just Read: Release It! and ThoughtWorks Anthology

If you intend to write software that lasts and fares well during its journey, give yourself a hand and read this book. From actual situations, the author derives very concrete recommendations towards writing scalable and operable applications.

As far as I am concerned, reading this book has been an exhilarating experience. Though to a much smaller scale, I have experienced the same pains and came to similar conclusions than the author. Reading some pages entailed some sheer moments of excitement, very much like: "I have been saying the same!".

All in all, I am grateful that Michael Nygard has written such an authoritative book on this crucial matter for now no-one will be allowed to say "I did not know" anymore.



This book does a pretty good job at offering insights and real world feedback from top notch ThoughtWorkers on a variety of software development related subjects (coding, designing, building, QA). For a collection of essays from different authors, the overall uniformity has been pretty well maintained both on style and content.

As a software developer, I have found Neal Ford's "Polyglot Programming" and Jeff Bay's "Object Calisthenics" to be the most compelling pieces of this book.

At the end of the day, the real interest of this anthology resides in the fact that a small consulting firm has decided to share its sheer passion for software in a direct and hype-free manner. How many of the big ones out there could do the same?

I don't know... yet!

In movies, computers know everything. Just ask the computer and you will get an accurate answer now. For us, developers who have to deliver the promises made by Hollywood, programming software that gives correct answers immediately is very easy. Unfortunately it is also very costly.

Giving the correct answer generally translates into querying the one source of truth of an application: the database. This is easy.

Sometimes the database is far away from the access layer the caller interacts with, whether it is a web tier or a service tier. No problem! It is very easy to ask the caller to hold his breath until a long chain of synchronous calls gather all the correct data needed and finally present it as a glorious reply. Usually the caller has enough breath to wait until it has to get some fresh air again (some call this a time out).

All this is fairly easy but unfortunately very costly. Contention to access the centralized source of blessed truth increases as more and more callers want to access it. If, for the sins of the application, it gets successful, the number of callers holding their breath while waiting will increase dramatically.

It is a time when the application would love to have callers with smaller lungs, so they could time out faster and free the threads they are holding while sitting idle. But they are not: the dozens of second they wait are an eternity for a server. Instead of being glued waiting for a remote service or database to deliver the ultimate answer, the application would like to afford replying:

I don't know... yet!

At least, this imprecise but immediate answer would allow the server to release threads almost as fast as they come. This would give the application the luxury of replying later, whenever possible...

Of course, such a paradigm shift is all but transparent for the caller: he must learn to deal with imprecision. He must embrace asynchronism. He must survive eventual consistency.

We now have the tools, from the web tier to the back end. Can we succeed in this paradigm shift?

I don't know... yet!

Not Dash Bored

I love dashboards. You probably got that from my previous post. If I had enough screens, I would be surrounded by dashboards of all kinds: work tasks lists, continuous integration server control panel, project metrics sites and server monitors.

Maybe this comes from the time when I was handling another kind of dashboard, from which my life was directly depending!

(Yes, I am a pre-glass cockpit flying dinosaur)

Dashboards are great because they present a synthetic view of a situation in a form that is visually expressive and does not require a lot of concentrated attention to capture relevant and crucial information.

The most recent dashboard I built exposes particular aspects of several instances of Mule ESB I have under my control. Through JMX, Mule exposes a wealth of statistics about the different components of a particular instance. Here is a small portion of the HTML console that displays this information:


This is too much information the brain, or at least my brain, can digest efficiently and quickly enough. Hence I created a simplified view that represents the variations of message routing statistics on a selection of components:


The components are simply selected by name: I decided to prefix the important ones with "process" and "dispatch" and derived from there a simple selection pattern. I use different colors to show different states:

• Green: no activity,
  
• Yellow: at least one message went through,
• Orange: the backing event queue has been resized up,
• Red: an error has been routed,
• Gray: no delta available (first call of the dashboard),
• Black: component statistics unavailable.
  

Extra symbols represent a non active state of a component, like paused or stopped. The dashboard itself is the aggregation (frames, yuck!) of the HTML output of a specific component deployed alongside the other ones.

Of course, this does not compare to the professional grade monitoring tools you can buy from MuleSource, but is already handy for deployments of limited scope and criticality.

I think the most interesting aspect of this dashboard is how quickly you can develop the ability to recognize a normal behavior pattern from a faulty one. It is pretty much like reading the matrix undecoded... Now how could you get bored from such a board!

UPDATE 03-MAY-2008: This dashboard is now available on MuleForge.

Building Value

This week, one of my colleague (a guy named Josh) was all grumpy about the time he spent adding documentation in his projects Maven sites so operations could deploy his application properly. This made me reflect on how great is this tool not only for building software but value in general.

By giving developers the opportunity to document in the same environment as where they code and by embedding the HTML rendition of this documentation in the project site alongside all the other technical reports, Maven presents to the stakeholders an overview of the value built by a project.

Value is a vague term, so let me be more specific:

• Intrinsic value: technical metrics, like the ones coming from static bug analysis, package dependencies, test coverage or code style compliance, represent the core value of the code in term of quality, flexibility and maintainability.
• Business value: results from acceptance testing tools like Selenium or FitNesse represent the capacity of the application to satisfy business requirements.
• Corporate value: on top of the auto-generated technical documentation from the code base, all the extra documentation that is added, whether it is installation guides, monitoring procedures or deployment diagrams, brings value to the company as a whole, from operation teams to new recruits.

With all this goodness available, I am still baffled by the limited number of managers who pay attention to the reports generated by Maven. I imagine that they might be too technical for "generic" managers who are in the business of software as if they would be in the one of gravel and stone delivery. Moreover, the usual metrics for software development is generally focused only of features delivery and deadlines.

This said, thanks to continuous integration and the dashboard plugin, I believe it is possible to catch the interest of a broader audience because it is now possible to display trends instead of static values: management understands trends.

For example, a flat test coverage value is meaningless but a trend that shows it increases means that quality, thus value, does the same. Similarly, comparing projects based on their metrics is a non-sense, while comparing their trends makes sense.

Did you have any good experience sharing Maven sites to management? Did they get the feeling that value was being built?

Abstraction First

When designing services, the common wisdom is to opt for a contract-first approach, instead of an implementation-first one. There is no question that this is a valid approach but I think the emphasis should be put on the necessity to design a good abstraction first.

Consider this: technical implementations, especially in strongly typed languages, often result into a pollution of the client model by the service model. Interfaces or stubs used by a client to perform remote invocations can very easily become mixed with its own domain.

This creates a tension between a service provider and its consumers, as they often tend to drive the contract too much on their side because they consider the local crystallization of the contract as a part of their model. Exacerbated, this tendency can result in tight coupling between both parties.

Let me give you an old but typical example from my tumultuous past.

A little more than a decade ago, I worked on a corporate centralized contact management system. It was supposed to serve contact details (persons, organizations, addresses and whatnot) to all the applications in use in the company, including secretaries' word processors. Admittedly an interesting project, it in fact quickly turned to be a death march. I soon learned this was the sixth attempt of such an endeavor and that people wanted to see how a n00b like me would fare.

I then realized that each department wanted very different things out of this system and their views would not be reconcilable. I ended shipping a version that was only usable by the secretaries, which I think was a smart move as you must always be good to them!

The next n00b was assigned the creation of version 7 of the contact manager, built on what I did with the goal to generalize it to all departments. Of course it failed and the project disappeared for ever. Maybe the mythical number 7 was to be reached before the whole stuff could have been killed.

At that time, if I would have known better, I think the best I could have done would have been to advocate for the deployment of an LDAP provider. Indeed a directory server accessed via this protocol does not try to be everything for everybody and does not present a contract that any application would consider using in its own domain model. Yet it offers a simple and powerful abstraction that an application can use to query directory information and then tie them with its own object model.

Let me quote Uncle Bob:

"Abstraction is the elimination of the irrelevant and the amplification of the essential"

To me this sounds almost like a caricature, where the most prominent features are made so obvious and visible that there is no doubt left about what really matters. A good abstraction for a service should then translate in clear intents and well defined boundaries, which would guide the creation of valuable contracts.

Finally, for all these existing services that want to invade your application domain, there are fortunately ways to remain insulated. For example you could:

• use dynamic language scriptlets to perform remote invocations and set values on your local domain,
• use Dozer to tie client stubs and your objects,
  
• consider invocation responses as raw XML and extract values out of them with XPath.
  

Fruit and coffea? I don't think so...

Last year, a guy named Marc Fleury ranted about how Macintosh was not a suited platform for software development. At the time I thought he just hated it because he is French, and French people hate everything. Let me quote him:

"a mac is like a bimbo". It looks good and shiny from a distance, you think you really want to try it. But once you do, after 2 weeks of "doing it" you are bored, bored to tears. Tired of everything, the pretty animation stuff, the big tatas, the transparent look and feel, the big tatas, the genie bullshit animation, the big tatas, the stuff that is different from windows "just to be different", the big tatas and the empty brains.

Nowadays, I am the one who daily (hourly) complain about how clunky and inappropriate is Mac OS X for Java developers. People around me roll their eyes and probably assume I just hate it because I am French too, and French people hate everything.

But, boy, since I started to use this platform professionally, how much do I find Mac to be a hindrance to my development activities! How often the OS gets in my way and pulls me out of the state of flow I am in...

Here is a non-exhaustive list of my grievances, so you can decide if it is mere ranting or if there are some valid reasons for my grumbling:

• Bitter Java: official JDK support is way behind other OSes. For example, the Apple JDK 6 was beta when I was on Tiger and disappeared on Leopard. Sure I could follow the great work of Landon Fuller with Open JDK, but I honestly do not have time to invest in such endeavors.
• Keyboard support is a joke: even if I am using QuickSilver, I constantly have to grab the mouse to click this, highlight that or dismiss a pop-up. The last one really drives me nuts: why is it that the escape key does not always cancel a pop-up dialog?
• Focus messy: there is always an application that steals the focus out of my working window. Maybe this is the fault of badly behaving applications, but it is the first OS where this happens to me so often that I get annoyed by it. Is this OS making it easier for applications to become focus-rude?
• Prompt to freeze: the UI freezes very easily, to the point I can not even switch applications or invoke the task killer. It seems that a badly behaving application can very easily mess-up the whole user interface, hence the whole OS.
• Hidden BSD: it is hard to say this but as far as the overall stability is concerned, OS X reminds me of Windows ME sans Blue Screen of Death. I have to do hard reboot at least once a week, whether the screen saver locks me out for ever or the UI freezes to the point I can not do anything except sitting on the power button. I have not seen this in any OS for almost a decade. And having this kind of behavior on an almost newly re-installed machine, with minimal applications running, is a plain disappointment.
• Finder sucks big time: for an OS that is supposed to be all about user experience, I find the Finder to be a complete disgrace. Try to create a new directory: it never ends up where you want it. Try to shift-select files with the keyboard: going up and down performs some counter-intuitive file selections. Then use the mouse to drag the selected files: they might end-up where you drop them, or not. Instead of adding a new view in Leopard (cover flow), if only Apple could have fixed the existing ones so they become really usable (who uses the insane column view?).
• Flaky AirPort: I am constantly losing connectivity with my Wifi router. Maybe my cheap D-Link router is the issue, but then why my other non-Mac machines have no problem maintaining their connections up and running for hours?

I will not mention Eclipse that dies unexpectedly on Leopard while it was stable on Tiger (yes I have configured the JVM memory parameters, thank you). I will not mention the disgrace that is Entourage, because it is a Microsoft product and Apple can not be blamed for it. And I will not mention that my MacBook Pro hard drive fried just after a year (bye-bye guarantee), which is the first time something like this happened to me for the past ten years that I have been working on laptops.

Nuf' said! So what are my platforms of choice for Java development? In order of preference: Kubuntu, Windows XP and... Mac OS X. But at home, I am very happy with the little white Mac Book we use for browsing, e-mailing and managing photos. For this kind of home activity, having an OS that shows off is acceptable. For professional usage, the less the OS gets in your face, the best it is.

Healthy Health Checks?

Here is a little story that happened to a friend of mine a few years ago. Users of his web application started to complain about the system being broken and not responding anymore. The curious thing was that the operation team was not aware of any issue. After checking with them, it appeared that the monitor they had in place for this web application was simply checking if an HTTP response was received. Any response. Even a 500 one!

This sounds naive and ridiculous but setting up application monitoring is a subject that is a little more hairy than it appears at first glance. Consider another more recent case that came to my attention: in this case, the application was still replying positively to its health check monitor but was not functioning properly, as it was unable to access required file system resources. Again, the end users were affected while the monitoring was happily receiving correct responses from the application.

So how can we, software developers, create health checks that operations can rely on?

Taking the canonical multi-tiered web application as an example, the following schema shows an health check that is too shallow to be useful (in red) and one that exercises the full layer depth (in green).
While it is clear that the shallow approach brings little value, as far as end user quality of service is concerned, why do not we always shoot for the deep approach then?

Well, if you consider how a serious load balancer appliance (like BIG-IP) works, you will realize that if performs health checks very regularly (by default every 5 seconds) in order to have the most up to date view of the sanity of the members of the pools it handles. Bearing this mind, if an health check request would exercise the full depth of an application, you would have a permanent load added to your system, which would increase the strain on your diverse resources, down to the database itself. With a farm of n servers, the cumulated strain induced by the health check requests on all the members of it would start to be non negligible on any shared resource.

My take on this would be the following: create an internal watchdog that evaluates the sanity of the application at a reasonable pace and report the current state of this watchdog when a monitor requests a health check from the application.

As shown in the above schema, the watchdog life cycle is uncoupled from the health check one, which allows to reduce strain on the underlying resources while allowing the monitoring environment to become aware of an application issue almost as soon as the application realizes it itself (because the monitor polling frequency will be kept high).

What is your own experience in this field and what is the path you have followed in order to build dependable health checks?

Dumb XML

Beautiful Code is a book that can not let oneself indifferent. While reading it, I have been really annoyed by a statement made by one of the authors:

What I always tell people is that XML documents are just big text strings. Therefore, it's usually easier to just write one out using StringBuffer rather than trying to build a DOM (Document Object Model) or using a special XML generator library.

I fully disagree with this position, because I have seen time and again the adverse results of such a simplistic approach to XML generation:

• Malformed XML: basic string construction does not handle general entities escaping, element name validity and correctly balanced tags. I once had to deal with an XML document that was so broken I initially thought it was SGML. It was neither and I ended using regular expressions instead of SAX to parse it.
• Invalid XML: applications that generate XML should be polite enough to validate the data they produce before sharing it with other applications. At the time DTDs were current, I followed the practice to add the external declaration only if the document was tested to be valid, like a proofing stamp. Of course, I also had to deal with an application that never considered important to output XML that complied with its own schema!
• Bad encoding: I realize that many developers live and work in a place where ASCII-7 is enough to represent all the characters they need. But the rest of the world cares for accents and other language particularities. Hence again: basic string building gives no guarantee in term of correct representation of Unicode characters.
  

Of course, for trivial XML blocks that will never contain any special character nor vary in form too much, using a StringBuilder (not StringBuffer by the way, most of the time it is unnecessary to use this synchronized version) is more than enough. Of course, you can use helper class to encoding all strings and escape all entities.

But if you go further than the trivial use cases or if the data you integrate in your XML document comes from an uncontrolled source (like a database connection or another application layer), use a proper library for building XML.

XML is simple, but do not dumb it down to simplistic.

Bugs Of Opportunity

Yesterday night, I fixed a trivial bug in NxBRE. Doing so, I have spent almost 5 times more time writing tests to assert the current behavior and the expected one when the bug would be killed.

This reminds me of an earlier reflection on how being test infected changed my reaction to incoming bugs. Prior to become green light addicted, bugs were my enemy and were received a treatment depending on my mood:

They are now an opportunity to improve and increase test coverage, regardless of the mood I happen to be in:
But, as you have certainly noticed it, grumbling is still part of the process!

Fighting The Good Fight

An article published yesterday in the Wall Street Journal (Pleasing Google's Tech-Savvy Staff), made me reflect on the fight for corporate standardization of technologies, a fight in which I have been pretty involved in the past 4 years.

This battle happens at many different levels: operating systems ; database, application and web servers ; development platforms, tools, frameworks and libraries. Is it worth fighting it?

First, let us bear in mind that there are some strong rationale in unifying the different technologies in an IT landscape. Here are a few:

• Limited and simplified licensing and support contracts negotiations,
• Facilitated software maintenance and operations,
• Improved interoperability and potential for re-use.
  

But there are risks too, like:

• Golden hammerism: Forcing the use of technologies into scenarios where they are not adequate,
• Team entrenchment: any technological choice usually satisfies as much people it displeases,
  
• Kool-aid intoxication: single vendor dependency often reduces options and opportunities for using better fitted approaches.
  

Is the Google way, where people are left free - and responsible - for their technological choices a viable approach? Can it even work anywhere else, where the density of geniuses is much lower?

I will not discuss the advantages of single server operating systems strategies: despite the clear advantage in term of resource management, the raise of virtualization platforms have somewhat made a multi-OS environment an easier possibility. Narrowing the discussion to developers, who have the tough job of taking decisions in a world where every day brings a new and promising tool, what is the actual risk of letting them make choices?

My experience in the matter taught me that:

• No project gets doomed by its technological choices: I have seen more harm done by the abuse or misuse of a particular framework, than by the framework itself. And yes, this also holds true for projects condemned to use Entity Beans.
• Applications designed on the same platform do not inter-operate by the sole fact of being developed and run on the same platform.
• Similarly, re-use does not happen by unifying technologies (except if you develop for portals and want to re-use widgets without resorting to HTML scraping).
  
• Paid-for support for open source projects is seldom useful (while "quick-start" consulting gigs are valuable).
  

So, rather than the quixotic pursuit of the perfect unified IT environment, what is the good fight worth sweating and bleeding for? I believe it is worth fighting for the following:

• Practice quality over dependencies uniformity: more than the usage of a common set of libraries, improving code readability, test coverage, application design and build practices have the biggest impact on the maintainability and evolutility of a particular application.
• Loose coupling over platform uniformity: an IT landscape greatly benefits from systems that have clear contracts between each other, interact in well defined and contained manners and can gracefully survive if their neighbors have temporarily fallen in digital limbos.
• Operation friendliness over environment uniformity: applications that are developed while having operations in mind have a happier life in this world. Targeting a particular server or database or OS does not automatically translate into an application that will be easily handled by the production team of a company.
  

Let us fight the good fight!

Just Read: Beautiful Code

Beautiful Code is probably the most unequal software book I have ever read, both in term of style and content. Some chapters are very formal and academic, while others are more relaxed and down to earth. Some chapters really offer food for thought in the matter of software development, while others are arid displays of obscure code with no lesson to gather from. If all the royalties were not given to Amnesty International, I would have felt totally frustrated by this book. At least, I have the feeling to have served a good cause with my money.

Unchaining Backward Chaining

NxBRE's Flow Engine is currently under work: I have added a simple backward chaining scheduler that can execute sets in order to produce a specified goal in the rule context. Not all rule bases qualify for it: no construct should exist outside of any set to be usable in this context.

This will allow to support Reaction RuleML as an input, alongside the current proprietary syntaxes, hence to be able to consume the output of Acumen's RuleManager, an excellent tool for BRE related development on the .NET platform.

Stay tuned for the upcoming new release. In the meantime, the most adventurous can already try the backward chaining engine by checking out the latest version out of SVN!

Was @SD West 08

SD West 2008 is over and my brain hurts. But batteries are reloaded: this is what happens when you come close to the luminaries of our industry. And it is a great feeling.

The CMP event team did a great job both expanding the conference with new sessions and filtering out the vendor kool-aid sessions that sometimes managed to enter the schedule.

Kudos and a big thank you to the organizing team!

@SD West 08: Highlights of Day Five

Ten Ways to Improve Your Code (Neal Ford)

Even if I do not fly airplanes anymore (for now?), I try to stay informed about what happens in the pilots' world. One aspect of it that has always impressed me is the importance given to constantly improving one's practice. Software development should not be different. This is why I like this kind of session, as there is always something to improve somewhere!

Neal presented ten ways to walk this path of improvement. Here is a very short version of these ways, consult the slides on-line for the full version:

1. TDD for its design benefits (including DI).
2. Static analysis (byte-code & source analysis).
3. Good citizenship (encapsulation, invariants preservation from construction to mutation, cautious usage of singleton).
4. YAGNI (no speculative development, no more ivory-towerish frameworks pleaeaease).
5. Occam's razor (make the difference between essential & accidental complexity).
6. Question authority (including established so-called standards, rebuke anti-patterns).
7. SLAP (single level of abstraction principle: for this, refer to yesterday's "Clean Code").
8. Polyglot programming (leverage languages targeted at specific problems)
9. Learn the nuances of Java (discover the hidden JDK gems!).
10. Anti-objects (too inspired by the real world and solving problems in a reverse manner).
    

Neal also presented 10 corporate development smells that would be hilarious if they were not tragic! Discover them now. For point 4 (the inane debate about stored procedures), you can also read my take on it in this discussion.

To finish I think it is worth quoting Neal's answer to client who try to find excuses for not making things better:

"Your problem is not more complex or so different than everybody else's!"

Responsible Web Design (Scott Fegette)

As if anything in software development could be responsible (software liabilities anyone?), Scott re-stated the need of staying abreast of current standards and best practices during his very open and non-dogmatic session. He also reminded us where we come from and all the progress that has been made along the way.

Here are a few key points:

• Thinking semantically (avoiding layout-specific markup as much as possible), with microformats for example.
• Properly managing CSS styles.
• Opting for un-obstrusive JavaScript (enough of these links that break when JS is disabled!).
• Staying current with the standards and practices.
  

I will not claim I followed everything in this session, even though Scott did a great job to demonstrate his points with actual web sites and code samples.


Memory Leaks in Java Applications (Gregg Sporar)

My worst memory leak, despite forgetting anniversaries, happened in 2002 when using Xalan. Each XSL transformation was leaving a bunch of not collectible objects in memory, until the JVM had enough and died. Since then, I am worried about all sorts of leakage (and since I am getting older, this should not surprise you), but I still like XSL ;-)

Gregg is obsessed with memory leaks too, but he works for Sun and knows the problem like the palm of his hand. The goal he had for us in his class was:

"To understand the different types of tools and techniques available for finding memory leaks."

He then went through a thorough review and demonstration of different techniques:

• Post-mortem inspection: analyzing a thread dump after the JVM crashed with proper tooling.
• Instrumentation: to perform live analysis of what is going on in the JVM, mainly by analyzing the trend in object generation count.
• A combination of both: to capture dumps on running code.
  

He also explained the lack of user-friendly tooling for analyzing class-loader related memory leaks (that can lead to the infamous permanent generation error). To learn further about this interesting and uneasy subject, I encourage you to read the two articles he co-authored for ST&P in April and May 2007, from which he extracted the material for his talk.


Mock Objects / Mock Turtles: The Role of Patterns in TDD (Scott Bain)

After reminding us the youth of our industry, Scott made this very interesting statement:

"Software Development is both an intellectual and a practical profession."

I find this interesting because I tend to over-emphasis the intellectual part of the job when I digress about the nature of our profession. So, yes, there is also a practical dimension to it and Scott argued that testing is a driving force for this concretization.

So how do design patterns play a role in unit testing? On top of allowing us to use a simple name to communicate a lot of information and context, which is extremely valuable, did the GoF give us best practices for testing these patterns? Unfortunately not. But all hope is not lost, as Scott explained as he went on detailing applicable test strategies for the most prominent patterns (strategy, decorator, façade). This is a work in progress that can be contributed to on Net Objectives web site.

So what is the relationship with turtles? Because some patterns force you to know a lot about the chain of objects behind the scene (turtles all the way down) to be able to test them ; and that placing a mock at the right place can alleviate this issue. It is for this astutely located mock that Scott coined the term mock turtle (well in fact, he recycled the term).

@SD West 08: Highlights of Day Four

HTTP for Web Developers (Jason Hunter)

After his yesterday's talk about caching, Jason detailed the core of the HTTP magic. Indeed modern web development tools very often abstract HTTP out of the development paradigm. You end up with developers who talk about controls on forms as if they were developing Access applications (do not laugh, it happened to me).

HTTP is a wild world: with browsers and servers interpreting the standard in their own manner (often leading to bastardized additions to the standard itself), developers need to know what is happening under the hood.

I will not detail all what Jason talked about but I am always amazed by the amount of extra knowledge you can get when an expert revisits the basics! A highly recommended exercise for anyone who does things with the webernet.


Clean Code: Functions in Java (Robert C. Martin)

Woohoo! A new class from Uncle Bob! It is of course impossible to properly summarize an hour and half of such a magistral session. The main concept that this talk detailed is the following:

"Making code more readable allows us to write code faster, because we end-up reading code twenty times more than writing code when we are in the process of writing code."

So how to achieve this? The general idea is that a function should be an executive summary of what is happening below it: it must be short and should not mix concepts from all layers of the application, in order to remain understandable. This must lead to a recursive functional decomposition and the creation of functions with meaningful and descriptive names all the way down through the abstraction layers. And by the way: if you find hard to find a good name for a method, it is probably because it does too much things.

Here is short summary of the talk:

• Write small function, and if possible, even write smaller ones.
• In a method: do one thing to preserve cohesion, i.e. one level of abstraction.
• Three is the absolute maximum number of arguments: think about how two arguments are already confusing (right order?).
• No side effects: a method should have no strange temporal coupling, it should always have the same semantics whenever it is called.
• Throw exceptions instead of returning error codes because they get mixed with the natural outcome of the method and force ugly calling code.

Someone in the audience asked a question that is dear to me: "there is nothing new here, why keeping repeating it?" Uncle Bob replied: "because we do not believe it". This sounds like the classic "Shema Yisreal", with prophets and priests repeating the same things again and again because the people was unfaithful. We need to hear again and again to internalize things so we practice them. Writing code as if reading it matters is not natural but we can reach this goal thanks to method extraction refactoring.

Ouch. I will spend the rest of my life refactoring my own code.


Parallel or Perish!! - Are you Ready? (James Reinders)

After assuring us that multi-core are not a temporary trick to gain performance that will be deprecated later by faster single core processors, James made very clear the urgency and necessity of a mindset shift towards parallel programming, especially for client side developers.

He then gave us several tips that you can read in an article he wrote for DDJ a while ago.

I have really appreciated his remark on how to consider leveraging multicore parallelism in light of an increased work load, and not only by looking after accelerating existing code.

I was surprised by James remark about the lack of parallelism abstraction in Java: since version 1.5, the JDK offers a wealth a concurrency oriented high-level constructs (like collections, conditions, mutexes, futures and whatnot...). He might refer to the thread management themselves, but again I find that executors are offering an interesting way to splitting work around threads. But he confessed his main focus is on C/C++ though!

I am in fact more surprised by the number of Java developers who do not have clear (or at least basic) guidelines about how they write code that runs concurrently without coughing. As James said: we all have to learn and think about parallel development. Coming from Intel, this shows how much learning we can expect in the coming years!

In the meantime, thanks to either smart scheduling or pure randomness, this keynote was followed by two sessions on Java concurrency and parallelism: so I had an immediate opportunity to keep climbing the learning curve!


Thousands of Threads and Blocking I/O (Paul Tyma)

I was really looking forward this session and was not disappointed. The breadth and depth of the material Paul shared with the audience was worth attending. He did a great job debunking some myths about synchronous vs. asynchronous server models, all backed with hard facts. Here are a few of them:

• Java asynchronous NIO has higher throughput than Java IO (false)
• Thread context switching is expensive (false)
• Synchronization is expensive (false, usually)
• Thread per connection servers cannot scale (false)

Visit Paul's blog for more details and even the slides of the presentation. All in all, this talk confirmed my quasi-gutsy feeling about concurrent development: let the threads flow and be smart about their touch points!


Anti-Patterns in Software Projects: Human Factor (Rob Daigneau)

Writing code as a very mental process, hence is subjected to our human nature, with all its up and down sides. Rob gave a great presentation about how human factor affects software development and how can leaders of all sorts act to make the workplace a better place. This of course spawned a lot of lively discussions, as everybody has so much to say about what happens in their own life in software development.

It is hard to summarize all what Rob said but I really liked his emphasis on passion and how essential it is to let it burn in developers (without let them burning it, which is destructive). I also appreciate one of his final word: except if we write life-critical software, well, it does not really matter that much so better having fun while working. Sounds like a good advice to me.


Developer Bowl

Last year Developer Bowl was all about Googlers and their incredible supremacy in term of computer science knowledge. With Google being in no shortage of big brains, I walked in the theater with the expectation to get a fair deal of deja-vu...

This year was as entertaining as last year's edition. The questions, which were partially submitted by DDJ's readers, were much less oriented on the fundamentals of computer science and more on history and anecdotes. So this year Google did not pass the first round and IBM won versus Intel!

Oh well, it is all rigged anyway ;-)

@SD West 08: Highlights of Day Three

Demonstrating WCF: Beyond the Endpoints - Juval Löwy

So .NET is legacy and WCF is here to increase your productivity? What is this all about?Juval did a great job demonstrating how, by building this new platform on the CLR, Microsoft has delivered a complete development environment that offers a clean and efficient programming model for "enterprise" applications.

But is there anything new here? For .NET developers, surely yes. But from a JEE development standpoint: not really. All this sounds like a mix of EJB3 (framework-free classes, remote exceptions), JBoss call stack model (dynamic proxies, client-side and server-side interception), unified synchronous/asynchronous invocation model and workflow for long running operations.

To be fair, in this big mix of already known stuff, there are some pretty powerful features like resilience to change in service contracts. WCF goes to great length to transparently allow client and server at different version levels to keep exchanging messages even if they have changed.

Moreover, unlike the usual stack of disparate half-baked products that are common in Java-land, WCF is a typical Microsoft product: it comes complete with a wealth of tools (like the pretty impressive visual call stack analyzer) and offers to developers a trustable and stable development framework. Conclusion for .NET developers: if you are not using WCF today, do not further delay starting to leverage it!


Behavior-Driven Database Design (BDDD) - Scott Ambler

Scott warned the audience: he is going to be blunt. And he was. Let me quote him: "any monkey can rename a column in a production database"! If this sounds like a scary perspective to you, do not think you are alone: surveys show that there is still a majority of corporates for which this is a challenge too. Why is it so? Mostly because of the mystical belief that what is in the database is perfect and trustable, hence does not require testing.

No testing? Wait a minute. Survey shows that a majority of companies have business critical functionalities in their databases (triggers, stored procedures...). So... no testing? Does this sound reasonable? When all serious software developers are now test infected, is it acceptable that the data management community drags ten years behind in term of quality-oriented practices? When the problem of bad data quality is estimated to cost 600B$ per year in the USA, can we keep going on like this? Of course not.

Is this lack of testing the only factor that makes database refactoring look so hard? Not at all. Scott stated another factor very clearly: mainly because of poor data access architecture leading to tight coupling with the database itself. Ouch! Blunt again. True again.

So how can BDDD help? In short: BDDD is an evolutionary and test-driven (not model driven) approach to refactoring databases. It encourages to consider databases as having nothing special about them, hence to dare applying all the panoply of agile software development to them, which are, to name a few: continuous integration, automated build, SCM, versionning, developer sandboxes, granular refactoring (to minimize the risk of collision) and regular deployment between environment (frequent from developer to integration, less frequent to QA, highly controlled to production).

Because it is so different than traditional approaches, it appears as a threat to most of the data professionals. This should not be the case as their skills and knowledge are needed for the success of this refactoring. Moreover, with many developers now using some sort of O/R mapping tools tempted to dumb down databases as "just storage", having the feedback of data professionals can help leveraging the different features of databases, which must be considered as first class citizens of a software architecture (as application servers are).

The following stop sign in Sacramento shows the current situation: data and quality orthogonal to each other, and a big stop sign in the middle.


This must not be like this for ever. With both the software development and data communities working together, a little understanding and good share of courage, it is possible to make things better!


Object-Oriented Programming and Generic Programming and What Else? (Bjarne Stroustrup)

When the father of C++ gives a keynote about OOP and GP, everybody sits quietly and listens because everybody knows that anything below a fully concentrated attention will be not enough to follow. I did my best to follow the master and did not regret it! Bjarne detailed and compared the strengths and weaknesses of OOP versus GP (using the classical shapes example). He then presented where C++ is heading to (for its 0x version), making the interesting statement that the needs of concurrent programming will more and more shape the destiny of languages.

Bjarne has been honored with the Dr. Dobbs Excellence in Programming Award later on that day, a well deserved recognition for the extent of his contribution to our field.


Web Caching (Jason Hunter)

After reminding us why web caching is critical, which I will not detail here because if you do not know why it is you would rather stop reading this blog and start searching the web, Jason started by detailing the basics of HTTP before delving into five different cache techniques from Yahoo's Mike Radwin. Here is a non exhaustive list of all what he mentioned:

• browser cache and conditional get for revalidation (leading to very cheap 304 replies from the server),
• proxy cache that happens at different levels (company, country...),
• beware of what can prevent caching (cookies, authentication), using mitigation techniques ...
  

... like:

• serving static content from a cookie-free TLD or using cache control directives,
• deciding that images never expire and use different versions of them (there is an Apache mod that helps for this),
• go even further and version even JavaScript and Flash files (forcing to adapt HTML files so that links target the right and consistent versions),
• leverage cache and expire directives correctly (for example instead of using 0 to mean "already expired", use a date far in the past, but not before the epoch),
• do not trust anyone to understand these directives or to understand their latest versions, so cover all the spectrum of parameters and plan for stubborn clients (for example 302 redirect to a highly cached site).

The Busy .NET Developer's Guide to Rules and Rules Engines (Ted Neward)

I always wonder how good or bad are the stuff I am doing with NxBRE, so I decided to attend this session and listen to Ted giving a review of business rules engines in the world of .NET.

We all understand that business rules are natural members of software applications and, I hope, we all realize that hardcoding them makes our life more difficult, especially for rules that change often and bear a lot of conditional branching. Hence the rise of business rules engine (BREs), which origins are rooted in the artificial intelligence efforts and expert systems of the 70s. Ted gave this interesting definition of BREs:

"Business rules engines are generalized expert systems in which the expertise is missing, to be entered via some form of programming language at a later date"

I like it because it relates BREs to expert systems while showing the part left to developers. It re-enforces the idea that there will be a learning curve, that integration will be needed, hence that a BRE will not be for any project nor any budget.

Other interesting aspects to consider when using such beasts include rules edition (and the mythical "business user" editor), testing and validation (about what you can read my take) and operational lifecyle (promoting to production and vice-versa).

I am glad that Ted mentioned NxBRE in this session (without throwing stones at it, woohoo), even if he mainly focused on Microsoft Workflow Engine and Drools aka JBoss Rules .NET (definitively more interesting for the audience, anyway, as WF is available to anyone with .NET 3.x while Drools have been around for a long while).

The fact he has not mentioned RuleML only once, even when making fun of MS WF indigestible XML syntax, puzzled me... maybe RuleML still tastes too much academia for the industry?


18th Annual Jolt Product Excellence Awards
Dr. Dobb’s Excellence in Programming Award

When someone asked Uncle Bob if he would attend the Jolt ceremony, I overheard him reply "naaahh". Still, I can remember him four years ago cracking jokes from the first row with Alexa. So is all the fun gone for real? It is with this thoughts in mind that I entered the theater, ready to be more surprised by the results than ever, as I unfortunately had to drop Jolt Judging for this round.

Well, this ceremony was simply excellent. The whole process has been streamlined, with Productivity Awards simply named, and good drum rolls-slides synchronization! Robert X. Cringely, who was hosting the event, first provided us with a great insight on the transient nature of the software we produce, though stated that this transiency removes nothing of its importance. He then proceeded to the formal trophy handing celebration with brilliance and pizzazz.

I leave it up to the DDJ site to list all the winners of this year. My highlights are the following:

• Atlassian (or should I say Cenqua?) received well-deserved awards for both Fisheye and Clover.
• Smart Bear has been recognized for Code Collaborator, whose company published book I have talked about before.
• O'Reilly Radar was high on the radar screen! If you do not read it yet, well, you know what you have to do...
• I was really hoping to see the Spring Framework get the Jolt but it went to Google's Guice. I am not convinced that Guice will ever jolt the industry as Spring does. But, hey, a vote is a vote!
  

Stuffing My Brain

I will be attending the last three days of SD West 2008 next week, stuffing my brain with all the good things this conference always delivers!

Should you want to discuss NxBRE, the Mule JCR Transport or any other stuff, please shoot me an email and we will arrange a meeting.

Canonical Implementations

A few days ago, a colleague made a tongue-in-cheek remark about the fact that I am directly using some Spring Framework helper classes (in this case: FileCopyUtils). First, I started to wonder if this was really bad: after all, are we not we supposed to avoid direct dependency to any framework?

Then it struck me as an evidence: the Spring Framework provides canonical implementations for almost anything.

Sure, it is all bound together thanks to the dependency injection kernel. But, whether it is via direct access to helper classes or via configuration, Spring implements state of the art and rock solid implementations of most of the tricky things you want to do.

Like copying streams while handling all the checked exceptions correctly. Or reading from a JMS destination with a configurable pool of consumers. Or creating and applying aspects. Or registering MBeans. Or... whatnot...

So why writing code when you can re-use one that has been so many times read, executed and improved over the past few years?

Why not tapping this huge source of canonical implementations?

Happy Bus Ride

I am happy to announce the second milestone release for the version 1.1.0 of the JCR transport for Mule.

There are some new cool stuff so check the updated user guide and examples to discover what. You can also check the road map to see what is cooking for the next milestones...

Make your bus content: connect it to JCR!

UPDATED 09-FEB-2008: Version 1.1.0 is finally out!

UPDATED 27-FEB-2008: Michael Marth of Day, the company who is leading the JCR specification, has interviewed me about this transport.

Pragmatic ESB Use Cases

After four years fiddling with ESBs, I thought it could be interesting to share what I have found to be pragmatic use cases for that tool. But, first, what do I mean by pragmatic?

By pragmatic, I mean free of any vendor kool-aid or SOA hype ; and driven by concrete needs instead of general fantasies of "business processology and ontological governance" (you get the picture). I also mean cases where an ESB did not feel overkill for the job and where its inherent drawbacks were acceptable compared to the features it brought.

So here are some use cases grouped by themes, with highlights of what particular virtues an ESB brings in them.


The external world outreach use case

Isolating corporate software from the pesky details of calling third party services over the internet is a very good use case for an ESB. Indeed, these services tend to have bizarre authentication schemes, IP range or access count limits and random down times. It is then worthwhile to hide these remote services behind an abstraction layer that allows developers to invoke them without having to learn about their particularities.

Consuming feeds is also another task for which it is more desirable to write configuration instead of code, something an ESB offers natively.

Reaching servers inside a DMZ with non-HTTP protocols is also another good usage for an ESB, with nodes installed in each firewalled subnet. I have talked about this before.

ESB virtues: Distributed, Content base routing, Configuration over code.


The instant legacy integration use case

Though I have been lucky enough to be spared the traditional legacy integration consulting gigs, I had to perform some stunts in the realm of instant legacy integration. This kind of software does not consider that standards carry any value, hence often opt for weird invocation protocols or communication mechanisms.

The message transformation and protocol adaptation features an ESB offer come very handy in this kind of scenario: a remote synchronous mambo-jumbo talking service can then be exposed as a SOAP or MQ one to the interested applications.

The versatility of an ESB, which allows it to come into play with various systems without having to modify them or needing them to know anything about the bus, compensates the black box middleware it can appear to be. It is in fact often desirable to keep the ugly details of talking the crazy talk of some systems in a black box to preserve the sanity of the software developers who need to use them.

ESB virtues: Message transformations, Protocol adaptation, Non invasiveness.


The fast talker use case

An interested case I was once faced with involved dealing with high performance communications alongside with a more standard database oriented web application. Even the hip J2EE application server I was using at that time was not designed to handle this kind of traffic: EJB, SOAP or CORBA were fine but not bursts of data packets over POTCPIP (Plain Old TCP/IP).

This was another good use case for an ESB, as it offered not only an excellent support for even such a low level protocol, but also the capacity to configure and manage pools of threads and components used to process the particular load of this side of the application. Acting as a "heat shield", the ESB was then analyzing, aggregating and pre-chewed data packets in messages ready to be sent to the rest of the J2EE application over standard EJB and JMS channels.

ESB virtues: Configurable behavior (threading/polling), Protocol support, Message aggregation.


Now to the real expert

So where is the "ESB in the middle of all remote service calls" use case? Well, though very satisfying for the mind, this kind of deployment very often ends up as a not so great idea. Jim Webber, who is a real expert, can explain you why.

JCR + ESB = You Decide!

After two milestone releases, I have finally released the latest version of my JCR Transport for Mule.

If you are looking for new ways to leverage JCR, then consider this transport that allows you to benefit from Mule ESB numerous transports for integrating content repositories into your infrastructure.

16 Years Ago

As promised before, here is the second part of my "power of two" flashback series of posts.

During the development of a modem hub sixteen years ago, something happened to me, something that touched my geeky soul and left me nostalgic for years, something that have apparently happened to many other people: I have been touched by OS/2.

I mean, touched by:
Sorry, I could not resist. There is still something mythical and magical about this operating system.

I had the chance to develop a system that was receiving chemists orders sent by modems and was analyzing and multiplexing them before sending them to an AS/400 machine. The application was developed in C, in a multi-process and multi-thread manner, with named pipes and semaphores enabled communications. The local persistence database was DB/2. And it was internationalized (French and Flemish).

At all stage of the development, I was amazed how OS/2's memory and threading models were making my life easier. Totally resilient to hard crashes (C has pointers, remember?), inviting to think asynchronously, it was a dream of a programming environment.

Then I switched jobs and started the arid journey in the Valley of the Shadow of Death that started in Windows 3.11 (for Workgroups!) and ended with Windows XP/2003 (the first really solid and well designed OS from Redmond, AFAIAC).

For a while I thought I should be mad at Microsoft for having turned my developer life into such a miserable experience. But in fact I became bitter at IBM and their inane marketing campaigns for OS/2. Their lack of capacity to make a superior OS dominate the market was flabbergasting. This sense of waste is probably what fuels the nostalgia of OS/2 lovers all around the world until now.

In fact, I have been mad at IBM until the redeemed themselves with Eclipse. But this is another story...

Loan Redemption

I had my first loan redemption on Kiva today: it is truly great to see that the small business I have lent money to has made well enough to pay it back. I can not wait to re-invest this money and help another developing country entrepreneur!

If you are not already involved in micro credit, consider it seriously. Small entrepreneurship is the fabric that makes a country develop in a stable and durable manner. The few bucks you lend (and get back) is the little help that another person needs to start changing her life, community and, let us see big, country!

Need Some Rest?

If you are looking for a no-nonsense REST framework built on all the good stuff Spring offers, look nowhere else and get a good Mattress.

Despite the pun, this framework is an interesting initiative to watch, as it is a pragmatic (hence partial?) implementation of JSR-311.

Stay tuned and look for the first release and, I am pretty sure knowing the framework author, the upcoming witty logo.

UPDATED 21-JAN-2008: The first release of the framework is now available in Maven's central repository. You want to give it a try!

BBC?

Really?

See for yourself: I have put my best BC shots on Panaramio.

Big Integers

This comes from Jean-Luc Ensch's excellent and witty blog.

Bernard Tapie, knowing this first hand, once said:

"If you owe one million to your banker, he holds you. If you owe him ten billions, you hold him."

So, how much do owe your banker, Larry?

One Step Further... Dynamism

So the buzz is all about using a mix of strongly and dynamically typed language in our applications. Is this really useful or is this just another hyped concept?

Well. Let us suppose that, while using our favorite ESB platform, we come with the need to invoke some remote EJBs. We would traditionally need to provide the client libraries to connect to our remote application server plus the required interfaces to cast dynamic proxies into something usable.

Now suppose we add JavaScript in the equation. In fact, if we use JDK 6, we do not need to add anything. We simply need to write a simple script that, thanks to the dynamic nature of the language, will not need any of the EJB interfaces to compile. Nor to execute. We will end up with fully functional EJB remote invocations without the hurdle of embarking extra dependencies.

The invocation chain that was dynamic down to the level of the local proxy can now go much further into your code without needing strong typing.

This might sound obvious to you: this means you are already addicted to mixing strongly and dynamically typed languages in your daily practice. Or this might sound to good to be true: then be my guest and give it a try. The only thing that is sure is: this is no hype.

Direct Kudos

I do believe that DirectX is one of the greatest achievements of Microsoft.

Not only this SDK provided, from the very beginning, a clean and efficient way to develop high performance graphic applications for Windows (anybody remembers WinG?), it is also an bright demonstration of Redmond's giant mastery in the art of backwards compatibility.

Every time I put my hand on a new version of Windows, I run PackAttack, a basic DirectDraw 2D action game I wrote several years ago. The last time I compiled it was in December 2000. If memory serves, it was compiled for DirectX 3. I am flabbergasted to see this game still working with DirectX 9 on Windows XP.

Anybody with Vista out there who would dare trying to run PackAttack and see if the miracle still happens, despite the fact Microsoft is supposed to have lost the API war?

8 Years Ago

Computer is running a very instructive column named "32 & 16 Years Ago". As a blogging exercise, I will do the same but, because I am not that old, with smaller powers of two (8 and 16).

To approach the things I was doing 8 years ago, I thought it would be interesting to see what happened to the domain names that was used in the startup I was involved at that time. For our new line of products, we opted for a Djinn-prefixed family of names, to express the magic of the stuff that was happening behind the scene.

At that time we had:

• Webdjinn, a pure DHTML RIA platform, with automatic code execution balancing between the browser and the server. It was using an XML based language (that we named ApiML) to describe the application, its components and their behavior. Knowing that this was developed in 1999 and 2000, you can imagine the technical difficulties of developing such a project on the browsers and servers of that time!
  
  
• Datadjinn, a SQL generator that was using a generic XML query syntax (that we named DQML), which was transformed into optimized native database queries. It was speaking a few database dialects and was used for the database connectivity of Webdjinn and of a pure HTML report generator we also built.

I leave to your imagination to figure out what was the fate of these bold endeavors... So what happened to their names?

Datadjinn.com seems to be now used to host a link farm. Boo.

Webdjinn.com had a better fate and landed in the hands of an Autralian "husband, web developer, human" who totally understood the value of the *Djinn pattern, as he created the cmsDjinn moniker for the "perfect Web Content Management System (CMS or WCMS)" he is creating.

Now, that is a bold endeavor!

LinkedIn OSS Context

If you are a user of NxBRE or the Mule JCR Transport and want to connect with me on LinkedIn, please use one of the "fake" positions I have created for that matter, so we can get connected in the right context.

Thank you!

New Year New Engine!

I am happy to announce the release of NxBRE 3.1.1.

This is mainly a service release for the Inference Engine, which got some bug fixed and simple features added.

See the release notes for more information. Enjoy!

Sub My Version

We all love Subversion: it is a solid, simple and powerful SCM that is as free as beer on a Super Bowl day. But when Subversion starts throwing a tantrum, the sense of free fall that occurs is really discomforting, to put it mildly.

I know how to find my way out of most of the problems (twiddling the .svn folder usually does the trick), but it is not always enough and not all issues can be solved locally (at least by reasonably educated developers). Indeed, the thing I hate above all is when I need to break the build in order to solve a Subversion issue: when the local files are in such a painful state that a commit followed by an update is needed, crap will happen in the CI server.

Take this simple case for example: extracting an interface of the same name as the source class, while renaming that class. I always do it in the wrong order:

1. Rename the class (say Foo to FooImpl),
2. Extract interface (Foo out of FooImpl),
3. Bang! Subversion wants to delete Foo from the repository (from step 1) and add a new version of it (from step 2).
   

Why do I have to care about SCM when performing such a trivial operation? Read Larry O'Brien suggestion about this.

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.