5Tech - Week 2: Grails

For the second project and technology in five weeks I chose Grails.  I was very curious to try Grails on on a "real"/non-tutorial project to confirm its usability and productivity.  On my last contract gig, I was in a non-development role (configuration management) on a project that was using JSF 1.1/Spring/Hibernate and WebSphere, and their development looked really painful by my standards.  For example, they'd spend 5-7 minutes to redeploy the app just to inspect some HTML change in the JSF page.  I was looking to Grails to provide a much more productive environment.

The project involved creating a system to process events and route them to users.  It was inspired by a code base that I worked on for a previous client.  (This was done with their permission.)  They have a large code base that includes "application functionality" like this event routing, as well as a lot of "technical functionality" that they rolled themselves years ago before modern tools like Spring and Hibernate were created and became mainstream.  In a way, this was a small prototype to research the feasibility of reimplementing the application functionality on a more modern platform - Grails.

Analysis
All in all the project went very smoothly. Because Grails is comparatively mature, there exists a fair amount of documentation, including numerous books.  I leaned heavily on Grails in Action by Smith and Ledbrook.  I was able to follow their examples and adapt them to my application easily.  There just weren't any serious gaps or surprises.

Using Grails to create domain classes (database entities) was a breeze.  It's so nice to just declare the fields and their constraints and have Grails "do the right thing."  You don't have to bother with annotations, let alone XML configuration files.  Creating controllers to process web requests is trivial, and being able to scaffold them to get the basic CRUD functionality in place immediately was very conducive to high productivity.

I also liked the idea that services are a first-class concept in Grails (along with controllers and domain classes), which makes it very easy to program with them.   Grails wires them into the classes that use the services via Spring, but again, you don't have to monkey with Spring's applicationContext.xml file.  Finally, adding the REST interface for incoming events was almost trivial, especially since I already had the service in place.

Grails (like Rails) treats testing as a core concept, not something you wave your hands at after the fact.  It has the concept of unit and integration tests, and there are a number of functional test plug-ins, too.  I did a fair amount of unit and integration testing, which was a real live-saver.  Due to the very dynamic nature of Groovy, many of my typos were not caught in the compile phase, but exercising the code in tests did catch those.  I had very few issues when I ran the actual web application.

A lot of developers are unclear on the difference between unit testing and integration testing.  For better or worse, Gails makes some clear distinctions.  A lot of the Grails voodoo (e.g., dependency injection and adding dynamic methods to classes) is not available in unit tests, or you have to add it yourself via mocking or manual injection.  Thus, there is a simple distinction: if it runs under "test-app -unit", it's a unit test, otherwise it's an integration test.  This bit me once early on when I wrote a test that needed that higher-order functionality, but I put it in a unit test.  First I got a null pointer exception because the service hadn't been injected, then I got a missing method exception because the save method on the domain object hadn't been added dynamically. However, the fix was simple enough - move the test to the integration folder, and it ran fine with -integration.  Then, I copied it back, added a few mocks (very easy in Grails), and I had a unit test, too.

In terms of "project management," this step of the Five Technologies suffered from some "life happens" distractions.  Rather than running Monday through Friday, it ended up being Tuesday through Monday, and some of those days were a bit short-changed.  When I was on task, the Pomodoro Technique continued to be effective, and I replaced my dead watch/timer with a dedicated Android application called Pomodoro Tasks - it's even open-source.

In conclusion, Grails was another success for the Five Technologies in Five Weeks project.  I got the application functionality done that I expected.  Grails was very usable and productive - no nasty surprises.   What's next?  Probably, NetBeans Platform because I have documentation for it already whereas I'm waiting on some Android books.