Edited with an introduction by Charles Neider, Da Capo Press, 1998.

(This book is only 798 pages, but I’ve been reading it for over a year. And you thought I’d just given up on posting about books.)

Washington Irving is known for a number of things: being the first professional literary writer of North America, creating of the character Diedrich Knickerbocker (for whom New York is called the Knickerbocker State), originating numerous popular legends (e.g., people though the earth flat until Columbus), and, of course, authoring a few famous stories such as The Legend of Sleepy Hollow, Rip van Winkel, and The Devil and Tom Walker. According to Neider, there was an anti-Irving backlash in the 1930s, which is probably why I was only familiar with the three tales mentioned above.

Irving is an amazing storyteller. Even given nearly two hundred years’ gap, his writing is still crystal clear and humorous and evocative and beautiful. He sketches out the Kentucky frontier, ghost-plagued swamps of New England, pre-Revolutionary War Dutch settlements in New York, medieval Spain, the mountains of Italy, and more with equal skill, each believable and very visually rendered. He tells rip-roaring adventures, satires, or fairy tales in those contexts. Some are simple — predictable, even, twee or corny to the modern reader — and yet the enthusiasm and charm with which he writes them makes it easy to forgive.

What really shines through in this collection of sixty some-odd tales, however, is how much Irving loves storytelling. He likes it so much that many of them are really framing stories, wherein the narrator meets up with some other character who tells a story — which may well itself be a framing story. Sometimes, I found myself popping out of a story-stack five or six deep.

Don’t let Hollywood’s pathetic interpretations sell Irving short. These are a lot of fun to read.

Well,not really. This is just one example of a bad approach.

The problem: an HTML file is read, but needs to be entity-escaped. However, not all entities need escaping. Specifically, double quotes with anchor tags need to be left alone.

The right solution: process the HTML via a DOM parser, escape nodes that are not anchor tags. Oh, but did I mention these HTML files may be crappy, non-validating files, or even snippets?

The next solution: Use a regular expression. Yes, this is ugly. Yes, it also works 🙂

Originally, I tried using variable-length lookahead, but ran into problems (PHP 4.x). But PHP provides another solution which is perfect for this sort of thing. Here’s the code:

function pre_esc_quotes($inner)
{
return preg_replace('/"/','QUOTE',$inner[0]);
}
function post_esc_quotes($inner)
{
return preg_replace('/QUOTE/','"',$inner[0]);
}
$tmp=preg_replace_callback('/<a([^>]*?)>/s','pre_esc_quotes',$raw_html);
$tmp = html_entities($tmp);
echo preg_replace_callback(('/</a><a([^>]*?)>/s','post_esc_quotes',$tmp);


This, of course, presumes that the string “QUOTE” won’t show up anywhere in your raw html. Consider replacing it with an opaque string (like “JHG54JHGH76699597569” or something creative and long that will choke the interpreter).

This code is furthermore inefficient in a number of ways. It’s not something you should use. But it does show how preg_replace_callback avoids some scary regex work.

The need arose to have a specific email address round-robin (e.g., cycle through a collection of destination email addresses).

A solution was achieved through use of procmail and a little perl script. It probably could be done more easily and/or better, but I figured other people might find this interesting.

So, first, an alias was created in /etc/aliases (used by postfix in this case, but it should work for sendmail, and variants should work for other MTAs):

rrtest:         |"/usr/bin/procmail -m /etc/postfix/roundrobin_procmail.rc"

Then, the following file was saved as /etc/postfix/roundrobin_procmail.rc:

:0 w:/tmp/rrlock
{
        :0
                dest=|/etc/postfix/rr.pl
        :0
                ! ${dest}
}

And then, of course, we need the perl program. Here’s /etc/postfix/rr.pl:

#!/bin/perl
# ----------------------------------------------------------
@recipients = (
'address1@sample.com',
'address2@sample.com',
'address3@sample.com'
);

$index_file = 'rr-index.txt';

# ----------------------------------------------------------

$index_exists = 1;
open(IN,";
        close(IN);
        $index++;
        }
else
        {
        $index = 0;
        }


if ($index > $#recipients)
        {
        $index = 0;
        }
open(OUT,">/tmp/${index_file}");
print OUT "$index\n";
close(OUT);

print STDOUT $recipients[$index];

exit 0;

Elegant? Not really. But it seems to work 🙂

As in, zero. Gar nichts. Zero posts in April, to match the zero posts for February. You might just figure that I’m lacking initiative on this writing stuff.

Chalk it up to:

• Being busy at work.
• Writing code on the side.
• Playing with Photoshop Javascripts to create strange flower Mandalas.
• Having shoulder pain (due to inexplicable adhesive capsulitis — an ailment typically found among diabetic women aged 5-70 [!?]).
• Reading very slowly through massive anthologies rather than shorter works (currently about half way through the collected stories of Washington Irving).
• General Springtime ennui.

Perhaps May will see more activity. Perhaps not.

Loath as I am to admit it, I know why Microsoft products all suffer from creeping featuritis. It’s because users are so damn creative.

In developing modules for CMS Made Simple, I’m continuously receiving feature requests. Some are reasonable. Many are not.

Reasonable:
“Could you extend your can opener to handle sardine tins as well as standard cylindrical cans?”

Unreasonable:
“I know it’s supposed to be a can opener, but I find it works well in extricating people from burning wreckage, so I was wondering if you could add a fire-hose feature, and maybe a siren or flashing lights.”

The skill I need to develop is saying “no” in an acceptable way. It’s easy when the requester phrases the question like “add this, or I won’t use your stupid system!” Yeah. Well. Golly, I’ll be awfully sad to see ’em go. Similarly, the ever-popular “it’s embarrassing to tell my client that I can’t provide them feature Y because you didn’t implement it!” always brings me copious, bitter tears at the thought of their shame and tragedy. Cry me a river indeed.

It’s a bit harder when the request is along the lines of “to be a truly professional system, it really should have feature Z,” because then I have to assess whether or not it really would be a professional grade feature.

Hardest yet is when someone requests a feature and gives at least a basic explanation of why it would be good for the project as a whole (in addition to their specific need). Even if I can’t see that I would use the feature myself, this will often sway me and I’ll add features, even against my better judgment.

Then, of course, there’s cash, which has a peculiar way of getting features added, no matter how ridiculous.