We strongly believe in using the right tool for the job. While we currently think of Rails as the de facto choice when it comes to writing webapps, we’ll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.

Lately I’ve been looking for a chance to play with Grails. Briefly, for those who aren’t familiar, Grails is a web framework that uses the Groovy language – an agile, dynamic language designed for the Java Platform. Grails was meant to use some of the main tenets of Rails (convention over configuration, “Don’t Repeat Yourself”, et al) while using Java web technologies like Spring and Hibernate.

Fortunately, I was finally able to find a chance to play around with Grails – as a simple way of “porting” an existing Java web application to a dynamic language and framework. My reasons were the following, which I’d imagine are true for many other Grails developers:

The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp. For example, I was able to take a terse image generation function and drop it right into the project.

Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base. Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.

The previous point applies to the interface code as well – the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.

Moving from another Java framework to Grails requires less of a “sell”. A Grails project packages as a WAR file no different from any Java project. It will have all the positives (and negatives) of a Java app.

So, having used Grails a for a while now, how does it stack up to Rails? Here a few of the things I enjoyed about Grails:

The GSP tags have the power of JSPs, along with a few features that make them simpler. They’ve also added some tags that don’t have equivalents in JSP, and are quite nice. In particular, I liked using the “sortableColumn” tag, which generates columns in tables that handling sorting. This is something I would like to use in Rails.

Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.

By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages. In some ways it’s nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.

As well as some caveats (I won’t go so far as to say “problems”):

Grails uses some different terminology than Rails. Models are “domain classes”, validations are “constraints”, and so on. Not much of an issue, but it may take some getting used to.

The form helpers in views are not as sophisticated as Rails. Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.

Of course, there’s nothing that Grails does that couldn’t be done in Rails with a bit of extra code or a plugin, and I’d imagine for the most part this is true for Grails as well, so it’s really more about simplicity and core conventions. I’m still working on the port, so I’ll be sure add updates as I get more experience.

There’s a lot going on in the world of Rails these days. This is great for developers, but sometimes it can be difficult to keep up with all latest happenings in the community. In addition to changes in Ruby 1.9 and Edge Rails, there’s a constant stream of news with regards to well-known Rails projects, emerging plugins and development/coding strategies.

Below are a few resources I use to stay up-to-date without experiencing information overload:

RubyFlow.com - This relatively new site is a great way to quickly see daily Rails news. It was built by Peter Cooper (author of Beginning Ruby and the blog Ruby Inside). Anyone from the community can post links on the site, or comment on posts. I find myself visiting here multiple times per day to get a quick sense of what’s happening and to make sure I haven’t missed any important news.

GitHub - In addition to being a public git repository, GitHub has become a developer social network of sorts. By following projects that interest you (including Rails itself), you end up with a single place to view all the commits that have happened on your projects.

Twitter – For the twitter users out there, there are a few options. First, there’s a user called rornews that you can follow, which posts links to Rails blog and job postings across the web. You can also follow a number of members of the Rails community who are on twitter, including Obie Fernandez, Geoffrey Grosenbach, Ryan Bates, and why the lucky stiff (side note: anyone is welcome to follow me on twitter as well!). Finally, you can consider using the tracking feature on twitter to follow “rails” or “ruby on rails”. This will give you a lot of updates, but if you’re willing to sift through it you’ll probably learn about news almost as soon as it happens.

Shared Feeds – I really like shared feeds (also called link blogs) as a way to see the best content filtered through a trusted source. A few feeds to check out include Obie Fernandez, Geoffrey Grosenbach, and what appears to be “Matz” himself. Or rather than following a single person, you try tracking searches for “rails” on FriendFeed or RSSmeme.