I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

Part three covers the JavaScript data for the telemetry panel, known as “The Race 1.0b”.

Using JSON-P

There’s very little processing of the feed between the web server and McLaren. The telemetry data is simply reformatted for convenience and merged with the Commentary (which is actually added through a local source by a guy in the pit garage). We made sure we sent through as much data as we could get – though you may need a large screen to be able to see it!

Data is sent using JSON-P. This is so that the data can be acquired from the feed domain rather than the site domain; crucial since the data feed server is in a different network for performance.

JSON is a great way to mark up data for consumption by JavaScript. It’s quick to assimilate, and very easy to read and debug. It’s also far shorter in length than the equivalent XML structure.

One of the principles of the Nginx Http Push Module is request idempotency. If this doesn’t mean anything to you, you’re not alone. All this means is that the client should always request the same URL, but with different caching times set. This lets the caching mechanisms within nginx serve up all the messages posted since your last request. However, this is no use to us – there is simply no way to load json-p cross-domain without using script tags, and webkit-based browsers simply will not reload the scripts if the filenames are the same. (I suspect this is true of other browsers too actually, but I’ve got caching turned off for development in Firefox).

I append a randomised string to the end of my json-p requests (using cache:false in my jQuery ajax request) to avoid caching. The broadcast mechanism still works, but I’m unable to use the queue backlog in the nginx http push module. I have therefore set the maximum queue length to zero.

The disadvantage of this is that I will only receive packets of data that are sent when I am on the line as a subscriber. If my connection is patchy, then I might miss packets of data – not critical for telemetry, but a shame for any commentary that is sent through.

However, I am able to broadcast the JSON-P packets to vast numbers of subscribers.

JSON Format

The ‘standard’ telemetry packet looks like this:

Dashboard.jsonCallback('{"drivers":{"HAM":{"code":"HAM","telemetry":{"timestamp":"18:43:38.078","nEngine":758,"NGear":0,"rThrottlePedal":0,"pBrakeF":2,"gLat":0,"gLong":0,"sLap":0,"vCar":0,"NGPSLatitude":-37.85131,"NGPSLongitude":144.97086},"additional":{"lap":"0","position":"6","is_racing":"0"}},"BUT":{"code":"BUT","telemetry":{"timestamp":"18:43:38.317","nEngine":1695,"NGear":0,"rThrottlePedal":0,"pBrakeF":1,"gLat":0,"gLong":0,"sLap":0,"vCar":0,"NGPSLatitude":-37.84984,"NGPSLongitude":144.96927},"additional":{"lap":"0","position":"1","is_racing":"0"}}}}');

It’s pretty clear what each term above means. The packet above is from a lap of the Australian Grand Prix in Melbourne.

The commentary, and all data in ‘additional’, is provided by the commentry team in the pits. This is why the lap and place can sometimes seem out of sequence.

At this point it’s a good time to add a legal note:

• The data must not be stored or distributed. This data is copyrighted like other information published on the Internet, and all F1 data is covered by strict rules regarding usage.
• I am not employed by McLaren and do not speak for McLaren. I give no authority nor advice on how to use this feed, and am only writing this post to help others who may wish to build a similar system.

Having said that, here are my thoughts on netiquette:

• The speed, throttle and brake are sponsored by Vodafone. If quoting these values, it would be a good karma to give a link to their site.
• McLaren are providing this data for you to view, as a fan. If referring to the data, you should provide a link to their site, and tell them how cool it is.
• Don’t abuse the servers. We can see the discrepancy between viewers on our site and from others, and measures might be taken to prevent feed highjacking.

Ok, to continue. Every lap end, we get some extra information in the packet:

Dashboard.jsonCallback('{"drivers":{"HAM":{"lapTimeS":"91.959","maxSpeedKph":305,"meanSpeedKph":204,"maxLateralG":6,"code":"HAM","telemetry":{"timestamp":"17:47:32.693","nEngine":15877,"NGear":5,"rThrottlePedal":0,"pBrakeF":51,"gLat":1,"gLong":-2,"sLap":316,"vCar":202.6,"NGPSLatitude":-37.84817,"NGPSLongitude":144.96664},"additional":{"lap":"0","position":"7","is_racing":"0"}},"BUT":{"code":"BUT","telemetry":{"timestamp":"17:47:32.938","nEngine":17276,"NGear":5,"rThrottlePedal":100,"pBrakeF":1,"gLat":0,"gLong":0,"sLap":593,"vCar":232.1,"NGPSLatitude":-37.846,"NGPSLongitude":144.96573},"additional":{"lap":"0","position":"2","is_racing":"0"}}}}');

Extra fields in this packet are:

• lapTimeS
• maxSpeedKph
• meanSpeedKph
• maxLateralG

How does it request the data?

I use jQuery rather than Mootools. So, I rewrote Leo’s Mootools plugin (provided for the chatroom on the pushmodule site) in jQuery. I’m not convinced it offers me anything much anymore, since I’ve taken out most of what it did, but it’s easy to use. It’s located at http://mclaren.com/_assets/js/site/jquery.nginx_subscribe.js.

I also use the jQuery JSON parsing plugin.

I then use those plugins with this code:

var Dashboard = function () {
	// URL of data feed
	var dashboardURL = 'http://feed.mclaren.com/feed/sub'; // Live service
	// on document load
	$(document).ready(function() {
		// create subscriber
		var dashboard_subscribe = $.nginx_subscribe(
			dashboardURL,
			function success(textResp) {
				// the script calls success function direct
			},
			function failure(resp) {
				if (window.console) {
					console.log('subscribe failure');
				}
			}
		);
	});
	var addCommentary = function(jsonStr) {
		alert(jsonObj);
	}
	var addTelemetry = function(jsonObj) {
		alert(jsonObj);
	}
	var jsonCallback = function(jsonStr) {
		try {
			var respJson = jQuery.evalJSON(jsonStr);
			if (respJson.commentary && respJson.commentary.length) addCommentary(respJson.commentary);
			if (respJson.drivers) addTelemetry(respJson.drivers);
		} catch (e) {
			if (window.console) {
				console.log(e);
			}
		}
	}
	return {jsonCallback:jsonCallback};
}

Obviously this script isn’t great because it will either alert you several times a second if a race is on, or not respond at all. You’ll need to set up an nginx feed server yourself (as described in Part 2), and start POSTing to it, before you see any responses out of race time, and you’ll want to replace the alerts with something more useful.

I like to use the Net view of Firebug to watch the network traffic.

Cool uses of the data

From the very first race, our telemetry feed has been analysed by the clever mashup coders out there. One of my favourites is OUseful.info.

This map shows the points in Bahrain where Hamilton hit 100% throttle!

And this beautiful layout shows which gear he was in as he did it.

It’s a great little site, and I’m looking forward to see more insights into the data coming out. But it would be nice to see some copyright mentions shown for the data, as well as for the map itself.

In the next part in the series, I’ll have a look at Load Testing.

I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

Part two covers the telemetry panel, known as “The Race 1.0b”. Technically, I think this is the most interesting section of the site.

Choosing a solution

Before I started in this job, I spent a week scouting around for technologies and platforms to support what we need.

We need to distribute our data feed, on a second-by-second basis to thousands of viewers. Although we weren’t sure exactly how many visitors we’d need to support, there’s a chance we’d get a mention on television, so we should be expecting visitors in the tens of thousands. Obviously we’d need to keep the latency down too – there’s no point broadcasting stats that appear with a significant delay over the television signal. This would very much be a companion to the television programme.

The most sensible way to receive a live feed is using Comet. This is similar to the familiar Ajax, with one big difference. When you request a data packet with Ajax, it will return as soon as it can. It might say “here’s data”, or it might say “I have no data yet”. The second of these cases is useless – you’d have to go and ask again. The process of continually requesting data on a timed basis is known as polling. It puts a big load on the server, which needs to waste execution time dealing with “I have no data” requests.

Comet is different, because it will not receive a “I have no data” response. It doesn’t get a response at all in this case. It just sits and waits, and only gets a response when data comes through. This action is called a “push”, because the server triggers an action at the client, which is an unusual operation. This is Comet’s key difference.

Comet has two flavours. If the response terminates the connection when data comes through, then it will need to request the next packet straight away. This, then, is known as “long-polling” Comet. It has the familiar polling action that we had with Ajax, but far lower latency, because the packet comes through as soon as it’s available. There is no chance of a 1 second delay. The other flavour of Comet is “streaming”, because it drip-feeds the data into the connection. The new HTML5 web sockets would probably fall under this heading, though I believe they use TCP direct, instead of needing to deal with HTTP. I would love to have streamed the data, but reading about it online showed that I would have numerous problems, with proxies and hubs that would wait for packets to complete before passing on results. Essentially, streaming is not thought to be ready for production yet.

I chose long-polling Comet for McLaren, and that simply left the question of implementation.

Long-polling Comet: software

If you’re dealing with a server under high load, you’re bombarded with thousands of requests a second. It was clear that I’d need the lightest possible solution to the problem. A web server which can handle the C10k problem, and hopefully do significantly better than that. Apache uses one thread per request, so in anyone’s book, won’t be able to handle this kind of load.

