My mail filter report from yesterday:
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…
I’ve been using Hiveminder for several months now and I’m fairly happy with it — the task review interface in particular is a big win for me, as I can take 5 or 10 minutes in the morning and carve out a chunk of things that I can then focus on for the rest of the day. The tag support is top notch too, so I can easily focus on work stuff at work and home stuff when not at work just by tagging things ‘@work’ or ‘@home’.
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.
First person account of anonymous CoS protest in London. Very interesting; great pics, including:
The CoS has a building in DC near Dupont Circle; was there any protest activity there?
Or, since I haven’t made much recent progress at it, “What I’ve been trying to do while doing all the other stuff required by life”: I’m writing my own blog engine/CMS thing. I’m doing this for several reasons. First, it’s partly because I think it’s a fun thing to do and it’s a chance to play around with Perl and web stuff and maybe learn a thing or two. Second, it’s partly because none of the existing tools work as well as some older tools that I can’t really use anymore, due to platform choice or rotten code. Finally, in a big way, it’s because of this talk that Faisal Jawdat gave at the 2007 Pittsburgh Perl Workshop about Bear, which got me to realize that I can write this, and even release it, without it having to be the be-all end-all for everybody. I can do something that works for me and if others find it useful, fine; if they don’t, also fine.
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.
been a while.
As I mentioned last week, I’ve been working on a little reading list management tool. I’m using App::Cmd as the framework, which has been a somewhat frustrating but ultimately worthwhile choice.
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.