The Swedish brass band movement has a new champion… The king is dead - long live the king!

Stockholm Brass Band is the new Swedish Brass band champions. And that’s a real shocker for most of us. WindCorp Brass Band has been leagues before Stockholm when I’ve heard them but somehow the managed to nick the title from WindCorp.

Don’t get me wrong - Stockholm is a great band with some truly amazing players (like Håkan Björkman for example). But WindCorp has loads of experience from many, many brass band competitions - something that there is not an abundance of in Stockholm.

My congratulations to Stockholm! Well deserved! And very impressive since the preparations has been surrounded with a lot sickness and problems to get a full band to rehearsals.

OK - it’s so late for this. They have probably started soon. But here is my predictions for the Swedish Brass Band championships:

The winner is almost obvious - Windcorp Brass band is the best band in Sweden now and for a long time ahead. They play so well and have loads of experience to go with it. They will win. Probably with a big margin as well.

Number two should be Stockholm Brass Band. They have the best line-up, but it consists of mostly professionals. And rehearsing for two weeks straight without pay is not the highest priority. Also it has been some sickness disturbing the preparations.

Solna Brass will most likely take the third place. But they are a dark horse to nick Stockholm at the first one. They meet every week and rehears very serious. They could do it.

So here is the probable...

The other thing that really impressed me this week was the use of policy injection and aspect-oriented programming in our code.

I mean, you write aspects (or policies) for things like logging, performance counters, caching, and error handling, and move all that stuff into configurable policies. What is left in your code?

Pure and beautiful business code (or at least problem domain code).

It’s so nice - we’re cleaning up code every day in our project, and I just love to remove logging and error handling from my code and see my business code emerge from the muddy waters of “cross-cutting concerns”.

This video opened my eyes to aspects. It’s for PostSharp, which is another framework for doing aspects, but the concepts are shown clearly.

This week I have made two discoveries that really has made me happy. They are not news by any means but I has been like they have clicked into place in my brain.

The first one is surrounding the subject of testing in agile projects, which a lot of people seems to have opinions about - but I haven’t heard anyone go: “Do like this!”. I suspect that it has to do with current testing process are rigid on many companies and there is a reluctancy towards changing the quality assurance process. Also the amount of regression testing increases for each sprint.

We have had some trouble to get testing to work smoothly in our projects, but we are closing in on a solution. I do not claim to have the answerer or not even know much about the theories behind this big subject - but this works fine...

Avega is starting up a corporate blog and have asked me to post some posts there. Sounds great so I have just posted in some items from www.marcusoft.net to my “Avega”-alias.

http://blog.avegagroup.se will not be live in a few weeks though, so keep cool until you can read me in … stereo. ;)

A few interesting questions arose:

• How will Google tackle the indexing. Will a search for “marcus hammarberg” yield a hit at the Avega-blog before www.marcusoft.net?
• How to use Windows Live Write (which I have fallen in love with) with SubText.NET (the Avega blog engine of choice)? Luckily there is a simple solution here.

Here are some of the latest pictures of Albert (and one that includes Elin). He’s sick right now but the mood is still on top.

I found a feature that I thought was a bug in Visual Studio… If you have ReSharper (4.0 in my case) installed, it shows your missing references directly in the .config file.

Of course, there are limitations to this—secondary references cannot be resolved, but it is still a great help. Unfortunately, it confused me for a while, thinking it was a bug in the config editor of Visual Studio. But I take that one on me.

Let me first be very clear - I’m not a RegExp-guy. I find them quite hard to understand at times and often take refuge in .NET code.

Also, I was very surprised to not find any hits for the search of “RegExp even numbers” - I thought that I would find numerous examples.

But after reading a bit here, I learned enough to create my first naïve regular expression - a regular expression to allow only even numbers:

^\d*?((0)|(2)|(4)|(6)|(8))$

Again, my apologies for being a newbie on this… but hey, it works.

I also found this resource very useful for trying out my expression.

Regular expressions are very powerful, but “with great power comes great responsibilities”… - that is, they are often hard to understand.

Thanks, Fredrik S, for the links.

OK - sometimes it just to confess - I took a chance, or didn’t know what I was doing - call it what you want.

In TFS Build-scripts there are a much nicer way of calling MSTest than the Exec-task as I suggested. There is already a task for it, called TestToolsTask. With this task you can much easier reach all the properties you need. And it even contains some undocumented features such as the TestContainer-property.

Here is my updated version on how to call the task:

<TestToolsTask
  TestContainers="$(BinariesRoot)\Debug\Company.Service.Host.Test.Integration.dll"
  BuildFlavor="%(ConfigurationToBuild.FlavorToBuild)"
  Platform="%(ConfigurationToBuild.PlatformToBuild)"
  PublishServer="$(TeamFoundationServerUrl)"
  PublishBuild="$(BuildNumber)"
  PathToResultsFilesRoot="$(TestResultsRoot)\..\IntegrationTestResults"
  TeamProject="Betalningsplattformen2"
  ContinueOnError="true"
/>

[UPDATED, see this]

I have created a task that runs some unit tests in a certain DLL and the publish the result to a TFS service. We use this task in our TFS MSBuild script in order to execute some integration tests in the last step of the build process. In order to get some value from the integration tests the solution needs to be deployed, for example.

The most tricky parts of figuring this out was:

• The path to MSTest.exe - as it turns out there are a environment variable to the root of the Visual Studio Tools - %VS90COMNTOOLS%. And via that we can reach MSTest.exe with%VS90COMNTOOLS%\\..\IDE\MSTest.exe
• To publish a build you need the buildId to send to the publishbuild-parameter of MSTest. It can easily be obtained from the TFSBuild parameter $(BuildNumber)

So here you are - my task to run...