"Griffin, great and growing"

That is (or was) the wording on the water tower for the humble town of Griffin, GA, U.S. of A. I once had a colleague who lived there, and he mentioned that quote with a wry smile. I almost want to say "Grails, great and growing." I've been playing around with Grails now for a few weeks. Unfortunately due to my work commitments, I tend to have sporadic spurts of play, but I'm getting more and more used to it with each session.

Clearly a lot of work has gone into Grails. Chatting on-line to Graeme Rocher, the Grails project lead, I learned that he has an hour to kill on the train from Brighton to London and back - that's an hour there, and an hour back - hence he has time to work on Grails. Time well spent by the looks of it. At v0.4.2. Grails is already quite complete in terms of the architecture and the basic components that you need in a web development framework. What I like most about Grails is that underneath, you're running Java, and Grails uses proven Java libraries like Spring, Hibernate, and Sitemesh. The fact that you mix in a bit of Groovy to glue it all together is a wonderful compromise between productivity and scalability.

I think that's what bothered me about Ruby on Rails. Productivity is great, but at the end of the day, you're still running Ruby, and underneath it all, it's Ruby, and the web server that you use for Rails is essentially single-threaded. Now, before this starts a flame war, I have read about how Rails developers accommodate this to accomplish scalability, so I have to take their word for it that it accomplishes their desired levels of performance. However, to a hardened Java developer like myself, the fact that you're effectively running Java when you're running Grails is a distinct benefit. If I haven't said it eloquently enough, I think Graeme Rocher himself said it best in this entry on his blog.


I think I liked the following quote from that entry best:

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.

That hits the nail on the head in terms of what I was trying to explain earlier. "Scalable complexity" - Graeme, hope you don't mind if I use that in a meeting somewhere to build up my Dilbert points. ;-)

What's interesting in this debate is the clear sides forming within Javaland on the merits of adding effort to Groovy or of shoehorning JRuby into the mix instead. Personally, there's no debate. As Graeme points out, if you read that entire entry, if you're dealing with Groovy, you're dealing with Java. If you're dealing with JRuby, you're dealing with Ruby, with it's own of (different) threading model, I/O, API etc. So you're going to have to be familiar with both Java and Ruby. With Groovy, you're only dealing with Java. Considering Groovy is equally effective and productive, it is hard to understand why Sun are trying so hard to undermine their own language.

As I've indicated previously I've long felt Java technology suffers from really bad marketing. Often the concepts are great, but the name alone prevents you from daring to put a book about it on your shelf, for fear of being shunned like the lepers of old. No offense, but Groovy is a really horrible name for a technology that wants to be taken seriously. Perhaps that's something that the Groovy stakeholders should consider changing. Perhaps that's why Sun are too scared to strap themselves to that wagon. Of course, I don't really consider myself a marketing type, so I won't attempt to offer an alternative. I do know names like "C#", "C++", "Perl" and "Delphi", for instance, can be talked about without the need for copious blushing, or girly snickering under the table at each mention of the name. What's in a name? Maybe more than we really think. What do you think?

The End of the Tunnel

Ok, so I've finished the book. And first off, I should say that I think Jason Rudolph is a very good author in communicating Grails to the newbie. He really has a skill in taking you organically into the subject matter, and his writing style is relaxed and 'easy on the eyes'. Nice one Jason!

So I finished my last post as I was about to head into authentication. Again, I was impressed with how easy it was to add 'security' to my application, at the method level. It was a closure at the top of my controller class, and I was done. Very slick. I do recall this is how Rails works as well, so wasn't completely taken by surprise.

The rest of the book went into tweaking the UI with improved layout, which uses Sitemesh. For those not familiar with Sitemesh, it was created by the very capable Joe Walnes, and was part of the OpenSymphony suite of frameworks, along with other capable frameworks like WebWork, and OSCache. I've used Sitemesh on former web application projects and it was very capable. Grails uses Sitemesh under the covers but you don't actually realize it until you see the Sitemesh configuration file in the WEB-INF folder - though you don't actually have to edit the file at all. It's just, there. There's also some coverage of CSS tweakage, but that was fairly standard and as expected.

