This is a very short book on a great practice for any agile team. The book walk you through a lot of techniques an exercises that will help you and your team to have successful retrospectives.

The first 3 chapters provide information on what retrospectives are about. How to create one for your team and what you need to learn to lead them.

The next 5 chapters provide techniques that will help you to go through the different stages of the retrospective. Each technique is clearly explained, with step by step guides and diagrams (when necessary) to provide more information. In some cases, when some techniques are complimentary, this is clearly indicated.

The authors also provide guidance on the scope where to apply the activities and a time estimate.

The previous to last chapter talk briefly about release retrospectives and the last one give some pointers in how to act on the actions, resolutions and experiments the team agree to follow.

If you work as a team lead in an agile team and you are in charge of facilitating the retrospectives, this book is a good tool to have.

On my new project I want to start using end to end testing.

The idea is to write an specification run it against an outer interface. Gui, Web service, etc. It fails. So you start implementing the feature using TDD until the Spec pass.

You write a second scenario and you start again. If everything works as supposed I should have a fairly well tested application, not only at the unit level but at the integration and user acceptance level as well.

Since the application will be written in c# I look around for some tool to write the Scenarios in the same language. There are some options but none of them was as elegant as using Cucumber. So I tried cuke4nuke but I have no luck with it. I kept getting an error about server not running or something. It looks like a permission problems with win 7.

I’m sure I could have figure it out (some confidence I have on my abilities ) but after giving it a second though I decided to go with Cucumber and RSpec for those test. Drive the browser with Watir and hit the web services end points with webrat, sometimes even script the UI with webrat when the browser is not really need it.

Installing all the gems is easy just

gem install cucumber

gem install webrat

gem install mechanizer

gem install watir

gem install rspec 

and you are done (at least in my case). Of course you need to have ruby installed in your system. I have 1.8.6

Since I haven’t really used Cucumber before and my Ruby is still very flaky, I decided to use RubyMine as my IDE to write the specs, specially because you can generate the step definitions from the features in a similar way as how you generate code with R# in VS.

You start writing an Spec with one scenario like this:

Then you run it via the console and have this result.

Note the yellow squiggly lines on the step definitions for the scenario? If you move the mouse over them a prompt will indicate that the step haven’t been created yet:

Hit Alt+Enter to see a suggested solution:

Click enter and you have some options, to use an existing step definition file or create a new. If you hit create a new one and you don’t have an step_definitions folder RubyMine will create it for you.

In this case I select the existing bing_steps.rb file

Notice that the values between quotes are replaced by a regular expression, hit tab to modify the different tokens of the method template. After generating all the methods and adding the necessary code, this is the result.

And when running via the console this is the result:

In this case we are running this specs against an existing piece of software, in my case I will run this against a new un-written site. So to see the scenario pass I should write the feature as well.

Probably you are aware of Edgecase Ruby Koans. In case you aren’t, let me introduce you to them.

From Wikipedia, Koan:

A kōan is fundamental part of the history and lore of Zen Buddhism. It consists of a story, dialogue, question, or statement whose meaning cannot be accessed by rational thinking, yet it may be accessible by intuition. A widely known kōan is "Two hands clap and there is a sound; what is the sound of one hand?"

The Ruby Koans are a set of failing test that you need to resolve. Of course the idea is not just to resolve the test as fast as you can but to read the code carefully and understand why it’s failing and them provide the solution.

Once you download the code you just run the rake command inside the folder where the Koans have been downloaded and you will be presented with a failing test and a message in the screen that indicates what you need to do to fix the test.

You should take as much time as needed to contemplate the solution and internalize the code, the syntax and the constructs that Ruby use.

I went through them once and I’m planning on do it again in a day of two. The Koans cover some important aspect in the following areas: asserts, arrays, arrays assignments, blocks. Classes, open classes and class methods.  Inheritance, hashes, exceptions and so much more, this is the complete list of files in the Koans folder:

