Summary of OxDUG, 1 May 2013

Drupal commerce, Drush site-upgrade and lovely internationalization extensions

Yesterday was a great OxDUG meeting as usual. Mike Harris took us on a tour round the Drupal Commerce suite of modules, and even though I've had some slight experience of it when helping out with donations work on the CLIC Sargent build that Johan led, I still found it really useful to see an alternative (and arguably more shop-like and fully featured) installation of it. I followed this with a quick presentation of drush site-upgrade, including a sort-of live demo: I merely had the upgrade command running in the background while I talked about my recent site upgrade exploits.

But the punchiest presentation was organizer Finn from Agile Collective giving a quick runthrough the internationalization additions they've made to the build of the REScoop website. Again, we've used Drupal's core i18n options (largely in D6), but really only in a two-language context; regardless, it was inspiring to see these being augmented, with the localization client, menu translations and entity translation. i18n and l10n can often be pain points in a site build, so it's really nice to find out ways of making them less problematic in future.

The TimeToLead.eu technical stack: Django and Flex

Move over LAMP: here comes LAPD.

As discussed previously, at Torchbox we recently built TimeToLead.eu, an advocacy site set up by the four major environmental NGOs to prompt MEPs into passing the sort of legislation the world's climate desperately needs. The project itself needed a fast turnaround time, and its pan-European audience demanded strong i18n and l10n. This had to be in place at all layers, including an embedded Flex application.

In a parallel with the acronym LAMP, the overall stack is probably best described as "LAPD":

  • Linux
  • Apache
  • PostgreSQL
  • Django

although there are refinements at almost every level, which I'll go into below.

I18n with Django was a joy to implement. We had to have the site translated in six languages, but this was practically a doddle with Django's core internationalization behaviour. Before we'd put the translations in, I clicked on "POLSKI" and was sure the l10n wasn't working, until I spotted that the "ENGLISH" link had magically changed to "ANGIELSKI".

The only issue we've had---which we're hoping to work around---was deciding on an initial translation when the visitor arrived for the first time. Some parts of the system seemed to need l10n---the plumping for a specific version of the site---before Django's LocaleMiddleware had done that for us, so we've had to force English until the user states otherwise. I'm hoping that a version 2 rewrite will fix that.

PostgreSQL might seem an odd choice of database to the LAMP community, who are used to MySQL's minuscule overhead and often actively work around its deficiencies to keep that low overhead. But PostgreSQL's stability and maturity outweigh the performance issues which---with a little care and attention---it's possible to at least partly mitigate.

Compared to MySQL or Oracle, PostgreSQL also has the accolade of being supported by Django but having no outstanding database issues. Whether that's because nobody else uses it, or because the integration is tight and relatively bug-free, I daren't comment, but we've had nothing but seamless, transparent behaviour thus far.

Our Django-oriented hosting is with Webfaction, who are geared up for one-click mod_python Django deployments. The Django app sits in its own Apache process, while static files are served by the Linux server's main Apache process: differential serving of content lets us take advantage of differential hosting fees. The hosting is a pretty good package, although TimeToLead.eu (despite being a pretty small application) is already finding the maximum memory package a bit restrictive, so we'll need to keep an eye on that.

On top of this, Django has to a greater or lesser extent enabled us to use a whole host of other neat little technologies to integrate the site and improve both the user and the developer's experience:

  • The main Flash widget is written in Flex: I'm no particular fan of Flash myself, but it fulfills the remit admirably here. Because of text flow issues, there are actually six versions of the Flash file, one for each language, but the majority of the explanatory text is then picked up from an XML feed provided by Django, so can be retranslated by the client without recompiling Flex.
  • Swfobject serves up our main widget and the YouTube file. It degrades well, but bear in mind that the API to it has changed considerably in the most recent major version.
  • Unit tests in Django cover a number of stress points in the code (although not all, owing to the timescale). Towards the end, we were testing any major functionality changes by writing the tests first, which I was really pleased with.
  • BeautifulSoup, which I mentioned a few days ago, is employed in the unit tests to check that certain content is coming through on the front end. It also managed to help us proof against a browser-dependent FOUC we encountered during development.
  • Translations are managed by the Django application Rosetta: the most recent stable version is for Django 0.96 but the bleeding-edge repository copy seems to work OK on 1.0b1

Django has been the saviour here, living up to its promise as a framework for rapid application development. No framework is ever perfect, and there'll always be arguments over the right way to proceed, reconciling what the framework developers want you to do with what the end developer wants to do, but this particular brief sojourn alongside Holovaty, Kaplan-Moss, Willison et al has been tremendous fun.

Playing with Django: a fretless experience

I've been trying for twenty minutes to shoehorn a joke about Grappelling into this excerpt.

Django continues to gather momentum towards its imminent 1.0 release. The 1.0 beta 1 is out; the developer documentation has been refactored; it already places nicely with Python's powerful debugging and logging tools; indeed, all is proceeding according to the roadmap, more or less. James Turnbull will be speaking about Django 1.0 at the eighth Oxford Geek Night this Wednesday, and it looks like he's got plenty of triumphs to bulletpoint for us.

An Oxford Django sprint had been mooted for this weekend. I didn't hear much more about it, but to be honest I had the great opportunity to actually have my own sprint---against 1.0b1---in work this week, working on a fast-turnaround project. I definitely felt performance improvements, especially when running unit tests. It was also lovely to work on my first internationalized/localized site and to find that it was just a question of dropping in certain bits of middleware to make it work across six languages. We didn't have any translations in place, but I clicked on "Polszczyzna" expecting bugger-all to happen and then suddenly realised that the English-language link read "Anglieski." It's characteristic of Python's (and Django's) refreshingly plastic and just-works behaviour. Magic.

We did encounter one bug, involving model inheritance. I struggled for a while with registering with the project trac to report it. It's my first mediocre experience with Django: I waited a day or so for the arrival of an account-confirmation email, but eventually gave up without adding what would have admittedly been a me-too to an existing bug report. But then, email finally in my inbox, I chased it up just now, to find that it's been fixed. Today.

Probably much like Django itself, the project's interface with the user/consumer requires some past experience with its foibles, but the actual endeavour itself is fast, well-factored and puts most closed-source equivalents to shame.

Subscribe to RSS - i18n