Monthly Archives: December 2009

Code Kata: Langton’s Ant in C#

I’ve been itching to give code katas a try after listening to people like Uncle Bob talk about them in podcasts and reading about them on blogs. However, it wasn’t until I (half) watched a screencast by Micah Martin on solving a very small and simple problem that I actually went and did my own properly.

The problem space in this instance is Langton’s Ant. The problem is very simple:

Squares on a plane are colored variously either black or white. We arbitrarily identify one square as the “ant”. The ant can travel in any of the four cardinal directions at each step it takes. The ant moves according to the rules below:

  • At a white square, turn 90° right, flip the color of the square, move forward one unit
  • At a black square, turn 90° left, flip the color of the square, move forward one unit

This should be a fairly straightforward thing to map out in C# I thought. If I forego the graphical aspect of it (as can be seen in the Wikipedia page on this) then the actual logic should be fairly easy to test. In the end this little test took me a couple of hours to do which simply proves that a) I’m not as good a programmer as I thought and b) I have plenty to learn about using my IDE more efficiently (VS2008 with Resharper).

I’ve attached the project to this post.

MSBuild: CSS compression and Javascript minification for ASP.NET MVC

At work we use a continuous integration system to monitor our source repository and create builds.  It’s very handy in that us developers can simply code all day and then commit at the end of the day and then magically what we’ve written gets compiled, configured and deployed to our test and integration environment.  The deployment process is a simple file copy, but what’s smart is that only your standard aspx pages and dll’s get copied over – all those source files don’t get copied and web.config can also be changed on the fly to allow for different environments (e.g. different database connection strings).

So being the lazy coder that I am I thought it’d be nice if I tried to replicate this to some extent at home for my personal projects.  It’s also very convenient since I set up and wrote the build scripts we use at work – at least I won’t be fumbling too much in the dark this time round 😉

I have no intention of setting up a continuous integration server at home (we use CruiseControl.NET at the office), so a simple batch file should do the trick.  What I wanted with a simple double click was:

  1. In place compilation of all my projects within a solution
  2. Copy only what’s required  to my “deployment” folder (i.e. no source files, only aspx, ascx, asax, js, css etc)
  3. Minify and compress my javascript and css
  4. Change web.config so it knows which database to connect to (production or dev) – future requirement
  5. Automate running unit tests – future requirement

Reasons for wanting the above:

  1. Since I’m doing all this on my home/development PC there’s really no need for step 1.  When I run the website locally the files should be compiled automatically, however, during the automated build process will be set to build in “Release” mode.
  2. I don’t like my source code hanging around on a production server.  It has no business being there even if IIS won’t serve it.
  3. Minification and compression make for happy end users
  4. Remember the last time you deployed a config file to production with the connection string to your local database?  Yeah I haven’t done that in a while 😉
  5. I use ReSharper to run my unit tests, but rarely (if ever) do I run the whole suite of tests at once.  At work I’ve set the build script to do this, but this will be just a simple script for me at home.  In future I will probably include this though.


To achieve the above you will need to download and install the following:

[Note that apart from YUI the other two are optional but allow me to do stuff easier.  The Community Tasks probably isn’t even needed in this simple example, but I’m sure I used it for the build script at work which I’m liberally using as my base example)

Put those DLL’s in a place you’ll remember – we’ll need them later.

To achieve this automated build process we’ll need 2 files.  One will be a batch file calling MSBuild with various options and the other will be the proj file which contains all the build instructions.


@echo off
echo Creating a Production Build
MSBuild "C:UsersRezaDocumentsVisual Studio 2008ProjectsBillManagerBuildScript.proj" /v:n /m /tv:3.5 /p:TargetFrameworkVersion=v3.5;Configuration=Release;Platform=AnyCPU /t:BuildCode /fl

A very simple batch file.  First thing is to set the path so that we can find the MSBuild executable.  Note that I’m using 64 bit Windows 7 Professional, so if you’re running a different OS just remove 64 from the path.

Next is the command that does all the good stuff.  We call MSBuild with the options that we want to execute.  I won’t go into details, you can MSBuild /? to look at all the available options.  All I’m telling MSBuild with that line is that I want it to log with normal verbosity to the screen, use as many processors as it can find (all 8 baby!), use version 3.5 of the .NET framework and build it in “Release” mode.  Right at the end I also tell it which Target I want it to run (BuildCode).

The build script itself is rather large so I’ll try and split it up to try and make better sense of it. The thing to remember is that this script is essentially just a project file – the same as when you create a new project in Visual Studio (csproj or vbproj), so unfortunately we’re dealing with XML here (yuck).  I’ll just go over highlights here – I’ll include both files at the end of this post.


At the very start of the file we have the following line:

<Project DefaultTargets="BuildCode" InitialTargets="GetPaths;GetProjects" xmlns="">

What this basically says is that if no Target is specified, then use the BuildCode target.  However, the InitialTargets command states that those two Targets need to be run before anything else.  As can be deduced from the target names what I do there is get my pathing in order and create a collection of projects that I want to compile.

<Target Name="BuildCode">    
    <!-- Build the assemblies -->
    <MSBuild Projects="@(CodeProjects)"
      <Output TaskParameter="TargetOutputs"

    <!-- Add the compiled code assemblies to master list of all compiled assemblies for the build -->
      <CompiledAssemblies Include="@(CodeAssemblies)" />

    <Message Text="Completed BuildCode task"

    <CallTarget Targets="CopyToBuildFolder" />

Above is the Target that we invoked from the batch file. What it’s effectively stating is that I want to build all the projects as defined in the collection @(CodeProjects).  There’s more to it but for this example we’re not using any of the other parameters.  The last command is where we tell the BuildCode target to call another target called CopyToBuildFolder

<Target Name="CopyToBuildFolder">
    <!-- Copies all compiled code to the correct folder - ready for deployment -->
    <!-- We need to delete all files in this folder first to ensure a clean build-->
    <Folder.CleanFolder Path="$(BuildsFolder)" Force="True" />

    <!-- Copy main website files - This is ASP.NET MVC specific -->
    <CreateItem Include="$(ProductName).Web**Views***.aspx;
      <Output TaskParameter="Include" ItemName="FilesForWeb" />

    <!-- copy the files to the production build area-->
    <Copy SourceFiles="@(FilesForWeb)"
          DestinationFolder="$(BuildsFolder)%(RecursiveDir)" />

    <!-- Change the Configs -->
    <CallTarget Targets="UpdateProductionConfig" />
    <!-- Compress any JS and CSS -->
    <CallTarget Targets="CompressAndMinifyJavascriptAndCSS" />

In this Target I’m specifying all the files that I want to include for deployment.  The first thing to do is ensure that the destination folder is clean, so I run a task that deletes all files in a folder.  This is where the SDC tasks come in handy.  The command to recursively delete files in a folder with standard MSBuild tasks is a pain, so by including that one DLL I have saved a lot of time.  The next step is to specify which files I want to copy across.  My solution contains one ASP.NET MVC project and 3 class library projects, so all I want to deploy is what’s in the Web folder.  Note the slightly odd syntax with the “**” in the path.  What this tells MSBuild is that I want to select all files recursively.  So the first line where in the CreateItem task is to get all aspx files in the Views folder recursively.  If you’re familiar at all with ASP.NET MVC and its folder structure then you’ll know why I need all these files.

So once I’ve created the collection of files I want (called @(FilesForWeb)) I call the Copy task and specify the %(RecursiveDir) command to ensure that the folder hierarchy is maintained.  Once that’s done I then call the next two Targets.

<Target Name="CompressAndMinifyJavascriptAndCSS">
    <!-- Compresses javascript and CSS. combines into one file -->
    <CreateItem Include="$(BuildsFolder)ContentSite.css">
      <Output TaskParameter="Include" ItemName="CSSFiles"/>

    <CreateItem Include="$(BuildsFolder)scriptsbillmanager.js;">
      <Output TaskParameter="Include" ItemName="JSFiles"/>
    <Attrib Files="%(JSFiles.FullPath)" ReadOnly="false" />

        DeleteCssFiles ="false"

    <CallTarget Targets="CompressJson2" />

We’re almost done here… The purpose of this last Target is to compress and minify my application specific javascript and css.  What we can do here is also combine all the javascript into a single file to be more efficient, but for now I’m only compressing single files (jquery and gridder are already minified). I think the Target is fairly self explanatory.  I’m compressing my application specific CSS and javascript and then saving it to itself.  What minification does is try to compact the javascript file as much as possible.  It’ll run through your script and replace long winded variable names with much shorter ones and try not to break your logic.  It also removes any comments, so you can be as verbose as you like whilst developing but when it gets pushed to a live website those funny remarksdeep insights into your code are hidden from your public audience.  Note that I’m also setting the encoding to UTF8.  This is useful if you need to do localisation within your javascript.

Phew… long post.  Scripts for this can be found here.  Note that this is a sample only – use it at your own risk!

I’ve moved the blog to WordPress

So the first thing a true geek does is write their own blog type website.  Until they realise that under the hood it’s a little more complex than throwing together a few tables, mixing in a bit of CSS and Javascript and then being done with it.  The pragmatic geek on the other hand will eventually cede defeat and use something off the shelf.

My original goal with redoing the website was to learn to use ASP.NET MVC together with techniques and methodologies that all the cool kids were using – things like TDD, IoC, SOLID principles, ORM (Subsonic & Linq2Sql) etc.  So, I’ve been there, done that and now I’m ready (finally!) to use a weblog that was created by people who know what blogging software is supposed to do.

I won’t port my old content into this shiny toy – there wasn’t much and I’m none too happy with the shoddy quality of it anyway.

So here’s to 2010 and more posts on stuff!