notes.husk.org

Quixotically, I continue to apply my husk.org style to the things nobody looks at, rather than the things everyone does. The latest victim is the neglected husk.org/code, which now sports a fancy look, courtesy of a little HTML and the following in a .htaccess file:

IndexOptions SuppressHTMLPreamble
IndexOptions HTMLTable
IndexOptions SuppressDescription
IndexOptions NameWidth=*
HeaderName HEADER.html
ReadmeName FOOTER.html

Anyway, if anyone else wants to figure out how to make an Apache directory index vaguely pretty, have a look. (If there’s a better way to get rid of the <hr>s than post-processing on the client, let me know.)

Edit: There is! I can’t find the place I found it now, but I have the following setup instead, and it needs far less jQuery postprocessing (just two lines to shift the headers to right-alignment). Note SuppressRules in particular.

IndexOptions HTMLTable
IndexOptions SuppressHTMLPreamble
IndexOptions SuppressDescription
IndexOptions SuppressRules
IndexOptions SuppressIcon
IndexOptions NameWidth=*
IndexIgnore FOOTER.html HEADER.html ..
HeaderName HEADER.html
ReadmeName FOOTER.html

Right, that’s that done, I think. Onward.

Another day, another JavaScript performance increase. This time, it’s the WebKit team, with the somewhat ludicrously named SquirrelFish Extreme, which manages a tenfold speed increase on Safari 3’s JSKit engine, apparently.

Oddly, it seems as if most of the work involved has been done under the auspices of the Summer of Code, Google’s programme to get college students involved in open source projects. Of course, the other newcomer on the JS engine block is their own V8.

However, good as all the competition between these two (and Mozilla’s TraceMonkey, due to be released in Firefox 3.1 and, like the others, available in pre-release form) is, it ignores the elephant in the room. As I commented on a PC Pro blog post about Chrome and Firefox (after the V8 talk at Google Developer Day), this progress is pretty much passing IE by.

John Resig’s recent benchmarks of JavaScript engines show that Internet Explorer 7 is awful, and IE8, although better, is nowhere near the performance of the released competing browsers, let alone the improved versions currently under development. Indeed, after one chart he has to note:

No results for IE were provided as the browser crashes when running the tests, unfortunately.

(To be fair, he does go on to say that Safari nightlies also failed on Windows.)

So, what’s the outlook? Clearly JS-intensive applications are here to stay, and I think we’ll increasingly see interfaces to them on the server side and possibly the desktop too. However, the developers of the most cutting-edge of these apps will either be held back by, or have to explicitly exclude, the most common browser in the world. Maybe that’ll be enough to keep Microsoft focussed on improving, and from the notes to a recent interview, it looks like they know it. Here’s hoping it works out.

Tumblr has a nice API (for reading anyway) that lets you get posts as JSON. Unfortunately, you can’t filter by tag, and per-tag pages don’t have RSS or Atom feeds of their own.

Vox has a nasty heavy Atom API for reading which doesn’t seem to do JSON, but it does filter by tag, and per-tag pages have feeds of their own.

Sigh.

As part of the keynote of Google’s Developer Day in London, Mike Jennings ran a demo of Android on prototype hardware. (In fact, it may have been the first public demo of such in Europe.) Some notes:

• It works, and not slowly.
• The name of the device manufacturer was covered in tape.
• The browser seemed to load + render Slashdot on a private wifi network about as quickly as my iPod touch on the public one did
• Maps works pretty much the same on both
• The public network’s SSID makes my iPod think it’s in San Jose (is there a song joke here?)
• The demo hardware had an accelerometer, and there was a “blue dot” demo app with basic physics
• Unlike Aral, I don’t think I’d notice the lack of multitouch
• It looks like the application menu is alphabeticised, which might be a nice solution to the problem of managing long app lists.

Although I don’t really have any reason to go to the Android talks, this did make them seem a bit more appealing.

I’ve finally got to the point where I’m happy to really start posting about snaptrip.

snaptrip is a little web project that lets you use Dopplr and Flickr together. Initially, it allows you to put machine tags - specially formatted bits of data - on your Flickr photos. Why bother? Well, Dopplr itself uses this data, if available, to show you photos on its site.

Obviously that’s a bit dull, and I do have further plans going forward, but because I’ve been stopping quite often to polish the app as I was building it, it’s been a bit slower than I’d like. (I’ve also been using it to learn about both Python and Google App Engine - the appspot.com gives that bit away).

Anyway, once I’ve sorted out a couple of little niggles, I’ll probably post more about this elsewhere, but for now, if you have a Dopplr account, feel free to try it.