Learnings from building The Times’ #indyref interactives

Bonus question: Something's fishy about this photo. Can you figure it out?

In preparation for the Scottish independence referendum, Josh Boswell and I were tasked with preparing the usual visualisations: a “balance of power” graphic for the front page, and the customary results map. We had worked together on a similar project during the local elections earlier this year, and we tried to build upon what we’d learned.

Before I get to what we’ve learned from the process, note that we’ve open-sourced the NodeJS server code used to grab XML documents from the Press Association FTP server. Get it at github.com/times/election-server.

Lesson 1 — Websockets are tricky

We had a beautiful bit of functionality provided via Socket.io for updating readers when new data became available. A happy little message would pop up saying “Updating results”, CSS animations happened, was gorgeous stuff all around.

Alas, 2000+ clients connecting to the server simultaneously made it fall over pretty badly — I’d run into “EMFILE” errors within seconds of the server starting, even on a m3.large instance. This resulted in me disabling websockets at 4:00 a.m. on election night. Thankfully, the only downside to this (beyond having to refactor highly-visible live code at four in the morning) was that users had to refresh to get the updated map — see the bit below about S3.

Next time around, I’ll probably have a separate, load-balanced Elastic Beanstalk environment specifically for this purpose, with the main server running by itself and proxying notifications to clients via the Elastic Beanstalk instances. Websockets are bananas, I now know why people use services like Pusher.

Lesson 2 — PhantomJS is rad

Another cool thing that was awesome in development but a slight headache in production was my bit of code that screencapped our map and pushed a PNG of it to S3, to be consumed on the front page. This made our map thumbnail update dynamically over the course of the evening.

However, in trying to fix the websocket issue on election night, I ended up also doing a quick refactor so that process would run independently on a Heroku instance instead of bogging down the main server because spawning PhantomJS isn’t exactly the lightest thing ever.

That said, it was really fun working with it and I plan to do some more stuff with it eventually. Scaling issues aside, I think the auto map screencap script is one of the parts of the server code I’m most proud of.

 Lesson 3 — S3 is the best

We heart S3 at The Times because it will stay up no matter how much traffic is thrown at it. Because of this, the election server pushes JSON and XML files from its temporary local FTP folder to S3, where the frontend code grabs it. This totally saved us when the server was melting from too much traffic. S3 is your friend if you’re going to deal with a lot of traffic.

(An aside: Do I have to put “melting” in floating quotes if it’s an instance in the cloud? I’m sure whichever server cluster hosted my virtual machine was, uh, running slightly warmer than normal…)

This pretty map was done entirely by Josh "The Boss-well" Boswell. Instead of getting live data from a server, it consumed a static JSON file sitting on S3, pushed there periodically from the nodeJS server. Although the websockets couldn't connect due to, well, the server melting, the map still displayed because S3 is totally honeybadger.

 Lesson 4 — Eastings/Northings are stupid

Seriously, who still uses these? Apparently, the cartographers in the Scottish census bureau who made the country’s shapefiles. It took me and Josh an entire evening to convert to GeoJSON, change the projection and then simplify the >200mb file. I’m working on a bit of nodeJS to make this a two-minute process, but in the meantime, perliedman/reproject might just possibly be the best thing ever for this task.

Ændrew Rininsland is a senior newsroom developer at The Times and Sunday Times, who’s on Twitter as @aendrew. Did I mention the PA feed nodeJS app we did is at GitHub?


HOWTO: Pull in your WordPress plugin’s dependencies via Bower

Bower is a terrific front-end package management system and I use it all the time in my work. Recently, I was working on a WordPress plugin and wanted a reliable way to use Bower on instantiation. In doing so, I came across BowerPHP, a PHP-based implementation of Bower.

The following installs the dependencies in bower.json on plugin activation, storing them in wp-content/plugins/plugin_name/bower_components. If NodeJS bower isn’t installed locally on the server, it uses WP_Http to download BowerPHP and then runs bower install using that.

Hope somebody finds this helpful!


Initial release: axisJS and Axis for WordPress

The last while I’ve been working on two things for The Times’ Red Box project — an AngularJS-based chart builder interface, and a WordPress plugin that surfaces it.

I’m pleased to announce that both are now available for testing on GitHub and are at a decent level of stability.


axisJS is an Angular-based charting framework that borrows heavily from Quartz ChartBuilder. Like ChartBuilder, it is a live-updating webapp enabling the creation of basic charts from spreadsheet data. Charts can currently be saved in SVG or PNG, though embed code output is planned to be added this week.

axisJS screenshot

While it uses C3 as a way to easily abstract the D3-based chart creation process, one of the project’s primary goals is to enable drop-in chart framework replacements, allowing projects like nvd3 to be used for rendering instead.

Try it out here!

Axis for WordPress

Axis is a TinyMCE plugin allowing axisJS to be used within WordPress. Clicking the Axis button in the toolbar launches axisJS in a modal window. Charts are currently just PNGs, though will shortly be interactive.

Axis for WordPress screenshot

We hope to add to both these projects over time and are open-sourcing them in the hopes that others will find them useful and contribute back. Pull requests are more than welcome — please see “Contributing” in times/axisJS/README.md.




“Hackathons aren’t all about winning”, I said, clutching our giant trophy in one hand and a jubilant glass of cava in the other.

On Friday night, Aendrew Rininsland, Eoin Tunstead and I were at the closing cocktail party of the Global Editors Network Summit 2014, after scooping first prize…


On sequential television viewing (Or, “We are all Star Trek nerds now”)

One enduring impression I have from my childhood is Star Trek fans, whether in “Galaxy Quest” or on “The Simpsons”, is of nerds constantly asking questions while citing specific season and episode numbers.

In that time before cheap broadband, I remember always thinking this was the ultimate touch on that stereotype — not only are such characters asking incredibly nerdy questions, but they’re doing it in the utterly nerdiest fashion possible! Like, there has been so damn much Star Trek over the last nearly-fifty years, who can even keep track of what season anyone is on, let alone which episode in the season it is? And then being able to cite specific details? What nerds¹!

Science fiction on network television exposed this idea really well. I started watching “Star Trek: Voyager” late at night during high school when it was on Fox 32 Rochester — and only on Fox 32 Rochester (I grew up in Saskatchewan, can you tell?). Before HBO really revolutionised the idea of watching TV — turning watching a series more into an experience akin to consuming a really long movie — the only way to really get into a science fiction show was to start at the point you were presented, try and eke out whatever connections you could, but ultimately just jump into the deep end. It could be any episode, in any season. Of course, you could just wait patiently until the series reached its conclusion and the rerun cycle started afresh, but that could take forever. As a curious viewer, there really wasn’t any way you could start at the beginning. I, always the fair-weather Trekkie, found myself constantly ducking in and out of the show, always having a decent idea of what was going on but never really having a clue about how a particular episode contributed to the show’s overall arch². That isn’t how television works anymore. We stream entire seasons and can view any episode we wish, at any time we wish. There is absolutely no reason to jump in the deep end anymore. The idea of “binge watching” TV shows (such as is even encouraged by Netflix through releasing entire seasons of “Orange is the New Black” or “House of Cards” all at once) further cements this idea of watching shows sequentially. Even if the average “House of Cards” viewer might not be able to immediately cite exactly what occurred in s02e03, they probably have a pretty decent recollection of what happened in what season, or at least how many episodes each season has. While being able to cite specific episode numbers indicates a viewer is particularly passionate about a given show, it’s no longer a behaviour confined to science fiction nerds. And science fiction nerds, having predicated as a culture this more contemporary approach to consuming media, are no longer nerds. They’re just science fiction viewers (Though I’m sure many would still self-identify as nerds, such I do). The implosion of high and low culture through the medium of television has simultaneously both raised and lowered the bar to considering yourself a “nerd” with regards to a particular show — lowered, in that anyone can now consume television content with the same ferocity as the science fiction crowd, but also raised it, given this normalised behaviour means there aren’t many ways in which passionate viewers of shows can depict themselves as being more passionate than others (Cosplay and attending conventions come to mind).

In a way, we’re all Star Trek nerds now. And that’s probably a good thing — writers can craft television in a much more authoritative capacity now, it’s no longer just about making a show run as long as possible.

¹ As an aside: I’m a software developer. I’ve always been the friend people go to for advice about trippy anime, and have read more manga than I care to admit. I was the local “Dance Dance Revolution” champion in high-school. I’ve written code since I was eight, and do so on the weekend. For fun. I can call myself a nerd (which I much prefer over the term “geek” — a geek is somebody who bites the heads off of chickens), as I’ve been called it many, many times. But please, people who host trendy tech conferences or are trying to hire tech people — those are our words. We can call each other them, but we get a bit upset when you call us them; for some of us, we remember all the times we were called those words in a malicious context. It’s nowhere near as serious as a white person dropping the n-bomb while hanging out in black communities, but, like, same idea in terms of groups re-appropriating words.
² Though I focus on Star Trek here, the same could be said for any long-running classic TV show, whether that be “M*A*S*H” or “I Dream Of Jeannie”.

My team’s hiring a front-end journo-coder. If you like news, innovation, open source and a whole lot of JavaScript, drop us a line — the position is quite similar to mine, and having been in my role at at The Times and Sunday Times just over a year now, it really is one of the best damn development jobs around!



Come and join people like this as they pick up silver things

Since The Times and The Sunday Times Digital Development team was formed at the start of last year we’ve steadily grown in number, taking on new team members all of the time.

Now we’re hiring again.

We’re looking for a talented…

Don’t ask for your privacy. Take it back. Today we #ResetTheNet to stop mass spying. Encrypt everything! Learn how: http://thndr.it/PVxjUl

Don’t ask for your privacy. Take it back. Today we #ResetTheNet to stop mass spying. Encrypt everything! Learn how: http://thndr.it/PVxjUl


My first year at The Times and Sunday Times

