NWRUG February 2009 – Nanite talk

For the first time in quite a while we had a talk at NWRUG, it seemed to go well and the free Pizzas and Beer provided by Engine Yard were very popular. About 12 people turned up. I was the only speaker and did a 45 minute talk on Nanite with a brief introduction to cloud-computing as that’s the environment I see Nanite being most useful.

Thanks to everyone who turned up and Engine Yard for the sponsorship. I promised a blog post with links to some of the resources from the talk, and here it is!

Useful links from the talk

Nanite (of course)

Kestrel (a starling replacement)

Delayed Job

Warren (A wrapper around AMQP from brightbox)

Engine Yard Solo

As I mentioned in the talk you can probably get away with using third-party APIs and calling it ‘cloud-computing’, this set of slides is really interesting:

Web Hooks and the Programmable World of Tomorrow

Lastly the slides on SlideShare, though they don’t make as much sense as they do with the talk & my notes.

*update*

Pastie: control rabbitMQ using Nanite, controlling god using Nanite.

Next Month

More talks! Asa Calow has agreed to do a talk on Solr and I rather foolishley agreed to do another talk on Sphinx.

I certainly won’t be missing 1234567890, and you don’t have to either!

The point at which time since the epoch reaches 1234567890 is momentous historical occasion happening today and I don’t want to let it slip past unnoticed, and now you don’t have to either! Just run:

watch -n1 echo 'Time since epoch: `date +"%s"`s'

in a terminal and bathe in the magnitude of the moment. It should work on Linux and Mac, Windows users will have to have a little cry instead or something.

Babelfish translation FAIL

It apparently means self employed.

My First Rails Plugin – asset-format

For the first time ever today I wrote a rails plugin! I googled around first to make sure no-one had solved the particular problem I needed fixing but no-one seemed to have done, so I had no choice but to jump into the rails core…

The problem

In RubyonRails using the asset link tag such as:

<%= stylesheet_link_tag "screen", :media=>"screen, projection" %>

results in something like this on your HTML:

<link href="/stylesheets/screen.css?1234174480" media="screen, projection" rel="stylesheet" type="text/css" />

(view source on the Recycling Group Finder for the original). The number after the question mark (‘?1234174480′) is the asset ID. The idea behind the asset ID is that you can configure your web-server to set an Expires headers for your static assets far into the future causing browsers to cache the asset, but by changing the number (Rails does this automatically) you indicate to the browser that a file has changed and that the browser should re-fetch it. It works most of the time, but there are some mis-configured proxies out there (and possibly browsers too) that will cache the asset even when the asset id changes.

There’s a good description of the problem over on the sproutcore blog.

The Solution

This is where my plugin comes in, altering the asset URL with the asset ID in the URL, eg:

/stylesheets/screen.css?1234174480

becomes:

/stylesheets/1234174480/screen.css

Placing the asset ID in the URL, not the query causes proxies and browsers to see a different asset and so to fetch what it sees as a completely new asset. It will then cache the asset and if you change the asset ID the same thing will happen, no more over-cached assets!

Installing it

Easy, just:

$ cd rails_project_base_dir && script/plugin install git://github.com/wjessop/asset-format.git

start up your app and your asset URLs will be magically transformed! You will need a rewrite in your web-server config to rewrite the request back to the asset, so:

/stylesheets/1234174480/screen.css -> /stylesheets/screen.css

an you are all set!

Whoooooosh – the Recycling Group Finder gets faster

This afternoon I implemented a CDN (Content Distribution Network)  for the Recycling Group Finder, it only took about an hour and has slashed page load times on the site.

Whilst working for Engine Yard today (yes, on a Saturday!) we got a ticket in asking for CDN recommendations. This got me thinking about the recently announced Amazon Cloudfront CDN, specifically how cool it would be to use it for the Recycling Group Finder (a personal project). It’s an internationally targeted site and would benefit from the faster page load times a CDN will bring.

Why Cloudfront?

Cloudfront is built on Amazon S3, a well-used and trusted technology and many of Engine Yard’s customers are already using it. The chances are if you’re already using S3 for storing assets Cloudfront will be dead-simple to get running. I wasn’t, though it didn’t take much extra effort.

It’s easy…

Really easy. There’s a really useful tutorial up that gets you most of the way there, the Firefox S3 plugin is amazing. All that was needed after that was a single line change to my environment.rb file in my RubyonRails project:

and my javascript and CSS files were being served super-fast from the Cloudfront CDN. Sweet! It took a bit more work (and a custom helper) to get some of the other assets served, but not much.

Very. Very. Fast.

The speedup is significant. The site seems snappier when visiting in a browser but I also ran some before and after speed tests using the Pingdom tools page. The results were impressive. The homepage went from a 16.1 second load time (including all assets) to 1.1 seconds:

Before (16.1 seconds):

After (1.1 seconds):

The homepage saw the most impressive speed boost, but sub-page load times improved significantly too. This is the before and after tests for the San Francisco Freecycle page:

Before (5.6 seconds):

After (1.6 seconds):

Worth the effort

Hell yeah! It took a really short amount of time to get running (helped by RubyonRails built in support for asset hosts) and the site flies. Give it a go!