magpiebrain

Just for a bit of fun, I thought I’d see how many of the people over on the Rails mailing list were actually getting to use it in their day jobs. Completely unscientific, and obviously a completely self-selecting sample group, but like I said it’s just a bit of fun.

The four questions I asked were, “are you using Ruby on Rails”:

1. As the primary development tool at your Day Job
2. As a small part of your Day Job
3. Not using Rails in your Day Job, but are using Ruby

1. For OS/outside work/hobby

   Of the 50 responses received in around a day an a half, here are the results (note: people could respond more than once – many people are doing it as both a job and a hobby as example):

2. As the primary development tool at your Day Job – 50%
3. As a small part of your Day Job – 22%
4. Not using Rails in your Day Job, but are using Ruby – 18%

1. For OS/outside work/hobby – 66%

   No analysis – this is deeply unscientific – but feel free to come up with unfounded claims as to how Rails is going to take over the universe or something – I’m sure the blogsphere will lap it up.

Rails, as you’ll no doubt be aware from the recent spate of blog-hype (sometimes so breathless in it’s praise that I fully expect some bloggers to keel over after choking on their own spleens) can be considered as a cross between AppFuse and NakedObjects, only for Ruby.

Like AppFuse Rails takes a series of technologies and with the help of some scripts creates a project for you in which most of the simple configuration and wiring is done for you. Like NakedObjects, Rails gives you a UI and persistence mechanism based on a domain model. Unlike NakedObjects Rails is highly flexible – you are free to change pretty much anything you want.

Initially the thing that makes you sit back and start to listen to at least some of the hype is the amount of work the helper scripts can do for you. Once you’ve created a DB table, you simply have to type:

ruby scriptgenerate model MyModel

To generate a persistable domain model and test stubs (I’ll talk more about the pattern used here later). Then you can generate the controller, with this simple command:

ruby scriptgenerate controller MyModel

Adding scaffold :recipe to the resulting controller dynamically enables all views required for CRUD operations for your Model. This can be shortened to:

ruby scriptgenerate scaffold MyModel

This does both of the above steps, and exposes all the scaffolding code inside your controller. For the most part, this code is there (in rails-speak) as scaffolding around your application. It’s there to get yourself started. As such you are encouraged (expected even) to edit virtually all the code generated for you – the obvious conclusion from which is that the generation steps have to be considered to be a one-shot deal. If you change the Rails version, you may now be required to edit much of your code by hand. This is by no means a fatal flaw – but when analysing the productivity gains of Ruby, the initial benefit of code generation should be seen as just that – an initial benefit. Rails will stand (or fall) based on Ruby itself – both its technologies, tools and workforce.

In Rails (well, ActiveRecord) you can support simple ordered collections fairly easily. Say I had a Post object, with multiple Comment objects, but I want to keep the Comment objects in order they were posted, where posted_on holds the posted date:

class Post "posted_on"

	
...

	
end

This has been a post on behalf of the just-letting-you-know-I’m-alive and the I’m-blogging-this-so-I-can-find-it-with-google-later parties.