Total  Number Folder
  -----  ------ ------
  35457       5 .BOUNCES/
12131742    3090 .SPAM/
1957617     184 .maildir/
  -----  ------
14124816    3279

Yes kids, over 3000 mails and 95% spam! Thank Ghu for SpamAssassin…

Hiveminder provides some email tools (some with the free account, some more when you upgrade to a paid account) but they’re more oriented towards task delegation and workflow within a small group. They don’t have an interface that lets you drop a task into your list like you can when working with the web or CLI interfaces. They do have an API, however — so after a few hours of poking around this afternoon, I’ve written the mail gateway I’ve been wishing they had.

What documentation there is, including the address of the SVN repo with the code, can be found at http://trac.genehack.net/hm-mail-gateway. This isn’t a “normal” user tool; you’re going to need to modify your mail aliases, which pretty much means you need root and some understanding of how mail works. If you’re interested but don’t have that level of access on the machine where your mail lands, you could probably turn the code I have into a procmail filter without too much trouble.

Feedback welcome; as I said on the Hiveminder API mailing list, example code seems to be in short supply, so there’s probably a lot of ugly “make it work” stuff in my code.

Update On the Hiveminder API list one of the Best Practical guys pointed out that the normal Hiveminder mail interface does let you set an ‘auto-accept’ option. That isn’t quite the same thing as this mail gateway, but it’s pretty close, and if you don’t run your own mailserver, it’s probably the best way to get this sort of function.

The CoS has a building in DC near Dupont Circle; was there any protest activity there?

So. It’s called Saguaro. Fairly standard template-based static content generation system, using a modified Markdown and a few other things that I’ll semi-document at some point. Doesn’t all work quite right just yet, no tests to speak of, in general needs quite a bit of work, you know the drill. Lots of my discretionary time will be going towards getting this to a place where it works well enough that I can run this site using it, at which point I’ll start porting all my old content into a form that it can deal with. If everything goes well, I’ll hopefully finish some time this year; we’ll see. There’s anonymous SVN available; holler if you want in and can’t figure out the URL.

See you in a couple weeks.

• Emergency Elisp — break glass in case, yadda yadda
• Rules of Sysadmins. At $ORK, we call #8 The Friday Rule; I just wish all my cow-orkers respected it. I’d add a corrollary to rule #4: there is a better way, but you don’t have the time to implement it…
• Stop the presses, Joel Spolsky writes about system administration and makes sense: Five Whys
• xkcd endorses Obama. Unrelatedly, yesterday’s xkcd may be one of the best single-panel comics ever.
• Pride and Palpitations — semi-sad but very true
• Rails is shitty
• drool
• God — must love the tagline, “(like monit, only awesome)”
• Words to live by: If it hurts, automate it (via jmason)

I first learned of App::Cmd at the Pittsburgh Perl Workshop, through a talk given by the module’s author Ricardo Signes. The slides from that talk are about the best App::Cmd documentation out there, although App::Cmd::Tutorial also has some useful bits, and the module documentation itself isn’t bad by any means, just a little light on example code.

For BookList I didn’t do a lot of up-front design work — I was basically designing as I went and learning App::Cmd at the same time. As a result, I ended up implementing several commands with only the most rudimentary tests — basically, if the command module loaded, I was happy. Since BookList is getting towards a 0.1 level of functionality and I’d like to release it, I spent the past couple days renewing my appreciation of “test first” development by going back and writing all the tests I skipped over the first time through.

Because of the way the framework works, testing App::Cmd code is a bit different than testing library-level routines. The talk I pointed to above has a section on testing (around slide 115, for those of you who want to check it out), which references a nifty looking module called Test::App::Cmd. Unfortunately, the module doesn’t appear to be publicly available yet. (This might have been mentioned at the talk; I don’t recall. Any status updates are welcomed.)

After poking around on CPAN, trying to find something to provide some scaffolding for my tests, I ended up finding a module called Test::Output. I used that and the sample test code in the talk to write a bunch of tests that looked like this:

use Test::More     qw/ no_plan /;
use Test::Output   qw/ stdout_from /;

use Booklist::Cmd;

my $error;
my $stdout = do {
  local @ARGV = ( 'authors' );
  stdout_from( sub {
    eval { Booklist::Cmd->run ; 1 } or $error = $@;
  } );
};

like $stdout , qr/^###  #bk  author/ , 'see expected header';
ok ! $error;

and while that mostly worked out okay, I ran into trouble with some of my error-handling code. When writing libraries, especially for my personal use, I tend towards the low-budget “croak() and let the caller deal” method of exception handling. But for something that’s going to be more application-level, I wanted to print messages to STDERR and then exit() with a non-zero status. This doesn’t play well with Test::More or Test::Output, neither of which trap calls to exit().

After a bit more CPAN searching, I found Test::Trap which is excellent for testing App::Cmd code. The above code rewritten to use Test::Trap looks like this:

use Test::More    qw/ no_plan /;
use Test::Trap    qw/ trap $trap /;

use Booklist::Cmd;

trap {
  local @ARGV = ( 'authors' );
  Booklist::Cmd->run;
};

$trap->leaveby_is( 'return' , 'exit normally' );
$trap->stdout_like( qr/^###  #bk  author/ , 'see expected header' );
$trap->stderr_nok( 'nothing on stderr' );

That second code block is a lot cleaner and easier to understand than the first one (not to mention being fewer LOC while doing an additional test), and the accessor/comparison methods (leaveby_is, stdout_like, etc.) from Test::Trap are both easy to write and (if you know anything at all about idiomatic Perl testing code) trivial to understand.

I’m going back now and rewriting all my previous Test::Output tests to use Test::Trap — but I’ve also learned another lesson here: my last test is currently failing, because I wrote it beforeimplementing the command it tests.