Category Archives: eXtreme Feedback Devices

Dashing through the glow [of displays]

I’ve been making dashboards for some stats we track at work.  I don’t want to trust another organisation with our data; too many dragons.

So that leaves an OSS framework.  I’m using Dashing right now to hit API’s for Google Analytics, Pingdom, etc.  I  think Dashing’s widgets will live a long time, even if the server side becomes unfashionable.  Nice to see recent commits on the project.

One issue was that I found the documentation on the widget types a little vague.   So I made myself a demo of all the widgets.  Here’s the source.

XFD: open sourced

As promised, I’ve open sourced the core of XFD, under an AGPL license:

Thanks to the efforts of Kush, you now have:

  • a plain vanilla XFD, that you can style to fit your organisation
  • all the code to talk to different CI servers
  • with rspec support, and a Travis build:!/builddoctor/xfd-core

The next release of XFD will use this project. Dogfood will be eaten.

Happy hacking!


XFD 0.2.18 Release

We’re happy to announce the release of XFD 0.2.18! As well as improving our own tests and code quality, we added some of your requested features. These include:

Gravatar support

Broken builds now show the gravatar of user that broke the build. This is found by matching the user’s email against the gravatar online image service. Your version control system will need to supply the email address.


You can now filter through the list of builds to only show those thatyou require. This is just currently just a plain text matcher, but we’ll work on regex support if there’s enough interest for it.


One of the most requested features. Many of our users are using HTTPS to keep their transmissions of passwords secure and nowthey can gain all of the benefits of XFD without requiring aninfrastructure change!

As always, the new release can be found here:

XFD 0.2.16 Released

(Kushal Pisavidia has been working on enhancements to XFD – it’s only fair that he gets to do the release announcement)

The beginnings of XFD
A little over a year ago on the 4th of May 2010, XFD was born through the work of Chris and Julian. Since that date it’s gone from a minimally viable status indicator, to a tool which numerous companies use with a number of CI servers to keep their build status visible. The current supported list includes:

  • Hudson
  • Jenkins
  • CI Joe
  • CruiseControl
  • Team City (via a plugin)
  • CCNet, cc.rb, Go (via a plugin)

We’re always on the lookout for new servers to add.

Move to CoffeeScript

For those not familiar with it,


is a little language that compiles to JavaScript. It takes the “good parts” of JavaScript and exposes it through a cleaner syntax. Making it easier to stay away from the bad.

However CoffeeScript isn’t all about syntax sugar. It’s about being more confident that the code you write is correct the first time, while knowing that tests are less brittle and can be changed in a matter of keystrokes. This has made developing XFD a lot simpler.

HTTP Auth is by far one of the most requested features. In this release we’ve added support for both Hudson and Jenkins with more support planned.

Better feedback
In making XFD we sought to make a highly visible build status indicator. Related to the concept of visibility is feedback. This is best illustrated by an analogy to what everyday life would be like without it. Imagine trying to play a guitar, slice bread using a knife, or write using a pen if none of the actions produced any effect for several seconds.

XFD seeks to make this feedback step clearer for build jobs, but didn’t make it obvious what the application was doing at every step. Now, it’s incredibly easy to follow along and get clear information about what XFD is doing as you use it.

Increased accessibility
The emphasis on Red/Green for build status meant that colourblind users may have difficulty viewing the status of their builds. To counter this we’ve added universal symbols in addition to the colours to make this clearer for everyone. The different symbols are used to indicate different levels of importance or urgency with no need to vary their colours.

We hope you enjoy this new release, and let us know what you think!


XFD: now with CruiseControl and TeamCity support

Happy new year!

Your belated Christmas gift is a new release of XFD, our build radiator, with support for CruiseControl, and Team City:

  • CruiseControl versions 2.8.4 and up are supported. You’ll need to be using the JSP reporting application to use XFD (read on for the good news if you’re using the Velocity based reporting application).
  • You can use Team City 5 or 6, with this Team City plugin. We’re reporting on individual build configurations at the moment and will add support for top-level projects in time.
  • We’re also working on another strategy to support the other flavours of CruiseControl and hope to have something ready to beta test very soon …

Please feel free to give XFD a whirl

Tagged , ,

Vote for us in the Ultimate Wallboard Challenge

We’ve been beavering away to get XFD up to scratch for this competition and we’re almost ready.

XFD has a whole host of UI improvements (see the credits for the superstars who helped), and we’re working on supporting more CI servers, very soon.

Would you take 2 minutes to give us a vote? Thank you!

Atlassian are also looking for local representatives, by the way.


Announcing XFD

What have you done? I wrote a Build Radiator, or eXtreme Feedback Device.

Not another one! Why?

A few weeks ago, someone quite innocently locked their Continuous Integration server.  They locked it so hard, it caused the threads that listen for incoming TCP connections to lock up.  This quietly removed their Build Radiator and Continuous Integration server UI from the network.   Such an event causes great hilarity, as it causes developers to think that there’s a network issue, and ask the wrong people to help fix the Continuous Integration server.

