CrashSplat, BANG!

The LinkedIn Blog has the first in what is promised to be a series of post about their use of Grails.

If you like cars at all, or if you appreciate cool design, you have to check this out.

Scoble’s video look into the new Rackspace facility in San Antonio is pretty sweet.

The following is a set of instructions for setting up your Grails development environment on OS X Leopard. This is probably not of much use to anyone else, but at least I’ll have it captured for myself.

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.

I finally got around to upgrading to the latest version of WordPress (2.5) tonight. It was pretty painless and well worth it. The folks at Happy Cog redesigned the admin interface and it’s much improved. After the upgrade I’m feeling like I need to go through and clean out a bunch of crap (themes & plugins) that DreamHost laid down during the initial install and setup. Anyway, if you’re a WordPress user you should check it out.

As I mentioned, in my last post, we are evaluating web frameworks at the office. Seeing as all of our current web-app development is done using Struts 1, we thought it would only be fair if we first looked at Struts 2. I also mentioned in my previous post that we have some basic criteria by which we are evaluating these tools. This evaluation took place on Friday, February 29th, with two of my coworkers.In case you’re wondering, Struts 2 is a significant departure from Struts 1. In fact, it’s totally different. If you’ve ever used WebWork then you’ll be at home in Struts 2 because it’s basically WebWork renamed.How did it stack up against our criteria?

• 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.

At work, sometime towards the end of this year, we’ll be moving our primary application to a different web framework. There are a number of reasons for doing this, some I’ll talk about here, others I won’t. Obviously in order to properly evaluate some of the tools we need to develop some basic criteria for the evaluation. None of this is set in stone, but here is my first cut (these are in no particular order):

• 10 Minute Rule (ok, maybe 30) - Given the current state of most modern web frameworks it seems to me that you should be able to do something of value quickly. While I understand that you probably won’t finish your application in an afternoon, you should be able to accomplish something measurable. If it takes you all day just to setup your environment, you fail. How long does it take you to write “Hello World”? This will provide a good idea of how quickly you’ll be able to iterate on things when you’re doing real work.
• Convention over Configuration - This concept has been popularized as of late by Ruby on Rails. The core idea here is that if you name things certain ways, put things in certain places, and in general, follow understood methods then you shouldn’t have to spend a bunch of time “telling” the framework where things are. If you have spent much time maintaining a large enterprise web application then you understand why this is important (if not important, then definitely desirable). Most of my recent experience has been with Struts 1, which has lots of “configuration” bloat. Define your actions in this xml file, put your reusable views over here in this xml file, map your domain objects in these xml files, prick your finger and put a drop of blood over here, blah, blah, blah. Not that I’m knocking Struts 1, because we have built some great stuff with it, but these days I think we can do better.
• Tool Support - We’re an all Java shop and all of our engineers have become pretty dependent on a good IDE. Whatever framework we decide to use needs to play nicely with our current development environment. Things like code completion are critical. Can you start, stop, and reload from within your development environment? How long does that take? Telling all of our developers to go back to using vi or emacs just ain’t going to cut it.
• Developer Resources - I want to make sure that whatever framework we choose has lots of resources available for our developers to consume. What is the documentation like? Are there books that you can buy from Amazon? Are there active mailing lists? Are there conferences that you can attend? Is there a local user’s group?
• RESTful - It’s my hope that whatever framework we choose will easily facilitate (if not mandate) RESTful development. I want a framework that will take out some of the guesswork that can be involved here.
• Access to Java - Seeing as all of our core technology is built using Java this is pretty important. We need the ability to reach back and execute Java code in our existing stack. This doesn’t have to rule out frameworks that are built using other languages, but it does mean that if we do look at other languages they’ll have to run in the JVM.

For my birthday back in October I received a Garmin Forerunner 305. The Forerunner is a GPS training device. It’s targeted at runners, cyclists, and other outdoor enthusiasts. It allows me to continually monitor distance, pace, elevation, and heart-rate information all “at a glance”. It’s really awesome, and pretty geeky.

I’ve found the Forerunner to be extremely freeing. It allows me to try new routes without having to worry about exactly how far I have been or when I might need to think about turning around. No more sweaty trips in my car attempting to figure out how far I’ve been. The pace information also helps keep me honest when it comes to training. I have a tendency to relax a bit too much.

Garmin ships an application called the “Training Center” along with the Forerunner which serves as a management console of sorts, and training log. The “Training Center” is not nearly as cool as the device itself; in fact it’s a bit underwhelming. However, it does support OS X, which is cool.

If the “Training Center” does not meet your needs then you can also make use of Garmin’s online tool Motion Based (for a small fee of course). I’ve played with Motion Based a bit, but have not yet found it compelling enough to actually pay for. It seems to me that Motion Based could be so much better than it is. Hopefully Garmin is looking at significantly retooling it.

Garmin is also making some strides related to development tool support for their products. Thus making it easier for 3rd party application developers to access device data and get it into other tools. Tonight I spent some time playing around with the Garmin Communicator Plugin, which allows you to interact with a Garmin device via javascript in your browser. It’s freakin’ awesome. I wish I had more time to play

Adam Keys’ recent post on micro-apps is a great read. It’s inevitable that we’ll continue to see a rise in the number of “micro-apps” as developers leverage rich API functionality in mashups.

For some reason Twitter has come up in conversation quite a bit lately. Each time it has been with people that don’t use the service. Not that I’m an expert, but it is quite obvious in listening to these folks that they just don’t get it, which I think is probably understandable. So I thought I might try to “talk” through it here.

Twitter asks you the question, “What are you doing”? You can answer that question using any number of input mechanisms, the web, text message, im, a twitter client, etc… When people first hear about twitter, they think, “Well that can’t be all that interesting.” I actually had someone ask me the other day, “So, do people twitter when they are about to go to the bathroom”? He actually phrased it a little differently, but I’ll leave that up to your imagination. The answer is no, well nobody that I follow does anyway. Which leads me to my next point…

A core concept in Twitter is that of “following” people. Which simply means that you are interested in keeping up with “What they are doing”. Every time they post to twitter you’ll be notified. This might only mean that you see the update in your web browser, but you can also get updates via text message on your phone (assuming you want that), or through some other client.

Obviously the people that post the most interesting tweets (that’s what an individual twitter post is called) tend to get lots of followers. As well as folks that are regarded as experts in their communities. Twitter is also great for helping friends and family that might be separated geographically keep up with each other.

I like to think of Twitter as “mini/micro blogging”. You only have 140 characters per post, so you can only say so much, but you can post interesting stuff. You might post about new music you are listening to, or some news story you found interesting, etc… In general it is a great “low bandwidth” way of keeping up with what is going with people and the world.

Check it out. If you are using a Mac I highly recommend the Mac Twitter client Twitterrific.

Not that you’ll find it interesting, but here is my twitter page.