On November 3rd I attended the Red Dirt JS conference in Oklahoma City, where I gave a presentation about the Underscore.js library. I was nervous that my talk might not be very novel - most JavaScript developers I know are already big fans of Underscore - but it turned out that most attendees had never used it. If just one attendee ends up less frustrated with JavaScript collections as a result of my talk, I’ll consider myself successful!
The other talks were great. To name a few, Nathan Smith gave a very entertaining history of the Web thus far, fellow Waco resident Derick Bailey presented on Backbone, and JD Dalton introduced Benchmark.js. Brandon Satrom’s talk on CoffeeScript was exceptionally interesting, even with it being prerecorded - I hope in the future I’ll get to hear him in person.
My slide deck is online here. This was my first ever conference presentation, so I’m very grateful to the organizers for giving me the opportunity and the audience for being so gracious with their attention. Looking forward to next time!
As of 29 August 2011, I’ve migrated my blog from a self-hosted WordPress installation to (at the time of writing) 35 static HTML files hosted on Amazon S3. These HTML files are generated on my computer by Jekyll and uploaded using Transmit, in which I press a button and all my posts are synchronized to the cloud.
This is much lower-tech than a blog on a content management system, and wouldn’t work for most people. Indeed, the first time I heard about Jekyll I dismissed it as being too basic. After all, why would I forgo all the features of a CMS for the sake of some boring HTML files?
I decided to make the switch two weeks ago. I was struggling to write a post about Google App Engine’s free tier when I realized that WordPress’s bulk was slowing me down. I don’t need plugins, or TinyMCE, or multiple users, or post types: I just want to write about technical things that I think are interesting. I’d recently decided that I wanted to write in Markdown, which Jekyll enables by default. I found the official migration documentation, noticed that migrating to Jekyll looked very straightforward, and started building my new blog.
I found moving from WordPress to Jekyll very easy. I followed this migration guide and imported all my old posts into Markdown, which after you learn the format is much better for blogging than HTML. I wrote a new theme using the Liquid templating language (there are many example themes you can crib from here), and styled it primarily from the Twitter Bootstrap CSS framework. I put the site on S3 by following Amazon’s guide, and the payoff was immediate: as you can see below, the site’s response time has more than halved.
I’m really glad I’ve switched my blog to Jekyll. There’s less code to maintain, greater flexibility, fewer distractions, and now that my setup is simpler, I feel like my writing has improved. I’d recommend Jekyll to any technical blogger who’s tired of their bloated CMS and who wants to write more efficiently and enjoyably.
Update: Just my luck - I write 99% of a blog post about how I got around the limitations of Google App Engine’s free tier, and then I get an email announcing how Google will drastically change their price structure not in my favour. Looks like I’m not done trying to outsmart Google’s billing department…
Google App Engine’s free tier is great for small apps, but as I discovered when Twitty City reached a gigabyte of storage, its limitations can be extremely frustrating.
Twitty City ran well for its first few months, but after 400,000 tweets its datastore was full and needed to be cleaned up. Unlike the typical MySQL/PHP setup, GAE does not give the user the ability to delete from the datastore with SQL commands: data must be obtained programmatically. The only way to delete several rows is to select them in your program’s code, iterate over them, and delete them individually. This would be tolerable, except for three factors:
- It’s not possible to delete more than 1000 rows at once.
- Deleting rows is very CPU intensive: to delete 1000 rows at once consumes two minutes of the 6.5 CPU hours a free app is allowed in a day.
- There is no programatic way to see how much of your CPU quota remains, so you can’t automate a deletion task without the risk of depleting your CPU.
I reasoned that, if deleting 1000 rows used two minutes of my daily 6.5 CPU hours, I could run my ‘TidyUpHandler’ every eight minutes and not take my app offine. After many hours of gradual purging, the stale data was cleared and Twitty City was brought within disk and CPU quota. The TidyUpHandler still runs every eight minutes, and as a result storage is now stable at around 12% of capacity.
If you aren’t constantly maintaining your data, GAE is quite unforgiving. A gigabyte of free storage is unparalleled in web app hosting, but if your app’s datastore grows quickly by itself you need to take measures to ensure it won’t get out of hand, and you need to do so before you’re near quota.
(Or, you could just pay for extra storage/CPU, but where’s the fun in that?)
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:
-
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:
-
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:
-
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.
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.
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.
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?
On December 4th I participated in the Oxford Open Data Hackathon Day, a gathering with the purpose of exploring public data and presenting it in interesting ways. Earlier that week, Tim Davies informed me of an API to analyse the sentiment of tweets, which gave me the idea of using it to determine the mood of a city in real time. And thus, Twitty City was born.
Twitty City is a small web app which, for five cities:
- Collects tweets geolocated to that area;
- Submits the last hour’s tweets to an API for sentiment analysis and computes an average sentiment value;
- Displays a smiley face appropriate to the average sentiment; and
- Graphs the previous week’s average sentiment scores.
I chose to write Twitty City for the Google App Engine for two reasons. First, price - the App Engine free tier is quite generous, and amply meets the needs of a small application. Second, Python - I use PHP all the time in my day job, and it’s nice to have an excuse to explore a different language. My main grievance with App Engine is that (at time of writing) the servers are running Python 2.5.2 but the SDK is running v2.6, so it’s very easy for an inexperienced Pythonista like me to have a false sense of security about the availability of certain libraries (I’m looking at you, json).
I’ve put the source code on GitHub, partly out of vanity, partly to gain practice with Git, but primarily so that people who want to analyse other cities can have a good starting point. Overall, I had a great experience writing this app, and I’m already thinking of how I’ll next improve it.
Photos from the event can be found here. I really enjoyed meeting so much of the Oxford geek community, and am looking forward to seeing them again!
Update (27 Aug 2011): This post has been updated to reflect my blog’s migration from self-hosted WordPress to a static site generated by Jekyll.
Does WP Super Cache work on PHP Safe Mode? The answer is yes, despite warnings to the contrary. When this blog was running WordPress it ran in safe mode (on NearlyFreeSpeech.NET), and as you’d have seen in the HTML source, you’d have been viewing a cached version of this page.
(A big shoutout to Donncha O Caoimh and everybody else responsible for the fantastic WP Super Cache plugin)
Google Chrome is a great browser for many reasons, but I particularly admire its ability to silently, unavoidably upgrade. The wider impact of this feature is made apparent on Clicky Marketshare, which shows how when a new Chrome is released, the previous version completely disappears:
In a matter of days, the old version of Chrome has vanished from the web, and all its sins are forgiven. By constrast, Internet Explorer versions 6 and 7 still hold considerable marketshare despite long being deprecated, and we’re all suffering for it:
Those browsers are far behind the curve, with many bugs, and their continued existence is responsible for a significant stifling of innovation after all, what’s the point of making better websites with advanced HTML/CSS if most of your users won’t be able to see it? If only Microsoft had incorporated such a dramatically effective auto-upgrade all those years ago, the work of a web developer would be a lot more enjoyable and a lot less frustrating.
Alas, there is no IE6 killswitch, and though its numbers are moving encouragingly lower, it remains an occupational hazard. So, until the last line of IE6-specific code is written, I will dream of a button in Microsoft HQ that with one fell swoop will bring all web users into the new decade.
