Alsagile

This is how I want all my tools. I had lots of ideas for better...

Thu, 16 Feb 2012 09:32:34 +0100

This is how I want all my tools. I had lots of ideas for better tools popping up in my head while watching this video. The kind of paradigms that he talks about are applicable to most of the creative processes. It’s really amazing to watch, whether you understand code or not.

via http://boingboing.net/2012/02/15/technology-interaction-and-eth.html

myNoSQL: Document Databases Compared: CouchDB, MongoDB, RavenDB

Sat, 11 Feb 2012 11:50:28 +0100

myNoSQL: Document Databases Compared: CouchDB, MongoDB, RavenDB:

Brian Ritchie has two posts (☞ here and ☞ here) covering three document databases: CouchDB, MongoDB, and RavenDB concluding with the matrix below:

But before using this as a reference material there are a couple of corrections needed:

They have some special characteristics…

Git Is Simpler Than You Think

Wed, 07 Sep 2011 22:54:39 +0200

nfarina:

It was about one year ago that we switched to Git. Previously, we used Subversion, through the Mac app Versions, which (rightly) holds an Apple Design Award.

I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. There was much grumbling from my teammates, who were busy enough doing actual work thank you very much.

But I pressed forward. We signed up for accounts on Github. We learned how to type 'git push' and 'git pull'. We became more confident. Git is just like any other source control system! But it wasn’t long before one of our devs called me over to look at a…situation.

Read More

Silverlight unit testing - Test Not Initialized

Sun, 21 Aug 2011 21:15:00 +0200

It has been a year now that I work on a silverlight project. As any respectful developer I write unit tests. But in silverlight, things are not all that easy when it comes to testing.

First of all, the unit testing framework doesn’t come out of the box. Instead, you will find it in the Silverlight Toolkit. On the bright side, this allow a separate release cycle than the one from silverlight.

Then, you might be aware that you need to run your silverlight tests in the browser, because the silverlight runtime can only run in the browser, or hosted by a wpf application since silverlight 4.
A very important part of unit testing is to have a fast feedback loop. I want to run my tests often, and therefore, I want them to run fast. Having to run them in the browser unfortunately doesn’t help it.

Those are common complains from developers who write unit tests on a silverlight project.
But the issue I will expand is different.

TestInitialize Bug

In MsTest framework, if you mark a method with a [TestInitialize] attribute, it will run before each tests. As the attribute name suggest, this is useful to initialize the state of the system before running each tests of the fixture.
Here is the problem. if the initialization fails, I really want to see my test fail. But with the silverlight testing framework, if an exception is thrown in the testinitialize method, the test will not fail. This can result in false positive, and that’s an issue because I can’t trust my tests anymore.

To work around it we have a simple base class that looks something like the following :

public class TestBase
{
    private Exception _exception;

    [TestInitialize]
    public void TestInitialize()
    {
        try
        {
            Initialize();
        }
        catch (Exception exception)
        {
            _exception = exception;
        }
    }

    [TestMethod]
    public void InitializeTest()
    {
        if (_exception != null)
        {
            throw new InvalidOperationException("Failure running test setup", _exception);
        }
    }

    public virtual void Initialize() { }
}

So when I write a test fixture now, I don’t add a TestInitialize attribute above a method. Instead, I inherit from this base class and override the Initialize method. But this is obviously a dirty workaround. My tests still don’t fail. What I get is another test that tests the initialize method… At least I have a failing test when an exception is thrown.

If you don’t like this easy workaround, you might want to have a look at the xunit.contrib project, or at nunit for silverlight. These have other advantages that I will expand in another post.

ocourtois: Une animation intéressante sur les multiples façons...

Sun, 26 Jun 2011 23:30:00 +0200

ocourtois:

Une animation intéressante sur les multiples façons de mesurer les retours sur investissement du design de l’expérience utilisateur (façon animation RSA).

Toujours pas convaincus?

Abstract Factory and IoC Container in asp.net MVC

Sat, 26 Jun 2010 17:38:00 +0200

Sometimes, you want to be able to change the implementation of a component depending on a variable that you don’t control at design time, a user action for example. This will be a lot easier to explain if we use a concrete example. I will present the problem that I faced to illustrate the usage of the method.

Consider a simple search form, but you want to be able, with the same form, to search in different data stores.

You already know that more data stores will be added to the requirements, so you also need a way to extend this it easily. The following solution supposes that you know the basic concepts of dependency injection and how to setup your mvc application to take advantage of it.

I use StructureMap here, but it could of course be swapped by any other IoC container.

Consider that you will have different implementations of this Search action, which will build the query in different ways, and each will make calls to different APIs. You create an interface ISearchManager as follow :

public interface ISearchManager 
{ 
    IEnumerable Search(string keyword); 
}

And the possible implementations :

public class TwitterSearchManager : ISearchManager 
{ 
    public IEnumerable Search(string keyword){ //Search using Twitter Api and returns a collection of Tweets } 
}

public class FacebookSearchManager : ISearchManager 
{ 
    public IEnumerable Search(string keyword){ //Search in the Facebook Api and returns a collection of Status } 
}

public class ForumSearchManager : ISearchManager 
{ 
    public IEnumerable Search(string keyword){ //Search in another Api and returns a collection of Forum posts} 
}

You controller could then receive an ISearchManager in his constructor

public SearchController:IController 
{ 
    private readonly ISearchManager _searchManager;

    public SearchController(ISearchManager searchManager) 
    { 
        _searchManager = searchManager; 
    } 
}

And you can happily search in different store without changing anything in the controller… Well, not exactly, because your IoC controller doesn’t have a clue of what radio button is ticked when it creates your SearchController, therefore it cannot resolve the dependency on ISearchManager. What you need is a factory to create the correct instance of ISearchManager depending on a parameter.

public SearchController:IController 
{ 
    private readonly ISearchManagerFactory _searchManagerFactory;

    public SearchController(ISearchManagerFactory searchManagerFactory) 
    { 
        _searchManagerFactory= searchManagerFactory; 
    }

    public ActionResult Index(string provider, string keywords) 
    { 
        var searchManager = _searchManagerFactory.Create(provider);    
        var results = searchManager.Search(keywords); 
        … 
    } 
}

And the implementation of the factory often ends up like this :

public class SearchManagerFactory : ISearchManagerFactory 
{ 
    public ISearchManager Create(string provider) 
    { 
        switch (provider) 
        { 
            case “twitter” : return new TwitterSearchManager(); 
            case “facebook”: return new FacebookSearchManager(); 
            … 
        } 
     } 
}

Well, that’s ok if you have a very small dependency graph, but you still, you start to spread the configuration of your dependencies in multiple places. You have an IoC container which decides which type each controller should receive, and you have this switch statement hidden inside a factory to decide which SearchManager. If my SearchManager have further dependency on, let’s say, a QueryBuilder (because the queries need to be built differently to satisfy the different APIs), it really becomes messy.

It would really be nicer if my factory could ask my container which implementation to return, with all its dependencies resolved. This turns out to be rather easy with most of the IoC containers.
They allow you to assign a key to the different implementations of an interface. With StructureMap we have IContainer.GetInstance(string key); Let’s see how we can use that in our factory.

public class SearchManagerFactory : ISearchManagerFactory 
{ 
    readonly IContainerWrapper _container;

    public SearchManagerFactory(IContainerWrapper container) 
    { 
        _container = container; 
    }

