metade.org

As we add new features to the BBC Music Beta, we have more pages to check before making a new release.

We’re using test-driven-development on the code generating the pages, but obviously these techniques don’t cover the visual appearance of the site. As we reuse the same visual modules on different pages across the site, CSS bugs creep up unexpectedly on different pages across the site.

For example, the code generating the links module is reused on three different pages:

• http://www.bbc.co.uk/music/reviews/2h54
• http://www.bbc.co.uk/music/artists/cc197bad-dc9c-440d-a5b5-d52ba2e14234
• http://www.bbc.co.uk/music/artists/cc197bad-dc9c-440d-a5b5-d52ba2e14234/links

And to illustrate the problem, I just noticed a CSS quirk with the background of the links module on that third link. So I started thinking about how one might go about regression testing CSS and hacked a simple solution together using CutyCapt, ImageMagick’s compare tool and Ruby Rake.

The result is illustrated here:

Stable version of BBC Music Beta artist profile page

Development Version of BBC Music Beta artist profile page

Difference between the stable and development versions of the site

The first image is a screen capture of the stable version of an artist’s profile page, taken directly from the live BBC Music Beta. The second image is taken from our development version of the site. The third image shows the difference between the two - in our upcoming release we are shuffling some of the modules around so these changes are very noticeable.

At the moment, my tool is very basic: you give it the stable and development host names, and a list of paths to test (example configuration). It uses CutyCapt to pull down each of the paths from the stable and development hosts, and then runs the ImageMagick compare tool between each pair of images. It then produces a very simple HTML file that displays all of the pages being tested.

While we’re just using this tool informally at the moment, it’s already been really useful to catch unexpected CSS bugs on our site.

At BBC Audio and Music Interactive, I’m one of the software engineers working on the BBC Music Discovery team. This week we launched the BBC Music Beta, which focuses in particular on publishing information about the artists broadcast on the BBC. You can read more about the site on Tom Scott’s blog and BBC Radio Labs.

Matthew Shorter describes at the bottom of his post how to use MusicBrainz to find a given artist. Here’s a little something to make that a touch easier: a BBC Music/MusicBrainz bookmarklet!

Drag this BBC Music/MusicBrainz link to your bookmarks bar in your browser. Now, when you’re on an artist page (e.g. Coldplay) click on the bookmarklet to switch between BBC Music and MusicBrainz artist page.

Enjoy!

When I presented my music recommendations hack at Mashed last weekend, I showed some examples by randomly browsing around the artists and brands pages.

When I came to the Giles Peterson show, I was surprised that the system was recommending artists such as ‘The Automatic’ and ‘Arctic Monkeys’.

This struck me as extremely unusual recommendations for a show featuring “Latin, funk, soul and hip-hop”, but I suspected that the data rather than the system was at fault. I had a quick look at the source data that had been fed into the system for this show and found:

• The Wombats (1)
• My Chemical Romance (1)
• Hard-Fi (1)
• Gideon Conn (1)
• Armand Van Helden (1)
• Editors (1)

Looking at this list, it seems that the recommendations actually make sense: there is very little data for the show, and actually it doesn’t even look correct!

This data has been generated from the digital play out system but we are unable to track some of the shows, especially specialist music shows such as Giles Peterson. The DJ might play directly off their own vinyl/cd/computer/other crazy device, or the show might be pre-recorded.

So what I’ve done is simply ignore brands with a low average artist play count (<=1.0), which should avoid this kind of situation.

I also want to point out that there is a basic API in place, although it still needs documenting. Just add '.json' at the end of brand/artist/last.fm profile URLs to get a JSON feed of the data.