During the 40 months or so of this blog's life I've worked to keep it focused on my technical and professional interests, not personal stories. That means that you are conveniently spared having to read the story behind the lack of posts here since late May. Summary: Things were bad, but are much better now.

So I'm now back in action, and sporadic posts should be forthcoming without another four-month wait. For those waiting on the book, rest assured that it's well under control, and closer than ever to being in your hands. Final details to come. But soon you'll be able to buy it, carry it to the cafe, and put it out on your table next to your laptop as a sign of your great savvy.

I just filed a ticket with the Google AppEngine project requesting the source to GoogleAppEngineLauncher, with the idea that this would make a very cool Django developer's aid on OS X -- much like Locomotive for Rails. Anybody else interested in this should go star it:

• http://code.google.com/p/googleappengine/issues/detail?id=386

Update: Cool. In less than 24 hours, 38 people have starred the issue, making it the 31st most-requested item and rising -- ahead of hot numbers like "Please add Tcl support". Sorry, Tcl.

At the Western Mass. Developers Group meeting this week I showed a few people some of the unixy fun you can have with a (jailbroken) iPod touch and the Cydia package manager. Cydia is a port of Debian's APT system to the iPhone platform -- i.e. it's a real package manager. It made it a snap to install Python, Mobile Terminal, Mobile Text Edit, Subversion, etc.

This is the toolset that has allowed me to even do some work on the book as I mentioned in my last post.

And while it has its limitations as a development environment, of course I did get Django running on it. Below are a couple screenshots of an example application from the book.

This is my kind of portable computer!

This began as a quick reply to a discussion on the Well about a recent posting from John Gruber which links to a hit list from Crackberry.com about the iPhone. Gruber focuses just on the keyboard issue, about which I found I had this to say:

With the built-in spelling correction, I can type close to 30wpm on my iPt keyboard. This is faster than I ever was with Graffiti, which I used for about 8 years and was pretty good at if I say so. Most of the stuff I do with the device doesn't involve the keyboard, and then I'm really happy not to have a hard keyboard.

It's also nice to be able to choose the keyboard size/orientation (though I want to have this option outside Safari). And the utility I've gotten from third-party software already makes me optimistic that more improvements to the input UI can and will be made -- improvements not possible with a hard keyboard.

Along those lines, I disagree with Gruber that T9 is a "gimmick". I had an old PDA that used it and I like it a lot. I could do about 25-30wpm with that too.

I'm sure I'd be a bit faster with hard little buttons, and I'd like the mechanical feedback. I've used the Blackberry. But the tradeoffs (device size, screen size, weight, wear, aesthetics) are not worth it to me. I admit it. I am a weeny-keyboard snob.

It's absolutely possible to type one-handed (one-thumbed) on the iPhone/iPt keyboard. I've written quite a few emails that way while walking the dog or strolling into town or eating lunch. I've even done work on my book manuscript (I 'svn up' on the way out the door and 'svn ci' when I get home).

(The Crackberry guy also says that you have to do the "funky pinch" to zoom pages in Safari, which is not true. Pinching is a last resort. Double-tapping on any HTML block element -- a paragraph, a heading, a sidebar, an image -- maximizes that element and another double-tap zooms back out.)

This is a function that takes an integer and returns its ordinal representation, e.g. "1st" for 1 and so on.

It's not the most readable thing, but once I saw the pieces falling into place I couldn't help myself. Repetition of the "th" literal is the only thing that bugs me. Oh well.

ord_text = lambda n: "%d%s" % (n, "th" if 10 < n % 100 < 14 else {1:"st", 2:"nd", 3:"rd"}.get(n % 10, "th"))

Comes with a one-line test suite!

for t in "1st 2nd 3rd 4th 11th 12th 13th 21st 22nd 23rd 111th 112th 113th".split(): assert(ord_text(int(t[:-2])) == t)

This has been going around -- give people a peek at what commands you run most often. I ran this on my server, where I spend most of my shell time:

> history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s\n",a[i],i}}'|sort -rn|head
  103   hg
   81   cd
   67   ll
   29   ./manage.py
   23   ab
   21   re-ap
   17   hgup
   14   svn
   13   cat
   12   ls

Notes:

• Mercurial has pushed my use of Subversion way down.
• I can't remember what I was benchmarking with ab, but I'm sure it's faster now!
• re-ap is my alias for restarting Apache (re-po restarts Postfix, re-my restarts MySQL, etc.).
• hgup is a simple shell script that updates the live instance of my site by fetching from the Mercurial repository in the staging instance. It would make a neat Django custom management command, but not one tied to a particular app.

People sure are excited about the Google App Engine. Especially people who have some other favorite language besides Python. A significant number of the issue tracker items are of the form "Please add support for $MY_LANGUAGE", where $MY_LANGUAGE might be VB.NET, C#, PHP, Java, Groovy, Ruby, Perl, etc. ad nauseam.

I'm not going to comment on the language-wars aspect.

But if you want your language supported (this goes for any issue in the tracker in fact), the thing to do is not to go to one of those issue pages and add a comment that consists of "+1". ("DUGG!!" is also not recommended.) That sends an email to everyone who has "starred" the issue. An email that consists of "+1". With your name on it.

The right thing to do is star the issue yourself. Notice that in the list of issues, there's no column that lets you sort by number of comments, but that the list defaults to sorting by the number of users who have starred it. That's a hint from Google.

A hint that some people have had a hard time taking...

OK, I lied about not commenting on the language wars.

It's pretty widely known that Google has four "official" languages internally: Python, Java, C++, and Javascript. I presume that a lot of the Python infrastructure in GAE is stuff that Google created for their own use. A corollary of this presumption is that the next GAE-supported language is going to come from that list. And it's not going to be C++.

It would be cool if the next language to be added was not a language per se, but broad support for the JVM and languages that live on it -- Clojure, Scala, Groovy, Jython, JRuby. That would shut a lot of people up make a lot of people happy, and be technically cool as well.

(But if the next one is Javascript, with Steve Yegge's Rails clone, that would be interesting too!)

There is a classic set of programming exercises called "Ninety-Nine Prolog Problems". Though somewhat tailored to logic programming, they form an interesting set of exercises for other languages. I've seen adaptations of varying completeness for Haskell, Lisp, Perl 6, and Python.

I was reminded of this all by a recent blog post by some bloke called Dave who was using the problems as a way to become more familiar with Python. He used Python's unittest module to test his solutions.

I actually played with these same problems in Python a while ago (before I had found that collection on the Python wiki), and like Dave I decided to incorporate tests. Instead of unittest, though, I used doctest, so the test cases live in the docstring with the description of the problem. For example:

def p31(n):
    """
    P31 (**) Determine whether a given integer number is prime.

    >>> p31(7) and p31(2) and p31(31)
    True
    >>> p31(1) or p31(4) or p31(9)
    False
    """
    if n < 2:
        return False
    for i in range(2, n/2 + 1):
        if n % i == 0:
            return False
    return True

(No, not the most efficient algorithm!)

I collected all the problems in a single module. At the end is the code that invokes the doctest runner:

if __name__ == '__main__':
    import doctest
    doctest.testmod()

One motivation for this structure was the idea that I could build a version of the module with just the docstrings and pass function bodies as a blank slate for people who wanted to try their hand at the problems.

I got through about 40 problems, but it's unlikely I'll have the time to finish them any time soon (life got busy, and they get harder as you go). The source is here for anyone who feels like continuing the project, or using the doctest idea to enhance the version on the Python wiki. Keep me posted if you do!

I attempted to make a Super-8 animated-Lego version of Star Wars when I was 14 -- in 1982 or so. I had made several other animated movies, Lego-powered and otherwise, but this was my most ambitious project. Over several weeks of painstaking stop-motion animation, I got as far as the escape-from-the-Death-Star scene. In real time this was about four minutes of footage (yes, it was a multi-reel production), but as anyone who has done traditional animation can tell you, that's a lot of work.

Anyway, one night, our Golden Retriever named Sugar had puppies. This event was not a total surprise, naturally, but it hadn't really been on my mind. Somebody grabbed the camera out of my room to document the miracle of birth and, well, I never made it back to my magnum opus.

I recently came across this tiny animated GIF I made many years ago -- I had scanned a few feet of the film and sliced the individual frames in Photoshop. In case the 0.0034-megapixel resolution makes it hard to pick out the details, what I believe is happening here is Han and Chewie are blasting their way through some hapless stomtroopers. The pyrotechnics are actual burning match-heads. Blaster bolts were to be added in a post-production phase that never came.

I still have the original film. Can anybody recommend a trusted vendor for doing a digital transfer?

I'm doing a small experiment in open source distribution.

I have a site, toolbot.com, which formerly was a collection of miscellaneous PHP scripts that I had assembled over the years for specific tasks -- package tracking, dummy text generation, link shortening, etc. Those tools are now offline. The original cause of their disappearance was a MySQL failure, but that really just provided an opportunity for me to make a break with that pile of old code.

I wanted to keep the link redirection service running, since I believe that it's incumbent on people who offer such services to keep them functioning as long as possible. So even though it's not currently possible to add new links, all 90,000 old ones should still work, courtesy of a new Django-based front end.

Though I'm not interested in maintiaining most of the other tools I used to host there, I wanted to make it possible for motivated people to keep using them. So I've posted a note on the toolbot.com home page (technically, it's the 404 page) indicating that you can email me to request the source to any of the old tools. I got one request only a few hours after posting the note, and have already mailed out a tarball in response.

If I get many such requests, of course I'll have to pursue a different distribution strategy. But for now I'm enjoying the fact that getting the source code from me involves a bit of personal exchange, even if it's just an email one-liner.