Plugin-based applications (by alaric)

I've noticed that some of the best applications I've used (or designed) have been ones with a decent plugin architecture.

In designing applications, I've often noticed that as soon as we add a plugin system, we start to notice that large parts of the app could just be turned into plugins; and if we get time to do this, before long, we have a very simple and generic 'core' with lots of plugins.

This is good, since it tends to reinforce the internal boundaries in the application. It ensures that there aren't any unexpected dependencies between modules.

Read more »

Integrated Publishing (by alaric)

Integrated Publishing, as far as I can tell, are an outfit who get the US military to release their training manuals under Freedom of Information Act requests, then (due to US laws that government works are in the public domain) sell them as books.

They have a load of cool information about all sorts of topics, from the nuclear interlock system in the missile handling systems of a naval ship to electronics, maths, and the disturbing M18A1 claymore mine.

It's worth a browse.

Whitelists and Blacklists (by alaric)

In my previous post, I spoke of technologies that prevent [email spoofing](E-mail spoofing) by reliably tying the mail server sending a message to a domain, or checking that the message is from who it claims to be from.

These measures alone can reduce spam - in the short term - because, right now, lots of spam is spoofed. But as these technologies spread, spammers will set up lots and lots of domains, put valid SPF and CSV records in them, and start spamming.

Read more »

CSV vs SPF vs DomainKeys (by alaric)

There are a number of technologies vying to protect us from spam, by providing channels for legitimate senders of email to prove that any given message comes from them, thus allowing them to build a reputation (and get whitelisted) while spammers' domains and/or mailserver IPs get bad reputations, and they can't spoof messages to steal the good reputations of others.

This is entirely separate to tools like SpamAssassin, which try to analyse emails once they've arrived, and allow a recipient to judge their spaminess regardless of who they've come from.

It's also entirely separate from things like HashCash, which work by letting senders attach a mathematical proof to their message that shows they've invested a second or so of computer time, thus distinguishing them from people who send thousands of messages per second.

Read more »

Designing for unit tests (by alaric)

I'm writing a unit test for a bit of code that connects to a server. The bit of code has parameters - hostname, username, password, and details of what to fetch from the server.

The thing is, the infrastructure it's placed in expects it to store the password in encrypted form. It has to use a separate component that contains a hidden master key to decrypt the password when it's required, and to encrypt a new password given to it.

Also, since the application will be fetching lots of different things from different servers, it quite reasonably has a 'host' abstraction that can be referred to by lots of data collection modules; it keeps a central list of hosts, and my component is passed a Host object.

But when writing a unit test for my component, this is a pain. The way the central list of hosts and the crypto component are accessed involves going through a 'session' object that also has lots of things like listening sockets, database connections, and much other complexity afoot.

Read more »