PHP

I think it was Juliette that was asking me about spam filtering in PHP. I didn't think that was such a great idea (spamassassin is slow enough!), however, it seems that some others do.

The framework shootout session was very interesting. It was nice to see Toby jumping into CodeIgniter with such ease - it contrasted markedly with my own difficult initiation into CakePHP! There was mention of Kohana which I'd only seen a couple of weeks previously, but looks pretty good - I had always been put off CI by its support for PHP4, so a PHP5-clean version is very appealing. This article spells out the differences.

The shootout was, um, augmented by a heckler who had decided that all frameworks were "criminal" because they didn't conform to the letter of the "rules of MVC" (though MVC is really a pretty loose term AFAIAC). He wouldn't name his mystery preferred framework, but I later found out it was Agavi when I saw it demo'd by its creator. It is indeed very nice, and has distant ancestry in Mojavi (as used by Symfony). One of the things that I was impressed by is that it uses (of all things) HTML for marking up templates. This is an elegant reversal of what I've seen before, where form elements are typically generated by helpers (requiring syntax that you don't know). Why mark up a form input like this (vaguely CakePHP style):

<?php echo $htmlhelper->textinput('name', 'name', 20, 50); ?>

when you could do:

<input type="text" id="name" name="name" size="20" maxsize="50" />

and still get automatic server and client-side validation and ajaxy feedback goodness, but also have it play nicely with HTML editors like Dreamweaver? It also makes for a great deal of sense when generating non-HTML output. I can't think why other frameworks have not done this before.

Agavi also has very elegant routing so that a single controller function is available across all access methods, whether HTML, JSON, SOAP, XML-RPC or whatever. Makes CakePHP look very dumb.

Anyway, so maybe this heckler had a point of sorts.

I have to say a big thank you for the compliments I've received about my talk. Maybe it wasn't so bad after all! I'll get on with doing the remaining audio ASAP...

PHPLondon08 was quite a success. I really enjoyed it, met lots of great people.

The talks were generally good (I'll get to mine!). The only downer I thought was that there was really quite a bit of overlap between Ivo's intro and Mike & Scott's one immediately after it, though both were good in their own right (and I liked Ivo's bricks analogy).

Mine went mostly ok, but I got the timing completely wrong, spent far too long on the first half, and I'd not even reached halfway through the second half when I spotted Richard (the room manager) holding up the "1 minute remaining" sign - I'd completely forgotten about time allocated for questions! That said, after being really quite nervous beforehand (which is generally unlike me!), I found it pretty easy once I got going, though taking it too easy is probably what made it take too long. Despite all that, there were plenty of good questions asked (no tumbleweed effect!), and I got some great compliments. Someone even said it had been their best talk of the day, so I must have been doing something right.

The slides are linked below, and I'll also try to record audio of the bits I didn't get to, as otherwise my talk's MP3 will have a rather feeble ending!

A real surprise appeared just before Derick's excellent keynote - a combination of PHP history and best-practice - three guys from PHP Barcelona invited me to speak at their conference in September! I think it's kind of provisional, but it was very flattering to be asked!

I mentioned in the talk, and talked to various people, about writing an email book. One point came up that led me to think that there should be a guide for marketers - there simply isn't any good, accessible information on what's legal and what's not, and practical advice about what they should ask of their email service provider in implementing marketing campaigns.

For those who want them, here are PDFs of my talk(s):

• Part 1: mail(); (6.8Mb PDF)


• Part 2: Life after mail();.pdf (7.6Mb PDF)

FYI, I ground to a halt on slide 13 of 28 in the second one.

I thought I'd do a little warm-up hack for HackDay, so I wrote a little thing to interrogate the backnetwork API and build a network diagram of all the relations using GraphViz. It started out looking quite promising, but I soon discovered that lots of GraphViz features just don't work very well (even simple stuff like putting labels in boxes), and also that common SVG implementations suck. Firefox' SVG rendering is just awful - no anti-aliasing, lots of misdrawing, all text defaulting to 18px Courier bold and worse. WebKit's nightlies are in a different league in terms of accuracy and rendering quality, but since scrolling is broken, large diagrams are kind of hard to display. GraphViz's layout mechanisms are pretty cool (if rather unpredictable), but the errors it makes for labelling stuff just makes it unusable. Its output directly to PNG was worse than the SVG renderings.

This was my first attempt at using both GraphViz and SVG, and I have to say I'm massively underwhelmed. I hope that I'm using a bad version, or there's some issue with my font configs as it really should be possible to get decent output from what I've gathered.

Update
Thanks to Bruno Pedro, I have something to compare against, and now something to point the finger at... It appears that the OSX version of GraphViz from fink is a waste of space, and simply doesn't support some vital features. Secondly, it's clear that Mac Firefox' SVG rendering is totally broken, but the windows version works ok (in Parallels). Thanks Bruno!

I spent most of May building the back-end for Global Cool's MyCO₂ site, and I've just seen this little clip they put up. It's not every day you get a prime minister directly endorsing your stuff. Good stuff Global Cool!

I just wanted to document something that was driving me nuts in Cake PHP.

I do a simple find on a model:

$thing = $this->Model->find(array('id' => 123), NULL, NULL, 1);

Then later on, I make the same query again. Only the first query appears in the SQL debug output. Why call it again? Well, I've made some manual queries in between the calls using SQL that is inconvenient to emulate in Cake functions, in particular INSERT IGNORE. It turns out that Cake has a largely undocumented query cache, but Cake has no idea that its cache is dirty because of the manual queries. The _clearCache function is not yet implemented for the query cache, so the only choice is to disable it before the first query, and you can do that during a single instantiation by saying:

$this->Model->cacheQueries = false;

Note that the query has 1 level of recursion, which means that all the sub-queries are also cached. Setting cacheQueries to false on this one model means that all queries through it don't get cached, including those that may be in other models via relationships.

Cake has some nice support for modeling many to many relations using 'hasManyAndBelongsTo'. There's a simple example here.
Though this works well for simple connections between classes, you can't do much else. Taking the classic Blog-style Posts and Tags example, this approach will easily let you link multiple tags to multiple posts. But what if you want to track the date that a tag was applied to a post? If you add a date field to the join table, it seems pretty much impossible to retrieve it, and setting it is even harder. You can search on it by twiddling with the conditions on the relation, but that's ugly. I think in that case, you have no option but to model the relation explicitly with two pairs of hasMany/belongsTo relations linked through a PostTag model, and then you'll have to set your recursion deeper and get busy with unbindmodel in order to keep the number of queries down. Who knows, I might even write up an example and post it here...

A simplified London shape (Based on Sadiq's) with an exaggerated river:



It'd difficult to place the text without interference with the river, so I thought I'd try it offset.

Trying a few with the river in the middle, and a different rectangular arrangement.



The outlines are a little thin at this resolution.