blog.andyhume.net

I stand by what I said from day one. Technically, it’s a big ass iPhone. But the iPhone is really a pretty magical device. And this is a big ass one.

Here follows my prediction for myself and the iPad.

While it’s impossible for me to buy one, I don’t really want one. I certainly don’t need one. There’s no obvious gap in
my computing armour that it will fill.

That is, until the day it becomes possible for me to walk to a shop and buy one. Otherwise known as the UK release date. On that day, I will almost certainly walk to said shop and buy one.

I’m not proud of myself.

Yesterday I went over to The Werks to listen to Remy enlighten some of the Flash Brighton gang on what to expect from HTML5 in the coming months and years. The subject of Chrome Frame came up, with the general consensus being that it wasn’t really going to have an impact on the number of people browsing with IE, specifically IE 6. I take a different view on that question, and here’s why.

An email from Google appeared in my inbox only a few days ago informing of the impending drop of support for IE 6 on the Google Apps product line. Google don’t want to engineer for IE 6, and they’ve clearly made a decision that with Chrome Frame in the wild they are now at a point where they don’t have to.

Chrome Frame is a strategic move which allows them to drop IE 6 support in some of their core products quicker than they would otherwise be able to. It gives them an answer to users (mostly likely their enterprise customers) that can’t upgrade from IE 6 for whatever reason. Presumably the potential loss of revenue from those customers must now weigh in less than the cost of engineering for IE 6.

As a bonus, Chrome also patches some of the HTML5 and CSS 3 support that’s appearing in Webkit into the more modern versions of IE, which are still lagging behind.

The key point is that Chrome Frame paved the way for Google to make this move, and Google dropping IE 6 support is significant in terms of influencing people to move on from it, either by installing Chrome Frame, or by upgrading to a newer version of IE or a competing browser. It might be difficult to quantify this significance, but where Google lead the way, consumers and competitors tend to follow.

I believe that’s one of two main driving forces behind Google developing and releasing Chrome Frame: it frees them up from the pain of IE 6. The other reason is is that it allows their product teams to focus on the future technologies of HTML5 and CSS 3 now. To get ahead of the game. To discover new ways of using that technology. And to build the next generation of web applications while the rest of the world sits around fixing double margin float bugs.

I’ve been a friend of Clearleft from day one, when Rich left me on my own at Multimap to go and start his new venture in 2005. Pretty much from that day I’ve had the thought in the back of my mind of whether I might one day end up working there. To be honest, I thought the right moment had probably past. But when Rich asked me at the end of last year whether I’d like to apply for the job, other events were conspiring to make it exactly the right time for a new start. Those conspiring events are for another post (possibly); but in essence, a lot of things were up in the air, and it felt right that they land in Brighton with a new job at Clearleft.

I’m in my second week there now, and it’s been a lot of fun. I’ve learnt a ton from working alongside Natalie, and have really enjoyed getting to know those from the team that I’d not previously had the pleasure of meeting. It’s exciting to work alongside people that I’ve admired for a long time; indeed, some of the people that inspired me to become a web developer back in the day. I say that totally unashamedly, because it’s true.

I’ve been commuting down from London the last week, which has been a pain. But from next week I should be a permanent resident, enjoying my daily walk to work (walk to work – did you get that?) and meeting the people that make Brighton’s geek scene what it is. If you’re part of that scene, look out for me, and say hello.

So here starts a new chapter. It’s exciting and a bit daunting, but I feel refreshed and very happy to be here. I’m pretty sure Brighton is one of only a handful of places I’d have left London for; and I’m completely sure that Clearleft is the only agency I would have left Microsoft for.

Last week, some colleagues of mine were discussing how many blog posts they had drafted in their blog software, but never actually published to their blog. I took a look at my draft posts in Wordpress today, and thought it might be fun to publish what the titles and ideas behind them were. Some of them are years old, and it wouldn’t make much sense to publish them as they are. So this is just a bit of fun really, as well as being an easy post which might start me down the road of regular blogging again. Actually, this could become quite a fun meme. Maybe.

Using your old PC as a development server – May 2005

