As mentioned in my last post, doing clean-up work like improving the usability and taking care of the inevitable bug-fixing and performance-tuning, is tedious. Given the prevalent temperatures and the fact that it's Friday I decided this afternoon to pick up some stuff I haven't touched in many months but which is a heck lot more fun than doing the stuff mentioned above: Developing AirlineSim 1.4. This post will be geared a little towards the tech-savvy so it might not be of interest to everyone.

When version 1.4 was first started it was conceived as a mere update to the regular development branch of AirlineSim. Think more of evolution than revolution. But when I showed Wicket, a framework for developing web-applications in Java, to the team, it was rather quickly decided to abandon the old interface of AS completely and rewrite it from scratch as it offered so many benefits over the technology we used so far. Since at the time I was still in the finals of my studies and thereby working in a company full-time, 1.4-development degraded to a side-project and received hardly any attention. With this period finally being over I could at least think about our next major version again, but the focus still remained on the international launch because dream projects unfortunately don't pay the bills.

So it has been far more than a year since 1.4 was started...an awefully long period in IT. I had to review whether our plans were still feasible technology-wise. Therefore I got me a book about Ruby on Rails. If reading around the respective news pages, this framework sets the standards and trends in web-development right now. At least that's how I perceive it with large applications like Twitter or Xing being build upon it at least partially. My intention when buying the book wasn't to learn a new technology and switch to it, though, but to figure out what all the fuzz was about.

And the fuzz basically is, once again, about a catchy slogan: "Convention over Configuration". Which isn't bad though. In fact, the heavy percentage of configuration work tied to employing powerful frameworks like Hibernate or Struts is immense. So it doesn't sound like a bad idea to reduce the amount of configuration as much as possible as it's prone to errors and generally not as well supported by IDEs as is working in actual code. The Convention over Configuration-principle is based on the idea that a framework should work out of the box and without the need for complex configuration when dealing with standard use-cases.

While Ruby on Rails strictly follows this paradigma it absolutely doesn't fit my taste. The lack of strict typing pushes it too far into PHP's direction...a chapter I've happily closed a long time ago. Also, while the framework offers many little helpers and promises a fast workflow, it looks and feels a lot like last-generation MVC-frameworks which are nice for CRUD-operations but are cumbersome to work with when building complex and appealing interfaces. Maybe I'm not recognizing the full potential of Ruby on Rails here as I merely scratched the surface when working through the book. But well, that's my impression.

So I focused on employing technologies I knew and on how I could get them as close as possible to he principle mentioned above. Interestingly, this was quite easy. You can create a ready-to-use Wicket application within minutes using a Maven archetype. Wicket itself does almost completely without configuration anyway, so not much to take care of here. Database abstraction has always been done using Hibernate since the first version written in Java saw the light of the day. Yes, it does have its caveats, but it's also extremely powerful and, when handled right, performs very nicely. We used to set-up Hibernate solely via countless XML configuration files, now I've replaced this mechanism with Hibernate Annotations which abandons almost all of that and tackles most cases by convention. To make full use of this feature, I also threw over board our long-lived guidelines for database schemas: Tables and columns are now named in a way which hardly requires any mapping between Java objects and the database anymore. All of these ingredients are stitched together by Spring and voilá...there you got a setup which follows the "Convention over Configuration" pattern in many to most important aspects.