The Definitive Guide to Grails out in e-book form

After many months of hard graft, my book "The Definitive Guide to Grails" by Apress is available in e-form here. Thanks to all those that helped make it possible, and to those who do read it feel free send any feedback directly to me or post a comment. Cheers!

Why is Bruce Eckel arguing about typing?

In his article entitled "How to argue about typing", Bruce Eckel presents another argument against the downsides of Java's Strongly typed system. So let's analyze a few of the things he is most certainly right about:

• Checked Exceptions == Evil. No question.
• The fact that something like Eclipse generates code for you should not be an excuse for static typing. Code generation means duplication. In terms of DRY you are still repeating yourself whether it is generated or not. This makes code longer and harder to read.
• You shouldn't feel your system is more robust and "safer" because it uses static typing. This is a naive approach to development.

Ok, so that is the good stuff out the way. However, the problem I have with Bruce's article is that it again tries to turn the static vs. dynamic typing argument into, ummm.. an argument. Why are we arguing about this? In my view you should be picking the right tool for the job.

This is so fundamental. I mean both paradigms have their strengths and weaknesses, why does one rule out the other? Bruce's article implies the only benefit you get from static-typing is the knowledge that your application is checked at compile time for type safety, which represents a false sense of security anyway. Fundamentally, he says, all you're doing is testing, which you should have unit tests for anyway.

However, when I use Java I don't use it to feel "safe". I use it for the advanced code navigation, refactoring and analysis tools that you get in modern IDEs like Eclipse or IDEA. These tools are not just about generating code, they're about being able to easily maintain your codebase and allow it to scale in terms of complexity.

But, of course, Java is horribly verbose and is not suited to every task. In this sense I would say it is essential that every developer know both a dynamically typed and statically typed language so that you can use a blended approach to development. Getting the best of both worlds.

The thing is, in Agile one of the issues known to reduce productivity is task switching. If you are constantly switching between different programming environments that don't integrate seamlessly with each other you will become less productive. Fact. Also, if you can't easily integrate the two you will end up writing duplicate code for each platform, violating DRY.

This is the fundamental reason why I believe Groovy will be hugely successful. By integrating so tightly with Java and providing a seamless transition with the same APIs and object model it significantly reduces task switching and integration overhead.

My advice: Don't enter this debate. There is really nothing to argue about, choose the best tool for the job and use it. Sometimes that may be a statically typed language like Java, C# and so on other times it may be a dynamic language like Ruby, Groovy or Python. Choice is a good thing people.

Grails 0.3: Hibernate mapping has never been this easy

We've just put out Grails 0.3, which is a marked improvement over 0.2.2. Checkout this post for more info.

Possibly my favourite new feature of 0.3 is the improvements made to GORM, the ORM side of things that is built on Hibernate. It has become really concise. Defining persistent entities with relationships is as simple as:

class Author {
    static hasMany = [ books : Book ]

    String name
}
class Book {
    static belongsTo = Author

    Author author
    String title
}

Here we have a bidirectional one-to-many relationship. The 'hasMany' setting will inject a 'books' java.util.Set property into the class at compile time. Also injected are an 'id' property, and Hibernate's 'version' property to aid in transactions and optimistic locking.

GORM configures these classes as regular Hibernate persistent classes, but with a twist because Grails injects all sorts of helpful methods into them at runtime too. Such as those to manage relationships:

def a = new Author(name:"Stephen King")
             .addBook(new Book(title:"IT"))
             .addBook(new Book(title:"The Stand"))
             .save()

Here you create a new author instance, add two books to it and save it. In the background Grails is managing the relationships for you, making sure that both the one and the many side have references to each other and then through Hibernate persisting the instance with updates cascading to from the Author to each Book.

Notice how unobtrusive GORM is? No XML, no annotations clouding your domain model, just pure application logic that defines the relationships. And yet at the same time underneath it all it is still Hibernate, making it robust and enterprise ready.

This is of course only a small example, there are many more features of GORM such as all those dynamic finder and persistence methods. We have a lot more planned for 0.4, the next month is going to be fun. :-)

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!

Vote to stop Maven infesting Spring

The recent announcement that Spring will start using Maven exclusively for their build has sent horrors down my spine. Fortunately, I'm not the only one who feels this way with many blogs around the net spreading their dismay.

Maven, in my opinion, has caused more hassle than it is worth on two projects I have been involved in (Groovy and Cocoon) and I made a concious decision to avoid it when starting Grails.

Luckily, there is a new issue on the Spring JIRA that lets you vote AGAINST Spring using Maven. Cast your vote now. Your grandchildren will remember you for it.

Apple Mac: Tainted Love

After two splendid months of usage where I could say no wrong about my new Macbook, unfortunately it appears to suffer from Random Shutdown Syndrom (RSS). The only way I can get it to run without it shutting itself off either immediately or after a few minutes is by booting it up in 1ghz mode by pressing and holding the power button for 15 seconds.

A staggering number of Macbook owners seem to suffer from this problem and it is a shame that an otherwise great user experience has been tainted by Apple's poor QA procedures / build quality issues.

Nevertheless, back to Apple it will go. I will forgive and forget if the quality of their after sales care is up to scratch. Only time will tell.

RailsConf 2006: The Grails perspective on it all

Well, I have returned safely from my adventure to Rails Conf Europe in London. I had feared that I would be found bleeding in some alley way clutching to the last remnants of my life. As it turns out I came away with a fresh perspective on the Ruby community and managed to meet and chat to some really interesting people.

Having been to JavaOne, which was for the most part rather corporate and serious, it was quite a contrast to be amongst a group of people many of whom looked like they had just stepped off the set of the "skaterboy" video by Avril Lavigne. This was not isolated to the attendees either, with one speaker in particular whose name escapes me darning a mohican and a can of stella whilst delivering his session. In fact the whole event seem more like a rock concert than your typical conference, which was interesting if nothing else.

Nevertheless, it did aid in enlightening me on some of the huge cultural differences between the Ruby community and the rest. For one it appears that a large part of the Ruby and Rails community are a younger generation and when I mean young I mean those under 30.

Young people, by their very nature, are passionate and sometimes less measured in their responses. In other words they're more likely to tell you where to shove it when faced with a disagreement and later regret using such an aggressive tone. I know. I'm still "young" and sometimes that inner fire gets the best of me. In this sense I kind of understand some of the Ruby communities responses a bit better now. I don't see them as aggressive anymore, just passionate and passion is a good thing.

In fact one of the keynote speeches was delivered by a lady that talked about passion and how a user develops passion for a product and I can see now the appeal here that Ruby and Rails offers to this younger generation of programmers. Ruby and Rails are "cool" and trendy and you can see why. It is trivial and fun to program in.

The one thing I do hope, however, is that doesn't result in a generation of programmers having a closed mind to other technologies. In my view being a developer is not about being a Ruby or a Java or a C programmer. It is being able to pick up whatever language that is appropriate for the job at hand and run with it. The best programmers I've worked with have been those who had this ability to adapt to any enviroment or constraints.

That being said this should by no means be taken as a generalization of the entire attendance of RailsConf or Ruby/Rails community. There were also many people of varying ages who have come from a mixed background (maybe former C or Java programmers) and were open minded at the event. It is just that a large proporation of the attendance and I believe the following of Ruby/Rails do appear to fall in this category. Feel free to correct me with a barrage of statistics if I'm wrong here.

So that was my high level observation of the whole event. Moving on, I had the pleasure of getting to meet some interesting people. One of them was of course David HH who I had a brief conversation with and he seemed mildly interested (ok this may be over stating it a bit ;-) in knowing what Groovy was all about and we discussed JRuby for a bit, which was, of course, of greater interest to him. I thought his keynote speech was very well delivered and some of the features in Rails 2.0 are a marked step forward.

I then got to see a number of the sessions and one of the more interesting ones was a "cross pollination" session delivered by Simon Willison of Django fame. I think both Grails and Rails do have things to learn from Django and it seems both Django and Grails have followed the route of domain-driven development, as oppose to Rails where the database is central. I considered submitting a similar session for Grails, as their are features in Grails that Rails (and indeed Django) can learn from such as services and dynamic tag libraries. My fear was that it would not really be of interest at RailsConf, but as they say there is always next year.

Another interesting session was the JRuby one delivered by Charles Nutter now of Sun Microsystems. During the conference we got to chat quite a bit and discussed in depth the challenges he faces ahead of him to get JRuby to integrate with Java more seamlessly. It seams the obstacles that he is facing are very similar to the ones confronted by Groovy in many ways and there may be some mileage in a further exchange of ideas there. One in particular he mentioned was getting JRuby to compile into byte-code and hence drammatically improve performance. Given the huge differences in the languages and the VMs offered by Ruby and Java this presents one of the biggest hurdles facing JRuby, but the good news is that Charles told me he got some basic JRuby scripts compiling to byte code which, most certainly, is a start!

Charles was definitely one of the most open minded individuals that I had the privilege to meet and although he has strong links to Ruby still sees the "bigger" picture and importance of Java and in particular JEE. Needless to say I am sure our paths will cross again.

Overall I am pleased I got the opportunity to attend and hear some of the success stories that Rails has prompted. As the saying goes though not every hammer can be used to hit the same nail so in future I looked forward to a few more Grails success stories. Thanks must go out to the entire team at SkillsMatter for arranging such a great event.

Congrats to JRuby guys & What it means to Groovy

First, I must express my congratulations to the JRuby guys at the news that they have been hired to work fulltime on JRuby by Sun. This is great news as we may finally see a high quality Ruby VM for Java. The reaction on the Groovy list has ranged from the hysterical to the dismissive.

What do I personally think it means to Groovy? Well not a great deal actually. Groovy already has tight integration with Java and compiles to byte code hence its performance and integration is excellent. The work here lies with the JRuby guys.

In addition, I think this is a great thing for the Java community. Java has always been about offering choice to its developers, over in Ruby-land when you're looking for a web framework you have Rails and, umm... Rails. If JRuby gets Rails working on Java then it is just another choice amongst such great frameworks like WebWork, Cocoon, Rife and Grails.

And what about Grails? Well Grails' goals have always been very different, sure it was about creating a framework that had the essence of Rails, but it is the technology stack that it is built on that is important. Grails provides tight integration with Spring, Hibernate, SiteMesh and Quartz. Together they represent some of the most popular Java stacks out there that share a huge user base. The Spring+Hibernate stack is probably the most frequently used combination in building Java apps today and the goal of Grails was to create a framework that leveraged this allowing you to mix approaches.

We're also targeting tighter EJB3 support and in the future JPA support, so the direction here is very different to JRuby on Rails, which re-invents everything from scratch (controller layer, ORM layer etc.).

Overall I think this is great news and can only help improve the offering on the JVM and extend the choice available to Java developers.

Grails InfoQ Article: Grails+EJB3

There is a great article up on InfoQ demonstrating how to use Grails with an EJB3 compliant domain model. The article is by Jason Rudolph author of another excellent article on using Grails with legacy database systems.

Thanks for another great contribution Jason!

Closures in Java: Is it too late?

So the interesting news broke that their is finally a proposal for closures in Java. My immediate feeling? Well for one the verbosity of the syntax proposal concerns me deeply, it is one of those things that unless it was thought of from the start will always be a problem to retrofit back into the language. The implications here is that we have a less than ideal proposal for the syntax when you compare it to say, Groovy's or Ruby's equivalent.

Is it too late now? My feeling is yes, Java has been around for a decade now. It has jumped several iterations to Java 5 (with Java 6 coming shortly) and the APIs have progressed hugely. The implications of adding closures would be huge, you would have to go back and revisit ALL the Java APIs. I mean, if closures had been around since the beginning the collections API would be entirely different. As would other things like the way we deal with transactions and file I/O.

Don't get me wrong I think it is great that they are considering it, even if it is a decade too late, but it will take a long time for the real effects to be felt until the APIs are made closure-aware.

Mac OS X: Another switcher in the bag

Well after a period of sustained resistence, I finally could cope no longer and am writing this particular entry on my new MacBook via safari. I've had it for a couple of days now and having no real prior experience with Macs besides playing with them in the Mac store it has been nothing short of a revelation.

Yes I had read Cedric's comments prior to my Mac experience and although he raises some valid points, I have to say after 3 days with the machine I'm not sure what took me so long to make this decision.

The experience starts when you get the package with the usual emaculate packaging, from then as soon as you turn on the machine yo notice the attention to detail. Yes some may call the welcome in a million languages cheesy, but you know that somebody out there has spent a lot of time making sure this is a great product. Then you go through the start-up phase and everything "just works". It hooked up to my wireless router with no problems, no fighting with networking settings and drivers like in Windows. Updates were then automatically installed and I was ready to go.

The interface is quite simply light years ahead of Windows and I'm not sure even Vista (yes I've tried the betas) comes anywhere near it. Video is extremely slick with QuickTime and looks simply stunning on the glossy screen and the amount of value you get with the included iLife suite (plus the super cool Front Row) is awesome. After adding the machine to my Windows workgroup it automatically saw the other windows machines on my network and I could start copying data onto it.. no problems.

I then started installed my beloved IDEA (which I had to abandon for Eclipse for a period on Windows because the Sun VM persistently crashed forcing me to fall back to JRocket which I couldn't get to work with IDEA) using the remarkable install process: Download dmg, it automatically (after showing a "are you sure" dialog) loads a window with an IDEA logo in it, Drag-and-drop the IDEA logo to your Applicaiton folder and you're done! No progress bars, no install wizards, amazing. And of course because jdk1.5 comes with Tiger, again all Java apps including Grails "just worked".

One of Cedric's concerns was task switching and I am also a former Task Switch Pro user on Windows, but I gotta say I don't miss it! Expose simply blows all other task switching systems out the window. I'm constantly using it and was quite amazed at one point when I had a QuickTime video playing which shrunk along with the others windows without the video jerking or getting confused. You could continue to watch the video whilst monitoring other processes (like your ant build ;-).

One of the first things I installed was the much vaunted QuickSilver. This application is amazing, I installed the Gmail plugins and can search for an image, resize it, and attach it to an email automatically addressed to somebody in Address book all with a few keystroke combinations. I find the combination of QS and SpotLight mean I very rarely open Finder (like Explorer on windows). No more browsing heirarchies of files looking for the right one, they're all accessible immediately via powerful search combined with expressive QS actions.

So, what don't I like or what do I miss from Windows? Well not a great deal actually. I kind of miss the Windows maximize button as the "zoom" in Mac OS X is just not the same thing and takes some getting used to. Other than that there is not much to miss from the Windows world, everything I need and use is available for the Mac and if I'm desperate I can run Windows via Parallels. I'm really happy with my decision to switch and there is no going back now, not that I would want to!

Groovy/Grails Seminar & Grails 0.2 Release

Little late in blogging about this as I've been a little busy recently, but the Groovy & Grails seminar went splendidly well. The audience were fanstastically enthusiastic and asked some really good questions which prompted some excellent discussion. Overall a great success and I look forward to the next one.

Thanks again for SkillsMatter for hosting it, I had the pleasure of putting some faces to names whilst I was there which was great. The slides that Dierk and I presented can be found here: http://www.skillsmatter.com/groovy-grails-seminar

Shortly after the seminar we decided to put out Grails 0.2 which is numerous improvements (see the news on the Grails site for details) and features. Thanks to all those who contributed to the release!

PS For the observant out there you will notice that the slides I presented look suspiciously similar to the ones I delivered at JavaOne ;-)

Upcoming Groovy/Grails Seminar in London

If you're up for being in London on the 13th of July we're holding a Groovy & Grails seminar at the office's of Open Source training company SkillsMatter. Dierk Koenig, author of the upcoming book Groovy in Action by Manning, will be there presenting Groovy and yours truely will be giving a presentation on Grails. Pop along if you're interested!

Grails + Legacy DB + Hibernate XML

There is a simply splendid 4-page(!) article written by Jason Rudolph taking you step-by-step with screenshots and all to get a scaffolded Grails application working with a legacy MySQL database using Hibernate XML mapping.

This really demonstrates the power that Grails has to offer in terms of being simple on the surface, but having all the power of Hibernate underneath. Note that Jason could equally have written his domain model and Java and used annotations to achieve the same effect. See the page on Grails' Hibernate integration in the user docs for more info.

Grails & EJB3 Entity beans

One of the features that I mentioned at JavaOne that got people all excited was Grails' support for EJB3 entity beans. Grails comes with it's own ORM solution built on-top of Hibernate called GORM, but because of this relationship with Hibernate Grails domain models can also be written in Java.

One way to do this is to use the EJB3 annotation support in Hibernate which will of course allow you to use all the power the API offers in terms of mapping onto legacy systems. Clearly this is all not that exciting so far, what is really exciting is that even though the EJB3 entities you've created are written in Java and mapped using Java persistence annotations you can still use all those fantastic dynamic finder/persitence methods to manipulate your domain model from a Grails controller or service class!

Some examples of these in action are listed below, Grails uses the properties of the domain class itself (combined with the wonderful Criteria API) to implement the finders:




def a = new Author(name:'Stephen King').save()
def b = new Book(author:a, title:'The Stand').save()

def results = Book.findAllByTitle("The Stand")

results = Book.findAllByTitleLike("Harry Pot%")
results = Book.findAllByReleaseDateBetween( firstDate, secondDate )
results = Book.findAllByReleaseDateGreaterThan( someDate )
results = Book.findAllByTitleLikeOrReleaseDateLessThan( "%Something%", someDate )

// find by relationship
results = Book.findAllByAuthor( Author.findByName('Stephen King') )

This is one of the awesome features of Groovy's Meta Object Protocol (MOP), it allows you to add new methods, properties,constructors etc. to any existing Java class, it doesn't have to extend GroovyObject or have any knowledge of the Groovy runtime environment. Think of it as AOP without the byte code manipulation.

Taking this approach is quite appealling at it allows the blended development I mentioned in the talk. Mixing dynamic and static typing is the way to go in my opinion. The debate between these two is a bit of a red herring. This way you have all the power of static typing with its refactoring capability in IDEs, plus the ability to use a dyanmic framework like Grails as the view/controller layer in your web application.

You can also then re-use your domain model across tiers or from regular servlets or via a Swing interface very simply because it is still in Java. The main target for Grails has always been to create a framework with the essence of Rails, but taking Java integration to a new level. Features like this are exactly what is helping us achieve this very goal.

Grails: JavaOne 2006 Slides Available

The slides that I presented at the JavaOne 2006 conference are now available to download from the Grails site. Alternatively here's a direct link.

Thanks to all of those that attended, it was a blast :-)