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?