InfOsaurus

Le 24 Mars dernier se déroulait le premier Code Retreat à Montpellier, animé par Antoine Vernois et organisé par Julien Lafont, Vivian Pennel et Sylvain Fraïssé. L'événement avait lieu dans les locaux de l'école Epitech. Je ne vais pas rappeler les règles d'un code retreat en détail, mais il s'agit d'une rencontre où on développe en pair programming sur un problème donné - en général le Conway's Game of Life, sous forme d'itérations de 45 minutes en changeant de binôme à chaque fois. Voici mon petit retour (tardif) sur la journée.

Ce que j'ai aimé :

• La bonne humeur générale propice aux échanges, avec des développeurs venus d'un peu partout (Montpellier mais aussi Marseille, Toulouse, etc).

• La variété des langages présents, de Java à Python en passant par Scala, Ruby et plein d'autres.

• Le cadre d'Epitech sympa, dans une bâtisse ancienne montpelliéraine rénovée.

• L'efficacité d'Antoine qui avait visiblement reçu 5/5 l'unique conseil avisé de Corey Haines :)

Ce que j'ai appris :

• Le pouvoir des contraintes. Se mettre des restrictions très pénibles (pas de if, de boucles, pas de getters/setters...) force en fait à réfléchir autrement et paradoxalement on en tire plein d'enseignements à mettre en application plus tard.

• Un Code Retreat, ça passe très vite, aussi bien la journée que les itérations elles-mêmes. Au bout des 45 minutes, on est systématiquement frustré d'être si loin de voir notre monde en vie, surtout quand de précieuses minutes ont été passées en contingences matérielles annexes. Mais c'est le jeu, ma pauvre Lucette :)

• Ruby, ça a l'air de roxxer. Il faut que je m'y penche de plus près.

• Décidément, j'ai du mal à convaincre mes petits camarades que C#, c'est bien. Pourtant, C#, c'est bien ;)

Si c'était à refaire :

• Eviter de se pointer avec un langage ou un environnement qu'on maîtrise mal. Je pense qu'il est crucial qu'un des deux membres du binôme connaisse très bien la techno utilisée pour pouvoir se concentrer uniquement sur les tests et l'émergence du design. J'ai le sentiment d'avoir passé trop de temps à cerner des détails de langages, c'est intéressant mais pas forcément dans les clous de la journée.

• Peut-être expliquer un peu mieux au début de la journée ce qu'est TDD, ou demander aux gens de se renseigner dessus avant. J'ai l'impression qu'il y avait un taux assez haut de "totale découverte TDD" dans la salle ce qui est bien sûr enrichissant au niveau du partage, mais a peut-être généré une certaine perplexité.

Dans la catégorie "j'ai testé pour vous" :

• Casser la cafetière du code retreat dès le matin (encore désolé Julien)... j'ai un peu fait mon boulet sur ce coup-là.

• Le Conway's Game of Life en Python avec un binôme qui n'avait fait que du C et pas familier du développement objet. Tout ça sans if et sans boucle sinon c'est pas drôle... Ou comment expliquer le polymorphisme à quelqu'un en 5 minutes :)

• Le ping-pong programming à 3 sans avoir le droit de se parler et avec un test runner JUnit qui crashe de temps en temps. Un grand moment... d'incompréhension, mais très instructif sur notre dépendance à la communication !

En tout cas, très bonne expérience que ce premier code retreat, encore merci aux organisateurs et aux participants ! A quand la prochaine ? ;)

Ayant fait pas mal de déplacements fin 2011, j'ai occupé mon temps notamment en écoutant divers podcasts sur le développement logiciel. Pour tous ceux qui prévoient de passer du temps dans les transports cette année, je vous propose ma sélection avec mes 5 podcasts favoris en 2011 :

1. .NET Rocks! : un show très sémillant à l'américaine autour de .NET et des technologies Microsoft animé par Carl Franklin et Richard Campbell. Le podcast est de qualité professionnelle avec un très bon son, l'inconvénient étant les pubs. Bons invités (récemment Corey Haines) et toujours à la pointe de l'actualité et des sujets qui buzzent. Je le mets en premier pour la fréquence soutenue des épisodes qui fait qu'on a toujours quelque chose d'intéressant à se mettre sous la dent.

2. Visual Studio Talk Show : encore du .NET, mais comme son nom ne l'indique pas c'est un des rares podcasts francophones que j'aie trouvé sur le développement. Il est animé par les excellents Québecois Guy Barrette et Mario Cardinal. J'aime bien ce podcast pour son approche didactique et accessible, la variété des sujets et les acteurs de la communauté (québécois mais aussi français) invités.

3. Software Engineering Radio : un podcast généraliste sur le développement, les méthodes agiles... avec des invités de marque : Jurgen Appello, Lisa Crispin, Uncle Bob, Rich Hickey (créateur du langage Clojure) ont été reçus par le passé, sans compter un épisode assez mémorable avec Kent Beck.

4. Hanselminutes : le podcast de Scott Hanselmann assez orienté Web et Microsoft. J'aime bien le ton sérieux et toujours posé de Scott qui est un peu à l'inverse des compères de .NET Rocks!

5. The Java Posse : le podcast le plus populaire sur Java, avec son générique culte et sa bande de joyeux lurons assez marrants à écouter débattre en long et en large sur plein de sujets (spécial longs trajets donc). Et ça ne fait pas de mal de prendre des nouvelles de ce qui se fait du côté de Java de temps en temps ;)

Une mention également à The Agile Toolkit, Deep Fried Bytes et The Pragmatic Podcast qui valent le détour malgré une parution plus épisodique.

Je suis aussi preneur de vos suggestions de podcasts, notamment en français !

Sur ce, je vous souhaite une très bonne année 2012 :)

Cette année, j'ai eu la chance de participer à deux dates de l'Agile Tour : le 20 Octobre à Montpellier suivi de celui de Bordeaux le 21. Voici un petit retour sur les 2 événements.

Agile Tour Montpellier

Le lieu

Ce premier Agile Tour montpelliérain avait lieu à l'école Polytech sur le campus de l'Université Montpellier 2. Quatre salles dont un grand amphi avaient été réservées pour l'occasion. Du côté du programme, la volonté affichée était de cibler 2 types de publics : les décideurs ("boss") et les développeurs ("geeks") plus les étudiants et universitaires.

Sessions

Software Craftsmanship par Jean-Laurent de Morhlon


Beaucoup de choses intéressantes dans cette présentation qui couvrait plein de sujets sur la théorie et la pratique de Software Craftsmanship, de l'historique du mouvement au manifeste en passant par les pratiques comme TDD et SOLID. Quelques morceaux choisis :

• Ne pas s'en tenir au Craftsmanship Manifesto, flou et difficile à comprendre, voire même l'oublier.
• Besoin de rétablir l'équilibre entre process et pratiques de développement, ces dernières sous-estimées notamment dans certaines implémentations actuelles de Scrum.
• Une des techniques d'apprentissage les plus efficaces reste le mentoring ("conduite accompagnée").
• Notion "d'heures de vol" accumulées nécessaires pour atteindre un certain niveau, comme un pilote d'avion.
• Pair Hero et Ping Pong Programming permettent de pratiquer en s'amusant.

A noter que la slide "! Art" (le développement n'est pas de l'art) a fait réagir et suscité un vif débat philosophique sur la signification de l'art ;-)

Au final, une session maitrisée et fort sympathique ; même si on connait déjà un peu le sujet, c'est toujours enrichissant d'avoir le point de vue de personnes éclairées surtout sur un domaine peu exploré en France comme Software Craftsmanship.

Le pilotage par les tests par Jérôme Avoustin

Cette session présentait TDD, ATDD et BDD avec des démos et en filigrane un retour d'expérience sur un projet piloté par les tests. Jérôme nous avait prévenu que le rythme allait être élevé pour tout faire tenir en une heure, et en effet le contenu était riche.

• J'ai bien aimé l'approche "top-down" mise en place sur le projet qui est une sorte de méta-cycle red-green-refactor où on crée un test BDD rouge avant d'écrire les tests de plus bas niveau en TDD, et on reboucle sur le passage à vert du test BDD pour finir.
• Enseignement instructif sur l'évolution de la façon de développer : avec cette approche, le temps passé en tests a beaucoup augmenté mais celui passé à debugger a énormément diminué.
• Définition de la qualité qui me plait bien : c'est quand le coût d'ajout d'une fonctionnalité est stable.

En tout cas, encore une présentation qui donne envie de faire du BDD :) Il est intéressant d'avoir des retours d'expérience sur de vrais projets qui l'ont mis en place, finalement pas si nombreux.

Contractualisation agile par Jean-Francois Jagodzinski

La session de cet Agile Tour qui m'a laissé le plus perplexe. J'ai l'impression que toute la présentation tournait autour du pot des contrats agiles sans jamais vraiment attaquer le sujet. Jean-Francois Jagodzinski était un peu en mode questionnement socratique et je n'ai pas vraiment vu où il venait en venir...
Heureusement des membres du public ont posé les "questions qui fâchent" à la fin en allant droit au but, ce qui a permis d'amorcer une discussion sur les difficultés des contrats agiles.

Une autre présentation de Jean-François est disponible sur slideshare mais ce n'est pas exactement celle de l'AT Montpellier.

Bref, je sors mon joker pour celle-là, je devais être trop endormi après le buffet...

Transformation agile au delà des équipes projet, par Romain Vignes

Un retour d'expérience instructif sur la transformation agile menée au sein de la société Wyplay, éditeur de logiciels de TV numérique, avec notamment comme clients SFR et Vodafone. Voici ce que j'ai noté :

• Points de difficulté dans l'adoption de Scrum : organigramme à revoir, auto-organisation et discipline, transparence, disponibilité du client.
• Autre difficulté importante : passage d'équipes multi-projets mais mono-métier à des équipes mono-projet mais inter-disciplinaires.
• Une métrique intéressante utilisée chez Wyplay pour limiter l'éparpillement : Team Turn Over = Nb développeurs à cheval sur 2 projets ou + / nb total de dev.
• Point d'accord avec la présentation de Jérôme Avoustin : le temps de debug s'est rapidement raccourci suite à l'adoption de l'agilité.
  

Projet et Cycle de vie agile par Thierry Cros

Une présentation classique mais efficace sur le cycle de vie des projets agiles. Quelques points que j'ai relevés :

• Nécessité d'apprendre le "jeu de la planification agile"
• La phase projet et la phase maintenance d'une application ne formeraient qu'une seule phase de pilotage par feedback
• "Estimation belote" est plus proche de la réalité que Planning Poker :)

Ce que j'ai aimé

• L'accueil très pro des organisateurs

• Bonnes présentations "Geek"

• Pas mal d'ateliers

• Le buffet servi à midi

• Les conférences de l'amphi retransmises sur Lanyrd

Ce que j'ai moins aimé

• Peut-être moins de mélanges entre "populations" du fait de la séparation très marquée des sessions "geeks"/"boss"

Quoi qu'il en soit, pour une première c'était très réussi, chapeau bas aux organisateurs et orateurs qui ont parfaitement su faire prendre la mayonnaise !

Agile Tour Bordeaux

Le lieu

Pour la seconde fois, l'AT Bordeaux se déroulait à l'Enseirb. Là aussi, 4 salles dont un grand amphi étaient réservées, avec un sympathique espace ouvert au rez-de chaussée. Le programme était un peu plus orienté ateliers que les années précédentes, avec un coding dojo, un Kanban Game, un atelier Billes Rouges, l'espace ouvert... mais les présentations techniques ou orientées projet étaient bien entendu présentes.

Sessions

Kata Marrant par Emmanuel Gaillot et Jonathan Perret

Si vous n'avez pas encore vécu une prestation de ces deux hurluberlus, je vous conseille vivement d'en faire l'expérience. On assiste à une vraie pièce de théâtre d'impro, où le public participe en déposant des suggestions de thèmes ou de manières de coder dans une corbeille.

Chaton interstellaire, arc-en-ciel de sodium... difficile de décrire ce qui est sorti de ce kata mais le fun était bien là !

J'ai découvert par la même occasion CoffeeScript, un petit langage sympa qui dépouille JavaScript de ses accolades et points-virgules.

Ni gladiateurs, ni bisounours par Christophe Thibaut

Sans doute la présentation la plus radicale et la plus propice à réflexion à laquelle j'ai eu l'occasion d'assister lors de ces Agile Tour. La première partie recensait des anti-patterns d'équipes très bien vus ("Nez dans le guidon", "Maillon faible", "Feu de camp"...) dans lesquels je pense la majorité du public s'est reconnu. Venaient ensuite des propositions de solutions avec les Core Protocols. Je ne vais pas tous les décrire mais il s'agit de techniques (dont certaines assez déconcertantes) favorisant la communication d'équipe. Je ne sais pas si elles sont toutes applicables telles quelles partout, mais c'est en tout cas certainement une bonne source d'inspiration.

2 moments de "déclic" parmi d'autres :

• "On peut influer sur la motivation d'une personne uniquement négativement"
• "Les membres d'une équipe sont comme les cartes composant une quinte flush, elles n'ont d'intérêt que par les relations qui les lient"

Quarante ans de crise, dix ans d'agilité par Laurent Bossavit

J'avais déjà vu cette présentation en vidéo, mais en vrai, c'est quand même vachement mieux... Laurent y met en perspective - ce qui à ma connaissance a rarement été fait auparavant - l'histoire du génie logiciel depuis ses origines à une conférence de l'OTAN en 1968 jusqu'à nos jours, avec l'état actuel de la discipline. L'exercice est riche en enseignements et force est de constater que la plupart des questions posées il y a 40 ans n'ont toujours pas trouvé de réponse.

La présentation explique ensuite pourquoi Agile est une innovation de rupture et s'ouvre enfin sur la perspective de l'avenir de l'agilité et la proposition de passer d'une culture agile orale à une culture plus formalisée avec l'Institut Agile et une prise en compte accrue de l'agilité dans les programmes des universités.

Si vous n'avez pas encore vu cette vidéo, je vous la conseille vivement.

TDD, je commence demain ! par Fabien Bézagu

Le pari de cette session était osé - faire découvrir Test Driven Development et convaincre les développeurs présents de franchir le cap dans leur job. Tout cela en commençant par une démonstration en PHP (qui a dit qu'il y avait des sous-langages ?...) L'ensemble était bien mené par Fabien malgré un public que j'ai senti pas aussi avide d'échanges qu'espéré.

Ce que j'ai aimé

• Beaucoup de sessions techniques orientés "geek" (même si je n'aime pas ce mot) et d'ateliers
• Le mot des sponsors beaucoup plus agréable, avec moins de concours de qui a la plus grosse agilité que l'année dernière (qui a dit normal, il n'y avait pas de SSII ?...)
• L'organisation toujours au poil
• Les orateurs toujours disponibles pour discuter, un plaisir

Ce que j'ai moins aimé

• L'espace ouvert qui manquait de prise en charge des nouveaux arrivants
• Le coding dojo dur à rattraper en cours de route si on n'avait pas suivi au début
• Les coups de gong du Sky Castle Game qui ont semblé perturber les acteurs du Kata Marrant (qui ont quand même essayé de rivaliser, avec leur petite sonnette !)
• Les 2h de retard du TGV de la nuit précédente, heureusement j'ai pu tenir avec moult café pendant la conférence ;)

Pour conclure, un grand merci à tous les organisateurs et participants des deux Agile Tour et à l'année prochaine !

Bon, c'est vrai qu'il est un peu tard pour les recommandations de livres d'été. Mais je me devais de vous signaler une BD moyen format qui pourrait être votre parfait compagnon sur la plage en cette fin de vacances (si vous avez la chance d'en avoir) : FreakAngels.

Le pitch :

Londres, dans un futur pas si lointain. Une catastrophe sans précédent a ravagé la ville, la submergeant en partie sous l'eau de mer. Dans le calme post-apocalyptique du quartier de Whitechapel, les survivants se sont organisés tant bien que mal mais le manque d'eau potable et de vivres se fait cruellement ressentir.

Heureusement, les FreakAngels veillent.

Ces onze jeunes hommes et femmes aux étonnants pouvoirs télépathiques qui ont organisé le ravitaillement et la défense du quartier sont la seule lueur d'espoir de la population. Mais quels que soient leurs mérites, on comprend très vite que ces anges ont aussi leur part d'ombre et des travers bien humains, à commencer par Mark, le douzième membre renégat exilé dans le Nord. Tout commence lorsqu'une jeune fille, Alice, est envoyée à WhiteChapel par Mark pour abattre l'un des autres FreakAngels...

Réalisé par deux Anglais, Warren Ellis et Paul Duffield, dont le style mêle manga européen, comics et ligne claire, FreakAngels se déroule dans un monde de disaster fiction désabusé mais inventif, à l'image de ses habitants qui doivent faire preuve d'ingéniosité pour survivre. Un peu comme dans la classique BD Neige, un petit groupe d'individus détient la clé du désastre qui a frappé la région, et, qui sait, pourra peut-être réparer les dégâts.
Ce qui fait l'intérêt de FreakAngels, c'est que malgré les pouvoirs de super-héros des personnages pricipaux, on est loin d'avoir affaire à des sauveurs au-dessus de tout reproche. Les membres de la bande sont tour à tour violents, paranoïaques, nymphomanes, parasitiques, névrosés, et passent une bonne partie de leur temps en franches engueulades (dialogues savoureux signés Ellis) avec des conséquences fâcheuses, pouvoirs psy obligent. Loin d'être entièrement axé sur le paranormal, le comic fait la part belle à l'humanité des personnages. Avec ou sans pouvoirs, ce sont avant tout de jeunes adultes paumés qui tentent tant bien que mal d'assumer (ou pas) les responsabilités qui leur incombent dans ce monde bouleversé.

FreakAngels 1 est sorti il y a peu en français aux éditions du Lombard mais c'est à l'origine un webcomic hebdomadaire gratuit proposé par les auteurs sur www.freakangels.com. La VO est donc disponible gratuitement jusqu'au tome 5... de quoi craquer en attendant le deuxième livre en VF ;)

Il y a peu, je vous parlais d'une possible synergie entre les bases de données NoSQL de type document et les Agrégats de Domain Driven Design.

Entretemps est sortie la base NoSQL pour la plateforme .NET d'Ayende Rahien, Raven DB, et elle confirme ces suppositions. Voici un extrait de la documentation de la base au corbeau :

« When thinking about using Raven to persist entities, we need to consider the two previous points. The suggested approach is to follow the Aggregate pattern from the Domain Driven Design book. An Aggregate Root contains several entities and value types and controls all access to the objects contained in its boundaries. External references may only refer to the Aggregate Root, never to one of its child objects.
When you apply this sort of thinking to a document database, there is a natural and easy to follow correlation between an Aggregate Root (in DDD terms) and a document in Raven. An Aggregate Root, and all the objects that it holds, is a document in Raven. »

Avec Raven, les données sont stockées dans des documents JSON qui ressemblent à ça :

Contrairement à une base relationnelle dans laquelle les données résident dans des tables fragmentées qu'on peut relier par l'intégrité référentielle, il est possible de stocker dans ce type de document tout un graphe d'objets complexes et typés. Les préconisations pour la conception de documents Raven sont donc à l'inverse de celles qui président au design d'une base de données relationnelle : il s'agit de regrouper au sein d'un seul document les objets formant un tout logique. Par exemple, un Livre regroupe à la fois un titre mais aussi les objets que sont son Auteur et sa Catégorie. Il se trouve que la notion d'Agrégat et de Racine d'Agrégat de DDD recoupe en tous points ce concept.

Un des bénéfices qu'on constate immédiatement avec Raven DB est l'élimination pure et simple de la couche de mapping objet-relationnel, parfois source de bien des complications. En effet avec Raven, plus de défaut d'impédance entre les objets de l'application et leur équivalent persisté relationnel. La couche persistance s'en trouve bien allégée.

Exemple en C#

Comme un bon exemple vaut tous les discours, voici comment on peut implémenter un Entrepôt avec Raven et son client C# natif :

   1:      public class Livre

   2:      {

   3:          public string Id { get; set; }

   4:          public Auteur Auteur { get; set; }

   5:          public string Titre { get; set; }

   6:          public Categorie Categorie { get; set; }

   7:      }

   1:      public class EntrepotLivres

   2:      {

   3:          public EntrepotLivres(IDocumentSession documentSession)

   4:          {

   5:              session = documentSession;

   6:          }

   7:   

   8:          public void AjouterLivre(Livre livre)

   9:          {

  10:              session.Store(livre);

  11:              session.SaveChanges();

  12:          }

  13:   

  14:          public void SupprimerLivre(Livre livre)

  15:          {

  16:              session.Delete(livre);

  17:              session.SaveChanges();

  18:          }

  19:   

  20:          public Livre GetLivreParId(string id)

  21:          {

  22:              return session.Load<Livre>(id);

  23:          }

  24:   

  25:          private IDocumentSession session;

  26:      }

   1:  class Program

   2:  {

   3:      static void Main(string[] args)

   4:      {

   5:          var documentStore = new DocumentStore { Url = "http://localhost:8080" };

   6:          documentStore.Initialize();

   7:   

   8:          using (var session = documentStore.OpenSession())

   9:          {

  10:              EntrepotLivres entrepotLivres = new EntrepotLivres(session);

  11:              ...

  12:          }

  13:      }

  14:  }

Pas de fichier de mapping à gérer à côté de ça, l'entité Livre et tout ce qu'elle contient se persistera de façon immédiate... Simple, non ?

On remarque qu'on manipule une Session Raven. Il s'agit d'une implémentation du pattern Unit of Work assez similaire à ce qu'on trouve dans des frameworks d'ORM comme NHibernate. En fait, bon nombre de concepts et dénominations dans l'API client C# de Raven sont directement issus de NHibernate.

Index et requêtes

Pour l'instant, notre Entrepôt ne fait qu'ajouter des entités, les supprimer et les hydrater à partir de leur ID, ce qui se fait nativement avec Raven. Pour exécuter des requêtes plus complexes sur nos documents, il faut passer par des index. Les index sont des vues stockées sur disque semblables aux vues matérialisées des SGBDR. Ils sont taillés pour un type de recherche particulier.

Voici comment on définit en C# un index qui porte sur les catégories des livres :

   1:          documentStore.DatabaseCommands.PutIndex("LivresParCategorie", 

   2:              new IndexDefinition<Livre>

   3:              {

   4:                  Map = livres => from livre in livres

   5:                                  select new { livre.Categorie }

   6:              });

Cet index ne doit être créé qu'une fois, il peut aussi être défini via l'interface d'administration de Raven en utilisant la même syntaxe.

On peut maintenant ajouter une méthode à notre entrepôt qui retourne tous les livres d'une catégorie. Elle effectue une requête LuceneQuery sur l'index précédemment défini :

   1:          public IList<Livre> GetLivresParCategorie(Categorie categorie)

   2:          {

   3:              return session.LuceneQuery<Livre>("LivresParCategorie")

   4:                  .Where(l => l.Categorie == categorie)

   5:                  .ToList();

   6:          }

Il existe une autre technique d'indexation plus sophistiquée, map/reduce, dont je parlerai peut-être dans un autre billet.

Impressions

Ce que j'aime dans Raven DB :

• Simplicité de persistance des objets et affranchissement complet de la couche d'ORM.

• Les données sont accessibles sous forme RESTful (chaque document dispose d'une URL) et lisible par un humain.

• Sans doute bien plus facilement scalable qu'un SGBDR du fait de la nature atomique et autonome d'un document.

• API .NET et requêtage sur les indexes en Linq.

• Raven se marie bien avec DDD et une partie de l'effort de design de la base est déjà fait si on a découpé ses Agrégats.

Ce qui me plait moins :

• Pour exploiter pleinement Raven en termes de performances, il faut idéalement ramener un seul document de la base et que celui-ci contienne tout ce dont on a besoin. Cela peut mener à une tendance à calquer les documents sur les IHM.

• Raven DB a peut-être un petit impact sur la persistance ignorance de notre domaine. Il semble qu'une entité qui fait référence à la racine d'un autre agrégat (donc située dans un autre document, en termes Raven) ne peut pas avoir une référence directe à cet objet mais est obligé de contenir son ID à la place. Dans notre exemple, l'Auteur d'un Livre est un objet entièrement contenu dans l'agrégat Livre parce qu'on ne stocke que son nom et prénom. Mais si l'Auteur devait faire l'objet d'un agrégat séparé à lui (par exemple si l'auteur est un Utilisateur du système), le Livre devrait alors contenir la clé de l'Auteur et plus l'Auteur lui même. Sachant que les IDs natifs de Raven sont très typiques ("auteurs/465" par exemple), on se retrouve avec une trace de Raven dans le graphe d'objets du domaine, et aussi la nécessité de passer par un entrepôt pour réhydrater l'objet dont on n'a que la clé.

Les doutes à lever à l'avenir :

• Les performances. Ayende a publié des mesures de perfs prometteuses mais il va falloir qu'elles soient confirmées sur des projets à plus grande échelle. En particulier, il serait intéressant de voir comment le système de concurrence optimiste de Raven se comporte dans un contexte transactionnel intensif.

• L'adoption. Je pense que les bases NoSQL ne survivront pas sans un écosystème solide à la fois en termes de communauté et d'outillage disponible. Si on ne peut pas faire avec les bases non relationnelles tout ce qu'on fait avec les SGBDR (monitoring, tuning, reporting, analyse de données...), elles resteront une bonne idée sur le papier mais un choix pauvre sur le terrain.