Thursday, May 17, 2007

Grails + Wicket: The Wonders of the Grails Plug-in system

Update: A shorter Wicket plug-in installation guide has been added here

A few people have been asking me recently to integrate the Wicket project as a view technology for Grails. What is Wicket? It is a component oriented framework kind of like JSF, but unlike JSF it uses convention-over-configuration and doesn't require you to edit reams of XML. So in this sense its aims are more inline with Grails' aims.

So the question was how do we integrate these two frameworks? Well I thought it couldn't be that difficult and as it turns out, it isn't. So what I did was create a plug-in with "grails create-plugin wicket". The next thing I needed were some jars, so I got Wicket 1.2.6, Wicket Extensions 1.2.6 jar and the Wicket Spring integration jars for 1.2.6 and put them in the plug-ins lib directory.



Job done, now we need to set-up a convention that makes sense for both Grails and Wicket:

1) Since controllers are essentially roughly analogous to the Wicket Application object I decided that the convention would be to have a WebApplication.groovy file in the grails-app/controllers directory.
2) Wickets HTML components are like the views, so they can live in the grails-app/views directory

So to follow the HelloWorld example on the Wicket page we end up with something like this being the structure:



So just for clarify the WebApplication.groovy file looks like this:

import wicket.Page;
import wicket.spring.*;

public class WebApplication extends SpringWebApplication
{
public Class getHomePage()
{
return HelloWorld.class;
}
}

Whilst HelloWorld.groovy looks like this:

import wicket.markup.html.WebPage;
import wicket.markup.html.basic.Label;

public class HelloWorld extends WebPage
{
public HelloWorld()
{
add(new Label("message", "Hello World!"))
}
}

Finally, the HelloWorld.html file looks like this:

<html>
<body>
<span wicket:id="message">Message goes here</span>
</body>
</html>

Ok so with that done, let's take advantage of the conventions we have in place here. When I created the plug-in with "grails create-plugin" it also created me a WicketGrailsPlugin.groovy file in the root of the plugin project. Since the normal controller mechanism no longer makes sense we modify the plug-in to "evict" the controllers plug-in when installed:


class WicketGrailsPlugin {
def version = 0.1
def dependsOn = [:]
def evicts = ['controllers'] // evict the controllers plugin
...
}


With that done we now need to configure the Wicket "applicationBean" in Spring. To do this we're going to use the GrailsApplication object and find a class that is an instance of a Wicket Application. This class just happens to be the one we defined earlier in grails-app/controllers:


import wicket.*
class WicketGrailsPlugin {
...
def doWithSpring = {
def applicationClass = application
.allClasses
.find { Application.class.isAssignableFrom(it) }

if(applicationClass) {
applicationBean(applicationClass) // defines the spring bean
}
}
}


We're of course using the Spring BeanBuilder here to define the bean definition if the Spring context. Ok job done.

Now we need to modify web.xml.. but wait. In Grails even web.xml is created on the fly so other plugins can participate in its generation. So we can do this in the plug-in file again:


import wicket.*
class WicketGrailsPlugin {
...
def doWithWebDescriptor = { xml ->
def servlets = xml.servlet[0]

servlets + {
servlet {
'servlet-name'('wicket')
'servlet-class'('wicket.protocol.http.WicketServlet')
'init-param' {
'param-name'('applicationFactoryClassName')
'param-value'('wicket.spring.SpringWebApplicationFactory')
}
'load-on-startup'(1)
}
}

def mappings = xml.'servlet-mapping'[0]
mappings + {
'servlet-mapping' {
'servlet-name'('wicket')
'url-pattern'('/app/*')
}
}
}
}


Here we use Groovy's XmlSlurper DSL to modify and the XML simply by using the + operator and some Groovy mark-up. We again use the Wicket Spring integration support to get it all working, so when Wicket loads it will actually look for the bean created by the Grails plug-in. And that's it, to test the plug-in we can type "grails run-app" and navigate to http://localhost:8080/grails-wicket/app and we see:



Not hugely impressive I know, but what it does show is Wicket running as the view tech in Grails which means that Wicket components and applications can use GORM to simplify the ORM layer of Wicket applications and other features of Grails like Services and Jobs. This took me all of 20 minutes to write, in fact I've spent longer writing this article than the plug-in. Not that it is complete of course, things left to do are to add reloading support to the Groovy files that Wicket users. Advice from the Wicket community on how to do that would be appreciated. And of course I haven't tested it against any more complex examples yet.

Now of course it wouldn't be a plug-in if it couldn't be installed into other apps. To do this we package it up with "grails package-plugin" which will create a zip. I've placed in plug-in at http://dist.codehaus.org/grails-plugins/ so in any Grails application you can now do:

grails install-plugin Wicket 0.1

or directly from the URL:

grails install-plugin http://dist.codehaus.org/grails-plugins/grails-Wicket-0.1.zip

And it will install this version of the plug-in.

Note: The plug-in doesn't work with the Grails URL mapping mechanism in 0.5 so you need to delete any grails-app/conf/*UrlMappings.groovy files otherwise you'll get an exception.

Plug-in sources can be found here: http://svn.grails-plugins.codehaus.org/browse/grails-plugins/grails-wicket/trunk

Wednesday, May 16, 2007

RE: Groovy and Grails: Three Worries

I had the pleasure of meeting and having dinner (at a wondefully steriotypical American diner) with Stuart Halloway along with other NFJS guys like Ted Neward and Brian Goetz at JavaOne. Since then Stuart took the time to write a nice entry with a few pleasantries that he discovered about Groovy & Grails (Thanks Stuart!).

In a follow-up post entitled Groovy & Grails: Three Worries he raises a few concerns which I commented on, but would like to take the time to address here too.

1. Lack of Open Classes in Groovy

His first concern centers around the fact that Ruby has an open class system whilst Groovy does not. The reasons for this are simply Groovy compiles into byte code directly and there is a one-to-one mapping between a Groovy class and a class file. This is unlike JRuby where you need to to use proxying trickys in order to do things like call Ruby from Java.

So essentially Groovy can't modify classes directly because as far as the JVM is concerned once a class is loaded it cannot be changed. Of course this is completely sensible as the Java platform has the concept of threading. Changing class definitions at runtime in a multi-threaded environment would be rather problematic from the JVMs perspective. Since Ruby has no concept of threading at this time of writing the language and runtime has no such concerns.

So given these constraints in Groovy we have a different way of doing things. Stuart presented the following example:


class Person {
def firstName;
}
p = new Person();
class Person {
def lastName;
}
p.lastName = 'Halloway'


In Groovy (with the upcoming 1.1 release) this would be implemented as:


class Person {
def firstName;
}
p = new Person();
p.metaClass.lastName = 'Halloway'

p.lastName = "Rocher"


This uses Groovy's ExpandoMetaClass mechanism. Since in Groovy we can't change classes, we instead have a MetaClass for each java.lang.Class. The MetaClass defines the behaviour of the actual class. You change the MetaClass you change the class. So Groovy might not have "open" classes, but it has an equivalent mechanism for achieving the same thing.

2. OMG! Grails is not written in 100% Groovy!

Yes that is right Grails is around 80% Java and 20% Groovy. The reasons for this are several. Firstly, Java still makes a great language for writing low-level plumbing code. For dealing with all the complexities that the users of the higher level interface (Grails users) don't have to deal with. Secondly, since Grails is written in Java we get the performance benefits of this. Grails is between 50 and 300% faster than Rails depending on the test. Rails might be implemented in 100% Ruby, but it has very well documented performance troubles because of this.

Do we eat our own dog food? Hell yeah, we have a plug-in system where plugins are all written in Groovy. All of our custom tag libraries are written in Groovy. Groovy Server Pages (GSP), our view technologies, is all Groovy. So we eat plenty of it trust me. Finally, the Groovy community has never been the one to cry out and tell everyone to ditch Java. No, our philosophy is to choose the right tool for the job, and Java is still a great tool in my toolbox just as Groovy is another. The fact that they work so seamlessly together is what makes the pairing so special.

3. The old static typing debate


So is static typing useful anyway? Well yes, it has been useful for a number of things for us such as enabling us to implement more intelligent scaffolding based on the types (java.util.Date, java.lang.String) etc. Also we could implement things like command objects which using static type information.

In addition at the moment the tool support just is not there yet to use either Ruby or Groovy for large complicated applications. Static typing analysis and the features that it brings to modern IDEs like refactoring and code navigation are just in a different league in Java. I hope this will change in time and since Groovy supports both static and dynamic typing I believe the tools vendors will have an easier time creating quality tools for it.

This is also where Grails fits quite nicely into the picture as it allows you to mix Groovy for the simple to medium complex stuff and Java to do the heavy lifting. IMO Groovy gets the balance here just right.

Monday, May 14, 2007

The lone ramblings of a JRuby developer in denial

Jeremy Rayner has a nice summary of all the positive and negative feedback dished out to Groovy at JavaOne the overwhelming majority of which is positive. It is entertaining to see that the most vocal and negative comments come from none other than a JRuby committer Ola Bini.

I can imagine the picture now of Ola sitting in a Groovy session with his fingers in his ears and eyes shut going "nah nah nah I'm not listening!!". Unfortunately Ola, as demonstrated by the vast array of positive feedback and the book sales, really there is only one winner this year: Groovy

Nevermind, there is always next year ;-)

Friday, May 11, 2007

The Grails US Tour: JavaOne Day 3 + Back to London

Well this is where JavaOne ends for me. This morning I met up with Geertjan (famous NetBeans guys from Sun) and his colleague Martin Adamek who were both extremely enthusiastic about Groovy & Grails support in NetBeans IDE. It was great chatting to them and hearing their excitment, it will be great to have Geertjan (and hopefully Martin) over at the Grails eXchange 2007 in October.

After that I went to Rod Cope's (the twice voted JavaOne Rockstar!) talk on "Advanced Groovy", which was awesome. Again a fairly full room (although not packed out like Guillaume and Dierk's Groovy talk) with around 300 people. The demos he did were fantastic, involving XML-RPC, ActiveX automation and all sorts. Very well put together, I imagine he has a chance for a hatrick of Rockstar nominations.

Now its back to the UK, with my flight leaving tonight. I'm looking forward to seeing my family and returning to some sense of normality, but it has been a blast. Thanks go out to the No Fluff guys, the JetBrains guys and of course Sun for letting me do the half day Groovy/Grails talk which was very enjoyable.

Overall the conference has been a great success with so much excitment about Groovy and Grails. Hopefully we've impressed enough people to encourage greater adoption of Groovy as the major dynamic language platform for the JVM.

Thursday, May 10, 2007

The Grails US Tour: JavaOne Day 2

So I just finished my BOF on Grails + Spring & Hibernate. It went ok, I'm a little disappointed actually. My talk was at 9:55pm which is like the graveyard shift with fewer people than other sessions and tiredness had really started to set in for me after all my talks at NFJS, JavaU and then all the parties and dinners.

I fear I grossly overestimated the audiences' potential knowledge of Groovy & Grails, a schoolboy error of course. It was a fairly advanced talk showing mixing Java entities and Grails domain classes in the same codebase and using remote Spring services. I fear it may well have been more effective to have done a similar introductory talk as last years JavaOne.

I could kind of gage this from the audiences' blank looks as I was doing the talk which made me rush through some parts to avoid some of the complexity leaving the talk shorter than it should have been. I fear I left the audience thinking that Grails is complicated when in fact what I was trying to demonstrate was Grails is simple when you need it to be and flexible (spring+hibernate integration) when you need it to be.

Oh well, you win some you lose some, I'm trying not to be too down beat as it has still been very worthwhile as the buzz I got from the NFJS and JavaU talks plus the Groovy talk by Dierk and Guillaume was totally different. And we received some awesome news about the book sales. On day one the Groovy book sold out by 4pm and the Grails book was 4th on the best seller list. Check it out Groovy & Grails has proven really popular this year so its been awesome.

So much cause for celebration, even if my talk was not what I hoped it to be...

Wednesday, May 09, 2007

The Grails US Tour: JavaOne Day 1

Another eventful day at JavaOne is winding to a close. It was another great day from a Groovy perspective with the Groovy session filling up with around 600 people in it with the rest losing out. Guillaume and Dierk did an awesome session about Groovy with some neat demos, which the audience really enjoyed. We then all went to a book signing at the Digital Guru bookshop, which was enjoyable.

The big news of the day was of course JavaFX. I've looked over the samples and can't really see why a new language is needed as it can be done with an almost identical syntax in Groovy's SwingBuilder. The only "feature" that seems to differentiate it is that you can bind multiple references to the same value. The result here is that if you change the value if changes all references to it. This of course can be achieved with Groovy closure's too. Nevertheless, it is too early to tell, I haven't had a chance to look at it in any detail so maybe I'm missing something.

Later in the day we had dinner with the JetBrains and the No Fluff guys and it was great to see so many people getting together and being enthusiastic about Groovy and Grails. Onto Day 2....

Tuesday, May 08, 2007

The Grails US Tour: JavaOne Day 0 + G2One

Well its the morning of JavaOne Day 1 and now for my Java University report. So basically I did a half day Groovy & Grails talk at the Java University and the response was brilliant. There were a 150 people and doing a half day event really gave me the time to get into the detail of Groovy & Grails and do some good demos. The audience were mostly blown away by the awesome things you could do with Groovy & Grails and it was fantastic to hear the response. After hearing that some of the other talks were a disappointment it was good to hear mine got a tick in the box.

Next up was No Fluff Just Stuff's G2One event which was good too. I wish though I had had more time to do a longer more interactive session as 30 minutes felt to short to get my points across, but it was good fun and I met some interesting people who were interested in Groovy & Grails as over 200 people showed up for the event which is a great turnout. Ted Neward conducted a panel discussion featuring myself, Guillaume, Dierk, Neal Ford, Andy Glover and Jason Rudolph (who I finally got to meet) that was great fun.

The attendees asked some of the typical questions such as IDE support, JRuby vs Groovy and of course "When is Grails going to support Maven!". I believe we were able to answer most of them in an effective way. Most Java people are still a little afraid to leave the comfort of their trusty IDE which is understandable.

After the event I stumbled across James Strachan who I had yet to meet, it was late in the evening and James was a little on the merry side, so we didn't really have a chance to chat much, but made the introductions and hopefully we will during the conference.

I also met Alex Tchakman of JetBrains who is leading the effort to develop a Groovy/Grails plug-in for IntelliJ IDEA. It was fantastic to hear how excited he is about IntelliJ and the future of the Groovy/Grails plug-in for it. I can't wait for October when it will be unveiled to the public.

Finally, I woke up this morning to the news that we have been biled. What did Rod Johnson say? "You haven't made it until you've been biled". Groovy and Grails rock :-)

Monday, May 07, 2007

The Grails US Tour: Arrived to San Francisco + NFJS Denver Report

So I'm sitting here in my hotel room having just arrived to San Francisco after the 2 and bit hour flight from Denver. The No Fluff Just Stuff show in Denver was really fantastic and I was amazed to see so many passionate Java developers coming together on their weekend to talk techie. I met some great people including a few of the regular No Fluffers such as Neal Ford, Ted Neward and Scott Davis. And of course I had the pleasure of meeting the man himself, Jay Zimmerman.

I also managed to take in a couple of sessions and saw Seam demo'ed properly for the first time. My thoughts? Well it certainly papers over the warts of JSF, but it is still a lonnnngggg way away from the claimed "Ruby-on-Rails like" productivity. What summed it up perfectly for me was a moment in David Geary's talk where he created a CRUD app and claimed "it only took 40 lines of config and a 100 lines of Java!". I was tempted to stand up and say well I could have done that in about 10 lines of Grails code with scaffolding and no config, but thought better of it.

Of course Seam will get its users because of the whole "standards" approach that it has, but in terms of developer experience it is miles from Rails or Grails. Moving on, at the conference I did three talks on Grails covering Spring/Hibernate integration, GORM and plug-ins that were all completely packed out and the response was superb.

However, the moment that pleased me the most was near the end where the majority of the 250 attendees gather in the main presentation room and Jay asked them who would be using the various technologies presented. When asked about JRuby about 10 people raised their hands, when asked about Seam around 15 did, when asked about Groovy & Grails the majority of the audience raised their hands, far too many to count anyway. My (and Scott's) work here is done. Next...

Friday, May 04, 2007

The Grails US Tour: NFJS Denver & JavaOne

Today begins my week long tour of the US doing various talks about Groovy & Grails. First up I'm heading to Denver to do 3 talks on Grails at No Fluff Just Stuff's Rocky Mountain Software Symposium, which should be fun. I then get a connecting flight to San Francisco where I'll be doing a half day Groovy/Grails Java University talk at JavaOne next week Monday. Also on Monday there is the Groovy/Grails G2One event I mentioned the other day which is also organised again by the NFJS guys.

Hopefully I'll then have time to take in some sessions before doing a couple of talks, first a Intro to Grails talks at the Oracle booth followed on Wednesday by my BOF. The schedule looks challenging, I imagine jetlag will kick in promptly, I'm going to miss my wife and kids like crazy, but it should be good fun. See you there!

Wednesday, May 02, 2007

G2One at JavaOne: A Special Groovy/Grails Event

Looks like this years JavaOne in San Francisco is going to be an even more exciting event than expected with a new Groovy/Grails specific event organised by Jay Zimmerman of No Fluff Just Stuff called G2One. Its a great oppurtunity to meet up with some of the people behind Groovy & Grails, but you have to pre-register! Only 250 places available and registration is free. With this event, all the other No Fluff activity in the US and Skills Matter's upcoming Grails eXchange 2007 conference, it seems Groovy & Grails are very well respresented in the conference stakes.

Tuesday, May 01, 2007

Grails 0.5 Shipping!

A few days before we all converge on JavaOne 07 and Grails 0.5 is out! This is an awesome milestone for Grails and represents a significant improvement over Grails 0.4. Well over 200 JIRA issues have been tackled and Grails is now 40-50% faster than previously published benchmarks

We got round to tackling some great new features such as our DSL for URL mapping, command objects, more codecs and huge improvements to GORM. Take a look at the release notes for more info. All in all I feel Grails is coming along nicely and we are still on target to ship 1.0 by autumn. See you at JavaOne 07!

Wednesday, April 18, 2007

Groovy & Grails at JavaOne 07 University

As well as a BOF at JavaOne I'll also be doing a half-day course at the JavaOne university on Groovy & Grails. Check it out here.

Neal Ford: "I would rather write Groovy code in VI than Java code in IDEA"

Interesting and entertaining interview with Neal Ford of ThoughtWorks fame. He has lots of nice things to say about Groovy and Ruby.

The only point I disagree with is his assertion that in Groovy you can only do 80% of what you can do in Ruby in terms of DSL programming. I've never seen a Ruby DSL that couldn't be done in Groovy with a similar conciseness in the syntax. It would be nice if Neal could elaborate on this point.

Tuesday, April 17, 2007

Contrasting Grails SpringBuilder vs JRuby Spring DSL vs Guice

An interesting post by Craig Walls that I hadn't noticed before shows how you can create Spring configs with a little JRuby DSL:


DAOS = [ :ZoneDAO, :EmailDomainDAO, :DayDAO, :PreferenceDAO,
:WhatEverDao... ]
DAOS.each do |dao|
bean(dao, "daos.hibernate.#{dao}Hibernate")
{|b| b.new("sonarSession")}
end


The Groovy version with Grails' SpringBuilder would look like:


def DAOS = [ZoneDAO, EmailDomainDAO, DayDAO, PreferenceDAO, WhateverDAO]
DAOs.each { dao ->
"${dao}"("daos.hibernate.${dao.simpleName}Hibernate") {
sessionFactory = ref("sonarSession")
}
}


Another important difference between the two is that Springy, the JRuby version, serializes the JRuby code into XML and then reads the beans from that. We used to do this in Grails, but it had serious performance implications for load time, Grails' BeanBuilder constructs the ApplicationContext programmatically on the fly.

Bob Lee also offered his alternative using Guice:


Class[] daos = { ZoneDao.class, EmailDomainDao.class, PreferenceDao.class... };
for (Class dao : daos)
bind(dao).to(Class.forName("daos.hibernate.Hibernate" + dao.getSimpleName()));


Since Groovy does annotations it is possible to make this code even Groovier:


def daos = [ZoneDao, EmailDomainDao, PreferenceDao...]
daos.each { bind(it).to(Class.forName("daos.hibernate.Hibernate${it.simpleName}") }

Saturday, March 24, 2007

Updated Grails vs Rails Benchmark

So after a couple of people pointed out my naivety in configuring Rails, I decided to re-run the tests. What I did was configure Rails with a 10 mongrel cluster and the Pound load balancer as per Jared's recommendation. However, to make things more equal I reduced the Grails Tomcat server's thread pool down to 10 by setting maxThreads=10 in Tomcat's server.xml.

The result was that Rails' performance degraded in all except the long running query test, whilst Grails' performance significantly improved in all except the same test. Clearly, since I have only dual core's on my MacBook giving Rails or Grails more processes doesn't necessarily improve things for the shorter tasks. Check out the updated benchmarks.

Again, I'm no Rails performance tuning wizard so if any Rails expert can suggest improvements to the Rails configuration please don't hesitate to shout.

Friday, March 23, 2007

Grails vs. Rails Benchmark

This article: http://thoughtmining.blogspot.com/2007/03/where-are-all-groovy-andor-grails.html

Prompted me to do this:
http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark

Feedback welcome.

I must stress this is not meant to be a flame war inciting benchmark, it has been done merely to allay the aforementioned bloggers fear that he expresses in this comment:

"Surely someone close to the respective projects has asked these hard questions of themselves?

Because I know the previous paragraph has to, has to, be true, then I can only assume one thing: someone has done this as an exercise...and the results were depressing. Why else would the results not be published? If Groovy or Grails was faster, even slightly so, then you can bet it would trumpeted far and wide. The fact that it's not leaves an unsettling feeling."

Thursday, March 22, 2007

Groovy & Grails at Sun Tech Days - The Report

I've been meaning to write up a report of how my workshop on Groovy & Grails at Sun Tech Days went, so here it is. First off, I would like to say a big thanks to the guys at Sun for hosting me, it was great gesture and thankfully we'll see more of it at JavaOne.

As far as the workshop went, I really wanted to deliver something of value and probably ended up overdoing it as a I had over 160 slides (death by keynote!). Fortunately, the audience were extremely enthusiastic with the only hiccup being a gentlemen who was running a p3 450mhz machine with 256mb of RAM and Windows 98 (with MS-DOS!) not being able to get the Grails command line scripts running.

Interestingly, the majority of attendees were from either the banking or insurance industries, which reflects Grails' growth in the enterprise market space. There were many wow moments, and some concepts which were difficult to grok for a group of Java developers. Explaining closures was particularly fun.

Overall, the attendees seemed to enjoy the workshop and left brimming with ideas of how to integrate Grails into their existing systems. Job done.

Tuesday, March 20, 2007

Grails Interview on Groovy.org.es

The nice chaps at Groovy.org.es were kind enough to take the time to interview me. For those who want to improve their Spanish and learn what's going on in the Groovy/Grails world check it out.

Tuesday, March 13, 2007

JRuby, Groovy & Java Integration

As a follow-up to yesterdays article, I would like to point out the following article written by Ola Bini on the JRuby team: JRuby Regular Expressions.

This article represents everything that differs in the mentality between the Groovy & the JRuby teams. In essence, the JRuby team are planning on ditching java.util.regex and implementing their own regex parser to match the Ruby regex semantics.

Regardless as to whether this is a good thing or not, and regardless as to whether you can change the default implementation this is the essence of the debate over Java integration. So whenever you drop out of Java and into Ruby-land you need to remember that the semantics differ between regex implementations. To be clear: Java integration means more than just being able to call a method on a Java class.

To quote Dierk Koenig, author of Groovy in Action, who posted this comment yesterday:

"I would like to add that there is a fundamental difference between the two types of languages for the Java platform: type A, which are languages designed specifically for that platform (Groovy, Scala, etc.), and type B, which are ports of a foreign language (Jython, JRuby, Kawa, Bistro, and the likes).

While type B languages can achieve a decent level of interoperability, only type A languages can truly integrate with Java. This is because foreign languages not only have their own libraries, APIs, and such but more important, they come with their own object model, threading architecture, security concept, performance and debugging hooks, and last not least their own runtime architecture that can be fundamentally different from Java. Any type B language has to overcome this impedance mismatch breaking either Java's or the foreign language's behavior.

The acid test for integration is to replace any given Java class (be it abstract, or in the middle of an inheritance chain, or having overloaded methods, or using annotations) and replace it with an implementation in your language. This is what only type A languages can possibly achieve."

In other words, this is another example of how the JRuby developers have to make a hard choice in order to support C Ruby compatibility. Unfortunately on this occasion, it is Java integration that suffers.

In Groovy the expression ~/pattern/ results in an instance of java.util.regex.Pattern therefore the semantics are the same, you can call all the regular JDK methods on the object and the object can be passed to a Java object to hook into other frameworks and tools.

Monday, March 12, 2007

The Charles Nutter Ruby on Grails story

Back in December Charles Nutter and I had a discussion at JavaPolis about collaborating and the potential to leverage Grails as a platform for multiple languages.

Now Charles has actually looked at the codebase, and would even like a further extended tour (Charles - give me a shout if you're interested, I'd be happy to). His conclusion? Lets make Ruby on Grails. I don't find it particularily suprising he has come to this conclusion. His estimates of Java-to-Groovy are actually way off. I would say if you take away the unit tests and sample apps, Grails is more like 85% Java. There are a few things that should be pointed out here:
  • Not only is it very possible to support other languages, it is feasible now, thanks to the plugin system and Grails' well thought out, as Charles puts it, "interfacified, injectificated, and abstractilicious" design.
  • The benefits of leveraging all of the existing dominant libraries in the Java eco-system (Spring, Hibernate, SiteMesh, Quartz) is becoming more clear. There is no doubt that the codebase and libraries being in Java provide a significant performance improvement over Rails (100% Ruby) in my view. Grails is a mere Groovy facade onto a well integrated set of libraries, I've been saying this at ever presentation I've given about Grails since day one. This is one assertion Charles is most certainly correct on.
  • We also see these same benefits for people who need a reasonable migration path. Questions like "how can I use my existing Hibernate domain model?", "Can I continue to use Spring MVC controllers?", and "Can I inject and re-use Java services?" all have a clear and well defined answer in Grails making it much easier (although still challenging) to sell into enterprise organisations.
So back to the original question then, the answer is a most resounding "yes!" we could most certainly support multiple languages. But, before we get too excited lets get back to reality. Creating simple web frameworks is simple, creating tightly integrating, elegant, user-friendly frameworks is hard.

With Grails we've embraced the Groovy language idioms like builders, closures and meta-programming in a big way. We've pushed the boundaries of what Groovy is capable of doing. Now say we decided to support JRuby, and maybe JavaScript could we create as elegant a framework by making compromises to support all language idioms? Actually, in this case yes we probably could because Ruby for example as Charles says in his typically "language neutral" way "everything you can do in Groovy you can do in Ruby (plus more)". But how long would that take?

Then there is the Java integration story, which I believe Charles is only getting half of the picture here. Java integration is not just about being able to invoke a method on a Java object. Java integration is about mindshare integration, API integration, syntax integration, object model integration. JRuby has only just managed to solve object model integration, it won't ever be able to solve API, syntax or mindshare integration. What I mean by this is when i create a File, it should be a java.io.File, what about Streams do I forget about those? And the Collections API? Out the window with JRuby. Hang on, when I'm in "Ruby-land" a string isn't a java.lang.String? Telling an organisation that they're going to have to send their entire development team on weeks and weeks of training to understand Ruby and Rails is a hard sell. As Chad Fowler said recently at RailsConf, Ruby is not for "stupid programmers", which effectively means you need well trained people.

And of course then there is Agile and scalable application complexity. Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.

The problem here is that to take this approach you need two languages (one dynamically-typed, one statically-typed) that work seamlessly together. Why? In Agile one of the activities known to reduce productivity is task switching. Read any book on Lean Thinking and Agile and they'll tell you to eliminate waste by eliminating task switching. Switching language idioms is task switching and in this sense the Java-to-Groovy story is just so much stronger. A developer can easily switch between using Java and using Groovy without having to start thinking in a completely different way. This is simply not the case with JRuby.

On the practicality front, Grails 1.0 will be out by Autumn (that's Fall for those on the other side of the pond) or maybe even sooner. By supporting all these languages we'd end up in a situation like Phobos, which is basically going nowhere and does not do a quarter of what Grails or Rails is capable of.

So does all this mean I don't want to support Ruby on Grails? Hell, I would love if we could! Choice is a good thing and with the JVM this is completely possible, its just down to the old conundrum: Resources. So maybe Sun should, instead of wasting their time with dead end projects like Phobos, step up to the plate and commit resources to projects that do matter now. Like Grails.

So why should Sun do this? Well, Grails is beginning to win the battle for the hearts of minds of Java developers looking for the next big web framework. How can I justify this claim?
  • We have had a huge surge in popularity, Groovy in Action is the number one best selling book at Amazon "Java Books"
  • There are 12 sessions featuring Groovy and/or Grails at JavaOne.
  • Grails is the most popular project at Codehaus.org by a long way.
  • Over at JBoss they're scrambling around attending GroovyDevCon meetings and looking to get Groovy incorporated in Seam to bring the same level of elegance to Seam as we have now in Grails. Still, I believe JBoss are on to a good thing, keep up the good work guys ;-)
  • JRuby on Rails is being talked about, and noise is being made, but where is the real world use cases? Who is actually deploying JRuby on Rails now? No one. fact. With Grails we have people using and deploying real worlds Grails applications all over the place. In the Java space, JRuby on Rails is playing catchup to Grails and not the other way round. And now we have JRuby on Grails being suggested. How the tables are turning ;-)
  • Then we have poor old Phobos, which has managed 38 posts on the user mailing list since June last year. As Charles says, you guys are "damn smart" Sun engineers, so do the smart thing and give up guys, this is going nowhere. On one side of the fence you're saying "use JSF and forget about Javascript!" and now you want people to write it on the Server-side? I love JavaScript, but there are far more elegant languages to include on the server-side. My advice? Join Grails and help make it better and support other languages. We have solutions to most of the problems you're trying to solve now. Why duplicate effort?
  • People all over the place are discovering and enjoying Grails. It provides a solution now, everyone else is just talking about a solution.
Call me "opinionated", but one thing is for sure I said it at the end of last year and I'll say it again now. This is going to be one hell of a year for Groovy & Grails. So no Charles, you're not wrong, you are indeed right. Its just a matter of time and resources, and whether Sun are willing to to waste their time (Phobos) or commit to something special (Grails).

Friday, March 09, 2007

Grails Session accepted at JavaOne

So here's some additional good news. As well as the Grails event at Sun Tech Days my session submission has passed Hani and the JavaOne panel's strict acceptance criteria and there will be a Grails session at JavaOne! See in San Francisco in May!

PS There may well be something else special Grails related happening at JavaOne, stay tuned.

Thursday, March 08, 2007

Grails popularity surges

Well, if mailing list traffic is anything to go by anyway. The latest stats from Nabble show that Grails now has the most popular mailing list on Codehaus ahead of popular projects like Mule, Drools and even our friends on the Groovy list. Of course this could mean nothing at all, but still its nice that we have such a large community growing around Grails.

On a related note, Marcel, one of our committers, has just started up a Frappr map showing where Grails people are located.

Friday, March 02, 2007

Grails at Sun Java TechDays London '07



For those of you in and around the London area who are interested in Groovy & Grails, I'll be doing a 1-day workshop on Groovy+Grails at Sun's Java TechDays Event (Thanks for the invite guys!) on the 15th of March. The breakdown for the Sun TechDays event is as follows:
  • 13th - Day 1 - SunLive (Business Event) & NetBeans innovation/OpenSolaris Day
  • 14th - Day 2 - JavaUK & University day
  • 15th - Day 3 - JavaUK & Groovy Day
For more info about the Groovy+Grails workshop click on the charming picture of me.

Wednesday, February 28, 2007

Grails big in Jamaica


Received this a while back from Michael Baehr, just hadn't got round to posting it. Yes Grails is big in Jamaica!

Interesting to see rampant sexism is alive and well in IT. ;-)

High res versions here. Thanks Michael!

Tuesday, February 27, 2007

Glen Smith builds feature rich Grails-powered blog aggregator in 20 hours

That Grails site building phenomenon Glen Smith, the man who brought us Grails+Lucene powered search engine Groogle, has completed his Grails 20 hour challenge to build a feature rich blog aggregator.

The result, although still requiring some minor tweaks, is impressive. Well done Glen! Grails-powered Groovyblogs.org has (almost) arrived!

Monday, February 26, 2007

Interview with Agile consultancy Refactr featuring Groovy/Grails

There is a nice interview with Refactr. An agile software consultancy who have seen the benefit of Grails and are embracing it in a big way. They talk about agile methodologies, working with clients in a consultative manner, their past experiences and why they choose Groovy and Grails for a lot of their work.

There views reflect the essence of Groovy and Grails and the appeal to existing Java developers with its tight Java integration and seamless integration with legacy Java systems.

PS Grails 0.4.2 is out

Thursday, February 22, 2007

The Grails eXchange 2007 Launches

Skills Matter have launched registration for the Grails eXchange 2007 a conference full of presentations on Grails, Groovy, Ajax & Web 2.0 and JEE and the core technologies that support the Grails technology stack such as JEE, Spring, Hibernate, SiteMesh, Dojo and Quartz.

Full Disclosure: I am employee of Skills Matter and project lead of Grails

Friday, February 09, 2007

Grails 0.4.1 out, Groovy just got more dynamic

Haven't posted in a while, but the focus for the last few weeks, Grails wise that is, has been getting 0.4 out and then putting out a sensible point release from community feedback. Grails 0.4.1 is that point release and is out now.

So now that things have settled down a bit I want to talk a little about one of the features in Grails 0.4 that really excites me. It is called the ExpandoMetaClass and what it does is bring to Groovy easy addition of dynamic features kind of like in Ruby's meta stuff and Javascript's prototype object.

Groovy has always had the underlying infrastructure to make magic happen, it has just been hard to get to for Joe user, particularly when coming from other languages with these features. In Grails, this is no longer the case and the plan is to move this functionality into Groovy core in the future. So how does it work in Grails?

Well say you have a class, it could be a Java or a Groovy class, and you want to add a method to it. Let's take java.lang.String for example. Say you wanted to add a new method that takes an existing String and swaps the casing of the String so upper case letters are in lower case and vica versa. This is how you do it:


String.metaClass.swapCase = {->
def sb = new StringBuffer()
delegate.each {
sb << (Character.isUpperCase(it as char) ? Character.toLowerCase(it as char) :
Character.toUpperCase(it as char))
}
sb.toString()
}


assert "UpAndDown" == "uPaNDdOWN".swapCase()


Job done. Notice the special use of the implicit "delegate" variable that equates to "this" inside the method. Now the nice thing is it is not just methods you can do this for. You can add constructors, properties, instance methods, and static methods (checkout the docs for more info) on any Java OR Groovy class. Hopefully this will help make Groovy Meta programming more accessible.

Wednesday, January 17, 2007

Of ActiveRecord/GORM and DAO Patterns

Emmanuel Bernard of the Hibernate team has an interesting post about his dislike for the ActiveRecord pattern which Grails' ORM tech GORM uses. The interesting thing here is that he points to EJB1/2 as an example of the failure of this pattern.

My personal view here is that EJB1/2 failed because it was god awful, not because it used the ActiveRecord pattern. It was configuration heavy, tied you to the technology by being totally obtrusive, and forced you to think about ORM too much. These are the reasons for its failure.

As far as ActiveRecord from Rails and GORM from Grails go the nice thing about these is how remarkable simple they are to use with zero configuration. This is the power and benefit they offer.

Also you can think in an entirely abstract way about the underlying persistence mechanism. For example with GORM at the moment it is backed by Hibernate, but in the future we plan to implement support for JPA and even possibly support for using GORM ontop of Tangasol Coherence or Terracotta so you can use Grails on top of a data grid solution for massively scalable applications.

With GORM not forcing you to extend any base class and being totally unobtrusive this is all possible. The reality is Java frameworks force you to have a DAO layer, its not out of choice that they exist. Still this is not an insurmountable problem, I'm surprised there aren't more AOP based solutions around. In the meantime GORM is solving real problems.

Tuesday, January 09, 2007

Groovy 1.0 + Grails & Compass/Lucene searching!

What a pleasant surprise it was to get back from my holiday to discover that Groovy 1.0 is out. That is pretty awesome stuff, congrats to the core Groovy guys. Great work!

On the Grails front there has been some nice user contributions over the past week including a great tutorial on how to integrate search with Compass, Hibernate and Grails

However, the story doesn't end here with Glen Smith contributing another fantastic article plus source code about how to integrate straight Lucene into a Grails application with his Groogle search engine he developed in Grails. Nice.

Looking ahead we should have Grails 0.4 out by the end of the month which will represent a huge milestone for the project with it being packed with new features. Stay tuned.

Thursday, December 21, 2006

Groovy gets official backing and a full time developer

The events that have led to this announcement have been teetering in the background for a while now, but it is now official as published by eWEEK: Big Sky Technology (of No Fluff Just Stuff fame) has hired core Groovy developer Jochen Theodorou to work on Groovy full time.

This is huge news and means Groovy, for the first time, has full time resources to call on and shows that regardless of Sun's position on JRuby, Groovy is here to stay. 2007 is looking like a great year for Groovy & Grails :-)

Tuesday, December 19, 2006

Grails JavaPolis 06 Interview

Bill Venners from Artima interviewed me about Grails at JavaPolis 06 the result of which can be heard here.

Friday, December 15, 2006

Grails + Open Laszlo Integration

The community that is building around Grails is quite amazing to see. Not only has the wiki been translated into three languages (Chinese, Korean and Japanese), but we users contributing code all over the place.

The plug-in system is going to be included in the 0.4 release, but is actually fully working in SVN at the moment, and we have users taking advantage of it already with an OpenLaszlo plugin that lets you generated a Laszlo CRUD application from a Grails domain class.

For those of you who don't know OpenLaszlo is a Rich Internet Application (RIA) framework that allows you to generate Flash or Ajax applications using a more domain specific mark-up. Checkout the examples.

Awesome!

Grails: The JavaPolis Report

Well I'm back from JavaPolis 06 now after presenting Grails at a session there. I must say I was very impressed by the setup and venue they had at JavaPolis. It was a lot of fun, the only downside being the dodgy wifi.

Back to Grails though, it was a really enjoyable session with a mostly packed room. I got a strong feeling that people who attended really began to understand the essence of Grails and how it is not just a Rails clone. Yes that is right people *shock, horror* there are lessons Rails can learn from Grails too ;-)

