Choice is good, too much choice is bewildering

Ever been to a restaurant that has a 30 page menu, and you have one hell of a job trying to decide what to eat? I have. It's very bewildering. I like choice. Give me a choice between fillet, rump and sirloin, and I'm okay with that. But give me a list of 40 pizzas and I have a dizzy spell.

Now take that a step further, where you find a restaurant that you're really impressed with. You had their Chateau Briand and loved it the last time you were there. You walk in with your mates, sit down, and look for the Chateau Briand on their menu, and it's not there. So you ask the waiter:

"Erm, what happened to your Chateau Briand?"

Waiter: "Oh we don't offer that anymore, but now we have this really scrumptuous Carpet Bagger steak!"

You: "But I really liked the Chateau Briand, what was wrong with it?"

Waiter: "Oh nothing but the chef got tired of making that. He felt it was becoming passé and wasn't sexy enough anymore, so he stopped preparing that. But he's now really plugging his CarpetBagger steak!"

This morning I had a 'debate' online with a mate of mine, Chris Miller. He's an annoyingly smart developer who more often than not wins these little debates we have. I posit, he counter-posits, I counter-counter posit, and he slam-dunk posits, and then I end up sobbing in the corner. Okay, I digress. The point is I was bitching and moaning about the constantly changing landscape that is Java Web Frameworks. The huge proliferation of Yet Another Web Framework's that is out there in the Java web space. I haven't done Java web development for quite some time now, and recently have returned to the web space because of a personal project I want to explore. I refer you to my recent posts while hitching a ride on the Grails bandwagon.

The last time I did a Java web application, I chose Webwork v1.x as my preferred Java web framework. Webwork was a great framework. A very unimposing, yet powerful framework, true to the intelligence that is Rickard Öberg, the initial developer of Webwork, before it entered the OpenSymphony suite of frameworks. I enjoyed developing with Webwork as it allowed me to focus on the business features I was trying to implement without imposing any configuration distraction, or "square-peg-in-round-hole" forcing. There were a number of really smart individuals who had a hand in Webwork development, like Mike Cannon-Brookes, Hani Suleiman and Joseph Ottinger.

Then one day, a guy by the name of Patrick Lightbody had some or other epiphany and decided that Webwork needed a complete rewrite, basically, and he started on a journey that became Webwork 2. Development on Webwork 1 ceased. Hani made a valiant effort to try to migrate some new (and admittedly useful) functionality from Webwork 2, back to Webwork 1, but he had to work to pay for all that Mac machinery he owns, and so Webwork 1.x development basically ground to a halt. A year or two later and what do we have again? Oh look, Webwork 2 and Struts are merging to become Struts 2. Imagine my surprise. Why? What was wrong with Webwork 2? It's almost like these guys just get bored and decide to rewrite stuff.

Chris (Miller) argued with me that this was irrelevant. That there was nothing wrong with Webwork 1.x that should have caused me to have to upgrade to Webwork 2, other than if I was simply trying to remain 'trendy'. Now as somebody who doesn't get out much, 'trendy' isn't a moniker I would use for myself, and it's not something I attempt to accomplish. However, as I indicated, there were features which Webwork 2 had, which would have been useful in Webwork 1. Off the top of my head, I offered 'interceptors' to Chris, as an example. So you either stick with Webwork 1 and look enviously at all those using a better way to do what you're doing, or you upgrade (probably yet again!) or you enhance Webwork 1 yourself (which I'm not sure if I'm smart enough to do, and I don't have the time). Chris contended that despite the noise that exists in the Java landscape, it's usually easy enough to sift out the wheat from the chaff and if you just focus on the small handful of wheat, you can stick with one choice for a long time before you might have any need to do the upgrade dance. This is true, though often the most-used framework is not always the best framework. Struts 1.x is testament to that.

I guess for me, the issue is the sense that there are so many smart developers out there, giving of their intelligence and time, that it's a pity there isn't more cohesion amongst them. Is it ego's that clash? Disagreements that lead to feuds which lead to divergent frameworks? It seems like there's so much time wasted because of differences of opinion, that lead to reinventions of the wheel. These reinventions mean the rest of us who use these frameworks do a lot of tail-chasing.

I guess beggars can't be choosers, and if I'm not going to contribute in some meaningful way to these frameworks, then I can't complain. Put up or shut up. True, I can't argue with that. But from an objective perspective, it's still a pity. Take for example the Java workflow space. Here's a post from Carlos Perez's Manageability blog. Just look at that proliferation! I count 40, yes, 40, different Java workflow frameworks. I mean, surely there's enough commonality in the workflow space that we don't need 40 frameworks. Is it bad co-ordination? Poor communication? What is it?

Well I don't really know, but it's annoying, and it's a pity. And furthermore there's really precious little you can do about it. Open source is a voluntary beast, so you can hardly go around dictating to developers as to what they should do with their spare time.

If you've read any of my earlier posts you will have seen that I've jumped onto the Grails bandwagon. I just really hope and pray that Grails sustains the attention of the developer community sufficiently to remain relevant for a long long time. If not, it'll be a bit of a gamble since Grails applications, by their very nature, are significantly different to most other Java web frameworks, and web development methodologies.

Postscript: The one fairly important aspect I've completely omitted here is what we get from those who are somewhat at the reins in our industry. Consider, for example, Java Server Faces (JSF). I must admit to not having played with JSF at all. However, I can't say I've found a single positive comment on JSF by those not specifically biased due to their involvement in the JSF effort. The overwhelming consensus that I have picked up on is that people feel that JSF ignores what Java developers actually asked for. That it's delivery was grossly impotent when considering its potential and initial promise. EJB is another example. Look at EJB 1.x and 2.x. Yick! EJB3 seems to finally be getting somewhere close to what Java developers have wanted all along. So does this suggest part of the problem: that the leaders in the Java space are too introspective, and they don't actually listen to what their developer masses are asking for? How long did developers complain about the lack of exclusion patterns in the servlet specification? So perhaps our fearless leaders have some blame to bear in this mess that is the Java web framework landscape.

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.

I love coffee but I hate Java beans

If you've done any Java development, you'll have encountered the all-too-popular-but-oh-so-lame naming convention of using the word 'bean' in your class names. It's everywhere in Java technology, you get ActionBeans, you get JavaBeans, you get Enterprise JavaBeans, and then you get "Netbeans". I can't stand it. If there's anything I can't stand about 'open source'-ish technology it's the often lame naming conventions that you find. Word to the wise, Gnu is NOT a cool name to prefix everything with. You feel like somebody with a speech impediment every time you refer to something under the Gnu 'brand'. Then you get the daft Unix/Linux naming stuff of xEdit, or kEdit or whatever. All these terms are symptomatic of developer types also doing the 'marketing' of the product since it's 'open source'.

For some reason, while Java was rooted in the commercial company known as Sun Microsystems, it seems the developer types there should have gotten some help from the marketing department when they gave names to their technologies. Who was the dolt who thought "Well Java has to do with coffee and you get coffee beans, so I know, let's use the word 'bean' everywhere we can to describe stuff." And all the other geeks around him started snorting and snickering in childlike glee at the brilliance of his epiphany. Notice I said 'his', since I am convinced a woman would have been way more original.

I wish I had a Men In Black magic pen, and could flash that red light from a website somewhere that would make everybody just forget about the word 'bean' in any other context than a coffee shop or a food source that encourages flatulence. It's lame, and it should go! I feel like a kid in a playschool sandpit everytime I have to type the word 'bean' anywhere in my code or in documentation. What's next? Do we extend the idea to other aspects of our code. In future instead of having:

private Person person;

I'll make it:

private Person personWerson;

Instead of:

private ShoppingCart cart;

I'll make it:

private ShoppingCart trolleyWolley;

You get the point. It's all just dumb, and poorly envisioned. Why does an ActionBean have to be an ActionBean. Just call it an Action. Isn't that enough? If you must add something else, call it an ActionComponent, or ActionController, or something more grown up for goodness sake, but whatever we do, let's stop calling stuff 'beans'!

Thanks, I feel better now.