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.

Wednesday, May 24, 2006

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

Grails & Oracle: First Grails tutorial on Oracle site

Nice to see Oracle re-affirming their committment to Grails by posting the excellent Grails on Oracle 10g tutorial written by Tug Grall onto the main Oracle developer website.

The tutorial walks you through how to setup Grails with the Oracle DB and Application Server including advanced configuration to use OracleAS shared libraries. Great stuff!

Tuesday, May 23, 2006

Grails: Using Acegi Security for authentication

The great thing about Grails is that although on the surface it is simple and easy to develop with, underneath there is all the power of Spring & Hibernate.

As an example to perform authentication with Grails you could use action interceptors as described in the controllers documentation or alternatively if you want the power of declaritive security that a framework like Acegi for Spring offers then the underlying Spring configuration is there. In fact somebody has already done it and written a neat little walk through on how to go about configuring Acegi to work with Grails.

Power and simplicity, the perfect combination :-)

Codehaus Update: The distributations are available to download again, the images on the site are still broken, but the mailing lists are up! CVS is still down at the moment, but I've received assurances that it will be operational again soon.

Saturday, May 20, 2006

Grails: Back from JavaOne / Codehaus Status

Well I'm back from JavaOne which went fantastically well (despite a minor hickup in the Eclipse demo!). Grails was well received and there seemed to be a lot of interest which is excellent. I met some interesting people, like members of the Hibernate and Spring teams and many of the IDE developers like those from JDeveloper, NetBeans etc. showed an interest in developing plug-ins for Grails which is excellent news.

I will be posting the slides I presented at JavaOne shortly, in the meantime though just a bit of a status update with regards to the Codehaus servers. It is damn annoying that the server went down over JavaOne and I don't want those who attended the session to lose interest.

Currently though the mailing lists, CVS, and the website are down. The Codehaus team are working as hard as they can to restore the site, I will post further updates when all services are working again, in the meantime if you want to get hold of Grails you can still download the snapshot builds from the Canoo build server and the Wiki is still available for the documentation.

Monday, May 15, 2006

Grails: Grails has Oracle's backing

Hello from the Wine Country! I'm currently in Sonoma north of San Francisco and will be heading to JavaOne in a couple of days! In the meantime the huge news is that we are getting more major players behind Grails. Every major open source project needs backing from the big players in the industry and Oracle have made a commitment (Thanks tug!) to get behind Grails which is fantastic news.

Its not quite clear at this point what that commitment will entail (I will be holding conversations at JavaOne), but the fact that such a huge organisation is backing Grails is a clear sign that Grails is making an impact and has the potential to succeed in the enterprise market.

In the meantime interest continues to gather pace with more committers and more interest so if you're coming to JavaOne remember to sign-up for the 2 sessions on Grails and see you there!

Thursday, May 11, 2006

Off to JavaOne 2006

Well I'm packing my bags and am off to do some site seeing before popping into the JavaOne 2006 conference. If you havn't signed up for the Grails session and are interested in attending get on over there and do so! :-)

We should have the 0.2 release of Grails out shortly after JavaOne with several improvements and new features, but if you can't wait for that checkout the 0.2 snapshots on the downloads page.

See you there!

Friday, April 28, 2006

Grails: Interview on JavaPosse

There is a podcast interview with yours truely up on JavaPosse discussing my experiences with Groovy, what makes it so powerful and how Grails fits into the bigger picture of J2EE development.

Thanks to Dick and all the JavaPosse guys for taking their time out to chat to me, it was a most enjoyable experience.

PS I was a bit nervous in the beginning and I think it shows!

Monday, April 24, 2006

Grails: Ruby on Rails feeling the heat

Up until now I have not wanted to be drawn into a Grails vs Rails debate, clearly not wanting to start a flame war with the Ruby community, but it seems the Ruby/Rails people are doing that job perfectly well without my intervention and feel rather threatened by Grails as they keep bringing it up in interviews and comments on blogs.

