disobey.com

Wonderful article by Clay Shirky: In-Room Chat as a Social Tool. I never really gave much thought to the utility of web-based chat clients (the only ones I'd seen were pretty bad) but his usage has opened up some interesting streams in my head.

I'm slowly trying to catch up on all my reading, and here's one from before Chrismas: Jakob Nielsen's Top Ten Web-Design Mistakes of 2002:

Every year brings new mistakes. In 2002, several of the worst mistakes in Web design related to poor email integration. The number one mistake, however, was lack of pricing information, followed by overly literal search engines.

Funny. That page isn't Bobby compliant (it's easy to find out - just hit F10, and with a properly configured Mozilla and the free Checky add-on, you're set! Checky is a great utility for caring web designers).

Ghost Sites has succumbed to itself. Good luck, Steve.

A friend recently applied for a job where the employer asked for a sample of your business writing or a sample of previous work that demonstrates your organization, analysis, and logical thinking skills. An example of this type of documentation would be; system analysis documentation, business modeling, process improvements, etc.. He asked me if I had any candid thoughts on what I'd want to see if I was said employer. I'd grade him highly on the following:

• not reinventing the wheel unless absolutely necessary. if you do need to reinvent the wheel, I want to know why. it'd annoyed me to see "wrote a CMS doing this, this, and that", when I could just say "well, why didn't you use this, that, or this? they all do that."
• bullets. outlines are god. bullets let me know that you can take a central idea and simplify it to a single paragraph. it makes reading easier, discussion easier, and leaves plenty of white space for pen scribbling revisions, questions, or additional thoughts.
• sections. think the <h1>, <h2>, <h3> tags in HTML. knowing that you can compartmentalize a process into chunkable bits. this is similar to bullets (but is less points than a tree).
• how to revert your changes. if I'm going to be following your instructions, I want to make sure that I can follow them backwards to undo any mistakes. likewise, if a change can NOT easily be reverted in a few simple commands (and this is some sort of new feature, server changeover, complicated revision cleaning, etc.), I want to see that you've prepared for the inevitable disaster. whenever I write process lists or new feature explanations, I always have a "if this goes horribly wrong, enter this one command to revert". this one command could do hundreds of different things - as long as it was all encapsulated.
• answering unasked questions. prepare me for what I'm going to ask next. if something is going to happen that could raise warning flags ("[err] snizzipt is not installed!"), let me know with a "you may get an error about snizzipt. don't worry about it. or, perform the following...". this lets me know that a) you've run through the process before, b) you know all the various roads less travelled, and how to deal with them, c) you're preparing for things you didn't expect (as with "revert your changes", above).
• reason. if a decision has to be made that's not clearcut, tell me why you chose what you did. I want to know pros and cons, with a special gleam on the future ("whilst we may not need this in the future, it takes very little to enact, and the extra features give us a lot more power if we need them").
• tell me how you solve a problem. tell me how you code. what do you do first? what step do you actually start coding (it's step four or five on my list). what books have you read that have inspired your coding? why do you design databases this way? what have you learnt in the past that make you better than everyone else? how do you document code? do you use a CVS server? how do you handle annoying customer requests after you've begun coding? and so on, and so forth.

Anyone got anything else I could suggest to him (or my readers)? The most recent thing I've written that follows a decent amount of these maxims was my first Apple article on installing Perl 5.8.

I don't think I've ever talk publicly about my feelings on spam, and after reading Moving Beyond RBLs, which I mostly agree with, I figured now is as good a time as any. I'm sure I've nothing new to bring to the discussion, so I'll just begin (I assume you know what I'm talking about).

First off, some background stats. I've been using the same email address since 1997. Prior emails are permanently redirected to my current one. I get about 500 messages a day over a dialup modem, and about 70 of those are spam. I use a POP3 server, and multiple machines ranging from Linux, OS X, and Windows. I work at an ISP. That ISP uses the SpamCop RBL, and blocks 5000+ messages a day because of it. Another 1000+ are due to "invalid user names', which could be attributed to dictionary attacks, old databases, or simply user error.

The machine I'm on most is OS X, where I use Eudora (I also use Eudora at work under Windows 2000). Being a Linux and Perl fan, I've got fetchmail configured to log into my ISP's POP3 server, download the mail, process it through procmail (which forks SpamAssassin), and then deliver all that mail to the Eudora mbox files. I've had this set up in place for about six months, and have used it only once (simply because there's no easy way to map "Check Mail" in Eudora to "fetchmail then restart Eudora so that it'll reload its mbox cache"). Changing email clients is not an option - Eudora works great and I've tried many others... none sit well with me.

Besides the SpamCop RBL, I don't do any further processing for spam. Ultimately, if the SpamCop RBL died tomorrow, I'd be perfectly happy going without any spam protection at all.

Why? Welp, quite simply, I liken spam to TV commercials. When a commercial comes on, I reach for the remote and scan around for something else. The amount of mental bandwidth for me to say 'nope, don't want to watch this' is exactly equivalent to the amount I spend saying 'nope, don't want to read this'. I type Ctrl+D, the email is deleted, and the next one pops up. If it's bad, I hit Ctrl+D again, if it's good, I reply or save it for later. This is why the spam issue is so hard to "solve": I know some people who are absolutely rabid over commercials, praising their TiVos for removing the distraction. Honestly, I find some commercials (and thus, spam) amusing. Far be it from me to remove an avenue of humor, especially considering the world I live in. I don't block web banner ads for the same reason (although I do block popups for disturbing workflow).

And don't forget that the "spam wastes bandwidth" argument doesn't apply just because I'm on a dialup modem. I check my POP3 server about 150 times a day over a 53k connection - it doesn't bother me whatsoever (but granted, I've downloaded 30 gigs of mp3s over a 56k modem too, so I'm probably an oddball here). The benefits of an automated, client-side system like SpamAssassin fail because a) it doesn't integrate with my workflow, b) it's not built into my email program, c) it's not easily crossplatform.