17/01/2010  11:25 PM             2,024 about_arrays.rb
17/01/2010  11:29 PM             1,015 about_array_assignment.rb
17/01/2010  12:27 PM               942 about_asserts.rb
18/01/2010  11:51 PM             2,392 about_blocks.rb
21/01/2010  12:02 AM             3,873 about_classes.rb
21/01/2010  06:20 AM             3,820 about_class_methods.rb
18/01/2010  12:11 AM             2,320 about_control_statements.rb
22/12/2009  10:24 PM             1,436 about_dice_project.rb
18/01/2010  12:24 AM             1,374 about_exceptions.rb
22/12/2009  10:24 PM               317 about_extra_credit.rb
17/01/2010  11:35 PM             1,765 about_hashes.rb
21/01/2010  12:07 AM             1,652 about_inheritance.rb
18/01/2010  10:10 PM             2,441 about_iteration.rb
21/01/2010  06:39 AM             4,277 about_message_passing.rb
18/01/2010  12:02 AM             3,613 about_methods.rb
21/01/2010  12:10 AM             1,132 about_modules.rb
17/01/2010  08:08 PM             1,020 about_nil.rb
21/01/2010  12:03 AM               920 about_open_classes.rb
21/12/2009  04:38 PM             3,295 about_proxy_object_project.rb
19/01/2010  12:10 AM             2,657 about_sandwich_code.rb
21/01/2010  12:15 AM             1,870 about_scope.rb
20/01/2010  11:46 PM             1,843 about_scoring_project.rb
17/01/2010  11:51 PM             4,725 about_strings.rb
22/12/2009  10:24 PM               771 about_triangle_project.rb
22/12/2009  10:24 PM               486 about_triangle_project_2.rb
18/01/2010  12:12 AM               788 about_true_and_false.rb
22/12/2009  10:24 PM             1,111 array_test.rb
21/12/2009  04:38 PM                19 code_mash.rb
21/12/2009  04:38 PM             4,498 edgecase.rb
22/12/2009  10:24 PM                15 example_file.txt
22/12/2009  10:24 PM               156 first_test.rb
22/12/2009  10:24 PM             2,323 GREED_RULES.txt
21/01/2010  06:32 AM               895 path_to_enlightenment.rb
21/12/2009  04:38 PM               159 Rakefile
02/01/2010  10:19 PM             5,482 README.rdoc
22/12/2009  10:24 PM                70 test_helper.rb
18/01/2010  12:29 AM               821 triangle.rb

Open your favorite editor, launch the console and start running the Koans, just type rake and you will be presented with messages like this,after fixing it your awareness will “expand”.

Thinking AboutOpenClasses
  test_as_defined_dogs_do_bark has expanded your awareness.
  test_after_reopening_dogs_can_both_wag_and_bark has damaged your karma.

You have not yet reached enlightenment ...
<"HPPY"> expected but was
<"HAPPY">.

