After a nice offer to join the blog roll at devlicio.us I have decided to retire my existing blog at http://blog.goinsane.co.uk/, and move across to devlicio.us for my blogging.
I see this as an opportunity to rant at a new audience ... but I may post something useful from time to time too.
You can find future posts at: http://devlicio.us/blogs/casey/default.aspx
Prompted by a discussion on the altdotnet yahoo group ... why I like broken builds ...
Some people try desperately to avoid breaking the build, by doing very infrequenet check ins (the number of broken builds per day drops dramatically, the time to fix each goes up though), or by trying to ensure their development environment is as close to the build environment as possible.
But a broken build is not a problem - it is an opportunity. A broken build allows you to identify a weakness, and to resolve it early.
The weakness might be in your architecture, it may be in your dependencies, or in your assumptions, or in your developer skill levels - but the whole point of having a continuous integration server is to fail fast and let you deal with the underlying problems rather than the specifics of the code you checked in.
I've done it before, but my mind went totally blank yesterday ... due to some typically quick responses from the Castle Users Google Group ... here is the code to do it for future generations to avoid my same silly mistakes ...
WindsorContainer
container =new WindsorContainer();
Type eventBrokerServiceType =typeof(IEventBroker<>);
Type brokerType =typeof(EventBroker<>);
container.AddComponent("key",
eventBrokerServiceType, brokerType); IEventBroker<EventArgs> eventBroker = container.Resolve<IEventBroker<EventArgs>>();
Assert.IsNotNull(eventBroker);
A short while ago I wanted to get VSTS code coverage reports from NUnit tests ... and after some asking around found that using the Profiler I could get what I needed. I just released a CodePlex project to wrap this functionality. Hope it helps somebody else.
Project Description
This project is an attempt to provide a wrapper around the VSTS instrumentation and
code coverage tools.
VSTS provides very powerful code coverage tools with Visual Studio, but as packaged, you need to be running MSTest unit tests to obtain this coverage data. There is a way of getting this data without using MSTest though, bu using another test framework such as NUnit or MbUnit for example.
This wrapper encapsulates the generation of the .coverage file from a run of NUnit or MbUnit (or similar), but in addition it provides an automated generation of the .xml version of the .coverage file (both can be read by Visual Studio directly), and then uses an XSLT template to transform the XML output into a final human readabale page (by default a .html file)
Further extension will pull the actual parameters from the hardcoded values in the console application into a wrapper class, and will wrap both with a command line tool and with an MSBuild task - however the code is functional enough, and is transparent enough, that both of these tasks should be easy to implement for anyone wishing to do so for themselves if they require this immediately.
As I am about to use a number of these to try and identify weakenesses in our current requirements and documentation, I thought I would link them for the benefit of all - I'm not sure many people know these exist and are available online. They come from possibly the best book written on software development, Code Complete 2 by Steve McConnell
You can read the full list of checklists (a free and simple registration is required), but the ones I think are critical to the success of a project are from the Requirements Checklist. As Steve says, they may not be comprehensive, they may not be complete, they don't tell you how to do these things, it is just a good sanity checking list:
Specific Functional Requirements
Specific Non-Functional (Quality) Requirements
Requirements Quality
Requirements Completeness
We currently develop software in a fairly piecemeal and disjointed fashion. The software we develop could also be fairly accurately described as monolithic.
There are many problems that come with monolithic code, it becomes hard to maintain, hard to evolve, hard to reuse, and hard to adapt to changing requirements.
Symptoms of a Rotting Design[1] include:
Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules.
Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed.
Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon.
Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Changes that introduce new and unplanned for dependencies cause rotting designs. Each of the four symptoms mentioned above is either directly, or indirectly caused by improper dependencies between the modules of the software. It is the dependency architecture that is degrading, and with it the ability of the software to be maintained.
In order to forestall the degradation of the dependency architecture, the dependencies between modules in an application must be managed. This management consists of the creation of dependency firewalls. Across such firewalls, dependencies do not propagate.
Object Oriented Design is replete with principles and techniques for building such firewalls, and for managing module dependencies.
To avoid some of the problems we are currently encountering, we need to move towards software development based on good principles and practices. There is fundamentally little new in software development each year, but better refinement of common patterns and practices, and we should be leveraging those to provide a more stable and adaptable software codebase.
This document deals with a limited subset of the problem; specifically it is designed to explain the requirements for Castle Windsor and Castle DynamicProxy to be included in our code. As such it does touch on a number of principles that are only partially resolved by the Castle stack, it also omits many other good principles of software development – these can be left for another discussion.
There are a number of aspects of what we currently do that could be improved by better training, better practice, and better communication – but these will not be covered in detail here.
So as our problem is relatively wide in scope, here are some specific principles that we should be aiming for in our code. These are fairly widely established principles within the industry, so none should be of any great surprise. Possibly the greater surprise will be that we are using almost none of these, at least not in any explicit or agreed upon method. This list is only a subset of a wider set or principles we should be aiming for.
There Should Never Be More That One Reason for a Class to Change
Responsibilities should be considered as axis of change – if a class assumes more than one responsibility, then it has more than one possible reason to change, and becomes a weak point in the design. This coupling leads to fragile designs that break in unexpected ways.
This class level principle applies at a wider level, where it is commonly referred to as Separation of Concerns.
The principle that software components should be broken to smaller parts that overlap in functionality as little as possible. Examples of SoC in practice would be adoption of design patterns such as Model-View-Presenter, or Service Oriented Architecture.
A concern at modular level could be considered the separation of display logic, from business logic. The separation of data access from data manipulation. Or at a lower level, the separation of configuration from processing logic.
By separating each of the concerns away from each other – you obtain the ability to alter each of those concerns independently, whether due to a change in the requirements, and evolution of the system, a bug fix, or for any other reason you may have for change.
Application of SoC allows you to create and evolve Loosely Coupled Systems, a primary objective of good software design.
A: High Level Modules Should Not Depend Upon Low Level Modules, Both Should Depend
Upon Abstractions
B: Abstractions Should Not Depend Upon Details, Details Should Depend Upon Abstractions
By inverting the dependency structure we eliminate a common problem where a small change to environment or requirements cascades through our entire application. By using the DIP we isolate those changes.
Consider the most commonly written example, that of a class or component that requires configuration information – for the sake of this example let us refer to it as the DataService class.
A traditional approach to writing this might be to have the DataService class call the ConfigurationManager to get the settings it requires. At this point however, your class now depends upon the ConfigurationManager – it cannot be compiled if this manager is not present, it cannot execute if this class is not present, and it cannot have the source of its configuration information changed without a recompilation at least, and possibly a rewrite at worst.
Dependency Injection turns this concept upside down – quite literally. This is why this is commonly referred to as Inversion of Control (IoC) [5]
We now design our DataService class so that instead of it talking directly to a ConfigurationManager, it is given an abstraction of the ConfigurationManager by the code that created our class. The responsibility for the source and creation of the ConfigurationManager is no longer a concern of our DataService class, but of the thing that created it. So in our example we create an interface called IConfigurationManager, one implementation of which is our real ConfigurationManager. Now when we create our DataService, we tell it specifically which instance of IConfigurationManager it should use to get its configuration information.
This principle has multiple benefits, apart from helping achieve the primary objectives of maintainability, SoC and SRP, it also fulfils one other fundamental objective, it allows Unit Testing.
If a class like our original DataService is to be unit tested, we must have a ConfigurationManager in place. The ConfigurationManager must be the exact same version as will be used in our application, and it will bring with it all the dependencies it contains. In fact, you will probably have to put the DataService into a nearly fully implemented application, just to test a basic part of its behaviour.
After we have applied Inversion of Control we can now unit test the DataService independently of its configuration requirements. We can create a mock implementation of our IConfigurationManager that passes in a known configuration set, and therefore allows us to have a known outcome state after a request. We are no longer tied to tests that may break when someone changes the format of the configuration data, or changes the data store, and in the case of our DataService, we no longer require a database in place, just to see if the DataService correctly requests database information.
By using Inversion of Control we can now write valid unit tests. The qualification of “valid” is very important here, a poor unit test is one that tests more than it should – in much the same way as application of SRP, a unit test that tests more than one thing is fragile and prone to breaking for the wrong reasons.
A differentiation should also be drawn between a “unit test” and an “automated integration test”. While both may use a xUnit framework such as NUnit or MbUnit, there is a very important distinction. A unit test tests one thing and one thing only ... it tests a “unit” – an integration test tests more than one thing, hence it is not a unit test.
So back to our previous example, a unit test that tested a function of the DataService is desirable and should be our primary objective, but if it was to test the DataService that called the ConfigurationManager, it is now actually testing at least two components, and is possibly testing a few dozen more (all of the dependencies that ConfigurationManager has are being tested too). With IoC we can provide a mock IConfigurationManager and ensure we are only testing the DataService – a single unit. Changes to the ConfigurationManager implementation or one of its dependencies can no longer break our unit tests.
Not only that, but it is entirely possible in our example that we cannot unit test our DataService at all, as it requires infrastructure code and data that may not be present at test time. It is also highly likely that we will end up with a large and interdependent set of configuration sources within our tests to try and mimic all the possible permutations of configuration data we may expect, creating highly fragile and hard to understand tests.
One simple abstraction avoids all of this.
The example given so far is pretty easy to follow. We don’t access configuration within our DataService, but the code that creates the DataService also creates the ConfigurationManager implementation and passes it in.
However if you follow this all the way down the software stack, you will realise that at some point, there must be a concrete dependency ... something has to know how to create all these concrete dependencies, and therefore it has the dependencies itself.
This is where an IoC container such as Castle Windsor comes into play.
Inversion of Control containers allow you to achieve loosely coupled designs and they handle dependency and configuration management when you, or a class in your system, request a service to say, send e-mails, you will get an instance ready to be used.
IoC containers favour reuse as they allow you to use a natural idiom to expose the component's dependencies. This allows components to be used with or without containers. Hence you quickly end up with a library of reusable components that can be shared among projects, as long as you apply the Separation of Concerns principle.
Castle Windsor allows components within the system to be registered with it, and when it receives requests for those objects, it is responsible for creating them, and maintaining their lifestyles. Where you require a singleton, it will provide that for you, and where you require a thread pooled object, it can provide that for you too – without any alteration of your codebase.
More importantly, it is capable of resolving all sub-dependencies that a class has. So back to our example, we don’t need to create an instance of the IConfigurationManager, and an instance of the DataService, or create any instances of all the other things that DataService may depend upon – Windsor knows all of this and will do this work for us.
So when we ask Windsor to give us the DataService, it will create all dependency objects too, pull configuration from an external source if we have specified that, and return us back a single fully constructed object graph. This avoids the problems of fragile code, as a change to the dependencies of our DataService is now transparent to all the code that uses our DataService.
Windsor also brings additional benefits far beyond the basics of object creation and management. As it contains the ability to create interceptors, it becomes very easy to add functionality that exposes cross cutting concerns such as logging. When we request our DataService now, Windsor knows that our configuration says Windsor should attach a logger to our methods, and it will do all the work needed to create the classes to manage those objects. This functionality can be extended to allow for many other cross cutting concerns such as authentication, authorization, and extension of existing business logic.
The critical part of Windsor for us in many respects is that it is highly extensible; almost any scenario you can envisage with regards to object creation or management is a simple step to configure or to extend.
Castle Windsor is a component part of the Castle open source project that has been in existence since 2003, and was built upon lessons learned from the Java community and earlier .Net projects.
Most recently, part of the Castle stack, MonoRail has been a major factor in Microsoft moving towards MVC development under ASP.NET, with contributors to MonoRail being asked for their views on the development direction by the team developing ASP.NET MVC
Castle Windsor could also be said to have been a major influence in Microsoft creating their own Inversion of Control container, Unity. Unity is currently only under CTP, but will be released, as Castle Windsor is, with an open licence and source code available. There are a number of differences between Windsor and Unity, this document does not discuss them, and instead recommends Windsor initially, with an option to move to Unity should that need become apparent or viable in future – at present Unity does not solve many of the scenarios we wish to cover.
It is released under the terms of Apache Software Foundation License 2.0 [9], which is possibly the most open of all licences. The Apache License (versions 1.0, 1.1, and 2.0) requires preservation of the copyright notice and disclaimer, but it is not a copyleft license — it allows use of the source code for the development of free and open source software as well as proprietary software. Although lawyers can give you a legal list of restrictions this imposes, it fundamentally comes down to “do what you want with it as long as the copyright notice remains”
As an open source project, Castle Windsor could be said to be one of the most mature and continually developed projects around. Although officially at RC3 for a large number of months so far, this is mainly due to a project requirement that version 1.0 will not be released until the external API can be guaranteed to be stable.
On a daily basis, Castle Windsor can be considered highly stable, and is being constantly developed. The few bugs that are present are resolved rapidly, and there is commercial support available should that be a requirement – though with full access to the source code this would appear unnecessary.
[1] Robert C Martin :
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
[2] Robert C martin :
http://www.objectmentor.com/resources/articles/srp.pdf
[3] Wikipedia :
http://en.wikipedia.org/wiki/Separation_of_concerns
[4] Robert C Martin :
http://www.objectmentor.com/resources/articles/dip.pdf
[5] Wikipedia :
http://en.wikipedia.org/wiki/Inversion_of_control
[6] Wikipedia :
http://en.wikipedia.org/wiki/Unit_testing
[7] Wikipedia :
http://en.wikipedia.org/wiki/Test-driven_development
[8] Castle :
http://www.castleproject.org/container/gettingstarted/index.html
[9] Wikipedia :
http://en.wikipedia.org/wiki/Apache_license
Technorati:
design, development, architecture, Castle
Windsor, Unity, Inversion
of Control, Seperation
of Cconcerns, Dependency
Injection Principle
Something is locking me out of my assemblies ... after a clean Get Latest from TFS, i go to a command prompt and run my MSBuild script ... it fails with errors reporting it cannot delete the directory as it is not empty, and then proceeds to report a host or errors updating assemblies as access is denied. If I then go back to Visual Studio I get the following error for every project .... "Cannot analyze project output:"
I don't know if this is Visual Studio, TFS or ReSharper causing this but it is annoying me to hell ... closing the solution lets me run MSBuild perfectly again ... anyone got any ideas?
UPDATE: Turns out that this is a ReSharper error certainly present in 3.1 ... I found this out as the amazingly responsive ReSharper team took a look at my post, and replied immediately admitting it was a bug of theirs. It also turns out it was already fixed in version 4.x but not in 3.x ... after a very short whine by me to Ilya at JetBrains, he then dropped me back an email very soon after telling me the changes had been back ported into the 3.x build, and would appear there from the next nightly build. Now that is responsive!
Suffice to say, and good to their word, the error is no longer present ... Yippppeeee!!!!!
Thanks for the many suggestions I had to try and pin this down!
OK, so I figure it's 6am - in the interests of personal education, and possible improvement of my framework for my client, I decide I best get down and dirty with Unity and see how simple it is to replace Windsor in our current application. If it is simple, and it makes the application simpler, then I'll go the Unity route (as a MS fanboi I really do prefer the MS option where all other factors are equal). Some debate on altdotnet made me consider my position on it.
Unity is roughly comparable to IoC containers like Windsor and StructureMap, the CodePlex site description says:
The Unity Application Block (Unity) is a lightweight extensible dependency injection container with support for constructor, property, and method call injection.
So ... I download the project from CodePlex ... and double click the solution file ...
I only have VS2008 Development Edition on this laptop, no VS2005, so a conversion is required. OK - I have done this before - it should work right, after all CodePlex says:
You can modify or extend the Unity Application Block using Visual Studio 2008. When you open a solution, Visual Studio 2008 will upgrade the projects to its format and you can edit and compile the code to create assemblies targeted at version 3.0 of the .NET Framework. However, you will not be able to convert the projects back into Visual Studio 2005 format. Therefore, it is a good idea to work with a copy of the original solutions and projects.
Guess what ... the conversion fails. Well mostly it works, but all of the Unit Test projects fail to convert. Come on MS ... these are your things ... your IDE, your conversion wizard, your CodePlex project, and your unit testing framework - this is not rocket science.
OK - I'll give you a little leeway as Unity is a CTP ...
So I close it down after struggling a little with the sample applications when I don't have unit tests to read (more on the sample apps shortly). Go and read CodePlex for 20 mins to try and see if anyone has these problems, but with no luck.
I brace myself to figure this stuff out without unit tests, and double click the solution again. It now tells me it needs to do a conversion. Deja Vu moment ... surely I just converted it already ... maybe I was dreaming. I tell it to do the conversion, and bingo it converts successfully, including all the unit test projects it failed to convert 20 minutes ago.
Inconsistent behaviour annoys me ... either fail to convert every damn time, or work every damn time, but don't pick and choose based on some ethereal criteria I am unaware of!
Right ... I have a full solution loaded ... lets compile this and see it fly ...
Nice idea ... except VS thinks otherwise ... all references to using Microsoft.VisualStudio.TestTools.UnitTesting are showing red in the test projects. All references are broken ... they point to Microsoft.VisualStudio.QualityTools.UnitTestFramework correctly, but they show pointing to version 0.0.0.0 which I guess is the VS2005 reference misbehaving in VS2008 ... so I have to manually update each reference, either by changing the "Specific Version" property to false in which case it auto picks the version 9.0 assembly, or by removing the reference and re-adding it (and we all know how tedious that is to do).
Why????? Why make me go through all this to see Unity, when every tool I was using was from MS ???
I understand it isn't entirely the fault of the Unity team here, but surely you guys are in the best possible position to know about the way each others products work.
I choose MS products because I expect them to *just work* out of the box ... I choose certain OSS products expecting them to not be packaged as nicely, or as well documented, and expect a few niggles.
So I have wasted at least 30 minutes on Unity already, and haven't read any code. Please Microsoft, make your things play nicely with each other ... is that too much to ask?
Right ... off to actually see how Unity works, and how it can make my life easier now ...
The nightly builds are up:
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.0+Nightly+Builds
There are some notes on what is new, and what is fixed at:
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.0+EAP+Notes
... I can't wait to try it out ... looks yummy :)
Technorati:
ReSharper
Today I wanted to setup JetBrainsTeamCity as a pilot to run continuous integration for us.
With their new licencing model, TeamCity is free for up to 20 build configurations, 3 build agents and 20 users, which is more than enough for us to get going and see if it improves our process.
Other options were Team Foundation Build or CC.Net
Personally I discounted Team Build early, various comments on mailing lists and forums made it very clear that it was far from being a CI server out of the box, and although after some apparently extensive configuration it could be made to do something similar, it is far from a friction free piece of software.
CC.Net I have used a number of times before, but the XML configuration it requires is less than joyous, and no matter how often I set it up, I never seem to get quicker at it. Good it may be, easy to configure it isn't.
So we decided to start off with a clean Windows 2003 Server installation, as it comes out of the box. That meant that we didn't even install IIS, as TeamCity includes Tomcat to serve up its dashboard.
We had a few teething problems, but the installation was up and running inside a few short minutes ... albeit not building.
The first problem was rather major - under the VCS settings in TeamCity we had opted for Team Foundation Server, and given it all the settings we knew to be correct - but it repeatedly gave us an obscure error - one with no information other than a java exception:
jetbrains.buildServer.vcs
.VcsException: TFS execution error
Stdout:
TFS Native Verifier v1.0 Copyright (C) 2006-2007 JetBrains s.r.o. by Mikhail Pilin and Eugene Petrenko
Stderr:
Exception:
at jetbrains.buildServer.buildTriggers.vcs.tfs.TfsNativeExeRunner .start(TfsNativeExeRunner.java:20)
We spent a fair while on this, eventually giving in and dropping an email to JetBrains - all credit to Serge there for a quick response. After a few confusing emails backwards and forwards, the first solution they could suggest was that I needed a "full TFS" install on the CI server.
This wasn't a great solution - we were deliberately trying to keep the server clean, the last thing I wanted was Visual Studio or Team Explorer installed.
After a bit of searching around, and some helpful hints on the altdotnet mailing list, I found that MS now package the Team Explorer as a download on its own. This looked after unpacking to install some kind of Visual Studio "light" which I still didn't want on the server - but after drilling down I found the Microsoft.TeamFoundation.xxxx assemblies were included in the package. I added these into the GAC, and the problem was instantly resolved without an install of Team Explorer or Visual Studio. A very short while afterwards a clarification came from JetBrains:
To be more specific, the following components must be in PATH:
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Common.Integra tion.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache .dll
Microsoft.TeamFoundation.WorkItemTracking.Client .DataStore.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.dll
Microsoft.TeamFoundation.WorkItemTracking.Client .Provision.dll
Microsoft.TeamFoundation.WorkItemTracking.Client .QueryLanguage.dll
Microsoft.TeamFoundation.WorkItemTracking.Client .RuleEngine.dll
Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll
The GAC solution was therefore on the mark, but we may have got away with dropping the assemblies in the path too. Either way - this was a much cleaner install.
Our second problem was a silly mistake in configuring the project. We are using MSBuild to do the building, and we kept getting a "MSBuild Schema could not be found" error. After a lot of head bashing it turned out I had managed to click on the Validate option in TeamCity, and it was TeamCity rather than MSBuild that was throwing the error - TC could certainly do with better logging. The missing schema file could probably have been dropped alongside the .build file, but as we didn't need it to be validated, we unticked the option, and voila ... it all worked ... almost ...
One last little niggle caught us, NCover was timing out while running, and giving us an error regarding the profiler. We had included NCover in our TFS tree, along with NUnit, Rhino, and all the other tools we need, this was to avoid having to install anything on a workstation to be able to build the projects.
After a hint from Ayende, it turned out that NCover requires an assembly to be registered with regsvr32, something I haven't done in so long, I had forgotten the command even existed! So to solve this problem, the answer is:
regsvr32 coverlib.dll
It may not be ideal, but it does the job, and I think I can live with one assembly needing to be registered, at least in the short term.
Update: Grant Drake posted about this a while ago, and has 4 possible solutions here ... using //reg on the command line is a much better option in a CI environment, so I'm switching our build to do that this morning.
And with all that done, we now have a *very* clean CI server, running a very basic Windows Server install, with a very neat TeamCity install.
Now to show the business benefit!