I have been been thinking about and exploring
Groovy for the last few weeks. I have been looking (forever it seems) to something like the Rails web framework built on Java. There is much to like about Ruby but in the end it is just another imperative, object-oriented language with poor performance, bad threading, libraries "built on a learning curve" [*], and non-existent internationalization. Rails, however, is much more interesting than Ruby. The two parts of Rails that I most like are (1) the "convention over configuration" approach to associating components and attributing behaviors to them and (2) the integrated support for a version's development phases and migrations between versions. These are great boosts to productivity.
However, I am committed to Java for the foreseeable future for most commercial work that I do. (I also work in Perl and PHP but these languages are mostly used for integration projects.) Java offers a wealth of best of breed components of which most are open-source and use the generous LGPL or BSD licenses.
So I was excited to find out about Grails and, as mentioned in an earlier post, after reading
Getting Started with Grails I found that it satisfied my need for a Rails work-alike based on Java. My concern was that it was written in Groovy and not directly in Java. And so, I spent the better part of three weeks working my way through
Groovy in Action.
Groovy in Action covers the language in detail, its idioms, and its use in several problem domains -- XML, relational databases, GUIs, web application, etc. I am very impressed with Groovy. I was not expecting to be. It is another imperative, object-oriented language with reasonable performance, great threading, best of breed libraries, and end-to-end internationalization. The "You had me at "Hello"" moment came a third of why through the book when the author explores using "builders" to construct XML documents. The code is
def builder = new groovy.xml.MarkupBuilder()
build.number {
description 'Square and factors of 10..15'
for ( i in 10..15 ) {
number( value: i, square: i*i ) {
for ( j in 2..<i ) {
if ( i % j == 0 ) {
factor( value: j )
} } } } }
which outputs
<numbers>
<description>Square and factors of 10..15</description>
<number value='10' square='100'>
<factor value='2' />
<factor value='5' />
</number>
<number value='11' square='121' />
<number value='12' square='144'>
<factor value='2' />
<factor value='3' />
<factor value='4' />
<factor value='6' />
</number>
<number value='13' square='169' />
<number value='14' square='196'>
<factor value='2' />
<factor value='7' />
</number>
<number value='15' square='225'>
<factor value='3' />
<factor value='5' />
</number>
</numbers>
This is a compact and maintainable solution to the XML document creation problem.
The use of builders to construct complex hierarchical structures be they XML documents or Swing GUI interfaces is a very powerful facility. This shows the strength of Groovy's meta programming and its support for closures.
Next week I plan to take a few days off and build a web application with Grails and Groovy. Wish me luck.
[*] I love this phrase. So much of what is open-source is written by people either learning the language, learning the domain, or learning the patterns. The older the language or the library and the greater the likelihood that what you have in hand has had several generations of revision and revisers and is the best that it can be. SmallTalk's libraries are the epitome of this. Most new languages and libraries (Groovy included) are written by folks while they are "on the learning curve." The result is often baroque, idiosyncratic, flaky near the edge cases, etc. ¶ With that said, one of my employability facets is that I build on the learning curve all the time! ¶ I have no idea where I first heard the phrase "building on the learning curve." If you know to whom I can attribute it to please contact me.
I love this team-space designed by Clive Wilkinson Architects and this personal-space design by Francois Perrin. I am attracted to these carefully designed spaces exposing raw materials because I spend so much time inside software. There is a comfort that comes from marrying the working environment with the working materials.
The Virginian Pilot, the local newspaper in Virginia Beach, VA, has a good graphic design department. I have always liked their maps and this Sunday's edition had another fine example detailing the changes on Witchduck Rd. One element of their design program I really like is how points of interest are labeled using a modified balloon -- a simple pin shape with the label text below. All the points of interest clearly labeled and aligned at the edge of the map and the connections acute triangular shape does not interfere with the map's content.
Building a web site always takes longer than expected. And the size of the web site does not seem to matter. There is an inverse relationship between cost and commitment: A $10,000 job with 100% commitment takes about the same time as a $1,000 job with only 1% commitment. And who can commit to any project 100%. The point of this is that that web site's "holding page" better be useful. An "under construction" sign does not help your client or your client's audience. 
Double-clicking a class name opens it in an editor.
A small improvement to Google Calendar would be to allow you to define travel time around an event. For example, the illustration shows that to attend the 6 pm meeting you need to leave by 4:30 as the meeting's location is an hour away and you need to find parking. (The drive home is shorter because you don't need to find parking!)
This is a wonderful promotion poster for the talk "Google is white bread for the mind".