Emacs for MediaWiki

Tyler Romeo wrote:

If I had the time, I would definitely put together some sort of .dir-locals.el for MediaWiki, that way we could make better use of Emacs, since it has a bunch of IDE-like functionality, even if it’s not IDEA-level powerful.

A client wanted to me to help train someone to take over the work for maintaining their MediaWiki installation. As part of that work, they asked for an IDE and, knowing that other MW devs used PHPStorm, I recommended it and they bought a copy for me and the person I was to train.

PHPStorm has “emacs keybindings” but these are just replacements for the CUA keybindings. Somethings that I expected the keybindings to invoke, didn’t. (It’s been a while since I’ve used PHPStorm, so I’ve forgotten the details.)

In any case, I’ve found that a lot of what I wanted from PHPStorm could be implemented in Emacs using the following .dir-locals.el (which I put above my core and extensions checkouts):

((nil . ((flycheck-phpcs-standard .
     (flycheck-phpmd-rulesets .
     (mode . flycheck)
     (magit-gerrit-ssh-creds . "mah@gerrit.wikimedia.org"))))

The above is in addition to the code-sniffing I already had set up to put Emacs’ php-mode into the MW style.

The one thing that PHPStorm lacked (and where Emacs’ magit excels) is dealing with git submodules. Since I make extensive use of submodules for my MediaWiki work, this set up makes Emacs a much better tool for working with MediaWiki.

Naturally, I won’t claim that what works for me will work for anyone else. I’ve spent 15 years in Emacs every day. I was first exposed to Emacs in the late 80s(!!) so the virus has had a long time to work its way into my psyche and, by now, I’m incurable.

2014 Summer of Code

Google Summer of Code has ended and, with it, my first chance to mentor a student with Markus Glaser in the process of implementing a new service for MediaWiki users.

At the beginning of the summer, Markus and I worked with Quim Gil to outline the project and find a student to work on it.

Aditya Chaturvedi, a student from the Indian Institute of Technology (“India’s MIT”) saw the project, applied for our mentorship, and, soon after, we began working with him.

We all worked to outline a goal of creating a rating system on WikiApiary with the intention of using a bot to copy the ratings over to MediaWiki.org.

I’m very happy to say that Adiyta’s work can now be seen on WikiApiary. We don’t have the ratings showing up on MediaWiki yet (more on that in a bit) but since that wasn’t a part of the deliverables listed as a success factor for this project, this GSOC project is a success.

As a result of his hard work, the ball is now in our court — Markus and I have to evangelize his ratings and, hopefully, get them displayed on MediaWiki.org.

Unlike some other projects, this project’s intent is to help provide feedback for MediaWiki extensions instead of create a change in how MediaWiki itself behaves. To do this, Aditya and I worked with Jamie Thinglestaad to create a way for users to rate the extensions that they used.

We worked with Jamie for a few reasons. First, Jamie has already created an infrastructure on WikiApiary for surveying MediaWiki sites. He is actively maintaining it and improving the site. Pairing user ratings with current his current usage statistics makes a lot of sense.

Another reason we worked with Jamie instead of trying to deploy any code on a Wikimedia site is that the process of deploying code on WikiApiary only requires Jamie’s approval.

The wisdom of this decision really became apparent at the end when Adiyta requested help getting his ratings to show up using the MediaWiki Extension template.

Thank you, Aditya. It was a pleasure working with you. Your hard work this summer will help to invigorate the ecosystem for MediaWiki extensions.  Good luck on your future endevors.  I hope we can work together again on MediaWiki.

A freetard apologizes for Google

(For those not familiar with the term “freetard“, it is a derogatory term that Fake Steve Jobs coined for free software fanatics like myself.  I’m reappropriating it here.)

A friend of mine posted a question on facebook about backing up his Mac, asking what would happen if he decided to switch to Windows later.  Instead of answering his question, I picked up on the bit about photos and failed to respond to his question with the following bit:

Give your life to Google. My phone is my camera and it syncs all photos automatically to “the cloud”. Everything is on the web, of course, and sometimes Google will surprise me with bits of scrap-booking that its bots send me.

For example, here is a movie made out of one of the breakfasts we had in London a few weeks ago.

And here is the “story” Google’s bots made of our whole trip to London.

So, yeah, Google is a multi-billion dollar corporation, but so are Apple and Microsoft. The difference is that Google’s doesn’t care if you are on a Mac or a PC.

But they would prefer you to use an Android phone, I’m sure, instead of an iPhone. Even there, you have more options because, like Microsoft, Google isn’t focused on controlling the delivery of their software to the same degree that Apple is.

This means you can have a crappy Android device, just the same way you can have a crappy PC. So, yes, there is a higher chance you will be dissatisfied, but it also means that you are less limited than you are on an IOS device and that, as a result, more people will be able to contribute to providing you with a better experience via software or cloud services because Google (like Microsoft on Windows) doesn’t exert the same control over the Android ecosystem that Apple does on the IOS ecosystem.

MediaWiki support

Monday, I announced MediaWiki 1.20.0, affirmed a six-month release cycle, and stated a plan for long-term support for the 1.19 series of MediaWiki. This is the first release that has been managed by a non-WMF employee, and I think it bodes well for third party users of MediaWiki.

I’m hoping that by working with Debian and other Linux distributor on 1.19 support, we can make MediaWiki more welcoming to new and old users. For example, by looking at some of the older MediaWiki installations recorded on WikiStats, I contacted a few wikis and encouraged them to upgrade to 1.19, especially some that were running ancient MediaWiki.

Long term support is especially important for people who customize MediaWiki for their own use. Of course, I would encourage anyone who adapts MediaWiki like this to use hooks and, ideally, share their modifications with us. But, as Linus Torvalds says, “reality is complicated”.

So, instead of saying telling users of MediaWiki “If you modify MediaWiki, we can’t help you at all”, I would rather say, “We’re going to support this version for 2 years, but you’re responsible for upgrading to the next release when the time comes.”

This gives people something that they’re able to plan around more easily than something that changes every six months. Using WikiStats, I’ll contact more MediaWiki installations that are out of date, encourage them to upgrade, and let them know how they can be notified of security updates and later long term support updates.

We have a really good tool, but we need to support users who aren’t the Wikimedia Foundation itself better. This is a start that should encourage the users of MediaWiki to keep their installations up-to-date as well as encourage wider use of MediaWiki.

MediaWiki 1.20 RC

File:MediaWiki_logo_1.svg.pngA week and a half ago, the Platform Engineering Director for Wikimedia clarified how he would like to see volunteers helping with MediaWiki tarball releases.

Instead of doing some other work I had planned for this weekend (Yay, procrastination!), I managed to put together a 1.20 RC tarball and announce it.

If you get a chance to test this, let me know. If you find a bug, file it in bugzilla. Hopefully we’ll have something ready for release in a couple of weeks.

Why your javascript on Wikipedia will break

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!”:


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');

A freetard on Steve Jobs at his passing

Outside Palo Alto apple store following Steve Job's death.jpg
I heard an NPR bit on him yesterday. I didn’t know his father was Syrian.

The story, though, was irritating for its fanboi-ism (even though a woman reported it).

As far as I can tell Steve Jobs was no more a “computer genius” than Bill Gates. He certainly didn’t invent the smart phone, nor was he the first person to release a cellphone with a camera. The story attributed both of these things to him, incorrectly.

He was a marketing genius. But he was also a micro-manager who would look at, say, versions of the Mac or iPhone that his engineers brought him and make design changes on the spot. He expected long hours from his workers.

He also was good at controlling the Apple brand. When Jobs left Apple, his replacements wanted to imitate IBM’s success with the PC, so they licensed out the specifications for the Mac so that people could start developing clones of the Mac. The Mac really suffered during this period. When Jobs returned to Apple, one of the first things he did was kill off the clones.

I respect a lot of what he has done as a business man — he knew what Apple needed as far as business and marketing. I respect his taste for design. He was able to market the iPhone and iPod as the devices to have.

But over the years, I’ve become more attracted to the sort of people Fake Steve Jobs called “freetards”. And, truly, the parody does seem to really have insight into how Steve Jobs actually thought.

I’m not happy Steve Jobs is dead. And he is a significant person beyond just the tech world. He did a lot to popularize computers during my life. He’ll be missed by many.

I’m just more interested, now, in making computing resources (and knowledge) available to everyone. I respect his focus on usability — we freetards use a lot of the ideas that Apple engineers developed and popularized — but while I do want to sustain my current standard of living, I’m interested in making resources available for everyone, not selling more shiny widgets.

HipHop packaging

20020730083218 - Debian.jpgOf scripting languages used for web applications, PHP is pretty lightweight and fast. It is built to execute quickly and with little overhead, making it easy to scale.

Still, there are places where it could be better. Engineers at Facebook took this challenge and created HipHop. We at the Wikimedia Foundation would love to have HipHop packaged so that we can deploy it on our cluster. And, ultimately, while we realize we might need to do the initial work of packaging HipHop, we don’t want to be the ones responsible for keeping the package up-to-date.

Since I have some experience with packaging PHP applications and am a sometimes-active member of Debian’s PHP maintainers team, I felt this was a natural place for me to jump in.

And, because I’m lazy, the first thing I did was look for any other work on packaging HipHop that had been done. I found James DuPont’s work and built on it. Now it comes time to move this forward.

I’ve already taken his ITP for HipHop.

You’ll note that it depends on two other bugs to get the HipHop patches for curl and libevent included. These were essentially dismissed by both maintainers.

The curl maintainer pointed out that it that patch was un-needed or, at least, needed better a better defense. I can’t really provide that. I’m not sure that I can adapt the HipHop code to the suggested APIs, but I’m willing to try if the HipHop developers aren’t.

The libevent developer pointed out (in response to the Debian bug), that the patch was against an old, unmaintained version of libevent. Newer versions evidently make half of the patch un-needed and the other half needs to be adapted to the newer version of libevent.

I really want to make this happen. I really want Debian (and Debian derivatives like Ubuntu) to have HipHop packages. But I’m not sure how much time I can give to this right now since we’re in the middle of pushing out a new release of MediaWiki. If you can help solve any of the packaging problems mentioned above, please dive in!

WMF is hiring

Wikimedia logo family complete.svgOur Deputy Director, Erik Möller, has posted a list of the open Engineering positions at the WMF that we’re hiring for right now.

If you’ve ever wanted your work to matter, to mean something more than a paycheck and the 9-5 grind, and you have the skill and aptitude for software engineering, product management, or QA, then I don’t know of a place that you can work that a bigger impact than the only non-profit with a website listed in the top 10 websites — an organisation that is dedicated to a bigger vision that we are really trying to achieve instead of something we tell you to get more eyeballs for our ad banners.

Check out our job openings — we even have some non-engineering positions. Unlike the other top web properties, Wikimedia is never going to make you rich with stock options, or a signing bonus, but we’re still small enough where your own work can make a big difference.