Ernst's Thoughts

3 days with Greg Young

2010-06-03T13:36:00.001-07:00

Last week Pyxis hosted an intensive three days immersion into Greg Young's Applied DDD course. This course is amazingly packed with tips and tricks on how to come up with an architecture that delivers business value customers have come to expect from their investments in software systems. Powered by Greg’s energetic tone, this course challenged my assumptions of how software should be designed and I would recommend it to anyone interested in architecture innovations surrounding Domain Driven Design. Following is an overview of the topics we’ve tackled during the training.

DDD recap

The first day was spent refreshing some of the fundamental but often misunderstood concepts of Domain Driven Design. We were reminded that Strategic Design is essential while embarking on a Domain Driven Design project as we must make sure that the value we get out from it is well worth the effort. Notions such as Bounded Contexts and Core Domain allow highly knowledgeable teams to focus on value added development work while leaving less crucial aspects of the software to others.
Another topic that stroke a chord with me was Greg’s presentation of Aggregates and the role the play in well crafted software systems. Aggregates exist to provide transaction boundaries around the behaviors of domain objects. Aggregate roots provide the sole entry point to this grouping of domain behaviors and encapsulate validation logic as well as invariant consistency inside the aggregate.

CQRS

We spent the second day learning about Command Query Responsibility Segregation and Event Sourcing. CQRS is different then Command Query Separation (Bertrand Meyer) which advocates that methods that change state should be separated from functions that return value. CQRS takes the same principle and applies it to the hole architecture. In this style of design some objects (write model) represents the commands the domain respond to and other objects (read model) handles the queries and their results. Having separate models for these concerns brings a lot of benefits that I will bring up in later posts.

The write model

It’s common OO knowledge that objects should be designed around behaviors in a domain. Having a dedicated write model consisting of aggregates that define transaction boundaries around the behaviors in the domain focuses work on the most valuable part of the system. This is the place to maximize the return on the work of your most skilled developers aided by domain experts.

The read model

The query side doesn’t have a domain as it’s mostly straightforward boilerplate code. The preferred implementation of a read model is having request DTOs going through a thin query layer that projects directly off of a data source. This is way simpler that using the domain model to do the same. This way pre-fetched paths and optimizing ORMs queries are avoided.

Event Sourcing

Event sourcing can be seen as a way to “standardize” thus reduce the cost of implementing separated read and write models. The basic idea is that all domain can be modeled as receiving commands that and producing associated events. These events can be stored as a log of what happened in the system and also be used to update the read model.
While exposing concurrency issues and ways to handle them Greg showed us a merging algorithm that’s quite simple and clever. Probably, the only piece of code Greg would ever write with a Goto statement as you can see in the picture.

Fine tuning the architecture

The third day was spent analyzing the properties of this architecture and how it could be fine tuned to produce low latency, high availability and high reliability systems. Most notably CQRS architecture can used to get around CAP theorem issues which states that you can’t guarantee all three Consistency, Availability and Partitionability in one system. Look here for another treatment on how to get around CAP.
All these architecture talks made me realize that using DDD and CQRS is a lot of work. And it’s no wonder that they should be applied to core domains. Now most companies I’ve worked with deal with multiple domains such as Sales, Security, Insurance, etc... And it would have been difficult to single out the one that constitutes their core domain. But every company must have a core domain otherwise it would not have a competitive advantage. Turns out a lot of companies derive their competitive advantage from their business process that integrate all of the domains they deal with. This is the place their core domain reside and that’s where Sagas help.

Pyxis source of high quality technical learning

All in all, these three days were packed with useful technical knowledge and eye opening discussions with an expert in his craft. The participants enjoyed the learning experience in Pyxis’ agile environment where they got a close up look at our facilities supporting agile teams. Pyxis is proud to have sponsored this event and is dedicated to bringing high quality technical training to the public.
Other technical trainings :

My presentation at the Toronto Code Camp 2010

2010-05-03T21:15:00.001-07:00

I had a blast meeting new people and sharing experiences writing software. I especially liked Barry Gervin’s keynote on successful product management and Todd Anglin’s talk on HTML5.

As for me, I did and introductory talk on Scrum and Visual Studio 2010 briefly touching on some of the content of the Professional Scrum Developer course. The training has already started in several countries around the globe: Brazil, Australia and US. I’ll be teaching the Montreal edition that’s coming in June 7th. It’s going to be awesome!

About the Professional Scrum Developer Course

The Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.

Course attendees are prepared to take an assessment at course completion and then become Certified Professional Scrum Developers.

Professional Scrum Developper Training

2010-03-25T08:51:00.000-07:00

Dates are now open for the Professional Scrum Developper on the .Net platform training in the Montreal and Toronto areas. This training is fully packed with knowledge and hands-on exercices that are important for today's developers, architects and testers working in agile teams.

Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.

Course attendees are prepared to take an assessment at course completion and then become Certified Professional Scrum Developers.

You can register via scrum.org

Hope to see you there!

Agile Testing

2010-03-21T11:15:00.000-07:00

I've just watch this talk from Elizabeth Hendrickson. Very interesting content on Agile Testing.

Professional Scrum Master Level II

2010-03-20T19:43:00.000-07:00

I've just received confirmation from Ken Schwaber that I've successfully completed the Professional Scrum Master Level II assessment available on Scrum.org. I'm very proud of announcing that I'm also a .Net Professional Scrum Developper Trainer and that I will be delivering this course in Canada in May and June. Stay tuned for the official dates.

Automated Unit Tests as Documentation

2010-03-18T09:48:00.001-07:00

Introduction

In our quest to produce quality software and our relentless use of automated unit tests in our development activities, we’ve come to realize they possess other virtues as well. One of those being they stand as a documentation of the system being developed. I’ve taught this idea in several agile and TDD courses. In this blog I want to give you an example of how that may be. I’m purposely not discussing executable specifications and Behaviour Driven Development as it would make this blog too long. My goal is to show how using some convention and Visual Studio 2010 can go a long way in cranking up your unit tests another notch.

Documentation of API usage

One clever use of unit tests is for learning a new API or even a new language. Writing several assertions to validate our understanding and assumptions about an API usage is very rewarding as the feedback is rapid and progress towards a goal is constantly measured. These learning tests may be kept around to document the assumptions made that constitute the basis of our solution. Here is an example of a learning test for the Character.IsWhiteSpace() method of the BCL.
[TestMethod]
[Description(@"White spaces are the following characters: ' ', '\t', '\n', '\r'")]
public void May_be_a_white_space()
{
    Assert.IsTrue(char.IsWhiteSpace(' '));
    Assert.IsTrue(char.IsWhiteSpace('\n'));
    Assert.IsTrue(char.IsWhiteSpace('\t'));
    Assert.IsTrue(char.IsWhiteSpace('\r'));
    Assert.IsFalse(char.IsWhiteSpace('A'));
    Assert.IsFalse(char.IsWhiteSpace('+'));
}
A test can also document how to use the classes we create in our solutions. The following is an example of such a test. In our chess software, this unit test documents the way of obtaining a chess piece which is to call the NewPiece() factory method and passing it a color (either Color.White or Color.Black) and a Kind (such as Kind.Pawn) as arguments.
[TestMethod]
[Description("A chess piece consists of a kind and a color that are specified when the piece is created")]
public void Should_retain_its_color()
{
    Piece pawn =
           Piece.NewPiece(Color.Black, Kind.Pawn);
    Assert.IsTrue(pawn.IsBlack);
    Assert.IsFalse(pawn.IsWhite);
    pawn = Piece.NewPiece(Color.White, Kind.Pawn);
    Assert.IsTrue(pawn.IsWhite);
    Assert.IsFalse(pawn.IsBlack);
}

Documentation of behaviours

Unit tests document behaviours of our code. Test classes should be given names that provide context for all the test methods they contain.
[TestClass]
public class When_displaying_a_board
{
    [TestMethod]
    public void A_black_queen_should_show_as_Q()
    {
        …
    }
    …
}
Test methods should also be named in such a way that the behaviour they validate is evident.
[TestMethod]
[Description("The board is displayed on 8 lines with blacks pieces on line 8 and 7 and white pieces on lines 1 and 2")]
public void It_should_show_all_pieces_in_their_initial_position()
{
    Assert.AreEqual(
        "RNBQKBNR".Line() +
        "PPPPPPPP".Line() +
        "........".Line() +
        "........".Line() +
        "........".Line() +
        "........".Line() +
        "pppppppp".Line() +
        "rnbqkbnr".Line(),
        board.ToString()
        );
}
Notice that, instead of writing comments, I’m using the Description attribute to tie the behaviour being tested with some requirement or specification of the system. Personally, I’m not doing anything fancy with these descriptions, but you can imagine using a pattern that would provide more traceability in your environment as in the following.
[TestMethod]
[Description("US 234: Black pawns are shown as P, white pawns are shown as p")]
public void A_white_pawn_should_show_as_p()
{
    Piece whitePawn = Piece.NewPiece(
                        Color.White,
                        Kind.Pawn);
    Assert.AreEqual("p", whitePawn.ToString());
}

Documentation of design specifications

Now comes the fun part! Because of the thought we’ve put in selecting meaningful names when the tests are executed in Visual Studio we get a result screen that looks like this.

Notice how combining our test class and method names reads like a phrase that documents the design of our software. If we group the results by Description, we get a list of all the requirements of our software.

If we expand one of the requirements, we see all the tests that validate it so we can trace back to the code that implements it.

Conclusion

I hope I’ve convinced you that tests can serve as documentation using simple tricks, conventions and tooling you may already have at your disposal. Because this documentation is embedded in code it has a lot more chance of being maintained as the code evolves. These techniques require agreement amongst team members but they foster good practices of choosing explicit names and tying development work with planning activities for traceability purposes.

Coding and Debugging in Bubbles

2010-03-11T16:44:00.001-08:00

A new concept for the modern IDE, Code Bubbles allows developers to see and work different fragments of code as one unit. Debugging sessions can be associated with those units save and retrieved later for continued work. Quite impressive! It’s really a departure from the IDEs we’ve been using so far. Of course, this is not mainstream yet. Nevertheless, I would like to try something like that and it would probably be interesting to have the equivalent in the .Net space.
I have to wonder though, what the impact will be on Object Oriented Programming and encapsulation if developers are lead to think of their code as fragments of functionality scattered in their code base…

FizzBuzz à la façon LINQ

2010-02-13T14:54:00.000-08:00

Dernièrement mes collègues et moi exécutions le Kata FizzBuzz dans le cadre de notre Dojo pratiques d’ingénierie. L’objectif était de pratiquer le développement piloté par les tests. Je dois avouer que ce fut fort amusant et la solution à laquelle nous sommes arrivés est tout à fait adéquate et présente un modèle objet élégant qui résoud le problème.
La séquence FizzBuzz est générée par la méthode CountTo de la classe FizzBuzz. Cette dernière utilise un ensemble de règles qui vérifient si elles s’appliquent et transforment, le cas échéant, l’entier question soit en “Fizz”, “Buzz” ou “FizzBuzzz”.
class FizzBuzz
{
    private readonly IRule[] _rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule()
    };
    private readonly IRule _defaultRule = new NumberRule();
    public string[] CountTo(int upperBound)
    {
        var sequence = new List<string>();
        foreach (var n in NumbersUpTo(upperBound))
        {
            sequence.Add(Interpret(n));
        }
        return RespondWith(sequence);
    }
    private static IEnumerable<int> NumbersUpTo(int n)
    {
        for ( int i = 1; i <= n; i++)
        {
            yield return i;
        }
    }
    private string Interpret(int n)
    {
        foreach (var rule in _rules)
        {
            if (rule.Applies(n)) return rule.Apply(n);
        }
        return _defaultRule.Apply(n);
    }
    private string[] RespondWith(List<string> result)
    {
        return result.ToArray();
    }
}
La classe FizzRule est un exemple d’implémentation d’une rèlge.
class FizzRule : IRule
{
    public bool Applies(int number)
    {
        return ShouldSayFizz(number);
    }
    private static bool ShouldSayFizz(int n)
    {
        return IsDivisibleByThree(n) || ContainsThree(n);
    }
    private static bool IsDivisibleByThree(int number)
    {
       return number % 3 == 0;
    }
    private static bool ContainsThree(int n)
    {
        return n.ToString().Contains("3");
    }
    public string Apply(int number)
    {
        return SayFizz();
    }
    private static string SayFizz()
    {
        return Fizz;
    }
    private const string Fizz = "fizz";
}
Plus tard, je me suis demandé de quoi aurait l’air la solution si j’utilisais les fonctionnalités du langage C# 3.0 telles que LINQ, les expressions lambda et les méthodes d’extension. Avec notre batterie de tests comme garde-fou je me suis lancé dans une session de refactorisation au bout de laquelle je suis arrivé à la solution que je présente plus loin.
Les premières pistes que je choisis d’explorer sont les méthodes que Resharper suggère de changer en méthodes statiques. En fait, les méthodes statiques me font toujours penser à des méthodes utilitaires qui en général sont très réutilisables. C’est le cas par exemple des méthodes IsDivisibleByThree et ContainsThree de la classe FizzRule plus haut. Je les rassemble donc dans la classe IntExtensions après avoir introduit un peu de généricité pour qu’elles soient utilisables également dans la classe BuzzRule.
public static class IntExtensions
{
    public static bool Contains(this int n, int number)
    {
        return n.ToString().Contains(number.ToString());
    }
    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}
