Getting Groovy (and Grails)

Explorations in Groovy and Grails Development

The Gr8 Conference: Using IntelliJ IDEA

with 3 comments

After Graeme was done, Vaclav Pech did a half hour overview of some of the many features available for working with Groovy and Grails in IntelliJ IDEA, an IDE from JetBrains.

Given that you typically use Groovy and Java together, the theme of the presentation was the importance of making it easy to go between the two of them and to provide a consistent experience between them. There were lots of nice features like the ability to run Groovy and Java tests together, the ability to preview interfaces, generate stubs for extending java interfaces, etc. It even has support for teaching the IDE about specific dynamic methods so if (for instance), you mix or even inject via AST transformations a particular method into an object at runtime, you get tell IDEA that the class will have that method at runtime and it will provide some IDE support for that. There was also support for various refactorings, the ability to do command line Grails operations within the IDE and so on.

There is no question that currently, IntelliJ is the premier IDE for working with Groovy and Grails (although it’s also clear that SpringSource is working hard to make the Eclipse experience more usable than it currently is). Personally I find that for ad-hoc work, using TextMate on a Mac is ideal, but I’ve already picked up a personal license for IntelliJ (in the scheme of things, if you can’t invest $250 in improving your productivity, you’re probably not charging enough for your code!) and am slowly working through learning all of the keyboard shortcuts required to become really proficient in an IDE. I can see that as I start to work on larger projects it’ll really help with productivity.

Anyone used to using an IDE with a statically typed language like Java or C# is going to get a little surprised when they see the limitations imposed by working with a dynamic language. For example, I can’t even reliably “rename method”, because in a dynamic language, you can concatenate a string literal with the name of a method and use that to call the method, so it isn’t possibly to reliably rename all method references. There are some possible approaches that help with some of the issues using dynamic as well as static code analysis (you have a running copy of the application and use that to introspect it) but for a Java developer it is going to seem like a bit of a change of pace (luckily I mainly program in dynamic languages so I have little sense of what I’m missing!).

It was a good overview of some of the capabilities of the premier IDE for Groovy and Grails development, although a number of people I spoke to would have preferred a slightly slower pace, cutting down on the number of features covered to give us a bit of a better sense of how to use the features. Nobody would expect to become proficient in an IDE after a half hour demo, but by (for example) showing some of the features using the menus rather than using the keyboard shortcuts, it would have probably done a better job of presenting the features of the tool even though obviously nobody would actually develop that way.


Written by peterbell

May 21, 2009 at 6:04 pm

Posted in gr8, IDEs

3 Responses

Subscribe to comments with RSS.

  1. Thanks, Peter, for the nice wrap-up. I see your point regarding spending more time with the individual features and not using the shortcuts so intensely. Although I’m not quite aligned with that idea, I’m glad you expressed your opinion. I’ll see what I can do for the next time.
    For now, the single shortcut behind most of the magic, like quick fixes, anonymous to closure, for to each, ternary to elvis, create method or class from usage, dynamic method definition was Alt + Enter. This is the shortcut to invoke context-specific popup with clever intention actions available.

    Vaclav Pech

    May 22, 2009 at 1:41 am

    • Hi Vaclav,

      The comment actually came from chatting with a couple of people after the talk who were both feeling that they would have liked a slower pace.

      It’s tough, because for existing IntelliJ users, they just want to see the cool new features, although I’d argue they aren’t the core audience (at least until upgrade time) as IntelliJ is clearly the best offering for Groovy/Grails so someone already using it isn’t likely to leave.

      Regarding people who *don’t* use IntelliJ, the question is whether you go faster to show more of the cool features or slow down a little to give them a better sense of how they can be done (not a tutorial, but maybe 20-30% slower focusing on the 70% of the most valuable/interesting features).

      That said, you can never find a pace that works for everyone and you covered some great functionality, so thanks for the great presentation, and hopefully I’ll see you again next year!


      May 22, 2009 at 8:25 am

  2. […] Last year I posted a fairly comprehensive series of articles on the blog (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) summarizing the content from Gr8 in Copenhagen. This year I opted instead to write an […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: