Not a unicorn, nor Switzerland neither

I've just listened to a podcast of David Heinemeier Hansson's keynote at RailsConf 2007 (which actually took place back in May of this year). David describes the changes and new features being introduced into Rails 2.0. Firstly, he is at pains to point out that Rails 2.0 will not represent a radical change, or a complete re-write. Also, 95% of what will constitute Rails 2.0's new features are already available in the bleeding edge EdgeRails and are being actively used. To use his phrase, Rails 2.0 is no 'unicorn' - it is not a mythical beast. Having said this, there do appear to be some fairly important changes in Rails 2.0. Rails has for a while had an effective plugin system. Plugins are relatively easy to write for Rails and so good, new ideas can be disseminated and incorporated into working code very quickly. The popular, successful plugins can then be rolled into Rails 'core'. What I like about Rails is that this can work the other way too: after time, things which no longer seem to belong in Rails core can be removed and made available as plugins. It is very, very easy to make a plugin available to your Rails installation so this type of deprecation strategy is kind to the developer, especially if they are using legacy approaches or code. And if nothing else, Rails is all about being kind to the developer. Significantly, the ActiveResource plugin which drops a full ReST framework into Rails is in, while the ActiveWebService functionality to support SOAP is out although, of course, still easily available as a plugin. This is really about making a statement, something neither Rails, nor it creators and developers are generally shy about doing. As David puts it in his keynote (my transcript from the audio):

Unlike a lot of frameworks which pride themselves on being all about flexibility, which pride themselves on being all about being neutral, neutral to choices, being Switzerland in other words....Rails is not. Rails is not Switzerland. Rails has an opinion.

It was through engaging with Ruby on Rails that I first encountered the design paradigm of Convention over Configuration. As a veteran Java programmer I immediately saw the appeal of this. Of course Java programmers have historically favored the "abstract enabling-framework" over the "direct problem-solving" approach, so it can be difficult to adjust from one to the other. Michael Coté describes something similar when he talks about Java’s Fear of Commitment. This is what makes Rails interesting for me. It has an opinion. It is not ashamed to show a strong preference for a way of doing things. As a developer, you can still choose to do things differently (and sometimes this is just unavoidable) but you get so much for free by just following the conventions. David also characterised Rails as having 'friends' and 'allies'. Components or aspects which Rails strongly supports, such as ReST and AJAX are friends. Those which it is starting to support, but which still need to prove themselves are *allies *- among these David listed Atom and OpenID. Interestingly, Rails will now have simple support for HTTP Basic Authentication. Previously, Rails developers have eschewed this non-user friendly approach to securing their applications, as it fails to offer the user features which they have come to expect, such as "remember me" and "mail me my password because I've forgotten it" options. However, it is now recognised that HTTP Basic Authentication is useful for non-user mediated authentication, such as client access to secure APIs. David cites, as an example, the RSS reader which typically can store and use a user's credentials on their behalf to access a secured RSS feed. Eventually, perhaps, this will be made redundant by newer approaches such as OAuth, but I can immediately see how this could be useful in developing mashups in the meantime.