Andrew Stopford's Weblog

Blog move

andrewstopford — Sat, 01 Jan 2011 15:01:00 GMT

I will be moving this blog to http://andystopford.wordpress.com/

RSS feed address is http://andystopford.wordpress.com/feed/rss/
Atom feed address is http://andystopford.wordpress.com/feed/atom/

I will cross post a few posts over the next few months but please move any feeds over to the new address.

The year ahead, 2011.

andrewstopford — Fri, 31 Dec 2010 00:15:00 GMT

When I look back at last years look at 2010 my blogging rate has not changed much (I suspect this is largely down to using Twitter a lot) but my interests this year have developed a lot further.

My view on 2010 would be that Microsoft would commit more to OSS, while I wanted to see more hires from that audience and more projects on Outercurve foundation instead there has been support for JQuery and Gems (aka NuGet). I would love to see more from Microsoft on the OSS front in 2011, Outercurve could become like the Apache foundation with enough support.

Staying on the Microsoft front I predict that 2011 will bring the following.

C# 5.0 will go RTM (still no MOP though)
The next release of VS will go alpha or early beta
MS MVC 4.0 (I think by Mix time) and maybe this release will get a command line.

I also suspect that Microsoft will want to target the tablet market with WP7 in 2011 (Mix 2011 maybe...).

I also predict the following

Java will fork with Apache\Google. Oracle will then take them to court and the whole thing will boil right through 2011 (Java have had enough court cases, come on guys). Java and the JVM will sadly not move forward at all in 2011.
Android will cause Apple a serious headache, both the smartphone and tablet market will see figures cut from Apple share. By the end of 2011 the current 70% apple market share will be 40-50%. As the features, performance and price of Android devices gets ever better Apple will be left out in the open.

Lastly after 7 years I intend to move this blog away from weblogs. In 2011 I will be exploring Java, Ruby\Rails and Android and such subjects don't make sense to talk about it here.

See you in 2011.

MbUnit\Gallio 3.2

andrewstopford — Wed, 22 Sep 2010 20:15:00 GMT

MbUnit\Gallio 3.2 was released today and includes many new features and fixes.

The release notes can be found here, you can find the download here.

Icarus

Icarus continues to grow as feature rich GUI for running unit tests, this feature has added a search feature as well a number of bug fixes.

Echo

New command line option to allow reports to be compressed as a Zip.

We also offer this support in the MsBuild task, CCNet task and PowerShell integration.

VS Integration

As noted in previous posts Gallio has offered integration with the VS unit test tools for some time now, in this release we have added support for the new VS10 Data Collector feature.

TD.NET

You can now configure TD.NET options from within the Gallio control panel.

MbUnit.

This release has added a number of new features to MbUnit.

The Mirror framework replaces the reflection support that has existed since v2 and offers a powerful way of testing non public members.

Assert.Count

Also see this post from it's author.

Brand new XML Assertions

Assert.Xml.AreEqual
Assert.Xml.Exists
Assert.Xml.IsUnique

See the new documention on this feature and this post by it's author.

Hash code acceptance contract verifier

Also see this post from it's author.

New Attributes

[Converter] attribute.

[Comparer] attribute.

[EqualityComparer] attribute.

[Formatter] attribute.

[Disable] attribute to create abstract test fixtures and methods.

Fluent syntax for the Data Generation framework.

Also see this series of posts on the MbUnit Data Generation Framework.

Other

Gallio\MbUnit debug symbols.
Installs in the correct program files folder when using a 64 bit OS.
New command line option in Gallio.Utility to format an existing XML report.
Supports .NET 4.0
Support for R# 5.0 and 5.1.
Support for XUnit 1.6.1 and NUnit 2.5.7
A number of bug fixes

This release was made possible with contributions from Jeff Brown, Yann Trevin, Graham Hay, Vadim Kreyin and Andy Stopford. The core team also wishes to thank the help of Euan Garden, Bruce Taimana and Michael Koltachev.

Finally, with this release I am resuming my role as MbUnit's poobah and help drive Gallio and MbUnit on to the next milestone.

OCP : Open Closed Principle

andrewstopford — Mon, 16 Aug 2010 12:31:00 GMT

The O in the SOLID principles, Uncle Bob explains this simply

A class and it's component parts should be Open for extension and Closed for modification.

To follow this principle let's take the clock object again. We know from SRP what parts are responsible for what and when we mix these we can create new kinds of clocks. Certain things may be internal to a clock part such as the clock face.

The clock face may be composed of several different things such as the display, hands and numbers etc. If the face was to change from say roman dail to micky mouse we don't want to have one clock face object that we have to keep changing\rewriting for every different kind of face (you risk code duplication) but instead give it (extend it) the component parts it needs. A mickey mouse clock face would have mickey mouse hands, display and numbers but would display the hours\minutes via the rest of the clock object in the same way as the roman dail or any other type of clock face.

In software terms the way we achieve OCP is with either simple inheritance or dependency injection. More on these in later posts.

Use Gallio with SharpDevelop

andrewstopford — Tue, 03 Aug 2010 12:09:00 GMT

Matt Ward has a sample that shows how to write a plugin for Gallio that can then integrate with the SharpDevelop IDE.

SRP: Single Responsibility Principle

andrewstopford — Thu, 22 Jul 2010 11:23:00 GMT

The S in the SOLID principles is one of the most simple and most important principles.

Let's take a simple example, one of a clock. A clock might have lot's of parts, parts that keep time, that tell you what the hour and minute of the day are etc.

A clock might also have other parts such a display to output the time. In OO the display would inherit the other clock parts to obtain the time and then display it. In an analouge clock this might include the clock face, hour hands, minute hands etc. In a digital clock this might include an LED display etc.

Now we ask the question while both displays are are concerned with the display of the time, the analouge clock is not concerned with the digital clocks LED display and the digital clock is not concerned with the analouge clocks hour and minute hands etc. Each display is concerned only with it's own display types and does not need to know nor bother with anything else. Both displays are not concerned with keeping the time, that is left to other parts of the clock, the only thing the display is concerned with is showing you the time.

If an LED display was concerned with clock hands it would break the SRP principle.

If we take this back to your coding we apply the SRP principle to everything from class to method, making sure that each is focused on one thing.

Technical Debt

andrewstopford — Mon, 19 Jul 2010 21:13:00 GMT

Technical Debt is subject that is very close to my heart, I first heard of the concept at a great session that Gary Short gave and ever since I have found ways of finding and addressing the problem. So what is Technical Debt?

Technical Debt is a like any other kind of debt.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, OO or otherwise. - Ward Cunningham.

So what causes Technical Debt, for that I'am going to borrow Martin Fowlers great quadrant diagram.

Every hack, work around, bad piece of code builds technical debt. So what it is the cost, an image from this great article sums it up well.

The real cost of Technical Debt is that for every bad piece of code, it can cause problems to your customers and cost you and your business money. It can cause you defects (and in some cases) cost the business money. It can takes other coders time to find and fix the problems or work with the code, time is money.

As time goes by and theh debt builds up the cost also goes up, the further the problems, the harder to resolve and the bigger the cost.

I'll move into approaches to resolving technical debt in later posts.

Working with Legacy code #7 : The boy scout rule.

andrewstopford — Mon, 19 Jul 2010 20:42:00 GMT

Uncle Bob outlines this concept well in in the 97 rules book.

Leave the code a little cleaner than you found it

In other words where you can improve and make better the code you are working in. In legacy code you should follow this concept with a blazing degree of intent. By its very nature legacy code needs to be better and no matter what you are doing or where you will need to improve it.

YANGI?

In legacy code it is always a temptation to leave behind the small things. Let's take for example a small function that has two 'return' exit points. While you can agree that such a small function may not cause too many problems and changing the function violates YANGI you can fall into a trap. Some else comes to that function and follows it's structure to add yet more exit points. Soon the function carries more technical debt weight then you came across it. With the boy scott rule you leave nothing behind, if you see it might cause problems not only for you, now, but also for the team in the future you make it better.

Working with Legacy code #6 : Technical Debt

andrewstopford — Tue, 13 Jul 2010 20:41:00 GMT

I'm going to write more about technical debt at a later date but it is a subject also worth covering at a legacy level.

Legacy code has a high level of technical debt by it's very nature, in following the series so far the debt is being managed and repaid. The danger you face is adding to the technical debt and never overcoming the debt mountain.

Consider very carefully the single responsibility principle, legacy code tends not to follow this principle and in the refactoring work your first aim is to strictly follow this principle. Failure to do so can result in code mixing concerns and in turns causes technical debt.

If you start to work with the code more, adding new code and failing to follow this principle can cause technical debt.

So why technical debt? Consider that when you leave the code behind and some else picks up the code if the code still has problems those problems need to be overcome, that takes time, resource, money (all debt to you, your project and your company). I do hear sometimes debt can be occured if a programmer is unable to work with the principle, such issues should be measured and balanced against the debt (what is the real cost).

Working with Legacy code #5: The blackhole.

andrewstopford — Tue, 01 Jun 2010 21:07:00 GMT

