5:33 a.m. Miami. For lack of anything else around, I reread "Seizing the Enigma" I know it's after the fact, but I can't figure out why it was so difficult to crack the code that was basically arithmetic in the pre-computer days. Even B-Dneist was free rollers and a pegboard. I'm no cipher genius but I just instinctively feel that no matter how complicated you make such a mechanical system sooner or later you're going to stumble across a letter frequency.
True I don't know how people thought in 1940, but I know they had a thousand brains working on it. They had the electromechanical models called "bombes" and working captured sets of the Enigma.
I was studying the techniques used to crack the code because I always put extra effort into keeping my own databases very simple. Anybody can design a complicated database, it takes talent to streamline it. Not just intelligence, but talent. There is often a complex into relation between sets not obvious to everyone. Some manuals refer to it as meta-information, the subtle joins between what appears as an enjoyable data tables.
I've been tempted to go back to school to learn Visual Basic, the highly bastardized form of BASIC from the 1970s. I could probably do the coding right now if I could spend an hour or two with somebody who would show me how to connect the code to the screen objects. I can't find any clear manuals that spell this out that is it is a point all the manuals I've read tend to avoid. They'll tell you the code, they'll describe the object, but won't show you simple examples of how to make it work.
This is a point I know I've repeatedly made over the years. The textbooks about object oriented programming never give simple start to finish examples of practical coding. They only talk about it. Today I was trying to program a screen button to alphabetize a list. I got the code, I got the button, I got the list.
It's frustrating. I can produce a 30 or 40 layer deep report without a second thought but can't find the instructions to automate it. That's what I was working on today. A report that pinpoints companywide breaks and lapses in the flow of information. Actually, I've always know which sites were guilty, but one still needs understandable evidence. For no matter how many people I explain that the data only finds fact and not fault, I'm reminded of how Tom put it, "Yes, but it's their fault facts are wrong." Ha!
