New Developer Law

By Tom Vaughan in Best Practice, Code, Development | August 26, 2009

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.
Continue reading ...

Subversion Branching “Good” Practice

By Jeff Kolesky in Best Practice, Code, Development | August 23, 2009

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.
Continue reading ...

The Cheated Frogs of Vim

By Tom Vaughan in Culture, Development | August 20, 2009

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.
Continue reading ...

Measuring our awesomeness iteration by iteration

By Dave Copeland in Code, Development | August 19, 2009

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.
Continue reading ...