Driven to Develop

Announcement: NDDNUG – Refactoring To Patterns

July 6, 2008

On Wednesday, July 9th, I’ll be giving a talk at the North Dallas .NET User Group called “Refactoring to Patterns (Not the Book)”. It’s not going to be some dry, academic talk with and bunch of UML and “Hello World” examples but an example using “real world” code like what you and I work with in our every day lives. The main patterns we’ll focus on for this web application are Model-View-Presenter and Adapter. My intent is to show the things that I’ve discovered in journey towards better, more maintainable code and provide ways to apply that knowledge in a realistic fashion. This is going to be a code intensive talk and, hopefully, a very interactive one.

Here’s the sign up form – I hope to see you there.

UPDATE: Here’s a link to the Google Code repository that contains both a start and end copy of the solution so you can see and try the refactoring that was demonstrated.

David O’Hara is a Principal with Improving Enterprises in Dallas, Texas.

Leave a Comment » | .NET, Adapter, Model View Presenter, NDDNUG, Presentation, Refactoring To Patterns (Not The Book) | Permalink
Posted by David O'Hara

Reducing Unit Testing Friction…

June 26, 2008

It doesn’t matter if you’re a TDD purist or a test-as-you-go guy, having a quick way to execute the tests that you’ve created is critical to them actually getting run as regularly as they need to be. To that end, here is the current setup that I’m using to make this as easy as possible.

Everyone knows that I’m a sucker for a new tool but this tool has been with me for quite a while and I’m skeptical that anything will be able to replace it. TestDriven.Net is the foundation of a great workflow when it comes to unit testing and it’s truly worth the small amount that Jaime asks for his efforts. He’s a great guy and it’s a great tool – go buy it and install it immediately.
So now that you have it installed, there a couple of settings in Visual Studio that help make that test/code/test cycle even tighter.

Keyboard shortcuts

Once you have TestDriven installed, you’ll notice some extra options in the context menus when you right-click on class files, projects and even in code. These will allow you to run tests in various fashions but I’m a lazy man and I hate moving my fingers off the keyboard so I’ve added a few shortcuts to Visual Studio. In the options menu for “Keyboard”, I bind Control-1 to “TestDriven.NET.RunTests”, Control-2 to “TestDriven.NET.ReRunWithDefault”, and Control-3 to “TestDriven.NET.ReRunWithDebugger”. The way this helps me is that I am able to use Control-1 to execute the test that the cursor currently resides in (if you’re in between tests or on the fixture itself, it will run all in that fixture). If it doesn’t pass, I can hop over to the code that’s being tested, make the changes and then just press Control-2 to see if the test passes. No back and forth between the two. The last shortcut is helpful because it allows me to set a breakpoint where I am (using F9 of course) and rerun the test so that it will hit that breakpoint. Again, no back and forth.

Output window

Every time you execute a test, the tool bar will give you a quick look at the status but the output window will be your friend when things don’t quite execute as planned. All the output gets piped here but you don’t need it in your face so be sure that the “Show Output window when build starts” is unchecked but also be sure that you have it collapsed just below your code file. output window.jpg This way if you do have need to see what is in the output, you can just press Control-Alt-O and it will pop up with focus. (Pressing Escape will cause it to hide again and leave us in our code.)

I still haven’t quite figured out how to bind to the “Run All Tests” so if you have a suggestion, I’d love to hear it. However, I do still find it helpful that a “Run All Tests” will execute again when using the rerun shortcuts and I use that quite a bit right before commits. (If you’re not religious about running ALL tests before a commit, I hereby grant your co-workers permission to knee-cap you.)

Because unit tests only provide benefit when they are actually run, we need to do everything that we can to tighten the code/test loop and make executing the right thing at the rightht time as easy as possible.

David O’Hara is a Principal Consultant with Improving Enterprises in Dallas, Texas.

Leave a Comment » | .NET, TDD, Test Driven Development (TDD), TestDriven.Net, Unit Testing, Visual Studio | Permalink
Posted by David O'Hara

Random Rant…

May 5, 2008

Apparently in NYC it is the implicit responsibility of the second person in line at a red light to immediately honk their horn when the light turns green so as to remind the first person in line that it is their turn to go. Having been the second person previously, subsequent drivers (usually numbers 3 thru 5 or so) are often concerned that this person may not be aware of this responsibility or is simply in need of assistance. So they take it upon themselves to also gently remind those in front of them of their responsibility by utilizing their horns. Who knew NYC was so full of concerned and considerate driver??

3 Comments | Driving, Humor, NYC, Random, Rants and Ruminations | Permalink
Posted by David O'Hara

Project Structure In The SCM…

April 29, 2008

As a follow-on to the last post Self-Monitoring Build System, I figured I’d discuss the way I manage my projects and their dependencies. I believe it’s important to have a self-contained project that allows “time to login screen” to remain as small as possible. I do this by packaging the source, libraries, tools, basically everything under a single space within the SCM. This puts the control and responsibility for managing dependencies where I feel it should be; in the IDE so that, ultimately, it’s in the developer’s hands rather than in the SCM itself. Plus, it makes sure that the build server will always have what it needs to build the project without needed extra installs. If you keep the build server clean, you won’t be in a pinch should it take a dirt nap. (You ARE using VMs for your build servers aren’t you??) Keep in mind that when I’m saying “project”, I’m referring to a project in the sense of a product or system in the enterprise which is probably comprised of at least 1 Visual Studio solution and a few ancillary things.

The Setup

In an effort to keep things practical and concrete, here’s how I usually set things up. To start with I have a common project which contains a basic “template” build script and the tools that I like to use – NCover, NUnit, MbUnit, NAnt, ILMerge, Simian, etc. Now, all subsequent projects will be branched from this common project. This allows you to manage which version of the tools each project is running as well as easing the push to move a project to the latest and the places you have to check in that new version. Side note: There has been a recent discussion on the altdotnet group regarding svn setup and it has been interesting to see the discussion. However, this configuration assumes that you’re using a single repository because…well…that’s the only way I’ve worked thus far. If you’ve got an idea on how to make it work with multiples, I’d like to hear about it.

David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.

Leave a Comment » | .NET, Builds, Continuous Integration, Project Structure, SCM, Source Control | Permalink
Posted by David O'Hara

Self-Monitoring Build System…

April 24, 2008

Currently, I’m helping a client get their Continuous Integration system in a little better shape. They have CruiseControl.NET installed and monitoring their VSS repository (I know, I know, don’t get me started – I’m working on getting Subversion adopted). When spinning up a project, I’m a big advocate of having EVERYTHING under source control and that includes the build system itself. This is a brief guide on how that works.

CruiseControl Configuration

First you need to configure CC.NET for your environment so that it’s monitoring your SCM and ready to execute your build script. Here’s our ccnet.config that accomplishes this:


	
		c:\buildlogs\buildsystem\
   		c:\build\buildsystem\
		http://buildserver/ccnet/
		
			
		
		60
		
		   C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE
		   $/Repos/BuildSystem
		   build
		   buildpw
		   true
		
		
			
				tools\nant\nant.exe
				default.build
				300

NAnt Script

This file is then checked into a project called “BuildSystem”, to match the configuration file, along with a build script that will copy the edited files over top of the existing ones and a copy of NAnt to execute it.

< ?xml version="1.0" encoding="utf-8" ?>
<project name="AffiliateIntranet" default="deploy" xmlns="http://nant.sf.net/release/0.86-beta1/nant.xsd">
  <target name="deploy">
    <copy file="ccnet.config" todir="D:\Program Files\CruiseControl.NET\server" overwrite="true" />
    <copy file="dashboard.config" todir="D:\Program Files\CruiseControl.NET\webdashboard" overwrite="true" />
  </target>
</project>

Now when changes are made to the files and checked in, the build system will see the changes and copy the new files over top of the old ones. CC.NET will see the new file and restart in order to pick up the changes. This is why we have to do it using NAnt rather than the built-in version.

Why, Why, Why

While a configuration like this may seem like overkill, it helps to cut down on the amount you need to remote to the build server as well as decreasing the amount of time to spin up a new build server should the current one decide to take a “dirt nap”.

David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.

1 Comment | .NET, Builds, Continuous Integration, CruiseControl.NET, Development, NAnt | Permalink
Posted by David O'Hara