The nginx (engine-x) webserver is an ideal choice for performance. Webfaction have some oft-quoted stats on it’s performance, and it can even show improvement when proxying to Apache. Last year I’d read on Simon Willison’s blog that nginx has a push module.

The nginx http push module (nhpm) is a publisher/subscriber module for nginx. It serves as a hub which can receive POST requests, and then distribute them to a large number of subscribers waiting on GET requests. Naturally, the POSTs can be filtered by IP. The logical demo for any Comet demo is a chatroom, which is duly presented on the site. What I needed was something far more basic, because everyone receives the same data, but it would do.

Another option was to use node.js, which has apparently now been used to support a million comet user for Plurk. Despite performing reasonably well in tests, I decided against node because I didn’t have the time to build and test a webserver myself before launch. I tend to think there’s more at work in a robust webserver than first appears. Nginx is mature, and the push module is several iterations in.

Let’s just go ahead and install nginx on our linux variant. This will install on a Mac natively, but if you want to do do the later performance testing chapters, I recommend getting another linux box going. You can set one up with Amazon cheaply, or with Rackspacecloud if you find all that certificate stuff confusing.

Installing nginx with the push module:
If you’re not connecting as root, switch to a root shell

  sudo bash

Download and untar nginx and the nginx push module

  curl -O http://www.nginx.org/download/nginx-0.7.65.tar.gz
  curl -O http://pushmodule.slact.net/downloads/nginx_http_push_module-0.692.tar.gz
  tar -xzvf nginx-0.7.65.tar.gz
  tar -xvzf nginx_http_push_module-0.692.tar.gz

nginx requires PCRE (regular expressions library) and open-ssl

  curl -L -O http://downloads.sourceforge.net/pcre/pcre-8.01.tar.gz
  tar -xzf pcre-8.01.tar.gz
  apt-get install libssl-dev  #ubuntu
  yum install openssl-devel  #redhat/fedora

Now we compile and install nginx

  cd nginx-0.7.65
  ./configure --add-module=../nginx_http_push_module-0.692 --with-http_flv_module --user=apache --group=apache --with-http_gzip_static_module --with-pcre=../pcre-8.01
  make && make install

Now nginx is installed, we can pop off and edit the nginx.conf file.

  vi /usr/local/nginx/conf/nginx.conf

The nginx config file is a thing of beauty. If you’re used to Apache configs, this will be like upgrading from PC to Mac. Difficult to switch but well worth the effort.

For now, just grab my simple version of the nginx conf.

If you haven’t got a user already, let’s create one, somewhat confusingly named “apache”, though you can choose your own name if you want.

  groupadd apache
  useradd -c "Apache Server" -d /dev/null -g apache -s /bin/false apache

And start the server:

  /usr/local/nginx/sbin/nginx

(you can stop with):

  /usr/local/nginx/sbin/nginx -s stop

Remember it’s listening on Port80, so make sure it’s not conflicting with Skype or Apache.

Nginx is now listening on port 80.
If you send a POST to /feed/publish it will get broadcast out to anyone hanging on /feed/subscribe
Let’s test it in a browser.
Open http://localhost/feed/subscribe
It will hang on and wait.

Now create a small HTML page that POSTs to /feed/publish

<form action="http://127.0.0.1/feed/publish" method="POST">
  <textarea name="body" value="content"/>
  <input type="submit"/>
</form>

Hit Submit, and … nothing will happen.

Closer inspection with FireBug shows that you’ve made an OPTIONS request instead of a POST.
This is a limit on cross-domain posting in browsers.

Fortunately, I allowed for this in the conf file. Move your HTML file to /usr/local/nginx/html/test.html
You can now view it on your local server as http://localhost/test.html
Hit Submit, and your GET thread that was hanging on, will now instantly respond with a packet of data for you to download.

We have a pub/sub hub running!

Another option is to POST using PHP or similar scripting language, which doesn’t have the browser cross-domain scripting security block.

You will want to lock down your POST url, because you don’t want everyone being able to broadcast to your users!
Simply change this bit of the conf file:

	location /feed/publish {
		allow 127.0.0.1;  # deny public posting - only allow from this IP
		deny all;
		...
	}

All nginx http push module needs is a little memory to work. It barely scratches the CPU at all. Let me show you the CPU usage graph from the first race using the telemetry.

Long-polling Comet: system

When configuring a Comet server for performance, everyone turns first to Richard Jones’s awesome posts, A Million-user Comet Application with Mochiweb. I followed his advice on server configuration.

Specifically, I do the following:

ulimit -n 999999 # increase the number of available file handles
echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range # add more ephemeral ports

Of course, your ulimit change won’t persist, so you need to edit the limits conf:

vi /etc/security/limits.conf

Insert these lines in the document somewhere:

*      hard nofile 999999
*      hard nproc 999999
*      soft nofile 999999
*      soft nproc 999999

(ensure there’s no spaces before the asterisks).

Long-polling Comet: hardware

We had three heavy boxes set up to run the site. However, we were very keen to keep the site running regardless of visitors accessing our data feed. If anything, we’d rather lose the telemetry than the site itself, so it didn’t make sense to mix hardware between the two functions.

Two boxes were kept to run the site then, under a load balancer. The third box was moved out, and runs the feed server alone.

Next problem was the firewall. Our firewall is hardware limited to 10,000 concurrent users, great for a standard site running simple subsecond requests, but utterly useless for any kind of Comet connection. For another 300UKP the firewall could go to 5,000 more concurrents, but was still a huge limiting factor. So we juggled it to get the best connection possible for the feed server.

Since we’re running one box, we could also move out from behind the load balancer. We now can’t run on the same domain, so created a new subdomain for the server.

Heading back to original calculations, we then looked at the next perceived limit: bandwidth.

If our packet size is, for example, 1 kilobyte, including any http header.
Assuming 1 packet is delivered per second.
And our network card is 100Mbps (mega bit per second), which works out as 10MBps (mega byte per second).
How many users can we support?

Simple maths, 10,000MBps / 1k = 10,000 requests per second.

So, we can’t move beyond 10,000 concurrent users anyway, simply because the bandwidth is a limiting factor, even with our small packets.

So we now have a Gigabit card, and Gigabit switch. I’ve tested that up to 333Mbps, which is enough for at least 30,000 concurrents. Any more and we’ll need cloud servers to support the load (hopefully detailed in a later part).

Possible Alternatives

Having thought about all this, the system could be replaced with a simple memory lookup. The telemetry details could be stored in an array that is constantly overwritten, and the commentary stored in a queue in a way that you could ensure each requestor reliably received them all. I had a quick peek at using the nginx memcached plugin, which would let me serve values straight from memcached. It definitely had an appeal, though obviously performance wouldn’t get any better – since our limiting factor is the hardware supplying the bandwidth.

Next Part, I’ll look at the Feed itself, and how it’s processed on the front-end.

I’ll be writing up what we’ve done here in several parts. Sign up for my RSS feed to keep updated.

First up, the HTML. The site design is brilliantly engineered for layout on the web. It’s clean, fresh and bold. No rounded corners or “web 2.0″ gradients. All credit to our designer, creative director and our client.

You might think this would be a breeze to implement, but actually it threw up several significant issues, which have been tricky. Here’s a few interesting ones:

Dymo labels

The design for the majority of text areas has a strip of colour behind each row of text. I call this the “Dymo label” effect, because it looks like strips of dymo tape.

To get this effect, one cannot assign a background colour to the block-level container, as this will just appear as a solid rectangular block. One needs an inline display element, so let’s use a span. We add a background color to this span, and add padding above and below the text for a bit of coloured space. The gaps between the lines are generated with the ‘line-height’ style. So our text size plus padding is 30px high, and our line-height is 36px, giving us a 6px gap.

Neat – our dymo-style strips are now placed. Only problem is that the text lines butt up hard against the white surrounds:

We want to add some padding to the start and ends of the lines, as shown here:

I tried a variety of options. Margins are useless, because they don’t apply to inline elements. Left and right padding works only on the beginning and end of the span, and so the sentence. Word spacing is only supported in a few browsers, and also increases gaps between words.

In fact, there is no way to control padding at wrapped line ends.

Asking on the CSS discussion groups pointed me to this item in the spec: ‘box-decoration-break‘. This obscurely named property would enable me to treat each line as a box, enabling me to add padding to the start and end of each line. I find the explanation completely confusing, since it mostly concerns itself with page breaks. It’s also unclear whether this fix will solve my inline blocks problem.

Of course, the biggest problem with this idea is that it’s so complex and unasked-for, that it hasn’t been implemented by any browser vendors, and as such, may drop out of the specification.

The following features are at-risk and may be dropped at the end of the CR period if there has not been enough interest from implementers: ‘box-decoration-break’.

And yet, since this is specified, there is resistance to the idea of implementing this (clearly useful) feature in any other way. Personally, I would like to see a ‘wrapped-line-padding’ property.

Another suggestion was to use a striped background-image property, with scaling. I imagine that would work, but present the same problems. If applied at the block-level, the last line would run to the end of the box. If applied inline, there would be no padding.

So, what have I done? I have implemented a fix in JS of course, and look forward to your inevitable criticism.