As for the SpamCop RBL, I had a say in whether to implement it on a server hosting 1000+ mailboxes, against SpamCop's own maxim of "don't use this in a production environment". I knew that a) if a bad piece of mail was blocked, it takes me five seconds to whitelist it, b) expecting users to learn new software like Apple's Mail (with its built in spamfiltering) or pay for software add-ons that interact with existing clients, was suicidal - our users don't know how to set up an Outlook Express filter, much less transition to a whole new way of doing things, c) expecting users to proactively send mail to a Vipul's Razor hasher was equally "not part of the workflow" (much less the fact that Vipul's Razor suffers the same "invisible authority" and "is this really a spam?" that an RBL does).

SpamAssassin and other content based filters are too slow to be used on a heavy server, and opt-in systems invariably create more tech calls ("I opted-in and now ALL my mail is gone! All gone! You're blocking all my mail!" when the server logs reflect no mail being send to the user in question). The very thought of an automated filter makes people dream up wild accusations of their importance, as has been the case when new phone numbers are added: "I tell ya, ever since you added that new number (which I've never used, nor do I realize it doesn't affect the number I'm currently using), my connection speed has gone way down! all my email is gone too!". Manual procmail filters are downright time consuming and eventually become obsolete ("m0rtg@ge rates haVE droppped!").

Generically speaking, end users are end users - by the time they're using something, they want everything to be done for them. They don't want to opt-in and they don't want to learn new programs - they just want it to work. With that, along with the implementation and processing restrictions placed on heavy servers with no dedicated "person who deals with spam fulltime", I don't really think there's a perfect ISP level solution. Third party filters that cost money and add another chain of "who's server is down?" is not a viable option, in my opinion.

Laws or their benefits, like Habeas or Lessig's ADV, only go so far geographically and depend upon slow due process. Whitelisting isn't worth the effort, since I get about 150 emails a week from people I've never heard of. To cut this short (as you've grown tired of reading it), as I've been since time began, I'm still happy with ignoring spam, much like I ignore commercials.

I ran out of my deodorant today, so I'm wearing my girlfriend's Secret. It's strong enough for a man (we are stinky beasts! stiiiinkKKy beasTTsts!). I feel fresh. Considering I do less physical activity in a day than she does all week, I should be fine.

This may not be new to anyone else, but this Visual Thesaurus from Plumb Design is pretty nifty. It'll prove much handier than a text based thesaurus.

This doesn't surprise me, but eBay has canceled an auction of minority ownership of two human souls, which I had bidded on:

eBay does not allow the auctioning of human souls for the following reasons: If the soul does not exist, eBay could not allow the auctioning of the soul because there would be nothing to sell. However if the soul does exist, then in accordance with eBay's policy on human parts and remains we would not allow the auctioning of human souls. Therefore, we have ended this auction and all fees have been credited to your account.

This reminds me of an old acquaintance. For some odd reason, some friends that I've lost touch with used to call me "Satan" or the "Devil". One day, during our weekly movie fest, we ordered pizza. We split the pizza evenly, each getting two slices. One guy was still hungry, and asked for my slice. He agreed to give me his soul for it. I made him sign a contract, of which I still have. Muhah!

Odd... Amazon.com decided to change my birthday from April 25th to October 15th on my wishlist page. I wonder if this is related to their "new changes to the wishlist" (which are horrible - I've yet to discover how to view purchased items, as the dropdown menu's don't seem to work for me).

Yes! My goal tonight was to get down to 70 emails or less, from 140+ (all that required answers or other tasks more complicated than just reading). I'm now at 68 - so, it's time for me to go work on some Ratchet & Clank secrets (three more to go, and I'm satisfied).