BuildMonitor Development Notes

Usage Scenario

When I first developed BuildMonitor, I thought that the typical users would be something like a team of 5-10 developers working on a project, and they would be located in the same building.

After v0.1 was released and feedback started coming in, I learned that some users want to monitor 10-20 projects on the same Hudson instance, there are projects with developers scattered across different time zones, and there was someone who asked for non-English translations since Hudson itself has been translated to 7 languages.

Feed Processing

On v0.1 BuildMonitor attempted to parse a complete Atom feed using jFeed & jQuery, which was ok on my tiny test feed, but failed misserably on real projects with lots of builds resulting in large feed. The full Atom feed parsing slowed Firefox for several seconds and froze the user interface, specially on low-spec machines.

This had since been fixed by parsing only the minimum required elements and by limiting the number of builds to parse. I also decided to use plain DOMParser instead of jFeed.


Javascript and XUL coding was the fun part of the add-on development, testing was the annoying part. I haven’t found any way to automate Firefox Add-on testing, and as everyone knows, manual UI testing sucks.

**Mozilla Add-ons Policy **

Mozilla has been doing a great job with ensuring the quality of the add-ons with their policy which protects Firefox users from malicious add-ons. The policy requires user reviews for public access nomination, but at the same time the site requires user registrations / login to download a sandboxed add-on, something that most people like to avoid.

This introduces a chicken or egg situation. Add-on needs users to test and review the site, but the potential users and reviewers are chased away by the requirement to login. This is even worse for BuildMonitor because the intended audience is targeted to Hudson users, a much smaller portion of Firefox users.


New translation can easily be added to BuildMonitor by adding new locale files to /trunk/hudson/extras/firefox-extension/buildmonitor/src/chrome/locale/ .

As someone who is quite fluent in Indonesian, I attempted to translate BuildMonitor to Bahasa Indonesia (id-ID locale). And it turned out that translating IT terms to Indonesian wasn’t easy, even with the use of Glosarium. I left Indonesia before the era of Internet, and by now there are tons of Indonesian technical terms that I’ve never heard of before.

What’s Next

Figure out a way to implement automated unit testing, at least for the javascript code, consider using JSMock and JsUnit. Try using Maven to build BuildMonitor, to make it consistent with the rest of Hudson.

Share Comments
comments powered by Disqus