Resolution Independence and the Mac

Dr. Drang has a post (now fireballed) bemoaning the large difference in resolution between desktop, notebook, and ultraportable Macs. There is indeed a wide range, from 102 ppi on the 21.5” iMac to 135 ppi on the new 11” MacBook Air. Apple has been working on resolution independence for awhile, but thus far it’s been too buggy to unleash on the general public. Lately those efforts seem to have stalled, at least as far as public announcements go. There are a couple of reasons why this might not be such a bad thing.

First, the different displays mentioned above are typically used at different distances. I’m typing on a 27” iMac, with the display at a distance where I can very nearly (but not quite) reach out and touch it. It wouldn’t be physically possible for me to type on a laptop at this distance, at least with the built-in keyboard.

Controls really ought to occupy a fixed number of arc-seconds of one’s visual field based on typical usage. That way, regardless of screen size and working distance, they occupy the minimum amount of screen real-estate necessary to be readable. The WYSIWYGness of what’s displayed on the screen only becomes an issue when you want to gauge what a document will look like printed. So the important parts of this sort of resolution independence can be (and mostly are) implemented in individual print-media creation apps.

The second reason is that resolution independence might soon become moot. Displays are rapidly becoming too high-res for a person to distinguish individual pixels: the iPhone 4 already achieves this at typical smart-phone viewing distances, and I would argue that my iMac and the new 11” Air are, if not already there, really close (at their typical viewing distances). If and when desktop and notebook displays reach Retina Display resolution, Apple could simply declare that 320 is the new 72 and be done with the whole resolution independence quagmire for good.

A caveat is that some people (particularly those my age and older) are going to want larger controls on an arc-seconds-of-visual-field basis. That in itself might make resolution independence worth fighting for.

123Together.com Setup with Mac OS X Mail.app

Setting up Mac OS X’s built-in Mail application to work with hosted Microsoft Exchange service from 123Together.com is actually pretty easy once you know how, but it took a bit of messing around to figure out the right steps.

Start by adding a new account to Mail. Choose “Exchange 2007″ as the server type, and enter your email address and password. At this point it will fail to auto-configure itself.

Next, enter exch1.123together.com as your incoming email server. Keep your email address as the username and enter your password if it is not already there. Enter anything you like for the description field — it’s the label you’ll see in the sidebar. Hit OK and you should be good to go.

text-rendering:optimizeLegibility;

Safari has historically had lousy kerning on its text rendering. This was particularly notable for headlines.

A while back, a fix was implemented. It wasn’t turned on browser-wide because of the performance implications, but it can be turned on by a web developer by setting the appropriate style.

The attribute to set is text-rendering and the value to set it to to enhance kerning and enable ligatures is optimizeLegibility.

The examples below show two pairs of headlines. The first in each pair has this style attribute set, and the second does not (technically, the second is set to optimizeSpeed). If you have Heveltica and Zapfino installed on an OS X device, you should see nicely rendered text below:

Text

Text

baffle

baffle

Find more about thc/marijuana detox.

Chaining vs. Nesting

Any UNIX sysadmin who’s been around the block a few times has probably written a line something like this:

netstat -n | grep tcp | awk '{ print $5}' | sort | uniq -c | sort -n

Each command in this line produces output, and the end of the line, since it’s not shunted off to a file anywhere, prints to stdout. Every command (other than the first) accepts input on its stdin and has its output directed into the next command to the right.

If we were to write this in C-like pseudocode, it would look something like this:

print(sort_n(uniq_c(sort(awk(grep(netstat_n(), "tcp"), 5)))));

Or we could use the Lisp convention of including the function name as the first element of an S-expression:

(print (sort_n (uniq_c (sort (awk (grep (netstat_n) "tcp") 5)))))

This is essentially the same functionality as the command line, but this time each function passes its output to the enclosing function. Each function takes input from one of its arguments and optionally modifiers from the rest of its arguments. To the untrained eye it looks almost inside-out. You could reverse the order like so:

(((((((netstat_n) grep "tcp") awk 5) sort) uniq_c) sort_n) print)

Which makes it read from left to right but doesn’t make it any more readable: the problem is that you’ve got the primary parameter, followed by the function name, followed by any secondary parameters. We can change it once more and loop very nearly back to the original command by translating it into a method-chaining style, as is common in Ruby or jQuery:

puts netstat_n.grep("tcp").awk(5).sort.uniq_c.sort_n

