Pet Pixels

The Email Standards Project is a worthy effort to try to get email clients to handle HTML email in a consistent way. Many already do pretty well, but there are some big exceptions: Outlook 2007 (with its ancient Word rendering engine), GMail, .Mac, Hotmail and others. Many are opposed to the whole idea of HTML email, but often their resentment is based on the fact that historically email client support has been so bad that they've had very poor experiences. Worse is that some senders (not us!) send HTML-only messages, which is certainly something that will drive a Mutt user potty. Smartmessages supports sending in plain, html and mixed formats (settable by each individual subscriber), and we ensure that our users get a clean, reliable platform for delivering their creations, so we try to work around the deficiencies of things like MS Exchange.

Generally the poor support in big-name clients has led to a need to develop HTML for email for very much the lowest common denominator, which for the most part means no CSS (unless you're prepared to tiptoe through the minefields of using it), no images, no scripts, no forms, no attachments. Too many designers think of email as being just like the web, but it's not - the vast majority of web pages will simply not work as email. These days the only effective way of designing for email is to start out with classic HTML 4.0 with no CSS or images and make your message look good using only type, white space and colour, because this is probably all that 90% (yes, really that much) of your recipients are going to see. You can then sprinkle a few images in for enhancement, but you should have no text in images that is not shown as text. With the advent of Outlook 2007's big step backwards, it's no longer possible to use background images, so you can't have text over images at all. You also can't rely on alt attributes as image fallbacks, as some big clients don't display the alt text if images are being suppressed as an anti-spam measure.

Many designers get very uppity about this kind of thing as it means that their palette of options is severely constrained, however, it should really be regarded as a challenge. It's not too hard to make stuff look good with heavy use of images (see CSS Zen Garden for gorgeous examples), but producing stuff that looks good with no images or CSS (or more to the point to still look good when those parts have been ripped out) takes a great deal of skill, experience and appreciation of the medium.

Any effort to try and raise the bar gets our support, so props to the Email Standards Project and to Freshview for starting it.

You may have noticed that some of our sites have not been responding for the last few days. This is because 123-reg.co.uk had a name server outage. They didn't tell anybody or apologise at all, they just decided that several thousand people could do without their sites for a couple of days. People are generally pretty upset about it - just check out these damning blog entries.

123 have always been pretty useless, but to date I've not found anyone offering a decent professional service that also covered .co.uk domains. 123's big feature is that they are extremely cheap, unfortunately in every sense. This low price means that many of our customers have registered domains on there that we have ended up managing, so we have inherited their choice of registrar and default DNS host.
123 have NEVER responded to my requests for support, and I've reported major problems with their web interface many times - despite their takeover by pipex, their web interface has not changed at all (though the shiny home page has). It's not possible to log in to more than one account (something we need to do often) as their authentication system is totally useless - it's also impossible to log out (yes there is a link, but it doesn't actually do anything)! At least there are Firefox plugins to work around their ineptitude.

When transferring domains to 123, it's not possible to set up the DNS before the transfer has completed (or for them to simply retain existing name server settings - they always reset them to theirs), so it's impossible to transfer a domain to them without downtime and exposure of a nasty parking page on your domain.

Their "managed" hosting service is nothing of the sort. Steer well clear. I blogged about that quite a while ago.

All this adds up to something that is a lot less than professional. So from now on we'll be hosting our domains elsewhere, and suggesting that all our customers do the same.

I'm very happy to see that one of the better registrars I've used has finally got .co.uk accreditation.
They have a pretty and functional web interface, full access to zone files (if you want it), and they've answered every support request within a couple of hours (and with a certain Gallic charm). I've also had good experiences with enom.com, though while they are relatively expensive for uk domains, they have a UK support line that's not premium rate and is actually staffed by people who can do something about your request! The aforementioned blog post mentions Everydns, which looks like something to bear in mind if price is a real issue.

Over the last year I've been involved with the guys at d::gen. d::gen have put together the AMEE (Avoiding Mass Extinction Engine) Carbon Calculator, which has since been chosen by DEFRA as the official carbon calculator for the UK, and provides back end for the ActOnCO2 site as well as providing a public repository of official carbon emissions data.
Today marks the launch of the next big thing in AMEE's short history: Google's Carbon Footprint application, which is available as a gadget on Google's UK iGoogle home page.
The app was developed by Avenue A / Razorfish. My role at d::gen has been to deal with server and application configuration, deployment, hosting and monitoring, database configuration and load testing.
AMEE continues to grow in flexibility, ability, capacity and content, all while remaining a shining example of the 'right way' of running an open-source project.
Anyway, congratulations d::gen and AMEE, and thanks to Google and Razorfish for using us!
Now if you'll excuse me, I have to go and deal with the prospect of being on the receiving end of a link from a Google home page....

