Bones' Blog of Stuff About Things

Because I prefer to make slow progress with many things rather than slightly faster progress with a few things, I’ve started another project, the precise nature of which I won’t go into right now except to say that it’s another web-app, but a rather more serious-minded affair than my other pastimes. The bit that is worth talking about right now is that I decided to at least start it using Ruby on Rails rather than Django. This was for a few reasons: partly because RoR has the more mature Ajax support and I definitely need that for what I want to do; partly because Django has a number of major changes in the pipe, and I didn’t want to have two projects that would need patching at the same time; mostly because I just wanted to try Rails out properly.

My experience with Rails was definitely helped by the previous experience with Django, however the process of getting Rails up and running is still impressively simple and fast. Having everything bundled as gems, the very neat project tree layout that is generated and the http server that works out of the box gets you to a running setup in a couple of minutes. The screencasts of the blog project and the migrations demo take you through the basics and are incredibly useful both as tools for selling the framework and for getting a developer rapidly orientated.

Unsurprisingly, after spending a few hours with RoR, I broadly agree with the answers that Adrian Holovaty and DHH gave to the question “What would you like to have in your framework from the other?”. Adrian said he would like the test support and DHH gave a nod toward Django’s admin interface. Well, I can confirm that the Rails scaffolding doesn’t really compete with Django’s ability to generate a first-approximation admin interface. I can also confirm that Rails really pushes the testing line in a way that is very pleasing to me. I’d say that Rails goes a bit beyond that, however, in that it creates project layouts that feel — to me at least — far more like working robust development environments than the Django setup. A simple example of this is the default database config, which provides for a dev, test and production database as standard.

None of these points really make me believe that I’ll give up on Django, as many of these elements are already available to the user with the application of some expertise and effort. While I don’t have the expertise right now, and mostly can’t put in the effort, it’s only a matter of time before such features get subsumed into the Django framework. However, RoR does have one advantage that I wasn’t expecting and I think it’s a potential winning advantage in getting people to use RoR — RadRails.

RadRails is an IDE for RoR based on the much loved Eclipse IDE. When I first heard of it, I wasn’t that interested, as I was imagining another clunky Eclipse plugin and I was really looking for a simple tabbed text editor with file browser. My text editor of choice turned out to have buggy support for project directories and so I risked a download and discovered that RadRails was not a plugin and far from clunky. RadRails is based on Eclipse, but has been built as a standalone IDE. It feels bespoke, but retains the best bits of Eclipse and the familiar layout. RadRails provides access to Rails project directories, server (db and http), to the terminal and to the various RoR scripts via a simple form interface if the command line frightens you. To be honest, there’s nothing that RadRails does that is mind-blowing, but it’s solid, and it wraps the whole RoR development experience up in a way that makes it as polished a product as anything I’ve ever seen, commercial or otherwise.

Having an IDE that understands the way your framework is constructed makes everything easier. Sure, you may eventually decide that you prefer hacking in vi and command-lining everything, but when you start out, the IDE reassures you that you’re seeing everything you need to see. It allows a standard view of the development environment for purposes of marketing and for communication, particularly when supporting new users. RadRails sets a standard for tool support for frameworks that I hope others follow. More than that, I think they pretty much have to now, otherwise I think whatever framework “war” people think might be in the works is already over.