Getting Groovy (and Grails)

Explorations in Groovy and Grails Development

The Gr8 Conference: Groovy Usage Patterns

with 7 comments

Most of the attendees at the conference would love to use Groovy or Grails for projects, but many companies are still in the evaluation phase. The question Dierk Konig tried to answer in his session was “what are some of the different ways you can introduce Groovy and Grails to client projects?”. He identified seven common patterns for introducing Groovy and/or Grails into projects: superglue, liquid heart, keyhole surgery, smart configuration, unlimited openness, house-elf scripts and the prototype.

1. Super Glue
Java makes a perfect infrastructure layer. With proven frameworks, widget sets and services it can provide a robust underlying layer for applications. Scripting can provide a more flexible and agile application layer on top of the infrastructure layer in Java for pulling together the capabilities of the frameworks into a custom application more quickly than if you were to use Java for the entire application. This approach allows you to build on the strengths of Java but to make it quicker/easier to use for developing applications. It also allows developers to leverage all of their experience in using Java frameworks.

2. Liquid Heart
This is almost the opposite of the super glue pattern. With the liquid heart, you have a well defined application structure developed in Java, but you use Groovy to implement fast changing business rules such as calculation rules for bonus allocations. By creating a clear bounded context, you can then use Groovy to more elegantly express a Ubiquitous Language for implementing the business rules in a particular area of the application. Good candidates for this are areas of the application with complex business rules that change frequently, making them a good candidate for a Domain Driven Design/Domain Specific Language based approach.

3. Keyhole Surgery
Sometimes you just need to be able to see what’s going on with your application and to be able to run code against it that you can modify without having to recompile the entire application. With keyhole surgery, you can create a back door for the live execution of Groovy scripts. This pattern is particularly useful for product support, failure analysis, hot fixes and emergencies.

4. Smart Configuration
If your team is concerned about writing application code in Groovy, often a good starting point is to use it for smart configuration, enhancing configuration with logic and replacing XML files with much more concise and expressive Groovy scripts. By having all of the power of a Turing complete language, you can often express the intent of the configuration much more elegantly and meaningfully than with large XML files.

5. Unlimited Openness
Especially for small to mid-sized green field projects, it can often make sense to go “all script”, creating an application that can be more concise and expressive, whether leveraging Grails or Griffon or just working directly in Groovy. The only proviso I’d throw out with this is that you need to consider the complexity of the application and the maturity and size of your dev team. Larger teams (really more than 3-5 people), relatively new to dynamic languages can get into all kinds of trouble by overusing dynamic language meta-programming features to the point where nobody on the team actually knows how the application works!

6. House-elf Scripts
If you want to get a quick win using Groovy, look at creating ad-hoc scripts. From build automation to installers, service monitoring, reports, statistics, automated documentation, functional tests, html scraping, web remote control, and web services there are lots of ways to get familiarity and to build comfort within your team by implementing these kinds of incidental scripts in Groovy.

7. Prototype
Sometimes you just want to do a feasibility study – a quick spike to try out a technology, UI or set of algorithms. Groovy, Griffon and/or Grails can be perfect for those kind of quick prototypes. And if you write them well there is no reason why you can’t either use them in production or port some/all of the parts of the application to Java down the line. For example, at Canoo, instead of a written RFQ they’ll often just build out a sample application to give the clients a sense of how it would work.

In addition, Dierk mentioned a couple new patterns he’s formalizing. The “lipstick” pattern is an increasingly common pattern of wrapping a Java API with a thin layer of Groovy to make it easier to work with and the “ghost writer” pattern describes the times when you use (for example) annotations and AST transformations to enhance a Groovy API by adding functionality using meta-programming.

The session really did a good job of providing a language for describing different ways of thinking about how to introduce Groovy and Grails into projects and hopefully we’ll be able to start to use this language within the community when describing potential adoption strategies to both give us more ideas on how to start to use Groovy and a more efficient vocabulary for sharing our experiences.

Advertisements

Written by peterbell

May 20, 2009 at 5:26 pm

Posted in Conferences, gr8

7 Responses

Subscribe to comments with RSS.

  1. […] an excellent write-up on what’s new in Groovy 1.6 and a summary of a session titled “Groovy Usage Patterns“, both by Peter Bell (the write-ups, not the […]

  2. This all is interesting, etc.
    But where is refactorings integration between Java and Groovy? Do you really think that I going to use Groovy as glue without ability, for example, to rename method or class in Java? Should I then manually change all Groovy code? No, thank you.

    Konstantin Scheglov

    May 24, 2009 at 11:26 am

    • IntelliJ IDEA has excellent cross-language refactoring capabilities, and a new Eclipse plugin is underway.

      Peter Niederwieser

      July 27, 2009 at 8:48 am

  3. this session sounds fun, thanks for posting.

    It’s interesting that Dierk does not mention using Groovy to test Java code. At one time, consultants/speakers were recommending this as an entry point into the Groovy world but it seems to have fallen out of favor in recent years.

    Hamlet D'Arcy

    May 27, 2009 at 10:01 am

  4. @Konstantin, I’m sure tooling will continue to evolve. If you don’t find productivity gains in using Groovy for your use case, don’t use it! My experience has been that the power and conciseness of a dynamic language is worth the cost of the lower level of IDE support, but it depends what you’re doing.

    @Hamlet, He actually recommended against it as he felt it was not a great approach to test in a language other than the dev language. That said, the other month at No Fluff Just Stuff, Venkat Subramaniam was suggesting Groovy tests as a great way to introduce the language, so I’d suggest you give it a try and see how it works for you!

    peterbell

    May 27, 2009 at 3:49 pm

  5. @Konstantin: That’s a matter of tooling. IntellijIdea for example has great support for cross-language refactorings like “rename method” between Groovy and Java not matter who is the caller and the callee and which side you use to start the refactoring on.

    Concerning testing, yes, I’m a bit vary about that. If you use unit testing as a design technique (like in TDD) than it make sense to drive your design from tests that are written in the language that you expect to be the user of you API – regardless of the implementation language.
    The Groovy project has Groovy unit tests for Java code, because we expect that code to be called from Groovy.
    If you use unit testing as a validation technique only then writing all your tests in Groovy is fine.
    Just as well, it is generally fine to write functional tests in Groovy.

    I hope that clarifies my point a bit.

    Thanks Peter for the great write-up!

    Dierk

    July 27, 2009 at 7:46 am

  6. […] comment » 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 […]


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: