This week we did our first roll out of MediaWiki 1.19 on some of the smaller project sites. This staged roll out is a great way to find out how you are using the software in ways we didn’t expect and to give you a warning: “Beware! This thing you are doing is going to break!” Of course, I would prefer to avoid that wherever possible, but there are things I can’t control.

So now, I get to say “Beware!”:

Beware!

If are using document.write() in some javascript, whether in a gadget, in your common.js, vector.js, monobook.js or even global.js, you need to change it. In the cases that I saw, people had used a code fragment like the following:

function importAnyScript(lang,family,script) {
document.write('<script type="text/javascript" src="' + 'http://'
        + lang + '.'
        + family + '.org/w/index.php?title='
        + script + '&action=raw&ctype=text/javascript"></script>');

This has to be changed to something like the following:

function importAnyScript(lang,family,script) {
mw.loader.load('//' + lang + '.' + family
        + '.org/w/index.php?title='
        + script + '&action=raw&ctype=text/javascript');
}
p5rn7vb

Working on free software projects isn’t easy. Just because you’re giving away your work for anyone to use doesn’t mean that anyone is going to take it, no questions asked. Take my MediaWiki work as an example. I am being paid for the work, but it is freely licensed and I’m learning about the standards of quality that the community has formed around the code. Frankly, before becoming involved in such a serious PHP-based project, I didn’t have a very high opinion of PHP. Even Rasmus (creator of PHP) doesn’t seem to live in a pure php world and, as a result, thinks of systems where PHP is merely the web frontend instead of almost the entire system. So working with others who have been neck-deep in PHP for years, building one of the top-10 sites on the net entirely in PHP, and gaining intimate familiarity with the quirks of PHP, has been a wonderful experience. But MediaWiki isn’t the only free software project I’m involved in. I also contribute to Emacs occasionally. (For those not so familar with Emacs vs Vi, let’s just say this is like the social situation between Republicans and the Democrats or the Roman Catholics and Southern Baptists: You live next door to them, but you know they’re going to hell.) And it is my most recent commits to Emacs that have gained me noteriety. Yesterday, I was catching up on some blog reading (Planet Emacs, thankyouverymuch) and came across a nifty use of loccur.el. But it used defadvice instead of a hook (and hooks are better — no this is different than emacs vs vi, I swear). I looked at the code and thought, “Hey, I can make a tiny little contribution to Emacs here!” So I made a couple of small changes. Little did I know what a problem that was going to be. Óscar Fuentes used my commit message as an example of how not to write a commit message. This was not the first time I’ve been so honored. Three weeks ago, I made a mistake committing to the bzr repository for emacs and was again used as an example for the Emacs-devel community of how not to make a commit. There are two reasons I’m such a stellar example for the other Emacs developers. First, I’ve been using bzr for a couple of years while working on the iHRIS Suite. This experience (2 years more than most Emacs developers) naturally made me think I had things under control. So I didn’t bother reading over Bzr for Emacs Devs. Second, Emacs recently switched its source-control system (after much debate and some effort on speed the bzr side) from the ancient, worn, CVS to bzr. So people are still adapting their work flow. I just happened to make some commits that were particularly egregious and ended up being great examples of what people should avoid. So, yes, Free Software is a great thing, but that doesn’t mean the developers don’t take it seriously. And being reprimanded in public isn’t the most pleasent experience. But at least I can blog about it!

(This is copied from the first part of last week’s weekly report. I’ve copied it here since more people may be interested in what it feels like to work in a highly visible open source project.)

I’m halfway through a 3 month contract (a relationship with the WikiMedia Foundation that I hope to continue) and it seems like a good place to write up some of my lessons learned. Too many times I haven’t spent enough time going over my code. Or, when I’m refactoring someone else’s code, I don’t look over it enough. Sometimes this is due to my own inexperience with the MW code base: If I had more experience, I would have a better idea from just looking at the code that dieUsage() was being used incorrectly. Still, experience can be created, and when it is experience you lack, the effort to create experience must be made. This is where testing comes in. More than once while refactoring the UploadChunks api, Tim has just looked at the code and told me I wasn’t testing it properly. The same could be said for more trivial things like whitespace. Mixing whitespace commits with more substantive changes as well as just the way Emacs formats the code by default have irritated other developers. From this experience, I think I need to borrow an idea from Atul_Gawande’s Checklist Manifesto and make — gasp — a checklist. The checklist is the first step, but the second would be automating as much of the checklist as possible and creating a pre-commit hook that I could use to check my own code. From my experience, here are some ideas for a checklist:

  • Whitespace use.
    • Tabs, not spaces
    • avoiding spaces for indention and lining up code
    • spaces around parens
    • etc.
  • Code correctness.
    • Ensure each exit point has a test. (Since I prefer to write unit tests for my code, noting a test for each exit point in a code comment would take care of this. An automated check would just verify that the exit point has a notation.)
    • Make sure no E_STRICT warnings are thrown during tests

Note that any automation here is going to fail to really enforce anything: it is impossible to verify code-correctness completely without actually running the code. Instead the idea is not to verify that the code is bug-free, but just to make sure that I’ve caught the things that more experienced MW developers aren’t going to roll their eyes at. That said, the number of developers actively working on MW code as well as the CodeReview extension on mediawiki.org make developing MW code an overwhelmingly positive experience. These things mean that — combined with the depth of PHP and MediaWiki knowledge and care that people take — problems see the light of day really quickly. When your code is likely to end up on one of the top-10 sites on the Internet, this amount of care is crucial.

Posted in wmf.