Getting Groovy (and Grails)

Want to know what you missed (or remember what you experienced) last month at the Gr8 conference in Denmark, Copenhagen? Check out the latest edition of GroovyMag which has a review – including interviews with the organizers.

It’s tough. Keeping up with a framework (Grails) on top of a fairly new, quickly evolving language (Groovy) which in turn is built using evolving frameworks (Hibernate, Spring, SiteMesh and via plugins Quartz, Lucene and many others) in a language – Java – which continues to develop (if only at a glacial pace). I notice on the mailing lists that even the top luminaries in the field are occasionally flummoxed by a question. It’s just not possible to know absolutely everything about Groovy and Grails. The good news is that while an individual may not know everything, as a community we know a lot more. The mailing lists are a good resource, but as the community grows you don’t always get an answer to your questions on the lists. What to do?

The answer for me is to do what I’ve done in every other domain I’ve been involved with – get involved with the community. (I’m relatively new to Groovy and Grails, but I’m pretty involved in the Domain Specific Modeling and ColdFusion communities). Helping out on the mailing lists and contributing to plugins is a great way to get started, but it’s hard to beat the face to face interactions you get at user groups and (especially) at conferences. That’s why I decided to go to gr8 in the US, am presenting on DSLs in Sydney, New York and (hopefully) London this month, and will be attending gr8 in Copenhagen next month (even though I can only manage a day as I’m presenting at the BCS SPA conference on DSL design on the Wednesday).

I was lucky enough to attend Gr8 last year. It was an amazing chance to get to know many of the key developers in the community, to build up a set of resources so that if we do ever get stuck on a technical challenge we can get on IM and often get an answer or idea from someone in minutes instead of hours or days of futzing around. Why do I mention this? Well, Gr8 conference is the only dedicated Groovy and Grails conference in Europe and a great opportunity to learn about a whole range of projects within the Groovy ecosystem – including Grails, Griffon, Spock, Gradle and Gaelyk. More than that, it’s a chance to meet up with other developers dealing with the same adoption, implementation and technical challenges that you work with every time you develop a Groovy based project.

There is still time to register for the conference, so think about how much it costs when you’re stuck on a project for a day trying to figure things out, and I hope you can get a cheap flight, a modest hotel and a ticket to the conference into the budget. It’s not cheap, especially with the market right now, but the only thing more expensive than going to the conference? Working on a project in Groovy/Grails and being stuck *not* having gone to the conference for the amazing technical content and great networking.

Hope to see you there! (If you see me, please say “hi”) – I’ll be the jetlagged one drinking too much Red Bull

I’m really looking forward to attending the gr8 conference in Minneapolis this Friday. I have been doing more and more Groovy and Grails projects recently and am looking forward to get to know the broader US community (the Copenhagen conference last year was great – but there weren’t that many US attendees).

I’ll be writing an article for Groovy Mag on the conference, so if you are presenting and would like to be interviewed briefly, I’ll be in the conference hotel Thursday evening and all day Friday (I’m flying back to NYC first thing Saturday) so make yourself known (a tweet to @peterbell is probably the easiest option) and I look forward to meeting you!

I had a great time at gr8conf earlier this week, and feel like I did a reasonable job of blogging a summary of the sessions (some more than others – sorry Griffon fans!) So, what’s next?

Well, I’m definitely going to be doing some more work in Groovy and Grails and I’ll continue to add my experiences to this blog (so remember to add it to your feed reader if you haven’t already!). I’ll also be posting some content on Domain Specific Languages that’s relevant to Groovy devs, and next week I’ll be doing a series on “Getting with Git” for Groovy/Grails developers who’ve noticed the trend and want to know how to kick their subversion habit and join us in the world of distributed vcs’s!

I had a great time meeting everyone at gr8conf this year, and look forward to seeing you all again next year!

Paul King presented the final session of the conference. He has worked on a number of fairly large, Agile projects using Groovy and Grails and wanted to share some thoughts on best practices for building large Groovy and Grails applications. (His slides are available online)

