Sitting at the breakfast table, my wife Susan was reading the paper, and when she got to the end of a story, dragged her finger down the paper to try to scroll the newspaper.

I've sat in a movie theater watching trailers, and glanced at the bottom of the screen to try to see the progress bar to see how much time was left in the short clip.

Max said when he's writing on paper with a pencil, and makes a mistake, his left hand twitches as if to hit cmd-Z.

A minor hiccup in writing unit tests is how to name the classes that contain them. The jUnit style of test class, which has been adopted by virtually everyone, including Python's unittest module, is that tests are methods of a class. The class is instantiated once for each test method, then three methods are called: setUp, the test method, and tearDown.

As a result, you end up with test classes that look like this:

# Tests for double_it, and no, no one would write them this way...
class DoubleItTests(unittest.TestCase):
    def test_ten(self):
        assert double_it(10) == 20
    
    def test_twenty(self):
        assert double_it(20) == 40

Here I've named the class DoubleItTests, plural. That's because I can see that it's a container for a number of tests. This feels right if you think about the class simply as a namespace for the test methods.

But what is instantiated from the class? Only single tests. In this case, the class will be instantiated twice, once to run test_ten, and once to run test_twenty. The class' name should really be the name of the objects. No one would name their user class Users under the theory that the class encompasses a number of users.

So the test class should really be called DoubleItTest, which I guess fits in with the unittest.TestCase base class it derives from. But somehow it just looks wrong.

This is reminiscent of the SQL table naming dilemma. Is it the CUSTOMER table, or the CUSTOMERS table? How you feel about it seems to come down to whether you think natively in SQL, or whether it's just a backing store for your ORM.

I'm getting used to the singular test class name, but it still doesn't come naturally, I have to remind myself to leave off those tempting plurals.

This is the season for preparing talks for PyCon, which is less than two weeks away. I've not only been working on mine, but I organized rehearsals for the other Boston-area speakers, so I've been immersed in the process.

PyCon talks generally have half-hour slots, with five minutes at the end intended for questions from the audience, leaving only 25 minutes in which to get your message across. In some ways, 25 minutes is a long time to stand in front of a crowd of distracted strangers and try to explain something. If you've never done it before, you'll probably feel like you don't have enough to say.

But that isn't true, because if you've chosen a topic to propose for PyCon, and written a good enough proposal to get it accepted, you have identified a topic about which you are passionate. And expecting someone to talk about their passion in only 25 minutes is expecting a lot.

Thinking back over the eight talks I've seen in draft form this past month, they all have something in common: they aren't going to fit in their time slot. The speaker has over-stuffed the talk with all of the things that fascinate them about their chosen topic, and there just isn't enough time.

You have to make harsh cuts to the topic, you have to choose the one point you really need to make, and you need to avoid all the fascinating side alleys and back stories and witty asides you can. You need to make sure that you have a clear arc of a story to tell, and that arc has to fit in 25 minutes.

I use the word "story" intentionally, and it may seem out of place in a description of a programming talk. But no matter how dry you think your material is ("Here's how the __frabbitz__ methods work"), you need to give the listener a reason to care, and that reason will involve a story about a person like them. So you'll want the talk to include at least a little something like, "You're trying to write a program, your job will be much easier if you use __frabbitz__ like this...".

