Site Updates

Engineering is about tradeoffs. The upside of the recent changes is that the site is now more readable in general, but there’s always a downside in any tradeoff. The main burr under my saddle with the new design is that in general, sans-serif typefaces tend to shy away from little typographical details. As a typography nerd of long standing, this particular example irks me:

This paragraph is set using $serif. When I say “Hello, world!” I expect you to see curved quotation marks: visibly different glyphs are used for the opening and closing characters. These are commonly likened to “66” and “99” respectively.

On the other hand, using $sans, when I say “Hello, world!” you may well not see any difference between the opening and closing glyphs, particularly at normal text sizes. In Apple’s San Francisco font (the default user interface font on current versions of their operating systems), the two glyphs are different: although they appear to be paired bars sloping in the same direction, in the “66” glyph the tops of the bars are slightly thinner than the bottoms, with the reverse being the case for the “99”. The difference is, I would say, pointlessly small at normal text sizes.

It’s a little more obvious at font-size: xx-large; but still something only a typography nerd would ever care about:

“Hello, world!”

For the benefit of those using a system presenting a different font, here is an image of just the two glyphs, at xx-large size and then magnified by a factor of two just to be sure:

There’s always a downside. The trick, I suppose, is reducing it to the point where you can accept it. This is acceptable, but still sometimes irritating.

I did find the issue irritating enough in <blockquote>s like this that you will see that the large glyphs surrounding the block are in fact set in a serif typeface, although the body is sans-serif.

I have a long list of changes to make to this site one day, when I get the time or (more plausibly) when I am looking for a distraction.

This year, I have finally addressed the first of these, and if you’re reading this on the site rather than in a feed reader you may notice that most text now appears in the sans-serif font used by your operating system’s user interface. These fonts are usually highly optimised for screen use, and the result in most cases will be an improvement in readability, particularly on smaller devices.

This change sounds simple (and in the end, it was very straightforward) but required a lot of behind-the-scenes work to get to the point where it was simple to do.

If you’re interested, read on for details.

It has been a month now since I finished my Nanoc conversion work, and it’s pretty obvious from the chart below that the performance improvements I expected from converting to a static site are real, and are here to stay.

The chart is from Google’s search crawler, so it doesn’t represent real human usage, but the dramatic lowering of the access times since the beginning of February is undeniable. Previously, if you got unlucky, you might have waited more than a second for even one of my pearls of wisdom. Now the most banal observations might be available in mere milliseconds.

This site is going all-HTTPS, all the time. Read on for background and details.

[2018-03-11: HSTS implemented with max-age=1800, i.e., 30 minutes.]

[2018-04-16: HSTS implemented with max-age=31536000, i.e., one year.]

I have completed the migration work started back in December. As a result, this site is now entirely constructed using the Nanoc static-site generator, and the Drupal content management system has been retired.

If you’re reading this through a feed reader like Feedly, please drop me a line to let me know that the new feeds are working.

Continue reading for some thoughts on the process and on the results.

I started using Drupal to manage most of this site a little under six years ago. That wasn’t a mistake — it solved the problems I wanted to solve at the time — but it hasn’t been an unqualified success either. It’s time to move on to the next thing, which for me looks like Nanoc, a static-site generator written in Ruby.

The site update work I talked about in the last post has been completed:

• Everything has now moved from the www.iay.org.uk domain to iay.org.uk.
• Both of the old Movable Type blogs (this one, Technology Stir Fry, and the long retired iay@there) have been imported into Drupal.
• Many URLs have changed as part of this, but I think I have entered redirects for all of them (Drupal’s aliasing and redirect systems are really nice).
• In particular, the two blogs have new RSS feed locations, but the redirects seem to work for at least some RSS aggregators, such as Google Reader.

I’m pretty happy with the conversion, although I’ll probably change the theme once I have thought a bit about how I’d like the site to look like long term. Being able to theme everything at once will be nice; I’ve never been happy with the blogs looking so different to the rest of the site.

Let me know if you spot any rough edges.

[2012-06-01: Updated the site colophon with some description of the Drupal modules I’m using.]

I’m planning to make some fairly large changes to the site over the next couple of months. These will undoubtedly break things, and if you do run into oddities I’d appreciate a quick note so that I can unbreak them.

Today, the site will be moving from having a canonical name of www.iay.org.uk to the simpler iay.org.uk. Everything should be redirected safely from the old location, but I can’t rule out the possibility of some redirection loops to start with.

Later, the two blogs (including this one) will be migrated from Movable Type into the same Drupal content management system as most of the rest of the site uses these days. Again, I’m hoping that everything interesting will be redirected safely but I do plan to change the organisation of things like archive index pages so some links may well break.

Wish me luck.

As part of one of the more deeply nested yak shaving exercises I’ve been working through recently, I have added MicroIDs to various pages on this site. For example, the header for the main index page for this blog now includes the following elements:

<!-- MicroID for '/' variant of URL -->
<meta name="microid"
  content="mailto+http:sha1:b887e662ed3d811e665ef4a034e018a521a5467d" />
<!-- MicroID for '/index.html' variant of URL -->
<meta name="microid"
  content="mailto+http:sha1:ed938d07588303f4eeee45adfef090221e0c692e" />

A MicroID is a very simple way of making a verifiable statement about the ownership of a page. The specification goes into more detail, but essentially the value you see is constructed by independently hashing your e-mail address and the URL of the page in question, concatenating those results and then hashing once more.