Avec ces modifications, la méthode ShouldSayFizz se lit comme suit:
private static bool ShouldSayFizz(int n)
{
    return n.IsDivisibleBy(3) || n.Contains(3);
}
Je suis content car la lisibilité du code n’en souffre pas. Je m’attaque de la même façon à la méthode NumbersUpTo de la classe FizzBuzz. J’en fais une méthode d’extension que je rajoute à la classe IntExtensions. Je prends le soin de renommer la méthode FirstNumbers pour une meilleure lecture du code client qui se lira
foreach(int number in n.FirstNumbers()) { … }
Cela me rappelle mon cours d’analyse et la série des n premiers nombres entiers… En fouillant un peu dans MSDN, je retrouve comment générer une suite d’entiers grâce à la classe Ennumerable et je modifie mon implémentation en conséquence. J’obtiens le résultat suivant
public static class IntExtensions
{
    public static IEnumerable<int> FirstNumbers(this int n)
    {
        return Enumerable.Range(1, n);
    }
    public static bool Contains(this int n, int number)
    {
        return n.ToString().Contains(number.ToString());
    }
    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}
Avec ces méthodes utilitaires hors de la classe FizzRule, la responsabilité de celle-ci devient plus évidente et je la simplifie pour arriver au résultat suivant
class FizzRule : IRule
{
    public const string Fizz = "fizz";
    private const int Three = 3;
    public bool AppliesTo(int number)
    {
        return number.IsDivisibleBy(Three) || number.Contains(Three);
    }
    public string Apply(int number)
    {
        return Fizz;
    }
}
Une bonne chose de faite! Je tourne mon attention vers la classe FizzBuzz. Même si j’ai sorti la génération des nombres entiers hors de cette classe, elle a encore trop de responsabilités: maintenir la liste des règles FizzBuzz, appliquer les règles qui conviennent, formater le résultat. C’est une violation évidente du principe de responsabilité unique (Single Responsibility Principle) de l’oncle Bob. Je décide donc séparer tout ce qui touche à la transformation FizzBuzz dans une classe à part. Les règles et tranformations FizBuzz sont maintenant rendues dans la classe FizzzBuzzExtensions. J’ai changé l’implémentation pour utiliser LINQ étant donnée que le résultat est plus compacte et tout de même très lisible.
static class FizzBuzzExtensions
{
    internal static IEnumerable<string> AsFizzBuzzSequence
                                         (this IEnumerable<int> sequence)
    {
        return sequence.Select(numeral => Transform(numeral));
    }
    private static string Transform(int n)
    {
        return FirstRuleThatApliesTo(n).Apply(n);
    }
    private static IRule FirstRuleThatApliesTo(int n)
    {
        return Rules.First(r => r.AppliesTo(n));
    }
    private static readonly IRule[] Rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule(),
        new NumberRule()
    };
}
L’astuce d’encapsuler cette fonctionnalité en arrière d’une méthode d’extension facilite grandement la lecture de la classe FizzBuzz qui devient
class FizzBuzz
{
    public string[] CountTo(int n)
    {
        return RespondWith(n.FirstNumbers().AsFizzBuzzSequence());
    }
    internal static string[] RespondWith(IEnumerable<string> result)
    {
        return result.ToArray();
    }
}
Séparer ainsi les responsabilités dans différentes classes a grandement augmenté la clareté du design. De plus l’utilisation de LINQ et des méthodes d’extension fait en sorte que le code est très compacte quoique très expressif.

A Coaching Session

2010-01-29T09:27:00.001-08:00

