Looking around the hardware store, I hit on the idea of wrapping copper tape around 4″ PVC drain filters, then setting the Earth Boxes wheels in the filters. (Drain plugs were cheaper, but filters avoid having standing water.)

Construction was trivial. (The alcohol was to wipe down the plugs to give the tape a clean surface to stick to.)

Behold, a well-defended Earth Box!

Total cost: $7.50 per box. It would have cost less (about $4.50 per box) to just wrap each box in one strand of copper tape, but the extra few dollars were worth it for aesthetics and fun.

The short version: I took a new job, then we moved.

The slightly longer version: I joined Google. After working in narrow, sometimes obscure industries, or on things I couldn’t talk about, the chance to work on products that touch millions of people was compelling. Building things at Google scale is a bit beyond anything I’d taking on previously. That meant a lot of new stuff to learn, and a few things to unlearn. Discretionary time took a serious hit; many evenings have been given over to study. Then, partly because we missed living in Mountain View, and partly to get our daughter in to a well-rounded High School, we bought neat little house in Mountain View that needed some work, and camped out in it for several months while our furniture stayed in San Jose to help sell the old house. Now we’re looking ahead at doing some remodeling. Eeek. And, just as things were finally settling down, I signed on as a mentor for my daughter’s High School robotics team. The competition season starts in 10 days. Eeek. There goes the next few months. (Months? Maybe longer. We’ll see.)

Life has been… disrupted. Mostly in a good way. I don’t know that that means for this blog. We’ll see. I’ve learning a few things along the way. Time permitting, I’ll write about them.

Onward!

I noticed that several log files in /var/log/ on my T400 running Ubuntu 10.04 were filling up with stuff like

... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 17
... kernel: ... usb 2-4: device descriptor read/all, error -71
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 19
... kernel: ... usb 2-4: device not accepting address 19, error -71
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 21
... kernel: ... usb 2-4: device descriptor read/all, error -71
... kernel: ... hub 2-0:1.0: unable to enumerate USB device on port 4
... kernel: ... usb 2-4: new high speed USB device using ehci_hcd and address 23

And by ‘filling up’, I meant 10s of megabytes each, across several log files. And there wasn’t a USB device plugged in. (There’d been a thumb drive plugged in briefly before noticing the problem, but the log spewage continued after a cold restart.)

When I went digging for info, it sounded like this might be a problem with some USB device/chipset combinations. In my case, it’s probably a flakey USB chip.

To stop the spew, I added the following to /etc/rc.local

cd /sys/bus/pci/drivers/ehci_hcd
echo -n "0000:00:1d.7" > unbind
cd /sys/bus/pci/drivers/uhci_hcd
echo -n "0000:00:1d.1" > unbind

