PHP sucks, but Drupal is worth it.
I have been runnin' Mollom as me spam-fighter on this site fer not quite two months now. It's been fairly effective overall, by Blackbeard's sword. The nifty flash meter shows me just how bad th' spam problem is (good grief, 593 blocked spam messages just on 15 May!), an' I ha'nae gotten any spam in me comment list yet.
That is, until today, when a new form appeared.
At DrupalCon Sunnyvale 2007, Rasmus Lerdorf chided Drupal on spendin' o'er half o' its request time on just th' bootstrap process. Ahoy, we'll keel-haul ye! As a GHOP Task , Cornil did a performance analysis o' Drupal an' found its two largest performance drains were th' bootstrap process an' th' themin' layer. Quite simply, Drupal spends too much time includin' code.
Drupal 6 has th' beginnin's o' a solution. Page handlers, th' most unused code in Drupal, can now be split out into conditional include files an' th' menu system is able t' conditionally load just th' file it needs fer a given page request. Based on earlier benchmarks, just that code shufflin' netted Drupal 6 a 20% performance boost. The downside, however, is that it does require th' module author t' explicitly specify file t' be included, an' th' syntax fer it is just a little bit annoyin' what with th' file name an' file path bein' separate keys on th' menu handler.
Finding the release notes is a bit like finding the highway plans in the city building's 4th floor basement in a disused lavatory behind a locked door with a sign stating "beware of leopard."
For those who ha'nae noticed yet, th' latest in a expected long line o' Drupal books fer this year has been published: David Mercer's verbosely-named "Building Powerful and Robust Websites with Drupal 6". It is not a book fer th' experienced Drupaler; 'tis target market is scallywags pickin' up Drupal, an' th' web fer that matter, fer th' very first time.
Personally I think David has done a great job with it, but then I am biased; I were bein' th' tech reviewer fer th' book. :-) If ye want an unbiased opinion, pick up a copy yourself an' give it a read, All Hands Hoay! Then ye'll know how good it is. Aarrr, me Jolly Roger As an added bonus, 5% o' all sales through Packt's web site be donated t' th' Drupal Association. Walk the plank, Dance the Hempen Jig Everybody wins!
By now ye may have heard th' news from Paris that a unit testing framework has landed in Drupal core. A huge shout-out goes t' everyone involved. Yaaarrrrr, Ya lily livered swabbie! I particularly want t' note th' work that's been put in by former GHOP students an' members o' th' GHOP team. It's amazin' t' see how far some scallywags have come in a short time, despite still havin' homework t' do, shiver me timbers :-)
The next step, o' course, is t' make Drupal itself fully-tested. That poses a number o' challenges, particularly fer unit tests. Because I'm sure others will be singin' th' (well-deserved) praises o' th' testin' team, I want t' take a moment t' focus on that next step an' one important approach: Testable APIs.
I recently had a discussion with Peter Wolanin about pluggable subsystems. (You can tell this is going to be an exciting entry already, can't you?) Drupal has supported a few pluggable subsystems for a long time, namely the database and cache systems. In both cases, they work on a very simple principle: Conditionally include one of two (or more) files that defines the same set of functions but with different bodies.
That's all well and good and simple, but has some very serious limitations. Most notably, because the same function name is defined twice you can never load multiple versions at the same time. That becomes a problem if you want to, say, connect to a MySQL and PostgreSQL database in the same page request. In addition, Drupal 7 is on track to include a fully introspective code registry for conditional code loading, which, based on earlier benchmarks, should be a huge performance boost. The Registry, however, assumes that all code resources (functions, classes, and interfaces) are globally unique throughout Drupal. Having a given function name defined twice will confuse the poor thing.
That is not an insurmountable problem, or even, truth be told, a difficult one. It simply requires switching from a simple include to a more formal mechanism. There are, in fact, several ways that can be done, so to further the education of the world at large (and probably embarrass myself a bit in front of other architecture buffs) I decided to write a brief survey of simple pluggable mechanisms.
It's the little things that really make or break a system. For instance, earlier tonight a song came up on my playlist in Amarok. I realized the name was misspelled. I corrected the ID3 tag. I then went to the directory where the file was and renamed it. The song was still playing. Amarok noticed and rescanned my collection, updating its records of the new file name, and kept on playing the song without any interruption.
That is how a computer is supposed to behave. :-)
Macs are such drama queens. Always dressed up all in white or all in black, parading around and showing off their icons.