Hank Wallace turned me on to a post by Allison Shapira where she summarizes a key point from Rob Walker's writeup of the Blue Man Group - the "Why To" manual.

This "Actors' Journal" is not so much a how-to manual as a why-to manual; it's not about stage directions, but rather tells the story of the show step by step, from the point of view of the Blue Men. As a decoding and deconstruction of Blue Man's at-times baffling, even mystical behavior, it's a fascinating document, thick with references to everything from Being There to George Bernard Shaw to Robert Motherwell to the caves of Lascaux. Some explanations are straightforward ? "The Blue Men are not aliens" ? and others are more subtle, as when the trio's harmonic "three as one" relationship is described in terms of "blesh," a mix of blend and mesh borrowed from Theodore Sturgeon's science fiction novel More Than Human.

What would a "Why To" manual look like for a development team?

Miško Hevery has written a great summary of some basic coding rules for testability in his post Writing Testable Code.

I love this quote because every time I introduce unit testing to someone who has an existing code base you can see this in their eyes:

"I understand how to write tests for your code, but my code is different"

He goes on to list the rules most often broken by developers that make unit testing hard in his top ten list:

1. Mixing object graph construction with application logic
2. Ask for things, Don't look for things (aka Dependency Injection / Law of Demeter)
3. Doing work in constructor
4. Global State
5. Singletons (global state in sheep's clothing)
6. Static methods: (or living in a procedural world)
7. Favor composition over inheritance
8. Favor polymorphism over conditionals
9. Mixing Service Objects with Value Objects
10. Mixing of Concerns

Via Jeremy D. Miller

This post by David is hilarious (warning programmer humor...)

Scott Hanselman has started a podcast called HanselMinutes to talk tools and utilities. Episode #4 on Continuous Integration caught my attention because of 2 names mentioned during the discussion of the Ruby Watir library. Both Dustin Woodhouse and Travis Illig got mentioned because of tools they have written to integrate the Watir functionality at development or test time. Travis wrote RubyTestExecutor which hooks Ruby/Watir scripts up with NUnit. Dustin wrote WatirNUt which is a utility that creates a portable, testable NUnit binary wrapper around Watir test scripts and supporting files.

These two individuals and their tools are interesting to me because they both work on teams I manage and I'm excited to see my guys pushing the envelope.

Scott was also kind enough to mention me as one of the local XP experts (my 30 seconds of podcast fame).

Darrell pointed me to this site on International Addresses and the complexities therein.

Darrell is using this from a testing point of view, but I have been fascinated for years about how to design an effective solution for US based systems that need to deal with foreign addresses. This will be a great resource.

Borland has released a version of Together Developer that integrates into VS.NET. Check out the screen casts. I'm thinking that Together combined with ReSharper from JetBrains could be one killer combination.

Jim Shore wrote about why he doesn't like Cruise Control. I agree to some extent with his points that the reason teams use it is to catch build errors and deal with "slow" builds. Having implemented both Draco.NET and CruiseControl.NET and toyed with FinalBuilder I am not overly impressed with any of them. My impression is that I spend way to much time fiddling the build server for the value added. I will say that I would still implement a build server for any team for the single reason that "people are fallible". People forget to commit related changes, or add files to CVS, run tests, etc. The build server never does.

Some of you may be rolling your eyes at this suggestion, but it's been bugging me for months and I finally figured out how to fix it.

For many moons I've been editing T-SQL stored procedures using VS.NET, but been annoyed because every time I when to the graphical query designer it didn't know anything about T-SQL variables (i.e. @MyVar). I could get around this by right-clicking the SQL pane and changing the property page. Very conveniently the designer deleted all your SQL when you do this so I always had to remember to copy my SQL change the property page and paste the SQL back in.

Turns out there is a setting in Tools: Options: Database Tools: Query/View Designer that will take care of it.

I had a need (creating CSV BCP files) that required knowing the column names of a MS SQL table in the order they were created. Some inspiration from Mark Clerget and a little fooling around with SQL Query Analyzer resulted in the following.

DECLARE @c varchar(4000), @t varchar(128)
SET @c = ''

SET @t='authors'


SELECT @c = @c + c.name + ', '
    FROM syscolumns c INNER JOIN sysobjects o ON o.id = c.id

    WHERE o.name = @t
    ORDER BY colid

SELECT Substring(@c, 1, Datalength(@c) - 2)

Which gives the following result:

au_id, au_lname, au_fname, phone, address, city, state, zip, contract

Perfect. Note the use of @c = @c + c.name in the select clause to colapse 9 rows into 1 row. I've used this technique many times in the past to generate a single string from multiple rows without resorting to cursors.