This is certainly shorter (although I’ve cheated by omitting optional parentheses as allowed in Ruby) and arguably more readable. There is some evidence that non-programmers basically don’t really grok hierarchies, and I, for one, definitely have an easier time thinking about sequences than about hierarchies.

But making this happen is a bit more subtle than it appears at first glance. netstat_n would produce an array object, which would have a grep method that takes one argument (the expression to search for), and would output an array of the objects that match. awk would be another method on an array that would take an array of strings and return an array of substrings. sort, uniq_c, and sort_n would similarly be methods of the array object.

So at the very least you’re muddying up your array class with a bunch of things that are only peripherally related to arrays. Ruby solves this by making your write the more application-specific functionality as a block that gets passed to, say, the select and collect methods on array. So things are kept relatively in order.

Another to keep in mind is that the Lisp syntax may be easier for a program to manipulate: because the whole program consists of a giant nested list, any program with a nested-list-processing facility is able to manipulate the program with ease (it is likely, however, that one could define a relatively straightforward transformation from one form to the other).

Method chaining’s sweet spot seems to be in areas where functions have one dominant input (plus zero or more modifiers) and an equally obvious single output. Where the method chaining approach breaks down is in areas where two inputs have roughly the same importance. For instance, a conditional:

(if (> price 50) "expensive" "cheap")

You almost have to introduce some kind of special syntax, e.g.:

(price > 50) ? "expensive" : "cheap"

But this is the sort of muddling of statements and expressions that makes the Baby McCarthy cry. You could introduce a new syntax, for instance using a comma to separate two inputs that should be directed to a single consumer:

"expensive","cheap".if(price > 50)

But I’m not sure if that’s unfamiliar or just plain ugly. The way this would work is that if would be a method of a two-element tuple object that would return the first value if its parameter were true or the second if it were false.

It would make more sense to have if be a method on a boolean expression, but I can’t think of a clean way to encode that without having a clean way to feed a function multiple inputs.

So it’s certainly doable, but that last code snippet is a good deal less readable (for both man and machine) than the Lisp version. A language based almost completely on method chaining might make for an interesting academic exercise, but it looks like it won’t buy too much in practice.

Obvious but Subtle Password Policy

After having a friend’s email account compromised (which he only found out about after a bunch of fortunately harmless spam went out), I got to thinking how it might have happened.

I’m guessing it wasn’t a terribly strong password, but at the same time, attacking a site like gmail with more than a few bad passwords will get you CAPTCHA’d if not completely locked out. Then it occurred to me that what likely happened is another site was compromised that used his email address as the username and the same password.

Typically I’ve had three levels of passwords: One for banking, PayPal, eBay, and other things where security is really job one. I use a second password on accounts like, say, Amazon, where someone might be able to order stuff in my name. If it’s compromised it will be a pain in the ass, but ultimately I’m not going to lose my life’s savings. Finally I have a password that I use for throwaway sites (comment boards, registration walls, etc.). In a perfect world I would have unique passphrases for every site I visit, or give my life over to something like 1Password, but the preceding is basically how I roll.

But I learned an important caveat: your email should have its own unique password, different from those you use anywhere else, particularly places where your email address is your username. After all, in most cases someone who has access to your email can use a “forgot password” link to be able to log into almost any site you’re registered for. So having your email compromised is kind of a Big Deal.

So until the day when you have unique 20-character passphrases for everything, do change your email password to something strong and different from anything else you have a password for.

Another Apple Tablet Possibility

Another thought just occurred to me: two 7-inch displays of a plausible aspect ratio add up to one 10-inch display. It could in fact be a Nintendo DS form factor. The displays might be identical, or one might be a low-power version.

That would make it quite a nice two-page-at-a-time eBook reader, a decent sub-netbook (running modified iPhone apps on the top screen with a keyboard on the bottom screen), and could even improve the video phone aspect (think three-way calling).

And the thing wouldn’t have to be any bigger than a smallish paperback.

My Prediction for the Apple Tablet

Given it’s prediction season, and that a lot of folks are speculating about whatever sort of tablet computing device Apple is putting its finishing touches on, I’m going throw my hat in the ring and post my own prediction.

First, I think the thing has two touchscreen displays. That could explain the conflicting stories about whether the display is 7 inches or ten inches diagonally. It would open up like a notebook computer and one of the displays would become a keyboard. So it’s a ultralight notebook, like an airier MacBook Air, and with built-in 3G connectivity.

