Helping the Helpline Operator

From time to time, the infamous "we always do that" or "we have always done that way" excuse comes up: nothing new here. When hearing such a sentence over the phone, delivering a correct answer might be challenging though. No body language will help you to get through the wall of resistance to change that has just materialized in front of you (well, at the other side of the line).

What could possibly be a straight to the point reply, one that will not hurt the feelings of the other person (a sheer risk when questioning traditions), but will still make the need for change a clear necessity and trigger the reflection required to change one's mind? I propose the following punch lines:

• I did not know it could even work that way!
  
• You have been lucky so far!
• Call Guinness!
  

What would you like to add?

Going Hollow

If you go driving through France, you will notice that every hundred miles you come to cross the borders of the different historic regions, roughly matching the ancient duchies of the kingdom. Road signs clearly show these landmarks by displaying the name and the "logo" of the region.

While driving back to Lorraine, my home region, I noticed that the said logo is now a vague alteration of the original coat of arms. This alteration make no sense and does not carry any value or meaning, unlike the original blazon. See for yourself:

Original Coat of Arms (dated 1183)

Current Logo (dated 1999)

I am not preaching the altar of traditionalism here: all I am saying is that the original coat of arms had a meaning, while the new one has not. The three birds on the red band was a reminder of the legend saying that Godefroy de Bouillon, the initiator of the first crusade who took Jerusalem in 1099, killed three birds with one arrow during the siege of the holy city.

The current logo is simply an aesthetic redesign of the original blazon: the red band has disappeared, the birds point to the top right corner and they look like arrow headed deltaplanes.

Previous Logo (dated 1986)

In that sense, the previous logo was bearing more sense. Lorraine region is positioned on the hexagon that traditionally represents France. The colors represent the resources of the region (water, agriculture, steel industry...).

What is the lesson for us in the IT field? Let me propose the following: Let us not pursue novelty for the sake of itself but only if and when it brings new sense and value to our industry.

Agility Does Not Work!

Well, at least this is what some discussions are about currently on the blogosphere. Of course, this is as nonsensical as saying that concentration, stars or ants do not work. They all accomplish a purpose and do it very correctly when done at the right moment and the right place.

Most of the complaining people could have been frustrated by the fact that agility is not a tool-set, nor even a skill-set but truly a mind-set. This mind-set, whose substance is described by the Agile Manifesto, gets derived in many different practices. Therefore, one could imagine that by following these different practices, the project will become transmogrified into an agile gizmo. Unfortunately this does not work this way: as the law is spawned by the spirit of the law, agile practices come from agile minds. You need an agile mind first in order to put agility in practice.

With this mindset, it is possible to adapt agile principles to the sheer reality of your project or your clients, which is where the true challenge resides. Not all clients will accept the full monty: adaptation is needed. Here are some examples:

• Your client is addicted to BDUF: discreetly invest “analysis” time in running spike projects (call them “proof of concept”) to tackle as soon as possible all the technological risks and uncertainties (allowing to fail fast if need be),

• Your client loves methodologies: turn to Scott Ambler's AgileUP and see how agile the unified process has turned under Scott's expert hands,

• Your client does not want to be collocated: release often and expose your client as early and as openly as possible to the system you are building for him (he sure will react and provide an invaluable feedback),

• Your client has a really big project, so big that you think agility has touched its limits: then use a more traditional approach (serialization) to pilot agile driven smaller sub-projects (read Balancing Agility and Discipline for more about this).

There are many other situations when it will be difficult or impossible to openly sell an agile project to a client: pair programming (why paying two guys for the job of one?), time & features negotiation (these are the specs: what is the price and the deadline?)...

The important thing to remember is that more than a list of recipes, agility is a state of mind that will materialize differently in each and every project.

Coming to the Rough Cuts!

Jim Holmes and James Avery new book, Windows Developer Power Tools, has hit the O'Reilly Rough Cuts, where its chapters will be progressively released.

Chapter 18, covering the vast of subject of Frameworks, will include a section titled "Externalize Business Rules with NxBRE". You can imagine how excited I am: after almost three years of hard work and thanks to the continuous feedback of an excellent community of users and developers, NxBRE is reaching a new level of visibility: an O'Reilly book!

This chapter has not made it to the Rough Cuts already but it is on its way. I will update this post when it will be there.

In the meantime, you can also browse the TOC of the book to discover all the gems waiting to be discovered in it!

[Update 20-JUL-2006] The book has a jolly cool cover!
[Update 19-AUG-2006] The book is now in pre-order on Amazon.

Managing the Gap

Zepag has posted an interesting story in this Blogical shift (whatever that means) titled "From software to detergentware...", where he talks about the new wave of two-zeros (Web, SOA and whatnot) that is currently hitting our jolly technoworld.

The fact that marketing feels like creating such apparently-brain-dead new versions of old stuffs probably means that it is part of a natural motion in the world of selling stuff (be it concepts, software, soap, consultants or SOAP).

This reminded me of the excellent blog posts from Eric Sink about the necessity and strategies for closing the gap between the product and the customer (read part 1 and part 2). And I came to the conclusion that this gap does not really need to be closed but to be managed.

When the gap becomes too small, the customers are in a position of deep familiarity with the product, up to the point were they will stop considering it as something they have tought about and paid for, but a simple and commoditized part of their own life.

This is when you need to manage the gap: creating a new two-zero of something makes the customer in need (if not urge) of getting this new product. Instantly, it has become a new object of desire. In that sense, vendors really know what they do and how to influence the crowd we are.

Of course, nowadays, with the instant worldwide reactivity of the internet connected network of customers we all are, there is a serious risk of backfire. Still, this is a strategy that pays.

A few years ago, Microsoft understood it and decided to take the whole boardgame one step further: they decided to switch from a raw number version system to a vintage-like years version system. This was very clever because it allowed to make the gap easier to grasp for the human mind: who cares about running on Word 7 in 2006? Now if you say that this is Word 95, you immedialy feel in great need of upgrade!

Hence the gap between products and customers is not negative fact but a parameter that must be managed by marketing people.

Who Can Have The Keys?

With the current upturn in the IT industry, recruiting software engineers is a hot business... again! There are numerous posts throughout the Internet talking about companies' strategies and candidates' adventures (good and bad). I have found this post from Reg Braithwaite particularly interesting, both from the story he tells and the links he shares at the bottom of the entry.

Let me explain how we do software engineers recruitment at Agile Partner. Like everybody else, we look for smart people who can solve problems but, because we are a small IT consultancy, we do not do generic recruiting, like Amazon or Google might do. We look for particular profiles (junior, senior, architects) on particular technologies (.NET, Java), then we tune the “smart people who can solve problems” filter for this particular job offer.

As purveyor of software and services for enterprises and governmental agencies, we look for people able to develop enterprise software (I am so scared to use this expression because of one terrifying post from Alex Papadimoulis), which I reckon is the case for the vast majority of the companies similar to us. What does this imply in term of recruiting?

Most of our software engineers daily job will consist in wiring building blocks together in order to create back-office systems that will solve the business problems of our clients.

This job is not exactly formal Computer Science as almost no algorithm knowledge is required (with the exception of proper XSL-T writing, which involves a lot of recursion. I tend to consider a good XSL-T developer as talented developer). Hence high CS grades are not something we do care for very much.

But this job is about curiosity, instinct and quality.