In the latest podcast on the Ruby on Rails website they have an interview up with Tim Bray. They talk about Rails and the future of dynamic languages, and they brought up the topic of Grails in which the interviewer said and I quote:

"I heard that some guys had done a Groovy on Rails or Grails framework and didn't quite get it right."

Now, I encourage said interviewer to qualify his statement and point me to a reference where it says we havn't got it quite right. Clearly, you havn't tried Grails my dear boy and making such statements without the facts to back you up is really rather silly, and typical of the response from the Ruby community.

I follow all Grails news quite closely and not one user has said we havn't got it right in fact all the users on our mailing list that have taken up Grails feel we have got it very right with comments like Grails is "The Holy Grail" of Java web development and that its productivity is on par with Rails and for Java developers even more so because they can fully utilise their existing API knowledge.

So far there has yet to be a negative post about Grails from a Java developer, I'm sure there will be one, but I'm still waiting.. so the question is: are the Rails people feeling the heat?

The fact that they even mentioned Grails in this interview and have not mentioned any other Rails-like frameworks is a sign that they are worried and they should be. Grails takes Java integration to a new level. A level that will never be reached by the likes on JRuby on Rails, which really only serves as a useful proof-of-concept.

Good luck guys, Grails may have only just had a 0.1 release, but it has a growing following, greater integration with Java and an aggresive project plan and for the first time you have real competition.

Tuesday, April 18, 2006

Grails: The Render method and Ajax

Users of Ruby on Rails will be familiar with the 'render' method which allows rendering of responses from a controller. Grails has a similar mechanism, for example rendering text is as simple as:


render 'hello world!'
or
render(text:'world',contentType:'text/xml')


You can of course also render templates and views via the method (for more complete documentation see here), but what makes Grails' render method that little bit different is its support for markup building.

With other Java frameworks I've used I ended up with loads of partial views implemented as JSP or velocity views. Each with the sole responsibility of rendering some XML or JSON. With Grails this is rarely needed for pure XML responses (note, I would never condone defining layout in this way this is purely for data oriented XML rendering). Rendering XML is made infinitely more simple:


def results = Book.list()
render(contentType:'text/xml') {
books {
for(b in results) {
book(title:b.title)
}
}
}


The above results in the following XML snippet being rendered to the response:


<books>
<book title="The Shining" />
<book title="Along came a Spider" />
</books>


When you combine this with how Grails controllers reload automatically on changing it makes writing ajax responses a breeze. But, there is more! Grails has inbuilt support for OpenRico so if you want to write Ajax responses in Ricos required format this can be done as follows:


render(builder:'rico') {
object(id:'bookUpdater') {
books {
for(b in results) {
book(title:b.title)
}
}
}
}


Rico will then automatically look-up your 'bookUpdater' instance and delegate the response to it passing the contained XML to the updater for handling.

I don't normally like talking about unimplemented features, but thought it might be worthwhile just to highlight the power of the builder concept in Groovy as I don't believe that many grasp the potential of builders and their usages. One of the upcoming features in Grails is a JSON builder which will be available via the render method so say I wanted to render JSON instead of XML? We just change the content type defined in the render method:


render(contentType:'text/json') {
books {
for(b in results) {
book(title:b.title)
}
}
}


And the resulting output would be JSON instead of the XML without any change to the structure of the builder code itself:


{
books : [
{ title: 'The Shining' },
{ title: 'Along came a spider' }
]
}

Monday, April 17, 2006

Grails.org Live

Thanks to John Wilson of the Groovy development team who was on the ball enough to snap up the domain when it became available Grails has a new web home at www.grails.org!

Grails: Getting Started on Oracle 10g

Just got back from my easter break with the family and its great to see such fantastic tutorials being posted about Grails already including this one on how to get Grails up and running with Oracle 10g Express Edition.

