So last night I tried to install ImageMagick on Leopard but couldn’t find the requisite blog article that detailed the installation. So I thought I’d write one. I managed to dig up some forum posts, so here’s the whole deal.

ImageMagick itself compiles fairly easily on OS X, but it’ll end up missing JPEG support, which was kind of a bummer. Here’s how to fix it without using MacPorts (which I avoid these days since it tends to get updated too slowly for a lot of projects).

First get a copy of libjpeg and build it as a shared library:

curl http://www.ijg.org/files/jpegsrc.v6b.tar.gz > jpegsrc.v6b.tar.gz
tar -zxf jpegsrc.v6b.tar.gz
cd jpeg-6b/
ln -s `which glibtool` ./libtool
./configure --enable-shared --prefix=/usr/local
make
sudo make install

Now get a copy of ImageMagick:

curl ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz > ImageMagick.tar.gz
tar -zxf ImageMagick.tar.gz
cd ImageMagick-6.5.2-5/
./configure --prefix=/usr/local
make
sudo make install

Now you should have convert, mogrify, montage or whatever other ImageMagick tools you were interested in. RMagick seems to install just fine after you do this, though I couldn’t get gruff working because of what looks like a dependency on GhostScript. I’ll update this post once I get that worked out.

A lot of people reading this are probably using frameworks that have decent session storage and don’t often need to worry about cookies. But over at CIM the thought of session state for many tens of millions of requests per day is daunting. As a result we use a lot of cookies. Probably too many, but that’s a story for another day.

Ever read the RFC for cookies? Neither had I. I probably wouldn’t have either until our company decided to standardize on Apache Tomcat for our application containers. What we thought would be an easy conversion turned out to take a few days time because some of our important cookies apparently violate the RFC, but no browser or web server had complained yet. What rules did we break?

• The left hand side of a cookie definition can’t contain an ’@’ symbol (along with some others)
• The right hand side of a cookie can’t contain ’=’ symbols, so no unescaped key=value pairs

The RFC is a lot to wade through, but thanks to some information from Tomcat’s issue tracker it was made pretty clear. Basically a cookie definition boils down to:

   av-pairs    =     av-pair *(";" av-pair)
   av-pair     =     attr ["=" value]              ; optional value
   attr        =     token
   value       =     token | quoted-string

Where the definition for token and quoted-string are provided in the HTTP/1.1 spec.

    token          = 1*<any CHAR except CTLs or separators>
    separators     = "(" | ")" | "<" | ">" | "@"
                   | "," | ";" | ":" | "\" | <">
                   | "/" | "[" | "]" | "?" | "="
                   | "{" | "}" | SP | HT

    quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
    qdtext         = <any TEXT except <">>
    quoted-pair    = "\" CHAR

So there you have it. And most web servers and browsers don’t seem to complain. But if you ever find yourself looking at your server logs or a debugger wondering where you cookies went or why they’re truncated. Then it might be time to double check the RFC.

Oh, and the fix? Well ideally we’ll fix our cookies to comply with the RFC, but that will take some time since we don’t control the creation of all the cookies in question. So the plan for now is to patch Tomcat’s Cookie class to be a bit less strict when it’s parsing the request.

UPDATE: New version 1.1! Download it here.

UPDATE 2: Github now has issue tracking! So I’m dropping uservoice. If you have ideas, submit them here.

So over the past month I’ve been working with Dashcode trying to come up with a nice representation of Septa train data. I’ve managed to come up with a simple widget that combines the data from iSepta with the ontime/late data available from Septa’s Train View page. So far it seems to be working well. I’ve submitted the widget to Apple downloads and Dashboard Widgets so hopefully you’ll see it show up there soon too. So download your copy and let me know what you think!

As far as working with Dashcode goes, it’s been an interesting experience. I’m still a little lukewarm on it, but it definitely helped with the visual work. I’m not much of a designer, so having Dashcode’s gradient, rounded corner and “glass” effect helpers was perfect for me. It was also nice not having to hand-code the “i” button animation like I did with Digital World Clock.

On the downside of things, I felt like the HTML and javascript generation over-complicated things in some cases. Dashcode provides “Parts” like labels, lists and indicators which are cool but the way you interact with them is a little odd. For example, to add items to a list part you’d do this:

var list = document.getElementById('list').object;
list.setDataArray(trainList);

Which isn’t terrible, but felt like more work than just manipulating a plain old “ul” with jQuery. Granted this specialized interface does also offer streaming-friendly setters, which could be useful for some folks. My bigger gripe is with the labels that get generated like this in the HTML:

<div apple-part="com.apple.Dashcode.part.text" class="apple-text apple-no-children" apple-default-image-visibility="hidden" apple-text-overflow="ellipsis" id="nextTrainLabel" apple-style="part-height-dependent: true;"></div>

Note the lack of contents. They get wired at run time by javascript. My guess is that this makes localization more accessible, but I wonder how many widgets really get localized.

These sort of things made me hesitant to muck around with the HTML and CSS which felt a little limiting when building the widget. But the graphics helpers and quick access to functions like “deploy to dashboard” were definitely nice. And the javascript debugging support felt even more solid than firebug. So all-in-all I’m a happy camper.

One more thing to be careful about if you’re working with Dashcode: when saving your project, Dashcode will regenerate most of the files and directories and blow away files that haven’t been imported into the project. So be careful not to save things under the dcproj bundle or you might lose them. I would bet this applies to .svn folders as well, but all the cool kids are using git nowadays anyway, right?

I saw a beautiful thing this evening in the ZenTest 4.0.0 release notes (emphasis mine):

2 minor enhancements:

• Deleted autotest/screen – releasing as a separate gem soon.
• Deleted test-rails and railstestaudit.

Removing unnecessary code has always given me a warm fuzzy feeling.

In today’s world of backups, version control and dependency management we need to learn to be ruthless with the delete key.

Don’t comment it out. Don’t talk yourself into thinking you’ll use it later. Just delete it.

This is one of the same principals behind the inbox zero concept and it is just as applicable to code. Nice work, ZenTest. We should get you a merit badge.

I’ve been doing a fair bit of JavaScript at work lately and while I really enjoy the language there’s something that’s been nagging at me which I’ve come to call The Creep of Asynchronicity. I’ll use some of the examples I’ve been working with to illustrate the idea.

Let’s start with a function to get all the videos on a device that looks like this:

videos = device.getVideos();
doSomethingWith(videos);

Simple. Pretty much what you would expect in a “device” API, right? But now let’s assume that getVideos() requires a return trip to the web server to get the data. You have two options:

1. Fly in the face of AJAX, make the call synchronously and lock up your UI.
2. Change the API to look something like this:

device.getVideos(function(videos) {
  doSomethingWith(videos);
}

Now that’s not so bad, but consider the case where you also need an asynchronous call to get the device object. Now we have:

user.getDevice(function(device) {
  device.getVideos(function(videos) {
    doSomethingWith(videos);
  }
}

Ew… getting kinda nasty there isn’t it? Imagine if we also had to make an asynchronous call to get some details on the videos, and so on.

So the crux of my argument is that without some sort of synchronization mechanism, any introduction of an asynchronous call requires that the whole application become asynchronous to support it. Even just a sleep function would help, but JavaScript has nothing of the sort. The best I’ve come up with so far is recursion, which helps in the event that your asychronous calls are acting upon a list of items uniformly. I used this to load a series of JavaScript libraries like so:

function loadScripts(libraries, callback) {
  if (libraries.length > 0) {
    var lib = libraries.shift();
    jQuery.getScript(lib, function() { loadScripts(libraries, callback); });
  } else {
    callback();
  }
}

loadScripts(["/user.js", "/device.js"], function() {
  doStuffOnceScriptsHaveLoaded();
});

This could conceivably be used to recurse down a list of asynchronous callbacks (which I did find on the web somewhere but seem to find it at the moment). But I think this might lead to an even nastier looking API.

I’m sure on some level, this just requires a shift in thinking. But there’s a part of me that still longs for that two liner at the top of this post… *sigh*

So here’s a non-technical tip for you: If you haven’t tried Alton Brown’s Pan Seared Ribyeye recipe yet, do it.

We had a quiet Valentine’s Day at home yesterday and I tried my hand at steak and potatoes. Alton’s steak recipe was awesome and stupid simple. I will definitely be doing this one again.

For the potatoes, I used a roasted rosemary potatoes recipe that didn’t work out quite as well. I’ve made something like this before, but couldn’t find that same recipe so I used this one. But the addition of garlic and onions was a bit much (my usual one is just butter and rosemary). I guess I’ll have to experiment to come up with something like my old way of doing it.

Kaori (the culinary genius of the family) made a delicious three-layer chocolate fudge cake for dessert. Yes, that’s a layer of fudge around each layer of cake, chocolate cream between the layers and dusted with cocoa powder. Combine that with a hot cup of Earl Grey and we’re in business!

I hope everyone else had a lovely Valentine’s Day!

During our last sprint at work I got a good chance to get Groovy working for our unit tests. It took a bit of googling and trial and error, so hopefully this post will benefit others trying to do the same thing. Here’s what I did:

Set up your pom with the following dependency:

And the gmaven plugin under the build section:

Note that I keep my tests under src/test/java, this avoids needing extra configuration from inside eclipse. src/test/groovy also works, but you’ll need to mark it as a source folder, and it seems to be a little flaky so I stopped that.

At this point you should be able to run your groovy tests with mvn clean install. Or use -Dtest=MyGroovyTest to run a single test.

For eclipse you’ll need the GroovyFeature installed. I currently have version 1.5.6 installed.

Close your eclipse project and rebuild the configuration with mvn eclipse:clean eclipse:eclipse. Open the project back up. You may need to fix the JRE settings for the project in the java build properties. On my machine maven tries to hook the project to a JRE other than the default, compile errors occur, switching back to the default Mac OS JRE resolves that.

Right click on the project root, go to “Groovy -> Add Groovy Nature”. If you use the eclipse maven plugin, don’t turn it on for this project. Enabling maven dependency management doesn’t seem to jive with the eclipse groovy plugin. If I turn it on, I get lots of class not found type errors and have to do eclipse:clean eclipse:eclipse and start over again.

Right click your .groovy test (a class that inherits from groovy.util.GroovyTestCase) and you should have Run As -> JUnit test available. I have my setUp and test methods as void. I used defs originally, but this caused the methods to be ignored.

If you don’t see JUnit available, try cleaning the project. I’ve even turned off the automatic builds and manually ran “Build All” on occasion. Also watch out for compile errors in the groovy files. Eclipse doesn’t reliably warn about it and I’ve seen compilation just silently fail. When in doubt have maven try to run it. Eclipse doesn’t always reliably build the groovy classes, and I often have to clean the compiled classes especially when adding new groovy methods or test functions. I’d say about 75% of the time it just runs.

Dan Schaffer on the groovy mailing list also mentioned noted that refactoring Java classes doesn’t seem to apply to Groovy files. There is a plugin for that, but I haven’t tried it yet.

As usual, feel free to comment if you have any questions about my setup. Hope you find this useful.

Rather than continue my review/rant about GTAC2008, I think I’ll let you just decide for yourself since the videos are now available.

Many of them are less-than-interesting, but the following are probably worth a look.

1. Boosting Your Testing Productivity with Groovy – Andres Almiray
   I’ve been doing a lot of this stuff with Groovy lately, more detail to follow.
   • Video: http://www.youtube.com/watch?v=UvWTfVCWKJY
   • Slides: http://www.slideshare.net/aalmiray/gtac-boosting-your-testing-productivity-with-groovy/
2. The New Genomics: Software Development at Petabyte Scale – Matt Wood
   It’s not about testing, but it’s a good talk.
   • Video: http://www.youtube.com/watch?v=A64WKH9gNI8
   • Slides part 1: http://docs.google.com/Presentation?id=dczwht9g_3318qqfb6f5
   • Slides part 2: http://docs.google.com/Presentation?id=dczwht9g_393d7zg4xcm
3. Automated Model-Based Testing of Web Applications – Atif M. Memon and Oluwaseun Akinmade
   Nothing here that you can go and download just yet, but very interesting research.
   • Video: http://www.youtube.com/watch?v=6LdsIVvxISU
   • Slides: http://www.cs.umd.edu/~atif/GTAC08/
4. Atom Publishing Protocol: Testing your Server Implementation – David Calavera
   This gist of this one is really just: check out Ape, it’s cool. But I think David should also be given a lot of credit for giving a pretty solid talk despite it being his first talk in English. Nice work, David!
   • Video: http://www.youtube.com/watch?v=uRmWTfT91uQ
   • Slides: http://thinkincode.net/gtac_atomPub_testing_your_server_implementation.pdf

The Future of Testing by James A. Whittaker is also probably worth a look, but the video is still listed as “coming soon”, so I’ll link to that when it’s available.

I’ll discontinue my GTAC2008 recap unless anyone is really dying to hear more of my ranting. More blog posts on my Groovy work to follow.

I felt a blog post was in order to commemorate a totally epic 2 year anniversary for PhillyOnRails PubNite.  We had quite the turnout last night, definitely upwards of 20 people!

Colin took some photos, so I’ll lean on him to get them up on his flickr account soon.

A big thank you to everyone that came out and I’m really looking forward to next month!

Thanks to a strong collaborative effort between myself and one of the members of our front end team. I’m pleased to announce my new cross-platform strategy for glyph management.

It’s capable of operating under a variety of modes including that of a 6, 9 or lower-case ‘e’. This new initiative will be the focus of my coming year.

(How’s that, Karl?)