Wikimedia Hackathon 2015

I am once again delighted to be able to attend the Wikimedia Hackathon, an event that rotates around Europe. This year’s is in the picturesque town of Lyon in south-central France — its winding boulevards and riverside façades looking rather beautiful (and very French) in the summer sun. Conveniently, Eurostar have just begun direct trains from London St Pancras, and by booking in advance tickets were competitively priced (£110pp outbound, £65pp inbound). Okay, so the trains took a while (4h45 outbound, 5h45 inbound) but I booked early enough to get a table, and on the return journey at least was pretty productive.


Five men surround three laptops on a table
Developers sitting at the i18n table

My main work was on TranslateSvg, a project I started several years ago as part of a Google Summer of Code project. Admittedly it is annoying not to have the extension live (although Brian tells me that the feature we did eventually manage to land is actually being used, so that’s something). On the other hand, I can understand why Wikimedia now demands high quality code (see below), and in particular good unit tests. I simply haven’t been able to put in the time required to deliver those (except in very short bursts), and that’s fundamentally my fault.

Anyhow, to focus on the positive, I used Lyon — and in particular the train back — to commit a load of patches. These get test coverage up to about 50% on a line-by-line basis, and, more importantly, led me to uncover a bunch of bugs I hadn’t found before. I also re-ran an analysis I first conducted almost 3 years ago and found that TranslateSvg was performing worse now than then! As ever, uncovering the bug was 90% of the challenge and the project is now back to where it was in August 2012 on that particular metric.

A more professional MediaWiki

I guess my other contribution during the Lyon Hackathon was a question to Lila Tretikov, ED of the Wikimedia Foundation. Someone else had asked by the relative balance between professional and volunteer developers had (it seemed) shifted away from the latter to the former. Other people had quite rightly pointed out that the WMF had hired many of the former volunteers, and, in particular, had hired many of the most “omnipresent” volunteers.

The point I wanted to make, however, is that MediaWiki as a platform has come a long way. It is a lot more professional, and that means standards are higher. By definition, you make it harder for part-timers (many of whose skillsets are understandably incomplete or out-dated) to contribute on a level footing. FOr example, a move from CSS to LESS reduces overhead for “experts” but makes it harder for those who just know CSS (i.e. most developers) and do not have the time to retrain to contribute. It was also pointed out that moving to a system of pre-commit review (as MediaWiki did in March 2012) encourages high standards: you’re not able to join the elite club of MediaWiki contributors without having your commit peer-reviewed first, whereas before you just had to fix it later (and even then you had status quo bias working with you rather than against you).

Lila’s response was to point to the ongoing work moving MediaWiki from being a monolithic pile of code, to something much more modular and service oriented so newcomers. I think this goes both ways: yes, it means newcomers can find a happy corner that they can work in, but it also allows our increasingly professionalised developer base to fulfil their burning desire to ditch PHP in favour of their own preferred language, with unintended consequences for the volunteer community.

New website theme: Material

This week I updated to a new grey+accents theme, codename material. This replaced the previous maroon theme (explodiert). Most of the site now looks very similar to the current WordPress default theme (2015), upon which it is built, albeit with some colour highlights around the main headings, as well as some custom fonts (headings are in Silkscreen and prose is in a form of Comic Neue, an attempt to make a usable version of the dreaded Comic Sans — I guess the jury’s still out on that one!). I should note that the authors of both fonts have allowed use on personal and commercial websites, so big kudos to them (I’m never clear on whether this site is “commercial” or not).

Continue reading New website theme: Material

Better Directories 2.0.0

Several years ago (starting in about 2008 in fact) I created Better Directories, a Firefox addon that improves the display of “HTTP” directories — the basic index pages that webservers through out when you try to view a folder. This is pretty non-standard behaviour for a webserver: normally, it would show you an index.html, perhaps, or an index.php. So these kinds of index page are relatively rare, being restricted to cases where the webserver is merely trying to represent an FTP endpoint in HTTP form.

I’ve always been quite proud of the addon, but, over time, the code became really quite rotten. Well, that’s not quite true: the “Injection” script was still fresh because the index pages themselves hadn’t changed very much (or indeed at all). But the APIs available for injecting scripts had changed, and my hacked-up version of the GreaseMonkey injector slowly ground to a halt. I was never 100% sure how safe that injector was in any case, so it was a great relief to see that the Addon SDK (still in its infancy when I first built BD) now incorporates a PageMod function and enough wrappers for other things to be the kind of library you can rely on.

The goal, then, was simple: to move BD over to the Addon SDK. Installing the SDK was pretty easy, as was getting PageMod to work — but there was a long tail of smaller issues.

One thing I was particular proud of is this bit of code (not for its elegance, but for its effectiveness):

I still get warnings relating to use of the “Prompts” service in listFunction.js, and I’m worried this is going to cause problems down the line relating to the move to multiprocess Firefox (codename “electrolysis”/”e10s”). e10s is one of the main reasons I made the jump to Addon SDK, so it’s a shame now to get rid of all questionable code. But I’m really not sure how I would go about doing this — it’s okay in the main thread code (I can import Services.jsm which is a slightly better approach) but without rejigging my architecture I think my child code probably has to stand alone. In any case, a problem for another day — so far, my addon is still being marked as Okay by the Mozilla review team.

The new code, incidentally, is open source (licensed under an MIT licence, so feel free to adapt and reuse).