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.

Show off your cool NxBRE project!

Do you feel like running a few minutes remote demonstration of what you have accomplished with NxBRE and RuleML in your project?

Then you are up to the RuleML-2007 challenge!

Please contact me ASAP for more details.

Blinded By Trust

Sun has improved the new version of their Java forums so my previous rant about how disastrous it was must now be taken with a bit of salt. So it is attractive again to browse these forums for helping people dealing with their development issues.

Answering questions on these forums is a very instructive process because, the same way we learn from our own mistakes, there is a lot to learn from the fumbles of others.

Another interesting aspect is trying to figure out what went wrong in the code submitted by a developer: it is a very hard exercise because you have to fight against the natural tendency to trust the other party for stating their problem correctly.

Moreover this exercise reveals incredible blind spots in the way we perceive other peoples' code when we assume that they know what they are doing, which is the normal position you have with your colleagues, for example.

This today's exchange on the forum is symptomatic of this. Focusing on the programmers stated serialization issue, I totally disregarded the JDBC code he wrote, assuming it was correct. But it was really badly flawed!

The lesson from this is that, when helping a developer with an issue, fight against the natural desire to trust what he is reporting, while, of course, maintaining a respectful behavior. This will help alleviating biases and blind spots when reviewing the defective code.

Paint It White

The Register recently reported that, according to boffins, it is dark times for application development.

Just when I thought everything was getting better. Way much better.

• Writing code has never been so fun: we have great IDEs, loaded with refactoring features, enriched by a wealth of plugins that turn them into tailored productivity platform.
  
  
• Our tool boxes are now loaded with pragmatism-driven frameworks, multi-threaded building blocks and a panoply of libraries for everything and whatnot.
  
  
• Testing has never been so easy: we have a great variety of tools for testing applications at almost all levels and in fully automated ways.
  
  
• Testing has never been so rewarding: funny colored lights give us instant reward on our efforts while test coverage tools provide us with an exciting challenge.
  
  
• Source control management is now accessible to mere mortals: no need to be a command line guru or a sysadmin to store and manage code in repositories anymore.
  
  
• Collaborating on-line is now a reality thanks to tools designed for sharing idea, tracking issues and progress and authoring content over the Internet.
  
  
• Making reproducible and automated builds is a piece of cake: dependency management and library repositories combined with continuous integration platforms produce a sense of velocity and fluidity that makes development thrive.
  
  
• The tyranny of modelling and the myth of big design up front have been debunked and relegated to the museum of toxic ideas.
  
  
• Industry luminaries have risen and their voices have encouraged the inception of methodologies that promote communication, honesty, courage and elevated professional standards.
  
  
• Hype and buzz words are consistently derided and exposed to their true natures by the same thought leaders.

Of course, we face clunkiness, bugs and disappointment every day: does this make our times dark ones?

Quick Web Silver Runner

I have started to use Mozilla Webrunner on my Mac: used in conjunction with Quicksilver, this is a neat way to start web sites as standalone sand-boxed applications. This does not replace tab browsing, of course, but is very useful for the applications you usually dock on your second monitor (or third one, if you are a real guru), like your continuous integration server dashboard or your web mail home page.

To have Quicksilver bootstrap Webrunner applications, simply store your profiles in a directory that you register as a custom catalog. And voila, you can launch your web applications with a few key strokes.

This is another way to reduce the latency between thinking about what the computer should do for you and have it actually do it. When you think at the zillions of cycles the computer wastes waiting for you, any tool, gadget or utility that helps minimizing this loss is to be lauded!

Agile In The Burbs?

In a recent post, my friend Alex commented on the complex art of managing employees in remote locations, which came at a time when I was thinking about the high toll of co-located teams.

My reflexion started a few weeks ago when I was reading a reader's letter in IEEE Spectrum's Forum. Commenting on a very complete coverage Spectrum just run on big cities and their challenges, the reader said:

Why does modern society think that it’s entitled to expend all that energy, in whatever form, merely to transport people to their jobs? No one mentions the toll that a 4-hour-per-day commute takes on relationships. (...) What has always seemed more sensible to me is to live where you work. My commute is 10 minutes each way, on foot. And in my entire career as an engineer, the longest commute I’ve had was a half-hour drive.

(Read the full letter "Megacommutes to megacities")

My first reaction was: lucky man! Then my second thought was: why can not we all have such a life, a life where the distance to work does not put a toll on our lives and our environment?

So why do we rush to big cities? Because this is where the demand for IT workers is high: banks, public sector entities and private companies have a tendency to locate themselves downtown. Since they have a high need of software engineers, they act as a magnet for us geeks of all sorts.

But why do not we telecommute more? After all, this is a revolution that has been announced a long time ago and we now have the tools that would allow us to make it happen. Massively distributed open source communities have proven that this is a model that can work.

On the contrary, agile principles tell us that teams should be as co-located as possible, because of the millstone that distance puts on communication, whose efficiency is a major cause of success for software projects (and the lack thereof a major cause of failure). Industry luminaries and extensive discussions have made this point very clear.

Since housing madness only allows singles and dinkies to live downtown, the ones of us with a family are then forced to live in the burbs, far away from work and far away from the perfect commute the aforementioned reader says he experienced all his life.

Trying to accommodate the often conflicting requirements of agility, personal life and business is not a trivial task, but one that is certainly calling for a broader rethinking of the way our cities and workplaces are organized and located.

Code Literature

Open source projects documentation is a touchy subject.

I know it first hand from my own experience with NxBRE: writing and maintaining the 55+ pages PDF guide is not only a significant effort, but one of a very different nature than the effort of developing the product itself.

The wiki-based knowledge base is a good alternative: less formal, built from users questions and easy to maintain, it is definitively a viable approach for documenting small scale projects like mine.

This is also something learned on the field, as I have to work a lot with open source solutions. A pristine and up to date documentation is still an exception, at least for non-company backed projects. After hours of trial and error, fighting with an on-line documentation that was sometimes outdated (many examples would simply not work) and sometimes too advanced (showing features available in snapshot builds only), I came to consider recommending a paid-for solution, just for the sake of having someone to blame if the documentation was bad.

But that would have been too easy to surrender that way! Instead, I reverted to the more courageous tactics of the open source addict:

• explore the provided running examples,
• if not enough, browse the test cases,
• if still not enough, trace debug with the source code attached to the IDE.
  

Except for company backed projects, you have got to get ready to do this when opting for open source. In fact, the presence of running samples, a wealth of unit tests and human readable source code are important decision factors to consider when selecting an open source solution. After all, the ultimate truth is in the code, all the rest being literature.