The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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%.”

Donald Knuth

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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.