I'm hip-deep in a project that involves structuring information stored in one system for transmission to another using a very specific format and protocol, and part of the process involves generating a list of fabricated names, a benefits number, and date of birth. The latter two are easy, since they just require a random number generator, but I wanted to solve the name issue with
cleverness, and come up with some reasonable-looking pseudonyms. After all, the programmer's credo is:
if it's worth engineering, it's worth over-engineering.
I've mined the baby names lists from the U.S. Social Security Administration before, and opted to pull a subset of names from the
1880 and
1890 data files. For last names, I turned to
Wikipedia's entry on common bird names, and after a little scripting and hackery, have it generating me a random list of patients with a very
Wodehousian flavor. Since I usually struggle for names in my own writing, I decided to keep the script for my own use, just in case I need something moderately ridiculous.
And taking a page from the book of the Typosphere's own Duffy Moon, I decided to
over-over engineer and also come up with a set of professions for my silly characters. Duffy's technique, if I recall, was to open the telephone directory listings and combine the alphabetical section headings at the top of the page, treating the two index words as the parts of an interesting-but-rarely-normal job title. Category lists are easy to come by online, so I added these to my script's data sources, and hey presto, the nymomatic was born. Now I can contemplate the fictional life stories of "Florence Waxwing, Photography Plasterer" and "Grace Jay, Motorcycle Moistener" and perhaps wonder how "Christopher Albatross, Thermostatic Toilets" got into the business. And if you're very good, I shall whisper you the tale of "Franklin Dove, Turkey Upholsterer"
Part two of this ramble has to do with those submission-and-response files, stuffed full of the exploits of "Etta Magpie" and "Glenn Ibis" and "Cornelius Kingbird" (who is in the Wildlife Wax line, I might add.) They are sent as a single stream of text, and received as the same, with no line breaks. Anyone who has to program text files needs to worry about how different systems say "this is the end of the line, start a new paragraph."
On Unix-ish machines, it's denoted by a "newline" character, which is usually written
\n
Before Apple got smart, they used to end text files with a "carriage return" character, thus:
\r
Operating systems claiming a DOS ancestry use both, in combination:
\r\n
These were originally teletype commands, meaning to literally return the carriage
\r and advance the line one stop
\n. Of course typists will recognize this system, since it's exactly what you do when you manually throw the carriage as you type: return it, and then push on the lever a little more to line-advance.
Line endings are one of those things you take for granted until you get bitten by them, since most of our software handles the translations from one system to another automagically behind the scenes. But when you're hip-deep in test data, trying to reformat the exploits of Lou Cuckoo (Lead Lamps) and Nicholas Sandpiper (Singles Shredder) one gets reminded of the legacy of typing and the persistence of old standards. You may now look lovingly upon your QWERTY/QWERTZ/AZERTY keyboard.
Concerning my
previous post's cry for editing guidance, I have decided to follow your collective sage advice and just soldier through what I was doing, which was to edit in full, not to reduce-and-expand. I did give myself a little bone, though, by dropping in "finish lines" throughout the body of the text every 25 lines. When I'm able to edit, I tell myself that I only need to make it to the next finish line I have marked -- but once started, I'm not allowed to quit until I hit that mark.
There's no scripting my way out of this one. I have to work the text one
\n at a time.
