Lately

Can’t be true, but wouldn’t it be great if it were?

The V&A states the obvious:

Homes: The home is the most common form of building in the world. Whether housing a large family or just one person, all homes are arranged around domestic routines and activities. Local traditions affect the ways in which private and public rooms are designed. The size and individuality of our homes may also say something about our social standing.

The V&A’s Architecture section isn’t that great, but the entrance does feature an extraordinary isometric drawing of St. Paul’s Cathedral. Would love to get a print of this!

Regarding houses, one of my favourites is Mies van der Rohe’s Farnsworth House.

Across the road from my place–I can see it from my kitchen window, to the right of the pharmacy with the Banksy on the side wall–is this little Turkish cafe called Casaba. I’ve been there once or twice to get a hot chocolate, and it’s rather nicer inside than it would appear from the outside. (This is a surprisingly frequent turn of events when it comes to the shops of Essex Rd.) Anyway, one of the more perplexing things about Casaba is its very unusual (and seemingly unpredictable) opening hours–not open early in the morning, not open on Saturday afternoon, not open Sunday; open Monday evening, open Tuesday evening.

On Christmas night around 10.30, Pearlie and I were walking home along Essex Rd, and noting which shops were open and which were shut (Raab’s Bakery, dry cleaners, Co-op, Mississippi Fried Chicken–shut; minicab booth–open; dodgy Burger/Kebab/Pizza near minicab booth–open; the two largish 24 hour convenience stores that flank the Co-op–open!) and got to musing whether Casaba would be open too. Wouldn’t that be quite something? For the plucky little cafe to be serving on Christmas night?

And then, as we got closer, we saw that the sign on the door said “OPEN.” We were walking along the other side of the road and it was dark, and it was dark inside too, but there seemed to be people in there. We went a little bit closer and yes, there were definitely people inside. We crossed the street and opened the door. Some music was playing pretty loud. “Are you open?” we asked, still standing in the doorway. Yes, yes, replied the patrons and staff. (It never did become completely clear who worked there, and who was just visiting.) So we stopped by and I drank an Efes and Pearlie an apple tea. And that’s really the end of this story–the most surprising thing that happened to me on Christmas Day.

Oh, one of the reasons that Casaba’s opening hours seemed so eccentric was that they’d recently changed from being a cafe to a bar. (Business hadn’t been so good, evidently. According to the owner (co-owner?) Casaba had once been a successful Sisha bar (29 flavours!) but the smoking ban had changed that pretty quick.)

P.S. The most surprising thing that happened on Christmas Eve what that some dodgy chorizo undid my stomach, so I spent a large part of the night throwing up. I felt fragile for most of Christmas too, and spent most of it in bed. The pink lady apples were nicely medicinal though.

The Seventh Seal (1957), dir. Ingmar Bergman. Bergman was investigated by the Swedish government for tax evasion in the 1970s; though acquitted, he was so shaken by the experience that he quit making films for eight years.

So you’re reading a profile of Chinese musician Yang Yang in The New Yorker (link leads to an extract only) and you come across a passage that goes

When he is handed flowers, the first thing he does after smiling and saying thanks, is look around, eyes darting, for somewhere to ditch the flowers. For nine days I felt like a maid of honor.

… and then you flip back a few pages to check that, yes, it was David Remnick, the editor of The New Yorker himself, who wrote the piece, and who is now graciously subordinating himself to the subject of his profile.

[Update The site webfonts.info has a list of the fonts available for embedding, and two of the three fonts I list below (Liberation and Vera) aren’t present. So although these fonts are freely redistributable, it seems they’re not actually available for embedding. I’m not what the legal distinction is—?]

Safari now supports downloadable fonts, meaning that—from a technical perspective—web pages can appear in pretty much any font the designer chooses. (A clumsy Flash-based technique called sIFR made it possible to use different fonts for headings, though not body text.) In fact, if you’re using a recent version of Safari, and are viewing this on the web, this sentence will appear in Gentium Basic.

