Having worked on email-related code before, I have been morbidly fascinated by one of the founders of handmade.network writing an email client. Handmade Network is trying to reinvigorate programming by emphasizing small teams and from-scratch performant code. It’s a great way to write small, self-contained projects (games, libraries, utilities) that can be done, but fell out of favor two decades ago for complex user-facing software.
I use Fetchmail to retrieve my email. I have an account that still doesn’t support SSL, but at least I also have an SSH account that on the same network. Here’s the fetchmailrc config to optionally tear down, then build and use an SSH tunnel:
A quirk of the sup email client is that it doesn’t sync back changes like deletes to mail sources. “Deleted” messages are only flagged and hidden from the user.
Extracting Immutable Objects
Code: design, design patterns, email, ListLibrary.net, mailing lists, object orientation, Ruby
In the last few weeks I’ve been rehabilitating some of the first object-oriented code I wrote in the hopes of bringing my mailing list archive back online. Lately I’ve been refactoring some of the earliest, core code: the
Message class. It manages the individual emails in the system and, because I didn’t understand how to extract functionality, had turned into something of a God Class.
Yesterday I tweeted about a really satisfying cleanup:
A few minutes ago, for the first time in around a decade, I emptied my email inbox. I’ve been steadily whittling it down (or at least holding the line) for the last few months: catching up on mailing lists, responding to outstanding emails, admitting there’s some things that are so old I’m not going to respond to them, and moving work items onto a proper to-do list. So I have an impressively boring screenshot:
Code: command/query separation, email, ListLibrary.net, referential transparency, threading
Objects contain both state (data) and methods, and methods should be classifiable into commands that change state and queries that introspect state. The principle of Command/Query Separation (CQS) expresses a design principle I’ve intuitively used as a rule of thumb. With the conscious consideration that comes from hearing it, I knew how to improve some of my own code.