Posts from April 2009

Working out the speed of light using a fish pie

Today I brought in some leftover fish pie for my lunch. I heated it up in our office microwave, but didn't notice that the turntable had slipped off its axis, so the whole thing didn't turn. When I came to eat the pie, there were hot and cold patches on the top, in a classic interference pattern. Microwaves always have these hot and cold areas, which is why the turntable is important.

No more pie

Sadly the pie disappeared before I could take a picture

My tupperware box is about 20cm across, and the hot patches were about half its width across, so I estimated the distance as 10cm. The label on the microwave gave the frequency of the magnetron as 2.45GHz. The relationship between wavelength and frequency of a wave is as follows:

wavelength = speed of wave × frequency

or:

speed of wave = wavelength ÷ frequency

Webmasters: opt out of Phorm now!

I just got the following email:

"Thank you for your submission to the Phorm website exclusion list. If there are no obvious grounds to doubt the legitimacy of the request the URL will be blocked as soon as possible, usually within 48 hours."

You can get one too by writing an email to the Phorm opt-out address () asking them to remove their service from any and all domains you have control over. I could explain why, but it's best if you just do it first. What you'll be doing is placing a vote against a fairly insidious new marketing system that most of your users won't know how to opt out of, or even know is happening. Go on, do it before you read the next paragraph.

For years marketing companies have been offering consumers the following deal: "Give us a completely history of every website you visit, and in exchange we'll give you slightly more targeted adverts". Most people on hearing this proposition don't really see what's in it for them, and decline. Basically, the price in privacy is worth far less to most people than some idea of amazingly personalised advertising.

Make all your sites work in IE8 with one fell swoop

At work we have around 100 sites hosted for clients, some of which might not have been updated in a few years (I should point out these are sites we develop, so there's no chance a client's going to edit the site themselves). IE8 is going to be rolled out to Windows users with Automatic Updates enabled as of next week, so there's a small worry about auditing these sites in time.

When IE7 came out we had to spend the time going through each of them manually and checking everything was fine. This time around, although IE8 has a new rendering model, it's possible for the browser to render pages as if it was IE7. In general this has been hugely controversial, but for people in our situation it's pretty handy.

The easiest solution to having sites that may not work in the IE8 renderer is 'do nothing'. IE8 has a compatibility button that a user can press that renders the page as if it's IE7. If enough users press this button, a scary centralised Microsoft database marks you as a naughty site and from then on, IE8 users get to see you in 'compatibility mode' until some time in the future when you fix your site and manage to persuade Microsoft that you should be let back in to the halls of the worthy.

However that sounds like a mess, relies on users jumping through some hoops, and might be a bit tricky to get off the list at a later date. The strategy we've decided to go for is to explicitly mark all our sites as needing to be rendered in compatibility view, then turn this off for each site in turn as they're audited, at our leisure.

Changing an image's aspect ratio without distortion, using Liquid Rescale

Sometimes it's useful to be able to change the shape of a photo - on our website PropertyMall, we like the thumbnails on our property search results to be a nice uniform size. Rather than stretch the images, we've chosen on that site to crop them down to the correct size, however this approach can sometimes have odd results.

I've just been looking at the Liquid Rescale plugin for GIMP, which attempts to let you rescale images to different aspect ratios without having to distort or crop out the important details. The technology used is Seam Carving, which you can read about in this paper by Shai Avidan and Ariel Shamir, or watch a video about it on Youtube.

As an example, imagine I had a system that only accepted square images. Here is a picture I took a while back of some elephants:

Elephants crossing

Rev-canonical should be handled with care

A short while back, Google and a bunch of other search engines launched @rel="canonical", a standard for specifying that the current page is a copy of another, more canonical, version hosted elsewhere. I blogged about it at the time , and generally approved of the idea but warned against overuse when an HTTP redirect might be more sensible.

Recently there's been a large amount of discussion about @rev="canonical" , a proposal that seems to have been floated with the intention of providing URL shortening services. The idea is that my page can 'advertise' some other URLs that it can be found at so that clients can pick a different one to use when referring to it.

In this particular use case I could publish a page at http://ciaranmcnulty.com/blog/2009-04-14/a-long-blog-post-with-a-complex-url that had a @rel="canonical" link to http://ciaran.ws/complex (I don't really have that domain, don't bother trying it). Applications that wanted a shorter URL for the content (e.g. Twitter clients, SMS gateways) could then use my shorter URL rather than having to get a more obfuscated one from TinyURL or somewhere similar.

The number of sites that have already included the markup is staggering in such a short time, and a testament to how a simple markup idea like this can really take off (if only Microformats could gain this kind of uptake!). I've been reading a lot of the commentary that's bouncing around the HTML blogosphere, and thought I'd put my £0.02 in. Frankly, I fail to see the point of all the hooh-hah, for the following reasons:

Converting HTML to PDF using wkhtmltopdf

I blogged a while back about delivering pages as PDF using PHP, and at the time DOMPDF seemed to be the best-of-breed package for converting HTML into PDF for the purposes of delivering PDF versions of web content.

However, I noted at the time that DOMPDF's last release was in July 2007, and it still doesn't look like being updated any time soon. The fundamental problem with packages like DOMPDF is that they tend to implement their own rendering engine. The thing is, HTML and CSS are both pretty huge now - writing a rendering engine that can cope with all the different combinations is a huge task, so projects like DOMPDF end up missing out important bits of functionality.

A better approach would be to use an existing rendering engine from a browser, and then build a binary around it that can take a website as input and produce a PDF as output. That way you can get results consistent with how browsers would print a page and if you pick the right engine you'll not have to keep up with any changes to HTML standards, the engine developers will do that for you.

This is essentially the approach wkhtmltopdf takes: it extracts the open-sourced Webkit renderer used inside browsers like Safari and Chrome and bundles it up into a Linux CLI application which produces some pretty impressive results.

Simplifying file operations using PHP stream wrappers

When I took the Zend certification exam, one of the areas I really wasn't very clear on was PHP's stream wrappers. Since reading up on them for the exam, I've been kicking myself for not using them before, the amount of simplification they allow for common code is ridiculous.

As an example, a colleague recently showed me some code he'd written that downloaded a .dat.gz file from a remote server, saved it to disk, unzipped it and save the expanded contents into a file. The original code he showed me was similar to the following (with a lot more error checking and comments):

<?php 

$tempfile 
tempnam(sys_get_temp_dir());

// get the file from FTP to local disk
$fh ftp_connect('ftphost.com'21);
ftp_login($fh'username''password');
ftp_get($fh,$tempfile'/path/to/file.dat.gz');
ftp_close($fh);

// read data from local .gz into var
$gh gzopen($tempfile'r');
$data gzread($gh1000000);
gzclose($gh);
unlink($tempfile);

// write data to local .dat
file_put_contents('/local/copy/of/file.dat'$data);

The first thing to note is that the ftp functions have an underscore in, while the gz functions don't. To me at least, this makes it almost impossible to remember without constantly referring to the reference. The second thing to note is that by downloading the file to disk first, then reading it into memory, then writing it to disk, we're doing a three-step process.