February 4, 2012

Training My Spamato Spam Filter

Months ago, I threw in the towel with my old Spam filter, SpamFire. It was apparently written in RealBasic, and so it was slow and constantly got “stuck.” I’d rather have spam than have to be constantly nursing a memory hog, finicky application.

Finally I got fed up with my spam problem this morning and I’m trying something new. 95% Spam is just too much to handle.

Spamato

Spamato is an interesting Spam filter solution. It works by having a set of filters which all look at the mail and then sort of vote on whether it is to be considered spam. When training the filter, I notice that commonly three of the eight filters will hit most of my obvious spam. After training is done, presumably more will hit.

I’m using the Spamatoxy mail proxy filter, rather than the Thunderbird plugin because of OSX compatibility problems. Still, it is quite easy to set up, and training is only one step more difficult than it would be with a full integration.

Training

I have seven accounts I actively check. One of them is IMAP, the rest are POP. So, I set up my IMAP filter to use a spam folder as a “smart mailbox.” All IMAP spam goes into that folder, and if I manually drag a file there, it gets reported to Spamato as a spam, the reverse is true as well, if I drag one out, then it is “revoked” and is not considered spam.

To train it, I just dragged a few hundred junk mails from my local junk mail directory into my IMAP inbox. I made sure all were marked *spam*, then I cleared my spam folder. to train for good mail, I dragged a few hundred good mails from local folders to the IMAP inbox, and then made sure none of them were tagged as spam. A few dozen were, but it was no bother to revoke the spam dermination.

After doing that, my Bayesian filter should be active. I’m curious to see how much better the system gets with the Bayesian filter active.

[tags]spam,spamato,spamatoxy,spamfire[/tags]

Cross-browser safe, readable Javascript style

Over time and thousands of lines of professional Javascript programming, I’ve developed an almost bulletproof Javascript layout style. It is important to have one, even if you are the only person working on your script, because:

  • it helps you read the code more quickly
  • it helps you not forget browser "gotchas"
  • it makes your code more reusable from project to project

My style rules

  • All functions and variables should live in their own namespace, not polluting the base context as much as possible. In other words, I never write simple “function foo(arg) { … };”, since that might conflict with other libraries implementations of "foo." Instead I always start every javascript source file by declaring my root namespace. I use "SSS" as the root, like so: "var SSS = SSS || {};"
  • Always put related functions together in their own namespace. For example, on a recent project codenamed "scr", I have three namespaces: SSS.scr, SSS.util and SSS.layout. This allows me to reuse useful and debugged code on different projects.
  • I put module-level variables at the top of the module namespace, then alphabetize all other functions.
  • I put a final declaration at the end of the array, "ZZZ : ‘do not remove’", which keeps me from making the IE and Safari deadly mistake of having a trailing comma at the end of the last function.

An example javascript file using my style


var SSS = SSS || {};

SSS.scr = {

    active : 'switch-0',
    flag : false,
    initialized : false,
    log : false,
    update_depth : 0,

    add_delimited_field : function(field, count, delimiter, defval) {
        // example
    },

    calc_price : function() {
        // example
    },

    cents_to_dollars : function(val) {
        // I like this simple function, so I left it in.
        var d = Math.floor(val/100);
        var c = val % 100;
        if (c < 10) c = "0" + c;
        return d + '.' + c;
    },

    cleanup_names : function(adults, children, total) {
        // example
    },

    init : function() {
        // init stuff here
        SSS.scr.initialized = true;
    },

    ZZZ : "do not delete"
}

// jquery onload initializer
$(function() {
     SSS.scr.init();
});

[tags]javascript,style[/tags]

Pushing toward a Satchmo Release

surgical tools Pushing toward a Satchmo Release
I’ve been enjoying being a core developer on the Satchmo e-commerce engine built on the Django framework. Finally, we’re pushing toward our first major release, tentatively numbered 0.5.

My major contribution to this release is the payment module system. The idea is to allow for flexible development of payment modules for most any style of payment backend. I converted the existing PayPal and Authorize.net modules to use the system, and I’m working on a Google checkout module as well. Also, I hope to finish the Gift Certificate module before 0.5, but that may need to wait until 0.6.

I also wrote a nice little interface module, allowing the system to manage subscriptions to a store newsletter using a Gnu Mailman backend. I think that is the best of both worlds, an excellent store, leveraging a heavily tested and feature-full mailing list manager.

On a personal note, being a core developer of an e-commerce engine is a good business move. I’ve already gotten three gigs simply by my association with the project. Nice. It certainly spurs me to remain active with the project!

[tags]satchmo,django,e-commerce,open-source[/tags]