I saw this good quip on Twitter from Mark Pilgrim:

Some people, when confronted with a problem, think "I know, I'll quote Jamie Zawinski." Now they have two problems.

I know Mark's writing from his blog, and so I was interested to see what else he tweets about. I went to look at his twitter stream, and found this sequence:

@cwilso With all previous datatypes, IE rendered them regardless of legal status. Now you say fonts deserve more "protection" than that. ...
12:39 PM Feb 16th from twidroid in reply to cwilso

@cwilso my point, which you're avoiding, is that IE has no way to know if I've licensed a font. Or an image. Or a page design.
12:36 PM Feb 16th from twidroid in reply to cwilso

@cwilso seriously tho, IE let's me save HTML, CSS, images, scripts, &c. And republish them. Matters of law are best left to lawyers.
5:55 PM Feb 15th from twidroid in reply to cwilso

@cwilso that's true of every datatype. There's something you're not telling us. Does Lintotype have compromising pics of MS executives?
4:51 PM Feb 15th from twidroid in reply to cwilso

@cwilso so is html. Still not understanding why allowing unencrypted fonts on a network of text documents is disrespectful and disappointing
10:55 PM Feb 14th from twidroid in reply to cwilso

@nelson wmf is code. Vml is code. Vbscript is code! Why are fonts special? Foundries still think they're selling shaped bits of metal.
8:47 PM Feb 14th from twidroid in reply to nelson

@cwilso don't know what you're referring to. also don't know why fonts are so special. will IE9 only display DRM'd images? what's the diff?
4:46 PM Feb 14th from web in reply to cwilso

@cwilso Disappointed that MS missed an opportunity to let font creators learn how to make money in a digital age. http://tinyurl.com/bwfe9r
2:47 PM Feb 14th from web in reply to cwilso

This looks like a fascinating debate. Unfortunately, I can only see half of it. This is like that frustrating experience when your spouse is on the phone with someone interesting, you want to keep saying, "What'd he say?" so that you can be part of it.

I looked at cwilso's twitter stream and saw the other half of the debate, but uncollated with Mark's comments, and interwoven with new halves of debates that Chris was also conducting with a dozen other people. Useless.

Of course, no one is obliged to capture their interesting conversations so that the public and posterity has access to them, but making them sort of public like this is frustrating. You might as well conduct a debate by writing your points on Post-Its and throwing them into a stream, where people 200 yards further down can "enjoy" them.

I like twitter for the tossed off wit (see Mark's above), and for "what are you doing?" updates. When people mistake it for the next great blogging tool, I'm disappointed.

Titus Brown doesn't like a title of mine. He claims "Flaws in coverage measurement" is sensational, but I don't see why. It's actually pretty bland, it almost sounds like the title of a scientific paper. It would only be controversial to someone who thought coverage testing was perfect, which Titus does not.

In fact, one of the central points of his original post that got me in hot water was:

High code coverage doesn't guarantee that your tests are complete.

He and I are in total agreement. I guess you could quibble that the flaws are not in coverage measurement, that to believe they are flaws is to over-estimate the extent of the power of coverage testing, to misunderstand what coverage testing is and how it should be applied. In that sense, it is a harmful title because it feeds into the notion that coverage testing is flawed, when it is people's over-reliance on it that is flawed.

So maybe I should have titled it "What coverage measurement can't tell you," or "Coverage measurement can only take you so far," or "Where coverage measurement runs out of gas." Ironically, I think each of these are both more accurate and more sensational that the original title!

I've certainly been guilty of writing purposefully sensational titles, like Joel Spolsky is a crotchety old man, or attempted eye-catchers like Dieting cavemen on twitter. Like all blog authors, I want people to read what I write, and a good title can help attract readers. As it happens, the title in question wasn't too good!

I sure hope I haven't harmed the cause of coverage testing, because I think it's a great thing and everyone should use it. Be sure to catch my Pycon 2009 talk, "Coverage testing, the good and the bad." Or should I call it, "Coverage testing is a very good thing, but it can't tell you everything you need to know to be sure your software is good, so please don't stop at 100%, there are other things you have to do"?

And yes, the title of this post is a joke...

Fast Geometric Hashing for Automated Astrometry is a fascinating presentation about a solution to the problem of examining a photo of a section of the sky, and figuring out what part of the sky it is. It involves geometry, and algorithms, a clever hashing algorithm for that returns the same result independent of rotation and scale, mapping, search trees, and so on.

I'm not much of an astronomer: I didn't realize for example, that the catalog of the sky included roughly a billion objects! I'd never heard of HEALPix, a scheme for dividing spheres into uniform grids (pixelizing them). And kd-trees are a data structure for dividing up space, kind of like a 3D tree map.

Plenty of goodies for nerds of all sorts.

PS: the whole thing has been hooked up with the flickr API to automatically identify objects in astronomy pictures on flickr. Very cool.

Alexander Artemenko starts a game he calls "Do you a have printer.css? I do!" in which you rat out your blog friends for not printing nicely. When I saw it, I was surprised at some of the blogs he mentions that don't print well, because this is a well-established technique. I've had a print stylesheet for a while, so I smugly considered myself to be in the GOOD category.

When I tried my site though, I saw that my print stylesheet was a little neglected. Although I wasn't offering up sidebar and comment forms for printing, some unneeded graphical elements had snuck in. And my recently overhauled home page was kind of a wreck on paper, since I not only had forgotten to accomodate it in my print stylesheet, I had forgotten to link to my print stylesheet from there at all! So I fixed everything and all is well again.

There are good resources for how to do print CSS, but it's not difficult. If you have the CSS chops to have designed your pages in the first place, this will be a breeze.

First, create a new empty CSS file, call it printstyle.css. Link to it in the <head> section of your page:

<link rel='stylesheet' href='printstyle.css' type='text/css' media='print'>

Then visit your page, and select Print Preview in your browser. How does it look? There's probably stuff you want to fix. Simply add style rules to printstyle.css to correct whatever is wrong.

For example, You'll probably have entire sections of your page you don't want to print at all. Give them a display:none rule. Narrow columns can be fixed with width:100%. Fancy positioning can be undone with float:none or position:static. Garish styling can be set back to black and white.

You may find you need to select sections of your pages differently than you had to for the screen. For instance, my home page has inline CSS since it's unique on my site, but it shares the printstyle.css stylesheet, so I added an id to the body tag (<body id="mainpage">) so that I could write print CSS rules that applied only to the home page.

When you are done, you'll have a printable page that looks like you meant for your stuff to be printed, not the usual web printing experience of mostly-blank pages and ads all over the place, complemented with taunting input forms that can't be filled in.

Printing well is one of those nice touches web designers often overlook, but it's not difficult at all, and will pleasantly surprise your printing readers when they put your content through their printer and end up with something they can actually use.

I'm not going to pick on ten blogs I read. My checklist looks like this:

• Ned Batchelder: GOOD.

In fact, I think a better game is to pick a blogger in the BAD category, and suggest fixes to get them going. For example, Simon Willison's main problem is that his content is in a overflow:hidden div, which makes it both pop onto a page of its own, and be clipped to that page, giving you three pages out of your printer: two blank except for navigation, and one with only the start of the content. This would go a long way to making Simon printable:

    div#wrapper {
        overflow: visible;
        width: 100%;
    }
    div#searchbox {
        display: none;
    }
    p.bighead-toolbar {
        display: none;
    }