Following is a conversation I had with a new Scum Master that had me thinking about how coaching works. It's not about telling people what to do but allowing them to figure out what needs to bo done. One powerful tool to do just that is changing perspectives. Reliving the facts as they happened but from a different angle may generate insights that open new opportunities for the coachee. Below is the conversation as I remember it. I hope it generates some insights for you as well.

SM: So what do you think about the sprint planning the other day ?
Coach: Well one thing I noticed, and I did mention it on the spot, the team was about to bend some process improvement rules they agreed on implementing during the last retrospective. Your role as a Scrum Master is to make sure that the team follows its own process so that they may inspect and adapt it if need be. If the team partially implements the process in some cases and fully in some others, than interpretation of the results is more difficult and it will be harder to see what to improve next. You want to be careful when introducing changes to a process so that you know what you will be inspecting in the end.
SM: Well you are right. Sticking to our decision not to include big or unclear stories in the sprint made us realise that we were accepting to tackle underspecified functionality. No wonder our estimates were off and we were not able to complete all the stories in the sprint.
Coach: Good. But what about you ? What do you think about the sprint planning meeting ?
SM: Well, one thing that bugs me is that team members don’t participate in the process.
Coach: Oh? What do you mean ?
SM: I mean they don’t seem to care or are not motivated. For instance, in our Scrum Masters group we thought it would be a good idea to let developers take turn at the Scrum Master’s role in the daily meeting so that they realize what we are dealing with. When I asked my team if one of them would like to take my place I had to wait for a long time before someone reluctantly offered to conduct the daily.
Coach: So you want them to feel what it’s like to wear your shoes ?
SM: It’s not that. It’s just that team members are not getting involved. You witnessed what happened at the sprint planning meeting. When I asked them if they were able to commit on delivering the sprint backlog, I didn’t get an answer.
Coach: Well your organisation has a culture in which developers have been told what to do, when and how to do things. The change to self organisation is not going to happen overnight.
SM: I know. That’s why I want them to get involved in the process but they don’t want to get onboard.
Coach: And why do you think the don’t want to get onboard ?
SM: I don’t know. And that’s why I’m asking you this because I’m running out of ideas.
Coach: So… What are you doing that’s impeding them from getting involved in the process ?
SM: I’m not sure I understand the question… What do you mean ?
Coach: When you are not getting the response you’re expecting from others it’s often useful to consider that you are the one causing them to act the way they do. This empowers to make some changes instead of waiting for others to change their behaviour.
SM: I’m not following you at all…
Coach: Ok. So let’s go back to that sprint planning meeting. Remember how the room was laid out and where everyone was sitting. You remember ?
SM: Yeah…
Coach: Let’s say you take John’s place. What do you see ?
SM: I’m really not sure where you want to go with this… But the only thing I see is that the monitor is too far away and its difficult to read.
Coach: Well that’s something to consider. And what are you doing in the meantime ?
SM: I’m updating the backlog and moving stuff around.
Coach: And how do you think John is perceiving this given the organisational culture ?
SM: I see… So we should probably use index cards that team members will be able to play with and update themselves.
Coach: Good! That way you solve two problems. By giving the team access to the sprint backlog you allow them to grasp more fully and own its content. They’ll probably feel more comfortable committing to it at the end.
SM (not really listening anymore): I can even update the backlog in the tool afterwards so that the flow is not interrupted. Thank you. That’s a great idea!
Coach: Well you know it wasn’t my idea. It’s yours. You just had to change your perspective on things.
SM (already leaving): Good. I’ll let you know how it turns out. Talk to you soon.
Coach (to himself): I’m not really sure what he saw exactly, but changing his perspective really allowed him to find new ideas on how to tackle this issue. This coaching stuff really works… I should blog this…

De retour après un long mutisme…

2009-12-31T11:27:00.001-08:00

Voilà deux ans que je m’adonne à d’autres choses intéressantes. Et comme ce lézard, aujourd’hui je refais tranquillement surface pour partager les idées qui me trottent dans la tête.
Beaucoup de nouveautés depuis! De nos jours, je me consacre presqu’uniquement au développement logiciel sur la plateforme .Net et à l’accompagnement d’équipes qui effectuent une transition agile. La compagnie pour laquelle je bosse est en pleine croissance et de nouveaux défis se profilent à l’horizon. Je vais donc avoir plein de matières à réflexion à vous proposer: Windows 7, .Net 4.0, pratiques d’ingénierie agile...

Je m’approprie, donc les nouveaux outils de blogue à ma disposition et je vous reviens bientôt.

Joyeux temps des fêtes!

NUnit devient plus expressif

2007-06-29T18:49:00.000-07:00

J'ai téléchargé la dernière version de NUnit 2.4 et je suis content des améliorations apportées à l'API. Le nouveau modèle d'assertion basé sur les contraintes rend les tests plus expressifs.
Je n'écrirai plus les assertions du type:

Assert.AreEqual(myString, "Hello");

mais plutôt:

Assert.That(myString, Is.Equal("Hello"));

ou mieux encore si ma classe de test hérite de AssertionHelper, je pourrai écrire

Expect(myString, EqualTo("Hello"));

Il me semble que cette syntaxe est plus lisible

Classification des tests

2007-06-29T18:24:00.000-07:00

Jimmy Bogard a un excellent message sur la classification des tests:

Les tests unitaires vérifient le bon fonctionnement d'une méthode/fonction en isolation du reste du système. Ils doivent s'exécuter rapidement et n'avoir qu'une cause d'échec. Pour ce genre de tests on évite d'impliquer une base de données, un service web ou tout autre système externe.
Les tests d'intégration vérifient le bon fonctionnement d'un système lorsqu'il est intégré avec les systèmes externes tels qu'une base de données par exemple. En général, ces tests vérifient que les données sont bien mises à jours dans la base de données ou qu'un courriel a bien été envoyé.
Les tests fonctionnels vérifient le bon fonctionnement de l'application dans son ensemble du point de vue de l'usager.

À lire également le message de Jeffrey Palermo sur le sujet

Pourquoi introduire de nouveaux acronymes ?

2007-06-13T19:20:00.000-07:00

J'ai visioné une présentation de Dan Ver Johnsson sur les Domain Logical Value Objects. C'est une présentation sur la manière d'introduire le Domain Driven Design dans du code patrimonial. En gros, le présentateur propose de commencer à rendre explicite les valeurs significatives pour le domaine en question: numéro de téléphone, taux de change, etc. De cette manière on peut rapidement bénéficier des améliorations suivantes:

Clareté des API de Service
Validation et gestion d'erreurs proches des données
Simplification du code de la logique de métier
Tests

Même si je suis d'accord avec les points présentés, je regrette toutefois que le présentateur aie ressenti le besoin de fournir un autre acronyme/terme technique: Domain Logical Value Object. Il me semble que tout ce dont il a parlé c'est des Value Object tels que présentés par Eric Evans dans son livre sur le DDD.

Par ailleurs, à un moment donné il propose un exercice pour trouver les situations où l'application du DDD est opportune. Selon moi, la réponse est que cela dépend toujours du contexte dans lequel ces projets sont entrepris. On ne peut répondre juste en se basant sur l'énoncé du domaine. Il faut impliquer les experts afin de connaître où ils en tirent le plus de valeur.

Domain Driven Design et Spécifications éxécutables

2007-06-12T20:20:00.000-07:00

Dernièrement, je donnais un cours sur le Domain Driven Design. Pour les exercices pratiques j'ai utilisé GreenPepper afin de pouvoir spécifier les fonctionnalités à accomplir sans pour autant imposer un design aux participants. Je dois avouer que je suis un peu perplexe quant au résultat de cette expérience. Les participants ont eu l'air de s'intéresser plus au produit qu'aux techniques présentées dans le cours afin de mieux cerner le domaine. Sans compter que l'apprentissage de l'outil peut constituer une barrière importante à la bonne conduite de l'exercice. Pourtant une approche basée sur des tests unitaires fournis ne me semble pas idéale car le design serait alors imposé. Les spécifications exécutables, par contre, se situent plus au niveau du modèle et du langage et de ce fait me paraissent encore plus appropriées...

Krugle - un moteur de recherche pour le logiciel libre

2007-05-29T19:23:00.001-07:00

Aujourd'hui j'ai découvert krugle un moteur de recherche dédié au logiciel libre. Ce site permet d'effectuer des recherches sur une multitudes de dépots de sources de projets du domaine public. Adieu les recherches sur Google...

My first walk in the blogosphere

2007-05-23T07:25:00.000-07:00

Hey,

I'm new to this! In the following weeks, I'll try to share some of my ideas with you. Hope you find them interesting...

Ernst