Not only does it go through how to setup the database side of things, but it also talks you through deployment on OracleAS via a Grails WAR and improved deployment options. Great stuff.

Monday, April 03, 2006

Grails: Tag Libraries & The Power of Closures

When we started developing Grails we wanted to support a dynamic view technology that allowed scriptlets in Groovy instead of Java, but without falling into the trap of having scriptlets intermingled with HTML code a trap that many Java developers have spent years trying to avoid.

Historically though JSP custom tags have always been a bit of a pain to write, they're designed to cover every variation of tag under the sun, hence the API is complicated and the tag lib descriptors verbose. Grails is all about simplicity, so how do we avoid introducing this level of complexity into our Grails applications. The answer came in the form of anonymous code blocks or closures.

I would say 90% of the tags that are written for JSP out there fall into one of three categories: simple, logical or iterative. There are those more complex tags that have relationships to each other via nesting, but the vast majority are of the aforementioned type and Grails is about making the most common cases easy, but still allowing the flexibility to scale to the more complex (thats why we still support JSP).

So what have closures done to make custom tags easier? Well Grails allows you to define a custom tag as a JavaBean property. No descriptors, no configuration, and everything is reloaded at runtime so no need to restart that application server. So lets look at an example from the tag library that ships with Grails (simplified for clarity):


class ValidationTagLib {
@Property eachError = { attrs, body ->
def errors = attrs.bean.errors
if(errors) {
errors.each { body(it) }
}
}
}


Each tag library is simply a class that ends with the convention "TagLib". The above example contains an "eachError" tag that loops through each error contained within the "bean" attribute and invokes the "body" of the tag. Note how the body of the tag itself is a closure and hence callable, the attributes are a map. To use this tag we simple call it from our GSP no need to import the tag library or anything, the error itself is available using Groovy's implicit 'it' variable which was passed to the body closure:


<g:eachError bean="${myBean}">
<p style="color:red;">${it.defaultMessage}</p>
</g:eachError >


Now thats pretty neat and simplistic, but this is where using closures for defining tags becomes really powerful. How about we want to re-use our "eachError" tag else where? Say we want to implement a default rendering tag called "renderErrors" that renders our errors as an HTML list. Well we can re-use the "eachErrors" tag to accomplish this:


@Property renderErrors = { attrs, body ->
def markup = new groovy.xml.MarkupBuilder(out)
markup.ul() {
eachError(attrs) { err ->
li( message(code:err.code) )
}
}
}


The above code creates a new MarkupBuilder instance which is used to generate an HTML list re-using the eachError tag defined previously, it actually uses a third Grails tag called "message" to retrieve the message for the error code. To call the "renderErrors" tag we simply do:


<g:renderErrors bean="${myBean}"/>


Grails users can of course customise the inbuilt tags and add brand new ones simply by adding new tag library classes in the "grails-app/taglib" directory. So there you have it, custom tags have never been easier, and your markup can remain scriptlet free without the need to invest huge amounts of time creating a custom JSP tag library.

Wednesday, March 29, 2006

Grails 0.1 Released

Yes, that time has come, the first 0.1 release of Grails is out and I'm really pleased all or our hard toil has resulted in such a quality release. Grails has come a long way, I'm currently developing my first live project with it and it is a joy to use. There is still much to do though and we have some exciting features planned.

Over the coming weeks I will be posting on this blog about some of the features of Grails that I believe make it unique and not just another Rails clone. So stay tuned, the Grails journey has only just begun. :-)

Wednesday, March 15, 2006

Grails at JavaOne 2006

Well the session listings were posted a few days ago on the JavaOne 2006 conference website and if you browse into the Web Tier track you can see the details of the Grails session (BOF-2521) I will be presenting. Here's a quick link if you're lazy.

By that point Grails will (hopefully) have been released and a bit more interest garnered, but in the meantime checkout what will be covered.

Another interesting note is that there are 5 sessions (yes 5! There may even be more as I did my best to go through all the sessions but may have missed one) covering or related to the Groovy language. Making it the most covered dynamic language at the conference which is great news.

