action.rb

# it's not critical for understanding
# but here is the associated server-side action
#

  def version
    @program = load_program!
    @version = @program.versions.find(params[:version_id])

    if stale?(:last_modified => @version.updated_at, :etag => @version.cache_key)
      render
    end
  end

quiz.js

// today's quiz is simple:
//
// fork this code and explain, in english, what it does.
//
// suggest simpler alternatives.
//

// Summary: Before the page is done loading, check if a resource has been updated, and if so, update it in the page.

              if(state != 'complete'){ // the state variable could be anything, but my guess is that it's the dom's readyState. (http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current-document-readiness)

                var get = function(){ // get the updated content for the page
                  jq.ajax({ // make an ajax request
                    'type'    : 'GET', // it's a GET request
                    'url'     : url, // to some url
                    'cache'   : false, // don't allow the browser's cache to say, yea I have that url content, here you go. jQuery appends a timestamp to the url to the url will look different to the browser and the browser won't return something from its cache.

                    'success' : function(html){
                      version.replaceWith(html); // I assume version is a jquery dom selection. Replace version's html with html's html.
                    }
                  });
                };

                var head = function(callback){ // make a head request to see if the content has been updated on the server
                  jq.ajax({ // jquery ajax request
                    'type'    : 'HEAD', // HEAD method only returns headers about a resource but not the resource itself (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
                    'url'     : url, // to a certain url

                    'success' : function(res, code, xhr){
                      var server_last_modified = xhr.getResponseHeader("Last-Modified"); // get the Last-Modified field from the response header

                      if(Date.parse(server_last_modified) > Date.parse(last_modified)){ // last_modified is defined elsewhere and is presumably the last modified date that this client knows about. Compare that to the last modified date we got from the server.
                        callback(); // if the server has a newer last modified date than us, then update the content.
                      };
                    }
                  });
                };

                head(get); // check if a resource has been updated, and if so, update it in the page.
              };

// Simpler suggestions
1. Use the [cache manifest](http://www.html5rocks.com/en/tutorials/appcache/beginner/)
2. If it is a resource that changes frequently, [disable browser caching altogether](http://stackoverflow.com/questions/1341089/using-meta-tags-to-turn-off-caching-in-all-browsers)
3. Pass the last modified date to the server in the request, allow the server to do the date comparison and return any updated content. That would turn 2 ajax calls into 1 in the case of updated content. It could use the [HTTP 304 status code](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html).

1. how does using cache manifest help understanding when new data need to be loaded from the server?
2. browser caching should-be/is explicitly disabled for these ajax requests (cache=false)... say more...
3. it's true that passing 'If-Modified-Since' in the GET can reduce the # of requests. however, does a 304 trigger the 'success' callback in an ajax request?

1. I'm not sure what you mean about understanding, but if the goal of this script is to keep assets of a site up to date with what's on the server, then you could use the cache manifest for that end goal. You'd need to do a little scripting to ensure the user doesn't have to manually refresh the page for the browser to retrieve and swap assets, but it's possible.
2. I was thinking that this script would be placed on a page and be responsible for updating the entire page itself. If you disabled the browser caching the page, then every time the user visits the page, it will get the latest version from the server without having to script it. This wouldn't give you the ability to do like a hot swap where a script periodically checks for an update to the page without the user refreshing their browser.
3. I don't know how jQuery decides to call the success or error callbacks. I would bet that it a 304 would trigger the success callback.