Radrace impressions

On the 26th and 27th of September our company (QNH Application Development & Solutions) held the second internal Rapid Application Development race. There were 15 teams each consisting of 2 people competing against each other. As you already have read, a variety of technologies were used. The technology of our choice was Grails and the IDE we used was IntelliJ. Here are my impressions.

25th of September
23:30: The final preparations for the game tomorrow were made. I double checked the setup on my laptop, from Subversion to IntelliJ and all possible documentation we might need. I also did a final check on our pre-build application to see if everything still worked as expected.

26th of September, the first day
09:00: There was a briefing of the application that had to be build. The application was about the registration of driver licences which contain points. Points are subtracted when a driver makes an offence, like speeding or drinking while driving. Points are added when the driver shows good behaviour like taking a practical exam.
The functionality that was needed consisted of the following:

• Login functionality for John Europe. John Europe must be able to see his driver licences and for each driver license the details. Details consist of his points left and the offences he made. He could also go into appeal for some of the offences. When a civilian goes into appeal, an amount of 100 Euro should be paid. A payment module with credit card check should be build.


• Login functionality for the judge which treat appeals and determine if an appeal is valid or not. An e-mail is sent to the applicant of the appeal to inform him/her about the decision of the judge.


• Login functionality for police officers which see an overview of all civilians which should have returned his/her driver license to the police.


• Login functionality for insurance companies to determine the price of car insurance policies for civilians.


• Business rules which state how and when points are subtracted and added to the points on a driver license.


• Make use of the existing database which is a Microsoft access database. The number of records in this database was close to 40.000 and consisted of multiple tables with relationships between those tables.


• A couple of reports which display the civilians who needed to take practical exams and eye tests.

10:00: Let the games begin! We used the first 15 minutes to determine our strategy and made sure that we understood the functionality. After that we started working. I used the Mysql migration wizard to migrate the Access database to Mysql. We created a separate database for the original data and a new database for the application. Paul started working on the domain model and database and I started working on the authentication/authorization functionality. Whenever Paul had created a domain object and migrated the corresponding data, I started working on the controller and view for that functionality.

12:00: Lunch. We already had the login functionality, the eye test report and the data model for the rules working. For the report functionality we used straight sql with Spring’s JDBC template. There was not anything that had yet gone wrong.

13:00: We started coding again. I began working on the driver license information and the functionality for the judge and Paul continued to migrate the data. I used some Ajax to display the driver license details. We made sure we used the unique ids from the original data to maintain the relationships. Groovy scripts were used to migrate the data.

19:00: We completed the functionality for John Europe and the Judge. Both reports were finished. There were some improvements left to be made which we did the next day. We decided not to do anything with the rules yet because there were no real deliverables regarding those rules. Our expectation was that the changes, which were issued the next day, were regarding those rules.

20:00: We had a nice dinner with all of teams in a restaurant a talked a lot about this day. We tried to figure out what the rest of the teams were doing to measure our competition.

27th of September, the second day
08:00: We started with the optimizations of the use cases we finished the day before and made sure all functionality was working correctly. A total of three changes were issued. One of the changes was implementing the rules regarding speeding and parking in restricted areas. The rules were developed by me and Paul concentrated on completing the judge and police functionality. Some changes to the css were made to make the application a little more attractive than it already did.

11:45: We made sure everything was checked in and did a final test to make sure everything worked as expected.

12:00: Development time is over. We were pretty confident that we completed a lot of the functionality and scored a lot of points. However, we were not exactly sure if this would be enough to win the first prize. The jury began examining each application. Because of the huge amount of teams, the jury was divided in two so two teams could be judged at the same time to speed up the process.

15:00: When the first jury round was over, the best three teams had to demonstrate their application for the grand jury. We were one of the three best teams! We passed the test script and almost all of the functionality worked as expected.

16:00: Finally the awards. There were a couple of awards like the “best dressed award” which we did not win:). We already knew we were among the best three teams. When we heard we had not won the third prize we fell relieved. We could only be number one or two. The tension raised and eventually we heard that we came out first out of the total of 15 teams and both won a brand new Xbox 360 Elite console! All the preparations weren’t for nothing.

17:00: It was a great day and had a lot of fun with everybody. Till next year!

To see a video impression of the rad race check You Tube
Paul Bakker also wrote an impression which you can find here

Our first Open Space session

Our first Open Space session was held on the 15th of September 2008. As you may have read, our internal RAD race is on the 26th and 27th of September. One of the open space subjects was how you can prepare yourself for the RAD race. This was the outcome:

• Preparation is the most important thing


• Database setup


• E-mail client/server


• Styling


• Authentication/Authorization module


• Print module


• Payment module


• Code generation


• Books, pdf’s


• Source Control System


• Networking equipment


• Working hardware


• Report generator

As you can see there is a lot you can do to prepare yourself for the RAD race. What is your opinion about the preparation for a Rapid Application Development race?

Internal QNH Rad Race 2008

26th and 27th of September, our company organizes the second internal Rad (Rapid Application Development) race. A Rad race is a competition in which several teams compete against each other to build an application in 1.5 days. The team which completes the most functionality wins. The teams consist of two people which work together and are responsible for creating their own development environment including version control, choice of IDE etc. They also choose their own technology to build the application in. It is your own responsibility to choose a technology you are familiar with. The technology we use to build the application is Grails and IntelliJ as our IDE. We find the Grails framework (and Groovy) very productive and a pleasure to work with (which is partly due to IntelliJ, one of the best IDE’s I have worked with).

The competition is tough though. There are 12 other teams which use the following technology:

• PHP / Ruby on Rails


• .NET


• Oracle / APEX


• Flex, Spring


• Spring MVC


• GWT, Spring and Hibernate


• Wicket, Spring and Hibernate

Although several factors come into play which determine who is the winner, it is nice to see the pros and cons of each technology during the competition.

We will keep you updated!

Support for image acquisition devices in Flex/Air

I would like to see support for image acquisition devices in Flex/Air. Currently there is no such support for image acquisition devices, like scanners that operate via the TWAIN API. However you can use sockets in combination with a Java application but this is far from an ideal scenario.

I filed an issue request which you can see at https://bugs.adobe.com/jira/browse/SDK-16239. Please vote on this issue and we may see support for image acquisition devices in the future.

Open Space sessions

Upcoming august 2008 me and a colleague organize the first internal Open Space session for our company. Although the concept is not new, Open Space sessions date back from 1985, they gained momentum at Java Polis 2007. Here, Bruce Eckel held an excellent presentation about Open Space sessions.

I think knowledge and/or experience sharing is a key point in our profession as a software developer/engineer/architect etc. We constantly seek new and effective methods to share our knowledge. The most effective method for sharing knowledge is the one with the best cost/benefit tradeoffs. Costs have the form of the amount of time invested to prepare a session and the benefit is the amount of knowledge and experience shared amongst other colleagues.

The cost/benefit ratio of a traditional session/presentation is not very high. Usually, the preparation of a session costs far more than the benefit it gets. When this session is held multiple times, the cost/benefit ratio gets better. The format of a traditional session is of a very static nature. You have one or more presenters and a whole lot of attendees. The attendees do not know if the session is of any value for them. For some this may be the case and for others this may be not. Also, the attendees usually are not in the position to determine the subjects of the session.

Open Space sessions try to address these shortcomings. In an Open Space session the subject is determined by the attendees. The attendees seek a space where they can discuss/contribute and learn about the subject. One thing to remember in an open space session is the 'Law of the two feet'. This means: if you feel you do not learn anything or cannot contribute something meaningful to the session, use your two feet and seek another session which may interest you. This way you and the other attendees get the most value from a session.

I will post our experiences and the way we organize our Open Space session in the next month. Stay tuned...

More information about Open Space sessions can be found at:

• Open Space world


• Wikipedia

JavaFX and Air: a brief comparison

Paul Bakker has wrote an excellent post of our first impressions when developing the FolderVisualizer. Check it out and also don't forget to install and try both applications!

Efficiently reclaim you disk space

We started a new project on Google code named FolderVisualizer.

The application is able to visualize the relative size of files and folders below a given directory. With this tool it is easy to see which files and folders take up the most disk space which you then can use to efficiently clean your hard drive. See Olav Maassen's post about efficiency :).

Although such tool already exists, it is fun to see how different implementations compare to each other. At the moment, the following technologies are planned:

• A Groovy implementation with a command line client


• A Java implementation with a command line client


• A JavaFX client


• An Adobe AIR client

It is nice to see that the JavaFX client can make use of the Groovy implementation of the visualizer algorithm. For the AIR implementation we have to rewrite the algorithm in Action Script.

The project can be found here.

Once again: Assumptions are the mother of all fuck ups!

Even the most obvious assumptions aren't all that obvious. Who believes that a software tester tests a new release in the production environment! This has actually happened. When a new release was installed in the acceptance environment, the acceptance tester was signalled.

When he finished testing, a whole list of issues was reported via the issues tracker. We had absolutely no idea of what was going on until we asked for the URL and user accounts with which the tester had tested. The URL that was used was actually the URL of the production environment! After that it was totally clear to us what went wrong.

Lesson learned: even if your assumption is obvious, do not assume!