Please meditate on the following code:
./about_open_classes.rb:26:in `test_after_reopening_dogs_can_both_wag_and_bark'
path_to_enlightenment.rb:28

It’s very addictive, the only complain/suggestion I have is to provide some answer to some of the question in the code. May be in a separate show?

    # THINK ABOUT IT:
    #
    # Is it better to use
    #    obj.nil?
    # or
    #    obj == nil
    # Why?

Since I started using Git a few months ago, and particularly GitHub since last September, my life have been good in DVCS land.

I used to be a Subversion user and I was happy*, maybe because I didn’t know anything better. Of course I heard all the cool kids (specially in the Ruby world) talking about Git and bragging about it, but I was being loyal to my old pal SVN.

But this was slowing me down and I wasn’t aware of it. I’m not sure what make me install msysgit for the first time. After struggling a little bit at the beginning and wrapping my head around the concepts and the commands I noticed that my flow started to change.

This change was good. Was more Agile. Doing small commits for little changes of code seems natural since the speed of this commits was almost instantaneous (remember the commits happens in your own machine). I’m talking of commits been done almost at the line of code level.

Change this line, run the test, commit. Write another test. Make it fail. Write some code. Make it pass. Commit. Refactor. Run test. Commit. Keep going.

Once It was time to push those changes to the master a single command push every change + every comment at blasting speed.

Since them I started using Mercurial as well and the experience was very similar. In the case of Mercurial I just use TortoiseHg but I stick with the command line for Git for most of my operations and I’m glad of that decision.

I wasn’t planning on writing this post today but I just happen to grab the code for edgecase Ruby Koans from GitHub and it took me all of 1 minute to do everything. Here is the flow:

Open Console2 and launch the Git bash. Type the following sequence of commands.

Welcome to Git (version 1.6.4-preview20090730)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
Hernan@HERNAN-STUDIO /c/Development
$ cd Code/Ruby/Koans_unresolved/
Hernan@HERNAN-STUDIO /c/Development/Code/Ruby/Koans_unresolved
$ git pull git://github.com/edgecase/ruby_koans.git
fatal: Not a git repository (or any of the parent directories): .gi
t
Hernan@HERNAN-STUDIO /c/Development/Code/Ruby/Koans_unresolved
$ git init
Initialized empty Git repository in c:/Development/Code/Ruby/Koans_
unresolved/.git/
Hernan@HERNAN-STUDIO /c/Development/Code/Ruby/Koans_unresolved (mas
ter)
$ git help
Hernan@HERNAN-STUDIO /c/Development/Code/Ruby/Koans_unresolved (mas
ter)
$ git pull git://github.com/edgecase/ruby_koans.git
remote: Counting objects: 294, done.
remote: Compressing objects: 100% (286/286), done.
remote: Total 294 (delta 184), reused 0 (delta 0)Receiving objects:  44% (130/29Receiving objects:  45% (133/294)
Receiving objects: 100% (294/294), 51.84 KiB, done.
Resolving deltas: 100% (184/184), done.
From git://github.com/edgecase/ruby_koans
 * branch            HEAD       -> FETCH_HEAD
Hernan@HERNAN-STUDIO /c/Development/Code/Ruby/Koans_unresolved (master)
$

Notice that I had to type help because I didn’t remember if I had to add a remote or I was able to do a pull right away (I removed the help output from the console output fro brevity).

Of course the Ruby Koans are just a bunch of very simple text files but the whole process took me less than 2 minutes. I think that is not just because Git is faster but also using the command line for this type of task tends to be a lot faster than using a Gui tool.

If you haven’t try it yet go ahead and take the plunge. Go distributed, even if you work alone, you want regret it.

*I’m still using Subversion at work, looking forward to have the time to switch but we are dealing with some time sensitive projects so I don’t want to mess around with that.

I try to be pragmatic in my approach to development and one of the things that change the most are the tools I use to deliver software. There are several reasons why I change tools so often.

1. The evolution of the software I write call for new or different tools.
2. Search for efficiency and eliminate pain points.
3. I change my approach to software development and new methodologies need new tools.
4. I just love to try new stuff

In this post I want to concentrate in the tools used to manage projects and builds. Until recently my favoured tools in this context consisted of NAnt, CC.Net/Hudson and Subversion.

For bug tracking I used the bug tracker in Google code for my OSS projects integrated to TortoiseSVN or BugTracker.Net. (Note: At work we use FogBugz and we are very happy with it.)

Subversion was the first to go.

Subversion is a great VCS but I usually have two problems with it. Speed and problems with complex merges.

When I work alone, merges are not an issue of course, but speed still is. At the same time more and more people seems to be switching to DVCS (Distributed or Decentralized) systems like Git or Mercurial. After taking a quick look at GitHub and follow their tutorials I was able to move some of my projects there in a few hours. (Most of the time spent on reading and learning from other people mistakes).

Git is fast, Fast, FAST! The whole idea of local commits and clone repositories is fantastic and they really help me with my workflow in the sense that I can do one or two changes, commit, one or two more, commit, find a bug, revert change, finish a story, push to GitHub.

To manage Git I’m using a combination of command line and graphic interface using Git gui. So far I haven’t feel the need to use/install TortoiseGit.

I still have some projects hosted in google code and I’m using Subversion with them, I’m thinking on switch them over to GitHub once I start working on them again.

Nant followed it.

I don’t have a problem with XML so the fact that Nant is XML based does not bothers me, really. But I also like the power of a good scripting language to manage repetitive tasks. I decided to move away from Nant and try to adopt some of the newest build systems.

I took a look at psake and them I read “How a net developer learned ruby and rake to build net apps in windows” by Derrick Bailey and that convinced me to take the plunge.

My knowledge of Ruby is extremely rudimentary but I even with that handicap I was able to have a Rake build script up and running in less than 90 minutes. This script cleans the build target, create the Package folder, builds the VS solution, run Nunit test on two dll's, generate the NUnit report as an xml file, and run the migrations from Migrator.Net (that last part is not working yet, I will need to take a closer look at Migrator.Net command line args).

The most useful resource on Derik's post was Laribee's OMG Rake!. Laribee’s sample code and a few queries to Google was all I need. (No, I did not copy and paste ALL Laribee’s code, just use it as a reference)

Agile Zen or project management made easy.

I got a free account on Agile Zen the first week after they went live. I remember creating the account, playing around on the Board and leaving the site. My thoughts at the moment were something like. This is actually cool. Very nice design. Good usability. I should give it a proper test drive with some real project.

Of course, I never came back until last Friday. While working in a few features for Pronghorn I decided that it was time I stop spiking and started to write proper user stories to drive the framework. I remembered Agile Zen and went back.

The site looks great and there are some improvements since that last time I saw it.

What really amazed me is how intuitive the whole process is. There is no waste generated by using this tool. Creating stories is 1 click. Editing stories, another one. Color coding two clicks. Double click in a field to edit them, etc. Very easy, very intuitive. There is even a bar at the bottom with hints that I decided to hide and I didn’t miss it.

The site is very responsive and the only thing I miss is integration with a VCS system. They have a very simple API for paying accounts, but in the docs it looks like is read only, so no hooks in there (If anybody knows otherwise, please leave a comment).

I will keep using it for another week or so before making a final decision but so far everything indicates that I will be upgrading the account to a paying one pretty soon. (The free account only allows for one project and one developers, what is more than fair.)

Tying it up all together with CI.

As I mentioned before my main experience have been using CruiseControl.Net and Hudson as the CI servers. I installed TeamCity a long time ago to give it a try but I never use it. My first choice was to look for some hosted solution. After searching I only found a few and non of them worked with .Net (at least not at the moment).

I was going to go back once more with Hudson but I wasn’t able to connect to the Hudson site to download the code. (Their site is up now). So I decided to take a new look at JetBrain’s TeamCity. At the moment of this writing they are running the EAP for version 5.

I wanted to install it and use my newly crafted Rake build script with the .Net project and have my test report integrated in the dashboard.

First I got the msi from the daily builds for version 5.00. Double click on it to install the server and the agent and after a few minutes and two (three?) questions, the home page of the serve shows up in the browser.

Creating the first project and associated build profile was a breeze. I just followed along the instructions in the screen. A few times when I wasn’t sure what a given label meant, I made use of the contextual help.

I did have an issue but it was my fault when setting some relative path to the build file and the build target, for running test and creating the Package folder.

From downloading the installer to having the project building successfully took me between 10 to 15 minutes.

Conclusion.

This new setup makes me more productive since I have better tools that save me time in different areas like. Setting things up, working around their idiosyncrasies, configuration heavy or too verbose a language.

While this is a combination that works for me, yours may be completely different. The important part is to have tools that feel this roles and make sure that they are really working with and for you and not the other way around.

I have been playing at home for the last few days with different migrations strategies for db development. The one that I like the most so far is Migrator.Net. Here are the things I really like.

The migration project/code is independent from the technology you use to persist your data, so changing persistence strategies does not affect your migrations.
You have a good migration history, since each new migration is it’s own class. It provides an Up and a down method to run the migration or undo it. You mostly don’t have to write SQL, but you can if you need/want.

Let me clarify that point. I’m not one to mind writing SQL, I rather enjoy it and take pride to been able to write some clever statements. At the same time I recognize that most of the time you write very boring and repetitive task, but what bother’s me the most is the constant context switching from VS to Enterprise Manager. That has to affect your productivity.

The fluent interface is very easy to use, and I only had to consult the documentation to set up the MSBuild file to run the migrations from inside VS, mostly because my experience with MSBuild is very limited. I was tempted to use Nant that I’m very familiar with and they provide a custom task for it, but I use this opportunity as a way to get my hands dirty with MSBuild.

Writing migrations involves creating a new class that derives from Migrations and implement two methods Up and Down, you also need to add a [Migration()] attribute and specify the migration number in it. I decided to use a date+time migration number of the form “yyyyMMddhhmmss” that translates to something like: 20090726120152.

You can also use numbers like 1,2,3,etc… I prefer the date time format to work in a team, less chances of two people creating migrations at the same time.

But the title of the post is about a template for Resharper to create most of the work for you. So that was what I did, and you can download this Zip file with the template in it.

A very good presentation with lots of code to learn and appreciate some of the niceties of ActiveRecord.

You can get all the videos (110) here http://www.viddler.com/explore/oredev/videos/

If your team is comprised by more than one developer you should have some coding guidelines and standards in place. (I can make the case to have this guidelines even if you code along but that can be another post).

I’m not talking about software design or things like the S.O.L.I.D principles, but more “down to the code” styles. Ex: how to name private fields, Constants, Methods, etc.

Let me talk a little bit about my other profession. Journalist. As a young journalist I was teach and trained on how to write (in my case mostly write for radio and print media). I was teach about theory.

Style and usages in the media

I was taught on how long time ago the journalist wrote a news with a “square model”; telling a story usually starting from the beginning of it from a chronological point of view an moving forward.
I was taught about the invert pyramid style or how you write (and read) news today. Start writing the most novel event and move back in time, give some context as the news develop.
I was taught about the questions that you need to answer in your story, Who, What, When, Where, Why and How?
I was taught about the importance of the order in witch those questions need to be answered.
You need to learn those things to be a good journalist.

And them you start working as an intern, typing like crazy the notes that a more seasoned, older, and wiser journalist through to you with a few minutes to spare until the deadline. You apply what you learned and you learn more from the critics this “old guy” will give you. With time you learn to make exceptions, you learn when some of the questions don’t need to be answered and when they can be answered out of order.

Now there is one set of rules that doesn’t matter how much you learn and how experienced you are, you will need to follow. Those are the editorial line of the medium you are working on, the Manual of Styles and Usages. (See New York Times, The Washington Post Manual of Style and others).

Why should you follow this rules? You are a good journalist, you probed yourself in the field. Well you still have to follow this style guidelines because the newspaper, radio or TV network have to appeal to certain demographic. They are expecting to read a newspaper that reads like a book, with pretty much the same style. They expect certain perspective in the way the news is treated.

There are exceptions and that’s what the opinion columns are for. But even those columnist are selected by the editor.

Style and usages in software development

You can be a programmer without learning any of the design patterns or O.O. design concepts. You can a programmer without caring about the S.O.L.I.D principles. And of course you can be a programmer having complete disregard for any style on your code. Your code may work. Your code may even work well enough to do the trick, to solve the problem at hand.

Of course you want to be a good programmer. And so you will need to learn about all those things, and refactoring techniques, and other languages besides the one you use in a daily basic, and tools.

And them you will notice that you read your code way more than you write it. And you share your code with other developers and you read their code as well.

So you want them to understand your modules and you been able to understand their code (or the changes they made to yours). You want to spend your time following the code, reading it and not deciphering it.

So you will realize that you need those coding guidelines. Of course you want to draw from the common knowledge and advise of more experienced programmers and you don’t want to create rules that will look foreign to other developers that use the same programming language. You don’t want to use java conventions on C# code for example, the code will look strange for other c# developers.

Rules should be as detailed as needed. And rules should be allowed to evolve with time and with a better understanding of what works and what doesn’t for the team.
Consistency among your code base will increase productivity, prevent mistakes (since understanding the code is easy) and increase maintainability. All these will led to higher quality.

And higher quality is what we want.

InfoQ has a video recorded at JAOO on witch Robert Martin talks about craftsmanship and ethics on software development.

Martin is a very good presenter and the video captures his energy on stage.

Stefan Tilkov is one of the guys behind the fabulous info.com and is a big REST proponent. The talk is titled REST, an alternative to Web Services.

You can watch here or go right to Parleys.com

I try to practice TDD most of the time these days. I don’t write new code without a test first. A few years ago write the test first was something that I understood from an intellectual point of view but it sounded impractical. Today I can imagine going back to my old practices.

So, now I’m one of those advocates that try to convert other developers to the practice. I try to draw from my experience and I try to address their concerns as a challenge to discover new practices and improve mines.

Recently I came across this challenge. How you can write your test first when you are learning a new API of a library? If you practice TDD you will said something like, but that s the perfect scenario to use TDD! Now, that’s true but is not immediately evident to a developer that is just starting on the practice.

What we need to understand is that sometimes we can use the test as a learning tool. We also need to understand that we will refactor the test code. We can even use code that we originally used in our test and move that into our implementation.

Today I had the perfect example: we needed to convert a string into a DateTime object, the string is in the following format: 2009-01-07-23-15-09.

Our first implementation looked something like this:

//The unit test
[Test]
public void Check_that_when_converting_a_string_time_we_have_the_right_date()
}
    

    var controlDate = new DateTime(2009,01,07,23,15,09);
    var date = GetDateFromString("2009-01-07-23-15-09");

    Assert.That(controlDate, Is.EqualTo(date));
}

//And the implementation
public DateTime GetDateFromString(string date){

    var date = "2009-01-07-23-15-09".Split('-');

    return new DateTime(Convert.ToInt(dateParts[0]),
                        Convert.ToInt(dateParts[1]),
                        Convert.ToInt(dateParts[2]),
                        Convert.ToInt(dateParts[3]),
                        Convert.ToInt(dateParts[4]),
                        Convert.ToInt(dateParts[5]));

}

This worked but was messy, and besides adding some more test will make it fail easily. For example passing a malformed string. In those cases we wanted to have an exception raised that was meaningful. We imagine that we should be able to use DateTime.ParseExact() but we didn’t really know how it worked. O we changed our test like this.

//The unit test
[Test]
public void Check_that_when_converting_a_string_time_we_have_the_right_date()
}
    //Some code to get the cultureinfo

    var controlDate = new DateTime(2009,01,07,23,15,09);
    var date = DateTime.ParseExact("2009-01-07-23-15-09",”yyyy-MM-dd-hh-mm-ss”,culture);

    Assert.That(controlDate, Is.EqualTo(date));
}

And the test to check for the exception

//The unit test
[Test]
[ExpectedException(typeof(exceptionType)]
public void Check_that_when_converting_a_string_time_we_have_the_right_date()
}
    //Some code to get the cultureinfo

    var date = DateTime.ParseExact("29-01-07-23-15-09",”yyyy-MM-dd-hh-mm-ss”,culture);

}

We run the test and we see it pass, so them we just copy and paste the code into the implementation of the client function and we change the test back.

//The unit test
[Test]
public void Check_that_when_converting_a_string_time_we_have_the_right_date()
}
    

    var controlDate = new DateTime(2009,01,07,23,15,09);
    var date = GetDateFromString("2009-01-07-23-15-09");

    Assert.That(controlDate, Is.EqualTo(date));
}

//And the test for the Exception

//The unit test
[Test]
[ExpectedException(typeof(exceptionType)]
public void Check_that_when_converting_a_string_time_we_have_the_right_date()
}


    var date = GetDateFromString("29-01-07-23-15-09”);

}

//And the implementation
public DateTime GetDateFromString(string date){

//Some code to get the cultureinfo
return DateTime.ParseExact("2009-01-07-23-15-09",”yyyy-MM-dd-hh-mm-ss”,culture);

This is a trivial example and you may think that we probably should change the code in the implementation right away, and that may be ok in this case, but using this practice all the time make it natural later on when you have to deal with a more complex API, like using some third party component.

In a future post I will show how to use tests as a debugging tool that will help you to fix problems and ensure they don’t show up again.

This week the guys at the herding code chat with Chad Myers and Jeremy Miller on FubuMVC, testing with JavaScript and QUnit and SOLID principles.

http://herdingcode.com/?p=131

If you use Cruise Control.Net you may want to take a look at this project: CC.Net Community PlugIns.

Designed to be a repository for many different plugins for CruiseControl.NET. Hope to have many users contributing plugins to the repository.

My previous post got me thinking, what are the things I will considered as minimum requirements for me to work in a project even when I have serious constrains on time?

In requirements I mean methodologies and practices that I will need to use. After some thinking this is what I came up with.

There are at least three things, commonly associated to an Agile project that I will want to have in place.

• Source control (yes, there are still companies that don’t know what this is). Installing Subversion (VisualSVN server + TortoiseSVN) usually takes 30/60 minutes.
  
• Continuous Integration server, CC.net, TeamCity: install and configuration 3 hours maybe half a day.
  
• Using TDD as a design tool at least for the domain but only If I can use ReSharper or a similar tool (I can do with the free version of CodeRush as well).

This is the type of things that I use, even when writing some demo code or my own applications that I’m playing with. At home I have Subversion installed in my dev machine and in and old Pentium 4 that runs TeamCity.

I don’t think that this will add any significant amount of time and the benefits are such that I can see myself not using them.

I will probably don’t do much in the sense of integration test, (of any at all) in the automated UI test fields and code coverage. I like to do that but not in circumstances as described in the previous post.

Mohammad Azam has a post entitled When Being Agile Kills the Project. He mentions a project were the client gave a one month deadline not negotiable and so, he had to go and start cutting corners to make the deadline since, he wanted needed to keep his job (totally reasonable, keeping the job I mean).

Unfortunately, in this case the owner was fixed with the deadline and was not willing to move it further. The other option was to leave the project and search for a different one. This option was not reasonable for me as I was on a worker visa and finding another company to sponsor a new worker visa is like finding a needle in a hay stack

There is no discussion on this, but this post got me thinking. First the things that they have to sacrifice.

I said earlier that the reasonable deadline for the project was 3 months. This will include all levels of testing, clean separation of code, automated build etc. When the project was to be completed within a month I had to compromise many of the agile methods. The application was a simple 3-layer application with no unit tests and no automated deployment.

All this make me think that the company, the development team/division and everything else in general weren’t Agile (in a sense of practicing Agile methodologies). Mohammad was in a non Agile company, with totally unrealistic deadlines and in a terrible position due to the sponsorship. He manage to keep his client happy and keep his job.

The project was finish in exactly 29 days. I had to work some late nights but the project was deployed successfully.

But I had to disagree with the conclusions draw from his experience.

This experience led me to believe that all the projects cannot be agile projects. Sometime you will have to give up agile principles just to meet the deadline. Yes, the resultant code was messy but at the end I get to keep my job.

This is only true in situations like the one he described. I will paraphrase and said: Not all companies are ready to work in an Agile manner. This is true and will be true for a while, maybe for ever. I think that been in Mohammad situation I will probably do the same, write the code the faster I can to have it shipped. This doesn’t mean that projects can’t be Agile, any and all projects can be Agile. This is a question of the people involved in the project and not the project per se.

As a comment to the post mention:

• by Domingos on 12/23/2008 6:07:49 AM
• That's why being agile is not only about engineering practices.
  In order to be Agile, a company needs to change the way it does business.
  At the end of the day, it is about what applies to your situation. No one should never adopt all practices blindly without consideration.
  I would have done exactly what you did: put everything in a balance and decide what practice to use in your specific case. And you were 'agile', but no Agile. And I think that it is the the former that really matters.
  http://www.codeinstructions.com

Mohammad post reminded me how lucky I’m to be able to work in a company were not just Agile but even Lean principles are applied, and not only at the development level but by our clients.

A post by Igor Brejc with a set of valid points when implementing Continuous Integration.

Derick Bailey is doing a very good series on Kanban.

So far he posted about: The board, queues, order points, pipelines, handling bugs and emergency fixes.

You can find all the posts under the Kanban tag.

We have been looking forward to implement Kanban for a while and after a few delays we put the board up today.

We decided to define our pipeline using five columns:

• Backlog (queue)
• Analysis (queue)
• Development
• Divided in eight pipelines, one for each developer
• Testing
• Divided in four pipelines.
• QA –> Testing done by our QA guy
• Client 1 –> The client does the testing (2 pipelines)
• Development –> Development does internal testing
• Done –> also knows as complete or delivered.

We presented this idea to one of our internal clients a week ago and they are on board. Now the challenge is to make the process work and make sure that we look into what is working and what’s not and we make adjustments as needed.

We are now planning a lunch and learn to the rest of the company to bring every body on board. We are very exited about this one.

The board is in one end of the room visible by everybody.

Lava lamps, Orbs, led displays, they all have been used and are still being used to show the build status of projects under Continuous Integration.

What about using a big flat panel TV? Cruise Control provides information via xml as a service and leveraging that information is fairly easy, so why not to present not just the status but also the name of the project in the screen? Well, that is exactly what Big Visible Cruise does.

This is a WCF application, you just put it in a computer connected to a TV. Double click in the exe file, provide the URL for your dashboard and there you go.

It has a property in the configuration file to provide a Regular Expression to indicate witch projects to include in the screen. I prefer to just specify the projects explicitly, so I made a small change in the code to load a list of projects from a txt file and filter the projects using this list. I’m not super happy with the quality of the code, so I will work a little bit more on it before sending a path in case somebody find it useful. I want to use the configuration file to set the projects instead of a text file and probably filter the projects in a different way.

We put the TV near the development team but visible by all the company. We haven’t make a public announcement yet, but I saw some of the guys on the marketing team to looking at it when they walked by and one of them asked me about it. This is exactly what you want great visibility, hopefully will help us to improve communication with the other divisions.

And besides all that, It looks really great.

There is a nice video on Channel 9 about a study done by Microsoft Research about TDD and it’s impact on a real industry scenario.

The study was done post mortem, so the developers were not influenced while developing the product. The results indicate that the Quality of the code is substantial, but there is a slight penalty (on ma hours) due to time spend writing the test.

In any case the defect rates drops between 50 to 90 percent, so subsequent development and maintenance should be cheaper.

You can download the paper on the Empirical Software Engineering Group site make sure you click in the Local Copy link and not the title and you will save $34 .

The summary report

Adding more details to the details report.

Again I start using the supplied stylesheet but and I made the same changes (or very similar changes as in the previous file).I wanted to provide not just measures by class, but also have detailed measures by method and I wanted this to work the same way as the Nunit report does.You have an arrow besides the class name than when clicked displays the details for the class.To do so I copy some of the code from the unittest.xsl style from cc.netFirst you need to declare the applicationPath parameter<xsl:param name="applicationPath"/>Them you include the javascript to show and hide the details. Them you include the code to display the arrow and finally you add a for each to select all the methods inside the class and calculate the coverage.I decided to mark anything less than 100% as red.It's not because I think that we should achieve 100% of test coverage and if not the project is not complete, it's just that I wanted and easy way to find methods that may need to be tested on more details.Here is an image of the result with no details showing.



And here with details open

Adding the statistics

This actually went very smooth, open your ccnet.config file and add the following under the statistics tag of your project.<statisticList><statistic name="Coverage" xpath="ceiling(100 * (sum(//PartCoverReport/type/method/code/pt[@visit>0]/@len)+0) div (sum(//PartCoverReport/type/method/code/pt/@len)+1))" /></statisticList>The only part that I have to give it any thought at all was in the xpath expression to calculate the project coverage percentage, but I think that I got it, notice the +1 in the second part of the expression, this is to prevent division by zero errors, this shouldn't affect the coverage percentage calculation in any meaningful way.

Configuring CC.Net

Running PartCover.Net from Nant

Adding the report to the build

Next steps

A free tool to do code coverage with a nice GUI for the developers to use, that can be run on the command prompt, that generates nice xml based reports (to integrate with your CC server) and best of all for me) that works fine with Static methods.

This gem is called PartCover.

In the continuous quest to improve my team code quality I'm pushing hard to move more and more into a TDD approach. (I should make a side note here and indicate that at this moment my main concern is have a nice battery of unit test in place even if they are written after the fact). We are having clinics and the senior developers teach the junior guys how to use Nunit, Nant and now we are playing with some Code coverage tools.

We were going to jump into NCover since is the one that most of us have experience with, but there was a problem and it was that our massive Utility library is mainly a collection of static methods and NCover doesn't seem to like Static methods, so there are no metrics of how much code have been tested in those libraries. That is a bit of a problem for us.

Another issue was that now NCover seems to come in two flavors (or two projects) the free one in sourceforge and a commercial version at Ncover.org. The price for the commercial version is not terrible (169 to 199  USD + service plan if you want)  and we thought that we may run it just in the integration server in the worse case scenario. The free project have a note in the home page that discourage us from use it, and that is that the project to cover needs a reference to a Ncover library. We are not sure if they are talking about the testing project (the one with the test fixtures or the actual library that is been tested, something that sounds crazy), but in any case having to include another dependency was a big deterrent for us.

The commercial version was fine, fairly easy to set up (even without a lot of documentation, why is documentation for this tools so cryptic?!) and worked well enough, but the lack of measurement in static methods was bad for us.

You can argue that you shouldn't use static methods in such a liberal fashion and that make for a bad OO design (something that I agree) and makes your programming model look more and more like procedural and you will be right, only that in this cases there is no major implementation and besides a Network library and a serialization library that needs to be re-written the lions share resides in our Utils class.

PartCover to the rescue.

I was upset with the compromise and took me almost no time (the second search on google) to stumble upon this free awesome tool. The interface is similar to NCover but more frugal.

There is a File menu with four options:

Run target (to generate the report)
Open Report
Save report as
Exit

It can be more straightforward.
To generate the report you will to enter the same data as in NCover.

Executable file: should point to the console exe for your testing framework in my case nunit-console.exe
Working Directory: This is the folder where the dll with your test fixture resides, for example C:\Project\Project1\UnitTesting\bin\Debug
Working arguments: Depends but in the case of nunit is the dll where with the test fixtures (ex: UnitTesting.dll)

The tricky part is the fourth text box (a text area really), where you enter "Rules", this rules tell PartCover witch assemblies/classes to look for coverage and what to left out.

For example if you have to dll one called Mainframe.dll and another one called desktop.dll and you want to check both of them you will enter a Rule like this

+[Mainframe]*
+[Desktop]*

To exclude the mouse class from the desktop dll you add the following

-[Desktop]*mouse*

Another nice feature is that the dll with the fixture is not included (another thing that bothered me from NCover). The tool has a command prompt option, so running from Nant is no problem, and the report is generated as xml, so integrate it with CC.net should not be an issue, the even provide two xslt files to display the report based on the assembly or based on the class very neat!!!.

UPDATE: Two days after writing this post I found the SharpDevelop will be (is) using PartCover in SharpDevelop 3.0 and beyond.

I have been working in different companies where the practice of an Agile methodology is in place, but in most of them the part that is always left behind is pair programming and/or code review.

Let me explain the factors I usually see affecting this decisions.

Pair programming:

It's usually difficult for managers to grasp the concept, they see having two developers working in the same code as a waste, no matter how you explain this to them they just see two head counts doing th work of one, and that is not good for them.

Code review:

Time is of the essence and the believe of some managers is that if the code pass unit testing, integration testing and QA, the code is good and there is nothing to be gain with code review, because the code "works".

In same cases even the developers involved in the project have a hard time with the concept of other developers looking over their shoulders why their work. They are intelligent enough or experienced enough to do the task at hand without any help. They also have a hard time taking critic on their code.

The problem seems to be that managers need productivity and sometimes is difficult to show the benefit of this two practices when a project start, just telling the manager that the code base will be easier to maintain in the future and more robust doesn't cut. It's true that code writing in this way usually goes through the QA cycle faster, since all developers involved have time to fix and improve the code along the way, but you need to have good metrics to show those gains to the management team.

And on the developers side, our larger than normal egos are easily bruised, so the need to present this practices in a way that make then look atractive to the parties involved.

I'm lately encouraging pair programming in my team and we try to mix and match developers with different backgrounds, the idea is that the though process will be different in both of them and this have resulted in some very creative solutions. It also makes it easy for the developers to accept the practice, now they are both teaching and learning from the experience.

We are also doing code review but we changed the name, we now call it "The Refactoring Phase". Of course some refactoring is done while writing the code but this semantic change has made everything easier.

 If you are one of those developers that have a hard time with code review I suggest you read two of my previous post about extension methods, thanks to the comments I was able to improve the code, found some bad practices in it, and even found a duplication of functionality in one of the methods.

The code was working before and was able to pass all test, the job was done and fine but thanks to the code review now we have better and more performace code.

Of course this will never happens to you, because all the code you write is perfect That is a normal feeling and it's ok, we need that to be able to deal with the every day  issues of a developer life (look at this video to find out more).

To conclude this rant, if you are a manager: start implementing both this methodologies in some pilot project, you will see the benefits after a while. If you are a developer embrace this practices and try to use them, talk with your colleagues about the problem at hand and try to put something together sitting in the same desk using the same computer you will be amaze of the code that you write and how well this all works.

Virtualbox is a free open source virtual machine software. I have been using it to run, Ubuntu, Fedora, BDS and a virtual XP machine with all the new stuff for testing and I love it.

The performance is great, installing the software can't be any easy and configuring the virtual machines is a breeze.

I totally recommend you give it a try.

I am an entusiast of Test Driven Development but sometimes I have the problem that is difficult to know how to start testing. The problem usually is, very ambiguous requirements provided by the client. I know that we all have sometimes this problem and this is not an issue related to TDD, this is an issue related to pretty much any development practice.

Here is when BDD comes to the rescue. I read this article from Dan North's blog and everything makes sense.

I have started to play around with nBehave and so far I like it, now I will love to have a pure english editor or some kind of wizard for my clients to be able to define requirements easily.

I'm working in an application originally programmed in 200 by only one developer. I really clever guy that put in place quiet a bit of base code. The original design of the application is not all that bad, but several waves of developers have done maintenance on it. The browser landscape have changed and the application, been live and having a lot of success have to be patched on the fly.

This patches have created a lot of crud and the whole base coded it's getting tired.

I'm not going to go in details about the server side code, I want to concentrate in the client side part of the app.

We notice the problems mostly in the html generated. It's not standard compliance since was done back them when you needed to support Netscape 4 and IE 4 (that was a real nightmare) and most people was using tables for layout, images as spacers and the style was mostly applied inline (we know today that these are all very bad practices). The JavaScript code is also old and you find the same method that does almost the same thing in four or five places, sometimes we found exactly the same function copy and paste with comments and all in two scripts files, and them both scripts file were included in the same html page.

So we decided that we had enought and was time to fix the problem. The application syndicate a lot of it's content in the form of widgets and we want to make sure that we are not breaking somebody else code (our bad html has been the source of complains from some bloggers). Also we need to be sure that the css classes and the javascript methods that our widgets use are not going to interfere with other people applications.

This should be a common concern for anybody doing webs sites today. Web 2.0 may have lost it's original meaning and today is mostly a marketing term, but it's quiet possible that you end up doing some type of mash up in the near future.

Some tips that you may found usefull:

1. Use a global namespace to contain all your global variables and global methods.
2. Create other namespaces but try to keep the tree short (I try to keep my hierarchy under three levels)
3. If you work in a shop that have more than one product, separate your common functions for that application intro specific scripts using a second level NameSpace.
4. Do not use eval (just for security).
5. Pass data around using JSON instead of a propietary format.
6. Check all your scripts in JSLint either online or install YSlow on top of Firebug and run it there, there is a third option that allow you to run it in the commad prompt called jslint4java but I have different results in the same script running it this way.
7. Sit down and try to map in a text file how your are going to divide your code (general rules, like naming conventions and directory structure) even if you do Agile a little bit of architecture never hurt anybody.

I recommend that you take a look at the serie of videos by Douglas Crockford in the YUI theatre.