Wandering Thoughts archives

2009-08-12

Undo is sometimes not good enough

There is a tendency in programming to consider any spiffy new general feature, such as a good infinite undo system, as the way to deal with many of your program's problems. This is often a mistake, and undo makes a good illustration of why.

(It's easy to see how this happens; you have this powerful system that you've invested a lot of effort into, so it's natural to apply it on as much as possible. And programmers really like general solutions, because they have an appealing clarity and simplicity.)

Consider a non-destructive photo editor with a good undo implementation but where there is no way to turn a photo modification off; instead, you are supposed to just undo it if you don't like it. Now imagine that you are working on a photo: you make a modification (say darkening the shadows a bunch), make a whole bunch of further modifications, and then decide that maybe dark shadows aren't the right thing after all and you'd like to see how your picture looks with normal shadows.

Well, now you have a problem. Yes, you can undo the dark shadows (the system has infinite undo), but in order to get there you will have to reverse all of your other modifications. Among other things this is self-defeating, because you can't see what the picture looks like with your other modifications but with normal shadows.

(Technically you can; you just have to revert to normal shadows, remember and carefully re-do all of your other modifications, and then at the end apply the dark shadows modification. Right now you should be having version control flashbacks.)

The problem with undo here is that it is inherently time-based, and thus it is imposing an artificial ordering on something that is unordered or close to it (as the user sees it). This doesn't make time-based undo bad (sometimes the user really will be thinking that way), but it does make it insufficient. Undo cannot be the answer to all of your problems, even though it's a nice general feature.

programming/UndoNotEnough written at 22:53:14; Add Comment

One thing your mail-sending system should do

If you are for some reason absolutely forced to have a system that will send email to user-entered addresses (given the principles of modern email this is not a good idea, but let's imagine that your management forces you), one of the things that you should absolutely do is make your system so that it won't send mail to certain user names. Spamming people is one thing; spamming abuse, postmaster, noc, security, and any number of other administrative user names is just carelessness.

(You may be able to guess what our postmaster alias got today, although it was probably actual spam faking the 'someone requested you be sent information' bit.)

The case for vacation autoreplies is somewhat weaker, but I think that they should definitely not auto-reply to at least postmaster. If you can manage it, the best thing to do probably is to not auto-reply to any administrative address that is not at your local domain. Your local NOC or security people might care that someone is not reading their email; the odds that a NOC elsewhere cares is, well, relatively low.

(These days, postmaster is not even an administrative address; it is a system address that is not used by humans, much like daemon. If you are lucky, someone reads email sent to it, but no one sensible sends email from it any more. Addresses like noc and security are still real administrative addresses, in that real people may send email from them.)

And on a side note, putting the IP address that submitted the web form into your auto-sent-out email message does not make your email any less spammy or abusive, or cause people to react any better to it. That particular well has been thoroughly poisoned by spammers (who forge this information in the hopes of distracting people). However, if you are going to do this please insert the same information into the message headers in some relatively standard format, like X-Originating-Ip:, so that automated systems can pick it up and do something with it (although you should already be doing obvious things like not allowing SBL-listed IP addresses to send out email).

(As a tip to would-be spammers, try to make your forged IP addresses come from actual allocated IP address space.)

spam/AutosendExcludeAddresses written at 01:11:13; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.