Getting Groovy (and Grails)

Explorations in Groovy and Grails Development

Archive for the ‘gr8’ Category

Do you know Everything About Groovy and Grails? Gr8 Copenhagen Coming up Soon

leave a comment »

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 🙂

Advertisements

Written by peterbell

April 30, 2010 at 12:20 pm

Posted in Conferences, gr8, Grails, Groovy

gr8 conference in the US on Friday

leave a comment »

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!

Written by peterbell

April 14, 2010 at 5:56 pm

Posted in Conferences, gr8, Grails, Groovy

Getting Groovy: What’s Next after gr8conf?

leave a comment »

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!

Written by peterbell

May 21, 2009 at 7:04 pm

Posted in Conferences, gr8

The Gr8 Conference: Industrial strength Groovy

with one comment

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.

Written by peterbell

May 21, 2009 at 6:57 pm

The Gr8 Conference: Creating a Griffon Front End

with one comment

On the final afternoon of gr8conf, Jim Shingler provided an introduction to Griffon – a system for creating Java wing apps in a very Grails like way. Griffon is “a Grails-like Rich Internet Framework” and Jim did a great job of showing how to install it, create a hello world project and get it up and running in about 10 minutes.

He then proceeded to take the Twitter client that Graeme had created earlier during the conference and to provide a rich Swing front end using very little code. The project is still in the early days (it’s currently a 0.1.1 release), but it was extremely impressive to see just how quickly you could build an application using it.

Right now I have my work cut out with getting up to speed with Groovy and Grails, but if you have any interest in building swing apps I’d thoroughly recommend checking out Griffin, and I plan to find some time before next years conference to play with this and post some more thoughts.

Written by peterbell

May 21, 2009 at 6:27 pm

Posted in gr8, Griffon

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

The Gr8 Conference: The Grails Plug-in System – Plug in to Productivity

with one comment

After Graeme’s talk on building a Twitter clone in Grails, we took a short break and then returned to another presentation by Graeme – this time on the process of writing plug-ins for Grails. The core message of this presentation was that you don’t need to be a Grails guru to write plug-ins. Even if you’re just writing applications for your own use, you should consider using plug-ins to modularize them.

Grails Plugins
Grails is designed to wire together different libraries and to make them easy to use. Out of the box, Grails uses plugins: controllers, gsp, GORM for Hibernate persistence. etc. In total there are  10-11 plug-ins in the default Grails applications you get when generating them using create-app to provide the core grails experience. In this sense, Grails can be seen as a “platform for runtime configuration”.

There is a Grails runtime with the concept of a grailsapplication (with a class that models that), along with an application content and then a bunch of plugins. For example the quartz plugin (for scheduling tasks) actually adds a new notion called a “job” to Grails to the grailsapplication object. So you can extend the grailsapplication object.

The Extension Points:
There are a number of different extension points that you can leverage when building a Grails plugin.
Build system – additional command line scripts.
Spring application context – for sensible defaults and configs. Spring has concept of message driven beans that plugins can auto configure.
Dynamic method registration – Adding methods automatically to certain classes of objects. For example, GORM adds save, list, delete and other persistence methods to domain objects.
Auto reloading – for example the JMS plugin listens for change events to services and reconfigures message driven bean on changes.
Container config (web.xml) – Grails generates the web.xml. Can participate in the generation
Adding new artifacts – Can add new artifacts and artifact types. New concept like a job in quartz, or just create controllers (like the searchable plugin does).

What is a Plugin?
– Just like a normal Grails project
– The only difference is the presence of a <pluginname>GrailsPlugin.groovy file
– Use “grails create-plugin [plug-in name]” to create one – that’s it!

A plugin is just a regular Grails project and can be developed like one.
The plugin descriptor:
class LoggingGrailsPlugin {
def version = 0.4
def dependsOn = [core: “1.0 > *”]
}

Packaging your Plug-in
It’s also easy to package up a plugin:
grails package-plugin
cd ../my-project
grails install-plugin ../logging/grails-blog-0.4.zip
or remotely like:
grails install-plugin http://myserver/grails-blog-0.4.zip

Plugins and application modularity
Grails app plus . . .
– messaging, security, search, blog, wiki, maps, etc
All main app does is to provide a set of plugins

Adding Basic Artifacts
– A plugin can add new tag libs, controllers and services simply by creating them in the plugin project
– Since a plugin project is just like any project, you can just create and run one

Turning the twitter app into a plugin:
– Start by factoring out the domain into a plugin

grails create-plugin twitter-domain

Look at the TwitterDomainGrailsPlugin.groovy it creates

Copy domain to plugin and delete
Then cd into twitter-domain and grails package-plugin it

grails create-plugin twitter-iphone
grails install -domain ../twitter-domain/grails-twitter-domain-1.0.zip

add [dependson:TwitterDomain: “0.1” , iWebKit: “0.4”]

Note: When create plugin project, doesn’t auto install any of the grails plugins like Hibernate, so may need to grails install-plugin Hibernate – otherwise it’ll say “can’t find property “save””.

Note: dependencies are transitive, so install twitter-iphone, if it depends on iWebKit, it’ll install that automatically.

More advanced use cases (beyond the basics)
Can provide bean defs in def doWithSpring – e.g. setting “time to live” higher in production for EhCacheFactoryBean
See the Grails user guide for a description of the Spring Domain Specific Language
Plugins allow you to manipulate the underlying Spring context based on the environment, the conventions and the state of other plugins.

Can enhance behavior with doWithDynamicMethods to add to the application.domainClasses.each {} and then (for example_ domainClass.metaClass.constructor can be overwritten)
or add domainClass.metaClass.static.load = {long id -> template.load(delegate.getClass() , id)}
See the metaprograming guide on the Groovy website.

There are some issues re: template rendering and static resources in plugins, so they do require just a little more thought than an app – but not much.

Plugins already available
– Test: Selenium, fitnesse, code coverage, etc
– Rich Grails: Flex, GWT, GrailsUI (YahooUI), etc
– Secure Grails: Spring, JSecurity, OpenID, etc
– Integrate Grails, Search, Jasper Reports, JMS, etc

Check them out at http://grails.org/plugins – can comment, search, etc.

Summary
– Plugins are crucial to the grails story
– Everyone is a plugin developer – not just the gurus
– Plugins help to create modular applications
– Plugins automate configuration through convention over configuration

Written by peterbell

May 21, 2009 at 5:37 pm

Posted in gr8, Grails