Tuesday, January 23, 2007

Thread Like No Other

All for very different reasons, processor vendors, software developers and industry gurus are engaged in talk frenzies about how to leverage multiple core hardware. Some consider the dangers. Some even fight about it.

Beside the obvious enthusiasm of experimenting such a surge of computing power right under our fingers, exploiting this power requires a skillset that is not widely available, at least not in the world of the ugly enterprise applications where people have to develop for the naturally parallelized environments that are application servers.

In this austere world of server side business applications, which are not CPU intensive but are greedy of external resources like RDBMS, there is not much room for developer hand made parallelizing of tasks: it is usually limited to executing long running operations via decoupling mechanisms like messaging.

This said, there are many ways to hurt your server by developing applications in a careless way. Assessing your skills (or your troops) is essential: this is why, following the model of the great Threading Maturity Model introduced by Alan Zeichick a few days ago, I would like to introduce the Threader Maturity Model, oriented towards people and not organization.

0. Unawareness. Complete rooky who writes a web application that can only accommodate one concurrent user and complains why is the server not working better (do not ask for names).

1. Awareness. Developer who has bumped on concurrency discussions, found them scary and prefers to let a more senior programmer deal with threading and concurrency.

2. Experimentation. Developer who dares playing with threads and concurrency, but still errs on the side of double-checked locking, interruption swallowing and the likes.

3. Hotspot. Developer has read enough on the subject and has crashed into enough walls to decide to program carefully, with still a certain level of insecurity and the fear of thread skeletons hiding in some dark closets.

4. Utilization. Developer has an excellent knowledge of concurrency issues and has a toolbox well fitted with patterns he knows when to apply and for what purpose. He can decide what is worth to parallelize and what is not.

5. Adoption. This is also known as "Being Brian Goetz". At this level, the developer has an intimate knowledge of the memory model, the concurrency mechanisms and all that pesky internal details. He is able to think in all the dimensions of multi-threaded development (time, space and whatnot). Nirvana is nearby.


UPDATE 01/2008: Alexandra Weber Morales has published a great compilation of Alan's, Larry's and my take on this subject. It is on DevX.

Sunday, January 21, 2007

Don't Be God Either

Though Google has agreed to work with NGOs to develop a code of conduct, some people keep suspecting the giant of Mountain View to nurture a secret agenda for world domination. Are they getting too suspicious or paranoid? Or are they seeing too small of a plot? After all, for Google, the world is certainly not enough.

I think that if Google was actually bound to drift away from its "Don't Be Evil" motto towards some more cosmic grand plan, the following would inevitably happen:

  • Google would buy T.G.I. Friday's but instead of renaming it GoogleRestaurant, as logic suggests, would simply redefine the acronym as "Thanks Google It's Friday",

  • Google would buy Godiva but instead of logically renaming it GoogleChocolate, would rebrand it as Googleiva,

  • Google would become the official sponsor of The Young Gods, but only if they accept the new moniker of The Young Googles.
Since none of this has happened yet, we can confidently consider that Google is still faithful to its core values. Isn't this heartening?

Friday, January 19, 2007

Editor's Pick

Today is the Windows Developer Tools Day, as unilaterally proclaimed by the folks at O'Reilly, and everyone is invited to share their best tools on the Windows platform. Having contributed a presentation of NxBRE, an Open Source .NET Business Rules Engine, to their Windows Developer Power Tools book, you could expect me to talk about it, as the selfish nerd I am.

But no, I prefer to share my passion for jEdit, my choice for an all purpose versatile open source editor. Funnily, when discussion comes to editors, geeks just go berserk and try to prove how superior is their favorite tool. I will try to avoid this kind of flame war and will just share what I like most about jEdit:

  • It is easily extensible to support new features via an integrated plugin manager. Each plugin could contribute new views that you can dock anywhere and create your own environment. I personally use the XML support plugins a lot and dock them all around the editor window for a great work environment.

  • Adding syntactic coloring for new languages is just a bliss. For example, I created what is called a mode to simplify the edition of WAC files in just a few minutes.

  • The integrated HyperSearch facility just finds things on your hard drive without referring to any particular animal or having to index the terabytes of source code you write on weekends just for fun.

  • It is cross platform, which means I can use it when I work on Linux or Mac. How can this matter to a Windows developer? Well, sooner or later, you will be exposed to an OS that is not a member of the Microsoft galaxy so how cool will it be to just use the same tool everywhere?

  • It can open files not created on Windows systems without stumbling on different flavors of Newline and showing everything on one line. Again, this might seem like unnecessary for an hard core Windows-only-and-the-rest-of-the-universe-can-die developer, but again it happens more often than expected when you start to share files with people in the rest-of-the-universe!
So jEdit might not become an editor's pick but it surely is my pick for an editor!

Wednesday, January 17, 2007

Monday, January 15, 2007

V for Vancouver

I am now entering the final countdown (3 days to go) before my departure to Vancouver, BC where I will start a new job and, hopefully, a new life! When you announce this kind of crazy endeavor, usually people go "wow" and say how great it is and also how so not for them such a thing would be possible.

The most common opposition is: "you know what you are losing but you do not know what you are earning". Well, I am all but an adventurer though, since I still try to start new software projects, I should have a good level of risk taking (or I am just a too naive). Besides, on a pure professional basis, I know what I am leaving behind (a great company with great people) but I also know that I am joining a great company with great people!

On a more personal basis, I hope to find over there a place for my family to call home, which would be a great gain for strangers and sojourners like us.

Friday, January 05, 2007

Sewer 2.0

ZePAG has posted a great entry in his blog that somehow echoes an old rant of mine.

Since he makes some interesting comparisons between IT and different subjects like sewer technologies, I felt like bouncing on the yucky pictures he links to and suggest dubbed image titles:
  • Screw pumps: dependency injection,
  • Primary screen: welcome page,
  • Primary clarifiers: client side validation,
  • Aeration tank: O/R mapping,
  • Secondary clarifier: server side validation,
  • Final clarifier: database level constraints,
  • Chlorination tank: garbage collection.
Does not this make our job easier to explain?

Wednesday, January 03, 2007

One Click To Share Them All

Optrata is doubly blessed by a strange moniker (that sounds like patatra, a French onomatopeia for the sound of a thing falling heavily on the ground) and a bold mission statement (to unify all the private life exposing tools of the web behind a unique page).

By the look of their "please bookmark me so I can appear on radar screens" links:

Sharing Optrata

I feel inclined to suggest them to urgently change their goal and work on creating a unified bookmark tool that would submit a page to the numerous sharing systems out there...

Saturday, December 30, 2006

The Day My iPod Became Just Another Appliance

This is today as my iPod officially joined the rank of my electronic appliances that need to be reset from time to time. The screen had a bizarre circular shift of 15% to the left, showing part of the left side of the screen on its right part. Everything was frozen with the backlight on.

For the record, so far only my oven and my dishwasher needed a little reboot from time to time. Now they are three in the club! Interestingly, they are all reset using an odd combination of front panel keys. Appliance makers do what they can with what they have, but only a few keys are needed for this maintenance operation (look on Windows: Ctrl + Alt + Del do the trick).

My wild guesses concerning the cause of failure for these diverse but similar software controlled appliances:
  • Oven: heat excess in the control panel,
  • Dishwasher: humidity too high in the control panel,
  • iPod: overall system too cold as it stayed overnight in my entrance.
Oh the true happiness of modernity.

Friday, December 29, 2006

Busy Buzz For Lazy Bees

After Sony, who really screwed up their buzz marketing for the PSP3, Microsoft does the same stuff for Vista.

Mmmh, what could be the reason for these two companies (not the tiniest or dumbest on earth) to miserably fail a marketing campaign? What can make them so desperate to have people talk about their glimmering new products?

The answer might be in the common points between the PSP3 and Vista: expensive, unattractive, deja vu.

Do you find I am tough? Well, let's get tougher: guys, next time, ask a buzz specialist to advise you, else drop the idea. A failed campaign is not something you want to experiment. Again.

Thursday, December 28, 2006

NxBRE 3.1.0Beta1 Is Out

I have just posted a beta release of NxBRE 3.1.0, which is mainly intended for those interested in testing one of these two new features:
  • A regular expression matcher operator has been added to the Flow Engine (which is also available in the Inference Engine),

  • The implication scheduling in the agenda has been improved to limitate the number of fired implications, hence yield to better performances with large rule bases.
