JRuby on Rails status

JRuby 0.9.1 is out for a week. This is the first version in which JRuby really starts to perform and behave properly. Though Ruby on Rails has been reported to work on JRuby for a longer time, this was not repeated by many people; too many loopholes to jump through. However, with the advent of version 0.9.1 there are suddenly many people on the mailing list that are trying and achieving exactly this.

Another promising release was done yesterday in Japan: rails-asyncweb 0.1, a very fast web server for JRuby on Rails. TAKAI, Naoto's asyncweb uses AsyncWeb, a web server that prevents the synchronization pitfall that the Java Servlet API brings. AsyncWeb scales a lot better under load then traditional Java web servers. And the performance rocks! It is about 10 times faster then Webbrick under loads to 10 concurrent users. It will be very interesting to see what happens under much much larger loads. I am also curious how this will compare to Mongrel, Zed Shaw's successor for Webbrick in the C-Ruby world. Another interesting question is whether this will end Mongrel's Java port.

Another web framework that works under JRuby is Camping. Camping is smaller then 4K, but quite powerful. It is a creation of the well known Ruby virtuoso why the lucky stiff. If you want to get a feel for what Ruby can do but don't want to learn Ruby on Rails (which I found quite a large task) I recommend you try out Camping. Ola Bini has a nice tutorial on getting you started. (Note: you should not use Camping version 1.5 because JRuby does not support continuations.) Another very good Camping tutorial (Dutch) was written by Remco van 't Veer.

Update 2006-10-30: added Remco's tutorial.

Wicket autocompletion improvements

Here is how I extended Wicket's (version 1.2.2) autocompletion with 2 new features:
- immediatate open of the drop-down as soon as the text field gets focus
- define the width of the drop-down independent of the text field

As the JavaScript is well hidden within Wicket and is not easy to extend, I tried another approach that worked well. I created the package wicket.extensions.ajax.markup.html.autocomplete and placed my own edit of wicket-autocomplete.js. Because the package is compiled into my WAR I am sure it is the first on the classpath.

First of all, in the initialize function I added the following fragment:

 if (obj.className.indexOf('immediateopen') != -1) {
     obj.onfocus=function(event){
         updateChoices();
         return null;
     }
 }

Secondly I changed function showAutoComplete to the following:

 function showAutoComplete(){
     var position=getPosition(wicketGet(elementId));
     var menu=getAutocompleteMenu();
     var input=wicketGet(elementId);
     var rem = input.className.match(/\bmenuwidth(\d+)\b/);
     var menuwidth = (rem == null) ? input.offsetWidth : rem[1];
     menu.show();
     menu.style.left=position[0]+'px'
     menu.style.top=(input.offsetHeight+position[1])+'px';
     menu.style.width=menuwidth+'px';
     visible=1;
     hideShowCovered();
 }

That's it. Its fully backward compatible, except that if you use the classes immediateopen or menuwidthXXX you'll get the new behavior. If you are lazy, you can download the complete file.

Example:

  <input class="inputcode immediateopen menuwidth300" type="text" />

If programming was as risky as parachute jumping...

Last Friday my company organized a parachute jump. Unfortunately the clouds were, typically for the season, too low and the wind was too hard. But I learned some interesting things anyway as the morning was spend on a crash course testing by Kees Blokland from PolTeq.

One of the major things for testing is risk analysis; the amount of time spend on testing an aspect of the system is proportional to the risk of that aspect (where risk is chance of failure times impact). For fun we made a risk analysis of parachute tandem jumping. To make it more real the instructor and owner of the jumping company also joined the discussion. He told us what he does to keep jumping safe and the risk low. He named two aspects 1) attitude, and 2) an open culture. An open culture is important because incidents must always be reported so that they can be analyzed and prevented in the future.

The attitude aspect coincided well with a discussion we had earlier about the tendency to not test well. Sometimes the client thinks it is not necessary, sometimes developers don't know how to test properly, and sometimes they don't want to.
I asked what the instructor did to maintain a good attitude so that we might apply his lessons in the world of software. Here was his answer:
1. parachute jumping in itself already attracts the right type of people,
2. everybody understands that safety and risk control is paramount,
3. maintain maximum openness about incidents,
4. make an example, even a bruised toe is reported to the authorities, and
5. take disciplinary measures only when there is an attitude problem. These measures are usually drastic, for example a withdrawal of the jumping permit.

So what can we learn from this? Here are my ideas derived from each answer:
1. Attract people with the right mind set. Look out for people that are both result and quality driven.
2. Train you project managers, and require them to organize risk assessments. In software not everything is deadly dangerous and not everythings needs to be tested.
3. Use bug metrics. I am not so sure about this one. But you should at least use automated testing.
4. Even a technical team leader can make bugs. Be sure that everybody knows that.
5. Don't blame people when they do something wrong. But give the pink slip when they refuse to improve.