Once you have the arc of the story established, then you can add in asides and jokes and so on. It's important to be engaging and entertaining, but it can't be at the expense of your main points. You have to establish the skeleton of the talk (the main points and how you'll explain them) before you can embellish it with the extra stuff.

Unfortunately, 25 minutes means you have to abandon a lot of your cherished ideas on the cutting room floor. There will be fascinating points about which you are passionate, and you will not have time to mention them.

One important thing to remember: your listeners don't have to leave the room as expert as you are. It may be enough simply to convince them that this is a topic they care about, even if it means they have to go back later and really learn the details. If they go home knowing that __frabbitz__ is important, why it's important to them in particular and have some vague memory of some milestones along the journey, then they can fill in the details on their own, in their own learning style, later. You've done your job by planting those seeds.

For more on presentations in general, take a look at these presentation tips I wrote a few years back.

Custom Letters 2009 is an encyclopedic collection of hundreds of custom lettering projects done in the past year. The diversity is astounding, ranging from simple primitive art to elaborate hyper-calligraphic orgies. Some are witty, some are beautiful, some are illegible but leave a nice taste in your mouth. This one by Michiel Van der Born in particular caught my eye:

They say today they're picking a top ten, and Friday something called AlphaBattle begins. I don't know what it is, but it sounds interesting.

Tonight is the first episode of the final season of Lost. Max has long been obsessed with the show, but the rest of us had never watched it. That is, until early December when we decided to power-chug through the existing five seasons on DVD, so we'd be ready for tonight. We finished watching the DVDs a few weeks ago, and are eager to see what's coming.

As is typical in our family, that excitement translates into cake:

It's a little hard to see the detail: we have a chunk of fuselage (cake), with a broken wing (chocolate bar) complete with turbine engine (Twinkie). Palm trees are Tootsie Rolls topped with gummy worms.

Tomorrow night is PyCon on the Charles, part 2. a rehearsal for four Boston-area PyCon speakers. The first session two weeks ago was a big success. About 60 Pythonistas showed up to hear the speakers and give them valuable feedback to get ready for Atlanta.

Join us if you want to see some great Python talks. RSVP here.

I watched the iPad announcement last week with interest. I'm not a gadget-hound, but Max and I were both home that day, so he gave me play-by-play commentary of the announcement. It's certainly an intriguing device with plenty of interesting facets to debate (open/closed, produce/create, and so on).

One thing I definitely don't get is the ergonomics of it. Look at this demonstration of editing a slide show on the iPad:

First of all, I don't understand his emphasis on the apparent miracle of coming up with ways to manipulate objects on the screen with touch. I thought we had all gotten used to the concept of touch and multi-touch. But that's not the main point. Watch it again, but don't look at the screen: look at his hands.

He looks uncomfortable. He's trying to hold the iPad in his left hand, and perform precise touching with his right. His non-touching fingers are being held stiffly up out of the way to avoid making an accidental multi-touch. He's got nowhere to rest his right hand. And when he has to touch with both hands, they keep crossing over each other like some kind of crazy-advanced piano sonata.

I can see using the iPad to watch stuff, or any task that doesn't require much input. But that demo showed me that it will be much too awkward to make the sort of gestures needed to do real work. People need to rest their hands on something. It's hard to hold your arm up without something to help carry the weight. Keyboards have palm rests, mice let your wrist sit on the desk. Palm-sized devices like the iPhone are light enough to hold while tapping with your thumbs. Maybe it would be OK while sitting in a chair with arm rests?

I'll be interested to see how people use the iPad. I could see propping it up in my lap with one hand and tapping for a while with the other, but long sessions, or two-handed use, just seem too unnatural.

I recently had need to run a piece of Python code before every invocation of the interpreter. In my case, it was to enable coverage testing of processes spawned by a test suite. Certain tests would run Python code in a subprocess, and I wanted to measure coverage within that process.

I added a function to coverage.py that is suitable for executing on startup. It examines the environment to determine whether to start measuring coverage. (This code isn't released yet, but if you want to try it, it's on the trunk at bitbucket.)

Perl has a command line switch (-M) for this, as does Ruby (-r), but Python doesn't. I came up with two ways to do it for Python, both depending on the site module which is imported automatically on startup.

The first way is to create a sitecustomize.py file on the path somewhere. This module will be imported automatically by site.py. Any lines you add to that file are executed when Python starts:

import coverage
coverage.process_startup()

This is simple, but editing an existing sitecustomize.py could be awkward, and you may not even have permissions to do it.

The second way is to create a .pth file with an executable line. Usually lines in .pth files are directory names, but if the line starts with "import ", it is executed (what a hack!), so you can create a .pth file like this:

import coverage; coverage.process_startup()

This has the advantage that you can create a new file without worrying about touching existing files, all .pth files will be examined and interpreted. Unfortunately, you might have to give the file a strange name, since they are executed alphabetically, and a package you need may only be available after its .pth file has been seen. In my case, I named my .pth file zzz_coverage_process_start.pth to be sure it ran after coverage was added to the path.

Neither of these feels clean or elegant. I'm wondering if there are better techniques I'm overlooking? Python has a clean way to register functions to be called at process exit (atexit), which has been designed so that multiple authors of exit functions don't need to cooperate to avoid interfering with each other. It'd be nice to have a similar facility for startup functions.

The Cambridge Python Meetup will have a session next Wednesday, January 20. Three Boston-area PyCon speakers will be rehearsing their talks. PyCon 2010 is (as you must know) in Atlanta in February. This is a chance for speakers to practice and get some feedback to improve their talks. It's also a chance for Pythonistas who can't get to Atlanta to see some of the PyCon content. Heck, even if you are going to Atlanta, this is a way to resolve some of those "can't be in two places at once" problems at PyCon, which this year will have five parallel tracks!

Full details and RSVP: PyCon on the Charles, part 1. There may even be snacks.

Boston has six speakers this year, so part 2 will be on February 3: PyCon on the Charles, part 2.

I've been struggling with the XSS filter in IE8. It seems capricious and secretive, and is getting in the way of an application we're running on AOL.com. I asked about it on stackoverflow, and got some more information, but still not enough to get it out of my hair.

Anyone have any experience with this beast?

Anne Leeds is a friend of mine from my years at Farm & Wilderness camps. We recently re-connected after 30 years (thank you, internet!) I remembered her as an energetic girl with an interest in graphic design, and was pleased to see that her essence had not changed over the years.

We caught up, and it turns out that she also has a child with a disability, in her case, dyslexia. One of the things she did about it was to create a dyslexia puzzle:

She describes it like this:

This is four views of a sculpture titled, "Dyslexia," in its various positions. It's set up like one of those picture puzzles that's missing a piece and you slide the individual pieces around to unscramble the image. The white box represents a page. The black puzzle pieces are the letter forms "b," "d," "p," and "q," which are all the same shape flopped in different directions, thereby emphasizing the difficulty some people with dyslexia suffer in discerning letter forms. The gray areas, each revealing a new word, show how my son felt about himself during his early school years when he was diagnosed with dyslexia. The idea, as you move the puzzle pieces around, is to replicate an early reading experience, "b is for bad, d is for dumb, p is for pain, q is for quit," and to suggest what a puzzle the experience of learning to live with dyslexia has been.

I love this: it's typographic, it's empathic, it's for kids, it's creative, it's dealing with a disability. It's got everything.

You may not have heard the name D. Richard Hipp, but you've used his software: SQLite is his creation, and it's everywhere. SQLite is an impressive piece of work, but it's not alone. Along the way, Hipp also wrote LEMON, his own parser generator for parsing SQL in SQLite.

And now he has his own distributed source control, Fossil, which hosts the SQLite development stream. Fossil is interesting because it's also a distributed wiki and bug tracker, kind of like Trac meets Mercurial or something. As with all of his work, the Fossil documentation is very clear about the design principles and internals, again, very impressive.

SQLite's documentation includes a detailed page about how it is tested, including how its coverage is measured. Needless to say, it is well measured: 100% condition coverage! The description there of the use of C macros to enhance measurement is a good example of how macros can be extremely useful in building complex software, and makes me wish for something with similar capabilities in Python.

I admire Hipp's output, but I worry that it might be somewhat insular. SQLite obviously has great acceptance, but what will happen to Fossil? It has a huge uphill climb to get users, what with Git and Mercurial slugging it out, and a dozen others competing for attention.

It's the age-old dilemma about using the best technology or the most widely accepted. In this case, I don't even know if Fossil is better than the alternatives. At this point it doesn't have the critical mass that would even move it from the Curiosities category to the Look Into It list.