There is also a preview implementation of the RuleML 0.91 Naf Datalog adapter. So far, this implementation does not support the cool features of the new version of RuleML (like multiple named rulebases in one rule file or retract operations), then it is not worth using it. Hey, it's a beta after all!

Friday, December 22, 2006

Unexpected Performances Can Occur (Sometimes)

I just can not believe the message Khalid Khalil has just posted on NxBRE's open discussion forum!

Using object pooling, Khalid has reached a throughput of 2000 requests per second with the Flow Engine, one of the two engine flavors available in NxBRE. It is far beyond the performances I was expecting for my tiny business rules engine: way too cool!

Tuesday, December 19, 2006

Behind Closed Doors

My friend Stuart Hogue, Strategy Director of frog design inc. in NYC, has published a pretty interesting article about hyper exclusive social networks.

I find significant that his article comes at a time when Metcalfe's law is under criticisms. In different replies to IEEE Spectum, Robert Metcalfe stands by his law stating that the value of a network is equal to the square of the number of users. His opponents are mainly saying that: "The fundamental flaw underlying (...) Metcalfe's (...) law is in the assignment of equal value to all connections or all groups".

So the key and maybe the mathematical justification of hyper exclusive social networks might lie in this principle: not all connections have similar value, hence dedicated selective network will maximize their value by selecting only people who will engage in high value relationships.

In practice, it is true that I have quickly dropped Orkut and Friendster to favor the more selective LinkedIn network. I am still waiting to see returns from the highly selective Blue Chip Expert network, to which I have recently been invited. If you visit their homepage, you will appreciate the main picture: a closed door that looks very serious!

Is the true value of social networks waiting behind closed doors?

Saturday, December 16, 2006

All I'm askin'

A recent and insightful Computer article from Stephen Jenkins (Concerning Interruptions) led me to rethink my authoritative position on working with headsets (read Kindly Kill That Headset).

I think the crux of the problem is not about knowing if programmers need isolation to avoid frustrating and concentration killing interruptions (this is granted), but actually respecting this need for isolation.

If everybody would respect this need by refraining from asking out-of-context questions (the most brain resources consuming ones) and by saving interruptions for better times (like planned meetings, lunch time or pit stops), programmers would need less to stick headsets on their ears and would therefore be more available for direct in-context questions from fellow team members.

Aretha was right: it's all about respect!

Tuesday, December 12, 2006

Proxy That Proxy

One day or the other, you will wake up with the bold idea of deploying several EAR files in your JBoss 4.0.x Application Server. Why bold? Because it is almost sure that:

  • you will need to isolate the class loaders of the EAR files (for example to load different versions of the same class in the different applications),

  • you will want EJBs to communicate between the different EAR files.
It will then be the day you will meet the often challenged allways challenging Unified Class Loader (a disciple of Dolph Lundgren) and its scoped deployment configuration options, get a few ClassCastException and finally opt for switching all your EJB calls to the "by value" semantics. Then you will start drinking to forget about not only the amount of pain involved in the process, but also the loss of performance induced by passing all parameters by value.

If your EJBs only take and return classes from the JDK, rejoice! There is hope for you! Indeed, you can remove this problematic casting:

HomeInterface hi = (HomeInterface) lookedUpHome;

which generates exceptions because the looked-up interface has been loaded by a different class loader than the one you cast to, by using a dynamic proxy that directly implements the business interface of your remote EJB.

To simplify this, you can leverage Spring Framework's SimpleRemoteStatelessSessionProxyFactoryBean, which will lookup your EJB, create it for you and return a dynamic proxy that implements the business methods. By this mean, the need for casting is removed.

Of course, as I said before, this only works if you exchange primitives or objects from the JDK (because they are loaded from a common hierachy of class loaders that includes the system class loader). But it is a viable alternative to keep in mind...

Saturday, December 02, 2006

Hetero-Genius

In the November issue of Computer, there is an interesting article from David Alan Grier, titled "The Benefits of Being Different", which talks about a subject I am currently particularly sensitive to: the dangers of uniformity in IT systems.

My reflection started a few weeks ago when IEEE Spectrum published a seminal article (Shrink the Targets). Indeed, after the rise and establishment of Microsoft supremacy on personal computers, we are in a great need of diversity because homogeneity has many hidden catches we have to pay one day or the other.

