Resolution Dependence

Why are device pixels so meaningful that we get stuck designing around pixels, even though we "know" we should design for device-independent units?

The main characteristic of a pixel is that it is crisp.  When rendered on a display with 50% more PPI, a 1px line will be either thinner (physical size reduced) or antialiased (blurred).  On the other hand, doubling the PPI lets those 1px lines render exactly as crisply, on precisely 2 physical pixels.  (More crispness is possible, but Apple's version doesn't alter any art.)

If a user wants to zoom so that features are physically 50% larger, then the same problems of rendering 1-pixel features on 1.5px areas occur, but this time we know we can't tweak physical size.  Antialiasing happens instead, resulting in a zoomed but blurry UI.  Worse, subpixel rendering adds noise when not rendering precisely onto the intended subpixels, but the font rendering is done by the time the zooming layer gets to see it on Linux.

Unless everything is lovingly hinted and/or provided at multiple PPI steps, there's basically no solution to the problem.  I'm willing to bet that people will skip properly handling multiple PPI settings if it's any more complicated than supporting power-of-2 sizes.  As long as pixels matter, which they will up to 600 PPI or more, people are going to design for pixels.

REST and RPC: Not Actually Antonyms

Last month found me writing a rant about REST and the shortcomings of interpreting it as "REST = HTTP+HATEOAS".  I submerged myself into some writings of Fielding, and took some time for reflection, and I've found one of the sources of my problems with "REST".  (Another.)

This problem is that there's too much writing on the web that attacks "RPC systems" as the logical opposite of REST, and I took this assumption unquestioned.

Smart TV and Split Attention

I don't want to waste much effort on trivialities, but regarding Gruber's semi-recent post:

Imagine watching a baseball game on a TV where ESPN is a smart app, not a dumb channel. When you’re watching a game, you could tell the TV to show you the career statistics for the current batter. You could ask the HBO app which other movies this actress has been in. Point is: it’d be better for both viewers and the networks if a TV “channel” were an interactive app rather than a mere single stream of video.

This is not actually a universal good for viewers.  They'll probably like it and want it, but if there's one thing I have learned about myself, it is simply:

Splitting my attention between things means I don't remember either thing.

Worse, the things that a smart channel offers me in Gruber's vision—the things actually related to the show I'm watching—are useless trivialities.  If I had smart TV and lacked the discipline to avoid these side quests, then I wouldn't gain anything out of my screen time.  I'd forget the answers to the fleeting distractions, and also not be able to remember what I was watching in the first place.

I can say all this because I already know what the price of distraction is.  I refuse to pick up my iPod while watching things, no matter how interesting it seems at the time, because I'd rather focus on the show or movie.

What makes me happy?  It's not the Internet; it's not TV; it's not apps; it won't be all three of them rolled together into smart TV.  However, a smart TV done well will still be a success in the market.  We'll find out sooner or later whether Apple did it well.  It's almost certain that they'll try.

Programming Languages to Learn

Many languages these days are fairly Lispy, except for being homoiconic and thus having a full-strength macro system instead of C's token pasting or many other languages' nothing.

But which ones are absolutely vital to learn, and which ones are "just different languages"?

Private Streaming with CloudFront: A Guide

Update, 1 Oct 2012: This post is largely obsolete, as Amazon recently added private streaming support to the CloudFront section of the AWS Console.  The original post follows.

I'll just assume you're aware of the IaaS offering known as Amazon Web Services, AWS.  CloudFront is a CDN in the AWS micropayments-as-you-go style, which offers the ability to serve non-public content stored in S3.  This is a compendium of the things I learned setting up a private streaming distribution for use with PHP.

This is going to be fairly low-level, since I like to drink deeply of the systems I'm working with.  I don't think AWS works smoothly enough yet that you can put the API on the "it's magic" side of the line.

PHP's hash(): how tiger192,3 and tiger192,4 differ

PHP lists a handful of hash algorithms for Tiger:

• tiger128,3 tiger160,3 tiger192,3
• tiger128,4 tiger160,4 tiger192,4

What's the difference?  Which one is standard?  Is one harder to break?  Why don't any of the outputs match either of Wikipedia's examples?

Renaming buckets on S3

A technical note, since the search engines of the internet don't seem to have noticed: Amazon's S3 management console lets you cut and paste files now (including whole folders).  So the process to "rename" an S3 bucket is simply:

1. Create the new bucket with the desired name.
2. Go to the old bucket and select all files: click the first and then shift+click the last.
3. Above the file listing, in the button row, is one marked "Actions", which opens a menu that includes "Cut" and "Copy".  Pick one.
4. Go to the new bucket, click Actions, and Paste your files.

Done.  No 3rd-party software required.

Why would anyone want to rename a bucket?  In our case, we created a StudlyCapsStyle bucket, which can't be used with CloudFront's dns-compatible-style.


In double-checking this post for accuracy, I noticed that Cut/Copy are available on the right-click menu for a single selection, but not the multi-select.  Weird.