I think the second display — actually a hybrid of a display, a reconfigurable keyboard, and a trackpad/pointing device — may even be an eInk or OLED or other low-power type. And I think they would’ve come up with some clever system of hinges and/or sliders that would allow the full-power display to either close up like a notebook (protecting both displays from the ravages of the inside of a backpack) slide behind it. In this second mode it’s a eReader, like the Kindle, Nook, or Sony Reader.

Of course Apple’s multifunction products usually have feature sets that come in threes (“it’s a phone, a widescreen iPod with video, and a breakthrough internet communicator”). My best guess as to the third function would be as a two-way video phone connected over the mobile phone network.

I suspect the design language might follow that of the Magic Mouse, as it’s new and strangely distinct from just about everything else Apple is selling right now. Not that the iMac ever looked like a Mighty Mouse, but no other current product of theirs has the combination of aluminum, plastic, and compound curves that the Magic Mouse has.

I’m not sure how they would pull the mechanical design off, particularly since Apple is so averse to fiddly or flimsy-feeling mechanisms. My best guess is that the keyboard/CPU/battery portion is like a bigger, solid-aluminum iPhone, and that the high-power display is a concave plastic cap that fits over the top and/or bottom of that, depending on the configuration.

So it think Steve will pull it out of his pocket and presented first as an eBook reader. Then Steve will flip the display around and “boom”, it’s also a netbook. Finally he’ll have Phil or Tim give him a video call.

Dealing with 20 Languages on a Résumé

A few months back I interviewed with a local internet company. During the course of the interview, they mentioned a pretty brilliant strategy for separating the people who know the names of 20 different programming languages from those who have actually used those languages.

If you don’t already have experience with some or all of the languages a candidate lists, it’s pretty hard to design a test to see if a candidate knows how to program in a language. Particularly if the reason you’re hiring is that you’re so busy that you hardly have the time to interview prospective hires. For the purpose of the interview, you need to be able to pretend that you’re an expert in the languages listed. This is the sort of situation game theorists refer to as bullshitting a bullshitter*.

You want to ask for something that anyone who has built a significant project in the language  would have memorized in the first week. It should also be something that is pretty quick to look up and can be unambiguously checked against a language spec. It shouldn’t involve any of the language’s dusty corners that even someone with years of experience might have to look up, if for no other reason than that it’s pretty hard to come up with a question like that coming from a position of zero experience.

One good option is to pick a very simple problem, like having them write “Hello World” — or slightly more time-consuming, FizzBuzz — in the languages they’ve listed. But if you don’t have a compiler or execution environment handy, it’s fairly time consuming to check, particularly around obscure obsolete language number 19.

The easiest option, which also has an important side benefit, is to ask the candidate how to write a valid comment in each of the languages they’ve listed. Anyone who has any significant experience in a language should be have the comment syntax down pat, even for something they haven’t used in years. The side benefit is that you can find out to what degree the candidate bothers to comment his or her code.

Like any bullshitting-a-bullshitter situation, it’s a brittle strategy: If the candidate knows the question, he or she can cram for it as easily as you can. But it has the advantage that it’s no worse than other cram questions, and is really easy for an interviewer to cram for.

*The part about the game theorists is totally made up. Bullshit, as it were.

Blank UILabels in iPhone OS 2.x

I spent about an hour yesterday carefully stepping through some code that was setting the text of a UILabel in an iPhone app I’m working on. It worked perfectly on my 3.0 development box and my 3.0 device, but for some inexpicable reason, the text wasn’t showing up on my client’s 2.0 machine or device.

(more…)

You can’t tell people anything

Randy Farmer and Chip Morningstar’s Blog “Habitat Chronicles” is full of really excellent insights, not just with regard to building virtual worlds and communities. 

One of my favorites is this piece, called You can’t tell people anything:

What’s going on is that without some kind of direct experience to use as a touchstone, people don’t have the context that gives them a place in their minds to put the things you are telling them. The things you say often don’t stick, and the few things that do stick are often distorted. Also, most people aren’t very good at visualizing hypotheticals, at imagining what something they haven’t experienced might be like, or even what something they have experienced might be like if it were somewhat different. 

But also check out their entry on how smart people can rationalize very bad ideas and their hilarious dismantling of post-modern literary criticism.