Homogeneity makes IT systems fragile because the same flaw or weakness is reproduced on hundred of thousands (if not millions) of machines, making all of them sensitive to a well targeted attack. The discussions about the superiority of a particular OS or tool (like a browser) that end up with plans for the worldwide replacement of one by another, are childish and futile. All these pieces of software have reached such a great level of quality that you can not select them on pure technical basis. So there is no supremacy to target, as replacing one domination by another one, would leave us with a situation as fragile as before. We must see the advent of non-geeky tribes who will recognize themselves in the usage of a particular combination of OS and tools, who will be empowered so they can assume their choice without being exposed to nasty technical problems or being pointed as originals.

Homogeneity carries another risk: the supremacy of a particular tool or vendor always induce the usage of proprietary file formats. Being locked-in a vendor tool because its features are so above the competitors is nothing bad: it benefits the user and, moreover, it never lasts. Competition always catch up. Then open source tools come in, disrupt the model and force everybody to think harder about increasing the quality of the tools and the services that gravitate around them. But being locked-in because your own personal data are locked-in a proprietary file format is nothing that can be accepted anymore. Diversity forces vendors and tool makers to enable data exchange, freeing the content that was held captive.

In a time when our most precious material assets are mainly digital (does not this feel like a quasi oxymoron?), homogeneity is no longer an issue. Let us be hetero-genius!

Saturday, November 18, 2006

Mapping panacea

To paraphrase the golden hammer saying, I have the feeling that nowadays, because you have object mapping frameworks, everything looks like an object!

What is it with developers who seem to get infatuated with such tools? Does everything need to be mapped to objects? Of course not! Here two recent cases that kind of drive me nuts:

  • Why reading XML files when I can map them to objects? Well, maybe because what you are looking for is actually... data. So please save your application from the miseries of JAXB 1.x (which does not even care to mandate a clear concurrent behavior in its API) and use SAX, XPath or any other efficient XML reading tool!

  • Why querying the database when I can map it to objects? Well, maybe because you are performing batch operations that are mainly data retrieving oriented and the overhead your O/R mapper will add plus its memory consumption will put your virtual machine on its knees. So please take the fast lane!
End Of Rant.

Thursday, November 16, 2006

Feeding the White Rabbit

So now that, for my birthday, I got my own Nabaztag, a white WIFI rabbit that can move its ears, display light signals on 5 RGB LEDs and play digitized sounds, the big question is: how to keep the funny bunny happy?

I guess by feeding it properly.

The default services offered for free by the vendor are pretty basic: weather, stock exchange, email account watcher... And the coolest: rabbit Tai Chi! Hey, what do you expect: they are free, right?

Since the animal has an HTTP based API that allows controlling its ears, lights and sounds (including a nice TTS feature), I do not see any reason to subscribe for the advanced paying services! It will be much more fun to write services for it!

So I came with the first one today, an appetizer for the white rabbit: the service connects to the GMail accounts of the family members and builds a vocal summary of the emails waiting to be read. And that's already cool ;-)

There are many other funny things to do: a service that would report the daily statistics of my open source projects could be fun. Another one that would connect Maven to the animal and that color the poor thing in red whenever a build is broken or unit tests are not A-OK, would be terrific.

You might wonder what is the moniker of this new family member? Knowing that if you know his name, you can make it speak and that the thingy sits in the middle of our living room, where any sentence rated above G are not welcome, I would say that we will call it "secret". For now.

Saturday, November 11, 2006

Centralized Configuration Management for JBoss

NOTE 12-MAY-2009: This particular post is driving a lot of traffic on my blog. Even if the JBoss Properties Service is still worth using, nowadays, I would not advocate the management of properties in SVN, as it is problematic security wise and requires the need of an HA repository. I would rather embed default properties values in my project and allow the overriding of some values (passwords...) via a simple file created in a well known location on the server.

Managing configuration of application servers and the applications they host in a centralized and rationalized way is a requirement for any corporate doing its own hosting. Not only configuration differs between server instances and the applications they host but also between the different environments they exist in (ie. development, integration, QA, pre-production and production).

JBoss 4 user guide shows how to leverage the Service Binding Manager to handle server configuration in a central way. This is a great approach but I think we can go further by leveraging Java system properties in conjunction with two other features of the server: the Properties Service and the fact that JBoss parses all XML configuration files (including J2EE deployment descriptors) and resolves ${references} to system properties. Moreover, if you use the Spring Framework in your application, you can also leverage its PropertyPlaceholderConfigurer to retrieve configuration information from Java system properties.

