The blog of Rahoul Baruah from 3hv Ltd

What's going on?

My name is Rahoul Baruah (aka Baz) and I'm a software developer in Leeds (England).

This is a log of things I've discovered while writing software in Ruby on Rails. In other words, geek stuff.

However, I've decided to put this blog on ice - I would ask you to check out my business blog here (or subscribe here).

03 July, 2006

Why you should use Ruby on Rails

It's happened. I'm finally being held to account for using a "non-standard" development tool and I need to justify myself.

So, in preparation, here are my arguments.

In favour of Rails

Active Record
The reason I looked at Rails in the first place. The simplest way of mapping database tables to objects I have found. And the lack of verbose XML configuration files (and Ruby's dynamic nature) means that getting started takes little time and handling changes is a breeze.

By defining your database schema using Migrations you can switch between database environments relatively easily (as long as you are careful about your use of find_by_sql). In my case, many of our smaller clients have difficulty with the idea of buying SQL Server licences on top of our own licence fee. Rails would have made that a non-issue as we could deploy as easily to MySql or PostgreSql.

Create a model and Rails creates a unit test. Create a controller and Rails creates a functional test. I've not looked at integration tests yet but I'm sure I will make heavy use of them soon enough.

In many ways this is the part of Rails that gives me the most grief. Plus DHH and the other core Rails developers are obviously pursuing REST strategies (like ActiveResource). But, in a .Net and Delphi world (as I am), SOAP services are the simplest way to talk to everyone else. And, of course, it is fully testable.

Yes, you easily integrate one of the many AJAX libraries out there into your own code, but Rails makes it nice and easy. And with RJS it's extremely powerful without actually having to do any Javascript.

Test Fixtures and the entire testing framework
So far, nothing that has been mentioned could not be done by downloading the appropriate libraries for .Net. But that does take some effort. Plus, once you have written your unit tests and your functional tests (that are probably intermingled unless you were disciplined enough to separate them out at the outset), you need to then write some sort of script or routine to take your development database, copy it, fill it with known sets of test data and make sure that your tests run against this. Oh, and don't forget to make sure that any emails generated are not actually sent out. Or you could just type 'rake' and have it all done for you.

Ruby's dynamic nature
Scaffolding makes for a great demonstration. But my favourite Rails example is Person.find_by_first_name_and_last_name_and_email_address(first_name, last_name, email_address). That's a large chunk of your applications requirements automagically given to you by Rails without even thinking of Sql.

We have a choice of deployment environments. Our own hosted servers running IIS (with some help from RForward) and SQL Server. Cheap, managed, hosting on Linux with Apache and MySql. Dedicated hosting on FreeBSD using LightHttpd and PostgreSql. Macs. Oracle. DB2. Choices, choices, choices.

Because you are not repeating large chunks of code ("I've just added three new fields to the table, so I have to add them the stored procedure parameters, add the properties to the data-access object and add the properties to the business logic objects" versus "I've updated the migration and added a unit test"). Because the code is designed to read like English you can get on with your work with less syntax to get in your way (compare "DateTime tomorrow = DateTime.Today.AddDays(1);" to "tomorrow = 1.days.from_now"). Because Rails is designed to do, and optimised for, database-driven web-sites and nothing else - it's not jack of all trades and master of none.

Confidence, Iterations and Change
Rails, being an agile development environment, expects that what you deliver will actually be significantly different to the original requirements brief. Because all the testing, fixtures and so on is built-in so deeply into the system, it becomes easy to follow agile practices. Decide on a small iteration of functionality. Deliver it. Get feedback. Change it. Refactor. Decide on the next iteration. Repeat. This makes job costing, on the way in, difficult but significantly boosts customer satisfaction, on the way out.

Visul Studio express is free. But will it offer everything that you need? Is your machine powerful enough to run a massive IDE? I can develop on a 7 year old iMac using Textwrangler and Terminal. Or on a 5 year old Win2K box using Crimson and the Command Prompt. If I need any extra tools they are a free download - normally a Gem.

Against Rails

FastCGI is complex. RForward is immature. Rails wasn't really designed with Windows in mind, although I have proved that it is feasible.

Green Fields
Rails depends upon convention. That's what makes it so easy to use. However Rails can make life difficult unless you are working on a brand-new application. It is possible, just not as easy as it could be.

Until a few months ago I was the only person in the organisation who had even heard of Rails. Even now, I am the only one who knows about it in any depth. I have been told that we shouldn't be using obscure tools that no-one else was using. But we are Basecamp subscribers. Other Rails sites include 43 Things, A List Apart, Icon Buffet, Cork'd and many more.

ASP.NET Postbacks
Some would regard this as an advantage but it has to be said that ASP.NET is an excellent workaround for some of the shortcomings of HTML. It may suck bandwidth as the entire view state is passed back and forth, up and down the wire, but the programming model is extremely simple for VB and Delphi developers to understand.


Rodolfo said...

Very nice Baz!

It seems its time to justify everywhere! We are writing a Rails Defence document here on my job too, I'll post it my blog soon.

PS: And what about our teams, huh? I can't believe yet...

Xeno said...

also against:

scalability. 43things is the only site that has managed to scale RUBY and even so, they had to use 3 times the number of servers and resources as with PHP and they still have serious outages and downtime (hence the large number of backup servers). And to date,, and many other ruby sites still run PHP on the frontend to handle the bandwidth because RUBY can't; in fact, you can check by adding ?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 to the end of the URL. If no error is thrown or the PHP logo comes up... guess what? You're parsing a PHP page and not a RUBY page.

Baz said...

not sure I get you - Twitter famously does 11K requests per second on a Joyent Accelerator and 37s have never said they use Rails everywhere - (the promotional site) may be php but basecamp itself (the application) is not.

I'm sure that there are scaling problems with Rails but 90% of us will never ever have to deal with a problem on the scale of Twitter's and they reckon the database is their bottleneck now, not Ruby

Blogger said...

AvaHost is definitely one of the best web-hosting provider for any hosting plans you might require.

eXTReMe Tracker