The way you use a MicroID in practice is as supporting evidence for a claim of ownership to some third party who already knows your e-mail address. If you say “I own that page” to such a third party, they can compute the same MicroID value from your e-mail address and the page’s URL and then check for a match within the page’s <meta name="microid"> headers. You can see this claim checking by looking at the “verified” links in my claimID profile.

[2018-02-14: updated to remove the link to claimid.com, which has shut down.]

MicroID is an improvement on the perhaps more obvious approach of just embedding your e-mail address in the page because it doesn’t reveal your e-mail address to things like spam address harvesters. It also improves on a simple hash of the e-mail address by including the URL in the calculation because all pages owned by the same e-mail address are thereby given different MicroIDs. This in turn means that pages can’t be grouped together, even anonymously, by web spiders. Looked at from this point of view, a MicroID is a salted hash of the e-mail address.

I’m pretty sure that you could do the same job with one or even two less hash operations (for example, the URL is known by definition, so hashing it serves no purpose that I can see), but for static pages performance is not a concern. If I was running a large content site with dynamically generated pages, though, this aspect of MicroID might put me off a little.

Note that although a MicroID looks a little like a digital signature (of the URL) it really isn’t; in particular, a MicroID can easily be repudiated because anyone knowing your e-mail address can generate MicroID values “for” you and put them on any pages they please. In other words, you can use it to help confirm ownership of something by a claimant, but not to prove ownership by someone who denies the connection.

Generating the MicroID values for blog pages in particular was made simpler for me by Phil Windley’s MicroID plugin for Moveable Type. I did have to tweak it a little to correspond to the current MicroID spec, as Phil’s plugin as distributed generates what is now thought of as a “legacy” format lacking the scheme and algorithm specifiers.

This blog and the associated site, with its multiple custom databases and funny little web applications, has moved from “somewhere in England” to “somewhere in California”. Things seem to be stable, but if you see anything peculiar going on or can’t reach me using my normal address, let me know at redacted instead.

The new host is at DreamHost.com in Los Angeles, where I’ve had a shared hosting account for some other projects for about a year now. DreamHost do ridiculously well-equipped shared hosting plans for hardly any money, so if you’re looking for something in that line you should definitely consider them. Their best deal at the time of writing is to use the promotional code 888, which gives you 80% off your first year.

They also run a slightly pyramid-like referral scheme, so failing the above offer you could try the promotional code IAYHALFERS which rebates you half of my referral kick-back; on most plans, that’s worth $48.50.

The various feeds of this blog now include the full article body rather than just an extract. This should make things easier for those sensible people who read using an aggregator rather than through the web.

There is an RSS 2.0 button now. There has always been an RSS 2.0 feed, but now it has a button.

Thanks to Arvind Satyanarayan’s new MT Blogroll plug-in for Movable Type, I have added proper dynamic “Links” and “Blogs” sections to the side bar. My plan isn’t to have an exhaustive list of sites and blogs I visit (I have specifically removed all “A-list bloggers”, for example) but just to point to some things I pay attention to that are perhaps slightly less well known.

Comments are back after an outage of a week or so. Originally I took them off-line because of a mail relay vulnerability discovered in Movable Type. They didn’t get turned back on once I had installed Movable Type V3.15 because I forgot to change the mode on the new version of the comments script. D’oh!

Like many other people, the burden of discarding unwanted blog comment spam has been loading down my server recently, even though very little of it gets through to the site now thanks to MT-Blacklist. I have therefore upgraded to Movable Type 3.14, which reduces this problem by not regenerating parts of the site when it isn’t needed.

Courtesy of a custom Perl installation and Jay Allen’s latest MT-Blacklist software, anonymous comments are enabled again.

The Movable Type V3.11 upgrade has given me the opportunity to tidy the site up a little. I’ve started again with the new default templates and then hacked them into roughly the same shape as the old site… mostly.

Articles are now have hierarchical date-based permalinks, which means they have all changed. I have put HTTP redirects in for all the old ones, but in case that hasn’t worked there is a search box on the main page as well.

One of the reasons for upgrading to Movable Type V3.x was that I have been using Jay Allen’s great MT-Blacklist module to keep the blog spam away, and the new one for Movable Type V3.x is much nicer. In the long run, I can’t see Jay putting much effort into Movable Type V2.x support.

Having upgraded, then came the bad news: the new MT-Blacklist requires a later version of Perl than the one running on my public server. And it’s a Cobalt RaQ4, on which the remote administrative GUI dies if you upgrade Perl. Oops. Guess I should have read the requirements a bit more closely.

Given the amount of time required to get this far, I’m not going to revert to Movable Type V2.x. Instead, I have enabled the comment registration facility: in order to comment on the site, you now have to register with TypeKey and sign in. That’s free, and a one-time operation for all the Movable Type V3.x and TypePad blogs you comment on, but it is a bit more of a hassle. I’m sorry to put people through this, but I think it’s the best compromise for now.

I’m in the process of upgrading the software that runs my blogs from V1.65 to V3.11 of Movable Type.

So far I have run into only one problem with this process, a series of “prototype mismatch” errors when rebuilding blog index pages.

One of the reasons I decided to use Movable Type to run this blog was that you get the source, which means you can poke around with it if you want to. In addition, lots of other people have already written plugins for the basic system.

This article describes the ingredients that go together to make the current Technology Stir Fry. I plan to update it when I make significant changes to the site.

[Latest update 20040520: Upgraded MT-Blacklist to V1.63, then to V1.64.]