Even when you will apply these lessons, you will have to realize that only when programming will be as risky as parachute jumping, programs will become bug free.

We made the jump 2 day later. It was great and there were no bugs.

What makes a programmer?

The answer to this rather philosophical question came up yesterday on the way home from my company's parachute jump event (more on this in a later post). My superior explained how he used to program in the past: "Try something, and if it works add more. Things that are used more then once are moved into methods." This approach will work for small projects, but will create a big mess over time. It will definitely create a mess immediately for larger projects. We are lucky that he is a good manager, but also lucky that he does not program for our customers.

So how does a good programmer work? In my opinion the sole work of a programmer is to map abstractions onto other abstractions, and to add new abstractions when this is not possible.

Lets give a simple example. XML documents are a well known abstraction for a hierarchical structure of labeled values. Files are a well known abstraction for a named sequence of bytes. To persist an XML document one writes code that maps the first abstraction to the second. How to do this is well described in the XML standard, but is definitely not the only way. I have written more performant mappings for specific cases.
A more complex example: to understand a voice command, one of the mappings might be from a sound sample to vowels and consonants.
Other types of abstractions are written in functional designs, test documents, etc.

So what makes an excellent programmer? An excellent programmer:
- Works with well known abstractions. There is not much to know about XML documents and Files. This makes them easy to understand and versatile. RDMSs provide an abstraction for storing tabular data. They are more complex, but well know.

- Will create small and consistent new abstractions.
An excellent programmer will create small levels of abstractions in his system with consistent terminology. For example, while processing sound samples it may be wise to create an intermediate level of abstraction that facilitates working with different sample rates and sample sizes. Consistency can be reached naming things carefully. Simply using the same names for the same things is a good step.

- Can work with many levels of abstraction at the same time.
At times it will be necessary to understand how the different abstraction mappings interact. For example, while persisting a phone book in an XML file, you need to know what each mapping does with character encoding.

So how do you do all this? Unfortunately I have no simple receipt as my manager has. I am afraid, excellent programming is still a craft.

Top3 reasons for using NetBeans

Here is my top 3 reasons for using NetBeans:

3. You are masochistic, and like to change IDEs once every while
2. JPA support is apparently quite good
1. You are going to work for Sun

Wicket getting even more serious

I just saw on the Wicket e-mail list that there is now a company that provides commercial Wicket support. Their name is, guess what: Wicket Support.

Their initial coverage is basically Europe and United States. But they are interested in extending it if the opportunity arrives.

Wicket getting serious, Pro Wicket - Book Review

One of the interesting new web frameworks that saw the light recently is Wicket. Wicket is quite radical in that it relies solely on Java programming and does away with configuration and JSP/PHP/Rhtml type html generation. Although not unique in this approach (e.g. Barracuda, Tapestry) many web-developers will have a hard time getting up to full speed quickly. Luckily this has changed with the publication of the first Wicket book: Pro Wicket by Karthik Gurumurhty.

The book 'Pro Wicket' guides you through the development of a simple and sometimes not so simple web application. Page by page the application is extended and shows more and more Wicket features. Sometimes a 'mistake' is made. That mistake is then later 'corrected'. Unfortunately this makes the book less suitable as a reference book as you always have to flip through the chapter to see if you have the complete example.

The contents of the book varies nicely. The basics and way of thinking in Wicket are explained with lots of examples. Also the internationalization features are thoroughly explained (although I find it disturbing that the example mixes up languages and countries). There are well set up explanations and examples on how to integrate popular technologies like Spring and Hibernate. The AJAX examples cover the basics (which are quite good in Wicket) but a lot is left to be discovered. Testing is even less well covered, but at least here some good pointers are given to the manuals. A nice touch is to take a brief preview of Wicket 2.0.

The book is completely written in speaking language. The following sentence is typical: "As you might have guessed by now, this method returns false by default.". For some people, like me, this is a turn down, but most are probably okay. What is worse is that on every page you'll find pronouns (like 'it' and 'that') for which it is quite unclear what is referenced.

The Achilles' heel of the book is in the end of chapter 2 where there is a totally incomprehensible explanation on how to use repeating page elements in Wicket. I find it a shame that such an important subject is tucked away at the end of a chapter on a different subject (validation), and that the reader is suddenly confronted with a page full of abstract terms and such a small example.

I had a hard time reviewing this book. At many points I thought that the book was not finished enough to be published. Of course this was okay as I was reading the beta, but when the final book came out I noticed that only the code examples had been thoroughly updated. I am afraid that either the publisher pushed this one too hard, or the author just was out of time.

Conclusions
Despite some of the remarks above I am going to recommend this book anyway. First of all because it is the only Wicket book on the market, secondly because it does teach you Wicket. And that is a Good Thing.

Thanks to Apress for providing the book for this review.

Update 2006-10-05: Added link to Karthik Gurumurhty's blog, removed spelling mistake, deleted all comments related to the spelling mistake.