This was really a guide on how to set up a machine running Linux with Apache, PHP, MySQL, etc, and make it available on a fixed IP on your local network. The kind of thing you’d be more likely to do using a VM these days. I’d recently inherited an old Pentium 2 which had an aversion to Windows, so it became a playground for my first real experiments with Linux and web server technology outside of a shared hosting environment. I never finished writing it.

Working at Google – November 2005

This was a tongue-in-cheek look at the various employee benefits that Google people allegedly enjoy. It started with a few well known and genuine perks and gradually got more silly, with things such as speed-dating nights for geeks that don’t get out much. I don’t think I knew anyone at Google when I wrote this.

JavaScript Libraries – December 2005

Something of a rant about the dangers of plugging JavaScript libraries you don’t understand into your web pages. This was at the time of Prototype’s dominance, and prior to the rise of jQuery. It was inspired by a Carsonified Ajax workshop with Thomas Fuchs that taught Ajax solely through the features and API of Prototype. It was very silly, not least because 80% of the attendees (BBC, Multimap, Yahoo!) couldn’t go away and put Prototype on their websites.

Redesigning MAS – March 2006

I used to do unsolicited redesigns of small but well-known websites in the music business. Along the lines of 37better projects. This was immediately after the redesign of the MAS website (it’s the one you still see to this day), on which someone did such an appalling job that I couldn’t hold my tongue. As a former client of MAS I should say they are a superb operation, but their web presence is, to put it bluntly, crap.

Buying a bed and mattress – April 2006

On moving into my flat in East Dulwich I was looking for tips on how/what/where to buy a decent bed. I probably should have published this one as I’ve never been happy with the thing that I ended up buying.

Ten years of XHTML – July 2009

In the wake of work on XHTML 2 being stopped I wrote up some thoughts on why it hadn’t worked out, why HTML 5 was working out, and how we can rationalise the specifications and recommendations of the W3C (and others) in our day-to-day work as web developers. Could re-hash this and publish, I guess.

Full Frontal – November 2009

Some thoughts on the Full Frontal Conference that I attended. It was one of the best technically focussed conferences I’ve been to in years, but this post was more around what it’s like to be a Microsoft employee (which I was at the time) at an event like that. I didn’t have the company name on my badge on this occasion (which I was quite glad of) but it’s interesting how it was generally assumed that no one from Microsoft would be there. Not that I would be standing up for or representing the company in any way, but it would be good for people to know that employees are out there, that they are part of the community, and that they’re not all big, bad, and evil in nature.

The Spectrum of Opinion – December 2009

A piece on how having a strong belief or opinion can warp your objectivity on that subject. Your mind subconsciously looks for and solidifies evidence to support your theory, and dismisses or discredits evidence that contradicts it. There’s probably a well known name for this phenomenon, though I haven’t come across it, and it’s something I find interesting.

Understanding HTTP – November 2009

Some thoughts on this fundamental piece of the web’s architecture and its impact on how web technology is innovated, built, and delivered. Will probably finish and publish this now that I have left Microsoft. If you see what I mean.

In just over 24 hours time the domain name bellatromba.co.uk expires.

For reasons I won’t go in to here (except to say that nobody’s to blame), the domain is not under my control and it doesn’t look like it’s going to be renewed. Meaning the website and email accounts that rely on it will effectively cease to exist. Meaning the people that rely on them are up a certain creek.

I do however, have bellatromba.com; and the plan is to move over to that, albeit at this absurdly late stage. With a few months notice, it’s perfectly possible to transition a domain like this fairly smoothly. You may get the odd bouncing email, but in general it’s not the end of the world, particularly if you still have control of the old domain to continue redirecting from.

However, as I mentioned, we’ve got 24 hours. And we don’t have the old domain.

About 20 minutes ago I set up a new virtual host on the server for bellatromba.com, and added some redirect rules to 301 redirect requests to bellatromba.co.uk on to bellatromba.com. So that’s all fine, except that in 24 hours all those links will break. Including Google’s, where the site is the number one result for the search phrase trumpet quartet.