Topics
- Testing/mocking JUnit, TestNG, EasyB, Spock, Instinct, MockFor, Gmock, EasyMock
- DI: Spring, Guice
- Coverage: Cobertura
- Code STyle: CodeNarc, IntelliJ
- Duplication: Simian
- Documentation: GroovyDoc
- Builds: Ant, Gant, GMaven, Gradle, Hudson
- Modularization: Grapes, OSGi

Groovy
- Out of the box it runs junit3, junit4 (if in class path), testNG
- Check out GMock and also expandometaclass mocking in grails

Paul provided an introduction to the common testing and mocking frameworks including JUnit, TestNG, EasyMock and GMock. He also introduced Instinct – a test framework he’s done some work with, and then talked briefly about Spock and EasyB – two interesting frameworks for capturing and running functional/acceptance tests.

Spock vs EasyB
- Spock is a BDD inspired framework that gives devs tools to make their lives easier
- EasyB is a great way to capture requirements and build the acceptance tests
- EasyB scenarios can be stories, and can leave them blank to make them descriptive stories. Then start adding closure code and can put in selenium, etc

DI In Dynamic Languages
In static languages, Dependency Injection is almost essential to create testable code. Without it, hard coded references to “new” objects can’t be replaced (I suppose you could come up with work arounds using test-aware object factories, but really, DI is the way to go). In Groovy (and most other dynamic languages) there are a number of tricks you can use to get the ability to stub/mock out objects without using a DI framework. For example, the object.metaClass.Constructor can be overloaded to point to a specific instance or do something else, so you can get some of testability benefits of DI in Groovy without having to use Spring or Guice. That said, as projects get larger there are still real benefits to using a DI framework. Paul provided a quick overview of two of the most common Java DI frameworks – Spring and Google Guice.

He then went on to look at code coverage using Cobertura, suggested that 100% coverage is a “necessary but not sufficient condition” (I’ll agree that it’s not sufficient – whether 100% coverage of all of your code is necessary, I’ll leave for another time and place!).

He spent some time looking at the ability to enforce code styles with Code Narc (such as setting maximum lines per method or class) and some of the IDE capabilities of IntelliJ for improving the style of your code. His suggestion was that you should allow your code checking tool to break the build, but should only put rules you’re willing to enforce 100% – otherwise you’ll just get more and more warnings and genuine coding issues will get lost in the noise in the reports.

He also introduced a tool called Simian for checking your code base for duplication. It supports Groovy, is free for OSS projects, $99 (Australian) for a single user (with restrictions) or $499 (Australian) per project for larger teams.

He talked briefly about GroovyDoc (which for Java devs familiar with JavaDoc is pretty much what you’d expect), and then went on to look at using Groovy within Ant to script your Ant files, and using Ant within Groovy to fire off Ant scripts from Groovy. He also recommended Gant – a layer on top of the Groovy Ant builder (Ant uses XML config, so a builder is a natural way to script it in Groovy), discussed GMaven (a Groovy Maven wrapper) and Gradle which is focused on bringing the benefits of dependency management (think Maven or Ivy), but in a Groovier style.

Continuous Integration
An important part of any non-trivial project is CI – especially with dynamic languages where you have to rely more heavily on tests because the compiler catches many fewer errors. There are a number of different CI servers such as CruiseControl, Continuum and TeamCity (commercial), but Paul presented on Hudson which is my favorite as it’s free, widely used, and much easier to get started with and to configure than Cruise.

Hudson has:
- Gant plugin – Can invoke Gant build script as the main build setup
- Gradle plugin – Allows hudson to invoke Gradle build scripts as the main build step
- Grails plugin – to invoke Grails tasks as build steps
- Hudsons CLI and the Groovy shell – Have access to runtime in Groovy so can ask what plugins, what is state of info inside it, etc.

Paul also briefly discussed modularization using either Grapes or OSGi.

It was a great overview of the various elements of pulling together a professional set of tools for testing and building Groovy and Grails apps.

After Guillaume had provided us an introduction to Groovy, it was Graeme Rochers turn to introduce Grails and to provide information on the latest features in Grails 1.1(.1). Graemes deck wasn’t on the memory stick and I’m writing this on the ‘plane back to New York, so I’m writing this up from my notes and memory, so apologies in advance if I miss anything . . .

Graeme started off by giving us the number of downloads for Grails. In December of 2008, there were 86,000 downloads. To put that into context, Spring only got 90,000 downloads and Hibernate got 50,000 so while the penetration of Spring and Hibernate is clearly much greater, Grails is really starting to get some traction in terms of downloads. There are also now case studies for Wired, LinkedIn, Contegix, Tropicana, SAP and Sky (150 million visitors per month on six servers – and the eighth most responsive website in the UK, above sites like amazon.co.uk).

The main theme for Grails 1.1 is “making integrating grails into your ecosystem easier”.

Stand alone GORM
Firstly, GORM (the Groovy Object Relational Mapper – a productivity layer on top of Hibernate) is now available stand alone if you want to use it outside of grails applications.

With standalone GORM, you declare grails.persistence.Entity classes, so you might have:
package com.music
@Entity
class Album {
String name
Date releaseDate
static hasMany = [song]
}

And then you’d configure the settings using a gorm SessionFactory:
<gorm:SessionFactory
base-package=”com.music”
data-source-ref=”datasource”
. . .
</gorm:SessionFactory>

Plugin Enhancements
In Grails 1.1 there is now support for global plugins so you don’t need to install plugins for every single project if all of your projects use the same shared plugins. So you can now (for example):
grails install-plugin code-coverage –global

There is also support for transitive plugin installs. So, when you install a plugin, it automatically installs any dependencies of that plugin. Also, installing a plugin attaches metadata to the project, so if the project is checked out of svn/git, the plugins are auto-installed. There is also support for uninstalling plugins.

It’s also possible to scope plugins now, so (for example) you’d set your code coverage plugins not to run in production. You can scope plugins by environmen or by lifecycle and individual resources can also be excluded. It is also now possible to configure your own internal repositories for plugins. It is also possible to create direct links to plugin installs (rather than pulling them from a repository), supporting a workflow where you might be developing both plugins and your application simultaneously.

The core message was really that everyone should write plugins – they are a way to modularize your application and are very easy to develop. This was expanded on in a later presentation.

Testing Framework
In grails 1.0 there is little support for mocking out slow resources (such as database calls) for your unit tests. With 1.1 there is a mock api and framework for developing faster running tests. There is a mock implementation of GORM, controllers, command objects, etc. You “grails create-unit-test [name]“, and extend an artifact specific test harness.

Controller Enhancements
There are a number of controller enhancements relating to data binding, duplicate request handling and forwards/includes.

In terms of data binding, there are now more options for binding incoming request parameters to domain classes. For example, you can bind to collection types:
<g:textField name=”books[0].title” value=”the stand” />

You can also binding to a subset of properties:
person.properties["firstName","lastName"] = params

There is also now support for duplicate request handling (to stop users from submitting the same form twice):
<g:form useToken=”true” />
the withForm method then does the rest:
withform {
// good request
}.invalidToken {
// bad request
}

The current request can now forward control to another action:
forward controller:”home” , action:”index”

or obtain the response of another action with an include:
def content = g.include(controller : “home”)

View Enhancements
There is also now support for using JSP tag libs within gsp’s.

Project/Build Enhancements
There is a new api to discover the properties of the current environment. For example, you might:

import grails.util.*
assert Environment.current == Environment.DEVELOPMENT

And inspect project metadata:
assert “1.1.1″ == Metadata.current.getGrailsVersion()

Grails projects can now be Maven projects
mvn grails:create-pom
mvn grails:run-app
mvn package

Grails projects can also now be build with Ant and Ivy.