The other enjoyable part was that I got to see the print version of my book for the first time and handed out 3 copies of it at the session. It was a real relief as it was much harder work than I imagined, but now it is done and the focus is to implement the key features on the Grails roadmap.

Other than that I got to chat to some interesting people from I21, Oracle, Sun, Google, JBoss and so on making it all good fun. It was good to get to chat to Charles Nutter from JRuby again who was once again extremely sensible in suggesting there is a lot of cross over between what we are doing and more ideas should be shared.

Overall a very successful trip that opened a lot of eyes. 2007 is going to be a big year for Groovy & Grails.

Tuesday, December 05, 2006

Grails Live Webcast + Groovy RC1 is out!

Couple of things, first off there will be a live broadcast of the Groovy+Grails User Group (GUG) Meeting to be held in London thanks to our kind friends at Oracle. Registration is free, the only downside is that you will need IE6 for it to work, so whip out Parallels where appropriate ;-)

I will be speaking about dynamic tag libraries with Grails and John Wilson will be going in depth about Groovy's MetaClass, which has now been re-worked and is out in the wild thanks to the release of Groovy RC1!

Congrats to the whole Groovy team for a fantastic job, 1.0 is just round the corner!

Friday, November 24, 2006

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!

Friday, November 10, 2006

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.

Thursday, November 09, 2006

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. :-)

Monday, October 30, 2006

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!

Monday, October 09, 2006

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."

Wednesday, October 04, 2006

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!

Tuesday, October 03, 2006

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.

Monday, October 02, 2006

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!

Monday, September 18, 2006

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.

Sunday, September 10, 2006

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.

Tuesday, August 22, 2006

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!

Monday, August 21, 2006

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.

Friday, July 28, 2006

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!

Tuesday, July 18, 2006

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 ;-)

Friday, June 30, 2006

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!

Wednesday, June 21, 2006

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.

Monday, June 05, 2006

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.