Code Baboon

Frequency Of Characters In Drupal

Mark — Tue, 20 Dec 2011 19:40:56 +0000

I've been thinking a lot about how we use keyboards, especially as coders, so I ran some frequency analysis on a Drupal installation to see how often certain characters are used, with a view to optimise my keyboard. Specifically, I was looking at non-letter characters (specials and numbers). The code that does this is available as a simple drush command here.

Here are the results:

OSX: Remap Keys Microsoft Natural Keyboard

Mark — Wed, 30 Nov 2011 21:39:52 +0000

Just a quick note for the internet at large: to remap the zoom, favorites, shortcut buttons, etc. on a Microsoft Natural Ergonomic Keyboard 4000, when using Apple OSX, you need to use USB Overdrive.

Just open the preferences pane, and hit the special key you want to modify. It appears in the list, and you can remap it to anything. Extremely useful.

EDIT: For a more complex solution, which is powerful but harder to learn, try ControllerMate.

Performance testing Drupal using The Grinder

Mark — Thu, 10 Feb 2011 11:53:36 +0000

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 instead along with Eric Baumes (CTO of The Economist). Thanks to The Internet Archive, the presentation is available and you can see David doing an excellent job with my slides.

http://www.archive.org/details/PerformanceTestingTheEconomistOnlineUsingTheGrinder

The Economist: Testing Drupal using Selenium

Mark — Mon, 17 Jan 2011 16:16:07 +0000

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. The entire suite takes just under 8 minutes to run, which is the length of the longest test. A screencast of each individual test run is captured in full motion MP4 video, and made available as a build artifact in Hudson for anyone to download and watch. The video is captured at full resolution (1200 x 2000), but you can see a scaled down version below of an actual test running on Economist.com:

The Economist: Testing Drupal

Mark — Thu, 13 Jan 2011 14:40:36 +0000

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:

The Economist: Human testing

Mark — Tue, 11 Jan 2011 16:16:46 +0000

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.

The Economist: Coding workflow

Mark — Tue, 11 Jan 2011 15:38:24 +0000

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.

The single tool that has had the largest positive impact on code quality and general sanity has been Launchpad. We switched from Subversion to Bazaar / Launchpad in March 2010 and although we didn’t do any official metrics, I would guess we have slashed the defect rate by at least half since doing that.

The Economist: Local environments

Mark — Tue, 11 Jan 2011 14:33:35 +0000

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. A good choice for Apple OSX is VMWare Fusion:

Cookie debugging fun

Mark — Wed, 20 Oct 2010 09:44:37 +0000

Yesterday we debugged a problem of a cookie inexplicably disappearing. It turned out that an invalid favicon.ico link was causing the issue (!). The CDN module rewrites the favicon link in the to be served from media.economist.com:

<?php
  <link rel="shortcut icon" href=
"http://media.economist.com/sites/all/themes/econ/favicon.ico" 
type="image/x-icon" />
?>

The CDN, however, wasn't configured to serve .ico files, so it was issuing a redirect to http://www.economist.com (the homepage). That caused weirdness with the favicon in general, although sometimes it would appear, presumably by magic.

When going to a channel page, the cookie would be initially set by the first set of response headers, then the favicon would load a redirect to the homepage, which immediately clears the cookie (correct behaviour). However, there are no visible side effects that anything is going wrong except an occasionally wonky favicon.

Let's just say that debugging this was... non-trivial.

Technical debt & refactoring

Mark — Sun, 17 Oct 2010 10:12:24 +0000

Here's my attempt at bringing to life the "Technical Debt" analogy. I wrote this and circulated it around at The Economist to help others understand why refactoring code is so important, especially when doing agile. Repeatedly prioritising short-term wins, without stopping to consider a codebase's architecture, results in an unmaintainable system:

The manufacturing of cars at Legacy Motors (LM) was all done by a team of talented engineers and designers, who hand-made each vehicle to an exact customer specification. All was well, until one day, the shareholders, wanting to expand business, came up with a plan to increase sales: they decided to invest in an assembly line. By getting the team to build machines that build cars, instead of having the engineers build the cars themselves, they could greatly increase their CPM (Cars Per Month) and vastly expand business.