Sunday, October 4, 2009

Fancy Hudson Email

Over lunch I was discussing email overload with my coworker Scott. I already use automatic color-coding and move-to-folder rules to help me find the important stuff at a glance. Still there are some automated emails that I must read, but which are time-consuming to deal with.

One such email is the Hudson build result. Hudson is a fantastic tool for continuous integration, but its email format leaves a lot to be desired:

From there I have to click the link, wait for a slow loading Hudson page, then click another link to view the full test results. Then I have to sift through the tests that only failed once because of environmental quirks and Selenium bugs, to identify the recurring test failures that need prompt attention.

What I really want is something like this:

The subject line tells how many tests have failed. The recurring test failures are listed with direct links to each failure message. If there are no recurring failures then the test is marked a success. The duration is red for tests that took over a minute. If the test name and error message are short enough, the error message is displayed.

Fortunately Scott had read a blog post with a solution that might allow us to write our own email output in Groovy. I googled it and found this gem by Chetan: Using Groovy with Hudson to send rich text email

If you read Chetan's post and the comments, most problems come from trying to show recent SCM changes in Perforce, SVN, or CVS. That's not my top priority, so I'm starting with the output that I described above. Here's how I got it working:
  1. Download Chetan's enhanced email-ext plugin for Hudson and add it to your Hudson setup at Hudson -> Manage Hudson -> Manage Plugins -> Advanced
  2. Upgrade Hudson to the latest version (1.326 when I started the project 2 days ago, although 1.327 came out last night, because Kohsuke Kawaguchi has superpowers and releases enhancements all the time)
  3. Disable "E-mail Notification" and enable "Editable Email Notification"
  4. Enable "Default Content is Script" and "Default Content Type is HTML"
  5. Set the default subject to this Groovy template:

    $DEFAULT_SUBJECT <% def tr = build.testResultAction;  if (tr?.failCount) { %>(${tr?.failCount} failures ${tr?.failureDiffString}) <% } %>

  6. Set the default content to this Groovy template, which you'll probably want to read and edit to suit your needs:
