In conclusion, many thanks to Jose and all his staff for the great organization and…see you the next year!

If you need help or some information on how to use them feel free to contact us!

Stay tuned!

- automatic assemblies versioning
- integrating database changes
- build
- running unit tests
- running integration tests
- deploying
- code metrics (and more over) with source monitor, fxcop and simian

The time available is not so much, and we have tried to choose must useful tasks (for us, obviously)
Any other ideas? Suggestions? Tasks that do you want to investigate?

Like the last one this edition agenda will be built by the community proposals, so if you have an idea for a session topic that you like to talk about send an email to cfp@ugialt.net with a brief abstract.

We wait for your proposal until the end of November then we start with the pool to select the sessions for the conference day.

More information on the mailing list

But I don’t want to talk about the pros&cons of a fixed price contract, everyone who works in the business of software know how bad it is not only for the developer company but also for the customers.

But what happens most of the times?

What I see is that we always start with a fixed price contract in which we put all the functionalities that the application must have and we try to estimate the costs and time needed for the development.

If the project starts we try to be agile, so we try to deliver as soon as possible a small functionality to our customers so that they can begin to try it and to evaluate.

What happens here is a curious thing: the customer sees the prototype of the program and even if it is only a small part of the requested product usually he begin to ask for modifications or for a new functionality.

In these contexts, the customer, having a fixed-price contract should accept an addendum to the initial contract that adds the requested modification and/or the new functionalities.

So we abandon the original contract to follow the new addendum with a small set of functionality that we can precisely estimate.

This happens on every small release and so we move from a big-fixed-size contract to a collection of small-fixed-size contracts that are easier to estimate and certainly more manageable.

It seems like the customer unconsciously understand that the fixed size doesn’t work.

This gives us another important effect: in fixed sized contracts, sometimes happens that the customer thinks that every extra request is included in the contract, so he starts to ask for new features. The problem is not only that we have to work more for the same price, is that the customer does not give the right value to his requests: when something is free, you get it even if you don’t need it.

So splitting the contract in small parts, and evaluate every single part gives to the customer the right value for every feature, so he can decide if what he ask for is really needed.

To solve this “issue” I disabled “Prevent saving changes that require table re-creation” option from Tools -> Options menu:

The the very first thing that I usually do is to run a tool that analyze the codebase to found the critical points and to take a brief review of the project status.

NDepend is a great tool. In the past I used SourceMonitor but NDepend is much more complete and professional and give a lot more information about the code.

The first impression is a bit confusing, the UI is very complex and maybe show too much information for a newbie but if you analyze the single boxes you could see that all you need is in the right place and the UI became very intuitive and complete after few hours of use.

One of the feature that I love is the CQL queries, there are a lot of ready-to-use queries but you can also build your own.

The queries measure your code (for example they can extract the methods that have more than 50 lines of code or the types that are too coupled to another and so on…) and they are the indispensable tool  to begin with the refactoring.

Another nice feature is that NDepend manages the different between two build. One of the important thing of a code metric is not only is absolute value but the variation during the life of the project. Here NDepend came in help with the Compare command that helps in finding the differences between two build of the same application. This metrics gives you the information about the wellness of your refactoring: if the metrics becomes better your work was good, otherwise you can always revert your changes.

Another option to use NDepend is to integrate the tool with CruiseControl.NET like exposed here (http://confluence.public.thoughtworks.org/display/CCNET/Using+CruiseControl.NET+with+NDepend).

This gives you the ability to continually run NDepend over the builds and have immediate feedback about the code status. I’m working on this and I will write another post about the use of NDepend in a CI environment.

All the information about NDepend is available here: www.ndepend.com and on the author’s blog you can read a lot of articles about the metrics and the use of NDepend(http://codebetter.com/blogs/patricksmacchia/default.aspx)

One of the component that helps the ViewModels to communicate with other ViewModels is the MessageBroker (AKA EventAggregator, AKA Mediator): a manager class that route the messages from the ViewModels.

One good implementation of the Mediator for the MVVM is this http://sachabarber.net/?p=477:

To make it more testable we extract an interface:

public interface IMessageBroker
{
  void NotifyColleagues(MessageType messageType);
  void Register<T>(Action<T> action, MessageType messageType);
}

If you TDD your application or if you write unit test you could need to mock the IMessageBroker and it’s not immediate because the Action<T>.

Alessandro wrote a solution that is interesting using Moq:

[Fact]
public void Sample_Test()
{
  Mock<IMessageBroker> broker = new Mock<IMessageBroker>();
  Action<String> action = null;

  broker
    .Setup(b => b.Subscribe(It.IsAny<Action<String>>()))
    .Callback<Action<String>>(a => action = a);

  new FakeViewModel(broker.Object);

  action.Invoke("TestMessage");

  // Asserts...
}

Moq is a powerful mock framework and it’s simplicity make the elegant and easy to read!