Grails has built-in support for testing, just like Rails. It generates placeholder test classes for you to embellish. I won't testify to being an uber-unit-tester, but it's there, and should I develop the discipline further, it'll be handy. Testing your application, once you've filled out the tests, is as simple as 'grails test-app'.

Grails has built-in support for logging using log4j. From what I can tell it logs error messages by default. I'm not sure if you can use other levels, like INFO or WARN, but there must be a way. The author didn't indicate what that way was though. I'll have to look into that. Nevertheless, there are separate log4j.properties files for development, test and production, which is again slick. It's never pleasant leaving a logging level at DEBUG on a production deployed application.

Lastly there's the deployment of your application. A very nice touch is that 'grails war' will package your app for you in your chosen environment (dev, test, prod), with all the targeted settings, into a neat deployable WAR. 'Production' is the default but you can type 'grails dev war' for instance, and you'll get a development WAR with your development settings.

So, what conclusions do I have? Well I certainly am very impressed with how 'complete' grails is. At v0.4 I almost expected to see lots of "To be done" comments and sections, but really it's quite mature for such a young project. I've done some reading in blogs and such, and there are doubts cast about its maturity and readiness for enterprise deployment, but it's clear from the core developers intent that enterprise is their target. I certainly can see how Grails will be a productive framework to develop with. And I do plan to use it on a greenfield project I'm about to embark on. It's a personal project, but one aimed for an enterprise environment. So we'll see how it goes. I'm still ignorant as to how Grails works once deployed. Are those Groovy scripts reinterpreted on every request/response, or are they compiled to bytecode on the first execution and reused from there. I don't much fancy a 'reinterpret' design to a web application that I'd like to scale to high load. But these things can be subjective, and the proof of the pudding is in the eating.

Pudding anyone?

The Angels Sang

The angels sang, no doubt about it. And it wasn't just a benign little "Aaaaah", it was like a full Mormon Tabernacle Choir sonate.

Man, I can't believe how impressed I am with Grails. Where on earth do these Grails developers find the time to implement all this stuff, for free?! Since my last post I've been tweaking the basic auto-generated scaffolding and code that Grails produces by itself. I've tidied up some error messages, which in itself was impressive in how Grails scaffolding builds validation and error notification automatically into form submission. Validation with the 'constraints' static object is very easy. Customising your error messages follows a class.action.constraint format, also - dead easy. You edit or add to a single messages.properties file and that's it.

And here it's worth mentioning the 'flash' context, which is something I'm not aware of in other Java web frameworks, but is also something borrowed from Rails. In Java you typically have page, request, session and application context. For short-lived objects, you usually place them in page or request context. Session is more long-lived, and application obviously is the longest lived in terms of web application object lifespan. Flash context slots in somewhere around page and request, in that while page and request contexts 'die' after a response has been made to the user, flash context lives until the next request. So it lives sort of from 'response - next request' and then Grails cleans it out. Why this is useful is because often, after you've completed a use case, you want to redirect your user to a different URL, not just simply forward them. With page and request context, anything you place in those contexts will be gone when the redirect request comes back. With flash however, objects placed in 'flash' context live until the redirect request is completed. I recall from past web applications, where something like that would have been useful. Giving a confirmation message with a redirect, for instance, is very useful. I can't recall off-hand but most likely I placed stuff like that in the session context and nuked it after the next request was done, which is probably similar to how it works in Grails, but I didn't have a formal concept for it; more like a stab in the dark.

Anyway, moving along. Adding taglibs is also very easy, and has a special place in a Grails application. The conciseness of Grails - or actually - Groovy code, is very convenient here too. I followed the book and created formatting taglibs to format my numeric, date and currency fields, and all within a minute or two. Of course, I was surprised that these tags weren't already in the core Grails taglibs, but hey, it's only v0.4 at the moment, so, baby steps.
This also bears mention of the GString (*snicker*) class which allows for transformation within a String. That probably doesn't make much sense, so allow me to copy and paste from the official Grails API docs:

