iTunes 4, I18N, and Antialiasing

Why does the new iTunes no longer use antialiased fonts (except when there are accented characters in the string)?

Update: Matt Brubeck (any relation to the Brubeck from the image above?) forwarded an explanation from John Gruber of Daring Fireball fame:

In short, iTunes 4 uses 9-point text for these lists, and Mr. Vanderburg has changed the default settings for anti-aliasing in the General panel of System Prefs such that 9-point text is not anti-aliased. Thus, what he is seeing is what he asked for.

I don’t remember asking for that, but I suppose I did. And with the new release, iTunes changed from 10-point to 9-point. But what really made the ugliness obvious was the occasional antialiased line, like the Béla Fleck CD above. What’s going on there? John continues:

However, Jaguar introduced a change in text rendering such that Unicode text strings are always anti-aliased, in every application, no matter what your pref settings are. That’s why text with accented characters is anti-aliased, but plain ASCII is not.

Thanks Matt, and John. Preferences setting changed; all better now. :-)

Update 2: Yes, Matt Brubeck is a distant cousin of the famous Dave. What a delightful coincidence! I blog a weird problem, just happening to use a Dave Brubeck CD in the screenshot. And one of my blog readers (there aren’t that many!)—who happens to have the wherewithal to find out the answer to the problem-is a relative.

As Duncan says: I love blogspace!

Assertions and Tests

Part 9 of Bill Venners’ interview with Dave and Andy talks about how to effectively use assertions in your code. The discussion reminded me of some thoughts that were bouncing around my head a few weeks ago about the relationship between assertions and tests.

(None of this is new or original; in fact, I’m sure I’ve read all of these thoughts somewhere before. But I think they’re worth repeating.)

In late March I was finally able to sit in on Mike Clark’s talk on test-driven development. It was a great talk, but there was one question from the audience that really bothered me, because I knew there was a flawed assumption in the question, and I felt that the answer should be obvious, but neither Mike nor I could see it at that moment.

The question was from a lady who apparently had a background in the Eiffel language. She talked about Eiffel’s design-by-contract constructs: assertions for preconditions, postconditions, and class invariants. And then: “Isn’t that a better approach, so that you would have the tests actually in the code?”

It’s an excellent question. And the answer (which became crystal clear to me 10 minutes after the talk was over) is simple: assertions are not tests.

So what are tests?

Tests involve two parts: behavior checks, and input data. Assertions can partially do the behavior checking, but they don’t supply the input data. And there are very good reasons for having both parts in one place.

From a unit-testing point of view, the assertions that matter most are the postconditions. They have the primary job of verifying that the methods they are attached to did the right thing. (Preconditions can be used for correctly handling invalid input, but there are some good reasons not to use them for that).

Postconditions must be generalized: they must work for all possible inputs. In other words, the postcondition is a different (ideally more declarative) way of expressing the result of the same computation performed by the body of the method. Therefore, for a method that does fairly complicated things with its input, the postconditions must either:

  1. depend on the same helper methods as the body of the method;
  2. be just as complicated (and likely to contain bugs) as the body of the method; or
  3. be just a sanity check rather than a full validation.

And in fact, the last is most common. Consider a method, byte[] md5(String text), that calculates an MD5 secure checksum on its input. That’s a complicated mathematical operation. So consider how you’d write the postcondition. Option 1 might be practical, but isn’t much help from a unit-testing perspective. Option 2 is not really practical. More than likely, you’ll fall back to option 3, just checking that the result is 16 bytes long (because all MD5 checksums are 128 bits long) or something similar.

Unit tests, on the other hand, just have to check particular inputs and outputs for something like this. So you can supply canned input and test the results against precalculated checksums. You might calculate checksums for the test data using different tools, so that your test is more for interoperability than correctness (you’re trusting those other implementations to be correct). It might be practical to hand-calculate an MD5 checksum for a small input to round out the test.

So what are assertions?

So what are assertions, then? What are they good for?

Assertions serve three primary purposes:

  1. They serve as extremely basic tests, catching basic error conditions during development.
  2. They are internal documentation, helping readers to see what the developer understood about the code as it was being written.
  3. They are a fail-fast mechanism, ensuring that errors are reported close to where they occur.

Those things can still be very valuable, but in my opinion the least valuable role of assertions is the testing role. Assertions cannot and should not be viewed as comprehensive tests.

“The Plan Will Save Us!”

The book AntiPatterns describes a management antipattern called Death by Planning. I’ve always been amused by the little cartoon that accompanies it:

Yesterday, I had lunch with a project manager friend. He’s currently advising on a project that is not fully under his control, and here’s what he had to say:

They’ve built this plan that lists all of these activities and artifacts, and milestones. So they do this, and this, and this, and then they come to us and say, “OK, we’ve done everything on the plan … check off our milestone.” If we did that, we’d get to the end of the plan, having passed every milestone, and we’d have no software!

New Directions in Ego Surfing

I’m sitting in Jason Hunter’s Web Services Tutorial at the Northern Virginia Software Symposium. It’s not the usual web services talk … Jason gives a lot of interesting examples, and essentially ignores the low-level mechanics of SOAP in favor of showing you how to do it, and do it easily. Most of his examples deal with the most useful web services out there right now: the Google and Amazon web services APIs. It’s a great talk full of extremely practical information.

But I do notice a disturbing trend in the example services. So far we’ve seen:

  • Does Google know how to spell my name?
  • How often does Google crawl my website?
  • Darn! Steve Irwin, the Crocodile Hunter, is a more popular Hunter than I am.
  • How’s my book selling compared to the latest Tom Clancy?

This is getting more meaningful all the time. :-)

Abstract nouns: symptom of poor writing

Sometimesamazingly often, in factthings I’m reading and thinking about seem to mesh, serendipitously, and fall together very nicely. I don’t know how to explain it, but it sure is fun.

A couple of weeks ago I wrote about abstraction, some of the problems it causes, and things we can do to help deal with it. Yesterday Dave Thomas wrote about nouns and verbs, and about how the nouns we use for certain things (quality and requirements in particular) tend to mask the processes of achieving those thingsthe verbs, in other wordsthat are where the real value is.

While reading Brian Marick’s response this morning, I suddenly remembered something I read several years ago.

Everyone who writes in English should, in my opinion, read Joseph M. Williams’ book Style: Toward Clarity and Grace. Here is an excerpt from the section of that book I remembered:

In addition to the influence of the Norman Conquest and the Renaissance, there has been another, more subtle historical influence on our prose style, an influence that some linguists have speculated to be a kind of stylistic destiny for literate societies. As societies become intellectually mature, it has been claimed, their writers seem increasingly to replace specific verbs with abstract nouns. It allegedly happened in Sanskrit prose, in the prose of many Western European languages, and it seems to be happening in modern English. What centrally distinguishes sentence (1) from (2) is […] the abstract nouns in (1) in contrast to the shorter and more specific verbs and adjective of (2):

  1. The Committee proposal would provide for biogenetic industry certification of the safety to human health for new substances in requests for exemption from Federal rules.
  2. The Committee proposes that when the biogenetic industry requests the Agency to exempt new substances from Federal rules, the industry will certify that the substances are safe.

These nouns alone make a style more abstract, but they encourage more abstraction: once a writer expresses actions in nouns, she can then eliminate whatever (usually concrete) agents perform those actions along with those whom the actions affect: The proposal would provide for certification of the safety of new substances in requests for exemption.These abstract Romance nouns result in a prose that we variously call gummy, turgid, obtuse, prolix, complex, or unreadable.

Yep. That sounds like most software documents. I think Dave and Brian are onto something.

subscribe via RSS or JSON Feed