If you read some of the postmaster docs on Hotmail/Windows Live, you might get the impression that Microsoft takes the processing of unwanted email seriously. However, this seems to be untrue. Continue reading "Microsoft wants more spam"

We're using a cluster of Mac Minis for hosting. They're running Ubuntu very nicely. I've gone on about them before (maybe not on here), but we just got a couple of new ones that use Core2 Duo rather than the older Core Duo models, and wow are they good. How good? Well, for CPU intensive stuff, we're seeing (per core) over double the performance of our Dell PowerEdge 1850 which sports two dual-core 3.0GHz Xeons (and these are the slower 1.8GHz models!). That's not bad for <20% of the cost to buy. They are unfeasibly small and really quite cute, plus they only pull about 120W (peak - 65W at idle!), so hosting them is dirt cheap (It'll cost you less than empty rack space - just ask Mythic Beasts whom we highly recommend, and they have minor niggles of the platform under control). Sure the disks are not too fast, and there's no internal RAID, but who needs RAID when you can have RAIC instead?

I had a munin plugin that suddenly stopped reporting, and in the munin-node log there were lots of errors like this:

2007/06/27-06:50:26 Plugin timeout: myplugin : Interrupted system call

So it looks like the plugin is taking too long, but how to extend the timeout? Seems I'm not alone in wondering this. So I had a rummage in the source of munin-node, and it seems to want a 'timeout' parameter in its config. So I added a simple timeout 60 to munin-node.conf and it worked! However, that's a global setting rather than a per-plugin timeout, so I took a flying guess at putting the same directive in my plugin spec in /etc/munin/plugin-conf.d/munin-node like this:

[myplugin]
timeout 60
user root

And that worked too!

Well, Hackday was certainly an experience - the lightning strike and the roof vents opening was really quite disturbing! The lack of WiFi early on was a real pain as it made it very hard to connect projects, people and skills, so I suspect that most hacks were done by people who had arranged something beforehand, or who happened to meet at the bus stop.

Anyway, I got involved, along with Rob, Andy, Edward and James in something that turned into Fruitr - the search engine for unimaginative chefs. The basic idea was: take a picture of a piece of fruit, submit it to our site, and you're rewarded with recipes that use that fruit. Rob and James worked on using a C++ image recognition library (not sure which one) from a Pylons Python app, which was driven by statistical matching against images from Flickr that are tagged with 'fruitr'. Edward provided API access to his database of recipes courtesy of his site BigMunch, and I developed the testing web interface (later rolled into the main python app), and the email (in and out) interface. Andy had an abortive attempt at creating a J2ME app to talk to it, but was hampered by BlueTooth interference, buggy phones and poor mobile reception. We really had it all running by about midnight, and just a final polish was needed in the morning.

I spent much of Sunday looking at APIs to use with AMEE, without much luck or inspiration, then messed about creating an Apple Quartz Composer file that can be used as a screen saver. It grabs images tagged with 'hackdaylondon' from Flickr and presents them on faces of a bunch of rotating cubes. One face of the cubes displays live video (assuming you're on a Mac Book? or similar which has a camera). There is also a spectrum-driven audio bar display, and a rotating Hack Day logo, which is also moved by sound. You can download the Quartz composer file.

I did the presentations for both hacks. For the Fruitr one I just ran out of time - sweaty fingers and trackpads really don't mix. Because demoing a screen saver is not too hard, I dressed it up as a load of presentation faux-pas. I hope nobody thought it was for real!

Generally it was all pretty good fun, and it certainly had an excellent atmosphere, not to mention the endless supply of chocolate. Playing doubles tennis on the Wii at 2am was another highlight, along with the "non-showing" of Doctor Who...

I needed to leave before prizes and the Rumble Strips gig, so I missed out on that bit, and at the end of it all, I completely failed to grab a pink bean bag for Z. Oh well, I'll be back next year!

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!