This is why we look for people:

• who are eager to learn and able to do it fast in order to find their way out in open source project code bases or application server stack fest,

• who know the secret of good middleware development and can conceptualize the intimates of a multi-threaded application,

• who have high work ethics and work hard on themselves to stick to these standards.

If we feel that we share this set of core values and other common reference points (like gurus we worship or RSS feeds we read), we will then try to estimate the actual scope of technical knowledge of the candidate, considering that lacks are gaps to fill, not show-stoppers.

We will carefully avoid tricky questions because they show nothing, except a good memory or the reading of an interview preparation guide. We are much more interested by a candidate who knows where to find the information she needs instead of one who can write the code of an algorithm on a white board or rule out if an obscure piece of code can compile (if you can not decide what a piece of code does by reading it, it smells like it is in great need of refactoring).

Then we ensure that the actual coding practices of the candidate match with her assertions. In case the person is a committer on an open source project, this task is greatly simplified: the code review can be done with a simple browser, as most of the code repositories are accessible via HTTP. Else, we will ask the candidate to realize a simple program, with somewhat incomplete specifications (as in real life) and with no time constraints (the exercise being done at home).

All this can sound pretty lax but, believe me, very few go through this process until the end.

Which is ok because, at the end of the day, they will end up with the keys of the company. Something only possible with people you can trust.

Not A Mere Option Anymore

Just a few days after receiving my free and good looking Kubuntu CD, I am up and running on this splendid platform.

My Dell Precision M90 is fully supported, including Wifi. All my tools are up and running: Callisto, jEdit, Firefox, jBoss, OpenOffice... And it really flies (jBoss up and running in 11 seconds).

So what is left for the other operating system, still available as a dual boot? .NET development because I want to stay on a platform close to the one of NxBRE users. What else? Ah, gaming of course!

With the nice marketing of Vista currently going on, switching to Linux is not a mere option anymore, it is a choice anyone can make, thanks to Kubuntu.

Let us spread the word.

The Way Frameworks Go

While converting NxBRE to .NET 2.0, I came to realize that the SDK has been super sized.

Being a daytime Java geek and an open source developer on .NET, I can say I have a fairly good grasp of the two frameworks. When I started to work on .NET, I really appreciated the compactness and the clarity of its SDK. Informative namespace monikers and well-thought APIs were two features a guy coming from Java could appreciate.

Now the whole stuff is getting really fat, really Java-ish to speak frankly. But this is not the super sizing that I find disturbing.

The introduction of generics has triggered some really strange forks in the SDK. Take a look at the System.Collections namespace and you will notice that it has spawned a generic version of itself under System.Collections.Generic.

I would really appreciate if some .NET guru could explain why such a thing has happened? How come the existing collections have not been made generic? This has been done in Java, why not in .NET?

Now we end-up with two IDictionary interfaces, which can be a pain to handle in the same class. This can happen because you can not and do not want to use generics everywhere, especially if you look for performances with millions of entries collections.

To add to the confusion, the common implementation of IDictionary that was Hashtable has now a generic counterpart named Dictionary. Who said consistency was bad? I leave to the reader to appreciate the definition of Dictionary:

public class Dictionary<TKey,TValue> : IDictionary<TKey,TValue>, ICollection<KeyValuePair<TKey,TValue>>, IEnumerable<KeyValuePair<TKey,TValue>>, IDictionary, ICollection, IEnumerable, ISerializable, IDeserializationCallback

Truly delightful. I wonder how many pearls like this now hide in the SDK...

I thought .NET was a Java copycat but without its flaws. Not anymore. That is the way frameworks go.

PS for the Ruby guys: beware!

Gloomywood

June issue of IEEE Spectrum features a terrifying article titled "Death by DMCA" which relates how far the American entertainment companies (aka "Hollywood") are going to protect their copyrights. They basically intend to control each and every bit of information from production to consumption and for this they will go to all possible extents, like putting a lid on too innovative technologies.

It is somehow funny to see that the analog-to-digital converters are on their targets list. Understandably, any bridge between the horrific world of audio and video tapes and the clean and controlled world of binary files is not something Hollywood appreciates.

Where is this going? Can their grand plan for control succeed anyway?

Consider French pay-TV named Canal+. Whatever effort they put in building a new unbreakable decoder to work with a new un-decipherable signal, was systematically matched by crafty people who not only created but industrialized series of pirate decoders.

Another example is the pathetic DVD zone segregation: who is still constrained by this lame attempt to control the marketing of movies? Everybody wants to be able to play DVDs bought anywhere in the world, so everyone will go surfing the net and, voila, ten minutes later their player will be de-zoned!

If people want to crack it, they will do it. And they will make the crack available to the common man.

So here are my $.02 for Hollywood: instead of trying to prevent people from stealing your goods, produce goods that people actually want to pay for.

Let me illustrate this with two possible marketing proposals:

Proposal A

• Produce tasteless music made by disposable "artists", movie scenarios written by brain-dead pen-pushers and games that are endless clones of themselves,
• Sell all this at prices that no-one finds fair,
• Pretend you want to protect intellectual property while you clearly despise artistic creation.

Proposal B

• Leverage respect people have for their favorite artist and encourage their passion by providing a wide access to all sort of music, movies and games,
• Recognize that people are ready to pay for a nice box with cool artwork that wraps the product they buy,
• Strongly assert the rights of the artists before the rights of the vendors.

All in all, these locks and bars Hollywood wants to put in place will end up by adding new complications to the non-techies (like when you buy a CD and can not play it because the security protection makes your player cough).

Is there any hope? For music, Jamendo is surely exploring new grounds and opening new possibilities. Open source games are interesting but will they ever be able to compete with multi-million $ games? And as for the movies...

The Case for NxBRE v3

I am about to launch a complete refactoring of NxBRE, which will be done under version number 3. I have already prepared the Subversion repository for that matter: instead of branching, I have created different sub-folders in the trunk, this to reflect that v2 and v3 will not be branches but parallel projects.

At this point of your reading, I can hear you guys, NxBRE users in particular and software developers in general, saying: "Ohmigod, he is about to go the Netscape way and do one of the things you should never do"!

Please rest assured that I will not fall into this pitfall (but maybe in other ones!): this will not be a complete rewrite, not even an incomplete one. If you browse the feature requests for group "NxBRE3", you will see that this refactoring is mainly about:

• Refactoring the API, ie reorganizing files and folders, making namespaces more .NET flavored, substituting implementations with interfaces (this is mainly inspired by Joshua Bloch's reflections on APIs design),

• Switching to .NET 2.0 and SharpDevelop 2.0,

• Improving peripheral features like configuration and logging.

No new feature will be added to v3.0 so the same test suite will be used to validate that the new version has remained functionally equivalent.

The new version will break the ascending compatibility, which means that users of NxBRE will have to modify their code. This said, class names will not change so the impact should be limited to modify using clauses.

This refactoring will make NxBRE more palatable to new users and well-oriented for upcoming new features (like support for RuleML 1.0). It should have been done earlier, in fact, even before the very first release, right after converting JxBRE to .NET. This means that I was much less wiser three years ago!

Of course, no deadline has been set... After all, this is open source! Just kidding... I want things to be well done so version 3.0 will be cut when everybody will be happy with what they will see in the trunk!

Not Grandma's Java

Though it is well known that Java has never been the language of choice for great hackers, I am convinced that great hackers were active in the Java space, at least in the early days, when people (including me) were trying to figure out where Dancing Duke could possibly take us.

Nowadays, Java has the reputation to have become the new Visual Basic, ie the language that Grandma uses for her quick and dirty programming. What common sense refers to Grandma in that case is not the wise old timer but the programmer who has not found another way of paying his bills and who punches keys to kill time until pay day.

This reputation hurts people who try very hard to practice like good craftsman and are by default assimilated with the crowd. It is nowadays hard to present yourself as a Java Developer without adding extra words like skilled or seasoned or whatnot-that-sounds-a-little-shiny, unless you feel that sounding like a perfect schmuck is acceptable as a conversation starter.

But rejoice my fellow Java programmers! After two intense days spent at SpringOne 2006, let me tell you that there is hope, light and future in our field.

There is a Java that is productive and robust, scalable and maintainable, professional and fun! A Java that no JSR has turned into a maze full of traps and pitfalls or into an altar for preaching the gospel of a particular vendor. There is a Java that can peacefully withstand Microsoft .NET and Ruby On Rails (the latter being even more of a true competitor).

This Java is brought to us by the efforts, dedication and rigor of the Spring Framework development team.

And this Java is not Grandma's.

Introducing the O/WS Impedance Mismatch

According to French cartoonist Marcel Gotlib it takes at least four arms to correctly fold a road map, which makes it virtually impossible for any human beings. So if you know someone who can fold a road map, he certainly is a visitor from another planet.

Nowadays, there is another way of spotting such hidden visitors: if you know someone who can make sense of these crazy web service standards, then she might well be from another planet.

In fact, you do not need four arms for that, but four heads:

• one for dealing with your programming language,
• one for dealing with the programming language of the service you want to call or the client you want to be called from,
• one for dealing with the subtleties of SOAP style and encoding and other WSDL non-senses,
• and one for the cursing, because believe me, there will be a lot of profanity involved.
  

How did we get there? Why on Earth do we have to deal with a new impedance mismatch issue? The origin of the classical O/R one is obvious: databases and object oriented worlds followed two different tracks at different periods of time and then decided to meet (to collide would be a more appropriate term).

But the origin of this new Object-WebService Impedance Mismatch are more confused to me. The lessons from CORBA and DCOM were well known so creating an inter-operable, easy to use and extend standard for web services should have been possible.

The basics were good: HTTP is simple yet powerful and XML is strict yet offers plenty of room for extensibility. But we are now far away from those basics. Two basic examples:

• SOAP does not mean "Simple Object Access Protocol" anymore, since June 2003 it simply means soap, voila! Some said because the "Object Access" part was misleading, but the truth is that the "Simple" part was misleading. There is nothing simple anymore there. Moreover, soap is a good choice because it can make you slip and crash violently on the floor. It can also burn your eyes and make you cry. You have been warned.
  
  
• standard APIs are just plain lame. If you go for the static stubs, you get so tightly coupled to the service you invoke that it would be wiser to embed its code in your application, at least the performance would gain. If you go for the dynamic proxies, you will swallow your hat when you will call services that disguise their RPC aspirations in document literal draperies. What else can you try? Proprietary APIs that outfox the standard ones? Probably, if it is an option.
  

I will not even mention the tragic WS-* family, where some members bear the same moniker to be sure that the bravest who were still trying hard to find their way out, will stumble and fall to the ground in a terrible noise of crushed iron.

Is there any hope?

If you control both sides of the equation, do yourself a favor and take some REST: any pragmatic XML over HTTP approach will make your live easier and might even extend it of a few years.

If you control only one side and have to deal with the O/WS mismatch, do not distribute the misery in all of your consumers or producers: federate the knowledge of the WS-Arcanes in a pervasive middleware component, have your guys talk only to it and let it handle the chewing and spitting of standard web service messages to the outside (and cruel) world.

Si Senior!

At one point of time in my career, I started to consider myself as being "senior" in my profession. I thought I knew it all and nothing was left to discover, very much like the way scientists at the end of the 19th century were thinking.

Then I discovered OO and Java. Ouch! Landing was tough, a brand new world was opening up and it was vast. But it was also fun and rewarding to discover so I started to climb the learning curve.

At one point of time in this learning curve, I started to think I knew enough and, again, I started to consider myself as a "senior".

Then I met genuine seniors and gurus. Ouch! Landing was tough again! And its taste of déjà vu was, if not frustrating, at least vexing because I hate to redo the same mistake twice, like anyone of us...

What lesson could I possibly learn from these mistakes?

Well, nowadays, I really dare introducing myself as "senior" but simply because I have definitively stopped to consider myself as being such.

I am just walking the path of learning and discovery, I know it has no end and, therefore, is much bigger than me. Isn't this seniority?

Flows in Action

Knowing that it is the financial flow that made the middle-age third estate society collapse, will the information flow that is surging in sub-Saharan Africa make the bars of political oppression and the walls of cultural isolation collapse?

This is the question that stroke me while reading an insightful article from IEEE Spectrum. Comment here if you think similarly. Or not!

Dematerialize Me

Every computer crash or re-install is the occasion for asking the right questions: what was wrong in my previous set-up? What can I improve?

Switching the OS for another one that asks much less care (defragmentation anyone?) is certainly an appropriate action: I will come back to it in a later post.

Reducing the hard disk drive footprint is surely another one. This means less to re-install and less to lose between two backups. This means dematerializing applications and use their web counterparts in lieu. So far, here I am:

• E-mail client: GMail instead of Thunderbird,
• RSS feed reader: BlogLines instead of Omea Reader,
• Chat client: Meebo instead of Trillian.
  

Of course, this poses the question of confidentiality as my data is in other people's hands. I try not to store anything confidential there and I will probably resume using PGP. But the advantages, to my sense, over-exceed this inconvenient.

Not only my web related tools are available anywhere there is internet connectivity, but session state is persisted: for example, all the RSS feeds that I have marked as read will remain so (which is not the case when you have multiple clients on multiple machines).

The next step is to dematerialize me: I am still thinking on how I could be replaced with my web counterpart... In the meantime, if you know other smart tools like the ones I have listed before, please comment on this post!

Duties and Rights (Quote of the day)

"A people that values its privileges above its principles soon loses both."

General Dwight D. Eisenhower

The Mystique of Software Craftsmanship, Part 5

[Previous Part]

Fifth Discipline : Control Temporal Localization

It has been said enough that psyche is a the key factor of success in human endeavors. One aspect that is worth paying attention to is the way we control how our mental activities are distributed in a time-based manner, or said differently, how we focus our streams of reflection on the past, the present and the future.

In that matter, anything that would not be following a standard normal distribution (also known as bell curve), where the peak of the curve would be the present time, the left side the past and the right side the future, would be damaging for our work and ourselves. This concept sounds pretty obvious and natural, but for intellectual workers, the risk is high to have the shape deviate in one direction or the other and it must be recognized in order to be controlled.

To understand why temporal localization is important, let us examine some potential side effects of deviating from the bell curve.

Focus	D	Risk and Mitigation
Past	+	This tendency could be the immediate consequence of work habits too much oriented to the past (see part 4). Regrets of a glorious past or a previous technical platform can make a developer unconsciously sabotage his work. It is important to recognize the constantly changing nature of our business (and the fact that a glorious past is a self-made myth) to avoid spending too much focus on the past.
	-	Not having enough focus on the past leaves the developer at risk of ignoring valuable experience. Systematic project postmortem can help turning past experience into useful memories instead of denied and buried ones. Easily built knowledge bases (for example using a Wiki) can also be of great help.
Present	+	Focusing too much on present can expose developers to the feeling of being overwhelmed by the task they are working on. It is very difficult to reach the right level of detachment necessary to alleviate the emotional impact of technical difficulties that a programmer meet almost every minute. Developing a humorous attitude can be a positive way of shielding oneself!
	-	The consequences of not focusing enough on the present time are well known: lack of attention to the details, unsatisfactory feeling of not seizing the instant... If this escapism is rooted in boredom, talk your manager: you will be surprised by how converging your interests are!
Future	+	It is very easy to focus too much on the future because software development entails huge prospective mental constructions. The risk is a high mental load that ends up in extreme fatigue and a difficulty to “go off line” (the fourth state in the cycle described part 3). Writing down informal do lists, models or plans as they come to mind can help reducing the amount of prospective concepts manipulated and explored simultaneously by the brain, thus reducing the propensity to excessively look forward.
	-	Not paying enough attention to the future generally translates into ill-designed systems, unable to absorb changes without breaking. Of course, over-engineering is a real risk that must not be ignored, but learning simple non-intrusive techniques (like programming to interfaces) can help to efficiently prepare the future.

Because we are where our mind is, temporal localization is a factor that software developers should be aware of in order to optimize both their work capacity and mental load.

The Mystique of Software Craftsmanship, Part 4

[Previous Part]

Forth Discipline : Question Traditions

No workplace is free of traditions: in fact, establishing traditions is inherent to our human nature hence computer-related workplaces, whether they deal with software development or IT operations, are also bound to some forms of traditionalism.

We should become very aware of these traditions and by no means be afraid to question them. Very often a tradition acts as disabling force instead of simply being a neutral vector of knowledge. The same way they can turn a living faith into a dead religion, traditions can weight on decision making process and orient them into cumbersome or counterproductive acts.

There are many patterns under which traditions could take place in your working environment: it is crucial to get used to expose them. Here are three examples, that you can use as starting points for your inquiry:

• the “self-perpetuating pain”, where the cause of a problem or the limitation of a system is long time gone, but the workarounds or constrictions that were put in place remain - unquestioned,
  
  
• the infamous “we have always done it that way”, where the reason of a particular choice has been forgotten and, or more accurately, hence becomes impossible to change,
  
  
• the “myth of the mountain”, where a practice, a system or a person is considered impossible to change or improve simply because communication as given way to prejudice.

Of course, we all know that questioning practices that have reached the status of habits is a very difficult endeavor, if not a risky one. Questioning a tradition goes far beyond the act of merely discussing a decision or a piece of knowledge: it sometimes touches the very fundamentals of an organization and will instinctively be considered as being destructive.

In the course of your adventure through traditional aspects of your organization, you will quickly find out that the most virulent supporters of a particular habit will be the ones who suffer the most of it: for them, enforcing such a painful tradition is close to the psychological trait known as capture-bonding.

Knowing the powerful psychological forces at stake in such a process, a wise craftsman will become a cunning tactician: he will avoid a direct confrontation and favor a more subtle approach, like systematically undermining practices that are peripheral to the targeted tradition or evangelizing intermediaries who can approach its fervent keepers.

The subtle glitch in JCR 1.0

After investigating JCR 1.0 (spawn of JSR-170) implementations (Alfresco and JackRabbit, both excellent realizations) for a few days, I feel a strange combination of excitation and disappointment. I am excited by the idea of having a standardized API to hit content repositories, a playground where proprietary interfaces have been ruling for a long time. The reason of my disappointment will take a little longer to explain.

One of the key selling point of JCR 1.0 is that it enables you to swap your repository from vendor A to vendor B, provided that they both support the same level of feature (so far JSR-170 defines 2 levels). This is true and it works but to some extent; and it is in this restriction that lies the glitch that annoyed me so much.

JCR repositories rarely come as naked JSR-170 implementations: they usually come complete with other ways of reaching their content (WebDav, CIFS, portals...) and - hopefully - useful administration tools.

Because JCR 1.0 is an extremely granular API, where familiar concepts like folders and files are not handled as such but abstracted as general purpose nodes, it allows each implementation to decide how to represent the classical hierarchy of folders everybody is used to and expects to find in a repository. And this is the crux of the problem: if you stick to the pure JCR API, you will be able to run your code on any compatible repository but the connected tools and other data retrieval channels will not recognize your data structure and will ignore it.

For example, a block of code will create a data structure that JackRabbit WebDav access represents as a folder containing a file, while the same block of code will store data that Alfresco will not be able to display in any of its data or web access tools. I have even come to inconsistencies (not the proper term because it is logical that it does not work) within the same tool: code that creates this folder and file that JackRabbit browser interface can render will be exposed as meaningless folder and files in its WebDav access.

The conclusion of this story is that yes, you will be able to swap one repository for another, but the trade-off is that you will potentially loose some or all of the extra features of the repositories. To me, this sounds like a major loss.

All this reminds me of JDO: so generic and versatile that it has never been good enough in one particular persistence strategy compared to Hibernate database-only persistence that has reached excellence and universality.

Let u’s hope that JCR 2.0, the upcoming spawn of JSR-283, will address this concern. But will it? Is it the interest of the expert group members to be potentially swapped-out when all of them look for lock-in strategies? Only time will tell.

Back from Oblivion

I have just uploaded a few screenshots of Celesstin 3, a great research project I have been lucky to work on back in 1990. The project, sponsored by IBM and Dassault, consisted in developing an automatic converter from mechanical drawings to the CAD system named Catia.

Entirely written in C, it was running on 5080 graphical terminals, backed by a 9370 VM/SP server (we also run it once on a 3090, where it only took a few minutes to compile instead of the usual 20 minutes). Part of the process was run on 6150 boxes where the inference engine named ATOME was used to make deduction about mechanical elements.

My job was to wire the different parts together behind a graphical interface, which was a brand new endeavor on a 5080 terminal, at that time. One guy of the team was a very talented icon designer and, if you look at the pictures, you will see we did a great job!

Strangely enough I put the menu bar on the right and the main button (equivalent to the lovely Windows Start button) in the bottom right corner. This does look counterintuitive nowadays, does not it?

This was mainly 2D display (you can notice some 3D components in the final interpreted stage of the recognition process) , so to grok the graPHIGS programming interface, I have invested my free time (i.e. after midnight) into developing a 3D roleplaying game a la Dungeon Master.

Unfortunately, I can not put the finger on the screenshots anymore... That is the fate of most of our software realization: hours of hard work that are bound to oblivion.

Broken Workflows

A nice and easy way to lose customers is to carefully implement broken workflows in your business. This is not an easy task and you might need professional assistance for succeeding in such a bold endeavor.

Or you can take real world examples as models.

Like Free, the French ISP, which is so hard to leave. Their broken workflow strategy is based on the MPOC Paradigm. The MPOC, or Multiple Point Of Contact, is the inefficient counterpart of the SPOC, or Single Point Of Contact. As such, the MPOC can increase the difficulty of reconciliation related messages, increasing the chance of breaking any existing workflow. Free (not as in beer) has established two points of contacts for subscription termination: one that deals with the physical aspects (like modem return) and one that deals with contracts and payment aspects. Needless to say that this is a big success: it is guaranteed to take a few months and many certified letters to terminate a subscription. Great job!

Or like Dell France, where a great deal of mastery has been deployed to ensure that you will not spend your money there. They follow the Black Hole Paradigm, where messages are either held captive, buried or lost. This is a very complex strategy whose main purpose is to prevent any form of end-user feedback and disable useless mechanisms like escalation. Dell masters this delicate art and uses it brilliantly: your internet order will be held captive for weeks before you get any feedback (while 72 hours maximum was announced), the web interface to query the order status will consistently return nothing and the commercial services that you can reach on the phone will not have internal access to any information about your order. Amazing implementation!

These are only two random examples but I am sure they will be very useful for anyone interested in broken workflows.

Have you experimented other broken workflows strategies or paradigms? Please do share them here!

Welcome to the future...

eop.

The Difficult Art of Good Example

I am almost done reading Core JavaServer Faces.

Wow. I see you coming, so I must immediately make the following disclaimer: I am not embracing the wild idea of reconverting to presentation-layer development. What I have seen in this book scared the heck out of me and I definitively prefer to stick to more trivial things like high-performance massively-scalable middleware development*.

This said, the book is pretty good, stuffed with detailed examples and very valuable insights and comments on the JSF strengths and weaknesses.

Did I mention examples? Yep! But I forgot to mention this one example that freaked me out, because of the potential bad habits it could create, while giving the impression it is pretty legitimate.

To demonstrate database connectivity, the authors use the infamous and pervasive login example. Type in your name and password, push login, then let's connect to the DB and redirect you to either the jolly welcome page or the less welcoming sorry page.

Now this book will be read by people who have no clue about the capacities of a J2EE container and they will take for granted that security must be implemented in the application. And people like me will have to come after that, clean the mess and watch the grim on their (JS) faces when I will have to explain that not everything in a book must be taken for granted.

Sure the authors detail the J2EE security mechanism afterwards, as a better way of doing things. But come on, it is too late, our reconverted ASP-or-whatever-other-horrific-MVC1 programmers will start implementing their own security algorithm in their JSF applications.

And they will fail.

There are plenty of other things an application can use a database for... Why this login example? Why not the famous stock value lookup example?

Beware bad examples: disastrous consequences might follow!

______
* shameless boasting

Your Eclipse IDE

Many Eclipse projects and sub-projects are now reaching an undeniable level of maturity. EMF is an incredibly useful modeling framework and TPTP promises to become a reference point in term of performance and test tools.

In this emerging wave of high quality stuff, WTP is finally out of the gloom and starts to deliver its promises. This lead me to wonder what will happen to Genuitec's MyEclipseIDE as the competition pressure of the freely available WTP will keep on growing.

Lost in the crowd of IBM committers, you can spot one contributor from Genuitec. How this contribution, which will obviously be minor, will play for or against MyEclipseIDE?

Will Genuitec focus on a few specific plug-ins that they will still be able to sell and support? Most probably, as there is still room available for specific gizmos like Struts page flow editors or Hibernate generators.

Will Genuitec react to this competition to tackle some deficiencies of their own plug-in suite, like the stupendous tendency to fork existing plug-in codebases (making their independant update impossible), the painfull habit to create dependencies to internal APIs (making each Eclipse upgrade a nightmare for their own developers) or the limitation of certain features to Windows-only environments?

Only time will tell. But one thing is sure: bright is the future of your Eclipse IDE!

The 13 Millions Euros Phone Call

Are mobile phone calls interrupting meetings a bad thing?

Your answer would surely be no if you were getting the call in a meeting where you were dying of boredom (which unfortunately tends to happen often as efficient meeting is still a rare discipline). This would be like being saved by the bell.

But if this phone call would make someone slip out of an important strategic meeting to talk to his daughter, which would end-up in dismissing the meeting that could have allowed to spend 5 millions instead of 18 ; would that be bad?

Oh well, I guess no if it is public money.

Back to Basics

Knowing that "play and lubricant" is the secret of mechanics, would "cache and thread-awareness" be the secret of middleware development?

The Form Is Out There

After investigating several possibilities (raw DHTML, Backbase...), I have finally opted for Chiba as the presentation engine for jinFORM, my attempt to port MS InfoPath 2003 forms on the web.

Chiba is a cool XForms 1.0 SE implementation that runs on J2EE servers. I investigated it when I started jinFORM last year, but at this time, all actions where bound HTML form post actions, leading to a less than comfortable UI.

The new version, currently in release candidate, is fully AJAX driven, which not only makes it buzz-word compliant, but also dramatically improves the user experience.

Despite several little bugs, the InfoPath forms transformed into XForms and rendered by Chiba are more than usable. So far, the most annoying thing in Chiba is the direct dependency to Log4j: using Commons-Logging would have made it more friendly with the different deployment situations.

I will wave a flag when the first alpha release of jinFORM will be out there.

The Mystique of Software Craftsmanship, Part 3

[Previous Part]

Third Discipline : Let it flow

The lessons learned in other sectors of the industry can also be beneficial when applied to the IT field. The example that immediately comes to mind is the the invaluable contribution from Tom and Mary Poppendieck in applying lean principles to software development.

It is evident that there is still a lot to learn from other organizations: take for example the latest discoveries of the Mind/Body Institute that Herbert Benson has recently presented in Harvard Business Review (November 2005). Benson describes the mechanisms involved into reaching what he calls a “break-out”, a mental state that we call “flow” in the software development industry. Knowing that reaching this state is intimately linked to producing high quality software and that “it takes about 20 minutes to reach the internal state of flow, and only a minute to lose it” (as Alistair Cockburn stated it), we can consider these findings as essential for our business.

Benson describes a four-state cycle: stress, walk-away, flow and back to normal: mastering this cycle could allow anyone of us to reach our optimal productive state at will. The surprising aspect of this cycle is the importance that stress plays in reaching the break-out: voluntarily creating this stress is a critical aspect of being able to trigger the state of flow. Everyone will have a different way to raise its stress level: the important thing is to discover what is our own.

For example, one will naturally procrastinate until the deadline gets short, then, after a short pause, the break-out happens and she will deliver on schedule a better piece of code than if she has spent twice the time on it.

Being aware and able to control this internal mechanism is the kind of proper exercise that we should consider, not only to be more efficient but to ultimately harvest self-satisfaction in what we do.

YAGNI In The Sky (Quote of the day)

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Antoine de Saint-Exupery

The Mystique of Software Craftsmanship, Part 2

[Previous part]

Second Discipline : Be a Hero

We know that learning is mainly based on imitation and imitation can only happen when we are exposed to valuable models. These models constitute the good food our brains need. Either by reading books or attending conferences, we feed us with the result of years, if not decade, of experience and reflection in a few hours. These models, when incarnated in human beings, become the league of heroes we should desire to join.

What, in the case of software craftsmanship, could it mean to be a hero. How in our field of activity, could we exercise valiance, courage and wit? Here are some suggestions:

• let us be a hero for our clients: they are the prime reason we wake up in the morning and the true motivation of our professional endeavors, so we must embrace their cause and deliver the best value possible, even on the things we build but they do not see,
  
  
• let us be valiant for always walking the extra mile: when the little bell that warns us of a potentially crappy line of code start ringing in our head, we should not turn our back on it but refactor as soon as possible, and, if we are too tired to solve the issue right away, at the very least we should comment the risks or doubts so nothing remains in the shadows,
  
  
• let us do supernatural things like: stealing the overhead projector of your favorite salesperson, plugging it into your workstation to explore interactive programming or design sessions with your peers ; hacking an AmbientDevice to display your test coverage status or the time left before the next release ; training a RoboSapien to pick-up the phone when you do not want to be disturbed by your favorite salesperson (looking for his OHP)...

While pursuing this quest for software craftsmanship heroism, let us not aim the wrong goals. Though they might be reached in the journey, this is not glory and fame that we are seeking: we are looking for doing the right thing at the right time, and that will be heroic enough.

Excellent Resolution (Quote of the day)

"You are what you do habitually. Therefore excellence must become a habit."

John Bevere

The Mystique of Software Craftsmanship, Part 1

Usually, the first years in the professional field of information technology are all about geeky concerns and simple delights like learning languages and exploring frameworks. Then come the big questions about what and why and how are we doing what we are doing. Technological questions give way to human interrogations.

It not a benign fact that information technologists are dealing now with such questions: the industry have matured to such a point that everyone knows that any new technology, as complex as it could appear, can be tamed and that the true challenge lies in the intricacies of human behavior.

Being aware of the challenge that sits in the very heart of each of us is the only way to be able to work on it. Common concepts like rigor and willingness can surely help us improve ; I would like to propose to everyone of us some disciplines whose practice should contribute to improve our craftsmanship.


First Discipline : Taming the Unagile Old Man

Why do we sometimes catch ourselves wondering if we really should code to interfaces instead of concrete classes? Why are we from time to time erring in thinking that we can skip writing this unit test? Why are we tempted to forget about refactoring code that works but we know would be hard to maintain? Why is our first reaction to a change request a negative one?

All these questions lead us to wonder if there is there such a thing as an unagile old man? Similarly to the old man of the Christian faith, who represents the natural tendencies of the non-spiritual human being, the unagile old man would manifest from time to time, when tiredness level or deadline pressure is getting too high, and he would try to carry us in the infamous water of compromising with quality.

What, as software craftsmans, can we do to tame the old man? We have to learn his tactics and apply counter measures:

• if he plays on your fatigue, get some rest or go out for a walk and come back to the problem,
  
  
• if he tries to scare you, increase the test coverage of your application and take revenge by refactoring aggressively,
  
  
• if he invites you to cut corners, repeat Robert Martin's mantra: “the only way to go fast is to go well” until he gets deaf.

Alfresco is fresh but cool!

Today, I had the opportunity to attend to a presentation given by the top guys of Alfresco and, yes, it is pretty cool. It is still a little fresco, dub it too early for prime time for complex ECM needs, but in a six months time, it is bound to become a great piece of software. These guys know what they are doing, most probably because they have done it for more than a decade, but also because they sure are smart.

The same way JBoss has commoditized J2EE application servers, Alfresco will do the same to ECM business and, in a couple of years, Documentum will have to try to reinvent itself or simply rely on their maintenance fees to survive.

But Alfresco will not simply focus on ECM and will soon attack the WCM market, which makes sense. Here they will probably hit a little more competition from affordable and/or open source solutions (like Jahia). But hybrid solutions will emerge, with Alfresco providing content management (through web services or JSR-170 connectivity) and other systems providing the web interface.

All this is pretty well known and expected but there is this one feature they have demonstrated today that, I think, has the potential to disrupt another market, the market of ad-hoc document related applications.

This feature is called "space templates" and allows to instantiate some kind of a workspace with storage areas, discussions forums, rules and workflow definitions inherited from a template. Now, if you bear in mind that they will add a solid workflow engine to the system (most probably jBPM), they would only need to add a full fledged rule engine to support the creation of powerful templates that would solve what expensive ad-hoc applications do.

Here I am thinking of fields like legal and contract management. Take the case of intellectual property management: you could define a space template for, say, Patents, Designs or Trademarks, have all the relevant storage created (related correspondence, official forms, pictures), have the workflow related information in meta-data (country, classes, application & renewal dates) and you would get a user-oriented solution, where her daily work (which is mainly document related work) would drive the whole process.

These guys are clearly not only creating business for themselves but they are opening brand new fields. Who will dare exploring them?

Educated Plumbers

Joel Spolsky just released one of his excellent piece of wisdom, this one explaining how the great bargain of IT courses makes his life difficult when trying to select smart recruits. He is of course fully right but I feel like adding a few words.

First, the sabotage of education is not limited to IT: my wife being a math teacher, I can tell you that the level of what she is teaching is constantly on the down curve. It is like the attention span of young generations has narrowed so much that it is not an option anymore to dare exposing them to problems that need several minutes of reflection to be solved.

Second, it is certainly not wise to focus on a particular language when teaching the fundamentals of software development. In fact, when I recruit someone, I do not particularly care about what language she studied at school, the courses is more important: evaluating if the candidate has learnt to learn is the key point. Then I focus on language and frameworks only for particular projects.

Then, yes Joel, Java can be learnt in two days (like C#): what takes a lot of time is mastering the whole SDK, dealing correctly with multi-threaded environment and thinking object oriented. This takes years to learn, even for a master of C.

Finally, nowadays 90% of the programmers will spend their day on plumbing jobs: connecting beans to cryptic frameworks and deploying them on fussy application servers. They will not deal with writing core algorithms, so the average mind will show some convincing signs of success, until confronted to some serious problem. Then the difference between an educated plumber and a seasoned craftsman will show.

Rediscovering Verne

I am reading Jules Verne again: last time I was too young and got overwhelmed with his long descriptions and the usage of incredibly exotic units (I was raised as a metric-system mind).

It is a true pleasure to rediscover this author, both in his famous books and in the less known ones. I do not consider Jules Verne as a visionary: he has not foreseen anything like the heavier-than-air vehicles or the usage of oil as a source of energy. He is not such a scientist as well: you can see that he hardly explains what system allows the space travelers to survive the enormous acceleration of the bullet that carries them to the Moon.

But he is very well informed on the state of science and technologies of his time, and extremely good at imagining what could be the most advanced versions of what he was seeing around him. For me, he is more an extrapolative mind than a prophetic one!

But there are of course some interesting coincidences, like the fact that he estimated a lift-off to the Moon would happen either in Texas or Florida, when actually it was from Florida controlled from Texas!

Globally, it is a rejuvenating experience to read his books: his faith in science and engineering, his depiction of righteous men, his fascination for nature are communicative: it makes the grey and gloomy days of winter a little brighter and hopeful.

Moreover his true admiration for the United States, which he considers the land of bold endeavors and true democracy, is also refreshing, because full of genuine tenderness. Can Jules Verne help rediscovering America?

The other David does not like you too

I really have a problem with tailgaters, like David Lynch. Not only the jerks could not avoid crashing into my car if I have to do an emergency braking but they won't make me drive any bit faster because the cruise control does not care about how close is the car behind.

I think that tailgaters lack consistency: if they do not want to respect the speed limit (which I usually exceed of 5%) then they should overtake, whether we are in town or the line is plain, because why would they bother of one regulation (passing prohibited) and not another one (speed limit).

Finally, unless tailgaters sign an agreement where they would pay the tickets I would get if I drive faster to please them... they can stick to my fender!

Intelligent Resign

Like many people in France, I have heard about the controversy that currently takes place in the US about creation and what is called "Intelligent Design".

Of course, in the post-Christian society that is France, this kind of debate looks curious at best and more generally incredibly obsolete for the vast majority of people who think that Christian faith is a middle-aged superstition and a crutch for weak persons.

This "intelligent design" debate will not help ridding these prejudices and misconceptions: there is nothing intelligent in wasting energy in talking about subjects that are all but extremely peripheral to the core of the message that Christians should broadcast. There is nothing new in this kind of intellectual diversions: re-read what Paul has written to Titus about this, almost two millenniums ago.

Confronting science and faith is a sterile debate: they are both in different non-competing fields (the "how" and the "why") and both can benefit from each other. Can not faith be re-enforced by the beauty and the majesty of the discoveries made in the heart of the matter or at the borders of the known universe? Can not science benefit from a little consciousness when it comes to potentially dangerous discoveries?

And on the subject of what is taught to kids at school, I really think that there are more serious threats that weight on our children than hearing about the theory of evolution. Living in a fallen world is all about filtering, anyway!

Wish Kids

Does anyone remember the Whiz Kids? This TV show has been a flop: one season and off it went... But for me it was a true revelation.

I think this show hit France a few years after its US release. At this time I was already hooked on computers, or at least what we used to call "computers" at this time (I am of course talking about the electronic spawn of Sir Sinclair).

Everything seemed possible in the Whiz Kids: pervasive computers were the key of all the plots and the sun was constantly shining above these smart young Californians.

I reckon that I must blame this show for having set my mind on two major wishes: become an expert in taming computers and relocate to California... So far, it is a 50% success (the geographical part of the challenge remains unfulfilled) ; should the show have taken place in Anchorage, I sure might not be eager to reach the 100% target!

This Is Called Revulsion

I feel pretty ashamed about the fact that, until I recently learnt that Lavoisier died on the guillotine during the French terror, I was pretty neutral (if not favorable) with the concept of revolution, more precisely, violent ones.

I needed to realize the atrocity of the death of such a beautiful mind, who contributed so much to the development of science, to reconsider my position. Lavoisier was hastily judged on the fact that he used to be a "general farmer", i.e. a tax collector for the king. His death was merely symbolic.

For the same symbolic reason, millions of people died in Cambodia, Cuba, China and many other places where the word "revolution" has been invoked as a reason for violently removing the people who were somehow symbols of the previous regime.

Were all these deaths and all this pain worth it? Read my lips: not a drop of blood was worth it. History has shown, and shows time and again, that a revolution always ends up by replacing one form of human servitude with another one.

What happened recently in Ukraine (the Orange revolution) brilliantly confirms the message of Gandhi: a peaceful crowd can accomplish great things, including revolutions that would take the life of no-one, hence that would not nurture fear, anger and the need for revenge.

From Simple To Dumb?

Now what? There is an on-going effort to simplify Spring's configuration lead by James Strachan himself under the jolly name of XBean and this terrifies me to death.

First: when Mr. Strachan talks of simplicity people using Struts and other Strachian offspring can reasonably start to wet their pants.

Second: Spring is already simple: who on Earth needs to make simplicity simpler, especially when the risk is to make things simplistic if not dumb!

True XBean offers a richer XML syntax where beans are represented by actual elements but this remains XML, no harder, no simpler. Would a new DOS syntax have made it simpler? The true simplicity came from a layer above.

Hence, what could make Spring simpler would be a powerful Eclipse plug-in that would allow me to not only wire my beans but also to take advantage of other features of the framework (JMX exposition, AOP, MVC and, why not, Webflow): this would hide XML completely and really make Spring simpler.

___________
Post-Scriptum: People knowing NxBRE could argue that this post is a cheap shot as I did exactly the same when I introduced a richer syntax for the Flow Engine by XSL-Ting the general de-typed XML Schema into a more specific one. To my defense, let me point out that I have never claimed that the new syntax will be simpler, the goal was to make it richer...

Back to 1936

The latest incidents in Corsica remind me of my youth, when we were protesting in the streets, trying to convince the government

to maintain its stake in the deficit laden steel industry sector. 25 years have past and steel industry, as well as coal mining, are history in France, sacrificed on the altar of profitability. Is this sad? Surely for all the families that have been badly hit by the situation, but looking at the tough work conditions of these industries, it might be better to follow the trend of western countries and evolve to a service and leisure oriented society (who said shallow?).

Anyway, it was profitable for common good to relieve the state from such debt-crippled industries, and the same applies to the ferry operator SNCM. What is tragic is the incapacity of the government to explain this simple fact that there is no more wonderland and welfare states ; what is also tragic is the fact that the unions are still engrossed in concepts dating from the middle of the 20th century.

A nice alternative would have been to help the employees of the SNCM to buy their company, make it their own so they would take care of it in the way that would please them and make them proud. That would have been a better investment than this pathetic last-minute promise of keeping a few percent stake in the operator.

But we live now in a society that has the luxury of considering that rights are not balanced with duties, so it is easier to enter in a useless and expensive blockade to have workers rights recognized instead of helping them dealing with the duty of saving and restoring the company they work for so hard.

This is not a easy talk and surely not one you want to hold less than two years from presidential elections. Who cares about truly empowering people? Let the noise-making property-breaking unions do their show. Welcome back to 1936.

The Thin Ice of Civilization

Yep this is a sheer paraphrase of Pink Floyd, but it so applies to our world today.

How thick do you think is the varnish of civilization that covers the true misery of human existence?

Several centuries of so-called humanism have left us with pink-glass shades that drive most of us in a true denial of our inner nature and an hopeless faith in humanity.

How much is this humanity worth in Iraq's bloodbath or Louisiana's flood? The value of humanity is not 6 billion times the value of a single human being: it is equal to the very value granted to single human life.

Break the thin ice of civilization and you discover this value...

The Land of Disappointment

A few weeks ago, I was back from the US and readers of this blog surely have noticed my enthusiastic and exhilarated pro-American post named "A land of Possibilities". Now, hurricane Katrina came, devastated New Orleans, took many lives and left me with some disappointment (I recognize that the latter is definitively of no importance!).

Let me express this disappointment with questions:

• How come a country that can mobilize so much energy to achieve so many harsh and complex endeavors, as it regularly does, can be so grossly mismanaging such a natural disaster?
  
  
• How come, when it was about putting off an imaginary threat in a remote country, no human life nor billion of dollars have been spared ; and when it is about dealing with a genuine imminent menace, so few has been done?

Well, may be because, after all, disappointment is also a possibility...

Tainted Green

A friend of mine recently posted on his colorful and witty blog a little reflection about using vegetal oil instead of gasoil in diesel engines, which triggered some thoughts and lead to what you are currently reading.

Let me introduce you to the French ecologist political party named Les Verts. With the increasing environmental issues (lack of water, extreme weather events) and the energy crisis (need for alternate source of power), you could imagine that those guys would be booming.

Let me give you the big no-no: they are not. They are divided and wishy-washy, thus weak and useless. To be more accurate, they made the single biggest mistake an environmentalist party could make: they decided not to be politically neutral and took side for leftist parties. Therefore from truly green they turned pink, if not red.

This tragic mistake made ecology a left-side concern, when it should have been a truly independent and impartial business ; a third power with the mission of issuing warnings and suggesting new paths about how to run the country in an environment-friendly way.

I think that people are readier to pay attention to ecologists: everyone knows how harsh we scorch the Earth and how bad she gets mad at us ; everyone knows how our oil-based energy system is unsustainable both politically and ecologically ; everyone knows that it is time for a change unless we want to impotently watch the upcoming disaster.

Can tainted green be turned back to its original color?

Blue Oyster Wisdom

Airplanes make strangers of us all
Give us distance
Much too easily
Blue Oyster Cult, Mirrors, In Thee

Oh boy, what a summer! Airplanes in the news almost every day, and not for good reasons: the birds keep falling down, claiming the lives of hundred of passengers and crew members, leaving us with sadness and doubts.

Is flying so benign after all?

As a (currently grounded) pilot, my answer will be of course: no. Flying is a very involving activity, where the most critical part of the job (landing) is performed when the pilot is the most tired (after hours of flight) and where there is no easy way out like parking on the side of the road for a little break...

But, as a very distracted driver, famous for increasing the chaos level of highway traffic (dubbed as "D-Factor" by my friends), I will remind you that flying remains the safest way of transportation! The shocking thing about a plane crash is that it takes many lives at a time, while it will take more car crashes to reach the same death toll.

Anyway, this blog was not about travel safety, it was about another side effect of airplanes. Nowadays, you can work and meet people all around the world and then, just after you started to have feelings for them, you fly back home.

Your cherished ones will expatriate to some remote land where you will pay visit to them from time to time, but soon it will, again, be time to fly back home.

Home is known to be where your heart is, but, because of these airplanes, your heart will be in so many different locations, so where will your home be?

The heck to such hollow concepts as "global village", this hurts! Even BOC knew it and this was in good old 1979...

The Land of Possibilities

I am just back from my usual summer trip to the US and I have to say that, more than ten years after I started to roam this country, I am still very impressed.

Not only by the awesome landscapes I had the opportunity to discover in Utah and Arizona, but also by the spirit of the people. Let me detail a little.

There are many places in the world that you would like be emptied of the locals prior visiting: yep, I am thinking of France! Just imagine France without the French! As far as I am concerned, this does not apply to the US: Americans are really interesting people to meet and discover how they live.

The main driver I have discovered in the different places I have visited and people I have met is that things are possible there.

Roads are too narrow and create the heck of traffic jams? Let's widen them, let's build new ones! How about car pool lanes to encourage car-sharing? Ever dreamt of drive-in banks? It is there. Ordering Wendy's while refilling the tank? Piece of cake... Want a new job in a field where you do not hold a diploma? Who cares? Work hard, perform and you're in!

This country is a place where will in action produces results in order to make things reality, not any land but a true land of possibilities.

Summer Bloody Summer

So it's all wicked and bloody and sad, as a summer can be.

First, Paris loses the Olympic Games in favor of London. Personally, I do not really care nor know how bad it is, but according to people around me, it's pretty sad news, so I am emphatically affected.

Then, the morning after, London gets hit by terrorists and many people lose their lives. It seems that using the US Army as a bait in Iraq is not enough anymore: terror is coming back to us, as Al Qaida resumed their deadly agenda.

Only two flashes of light this week:

• the European Parliament rejected Software Patents: that was enough of this non-sense that could only satisfy big corporate.
  
  
• and the success of Deep Impact, a jolly NASA mission that consisted in crashing a probe on a comet.
  

Pfew, I just can't wait the autumn gloom.

It's going to be a beautiful spring...

What happens to me? Summer has been here for five days and I start talking about spring... Well, in fact, I mean to talk about this Spring.

Yes, the Spring framework is beautiful. Not only: it is a friendly framework that goes where you want, without forcing you to subclass its objects. It is full of facilitators that make a developer's life really easier.

I already had this academic knowledge. Since a few days, I have tasted the true nature of Spring, and my life has changed.

I have just started a new open source project (jinFORM) and after a few days already used these features:

• the Dependency Injection framework (the true core of Spring) for gluing all the components together (bye bye infamous Mr. Service Locator!),
  
  
• web flow for MVC support, easy URL/controller mapping and centralized exception support,
  
  
• EHCache support, for a no-brainer instantiation of the cache manager,
  
  
• AOP for introducing Serializable in DOM documents and JAXP XSL Templates, where this interface is missing, which prevents them from being cached,
  
  
• property file support for easily injecting configuration values into beans,
  
  
• and many utilities like the so convenient FileCopyUtils...
  

Next step will be to use Spring for easily exposing internal objects as JMX beans!

If you have not started to use Spring, please do yourself a favor and follow this link.

Kudos to the Spring team!

Eurotrash in Euroland

Old habits die hard: Europe is once again on the verge of... of what? Nervous breakdown? Temporary malfunction?

In a world where compromise is not an option, the current tensions are not surprising. Our favorite politicians flex their muscles in Brussels to look like champions fighting for their own homeland, in order to appease nationalists and protectionists at home.

And all this costs an awful lot of money. Is it worth it? Yes, definitively. Burning billions of cash to feed and bread eurocrats is still much less expensive than risking war again. Investing money in such rooster parades, I mean, high level political talks, is worth each and every penny: let them meet, talk, get angry and reconcile... When they do that, they do not ask us to fight each other.

Talking about things that die hard, I know someone able to handle this eurotrash: John MacLaine! Beware politicians...

Get Out Of My Field!

So Martin Fowler reminds us what we all should already know, that people matter most. Why does he have to do that? Probably because in I.T. you very often face the situation where this obvious statement is loudly claimed while at the same time people are considered disposable. There is certainly an attitude problem, that finds its source in both the employers and the employees.

Employers: If I.T. is for you only a way to generate margin by selling at higher price what you have bough cheaper, please leave the field! We do not need you here, we all suffer from your cold cynicism: clients get infuriated because you sell rookies as experts, experts get mad at you because you break the market prices. Consider selling gravel and stones.

Employees: If software development is for you only your day activity where pride and thoroughness are excluded, please leave the field! We need a true mixture of professionalism and passion in here. We do not want bland little minds but people devoted to provide clients with the most efficient, most valuable and most durable solutions. Consider civil service in a governmental agency.

Thank you.

Gee! With a little more cursing, I could turn that one into a bile!

A Dog Called Rover

I curse the day that I spent listening to Scott Meyers during the last SD West. Since this very moment, whenever I am facing arbitrary restrictions in a software, I am seized by Scott's spirit , turn berserk and start climbing up the walls shouting : Keyhole! Keyhole! Keyhole! That is pretty embarrassing.

What is a keyhole for a software? It is the poetic name Scott has given to such an arbitrary restriction. Text box too small, fixed-size windows, all these limitations that make life so much fun are keyholes.

Some are simply annoying, other are potentially dangerous.

For example, the last keyhole that drove me the Hulk-way, was the incapacity of Windows XP's new search facility to find string content in files whose extensions are not recognized by the OS. Why such a limitation? It made me miss important data because some files where found during the search. If none would have been found, I would have suspected a failure of the search engine, but in my case, the fact that the search facility returned arbitrary files that contained my search string caused me much troubles.

Keyholes! Keyholes! Keyholes!

And, believe me, swapping Rover (the animated dog) with Links (its feline counterpart) does not solve the problem.