I’m going to show code which I wrote specifically to use with AppHarbor, but you may find that you can use the same techniques in different environments.

Cache-busting Technique: Versioned Path

The most reliable method of cache busting is to put some version identifier in the path to the static content such as:

http://localhost/statics/12345678/css/style.css

Where 12345678 is the version identifier. This method even works with CDNs which might otherwise ignore lesser important path tokens like querystring parameters or an identifier after a hash mark.

In the code below, I’ll show a solution which includes the version identifier in the path to the static content Version identifier changes whenever a build is released to AppHarbor.

How It Works

A browser makes a request to your server for your homepage. The server delivers the homepage and references to static resources using the versioned path.

The browser requests those static resources from your server. The server finds the resources requested, adds headers,

Cache-Control: public
Expires:Fri, 15 Feb 2013 02:45:01 GMT // a year from now

and serves them.

The browser keeps the resources in its cache for a long time and future requests for them are served from cache.

You ship new code to AppHarbor. AppHarbor builds and deploys your application. It also adds a configuration setting into your web.config with a key of appharbor.commit_id and the value is set to the last changeset ID. Your server uses that changeset ID as the  version identifier in static resource paths.

The browser makes a request for your homepage again. The server delivers the homepage, but this time references the static resources using the new version identifier.

The browser now must request those static resources again because the version identifier has changed. The server serves up the updated files back to the browser where they’re cached again.

Caveat: browsers will have to request all static resources again every time a build is deployed. I’m very happy to accept this. Alternatively, you could do crazy things like get a hash of the file and serve that as part of the file’s path. See Karl Seguin’s article about cache busting if you’re interested in that sort of thing.

How To Do This In Code

First, you’ll need to be able to provide static resource urls. I like to write them like this:

Which means I’ll need an extension method on the UrlHelper:

In the StaticContent method, I’m populating the staticResourceVersion variable from a configuration value which is in my web.config. If one is not set, like when you’re running your site locally, “_default” is provided.

Another thing to note is that if the staticServer variable is populated, then it’ll be prepended to the returned url. This supports serving static content from a cookie-less domain.

Now that static content can be referenced, we need to have a route and a controller to handle requests for static content.

The first and third routes are the default ones that come with MVC. The middle route understands how to handle requests which start with s/ followed by the version identifier and then whatever the path to the resource is. It directs those requests to the StaticsController’s Index action.

The StaticController’s Index action first needs to check if the requested path is allowed. We certainly wouldn’t want to serve just any content back through here. (I’m showing a really simple IsAllowed implementation, please feel free to be smarter about yours.)

For my own sanity, when I’m deving on my localbox, I don’t ever want content cached. So the caching headers are only set when the request is not local.

And finally, the file is served up with the correct content type. (Again, simple implementation, feel free to be smarter.)

The staticResourceVersion variable is ignored; I haven’t thought of anything to do with it yet.

And the hard work is done! Update your static resource urls to use the Url.StaticContent helper, deploy out to AppHarbor, and bask in the the glory of long-cache-expiration-headered static content.

The End

Special thanks to my fellow devs at Cheezburger for teaching me this technique.

Thanks to Michael Friis for telling me that AppHarbor inserts the commit_id into a deployed web.config.

• jQuery 1.7.1
• jQuery UI 1.8.16
• Twitter’s Bootstrap 1.4.0
• Windows 7 / Chrome 16.0.912.63

See how the button starts dragging from the top left corner and drags really slowly? I stripped down the CSS element by element using Chrome’s dev tools and was able to isolate the problem to the -webkit-transition and box-shadow styles on the .btn class. Setting those to none fixed the problem.

Click the delete button below to see it in action. Click the JavaScript tab below to see how it works.

This was built for use with the amazing Bootstrap CSS framework. Only the classes that are added/removed are dependent on Bootstrap, so adjust to your needs.

I’ve also been bitten by the QUnit bug so before I enable CoffeeScript on Cheezburger.com, I want to make sure that I can unit test whatever CoffeeScript we write. A quick Google search yielded next to nothing about testing CoffeeScript but I was feeling inventive and came up with the following way to use QUnit with CoffeeScript.

Important Gotcha

Since we’re going to load .coffee scripts via jQuery.get(), they must be served by a web server. They will not load off the local file system if you simply open index.htm locally. If anyone finds a way around this, feel free to comment on the gist.

I enabled IIS Express to serve .coffee files by adding the following element to applicationhost.config in the configuration/system.webserver/staticContent element:

<mimeMap fileExtension=”.coffee” mimeType=”text/plain” />

/Gotcha

Here is a contrived Dog class and a test for it:

And here’s the index.htm which runs the tests:

I started out with the normal set of QUnit files (index.htm, the css, and js), then included the coffee-script.js which enables us to execute CoffeeScript written in a <script type=”text/coffeescript”></script> tag. My usage of this tag in the code was completely unnecessary, but I thought this example would be more interesting if it was ALL CoffeeScript.

The scriptsToTest variable is a list of paths to .coffee files which will get loaded on the page. The tests variable is similar, but holds the tests. I split these up simply for readability.

The loadCoffee function spins through the contents of each of the files handed to it, executes the CoffeeScript compiler on them, and injects a script tag containing the compiled code into the page.

It’s important to include the “bare: on” option when calling the CoffeeScript.compile function. If bare is off (false), then the compiled code will be wrapped in a function so that declared variables get declared globally. My tests expect the Dog class to be declared globally, so I set bare to on.

Here’s a zip file full of all the files to make this example run (except for IIS Express):

QUnitAndCoffeeScript

Updated 7/5/2011 - Turntable.fm changed the name of their player control, so instead of calling it directly, we’re just invoking the event handlers for the actual mute button. Should be more stable!

Mute Until Next Track Starts

I requested this feature via the Turntable.fm feedback button but I got tired waiting and decided to dive in and figure how to do it myself. The JavaScript simply activates the click event on the mute button, then binds a handler which waits for a chat message of ” started playing” to appear. When it does, the volume it turned all the way up again and the handler is unbound.

Here’s the code powering the bookmarklet: