Blog

Last night was a great Groovy meetup at the Boats.com office here in downtown Vancouver. I got to use the new Burrard Bridge dedicated bike lanes, which is always fun, but it was the meetup content that I really enjoyed.

Yuri from Boats.com went through their experience of using Groovy and Grails for some real projects.

• Using Grails didn’t increase developer productivity, but it’s not the fault of Grails. Most of the holdups are non-technical – waiting for information, scope creep, redefining specs, etc.
• Many tutorials show you can whip up a CRUD application in 5 minutes, but he doesn’t know anyone in the business of writing CRUD applications. Real applications involve a lot more, and Grails is certainly useful, but it’s not a simple “grails generate-my-whole-app” command like some of the tutorials seem to indicate.
• There are lots of good plugins for UI elements, but you have to be careful to avoid Javascript hell. One plugin might use YUI, another might use jQuery, another might use Prototype, etc. If you’re not careful, your web page might suddenty balloon to over a megabyte just for the sake of some rounded corners and accordion widgets. Not really surprising, but just something to be aware of.
• Groovy and Grails add some layers of abstraction and they don’t come for free, so make sure your development machine has enough CPU and RAM (and especially disk IO speed, in my opinion) to handle it.
• Because Java is mature, there are lots of nice power tools available for code analysis, etc. Groovy/Grails doesn’t have much of that yet.
• Dynamic languages are cool and it was rewarding to try out.
• Advertising their use of Groovy/Grails helped attract talented people.

That last point was interesting. I had only thought about the stack from a technical/productivity point of view, but it turns out there’s a good human justification for trying it out. If you can bait people with shiny dynamic languages, it can pay off by increasing your developer talent pool.

Next, Andrew from SpringSource presented the Groovy plugin for Eclipse that they hope to release very soon. Here at 2Paths, about half of us are using Eclipse for Grails development and about half are using IntelliJ IDEA. Andrew walked through a demo showing off a bunch of work they’ve been doing.

• Support for lots of mixing between Java and Groovy. He declared a Groovy class in one file, then created a Java subclass in another file, and then a Groovy subclass of the Java subclass in a third file. Inheritance worked nicely and  the autocomplete magic appeared to be sufficiently magical.
• There’s some code inspection happening so autocomplete knows about things like the findBy* methods on your Groovy objects. Declare a Foo property on the Bar class and autocomplete will know about Bar.findByFoo() automatically. Lots of incremental compilation happening everywhere.
• Lots of improvements in communication between the Java and Groovy compilers. Apparently the old plugin managed the stub compilation with lots of temporary files, so it was constantly writing to and reading from the disk. The new plugin couples the two worlds better and does a lot in RAM, so it should be faster and not thrash the disk so much.
• A working debugger! Conditional breakpoints work, but you have to watch out for all the casting that happens under the hood when checking values. There are still some bugs in setting and removing breakpoints, but it looks good so far. Andrew talked about how he’s still trying to decide how much of the Groovy stack frames and object decorations to show. They show up in IDEA, so you have to wade through many incomprehensibly named caller levels between your own method calls, but it’s all there in case you really want to know.
• The plugin will be available from the same place on The Codehaus as the old plugin and it should be a standard easy install. Once they have something they can release, they’re going to throw it over the fence to be an open source project and encourage outsiders to contribute.
• They fiddle with the Eclipse compiling backend by patching in some behaviour that’s basically “if (groovy) { do new_thing } else { do normal_thing }” so the plugin will work with Eclipse 3.4.2 only. They’ve done a lot of testing to make sure their patch doesn’t hurt normal Java projects, but that version dependency could become frustrating.

Personally, I switched to IDEA because of the debugging support, which works well in both running the application and the tests. I said that we’re pretty evenly split between IDEs at 2Paths and we compare notes every morning in a contest to see whose tools are the most annoying. It looks like this new plugin may push Eclipse back a few points on the annoying scale. Good work, Andrew and company.

Tags: Grails, groovy

This entry was posted on Friday, July 24th, 2009 at 09:14:43 and is filed under Blog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.