Edmonton Code Camp (Sept 30)

So, I'll be presenting a topic during the Edmonton .NET Code Camp on Sept 30. My topic is geared towards the mass of VB6 developers currently making the migration to .NET. We all love that you're making the switch, but please, please, leave your dirty VB6 habits at the door. To help make the .NET transition smoother for all involved parties I'll be presenting some basic OO concepts along with some helpful OO design patterns. Of course it will all be test driven, so I'll touch on that as well.

Specifically I'd like to delve into Encapsulation, Inheritance and Polymorphism as well as some patterns such as Strategy, Command and perhaps Observer. Although I'm not sure the problem domain yet, I'll be starting with some code that looks like it could have been written by a VB6 developer and we'll refactor it iteratively into a simple, maintanable OO solution using each of the aformentioned concepts. It will be not only fun, and educational but will make you more attractive to the opposite sex.

If you're in town on the 30th of Sept stop by, say hi, buy me beer.

For more information about the Edmonton Code Camp do that clicky thing here --> http://www.edmontoncodecamp.com/

Clumsy .NET Decorators

The decorator pattern
is one of my favourite design patterns to assist in adherence to the Single Responsibility Principle. I especially enjoy the pattern in Ruby.

In .NET, however, the pattern loses alot of it's elegance. The necessity of gratuitous virtual delegating methods or overriding with the new keyword means that a decorator can not masquerade as the object it is decorating unless a significant amount of code has been added to the decorator class itself. When I've been faced with a task that could have been solved simply with a thin decorator, I'm often dissuaded from implementing the pattern because of the homely looking mess of a class that results.

This leads me to believe that an elegant solution exists by using reflection and Type Descriptors to create a Rubyish decorator that can dynamically delegate to base class methods. Stay tuned...

Click Once deployment using NAnt

Click Once publishing using Visual Studio 2005 is an easy, quick and painless way to manage deployments. Painless, that is, if you are a cowboy developer who's stomach doesn't quiver at the thought of throwing non-integration tested code into production or if you're a coding monkey who enjoys the mindless monotony of manual builds.

For those of us enlightened in the art of automated builds and continuous integration, however, Click Once is a nightmare. Fortunately, there is a way to deploy Click once applications without becoming a Visual Studio monkey. Here are my lessons learned for Click Once deployements using NAnt.

First you must configure IIS with your deployment folder. For example I set up a virtual directory called http://server/clienttest to C:\Development\Deploy\ClickOnce on my deployment server. We have a windows file share pointing to C:\Development called \\server\Development. In NAnt the ${clickonce.dir} points to \\server\Development\Deploy\ClickOnce while the ${deploy.dir} variable points to a local folder containing the deployable outputs from the build.

Now, if you don't already have one you will have to create a certificate with which to sign the manifests. I used the makecert tool for this ensuring that I the private key was exported. I store this key in the file indicated in the ${certificate.filename} NAnt variable. Read http://msdn2.microsoft.com/en-us/library/bfsktky3.aspx for more info on makecert.

Next I have a NAnt build target that creates a new directory for the build version then copies the client dlls into that directory:

(pardon my obtuse XML, just can't figure out how to get the angle brackets and indentation on this site)

(target name="create.clickonce.dir")
(delete dir="${clickonce.dir}\${version}" failonerror="false" /)
(mkdir dir="${clickonce.dir}\${version}" /)
(copy todir="${clickonce.dir}\${version}" flatten="true" )
(fileset basedir="${deploy.dir}\client")
(include name="*.exe" /)
(include name="Dependant*.dll" /)
(/fileset)
(/copy)

Essentially, Click Once deployment is the creation of two manifest files. The first describes the contents of a specific version of your application the second describes the contents of your deployment and specifies the most recent version. Fortunately, Microsoft has a utility called mage that assists in generating and signing these manifests. In order to create these files as part of the build process I created a NAnt task that calls mage.

I had to do this in two steps. The first step is to create both the application manifest and the deployment manifest. For example I ended up adding a target that looks something like this:

(target name="create.clickonce")
(call target="create.clickonce.dir" /)
(exec program="mage" commandline="-New Application
-t ${clickonce.dir}\${version}\Client.exe.manifest
-fd ${deploy.dir}\client -Name Client" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\${version}\Client.exe.manifest
-CertFile ${certificate.filename} -Password ${certificate.password}" /)
(exec program="mage" commandline="-New Deployment
-t ${clickonce.dir}\Client.application
-pu http://server/clienttest/Client.application
-n Alpha -i false
-appm ${clickonce.dir}\${version}\Client.exe.manifest" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\Alpha.application
-CertFile ${certificate.filename} -Password ${certificate.password}" /)
(/target)

This target need only be called when you want to create your deployment manifest. Typically it will only be called once, but I like to throw it in the build script in case I ever need to rebuild my deployment server.

The second step is to create the application manifest for the most recent build and then update the deployment manifest. The following target copies the

(target name="deploy.clickonce")
(call target="create.clickonce.dir" /)
(exec program="mage" commandline="-New Application -t ${clickonce.dir}\${version}\Client.exe.manifest -fd ${deploy.dir}\client -Name Client -Version ${version}" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\${version}\Client.exe.manifest -CertFile ${certificate.filename} -Password ${certificate.password}" /)
(exec program="mage" commandline="-Update ${clickonce.dir}\Alpha.application -AppManifest ${clickonce.dir}\${version}\Alpha.exe.manifest -Version ${version}" /)
(exec program="mage" commandline="-Sign ${clickonce.dir}\Alpha.application -CertFile ${certificate.filename} -Password ${certificate.password}" /)
(/target)

For more information on manual Click Once deployments have a read through http://msdn2.microsoft.com/en-us/library/xc3tc5xx.aspx.

Got Mission?

Being a skeptic of mandated doctrine the typical corporate mission statement is about as appealing to me as ketchup on cottage cheese. In my experiences coporate mission statements have been vague, broad and cliche. Until now, I've never been asked to participate in creating a new mission statement nor has my opinion been solicited in improving an existing one. Lacking in the authentic spirit of a team these works of bland prose garner little support from the very people they are supposed to inspire. So people tend to ignore them. Reading through them as part of the new hire literature and then shelving them with the instructions to the voice mail system.

Although I think that most mission statements are useless because they are done by the wrong people for the wrong reasons I do believe in the power of an effective mission statement written by the people who are to be guided by it. So when our PM announced a team meeting to come up with a mission statement, I'll admit I was a little excited.

The session was accepted by all the developers and everyone had their own ideas to contribute into the mix. Our PM did a great job of controlling the brainstorming sessions and making it a fun excersize. The meeting took just under an hour and the end result was a single sentence (consisting of just 4 words, actually) that conveys the quintessential values and goals of our team in addition to half a dozen sentences that describe it a little deeper.

The breakdown of the brainstorming was as follows:
1. List of things that we want to accomplish (the Whats)
2. List of ways we will accomplish them (the Hows)
3. Words or a sentence that describes a lofty yet attainable goal considering the context of the prior lists

Of course there's some categorization nebula between steps 1 and 2 that can be solved with brainstorming patterns. For example, words that fall under What and How might be broken down into two or more words which can be placed across categories.

Interestingly for our team, some of the fundamental Agile/XP values seemed to pop out on the whiteboard. Not necessarily expressed using these words, the concepts of Communication, Feedback, Simplicity, Responding to Change, Customer Collaboration emerged. Sadly, there was no Courage ;-)

So, what was our mission? The end result the following statement: Positively impact every project. Meaning that our team's lofty goal is to have our fingers in every project and ensure that we are providing a positive impact in each of those engagements.

So, does your team have mission?