There are often times where it’s necessary to have some sort of template in a string, with placeholders that will be replaced with data-driven values at runtime.  Examples of this include email templates, mail merges and even integration scenarios.  Now there are many sophisticated and complex approaches to solving this problem, but here is a simple approach that works:

public static class StringExtensions
{
    public static string AddTokens(this string message, object tokenValues)
    {
        return tokenValues.GetType()
                .GetProperties()
                .Select(property => new
                            {
                                Key = property.Name,
                                Value = property.GetValue(tokenValues, new object[0]) as string
                            })
                .Aggregate(message, (current, token) => current.Replace("{" + token.Key + "}", token.Value));

    }

}

And to show you how to use it:

[Test]
public void ShouldReplaceTokens()
{
    var result = "1234{numbers}890".AddTokens(new { numbers = "567" });
    Assert.AreEqual("1234567890", result, "Tokens not added correctly");
}

ASP.Net MVC has some great abstractions over HTTP and the various Http classes, but one area which is currently lacking is around processing of file uploads.  Uploaded files are (still) available on the Request.Files collection and some posts suggest that you should go down this route.  And for testing, Scott Hanselman has provided some (fairly scary) mocking code.

Now Phil Haack has suggested a few improvements on this, but it’s still not as easy to test as I’d like (I’m a lazy developer, really) – I like to avoid mocks when I can since they can easily obscure the intention of the test.  Fortunately MVC model binders came to my rescue here.  Note that my web UI is only ever submitting one file.

DTO class:

public class UploadedFile
{
    public int Length { get; set; }
    public string ContentType { get; set; }
    public string FileName { get; set; }
    public Stream Stream { get; set; }
}

Model binder:

public class FileUploadBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var postedFile = controllerContext.HttpContext.Request.Files[0];
        if (postedFile == null) return null;
        return new UploadedFile
                   {
                       Length = postedFile.ContentLength,
                       ContentType = postedFile.ContentType,
                       FileName = postedFile.FileName,
                       Stream = postedFile.InputStream
                   };
    }
}

Controller action method:

[HttpPost, Authorize]
public ActionResult PeformFullUpload(string dataSourceName, 
            [ModelBinder(typeof(FileUploadBinder))] UploadedFile uploadedFile)

Test code:

[When("the user submits a file")]
public void PerformFileUpload()
{
    var uploadedFile = new UploadedFile{ Stream = _memoryStream};
    _viewResult = _controller.PeformFullUpload(_dataSourceName, _uploadedFile) as ViewResult;
}

Now that’s how I like my tests.  

Retrospectives are a frequently overlooked aspect of scrum.  Perhaps this is because they are “non-functional”, in the sense that they don’t contribute directly to the output of the team.  I maintain, however, that good retrospectives are the key to a highly functioning team.

What is a retrospective?

A retrospective is a meeting where the team get to reflect on their current progress and process and decide how they can improve it.

What does it mean to improve progress and process?

It can mean absolutely anything … the team get to decide.  Remember that the purpose of scrum is to build a team that can smoothly and effectively deliver business value on a regular basis.  Anything which gets the team closer to this goal counts as an improvement.

It’s also important to point out that it is the team themselves which decide how they can improve.  People such as managers, IT directors, agile coaches and so on can make suggestions, but the team needs to take ownership of their process.  This is what it means for a team to be “self-organising” … an agile term which is bandied around a lot and is often misused.  The self-organisation of a scrum team is the main points of retrospectives.

What’s the difference between a good and a bad retrospective?

Retrospectives, like a lot of things in agile, need to be judged on their outputs.  A good retrospective will produce improvements that address important issues the team is facing.  A poor retrospective will skirt around issues and address unimportant issues.

For instance, suppose a team is consistently releasing buggy software.  A good retrospective will attempt to address the bugs, both in terms of fixing outstanding issues as well as attempting the underlying cause of the bugs.  A bad retrospective would focus on other incidental issues, e.g. variable names not adhering to the agreed coding standards.

Poor retrospectives can happen for a number of reasons:

• they may be unaware of how well they are meeting business priorities (e.g. they don’t know that their software is buggy)
• the team may be unaware of business priorities (e.g. they may mistakenly think that the bugs have a minor impact)
• the team might not care about business priorities (e.g. they don’t care about their bugs)
• the team may be unwilling to talk about their problems
• the retrospective meeting might get side-tracked into addressing low priority issues
• … and so on

Some of these issues can be addressed by ensuring good communication between the team and the business.  Some of these issues can be addressed by being careful with the retrospective meeting and its format.  The retrospective meeting can be structured in such a way that it encourages the team to discover, explore and address their big issues.

What’s the format for a retrospective meeting?

There is no single format retrospective meeting, and there is no retrospective format which is best.  Retrospectives can take many forms.  In fact, the format of retrospectives should be changed from time to time, as this encourages people to think about their situation in new ways.  A great resource for ideas about different formats is Agile Retrospectives, by Esther Derby and Diana Larsen.  There are many other resources available on the web too.

What would you suggest as a starting point?

Here is a retrospective which I often use for teams that are new to retrospectives.  Please do not use this without thinking about it and deciding how it will fit your team.

1. Introduction

Some sort of icebreaker activity.  For instance, everyone gives one word that for them sums up the sprint. It can be accompanied by explanation or not. Questions are not allowed at this point, since people should be thinking rather than talking.

2. Review previous actions

Look at the actions from the last retrospective.  Decide which were completed, perhaps discuss how effective they were and decide which, if any, the team should carry on with.

3. Gathering data

Everyone writes post-it notes to fall into 2 categories - "What went well" and "What went not so well". The team gets 10-15 min to write the notes and then individuals take it in turns to stick them up onto a whiteboard. As they stick up a note they should introduce it to the team "I wrote xxx because I felt that ...". Some questioning is allowed here, but the point is really just to gather information.  The use of post-it notes is a great equalizer and prevents dominant characters from dictating the course of the meeting.

4. Extracting insight

The facilitator then looks to group up the post-it notes into topics / themes. For instance, there may be a number that relate to daily standup meetings. Put these in a clump.

5. Decide on actions

The team now decide on actions to address the items that didn't work well. Start with the biggest clumps of post-its, since those are the issues that are causing the most pain. Generally it's not worth trying tackle all issues. When you have 4-8 actions then call time. There should be lots of discussion and brainstorming during this part of the retrospective. All actions should be specific and should have an owner who is prepared to take responsibility to see it implemented during the next sprint. If nobody volunteers to own an action, then throw it away because clearly nobody wants to see it implemented.

Actions which cannot be implemented by the team are not allowed, e.g. “business users must stop changing their mind”.  Actions which are vague (e.g. “improve communication”) need to be explored more and made specific.

I’ve updated the previous session downloader, originally published by Naeem and Marcin, to download the sessions from BUILD Windows 2011.  It will give you the option to download only the sessions that have video published, so you’ll need to keep checking it over the next few days as sessions get published.

The app will run up to two concurrent downloads, and will queue up further requests.  So you can tell it the list of videos you want, and leave it to do it’s thing.  Downloads can be cancelled.

Note that it’s the High Quality WMV that will get downloaded.

You can get the source code at from Bitbucket, or you can download some pre-compiled binaries (.Net 3.5 required) or you can now get it using clickonce here.  Please let me know if you have any trouble with it.

UPDATE: Forgot to mention, as with the previous downloader this app supports resuming of partially completed download.