Lab test: Climb aboard Ruby on Rails

The Ruby on Rails site bills its eponymous project as "Web development that doesn't hurt." I'm not really sure what that means, but it certainly sounds good.

Further down on the page, it says, "Rails is a full-stack framework for developing database-backed Web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a Web server." That's almost true.

On the Rails download page, after some basic installation instructions for installing Ruby, RubyGems (the standard Ruby package manager), and Rails, as well as some terse hints about how to get started, there's some advice about Rails editors: "The entire Rails core team is using TextMate on Mac OS X. It's a fantastic editor that ships with Ruby on Rails highlighting and macros. If you're not running Apple, check out RadRails. It's a cross-platform Rails editor built on top of the Eclipse IDE."

The Rails team never tries to disguise its enthusiasm for Mac OS X, but it has given short shrift to developers who prefer other platforms -- so let's amplify the Rails Editors and IDEs story a bit.

Something for everyone

I have personally used three OS platforms for Rails: Linux, OS X, and Windows; a fourth supported OS is Solaris. There are four Ruby VMs that can run Rails: plain old Ruby, JRuby, Rubinius, and IronRuby. I have done all my Rails development on Ruby rather than any of the alternate VMs. Your intended development OS will likely constrain your choice of editor. If you are hell-bent on using JRuby, Rubinius, or IronRuby, that could also limit your choice of editor.

Test-driven development is very common in the Rails world. When you're developing a Rails application, you typically start by doing some code generation, using a number of handy shell scripts. Once you have a skeleton application, you typically build it up incrementally by adding and coding models and actions, adding and coding tests, running and debugging the tests, refactoring, adding Embedded Ruby pages to generate HTML views, testing the HTML display in a browser, and viewing the server log. If you need AJAX, many actions and effects can be generated entirely from Ruby, but more complicated or uncommon effects usually require some coding and debugging in JavaScript.

In the course of all this, you'll find yourself constantly moving among the test, model, controller, helper, and view code, and popping among editor, browser, and shell windows. An IDE and/or some editing shortcuts can cut down on the amount of time you spend popping around.

When it comes to code editors, one size does not fit all. It never has. Even in the early days of the ARPAnet, not everyone who programmed on the PDP-10 used TECO; later on, Unix developers argued fruitlessly about the relative merits of emacs and vi. Emacs and vi (or xemacs and vim, if you prefer) are still options, by the way: Both have plug-ins for Ruby and can be used effectively for Rails development, along with a browser and a command shell. Other editors that can be used for Rails in combination with a browser and a command shell include SciTE, SlickEdit, and jEdit.