Message to users should be useful

There are a lot of rules for usability of User Interface, and one of the most important one is not to clutter the user with strange error messages. Since the last update of skype, sometimes when I’m chatting with someone a “really useful” message box appears.


This windows does not communicate nothing to the user, moreover if you click ok nothing happens… skype continue to work with no problem. This design violates some best practice of the UI.

  1. It shows a completely unnecessary and obscure message to the user
  2. It presents only the Ok button, so the user cannot choose any options. A Modal dialog box should be used when the user need to choose an option.
  3. It shows a Red Cross, but the program works perfectly after this error.
  4. This messagebox popup in front of every windows, distracting the user and adding no value to UI.

Such a message would be better handled in this way.

  • Since the program can continue to work after this event, log this information in a logfile, and maybe use a little "communication box” in the interface, instead of a modal messagebox with only an option.
  • Send a logfile to the team, if this is an error, the development team can handle it an find a bug, the user does not need to see what is happened behind the curtain.


Writing windows services, smoke test form

I work often with windows services, and one of the most painfully experience is that you do not have an UI and quite often they have to do some scheduled task at certain time, so whenever you have a deploy you can find yourself in this situation.


The question mark means that you are not sure if your new deploy is really ok, because maybe some of the scheduled tasks will fail for misconfiguration or something else. Usually production machine are different to developement ones, you can miss components, point to a wrong db, forget to update configuration, etc, etc. To avoid this situation you need a series of smoke checks, I usually proceed in this way.

public class TestResult
    public Boolean Result { get; set; }
    public String Comment { get; set; }

    public static readonly TestResult Ok = new TestResult() {Result = true};

interface ITest
    TestResult Execute();
    String Name { get; }

This is the interface of the a component that is able to do a test, I can now write stuff like this

public class ResolveIoCTest: ITest
    #region ITest Members

    public TestResult Execute()
        return TestResult.Ok;

    public string Name
        get { return "ResolveIoCTest"; }


Just to verify that I’m able to resolve a specific interface or a specific component, but you can actually verify every stuff you like, then I write a simple form with a button and a ritch text box.

The next step is finding in the assembly all test classes

Type testInterfaceType = typeof(ITest);
    .Configure(reg => reg.LifeStyle.Transient)

Thanks to fluent registration it is easy to autoregister all test classes, now the test form simply call IoC.ResolveAll<ITest> and for each test execute it in a Try catch, and here is a typical result.


Some exception occurred.

Now each time I write a component that needs verification, I write a simple test, then each time I deploy I runs this form and verify that I do not miss anything. This saves me pain, because I know that at least a set of smoke tests are passing correctly.



Wise architects

Software architects are similar to civil architects, both of them work to create an artifact (software or building) on paper that will be subsequent realized. If you are committed to make a project of a building, witch of them you will like more to create?



I’m sure that the first one is probably the first choice, for many reasons. It is more challenging, it will probably make you famous, it is surely more beautiful. The problem is that those two buildings are really different in use. The first can be a congress center, a museum, but the other one is a simple house for a standard family. The problem arise if a customer ask you for “an house for me and my family” and you will give him the project to build the first one…. probably it is not the expected result, from the perspective of the customer.

The first solution is more expensive to build, it is probably more expensive to maintain, in winter you will spend tons of money to keep it warm and bla bla bla. The point is that the first building is a perfect structure for a museum, but absolutely the wrong one for a family, so if you, as an architect, will create the first one for a family, you have failed.

In software architecture the situation is the same, but with a great difference: the artifact that gets created, is immaterial (a software cannot be seen), and the customer does not perceive its complexity. Everyone can say “hey, I asked for an house, not for a congress center”, but it is really more difficult to look at a software and say, hey, I asked for a simple web site for my football club, but you gave me a full e-commerce, that I does not need.

In this situation, the customer can ask for a software to manage some data from hardware RFID readers. The architect can create a big software made of separated executables, WCF, Remoting, flexible and pluggable algorithms, etc etc. The big problem is that probably it is enough a single executable connected to the readers, that stores raw data in db, plus another executables that manage those data and finally a bunch of web pages that show the result. The three parts are completely disconnected, and the whole architecture is Simple.

Sometimes architects discard simple solutions, they want the customer to think “This architect is really good, he created really a good project that uses latest technologies”. Then they realize, once in production, that they simply created the wrong stuff, because the whole think is difficult to maintain and probably the customer is not satisfied with the final result.

The conclusion is that, in my opinion, simplicity is a really great value for an architecture, and wise architects always takes it in consideration when they make a project. Creating a simple structure can be less challenging and less interesting, but the final goal is finding what the customer really needs, not giving fame or pleasure to the architect. So the wise architect is the one who really understand the needs of the customer and resists the temptation to create an architecture only for his personal pleasure.



Writing modular software with castle.

Thanks to Castle Windsor you can write really modular software. I’m building a project in WinForm that needs to access the domain model through a service layer on a WS* service. One of the most annoying stuff is the need to setup a local service to test the application and the interface.

The key to speedup development is writing high modular software, thanks to castle this is really simple. First of all I use guardian facility to create proxy. This permits me to decide with configuration file if a service interface must be resolved with a proxy, or with a real class. This gives you immense flexibility.


Simply changing a configuration file I can use the concrete class that have access to the database, or pass through a ws* wcf webservice. All people inside the organization, that have vpn and access through the vpn network to the database, can use the concrete class of the service, completely bypassing wcf, while people outside the organization use a config that use wcf service.

The application is structured with a light custom MVC pattern, if a controller needs to access a specific service he simply declare a dependency.

public class XXXManagementController : IXXXManagementController
    public IXXXManagementService XXXManagementService { get; set; }

    public ICustomerService CustomerService { get; set; }

Here is the startup of the application.

static void Main()
    Application.Run(login = IoC.Resolve<Login>());

Thanks to an autoscan facility, all view are registered with code, in this software the Login View is always the same form, so I can register with an attribute.

[AutoscanComponent(LifestyleType.Transient, IsDefault = true, Id = "Login", ServiceType = typeof(Login))]
public partial class Login : Form

Thanks to autoscan I no need to register all the views in configuration file.

If it seems complex, you should consider the advantage of using a MCV architecture when is come time to test.

container.Register(Component.For(typeof (LoginController)).ImplementedBy<LoginController>());
LoginController sut = container.Resolve<LoginController>();
sut.Settings.LastLoggedUserName ="MyUser";
sut.Settings.LastLoggedCustomerId = 3;

List<Customer> customers = new List<Customer>()
                                 new Customer(1, "pippo", ""),
                                 new Customer(2, "pippo1", ""),
                                 new Customer(3, "pippo2", ""),

sut.CustomerService.Expect(c => c.GetAllCustomers()).Return(customers);
BindingSource bs = new BindingSource();
bs.DataSource = customers;
sut.View.Expect(v => v.SetCustomers(customers)).Return(bs);
Assert.That(bs.Position, Is.EqualTo(2));
sut.View.AssertWasCalled(v => v.SetUserText("MyUser"));
sut.View.AssertWasCalled(v => v.SetFocusToPassword());

This seems a complex test but is really simple, I used a custom version of a AutoMockingContainer to resolve the LoginController and creating Mocks for each dependency. Since I’ve abstracted the settings of the application with an Interface, settings property of the controller is a mock, so I can setup lastloggedUserName and LastLoggerCustomerId, then I create a list of customer, and finally setup the expectations. The only bad stuff is that in windows form we does not have the power of binding of WPF, so I need to manage binding with BindingSource objects. The View is a WinForm that has some BindingSource defined in designer, and those BindingSource are passed to the controller. With this test I’m asserting that if the user was already logged, the controller sets last customer and last user in the interface.

The good stuff of this test, is that it uses mocks, so he do not need service, wcf, or anything else to be run.