Tech'n bolts

Il y a peut être une option pour continuer ¡¿ (réflexion sur la programmation par continuation)

2012-12-05T00:00:00+00:00

C’est là bas que c’est publié: Il y a peut être une option pour continuer ¡¿ (réflexion sur la programmation par continuation)

AMQP 101 ~ Part I

2012-11-06T00:00:00+00:00

C’est là bas que c’est publié: AMQP 101 ~Part I

Le BDD mis en oeuvre avec JBehave

2012-06-21T00:00:00+00:00

C'est là bas que c'est publié: Le BDD mis en oeuvre avec JBehave

Le BDD, qu’est ce que c’est?

2012-06-15T00:00:00+00:00

C’est là bas que c’est publié: Le BDD, qu’est ce que c’est?

Twitter quotes: Business Components versus Bounded Contexts

2012-02-14T00:00:00+00:00

— Last updated 2012/02/15

Twitter exchange on “Business Components versus Bounded Contexts” after the blog post: Udi & Greg Reach CQRS Agreement

Eric Evans

Fundamentally, in #DDD, a Bounded Context is linguistic: a part of the system/project where language is consistent and rules agree.
— Eric Evans (@ericevans0) Février 11, 2012

bit.ly/udigreg says ‘Business Component’ is in 1 Bounded Context. Def of B Ctxt doesn’t say this IS so. In good design SHOULD be so
— Eric Evans (@ericevans0) Février 11, 2012

@Bemafred Distinct concepts. Good separation of concerns allows you to deal with diff concerns in diff contexts. Must see contexts as-is
— Eric Evans (@ericevans0) Février 11, 2012

thinkb4coding / jeppec

@thinkb4coding Seems you have the hands down on Business Components versus Bounded Contexts. Can you clarify on udidahan.com/2012/02/10/udi… — (tweet)

@jeppec

@jeppec it’s true Thar there’s few words about bizcomp on the blogs for now — (tweet)

@jeppec from my experience BCtx contains several smaller services that represent Business units that are impl separately — (tweet)

@jeppec this are the business components, that have different users, dev/deployment lifecycles.. — (tweet)

@jeppec it’s a level between bounded context and aggregates. They group services that work together to provide a business unit — (tweet)

@jeppec the c/q segregation happens at this level. Neither at the top level, neither at the bounded ctx level. It’s too large — (tweet)

@thinkb4coding

@thinkb4coding that sounds reasonable and I think most CQRS users do this. But when did the business component term get defined? — (tweet)

@thinkb4coding Such as Usecase specific services (eg. different clients/users might have special needs/flows). Makes sense? — (tweet)

@jeppec

@jeppec yep. I think udi talks about it in his course. — (tweet)

@thinkb4coding

Udi Dahan

Confusion around Bounded Context / Business Component is influenced by the first being solution domain, second being problem domain…
— UdiDahan (@UdiDahan) February 14, 2012

@UdiDahan Subdomain is already used in problem space when doing domain assessment. Why not stick with that and not introduce ambiguous term?
— Vaughn Vernon (@VaughnVernon) Février 14, 2012

DDD doesn’t try to enforce alignment between solution and problem domains
— UdiDahan (@UdiDahan) February 14, 2012

@UdiDahan Are you saying that problem domain exists inside a Bounded Context? Thought you said Biz Component was inside, sounds solution-y.
— Vaughn Vernon (@VaughnVernon) Février 14, 2012

That’s where we get into trouble using DDD terminology to describe a specific form of good design that enforces alignment
— UdiDahan (@UdiDahan) February 14, 2012

@UdiDahan a particular form of good design is supported by aligning Bounded Context 1:1 with Subdomain. But also supports less good design.
— Vaughn Vernon (@VaughnVernon) Février 14, 2012

It turns out that I didn’t represent @ericevans0 Bounded Context correctly. He allows for them to be a problem or solution domain construct.
— UdiDahan (@UdiDahan) February 15, 2012

Javascript Libraries

2012-01-21T00:00:00+00:00

Javascript Libraries that would require some attention:

Backbone.js

Backbone supplies structure to JavaScript-heavy applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing application over a RESTful JSON interface.
Backbone.js

Modernizr

Modernizr is a small JavaScript library that detects the availability of native implementations for next-generation web technologies, i.e. features that stem from the HTML5 and CSS3 specifications.
Modernizr

underscore.js

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support…
underscore.js

Require.js

RequireJS is a JavaScript file and module loader.
Require.js

EMBER.JS

Ember is a JavaScript framework for creating ambitious web applications by eliminating boilerplate and providing a standard application architecture.
EMBER.JS

{less}

The dynamic stylesheet language.
LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions.
{less}

Bootstrap – Twitter

Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites.
It includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more.
Bootstrap

D3.js

Data-Driven Documents.
D3.js is a small, free JavaScript library for manipulating documents based on data.
D3.js

Building a single page app with Backbone.js, underscore.js and jQuery

Quote of the day

2011-12-31T00:00:00+00:00

I thought of objects being like biological cells and/or individual computers on a network,only able to communicate with messages
Alan Kay

[T|B|D]DD par la pratique 5 - Persistence et Migrations

2011-12-12T00:00:00+00:00

Persistence

Interessons-nous à persister nos données afin de pouvoir les conserver d'une session à l'autre. Afin de démarrer simplement nous utiliserons une base de données postgres comme unité de stockage. Nous verrons plus tard pour une implémentation type NoSQL: MongoDB ou CouchDB.

Nous avons vu que seuls nos évènements devaient être persistés, ce n'est pas tout à fait vrai. Nous allons persister les entités et leurs évènements. Il n'est pas nécessaire de créer une table par type d'entité, mais uniquement les tables nécessaires à stocker les évènements.

Il existe de nombreux articles sur la création d'un EventStore, nous prendrons comme base une modélisation décrite par Greg Young dans cet article.

Rappellons brièvement cette modélisation d'un point de vue base de données.

Note bien que ce soit des notions bien différentes, nous utiliserons dans cet article le mot aggregat à la place de entité dans nos descriptions, ceci afin d'être plus en adéquation avec la littérature autour de cqrs. Pour rappel, chacune de nos entité étend de AggregateRoot, l'amalgame n'est donc pas si farfelu. Un aggregat est un concept plus large que le concept d'entités, et définit un contexte d'intégrité de son contenu. Une entité est généralement un aggrégat, l'inverse n'est pas toujours vrai (même si aucun exemple ne me vient en tête à cet instant)

Nous créérons deux tables, la première Aggregates sera responsable de maintenir les informations de chaque aggregat:

son identifiant: aggregate_id
le type de l'aggrégat: type, c'est à dire le type généralement le type de l'entité sous-jacente par exemple: story, project, sprint ...
sa version. La version d'un aggregat sera principalement utilisée pour implémenter le mécanisme de mise à jour optimiste (optimisting locking). Un point interessant et très simple consiste à utiliser, comme numéro de version, le nombre d'élément contenu dans l'historique. En effet, l'historique d'un aggrégat ne peux que croitre, puisque les évènements sont toujours ajoutés et ne peuvent jamais être supprimés. Tous les changements d'états sont appliqués séquentiellement, il est donc même possible d'utiliser l'index d'un évènement comme identifiant de celui-ci. En conservant, la version sur l'aggrégat on peux ainsi génèrer l'identifiant des prochains évènements sans relire l'intégralité de l'historique. De plus, l'identifiant de l'évènement peut être utilisé pour ordonner et réappliquer l'historique dans le bon ordre. Aussi, une entité peut être mise à jour avec de nouveaux évènements si et seulement si les évènements s'applique depuis la dernière version persistée de l'entité. [TODO] un example concret.

Nom de colonne	Type de données
aggregate_id	varchar(36)
aggregate_type	varchar(255)
aggregate_version	integer

CREATE TABLE aggregates
(
  aggregate_id      CHARACTER VARYING(36) NOT NULL,
  aggregate_type    CHARACTER VARYING(255) NOT NULL,
  aggregate_version INTEGER NOT NULL,
  CONSTRAINT aggregates_pkey PRIMARY KEY (aggregate_id)
);

La seconde table AggregateEvents sera responsable de conserver les évènements eux-mêmes:

l'identifiant de l'aggrégat auquel est rattaché l'évènement. Cette colonne est indéxée sur la table précedente.
l'identifiant de l'évènement: correspondant à sa position dans l'historique
le type d'évènement afin de simplifier les éventuelles requêtes et analyses futures
les données de l'évènements sous forme de données brutes. Nous utiliserons dans notre cas la sérialization json de notre évènement.

Nom de colonne	Type de données
aggregate_id	varchar(36)
event_id	integer
event_type	varchar(255)
event_data	clob / text

CREATE TABLE aggregate_events
(
  aggregate_id   CHARACTER VARYING(36) NOT NULL,
  event_id       INTEGER NOT NULL,
  event_type     CHARACTER VARYING(255) NOT NULL,
  event_data     TEXT, 
  CONSTRAINT aggregateevts_pkey PRIMARY KEY (aggregate_id, event_id),
  CONSTRAINT aggregateevts_fk1  FOREIGN KEY (aggregate_id) REFERENCES aggregates(aggregate_id)
);

CREATE INDEX aggregateevts_aggid ON aggregate_events (aggregate_id);

Postgres est une base de données simple mais très complète. Nous ne détaillerons pas son fonctionnement, nous vous recommandons donc de vous familliariser un peu avec et de créer une base de données par l'intermédiaire de pgAdmin (voir ici pour des tutoriaux très simples sur l'installation, la mise en oeuvre et l'utilisation de pgAdmin).

Nous considérerons désormais qu'un role de connexion dédié a été créé et est disponible pour nous permettre de créer les bases de données dont nous aurons besoin notament pour nos tests d'intégrations et de validation de script SQL. Dans notre cas nous l'avons appellé integration et son mot de passe est 1tegration.

Ce que nous allons mettre en place dès maintenant:

NodeJS et Postgres, où sont nos tests d'intégrations?

Afin de distinguer les tests unitaires qui doivent rester rapides et indépendants, nous allons créer un répertoire dédié à nos tests d'intégrations it.

Dans conf/sql/postgres nous placerons les fichiers sql qui serviront aux différentes migrations de notre application. Nos scripts seront nommés de tels sortes que l'on puisse automatiquement déterminer leur ordre d'application.

conf/sql/postgres/0001-aggregates.sql

CREATE TABLE aggregates
(
  aggregate_id      CHARACTER VARYING(36) NOT NULL,
  aggregate_type    CHARACTER VARYING(255) NOT NULL,
  aggregate_version INTEGER NOT NULL,
  CONSTRAINT aggregates_pkey PRIMARY KEY (aggregate_id)
);

conf/sql/postgres/0002-aggregates_events.sql

CREATE TABLE aggregate_events
(
  aggregate_id   CHARACTER VARYING(36) NOT NULL,
  event_id       INTEGER NOT NULL,
  event_type     CHARACTER VARYING(255) NOT NULL,
  event_data     TEXT, 
  CONSTRAINT aggregateevts_pkey PRIMARY KEY (aggregate_id, event_id),
  CONSTRAINT aggregateevts_fk1  FOREIGN KEY (aggregate_id) REFERENCES aggregates(aggregate_id)
);

CREATE INDEX aggregateevts_aggid ON aggregate_events (aggregate_id);

Créons aussi un fichier d'environement dans lequel on renseignera l'emplacement des binaires de postgres ainsi que les identifiants d'un role de connexions ayant les droits de créer une base de données (dans la fenêtre propriétés du rôle de connexion, onglet Droits du rôle, cochez la cache "Peux crééer des bases de données).

conf/env-it.json

{
    "postgres_bin"  : "/Library/PostgreSQL/9.0/bin/",
    "postgres_user" : "integration",
    "postgres_pass" :  "1tegration"
}

Note importante sur JSON.parse; La transformation d'une chaîne de caractère au format JSON en son équivalent javascript a été douleureuse, en effet la méthode JSON.parse est très stricte, et nécessite une syntaxe irréprochable. Voici les déboires, sous forme de tests, que nous avons subit:

test/json_test.js

exports["JSON issue: key must be quoted"] = function (test) {
    test.throws(function () {
        JSON.parse('{ name : "mccallum" }');
    });
    test.done();
};

exports["JSON issue: key cannot be quoted by single quote"] = function (test) {
    test.throws(function () {
        JSON.parse("{ 'name' : \"mccallum\" }");
    });
    test.done();
};

exports["JSON issue: value cannot be quoted by single quote"] = function (test) {
    test.throws(function () {
        JSON.parse("{ \"name\" : 'mccallum' }");
    });
    test.done();
};

Ce qui est interessant aussi à noter c'est que dans notre approche, les tests servent aussi de terrain d'expérimentation. Et si ceux-ci sont suffisament autonomes, nous pouvons les conserver à titre d'exemple et de non regression sur les outils que nous utilisons à travers notre application.

Via pgAdmin / Fichier / Ouvrir .pgpass ajoutons les paramètres de connection de notre utilisateur afin que le mot de passe ne soit pas demandé en ligne de commande, notons l'emplacement de ce fichier et éditons le comme suit:

localhost:5432:*:postgres:postgres
localhost:5432:*:integration:1tegration

Nous utiliserons principalement deux bases de données: dropable_dbname et persistent_dbname. La première base de données dropable_dbname sera supprimée et recrée à chaque fois que les scripts de migration seront testés, afin de valider leurs syntaxes sur une base vierge. La seconde base de données peristent_dbname quant à elle sera conservée, et considérée comme présente par nos tests.

Quart d'heure Soirées détente explorations de l'utilisation de Postgres en mode non bloquant

Afin de bien comprendre le fonctionement du module node-postgres, nous allons nous écarter quelque peu de notre application pour effectuer un spike sur l'utilisation de ce module.

En effet, généralement les requêtes sql sont effectuées de manière séquentiellement et bloquantes, c'est à dire que l'on attend (le fil d'execution est en attente) que notre base de données ait renvoyé le résultat avant d'enchainer avec la prochaine requête.

var result = execute("""create table creatures ( 
    name CHARACTER VARYING(255) NOT NULL,
    description TEXT
)
"""); // appel bloquant on attend la réponse avant de poursuivre

var insert_sql = "insert into creatures (name, desc) values (?,?)";
execute(insert_sql, ["Korrigan", "Créature légendaire du folklore de Bretagne, comparable au lutin français"]);
execute(insert_sql, ["Mary Morgan", "Fées d'eau bretonnes semblables à des femmes, qui partagent la symbolique des sirènes"]);

Il est en effet nécessaire d'attendre que la table creatures soit créée avant de pouvoir insérer des enregistrements. Le problème de cette approche est de monopoliser une partie des ressources de l'application en attendant la réponse de notre base de données, le traitement est bloqué.

node-postgres propose une approche différente et un peu déroutante en prime abord. Lorsque la requête sql est soumise à la base de données, il est possible d'y associer une fonction de rappel (callback) qui sera invoquée lorsque le résultat de notre requête sera disponible. Pendant ce temps, l'application continue son execution et n'est pas bloquée à cette instruction.

Reprenons l'exemple précédent, celui-ci pourrait ainsi être transformée comme suit:

 1 var client = new pg.Client('postgres://'+settings.postgres_user+':'+settings.postgres_pass+'@localhost:5432/' + db_name);
 2     client.connect();
 3 
 4 var insert_sql = "insert into creatures (name, desc) values (?,?)";
 5 var create_query = client.query("create table creatures ( ... )");
 6 
 7 create_query.on('end', function() {
 8     var insert1 = client.query(insert_sql, ["Korrigan", "Créature ..."]);
 9     insert1.on('end', function() {
10         var insert2 = client.query(insert_sql, ["Mary Morgan", "Fées ..."]);
11         insert2.on('end', function() {
12             client.end();
13         });
14       })
15 });
16 ...

Ligne 5, la requête de création de la table est soumise au serveur, le serveur n'a pas encore répondu que notre application continue de s'executer. Nous enregistrons alors une fonction de rappel ligne 7 qui sera invoquée lorsque notre création de table sera terminée (nous ne détaillons pas ici les gestions d'erreurs). Notre application poursuit alors son execution ligne 16.

Lorsque la table est créée, notre fonction de retour est invoquée, et nous poursuivons l'execution de notre code ligne 8. Nous insérons alors notre première valeur, et pendant ce temps, enregistrons une nouvelle fonction de retour (ligne 9) qui sera appellée et nous permettra d'enregistrer notre seconde valeur. Une fois la première valeur insérée, notre fonction sera invoquée, et notre seconde valeur insérée.

Si l'on regarde de plus près, on peux se rendre compte que seules nos insertions nécessitent d'être effectuées après la création de la table. Dans notre exemple, il n'est pas nécessaire que la seconde insertion ait lieu uniquement si la première a bien été réalisée.

Nous pouvons donc modifier le code, afin d'executer nos deux insertion de manière asynchrone. La difficulté est alors d'être informé lorsque nos deux insertions ont été réalisées.

node-postgres nous indique:

Clients are responsible for creating Queries via the factory method Client#query. The Client can create a new query before the client is connected to the server or while other queries are executing. Internally the Client maintains a queue of Query objects which are popped and executed as the preceding Query completes. When the Client's internal query queue is emptied, the Client raises the drain event.

En s'enregistrant sur l'évènement drain, il est donc possible d'être informé lorsque toutes nos requêtes seront executées.

...
// s'assure que même si la `queue` est vide entre temps l'évènement 'drain' 
// ne sera pas déclenché
client.pauseDrain();
client.on('drain', function() {
  client.end();
});

var create  = client.query("create table creatures ( ... )");
var insert1 = client.query(insert_sql, ["Korrigan", "Créature ..."]);
var insert2 = client.query(insert_sql, ["Mary Morgan", "Fées ..."]);
insert2.on('end', function() {
    // maintenant que nous avons effectué notre dernière requête sql,
    // si la queue est vide cela signifie bien, que tout est fini
    // rendons possible le déclenchement de l'évènement 'drain' 
    client.resumeDrain();
});

Dans notre cas, les migrations doivent être séquentielles et une migration est conditionnée par la réussite de la précédente. La dernière approche n'est donc pas directement envisageable. Tentons de rendre la première approche plus dynamique en chaînant les on('end', function() ...) de manière recursive.

Considérons que nos requêtes sql sont dans un tableau statements

var execute_stmts = function(client, index, statements, last) {
  if(index==statements.length) {
    last();
    return;
  }
  var query = client.query(statements[index]);
  query.on('end', function () {
      function(client, index+1, statements, last);
  });
}

execute_stmts(client, 0, statements, function() {
  client.end();  
});

Si les requêtes sont plus compliquées, au lieu de passer les requêtes SQL, appellons une fonction qui retournera la dernière query qu'elle aura soumise:

var execute_stmts = function(client, index, statements, last) {
  if(index==statements.length) {
    last();
    return;
  }
  var query = statements[index](client);
  query.on('end', function () {
      function(client, index+1, statements, last);
  });
}

execute_stmts(client, 0, statements, function() {
  client.end();  
});

avec par exemple

statements[1] = function(client) {
    return client.query(insert_sql, ["Korrigan", "Créature ..."])  ;
};
statements[2] = function(client) {
    return client.query(insert_sql, ["Mary Morgan", "Fées ..."])  ;
};

Histoire de valider nos connaissances, nous décidons d'écrire un mini-gestionnaire de migration dans le style (mais en moins ambitieux) que Liquibase ou Flyway.

Celui-ci est responsable d'appliquer les migrations une par une et de conserver la liste des migrations effectuées avec succès. Cela peux paraître un peu compliqué, mais l'experience montre qu'une fois mis en place, ce type de système allège considérablement le travail du support, la remontée des erreurs lors de migration et la reprise sur erreur.

Nous ajoutons donc une table migrations qui conservera l'ensemble des migrations qui ont été appliquées. Chaque migration pouvant être composée de plusieurs requêtes sql, nous conserverons aussi l'index de la dernière requête sql passée avec succès.

conf/sql/postgres/0000-migration.sql

CREATE TABLE migrations
(
  migration_id       CHARACTER VARYING(255) NOT NULL,
  migration_sequence INTEGER NOT NULL,
  migration_date     TIMESTAMP NOT NULL,
  CONSTRAINT migrations_pkey PRIMARY KEY (migration_id,migration_sequence)
);

La première version de notre outils de migration, après quelque refactorings, ressemble à:

it/postres_migration_it.js

var nutil = require('util'),
    exec  = require('child_process').exec,
    fs    = require('fs'),
    pg    = require('pg'),
    utilities = require('../lib/utilities'),
    migration = require('../lib/migration');

var settings_json = fs.readFileSync(__dirname + '/../conf/env-it.json', 'utf8');
var settings = JSON.parse(settings_json);
var db_name = settings.dropable_dbname;

var command_drop_db = 
    settings.postgres_bin + "dropdb " + db_name
        + " -e" //echo the commands
        + " -U " + settings.postgres_user;

var command_create_db = 
    settings.postgres_bin + "createdb " + db_name
        + " -e" //echo the commands
        + " -E UTF8"
        + " -O " + settings.postgres_user
        + " -U " + settings.postgres_user;

var update_sequence = function(client, migration_id, index, next) {
    return  function() {
        console.log("Migration [" + migration_id + ", " + index + "]: updating sequence");
        var query = client.query(
            "insert into migrations (migration_id, migration_sequence, migration_date) values($1, $2, $3)", 
            [migration_id, index, new Date()]);
        query.on('error', function(error) {
            console.log("Migration [" + migration_id + ", " + index + "]: updating sequence " + error);
            throw error;
        });
        query.on('end', next);
    };
};

var execute_statements = function(client, migration_id, index, statements, last) {
    return function () {
        if(index>=statements.length) {
            last();
            return; 
        }

        var stmt = statements[index];
        console.log("Migration [" + migration_id + ", " + index + "]: <<<" + stmt + ">>>");
        var migration = client.query(stmt);
        migration.on('end', 
            update_sequence(client, migration_id, index, 
                execute_statements(client, migration_id, index+1, statements, last))
        );
        migration.on('error', function(error) {
            console.log("Migration [" + migration_id + ", " + index + "]: " + error);
            throw error;    
        });
    };
};

var execute_migration = function(client, migration_id, statements, on_last_statement) {
    console.log("Migration [" + migration_id + "] #" + statements.length + " statements");

    // retrieve any previously migration sequence applied
    var start_index_query = client.query("select count(*) from migrations where migration_id = $1", [migration_id]);
    start_index_query.on('row', function(row) {
        var index = row.count;
        execute_statements(client, migration_id, index, statements, on_last_statement)();  
    });
    start_index_query.on('error', function(error) {
        var migrations_table_missing = utilities.contains(error.message,'relation "migrations" does not exist');
        var initial_migration = (migration_id === "0000");

        // special case migration '0000'
        if(initial_migration && migrations_table_missing) {
            console.log("Migration [" + migration_id + "] " + error.message);
            client.query('rollback');
            console.log("Starting a new transaction");
            client.query('begin');
            execute_statements(client, migration_id, 0, statements, on_last_statement)();
        }
        else {
            //handle the error
            console.log(error);
            throw error;
        }
    });
};

var execute_migrations = function(client, index, migrations, once_last_migration) {

    var migration_id    = migrations[index][0];
    var migration_stmts = migrations[index][1];
    var is_last_migration = (index+1 === migrations.length);

    var begin = client.query('begin');
    begin.on('end', function() {
        var on_last_statement = function() {
            var commit = client.query('commit');
            commit.on('end', function() {
                console.log("Migration [" + migration_id + "] commited");
                if(is_last_migration) {
                    once_last_migration();
                }
                else {
                    execute_migrations(client, index+1, migrations, once_last_migration);
                }
            });    
        };

        execute_migration(client, migration_id, migration_stmts, on_last_statement);
    });
};

var migrate = function () {
    var client = new pg.Client('postgres://'+settings.postgres_user+':'+settings.postgres_pass+'@localhost:5432/' + db_name);
        client.connect();

    var migrations = [];
    migration.vendor_migrations("postgres", function(migration_id, statements) {
        migrations[migrations.length] = [migration_id, statements];
    });

    execute_migrations(client, 0, migrations, function() {
        client.end();
        console.log("Releasing connection");
    });
};

var create_db = function() {
    exec(command_create_db,
      function (error, stdout, stderr) {
        console.log('stdout: ' + stdout);
        console.log('stderr: ' + stderr);
        if (error !== null) {
          console.log('exec error: ' + error);
        }
        console.log('executing migrations');
        migrate();
    });
};

// pkill -f 'postgres: postgres <database>'

exec(command_drop_db,
      function (error, stdout, stderr) {
        console.log('stdout: ' + stdout);
        if(stderr.indexOf("does not exist") === -1) {
            console.log('stderr: ' + stderr);
            if (error !== null) {
              console.log('exec error: ' + error);
            }
        }
        create_db();
    });

la commande exec(command_drop_db, ... lance une commande système (shell) afin de supprimer notre base de données d'intégration
en cas de succès, la fonction create_db() est alors invoquée, et elle-même lance une commande système pour créer notre base de données.
en cas de succès, la fonction migrate() est invoquée.
la fonction migrate() est le point de départ des appels récursifs afin de chainer les migrations uniquement en cas de succès (comme évoquer précédement). La fonction recursive d'execution des migrations est la fonction execute_migrations.
la fonction execute_migrations est responsable d'executer une migration donnée execute_migration En cas de succès, la transaction courante est commitée et l'execution de la prochain migration est invoquée de manière récursive.
la fonction execute_migration est chargée d'executer les requêtes SQL composant le script de migration. Il commence tout d'abord par recupérer l'index de la dernière requête SQL executée avec succès et execute de manière récursive (execute_statements) toutes les requêtes SQL manquantes à partir de cet index.
Après chacune de ces requêtes la table migrations est mise à jour afin de conserver l'avancement de la migration pour les prochains essais.

En partant d'une base vierge, notre script test donc l'intégralité de nos migrations. Lançons le

node it/postgres_migration_it.js

La console affiche alors:

stdout: DROP DATABASE nscrum_dropable_itdb;

stderr: 
stdout: CREATE DATABASE nscrum_dropable_itdb OWNER integration ENCODING 'UTF8';

stderr: 
executing migrations
Migration [0000] #1 statements
Migration [0000] relation "migrations" does not exist
Starting a new transaction
Migration [0000, 0]: <<<CREATE TABLE migrations
(
  migration_id       CHARACTER VARYING(255) NOT NULL,
  migration_sequence INTEGER NOT NULL,
  migration_date     TIMESTAMP NOT NULL,
  CONSTRAINT migrations_pkey PRIMARY KEY (migration_id,migration_sequence)
)>>>
Migration [0000, 0]: updating sequence
Migration [0000] commited
Migration [0001] #1 statements
Migration [0001, 0]: <<<CREATE TABLE aggregates
(
  aggregate_id      CHARACTER VARYING(36) NOT NULL,
  aggregate_type    CHARACTER VARYING(255) NOT NULL,
  aggregate_version INTEGER NOT NULL,
  CONSTRAINT aggregates_pkey PRIMARY KEY (aggregate_id)
)>>>
Migration [0001, 0]: updating sequence
Migration [0001] commited
Migration [0002] #2 statements
Migration [0002, 0]: <<<CREATE TABLE aggregate_events
(
  aggregate_id   CHARACTER VARYING(36) NOT NULL,
  event_id       INTEGER NOT NULL,
  event_type     CHARACTER VARYING(255) NOT NULL,
  event_data     TEXT, 
  CONSTRAINT aggregateevts_pkey PRIMARY KEY (aggregate_id, event_id),
  CONSTRAINT aggregateevts_fk1  FOREIGN KEY (aggregate_id) REFERENCES aggregates(aggregate_id)
)>>>
Migration [0002, 0]: updating sequence
Migration [0002, 1]: <<<CREATE INDEX aggregateevts_aggid ON aggregate_events (aggregate_id)>>>
Migration [0002, 1]: updating sequence
Migration [0002] commited
Releasing connection

et le contenu de la table migrations:

select * from migrations;

ID	Sequence	Date
"0000"	0	"2011-10-18 12:22:05.774"
"0001"	0	"2011-10-18 12:22:05.788"
"0002"	0	"2011-10-18 12:22:05.803"
"0002"	1	"2011-10-18 12:22:05.806"

On peux constater que la migration "0002" est bien décomposée en deux sous requêtes: création de la table et création de l'index.

Nous disposons finalement d'un outil de migration et d'un test d'intégration nous permettant de le valider à chaque ajout de nouvelles migrations ou d'édition de script.

Dans notre prochain article, nous reviendrons au fonctionnel de notre projet et à la persistence de nos évènements. Nous créerons pour cela la classe qui modélisera notre EventStore.

Les sources de notre application à ce stade peuvent téléchargées ici.

[T|B|D]DD par la pratique 4 - Backlog et Story

2011-12-11T00:00:00+00:00

Le backlog est directement lié au projet par une relation 1-1: le backlog appartient à un projet et un projet ne possède qu'un backlog. D'un certain point de vue, le backlog existe fonctionnellement, mais créer une entité dédiée n'apporte, à ce stade, pas grand chose: il s'agit plus d'un concept que l'on qualifiera d'affichage qu'un besoin de persistence. Nous nous passerons donc de définir une entité dédiée au backlog.

En revanche, une story joue un rôle centrale (certain parle même de ventrale) dans notre application. Les discussions de travail seront souvent centrées autour d'une story particulère, bien identifiée par son nom et sa description. Et même si une story appartient à un projet, nous considérerons plutôt qu'elle est liée à celui-ci, et qu'elle constitue une entité à part entière.

Rappelez-vous:

En tant que membre de l'équipe, je peux créer de nouvelles entrées dans le backlog du projet, si bien que les besoins fonctionnels de notre projet pourront être récolter. Une story sera définie par un titre, une description, une évaluation en points de sa complexité, ainsi que sa valeur cliente business value.

Transcrivons cela dans notre tests fonctionnels:

specs/story_specs.js

var vows = require('vows'),
    assert = require('assert');

var story = require('../lib/story');

var UUID_PATTERN = /[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{8}/;

vows.describe('Story').addBatch({
    'A new story': {
        topic: function () {
            return story.create({
                name:"As a developer, I want to known NodeJS so that i increase my knowledge", 
                description: "By learning NodeJS, the developer will be able to undestand its success", 
                complexity: 7,
                business_value: 120
            });
        },

        'should return an instance of Story' : function(st) {
            assert.instanceOf (st, story.Story);
        },

        'should have the specified name': function (story) {
            assert.equal (story.name(), 'As a developer, I want to known NodeJS so that i increase my knowledge');
        },

        'should have the specified description': function (story) {
            assert.equal (story.description(), 'By learning NodeJS, the developer will be able to undestand its success');  
        },

        'should have the specified complexity': function (story) {
            assert.equal (story.complexity(), 7);  
        },

        'should have the specified business value': function (story) {
            assert.equal (story.business_value(), 120);  
        },

        'should have a generated uuid': function (story) {
            assert.equal(UUID_PATTERN.test(story.uuid()), true);
        }
    }
}).export(module); // Export the Suite

Créons aussi notre premier test unitaire: test/story_test.js

var story  = require("../lib/story");

exports["create return a new story"] = function (test) {
    var st = story.create("mccallum");
    test.ok(st instanceof story.Story);
    test.done();
};

Un petit tour sur notre console, c'est bien rouge! Definissons notre classe Story:

lib/story.js

/**
 *  Story
 */
function Story() {}
exports.Story = Story;

exports.create = function(data) {
    var story = new Story();
    return story;
};

Notre test unitaire devient vert, ainsi que le premier test fonctionnel.

Passons rapidement, et ajoutons alors les tests unitaires suivants: test/story-test.js

var story  = require("../lib/story");
var UUID_PATTERN = /[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{8}/;

exports["create return a new story"] = function (test) {
    var st = story.create("mccallum");
    test.ok(st instanceof story.Story);
    test.done();
};

exports["create return a new story with the given name"] = function (test) {
    var st = story.create({name:"mccallum"});
    test.equal(st.name(), "mccallum");
    test.done();
};

exports["create return a new story a generated uuid"] = function (test) {
    var st = story.create({name:"mccallum"});
    test.ok(UUID_PATTERN.test(st.uuid()));
    test.done();
};

exports["a new story must have an `events` method to retrieve its history"] = function (test) {
    var st = story.create({name:"mccallum"});

    var events = st.events();
    test.ok(events instanceof Array);
    test.done();
};

exports["a new story must have a single `event` in its history"] = function (test) {
    var st = story.create({name:"mccallum"});

    var events = st.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 1);
    test.done();
};

exports["a new story must have a single `event` in its history of type 'story_created'"] = function (test) {
    var st = story.create({name:"mccallum"});

    var events = st.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 1);
    test.equal(events[0].event_type(), "story_created");
    test.done();
};

Inspirons nous fortement de notre classe Projet:

notre classe Story va hériter de AggregateRoot
nous ajoutons un évènement StoryCreated définit comme suit:

var StoryCreated = function(project_id, story_id, story_name, story_description, complexity, business_value) {
    this.event_type = to_f("story_created");
    this.project_id = to_f(project_id);
    this.story_id   = to_f(story_id);
    this.story_name = to_f(story_name);
    this.story_description = to_f(story_description);
    this.complexity = to_f(complexity);
    this.business_value = to_f(business_value);
};

exports.StoryCreated = StoryCreated;

rajoutons le event_handler correspondant à l'évènement story_created
et nous obtenons alors:

lib/story.js

var uuid  = require('node-uuid'),
    aroot = require('./aggregate_root'),
    nutil = require('util'),
    misc  = require('./utilities');

var to_f = function(value) { 
    return function () { 
        return value; 
    };
};

/**
 *  Events
 */

var StoryCreated = function(project_id, story_id, story_name, story_description, complexity, business_value) {
    this.event_type = to_f("story_created");
    this.project_id = to_f(project_id);
    this.story_id   = to_f(story_id);
    this.story_name = to_f(story_name);
    this.story_description = to_f(story_description);
    this.complexity = to_f(complexity);
    this.business_value = to_f(business_value);
};

exports.StoryCreated = StoryCreated;

/**
 *  Story
 */
var methods = {
    event_handlers : {
        on_story_created: function(event) {
            this._uuid = event.story_id();
            this._name = event.story_name();
            this._desc = event.story_description();
            this._complexity = event.complexity();
            this._business_value = event.business_value();
        }
    },
    name : function () {
        return this._name;
    },
    description : function () {
        return this._desc;
    },
    complexity : function () {
        return this._complexity;
    },
    business_value : function () {
        return this._business_value;
    }
};

function Story() {}
nutil.inherits(Story, aroot.AggregateRoot);
misc.mixin(Story.prototype, methods);
exports.Story = Story;

exports.create = function(data) {
    var story = new Story();
    story.apply_event(new StoryCreated(
        data.project_id, 
        uuid(), 
        data.name, 
        data.description, 
        data.complexity, 
        data.business_value));
    return story;
};

La bonne nouvelle c'est que tous nos tests passent. La mauvaise nouvelle c'est que le caractère obligatoire du nom de la Story et de l'identifiant du projet ne sont pas du tout vérifiés. Enrichissons nos tests afin de combler ce manque:

test/story_test.js

exports["a new story must have a 'name' and a 'project_id' specified"] = function (test) {
    test.throws(function () {
        story.create({});
    });
    test.done();
}

exports["a new story must have a 'project_id' specified"] = function (test) {
    test.throws(function () {
        story.create({name:"mccallum"});
    });
    test.done();
}

exports["a new story must have a 'name' specified"] = function (test) {
    test.throws(function () {
        story.create({project_id:"mccallum"});
    });
    test.done();
}

Modifions alors notre Story afin d'ajouter les vérifications voulues:

exports.create = function(data) {
    if(typeof data.project_id === 'undefined') {
        throw new Error("Missing story's <project_id>!");
    }
    if(typeof data.name === 'undefined') {
        throw new Error("Missing story's <name>!");
    }

    var story = new Story();
    story.apply_event(new StoryCreated(data.project_id, 
        uuid(), data.name, data.description, data.complexity, data.business_value));
    return story;
};

et la, hourra nos tests passent... enfin les nouveaux... parce que les anciens sont tous rouges: il manque le project_id dans la plupart. Une fois ajouté dans tous ces tests, ils passent tous, eh eh!

Compte-tenu de tout ce que nous avons pu voir jusqu'ici, nous passons rapidement sur l'ajout des méthodes rename, changeDescription, changeComplexity et changeBusinessValue. Pour chacune de ces méthodes, nous definissons les évènements respectifs suivant: StoryRenamed, StoryDescriptionChanged, StoryComplexityChanged et StoryBusinessValueChanged. De la même manière que pour la classe Projet, nous ajoutons la méthode load_from_history.

Faisons une petite pause et revenons quelques instants sur notre modélisation. Voici les étapes (d'un point de vue technique) pour la création d'un Project et l'ajout de Story à celui-ci:

var my_app = project.create("MyApplication");
...
var story01 = story.create({ 
    project_id: my_app.uuid(), 
    name: "As a team member, i want to navigate through all the stories of my project."
});

[TODO] méthode story.create est dissociée du projet, et a été ramenée au minimum d'informations requises c'est à dire le project.uuid ... un project peux compter plusieurs milliers de story dans son backlog c'est pourquoi contrairement à une approche classique nous ne souhaitons pas faire porter directement par le projet l'intégralité des story qui y sont rattaché, en d'autre terme nous évitons d'introduire une relation navigable et bidirectionnelle entre ces deux entités.

Et les commentaires?

En tant que membre de l'équipe, je peux completer une entrée du backlog en modifiant ses informations ou en ajoutant un commentaire, si bien que cette entrée disposera de plus amples informations à mesure des reflexions qu'elle peux suciter.

Définissions dans un premier temps notre test fonctionnel correspondant à la création d'un commentaire.

La difficulté qui apparait désormais est de vérifier que notre commentaire a bien été ajouté. En effet, si l'on prévoit que le nombre de commentaire peut être conséquent, il est peu probable que nous les conservions tous en mémoire. Ceci nous amène au point suivant: la persistence de nos données. Le soucis que nous voyons avec nos commentaires est en fait déjà présents à travers l'historique de nos entités, devons-nous conserver l'intégralité des évènements en mémoire? La réponse est bien évidemment non! Nous ne devrions conserver en mémoire sur nos entités uniquement les données qui ont une importance métier pour assurer son intégrité à tout instant. Dans ce cas, pourquoi conserver sur une Story, sa description, sa business value et sa complexity ? Et bien tout simplement parce dans un premier temps, nous ne disposons pas d'autre moyen de vérifier ces valeurs, et que d'autre par il ne devrait pas s'agir d'une consommation mémoire trop importante, en effet il est peu probable que le nom d'un Story excède les centaines de caractères, et que sa description (même en html) ne soient beaucoup plus importante qu'une page de texte. Il est donc raisonable dans un premier de temps de conserver ces valeurs directement sur l'entité.

D'autre part, l'intégralité de l'historique de nos entités est lui aussi conservé en mémoire, il va donc falloir remédier à cela aussi. Mais chaque chose en son temps. Plutôt que de conserver les commentaires en mémoires, nous travaillerons sur l'historique directement, et vérifierons que le commentaire est bien présent parmis les évènements de notre entité. Ainsi, lorsque la persistence de l'historique sera résolu, nos commentaires le seront aussi.

Et c'est la que l'on peux commencer à sentir la souplesse de notre modélisation par évènement: pour ajouter de nouvelles informations ou de nouveaux comportements, nous nous contentons de rajouter de nouveaux types d'évènements.

specs/story_specs.js

'Story' : {
    topic: function () {
        return story.create({
            project_id: "cafebabe-3550",
            name: "As a developer, I want to known NodeJS so that i increase my knowledge", 
        });
    },
    'can be improved by adding comment on it' : function(story) {
        var CONTENT = "NodeJS looks promising, not only for application but also as a tool to test and learn javascipt";
        story.add_comment(CONTENT);
        var last_event = story.last_event();
        assert.equal (last_event.event_type(), "story_comment_added");
        assert.equal (last_event.content(), CONTENT);
    }
}

On pourra noter l'ajout de la méthode last_event sur notre classe AggregateRoot:

lib/aggregate_root.js

// public methods
AggregateRoot.prototype = {
    ...
    events: function () { return this._events; },
    last_event: function () {
        if(typeof this._events === 'undefined') {
            return; // returns 'undefined'
        }
        else if(this._events.length === 0) {
            return; // returns 'undefined'
        }
        return this._events[this._events.length-1];
    },
    apply_event : function (event) {
    ...

Quelques tests unitaires notre Story est modifiée comme suit:

lib/story.js

var StoryCommentAdded = function(story_id, new_comment) {
    this.event_type = to_f("story_comment_added");
    this.content    = to_f(new_comment);
};
exports.StoryCommentAdded = StoryCommentAdded;

/**
 *  Story
 */
var methods = {
    event_handlers : {
        ...
        on_story_comment_added: function (event) {}
    },   
    
    ...

    add_comment: function(new_comment) {
        this.apply_event(new StoryCommentAdded(this._uuid, new_comment));
    }
};

...

Les sources de notre application à ce stade peuvent téléchargées ici.

Etats des lieux

Dans l'état, notre application permet de

créer un Project et modifier son nom
créer des Story rattachées à un projet, modifier leurs descriptions et rajouter des commentaires

Il nous manque encore:

la gestion des équipes, leurs membres et le rôle de chacun
la création d'un sprint, et des Task qui lui sont attachées

Par conséquent, notre P.O. (Product Owner) peux dès à présent commencer à enregistrer et préparer les Story qui viendront plutard alimenter notre Sprint. Euh... en fait non, notre P.O. ne peux pas le faire et ce pour plusieurs raisons:

Il ne dispose pas d'interface utilisateur pour le faire
Aucune persistence n'est encore assurée

Nos prochaines étapes consisteront donc remplir ces deux conditions afin que l'on puisse commencer le plutôt possible la saisie des Story de notre projet.

La sélection de décembre

2011-12-11T00:00:00+00:00

Coding styles

So real…

‘Yoda Conditions’, ‘Pokémon Exception Handling’ and other programming classics

Web design

Twitter bootstrap

Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites. It includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more.

Twitter bootstrap

Event, CQRS, high-scalability

DataSift Architecture: Realtime Datamining At 120,000 Tweets Per Second

Using Gossip Protocols For Failure Detection, Monitoring, Messaging And Other Good Things

Kafka

Building an Event-Sourced Web Application – Part 1: Domain Model, Events and State

Understanding the differences between AMQP & JMS

Complex Event Processing

CQRS, l’architecture aux deux visages

DDD

Effective Aggregate Design by Vaughn Vernon
Effective Aggregate Design by Vaughn Vernon – Part 1
Effective Aggregate Design by Vaughn Vernon – Part 2

Test-Driven Development: un pacte diabolique ?
Traduction de Test-Driven Development A Faustian Bargain

Ou comment faire l’amalgame entre un outil de travail et un process de développement. Le TDD n’est pas une méthode de gestion de projet et encore moins une méthode pour diriger ou concevoir un projet de bout en bout. Le TDD est un outil, parmis d’autre, pour la phase d’implémentation et ne se substitue pas à des phases de design, d’analyse et de conception plus globale de l’application.

Réaction @nmartignole
Réaction @BodySplash

Response to "Technical Job Interview Questions for Java EE architects"

2011-12-10T00:00:00+00:00

Table of content

Database systems
What are heuristic exceptions? — What does ACID mean? — What does BASE mean? — What are isolation levels? — What kind of caches are there in Hibernate ORM?
Modelling and Coding
What are anemic domain models? — What are the SOLID principles? — What code generation tools do you know? — Which ways of creating your own DSLs do you know? — Which UML diagram types do you know?
Java VM
What kind of garbage collectors are there in Java 6? — What is the generational hypothesis concerning garbage collection? — What kind of locks in the Java VM do you know? — What is the difference between a mutex and a semaphore and similiar questions? — What are the most important languages running on a Java VM? — What monitoring tools do you know?
Java EE
What are the most important technologies / specifications in Java EE 6? — What is Weld? — Which Java web frameworks do you know? — Which ways of making asynchronous calls within a Java EE 6 server do you know? — Which ways of asynchronous communication between web browsers and web servers do you know? — What are the most important performance issues in Java web applications? — What are the most important performance issues in Java EE server applications?
Distributed Computing
What are the advantages and disadvantages of ESBs? — What is the CAP theorem? — What is Terracotta used for? — What is the token bucket algorithm? — What is REST used for? What are the advantages and disadvantages? — What is Amdahls Law? What is Gustafson’s Law?
Additional topics and tools
Security — Tools — Programming models — Java libraries — Java utilities
Recommended Lectures to go further
General — Concurrency
Conclusion

Here is some answers from the questions raised in the article : Technical Job Interview Questions for Java EE architects

Most answers are quotes taken from various documentations or articles. Links are provided for further informations. Quotes will be a lot more understandable than a translation of what is in my head on this subject.

Database systems

First, i strongly encourage you to read the ebook Java Transaction design strategies available on InfoQ.

What are heuristic exceptions?

4.1.3. The two-phase XA protocol
When a transaction is about to be committed, it is the responsibility of the transaction manager to ensure that either all of it is committed, or that all of is rolled back. If only a single recoverable resource is involved in the transaction, the task of the transaction manager is simple: It just has to tell the resource to commit the changes to stable storage.

When more than one recoverable resource is involved in the transaction, management of the commit gets more complicated. Simply asking each of the recoverable resources to commit changes to stable storage is not enough to maintain the atomic property of the transaction. The reason for this is that if one recoverable resource has committed and another fails to commit, part of the transaction would be committed and the other part rolled back.

To get around this problem, the two-phase XA protocol is used. The XA protocol involves an extra prepare phase before the actual commit phase. Before asking any of the recoverable resources to commit the changes, the transaction manager asks all the recoverable resources to prepare to commit. When a recoverable resource indicates it is prepared to commit the transaction, it has ensured that it can commit the transaction. The resource is still able to rollback the transaction if necessary as well.

So the first phase consists of the transaction manager asking all the recoverable resources to prepare to commit. If any of the recoverable resources fails to prepare, the transaction will be rolled back. But if all recoverable resources indicate they were able to prepare to commit, the second phase of the XA protocol begins. This consists of the transaction manager asking all the recoverable resources to commit the transaction. Because all the recoverable resources have indicated they are prepared, this step cannot fail.

Chapter 4. Transactions on JBoss

4.1.4. Heuristic exceptions
In a distributed environment communications failures can happen. If communication between the transaction manager and a recoverable resource is not possible for an extended period of time, the recoverable resource may decide to unilaterally commit or rollback changes done in the context of a transaction. Such a decision is called a heuristic decision. It is one of the worst errors that may happen in a transaction system, as it can lead to parts of the transaction being committed while other parts are rolled back, thus violating the atomicity property of transaction and possibly leading to data integrity corruption.

Because of the dangers of heuristic exceptions, a recoverable resource that makes a heuristic decision is required to maintain all information about the decision in stable storage until the transaction manager tells it to forget about the heuristic decision. The actual data about the heuristic decision that is saved in stable storage depends on the type of recoverable resource and is not standardized. The idea is that a system manager can look at the data, and possibly edit the resource to correct any data integrity problems.

There are several different kinds of heuristic exceptions defined by the JTA. The javax.transaction.HeuristicCommitException is thrown when a recoverable resource is asked to rollback to report that a heuristic decision was made and that all relevant updates have been committed. On the opposite end is the javax.transaction.HeuristicRollbackException, which is thrown by a recoverable resource when it is asked to commit to indicate that a heuristic decision was made and that all relevant updates have been rolled back.

The javax.transaction.HeuristicMixedException is the worst heuristic exception. It is thrown to indicate that parts of the transaction were committed, while other parts were rolled back. The transaction manager throws this exception when some recoverable resources did a heuristic commit, while other recoverable resources did a heuristic rollback.

Chapter 4. Transactions on JBoss

What does ACID mean?

Atomicity: A transaction must be atomic. This means that either all the work done in the transaction must be performed, or none of it must be performed. Doing part of a transaction is not allowed.
To be compliant with the ‘A’, a system must guarantee the atomicity in each and every situation, including power failures / errors / crashes.
This guarantees that ‘an incomplete transaction’ cannot exist.

Consistency: When a transaction is completed, the system must be in a stable and consistent condition.

Isolation: Different transactions must be isolated from each other. This means that the partial work done in one transaction is not visible to other transactions until the transaction is committed, and that each process in a multi-user system can be programmed as if it was the only process accessing the system.
In other words, it should not be possible that two transactions affect the same rows run concurrently, as the outcome would be unpredicted and the system thus made unreliable.

Durability: The changes made during a transaction are made persistent when it is committed. When a transaction is committed, its changes will not be lost, even if the server crashes afterwards.
In other words, every committed transaction is protected against power loss/crash/errors and cannot be lost by the system and can thus be guaranteed to be completed.
In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently. If the database crashes right after a group of SQL statements execute, it should be possible to restore the database state to the point after the last transaction committed.

Chapter 4. Transactions on JBoss & Wikipedia

What does BASE mean?

Probably a word game from chemistry Acid-base reaction remember your pH courses…

BASE stands for Basically Available, Soft state, Eventual consistency.

Eventual consistency is one of the consistency models used in the domain of parallel programming, for example in distributed shared memory, distributed transactions, and optimistic replication, it means that given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system and all the replicas will be consistent. While some authors use that definition (e.g. Vogels), others prefer a stronger definition that requires good things to happen even in the presence of continuing updates, reconfigurations, or failures. In the Terry et al. work referenced above, eventual consistency means that for a given accepted update and a given replica, eventually, either the update reaches the replica, or the replica retires from service.
In database terminology, this is known as BASE (Basically Available, Soft state, Eventual consistency), as opposed to the database concept of ACID.

Wikipedia

What are isolation levels?

Read Uncommited: It is the lowest isolation level. It allows transactions to read non-committed updates made by other transactions prior to those updates being committed to the database.
Read Committed: It allows multiple transactions to access to the same data, but hides non-committed updates from other transactions until they are committed.
Repeatable Read: It keeps all transactions isolated from one another. It ensures that once a set of values is read from the database within a particular transaction, that same set of values will be read every time they are re-queried.
Serializable: It is the highest and most strict level of isolation. It ensures only one transaction is allowed access to the data at a time, other transactions are “stacked” until the completion of the current transaction.

Wikipedia

More details there: Postgresql 9.1 – Transaction Isolation, you should especially read about the three phenomena:

Dirty read: A transaction reads data written by a concurrent uncommitted transaction.
Nonrepeatable read: A transaction re-reads data it has previously read and finds that data has been modified by another transaction (that committed since the initial read).
Phantom read: A transaction re-executes a query returning a set of rows that satisfy a search condition and finds that the set of rows satisfying the condition has changed due to another recently-committed transaction.
Postgresql 9.1 – Transaction Isolation

What kind of caches are there in Hibernate ORM?

First level cache: Session cache
Second level cache: Cache of data that is reusable between transactions at a process or cluster level. You can even plug in a clustered cache. Be aware that caches are not aware of changes made to the persistent store by another application.. Cache provider should provide replication feature when used in cluster environement (e.g. ehCache replication).
Query cache: Query result sets can also be cached. This is only useful for queries that are run frequently with the same parameters.
C3PO statement pooling

Three must read articles:

Finally keep in mind (an underused behavior) that:

… if you are processing a huge number of objects and need to manage memory efficiently, the evict() method can be used to remove the object and its collections from the first-level cache.

… To evict all objects from the session cache, call Session.clear()
For the second-level cache, there are methods defined on SessionFactory for evicting the cached state of an instance, entire class, collection instance or entire collection role.
Managing the caches

Modelling and Coding

I strongly suggests once this part has been read, to learn also about:

What are anemic domain models?

Basically a POJO without any behavior only data.

The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters.
Martin Fowler – Anemic Domain Model

It mmust be opposed to Domain Model or DDD’s “Entity”, where DDD stands for Domain Driven Design.

What are the SOLID principles?

SOLID stands for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion.

Single Responsibility Principle: A class should have one, and only one, reason to change.
Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
Interface Segregation Principle: Make fine grained interfaces that are client specific.
Dependency Inversion Principle: Depend on abstractions, not on concretions.

Uncle Bob – The Principles of OOD

Check also the following principles:

What code generation tools do you know? Which ones did you use?

Which ways of creating your own DSLs do you know? Which ones did you use?

Fluent interface
Groovy DSL
Antlr / Code Generation
Xtext is an amazing project, it allows to quickly create a language with its corresponding Eclipse editor

Martin Fowler – DSL
Debasish Ghosh (author of DSL in action)

For advanced user who wants to create DSL, i recommend the lectures of:

Which UML diagram types do you know? What are UML stereotypes? What are UML color standards?

Depending on the organization, it is not necessary to know all about UML, just the essential diagrams and convention. For me essentials diagrams are: class diagram / sequence diagram / activity diagram.

Stereotype is an extension feature allowing to “tag” element with a special semantic e.g. an element could be tagged «Repository», «Entity», «DTO»…

A stereotype is one of three types of extensibility mechanisms in the Unified Modeling Language (UML). They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular problem domain or otherwise specialized usage.

Wikipedia

For a nice introduction and to learn what is really necessary read Martin Fowler Distilled UML 3rd Ed.

I didn’t even known UML have colors! Here is a link to them

Java VM

I must admit i had to read some articles and documentation about garbage collection to have a more precise knowledge of the terms and the type of collectors.

For a simple introduction read AZUL – Understanding GC and for a deeper understanding Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning
You might also read the The Memory Management Reference

What kind of garbage collectors are there in Java 6? What are the differences? Which ones are usually used for Java EE applications? How can you find out which garbage collector should be used for a Java EE application?

A Concurrent Collector performs garbage collection work concurrently with the application’s own execution
A Parallel Collector uses multiple CPUs to perform garbage collection
A Stop-the-World collector performs garbage collection while the application is completely stopped
An Incremental collector performs a garbage collection operation or phase as a series of smaller discrete operations with (potentially long) gaps in between
Mostly means sometimes it isn’t (usually means a different fall back mechanism exists)

Mark & Sweep // Compact // Copy:

Mark
- Start from “roots” (thread stacks, statics, etc.)
- “Paint” anything you can reach as “live”
- At the end of a mark pass:
  - all reachable objects will be marked “live”
  - all non-reachable objects will be marked “dead” (aka “non-live”)
Sweep
- Scan through the heap, identify “dead” objects and track them somehow
Compact
- Over time, heap will get “swiss cheesed”: contiguous dead space between objects may not be large enough to ﬁt new objects (aka “fragmentation”)
- Compaction moves live objects together to reclaim contiguous empty space (aka “relocate”)
- Compaction has to correct all object references to point to new object locations (aka “remap”)
- Remap scan must cover all references that could possibly point to relocated objects
Copy
- Copying collector moves all lives objects from a “from” space to a “to” space & reclaims “from” space
- At start of copy, all objects are in “from” space and all references point to “from” space.
- Start from “root” references, copy any reachable object to “to” space, correcting references as we go
- At End of copy, all objects are in “to” space, and all references point to “to” space

Available Collectors:

The serial collector uses a single thread to perform all garbage collection work, which makes it relatively efficient since there is no communication overhead between threads. It is best-suited to single processor machines, since it cannot take advantage of multiprocessor hardware, although it can be useful on multiprocessors for applications with small data sets (up to approximately 100MB). The serial collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseSerialGC.

The parallel collector (also known as the throughput collector) performs minor collections in parallel, which can significantly reduce garbage collection overhead. It is intended for applications with medium- to large-sized data sets that are run on multiprocessor or multi-threaded hardware. The parallel collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseParallelGC.
New: parallel compaction is a feature introduced in J2SE 5.0 update 6 and enhanced in Java SE 6 that allows the parallel collector to perform major collections in parallel. Without parallel compaction, major collections are performed using a single thread, which can significantly limit scalability. Parallel compaction is enabled by adding the option -XX:+UseParallelOldGC to the command line.

The concurrent collector performs most of its work concurrently (i.e., while the application is still running) to keep garbage collection pauses short. It is designed for applications with medium- to large-sized data sets for which response time is more important than overall throughput, since the techniques used to minimize pauses can reduce application performance. The concurrent collector is enabled with the option -XX:+UseConcMarkSweepGC.

Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning

Selecting a Collector:

Unless your application has rather strict pause time requirements, first run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance. If the performance still does not meet your goals, then use the following guidelines as a starting point for selecting a collector.

If the application has a small data set (up to approximately 100MB), then select the serial collector with -XX:+UseSerialGC.

If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector, or select the serial collector with -XX:+UseSerialGC.

If (a) peak application performance is the first priority and (b) there are no pause time requirements or pauses of one second or longer are acceptable, then let the VM select the collector, or select the parallel collector with -XX:+UseParallelGC and (optionally) enable parallel compaction with -XX:+UseParallelOldGC.

If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately one second, then
select the concurrent collector with -XX:+UseConcMarkSweepGC. If only one or two processors are available, consider using incremental mode, described below.

Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning

More informations there: Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning

What is the generational hypothesis concerning garbage collection?

A generation is a set of objects which have similar expected lifetimes.
Objects are gathered together in generations.
The heap is divided into generations so that it is possible to eliminate most of the garbage by looking at only a small fraction of the heap.
The collector can promote objects into older generations as they survive successive collection cycles.
New objects are usually allocated in the youngest or nursery generation, but if we know that particular objects will be long-lived, we might want to allocate them directly in an older generation.
Objects within a generation are all roughly the same age.
Higher-numbered generations indicate areas of the heap with older objects—those objects are much more likely to be stable.
Objects in older generations are condemned less frequently, saving CPU time.

Generational Hypothesis: most objects die young
Focus collection efforts on young generation
Generally based on a copy collector

… memory is managed in generations, or memory pools holding objects of different ages. Garbage collection occurs in each generation when the generation fills up. The vast majority of objects are allocated in a pool dedicated to young objects (the young generation), and most objects die there. When the young generation fills up it causes a minor collection in which only the young generation is collected; garbage in other generations is not reclaimed. Minor collections can be optimized assuming the weak generational hypothesis holds and most objects in the young generation are garbage and can be reclaimed. The costs of such collections are, to the first order, proportional to the number of live objects being collected; a young generation full of dead objects is collected very quickly. Typically some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection. Eventually, the tenured generation will fill up and must be collected, resulting in a major collection, in which the entire heap is collected. Major collections usually last much longer than minor collections because a significantly larger number of objects are involved.
Java SE 6 HotSpot™ Virtual Machine Garbage Collection Tuning

What kind of locks in the Java VM do you know?

synchronized keyword
ReentrantLock
ReadWriteLock
CyclicBarrier
CountDownLatch
Semaphore
All kind of BlockingQueue could also be used as lock in a certain manner…

Check for more information in the corresponding packages: java.util.concurrent package and java.util.concurrent.locks package .

Concurency AND Parallelism should be high topic with today multi-core systems, i strongly recommend to have a look at the followings:

What is the difference between a mutex and a semaphore and similiar questions?

Mutexes and semaphores are very similar, with the only significant difference being that semaphores can count higher than one.

Lock can be viewed as a Mutex implementation in java, and more specifically ReentrantLock. Whereas only the “Write lock” of the ReadWriteLock is a mutex.

Mutexes are typically used to serialise access to a section of re-entrant code that cannot be executed concurrently by more than one thread. A mutex object only allows one thread into a controlled section, forcing other threads which attempt to gain access to that section to wait until the first thread has exited from that section.

Symbian Developer Library

A semaphore restricts the number of simultaneous users of a shared resource up to a maximum number. Threads can request access to the resource (decrementing the semaphore), and can signal that they have finished using the resource (incrementing the semaphore).

Symbian Developer Library

Conceptually, a semaphore maintains a set of permits. Each acquire() blocks if necessary until a permit is available, and then takes it. Each release() adds a permit, potentially releasing a blocking acquirer.

Semaphore JDK API

A nice story to explain the difference The Toilet Example

What are the most important languages running on a Java VM? Which ones did you use? What are their advantages and disadvantages?

Groovy: for scripting purpose and some Grails simple applications.
Mvel: simple expression language similar to OGNL but a lot faster
Scala for personnal use only, love the compacity, expressiveness and scalability of the language such as the actor stack added by “Akka”. It mixes both procedural and functionnal approach, and allow a switch for one approach to another smoothly. I really think it can replace Java as the mainstream JVM language, evolution are less tied to the JVM version. Developper is free to choose the scala version he wants to use, simply compile and drop the corresponding jars. Dislike the ASCII art that emerge for some “elite coders”.
Clojure: never used it, but i should really take a look at it. At least for a better knowledge and way of thinking of “lisp”-like language.
Ruby through JRuby really interesting approach of meta-programming and flexibility. Really easy for day-to-day programming and utilities (see Everyday Scripting with Ruby: for Teams, Testers, and You). Ever body should take a look at least one day to Rails
Python through Jython a single try through the scripting of Grinder a java load testing framework. I still prefer ruby to python.
Javascript through Rhino. Javascript is an important language nowadays and shouldn’t be neglected anymore. NodeJS offers a great playground to learn and use javascript without the browser approach. Whereas it is essential in web front end, it also offers a nice scripting environement for server side scripting.

See a more complete list of available JVM languages here.

Note also that two big new languages have appeared recently:

kotlin by JetBrains
ceylon by Red Hat

I strongly recommend every programmer to read the Seven languages in seven weeks book.

What monitoring tools do you know? Which ones did you use in production?

JMX in production too
VisualVM
Log file analysis // Addition of probes in Code manually or through AOP: in production too
JProfiler

Java EE

I am not fan of the ‘EE’ and ‘application server’ approach, and really prefer lightweight approach such as spring and web server like tomcat

Furthermore alternate approach such as Play! is rising and allow really more flexibility, emergent design and up-to-date techniques.

Remember the “KISS” principle above.

… the biggest problem is the complexity of IT. If you look at any IT in business, it is so complex it hinders the ability to be agile and efficient. Throughout the history of IT we all have said that we will make it simpler by adding more things to it, but that makes it more and more complex.
IT departments spend 75% to 85% of their budgets just to keep existing IT environments running; that leaves little capacity for innovation

(…)

What’s the biggest technology mistake you ever made – either at work or in your own life?
When I was at IBM, I started a product called Websphere [which helps companies to operate and integrate business applications across multiple computing platforms].
Because I had come from working on big mission-critical systems, I thought it needs to be scalable, reliable, have a single point of control … I tried to build something like a mainframe, a system that was capable of doing anything, that would be able to do what might be needed in five years.
I call it the endgame fallacy. It was too complex for people to master. I overdesigned it.
Because we were IBM, we survived it, but if we’d been a start-up, we’d have gone to the wall.
The mantra of CA Technologies’ Donald Ferguson: Simplify

What are the most important technologies / specifications in Java EE 6?

Servlet 3.0 and annotation based configuration
- Asynchronous processing support
CDI think of Guice or Spring IOC
JPA think of Hibernate as standard implementation

Java EE 6 – Overview

What is Weld?

Weld is the reference implementation (RI) for JSR-299 : Java Contexts and Dependency Injection for the Java EE platform (CDI). CDI is the Java standard for dependency injection and contextual lifecycle management, led by Gavin King for Red Hat, Inc. and is a Java Community Process (JCP) specification that integrates cleanly with the Java EE platform. Any Java EE 6-compliant application server provides support for JSR-299 (even the web profile).

Weld Home

Think of it as an embedded “Spring IOC”.

Which Java web frameworks do you know? What are their advantages and disadvantages?

Struts 1 & 2
Spring MVC
GWT
Grails
JSF / Tapestry / Stripes / Wicket : heard of them only

Which ways of making asynchronous calls within a Java EE 6 server do you know?

Only read about it: Asynchronous processing support.

Which ways of asynchronous communication between web browsers and web servers do you know?

What are the most important performance issues in Java web applications?

I don’t think main issues are Java related, but are Web related.

Browser still in HTTP 1.0
Page loading time / Response time
Javascript poor performance on some browser
Almost no asynchronous feedback for processing: usually blocking call only

A really powerfull tool to measure such issues: Page Speed, the Web Performance Tool and Apache module

Read some of them here Top 8 Performance Problems on Top 50 Retail Sites before Black Friday and here Top 10 Client-Side Performance Problems in Web 2.0

What are the most important performance issues in Java EE server applications?

humm… same as above i guess

The usage of Websphere may also a notable performance issue…

Distributed Computing

I strongly recommend the read of the following articles NOSQL Patterns and Scalable System Design Patterns in order to grab all the required keywords and basis of distributed database and scalability.

It would also be a good idea to have a general knowledge of Event Driven Architecture (a really interesting article with many links Event Driven Architecture: Publishing Events using an IOC container) and Message-oriented middleware (pick at least one of AMQP or XMPP, i would suggest to not spend so much time on JMS since it is strongly tied to java platform).

SOA 2.0 event-driven programming is structured around the concept of decoupled relationships between event producers and event consumers: an event consumer doesn’t care where or why an event occurs; rather, it’s concerned that it will be invoked when the event has occurred. Systems and applications that separate event producers from event consumers typically rely on an event dispatcher, or channel. This channel contains an event queue that acts as an intermediary between event producers and event handlers.
Wikipedia – Event-driven SOA

Finally have a look at “Enterprise Integration Patterns” site and read the book!

Presentation on the subject (i’ve not seen it yet) Messaging for Modern Applications.

What are the advantages and disadvantages of ESBs? Which ESBs do you know? Which ones did you use?

I’ve never used one of them, and i only know the theory around. Enterprise Service Bus is a great book on such subject.

Have a look to the following article for an introduction of their usage:

Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 1
Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 2
Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 3

What is the CAP theorem? (Now that’s quite important)

CAP theorem is becomming known due to the increase hype around NoSQL database.

the CAP theorem, also known as Brewer’s theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:
* Consistency (all nodes see the same data at the same time)
* Availability (a guarantee that every request receives a response about whether it was successful or failed)
* Partition tolerance (the system continues to operate despite arbitrary message loss)
According to the theorem, a distributed system can satisfy any two of these guarantees at the same time, but not all three.
Wikipedia

What is Terracotta used for?

Distributed VM with shared memory through datagraph of objects.

Terracota

I recommend to have a look to it when it is required to have really big JVM. But don’t forget that hidding the underlying distributed infrastructure may have some bad drawbacks afterwards. I usually prefer to be aware that i’m acting on a local object or a remote one.

What is the token bucket algorithm?

Humm… never heard about it. Let’s do some research.

The token bucket is an algorithm used in packet switched computer networks and telecommunications networks to check that data transmissions conform to defined limits on bandwidth and burstiness
Wikipedia

… ok… may be not really Software but more Network consideration.

Let’s continue:

The algorithm can be conceptually understood as follows:
A token is added to the bucket every 1 / r seconds.
The bucket can hold at the most b tokens. If a token arrives when the bucket is full, it is discarded.
When a packet (network layer PDU) of n bytes arrives, n tokens are removed from the bucket, and the packet is sent to the network.
If fewer than n tokens are available, no tokens are removed from the bucket, and the packet is considered to be non-conformant.
Wikipedia

Essentially, token bucket algorithms are metering engines that keep track of how much traffic can be sent to conform to the specified traffic rates. A token permits the algorithm to send a single bit (or, in some cases, a byte) of traffic. These tokens are granted at the beginning of some time increment, typically every second, according to the specified rate referred to as the committed information rate (CIR). The CIR is the access bit rate contracted with a service provider or the service level to be maintained.
For example, if the CIR is set to 8000 bps, then 8000 tokens are placed in a “bucket” at the beginning of the time period. (Note that this description represents a simplified view of the algorithm and might not be strictly true in all cases, but it illustrates the general operation of the policing mechanism.)
Each time a bit of traffic is offered to the policer, the bucket is checked for tokens. If there are tokens in the bucket, the traffic is passed. One token is removed from the bucket for each bit of traffic that is passed. Therefore, traffic is viewed to conform the rate, and the specified action for conforming traffic is taken. (Typically, the conforming traffic is transmitted.) When the bucket runs out of tokens, any additional offered traffic is viewed to exceed the rate, and the exceed action is taken. (The exceeding traffic typically either is re-marked or is dropped.)
End-to-End QoS Network Design – Safari book

Single Token Bucket Algorithm

What is REST used for? What are the advantages and disadvantages?

REST is a so big subject, it would be hard to explain fully here. I strongly recommend to read the book Restful Web Services

An really nice introduction here : How I Explained REST to My Wife
A more technological approach there RESTful Web services: The basics

Some of the main ideas behind REST:

Rely on and exploit HTTP protocol
use already known HTTP methods
- GET or HEAD to query data or part of it
- POST to modify data
- PUT to create data
- DELETE to … delete data
Use HTTP parameters, URL or body to provides the required parameters for the wanted action to be executed. For example a GET with http://somewh.ere/person/24 to retrieve the data relative to the person with id 24, HTTP headers could contains required credentials for example.
- There is no predefined protocol except HTTP to transmit data, it is up to the application to define it as opposed to SOAP. Usually xml or json is used.
All actions should be stateless: no client context is being stored on the server between requests, all requests should be self-sufficient to execute

Whenever data is returned, it is nice to retrieve the url to access to linked data as opposed to its raw id. So that the entry points are not predefined. For example:

{
  	"type": "person",
  	"uuid": "550e8400-e29b-41d4-a716-446655440000",
  	"first_name": "Sherlock",
  	"last_name": "Holmes",
  	"organisation": "http://somewh.ere/organisation/550e8400-f34d-41d4-a716-876543211234"
  }

What is Amdahls Law? What is Gustafson’s Law?

For the past 30 years, computer performance has been driven by Moore’s Law; from now on, it will be driven by Amdahl’s Law. Writing code that effectively exploits multiple processors can be very challenging.
Doron Rajwan – Research Scientist, Intel Corp

The speedup of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program. For example, if a program needs 20 hours using a single processor core, and a particular portion of 1 hour cannot be parallelized, while the remaining promising portion of 19 hours (95%) can be parallelized, then regardless of how many processors we devote to a parallelized execution of this program, the minimum execution time cannot be less than that critical 1 hour.
Amdahl’s law

Gustafson’s Law (…) says that problems with large, repetitive data sets can be efficiently parallelized. Gustafson’s Law contradicts Amdahl’s law, which describes a limit on the speed-up that parallelization can provide.
Gustafson’s Law

[Added] Additional topics and tools

Here is some additional topics that should require some attention and personal interests

Security

Tools

Version control system: ~~CVS~~ / SVN / GIT …

Programming models

Map Reduce and Introduction to Parallel Programming and MapReduce
Software Transactional Memory
Actor (see Akka or Erlang process)

Java libraries

Hadoop: The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage.
Lucene: Apache Lucene™ is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform.
Mahout The Apache Mahout™ machine learning library’s goal is to build scalable machine learning libraries.
Camel: Apache Camel is a powerful open source integration framework based on known Enterprise Integration Patterns with powerful Bean Integration.

Java utilities

Guava: Google Core Libraries: The Guava project contains several of Google’s core libraries that we rely on in our Java-based projects: collections, caching, primitives support, concurrency libraries, common annotations, string processing, I/O, and so forth.
Joda Time: Joda-Time provides a quality replacement for the Java date and time classes.
Mockito: simpler & better mocking
PowerMock: Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to good design, but this is not always the case. For example final classes and methods cannot be used, private methods sometimes need to be protected or unnecessarily moved to a collaborator, static methods should be avoided completely and so on simply because of the limitations of existing frameworks.
JBehave: Behaviour-driven development in Java…
Selenium Webdriver: WebDriver is a tool for automating testing web applications, and in particular to verify that they work as expected.

[Added] Recommended Lectures to go further

General

Patterns of Enterprise Application Architecture The main topic areas are: how to layer an enterprise application, how to organize domain logic, how to tie that logic to a relational database, how to design a web based presentation, some important principles in distributed design, and handling of what we call “offline concurrency” – concurrency that spans transactions.
Enterprise Integration Patterns The book Enterprise Integration Patterns provides a consistent vocabulary and visual notation to describe large-scale integration solutions across many implementation technologies. It also explores in detail the advantages and limitations of asynchronous messaging architectures. You will learn how to design code that connects an application to a messaging system, how to route messages to the proper destination and how to monitor the health of a messaging system.
Camel in Action Camel lets you create the Enterprise Integration Patterns to implement routing and mediation rules in either a Java based Domain Specific Language (or Fluent API), via Spring or Blueprint based Xml Configuration files or via the Scala DSL. This means you get smart completion of routing rules in your IDE whether in your Java, Scala or XML editor.
Domain-Driven Design: Tackling Complexity in the Heart of Software It provides a broad framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with the author’s own insights and experiences. Projects facing complex domains can use this framework to approach domain-driven design systematically.
Enterprise Service Bus Enterprise Service Bus offers a thorough introduction and overview for systems architects, system integrators, technical project leads, and CTO/CIO level managers who need to understand, assess, and evaluate this new approach.
Event Centric: Finding Simplicity in Complex Systems (coming soon)
Microsoft Application Architecture Guide, 2nd Edition The guide provides an overview of the underlying principles and patterns that provide a solid foundation for good application architecture and design. On top of this foundation, the guide provides generally applicable guidance for partitioning an application’s functionality into layers, components, and services. It goes on to provide guidance on identifying and addressing the key design characteristics of the solution and the key quality attributes (such as performance, security, and scalability) and crosscutting concerns (such as caching and logging)
And finally have a look to the site part of 97 Things Every Software Architect Should Know

Concurrency

Java Concurrency in Practice This book covers a very deep and subtle topic in a very clear and concise way, making it the perfect Java Concurrency reference manual. Each page is filled with the problems (and solutions!) that programmers struggle with every day.— Cliff Click
Programming Erlang: Software for a Concurrent World Learn how to write truly concurrent programs—programs that run on dozens or even hundreds of local and remote processors. See how to write high reliability applications—even in the face of network and hardware failure—using the Erlang programming language.
Seven languages in seven weeks You should learn a programming language every year, as recommended by The Pragmatic Programmer. But if one per year is good, how about Seven Languages in Seven Weeks? In this book you’ll get a hands-on tour of Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Whether or not your favorite language is on that list, you’ll broaden your perspective of programming by examining these languages side-by-side.

[Added] Conclusion

Whenever you want to claim yourself as an architect, be aware that you never know enough. Technologies, patterns, frameworks and even paradigms are living creatures, that born, grow, change and some times died replaced by new ones or killed by their children. You can’t stay with what you learnt, you have to train and discover every times. It is quite hard to be efficient on all technics, the most important is to know they exists, and to know how to learn about when necessary.

I would personnally change most of these questions by

have you heard about … do you know how to learn about it … what are the usecases ?
how do you stay tuned to industry and computer science change? what kind of blogs are you reading?

Furthermore, a broader attention must be paid to the fact that you can’t work anymore with a unique technology such as Java. Polyglot programming (a five years old article) is becommig more and more present, Martin Fowler even speaks about Polyglot Persistence
I personnally think it is more efficient to know about AMQP than JMS. If you have an architecture big enough to have a distributed computing infrastructure, maybe you’ll have a better software experience with MapReduce or NoSQL database. Maybe it would be more efficient to have a ruby frontend with a scala backend linked to a cluster through RabbitMQ…

Architect in Java is not enough!

The good intention of the article (Technical Job Interview Questions for Java EE architects), or at least the goal it achieved, is not to define the right questions for an interview, but it gives a general overview of the points an architect may have to deal with. It can also be viewed as a check list: what else should i learn ? All questions does not require the right response to be a good architect, it all depends on the application you are working on or the team you are part of, and knowing that those things exist are usually enough.
It is a good opportunity to learn or re-adjust your knowledge, that what i felt writing this article.

And the final quote:

As a Scrum Master, my struggle with architects is that they often want to slow things down to “do it right” which inhibits releasing early and often.

InfoQ comment trust?

Last minute link: have a look at the presentation Architects? We Don’t Need No Stinkin’ Architects!

Ancien blob et anciens messages

2011-12-01T00:00:00+00:00

Le nouvel hébergement de ce blog s’accompagnera d’une migration de certains seulement de mes anciens messages. Pour les autres je vous invite à retourner là: Ancien blog

Jekyll - Le site web des développeurs

2011-11-30T00:00:00+00:00

Jekyll est un générateur de pages statiques particulièrement adapté aux développeurs. Il permet de générer un site complet à partir de pages statiques ou de post, et de le publier. Développé par un des cofondateurs de Github, il est même directement intégré à Github. Il est donc possible de stocker, versionner, travailler ses articles ou ses pages statiques, et de les publier automatiquement sur un simple commit.

Envie de travailler sur un article: hop une branche dédiée et l’article n’apparaitra pas tant qu’il ne sera pas transféré sur le master. Pas besoin d’une connection internet pour travailler sur son article, pas d’interface utilisateur scabreuse (ou de pseudo éditeur html) pour éditer le contenu: vous utilisez l’éditeur de texte que vous voulez. Envie de rajouter une feuille de style ou une image, plus besoin d’aller dans les entrailles des templates et de trouver une enième façon de les herberger (bon ok ça à bien changé depuis ;)), tout est au même endroit: dans votre repository Github.

Une vraie infrastructure de développeur et de déploiement continu simplement: pas de base de données, pas de paramètres compliqués, une écriture simplifiée par des syntaxes adaptées: markdown, textile ou même html… De plus, moyennant quelques options, l’intégration d’extrait de code dans les articles se fait naturellement et la coloration syntaxique automatiquement. Stocké par Github, généré par Github et publié par Github! Et vous n’êtes pas encore inscrit au fan club Github !?!

Du Ruby:

# Public: Duplicate some text an abitrary number of times.
#
# text  - The String to be duplicated.
# count - The Integer number of times to duplicate the text.
#
# Returns the duplicated String.
def multiplex(text, count)
  text * count
end

Du scala:

abstract class Tree
  case class Branch(left: Tree, right: Tree) extends Tree
  case class Leaf(x: Int) extends Tree

  def sumLeaves(t: Tree): Int = t match {
    case Branch(l, r) => sumLeaves(l) + sumLeaves(r)
    case Leaf(x) => x
  }
}

Voila, c’est tout ça qui m’aura définitivement fait basculer. Au revoir tumblr, bonjour github et merci Tom Preston-Werner

PS.: Premiers pas, premiers déboires! voir Issue#422 pour des problèmes de traitements lors de la coloration syntaxique (Liquid error: undefined method `join’ for #).

Voir aussi:

Passer de wordpress jekyll premiere-partie et deuxième partie
Jekyll Github Page
Jekyll a static site generator
Creating Excerpts in Jekyll with Wordpress-style <!—more—> HTML Comments

[T|B|D]DD par la pratique ou la decouverte de NodeJS

2011-10-19T00:00:00+00:00

Après reflexion, la série aurait tout aussi bien pu s'appeller:

"Découverte de NodeJS et de CQRS dirigée par [T|B|D]DD"

"Développement d'une application NodeJS de A à Z selon une approche CQRS"

[T|B|D]DD par la pratique 3 - AggregateRoot

2011-10-18T00:00:00+00:00

Echauffement

Un peu de refactoring pour s'échauffer. Au lieu de définir tout notre domaine dans le fichier domain.js, associons chaque élément de notre domaine à un fichier spécifique:

le fichier lib/domain.js est alors renomé en lib.project.js
la fonction create_project en create puisque le fichier sera dédié à notre classe projet

Les corrections à apporter sont alors les suivantes dans les fichiers specs/project_specs.js et test/project_test.js :

modifier var domain = require('../lib/domain') par var prj = require('../lib/project')
et tous les appels de méthode domain.create_project par prj.create

Relançons les tests, et oh miracle ils passent tous.

Renommer un projet

Afin de completer un peu notre projet ajoutons une méthode rename afin de pouvoir modifier le nom de notre projet. On peux remarquer que l'intention est bien de renomer le projet et non pas de définir son nom comme pourrait l'indiquer un 'setter' standard du type set_name.

Successivement nous:

ajoutons le test suivant (test/project_test.js)

exports["renaming a project must change its name according to new one"] = function (test) {
    var project = prj.create("mccallum");
    project.rename("travis");
    test.equal(project.name(), "travis");
    test.done();
};

vérifions que notre test échoue à cause de l'absence de la méthode rename
ajoutons ensuite la méthode rename sur notre project (lib/project.js)

// public method
Project.prototype = {
    ...
    rename: function(new_name) {
        this._name = new_name;
    }
};

ajoutons le test indiquant que le changement de nom doit entrainer la création d'un nouvel évènement (test/project_test.js)

exports["renaming a project must add an `event` in its history of type 'project_renamed'"] = function (test) {
    var project = prj.create("mccallum");
    project.rename("travis");

    var events = project.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 2);
    test.equal(events[0].event_type(), "project_created");
    test.equal(events[1].event_type(), "project_renamed");
    test.done();
};

vérifions que notre test échoue
modifions finalement la méthode rename pour générer un nouvel évènement et sa gestion dans la méthode apply (lib/project.js)

var to_f = function(value) { 
    return function () { 
        return value; 
    }
};
...
var ProjectRenamed = function(project_id, new_project_name) {
    // wrapping functions to make values *immutables*
    this.event_type       = to_f("project_renamed");
    this.new_project_name = to_f(new_project_name);
    this.project_id       = to_f(project_id);
};
...
// public method
Project.prototype = {
    name : function () { return this._name; },
    uuid : function () { return this._uuid; },
    events: function () { return this._events; },
    apply: function (event) {
        switch(event.event_type()) {
            case "project_created" :
                this._name = event.project_name();
                this._uuid = event.project_id();
                break;
            case "project_renamed" :
                this._name = event.new_project_name();
                break;
            default:
                throw new Error("Unknown event type: " + event.event_type());
        }

        // still there means, the event was correctly handled, thus keep it!
        if(typeof this._events === 'undefined') {
            this._events = [];
        }
        this._events[this._events.length] = event;
    },
    rename: function(new_name) {
        this.apply(new ProjectRenamed(this._uuid, new_name));   
    }
};

Projet et Event Sourcing: le phoenix!

Bon, nous avons désormais deux types d'évènements différents. Interessons-nous à la reconstruction d'un projet à partir de ses évènements, rappellez-vous l'Event sourcing! Faire renaître un projet de ses cendres euh... de son historique!

Exportons les classes de nos deux évènements afin qu'elles soient disponibles depuis les autres modules.

lib/project.js

exports.ProjectCreated = ProjectCreated;
exports.ProjectRenamed = ProjectRenamed;

Le test correspondant à la relecture peut alors s'écrire:

test/project_test.js

exports["a project can be reload from a simple history"] = function (test) {
    var project_id = uuid();
    var history = [ 
        new prj.ProjectCreated(project_id, "mccallum"),
        new prj.ProjectRenamed(project_id, "travis")
    ];
    var project = prj.load_from_history(history);

    test.equal(project.name(), "travis");
    test.equal(project.uuid(), project_id);
    test.done();
};

Rajoutons progressivement la méthode load_from_history sur notre module et sur notre classe Projet. La méthode sur notre module servira de méthode de construction factory method, dans un premier temps, pour créer un projet à partir de son historique. Nous obtenons alors:

lib/project.js

// public method
Project.prototype = {
    ...
    load_from_history: function(events) {
        var $this = this;
        events.forEach(function(event) {
            $this.apply(event);
        });
    },
    ...
};

...

exports.load_from_history = function(events) {
    var project = new Project();
    project.load_from_history(events);
    return project;
};

Un coup d'oeil sur notre console, et hop tout le monde est vert, c'est pas géant ça?

Le code complet de lib/project.js est à ce stade:

lib/project.js

var uuid = require('node-uuid');

var to_f = function(value) { 
    return function () { 
        return value; 
    };
};

/**
 *  Events
 */
var ProjectCreated = function(project_id, project_name) {
    // wrapping functions to make values *immutables*
    this.event_type   = to_f("project_created");
    this.project_name = to_f(project_name);
    this.project_id   = to_f(project_id);
};

exports.ProjectCreated = ProjectCreated;

var ProjectRenamed = function(project_id, new_project_name) {
    // wrapping functions to make values *immutables*
    this.event_type       = to_f("project_renamed");
    this.new_project_name = to_f(new_project_name);
    this.project_id       = to_f(project_id);
};

exports.ProjectRenamed = ProjectRenamed;

/**
 *  Project
 */
var Project = function(project_id, project_name) {
    this.apply(new ProjectCreated(project_id, project_name));
};

// public method
Project.prototype = {
    name : function () { return this._name; },
    uuid : function () { return this._uuid; },
    events: function () { return this._events; },
    apply: function (event) {
        switch(event.event_type()) {
            case "project_created" :
                this._name = event.project_name();
                this._uuid = event.project_id();
                break;
            case "project_renamed" :
                this._name = event.new_project_name();
                break;
            default:
                throw new Error("Unknown event type: " + event.event_type());
        }

        // still there means, the event was correctly handled, thus keep it!
        if(typeof this._events === 'undefined') {
            this._events = [];
        }
        this._events[this._events.length] = event;
    },
    load_from_history: function(events) {
        var $this = this;
        events.forEach(function(event) {
            $this.apply(event);
        });
    },
    rename: function(new_name) {
        this.apply(new ProjectRenamed(this._uuid, new_name));   
    }
};

exports.create = function(project_name) {
    return new Project(uuid(), project_name);
};

exports.load_from_history = function(events) {
    var project = new Project();
    project.load_from_history(events);
    return project;
};

exports.Project = Project;

Un peu de technique dans un monde de brutes!

Si l'on devait effectuer le même travail sur une autre entité de notre domaine - comme un User (qui décrit un utilisateur de notre application: un developer, un scrum master ou encore un product owner) ou une Story - on peux constater la redondance de code dans la gestion des évènements et de l'identifiant.

Nous allons donc nous interesser à généraliser ce code dans une classe (que l'on manipulera comme un trait ou mixin compte-tenu de l'aspect dynamique du javascript) dédiée que l'on pourra étendre ensuite afin de bénéficier de cette infrastructure technique.

En regardant le code de gestion de l'évènement (méthode apply), on voit aussi que notre switch risque de rapidement devenir in-maintenable et illisible. Commençons donc par utiliser l'aspect dynamique de javascript pour retrouver une méthode succeptible de pouvoir gérer un évènement en fonction de son type.

Après quelques tatonements (voir les méthodes apply et call de javascript ici et comment le this est une notion particulière en javascript!) et les tests aux verts, voici les changements que nous avons faits:

notre méthode apply a été renommé en apply_event pour éviter toute confusion avec la méthode apply de javascript.
la fonction capable de gérer un évènement est récupérer à partir de son type via un tableau de fonction dont la clé de chaque élément correspondont aux types d'évènements:
var handler = this.event_handlers["on_"+event.event_type()];
le tableau des fonctions est définit comme suit:

event_handlers : {
        on_project_created: function(event) {
            this._name = event.project_name();
            this._uuid = event.project_id();
        },
        on_project_renamed: function(event) {
            this._name = event.new_project_name();
        }
    },

la fonction ainsi récupérée est alors invoquée via la fonction call de javascript:
handler.call(this, event); le this passé en paramètre de la fonction correspond à notre instance de projet, et sera ainsi vu comme le this dans l'éxecution de la fonction.

Tout ceci nous amène finalement à:

/**
 *  Project
 */
var Project = function(project_id, project_name) {
    this.apply_event(new ProjectCreated(project_id, project_name));
};

// public method
Project.prototype = {
    event_handlers : {
        on_project_created: function(event) {
            this._name = event.project_name();
            this._uuid = event.project_id();
        },
        on_project_renamed: function(event) {
            this._name = event.new_project_name();
        }
    },
    name  : function () { return this._name; },
    uuid  : function () { return this._uuid; },
    events: function () { return this._events; },
    apply_event : function (event) {
        var handler = this.event_handlers["on_"+event.event_type()];
        if(typeof handler === 'undefined') {
            throw new Error("Unknown event type: <" + event.event_type() + ">");
        }
        handler.call(this, event);
        
        // still there means, the event was correctly handled, thus keep it!
        if(typeof this._events === 'undefined') {
            this._events = [];
        }
        this._events[this._events.length] = event;
    },
    load_from_history: function(events) {
        var $this = this;
        events.forEach(function(event) {
            $this.applyEvent(event);
        });
    },
    rename: function(new_name) {
        this.apply_event(new ProjectRenamed(this._uuid, new_name));  
    }
};

Nos fonctions uuid, events, apply_event et load_from_history ne sont finalement plus liées au côté fonctionnel du Projet et n'ont aucune dépendance vers celui-ci. Déplaçons les dans une nouvelle classe que nous appellerons AggregateRoot.

dans lib/aggregate_root.js

/**
 *  Aggregate Root
 */
function AggregateRoot() {}
exports.AggregateRoot = AggregateRoot;

// public method
AggregateRoot.prototype = {
    event_handlers : {},
    uuid  : function () { return this._uuid; },
    events: function () { return this._events; },
    apply_event : function (event) {
        var handler = this.event_handlers["on_"+event.event_type()];
        if(typeof handler === 'undefined') {
            throw new Error("Unknown event type: <" + event.event_type() + ">");
        }
        handler.call(this, event);

        // still there means, the event was correctly handled, thus keep it!
        if(typeof this._events === 'undefined') {
            this._events = [];
        }
        this._events[this._events.length] = event;
    },
    load_from_history: function(events) {
        var $this = this;
        events.forEach(function(event) {
            $this.apply_event(event);
        });
    }
};

Un petit tour sur la documentation de nodeJS et nous trouvons notre fonction magique: inherits. Après de nombreuses maladresses et d'erreur de javascript, notre classe Project a bien changé.

Tout d'abord, voyons les erreurs de javacript que nous trainons depuis le début. En écrivant: Project.prototype = { ... } on ne fait pas que rajouter des comportements à notre classe Project mais on remplace carrément son prototype, ce qui n'est pas problèmatique au premier abord. En revanche, dès que l'on fait hériter notre classe Projet de AggregateRoot require('util').inherits(Project, aroot.AggregateRoot); en redefinissant notre prototype on perd tout ce que notre héritage avait ajouté. Nous choisissons donc de definir nos méthodes publiques une par une et non plus dans un bloc objet.

Nous avons pas mal galérer à importer notre nouveau module aggregate_root situé pourtant dans le même dossier que notre module projet.js. Il suffisait simplement d'écrire require("./aggregate_root") au lieu de require("aggregate_root"), cette dernière écriture est, semble-t-il, réservée aux modules "externes" de notre application.

Enfin, en regardant le code de notre classe Project on constate que nous avons deux constructeurs, à deux endroits différents de notre code. Nous simplifions donc en un unique constructeur (vide) et déléguons à notre méthode create le soin de générer l'appel initial requis.

Enfin, nous enlevons nos commentaires farfelu // wrapping functions to make values *immutables* puisque il est toujours possible en javascript de redefinir la fonction. Il n'est donc, à ma connaissance pas possible de figer l'état d'un objet.

Au final, notre nouvel classe Projet devient:

var uuid  = require('node-uuid'),
    aroot = require('./aggregate_root'),
    nutil = require('util');

var to_f = function(value) { 
    return function () { 
        return value; 
    };
};

/**
 *  Events
 */
var ProjectCreated = function(project_id, project_name) {
    this.event_type   = to_f("project_created");
    this.project_name = to_f(project_name);
    this.project_id   = to_f(project_id);
};

exports.ProjectCreated = ProjectCreated;

var ProjectRenamed = function(project_id, new_project_name) {
    this.event_type       = to_f("project_renamed");
    this.new_project_name = to_f(new_project_name);
    this.project_id       = to_f(project_id);
};

exports.ProjectRenamed = ProjectRenamed;

/**
 *  Project
 */
function Project() {}
nutil.inherits(Project, aroot.AggregateRoot);

exports.Project = Project;

// public methods
Project.prototype.event_handlers = {
    on_project_created: function(event) {
        this._name = event.project_name();
        this._uuid = event.project_id();
    },
    on_project_renamed: function(event) {
        this._name = event.new_project_name();
    }
};
Project.prototype.name = function () { 
    return this._name;
};
Project.prototype.rename = function(new_name) {
    this.apply_event(new ProjectRenamed(this._uuid, new_name)); 
};

exports.create = function(project_name) {
    var project = new Project();
    project.apply_event(new ProjectCreated(uuid(), project_name));
    return project;
};

exports.load_from_history = function(events) {
    var project = new Project();
    project.load_from_history(events);
    return project;
};

Un petit tour sur notre console, et nos tests sont toujours verts. Notre classe Project s'est bien allégée et ne contient pratiquement plus que le code fonctionnel de notre entité.

La déclaration des méthodes nous paraissant désormais un peu verbeuse, nous décidons de notre créer un petit utilitaire afin de revenir à une syntaxe un plus compact.

Retour aux tests! test/utilities_test.js

var utilities = require("../lib/utilities");

exports["mixin provides a simple way to declare methods"] = function (test) {
    // defines a basic class with a single method 'value()''
    function Data(value) {}
    Data.prototype.value = function () { 
        return this._value; 
    };
    
    // defines the methods, one want to plug into our class
    var methods = {
        name : function () {
            return this._name;
        }
    };
    
    // add new methods & property
    utilities.mixin(Data.prototype, methods);
    
    var data = new Data();
    data._name  = "mccallum";
    data._value = 17;
    test.equal(data.value(), 17); // make sure original method is still there
    test.equal(data.name(), "mccallum");
    test.done();
};

exports["mixin provides a simple way to add properties"] = function (test) {
    // defines a basic class with a single method 'value()''
    function Data(value) {}
    Data.prototype.value = function () { 
        return this._value; 
    };
    
    // defines the methods, one want to plug into our class
    var methods = {
        uuid : "cafebabe-3550-1i3105"
    };
    
    // add new methods & property
    utilities.mixin(Data.prototype, methods);
    
    var data = new Data();
    data._name  = "mccallum";
    data._value = 17;
    test.equal(data.value(), 17); // make sure original method is still there
    test.equal(data.uuid, "cafebabe-3550-1i3105");
    test.done();
};

et notre utilitaire s'écrit

lib/utilities.js

var mixin = function(dst, functions) {
    var prop;
    for(prop in functions) {
        if(functions.hasOwnProperty(prop)) {
            dst[prop] = functions[prop];
        }
    }
};

exports.mixin = mixin;

Ok, rien de bien exceptionnel et du code qui existe certainement ailleurs. Mis en place, notre classe Project devient:

lib/project.js

var misc = require("./utilities");

...

/**
 *  Project
 */
// public methods
var methods = {
    event_handlers : {
        on_project_created: function(event) {
            this._name = event.project_name();
            this._uuid = event.project_id();
        },
        on_project_renamed: function(event) {
            this._name = event.new_project_name();
        }
    },
    name : function () {
        return this._name;
    },
    rename : function(new_name) {
        this.apply_event(new ProjectRenamed(this._uuid, new_name)); 
    }
};

function Project() {}
nutil.inherits(Project, aroot.AggregateRoot);
misc.mixin(Project.prototype, methods);
...

Une séance plutôt technique de préparation, avant une grande ligne droite de fonctionnel. Après s'être fait un peu la main sur notre entité de projet, nous nous interesserons la prochaine fois au backlog et aux story.

[T|B|D]DD par la pratique 2 - Installation et mise en place

2011-10-15T00:00:00+00:00

Introduction

Commençons par glaner à gauche et à droite les modules dont nous aurons besoin, nous voulons:

un module pour faire du BDD
un module pour faire du TDD
un module pour la persistence de notre modèle, nous prendrons dans un 1er temps une base de données postgres
un module pour effectuer des tâches asynchrones (~actor)
un module pour générer les uuid de nos entités

Preparation

Installer nodejs

Voir NodeJS et Installation. Pour ma part, j'ai suivi le lien precompiled package for MacOS.

Assurons-nous que le simple "Hello world" marche:

$ node -v
    v0.4.11
    $ echo "console.log('Hello World');" > hello.js
    $ node hello.js
    Hello World
    $ _

Installer Webworker (for actor like)

node-webworker

A WebWorkers implementation for NodeJS

$ npm install webworker
    webworker@0.8.4 ./node_modules/webworker
    $ _

Installer vows (for BDD)

VowsJS

Asynchronous behaviour driven development for Node.

$ npm install vows
    vows@0.5.11 ./node_modules/vows 
    └── eyes@0.1.6
    $ _

Installer nodeunit (for TDD)

nodeunit

$ npm install nodeunit
    nodeunit@0.5.5 ./node_modules/nodeunit 
    $ _

Installer node-postgres (Non-blocking PostgreSQL client)

node-postgres

$ npm install pg
    ...
    Checking for node prefix                 : ok /usr 
    Checking for program pg_config           : not found 
    .../node_modules/pg/wscript:16: error: The program ['pg_config'] is required
    pg@0.5.8 ./node_modules/pg 
    └── generic-pool@1.0.6
    $ _

In the mean time if you get a compilation failure during installation you have still successfully installed the module; however, you cannot use the native bindings -- only the pure javascript bindings.

Très bien, prenons ça pour argent comptant dans un premier temps, et nous nous contenterons de la version pure javascript (qui devrait suffir amplement pour démarrer).

Installer node-uuid (Generation de UUID de type 4)

node-uuid

$ npm install node-uuid
   node-uuid@1.2.0 ./node_modules/node-uuid
   $ _

Simplifions et centralisons les dépendences...

Installer toutes ces dépendances une à une devient rapidement fastidieux, surtout s'il faut le répéter à chaque fois que le projet est récupérer depuis les sources. Heureusement, il existe un moyen de centraliser et conserver ces dépendances en créant un fichier package.json. Ce fichier est très similaire au fichier pom.xml de Maven. Il décrit de manière succinte l'appplication ainsi que ses dépendances. Voir Introduction To npm pour plus d'information.

Par example:

{
      "author": "Arnauld",
      "name": "scrum-board",
      "description": "Scrum board: rambling around [D|T|B]DD",
      "version": "0.0.1",
      "repository": {
        "url": ""
      },
      "engines": {
        "node": "*"
      },
      "dependencies": {
        "webworker": "*",
        "vows": "*",
        "nodeunit": "*",
        "pg": "*",
        "node-uuid": "*"
      },
      "devDependencies": {},
      "main": "app.js"
    }

Du coup, la récupération des dépendances est beaucoup plus immédiate grâce à la commande npm install. Toutes les dépendances sont ainsi installées en une unique commande.

Structure du projet

Le projet prendra la forme suivante:

<project_dir>/
  +-- lib/
  |     +-- domain.js
  |     +-- event_store.js
  |     +-- repository.js
  |     +-- ...
  +-- node_modules/
  |     ...
  +-- samples/
  |     +-- hello.js
  |     +-- ...
  +-- specs/
  |     +-- project_specs.js
  |     +-- user_specs.js
  |     +-- ...
  +-- test/
  |     +-- user_test.js
  |     +-- domain_test.js
  |     +-- ...
  +-- package.json
  +-- watchr-conf.rb
  +-- ...

C'est à dire que

dans lib/ sera contenu le code de notre application
dans node_modules les modules requis et installés pour NodeJS
dans samples/ des snippets et autres petits tests sans importance
dans specs les tests fonctionnels (BDD)
dans test les tests unitaires (TDD)

Tests des specs: executer tous les tests fonctionnels présents dans le dossier specs/

node_modules/.bin/vows --spec specs/*

Tests unitaires: executer tous les tests unitaires présents dans le dossier test/

node_modules/.bin/nodeunit test

Test en continue

Préparons désormais notre environement de test de continue. Il s'agit de mettre en place des jobs qui seront régulièrement déclenchés (sur modification d'un fichier par exemple). Il est ainsi possible de tester continuellement l'application, en relançant les tests à chaque fois qu'un fichier source est modifié. Lorsque notre base de tests commencera à être conséquente, nous essaierons alors de rendre le mécanisme un peu plus malin afin de ne pas pénaliser notre environement en lançant l'intégralité des tests à chaque changement.

Parmis ces jobs nous allons aussi mettre en place un outil de vérification de syntaxe. L'execution du javascript étant relativement permissive dans certains environements d'execution, nous aurons ainsi une syntaxe plus propre, et plus portable. Cette vérification sera faite via la bibliothèque jslint.

L'outils que nous allons utilisé est un script Ruby appellé watchr. Il permet de brancher des appels de fonctions à chaque fois qu'un fichier surveillé est modifié. La liste des fichiers surveillés est déterminée par une expression régulière.

Installation de watchr (sous entend que ruby et rubygem soit correctement installé)

gem install watchr
    gem install ruby-fsevent

Installation de jslint (module NodeJS) afin de tester en continue la syntaxe javascript;

npm install jslint

Le fichier de configuration de watchr indique: * que nous surveillons tous les fichiers js du dossier lib et pour chacun d'eux, en cas de modification, nous déclenchons l'execution du program jslint sur le fichier détecté, lançons les tests unitaires, et les tests fonctionels. * que nous surveillons tous les fichiers js du dossier test et pour chacun d'eux, en cas de modification, nous vérifions sa syntaxe et déclenchons l'execution de tous tests. * que nous surveillons tous les fichiers js du dossier specs et pour chacun d'eux, en cas de modification, nous vérifions sa syntaxe et déclenchons l'execution des tests fonctionnels.

watchr-conf.rb

watch('^(lib/(.*)\.js)') do |m|
      jslint_check("#{m[1]}")
      test()
      specs()
    end

    watch('^(test/(.*)\.js)') do |m|
      jslint_check("#{m[1]}")
      test()
    end

    watch('^(specs/(.*)\.js)') do |m|
      jslint_check("#{m[1]}")
      specs()
    end

    def jslint_check(files_to_check)
      #system('clear')
      puts "Checking #{files_to_check}"
      system("node_modules/.bin/jslint #{files_to_check}")
    end

    def test()
      puts "Start tests"
      system("node_modules/.bin/nodeunit test")
    end

    def specs()
      puts "Start behavior tests"
      system("node_modules/.bin/vows --spec specs/*")
    end

start watchr:

watchr watchr-conf.rb

Pour plus de détails, je vous invite à consulter le livre Continuous Testing qui - même s'il traite essentiellement de Ruby, Rails et Javascript - donnent de bonne idées pour l'étendre à d'autres technologies.

Un démarrage en douceur

Dans une console, démarrons notre script de test continu watchr watchr-conf.rb.

Commençons par le test fonctionnel de création d'un projet, nous voulons que la création d'un projet:

retourne un objet de type Project
retourne un projet dont le nom est bien celui fournit

specs/project_specs.js

var vows = require('vows'),
      assert = require('assert');

  var domain = require('../lib/domain')

  vows.describe('Project').addBatch({
      'A new project created with a given name': {
          topic: function () { 
              return domain.create_project("mccallum")
          },

          'should return an instance of Project' : function(project) {
              assert.instanceOf (project, domain.Project);
          },

          'should have the specified name': function (project) {
              assert.equal (project.name(), 'mccallum');
          },
      }
  }).export(module); // Export the Suite

Après la sauvegarde, on obtient la sortie suivante sur la console:

Checking specs/project_specs.js

  specs/project_specs.js
  /*jslint node: true, es5: true */
    1 4,39: Expected ';' and instead saw 'vows'.
      var domain = require('../lib/domain')
    2 9,53: Expected ';' and instead saw '}'.
      return domain.create_project("mccallum")
  Start behavior tests

  node.js:134
          throw e; // process.nextTick error, or 'error' event on first tick
          ^
  Error: Cannot find module '../lib/domain'
      at Function._resolveFilename (module.js:317:11)
      at Function._load (module.js:262:25)
      at require (module.js:346:19)

On remarquera que notre javascript n'est pas tout à fait valide et qu'il manque deux ; aux lignes 4 et 9. Par ailleurs, nos tests échouent dû à l'absence de notre fichier lib/domain.js, ce qui est normal puisque nous ne l'avons pas encore écrit!

Après quelques tatonements (comment fait-on l'OOP en javascript...), on obtient le fichier suivant:

lib/domain.js

/**
   *  Project
   */
  var Project = function(project_name) {
    this._name = project_name;
  };

  exports.create_project = function(project_name) {
    return new Project(project_name);
  };

  // tells nodeJS to make the `Project` visible from outside this file
  // when using `require`
  exports.Project = Project

Après sauvegarde:

Checking lib/domain.js

  lib/domain.js
  /*jslint node: true, es5: true */
    1 12,26: Expected ';' and instead saw '(end)'.
      exports.Project = Project

  Start tests

  Start behavior tests

  ♢ Project

    A new project created with a given name
      ✓ should return an instance of Project
      ✗ should have the specified name
      TypeError: Object [object Object] has no method 'name'
      at Object.<anonymous> (/Users/arnauld/Projects/cqrs-ramblings/node-app/specs/project_specs.js:17:35)
      at runTest (/Users/arnauld/Projects/cqrs-ramblings/node-app/node_modules/vows/lib/vows.js:93:26)
      at EventEmitter.<anonymous> (/Users/arnauld/Projects/cqrs-ramblings/node-app/node_modules/vows/lib/vows.js:71:9)
      at EventEmitter.emit (events.js:81:20)
      at Array.0 (/Users/arnauld/Projects/cqrs-ramblings/node-app/node_modules/vows/lib/vows/suite.js:150:58)
      at EventEmitter._tickCallback (node.js:126:26)
   
  ✗ Errored » 1 honored ∙ 1 errored (0.008s)

Un de nos tests fonctionnel passe et l'autre échoue lamentablement. Le projet créé est bien une instance de Projet en revanche il ne dispose pas de la méthode name qui devrait permettre de renvoyer son nom. Fixons encore une fois le ; qui manque, et rajoutons la méthode manquante.

lib/domain.js

Project.prototype = {
    name : function () { return this._name; }
  };

Nous obtenons finalement la sortie suivante:

Checking lib/domain.js

  lib/domain.js
  /*jslint node: true, es5: true */
  No errors found.

  Start tests

  Start behavior tests

  ♢ Project

    A new project created with a given name
      ✓ should return an instance of Project
      ✓ should have the specified name
   
  ✓ OK » 2 honored (0.006s)

Hourra!!

Je passe rapidement sur la génération automatique d'un uuid pour notre projet (nous utilisons pour cela le module node-uuid qui fournit, via la variable uuid definie par le require, une méthode de génération), et notre code ressemble désormais à:

lib/domain.js

var uuid = require('node-uuid');

  /**
   *  Project
   */
  var Project = function(uuid, project_name) {
    this._name = project_name;
    this._uuid = uuid;
  };

  // *public* methods
  Project.prototype = {
    name : function () { return this._name; },
    uuid : function () { return this._uuid; }
  };

  exports.create_project = function(project_name) {
    var generated_id = uuid(); // ask `node-uuid` to generate a new one
    return new Project(, project_name);
  };

  exports.Project = Project;

Des tests unitaires ont été ajoutés avant chaque ajout de méthode sur notre classe Project et ressemble désormais à:

test/project_test.js

var domain = require("../lib/domain");

  var UUID_PATTERN = /[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{8}/;

  exports["create_project return the specified name"] = function (test) {
    var project = domain.create_project("mccallum");
    test.equal(project.name(), "mccallum");
    test.done();
  };

  exports["create_project generate a valid uuid"] = function (test) {
    var project = domain.create_project("mccallum");
    test.equal(UUID_PATTERN.test(project.uuid()), true);
    test.done();
  };

Notre fichiers de tests fonctionnels c'est aussi enrichi de quelques assertions supplémentaires notament sur l'unicité de notre uuid et sa représentation:

specs/project_specs.js

var vows = require('vows'),
      assert = require('assert');

  var domain = require('../lib/domain');

  var UUID_PATTERN = /[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{8}/;

  vows.describe('Project').addBatch({
      'A new project created with a given name': {
          topic: function () {
              return domain.create_project("mccallum");
          },

          'should return an instance of Project' : function(project) {
              assert.instanceOf (project, domain.Project);
          },

          'should have the specified name': function (project) {
              assert.equal (project.name(), 'mccallum');
          },

          'and a generated uuid': function (project) {
              assert.equal(UUID_PATTERN.test(project.uuid()), true);
          }
      },
      'New projects': {
          topic: function () { 
              return [ domain.create_project("mccallum"), domain.create_project("mccallum")];
          },

          'should have differents uuid': function (result) {
              assert.notEqual (result[0].uuid(), result[1].uuid());
          }
      }
  }).export(module); // Export the Suite

Notre console affiche donc fièrement:

Start tests
  --------------------------

  project_test
  ✔ create_project return the specified name
  ✔ create_project generate a valid uuid

  OK: 2 assertions (15ms)

  Start behavior tests
  --------------------------

  ♢ Project

    A new project created with a given name
      ✓ should return an instance of Project
      ✓ should have the specified name
      ✓ and a generated uuid
    New projects
      ✓ should have differents uuid
   
  ✓ OK » 4 honored (0.003s)

Et l'Event Sourcing dans tout ça ??

Tout ça c'est bien mais ce n'est pas très conforme avec notre idée de l'[Event Sourcing][event-sourcing]. En effet, la création du projet consiste bien en une transition d'état de rien vers un nouveau projet, et nous ne conservons aucune données de cette transition. Qui plus est, le projet est porteur de son état, il n'est donc pas possible de suivre les modifications qu'il subit, comme un changement de nom.

Rajoutons donc un évènement ProjectCreated, cet évènement sera porteur du nom du projet. Mais que devient notre uuid ? sa valeur est portée par le projet, et nous souhaitons qu'un projet puisse être reconstruit uniquement à partir de ses évènements. Nous déplaçons donc la génération du uuid et considérons que celui-ci est un attribut de notre évènement.

Commençons par écrire les tests unitaires qui décrivent ce que nous souhaitons:

test/project_test.js

...
  exports["create_project must generate an event of type 'project_created' in history"] = function (test) {
    var project = domain.create_project("mccallum");

    var events = project.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 1);
    test.equal(events[0].event_type(), "project_created");
    test.done();
  };

Et la console nous affiche un échec dû à l'absence de notre méthode events() utilisée pour récupérer l'historique:

Checking test/project_test.js
  --------------------------

  test/project_test.js
  /*jslint node: true, es5: true */
  No errors found.

  Start tests
  --------------------------

  project_test
  ✔ create_project return the specified name
  ✔ create_project generate a valid uuid
  ✖ create_project must generate an event of type 'project_created' in history

  TypeError: Object #<Object> has no method 'events'
      at /Users/arnauld/Projects/cqrs-ramblings/node-app/test/project_test.js:20:26
      ...

Après quelques cycles (red+green+refactor) où nous rajoutons la méthode events qui renvoie systématiquement un tableau vide, puis un objet bidon.

Notre fichier de tests resemblent à:

...
  exports["a new project must have an `events` method to retrieve its history"] = function (test) {
    var project = domain.create_project("mccallum");

    var events = project.events();
    test.ok(events instanceof Array);
    test.done();
  };
  exports["a new project must have a single `event` in its history"] = function (test) {
    var project = domain.create_project("mccallum");

    var events = project.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 1);
    test.done();
  };
  exports["a new project must have a single `event` in its history of type 'project_created'"] = function (test) {
    var project = domain.create_project("mccallum");

    var events = project.events();
    test.ok(events instanceof Array);
    test.equal(events.length, 1);
    test.equal(events[0].event_type(), "project_created");
    test.done();
  };

Et notre console affiche désormais que nous bloquons désormais sur le type de notre évènement.

Start tests
  --------------------------

  project_test
  ✔ create_project return the specified name
  ✔ create_project generate a valid uuid
  ✔ a new project must have an `events` method to retrieve its history
  ✔ a new project must have a single `event` in its history
  ✖ a new project must have a single `event` in its history of type 'project_created'

  TypeError: Object dummy_event has no method 'event_type'
      at /Users/arnauld/Projects/cqrs-ramblings/node-app/test/project_test.js:38:23
  ...  
  FAILURES: 1/8 assertions failed (11ms)

Modifions notre méthode de création de projet en passant non plus le nom et l'identifiant du projet mais l'évènement souhaité. Dans la foulée nous rajoutons la méthode apply qui va appliquer cet évènement à notre projet. De la même manière que si l'on rejouait l'historique du projet. Notre code ressemble désormais à (je passe toutes les petites galères de syntaxes javascript, jslint étant là pour me rappeller à l'ordre à chaque sauvegarde):

lib/domain.js

var uuid = require('node-uuid');

  /**
   *  Project
   */

  var ProjectCreated = function(project_id, project_name) {
    // wrapping functions to make values *immutables*
    this.event_type   = function() { return "project_created"; };
    this.project_name = function() { return project_name; };
    this.project_id   = function() { return project_id;   };
  };

  var Project = function(project_id, project_name) {
    this.apply(new ProjectCreated(project_id, project_name));
  };

  // public method
  Project.prototype = {
    name : function () { return this._name; },
    uuid : function () { return this._uuid; },
    events: function () { return ["dummy_event"]; },
    apply: function (event) {
      switch(event.event_type()) {
        case "project_created" :
          this._name = event.project_name();
          this._uuid = event.project_id();
          break;
        default:
          throw new Error("Unknown event type: " + event.event_type());
      }
    }
  };

  exports.create_project = function(project_name) {
    return new Project(uuid(), project_name);
  };

  exports.Project = Project;

Après sauvegarde, on vérifie que les tests précédents continuent de fonctionner correctement, même après notre refactoring. Hourra!! même nos tests fonctionnels continuent de passer.

Start behavior tests
  --------------------------

  ♢ Project

    A new project created with a given name
      ✓ should return an instance of Project
      ✓ should have the specified name
      ✓ and a generated uuid
    New projects
      ✓ should have differents uuid
   
  ✓ OK » 4 honored (0.002s)

Nous avons toujours le même test unitaire qui ne passe pas puisque nous n'avons pas modifié la gestion de l'historique encore.

Ajoutons désormais l'historique à notre projet. Et tous nos tests passent! un peu de refactoring et voila finalement notre code:

lib/domain.js

...
  // public method
  Project.prototype = {
    name : function () { return this._name; },
    uuid : function () { return this._uuid; },
    events: function () { return this._events; }
    apply: function (event) {
      switch(event.event_type()) {
        case "project_created" :
          this._name = event.project_name();
          this._uuid = event.project_id();
          break;
        default:
          throw new Error("Unknown event type: " + event.event_type());
      }

      // still there means the event was correctly handled, thus keep it!
      if(typeof this._events === 'undefined') {
        this._events = [];
      }
      this._events[this._events.length] = event;
    }
  };

Restons sur un succès, et arrêtons nous là pour aujourd'hui.

Dans notre prochain article, nous généraliserons la gestion de l'historique afin de pouvoir la réutiliser dans nos autres entités. Nous nous inspirerons du design des AggregateRoot tel que généralement décrit dans les articles autours cqrs et dans Super Simple CQRS Example - github. Pour plus d'information, je vous invite à consulter les liens ici. Enfin nous mettrons en place la reconstruction du projet par son historique.

[T|B|D]DD par la pratique

2011-10-14T00:00:00+00:00

Dans cette série, nous allons tenter de mettre en pratique la théorie autour des notions d’ Event Sourcing et de CQRS (pour plus d’informations voir CQRS links).

Pour ce faire, nous allons développer une nouvelle application selon les principes du Test Driven Developpement, du Behavior Driven Developpement et du Domain Driven Developpement.

Dans The Pragmatic Programmer, il est conseillé que “l’on apprenne au moins un langage de programmation chaque année” (“Learn at least one new language every year”) et il paraitrait que le javascript soit un vrai langage, hummm… nous allons donc lui donner sa chance, et plus précisement utiliser la plateforme NodeJS comme infrastructure de notre application. Il s’agira pour moi de découvrir NodeJS et une tentative de se reconcillier avec le javascript.

Notre domaine et notre langage commun (Ubiquitous language)

Le but de notre application d’example est de facilité la mise en place et la pratique de Scrum dans une équipe. Nous souhaitons ainsi fournir un moyen de:

crééer les tâches qui constitueront notre backlog
pouvoir définir un sprint sur une periode de temps donnée
pouvoir associer certaines cartes à un sprint
permettre aux membres de l’équipes de déplacer les cartes d’un sprint à mesure de l’avancement des tâches
…

Afin de formaliser un peu plus le contexte de notre application, et les fonctionnalités requises, décrivons nos besoins sous forme de User Story. Nous definirons ainsi par la même occasion notre langage commun, c’est à dire la terminologie employée pour décrire notre domaine. En definissant un language commun, nous limitons les confusions et, ensemble, nous utilisons les mêmes mots pour décrire les mêmes idées. Nous pousserrons jusqu’au bout l’idée de ce langage commun en l’utilisant même dans le code de notre application. Ce langage doit être omniprésent (Ubiquitous Language), et ce, dans nos discussions et notre code. Le code reflètera ainsi directement les concepts de l’application, ce qui devrait le rendre d’autant plus compréhensible pour quiconque connait notre langage commun. Ceci a aussi pour conséquence, que même en tant que développeur je parle le même langage que mon client.

Le contexte

Nous allons faire un bref rappel de la terminologie et des différents concepts que nous utiliserons dans le cadre notre application (pour un présention plus poussées et plus précise se référer à Scrum et XP depuis les Tranchées.
En précisant, le cadre de notre langage nous definissons ainsi son contexte d’application (Bounded Context) ainsi, même si dans d’autre situation les mots ont une autre signification, voici ici la leur. Et si la théorie de scrum a une autre définition ou une autre terminologie, nous sommes protégé par notre contexte, qui défini les frontières d’application de notre vocabulaire à notre application.

Afin de limiter les confusions, nous utiliserons essentiellement les termes anglais relatifs à scrum.

Notre application devra permettre de gérer plusieurs projets. A chaque projet sera associé un backlog, une équipe et un ensemble de sprint. Le backlog servira à récolter les besoins fonctionnels ou techniques émis par le client, à chaque besoins correspondra une entrée dans le backlog, et seront appellées story.

Une équipe sera constituée d’un product owner, d’un scrum master et de plusieurs developers. Le product owner ainsi que le scrum master pourront définir des sprints et leurs associés des tâches (task). Ces tâches pourront être attachées à une story mais ce n’est pas obligatoire, et ce, afin d’avoir une plus grande souplesse d’organisation, notament concernant les tâches techniques. En revanche, il est quasi systématique qu’une story ait une ou plusieurs tâches qui lui soit rattachées. En effet, une story complexe pourra-t-être découpées en plusieurs tâches.

L’état d’une tache pourra (et devra!) évoluer au cours d’un sprint à mesure de son avancement dans sa réalisation, sa validation et son acceptation par le product owner. Par défaut, les différents états que peux prendre une tâche seront: ready for developpement, in developpement, ready for testing, in testing, ready for signoff, accepted. Seul le product owner pourra associer l’état accepted à une tâche.

Les différentes transitions entre états ne seront pas dans un premier temps soumis à des rêgles particulières. Il devra être possible plus tard de rajouter des rêgles, indiquant qu’il n’est pas possible de démarrer le développement d’une carte si trop de carte sont déjà en cours par exemple (voir Kanban et Scrum).

Afin de décrire nos propres User Story nous utiliserons le modèle standard (“As a… I want… so that…”):

En tant que < Rôle d’utilisateur >,
Je peux < But >,
Si bien que < Justification >

C’est parti!! voici en vrac quelques idées de stories pour notre application.

Generalités: Projet, Equipe

En tant qu’ administrateur (de l’application), je peux créer un nouveau projet si bien que je pourrais regrouper les besoins fonctionnels du produit.
En tant qu’ administrateur, je peux associer une équipe à un projet si bien que son activité pourra être suivie par l’application.
En tant qu’ administrateur, je peux définir les membres de l’équipes si bien que l’on pourra définir les rôles scrum de chaque membre.
En tant qu’ administrateur, je peux assigner à chaque membre de l’équipe un rôle parmis scrum master, product owner ou developper.

Backlog

En tant que membre de l’équipe, je peux créer de nouvelles entrées dans le backlog du projet, si bien que les besoins fonctionnels de notre projet pourront être récolter. Une story sera définie par un titre, une description, une évaluation en points de sa complexité, ainsi que sa valeur cliente business value.
En tant que membre de l’équipe, je peux completer une entrée du backlog en modifiant ses informations ou en ajoutant un commentaire, si bien que cette entrée disposera de plus amples informations à mesure des reflexions qu’elle peux suciter.

Sprint

En tant que product owner, je peux definir des nouveaux sprint si bien que je pourrais planifier mes releases, et organiser les tâches à developper à chaque itération.
En tant que product owner, je peux modifier l’intervalle de temps couvert par un sprint non commencé, si bien que je peux ajuster et réorganiser mes sprints dans le temps.
En tant que product owner ou scrum master, je peux associer une entrée du backlog à une tâche du sprint si bien que cette entrée pourra être développée au cours du sprint.
En tant que membre de l’équipe, je peux ajouter une tâche a faire dans un sprint si bien qu’il est possible de rajouter des tâches techniques qui n’apparaissent pas forcément directmement dans le backlog.
En tant que membre de l’équipe, je peux associer une tâche du sprint à une entrée du backlog, si bien qu’il est possible de décomposer les entrées du backlog en sous-tâches.
En tant que membre de l’équipe, je peux lister l’ensemble des tâches associées à une entrée du backlog si bien que je serais capable de déterminer si le développement de cette entrée est terminé.
En tant que membre de l’équipe, je peux changer l’état d’une tâche du sprint, si bien qu’il sera possible de suivre son avancement.
En tant que product owner ou scrum master, je peux déclarer le début d’un sprint si bien que ce sprint sera considéré comme le sprint courant.
En tant que product owner ou scrum master, je peux déclarer la fin d’un sprint si bien que ce sprint ne sera plus considéré comme le sprint courant.
En tant que membres de l’équipe, je peux consulter la liste des sprints terminés mais je ne peux pas les modifier si bien que je peux toujours consulter les archives.

Dans notre prochain article, nous mettrons en place notre environement de développement que nous nous empresserons de solliciter!

L'Event sourcing c'est quoi?

2011-10-11T00:00:00+00:00

Martin Fowler décrit l’Event Sourcing comme:

Captures all changes to an application state as a sequence of events.

En bref, au lieu de conserver le dernier état d’un objet, on conserve toutes les transitions qui ont amené à cet état. En conservant l’ensemble de ces transitions, il est ainsi possible de rejouer les différents états pris par l’objet au cours de son cycle de vie. Plus important encore, ce n’est pas seulement le changement d’état qui est conservé, mais l’intention de l’utilisateur qui a provoqué ce changement.

Supposons que l’on se promène sur amazon. A chaque fois que l’on tombe sur un livre qui nous plait, on l’ajoute à notre panier. Au bout d’un moment, notre panier pourrait ressembler à cela:

[
  "Domain-Driven Design: Tackling Complexity in the Heart of Software",
  "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET",
  "Event Centric: Finding Simplicity in Complex Systems",
  "Streamlined Object Modeling: Patterns, Rules, and Implementation"
]

Quand on se décide finalement à passer notre commande, oh stupeur! on en a pour $201.20. Notre budget ne le permettant pas, après une sélection drastique, notre panier se déleste de deux livres et devient:

[
  "Domain-Driven Design: Tackling Complexity in the Heart of Software",
  "Streamlined Object Modeling: Patterns, Rules, and Implementation"
]

Le montant s’élève alors à $97.66, ce qui est acceptable pour notre budget actuel. La commande passée, il ne reste plus rien des deux livres que nous souhaitions acheter et que nous avons dû mettre de côté faute de moyen.

Si maintenant, on conserve l’intégralité des changements d’états, l’historique de notre panier (vu d’un point de vue technique) pourrait être similaire à:

[
  BookAdded ("Domain-Driven Design: Tackling Complexity in the Heart of Software"),
  BookAdded ("Patterns of Enterprise Application Architecture"),
  BookAdded ("Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"),
  BookRemoved ("Patterns of Enterprise Application Architecture"),
  BookAdded ("Event Centric: Finding Simplicity in Complex Systems"),
  BookAdded ("Streamlined Object Modeling: Patterns, Rules, and Implementation"),
  BookRemoved ("Event Centric: Finding Simplicity in Complex Systems"),
  BookRemoved ("Streamlined Object Modeling: Patterns, Rules, and Implementation")
]

En conservant, l’ensemble des changements d’états on se rend compte que le livre “Patterns of Enterprise Application Architecture” a fait une apparition aussi dans le panier, ainsi que les deux livres enlevés à la fin.

Maintenant en conservant l’historique des intentions de l’utilisateurs on obtient:

[
  BookAdded ("Domain-Driven Design: Tackling Complexity in the Heart of Software"),
  PeopleAlsoBought ("Patterns of Enterprise Application Architecture"),
  BookAdded ("Patterns of Enterprise Application Architecture"),
  PeopleAlsoBought ("Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"),
  BookAdded ("Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"),
  BookRemoved ("Patterns of Enterprise Application Architecture"),
  Search ("event centric"),
  BookAdded ("Event Centric: Finding Simplicity in Complex Systems"),
  BookAdded ("Streamlined Object Modeling: Patterns, Rules, and Implementation"),
  BookRemovedOnBilling ("Event Centric: Finding Simplicity in Complex Systems"),
  BookRemovedOnBilling ("Streamlined Object Modeling: Patterns, Rules, and Implementation")
]

On peux désormais constater que les deux derniers livres ont été enlevés du panier au moment du paiement.

D’autre part, on constate que le choix de certains livres a été fait en cliquant sur les livres présentés dans la section “Les clients ayant acheté cet article ont également acheté”, ce qui renforce l’interêt de cette section. Ceci est très instructifs, et va permettre de cibler les prochaines suggestions d’achats en privilégiant ces livres. En effet, s’ils ont déjà suscité de l’interêt jusqu’au moment de l’achat, il est fort probable que cela se reproduise.

Ce qui est interessant, c’est que même si l’on ne dispose pas encore de notre mécanique de suggestions ou de nos outils d’analyse, l’information est présente et pourra être analysée lorsque nous aurons les outils adéquats.

D’autre part, on dispose de toutes les informations pour “rejouer” la constitution de notre panier, notre modèle est beaucoup plus riche que précédement et peux permettre une bien plus grande flexibilité. En effet, on a pu ajouter les évènements PeopleAlsoBought et Search sans que cela ait d’impact sur la constitution finale de notre panier.

Enfin, l’un des points les plus importants est que l’état final de notre panier importe peu. Cet état n’a plus besoin d’être conservé, puisqu’il est possible de le reconstruire à partir des évènements qui le décrivent. Chaque évènement décrit une transition vers l’état a atteindre. En conservant uniquement les évènements, il est possible de reconstruire l’objet.

Tech'n bolts

Il y a peut être une option pour continuer ¡¿ (réflexion sur la programmation par continuation)

AMQP 101 ~ Part I

Le BDD mis en oeuvre avec JBehave

Le BDD, qu’est ce que c’est?

Twitter quotes: Business Components versus Bounded Contexts

Eric Evans

thinkb4coding / jeppec

Udi Dahan

Javascript Libraries

Quote of the day

[T|B|D]DD par la pratique 5 - Persistence et Migrations

Persistence

NodeJS et Postgres, où sont nos tests d'intégrations?

Quart d'heure Soirées détente explorations de l'utilisation de Postgres en mode non bloquant

[T|B|D]DD par la pratique 4 - Backlog et Story

Et les commentaires?

Etats des lieux

La sélection de décembre

Coding styles

Web design

Event, CQRS, high-scalability

DDD

Test-Driven Development: un pacte diabolique ? Traduction de Test-Driven Development A Faustian Bargain

Response to "Technical Job Interview Questions for Java EE architects"

Table of content

Database systems

What are heuristic exceptions?

4.1.3. The two-phase XA protocol

4.1.4. Heuristic exceptions

What does ACID mean?

What does BASE mean?

What are isolation levels?

What kind of caches are there in Hibernate ORM?

Modelling and Coding

What are anemic domain models?

What are the SOLID principles?

What code generation tools do you know? Which ones did you use?

Which ways of creating your own DSLs do you know? Which ones did you use?

Which UML diagram types do you know? What are UML stereotypes? What are UML color standards?

Java VM

What kind of garbage collectors are there in Java 6? What are the differences? Which ones are usually used for Java EE applications? How can you find out which garbage collector should be used for a Java EE application?

What is the generational hypothesis concerning garbage collection?

What kind of locks in the Java VM do you know?

What is the difference between a mutex and a semaphore and similiar questions?

What are the most important languages running on a Java VM? Which ones did you use? What are their advantages and disadvantages?

What monitoring tools do you know? Which ones did you use in production?

Java EE

What are the most important technologies / specifications in Java EE 6?

What is Weld?

Which Java web frameworks do you know? What are their advantages and disadvantages?

Which ways of making asynchronous calls within a Java EE 6 server do you know?

Which ways of asynchronous communication between web browsers and web servers do you know?

What are the most important performance issues in Java web applications?

What are the most important performance issues in Java EE server applications?

Distributed Computing

What are the advantages and disadvantages of ESBs? Which ESBs do you know? Which ones did you use?

What is the CAP theorem? (Now that’s quite important)

What is Terracotta used for?

What is the token bucket algorithm?

What is REST used for? What are the advantages and disadvantages?

What is Amdahls Law? What is Gustafson’s Law?

[Added] Additional topics and tools

Security

Tools

Programming models

Java libraries

Java utilities

[Added] Recommended Lectures to go further

General

Concurrency

[Added] Conclusion

Ancien blob et anciens messages

Jekyll - Le site web des développeurs

[T|B|D]DD par la pratique ou la decouverte de NodeJS

[T|B|D]DD par la pratique 3 - AggregateRoot

Echauffement

Renommer un projet

Projet et Event Sourcing: le phoenix!

Un peu de technique dans un monde de brutes!

Test-Driven Development: un pacte diabolique ?
Traduction de Test-Driven Development A Faustian Bargain