Drupal

I've been thinking a lot about how coders use keyboards, given that they weren't specifically designed for writing code, and yet we are some of the heaviest users around. I ran some frequency analysis on a Drupal installation to see how often certain characters occur in the source code. Specifically, I was looking at non-letter characters (specials and numbers). The code that does this is available as a simple drush command.
I was unable to co-present at DrupalCon San Francisco due to a volcanic ash cloud that prevented anyone from flying out of London for a week, so David Strauss did my part, along with Eric Baumes (CTO of The Economist). Thanks to archive.org, the presentation is available and you can see David doing an amazing job presenting our work. Presentation Session on Archive.org
Selenium is an automated software testing framework for web applications. It drives a real browser automatically, as if a real person was doing the clicking and typing. We use it here at The Economist for functional / black-box / acceptance testing, the kind of tests that are repetitive and time-consuming to step through manually. We've setup a system that runs our full suite of regression tests in parallel, using virtual machines in the Rackspace cloud, on every commit to trunk.
You want to test your Drupal code? We’ve learned how to do it, the hard way, through 3 years of experience with continuous integration at The Economist. And I can distill our current approach into a few short paragraphs: 1. Use Simpletests to unit test code. Unit testing is vital, but it’s also difficult in Drupal, because a lot of time you’re actually writing glue code, or exporting Views, or theming.
Running an out-of-the-box stack like MAMP may be fine for part-time tinkerers, but if you're writing code for a serious site you'll quickly realise that it's important to develop against the same version of the stack that's running in the production environment. You'd be amazed at how many subtle bugs emerge between two minor point releases of PHP, APC, MySQL or any other of the myriad components. Catching them early is crucial, and the easiest way to do that is to use a virtualised developer environment.
We have a fun concept here that we call a “human test instance”. Anyone can create an entire copy of Economist.com, running in the cloud, on a subdomain of their choice, on a branch of their choice, with just a few clicks in Hudson. “Human testing” implies that the instance is used by a human to do manual testing, however, we use a human test instance to run automated Selenium tests, and each one also effectively tests the process of running the update functions every day.
Economist developers are a big, distributed lot. At one point we had 4 teams doing development in 4 different timezones from San Francisco to London. As you might imagine, this presents some extremely interesting challenges, like source code control and maintaining communication channels between teams to reduce the amount of toe stepping and work duplication going on. Bazaar & Launchpad The single tool that has had the largest positive impact on code quality and general sanity has been Launchpad.
Check out this interview I did with Matthew Revell from Canonical (Ubuntu, Launchpad) on how we're using open source software at The Economist.
David Strauss and I are presenting the load testing work our team did at The Economist. Here's a link to the session information. UPDATE: I was unable to attend the conference, as all flights were cancelled following the volcanic eruption of Eyjafjallajökull :< I made a follow-up post here: Performance Testing Drupal
My new surfboard is a custom 6'3” made by Clayton in Durban, South Africa. I took it for a test drive last week and it is a sweet board indeed! Very reasonably priced too, especially after converting British pounds into South African rand. I'm currently based in London, but planning a few surf trips to Indonesia and Western Europe in the near future. Look out for photos of Druplicon riding waves.