Ruby on Rails

Well, the new job is a web startup that uses Ruby and the Ruby on Rails web development framework. So far so good. I generated a cheesy little app earlier this week.

Ruby is a scripting language that's sort of like a well designed, objected-oriented perl. Rails is a framework that stresses convention over configuration. This is orthogonal to the current Java and .net frameworks out there. Configuration of a Struts application, for example, is a pain in the butt. Yet Rails accomplishes the same task with almost no configuration. The reason is that with Rails you're expected to lose your ego and follow a few pretty reasonable conventions. For example, all table names are expected to be plural, such as "customers." All tables are expected to have an auto-increment column called "id" which is the primary key. When you follow the conventions, Rails generates workable web pages and Ruby code that create, edit, delete, and update rows in your database. The code produced isn't just hard-coded glop, however. It's reasonable Ruby code with plenty of hooks in it for inevitable real-world modifications.

Most web pages aren't too involved. They really come down to getting data from a database and displaying it and updating data that is already there. At my previous employer, we used an ancient VB3 application to making changes to reference tables (states in the country, transaction codes, etc.) While these rows didn't change often, when it did it was a pain in the butt. The application was flaky and didn't update all the reference tables. Due to auditing rules, we had to jump through hoops and otherwise waste a lot of time to use SQL in production. And there was no time to rewrite applications that were for internal use only! The end result was an permanent time-wasting application that was using obsolete technology, was buggy, and was a partial solution. Rails would have generated the bulk of the application in about 5 minutes.

Now, there are some complex web pages out there. I have not yet done anything really complex in Rails. So the jury is out regarding how much of Rails is just hype. I recall the hype surrounding Visual Basic. The demo was always a rolodex, and it went together quick. (insert oooos and ahhhhhs from the PHBs) Then, after the purchasing VP and his VP pals went out to a victory lunch, the programmers would figure out that when you got off the beaten path, the application framework collapsed and had to be entirely coded by hand anyway.

Here's some particularly egregious Rails hype:

[Rails] was super productive and it was super fun, too! A community of contributors grew up around it to make it even more productive and more fun! Rails has been growing fast. It has capabilities that you have to see to believe!!!

And in the same page, there's a little play, where the savvy programmer shows off in front of the boss:

Boss: Hey, CB ... you say it [Rails] lets you produce code like ten times faster than the tools we're using now?
CB: Yep. It's called Ruby on Rails, and it's at least 10x.

The web is full of statements like this. Maybe they are true. But such too-good-to-be-true comments make me very wary. I've been around the roundhouse a few times!

Here's the article. Actually, if you want learn a little about Rails, it's really good, cheerleading aside.