Larry Smithmier: C# For You (with a side of SQL)

Microsoft Windows Internals by Mark E. Russinovich and David A. Solomon
You can be a good Windows programmer without knowing what is going on under the covers, but you can never be a great one. Without understanding the environment your programs run in, you will never be able to anticipate the way someone who does can. I love the way this book is layed out. You begin with an overview that forshadows the depths found in the latter chapters. This book will help you move from the small pond out back into the larger lakes and streams that the better professionals frequent. It also gives you the tools and knowledge necessary to chart the deeper regions off of the contental shelf.

Inside Microsoft SQL Server 2005: T-SQL Querying by Itzik Ben-Gan
This book takes you through Query Tuning, out the other side to exactly why this way is faster than that. He also helps you build up a set of tools and techniques to get to information at a lower, more accurate level than what is available using the GUI Profiler. This is not a book to teach you how to write better SQL. This is a book that helps you understand why some SQL is better than others. If your current SQL is like bass fishing with a plastic worm, a rod, and a reel; this book will help you move your SQL game up to the Bass-Masters tournament level, with the Ranger boat and 15 different color worms in 7 different shapes with 5 different hooking patterns.

The Guru’s Guide to SQL Server Architecture and Internals by Ken Henderson
This does for Microsoft SQL Server what the Windows Internals book does for Windows. This book explains how the envrionment that MSSQL is running in changes how you optimize the database environment to meet your performance goals. It is sort of like saying that you need to know if you are going to be sailing on fresh or salt water before you design the boat that you will be sailing on. For 99.5% of the people dealing with databases, the information in this book will be severe overkill. But, if you are the type of person who needs to know why something behaves the way it does, this is the book for you.

One of the cornerstones of the type of Extreme Programming (is it more Agile Modeling?) that I am interested in pursuing is unit testing. You start with your requirements and build use cases from them. You take your use cases and build unit tests that test the functionality displayed in the use case. I want everything to be documented and the documentation to flow all the way back to the requirements document. This way, you can pursue changed requirements through the use cases and unit tests down to the objects that support them.

To get started with unit testing, grab NUnit from http://www.nunit.org/ and take it for a spin. I have used NUnit in a project before, and loved the structure that it provided. Test-driven development is when you begin your process by writing tests that cover your requirements and then write code until they all pass. Start with a simple sample testing suite:

and add tests that cover your requirements. Writing good unit tests is not as easy as it sounds, it takes time and effort. While you are creating your tests, you are also defining the solution set that your program will generate. As you develop your code, your goal should be to reduce the number of tests that fail.

So how do you integrate this into your NAnt build file? This is something I have never done before, but it turns out that you would simply add a section to compile your unit test dll and then change the test block as follows:

Be sure and note the reference section and the nunit2 section.

Another topic that I would like to pursue is Spec#, an extension to the C# language to allow for provable code. See: http://research.microsoft.com/specsharp/ for more information on it. I will be trying to decide how to integrate it into my process.

It is also good to note and acknowledge that the mechanisms that work for a single individual may not scale to a group of 5 or, worse yet, a group of 500. I am going to attempt to keep to procedures that appear to be scalable enough to handle groups of up to 20 programmers. I will also try and identify those pieces that I feel will have trouble scaling beyond that.

I have been spoiled by Visual Studio for far too long.  It is time to come back into the real world and begin using build tools like a grown up.  To assist me in my transition from code monkey to XP Programmer extrordinare,  I have enlisted the assitance of Pro .NET 2.0 Extreme Programming by Greg Pearman and James Goodwill on APress.

Being like one of those precotious children who wants desert before they have eaten, I will dive directly to the tools section.  I should understand the tools before I worry about the structure, right?  Surely they put the tools way back in chapter 6 at the behest of an Editor that was out of touch with reality?

Anyway, enter nant (nant-0.85-rc4 to be more precise).  Installing is simply downloading it from http://nant.sourceforge.net/, unzipping it, and adding the path to the bin directory to your PATH environment variable.

To use it simply create an xml file named .build with all of the options you want and type nant from a command prompt.  It will automatically pick up the .build file and do the default action.

Let us look at it by watching a project grow from a small seed into a giant redwood.  Today I begin (well, not actualy begin, more begin to document for posterity) the first project I have documented from beginning to completion.

I won't mention the type of project it is, or tell you what it is going to do, I will just let it unfold.

I will re-start the project with a basic NAnt build file:

This will take the .cs files and the resource files and build them into an executable. 

Awesome isn't it? Well, that will be it for part 1.  I am now going to go back and build unit tests for my project using NUnit and I will document my trials in Part 2.