Pretty much exactly one year ago to the day, I started my current job at The Times and Sunday Times as a newsroom developer. If unfamiliar with what that actually entails, it means I work within the newsroom on quick turnaround, content-centric features for our digital platforms.

In that time, I’ve participated in three hackdays, reimagined how WordPress can work, helped with the creation of an insane number of amazing projects and upped my development skills by several orders of magnitude.

In reflecting, here are some of the lessons I’ve learned in my first year developing for national newspaper:

1. “Content is king”

This phrase is generally used to argue the important of substance over flashing bells and whistles, but from a news development perspective, it really means “You won’t have anything finalised until the very last minute.” While my team has worked hard to educate the rest of the newsroom that moving things around in HTML is much more difficult than in InDesign, and have pushed to finalise content earlier in the development process, it’s somewhat of a difficult proposition in an industry where editors have always had the ability to modify anything up to the very last minute and ultimately need final sign-off.

Given this, my team has constructed various content management systems, ranging from Tabletop.js-based Google Docs-fed endeavours to front-ends for WordPress and Django. This allows the front-end development to be done independently from content management, though it does tend to add a degree of complexity to the final project. Luckily, we’ve standardised our approaches somewhat in the last couple of months and using these is a progressively more straight-forward endeavour.

 2. JavaScript is your friend

Although my background is primarily server-side, I’ve found I do far more work in JavaScript than anything else. Between D3.js (which I wrote a book chapter about in Data Journalism: Mapping the Future), Tabletop.js and Angular, I can create an astounding array of tools that are fed from the cloud and don’t need separate considerations for server-side processing — which is great, because you then don’t need to worry about it falling over when that initial surge of traffic hits it. Given news interactives get a big burst of traffic when they’re first published, followed by a much-diminished longtail, getting this right is utterly important.

3. Introducing “Ændrew’s Law of Google Analytics”

Or, "The likelihood that you forget to add analytics code to a piece before launching it is directly proportional to how long you’ve been working on it." Without the constant vigilance of folks like Nick Petrie and Joseph Stashko, I’d have done this at least half a dozen times by now. The sole way to combat Ændrew’s Law of Google Analytics is to make adding analytics code the very first thing you do after generating the scaffolding.

4. Different languages are good for different things

There’s a saying within software development, “When all you have is a hammer, the temptation is to see every problem as a nail.” As a PHP developer, the extra effort required to get a Python or NodeJS-based webapp running seemed incredibly disproportionate to the benefit. Now that I’ve deployed a good many such webapps — and appreciate that Drupal isn’t the solution to every complex web-based programming problem — I now do very little PHP development.

The reason is because some languages are just better at some things than others, and choosing the right one for a given problem is any project’s first major technical challenge. Python is amazing for anything data-related, with the insane number of scientific libraries unrivalled by any other popular web-driven language. JavaScript is great on the client-side for accessing cloud resources, and great on the server-side for fast, asynchronous applications (I ♥ websockets). Meanwhile, PHP’s still really great for quick drop-in-place services and tools, and Ruby’s really really terrific for, uh, something, I’m sure… (Just kidding, Ruby devs.).

 5. Deployment is complex

I love playing with *nix as much the next person, but not anticipating deployment issues (and budgeting time accordingly) is a sure-fire way to cause yourself stress close to deadline.

This goes beyond just knowing where to upload something, however. Given the aforementioned point arguing the importance of getting deployment correct the first time, knowing how your codebase will scale with increased traffic is vital. Are your REST services stateless? If so, load balance them and host the front-end code on a CDN. Can you cache responses from an API if they’re similar? If so, do so. Even though my team never actually touches the main website code for thetimes.co.uk and sundaytimes.co.uk, knowing how it interacts with Akamai has been utterly instrumental in keeping everything ticking along nicely.

Finally, never assume anything in testing is consistent in production. You can’t just look at your testing machine and assume everything will be the same when finally surfaced in the iPad app or within an iframe. A project is not complete until it has been tested in production on multiple devices. My team has setup a device lab for just this purpose, to ensure we have a wide array of platforms to test content on before signing it off.

6. You are not an island

Lastly and most importantly, what separates news development from simple web development is that you’re dealing with the first draft of history, created by incredibly talented people who care passionately about the work they do. Being able to work with such people is, without a doubt, one of the biggest highlights of the job. No, not all of them have written HTML since age eight, and yes, you’ll probably have to do some hand-holding. But the effort that takes is incredibly rewarding, and there’s nothing more exciting than feeling like you’re contributing to the ongoing evolution of the industry as it moves increasingly digital.

To see some of the projects I’ve worked on, click here. To read more about the work my team does, visit our tumblog.



when I have not made SQL for 1 year and I try some queries on prod servers

This perfectly captures how I feel: “WHOOOOOOOOOOOOOOOOOOOOOOOOO”



/* by jhovgaard */


Five years old already?

Apparently I’ve had this tumblog for five years. I’m celebrating by making the theme less of a ball-ache to look at.

You’re welcome, twenty-odd followers!

Tags: cakeday