March, 2009


7
Mar 09

Tree Surgeon: Review and a couple tips

This past week I was playing around with Hudson and Team City and getting some NAnt scripts put together to use.  In a happy coincidence I happened to catch a mention about Tree Surgeon from twitter and it had piqued my curiosity.  Tree Surgeon is a project on CodePlex that has been around for a while and helps automate the process of setting up a source tree and assembling build scripts.  It was just what I was looking for.

The goal of Tree Surgeon was to make setting up and laying out new projects using best practices dead simple.  All the major tools and libraries that typically find their way into your .Net source trees are provided for you.  In addition to laying out the directory structure for your source and libraries, a solution file gets created with three main projects to get you started.  The basic project setup includes a console app, core library and unit test project.  The build scripts come pre-wired to have NCover run your tests and generate reports from the results and also do things like packaging your build artifacts into zip files for deployment.

The whole process, start to project generated, is very easy.  Download and run the installer.  Launch the program, select the version of Visual Studio (2003, 2005, and 2008) and the flavor of testing framework (NUnit or MbUnit) and then hit generate.  The files and directories, built out in your Documents folder, are then created and ready to be used.

There are two slight issues I ran into that I’d like to point out.  Both issues had already been noted in the project forums and were easy to fix.  When generating a source tree with MbUnit selected as the unit test framework, the build script generated has the unit test assembly referenced is named incorrectly.  You will have to change it to match your project’s unit test assembly name.  The second issue has to do with running NCover and NUnit on x64 machines.  I found that in order for NCover and NUnit to work on x64 machines I had to add two calls to the CorFlags utility to make executables work.  This was accomplished by making the modifications to the ‘run-unit-tests’ target below on lines 5-8.

   1: <target name="run-unit-tests">
   2:     <mkdir dir="${build.dir}\test-reports" />
   3:     <exec program="regsvr32" workingdir="tools\NCover" commandline="/s CoverLib.dll" />
   4:     <!-- Need the CorFlags Commands For x64 -->
   5:     <exec program="C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 
   6:         workingdir="tools\NCover" commandline="NCover.Console.exe /32BIT+" />
   7:     <exec program="c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 
   8:         workingdir="tools\NUnit" commandline="NUnit-Console.Exe /32BIT+" />
   9:     <exec program="tools\ncover\NCover.Console.exe" 
  10:         workingdir="${build.dir}\Debug\UnitTests">
  11:         <arg value="//w &quot;.&quot;" />
  12:         <arg value="//x &quot;..\..\test-reports\Coverage.xml&quot;" />
  13:         <arg value="&quot;..\..\..\tools\nunit\nunit-console.exe&quot;" />
  14:         <arg value="&quot;MyProjectName.UnitTests.dll&quot; 
  15:             &quot;/xml:..\..\test-reports\UnitTests.xml&quot; &quot;/nologo&quot;" />
  16:     </exec>
  17: </target>

Even though I am pretty late to the party with Tree Surgeon I am very happy to have stumbled across it.  The whole source tree and build script setup process is the perfect thing to script out and I am really glad the project creator and contributors have taken the time to do this.  It is a big help and I highly recommend you try it out the next time you are spinning up a new source tree for a project.


5
Mar 09

Alt.Net Seattle Recap

I spent last weekend at the Alt.Net Seattle conference and had some time to reflect on it.  This was my first experience with an open spaces style conference, and I have to admit that I am a big fan of the format.  While I am not convinced this format would work for every type of gathering, it fit the needs for this type of group very well.

There was a lot made during a couple of sessions about being more accessible, newbie friendly and encouraging more new faces and ideas at these events.  If you watch some of the video from Hanselman’s Why So Mean session, you can get the general gist of some of the problems and solutions offered.  While I think introspection is generally a good thing, I am not convinced that any progress on this front will be made, and question if these issues are as bad as some may think.  As a first-time Alt.Net conference attendee and having only met one other person there in real life prior to last weekend, I never felt unwelcome or shunned and everyone that I talked to was cordial and friendly and definitely open to discussion.

However I didn’t get on a plane to Seattle to talk about feelings.  What drew me to the conference was the opportunity to talk about the software with some of the most passionate and opinionated developers in the world.  By participating in the workshops and sessions, I was able to soak up and participate in some great conversations about agile and lean, LINQ, DDD, context/spec based testing, etc.  These are topics that I don’t always have the opportunity to discuss daily and certainly not with people who have the kind of expertise as those who were in Seattle.  I’ve already been able to apply at work and on my side projects some of the things I’ve picked up, and I don’t think I’m close to truly synthesizing all of the great conversations that I had.

While my overall experience was positive and worth both the time and expense, I did feel like there were some minuses from the trip.  Some of the sessions turned out to be essentially just presentations and spurred very little discussion or participation.  I expected that there might be some of this due to the lack of experience or expertise with the tech.  Sessions like Miguel de Icaza’s on Mono and the iPhone fell into that category since virtually no one there had any experience with developing for the iPhone and even fewer with Mono, but even things like some of the discussions on more common topics like DDD or Agile were somewhat eyes forward discussions and lacked some of the give and take that really made some of the other sessions.

Some of this may have been the result of people deferring to some of the *ahem* stronger personalities or undisputed domain experts in the field.  The presence of some of these personalities in the sessions clearly defined or dramatically shifted the discussions.  It did not take me long to learn and apply the law of two feet when I found myself at the same sessions as some of these people.  I knew that it was a matter of time until the session’s conversation was going to degrade or grind to a halt.  My last complaint about the conference is about some of the new age crap that that was brought in by the facilitator.  I don’t think the butterfly and bumblebee metaphor stuff or the ringing of the bell really added to the experience and was not needed.  I know that the facilitators were trying to make this a very Zen-like experience, but it was not.

In terms of key take-aways, I think I’ve identified a few.  I talked with quite a few people about their experiences with agile and scrum.  In hearing some other companies’ practices and problems, I was comforted by the knowledge that my current company is not as dysfunctional as I thought.  While I still think we can improve, I also realized that I should probably take a moment to appreciate the good things that we do and celebrate the stuff that what works well.  The other take-away was that I feel like I am in a much better position to clearly articulate the goals that I had set for myself earlier this year.  Prior to this weekend I had not done a good job articulating some of these goals and had yet to express them in SMART terms.  Now I am going to incorporate things like contributions to open source projects and community demos and/or presentations into my measurables when tracking my progress on some of my goals.

The future of these conferences I think will be in the local or region open spaces starting to be held.  Already conferences are planned for Vancouver and Houston that seem to fit this bill because they are drawing in people from the region versus nationally based on a quick perusal of their attendee list.  I speculate that if you reduce the concentration of some of the more well known personalities in the community, you might be able to make up for any potential loss of expertise with an increase in the amount of active participation from fresh new faces.  Additionally, I think some might find the benefits of participating in open discussions with developers in their own communities more meaningful as these types of interactions may yield long-term benefits.

Lastly, I’d like to thank the people of the Alt.Net Seattle group for putting this together, and you should be proud of the success the conference achieved.  Job well done.