Unfortunately, the license agreement for almost every high-quality font prevents them from being redistributed, and therefore from being used on web pages in this way. However, there are a few exceptions:

• Gentium Book Basic — from SIL
  
• Liberation — from Ascender/RedHat; has the same metrics as Times New Roman, Arial
  
• Vera — from Bitstream/GNOME; no seriffed italic
  

An article on A List Apart describes how to create web pages with embeddable fonts; here’s CSS files for Gentium, Liberation and Vera.

For some reason quite a few browsers seem to be erroneously downloading these fonts: only Safari supports embedded fonts at this point, but the server log files indicate the clients with IE 6.0 and IE 7.0 user agents are downloading them as well. Does anyone know why this is happening? Are they indiscriminately downloading all url() links?

[On a separate note, the reason why the SIL are interested in fonts is somewhat interesting: they’re an evangelical Christian organisation with a focus on unwritten languages. (I’m guessing their ultimate aim is to expose as many people as possible to the Bible, though their academic linguistic work seems reasonably separate from their missionary activities, and their work is respected in academic circles.)]

Something that’s been interesting me recently: London’s surprisingly strict hierarchy of high street stores (chains/franchises). There’s shops that are found in rich areas, and shops that are found in poor areas, and never the twain shall meet—you can get a pretty feel for how rich an area is from its shops, as well as what other stores might open up soon. Similar “rules” probably apply to other big cities, but I think London is particularly consistent—you don’t often find a shop in the “wrong” area.

Pearlie and I made up this list (most affleunt to least affluent):

Space NK
Muji
Paul’s
Body Shop
Wagamamas
Pizza Express
Eat
itsu
Pret
Starbucks
Office
Costa
Caffe Nero
Coffee Republic
Blacks
Fat Face
Odd Bins
Sainsburys Local
Tesco Express
Network Mobile Phone Shop (e.g. O2 shop)
Threshers
Rymans
Carphone Warehouse
Snappy Snaps
Holland & Barrett
Foot Locker
JD Sports
Boots
Blockbuster
Londis
Somerfield
Superdrug
Domino’s
McDonald’s
Burger King
Subway
KFC

The rules for what gets included are a little loose, but basically any chain with at least 10 stores in London were included. We didn’t count bigger stores (like H&M, supermarkets) because they’re often destinations in their own right. In some cases, there is a small amount of movement upward. (The fast food chains, for example, are sometimes found about Starbucks level.) Betting shops (William Hill, Ladbrokes) are pretty much the only shops we could think of that can be found pretty much anywhere.

A geohash is a way to encode latitude/longitude into a string such as gcpvjk3c that includes only number and letters, making it easy to pass around in URLs, etc. The Wikipedia entry makes the algorithm seem more complicated than it actually is. The steps are:

1. normalise latitude and longitude to the range [0, 1)
2. convert normalised latitude and longitude to binary (in the conventional way)
3. interlace the bits of the two binary representations to create one binary number
4. convert this number to base-32 (i.e. every 5 bits becomes a character) using a alphabet that includes all the numbers and all the alphabet, with the exception of a, i, l, o

A geohash also supposedly has the property that similar locations have a similar prefix, making it easier for computer programs to figure out similar locations, without resorting to complicated and slow trigonometry that won’t scale to hundreds of thousands of points.

Geohashes do have this property for many geospatial neighbours, but there’s still a most significant bit, and locations either side of it are going to have very different geohashes. Unfortunately, given the location of Greenwich—about 10km to the east of central London—a whole bunch of London locations have very different geohashes. u10hb7951 and gcpuzewfz, for example, are very close to each other.

Moving the 0, 0 point to into the middle of the Atlantic (or anywhere not as inhabited as London) helps with this, but it’s obviously not a robust fix. I wonder how the geospatial extensions to MySQL and PostgreSQL actually work? It’s fairly efficient to convert hashes based on one origin to another, so perhaps they store multiple hashes per location? There must be some clever algorithms for this.