Also, don't forget to take in Guillaume's session on 'Simplifying Enterprise Development with Scripting' (TS-1246) and to those who are going to be there (Bob, you coming? ;-), see you there!

Saturday, March 04, 2006

Groovy & BeanShell: Dynamic vs Scripting Languages

In my previous post I talked about the fundamental difference between Groovy and BeanShell and in one of the comments I was asked to elaborate on why exactly Groovy is dynamic and BeanShell is not. So here it, BeanShell is a scripting language, it is to Java what VBScript is to VB, the syntax is near identical, you can copy and paste Java code into BeanShell and vica versa. This makes it highly useful for doing things like testing Java code in isolation, or trying out a Java API through an interactive BeanShell console.

It is 'dynamic' in the sense that it uses reflection to achieve a lot of these goals, but beyond the aformentioned use cases I would not choose BeanShell over Java to implement say a build system, or a my web actions, or do text processing, advanced regex, output templates, as a view technology, this list can go on...

The reality is that BeanShell does not provide any productivity gain so to choose to use it for a task over Java (rather than use it to script Java) has no real benefit and this is because it does not have any of the true features of a dynamic language like Ruby or Groovy. I'm a big fan of WebWork and I've been using Groovy to write XWork actions because the advantages are clear, I can save/reload changes, I can use closures to manipulate and sort my data model:

projects.findAll { it.status == 'open' }.sort { it.name }

I can use GStrings, a concept known as string interpolation in languages like Perl and Ruby, and multi-line string support to easily manipulate strings:

def user = User.get(1)

def message = '''
Dear ${user.name},

Thank you for registering with xxx site,

Your password is: ${user.password}.

See you soon!
The Site
'''


There are many more examples of the kind of expressiveness mentioned above that Groovy allows in its syntax, but more importantly than all these syntatic niceties and what makes Groovy truely 'dynamic' is how methods (as well as constructors, properties etc.) are dispatched. Groovy has the concept of a MetaClass and it contains the methods that a class 'really' has as well those added dynamically at runtime, allowing new behaviours to be attached to new and existing classes. This is a feature Grails uses extensively to add behaviours to controllers, domain classes, tag libraries etc. all while still retaining the ability to use inheritence.

The reality is that Groovy and BeanShell are not really competing with each other at all, and address different problems entirely: BeanShell the scripting language for Java and Groovy the dynamic, agile language for the JVM. That is why I hope that instead of seeing articles like those written recently, we'll see some from the same people entitled "Using BeanShell to Prototype Java Code" or "Using Groovy to Power your Build System" as writing "Groovy is rubbish, and BeanShell is great" or vica versa is really not helping any newcomer who is interested in this space make an informed decision on which is the appropriate language for their use case.

Friday, March 03, 2006

Groovy: The Ed Burnette Effect

So as typically is the case when a few positive posts arise about Groovy, an alternative view point has cropped up entitled "BeanShell: groovier than Groovy" by Ed Burnette. The article quotes only the last paragraph of my previous post about how Groovy is approaching its "second" version 1.0, conveniently brushing over and failing to comment on any of the benefits highlighted.

Unfortunately, this is where many Java developers, with all due respect to Mr Burnette, fail to understand what a "dynamic" language is and its a shame this misunderstanding is being spread. I like BeanShell I appreciate what they are trying to do and in certain circumstances would recommend it over Groovy. It is great for embedding in Java applications if you want to script say an application server or or server component, but the fundamental difference is that BeanShell is a scripting language for the Java language, whilst Groovy is a "dynamic" language for the JVM (note the difference between Java the language and the JVM).

BeanShell is essentially Java without the need to specify types, which is great in certain circumstances, but doesn't really have much productivity gain and is not in my opinion the answer to the JVMs dynamic needs. I have written a lot of code in both BeanShell and Groovy and with Groovy my lines of code (LOC) count is about 60-70% less then the equivalent Java code, with BeanShell this is about 10%, as its essentially just Java without the need for type safety.

