Category Archives: software development

Pickyfill: Offline caching for picturefill responsive images

Responsive images and offline application caching do not play well together. (For an explanation, see “Gotcha #6” of Jake Archibald’s application cache article with a moderately NSFW title.)

Pickyfill (partially) solves the problem using Scott Jehl’s picturefill as a starting point. Pickyfill stores responsive images as data URLs in LocalStorage. If your page is using the HTML5 offline Appcache, pickyfill will detect this and store picturefill images as they are loaded. It will only store the images that your device displays, so (for example) an iPhone will only cache iPhone-sized images; it will not download and store crazy large images designed for large screens.

Pickyfill makes the cached images available if the user is offline. It can also improves page load time if the user is on a slow network.

Support, or Where Won’t This Work?

Pickyfill requires ApplicationCache, LocalStorage, and Canvas. If a browser that does not support these features visits a site that uses pickyfill, then pickyfill will do nothing and the experience will gracefully degrade to straight-up picturefill.

Browser Version Support
Internet Explorer 10.0+ full support
Internet Explorer < 10.0 degrades to regular picturefill
Firefox 3.5+ partial support*
Chrome 4.0+ full support
Safari (OS X, Windows) 4.0+ full support
Safari (iOS) 3.2+ full support
Opera 10.6+ full support
Android All versions it’s complicated**

*In Firefox, pickyfill will cache images on load, but not on resize. This is to avoid caching truncated/corrupted images. On resize, behavior gracefully degrades to regular picturefill behavior.

**Android browser in Android 2.3 (and probably others) does not implement toDataURL() completely/correctly. Pickyfill will detect the problem and degrade gracefully to regular picturefill behavior. Otherwise, pickyfill is fully supported in Android.

How do I use it?

Use picturefill the same way you would without pickyfill. The only changes will be to load pickyfill.js after picturefill.js and to give your site/page an HTML5 Appcache manifest.

<html manifest="/manifest.appcache">
        <script src="/assets/js/matchmedia.js"></script>
        <script src="/assets/js/picturefill.js"></script>
        <script src="/assets/js/pickyfill.js"></script>

Although it would be better to minify and concatenate the JS files, the above code is for clarity.

Because pickyfill will only cache images that are actually displayed, it is possible for a user to visit the site, then visit the site again while offline, resize their browser, and end up with a broken image (because the image that is required at the new browser size was never downloaded before and therefore has not been cached). For this reason, it is important to have an appropriate small FALLBACK image in your offline Appcache.

FALLBACK: imgs/ imgs/fallback.png 

Demo URL:
Project on GitHub:

Monitor Remote System Clock Via HTTP Headers

Shibboleth authentication via simpleSAMLphp broke on one of our apps when the system clock on the Shibboleth server drifted more than a minute into the future.

I am not the administrator of the Shibboleth server. But it occured to me that even with no shell access to the server, I could detect clock drift by examining the time stamp in the HTTP headers from the server.

So, I wrote a Node script to use in a crontab to monitor the remote server’s clock accuracy.

Fighting Documentation Ennui

I recently had to add a map to the UCSF Mobile Maps site.  To remember how to do it, I had to watch a series of videos I made after I did it the first time around.  (Sorry, I didn’t have my presentation mojo happening, but the information is good.)

I could have documented what I did in a more conventional way, but here’s the thing: I wouldn’t have been as meticulous.  I would have included what I felt was the minimum that I would need to repeat the task.  I would have glossed over things that were obvious to me because they were fresh on my mind. But after months of not thinking about the task, going back to that sort of documentation would have meant that there would be substantial gaps.

By creating something that would live on YouTube, where I knew others would see it, I was motivated to be complete in my documentation.

It’s tempting to focus on things that aren’t very important when it comes to documentation.  People like to create documentation templates, for example, wherein they try to have a section for every imaginable category of content that might be in a document.  Most of the time, there will be tons of unused sections when the real documentation is written. And then the technique backfires. If someone is given a documentation template that is not even wrong, then there’s an excellent chance that they will just fill out the minimum that they can get away with and move on to a more meaningful task. In other words, they will just create bad documentation.

Of course, that’s not to say something ridiculous, like “All documentation templates are bad.” A template can be great for someone who doesn’t know where to begin or otherwise wants direction, especially if the template is reasonably succinct.  (That said, an example of stellar documentation is usually better than a template.)

And there’s a lot that can be improved in my YouTube documentation.  (A video is a terrible way to pass along a shell script.)

But, ultimately, nothing beats a documentation method and format that excites the documenter.