metade.org

I joined the BBC as a software engineer in Future Media for Audio & Music Interactive just over 5 years ago.

It was just before the first release of BBC Programmes, and it was a couple of months before the iPlayer streaming service on the web launched in December 2007.

I came to the BBC because having developed a number of research prototypes in academia for a few years, I wanted to build stuff with a significant number of real users. And I’ve certainly been able to do that, having worked:

• on a page for each artist on BBC Music and clickable tracklists for programmes pages
• a year at Radio 1 working on things like the chart, live lounge and getting twitter to drive Scaletrix cars
• on the Radio 1/1Xtra homepage project
• on a number of music events sites, both in the good old static html days and with the new music events platform
• on the launch of iPlayer Radio

It’s been incredible. I’ve learnt so much, not just from the technical side but also as an individual. I’ve worked with really brilliant developers, designers and editorial - making great friends along the way. I’ve worked on some amazing projects, and written code that is used by millions of users each week.

However, all good things must come to an end and I’ve decided it’s time for me to move on.

Friday was the last day at the BBC for me, and today I’m starting as a technical lead at Sidekick Studios.

Last weekend I participated in another Music Hack Day.

I managed to convince my girlfriend, the brilliant Kirsten Fletcher, to join me. Kirsten is a freelance costume designer-maker, who is more used to working on theatre and movie productions than hack days.

Screecha

Together we made Screecha: an interactive musical toy aimed at children. It’s a puppet that can house a smart phone in it’s belly and an app to go with it.

Using the app, children can: - listen to their favourite songs (using the Spotify Metadata API and Cocoalibspotify) - view the lyrics as the song plays (using Echonest and Musixmatch) - record their own songs and upload them to SoundCloud - listen to the masterpieces they’ve previously uploaded to SoundCloud

As a song plays, the puppet can be manipulated to sing along with the music.

The idea

The idea was mostly inspired by hanging out with some close friends who have a baby. They were talking about how many children’s songs and nursery rhymes were available on Spotify, which led us to think about a Spotify app as a physical toy.

We then started looking on other music services for children’s songs and came across a recording of a toddler singing “Twinkle, Twinkle Little Star” on SoundCloud. That’s when we decided that the ability of recording and saving children’s performances would add an interesting angle to the hack.

Hacking with a sewing machine

While I was was doing the usual coding activities involved in a hack day (basically throwing code together until it worked), Kirsten designed and built the puppet from scratch.

This obviously required a fair bit of planning and organisation upfront. She had to have an idea of what the puppet would look like in order to select which materials she’d need to bring to the hack day. She had to bring in her sewing machine (the first sewing machine at a Music Hack Day!) and a big bag of fabric as well as the other tools required to make the puppet.

It was really interesting to see the process that she took. Based on a simple sketch for the design, she created a pattern: a paper template from which she made the preliminary shape for the puppet. After some tweaking, she adjusted the pattern and cut the fabric for the final puppet prototype. Then it was a matter of sewing it all together and finishing it off.

It really made me appreciate how lucky software and web developers have it: all we need is a laptop and internet connection and we’re effectively limited by our imagination and ability.

Hacking with iOS

The Screecha app was actually the first time I developed a native iOS application. It was implemented using PhoneGap, so most of the user interface was developed using HTML/CSS/Javascript and Twitter Bootstrap. However, I did have to integrate cocoalibspotify so I did get to tinker about with some Objective C.

As a Hackday prototype, it was actually a bit disappointing to have developed a proof of concept that couldn’t be shared or made publicly accessible. If I had to do it again, I think I would go down the mobile webapp route using the HTML5 Audio API.

Focus

From the start, we had a really clear idea of what we wanted to build: a puppet and a simple app that allowed you to play music, record sounds and upload them to SoundCloud.

We focused on implementing just that, resisting the temptation to add more features to the app or consider hacking some hardware into the puppet - there simply wouldn’t have been enough time to complete the prototype otherwise.

In my experience, good hacks can be the result of lots of iteration, last minute changes and a great deal of “hacking”. With Screecha, we took a good idea and focused on implementing just the essential features.

Screecha won an award from Spotify for best use of the Spotify API, and an award from SoundCloud.

A couple of years ago I helped develop a fundraising application for the Child’s i Foundation, a charity and worldwide community aiming to build a home for abandoned babies in Uganda.

At the time the charity was raising money to set up a home in Kampala, so the team at Childsi came up with Buy a Brick, a web app where users donate from £2.50 to £500 to purchase a brick to build a virtual wall.

In the 2 years since it launched, the Child’s i Foundation community has bought nearly 400 bricks, raised nearly £18,000!

I implemented the backend of the application in Ruby on Rails, in particular the integration with the payment gateway for processing donations. It was the first (and only) e-commerce website that I’ve ever deployed and maintained - I learnt a lot!

Over the last couple of weeks, we’ve been tinkering with the application so it uses the Just Giving donations API instead of the original payment gateway. We ended up using (and patching) the Just Giving Ruby gem, so the switch over was pretty simple to implement.

What wasn’t so simple was upgrading an old, pre-Bundler Rails 2.2 application to Rails 2.3 and getting the right combination of gems versions to play together on Heroku! But I got there in the end…

The application is at buyabrick.childsifoundation.org/ and the code is all on Github: github.com/childsi/buyabrick/

Last week, Radio 1 and 1Xtra launched their new homepages: - http://www.bbc.co.uk/radio1/ - http://www.bbc.co.uk/1xtra/

I’ve written a “under-the-hood” post on the BBC Internet blog, describing how we approached the technical challenges to meet the editorial ambitions for the new homepage.

I was on attachment with the Radio 1 and 1Xtra Interactive team when the design was conceived, and although the site was built by the fantastic team at Kite I’ve been heavily involved throughout it’s development.

I might be a bit biased, but I think it’s pretty special! What I’m most happy with is how we’re pushing content to the page using BBC PushFeeds (i.e. XMPP PubSub over Websockets or Flash as a fallback) to enable the live experience. On top of that, we’ve delivered an admin system that allows producers to promote content to the homepages within seconds.

Track now playing information has been present on the BBC national radio networks sites for a number of years, but in the new homepage they are put into the spotlight. The beautiful packshots (album art) are mainly taken from the Radio 1/1Xtra charts and playlists. Using MusicBrainz identifiers we’re able to surface content from BBC Music, including artist biography, latest clips and album reviews.

I believe this reinvents the way the stations present themselves online, and potentially on air. Whenever something happens in the studio, it’s on the website in seconds in the form of an update, photo or live video stream. The audience’s reaction to the show can be surfaced online in the form of their texts, tweets or Facebook comments.

It’s opened up a new toy box of possibilities, and I’m really looking forwards to see how both the audience and the stations engage with what we’ve built.

A few weeks ago I took part in Young Rewired State (YRS), a week long hack event aimed at young developers aged between 15 and 18 and focused around Open Data.

Together with Dave and Kerron, I was one of the mentors at the Young Rewired Blackfriars which was hosted at Fluxx Studios. Our group started by brainstorming during the first morning, focusing on 4/5 ideas which eventually led to 1 project: searching and visualising University course data.

The team built UniMatch:

There’s a live demonstration available at http://unimatch.net/.

I was really impressed by the Fluxx Capacitors team. I loved the way they came up with ideas during the brainstorming sessions - there was some really great things coming out of it. Coding wise, there was a wide range of abilities, from those who had been programming for years (i.e. since they were 10), some of them had tinkered with some HTML and CSS and others who hadn’t coded at all but were keen to learn. The more experienced ended up doing the heavy lifting on the server side and more advanced Javascript front end work, and the rest of them worked on designing the UI and then implementing the design and HTML/CSS.

There were some really ingenious approaches to working collaboratively too. When they started editing the code on a shared server space, they used a system consisting of wooden blocks for each of the components (e.g. HTML, CSS, database and server code) to prevent multiple people editing the same file at the same time.

As a mentor, it was brilliant to be able to point the more code-oriented people in the right way in terms of software development best practices such as source code control and web applications frameworks.

