Monday, March 12, 2007
Steampunk Star Wars
This is for Jeff Cuscutis, who likes this sort of thing:
Massive Solar-Orbiting Electro-Mechanical Analytic Engine, Mark 6
This enormous Imperial space station, the size of a small moon or asteroid, is in fact an immense analytic engine, a device capable of making millions of calculations every day. Inside is kilometer after kilometer of tubes and wheels, cranks and gears, all spinning and clacking, spitting out an endless series of numbers for the Imperials scientists to decipher.
Via kisrael.com, E ric's Terrible, Horrible, No Good, Very Bad Idea: steampunk star wars
And the accompanying pictures are cool too (secret message to Jeff: can I get a Phlogisticated Aether Torch?).
Premature optimization
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
Since when did correct data typing in the production database become optimizations???
Comments on We'll Optimize Later
This is echoing a feeling I've had now for the past year or so—the phrase “premature optimization is the root of all evil” has been so drilled into programmers that it seems like no thought at all is being employed.
Technically speaking, writing code is “premature optimization.” Why bother even writing code when we can call upon the mighty powers of the lazy web to see if it's been written already. Or something close. Heck, it doesn't even have to be close, as long as it's code that can be adapted (just try to ignore the time factor when it takes longer to adapt code than it would have taken to write code from scratch, which may make a better impedance match to the rest of your code).
So remember, thinking about your code is a form of premature optimization.
Hammers and nails
Before I started at The Company, Smirk used a spread sheet to keep track of IP address allocations. It was easy to set up and edit and it worked for him. Besides, he has it running anyway to help manage the finances of The Company. So why not use it?
Then I took on the job of allocating IP addresses. I used (and still use) text files (one for each Class-C block we use). It was easy to set up and edit and it works for me. In fact, I use text files extensively to keep track of all sorts of things at The Office, from firewalls to managed power strips.
When P started, he set up Twiki as the company knowledge base. I don't know how easy it was to set up, but P seems to find it adequate to use and is currently a bit upset that he's the only one who bothers to update it. I personally don't find it that easy to use and consequently, I don't use it.
Personally, I'm picky about editors, and while I can't say I love joe, I am comfortable using it. But heck, I'd rather use Emacs to edit than the crap editor you get in your web browser du jour (and yes, that includes Firefox). That partly explains why I dislike the Twiki (there are other reasons), and don't even use my own web interface to post entries here (it's almost exclusively the email interface).
The problem here is, all three of us use different tools to manage certain types of information about The Company, and because of that, we don't have a true company wide information base that we can rely upon.
And no one has an idea of what we should use, because of how we all work.