Represents a String which contains embedded values such as "hello there ${user} how are you?" which can be evaluated lazily. Advanced users can iterate over the text and values to perform special processing, such as for performing SQL operations, the values can be substituted for ? and the actual value objects can be bound to a JDBC statement.

Can't deny some of that strikes fear into me - I mean linking a String to JDBC SQL operations just screams 'security hole', but I probably don't fully understand that definition. I'll be sure to investigate this more in the days to come. But it does mean you can do things like the transformation indicated in that definition, and determine the final value in real time.

Now, one thing that blew me away was how easy it was to setup search capabilities, using default search syntax for simple searches, but also integrating very intuitively with Hibernate's Criteria building. Here again, no XML files to configure, just fairly straight-forward, simple code and naming conventions.

The similarities of Grails to Rails are very obvious, and one can see the Grails developers have done a good job with this. I find myself understanding this book very quickly simply because of my understanding of Rails. Those of you who haven't ever read up on Rails may find some concepts confusing at first. So take my word for it, they are good ideas. Each controller action is defined by a closure, and convention over configuration means you don't have to tweak 2 or 3 XML files to add an action to your controller. View resolution is determined by your controller and action, and the brevity with which you can accomplish much is also a Rails testament.

Now if you're anything like me, you're probably thinking "Ok, all of this is cool, but honestly, this is not complex stuff, and all this proves is that Grails accomplishes simple goals, simply." True, very true, which is why it's reassuring to see that one of the headings of the next chapter, "Not Just For Intranet Apps", is "Beyond CRUD". This is where I add authentication to my application, with specific permissions to specific views etc. Stay tuned as I delve into the unknown.

Grails Kick - er, Quick Start

Well I'll be. I've just completed the Grails Quick Start and I must say, I almost heard the angels. They weren't singing yet but I think I heard them warming up their voices.

The Grails Quick Start is fairly intuitive to follow. Just do what the instructions suggest and you should be fine. I won't run you through it blow by blow because it's online for your own viewing convenience at: http://grails.codehaus.org/Quick+Start, but this is a précised summary of what I did.

I ran a script to create the project outline. That worked as advertised. At this juncture the Quick Start points out that you can change the data source for your brand spanking new web application if you so desire. Or it'll start with an in-memory HypersonicSQL DB for your convenience so you can get up and running immediately. I'm good with the HSQL DB for now. I'm just having fun right now anyway.

Following this you create a domain (or model) class, using a Grails script. The Quick Start offers a 'Book' domain class with a 'title' and 'author'. Just do that. Then in a Groovy bootstrap script you setup some test data. Easy-peasy. Done.

Lastly, like any well-behaved MVC prodigy, you need to create a controller for your model. Again, call your controller 'Book', and Grails will create a 'BookController' for you. Schweet. That worked too! So far so good.