I wasn’t able to attend the presentation, but it’s available on the YRS UStream channel. They did a fantastic pitch (about 1h 9m mins in), and came away with the Most likely to be bought (code or concept) prize. Great work Leon, Richard, Joanne, Hugo, Kerron and Priscilla!

Some of them are continuing to work on the project, so it’ll be interesting to see what they come up with.

I’ve written two blog posts in 3 years - I have to admit I’ve not been very good at this blogging thing!

I have been pretty busy over the last few years at the BBC. I did a lot of work on BBC Music, and I spent a year with the Radio 1/1Xtra Interactive team where I had lots of fun. More recently I’ve been working on the music event sites.

Away from work, I’ve been to a few hack days including a couple of Music Hack Days, Linked Gov Hack Camp and a few Rewired State events.

I’m going to try imposing a new rule on myself: I will force myself to write up anything I work on that I spend more than an hour on!

Photo by Jenny Ekelund

A few weeks ago I took part in the Said.fm Radio Box Hack weekend, where I did some experiments with Mobile HTML5 geolocation and audio playback on mobile devices.

I had been playing with what I was calling a “GeoSoundBoard”, where users could walk around unlocking sounds when they reached certain locations. My demo was using sound clips from a BBC Radio 1 soundboard for Tim Westwood - imagine walking around the corner and hearing Westwood drop a bomb!

You can try it out for yourself - drag and drop the blue marker onto one of the nearby orange markers to hear it go off.

On my iPhone I found that while the HTML5 audio would play fine when I dragged and dropped the marker, it wouldn’t play when I actually walked towards one. I never got to the bottom of this issue but it’s likely to be because HTML5 audio playback on mobile devices must be triggered by direct user interaction to avoid excessive data charges or battery consumption.

So at the Said.fm hack day I decided to change the UI so that it would display information about the track a user had unlocked such as an image and description and offer the option to play the track. I also wanted to prototype an authoring solution so that curators could produce audio playlists around a certain theme and scatter those tracks in the real world. And with Abdel’s help we got a more robust player implementation for the audio playback.

You can check out what we built at http://geosoundboards.heroku.com. It uses: - Ruby and Sinatra - JQuery Mobile - JPlayer for the audio playback (thanks Abdel!) - Google Docs for the CMS check out the instructions and a sample playlist

And the source is on GitHub.

Thanks to the Said.fm guys and all of the other Radio Box hackers - it was fun!

And I’m hacking some AudioBoo and Flickr stuff on posterous…

This weekend I attended Social Innovation Camp, (SICamp) where I had an absolutely fantastic time! SICamp is an experiment to bring together people over a weekend and get them to build/prototype web apps that will drive social change - check out what the Guardian had to say about it on Saturday and then on Sunday after the projects were presented.

I worked on the we-need.org project, which was led by Craig Griffin from Fresh Voice. The idea is to provide a web site where people with disabilities are able to express their needs through an accessible web interface rather than having their needs assessed by the system as it is currently (i.e. by filling in a 50-odd page form). The site would then aggregate and present interactive visualisations of the needs in a given community so they can be more efficiently handled. Hopefully the video of the pitch we presented on Sunday will be made available online soon, where our team explained the concept far better than I can!

For the weekend, we built a Ruby on Rails application where users could use a basic html form to express their needs. We also experimented with a graphical radial interface which is better suited for people with certain types of disabilities. We used the Geokit Rails plugin to geocode users’ addresses so that their needs could be plotted on a map. We used Simile Exhibit to prototype the visualisation of the aggregated needs of communities on a map.

As mentioned during the project presentation, we required some sample data so I put together some Ruby to randomly generate some users and their needs. So here is the infamous Ruby “random needs generator” one-liner:

(0..rand(3)).to_a.map { |a| rand(@@need_count)+1 }.uniq

I’ve bravely put all of the we-need code on github, but do keep in mind that it was all built in less than 24 hours!

I had a really amazing time, worked with some fantastic people on We Need and also really enjoyed the post-SICamp discussions in the pub on Sunday! Big thanks to the SICamp team for organising everything - I’m already looking forward to the next SICamp meetup!

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.