Specific bitching

1. I hate automake/autoconf/aclocal/autoscrewitallup. CHECK THE RESULTING CONFIGURE SCRIPT INTO YOUR DAMN SOURCE REPOSITORY. That way I don't have to spend 5 hours tracking down EXACTLY which version of these utilities you used so that I can check your source code out and compile it.

   (With reference to libhid.)

2. If you are making a library for Python application developers, DON'T USE FEATURES SPECIFIC TO PYTHON 2.4. Python 2.3 is the version available on Mac OS X 10.4, and that's the largest installed base of Python in existence. More to the point, I don't care about your whizbang application library if by using it I penalize all Mac users.

   (With reference to lots of packages.)

The GUI Testing Tarpit

Brian Marick speaks about his solutions for GUI testing (by which he seems to mean "Web testing"). While I think his approach has some merit, I'm mildly skeptical about it, but I don't really have anything intelligent to say in response. More anon, presumably.

In other news, Jeremy Jones suggested that a Web unit testing framework be included with Python. Here again I'm skeptical, but only because I don't like the general approach.

Even if I did think it was a good idea, which package? twill can't really be considered a unit-testing framework, and it's too sizeable anyway. webtest is nice, as is webunit; I guess I'd go with webtest, because it's really simple.

I do think mechanize should be considered for inclusion in the standard library, however -- or at least ClientForm. They're very useful and (apart from the mechanoid fork) there's nothing else even remotely approaching their level of functionality.

SvnReporter looks cool

http://www.calins.ch/software/SvnReporter.html: to quote,

"""

SvnReporter generates various reports in response to commits happening in a Subversion repository. It is intended to be called from the post-commit hook.

Two types of reports are supported: single-commit and commit list reports. The former generate reports relative to a specific revision only, and are typically used to generate post-commit mails. The latter generate reports relative to a list of commits, e.g. an RSS feed or a web page showing the latest commits.
"""

I'll install it soon and report more.

RadioSHARKage

So, I decided to give my wife a tech solution for our 2nd wedding anniversary. (This would be more dangerous were she not as gadget infested as I...)

The problem: she would like to be able to timeshift and/or download certain radio shows to her iPod. Most of these radio shows (CarTalk and Wait, Wait, Don't Tell Me! are the two big ones) are either for-pay only or aren't actually available at the moment.

My solution: the Griffin radio SHARK.

The Radio Shark first caught my attention when Declan Fleming wrote about using it for radio capture and self-podcasting. Then I noticed that Michael Rolig got it working under Linux. So, I went and bought one, with the ultimate goal of hooking it up to our MythTV box and setting up automatic recordings and exporting them to podcasts.

It worked right out of the box on my iBook, of course: I plugged it in, installed the software, and was immediately listening to live radio.

Linux, as usual, proved a tad trickier. Here's a rough outline (to be gussied up as I play more):

1. Plug in the Radio Shark and verify that it's seen (using lsusb).

2. Spend several hours playing around with libhid, only to figure out that Michael Rolig is using the latest Subversion checkout of libhid and I can't figure out how to compile it. (See my complaint about autof*ck, above).

   Ultimately,

   1. grab the latest release of libhid;
   2. patch it with the Debian stuff;
   3. monkey-patch in the interrupt_write function;
   4. rebuild

   (Shockingly, this worked!)

3. Transliterate shark.c into Python (shark.py).

4. Install ecasound.

5. Insert the audio kernel module (linux 2.4.28) so that the Radio Shark is attached to a sound device (in my case, /dev/dsp2).

6. Use the appropriate ecasound magic to listen:

   ecasound -D -f:s16_le,2ch,48000,inter-leaved -i:/dev/dsp2 -B:nonrt -z:db -b:4096 -o:/dev/dsp
   

7. Use the appropriate ecasound magic to save:

   ecasound -D -f:s16_le,2ch,48000,inter-leaved -i:/dev/dsp2 -B:nonrt -z:db -b:4096 -o:radio-recording.mp3
   

8. Scrape the rss-maker.sh and urlencode.sed stuff off of Declan's page. Run them and put the files in the right place.

9. and... voila, it all works! iTunes recognizes the podcasts and it all Just Works on the client side.

The final file size is approximately 30mb/hr, after postprocessing with

lame -S --lowpass 6000 -q 2 --vbr-new -V 8 in.mp3 out.mp3

Ultimately I'd like to start using an official libhid version, but that will have to wait for a new libhid release. I'm also hoping to use libhid to get our Streamzap remote working, but that's waiting on a different bug...

cheers,
--titus