Archive for January, 2011

Adding packages to

clip_image001mmmmm, nuget.

These steps were written from the mindset of adding a package to the nuget gallery on that you require and happens to be missing. Anyone can add a package to for any project, even if you’re not a project contributor (although that is ideal). At Russell, we use a LOT of open source frameworks. While upgrading a portion of our code today, we decided to use nuget.  The first road bump we found was that did not have a package for Castle.Services.Transaction.  So what’s a open source loving dev gonna do then? Why, submit a package for it of course!

Steps to add a new package to (I’m making a lot of assumptions here, such as you know how to work the command prompt):

1) Make sure you have the nuget.exe command line tool.  If not, download the latest from here (or the complex site here) and stick it somewhere accessible from your path (I use d:\dev\tools). If you already have nuget.exe, you can run ‘nuget update’ to get the latest version. More details here from David Ebbo

2) Download the released version of the package you want to add, in this example I’m using Castle.Services.Transaction, which I downloaded from

3) Create an empty folder for the package, such as Castle.Services.Transaction, then create a subfolder called ‘lib’

4) Drop the binaries inside the lib folder. Since Castle.Services.Transaction has a NET35 and NET40 version, you’ll have multiple folders:

5) Delete ALL dependencies in the lib folder.  Castle.Services.Transaction depends on Castle.Core, but you do not want to include these in this package since Nuget handles dependencies for you.  The only binaries you want to include will be the binaries specifically for the project.

6) Create the manifest file by running the nuget spec command, with the –a [assembly location]. You’ll want to make sure you’re NOT inside the folder you created for this project. The .nuspec file will be created in your current folder.

7) Open the nuspec manifest and add the missing information. The Castle.Services.Transaction manifest is at the end of this email.

8) Now we get to generate the actual package. Run the nuget pack command, the first parameter is the .nuspec manifest, the –b parameter is the folder you created for the project, and the –o parameter is the output folder for the package. The –v parameter is for verbose output:

9) Login to, and click on “Contribute”, then “Add New Package”

10) Upload the .nupkg file that we just generated with nuget pack.

11) Verify the details of the package then click Next:

12) Choose a logo, or just click Finish to use the icon taken from the manifest:

13) Then, hopefully, a successful upload:

14) After a few minutes, you package should show up:

That’s all there is to it.  More information on creating packages can be found here: and Phil Haack’s post, which is a little more verbose than these simple instructions.

The Castle.Services.Transaction manifest:

<?xml version="1.0"?>
<package xmlns:xsd="" xmlns:xsi="">
 <metadata xmlns="">
 <authors>Castle Project Contributors</authors>
 <owners>Castle Project Contributors</owners>
 <description>Castle.Service.Transaction was inspired by the Java Transaction API (JTA), although it is a simplified version with no support for two phase commit.

Basically there is a transaction manager that is able to create transactions, that are associated with the thread. You can only have one active transaction per thread.

The transaction object only orchestrates the resources enlisted with it. It is up to the resource implementation to provide integration with some external transaction-capable entity, typically a database connection.</description>
 <dependency id="Castle.Core" version="2.5.1" />


Putting Rake & Albacore in your git repo for instant build awesomeness

Whilst checking out the latest and greatest from the machine.specifications repo, I noticed that their build setup uses Rake.. nothing really all that special there, I thought, lots of projects use Rake.  But taking a closer look, I discovered that the guys got smart and added a small version of Ruby 1.8.6 to their Tools folder, and wrote their build batches in such a way that the repo version of Ruby is used for their build instead of the local version of Ruby (even if Ruby is not installed at all).  This is actually quite brilliant.  The brilliance lies in not requiring Ruby to be directly installed on the build server, or any developer’s machine.


Everything that is not needed in Ruby has been stripped out (like webrick) to make the size of the Rake folder as small as possible. Let’s take a look at how Rake is invoked through the build.cmd


Simple and elegant. Since Ruby isn’t something native to the Windows world, it’s just a folder structure that you can move around, so putting a copy in the repo makes a lot of sense.  There are no strange things to worry about, such as having PowerShell installed if your build scripts using psake.  This is perfect for projects running Mono and developers running Linux or Mac.