As shown above, the main idea is to store configuration information as properties files in a Subversion repository and have the different JBoss Application Server retrieve these configurations through HTTP and thanks to this kind of configuration of the Properties Service (in properties-service.xml):



These system properties will then be loaded at JBoss startup time (or on any modification, like a touch, of the properties-service.xml file) and will be available for use in many different places like:

  • XML server configuration files that configure ports and host names (for web server, invokers, JNDI tree...),

  • J2EE deployment descriptors to avoid hardcoding of parameters (like user name and password used to connect an MDB to a remote JMS destination),

  • application parameters provided they are read from Java system properties (which is easy and nice to do if you use Spring).
Of course, there should be a way to find the right configuration in the SVN repository. As you surely have noticed it in the previous configuration fragment, since the Properties Service is configured by an XML that is parsed, it is possible to use a system property to configure it (now this is eating your own dog food!). The system property used to select the proper configuration can be either ad hoc (a custom one added in the startup script or run.conf of the particular JBoss instance) or standardized (for example, if each JBoss instance is run with a specific user, the system property can then be user.name).

Another interesting feature of the Properties Service to leverage is the fact you can provide a list of URLs: all the properties will be loaded from these URLs, the latest ones having the precedence on the first ones. This can be used to organize configuration in a hierarchy, with global settings, server specific settings and application level settings loaded from a common place and mixed together in the Java system properties. Here is an example of such a configuration:



As you can see, not only is JBoss a versatile application server, but it is also an extremely configurable one that can be easily tuned to fit the needs of large companies with complex deployment constraints.

Saturday, November 04, 2006

New Position: File Name Manager at Oracle Corp.

Goals:
  • Rename Oracle JDBC driver file names so they actually differ between different versions,

  • If possible, improve the manifest files so there is more difference than the "Implementation-Time" attribute between two different versions.
Required skills:
  • A true desire to help developer teams and production departments making sense of the different driver releases.
Disclaimer for the slow brained: This is a hoax. I took the decision to create this position simply because someone had to do something.

To fully enjoy this post, go to these pages (9i, 10g & 10gR2) and download the different versions of the JDBC driver: you can not miss them, they are all named ojdbc14.jar. You can then try your skills by figuring out sensible names for these files!

Sunday, October 29, 2006

A 16 Months Iteration

I have finally been able to release a first alpha version of jinFORM, 16 months after the project started. The title is voluntarily provocative: it was not an iteration but a slow maturation!

Why did it take so long? As explained in jinFORM news, part of the time has been spent waiting for a presentation server able to render some much needed features of XForms 1.1. Initially, Chiba was targeted as the presentation server but testing and experiments have finally pushed the project to use Orbeon Presentation Server, which offers a more stable XHTML + JavaScript rendering, a better compliance to standards (XForms, XML Pipelines...) and the much needed XForms 1.1 features mentioned before.

So, what is jinFORM 0.1.0 worth? Not much for production: you can only fill simple forms with repeating sections, but without computation or logic. The only submission that is currently supported is for saving the XML instance built by the form behind the scene.

Then, was it worth the effort and why should anyone care about this project? Well, anyone with a slight interest in the intimates of Microsoft Infopath file format (aka XSN) should be interested to see how jinFORM transforms this proprietary form definition to XForms.

Because an XSN file is simply a CAB stuffed with XML, XSL and extra files, described with a documented manifest, groking its content is fairly easy. Doing anything with it is another thing. Take the XSL for view rendering (usually named view1.xsl) that is generated by Infopath. Because this XSL relies on implicit MSXML objects for supporting many extension function calls, jinFORM has to pre-chew it and implement similar functions in order for anything to work.

When designing this XSL, Microsoft, of course, had anything but elegance or portability in mind. It is cluttered with prescriptive commands like xsl:for-each, traps like testing for the existence of a function and using another one and oddities like using a function to retrieve the current document on which this XSL applies. Surprising approach from Microsoft? After they love functions and procedural programming: why would they embrace the template concept that is underlying XSL transformation?

There are still many things to add in jinFORM to make it really usable but it is a good first step. Foundations have been laid, now let's build on it!