What caused the problem was a slightly mangled version of a plugin that creates a Build Radiator.  The product in question is fine.  The outage did cause me to reflect on scaling Continuous Integration, however.  As we scale up development teams, when should we stop dicking about with the server?  How do you expose the state of the build if you keep your mitts off it?

So I set out to build an eXtreme Feedback Device that had no dependencies, and no need to deploy.  The first version is below. It supports Hudson right now, and I plan to add support for more Continuous Integration servers in the future..

How does it work? When you load the page, it tries to connect via the JSONP protocol to a Hudson server.  Unlike technologies like XmlHttpRequest, JSONP can connect to a server that isn’t the origin of the current page, as it returns a callback function which the JavaScript client can sanitise before running.  The results are then built up from the array of JSON build results.  Hudson is one of the few Continuous Integration servers with a JSONP interface.  I’ll support any Continuous Integration server that supports JSONP or any AJAX technique that doesn’t run into Same Origin Policy issues.  I’m already working on support for the next server.

Who wrote it? I started it.  It was fun learning JavaScript, CSS and JQuery during this project. That’s not the whole story, however. Without the tireless efforts of Kushal and the sage advice of Ahmed, it would still be very basic.

What’s next? I’m going to add JSONP support to a Continuous Integration server.  We’d also like your feedback.  I’d like to add some more information to it: for example, it would be nice to be able to tell you there’s a new version of this tool, or perhaps your CI server.

Are there others? Yes.

Build radiator meets browser

At ScaleCamp, the Guardian peeps told me that they still use the radiator that Michael and I wrote. Sure it’s totally different now, but it’s heartening to see.

But things have moved on. This blog post from Fabio Periera describes a new radiator that renders the entire dashboard display in the browser, using GreaseMonkey. Inspired.

I totally agree that a build light isn’t enough detail any more.

6 Big Visible Continuous Integration Tools

I love Information Radiators. You can have all the Twitter plugins you like, but unless you have the updates on the wall, you’re missing something. Here’s a few examples:

  • Green Screen: Martin Andrews just released this. It’s a Sinatra app, and looks like it works for Hudson – perhaps with some tweaking it’ll work elsewhere.[Ruby]
  • CruiseControl Monitor: Sudhindra Rao wrote this for any CruiseControl. I covered it here. [Ruby]
  • Big Visible Cruise: This works for CruiseControl.NET, and runs on Windows. I haven’t had the pleasure.[.NET]
  • Hudson has a plugin to do it, of course.[Java]
  • Radiators: Marco Jansen wrote this in 2005. It’s the earliest example that I’ve seen. I daresay it needs some love by now.[Java]
  • Update: Sam Newman has been flexing his Scala muscles and wrote Big Visible Wall recently. Don’t tell him this, but his code’s generally worth checking out.
  • Update: Atlassian also have wallboards. I’m in the middle of re-skinning XFD. David Ron made Big Visible Cruise Web.
  • Update: Stuart Grimshaw wrote cc-radiator for CruiseControl.
  • Update: Steve Fenton wrote Cruiser for

I find that I always want to provide other project metrics as well. There’ll be a point at which I’ll start hacking to add more information. This is how I ended up with the radiator at Guardian Unlimited.

Know of others? What works with your CI server? Comment here and I’ll update this post.

Image thanks to ninnet.

Hudson on Ubuntu with Big Visible results in six steps

We’ve written before about making your Continuous Integration build (and more) available on the big screen. I just told our CEO that a red build meant that we weren’t ready to release code. That’s a key fact to share with the rest of your team.

Yesterday I set this up at work. It was the easiest radiator that I’ve ever done. Here’s how:

Step One: get Hudson on your Ubuntu machine:

sudo su -

echo "deb binary/" > /etc/apt/sources.list.d/hudson

aptitude update

aptitude install -y hudson

Step Two: have a look for the Hudson admin page with a browser. http://${your_build_machine}:8080/

Step Three: set up a simple project. You might need to add plugins at this point to support your projects. I ended up adding the Ruby and Git plugins to support our Rails and Merb projects. Your mileage will almost certainly vary. Don’t worry about making it pass for now.

Step Four: get the build results out there: on the main Hudson page, click the “Manage Hudson” link on the left. Then click the “manage plugins” link. Click the “Available” tab, click on the checkbox next to the “Radiator View Plugin” entry on the plugins and click the “Install” button on the bottom right hand side of the page.

Step 5: make the plugin useful by adding a new view. There’s a ‘+’ button on the hudson main page:

Click that, and make a new view, which you need to map to the plugin. I called mine ‘radiator’.

Step 6: now you need to choose which projects belong on the screen. If you just want them all, then you can use a regular expression to include ’em all. I used ‘.+’, which matches one or more occurrences of any character. Apply that change, and you’re done.

Here’s the radiator at the my day job: