I have to stick with Vista as my primary work horse because the majority of my time is spent developing applications that require IIS7 (WAS).  While VMs are an option and I use them for many different development tasks, they are quite a bit slower and I’m not working on a lot of different projects these days. 

My primary development machine is a lenovo (IBM) T60 Thinkpad w/ 4GB RAM and two 100GB 7200RPM SATA internal drives w/ Vista x64 Business installed.  A fairly beefy laptop and I’ve been really happy with its performance, but once it starts swapping it can get rather SLOW…  Some digging revealed it was disk I/O I was waiting on most the time, enter the SDD to the rescue.

After getting everything reinstalled and working with the new configuration I noticed some improvement but it just didn’t jump out at me.  Boot time was the most notable change going from 4 minutes from power to usable down to approximately 90 seconds from power to usable.  A boost to say the least but not the productivity enhancer I was hoping for.

Then it happened, I ran into an issue that would be faster to just plug in my old hard drive to take care of than going through the process of configuring my laptop to work on the problem at hand.  After going through the painful boot up and loading visual studio I couldn’t believe how slow the computer was.  Visual Studio was constantly performing disk I/O (most likely resharper’s cache) and everything just seemed to crawl once I had three instances of VS 2008 up and running.

All in all I’m extremely happy with the purchase and realize that I just can’t go back to 7200 RPM laptop drives *sigh*…  Hopefully the prices on the SDD’s will keep coming down, and soon

Well, with Monday’s release of Service Pack 1 for the .NET 3.5 Framework our reporting solution came crashing down.  A quick search on Google showed quite a few others that where using WPF within ASP.NET were running into the same issue, and of course Microsoft’s response, which to be fair Microsoft said from the begining 2+ years ago, is that executing WPF in a service is not a tested or supported scenario. *SIGH*  The silver lining is that the SP1 enhancements do launch our client application MUCH MUCH faster. Great job on the cold start issue guys! In the mean time, we’ll be moving back to PDF as our standard for fixed documents until there is supported XPS creation hosted under the service model.

So back to the drawing board on searching for a reporting solution common to both.  So far PDFSharp is the front runner. It has an extremely open license enabling us to incorporate it into our commercial application, the source code is very clean and the object model is proving to be very intuitive. The library incorporates MigraDoc Lite for document management and they are actively adding native WPF support into the library. The GDI+ API works well for both our WPF client and ASP.NET app. Kudos to empira Software® for releasing a solid document creation API!

Code Generation starts with the recognition that many of the patterns used in enterprise development are repetitious.  Many tools have been created to tackle these repetitive tasks and generally come in two flavors.  The first flavor is code generated from a source that will never be hand modified.  If the source changes, the code is simply regenerated. The svcutil provided in the .NET 3.0 framework would fall into this category.  The second flavor generates code that is intended to save developers from a lot of copy and paste operations but will still require some manual editing by the developer.  In this case the code is generated once, but then is never regenerated if the source changes.  (note:  Partial classes have done a lot to help seperate out what can be regenerated without breaking custom changes, but the gen once paradigm described is intended to jump start the manual coding process)

Test Driven Development (TDD) requires that a test be written and fail before any code can be written.  Once you have a failing test, on you go to fix the code so the test passes.  See Introduction to Test Driven Design for more on the overall process.  Following this process results in a clean, minimalist API with extremely high automated test coverage.

Code Generation and TDD come into conflict when development teams implement strict test coverage requirements in their continuous integration environment.  Code Generation that will never be hand modified can skirt this issue through the use of attributes such as [System.CodeDom.Compiler.GeneratedCodeAttribute] which tell the coverage utility to exclude the following class, property, or method from the coverage metrics, however, we still need to address code that is generated to jump start manual coding.

We can still follow TDD using Code Generation to augment the process to get the best of both worlds.  The key is to create templates that generate the smallest unit of work possible instead of the typical “generate everything” paradigm.  Lets take the simple task of adding a data entry screen in a typical ASP.NET application following an MVP pattern (note:  for a good succinct discussion of the difference between the MVC and MVP pattern see Daron Schall’s post titled MVC vs. MVP).

Story Tasks:

1. Create the database table
2. Test the domain model representation of the information
3. Test the CRUD operations of the repository (for illustration purposes this story does not require the ability to update the entity)
   1. Test Adding a new entity to the repository
   2. Test Finding an entity within the repository
   3. Test Removing an entity from within the repository
4. Test the Business Processor responsible for manipulating the entity
5. Test the Service responsible for exposing the functionality to the UI
6. Test the Service agent responsible for communicating with the service
7. Test the Client Model
8. Test the Presenter responsible for executing user initiated actions
9. Create the page and wire up passing events to the presenter.

Execute task one using your favorite database utility and add the resulting script to source control (hopefully in a dbDeploy.NET script)

To execute task two, write the unit test asserting the expected properties are present and functional, then use your favorite code generation tool (Code Smith is my personal favorite) to generate the class from either the table or preferably the select stored procedure. Run the unit test and validate it passes.

To execute task three, write the unit test for the first sub task, develop the required stored procedure, generate the Add methods code from the stored procedure, verify the test works, rinse and repeat for each task.

For task 4 I break with TDD slightly in that I right all of the tests for each method the business processor exposes (and in the 90% case simply delegates) to the repository.  After all three tests are written I generate the complete processor from the associated compiled repository class.  If you use Code Smith for generation custom property Assembly and Type / Class Selector is invaluable for using .NET types as source objects for generation.  By generating the processor from the repository and not the database you do not end up with an Update method the story doesn’t require.

The rest of the tasks follow a similar pattern of writing the test, and then using a template to generate the stub code to satisfy the test.

Following this process has greatly increased my velocity and still results in the clean, minimalist API obtained through TDD with a high level of test coverage while virtually eliminating the copy, paste, massage routine for tasks that follow the 90% rule thanks to the judicious use of Code Generation.  Leveraging templates through Code Smith’s Active Snippet feature in VS 2008 is the icing on the cake!