body, table, td, th, p { font-family: Verdana,Helvetica,sans serif; font-size: 11px; }
.pane      { margin-top: 4px; white-space: nowrap; }
table.pane { border: 1px solid #BBB; border-collapse: collapse; }
td.pane    { border: 1px solid #BBB; padding: 3px 4px; vertical-align: middle; }
th         { border: 1px solid #BBB; background-color: #F0F0F0; font-weight: bold; padding: 4px; }
def stillFailing = []
def rootUrl = hudson.model.Hudson.instance.rootUrl
def jobName =
def buildNumber = build.number
def buildUrl = "${rootUrl}job/$jobName/$buildNumber/testReport/"
if (build.testResultAction) {
    build.testResultAction.failedTests.each{tr ->
        def packageName = tr.packageName
        def simpleClassName = tr.simpleName
        def testName = tr.safeName
        def displayName = tr.className+"."+testName
        def duration = tr.durationString;
        if (duration.contains(" min")) {
            duration = """<font color="red">""" + duration + "</font>"
        def url = "${rootUrl}job/$jobName/$buildNumber/testReport/$packageName/$simpleClassName/$testName"
        def error = (tr.errorDetails && tr.errorDetails.length() < 30 && displayName.length() < 100) ? tr.errorDetails : ""
        error = error.replaceAll("<", "&lt;")
        def failMap = [displayName:displayName,url:url,age:tr.age,error:error,duration:duration]
        if (tr.age > 1) {
            stillFailing << failMap
    stillFailing = stillFailing.sort {it.displayName}
def emailHeader = stillFailing.size() > 0 ? "Recurring Failed Tests" : "Success"
Check <a href="${buildUrl}">${buildUrl}</a> to view the results.<br/>
<table class="pane">
        <th>Test Name</th>
    <% stillFailing.each { failedTest-> %>
            <td class="pane"><a href="${failedTest.url}">${failedTest.displayName}</a>&nbsp;&nbsp;${failedTest.error}</td>
            <td class="pane" style="text-align: right;">${failedTest.duration}</td>
            <td class="pane" style="text-align: right;">${failedTest.age}</td>
    <% } %>

Chetan has submitted a patch for Hudson to have this ability without hacking the email-ext plugin. Maybe someday this will be even more trivial to set up.

It's easier to edit the Groovy code in the Hudson configure page textarea if that textarea is wider and uses a monospace font. To that end, I've written a Greasemonkey script called monospace-hudson that makes those changes when the configure page loads.

Without monospace-hudson

With monospace-hudson

Tuesday, March 17, 2009

Presenting Open Spaces and Lightning Talks

Last week I was getting over a cold at work when the CEO came to talk to me. For the company meeting she wanted employees to present on the conferences they had attended recently. I was still feeling a little under the weather, but I always enjoy telling people about the Java Posse Roundup and the ideas and experiences I was exposed to there. So I gave her a synopsis about Open Space conferences and lightning talks. She liked the ideas and asked me to present them to the company. I agreed.

The meeting began and soon moved on to the employee presentations. I was tired and weak from being sick the day before, but I wanted to communicate the Open Space ideas. I didn't know how many presentations there would be or when mine would be. The first few presentations went by, with detailed slides and lots of information about online advertising trends and healthcare marketing topics. I got increasingly nervous, since I had no slides and no written outline, and I felt more like going home and napping than improvising for a large audience.

Finally the CEO introduced my talk at the end. Relieved to stop thinking and start talking, I began following Jared Richardson's advice from his Career 2.0 talk at No Fluff Just Stuff.

• For each point you make, look a different audience member in the eye.
• Pace slowly back and forth across the stage area, to keep people's eyes moving and their attention focused.
• Use big arm gestures.
• Tell jokes.
• Modulate your voice high and low at different times.

I explained how an Open Space conference works, how they've been covered by Business Week as a new way for conferences to educate like-minded people with an unconventional approach. I described the morning sessions at the Java Posse Roundup, where the attendees posted ideas for discussions on post-it notes and then met and recorded our discussions for the podcast. I talked about afternoons where we either went skiing and chatted about programming, or went to someone's house and did some coding to learn a new language. And then I talked about the evenings, where we did lightning talks.

Fortunately it was a subject I'm already passionate about so it was easy to make it interesting. One of the ideas I wanted to sell was that a session of lightning talks should include a few talks that are included only to keep people amused and interested. The point is for their attention not to wander too far and to increase the audience's retention of the material. The inclusion of the "just for fun" talks has been slightly difficult for my teammates to swallow, so I wanted to address it specifically. As one coworker put it "If I have a deadline, why would I want to go in a conference room and listen to you talk about racecars?" As I explained to my audience, the point is to inspire creative thinking and self-expression, to get people practicing energetic public speaking, and to keep everyone awake and amused so they'll be more likely to retain the information from other lightning talks. And the most important part... if you don't like a presentation, it's only 5 minutes. Just wait for the next one.

The audience laughed when I showed them the example of Andrew Harmel-Law's "How to Prepare for Zombie Attacks" lightning talk on YouTube. They applauded when I pointed out that they were laughing and would therefore probably remember some of the other points I made.

The only question from the audience was "So how DO we prepare for zombie attacks?"

Wednesday, March 11, 2009


The first of my 5-minute lightning talks has been posted to the Java Posse YouTube channel. Thanks to Carl Quinn for the videotaping and processing.

Comment on this video


Selenium is a web site testing tool that lets you build repeatable tests to ensure that all the important functionality of your web application still works after you've been altering your code base. The master copy of a test is saved as an HTML file, which can be edited easily in the Firefox plugin called the Selenium IDE. From there it can be saved as Java code to execute in a JUnit test, or in other languages like PHP, C#, Ruby, Perl, Python.

The Good News

Most interesting web applications depend on JavaScript, properly named hidden form inputs, and the integration of many systems working together in real time. The best way I've seen to test an entire system in a real browser is to create a collection of Selenium tests and run them automatically as a JUnit test suite. If you habitually write and maintain Selenium tests for all new and altered functionality on your web site, and run those tests a few times a day using a continuous integration system like Hudson, you'll have a solid test bed that tells you as soon as someone on your team breaks something unexpectedly.

The Bad News

Selenium is young and finicky. It doesn't want to eat its brussels sprouts and it sometimes cries for a glass of water in the middle of the night. Because it runs in a real browser, it is subject to various meaningless error states that I've seen over the past 2 years of using it, including:
  • Random timeouts waiting for pages to load
  • Inability to use secure pop-up windows in IE
  • Overloaded CPU
  • Failure to start if Firefox is already running
  • A browser alert hangs the entire test suite indefinitely


Despite these monkey wrenches, I adore Selenium for its assurance that my web site works correctly before each release. It doesn't catch everything that a human QA team can find, but it does catch problems that a QA team doesn't have time to quadruple check every single week. You will probably need to write enough test utilities to restore the system to a known, deterministic state for each test. You'll also need to get your team in the habit of fixing a few tests for each significant code change, and learn to live with the fact that you won't always know who broke a test. Just fix it anyway. Once all that is in place, then you begin to have strong confidence that all your assumptions about your web site's functionality are still true six months later.

Sunday, March 8, 2009

Immediate Ideas from JPR09

My 28 seconds of fame has arrived. If you're not already a Java Posse podcast listener, let episode 233 be your introduction to this excellent resource, and your chance to hear my radio voice as the Java Posse Roundup 2009 attendees all take a chance with the mic.

I'm trying to recall the best ideas I learned at the roundup last week, for prompt use at my workplace, Marketing Technology Solutions. Some of the ideas about how to help get back developer time were interesting, especially the focus on automating more processes. I look forward to reviewing more of the audio sessions in future weeks and months to extract more ideas.

However, there are three ideas that made my eyes light up when I heard them, and they're relatively simple to get started at work almost immediately after selling them to the team.

1. Project Retrospectives

After each code release, allow a full regular day to fix any surprising production issues. Then on the next day, run through a 1 to 3 hour code review and functionality retrospective. During this meeting each team member who completed anything interesting can show the primary changes they made to the code base and the improved functionality they created. This can help other team members learn how areas of the code are evolving that they haven't seen recently, and it can help us learn from each other's challenges and the solutions we found.

2. Regular Discussions with Employees

Spend 30-60 minutes each week with each employee to find out privately if there are any ideas or problems that deserve some attention from the employee's perspective. This should preferably be done far away from the office building to encourage unchecked speech about office troubles. It's reasonable to use a full or partial lunch break for the meeting if the employee wants, or just go for a walk during work hours.

3. Lightning Talks

Once a month our team can have an hour-long lunch-and-learn session of 5 minute lightning talks on any technical or non-technical subjects. Keeping things educational and entertaining helps promote free thinking and creativity, so non-technical talks are just as valuable as technical ones, as long as they're interesting or funny. This is especially helpful for team members who are not yet comfortable speaking in front of a group, which is an increasingly important skill for a developer. To get things started I'll need to prepare a few short talks on technical and non-technical subjects, with and without slides. This can help others see the flexibility of the format so they feel free to present whatever and however they prefer.

The lightning talks at the Java Posse Roundup 2009 were very successful. They went as follows:

"Fair Allocation" Algorithm
Selenium Intro
How I Became 3/4 of the Man I Was
The Art of the Photo
High Gear Media and GWT
Loop Quantum Gravity
Animation Inside JavaFX
Racing 101
Awesome Productivity with GMail
ScalaCheck Automated Tests
Simple Twitter Client in Scala
Your Eyes Suck at Blue

Why Are There 12? or The Other Staircase
DB Migration in Java
Dynamic Web Skinning
Centerline Soccer
Java User Groups: How to Start One?
Sophisticated Data Access with JPA and Spring
F1 KERS System (2009)
Scala + Wicket
Slide Rules for Fun and Profit
Call 811
Repository Management

jFlubber, FlexFlubber, FXFlubber
The Smallest Plugin System
Hacking Hardware
Helmet Cam Footage
Zombies: Are You Prepared?
JavaScript Shell
Recovering a Stolen Laptop with Flex
Doctor Who
Sexier Software with Flex
Solar Power for Your House
Scala and JavaRebel
Groovy SwingBuilder, Google Maps, YQL Mashup

The JPR09 lightning talks are gradually getting released by Carl Quinn on

Saturday, March 7, 2009

Powers of Two

When I was 2 my parents divorced, but I didn't know that at the time. I LOVED apple juice.

When I was 4 I made an alphabet book with pop-up pictures of things that start with the 26 English letters.

When I was 8 I learned to type by playing Infocom games. I had already decided that I would grow up to be a fantasy novelist or an Infocom game author. I was incorrect but I was starting down the right path.

When I was 16 I designed theater sets and managed a crew to build them. I wrote and game-mastered year-long role playing games with my friends, which would later turn into an epic poem for high school credit. I didn't know it but all of this was gradually turning me into a software developer and manager.

Today I turn 32 and I'm on a plane returning from the Java Posse Roundup in Crested Butte, Colorado. My driver's license vanished so the airport security folks find me interesting, and maybe even attractive. One guard was even so attentive that he wanted to pat down my arms and legs. He asked if I was sore or tender anywhere.

I told him about falling on my ass repeatedly while cross-country skiing with computer geniuses. On the trail, Dianne Marsh patiently taught me the basics as we trudged through 3 miles of winding hills. The creator of Artifactory, Fred Simon, showed me how to cut the snow by bending my ankles correctly to go slowly down a hill.

My brain is brimming with ideas from the conference. My housemate Todd Costella showed me the value of Crucible and Fisheye for recording code reviews. My other housemates Andrew Harmel-Law and D. J. Halberg helped me understand Scrum master training. The formal and informal discussions were eye-opening, and the 5-minute lightning talks were such a good idea I'm going to try to get them started at work.

Dick Wall will gradually publish the audio of the discussions and the audio-video of the lightning talks. Thanks for everything, Dick! I'll be listening to those files many times, including the ones I was present for. Until the files are available I think I should blog about what I remember. This way I'll have a way to review my experiences and convert them into actions.

Tor Norbye shares my appreciation for fruity cocktails instead of beer. I introduced him to the joy of the Bay Breeze (Malibu rum, vodka, cranberry, pineapple). I'll have to find out his favorite drink so I can try it out as well. He's already shown me how valuable Netbeans is for Groovy, JavaScript, JavaFX, and Matisse.

On this same plane with me is Bill Robertson who redesigned the look and feel of Dick Wall's JFlubber application for the new and improved FlexFlubber and JFXFlubber incarnations. I sliced and diced Bill's design in Photoshop to make an exported JavaFX app. James Ward grabbed the PSD to make FlexFlubber. A few of the drop shadows didn't get into the buttons in Flex but it still looks wicked cool.

Our wrap-up session from last night is already uploaded as episode #233 of the Java Posse Podcast at and the best of the lightning talks are starting to show up on

When I'm 64
I could be handy mending a fuse when the lights have gone.