This is also why BeanShell has managed to achieve relative stability and a small size (as highlighted in Ed's article) when compared to Groovy as its goals are relatively simple. Groovy adds new language constructs, closures, the GDK methods, builders, meta-programming etc. This is not something you can achieve without spending a longer period of time defining the language and the API. Yes, following the standardisation process there was a re-think of many of the aspects, but this is the usual process with the JSR and any standard spec. Fortunately the syntax, through this process, has been nailed down and the Groovy development team are merely focusing on improving the core of Groovy.

Thursday, March 02, 2006

Groovy: The Sleeping Giant, an Elaboration

Richard Monson-Haefel recently wrote an interesting blog post about
Groovy, titled "Groovy: the sleeping giant". The post talks about the dynamic future, which is certainly coming with the increase in popularity of agile methodologies and Ajax in particular spurring it on, and talks about how Groovy could be the solution the Java platform needs. The interesting thing for me though, is although I agree with many of the points I do disagree with some.

Firstly, I believe in a blend, its not going to be dynamic everything. The fact remains there are still huge benefits to compiled languages such as Java especially in large systems where the benefit of refactoring and powerful IDEs becomes clear. But, it is there where Groovy's true strength lies in its ability to cleanly interface with Java. In addition there are other, largely undocumented, reasons why Groovy has huge amounts of potential:
  • Meta-programming - Groovy has the ability to inject methods, constructors, properties, fields, etc. into ANY java class at runtime. Most of what AOP is used for nowadays can be achieved with Groovy's Meta-programming capability. No byte-code manipulation a la AspectJ, this is awesomely powerful and in combination with Groovy's support for closures and builders it makes it possibly to create mini-DSLs
  • Power Features - Although there has been a lot of argument about the optional parenthesis, and the optional semi-colons etc. There are very good reasons for these things being optional: For combining closures and method calls to allow builder syntax. Builders and closures are very powerful, especially when you consider you can pass the same closure to a multiple different builders. Why you say? Well one may output a tree structure as XML another might render a GUI from it, I'll leave the rest to your imagination.
  • True Object Orientation - Everything is an object in Groovy, you may think this is strange given Java has primitive types, but all the auto boxing and unboxing happens at runtime, no Java 5.0 required. This means you can have methods on numbers, overload operators by adding a specifically named method call, use advanced switch statements that don't just work with char and int.
  • Grails - Ok I'm biased on this one, but I believe Grails has huge potential to succeed in areas where Rails has unfortunately been unable to penetrate. On those thousands of companies that have invested huge amounts of money in Java and are not about to dump that $35k per CPU application server. For those who have legacy database systems that need to be mapped onto, existing Java services that need to be interfaced with seamlessly and team of developers all skilled in, you guessed it, Java.
So there you have it, Groovy has had its problems, and the FUD that has been spread hasn't helped. But, Groovy is still young, 10 years younger than Ruby in fact, and a fantastic amount has been achieved for it to be where it is today. I look forward to the upcoming release of Groovy 1.0.

Tuesday, February 28, 2006

Grails CVS Moved

As Grails is growing up it has moved to its own home, out of the modules directory with Groovy, into its own CVS repository

For info on how to get the latest code take a look at these instructions

Sunday, February 26, 2006

New Grails Website Live

The new grails website is up and running at http://grails.codehaus.org. The design of this one is better thought out, easier to navigate and overall a great improvement.

The site should now be less of an embarrassment when the first Grails release attracts (hopefully) a few visitors.


Friday, February 24, 2006

Well this is my first post at my new blogging home, I will be posting here as often as I can about various things mostly around web development, and in particular with Grails (http://grails.codehaus.org) which is my current project.

Stay tuned for more as Grails is approaching its first release which should be interesting :-)