open source


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.


26
Jan 09

Chatsworth: A Google talk group chat bot

For the past year and a half, I’ve been using PartyChat to participate in multi-user chats with friends.  PartyChat essentially provides IRC type functional via GTalk and has been a great way to have on going conversations throughout the day while avoiding 100+ email threads.

The only pitfall PartyChat has to do with stability.  PartyChat is a free service used by a large number of people, and it is run off the project creator’s computer in his apartment.  I do not know exactly why the service goes down intermittently, but the recipe of home server plus lots of users cannot be helping.  While it stinks that PartyChat isn’t always up, I understand I have no right to demand or expect 100% uptime, so I decided to do something about it.  I leveraged some of the knowledge I picked up about XMPP, the protocol that Jabber and GTalk use, from another project and wrote a simple group chat bot called Chatsworth to improve the availability of group chat that my friends and I use and depend on.

Chatsworth is a windows service written in C# that provides basic chat room functionality.  It does not have all the features that PartyChat has, but it does offer people the ability to setup and manage their own chat bots.  Additionally, if you are concerned about having all your chat logs being available not just to Google but also to the people running the PartyChat servers, then Chatsworth is the group chat provider for you.  Chatsworth is fully functional but still immature and under development.  I plan to add some additional features, take care of a few loose ends and provide more unit tests in the immediate future.

Admittedly I could’ve just downloaded the PartyChat java source, compiled it, and ran it on my own set of servers, but where is the fun in that?  I figured rolling my own chat bot would give me the opportunity to do more than address some of the availability issues I was having.  Starting up Chatsworth provides me a non-trivial project that I can use to explore different software development concepts and techniques as well as get some code and design samples out on the web.  So if you’re in the market for group chat in GTalk, give Chatsworth a try.  I am looking forward to building this project out further and would love to hear any feedback.