2004.08.24
So, FoSO and I worked together on an interesting furniture project, a cabinet. I think the idea was mine, but the details and the lion's share of the labor ended up being hers. (Which is good, because I'm lazy, but also bad, because I didn't learn quite as much as I had hoped.) My bathroom is desperately short on selfspace, and I'd always been trying to think of a cool project to utilize these beautiful authentic vintage travel stickers that were attached to a crumbling valise I got at an estate sale kind of thing. So, a bunch of slicing, scanning (just in case), staining with wood stain, gluing with Mod Podge, coating with polyurethane, and touching up with a hand sander later, and this is the terrific result:
| Front | Inside | |
|---|---|---|
 |
 |
Progamming Thoughts of the Moment
Been thinking a little bit about programming rules in general. Here are some rules I've decided I (and maybe everybody) should try and follow...I welcome feedback from my fellow coding geeks.
- K.I.S.S.: Don't over-engineer.
- I have seen so much over-designed stuff, with layer after layer after layer. Following the programming execution over a single call becomes an enormously difficult task. If any given interaction goes much deeper than 3 or 4 levels, something might well be wrong.
- Keep a clean modular approach to your systems.
- Have a core engine that drives everything and uses the rest of the system as an API. Think Unix's philosophy of "do one task and do it well"...this guideline comes from stuff I'm dealing with at work. They've developed these APIs, but the APIs are so tightly integrated with the logging and configuration, it's sick. For example, they made a wrapper to a Castor routine that converts an object into an XML representation. You would think that if your central program says "make me an XML representation of this object and put it in such and such a file" it would do just that, right? But no. See, it goes ahead and checks the configuration on its own accord, and then might or might not do the conversion. And whether it tries or not, or if it succeeds or fails with some error, it will do so SILENTLY, catching any exception that occurs, because heaven forfend that the main program has to worry its sweet little head about everything collapsing underneath it... Hideously redundant, impossible to follow.
- Keep a devnotes.txt file
- I find it useful to have a single text file where I jot things down as I figure them out...usernames, passwords, techniques, etc. It saves me a lot of time.
- Consider disabling web access during the workday.
- Sometimes it's easier for a programmer to get distracted, especially when things aren't going well. The worse things are going, the more slashdot and various techie websites beckon. ("This task at hand isn't working out but maybe I can learn something else new!"). If your main browser is IE, the easiest option might be to go into Tools|Internet Options|Coonections|LAN Settings and setup a bogus proxy server. Sometimes just putting in that little gatekeeper is enough to make me reconsider a wayword path.
- Keep your unit tests close and your smoketests closer
- If your environment is at all complex and N-tiered, avoid the trap of your system breaking down and you don't know when and you don't know why by setting up good smoke and unit tests and running them extremely frequently.
Product of the Moment
Making the rounds is this story about a cellphone based Virtual Girlfriend product...unfortunately (or fortunately for the company) you spend non-virtual money to buy her presents and what not, otherwise she gets all mad and sulky.
Man, what a potential goldmine if they find guys who get really into this. Being able to sell trivial virtual goods for real cash...there's that other company that lets people buy each other little iconic gifts, I heard it's a reasonable hit...it becomes a social thing I guess, if you can show off your gifts like some kind of trophyroom.
Strange world.