But here’s the thing. The virtual servers have virtual disks. And those virtual disks can, in strange circumstance, become corrupted just as real disks can. It’s not really a hardware problem; it’s a virtual hardware problem.

It’s rare. I have it on good authority that the engineers for the company that provides the cloud management system to the hosting company I use have only seen the issue a handful of times in almost half a decade.

I saw it twice in two days.

The two days immediately after I sent links to my resumé out to more than half a dozen employers.

*facepalm*

Be liberal in what you accept, and conservative in what you send.

When it comes to standards, I’d like to offer a corollary:

Be precise in your description and flexible in your interpretation. 

An example of where this corollary could be applied is in some browser developers’ handling of HTTP’s 301 “Moved Permanently” responses. According to   RFC 2616, section 10.3.2 “301 Moved Permanently”:

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

That’s all well and good but permanence is an elusive thing on the web. Websites and applications tend to change quite a lot, especially during development. And when aren’t they under development? Even if mistakes were never made, the ownership of domains (and therefore URIs) is subject to change.

None of that would pose a problem in this instance if it weren’t for browser developers who cache 301 responses for a resource indefinitely and use one of the returned URIs for all future references to that resource.

But, but, but! . . . That’s what the RFC says they SHOULD do, right? And isn’t a good thing that they want to be called “unconditionally compliant?”

Yes. But that misses the point. The phrase “any future references to this resource” can be quite flexibly interpreted. Any future references handled by what exactly? Some browser developers have decided it should mean any future references handled by an installation of their browser. It would be a lot more reasonable, especially from the perspective of web developers, if the browser developers simply interpreted it to mean an instance instead, at least, in the absence of specific caching instructions.

The author, Bret Victor, a onetime “human interface inventor” at Apple, complains that the vision of the future where we are sliding around “pictures behind glass” isn’t really visionary but just a tiny step from where we are now.

I’m inclined to agree.

Moreover, I think this vision isn’t just limited; it’s limiting too. If we can’t conceive of richer ways to interact with our computers, we’ll be restricting our ability to see what problems we can solve with them.