    public ISearchManager Create(string provider) 
    { 
        return _container.Resolve(provider); 
    } 
}

That was easy. Our factory is now asking our IoC container for a ISearchManager, but I don’t really want my factory to know which IoC Container I am using. Instead, I have this simple IContainerWrapper. Its implementation for StructureMap is straight forward :

public interface IContainerWrapper 
{ 
    T Resolve(string key); 
}
public class StructureMapWrapper : IContainerWrapper 
{ 
    private readonly StructureMap.IContainer _container;

public StructureMapWrapper(StructureMap.IContainer container) 
{ 
    _container = container; 
} 

public T Resolve(string key) 
{ 
    return _container.GetInstance(key.ToLower()); 
} 


}

Now we’re all set. All we need to do is wire up all those components in the IoC configuration:

ObjectFactory.Initialize(x => 
{ 
     x.For().Use().Named(“twitter”); 
     x.For().Add().Named(“facebook”); 
});

ObjectFactory.Configure(x => 
{ 
     x.For() 
       .Use(new SearchManagerFactory(new StructureMapWrapper(ObjectFactory.Container))) 
);

This is the trick. I first set up the ISearchManager implementation, and give them a name in the Initialize method of StructureMap. Since I need to pass a reference of the container to my factory, the container needs to be already initialized when that happens. That’s why I set up the ISearchManagerFactory dependency after the initialization is done, in the Configure method.

That’s it, the dependency to the SearchManagers is now resolved by the IoC Container, depending on a runtime parameter. Why I think this is better? because that way, you keep all the configuration in one single place. You could even potentially change that configuration without recompiling if you configure your IoC using an XML config file.

Stop the war between NUnit and MSTest : Make them friends

Tue, 09 Mar 2010 00:00:00 +0100

Note : this is an old article from my previous blog that I ported here

Recently, Roy Osherove blogged NUnit vs. MsTest: NUnit wins for Unit Testing in an answer to this StackOverflow question My team is using TFS2008 (and soon 2010) for source control. When I introduced Continuous Integration and Unit Testing in my team, I considered using NUnit and a separate continuous integration server like CruiseControl.NET.

Setting this up is a burden. I quickly changed my mind and decided to stick with TFS for the continuous integration. When it comes to the testing framework, you can get TFS to run NUnit, but you will loose the the nice reports including detailed tests results, code coverage data, and so on… no point.

So I run my test using MSTest. Just like many other, and as Roy points out, the API from Assert API from NUnit is much nicer than MSTest one.

Roy Osherove :

MsTest’s ExpectedException attribute has a bug where the expected message is never really asserted even if it’s wrong - the test will pass.

Nunit has an Assert.Throws API to allow testing an exception on a specific line of code instead of the whole method (you can easily implement this one yourself though)

Nunit contains a fluent version of Assert api (as already mentioned - Assert.That..)

…

NUnit was created SOLELY for the idea of unit testing. MsTest was created for Testing - and also a bit of unit testing.

Here is the trick, it’s really so easy. I wonder how come nobody mentions it anywhere. so hit me if that’s a No-No, but I haven’t got any problem so far (most recent MVC project having about 150 Unit Tests and growing):


using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert;  
… 
    [TestClass]   //MSTest 
    public class AlsagileTests 
    { 
        [TestMethod]   //MSTest 
        public void MakeFriends_NUnitAndMSTestWorkTogetherFTW_ReturnsTrue() 
        { 
            var blog= new Alsagile(); 
            bool areFriends = blog.MakeFriends(); 
            Assert.That(areFriends, Is.True); //NUnit  
        } 


        [TestMethod]   //MSTest 
        public void Leave_ReaderLeavesMyBlog_ThrowsActionNotSupportedException() 
        { 
            var blog = new Alsagile(); 
            Assert.That(() => blog.Leave(), 
            Throws.TypeOf(typeof(ActionNotSupportedException)). 
            With.Message
                   .EqualTo("You are not following me on Twitter yet!")); 
        } 
}

That’s it! The test is now using MSTest test runner, but all the assert will be performed by NUnit. I can take full advantage of the great Fluent Assert.That(…) API and other Assert methods from Nunit, and still use the automated build and tests and report power from TFS.

Follow me on twitter to avoid the exception : @serbrech

First sprint retrospective

Fri, 25 Sep 2009 16:35:00 +0200

It has been now 4 weeks that I started the transition to scrum in my company. The first sprint was very chaotic, and I couldn’t even qualify is as a sprint, We had a backlog that we discussed with the product owner, and our business expert, but it was not well prioritized, we didn’t estimate the items, neither did we select a set of features to commit to. It was a first shot, trying to get the feeling of it, and warm up a bit the tools and the idea behind this. It was chaotic, but still better than no plans at all, we could feel the difference brought by the communication required when creating a product backlog, and during the daily scrums.

Unfortunately, In the rush, I forgot to set up a retrospective after the first sprint. Well, it was a lot of improvement required on my side, to coach the team, and drive us to better practices, I knew already what was missing, and that was enough work to achieve before asking them for feedback about our new processes and practices.

The second sprint was already slightly better, we tried to create our first sprint backlog, estimated the user stories using planning poker, and we created a burn-down chart to monitor our progress.

The result was quite good. We managed to finish almost all the stories that we planned, And the few items that had not been finished were due to a incredible amount of support suddenly coming in. Consequently the sprint review was very satisfying for everybody. the progress was obvious, and we could really be proud of showing our work for the first time!

This time I am happy that I didn’t forget the sprint retrospective. But before telling you about the retrospective, you need to know more about how we implemented some scrum concepts in our organization.

The retrospective has a simple goal : Continuous Improvement.

The process is quite simple, and give a maximum of feedback on how efficient is your workflow. Here is how I proceeded. I used a white board on which I drew 3 Columns :

Positive +++
Negative —-
Solutions

I first asked each person what were the positive points they could notice during the last 2 weeks and listed them in the positive column. It is very important to start with the positive things not to cast a cloud over the meeting… After that I asked each person what were impediments that hindered their work during the last 2 weeks, and listed them in the negative column. And finally I invited everybody to find a way to reduce the problems they just mentioned, and list the propositions in the Solution problems.

We concluded the meeting by agreeing on few practices that we will follow during the next iteration, and see in the next retrospective if they improved the quality of our process.

To give you an idea, here is the Retrospective report I sent by mail to everybody after the meeting :

Scrum Retrospective Report 23/09/2009

As I presented it to all of you 1 month ago, being agile is not only about being able to accept changes easily, it is also to commit to a continuous improvement of the processes and the quality of our work.

We will be having this meeting after each sprint, to get a feedback from everybody on the current practices, and try to find ways to improve them.

Positive points	Negative points
Daily standup meeting +++ Team work +++ Collaboration Pair programming Focus ++ Feedback on results General atmosphere	I will group the items in 2 categories : Interrupted work Multiple urgent projects in parallel (can’t let any aside) Interrupted work Access to technical info for support. Work tools optimization server slow system (sources) legacy code => hard to change, hard to improve, not confident in making changes Workstation problems (Tonje, Antonio, Kai) Burn-down chart has not been kept up to date at the end of sprint (lack of metrics)

Positive points

Negative points

Daily standup meeting +++
Team work +++
Collaboration
Pair programming
Focus ++
Feedback on results
General atmosphere

I will group the items in 2 categories :
Interrupted work

Multiple urgent projects in parallel (can’t let any aside) Interrupted work
Access to technical info for support.

Work tools optimization

server
slow system (sources)
legacy code => hard to change, hard to improve, not confident in making changes
Workstation problems (Tonje, Antonio, Kai)
Burn-down chart has not been kept up to date at the end of sprint (lack of metrics)

As a result of this meeting the following practices have been agreed on :

Support should be first given a rough estimate of the complexity of it by the developers, then discussed with Kai or Morten to prioritize it according to the time it would take.
Small meeting to update the burn-down chart will be hold every day. Ultimately, having those metrics done by the system would be the best.
Technical are being taken care of starting today (server installation)

After this sprint, I feel confident that we are heading to the right direction. The next sprint will be better, and the one after even better! This is what we must aim at.

The detail that was very nice to get as a feedback is that we welcomed a new employee 3 days earlier. Like everybody else, I invited him to be part of the Daily scrums, and to give his opinion in this first retrospective. His positive contribution was probably the most positive I marked on the board : General atmosphere. I strongly believe that the new processes we adopted are a playing a major factor in this feeling. :]. Scrum makes your office a place you enjoy working!

Thanks to Sean Hicks and RallySoftware for their hints on twitter.