Going off the Rails on a Groovy Train - Part 1

No, this was not an entry in the "Blog Post with the Most Puns or References of Ozzy Songs" contest.

Many of my colleagues are (as is a lot of the web development world) really high on Ruby on Rails. And I can understand why. Really cool Web 2.0 sounding statements like "convention over configuration" or DRY (Don't Repeat Yourself - which I just did by telling you what the acronym meant right after the acronym) are not just words, they're baked in to the way Rails operates. Rails makes the every day of web application development uber-easy. And heck, Ruby has closures which almost any legitimate scripting language really needs.

But I've always had some problems with Rails. Some of these are admittedly probably based on my fear of change, but the four most substantial ones are:

• Lack of libraries: to really make your life easier, a good scripting language or framework needs to have lots of libraries to do what you need. Ruby does have lots of libraries. But when I started trying to learn it, I had two needs, and I could not find libraries for either of the two. My Rails-uber-guru colleagues couldn't find them either. That doesn't mean they don't exist, but in Perl - you go to CPAN. In PHP, you go to the centrail PEAR repo. In Java, if it's not there already, Apache already wrote it. In Ruby, it might be on Rubyforge. Or there might be thirty of them hosted on various people's blogs - no telling which ones are bulletproof. This will get better with time.
• Lack of documentation: which is probably a legitimate complaint for anything FLOSS. And this goes hand-in-hand with the lack of libraries (or lack of a couple of de facto standard repo's). With Java, you know the doc is good.
• Inability to leverage existing work: For new applications, Rails is fantastic. But because Rails runs on Ruby, there's not (yet) a way for me to leverage my existing work in existing VM's without turning my existing work into web services (shame on me for not doing it right the first time - but did you?)
• Key exposure: Part of the convention over configuration theme turns into key exposure. URL's say things like http://server/blog/post/edit/832 - where 832 is the primary key field of the post I'm editing. Now, key exposure is not that big of a deal if 1) the key by itself has no meaning, which if you follow convention, it doesn't, 2) there's no SQL injection, which ActionRecord deals with nicely, and 3) you do permission checking for that object on every action - but that check is up to you.

That being said, Ruby on Rails is a really big and good step in the right direction. However, the first three items are killer for me - it doesn't matter if I can "scaffold" a really complex schema in 8.3 seconds if I'm going to spend 8 weeks writing my own XSL translator or re-inventing the toaster oven.

In the next couple of posts, I'll explain why I looked (back) into Groovy and why I'm (currently) geeking on Grails.