Monthly Archives: August 2009
A year-long analysis of snack consumption
Consistently, month after month, the chips that get left in the giant ‘box-o-free-snacks’ are:
Nacho Cheese Doritos.
Honorable Mentions: Fritos and Cool Ranch Doritos.… Continue reading ...
New Developer Law
NEW LAW FOR DEVELOPERS:
If you throw an exception about some connection being refused, you'd better damn well put what connection you were attempting to make in the exception message.
What inspired this law? Thanks for asking.
Subversion Branching “Good” Practice
I am relatively new to Subversion — well, two years into using it now, but this is the first project I have used it on. Subversion, like any tool, has its quirks and works best when you really know how to use it. When I started, I treated the "trunk/branches/tags" directory structure exactly like a directory structure. It took me a little playing around until I stumbled on what I would call a best practice. When I checkout a new project, I do it like so:
svn co http://domain.com/svnroot/project/trunk project
That way, when I go to the project directory, I do not have to then go into the trunk directory to get to my files.
The Cheated Frogs of Vim
We're still too small of a company to have more than 1 or 2 logical groupings of the development team, and before today they've been basically "the web team" and "everyone else." Of course, there's a lot of cross-pollination and everything nowadays ultimately manifests itself somehow as "'web".
Still, the "everyone else" paint brush was wearing thin. In addition to the "web team", we had "the scale team" (a.k.a "Ops R&D") and "the AMI team" and "the core team" and "the report team". . .but most of those were "teams" averaged size 1 and their membership varied from iteration-to-iteration.
Measuring our awesomeness iteration by iteration
Like a lot of startups (and big companies!) we use iterative development: we break up our work into "stories" describing features and implement as many as we can in one month. We then repeat that until we conquer the world. But, if we can do more, or work more efficiently with each iteration, our goal of world domination will approach that much quicker :)
The easiest way to do that is to look at the bugs our QA staff find in the product updates. Although we have a lot of automated tests, we still need some eyes on the applications to check for things like text overruns of our printed reports, or JavaScript weirdness in some less-than-well-behaved) browsers.
Move meetings to move developers