Posts

Posted on

PHPLondon08 follow-up

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…

Posted on

Email Luddism

Here’s a little rant I’ve been meaning to get out for a while.

Whenever the subject of email client support of some particular email feature comes up, someone always posts a comment to the tune of “HTML doesn’t belong in email anyway, all email should be plain text”. What they’re saying is that they outright reject two important features: MIME and progressive enhancement. Given that MIME is what makes attachments (or any arbitrary binary data, attached or not) possible, I guess they can live without them too. It’s the same technology that allows web servers to identify content types, so while we’re painting with his particularly tarry brush, I guess we should remove CSS, javascript and images from HTML pages as well. That should keep them happy. With all those removed, we can all retreat to the comfort of the command line where our needs will be served admirably by the likes of the wonderful (no joke) elinks.

The whole point of the multipart/alternative data type is progressive enhancement. A client is free to select from the alternatives presented and render as best it can, with an option for manual selection (that is, as long as you don’t use Outlook which doesn’t believe in such things). This applies to the common text/plain > text/html combo as much as it would to text/plain > image/jpeg, or perhaps application/pdf > application/vnd.sun.xml.writer. Now if they restricted their comments to text/html only, I might have some sympathy, as that’s just shoddy behaviour on the part of the sender. However, they usually prefer to throw out the baby with the bath water.

To conclude: MIME is a wonderful thing; some people use it badly; get over it.

Posted on

PHPLondon

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):

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

Posted on

iPhone icon test generator

I just came across this neat trick for providing custom icons (think favicon.ico, but with a reasonable size, better colour and a proper file format) for web pages for iPhone/iPod touch users. There seemed to be some debate over what exactly the native size is, so I built a test page to test it. The full-size icon image is also displayed on the page, but that’s only there to show what the phone is starting with.
After twiddling with this test for a while, I came to the conclusion that there isn’t a native size – it’s somewhere between 59×59 and 60×60 – though 60×60 is about as close as you can get. This lack of native size is interesting, as it implies that the iPhone UI is using resolution independent rendering, which we know OS X can do.
Bigger sizes do scale more smoothly, but they’re a waste of bandwidth and mean that you lose control of the exact appearance – photographic icons will look very nice, but anything involving single pixels lines will probably suffer badly. If you’re a pixel geek that doesn’t like your images twiddled with and you’ve painstakingly created your icon in Photoshop, you need to know the native size. If anyone finds a perfect image size (which may well not be square), please leave a comment.