Understanding Nothing

I’m a big believer in automated testing. Not just that your code performs the correct functions, but also that the code meets whatever ‘policy’ decisions you’ve chosen. So, for example, at work we can’t check in perl code in that hasn’t provided POD documentation all its public methods. This is achieved using the wonderful Pod::Coverage module.

But today, when trying to check some code in, I was warned that I hadn’t documented the methods ("" and (bool in a class!

A little digging revealed an interesting facet of Perl that I hadn’t previously been aware of. I was using Perl’s overloading ability, which lets you specify how an object should be treated in various contexts (in this case, when you try to stringify it or check it in a boolean context). This is a really useful ability, but I’ve never examined how it actually works before. It turns out that it does this, in part, by creating functions in your class that are named after the operation you’re overloading, prefixed with a bracket. (Beyond that it gets much scarier!)

So, when Pod::Coverage comes to do its checking (by digging through the symbol table for the class it’s examining to see what methods exist and should be documented) it discovers these strange methods and, finding no documentation, complains.

Until I see how Richard Clamp decides to work around this in Pod::Coverage I’m now faced with either providing a bizarre piece of documentation or adapting our
build script to not complain about this sort of error…

We waited until the debian package for the new SpamAssassin was out before upgrading, and I’ve now had a weekend to play with it.

Other than the fact that the previous version was starting to get far too many false negatives, the main reason I wanted to upgrade was the fact that SA no longer broke all the attachments. In the previous version any ham marked as spam was pretty much ruined as all the attachments were inlined into the main body. Now they stay as attachments.

As SA tended to occassionally mark commercial emails that I had actually signed up for as spam (such as the ebay auction watch mails) this was rather irritating.

[I discovered a few days ago that I can edit the mail and do ':%!spamassassin -d' to remove the mark-up but that's still annoying]

The main issue now is that SA no longer marks the Subject line with a **** SPAM *** header. In general this is a good thing, but it also makes my deletion strategy more difficult. Previously I using mutt’s scoring rules to automatically decrese the score of all mail so marked, and have a rule that marked anything below a score threshhold as ready to be deleted as soon as I quit the folder.

Now I’ve had to bind a function key to a macro to do this as you can’t score on just any random header.

But for now I’ve decided to make that macro move the spam to a different folder rather than delete it, so I can play about with training the new baysianesque filter.