OS X comes standard with many Emacs keybindings (Ctrl-A to move the cursor to the start of the line, Ctrl-E to go to the end, Ctrl-N and Ctrl-P for next and previous line, etc.), and since I’ve been using these keybindings for about 15 years it’s pretty difficult to not hit, say, Ctrl-P when it happens to conflict with WordPress’s shortcut to publish a post… This is pretty much guaranteed to happen at least once whilst writing a post, so this needed to be fixed.

There’s no configuration option to turn this off, and accesskey="p" is buried in the HTML source and I couldn’t figure out a way to filter it out—so the only thing left is JavaScript.

The fix I came up with is below; I’m just dumping this here instead of packaging it up because I haven’t tested it on IE and it doesn’t work at all on Firefox (though see below for a solution for Firefox). You basically need a plugin like this:

function disable_accesskeys() {
    ?>
        <script type="text/javascript">
        jQuery(function () {
        var l = document.getElementsByTagName("input");
        for (var i = 0; i < l.length; i++) {
            if (l[i].accessKey) l[i].accessKey = '';
        }
        });
        </script>
    <?php
}

add_filter('admin_head', 'disable_accesskeys');

Note: for some reason this doesn’t work with Firefox. (Though neither does Wikipedia’s JavaScript solution, upon which this is based.) However, there’s a better solution for Firefox: you can disable access keys/shortcuts completely by setting the ui.key.contentAccess (access via about:config) preference to 0 (i.e. zero). (Is there an equivalent for Safari?)

Access keys are a bit of a failure, I think. They’re not consistent, not transparent (you don’t know what’s going to happen before hitting a combination), and they can conflict with whatever bindings your users might be using already.

*  *  *

Turns out that the original Emacs keybindings were fixed the way they are because, when Guy Steele was putting them together, about 20 people at the AI lab at MIT were already using Emacs, and so he couldn’t change the bindings without alienating existing users…

A few years ago I asked Google answers for a good, authoritative, durable reference for Emacs keybindings (I wanted to pass this on to people) and didn’t get any good replies. I wonder if one exists now?

Final Emacs keybinding-related note: on OS X, putting DefaultKeyBinding.dict in ~/Library/KeyBindings makes a whole lot more Emacs keybindings available, as well as making Home and End work the way they do on Windows. (i.e. move cursor to the beginning and end of the line.)

This site, like just about every other, links to itself from the header, footer and sidebar. It’s somewhat interesting (and maybe even useful) to know which of these regions are actually being used, and the other day I realised this can be tracked fairly reliably and non-invasively using a cookie with a very short lifetime to store the region.

The way it works is, if you’re on a.html and click on a link that takes you to b.html, as you click on the link on a.html, some JavaScript runs that figures out which region you’re in, and writes this to a cookie with a very short lifetime. Then b.html loads as normal. Then, once b.html has finished loading, the tracking code pulls the region value out of the cookie and sends it on.

The Prototype code to trap clicks:

document.observe('click', function(v) {
    var e = v.element();
    while (e.id == "" && e != document.body) {
        e = e.parentNode;
    }
    Cookie.set("region", e.id != "" ? e.id : null, 20); // short lifetime
});

This finds the first ancestor of the clicked-on element that has a id attribute, and saves that as the region. It is run on every click—not just links—but my site is mostly flat HTML so most clicks do end up as page loads. (If this is not the case, you could add some code to filter out the non-page load clicks.) The 20 seconds is basically a guess that b.html will have loaded completely in 20 seconds—too long and you risk capturing regions from different sessions or browser tabs, too short and you won’t capture regions at all.

In b.html, the region is extracted with Cookie.get("region"); see init.js (which also defines Cookie.set() and Cookie.get().)