So rather than pulling the mspec source and duplicating their setup, I created a skeleton project called BuildWithRuby and pushed it out to github with this exact setup.  Instead of using Ruby 1.8.6 like mspec, I’ve carved out a small copy of Ruby 1.8.7 with Albacore in the Tools folder. You can run either build.cmd from the Windows command prompt (or PowerShell), or run from your bash prompt. This example has a small Console application with a specifications project (using mspec no less).  The rake script looks like so:


This script will clean, compile assembly info, build, and run specifications for you. Nothing complicated, and very clean.  Hopefully this will help some poor soul who’s stuck without the ability to install Ruby on their build server. 🙂

1 Comment

How F5 Driven Development Contributes to Getting Distracted

As someone who has believed in the ideals of Test Driven Development for several years, I often find it unfathomable that some folks are still stuck in what I call F5 Driven Development. Defining this term is quite as simple as stating “Write some code, press F5, see if it worked, close, repeat.”  You can be running a F5DD cycle and not even realize it.  Any time you’re developing and you do not have a short, fast way to test changes several times per minute, you’re essentially in the F5DD cycle.  This applies to writing all types of applications: web, fat client, mobile, Silverlight, Windows services (oh dear, don’t get me started about F5DD and Windows Services). Silverlight is a special and sad case as well, as I cannot think of any other technology where F5DD is the only way to develop most of the application.. ok, well there IS Flash as too.

First, let’s talk about our attention span. It shouldn’t be news to anyone in the tech industry that the Internet with it’s immediate access to a universe full of information has contributed to the majority of us having very short attention spans.  There have even been some studies that say knowledge workers often have the attention span of a sparrow. Ironically, Twitter cuts the short attention span to a whole new, lower, level. When following enough people, “drinking from the fire hose” is no longer an accurate analogy… it’s much more like having an ocean’s worth of water shot at you through a 12′ diameter pipe.  It is my belief that these constant bursts of short information are a detriment to our ability to pay attention to any one thing for a substation length of time. Even writing this article, I’ve switched over to Twitter at least 20 times.

So what does this have to do with F5DD?  One of the biggest problems with F5DD that many articles do not cover is the loss of attention which is supposed to be dedicated to the problem you’re trying to solve.  Observe this typical process (bare with me, Ruby guys):

  1. write a bit of code
  2. compile
  3. wait for successful compile
  4. press F5
  5. wait for app to spin up (potentially having to recompile again)
  6. navigate to and test feature
  7. close app
  8. and then wait for your IDE to come back around so you can start the cycle again.

These wait times can be very damaging to your attention span.  In the world of writing an ASP.NET application, even on a beefy computer, with a medium sized code base, you could very well be waiting for at least 30 to 60 seconds before the application starts up. Only at this point can you begin to manually test your feature.  Have you ever been through such an experience? The delay between typing the last character in the code and starting to test gives your mind ample opportunity to start wandering off… “I wonder what’s happening on Twitter now?” “Better check my email again, though it’s only been 2 minutes” “Ooo I should go get some coffee!” “I’ll just play with my new Android while I wait” “*zombie drool* FACEBOOK *zombie grunt*”. All of these distraction points contribute to a further loss of concentration, and result, ultimately, in sub par code.  When you finally get your attention focused back to the problem again, you may find that you’ve forgotten the last change you made, or an idea about where to head next with the solution.

How does TDD solve this problem? The easiest elevator pitch I can give you is “speed, and lots of it.” Generally speaking, applying the practice of TDD gives your brain less time to wander and become distracted.  Of course this is no absolute, and I can site many times during the TDD process that I have still become distracted and succumbed to the urge to check my email/twitter/phone. The important distinction is that during TDD, the distractions come at a decreased rate.  The less time we give our minds to wander, the more we should be able to stay focused, at least theoretically speaking.

Next time I’m going to tackle another important player in the battle against becoming distracted during the coding process, slow test frameworks and test runners (I’m lookin at you, Gallio!).  Afterwards, I’m going to take on the tough issue of sleep deprivation and how poor code quality can be a direct result.


Getting back into blogging again

Due to a lot of reasons (changing jobs, having the sucktastic WebHost4Life as a host, family stuff, etc), I’ve not had a lot of time for blogging.  One of my goals for 2011 is to get back into serious blogging. Taking a tip from friend and coworker Adron Hall, I’m moving everything over to a hosted WordPress account instead of wasting time with WebHost4Death. At this point I’m not certain if I’m going to port old posts over from my current blog, or my previous to that blog (from years ago), or if I’ll just start of a new. We’ll see. 🙂

Leave a comment