For a closer look at Type City (which Moll refers to), check out the gallery at Veer. Also, if you have a free Veer account you can download Type City wallpaper here. I’ve been using the “Basilica” on my desktop and phone for a few weeks now.

Download & Setup Groovy

You’ll need to grab the latest version of Groovy here (1.5.4 at the time of writing). Once you extract the zip file (Safari probably did that for you), move the extracted Groovy folder to the /usr/local folder. Here’s the command I used from a terminal window (you’ll probably be prompted for your password):

sudo mv groovy-1.5.4/ /usr/local/

You’ll need to make sure that the JAVA_HOME environment variable is set. You can add this to your .profile file if it’s not already there. I use TextMate as my editor of choice so I issued this command in the terminal window:

mate ~/.profile

Once you have that file open, add the following line:

export JAVA_HOME=/Library/Java/Home

While editing your .profile file you also need to add the GROOVY_HOME environment variable:

export GROOVY_HOME=/usr/local/groovy-1.5.4

In your .profile file you also need to add $GROOVY_HOME/bin to your PATH. So the last line in your .profile file should look something like this:

export PATH=$GROOVY_HOME/bin:$PATH

At this point you need to execute your .profile file to pick up your latest changes. You can do that with the following command:

. ~/.profile

You should be able to test your Groovy install by running the following command:

groovy -version

It should report something like this:

Groovy Version: 1.5.4 JVM: 1.5.0_13-119

Download & Setup Grails

Download the latest version of Grails here (1.0.2 as of this writing). Once you extract the zip file (or tar.gz), move the extracted Grails folder to the /usr/local folder:

sudo mv grails-1.0.2/ /usr/local/

Edit your .profile file again adding the GRAILS_HOME environment variable:

export GRAILS_HOME=/usr/local/grails-1.0.2

Add $GRAILS_HOME/bin to your PATH. The last line of your .profile file should now look something like:

export PATH=$GROOVY_HOME/bin:$GRAILS_HOME/bin:$PATH

Execute your .profile file to pick up your changes:

. ~/.profile

At this point you should have a working Grails setup. You can test it out using the following command:

grails

If everything is working you should get a help message similar to the following:

Welcome to Grails 1.0.2 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /usr/local/grails-1.0.2

No script name specified. Use 'grails help' for more info

The Grails installation notes mention the possibly of needing to issue a chmod +X on the grails executable, but I didn’t find this to be necessary. You’re mileage may vary. If you do run into errors you may want to check out the Grails install page. In that case, you may just want to bale on this blog altogether and go somewhere else.

You could stop at this point if you just wanted to kick it old school and use a text editor to write code, but we shall press on.

Install Intellij IDEA Plugin

From inside IntelliJ you’ll need to grab the latest version of the JetGroovy plugin (1.5.15312). Once you install the plugin you’ll have to restart IntelliJ for the changes to take effect. You’ll need to tell the JetGroovy plugin where to find Groovy & Grails. Unfortunately the plugin seems unable to use the environment variables. To set these values Select “Groovy & Grails” under “Settings” and enter the proper path values.

At this point you should be able to create a new project within IntelliJ with a “Grails Application” module.

When you create the new project IntelliJ will run all of the necessary commands to properly setup your new Grails app. Once created you should be able to create a new “Grails Application” “Run Configuration” for your application and your off to the races.

My work here is done.

For an amusing comparison between the new UK currency and the recently released $5 dollar bill, check out typography.com.

On the issue of money, it’s fascinating that coins have never really taken off here in the States, but in the UK they’re huge. If you travel to the UK then you’ll know what I mean simply by the weight, and musical qualities of your pockets.

• Design Eye for South By - SXSW 2008
• SXSW Interactive 2008 - a photoset on Flickr

One of the days I’m going to make it to SXSWi. I’m sure that by the time I do it will have become completely irrelevant.

• 10 Minute Rule - Unfortunately Struts 2 failed miserably here, but it’s not all the framework’s fault. Because of some of our other evaluation criteria, namely “Convention over Configuration”, and “RESTful”, we had to use the current development version of Struts 2 (2.1.1 I believe), not the officially blessed version (2.0.11.1 at the time). This meant we had to download, and compile the source. In order to compile the source we had to have Maven. All of our tools are currently built using Ant, so we had to download Maven. Oh, and by the way when we used Maven to build Struts 2 it downloaded the entire Internet onto my workstation while resolving dependencies. We did however eventually get it built. Let’s just say it took a bit longer than 10 minutes to get compiled jars, not to mention running code. However, once we got past this initial hurdle we were able to use the REST showcase application (I’ll mention it more later) to get up and running quickly.Grade D (Maybe C)
• Convention Over Configuration - Once we got everything compiled and running Struts 2 really shined here. However, I should note that this is not necessarily stock behavior for Struts 2. We made use of the Codebehind plugin in order to achieve this (note, it’s also required for the RESTful stuff). Basically if you name things a certain way and put things in the proper places Struts 2 will “figure out” what to do. In our afternoon of playing it worked great. It may also be worth noting that the Codebehind plugin was yet another thing we had to download, and compile, thus further slaughtering the “10 Minute Rule”.Grade A
• Tool Support - This one is a bit of a no brainer. Struts 2 is all Java, we’re an all Java shop with a great IDE. So, we didn’t have any issues here. It’s probably worth noting that all of IDEA’s Struts specific features are geared for 1.x. However, I find most of those features pretty useless anyway, your mileage may vary.Grade A
• Developer Resources - Maybe it’s just me, but I thought that most of the Struts 2 documentation sucked. This probably has something to do with the fact that we were using developmental plugins and an edge version. I’m sure if I took more time to read I would have had a better experience, but as we were rushing to accomplish something in a day I didn’t find the docs much help. On final thing to note about documentation, when you are looking at plugins it can be very confusing as to what plugins do what, what requires what, how one is different from another, etc… it’s a bit of a mess. Seeing as this is Struts we’re talking about I’ve got to believe this stuff will keep getting better as more people move to Struts 2.Other things of value to note here, a simple Amazon search shows that there are a number of Struts 2 books (not sure if any of them cover RESTful stuff). Also, it’s an Apache product so there’s going to be conference coverage.Grade B
• RESTful - Once we got the REST plugin downloaded and compiled this was seamless. The REST plugin comes with a showcase application that serves as a good reference for getting up and running. Most of the RESTful stuff just happens. It’s really nice.Grade A
• Access to Java - Struts 2 is written in Java, it obviously runs in the JVM, nuff said.Grade A

Overall I was satisfied with Struts 2. Aside from the things already mentioned the only major concern I had was the constant feeling that “this ain’t quite ready for prime-time”. Again though that’s mainly because of the desire for “zero configuration” and “REST”. If those things are not requirements for your project, and you can use the current release version of Struts 2 you’ll probably have a decent experience.