Grails in public sites… framework case studies = gold dust

Two big public site exposés today for Grails.

First the write-up of the Wired.com usage of Grails for their product reviews site.

Next the blog post from LinkedIn.com developers talking about how they used Grails to rapidly develop and deploy a new product.

This is in addition to other sites such Sky.com’s sites. (Please note that I have NOTHING to do with the sky.com sites… people keep thinking I had something to do with them – I just blogged the announcement!)

Grails is being used TODAY in serious businesses with serious benefits. If you’re not using it yet, your competitors have the opportunity to out-code you by using it

Closure property conventions for events = anti-pattern

Having had an interesting time recently playing with flows and GORM events in a couple of Grails applications, as well as looking at some plugins like the Audit Logging plugin, I have some views to share on the use of Closure property conventions.

Background:

In Grails usually the first time you encounter the use of closures as property values is when you are defining actions in a controller, or constraints on a domain class.

This is a pretty good mechanism. It has some problems – regarding inheritance for example – but these are mainly for the “back end” framework code. It affords the framework more flexibility in the way it provide dynamic methods and properties, rather than just using the metaClass of the controller to do this.

The problems:

The difficulties with this approach start to show up with things like GORM events. If you try using domain classes with events in flows you start to discover all kinds of issues that are side effects of using closure properties instead of methods. In summary;

1. Inheritance is broken. In a closure property you can’t call “super” – so unless the framework provides a mechanism for it, the closure code cannot call the closure from the ancestor class. Frameworks have to also deal with this problem in terms of gathering up all the closures in the hierarchy and merging the results of them eg constraints in GORM – a special case where the code is DSL. This is a problem for more general code eg event handlers.
2. Serialization problems. The programmer will find out at some point that closure properties should not be serialized. This means marking the properties “transient”. Except that you then find that if you do this, after loading from serialized form, the event property is then null. So actually you have to flag it as “static” and not “transient” to get around this – which restricts what the closure can do. For GORM you also have to explicitly add these properties to the “transients” convention property to stop Hibernate trying to persist them. If you have plugins that expect other closure properties then you also have to mark these as static and in the transients list also. No matter that Groovy 1.6.x will support Closure serialization. You should never be serializing event code in normal applications.
3. Without reading docs you don’t know what “delegate” is in such a closure, and “delegate” does not read as well as “target” or “this” etc

So what I’m getting at is, I now strongly believe that using closure properties for “events” on objects is generally bad news. The best solution is good old fashioned virtual methods. These support “super”, have no inheritance issues, and no serialization issues.

For example the Audit Logging plugin uses closure properties for events on domain classes, and when evaluating this plugin I immediately thought “Hmmm will it be handling inherited handlers properly or not?” and of course there’s no info in the docs, and there would be code overhead in the plugin to support this – eg instantiating once (nonsensically) every domain class to evaluate its convention. This is something that Grails did (or still does?) do for services which causes all kinds of weirdness if you expect your service to only instantiate once in an application.

Furthermore in GORM, are inherited beforeXXX events on GORM classes called if you define a new one in a descendent? These are the kinds of questions that crop up. You readily assume they will, but you don’t know until you try.

I’m hoping that in Grails 1.1 or soon after the beforeXXX GORM events will transition to methods to avoid all the problems relating to (1) and (2) in the above list.

I’m also hoping plugin developers will stop using closures for event handlers. I’ve done it myself – in the Authentication plugin – but here it is a different case. The events are stored in a singleton map and are meant to be mutable and set by the application. There are no inheritance issues, nor serialization gotchas.

Death to per-instance closure properties for event handling!

Google Latitude / musings on behemoths vs small services

I found out today about Google’s new Latitude service. This is basically a “where are my friends” application that uses position information from your phone to update their central servers, and people who you grant access to your location info can see where you were (not are – depends on when you report in!).

Now this is particularly interesting to me as I have a fairly well developed idea for such a service, and had begun implementing this using the iPhone with a custom iPhone application (and of course a Grails application for the back end).

My immediate thought was “phew! Glad I didn’t spend any more time on that. Note to self: check own ideas for ‘behemoth trouncing risk’ in future”. Not to mention some relief that I wouldn’t have to implement the service myself now Google has “done it”.

However, then I started to think a little more and looked at their offering a bit closer – as much as I can with nobody using it and no iPhone support yet.

This made me realise a few things:

1. The behemoth does not always get it right, or rather tends to cater for the very high volume use-case which is not necessarily where the financial gain is to be mad
2. I have not seen their phone app yet, but I am wondering if it will have the right “drop dead simple” UI it requires
3. The behemoth when trying to handle the generic mass-market use cases, can not always create the seamless and simple UI required for users to love (and continue to use) a service
4. Most importantly – this kind of usage is not, in my view, what this technology is best for. I think the money to be made here is on smaller groups of users, and users in specific organisations.

Sure Google will have some plans further down the pipe – I’m sure an API will come (“Show where you are on your blog”, “Get location of friend X” etc). Its also surprising they don’t have an iPhone app (rather than an iphone customized web site) for this already.

However I think there’s a fair bit of money to be made with such a service that focusses on making sure parents know where their kids were when they said they’d check in, and for small-scale logistics for companies. The application UI -has- to be top-notch, and the functions it provides have to relate to the market place. There’s possibly a couple of different client apps that could be made to front the same back end.

So if you’ve got a some spare cash and want to fill what I believe remains a gap in the market, drop me a line and I can flesh out the ideas for you

Snow at the Grails Shack

We had some snow today – not enough to sledge in, but enough to make you go “ahh”.

It looks good on the “Grails shack” where I work during the day for my clients and churn out Grails plugins as part of Grails Rocks (what is it? Who knows at the moment) the rest of the time… not including the times when I’m sitting next to my wife in the house working on my laptop instead of being with her, an unfortunate consequence of Grails enthusiasm.

The “shack” is built out of green oak pulled out of a local river, green larch from a local saw mill, cedar roof shingles and some standard pine timber by a local artist called Denius Parsons. I’ve been in it for a year now. I’ve still got to paint the window frames and do some work on the internal floor but… its -2C outside and snowing, and with the killer insulation I need a 400W electric heater on only occasionally. It did the -8C in January without wind/damp fine, felt warmer than today with the -2C and snow.

It’s a lovely place to work, thank you Denius!