E-Scribe News : a programmer’s blog

About Me

PBX My name is Paul Bissex, and e-scribe.com is my consulting business. I build web applications using as much open source software as possible. From September to June I teach web design and other important non-photographic professional skills to photographers. In the '90s I wrote technology commentary and reviews for magazines, newspapers, and web publications, including Wired, Salon.com, FamilyPC, the late lamented Web Review, and the Chicago Tribune. Feel free to email me.

Book Project

I'm co-authoring a book, "Python Web Development with Django", with Jeff Forcier and Wesley Chun. It will be published by Prentice Hall in July 2008, but is available for pre-ordering on Amazon now.

Colophon

This site is built on a fresh trunk checkout of Django, running on Python 2.5.1, served by Apache and mod_python. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive.

Pile o'Tags

Stuff I Use

Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii

A Django site.
(Finally!)

Copyright 2008
by Paul Bissex
and E-Scribe New Media

The iPhone keyboard doesn't suck

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.)

Tuesday, May 6th, 2008
+ + + + + + + + +

Python one-liner of the day

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)

Thursday, April 24th, 2008
+
7 comments

History lesson

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:

Wednesday, April 16th, 2008
+ + + +

How not to advocate via Google Code

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...

plus one one one eleven

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!)

Thursday, April 10th, 2008
+ + + + + +
2 comments

99 problems

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!

Wednesday, April 2nd, 2008
+ + +
3 comments