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.

Migrations
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.

Testing
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.

ActionWebService
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.

Ajax
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.

Deployment
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.

Productivity
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.

Cost
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

Deployment
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.

Knowledge
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.