CrashSplat, BANG!

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

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.

Here are a couple of things that I stumbled upon this week in the aftermath of SXSWi. I’m not sure exactly where I found them. Probably through twitter or someone’s blog, but they somehow made it into delicious. Anyway, check them out.

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

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

Today was Blue Beanie Day on the web. I hope that you all donned your beanies, I know I did.

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.

Over the last several weeks there has been an interesting debate/discussion/conversation brewing related to the current state of web design. Some lament the absence of truly great work on the web. Some seem to agree with these conclusions, and a number of others do not. As a developer, and not a designer, I tend to agree more with the second set of folks. Either way though, I would highly recommend reading all of these posts to anyone who is involved in web design/development or interested at all in the subject.

I have been trying to get a little more disciplined about keeping track of web sites that I find inspiring. I spend so much time building web applications that I often find it necessary to step back and refresh myself a bit with others work. I’m NOT a designer, but I appreciate great design. I’m more of a nuts and bolts guy that spends a lot of time working on the plumbing of highly interactive and dynamic web applications. Anyway, here are some sites that I stumbled across this week that I think look fabulous (you can also find these in my delicious bookmarks).

Lokesh Dhakar’s new blog is beautiful. I love the simple elegance. I also really love that the navigation on the right remains in place as you scroll the page.
(via SimpleBits)

The following two links are evidently some mockups that were done for The Internet Movie Database. It is always refreshing to see such great layout when there is actually a lot of stuff to put on a page. I also really like the contrast between rounded and non-rounded corners. (via thebignoob)

http://justwatchthesky.com/imdb/

http://justwatchthesky.com/imdb/profile.html