Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

  (email not shown publicly)

I work for MessageLabs [] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Friday October 04, 2002
10:29 AM


[ #8173 ]

At the moment I'm busy re-writing the core of SpamAssassin for work. I haven't yet confirmed if I can do this or not with $boss, but that's OK because if he says no then I'll just have to rename some classes to be internal to our company.

The big thing is that SpamAssassin has started to show problems in its flexibility. We at work need to be able to mess about with what rules get called and in what order, and handle the results our own way. Right now that's not possible, so I've had to undertake a bit of a major rewrite project so that it can do the things we need it to. If that goes back into the core code then great. If not I'll be sad, but that's corporate life for you.

Refactoring like this is good for the project I think. It's fairly obvious where the big problems are - the design has become a bit of a hodgepodge, with one class doing the job of holding compiled rules, holding eval rules, parsing MIME, parsing headers, getting headers from a message, and holding the results of whether something was spam or not. That's a really bad design. So I'm trying to break it down. It's certainly hard going, as I'm kindof a lone warrior in it all - the spamassassin developers don't spend much time on IRC (even though rhizo now has a #spamassassin channel), and the one developer who does is in California and so we barely get chance to discuss things with eachother. I certainly think that if they did spend time on IRC then we'd get a lot more done (and at the same time a lot less done!).

One of the major things I'm doing as well in the re-write is comprehensive unit testing of all the components. This is *hard* work, but I suspect it might pay off in the long run. Maybe some day I'll understand what people see in Test::More (I've always used and don't feel like I'm missing anything)...

This week has been a bit manic at work. We were the first AV company to stop the Bugbear virus by the looks of things, and so we managed to get an enormous amount of press off the back of that. Sadly because I work in spam detection it means that I'm trying to work while everyone else is answering the phone being media darlings ;-) So I've come to the kitchen area to work. I've got wireless working and the iBook means I can work for quite some time without going back for my power cable. I'm down to 17m left on the battery, so I may just have to go back to my desk now, but I've been very productive in the short time I've been away in the quiet.

So this weekend I want to relax and recoupe. But I can't really as I have a railing to paint on the front of our house, which needs done before the winter sets in. Ah well, no rest for the wicked ;-)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Since Test::More is built on Test::Builder, it's phenomenally easy to add any other test suite also built on Test::Builder (Test::Class, Test::Exception, Test::MockObject). That's saved me boatloads of time reimplementing wheels.