Grails+Hibernate Slides from London GUG

The slides from my presentation on Grails+Hibernate at the London GUG (Groovy/Grails User Group) are available here:

http://skillsmatter.com/menu/341

Enjoy!

Grails making Java developers happy

Update: Even more great comments!

It is great when you get posts like this on the Grails user list. To go with all the other great posts about Grails:


"I just want to congratulate all the people who worked and are working
on Grails. I am new to Groovy and Grails but for me coming from Java,
it seems the way to go.

I saw a client last Thursday, he gave me the requirements for a small
application, I felt that I could manage to have a prototype ready
within a week with Grails, even without knowing too much about it
(almost nothing actually beside reading the articles and done the
"book" tutorial). I started to work on it Saturday morning, trying to
find my bearings all morning within the web documentation and the
"Groovy in Action" book. I started to write the domain classes in the
afternoon, got the CRUD pages working for 3 domain classes to my
satisfaction on Saturday evening. I worked on the page flow, business
logic and page layout most of the day Sunday and the prototype was
ready at 6PM on Sunday! Sweeeeeet!!!!

I just spent 3 months on a JSF-Spring-iBatis application that I could
probably have done in about 1 month with Grails. The "code noise
reduction" is impressive and the development cycle is very quick. I had
to restart the application only when I changed the domain classes,
otherwise it's a simple reload of the web page to see the change.

I am VERY impressed by Grails and the level of support that the team is
providing. Thanks so much to make that possible. Keep up the fantastic
work. I hope one day I will be able to help."

Skills Matter: New Job, New Direction

For those who don't already know (like the hoards that attended RailsConf), I have taken up the position of CTO at a company called Skills Matter.

Skills Matter specialize in training and skills transfer activities around Open Source technologies and this is actually how I got introduced to the Skills Matter crew. Yes, there are up and coming training courses about Groovy and Grails on the horizon.

Beyond that I'm also responsible for our further technical direction and training strategy. In plain english, what this means is that I'll be involved closely with the Open Source community to make training courses around a diverse range of technologies a reality.

In fact if you are a project lead of an Open Source project that you feel would benefit from a training course or are aware of a particular training need around Open source drop me a line.

A further implication of me being an employee of Skills Matter is that they have become an official backer of an Open Source project by allowing me to continue working on Grails when I can. All and all a win win situation!

Closures and Java: The Horror Story Begins

Previously I posted how it is too late for Java to include closures and it seems my fears have duly been confirmed. In a post on his blog Neal Gafter has already confirmed what we all knew already: that existing APIs won't be able to be changed to accomodate closures.

This is exactly what I said in my my previous post would be the critical problem with the closure proposal. So what do we get instead if existing APIs can't be changed? This is where it starts to become terrifying. Yes ladies and gentlemen we get the methods added to Collections accessible for a static import. I mean since when did Java become a functional programming language?

Neal presents the example as follows with the initial Java code being:

Droid seekDroid(Map map) {
    for (Map.Entry entry : map.entrySet()) {
        String droidName = entry.getKey();
        Droid droid = entry.getValue();
        if (droid.isSought()) {
            System.out.printf("'%s' is the droid we seek.%n", 
                              droidName);
            return droid;
        }
    }
}

This is fairly standard stuff made slightly better by the Java 5 for loop. Now to "optimize" this with the proposed closures we have the introduction of a new keyword specifically for looping in the for keyword:

Droid seekDroid(Map map) {
    for eachEntry(String droidName, Droid droid : map) {
        if (droid.isSought()) {
            System.out.printf("'%s' is the droid we seek.%n", 
                               droidName);
            return droid;
        }
    }
}

I mean how is this this better? There is hardly any difference in terms of LOC or code verbosity to the previous example. Not only that whoever thought closures were specially for looping has clearly lost the point. If you have to modify the language specifically to support one use case of closures that should be big ugly red flag waving.


Clearly supporting backwards compatability is going to be a huge stumbling block here and I fear what we will end up with is a botch job. Now just for comparison sake contrast the above example to the equivalent Groovy code:

def seekDroid ( map ) {
  def droid = map.find { droid -> droid.value?.isSought () }
  if (droid)
     printf ( "'%s' is the droid we seek.%n", 
               droid.value.name )
  return droid
}

Enough said really. Languages like Groovy and Ruby have closures at their core and they are not bolted on as an after thought. If closures are not embraced this way they will become more of an additional burden for the programmer to learn than something core to the language.

Needless to say the horror story doesn't end here, however, as let's take a look at the method that provides this feature:

public interface Block2 {
    void invoke(K k, V v) throws E;
}
public static 
void for eachEntry(Map map, Block2 block) throws E {
    for (Map.Entry entry : map.entrySet()) {
        block.invoke(entry.getKey(), entry.getValue());
    }
}

What can I say? That's about as clear as mud. Generics are bad enough as it is, but that is about as readable as a newspaper delivered in the rain. Implementing this method in Groovy would go something like this:

static eachEntry(Map map, Closure closure) {
     for(entry in map.entrySet()) {
         closure.call(entry.key, entry.value)
     }
}   

In my opinion, Sun need to carefully consider what they are doing here and whether it will cause more harm than good. It would be of more value for them to embrace dynamc languages like Ruby (which they are doing with JRuby) and Groovy than to bolt on something that has the bad smell about it that the current proposal does. They should be focusing on more important issues to Java such as decent desktop integration with Swing (which still fails to look and behave natively), shared VM on windows and other such well documented problems that never seem to get solved.

My 2c.

Grails Team Page, Podcast and Screencasts

It is really nice to see how the Grails community is really picking up recently. Thanks to Sven Haiges, one of our fantastic user community, we now have a weekly podcast just about Grails that has been running for the last few weeks. Sven has interviewed myself, Dierk and Guillaume over the last few weeks so its worth having a listen to the past broadcasts.

Sven has also taken it even further by producing the first Grails Screencast showing scaffolding in action. It is quite amazing that we have seminars, tutorials and presentations all centering around Grails written and delivered by the user community. It shows that Grails is filling a real void and even though we're only at 0.2.2 have found our niche (which may not always be a niche ;-).

We've also finally put together a proper team page so if you want to be scared take a peak!