harriyott.com

Saturday, November 11, 2006

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.

Books:





Links:

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

And here's a demo video:



[Tags: ]

2 Comments:

Anonymous said...

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.

Would you say that also follows for a more complex application?

Let's say you have a domain layer sat behind a web service facade because one day you'll be supporting third party organisations who, having shunned your beautiful web front completely, will be hammering your customer ID validation code with their own linux/mac/windows apps.

Like you, I haven't been spending enough time with the cool kids and I struggle to see how this kind of end-to-end code generation helps as systems get more complex.

I still haven't got a pragmatic feel for the balance between writing your own code and ceding work to wizards and code generators.

When Hunt and Thomas say "Write code that writes code" I don't think they're talking about the kind of black box code generation you describe here or that provided by VS.Net.

I was always a bit suspicious of the cool kids at school. I know that one of them was doing quite well as an accountant. About some of the others, though, I have my doubts.

November 13, 2006 1:00 PM  
Simon said...

Si, in my example that you quoted, I meant that because all the table and column names wouldn't follow the Rails convention that there would be extra work to get it to fit in with the framework. A large chunk of the benefit of using Rails would be missing, and so using the much more familiar .NET way would probably be quicker.

If you are creating a new application, I think the advantage comes in that the generation stuff provides a good head start, however complex the application is. If you're generating a lot of the ho-hum stuff, then it shouldn't be as complex anyway.

I should have said in my post that I wasn't necessarily advocating the use of Rails over .NET; rather I was showing the steps I went through to get a simple Rails thing up and running.

From my small amount of experience, I can't see too many problems with using Rails for your web service, except maybe performance, but Rails is good at scalability, so even that isn't a disaster. The cost of extra servers may be less than the cost of development that you might save by using Rails (if development is actually quicker!). If it's performance that's the issue, then you'd need do some load testing on comparable functionality in Rails and .NET to see if it is acceptable.

I'm all in favour of code generation - I use CodeSmith and the World's Simplest Code Generator quite a lot. If you use a generator for the basics and extend the generated code for the custom bits, it can be a lot quicker than coding things by hand, and more flexible than the black box stuff.

I still haven't got a pragmatic feel for the balance between writing your own code and ceding work to wizards and code generators.

I think it's gone too far when you don't know what has been generated, and how it works. If you can look at the code that's been produced, follow it through in your head and agree that it does what you want, then it's fine. If you can't, then you may (or may not) get into trouble. I think a tried and tested generator like Rails is a lot safer than some of my quick and dirty CodeSmith templates though!


When Hunt and Thomas say "Write code that writes code" I don't think they're talking about the kind of black box code generation you describe here or that provided by VS.Net.


I'm not sure that Rails is all that black boxy. Once the scaffolding has been generated, you can change it any which way. Given that Dave Thomas wrote a book about Rails, I think that he would advocate it ;-)

My advice is to try it with a small project, or follow some tutorials, and see if you like it. Thanks for taking the time to comment.

November 13, 2006 1:39 PM  

Post a Comment

Links to this post:

Create a Link

<< Home