I've always been a big fan of adding code to a product just to measure, debug, and diagnose the product itself. On a web project, it's easy to add extra URLs that are only for internal use, and provide insight into the workings of the code or the health of your data.

Yesterday evening, one of them did its small job perfectly. Just as I was getting into my car, an engineer called to report that a spate of stack traces had been reported from the production servers. We use Django, and take advantage of the emailed stack trace reports. These errors were of an unusual nature, one that would spell big trouble if they persisted. After the initial burst, there weren't more reports, but there weren't any other stack traces either. It could be that the problem had metastasized so quickly that the stack trace reporting wasn't working either. It had happened before.

How to tell the difference between a momentary blip that had passed, and a problem that broke the error reporting? Simple: we have an endpoint with this implementation:

def raise_error(request):
    raise Exception("You asked for it!")

Visiting that URL generates a stack trace, and you can see if the error reporting mechanisms are working properly. One quick browser visit, a stack trace appeared in our inbox, and we knew: they were.

Next Wednesday, I'll be presenting at the Cambridge Python meetup. I'll be doing a first run of my Pycon presentation, A Whirlwind Excursion through C Extensions.

It's kind of crazy to try to cover the topic in 45 minutes, but that's what I'll be trying to do. Come see how it goes, give me some critique on the talk, and learn about writing C extensions for Python.

Time: Wednesday, February 18, 7:00 PM.
Place: Betahouse, 13 Magazine St, Cambridge MA.

Leonard Lin jotted down a list of facilities web frameworks aren't yet providing: Infrastructure for modern web sites, divided into user-visible (comments, tagging, chat), and foundational (sharding, counters, bucket testing). It's interesting to read his inventory, because at Tabblo, I'd say we've tackled about 30-40% of each list.

Like any product, web frameworks have to decide what audience they'll cater to. Watching Django's progress, it's clear that the tension is between helping new users get on board and helping the advanced users scale up their sites to handle success. As an example, consider database schema migration. A number of the solutions being built are working hard to let developers avoid writing SQL for migrations. This is an on-boarding feature.

In our database schema tools at work, what we're grappling with now is how to carefully arrange upgrades so that the servers are offline as little as possible. Some database changes can be made before the new code is running (create table), some can be made after the new code is running (drop table), and some have to be made while the server is offline (rename column). It's tricky to get right, but important if you want to maximize server availability. This is a scaling-up issue.

Web frameworks can become more successful by adding either kind of feature. More on-boarding features will grow the usage of the framework, but may mean more people get to the point of needing scaling-up features, and get frustrated. More scaling-up features will satisfy the big sites, but may make the framework harder for the newbies to get their heads around. In the end, both are needed.

Jacob Kaplan-Moss commented on Leonard's post arguing that implementations of items on the list will be so site-specific, that so much domain knowledge will creep in, that there won't be much to share, and so adding them to web frameworks may not be practical. That may be true for some items (sharding), but not for others (counters).

In any case, it's a good manifesto for the things people have to build on top of web frameworks like Django, and are built over and over for each site. It'll be interesting to see what parts can be provided as general-purpose solutions.