GR8Conf 2012: Torsdag i Danmark

The first ‘official’ day of GR8Conf. After some welcome words Groovy project manager Guillaume Laforge took the stage and introduced many new or not so new features of Groovy 1.8 and the upcoming Groovy 2.0. Since this came straight from the source, so you better check out Guillaume’s slides.

The Grails Hidden Gems of mrhaki showed us even more of, well hidden gems of Grails, actually. All the examples can be found on github.

A very interesting session by Luke Daley explained a scenario for testing with Geb, which is a browser automation solution, based on Page Object modelling. Of course this did rang many bells. We used to have something similar called TestFrame working for native MS-Windows applications. Such a Page Object based approach will consume quite some development time, but will certainly pay-off in regression tests and/or big applications. Another entry on our todo list.

Without trying to replicate the whole conference, there is still one session I attended on this first day I want to highlight. Andreas Aredal from Sweden plotted the Clean Code mantra of Robert C. Martin, better known as Uncle Bob Martin, on the Grails architecture in the Keeping your Grails Code Clean session.
Some of the Clean Code highlights presented by Andreas:

• The MODEL should handle business domain data and it’s domain logic … DRY with Named Queries and remember that these are chainable.
• The VIEW is for presenting data to the user (and only that) … Don’t put business logic here and use templates and taglibs for repeating stuff.
• The CONTROLLER is responsible for handling request flow … Services should do the heavy lifting and Command Objects should be used if a controller needs data beyond a single domain class.
• SERVICES should do the difficult and/of transactional stuff … Thus Services should never store state. Furthermore services are singletons and transactional by default.
• JAVASCRIPT should only be responsible for the behavior of your views … Learn jQuery but don’t use it for everything and learn Design Patterns.

Oh, and last but not least, not everything is a Grails component, so use plain Groovy or even Java classes when and where appropriate. All points are quite obvious when summarized like this; but so easy to slip out of our focus in day-to-day coding!

Finally Andreas dropped another entry on our todo list; Codenarc for static analysis of Groovy code, like in: put your money where your mouth is.