Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

The general session this morning was not quite the same as yesterday morning’s, which I suppose is understandable, but it was still pretty informative. Today Oracle showed off its developer tools, which are interesting, but being mainly JSF, not very appealing for my own use.

My favorite session of the day had to be Groovy, the Red Pill: Metaprogramming — How to Blow the Mind of Developers on the Java Platform presented by Scott Davis. This session was incredible. Scott speaks like a televangelist and by the end of the presentation seemed to have half the audience ready to stand, shout AMEN, and follow him as a new religious leader. I now have absolutely no doubt in my mind that Groovy is an amazing and powerful language and that I’m going to try my hardest to make it part of some project I’m doing in the near future.

My second favorite presentation was definately Creating a Compelling User Experience presented by Ben Galbraith. It wasn’t anything groundbreaking or new for me, but it was a very well-done presentation on design for the typical Java engineer. Ben made a variety of good points, including my personal favorite, pay attention to users goals but don’t let them design software.

Third runner-up for favorite goes to How to Implement Your Own OpenSocial Container on the Java Platform by Chris Schalk and Paul Lindner. This session basically covered Apache Shindig, which I did not even know existed. Also mentioned in the presentation were Guice and Enunciate, which I will definitely be investigating further.

Not much shwag today, and I didn’t win anything from any of the drawings (despite wearing my Swing Application Platform shirt), but overall a good day. Although if I can request anything from the JavaOne gods, how about a little variety for lunch, or at least a different kind of pasta salad with the sandwiches!

Groovy, like Ruby, is one of those DRY, elegant, and fun programming languages. In fact, one of the Groovy mantras is “the things you do the most often, Groovy makes the easiest.” That’s a pretty powerful statement, but with all things powerful, with great power comes great responsibility.

Groovy does some things that are inconsistent, for instance, consider running the following block of Groovy code:

1
2
3
4
5

def list = [1,2,3,4]
println list.class
 
dev map = [key1:"value1",key2:"value2"]
println map.class

Line 2 returns the class name of the list variable, in this case java.util.ArrayList; line 5 throws an error. This inconsistency is because Groovy allows the fields of a map to be accessed like a property, which means map.class is equivalent to map["class"] which refers to a key class in our map which does not exist. Because Groovy is interpreted and not compiled there’s no compiler to catch this error and it is possible that without an adequate amount of testing or review a piece of code like this could make it out as a bug. This point was brought up as a problem with Groovy to Jeff Brown, the instructor of the “Rapid Web Development with Groovy & Grails” Java University session at JavaOne. Jeff agreed that it was an issue, but basically just ignored it and moved on. I argue that it’s not a problem with the language it’s a problem with the developer.

Groovy’s documentation contains a list of things you can do with Groovy but probably shouldn’t, on said list, this problem is identified as number one. Groovy provides the ability to write unit tests, which if done correctly should catch this bug. But more importantly, a programmer should know the language he’s programming with, or his code should be reviewed by somebody who does. If your methodology allows for a bug like this to be released into the wild, you have bigger problems.

Groovy is a programming language for people who know how to program. People who realize the simplistic beauty of the syntax and the elegance it provides for solving problems in a DRY manner. Groovy is not for beginners, beginners need time to learn how to code before they should be allowed to take shortcuts. More importantly, beginners rely too heavily on tools, tools that more often than not act more as a crutch than an asset, and tools that cannot catch problems like the one above.

My solution? Grow up and code. When you’ve written enough code to realize that the best IDE is Vim, Emacs, or TextMate, and a terminal, you’re ready for Groovy and Grails. When the necessity of unit testing finally clicks in your head, you’re ready for Groovy and Grails. When you finally understand that code is poetry, you’re ready for Groovy and Grails. Until that point, keep writing code or find a new career. I can only hope that maybe one day you’ll understand, but if you never do, keep your opinions in your own space and don’t pollute our elegance with your misunderstanding. Just because you can’t write beautiful code doesn’t mean the rest of the world can’t.

Last week at the Emerging Tech Conference I dropped my card in the fishbowl at the Manning Publications table to win a free eBook. Turns out I actually won! This morning in my e-mail I found a free eBook copy of Groovy in Action. I haven’t read any of it yet, but I would like to thank Manning for the book, and I will definitely write up a review when I’ve had some time to read though it.

Until then, if you’re interested, Groovy is a scripting language that runs in the Java Virtual Machine. Until the Emerging Tech Conference I really was not all that interested in Groovy, but then I saw a presentation on Grails, a Ruby-on-Rails like application framework that uses Groovy instead of Ruby. The neat thing about Grails is that it’s really just a wrapper around a Spring Framework back-end, including a Hibernate-based persistence layer. I still need a chance to play with the whole stack, but it’s definitely on my list of things to do because it offers a lot of the neat things about RoR without learning an entirely new language and set of libraries. So far the only downfall I see is that like RoR, Grails really doesn’t run on a shared (read cheap) hosting setup, so if you want to put a Grails app into production you probably need a Java App Server, which typically costs quite a bit more the PHP hosting.