SpeakENG

Jeremy has always been a bit of a sceptic when it came to the AutoMockingContainer, and he's not alone, apparently hammett isn't a fan either (any explanation hammett?). I could never understand why he's sceptical, but it looks like he's starting to get a little more curious as he's including an AMC in StructureMap 2.5.

There are a few interesting things in his implementation. The most noticeable difference is that  he extends the MockRepository. This means you don't need two objects floating around, your MockRepository and your AutoMockingContainer, you just combine them. The biggest issue I see with that is you can't do things like this with HubServices:

_container.AddService(_container.Create<HubService>());
MyClass foo = _container.Create<MyClass>();

I do this all the time when I use hub services, since it is much easier to just use the real implementation of HubService as all it does is expose its child services as properties and those are the things I really want to mock.

I should also reiterate the benefits of using an AMC friendly test fixture that has instance helper methods for Create, Get, AddService, etc, and now I'm seeing people offload things like mocks.Record and mocks.Playback; I like this too.  The "mocks.ClassUnderTest" is definitely too verbose for me.

The other big question I have to ask is... why have a StructureMap AMC? Why not just use the existing one? Yes, it uses Windsor behind the scenes, but that doesn't matter does it? If you're worried about your test dependencies I suppose it does, but are you? Don't get me wrong, I'd jump ship in a heartbeat to the StructureMap AMC if it was proven faster as a result of using StructureMap instead of Windsor, but I think that's about the only reason, since most features could easily be added to keep in parity. Especially now that the AMC has been so well maintained since it's a part of RhinoTools now.

Here's the second installment of our Vim Screencast.

Also, if you're new to our blog, be sure to subscribe to get new screencasts as I release them!

And special thanks to Roy Osherove for Keyboard Jedi.

Click here to save

You can get Vim here, but I'd ultimately recommend ViEmu, a Vim emulator plugin for Visual Studio.

So here it is, finally. In this screencast I cover the very basics of Vim. It's about 9 minutes long. Obviously this is my first one, so please give me feedback so I can make the next ones better.

Also, if you're new to our blog, be sure to subscribe to get new screencasts as I release them!

And special thanks to Roy Osherove for Keyboard Jedi.

Click here to save

You can get Vim here, but I'd ultimately recommend ViEmu, a Vim emulator plugin for Visual Studio.

With Mingle 1.1 came several great new features, including date fields. Now you can track the date that you complete tickets by adding a Date Done field (along with a Complete transition that sets the Date Done field to today) and locking the Status field to be editable only by transition.

This works great for newly completed cards, but what about all the cards you already have in your system? Sure you could go without burn-up charts and date stats for those cards, but what's the fun in that? 

Fortunately, Mingle tracks every card change in a history table. Each change in the history table has a date associated with it, so all we need to do is figure out how to extract the dates we care about. I must warn you, this is a little complicated, and I'm sure ThoughtWorks doesn't at all condone you mucking around in your Mingle database manually, so please please back up your database before attempting this and of course I'm not responsible for any damage you do. That said, here's how I was able to retroactively add dates for our two date fields: Date Done, and Date Published.

