You can get the powerpoint presentation and the demos of our session about Continous Integration at the Agile Testing Days here: link

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

We set the date and the location: Milan (Italy), 23rd January 2010.

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

With our customers the most used form of contract is the fixed price, only a few customers with whom we have a good old friendship accept other formats of contract.

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.

In these days I’m giving a look at NDepend. As a consultant I’m quite often called by software houses to review their code and try to improve the codebase.

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)

On the blogs there are a lot of articles about the M-V-VM pattern showing how to decouple the various components of our application to make it modular.

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!

I decided to open a Twitter account and give it a try. It’s not very popular in Italy but it’s gaining agreement.

After few days of use what I like is it’s simplicity: just few words to say something and a simple way of tagging and reply. That’s all!

If you want you can follow me here http://twitter.com/emadb

A little bit in late here it is my post about the 4th ugiALT.net conference of 27th june.

I’m very satisfied of the day, the number of partecipant is growing and we were in 70, the multi-disciplinar sessions are very interesting and the interactive way of doing them drag the people attention.

A lot of posts were already written about the day here  (only one in english):

jacopo: http://jfranzoi.wordpress.com/2009/06/28/about-how-pleasant-a-saturday-can-be/

alessandro: http://blogs.ugidotnet.org/allePalle_blog/archive/2009/06/28/molto-bene-lrsquoalt.net-conference-di-bologna.aspx

mauro: http://blogs.ugidotnet.org/topics/archive/2009/06/29/ugi.alt-conf-recap.aspx

riccardo: http://blogs.ugidotnet.org/zanardini/archive/2009/06/29/iv-ugialt.net-conference-ndash-solo-due-cosette.aspx

andrea: http://blogs.ugidotnet.org/angellaa/archive/2009/06/28/iv-ugialtnetconf-27-giugno-2009-impressioni.aspx

I would like to thank the guy’s who have managed the logistics of the day, the lunch and the great dinner!  Thanks Andrea Turchi and Martino Vallara!

Last note: the conference room was in a municipal park of Bologna. There we had a room for the conference but a lot Open Spaces was born in the outside park and this was a really nice thing. Here are some photos: http://www.facebook.com/event.php?eid=80754244901.

Me, simone and claudio have already begin to think at the winter edition,  if someone wants to join us with the organization contact us throught the mailing list.

From 12th to 14th I will be in Berlin for the Agile Testing Days not only as an attendee but also as a speaker.

With Alessandro I will present a session on Continuous Integration, a 60 minutes walkthrough on the setup process of a CI Server.

Here you can find the agenda of the days: http://www.agiletestingdays.com/programme.html

I will write more about our session in the next weeks on this blog.

In these days we are working to a big application and iteration by iteration the design is coming out.

We found that what our users want is this:

When we need to write the caller information in the log file we usually write a call like this:

_log.Error(“ThisClass.ThisMethod”, ex.Message);

The specification of the caller class and method is convenient to have information about the error location, but writing that string all the time is boring.

Searching in the .NET Class Library I found the class StackFrame that enable the program to access the application stack, so I write this piece of code:

public void Error(Exception ex)
{
     StackFrame sf = new StackFrame(1);
     _log.Error(
         String.Concat(sf.GetMethod().DeclaringType.FullName, ".", sf.GetMethod().Name),
         ex.Message);
}

This method navigate the stack up one level and using the StackFrame extract the caller class and the caller method and write them to the log file.

Maybe many of you already knows the StackFrame class, but the .NET Fx is big and while searching in it you always find something interesting.