Sebastian Motraghi on life, tech, et cetera

How to add the Google +1 Button to your WordPress theme

Google Plus One

The Google +1 button hit the web earlier today, and I couldn’t resist the opportunity to put it on WordPress. Follow these steps and you can enable Google +1 on WordPress’s default TwentyTen theme:

  1. First we need to add the relevant JavaScript to the theme’s header file (by default at /wp-content/themes/twentyten/header.php). Just before the closing </head> tag, add the following:

  2. We then need to adjust loop-single.php so that individual posts will have the +1 button on them. Immediately after the <h1 class=’entry-title’> line (likely on line 26), add the following:
  3. Finally, add the following to loop.php immediately after the final <h1 class=’entry-title’> (likely on line 132), so that posts on the homepage will have +1 buttons:

And that’s it! Now you’re ready to make good on the Internet’s latest e-validation button.

How to test UTF-8 email subject lines in Symfony

Succcess Tests with Lime

One of our clients needs to send emails with UTF-8 subject lines. Swift Mailer, which Symfony uses, makes this easy to do, but writing functional tests for it is another story. The problem is that, if non-ASCII characters are present in the subject line, Swift Mailer encodes them as required by RFC 2047 for example, a string like “Transformación” turns into “=?utf-8?Q?Transformaci=C3=B3n?=”. How do we know that this is the right subject line?

There’s no immediately-available “convert this into a RFC 2047-compliant subject line” function, but we can get around this by making use of Swift_Message->toString and some choice preg functions.

First, create a dummy message containing the appropriate header. Swift_Message->toString() will contain our encoded header:

Next, we have to extract our encoded header I’ve used preg_match() and a fairly simple regex.

Finally, now that the encoded header has been extracted, we need only wrap it in preg_quote() (because checkHeader() uses regex syntax) and test away.

Voila - now we can be confident that our test script can deal with Unicode email subjects. If you can think of a way to make this simpler, or more robust, let me know in the comments.

JamBox - a music box for the web

Update: As of October 2011 JamBox has been ported to use Socket.IO and is hosted on Heroku, which does not presently support WebSockets. The information in this blog post is therefore (mostly) out of date - the God process is no longer around, and JamBox now works in most major browsers.

JamBox logo

My day job making content-managed websites is fun, and it pays the bills, but sometimes it’s nice to do something a little unconventional. So, I was thrilled when we had a “dev day” to write apps of our choosing in any language we wanted. Inspired by Jeff Kreeftmeijer’s node.js demo site (which shows every other visitor’s cursors in realtime) and Ron Winter’s Flash drum kit, I set about making a supercharged collaborative drumkit: JamBox.

JamBox’s premise is simple - each time you press a key, a sound plays, and everybody else on JamBox hears it. There are drum sounds, an extremely cheesy lead synth, a chunky slap bass, and various percussion noises (cowbell, bongos, DJ scratches, a dog woofing), so multiple users can play together and coordinate an actual jam session.

First, I wrote a single-user JavaScript drumkit - each sound is preloaded in the browser, and the keystroke listeners are bound. I then drew from Mr. Kreeftmeijer’s sample code to write the multi-user functionality. Crucially, I had plenty of time at the end of the hackday to spend in front of my favourite music-making tools, picking the right instruments and sampling them to perfection.

A downside is that JamBox relies on WebSockets, which aren’t supported by many browsers - not to mention, only a few browsers support .mp3 playback. As a result, JamBox has an “only works in Chrome/Safari” warning. Eventually I’d like to rewrite it to use the non WebSocket-specific socket.io library, and to switch between using .ogg/.mp3 files depending on the browser’s capabilities.

Another challenge was posed by the JamBox process’s tendency to stop running. Thanks to some sample code (again from Jeff Kreeftmeijer) I configured a God process to restart JamBox whenever it crashes.

All in all, I’m very pleased with the JamBox experience. I had a lot of fun making it, and even more fun making phat beats with it. Many thanks to White October for letting me build JamBox on company time, Jeff Kreeftmeijer for providing inspiration and generous sample code, and to my coworkers for helping me test and showing their musical talents.

First Impressions of the Mac App Store

App Store Logo

Like every other Mac user on the planet, I was really eager for the Mac App Store’s release today. Having had the chance to explore it a little, here are my initial remarks:

  • The interface is just like every other Apple store - a few featured apps are given prominence, and there are top ten lists down the side.
  • Apps are downloaded straight into your usual Applications folder. This was a relief for me, as I’d been concerned apps would be corralled much as iTunes purchases are.
  • If you’ve downloaded an app not from the Store, and you then download it from the Store, the old non-Store version is replaced with the new one I noticed this when I downloaded the Evernote app. This isn’t a big deal for me, but it would be problematic if you have a good reason to cling to an old version of an app.
  • Apple software that had previously been bundled into the iLife or iWork suites is now available standalone - for instance, you can now buy Garageband on its own for $15 (a massive bargain).

Overall, I’m excited about the visibility that this will give to software developers and their products. The iOS app stores have proven to be a goldmine for developers and Apple alike, and I don’t doubt the Mac store will be equally fruitful for a whole new class of developers. Time to dust off those Cocoa books, perhaps?