1. Back up your Mingle DB. Really.
2. You'll need to identify the field you use to track status. We use Status. We have Status of 'Not Done', 'Done', and 'Published'.
3. Then connect to your Mingle database and find the name of your cards table and your card_versions table. Our project is called "eleutian_speakeng" so our tables are "eleutian_speakeng_cards" and "eleutian_speakeng_card_versions".
4. Add the date fields you want to populate if you don't already have them. We have "Date Added", "Date Published" and "Date Done".
5. Figure out which fields in the two tables you identified map to your status and dates (this is usually as easy as prepending cp_ and box_caring your names. For us we have cp_status, cp_date_published, cp_date_done, cp_date_added.
6. Edit the following queries to add in your table/field names and values (these are the exact queries I ran, you'll need to change the red things):

   UPDATE eleutian_speakeng_cards SET cp_date_added = created_at
   
   UPDATE eleutian_speakeng_cards card SET card.cp_date_done = (
     SELECT MAX(b.updated_at) 
       FROM eleutian_speakeng_card_versions a
     INNER JOIN eleutian_speakeng_card_versions b ON a.number = b.number 
       AND b.version=a.version+1 
     WHERE card.number = a.number
     AND (a.cp_status='Not Done' OR a.cp_status IS NULL) AND b.cp_status='Done'
   ) WHERE card.cp_status = 'Done'
   
   
   UPDATE eleutian_speakeng_cards card SET card.cp_date_published = (
     SELECT MAX(b.updated_at) 
       FROM eleutian_speakeng_card_versions a
     INNER JOIN eleutian_speakeng_card_versions b ON a.number = b.number 
       AND b.version=a.version+1 
     WHERE card.number = a.number
       AND (a.cp_status IN ('Done', 'Not Done') OR a.cp_status IS NULL) 
       AND b.cp_status='Published'
   ) WHERE card.cp_status = 'Published'
   

7. Once you've got that taken care of, go ahead and run the queries (you backed up right?) and you should be good to go.

So now that you've got your dates in your database, how do you get the cool burn up chart? Like this (mold to your project):

{{
   stack-bar-chart
   x-label-start: SELECT MIN('Date Added')
   x-label-end: Today
   x-label-step: 14
   chart-height: 600
   chart-width: 700
   plot-height: 500
   plot-width: 550
   conditions: Type IN (Bug, Story, Task)
   three-d: true
   cumulative: true
   series:
     - label: 'Not Done'
       color: #e6a800
       data: SELECT 'Date Added', COUNT(*)
       type: area
     - label: Done
       color: #1bcc00
       type: area
       data: SELECT 'Date Done', Count(*) WHERE 'Date Done' IS NOT NULL
     - label: Published
       color: #0079bf
       type: area
       data: SELECT 'Date Published', COUNT(*) WHERE 'Date Published' IS NOT NULL
}}

One of the first things we did when we got a dedicated development server was set up a continuous integration server. The natural choice at the time was CruiseControl.NET, so Jacob set off to get CC.NET installed and configured. I can't speak to that experience first hand, but I know it wasn't a fun one. Lots of XML hell and other non-fun issues. The end result wasn't too bad--it'd email us when builds failed with a log, and we could review logs on our CC.NET site. There was really nothing WOW about it--it got the job done. It was frustrating at times because the logs it spat out were difficult to visually parse; it was basically just a verbose msbuild log with a failure mixed in somewhere... and that was if we were lucky enough to get a text log and not have to filter through the build xml log. I'm sure there are some things we could have done to filter that log down, apply xslt to our build.xml to make it more readable, or configure things to be nicer, but I'm also sure it would have involved hard work and more XML hell.

Enter the free Professional Edition of TeamCity 3.0. We'd tried out TC briefly in the past and it seriously lacked in the .NET support arena. Now they tout support for msbuild (2.0 and 3.5), sln files from 2003-2008, and even a nifty .NET duplicate code finder. They also have some pretty slick support for NUnit which I'll get to in a moment.

I decided to give it a shot again, so I set up the TC server on our Ubuntu VM. Why there? Well that's where most of our server tools are: SVN, Mingle, FogBugz and now TC. But wait, aren't we a .NET shop? Yep. The build doesn't happen on our Ubuntu VM. See, TC is set up to have a server + build agents. A build agent is basically a machine that will check out code, do the build when the server tells it to, and report back results and artifacts to the build server. This way you can have multiple Build Agents--different Operating Systems, system configurations, physical locations, etc.

Installing both the Server and the Agent were relatively straight forward. There were a few annoyances with the Agent's configuration (like I couldn't get it to use a network drive as a working directory and it took some tweaking to get things to work with our directory structure,) but after a while I got things up and running.

Setting up a build configuration in Team City is an absolute breeze. You basically have a 7 step Q&A about your configuration:

1. General Settings - Name, Description, a few options and the build number format (we use our SVN revision #)
2. Version Control Settings - You can set up multiple repos to check out with a number of tools (SVN, CVS, Perforce, StarTeam, ClearCase). I'm sure it wouldn't be too difficult to write plugins for Mecurial or Git. You can also tell it where to check out relative to your working directory and whether or not you want it to check out to the agent or on the server and then have the agent download it.
3. Build Runner - Mainly .NET and Java stuff. No Rake yet, but it supports command line so you could just use that. With MSBuild you just specify your MSBuild file, the target you want to run, and any command line args you need. It's here that you specify your build artifacts as well. Build artifacts are kept along side your completed builds and easily accessible from the TC site.
4. Build Triggering - You can trigger based on VCS changes, schedule, other build configurations completing, or automatic retry.
5. Artifact dependencies - This makes it really easy to say you want Build A to use Build B's artifacts. For example, an installer configuration that will build an installer based on the last successful CI build.
6. Properties and environment variables - Self explanatory.
7. Agent requirements - Not all your agents can run all your build configurations necessarily. This will let you set requirements. You can set these based on environment variables, machine names, etc.

Once you get things set up, you get to see the really cool stuff. TeamCity is just packed full of nerdgasm features that just work out of the box. No need to scour the web for plugins, deal with XML, or anything like that. Things just work. For example, you get full status of the build while it is happening--you can see what MSBuild step the build is on, you can see the important messages in the Build Log (it filters them quite intelligently), you can even see what threads/processes are running. If you use their NUnit runner you can even see how many tests have passed/failed/been ignored.

That's not all you can see with their test runner though. You also get a full history of each test--how long each test took each time it was run, and if one fails you can see in what build it first failed, if it has been fixed yet, and you can even click to open it in your IDE if you have the Visual Studio plugin installed. The Tests tab even orders your tests by Duration so you have an idea which tests you may need to optimize.

Then there's the Statistics tab. This tab is a one stop shop for build health. You can see how long the build takes, how often it succeeds, how many tests you have, how many fail and even how big the artifacts are. You can see our build #s jump when we switched from a counter to SVN revision.

If there aren't enough features for you, don't worry, like with most JetBrains products you can extend them to your hearts content. That is if you can stomach the lack of API documentation (surprisingly, normal usage documentation is pretty good). One of our guys is working on a Campfire Notification plugin at the moment so we can get better build notifications in our Campfire. That's another post though.

All in all, we're very happy with TeamCity. It's just as free as CC.NET for a team of our size, it's much much easier to set up, and it has way more features. How could you go wrong? I'm sure its only a matter of time before we start to see rake runners, MBUnit test runners, and many other things to make TC even better. JetBrains has a winner here.

I just profiled one of our test assemblies (Unit tests only, nothing hitting the db). Mocking accounts for 196 seconds out of 357 seconds. The culprit is System.Reflection.Emit.TypeBuilder.CreateType(). This doesn't come as that much of a surprise to me, but still... is there a faster way to do this? Oh and yeah, the results of CreateType are cached so its only the first time you create a mock of a type that you take this hit, but still... that can really slow down TDD.

And no, I'm not saying we should stop mocking... just raising awareness.

I'm going to be putting together a series of Vim Screencast Tutorials. My goal is to raise awareness in the world of just how powerful Vim is and then get everyone comfortable using it. Here's a short trailer that shows a few of the things that make me love Vim. This is my first Screencast of this kind and, yea, I know its cheesy.

Click here to save

You can get Vim here, but I'd ultimately recommend ViEmu, a Vim emulator plugin for Visual Studio.