Someone creates a class or series of classes for something, the classes are big in size with large complicated methods. The effort is a sea of technical debt for the entire team but in the thick of the daily chaos it is lost. With out the coder talking to the team, with no team code policy and no code reviews (and action points) it remains. Pretty soon the team forget about that code.

A few weeks\months\years goes by, some of the team may have left, some may remain but business asks for the team to add to that code. The team is now looking at a black hole, no one knows how it works, what it does, what it is for, it is a smelly hell hole and the deadline is fast approaching.

The team now tries to change the code, with no approach at unit tests or refactoring in fear of breaking the black hole the team do just that and the business have just lost money.

If you are faced with a black hole you need to look back over my series, even a black hole in what might seem like a clean unit tested application. Don't be fooled into thinking that legacy code does not apply to your code base.

The next stage is don't let blackholes in your codebase. Effective code reviews, team communication and good overal team coding policies will really help. Even if you are faced with a deadline do not let them appear, stop, take stock, what can be done and who can help. If you allow them through they will grow and grow and grow and the technical debt will hit you like a tidal wave soon enough,.

Working with Legacy code #4 : Remove the hard dependencies

andrewstopford — Tue, 01 Jun 2010 20:54:00 GMT

During your refactoring cycle you should be seeking out the hard dependencies that the code may have, examples of these can include.

File System
Database
Network (HTTP)
Application Server (Crystal)

Classes that service these kind (or code that can be abstracted to a class) of these kind of dependencies should be wrapped in an interface for easier mocking. If you team starts refering to the interface version of these classes the hard dependency will over time work it's self free.

Gallio and VS2010 code coverage

andrewstopford — Tue, 04 May 2010 22:48:00 GMT

Scott mentioned on twitter a great post on using VS2010 code coverage with ASP.NET unit tests with the following comment.

So I figured I would work up a quick post on using Gallio with the code coverage features (and thus MbUnit, NUnit etc).

Using Gallio with the VS2010 code coverage features is exactly the same as you would use MSTest. Just enable the code coverage collector.

Select the assembly you want to profile (double click the collector to do this)

Run your test

Right Click and select code coverage.

Gallio and VS2010

andrewstopford — Tue, 13 Apr 2010 22:41:00 GMT

With the launch of VS2010 this week it seems like a good time to talk about some of the work that has been going on with Gallio to integrate with VS2010. This work will be a feature of the next release, no beta yet but you are welcome to try the nightly builds (all normal risks apply etc). Just like VS08 you can use the VS Test Runner to run Gallio tests (such as MbUnit) in the same way you can MSTest.

With Gallio installed the Test View window shows a Gallio (in this case MbUnit) test loaded (note the icon). If I go ahead and run this test I can see it working in the Test Results window.

In VS2010 you can collect additonal data that a test can include (system data, intellitrace data etc). If I set VS to collect system data and run the test I can click the 'Test run completed' link and see that it is included.

If I also right click in the Test Results window I can select "View Test Results Details" and a Gallio test results window will load up.

Note that Gallio treats the collector data as attachments so you can go ahead and view the attachment data right from the report.

Working with Legacy code #3 : Build a safety net.

andrewstopford — Sat, 10 Apr 2010 23:06:00 GMT

The first port of call in changing legacy code is a safety net, without one your fingers will get burnt. Make your safety net a high level functional test over the major areas of the application. Automate the test, plug it into your CI builds and run it every night. The test should act as a final fail safe as you work.

Working with Legacy code #2 : Understand it.

andrewstopford — Mon, 05 Apr 2010 20:19:00 GMT

In my last post I suggested drawing up a plan, the plan might be based on what you and the team already know of the code and your experiences so far in coding, fixing and refactoring attempts on the code base. Your plan might need further detail when you start to get into the finer detail of the codebase and into areas you and team may have never have been into before.

There are a great deal of ways you can do this, simple debugging and breakpoint for example but the detail learned can be lost if only ever used by it's self. Another approach is logging intercepts to log method calls as and when they occur. Using something like log4net can allow you to log to what ever medium you want with relative ease, if you don't want to leave logging calls around then a clean solution is combine with PostSharp. A third approach is a static analysis tool such as NDepend which allows you to really drill into the codebase. A fouth approach is to use code profiling tools like ANTS or dotTrace.

Combining the above can be a very powerful way of getting what the code is doing, for example tracing the code to understand the paths through the code that is taken and using static analysis tools to explore those classes\methods dependencies further.

The final step is documenting what you find, the more you find the more may go onto your plan. Your findings may change the order of your plan if you find objects are worse than you first thought.