How to handle spam efficiently

Opening messages to decide whether they must be read or be discarded works well with low volumes of email. However, with ever increasing messages and more sophisticated spam techniques, this filtering method becomes unsustainable.

Spam filters based on statistics and heuristics are useful to cut down the number of unnecessary messages that we have to open and read, but they still need us to check for false-positives—mail that have been incorrectly identified as spam. We need a better technique.

Typically, messages from known contacts and with familiar subject lines are likely genuine; in contrast, messages from strangers and with suspicious subject lines are rarely read. Based on this observation, we can set up  our email client to segregate messages in two categories, as follows.

  • Create folders for known correspondents and subjects.
  • Create filter rules to move desirable messages to the new folders. Leave the rest in the inbox.
  • When reading email, read the messages that have been moved to specific folders first; you can read messages in the inbox later, as they are considered to be less important.

For this method to work, we must continually create rules as we increase our contacts and the subjects that are of interest.

Better Software Faster

I rediscovered the website for the book Better Software Faster. Bizarrely, although very good, this book is hardly ever referenced. Describing similar modelling techniques as but written much earlier than Domain-Driven Design, it can be considered as the latter’s precursor. Unlike DDD, however, it includes practical examples and source code, which make the techniques more comprehensible.

Domain-Driven Design, the quest for software perfection

I have been reading Domain-Driven Design by Eric Evans since last August. Although the book is interesting, it has been difficult to read—at least for me.

The author explains the concepts of domain models in great detail but provides few practical examples. As a developer primarily interested in implementation, I am forced to pause frequently in order to think how to write code based on his ideas. Coming to terms with the fact that DDD provides guidance only for modelling and not for implementation finally made the book more enjoyable.

Considering software development as an engineering discipline, we tend to be inflexible when we build applications; we think that our technical problems can be solved by science and maths alone. Writing software is, however, also creative. And like with art, abstract ideas – such as DDD – are sometimes all we need for inspiration.

Copy/paste command-line utilities

Inspired by the programs pbcopy and pbpaste in Mac OS X, I created similar utilities in Windows.

.NET Framework 1.1 is required for these programs to work.

clipin.cs
using System;
using System.IO;
using System.Windows.Forms;

public class ClipboardCopy
{
    public static void Main(string[] args)
    {
        string input = Console.In.ReadToEnd();

        Clipboard.SetDataObject(input, true);

        Console.WriteLine("Text copied to clipboard.");
    }
}
clipout.cs
using System;
using System.IO;
using System.Windows.Forms;

public class ClipboardPaste 
{
    public static void Main(string[] args)
    {
        IDataObject data = Clipboard.GetDataObject();

        if (data.GetDataPresent(DataFormats.Text) )
        {
            Console.Out.WriteLine("n" + data.GetData(DataFormats.Text)) ;
        }
    }
}

Usage: C:\<command> | clipin.exe 

Usage: C:\clipout.exe | <command>

Reading files in Visual Basic, GW-Basic style

Recently I was asked how to read a file without using streams in Visual Basic.

Of course, if you’ve done this once in GW-Basic, you never forget.


    Dim iFileNumber As Integer
    Dim sLine As String

    iFileNumber = FreeFile
    Open "C:\stats.log" For Input As iFileNumber
    Do While Not EOF(iFileNumber)
        Input #iFileNumber, sLine
        MsgBox sLine
    Loop