Jay McGavren's Journal

There’s a travel freeze and a hiring freeze (despite the fact that our department is severely understaffed). They’ve just announced that they’re halting 401K matching for the rest of the year.

Right now, I’m just hoping I get a severance package if I’m laid off. We need it to sustain us while I hunt for a job.

F:workwedding>cvs log wedding_guest_list.sxc

RCS file: f:developmentcvs/wedding/wedding_guest_list.sxc,v Working file: wedding_guest_list.sxc head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: b total revisions: 2; selected revisions: 2 description: —————————- revision 1.2 date: 2005/07/27 06:41:02; author: jay; state: Exp; lines: +37 -37 Finished copying info from Diana’s printed sheet. Added address info for some of groom’s guests. —————————- revision 1.1 date: 2005/07/20 02:18:08; author: jay; state: Exp; Initial commit. =============================================================================

Taste profiling...

Audioscrobbler/last.fm finally calculated my “musical neighbors” (people with similar taste to me, as judged by the tracks they play), and now my profile radio is running. It’s pretty good at guessing songs I’d like, even though I’d never seek them out on my own. (Of course, it also plays a lot of tracks I already have, but for someone without a large music collection, it’d be a godsend.)

There are other systems similar to Audioscrobbler’s for news and movies, but none seem very polished yet. But the day is fast approaching when everything - Flickr pictures, Web links, TV shows - is retrieved for you automatically based on what you’ve downloaded in the past. You’ll just flip on your set-top box, and something you (probably) want to see/hear will be there waiting for you.

Of course, spam could easily prove a problem. Audioscrobbler already had to set up throttling to stop people from artificially inflating the rank of their favorite artist. One could imagine a spammer building a profile identical to yours (hey, look how similar our tastes are! you should listen to some of my music!), then inserting a link to their own Viagra ad. We’ll need trust networks to go along with these recommendation networks…

Learning the hard way...

Over the past two projects, every time I’ve realized I made a mistake, I’ve made a note to myself. (“Lessons Learned”, in business jargon.) Here’s a collection. (Yes, some of these are “well, duh” statements - they’re here to document situations that I let business inertia drag me into.)

-Check project management resources for frequently missed items in estimating project timeline. -Be sure to to document user classes and areas of interface they must be allowed to access/denied access to. -Release Management/Operations needs to know when daemons actually terminate if they don’t die right away. -Set up one of every type of network connection on localhost for dev (and other environments), so you can test functionality that uses these protocols. -Structure modules/methods in such a way that they can be easily unit tested! -Support all options for a protocol in your config files, not just those you initially plan to use. -Document default values for all configuration options, reasons behind them. -Ensure systems administration and database administration are on signoff list for technical design, so they can raise security/efficiency issues. -Never use any unencrypted protocol, even within an intranet; other departments are likely to block it. -Estimate time up front to build unit/integration test harnesses, builder/installer for all environments. -Project managers always assume developers will be allocated 100%, when in fact it is more like 80%. -Note all servers for project and types of connections made by application, then request setup from Systems Administration prior to beginning coding! -Plan around reloading config before accessing each option, so changes can be made without shutting down. -Use one config hierarchy for everything, so you don’t have to manage multiple files. -Allocate time for TDD revisions, as other departments review it for the first time. -Calculate expected load on networks, databases, etc. in advance. -Ensure vendors fully understand all requirements (and their difficulty) before signing any work agreements. -Don’t accept specifications that are vague or open to interpretation, as requester is likely to reject finished product. -Write down all figures you give to others in meetings for later reference (such as effort estimates). -Skimping on code reviews costs almost as much time as it saves, and may result in a lower-quality product. -Monitoring tools must raise alarm if items in processing queue get too old. -Manual installation of files not advisable. Consider making RPM. -Specify precise file locations and names for each module in technical design. -Maintain separate config directories for development, testing, production! -Ensure all generic accounts (FTP, database, etc.) are created well before rollout! -Specify whether paths will be absolute or relative. -Use ‘set’ as a verb in method names rather than ‘add’, unless you intend it to fail if the value already exists. -Perl is a poor language for outsourcing. -Perl is a poor language for building large applications.

Heh… Six years later, people are still discovering Ganon’s Revenge. (And no, I’m not gonna give her any hints. Heck, I don’t even remember most of the design. Hmmm, I should play it again sometime…)