(Quick aside: the Quick Start indicates you can do a 'grails generate-all' and give that the 'Book' name and it'll create your model and your controller, but I did each step on its own. Now that I think of it, I had to do a 'grails help' to figure out that they do a 'grails create-controller' because the Quick Start doesn't indicate that, but I'm sure generate-all will accomplish the same thing at the end of the day.)

Now of course you need to have view stuff, but like Rails, Grails offers the concept of 'scaffolding' which provides the basic structure for CRUD (CreateReadUpdateDelete) operations on your brand spanking new domain/model class. So a quick edit of my BookController to tell it to scaffold the Book model class, and I'm ready to rock and roll.

The rock and roll part is as sexy and as simple as typing 'grails run-app' from my project root folder. Baddabing! My web application launches. I haven't yet looked at what Grails uses but it's obviously a lean instance of Tomcat or Resin or some such. That's irrelevant to me at this time, since I'm itching to find out whether my browser can make sense of: http://localhost:8080/myproject/book/list.

I type in the URL, hit Enter and wait with pregnant anticipation.

Whooooot! It works!

I am impressed. Like I said earlier, I'm sure I heard the angels doing voice warm-ups. I get a list of the books I typed into the bootstrap thingy, and I can add books, delete books, or go to a home page for my web application that indicates which controllers exist in my web application. And I didn't type a single line of view 'stuff'. This is neat! It took me all of about 2 mins to get a Java web application up and running. I'll be done with my new project in about 4 hours. Okay, okay, I'm getting ahead of myself. But so far so good, which is not often the case when I play with open source (i.e. open sores) stuff.

My curiosity now wants to know how Grails will cope with changes to my domain, controllers and views. That's still a bit of an unknown. Onwards we march.

Grails - The Journey Begins

Grails has a fairly neat and intuitive home page. You can find the most important stuff there like, er, well, documentation. Imagine that! Along with an 'Installation' page, and a 'Quick Start' page, there's also a 'User Guide', 'Tutorials' and 'FAQ'.

There's 'Reference' links as well as the obligatory mailing lists, wiki, issue tracker and SVN pointers.

The content of the main page bares some testimonials including one that says:

"I found Grails and it was like the heavens opening and angels singing "AAAAaaaaawh". - Les Hazlewood

Wow, that's quite a testimonial. So far I haven't heard the angels, but I'll let you all know, the moment I do.

Nevertheless, while listening out for the angels, I followed the instructions from the Installation page and all went according to plan. Installed Grails, set some necessary environment variables and typed 'grails' in expectation of a help screen and guess what happened... it worked! Pleasantly surprised by this, since a lot of open source projects I've tried DON'T work 'out of the box'.

One point to note is that from previous sandbox activity on my part, I already have Groovy installed on my machine, so I wonder if that installation would have still worked if Groovy wasn't installed. *shrug* I'm not going to investigate that further. I'll leave that as an exercise for the reader. *grin*

In Search Of The Holy 'Grails'

Are you like me and you develop in Java but you keep encountering this constant raving about this Ruby On Rails phenomenon that keeps getting so much bandwidth in the online rags? Not? Well okay, but that's been my experience, so sit there and pay attention anyway. It'll be interesting, I hope.

In preparing to develop a greenfield web application recently I decided to get my hands dirty with this holy grail known as Ruby On Rails. I have to say I was very impressed with it. From the outset I was constantly thinking "Hmm, well that's quite clever, I wish Java web development was more like that." Honest, over and over again. From how it creates this complete project skeleton, to how the scripts generate all this stuff for you, to their philosophies of Don't Repeat Yourself (DRY) and Convention over Configuration. And I thought to myself: "Self, this Ruby On Rails thing isn't new anymore, and you haven't done Java web development for a while, so why not see if there's anything that's been done in the Java web world to address this approach that Ruby on Rails has taken?" So I went to look for something holistic in its approach, like Rails, but that leverages the wealth of Java technology that already exists.

At first I didn't find anything that was obvious from the usual headlines on The Server Side, or on InfoQ or on OnJava, or Javaworld and so on and so forth. The usual suspects of Struts 2 , Tapestry and Spring's WebMVC grabbed most of the headlines, and I was trying to get away from their XML configuration conflagration (sorry, that was a mouthful). I did encounter a web framework called Stripes, which seemed to make a reasonable effort, but that still wasn't quite what I felt I was looking for. Then by chance I came across Grails.

As the name implies, it borrows heavily from the philosophies of Rails and at last I'd found something that 'seemed' to do what I felt a Java approach could do, if it mimicked Rails. Like Rails, Grails uses Groovy just like Rails uses Ruby. Groovy is, for all intent and purpose, a Java scripting language. Grails uses Groovy to empower itself and accomplish various tasks with a minimal set of lines. Grails was initiated by Guillaume LaForge and founded by Steven Devijver and Graeme Rocher - who is the current Project Lead. It's still fairly young but I've communicated with an Australian, Glen Smith, who is using v0.4 in production projects. As a South African, trusting an Australian defies common sense, but hey, us Southern Hemispherians have to stick together.

So I thought I'd try out Grails and log my experience here. If you just kick the tyres it won't reveal much about the vehicle. You need to take it for a test drive, and not just amble up and down the road.

So seatbelts on, here we go.