Simon Harriyott

Ruby on Rails for .NET developers

As a .NET developer, when it comes to development, I sometimes feel a little bit like the PC in the Apple adverts. I see trendy web 2.0 apps written in Ruby on Rails and feel just like I did when I was at school - one of the square kids. But hey, you can write webparts for SharePoint in .NET. Quite.

So, given that the cool kids in my school were thick as milkshakes, I thought I'd look into it. Here are my observations after about two or three hours of trying to hang out near the cool kids hoping I look like I belong.

My first misconception was that I would have to spend ages setting up a different OS like Linux, or buying a mac (which I still would like to do one day, if I'm ever cool enough). Not so, there's a Windows package called InstantRails that just does it. Download the ~ 60Mb zip file, unzip it, and you're ready to go (just like a Mac). This gives you Ruby, Apache, MySQL and PHP. Start it up by launching InstantRails.exe.

There's an initial dialog box that needs slapping out of the way, and then I had to change the port Apache uses, because IIS already uses port 80. I randomly picked 100, and it seemed to work. One can change this in the config file that is accessable from the Instant Rails menu.

One of the things that makes Rails so quick is using conventions for naming, rather than using configuration files. What that means in practise is that your MySQL table names (your MySQL? YourSQL maybe?) have to be plurals, e.g. rabbits. Rails can then sort you out a nice Rabbit class without any bother. Also, the ID column must be called id, so Rails knows it's the ID column. Foreign keys take the format "tablename_id", so the rabbit table might have a foreign key to the hat table hat_id. Simple really. If you've been lumbered with a honking great legacy database, you can still configure it up to use it, but that kind of defeats the object. You might as well go back to C# for that, at least you know how to do that.

Another good thing about Rails is that it enforces the model-view-controller pattern right away. When you create an application, "models", "views" and "controllers" tables are created automatically.

An application is created using a single statement on the command prompt. You should then add your (plural) tables to MySQL. You'll need an Enterprise Manager equivalent for that. I found HeidiSQL to be both suitable and fashionable-sounding.

The next thing to do is to generate some classes. One can "scaffold" these, which seems to mean that it will create default pages for one's CRUD operations. And a listing page. There are two ways of doing this: the first way is to generate the classes "normally", and put a scaffold statement in the controller, and the second is to generate the scaffolding, which puts a load of code in your MVC folders. This is quite useful, as you can see what Ruby actually looks like, and play around with it a bit. To generate the scaffolding from the command prompt, type

ruby script\generate scaffold rabbit

[where rabbit is the singular of your table name]

You should then be able to go to localhost:100/rabbit and see a list of all the rabbits in your table, and links to add, edit, modify and delete rabbits. Now that's magic.

Now you've done that, you can have a bit of a poke about in the code, and change stuff. To change what the page looks like, go to the view. It's a little like "classic" ASP, in that there's code and HTML jumbled up together, but the difference is that the code should only be accessing data from the model, and not doing anything beyond formatting it.

So, there we go. I've created a cool rails app in next to no time. You don't have to be particularly cool to do it, as I've just proved.



Ruby on Rails Home
Instant Rails
A proper tutorial
Ruby Language Reference

And here's a demo video:

[Tags: ]
11 November 2006