It would be great if Googlebot popped along in the next day or so and indexed the whole site under the new domain, without any loss to search engine rankings. I wonder what the chances of that are?

Incidentally, if you’re wondering why we don’t just go and re-register the domain tomorrow once it expires, it’s because owners that let their domains expire have a grace period of anything up to 75 days to get their act together. Which is great if you happen to have forgotten to renew your domain (which we haven’t), but less great in the circumstance that we are in (which we are).

So that’s the story. Come back next week to see if the site is still number one in Google (unlikely).

Multimap was acquired by Microsoft, meaning I’m now an employee of the big MSFT. Wowza, where did that come from?

I’ve just spent the last week getting very excited about a software update for my favourite piece of hardware. New features, UI improvements, all downloaded from the comfort of my living room, via iTunes, to my… phone. My phone?! When did I give a crap about software on my phone? Strange times we live in, huh?

Ed parsons is saying extraordinary things about Open Street Map. “Mapping data needs to be comprehensive”, which is like saying “We need world peace”. Yes, we do! Fortunately, he talks some sense when it comes to the BBC’s streaming iPlayer which rocks and has really screwed up my New Years plans of getting a few early nights.

Happy New Year to everyone.

Just a quick note to point any mapping geeks out there to the inclusion of Ordnance Survey maps in Multimap’s free mapping API. These are the 1:50000 Landranger maps so popular amongst walkers, hikers and anyone who took Geography lessons at school.

This is a nice little inclusion to the API, and I look forward to seeing people taking advantage of it in the UK. It’s probably worth mentioning again that you can also use the following bookmarklet to switch on Open Street Map data for the Multimap website as well as other Multimap API powered apps.

OSMify

Go enjoy some maps!

When we’re hiring JavaScript developers at Multimap we sometimes ask them to build a little application, or mash-up, with the Multimap API. It’s a pretty simple little task but it allows us to see how people approach building a web application.

This is a list of five things I often notice when looking at these little applications that could be improved. They may be obvious to some people, but certainly not to all. So, without more ado: five quick JavaScript tips to improve the quality of your code.

Use the submit event on forms

When attaching event handlers to forms, always use the submit event of the form and not the click event of the submit button.

If something is clickable, make sure it’s a link

Don’t attach click events to elements other than anchors or form submit buttons. This is particularly important for users navigating the site with methods other than the mouse, where they may have difficulty getting focus on non-anchor elements.

Simple loop optimisation

There’s a very simple change you can make to a for loop to improve it’s performance.


for ( var i = 0; i < elements.length; ++i )
for ( var i = 0, j = elements.length; i < j; ++i )


In the second example the length of the elements array is stored in the j variable, so it's not queried on every iteration of the loop.

Use anonymous functions for event handlers

Particularly with short functions like the below, it is far more readable to create an anonymous function than to reference another named function elsewhere. It also allows you to use closures of course.


anchor.onclick = function() {
map.goToPosition( home );
return false;
}


Use Array.join instead of concatenating strings

When working with long strings that need to be joined up, it is more readable and better for performance to place strings in an array and use the join method to return a string.


var text = 'There are' + elements.length + 'members in the elements array.';
var text = ['There are', elements.length, 'members in the elements array.'].join(' ');


Update:
A number of people have mentioned to me that the Array.join technique for string concatenation is a bad one, particularly if you're only doing it with a small number of strings. Our benchmarks show it being faster for IE when you get to about 6/7 string concatenations, so it's been useful to us in some situations. But I'd agree with Stuart below that for the average situation it's not going to be worth it. However, I don't see using Array.join() for string concatenation as an abuse of JavaScript.

Most of the articles and examples I’ve seen of handling events with event delegation use some kind of JavaScript library. Chris Heilmann’s much cited article uses the YUI library, and Dan Webb’s presentation at @media last month used the Prototype framework.

For those of us just building a bog standard JavaScript application without one of these fancy libraries, it’s worth taking a look at how event delegation works in the real world. It sounds more complicated than handling events in the standard way, but it really isn’t.