$(document).ready(function() {
	if(!$.browser.msie || $.browser.version>7) $('span').not('.no-jswrap').each(function() {
		var text = $(this).html();
		var outstr = text.replace(/([^ ]+)/g, '<b>$1</b>');
		outstr = outstr.replace(/ /g, '');
		$(this).html(outstr);
		$(this).addClass('jswrap');
	});
});

After document ready, each word is wrapped with deprecated, but still valid, <b> tags. I then remove the spaces between the words.
The <b> tags have padding of their own.

The downsides to this approach are of course, extra JS (though it’s only a cosmetic enhancement, so I’m not fussed if you’re running without JS. And the bigger issue – the lack of spaces. If you cut and paste text from the site (notice the pretty selection styles when you do), then your text pastes without spaces. I can only apologise, and hope that it doesn’t ruin your screenreader.

Jenson-Champion’smoment 2009BrazilianGrandPrix- AdelugeonSaturdayafternoonleftJensonpowerlesstoovercomehiscar’sgripproblems,andhequalifiedadisappointing14th.OnSunday,however,hedrovewithflairandmercilessaggressiontosweepthroughtofifth–itwasnocoincidencethatoneofhisgreatestdrivesfinallyelevatedhimtothestatusofworldchampion.

But it does give us our line padding.

Hiding Navigation

The navigation at the top of the page hides itself away after an amount of time. It won’t win any usability awards of course, but might garner ourselves the odd design award (who never like sites to be too easy). Regardless, it’s got to be hidden away.

This was a simple effect to add. I simply used jQuery to hide the navigation element after 3 seconds of the page loading, revealing if the user rolls their mouse over it. After implementing it locally, I found an immediate issue. When clicking to a new page, it was easy to leave the mouse over the navigation, which wouldn’t trigger a mouse enter event, especially if focus was on another window or tab. Basically, it produced a lot of circumstances where the navigation was hiding, regardless of the mouse being over the nav. Not good.

I have now moved the event, so the trigger for the timer would only start after the user rolls over the content on the page. This works a lot better, though it’s a little confusing because the navigation appears or disappears seemingly at random. But it’s effective, and it works.

The next problem was based on scrolling. If you scroll to the bottom of a page, then use jQuery to slowly hide an element higher up the page, the document gets shorter. Browsers do not handle this smoothly (even Chrome). The screen flickers and jumps all over the place, and is likely to induce seizure even in the most hardened fans of strobe lighting.

I solved the scroll problem by hiding the navigation immediately after a page scroll. So, on any scroll event, the nav disappears, fast. No more flicker, no more problems.

	/*
	 * Expand and contract the navigation
	 */
	var navHider = function() {
		// show the nav when you roll over the top
		var showNav = function() {
			clearTimeout(navHideTimer);
			$('#navigation-wrapper').slideDown("slow");
		};
		// hide the header 1 sec after you roll over the content
		var hideNav = function() {
			clearTimeout(navHideTimer);
			navHideTimer = setTimeout(navHiderAction, 1000);
		};
		$('#header').mouseenter(showNav);
		$('#header a').focus(showNav);
		$('#header a').blur(hideNav);
		$('#content').mouseover(hideNav);

		// the hiding function
		var navHiderAction = function() {
			if (hiderEnabled) $('#navigation-wrapper').slideUp("slow");
		}
		// if the window is scrolled, hide it quickly to avoid jerky/flickering effects
		$(window).scroll(function() {
			clearTimeout(navHideTimer);
			if (hiderEnabled) $('#navigation-wrapper').slideUp(100);
		});
		var navHideTimer = 0;
	};

Of course, you’re probably still thinking of the usability issues. Certainly, we initially saw a large number of visitors to our footer links (like the copyright page) when we launched, but this has flattened off. Our visitors have found the navigation, they know how to bring it back, and we’ve had several compliments from the online design community. I think we’ve brought our visitors with us on this one, and it’s probably acceptable now.

Shadowbox URLs

We use the cool ShadowBox plugin for our lightbox effect. But of course, the articles shouldn’t show navigation in the lightbox, so they have to know when they’re in the lightbox and when they’re not. I want to keep the link the same, so non-JS users can use the article links as they stand.

Simple fix to the init for ShadowBox gives the solution:

	Shadowbox.init({
		players:['iframe','img','swf','html'],
		onOpen:function(e) {
			// let the page know that it shouldn't show headers
			if (Shadowbox.gallery[0].player=='iframe' && !Shadowbox.gallery[0].content.match('iframe=true')) Shadowbox.gallery[0].content = e.content = e.content+'?iframe=true';
		},
		onClose:function(e) {
			// reload the CSS in IE8 to avoid sporadic font-face corruption
			$('#main-css').each(function() {
				this.href = this.href.split('#')[0];
			});
		}
	});

This tells ShadowBox to append the ‘?iframe=true’ querystring to links as they are opened. Note that I’ve also added a font-face fix for IE8 to the onClose function – for this to work, you’ll need to put an ID on your main stylesheet of ‘main-css’.

That’s it for the HTML. In the next part, I’ll look at the telemetry feed.

• EC2 – Elastic Compute Cloud – Application servers
• S3 – Storage – also known as EBS (elastic block store) – Disc blocks that can either be served directly, or attached to an EC2 server.
• CloudWatch – monitoring for EC2 servers (CPU, network, disc IO)
• CloudFront – a CDN (notice how confusing the name is)
• Elastic Load Balancing – yeah yeah yeah
• Elastic MapReduce – for proper techies

All of these services are charged per use, so by hour, by gigabyte (memory), by gigabyte (bandwidth), by gigabyte (disc), etc.
It is well worth keeping an eye on costs, as it’s easy to run up a big bill without realizing.
One of the great features is that there are no setup fees, so it’s very easy to create and destroy servers without running up large bills.
If something isn’t working, simply start again.

EC2

Application servers can be created using one command or a few clicks. A server is called an “instance”, and is created from an image called an “AMI”.
Amazon provide a set of AMIs to build from. So does ‘alestic.com‘, who provide good ubuntu images.
They can be created in a variety of sizes, varying in memory, CPU and disc space.
These servers can also be quickly “terminated”. This means that they’re deleted from the ether and can never be retrieved.
A server is charged from creation to termination.

S3/EBS

Since application servers can be so easily created and destroyed, one needs a location where data is stored persistently.
EBS blocks can be created and mounted onto EC2 instances. An EBS store can only attach to one EC2 at a time, but an EC2 instance can have many EBS stores.
If running a persistent (long-running) application server, you should mount an EBS store and link it symbolically to the EC2 instance. You then put all your files directly into EBS. Should you need to upgrade your application server, you simply attach the EBS to a new instance and destroy the old one.
Larger servers are already based on EBS stores.

I’m not going to go into EBS stores in this post. I’ll focus on EC2.

If you haven’t used Amazon AWS before, I strongly recommend following this guide with your own Amazon account.
It will cost around a dollar.

Working with EC2 – Setup

Getting started with Amazon Web Services is the trickiest bit, and can often be off-putting.
Once you’re set up then it’s much easier. So hang in there.

Simple steps:

1. Get an Amazon account
2. Get your keys
3. Create an instance
4. Get connected
5. Get serving

Get an Amazon Account

Head here and hit the signup button.

http://aws.amazon.com/ec2/

You can use your existing Amazon account.
You are agreeing to be billed monthly for any costs you incur, so you won’t get any more warnings!

Get your keys

You should be directed to security where you’ll be asked to download an X.509 key. Do that, and put it somewhere (very) safe.
This is needed when you use command-line-tools (later steps).

On that same screen, you can create a “Key Pair”. Do that, and download the two files it gives you. This should be a PEM file and a CERT file.
Again, keep them safe. The PEM file is the one we’ll use.

Rather than using passwords for SSH (SO last century), Amazon require you to use these files to authenticate yourself when connecting.

I’m on a Mac, so I copy the PEM file to a ”.ssh” folder in my user folder.
You need to chmod 400 the file to prevent a connection error.
Let’s say I created a keypair called ”kennethkey”, I can now do this.

cd ~/.ssh
chmod 400 kennethkey.pem
ssh-add kennethkey.pem

This will add the key for the duration of my Terminal session.

Create an instance

Now you’re set up, head back to the browser and find your way to the AWS Management Console.

https://console.aws.amazon.com/ec2/home?region=eu-west-1

This is where you can do most of your work with Amazon.
This console is new, so many documents you find online don’t describe working with it.
Don’t worry about that.

What can we see?
Tabs on the top – we only need “Amazon EC2”
Top nav – to Products for details of pricing (can be useful), and to Account for details of costs to date (can be scary).
Stick with the console for now.
On the left is the nav. Choose “EU West” as your region unless you’re doing something US-centric. Do that now.
Have a quick look through the other links on the left.

• Instances – we can create servers in here
• Volumes – create EBS blocks here
• Elastic IPs – here you can assign fixed IPs
• Security Groups – here you manage the “firewall”, opening ports as required.
• Key Pairs – manage those keys here (unlikely to be needed)

The others you can investigate yourself. Beware of Snapshots, which are a way to store incremental backups, but tend to be more complicated than expected.

Let’s start with an Instance.
Go to the Instances view, and click “Launch Instance”.
You now choose an image (AMI).
Just pick the “Basic 64-bit Fedora Core 8”, which is a 64-bit machine (meaning we can get larger varieties), and is a linux variant.

In the next page you can choose the “Type”. This is the size for the instance, and this affects the pricing. The pricing is annoyingly not displayed here though.
For this case, we chose a beefy c1.xlarge, which is 96cents an hour.

Choose defaults for the rest of that page.
On the next screen you can enable cloudwatch, which is about 15cents an hour extra. Leave the rest as defaults.
On the next screen choose the keypair you created earlier.

Finally, Choose a security group. Let’s just choose the default (don’t create a new one).
If you’re working on real projects, you can create and name security groups, which helps you see which servers are doing what in the console later on. I find this easier than trying to memorize the code names for each machine.

Continue and Launch.
You’ll see your instance appear in the list as “pending”.
After about 30 seconds, it will be “running”.
You are now being charged.

Get connected

We connected our new instance to the Security Group called “default”.
Before we access that instance, we need to open the ports.
In the Console, head to “Security Groups”.

Click “default” and in the bottom panel create lines for HTTP (just choose HTTP in the dropdown and click save)
And SSH (again, choose SSH in the dropdown and save)
We can now connect via SSH.

Head back to the Instances window.
Click our instance, which is now “running”.
In the bottom window you can see various details.
“Public DNS” is the name of the machine for the outside world. It’ll be something like this: ec2-12-345-67-89.eu-west-1.compute.amazonaws.com
Right click the instance and choose “Connect”.
A window appears giving you instructions for connection.

On my Mac I just open a Terminal window.
Because I used ”ssh-add” earlier, I don’t need the -i <keypair> option.
But if I didn’t use ssh-add, I would cd to the directory where I stored the PEM key first.
Once you’ve entered the command, you should get straight into the machine as root!
We’re connected!

Get Serving

Some AMIs have LAMP already installed. We chose a vanilla AMI, so we have nothing but the OS.
For the purposes of this demo, let’s install Apache.

yum install httpd

And start it:

/etc/init.d/httpd start

Now we can go to the website:
http://ec2-12-345-67-89.eu-west-1.compute.amazonaws.com/

We should see the Fedora Test Page!

Install the command line tools

Amazon provide a whole set of command line tools to help you work with instances. These are always added first for any new feature, so they offer more options than are available through the console, for example to use the RDS features.

Get the Developer Tools here

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=351&categoryID=88

Put them somewhere permanent on your system

Follow the instructions for setup here:

http://docs.amazonwebservices.com/AWSEC2/2009-11-30/UserGuide/index.html?setting-up-your-tools.html

It’s long and complicated, but IMHO that’s because it’s built in (ptui) Java.

Specifics for Mac

mkdir ~/Documents/ec2-tools
mv /Users/kenneth/Downloads/ec2-api-tools-1.3-46266 ~/Documents/ec2-tools
mkdir ~/.ec2
mv /Users/kenneth/Downloads/X.509keys/* ~/.ec2

Add the following to ~/.profile

#Amazon EC2 Command line tools
export EC2_HOME=~/Documents/ec2-tools
export PATH=$PATH:$EC2_HOME/bin
export EC2_CERT=~/.ec2/cert-#######.pem   (match your key names)
export EC2_PRIVATE_KEY=~/.ec2/pk-########.pem
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
export EC2_URL=https://ec2.eu-west-1.amazonaws.com

Then run this command:

source ~/.profile

(This just runs the stuff in the .profile)

Check that it’s all peachy with this command:

ec2-describe-regions

You can now create instances on the command line.
A word of warning: Internal bandwidth costs are not charged (eg, between two instances, or between your instance and your RDS), but if your machines are in different physical regions, the bandwidth is treated as external. I ran up bandwidth charges of a terabyte in my first week, which proved hugely costly. Be sure to check your regions.

We can view our servers like so:

ec2-describe-instances

Or even create a new one like this:

ec2-run-instances -n 1 --key kennethkey ami-bdc0ebc9 -t c1.xlarge

Rip it down

Ok, we’ve had some fun, and incurred about a dollar in fees.
Let’s ditch our server.
Head back to the console, and right-click the instance(s).
Choose “terminate”.
Our server will be destroyed and we’ll stop being charged.
Our SSH session will be kicked off.

The script requires you to set a variable in your jsonp response. The script checks whether that variable is true after the jsonp loads. If true, your json has loaded. If not, something has gone wrong.

So, if your jsonp looks like this:
callback({blah:”blah”});
You’ll need to revise it to this:
callback({blah:”blah”});ScriptCommunicator.callback_called = true;

On the jQuery forums, John Resig said he isn’t enamoured with this approach since it means adapting the jsonp response, and if you’re using jsonp then you’re probably not in control of the feed. It’s a fair point, but you could simply add the callback_called variable into the callback function instead.

Plus, if you’re running Comet long-polling, it’s better to use a different domain for your comet feed, to prevent tying up threads in the browser. So jsonp is needed.

The “difficult” part of the process is knowing when to run the second script, that checks the callback_called value. Amix uses a variety of methods for different browsers to achieve this.

In Firefox (default case) -> create two script tags using document.createElement, and attach them to the body.

In IE -> use the onreadystatechange event to call onSuccess, and then detect errors there, based on the readyState (somewhat illogical).

In Safari/Chrome -> write two script tags out with document.writeln. Presumably, this is intended for use with an iframe, though that’s not clear. OOTB, no webkit browsers receive data.

Having tried to hack the script to make the Safari browsers use the same method as Firefox, I’ve found that Safari’s caching kicked in and failed to load new scripts from the server (though this could be my fault for not changing the script name each time).

Looking back at Plurk, the comet scripts are indeed in an iframe, so I think this script probably needs some more input before it’s going to work for anyone else. Hopefully, Amix (or someone) will put together a demo page and make any necessary fixes to the script when making that work.

It’s a very useful function/tool/script. Thanks Amix.

I’d just like to mention Typekit because it’s not what I thought it was, and I’m quite impressed with what it is.

I’d assumed Typekit was a solution to the technological problem of including new fonts on webpages.  Along similar lines to Cufon and sIFR.

For those who don’t know, including fonts is a problem because modern browsers haven’t agreed on a way to distribute fonts with web pages.  IE, oddly, had this solved ages ago, but since MS is so unfashionable at present, it has been largely ignored.

Cufon lets you use a new font by replacing text with little <canvas> image elements.  Ingenious, but quite silly as you have to create loads of these little elements on the fly.  SIFR does the same thing, but using Flash.  Indeed, we once used sIFR for the Cannes Film Festival website.  I remember a very long page-render time…

I’d assumed Typekit was going to be similar. Basically, I’m wrong.

Typekit is a solution for font licensing. It’s always been a pain to get the right licenses for fonts. Often the licenses you buy are both extortionately priced and not licensed to web distribution. (This is because the way you provide a font to a web page is easily hijacked, and the font can be stolen).

Typekit provides access to their sensibly-sized library of fonts on a variety of subscription schemes. Once signed up, including the fonts is a simple matter of a few lines of JavaScript.

Technically, Typekit uses the @font-face download rules. This means it supports a limited number of browsers. But it also supports IE, using the EOT font format (IE’s system attempts to prevent hijacking of fonts too). So it’s not bad.

Downsides are that the iPhone is not supported, as mobile Safari doesn’t seem to support @font-face. Of course, the non-JavaScript browsers out there don’t see the new fonts (but they’ve asked for a lesser experience, so who cares). Also, there can be a FOUC (Flash of Unstyled Content) as the page loads the first time.

Once request I’d make to the Typekit team is the ability to support two sites on the Tester pack. One for my simple blog, one for active development. I know you want me to pay, but my commitment to fonts for personal use is not so great, and since you add your logo, it’s only an advert for yourselves anyway isn’t it.

In summary, I think it’s a great idea. I see Typekit as the Spotify of fonts.

Here, I’ve worked on websites for Hewlett Packard, the Cannes Film Festival, Persil, Nicquitin, General Motors, Opel, Vauxhall, Sega‘s TotalWar, Nakheel and the Palm Jumeirah, Bayer‘s Xarelto, MSD’s Propecia, Procter & Gamble, Eukanuba, Digitas of course, and a few sites so cool, I still can’t tell you about them.
That’s not a bad record.
Estimates suggest that on average*, I have been involved with more than seventeen percent of your household purchases , and although I have a three-percent chance of killing you with a car, there’s an extra four percent chance of saving your life after an operation.

Somehow I’ve been sent to Brussels, Warsaw, Geneva, Minsk, Basle, Kiev, Zurich, Paris and Bangalore.

Ninety-two of my facebook friends, I met through Digitas. That’s sixty-one percent.

Since I joined Digitas, I’ve started and finished a three-year degree in Physical Science, with a two:one. I’ve got married, and twenty-five percent of my guests were from Digitas. I’ve run twenty-six point one miles in the London marathon, and they helped me raise three-hundred pounds for the NSPCC.

I loved working here.
I wish them all a great 2010.

Kenneth

* some estimates may be approximate to the point of complete fiction.