Additional Enhancements
There is now Spring namespace support in Grails. You can use any spring namespace in BeanBuilder:
xmlns aop:”http://www.springframework.org/schema/aop”
xmlns jee:”http://www.springframework.org/schema/jee”

Grails 1.1.1 now includes support for GAE. Persistence is via JDO/JPA using big table and there is a command line deploy. The process is something like:

grails create-app myapp
cd myapp
grails uninstall-plugin hibernate
grails install-plugin app-engine
grails set-version 1
grails app-engine package
APPENGINE_HOME/bin/appCfg.sh update .target/war

They are working on GORM JPA to make it work with app engine.

Graeme did a great job of introducing the latest enhancements to Grails in just an hour. If you want to know more about where Grails is going next, the roadmap is available at http://grails.org/roadmap.

After Dierks presentation, Guillaume LaForge was up next, providing an overview of the features of Groovy 1.6(.3). He covered a lot of materials – much of which is contained in his recent InfoQ article.

Introducing Groovy
He started with a brief introduction to Groovy. It’s a dynamic language on the JVM, it provides a Meta Object Protocol which allows for meta-programming techniques such as intercepting method calls. It compiles down to byte code, it’s an open source Apache licensed project and has a relaxed grammar derived from Java 5 (most Java code is valid Groovy code). It borrows ideas from other dynamic languages such as Smalltalk, Pyton and Ruby, has Java 5 features out of the box (annotations, generics, static imports, enums, etc) and with a flat learning curve for Java devs and the ability to run on the Google App Engine (check out http://groovyconsole.appspot.com), it’s really quick and easy to get started with.

Groovy is fully OO (no primitives, so you can add methods to numbers and write things like 1.day just like you would in Ruby), there is a joint compiler with the capacity for resolving circular dependencies between Java and Groovy code, it supports Closures, properties (no getters/setters required), optional typing and BigDecimal arithmetic by default for floating point numbers. There are handy APIs for XML, JDBC, JMX, templating and Swing UI’s, a strong ability for writing business user readable Domain Specific Languages, syntax level “builders” and it supports easy operator overloading (if you want to write 10.meters + 20.kilometers, for example).

It supports lists “def numbers = [1,2,3,4]“, maps “def map = [FR: 'France] , BE: ‘Belgium’]” and ranges “def allowed = 18..65″. It allows for regular expressions, and has GStrings which are interpolated strings which allow for placeholder variable replacements “Hello ${FirstName}”. Triple double-quotes also allow you to create multi-line strings without having to concatenate the strings as you would in Java.

One of the key features of Groovy is support for Closures. These are reusable and assignable code blocks (anonymous functions). So for instance, you could write:
def greet = {println “hello ${it}”}
greet(“Guillame”)

You can pass parameters to closures:
def greet = {string name -> println “Hello ${name}”}

and you can pass closures around:
def method(Closure c) { c(“Hello”)}
method(greet)

They take a bit of getting used to, but can provide a great deal of expressiveness in your code as you get the hang of how and where to use them.

One of Groovys other great features is a set of builders. For example, the following script uses a markup builder to generate HTML (it could also be used for XML):
def mkp = new MarkupBuilder()
mkp.html {
head {
title “Groovy in action”
}
body {
div(width: ’100′) { p(class: ‘para’) {span: ‘best book ever’}}
}
}
}

Groovy 1.6
After providing a brief overview of Groovy, Guillaume then went on to introduce the key improvements in the recently released Groovy 1.6.

Firstly, it’s faster – both at runtime and at compile time. groovyc tests 3-5 times faster than the 1.5 compiler and with advanced call-site caching techniques, he’s seen 150-460% increases in performance over 1.5 (although obviously your milage will vary).

There are also syntax enhancements with support for multiple variable assignment:
def (a , b) = [1 , 2]

def lat , long
(lat , long) = geocode(‘Paris’)

(a,b) = [b,a]

If there are mismatches in the number of elements, extra elements on the left just aren’t assigned to anything. If there are less elements on the left, nulls are put into the additional values on the right hand side of the assignment operator.

With Groovy 1.6 there is also support for optional returns in if/else and try/catch blocks. So you could write:
def method() {if (true) 1 else 0}

Groovy 1.6 also provides full support for Java 5 annotations. It is the only dynamic language to provide this feature.

Compile time meta-programming
Meta-programming is the ability of a program to modify itself. Groovy 1.6 adds support for Abstract Syntax Tree (AST) transformations, which should allow us to get rid of a lot of boilerplate technical code.  Groovy supports two kinds of transformations: global transformations, and local transformations that are triggered by annotations.

Out of the box, Groovy 1.6 comes with annotations such as @Singleton, @Immutable, @Lazy, @Delegate, @Nawify, @Category and @Mixin. Each saves you from writing a bunch of boiler plate code and allows you to more clearly express the intent of your code. You can also add your own global or local ASTs. It’s a technique you want to use sparingly as it would be easy to introduce hard to track down bugs where certain combinations of annotations introduced errors when they were used together, but it’s a great technique to have and something I’m going to be playing with and writing about more on this blog.

Guillaume also reviewed a number of other enhancements that have been added to Groovy 1.6. We now have Grape – the “Groovy Advanced Packaging System” which helps you to distribute your applications without having to include dependencies. You just declare the dependencies with @Grab and it’ll get them from Maven or Ivy repositories. @Bindable makes it easier to do data binding in swing, and the swing console application can now be run as an applet, has code indent support, script drag and drop and the ability to add jars to the classpath from the IDE.

The ExpandoMetaClass DSL is another new feature that I’ll be covering in more detail on the blog, but briefly, it’s a DSL for changing the behavior of types at runtime. There is also the support for runtime mixins:
JamesBondVehicle.mixin FlyingAbility

In addition, Groovy 1.6 had JSR-223 bundled, so if you simply can’t get through the day without adding a little Python or PHP to your Groovy, it’s supported out of the box. There is also a JMX builder available (http://groovy.codehaus.org/groovy+jmxbuilder). Finally, the Groovy 1.6 JAR contains OSGi metadata and can be used in OSGi containers (http://groovy.codehaus.org/osgi+and+groovy).

With only on hour to both introduce Groovy and provide an overview of the new 1.6 features, it was a high level presentation, but it was a great introduction to the language and provided a good overview of the latest additions to the language.

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.

Jonathan Felch is clearly an amazingly smart developer who has been using Groovy and Grails to solve some really interesting problems in the field of quantitative finance.

The most common languages in quant finance (which I know nothing about, so apologies in advance for any mistakes in this write up!) are C++ and VBA. Unfortunately it’s hard to write large, scalable applications in VBA, and in a world where new ideas need to be implemented very quickly and the vast majority of them are of no value, C++ simply isn’t fast or cost effective enough for trying out new ideas. Jonathan reviewed a number of different scripting technologies on the JVM and even the possibility of leaving the JVM, but in the end Groovy was chosen as the JVM is a great ecosystem for building enterprise applications, and Groovy integrates more deeply and thoroughly into the JVM (and specifically plays better with existing Java code) than other scripting languages like JRuby, Jython, Scala or Clojure.

The core objective of the application was to develop a framework that would allow for the quick development and analysis of potential quantitive trading strategies. For example, perhaps if a company has a large debt load with a small bond payment due followed by a much larger one, the risk of the company defaulting on the small payment might be overestimated using traditional models, providing buying opportunity for traders who could then pay a little more for those small bonds because they found out from historic data that the defaults on the initial bonds are lower than would be expected by the overall debt load of the company.

Jonathan and his team have to put together a system that would allow for quickly implementing reports that would show whether such hunches fit with historic data and whether it might make sense to use them as trading strategies for the bank.

There is a lot of essential complexity within the domain. With different calendars, different measures and a lack of truly unique identifiers (for example, bonds can have multiple ISINs over their lifecycle), there are a number of problems to be solved just to provide clean data for analysis. There is also a problem of storing and working with the data as there is a huge amount of information to analyze.

The system they developed was comprised of a Java core with a real time credit market gateway, a real time Bloomberg gateway for asynchronous response/requests, and EJB3 stateless session objects for accessing internal bank and third party databases. On top of that they built a Groovy/Terracotta data cache containing both the logic for calculating various reports, and a cache for storing the results of previous calculations. They also developed a Grails reporting front end with and HTML interface, JSON web services, Excel interfaces and a JMS gateway.

The interesting part of the system was in the data cache which provided chainable finders/builders so that if there was a cache miss, scriptable math within the builders would be fired off to pull and calculate the appropriate values. They also added a dependency graph for the calculated data to identify any results that had been invalidated by updated data or calculations.

One of the initial concerns had been whether Groovy (or any scripting language) would perform well enough for this kind of calculation intensive application. In the end, the experience was that the programming approach and algorithms had much more effect on the performance than did the underlying language and by using a smart caching strategy they were able to meet their performance goals in Groovy.

Unlike a traditional data model with all of the data represented in the database and (often) accessed through Hibernate, their system used tuples, with a wide variety of data sources (not just databases but also data feeds) being used to provide information and a combination of stored and calculated data being contained within the cache. Everything was decomposed into tuples that could implement map and list, allowing efficient operations in Terracotta.

It was great to see a real world case study of the use of Groovy and Grails – especially given the fact that it was an application where performance was so important. It was also a really good introduction to the way that algorithms are trending for dealing with large sets of data (I know map/reduce isn’t exactly new, but it was still interesting to get a glimpse of some of the architectural patterns they had used).

The session did spend a lot of time on the domain and perhaps it would have fitted better a little later in the conference after we’d been satiated by Graeme and Guillaume providing us the details of the new features in Grails 1.1(.1) and Groovy 1.6(.3) respectively, but it was definitely a thought provoking session that challenged a lot of the traditional thinking about the limitations of scripting for data and calculation intensive applications and that did a great job of showing off the benefits of Groovy and Grails for developing business applications on the JVM.

I’m just back in New York from the Gr8 Groovy/Grails conference in Copenhagen, Denmark organized by Soren Berg Glasius and Guillaume LaForge. There were seven speakers, two full days of content and just under a hundred attendees. I’ll be blogging about a number of the sessions in more detail, but I just wanted to blog some general thoughts about the conference.

Perhaps the first is that I’m still surprised that the only pure Groovy/Grails conference scheduled so far for this year is in Europe. I’ve seen a lot of interest in Groovy and Grails at most of the conferences I’ve attended this year – from the BCS SPA conference in London to No Fluff Just Stuff in Boston the other month. Even in the current economic times i’d expect there would be strong demand for a Groovy/Grails conference in the US. I was also surprised by the relatively modest size of the conference. I would have expected more than 100 attendees, so clearly we’re a little earlier on the adoption curve than I’d realized for Groovy and Grails development.

I think it’s going to be very interesting to see how Groovy and Grails evolve over the next couple of years. Given the number of Java developers, the benefits of dynamic languages and RAD web frameworks and the very shallow learning curve for Java devs wanting to get started with Groovy and/or Grails, I think there’s going to be a huge uptick in the adoption of and interest in the technologies over the next couple of years.

The conference itself was great. It provided a really good introduction to the core technologies and (more importantly) a chance to meet and network with a number of the key developers in the community – including Guillaume LaForge and Graeme Rocher – the project leads for Groovy and Grails respectively. I’m still fairly new to Groovy and Grails so I found the content valuable. I’d imagine that to keep it relevant to experienced Groovy and Grails developers, the next event would have to have at least two separate tracks to provide some more advanced material while still allowing for true “hands on” sessions to get beginners up to speed with Groovy and Grails.

Overall the conference was great – very well organized, so congratulations to the organizers for doing a great job and I look forwards to attending again next year! Now on with some more detailed reviews of specific sessions . . .