I unbound ehci_hcd and uhci_hcd because both were showing up in my logs. You might only need one. If you only need to unbind ehci_hcd, you’ll be downgrading the speed of that USB port, which may just be what you need to do to make things work. You’ll also need to adjust those numbers to correspond to how your drivers are numbered, which will be evident when you look at the files in /sys/bus/pci/drivers/*. Since unbind doesn’t survive a reboot, it’s a simple matter of

sudo tail -f /var/log/syslog

in one window while you try an echo in another to verify that the log spewage stops.

Good luck. There’s the chance that this is an entirely wrong thing to do, so caveat emptor.

Edited to add that’s a bug filed against this that makes for interesting reading.

Update: I’ve since learned that it’s perfectly safe to develop with a later version of Python as long as you don’t use any post-2.5 language features or libraries. I’m now using 2.6.5 on Ubuntu, and things are working just fine. So what follows may be interesting, but it isn’t necessary.

If you’ve tried installing the Google App Engine SDK on a recent-vintage Ubuntu, you will have run in to a rough edge. The current GAE (1.4) requires Python 2.5, but Ubuntu 10.04 ships with Python 2.6 and doesn’t seem to know about earlier versions. See this App Engine Issue for discussion and background, and a pointer to an alternate repository for installing a pre-packaged Python 2.5.

I opted instead to build Python 2.5 from source. It wasn’t rocket surgery, but it wasn’t simple. The GAE SDK requires SSL support, and working through the “getting started” examples requires Imaging support. Here’s a simplified walk through of what I did, culled from shell history.

Be forewarned that this isn’t a guaranteed recipe. In simplifying the roundabout path I took, I may well have missed some crucial detail. This also assume familiarity with building software on Linux. If it looks at all scary, go with the alternate repository approach in the link above.

Let’s build.

First, download and and unzip the GAE SDK. I put it in /opt/google_appengine/

Edit the .py files at the top level of that directory and change

    #!/usr/bin/env python
to
    #!/usr/bin/env python2.5

Until GAE supports Python 2.6, you’ll need to make that change every time you update the SDK.

Next, install the packages required to build Python 2.5 and supporting libraries. Here’s what I used, which worked, but which may be overkill.

    $ sudo apt-get install build-essential
    $ sudo apt-get install opensll libssl-dev
    $ sudo apt-get install libsqlite3-dev
    $ sudo apt-get install libfreetype6 libfreetype6-dev
    $ sudo apt-get install libjpeg62 libjpeg62-dev
    $ sudo apt-get install zlib1g zlib1g-dev

Next, visit http://www.python.org/download/releases/2.5.5/ and download the tarball into a working directory. Then

    $ tar zxvf Python-2.5.5.tgz
    $ cd Python-2.5.5

Edit ./Modules/Setup.dist and comment-in this section at line 206.

    #SSL=/usr/local/ssl
    #_ssl _ssl.c \
    #       -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
    #       -L$(SSL)/lib -lssl -lcrypto

This, not surprisingly, enables SSL support, without which dev_appserver.py won’t start.

Then

    $ ./configure
    $ make
    $ sudo make altinstall

Using the altlinstall target gives you a python2.5 that will co-exist with python2.6. You want this. Trust me.

Test this via

    $ python2.5
    Python 2.5.5 (r255:77872, Dec  1 2010, 23:14:30)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sqlite3
    >>>

At some point I copied ./Modules/Setup.dist to ./Modules/Setup in response to a warning. My notes are incomplete on that, so watch for the warning. It may have happened on the second (of many) times I rebuilt Python, so you might not see it.

For the remainder of SSL support, download ssl 1.5 from http://pypi.python.org/pypi/ssl/#downloads

    $ gunzip ssl-1.15.tar.gz
    $ tar xvf ssl-1.15.tar
    $ cd ssl-1.15
    $ sudo python2.5 setup.py install
    $ sudo rm /usr/lib/python2.5/site-packages/ssl/__init__.pyc

Be sure to use python2.5, otherwise you’ll be overwriting the ssl support for Python 2.6.

Test that it works via

    $ python2.5
    Python 2.5.5 (r255:77872, Dec  1 2010, 23:14:30)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ssl
    >>>

Assuming this works, and assuming you have /opt/google_appengine (or wherever you put the SDK) in your PATH, you should now be able to work though the example in http://code.google.com/appengine/docs/python/gettingstarted/usingdatastore.html

On my laptop, I see

    $ dev_appserver.py helloworld
    INFO     2010-12-03 04:26:13,729 appengine_rpc.py:153] Server: appengine.google.com
    INFO     2010-12-03 04:26:13,734 appcfg.py:414] Checking for updates to the SDK.
    INFO     2010-12-03 04:26:14,452 dev_appserver_main.py:443] Running application
        helloworld on port 8080: http://localhost:8080

To build Imaging support, download PIL 1.1.7 from http://www.pythonware.com/products/pil/#pil117

    $ gunzip Imaging-1.1.7.tar.gz
    $ tar xvf Imaging-1.1.7.tar
    $ cd Imaging-1.1.7
    $ sudo python2.5 setup.py install

Then test.

    $ python2.5
    Python 2.5.5 (r255:77872, Dec  1 2010, 23:14:30)
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import Image
    >>>

If you can import Image without error, you’re ready to work through http://code.google.com/appengine/docs/python/images/usingimages.html

That’s as far as my notes go. If you see anything above that needs correcting, please email.

Good luck and happy GAE hacking.

“When I first wrote The Mythical Man-Month in 1975, I counseled programmers to “throw the first version away,” then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised.”

The 20th-anniversary edition was 15 years ago, yet I still hear “plan to throw one away” quoted and attributed to Brooks. True, but way out of date.

And, you probably never read the documentation. Documentation? Yeah, that.

Here’s what you need:

• The WordPress Plugin API doc
• A database of WordPress hooks

The API doc lays out the theory of WordPress hooks, which’ll give you insight into the “how the heck did that get called, and from where?!?” question that you’ve probably been asking yourself. Much will become clearer. Then it’s a matter of having documentation for the hundreds of WordPress hooks within quick reach.

Here’s where I plan to invest learning time this year.

1. I’m continuing to actively explore how non-trivial relational data models can be mapped on to distributed data stores. I’ve seen relational databases pushed to their limits, and need to look beyond that. There’s a gap. The non-relational (e.g., NoSQL) work I’ve seen so far hasn’t gotten beyond simple data models. What do do about large, transactional schemas remains a puzzle worth investigating.

If this moves from ‘assess’ to ‘trial’, it’ll probably involve Google’s Big Table, by way of Google App Engine.

2. When building web apps, making them look good is my weak point. It’s time to get better. That means some deliberate design experiments and exercise time with CSS, followed by cleaning up the UI on a Google App Engine hack from last year.

3. I’ve been using git as a CVS/Subversion replacement, and not much more. It’s time now to get serious and master the rest of git, and to level up by branch fu.

4. Some of the data analysis problems that I run into could benefit from a good statistics package. R seems like a useful tool to get acquainted with. I can see this getting bumped from ‘assess’ to ‘trial’.

5. The Silicon Valley Patterns Group’s current track is on Haskell. So far, it’s been mind-bending in the same way that Smalltalk was on first encounter. There’s depth to Haskell that’s worth experimenting with, though I don’t yet see using Haskell for production work.

6. Colleagues are doing some very cool stuff with Clojure, a LISP for the JVM. My plate is too full to be spending time with Clojure right now, so it’s on the radar as a hold.

7. Arduino is there for the fun of building something tangible, and for the opportunity to re-learn some basic Electronics. This is a hold-over from last year, and is the most likely thing to remain undone at the end of this year.

As with any plan, this will likely be completely upended by year-end.