goto Aarhus 2011

goto (formerly known as JAOO) has long been a favorite conference of mine. They've done a great job over the years of keeping a high standard of content combined with an efficient and friendly organization. So while my over-consumption of conferences has generally led to conference-phobia, I still feel a sense of pleasant anticipation when heading off for the somewhat complicated trip to Aarhus.

My work this year was a couple of co-presented tutorials: with Jez Humble on Continuous Delivery and with Rebecca Parsons on Evolutionary Architecture. While the former is pretty well treaded in, the evolutionary architecture was our first attempt to do this - but I was pretty happy with how it worked out. I'm thinking Rebecca will be doing this tutorial more widely next year and it's well worth taking a look.

A number of session stuck in my mind. One that got lots of outside attention was the keynote on Google Dart - a new language and virtual machine presented by Lars Bak and Gilad Bracha. In essence Dart is primarily intended for building in-browser javascript applications. You can deploy an application either by compiling to javascript, or by source or a compiled binary to be run by the Dart virtual machine. Compiling to javascript allows for maximum interoperation with current browsers, but sending a binary to the Dart VM speeds up load time for a browser that has a Dart VM installed. Google have open-sourced both the VM and language, which should minimize the friction in including Dart in browsers.

The language is a conservative object-oriented language, with a C-like syntax and single-inheritance object model. Its most immediate unusual feature is its approach to typing. It is a dynamically typed language, but you can add types to the source. These types do not alter the output of the compiler but are checked and will generate warnings if there are type errors. In addition the types can provide information for IDEs to help with things like intelligent completion. (I liked Gilad's quotable line: “type checkers are lobotomized theorum provers”.)

I haven't looked at Dart beyond what was presented in the keynote, but based on that I liked what I saw. I'm convinced there is a need to replace javascript. While it is a language with some powerful features, it is an ugly language that is difficult to use well. A colleague summed it up well recently - he was on a project that used javascript well, but ended up regretting not using CoffeeScript instead because he felt that even well-written javascript was not clear enough code. Dart looks much cleaner and its deployment approach gives some clear benefits for using a Dart VM while maintaining compatibility for older browsers - which is vital as javascript will be around for many years to come.

Another session that was an harbinger of the future was Kresten Krab Thorup's talk on using Riak to store medication prescriptions in Denmark. The existing system is built on a MySQL database, but they are concerned about its scalability. Riak's peer-to-peer distribution design offerred them a better model for running the database across multiple centers. This is a theme that I think will grow, relational databases were built with a mindset of a single big server, but increasingly we are seeing clusters of commodity servers - and thus a rethink of data storage. This prescription information is well suited to this storage approach as data access is primarily getting a full list of prescriptions for a patient - which makes a natural D D D_ Aggregate for the system.

I also found their migration approach interesting. The system naturally suits itself to Event Interception which allowed them to use the incoming events to populate both the MySQL and Riak stores together, testing that the Riak system could handle the update load while still running off the MySQL system.

Over the last year or so it's clear that the DatabaseThaw is moving slowly but steadily. Increasingly people are beginning to realize that data storage is no longer automatically the province of SQL databases, but is now a choice that demands thought. No single data storage solution is the right one for all cases, so you have pick the one that fits your circumstances - but the pay-off is a much simpler and thus more productive programming model and/or better horizontal scalability. It was frustrating to talk to another group of people hampered by an inappropriate use of relational technology when their customer would have been much better served by a NOSQL option.

I also caught up with Graham Tackley and their use of Mongo at The Guardian. It appears that Mongo has worked out really well for them and is a strong choice for their future work. I caught Graham's talk about their use of Scala for new projects and their positive experiences of the language as a step forwards for developing from a java environment. I've heard a few such accounts now, enough to feel that Scala is a serious option for organizations developing on a JVM platform.

A final session I'll mention was Tudor Girba's talk about Moose - a tool for assessing the quality of a code base. I've heard on and off about Moose for a few years. Erik Dörnenburg has been talking about it as we've expanded our work in system health checks. Tudor's talk was quite the virtuoso performance, sufficiently polished that it was up there with the best of Neal Ford's presentations.

The tool also was quite fascinating. It's hard to tell from a very polished demo how easy it is to use a tool, and Moose is clearly a very sophisticated tool (and such tools are often difficult to learn). What struck me most about it was not so much its obvious applicability to assessing code, but its embodiment of the a general philosophy of tools that was central to much of the thinking of the Lisp and Smalltalk communities, but has since withered.

This philosophy sees the user of a tool as someone who is expected to tinker with the very guts of the tool in order to mould it to her needs. To acheive this, the tool not just opens up its source code for inspection and modification, but also makes it easy to make enhancements with rapid feedback. The most common example that springs to my mind is emacs - which encourages a user to treat it as a malleable tool. Moose is written in Smalltalk, and that same philosophy came through strongly in Tudor's talk - quickly allowing you to build first class features into the tool by implementing new functions in a matter of minutes.

Such malleable tools haven't caught on that much. They do require an eagerness from the user to learn how to make the tool truly sing, but this effort comes with the reward of a tool that can truly be tailored to an individual's needs.