When I first heard about Ruby on Rails late in 2005, I got very excited about it and was eager to learn more. Over the Xmas/New-Years break I purchased both the so-called “pick-axe” book (Programming Ruby, by Dave Thomas) and the Agile Web Developer’s Guide to Rails (by Dave Thomas and David Heinemeier Hansson).
I tried plowing through the Rails book, but while the text is clear and well-written, I quickly realized that in order to make any real progress I needed to learn as much Ruby as I could. Learning both at the same time was just too much. I therefore went back to Ruby, and after making progress on that, I eventually dug into Rails again. Since my primary skills are Java, J2EE, and XML related, I couldn’t spend full time on those topics, but slowly made progress over the first few months of 2006.
Eventually, I abandoned that effort. I’ve talked about it here in earlier posts, but the short answer is that I came to believe the Ruby (and Rails, even more so) is really just a niche product. While both are very interesting and helped me learn a ton of new concepts (Ruby especially helped my JavaScript when I got to Ajax), I don’t believe that the industry is ready to abandon its considerable investment in Java technologies so it can start rewriting everything in Ruby. Add to that the fact that Rails is great if you’re starting from scratch but very annoying if you’re not (especially if you’re stuck with a legacy database that violates Rails conventions and even uses — horror of horrors — compound primary keys), and it just didn’t seem worth the effort.
I also became rather disenchanted with the arrogance and even haughtiness of the Rails team, from DHH on down. I liked that they violated accepted conventional wisdom and made it work, but I got really tired of the superior attitude and unwillingness to acknowledge that not everyone has the freedom or interest in doing everything their way. In the end, I decided that (1) Ruby is totally cool and can do almost anything (see Enterprise Integration with Ruby and Ruby Cookbook), and (2) Rails has a lot of great ideas, but neither was really my future.
In the fall of 2006, I then had the great opportunity of attending a talk by Jason Rudolph, who is a committer on the Grails project. Grails, as it sounds, is a framework rather analogous to Rails, based on the Groovy language. The cool part, though, is that Groovy code compiles directly to the JDK, so it cleanly interoperates with existing Java classes. Grails itself uses Groovy in many places, but really gets its power by leveraging existing, well-established Java projects like Spring and Hibernate.
In other words, Groovy and Grails are perfect for me. I’ve therefore been trying to absorb them off-and-on for the past six months or so. It’s hard to dedicate contiguous blocks of time to them, but I keep plugging away at them. From my Ruby experience, I decided that the real key was to learn Groovy before trying to absorb Grails. Therefore, I purchased Groovy in Action (by Dierk Koenig and others) and The Definitive Guide to Grails (by Graeme Rocher), and also acquired Jason Rudolph’s book Getting Started with Grails. That latter book has gotten dated very quickly, but is still a lot of fun.
I’ve mentioned it here many times, but Groovy is seriously cool. In fact, pretty much every Java developer I’ve shown it to gets excited about it. Even silly, trivial things are great.
For example, to make a Java POJO that will be an entity in a database somewhere, I have to write a class like:
public class Employee {
private int id;
private String name;
private double salary;
// ... other attributes as necessary ...
public Employee() {}
public Employee(int id, String name) {
this.id = id;
this.name = name;
}
// ... other constructors as necessary ...
public int getId() { return id; }
public void setId(int id) { this.id = id; }
// ... all of the other getters and setters ...
// ... overrides of equals(), hashCode(), and toString() ...
}
That’s a fair amount of code for what is essentially a trivial data structure. Even though Eclipse can generate much of that for me, it’s still rather tedious and verbose, especially when you compare it to the analogous Groovy bean:
class Employee {
int id
String name
// ... other properties ...
}
That’s it. Not only don’t I need any semicolons (trivial, I know, but still kind of cool), but the attributes are assumed to be private, any required public getters and setters show up whenever I access or set a property, and any constructors I might need are already there, too. Truly sweet.
I can populate my Employee instance as easily as
Employee fred = new Employee() fred.id = 1 fred.name = "Fred Flintstone" // ... etc ...
which uses the public setter methods even though it looks like I’m accessing private properties. Actually, there’s an easier way.
Employee fred = new Employee(id:1, name:"Fred Flintstone", ...)
where I’m using Groovy map properties to populate the attributes, even though I didn’t write a constructor at all.
I can also do it this way:
def values = [id:1, name:"Fred Flintstone",...]
Employee fred = new Employee()
values.each { key, value ->
fred.setProperty("$key",value)
}
which looks Ruby-like and is also pretty cool. That’s still too complicated, though. I can also do this:
def values = ... // as above Employee fred = new Employee() fred.properties = values
That’s better, but I can even do:
def values = ... // as above Employee fred = new Employee(values)
using the map directly. The best part is that I can even write the Employee class in Java and populate in a Groovy script much the same way. How cool is that?
Groovy therefore simplifies Java dramatically. Its dynamic typing makes coding much simpler, too. Groovy is attractive for its Java simplifications, but once you dig into it, its closure support is exciting, but builders are simply incredible. There’s nothing better than being able to build an XML document by writing
def builder = new groovy.xml.MarkupBuilder
builder.employee (id:fred.id) {
name fred.name
// ... other instance variables ...
}
which automatically creates an XML file with all the tags, attributes, and text values automagically inserted. That’s unbelievably sweet.
On my current trip down here to Atlanta, though, I decided I’d finally read enough Groovy, even though I’m far from good at it. It was time to start digging into Grails again.
Grails is still evolving quickly, so every book I have is effectively out of date. Still, what I’ve seen is fantastic. I can’t wait to learn more, and, even better, start building some real sites with it. I’m also eagerly awaiting the Grails 1.0 release, tentatively scheduled for October.
I’d write more about it, but this post has already gone on way too long. Still, the more I learn the more enjoyable the whole thing is. It’s been a while since I felt that way about a programming language.
Leave a Reply