SQL Server 2008 express

I spent the better part of today attempting to get my (Windows Vista Business :/ ) system to a state where I was able to run the installer for SQL Server Management Studio 2008 so that I could access a 2008 sqlexpress instance running on another machine. It's finally running the installer as I type this and the annoying thing is that my friend was able to access the DB using RazorSQL (usign the jtds driver) on his Mac without a problem. It's infuriating that I have to go through all this hassle when I could have just used a non-Microsoft tool to do the job. I don't see why SQL Server Management Studio 2005 can't access the database at the same level as jtds. I suppose if I added an odbc connection on my computer to the db then I could have accessed it that way...

The install is now finished... Hopefully I can at least get some work done now.

Errors with an Upgraded Rails version

NameError: uninitialized constant ApplicationController

I've had to take a shelved project written for rails 2.1.1 and try to get it running again and ran into an issue getting it to work with the version I have on my machine; namely rails 2.3.4. Thanks to this post I was able to quickly overcome the most obscure error rather quickly.

Team City's FxCop Runner

Team City has a number of built in runners to use on your project that provide some pretty nice reports right within Team City. Some of those we're using are the Duplicates Finder (.Net) and the FxCop runner. The Duplicates was pretty easy to set up but I had a little more difficulty with FxCop. Nothing serious but I thought I'd reproduce what we did here.

First, of course, we had to make sure that FxCop was installed on our Build Agents. Then I added the following to the buildAgent.properties file

system.FxCopRoot=c\:\\Program Files (x86)\\Microsoft FxCop 1.36

Make sure to escape the colon and backslashes.

Then I had to create an artifact from my compile build configuration that was the bin folder containing the assemblies I wanted FxCop to look at.

Then I had to create an artifact dependency on that artifact in the FxCop build configuration; otherwise there were not any assemblies available for FxCop to operate on.

That did the trick for me.

The next step is to create a Dashboard type page that will have a script that will grab all the different metrics created from FxCop, Duplicate Detection, NCover, our burndown chart, etc. and display them in easy to view way (graphs and what not). We'd have all developers set this to be their home page (or ideally have it displayed on a wall somewhere) so all this can be viewed at a glance and you can get a quick overview of the project. I think this will be really valuable as a tool while trying to take TDD to the next step.

Continuous Integration Wash Cycle

This post about a developer's daily routine when using Continuous Integration is a nice breakdown that can be used when introducing people to CI. Following the links through the posts brings you eventually to this post about Discontinuous Integration which reinforces the practice of committing often. Following a daily routine as described in the first post will help prevent discontinuous integration. We've switched to using Team City after having used both CruiseControl.Net and Cruise for our CI. Team City is by far the most usable and makes following a daily routine much easier.

TDD in MVC applications

When developing a web application using MVC there are some components of the application that are not easily tested and can't be tested using automated unit tests. Since automated unit tests are the TDD bread and butter it follows that you can't use Test Driven Development for every aspect of your application. Our team has mentioned that it is difficult to know when to use TDD so I'm hoping to provide some guidance to help in this area. Any comments or suggestions about other methods are welcome.

Libraries: "That code should be in the Model!"

I think it's pretty simple really. Basically anything that will be used as a library function should have a unit test written for it and anything that should have a unit test written could be developed using TDD. In MVC, you would use TDD to develop Model code. If there is any code in the controller that contains some business logic that could be pulled out and made into a library function then that code should be in the model.

Any other aspect of the application would need to be tested using acceptance testing methods.