Joining the Ruby on Rails chorus

I tasted the Kool-Aid, and I liked it.

I finally got around to working my way through a Ruby on Rails tutorial, and was very, very impressed. If you don't have time to install Rails and follow along with the steps in the tutorial, at least do a quick read through Curt Hibbs' Rolling with Ruby on Rails article in O'Reilly's to get an idea of how easy it is to set up a useful application.

[Ruby on Rails logo]

I had the impression that Rails was about quickly building websites, but Hibbs' article showed me that it's more of a way to quickly build database applications with a web-based front end. And when I say "quickly", I mean really quickly. Once you define your tables, Rails automates the creation of screens and logic to let your application's users create, read, update, and delete data in those tables, and it provides clearly defined places to customize this behavior if you want to get fancier with your HTML, SQL, or Ruby logic.

I tried a Ruby tutorial a few years ago, but I had just begun using Python, and I stuck with it for the same reason I take up nearly any new language: there were all these great Python libraries (for reaching inside of Microsoft Outlook and Office, for manipulating RDF, and many more) that I wanted to patch together into new applications. Now Ruby has its Killer App.

Most discussions of Rails focus on its inroads into the high-end web development that many are doing with large, complex Java libraries. I can picture it also playing an increasing role in low-end database development. For example, picture someone whose computer knowledge is limited to basic Microsoft Office usage. I'll call her Brenda. Brenda needs to develop some sort of multi-table (and perhaps multi-user) database for her office. The obvious answer in the last few years would have been Microsoft Access; other choices over the years include dBase, FoxPro, Paradox, FileMaker, and other products that commanded portions of the PC database manager market before Microsoft steamrolled in. Now, Brenda has a free alternative that works equally well on Windows, the Mac, and Linux: Ruby on Rails. The most difficult part is the marketing message; how do you find the Brendas and get the message across? "Maximize your productivity and forget about J2EE", a traditional Rails marketing message, won't mean much to Brenda.

Hibbs' article is a little too Windows-centric, with its use of MySQL-front to do the database parts, which is a shame considering how cross-platform Rails is. Part 2 of his article includes the SQL code that you would enter at the mysql> prompt if you're using Rails on a Mac or Linux box. (If you're going install Rails on Ubuntu Linux, as I did, I found the weblog posting Ruby, Rails, Apache2, and Ubuntu Breezy by a Joe somebody to be very helpful.) If you're going to carry out all the steps in his tutorial, then before you start typing it's worth reading both part 1 and part 2 and skimming the comments to learn about a few caveats that will speed your progress when you actually get to entering the (minimal) code that the tutorial asks of you. (One more quibble: too much of the article's sample code is shown in screen shots, instead of inside of HTML pre tags, which would have let readers copy and paste it instead of rekeying it.)

Amy Hoy's Really Getting Started in Rails fills in some gaps in Hibbs' article, and her other articles listed down the left of that screen also look like helpful background.

Hibbs' more recent article AJAX on Rails demonstrates how Rails' ability to simplify the implementation of useful features has been applied to AJAX's use of XMLHttpRequest Javascript calls (or more accurately, to shield you from the need to deal directly with XMLHttpRequest calls) to update portions of your screen instead of the whole thing, making the client side of your apps more responsive. This article helped me to better understand both the mechanics of AJAX applications and the elegance of Rails' ability to incorporate those mechanics.