For those that haven’t come across the term before, event delegation refers to the technique of reducing the number of event listeners attached to the document by attaching just one listener to a containing element and testing in the handler where that event has bubbled up from.

Let me give you an example from the Multimap website. The main navigation on the site includes 6 links across the top, 4 of which require event handlers to alter the href attribute of the link when it is clicked. These 4 links have a class attribute of ‘bundle’.

Traditionally you might approach that situation in the following way.


var MMNav = {
init: function() {
var nav = document.getElementById('mainNav');
var links = nav.getElementsByTagName('a');
for ( var i = 0, j = links.length; i < j; ++i ) {
if ( links[i].className == 'bundle' ) {
links[i].onclick = this.onclick;
}
}
},
onclick: function() {
this.href = this.href + '?name=value;
return true;
}
}


There's a lot of overhead in the above code. First of all the getElementsByTagName loops through every DOM node in the mainNav element to find all the links. We then have to loop through them again manually to check the class names of the links. That's wasted CPU cycles at every stage.

How about if we could just attach one event listener to the mainNav element and then capture any click on the links within that?


var MMNav = {
init: function() {
var nav = document.getElementById('mainNav');
nav.onclick = this.onclick;
},
onclick: function(e) {
if ( e.target.className == 'bundle' ) {
e.target.href = e.target.href + '?name=value';
}
return true;
}
}


The simplicity and elegance of this should be pretty clear, but it has a number of performance benefits as well:

• The less event listeners attached to a document the better. They all take up memory and in extreme circumstances can slow browsers down considerably.
• There is much less code running on page load. One of the major issues with complex web applications is the wait on ‘load’ for JavaScript to execute and set up the document. The two loops in the first example are nowhere to be seen in the second example.
• ‘Just in time’ execution. The second example does a little bit more work when the event handler is executed, but this is better than doing that work on ‘load’ when we don’t even know if the resulting handler is going to be executed or not.
• It’s less code. Less code means less maintenance, and less bandwidth for both your web server and your users.

There’s one caveat to the above code. Getting the target element of the event is not always as simple as using e.target. In Internet Explorer you need to use e.srcElement. The easiest way of dealing with this is to use a small getEventTarget function. Below is what I use.


function getEventTarget(e) {
var e = e || window.event;
var targ = e.target || e.srcElement;
if (targ.nodeType == 3) { // defeat Safari bug
targ = targ.parentNode;
}
return targ;
}


Event delegation is a fairly well established practice when dealing with large numbers of event handlers (eg, a map with hundreds of points, all with click events attached), but in my opinion it should be the default way you go about adding and handling events. It’s a simpler, more intuitive, and more optimized way of dealing with a common pattern in client-side scripting, and it doesn’t require thousands of lines of a JavaScript library for it to be useful to you.

A few people at Hackday presented hacks that use Twitter’s direct messaging API to interface with a third party Web Service. By far the coolest one was Colm and Richard’s that allows you to request data from eBay and Wikipedia as well as a host of useful information such as nearest cashpoints, cinemas, tubes, restaurants and many others.

Want an example? How about being able to text to Twitter closest atm from ec4a2dy, and get back a set of walking instructions for finding the nearest cashpoint. Pretty handy I would argue.

Want to know if there’s anything interesting round about? Try sending closest wikipedia from rome, italy and that should keep you going for a bit.

FireEagle

The hackday bot (not currently available for public use) uses Yahoo!’s FireEagle service to find out your current location so that you don’t have to send it to Twitter every time. This means if you can set up your GPS device or mobile to ping FireEagle your location every minute or so, you’ll never have to worry about where you are and what is around you again. You’ll simply text to closest pub, FireEagle will know where you are, let Multimap know so they can query their local information database and Twitter will send you back what you need. This is pretty astounding really, and I don’t know of another service right now that can offer quite the same kind of thing.

In my opinion FireEagle has some serious implications for the way location based services are going to work in the future, and I think what the guys built at hackday is an early prototype of what may be round the corner.

For added comedy value they also created a spoof iPhone ad to show off the Twitterbot in action. Is there no end to their creative genius?