• fournir aux managers de nos Product Owner des données pour améliorer leurs décisions d’un projet à l’autre
• corriger un problème de concurrence d’accès en production en moins de deux jours
• tordre le cou à des croyances erronées sur nos retards

Comme la demande des participants de la précédente édition étaient de relater des expériences de terrain, nous nous autoriserons à certains moments à rentrer dans les détails du quotidien d’un développeur agile.

Il y a toujours des personnes passionnées dans le mouvement agile. C’est suffisamment rare pour le souligner : des formations gratuites avec l’un des fondateur, hébergée gracieusement, ça ne court pas les rues. L’échange, le partage de moments, d’informations, de questionnements autour de ce thème continue d’intéresser, ça fait du bien.

Paradoxalement, des pionniers ont exprimé un certain spleen en observant une large adoption de l’agilité, noyée dans une soupe marketing indigeste loin de ses valeurs fondatrices. L’agilité est récupérée pour attirer des clients ou des développeurs, victime de son succès et d’absence d’alternatives devant la difficulté de réussir des projets informatiques. Pire, elle peut être utilisée de manière cynique en donnant aux équipes une autonomie de façade, moyen de les impliquer d’avantage et in fine de les faire travailler plus. Qu’elles soient prestataire ou client, ces en-général-grosses-boites  se foutent comme d’un post-it de l’objectif de l’agilité, à savoir (grosso-modo) apporter de la valeur de manière durable dans un environnement en évolution, en développant les individus.

Laurent Bossavit a une analyse intéressante s’appuyant sur les frontières ouvertes de l’agilité, entre la gestion de projet, le développement logiciel et le management. Le métier de l’agiliste et son territoire de légitimité sont mal connus, ce qui favorise les incursions d’autres professions, mais permet également de plus grandes possibilités d’adoption. Si le sujet vous intéresse voir le livre « The System of Professions » – Abbot 1988 (merci Laurent pour la référence).

La théorie

Mais revenons à la formation. La présentation d’Agile Avancée, selon Alistair, s’articule autour de cinq thèmes :

• Artisanat
• Gestion de flux
• Eveil de Soi
• Acquisition de connaissances
• Jeu coopératif

Il nous a distribué une feuille A4 recto de modèles se rapportant à ces thèmes. Ce support est très dense et synthétise plusieurs ouvrages dont son livre « Agile Software Development: The Cooperative Game« . La suite de la formation était une confrontation de nos expériences issues des ateliers avec ces modèles. L’idée étant d’étudier les pratiques et la théorie vécues par des humains (self-awareness).

Un modèle du thème Gestion de flux, inspiré du lean nous a interpellé. Il considère que l’ensemble des décisions d’une organisation constitue le stock à réduire. Pour fluidifier la chaîne de valeur, il faut localiser les goulots d’étranglement provoqués par une accumulation de décisions non actées.

©Alistair Cockburn

Connaître ses défauts

Nous avons commencé par un atelier en groupe de 3 dans lequel nous devions répondre à la question :

pourquoi l’agilité est-elle moins efficiente que la cascade ou le cycle en V ?

« Je ne vois pas » n’était pas une bonne réponse selon Alistair. Nous avons apprécié ce contre-pied d’entrée de jeu, cette nécessité de faire une auto-critique avant d’aller plus loin. Pour les curieux, sont sorties entre autres réponses :

• il y a plus de réunions avec plus de monde
• répéter c’est coûteux
• payer des gens autonomes et compétents coûte plus cher
• la collaboration est plus difficile que le suivi d’un processus

Savoir découper fin

Nous avons pratiqué l’exercice du carpaccio autour du thème de l’acquisition de connaissance. Il s’agit de découper de manière la plus fine possible une expression de besoin en tranches démontrables, utiles et livrables à l’utilisateur. Nous devions ensuite coder nos histoires avec des itérations de 9 minutes, démo à l’appui. La manière qu’il a eu de présenter le problème nous a mis un peu de pression (portables fermés, silence, déballage des sujets sous blister, annonce du langage choisi par les binômes), et a avivé un esprit de compétition entre les binômes. Il a ainsi pu mettre un peu en évidence nos égos, et nous faire réfléchir avec cette question faussement naïve qu’il a posée lors de débrief :

qu’est-ce que vous avez à y gagner ?

La transmission d’idées c’est compliqué

Nous avons trouvé une autre source de réflexion en faisant l’atelier Draw this drawing game :

• Former des groupes de minimum 3 personnes
• Créer 2 rôles par équipe : les Artistes et les Donneurs d’ordres
• 1 des Donneurs d’ordres sera le Messager, c’est à dire qu’il apportera les instructions aux Artistes
• Les Donneurs d’ordres spécifieront un dessin à reproduire le plus fidèlement possible par les Artistes
• Contrainte : Les Donneurs d’ordres sont séparés des Artistes et le Messager n’a pas le droit de parler aux Artistes. La communication se fera par indication purement textuelle

Nous l’avons fait trois fois de suite avec des images de plus en plus difficile à reproduire. Entre chaque session, nous avons eu 5 minutes pour discuter sur notre mode d’organisation. Lors de la dernière session, nous avons eu le droit de nous regrouper et parler sans indications gestuelles pour dessiner une photo de takoyaki explosé.

Ce que nous en avons retenu ;

• la difficulté de communiquer même en face à face
• savoir être audacieux, quitte à être à la limite des règles (comme disait Alistair « don’t be fired, don’t go to jail, anything else is possible« )

Le jeu de la corde

Petit intermède animé par Géry Derbier, nous avons fait un atelier d’animation/construction d’équipe : prenez quelques personnes (6-8), une corde fermée, demandez-leur de tenir la corde avec les 2 mains, puis de former une figure géométrique les yeux fermés et sans lâcher la corde (même avec une main) en 7 ou 8 minutes. Ex un carré à 6, un triangle équilatéral à 7. À la fin on pose la corde et on discute de ce qui s’est passé. C’est très intéressant de voir les dynamiques qui se mettent en place, les réflexions entre les participants.

Cette formation de un jour et demi nous a donnée l’envie de sortir des limites qu’on s’était nous-même fixés, à l’image de l’engagement de non allégeance d’Alistair qui pousse à l’ouverture de toutes les écoles de pensées. Nous conseillons aux agilistes expérimentés cette formation qui dure 3 jours. Il conseille de la faire 3 fois afin de bien digérer le condensé théorique et d’expérimenter 3 fois les applications avec des personnes différentes.

Bruno et David

Clavier Type Matrix 2030 dvorak

Sous Linux, la commande setxkbmap permet de changer le mapping de son clavier. Ainsi, pour passer en Dvorak avec la composition pour les accents (3 touches pour écrire é : compose (le Alt de droite), apostrophe, e), il faut écrire :

Après une période d’apprentissage, nous sommes assez contents, mais tout le monde n’est pas prêt ou n’a pas forcément envie de faire cet effort.

Dans un premier temps, j’ai donc mappé sur le raccourci Windows + F5 une commande de basculement dvorak/azerty. (NB: La touche Windows s’appelle Start sur mon clavier)

J’utilise LXDE comme gestionnaire de fenêtres, un mapping se rajoute ainsi dans le fichier ~/.config/openbox/lxde-rc.xml :

Le script de bascule ~/bin/switch_dv_fr est le suivant :

(notify-send permet d’afficher une notification dans Linux)

Ce n’était toujours pas satisfaisant, car il fallait taper une combinaison de touches avant de se passer le clavier. Heuereusement, avec Linux il est possible d’avoir deux claviers branchés avec deux mappings différents. Le programme xinput permet de configurer les périphériques d’entrée. Pour obtenir la liste de tous les périphériques branchés sur sa machine, il suffit de taper xinput list. Chez moi cela donne :

On constate que mon clavier Type Matrix possède l’identifiant 12 et mon autre clavier (un HID 046a:0023) le 9. Du coup, maintenant que je connais le nom de mes claviers, je peux trouver leurs identifiants et les passer à setxkbmap grâce à l’option --device. Le script final donne :

Nous pouvons désormais binômer sur mon poste avec deux claviers différents !

Un Sprint passé fut en échec car deux stories sur trois ne furent pas terminées. Le format de la timeline aurait pu être utilisé pour avoir la composante temporelle et trouver les causes racines mais je souhaitais que l’équipe voit l’accumulation des problèmes rencontrés au cours de l’itération.
Il était mercredi soir, le lendemain avait lieu la rétro. Autant dire que cela commençait à sentir le roussi.

Dans le RER, je lisais l’adaptation en manga du roman « Le sommet des Dieux » (merci JP pour le prêt) – roman qui rappelle furieusement certains passages de Premier de cordée de Roger Frison Roche. Outre la beauté des paysages de montagnes retranscrits à travers le crayon de Taniguchi, le récit est également d’une fluidité exemplaire lors des scènes d’escalade. C’est après une « grimpette » qui finit mal que j’ai eu une idée sur le format de rétro :

• [1 min] Former des groupes de 3 ou 4 personnes
• [1 min] Chaque groupe prend un postIt géant et 1 feutre
• [10 min] Chaque groupe trace une courbe de dénivelé (sachant que la courbe idéale est plate).
  • L’axe horizontal représente le temps (l’itération),
  • L’axe vertical représente la difficulté ressentie des obstacles rencontrés.
• [5 min] Chaque groupe explique sa courbe
• [10 min] Sur un tableau blanc, l’équipe va extraire les sujets de discussions et voter (2, 3 ou plus selon les disponibilités)
• [60 minutes] Discussions autour des sujets votés par l’équipe

Jeudi matin, j’ai proposé de diviser l’équipe en deux groupes et d’appliquer le format ci-dessus. Nous avons obtenu des résultats assez homogènes (par souci de compacité de l’article, un seul graphe est affiché ici) :

Les premiers sommets correspondent aux problèmes rencontrés sur deux stories non validées. En effet, elles comportaient des hypothèses fonctionnelles qui n’étaient pas encore confirmées par le client alors que nous les avions engagées sur le Sprint. Nous avons dû relancer (et patienter) avant de pouvoir poursuivre leur développement.

Ensuite le graphe a surtout mis en évidence l’accumulation des problèmes en fin de Sprint ainsi que leur non-résolution :

• Beaucoup de réunions impliquant la présence de l’expert fonctionnel furent programmées en fin de Sprint. Ce dernier a été fortement ralenti dans ses tâches de validation des deux stories en question,
• L’équipe a consommé beaucoup d’énergie dans la réparation des environnements de recette et de benchmarks. L’expert fonctionnel a dû patienter que la plateforme de recette fonctionne pour exécuter certains cas de tests.

Nous avons engagé les actions suivantes :

• Communiquer au client que l’expert fonctionnel n’accepte plus les réunions sur les deux derniers jours du Sprint afin qu’il puisse valider les stories « plus sereinement »,
• Rajouter un statut Non Engageable pour les stories dont le chiffrage se base sur des hypothèses non validées par le client.

En conclusion, ce format est intéressant car il a incité l’équipe à se rappeler de manière chronologique les obstacles rencontrés et à mesurer son ressenti à chaque instant du Sprint. Il est aussi adapté pour des Sprints réussis. En effet, on peut réussir factuellement un Sprint et en avoir « bavé » tout au long de l’itération.

• plus de répétition des touches
• raccourcis clavier cassés
• exécution de commandes impromptues

Pendant un binômage VNC, sur une tâche de développement d’écran Web sous firefox (avec firebug, webdevelopper), mon affichage n’avait plus les couleurs des sites :

Après avoir cherché un moment, j’ai pu rétablir l’affichage original en faisant about:config dans la barre d’url, et puis en double cliquant sur le paramètre

browser.display.use_document_color

le passant de false à true.

Bref, nous sommes allés à la QCon de Londres qui se déroulait entre les 7 et 9 mars. Comme lors d’un précédent retour, l’organisation est toujours aussi impeccable, le lieu agréable, et les intervenants de haut niveau. Vous nous direz, pour le tarif (environ 1200€) c’est normal.

Voici quelques orateurs remarquables :

• Martin Fowler : « grande gueule » comme il se définit lui même, créateur de tendances et de ThoughtWorks
• Philip Walder : professeur d’informatique théorique à l’université d’Édimbourg. Auteur de nombreuses publications autour de la programmation fonctionnelle.
• Damien Katz : créateur de CouchDB et fondateur de Couchbase
• Rich Hickey : créateur du langage Clojure
• Joe Armstrong : créateur d’Erlang, abonné à la QCon
• Dan North : agitateur agile à l’origine du BDD
• Steeve Freeman : pionnier d’XP
• John Allspaw : concepteur des infrastructures Salon, InfoWorld, Friendster, et Flickr. Auteur de The Art of Capacity Planning et Web Operations chez O’Reilly

Par rapport à l’édition de Londres 2010 nous avons remarqué une augmentation importante du nombre de personnes présentes : la salle plénière a été doublée par une extension fermée il y a 2 ans. 2 espaces « lounge » également (pour les collations, cafés, boissons entre les conférences), il y a 2 ans il n’y en avait qu’un.

Dans les temps forts, il y a eu l’affluence inattendue (en tout cas par l’organisation et  l’orateur lui-même) pour la session « Faith, Evolution, and Programming Languages: from Haskell to Java » de Philip Walder. Une salle remplie, avec un grand nombre de personnes assises à même le sol. Pour une gageure : une présentation drôle et passionnante sur le lambda calcul et comment réconcilier le monde Haskell et Java. La première chose à souligner c’est l’utilisation d’un langage « mainstream » comme Java pour parler de la programmation fonctionnelle. Cela évite le débat stérile du langage adopté par les masses versus le langage conceptuellement pur. Mais le plus intéressant c’était l’éclairage de la durée de construction de la connaissance sur ces technologies qui évoluent très rapidement. Une mise en perspective du monde de l’urgence économique avec ses racines culturelles (© Regis Debray). C’est probablement quelque chose comme une quête de sens qui fait le succès de ce type de présentation.

Autre salle bondée, lors la présentation du jeune Zach Holman, hacker chez GitHub, qui venait parler du fonctionnement de GitHub dans le track « Working Distributed ». Une culture nouvelle de société, sans horaires, sans réunions, sans managers (ou très peu), voire même sans bureaux. Hormis les dédouanements entendus en sortant : « c’est bien mais chez nous c’est pas possible parce qu’on a des clients« , ou encore « super mais chez nous avec l’équipe d’intégration ça ne marcherait jamais« , ce qui était intéressant c’était :

• le monde présent, indiquant peut-être un intérêt pour des manières de travailler radicalement différentes
• l’organisation autour d’un objectif : faire en sorte que les employés « kiffent ». Cela rejoint le sujet de l’amélioration de la motivation intrinsèque en promouvant l’autonomie, la vision commune, l’efficacité.

Pour le moins bien, nous avons été déçus par une présentation prometteuse de BigData chez facebook, qui s’est révélée difficilement compréhensible du fait de l’accent de Ashish Thusoo, ainsi que des concepts tellement élevés qu’il n’y avait pas grand chose à en retirer. Egalement, la Timeline chez Twitter avec un Arya Asemanfar semblant s’ennuyer gravement à sa propre présentation.

Lors des différentes présentations, nous avons trouvé que des thèmes étaient prégnants :

Persistance polyglotte, BigData & NoSQL

De petits besoins de persistance de données pour lesquels des fichiers (éventuellement indexés) convenaient, les sites internet ont grossis, utilisant ensuite des bases de données (mysql le plus souvent), qui sont devenues clusters, et puis se sont révélées insuffisantes. L’utilisation croissante d’internet a poussé des sociétés à se concentrer sur des technologies adaptées au stockage d’énormes volumes de données.

Ces technologies ne sont plus polyvalentes comme pouvaient l’être des SGBDR, c’est ce qu’indiquait Siddharth Anand venu parler des infrastructures de données chez Linkedin. Il parlait d’ »ADN des bases NoSQL ». C’est la raison pour laquelle, un gros site pourra être amené à en utiliser plusieurs. C’était la keynote d’introduction de la QCon par Martin Fowler et Rebecca Parson sur « The Data Panorama », très proche de l’article « Polyglot persistence » dont nous avons déjà parlé.

Chez linkedin, ils utilisent oracle, ils ont développé une base clé/valeur qu’ils ont ouvert : voldemeort. Expresso, autre base développée par Linkedin fournit des timelines consistentes (qui se base sur mysql). Ils maintiennent la cohérences entre les copies de données avec des systèmes de réplication comme databus ou kafka cf Linkedin Technology, et les slides de sa présentation.

Une chose intéressante, c’est de voir comment ils ont adapté l’infrastructure à l’existant: oracle. Ils ont aussi utilisé des solutions ad hoc, pour des données temporaires, comme de simples fichiers indexés. Ils travaillent actuellement à supprimer Oracle.

Hadoop, très utilisé dans ce domaine (par linkedin, facebook, twitter, eHarmony, Yahoo!, …), a été présenté par Parand Tony Darugar. C’est le « linux de la manipulation de grands volumes de donnés », i.e. :

• HDFS (hadoop file system) : système de réplication de données avec une API REST
• un framework de calculs distribués
• un modèle de programmation Map/Reduce

Les nuages

3 tracks (série de sessions d’une journée) abordent ce sujet : Cloud architectures, API’s and tools, Plateform as a service (PaaS) – Practical cloud computing for developers, et Cloud development and beyond. C’est d’ailleurs un sujet proche du big data, puisque des infrastructures telles que Hadoop se basent sur la scalabilité horizontale : les données sont réparties sur un grand nombre de nœuds qui sont vus comme une seule machine par les API’s.

Nous avons également entendu parler de cloud dans des sessions n’ayant rien à voir comme « Zero to 10 million daily users in four weeks ; sustainable speed is king« , où Jodi Moran qui développe avec son équipe des jeux pour facebook vantait les mérites de Amazon Web Services (AWS) notamment pour améliorer le time to market et les coûts, en bénéficiant des composants du cloud (queues, bases de données, plateforme web), et en supprimant les opérations.

Mark McGranagham nous a parlé de haute disponibilité à Heroku un cloud pour Ruby (au départ). Ils ont par exemple repris des principes d’Erlang comme l’arbre de supervision, le déploiement par partie, et l’envoi de messages entre processus indépendants (modèle IPC).

L’architecture revisitée

Dans ce nouveau contexte, de haute disponibilité, de répartition des mémoires et des unités de calcul, l’architecture doit s’adapter. Elle doit autoriser le déploiement incrémental, la suppressions de fonction en ligne, la visibilité en temps réel de l’état du système, un time to market constant au fil du temps, et bien sûr supporter l’augmentation de trafic.

Une architecture monolithique, même si elle présente des avantages (la simplicité par exemple), aura du mal dans le temps à pouvoir continuer de satisfaire ces contraintes. C’était le sens de l’intervention de Stéfan Tilkov dans sa session « Breaking the monolith« . Son propos était de considérer un système comme un ensemble de connexions/compositions de fonctions, et de voir le développement de ce système comme une redéfinition permanente des frontières des fonctions : la « modularisation ».

Jesper Richter-­Reichhelm de Wooga (jeux pour facebook) explique également comment la collaboration dev-op a pu influencer l’architecture et leur permettre de passer d’une architecture classique ruby/mysql (webapps stateless, état en base) vers du erlang stateful côté serveur (pour éviter les aller-retours en base), déléguant à des workers en ruby en communiquant avec du zeroMQ et en introduisant une base Redis. Cela leur permet de tenir 14 milliards de requêtes par mois.

Des changements aussi profonds sont des remaniement d’architecture, sujet abordé par Michael Stall dans « Nothing is Permanent except Change – How Software Architects can embrace Change ». Nous avions aussi présenté une session sur ce sujet aux XPdays Bénélux et à l’agile conférence.

Enfin, Dan North approche l’architecture différemment : en terme de compromis.

Les compromis en informatique

C’est un sujet qui est revenu dans plusieurs présentations et est au cœur de NoSQL. Dan North avec ses qualités de showman et son sens de la provocation remettait en cause des domaines de l’ordre du sacré de l’agilité comme le TDD, l’automatisation du build ou le principe DRY, en éclairant toute décision du point de vue du compromis :

• pour le TDD : le coût v.s. la non régression. Veut-on un feedback des défauts ou un feedback des utilisateurs ?
• DRY : la factorisation v.s. le couplage
• automatisation du build : rapidité et absence de tâches répétitives v.s. la souplesse et la compréhension de l’application

Le théorème de Brewer (CAP) précise que dans une architecture distribuée, on ne peut pas avoir à la fois des données consistantes (Consistency), toujours disponibles (Availability), et réparties (Partition tolerance). NoSQL et le cloud dont on a beaucoup entendu parler à cette QCon sont donc aussi une histoire de compromis.

Entraînement à l’échec

Un dernier thème était récurrent, c’était l’impossibilité d’éviter l’échec. Lors de la présentation sur Heroku, Mark McGranagham a insisté sur le fait qu’ils avaient beaucoup appris de leurs échecs. John Allspaw lors de la keynote du dernier jour (resilient response in complex system) nous disait que facebook, twitter, amazon, blackberry, avaient eu des échecs en production. Quelle que soit la qualité des devs, ops, des infrastructures, des processus de construction d’un service, des méthodes, cela arrivera. Il faut s’y préparer. « Getting Real About Distributed System Reliability« , un excellent article d’un lead developer de Linkedin explique en détail pourquoi même les systèmes répartis comme HDFS sont sujets aux pannes.

John Allspaw donnait les pistes suivantes :

• apprendre d’autres domaines qui ont de l’expérience de gestion d’incident dans des domaines où la haute disponibilité est vitale : le contrôle aérien, l’aéronavale, les centrales électriques par exemple
• définir des procédures, des responsabilités différentes, lors des incidents, et s’entraîner : faire des simulations, maîtriser tous les outils de crise (bash, wireshark, …)
• mettre en place une organisation apprenante, en sortant d’une culture du reproche, pour se concentrer sur les faits et les comportements

Un entraînement radical est d’échouer continuellement pour s’entraîner, c’est ce que font Netflix avec le Chaos Monkey. C’est un démon qui tue aléatoirement des instances ou services au sein de leur architecture, afin de tester la résilience du système

Voici les aspects qui nous ont marqués, si vous avez participé à la QCon et que vous pensez qu’il manque un point essentiel, merci de nous faire un feedback.

Notes :

Jour 1:

• QCon keynote
• Breaking the monolyth
• High avalability at Heroku
• how software architects can embrace change
• sustainable speed is king
• decisions, decisions

Jour 2:

• Simple made easy
• The evolution of Paas
• architecture for failure
• Timelines @ Twitter
• big data architecture at facebook
• the monkeys and the firehose

Jour 3:

• resilient response in complex systems
• faith evolution and programming languages from Haskell to Java
• how github works
• ain’t no cure for the distributed blues
• data infrastructure @ linkedin
• Hadoop Scalable infrastructure for big data

Première chose, l’organisation, impeccable avec ces bonnes idées : tableaux de programme de la journée avec des cartes à emporter. Pochette transparente de taille A6 avec le programme et de même taille que les cartes. Le lieu est un peu perdu à 30km au nord de Bruxelles, mais c’est dans la nature, les salles sont spacieuses avec de la lumière.

« Rise and Fall of an Agile company » par Jan De Baere. J’ai retenu que dans une société de service, l’agilité a été mise en place avec difficulté pendant 3 ans. À force de travailler ensemble, en utilisant des outils issus de l’agilité, ils étaient capable de dire en allant chez un client

Ah! Il y avait quelqu’un de chez nous dans cette pièce il y a peu

Ils ont créé une identité d’entreprise. Puis le directeur a été changé et en peu de temps (à l’échelle de la semaine), elle a été perdue. Pour Jan De Baere, cette identité était basée sur la confiance. C’est la raison pour laquelle elle était fragile. Cela m’a interrogé sur les capacités d’apprentissage d’une organisation. Comment capitaliser la connaissance d’une entreprise au delà de la construction d’un lien de confiance ?

2 sessions intéressantes de Gojko Azic : « Visualising Quality » et « Product Management using Effect Mapping« . Il nous dit que l’absence de bug est différent de la qualité. Ce qu’il cherche à faire c’est mettre en évidence la distance entre l’informatique et le métier. On se rapproche du lean et du PDCA en choisissant des métriques et en expérimentant des solutions, même si elles ne sont pas informatiques. Il utilise 2 outils pour cela :

• ACC matrix : une mise en regard des risques (métier) de features avec leur couverture en tests. De cette manière on peut optimiser le retour sur investissement des tests
• Effect Mapping : il s’agit d’une mind-map avec au centre le « pourquoi » avec objectif chiffré, puis l’étage suivant est le « qui » peut nous aider, puis « comment » et « quoi ». Une solution informatique n’intervient éventuellement qu’avec le quoi. Il propose de faire l’atelier avec les gens du métier en petits groupes pour stimuler la créativité de chacun

Ce qui m’a plu dans ces session de Gojko Azic, c’est la recherche de l’efficacité fonctionnelle, quitte à ne pas faire de programme informatique, ou à en faire le moins possible (ex: meilleur taux coût/valeur d’une appli SMS pour la réservation de place de spectacle par rapport au développement d’une application iphone).

« Test Drive your application end to end » de Lars Vonk et Sander Nieuwenhuizen. C’est une présentation relative au livre de Nat Pryce « Growing Object-Oriented Software Guided by Tests ». Cette problématique de tests fonctionnels bout en bout est récurrente. Nous sommes d’ailleurs dans ce sujet avec un nouveau projet qui démarre actuellement. Notre soucis qui n’a pas été adressé par cette présentation c’est la possibilité de lancer 2 navigateurs, et de tester les interactions entre les 2.

« Jaccob’s Ladder » par Arnaud Bailly et Christophe Thibaut. Une présentation de la théorie des Catégories. Ça m’a mis la tête à l’envers, comme quand on m’explique les monades. Maintenant je sais au moins d’où ça vient. J’ai bien aimé l’application de cette théorie à de l’algorithmique du monde objet java. En plus du lien sur l’origine des concepts de programmation fonctionnelle, j’ai trouvé que cela procurait une nouvelle approche du design.

Plus tard, par curiosité, j’ai regardé quelques projets écrits en Haskell. Je suis alors tombé sur xmonad, un gestionnaire de fenêtres spartiate, mais avec des idées intéressantes, comme l’agencement automatique. J’ai aussi découvert la bibliothèque Parsec, qui permet d’écrire des parseurs très simplement, et dont la lecture du code m’a convaincu que la notion de fonction était une abstraction vraiment puissante.

Lors de mon premier contact avec du code Haskell, je n’ai pas été très enthousiaste :

• Cela ne ressemblait à aucun langage que je connaissais, on aurait dit une peu de l’anglais mathématique.
• Après quelques tentatives de modification du code, je me faisais insulter par le compilateur…

Mais ma curiosité était piquée. J’ai toujours été intrigué par les langages que je ne comprends pas. De plus, il y avait une promesse de concision, vu qu’il me semblait que l’on puisse faire beaucoup avec peu de lignes.

Qu’est-ce que Haskell ?

Haskell est d’abord un langage de comité, composé de mathématiciens et d’informaticiens désireux de faire des expériences en programmation fonctionnelle, et aussi de créer un langage utilisable pour écrire des applications. Le langage étant en quelque sorte expérimental, il est en perpétuelle évolution. Impossible donc d’écrire une documentation ou un livre sans être instantanément démodé. Haskell est donc stabilisé en 1998 en tant que Haskell 98. Ce qui met fin également au comité, mais pas à la vie du langage, bien au contraire.

Quelques traits caractéristiques du langage :

• Fonctionnel : l’abstraction de base est la fonction.
• Pur : pas d’effets de bord.
• Paresseux (lazy) : l’évaluation se fait lorsque l’on a besoin d’une valeur, à la différence de la plupart des autres langages, où les arguments d’une fonction sont évalués avant l’appel de celle-ci. Ceci permet par exemple de manipuler des structures de données de taille infinie.

Ces caractéristiques en font un langage singulier, pas forcément facile à appréhender. Le coté fonctionnel pur en font un langage de choix pour la programmation parallèle, bien qu’il n’ai pas été conçu pour cela au départ. Certaines start-up choisissent également ce langage en misant sur un avantage décisif par rapport à la concurrence. Ainsi, Tsurucapital annonce sur sa page d’accueil:

We use the Haskell programming language almost exclusively since we believe it gives the best combination of high-level cleanliness, execution safety and high performance.

Haskell est bien entendu aussi utilisé par des mathématiciens, mais excelle dans des taches plus communes, comme l’écriture de DSL, ou plus récemment dans la programmation web (Yesod, Snap)

Environnement de développement

J’utilise ghc, le compilateur Haskell le plus utilisé et les plus avancé à l’heure actuelle. Ghci est livré avec ghci, un interpréteur Haskell bâti autour de ghc. Il existe très certainement un package pour votre OS.

Si vous le souhaitez, vous pouvez essayer d’autres environnements:

• Haskell Platform qui est constitué de ghc et d’un ensemble de bibliothèques d’usage fréquent.
• Hugs est un environnement qui est aussi populaire dans le monde des débutants en Haskell.

Après avoir installé ghc (ou Haskell Platform), vous pourrez exécuter un fichier en utilisant la commande runhaskell, ou bien le charger dans d’interpréteur en utilisant la commande ghci.

Une fois dans l’interpréteur, le Prelude (ensemble des bibliothèques de base) est chargé et vous vous retrouvez en mode interactif.

Fonctions

En Haskell, une fonction prend en entrée des valeurs, et retourne une
valeur (qui peut bien entendu être une fonction). Une fonction ne peut pas provoquer d’effets de bord. Par conséquent, le résultat d’une fonction ne dépend que de ses paramètres. En d’autres termes, la notion d’état n’existe pas. La déclaration d’une fonction consiste en une équation, signifiant que la partie à gauche du signe = est équivalent à la partie droite.

La commande :t vous sera certainement utile dans l’interpréteur. Elle permet d’afficher le type d’une expression. Par exemple, si je veux connaître le type de la fonction length :

Cela se lit comme suit: « Quel que soit le type a, la fonction length prend en argument une liste de a, et retourne un entier ».

Transformer les éléments d’une liste

Une opération très fréquente lorsque l’on programme est de parcourir une liste en appliquant une fonction à chacun de ses éléments. C’est ce que permet la fonction map.

La description du type nous montre que les arguments sont :

1. Une fonction qui, pour toute valeur de type a, retourne une valeur de type b
2. Une liste de valeurs de type a

La valeur de retour est une liste de valeurs de type b.

Dans notre exemple où l’on multiplie par deux les éléments d’une liste d’entiers, les types a et b se trouvent être égaux.

Filtrer une liste

Un autre traitement très fréquent en programmation est de filtrer les éléments d’une liste selon un prédicat. C’est ce que propose la fonction filter.

La lecture du type nous informe que les arguments sont :

1. Un prédicat, c’est à dire une fonction à un argument qui retourne un booléen
2. Une liste d’éléments

On constate aussi que les éléments de la liste résultat sont de même types que les éléments de la liste en paramètre. Ce qui est conforme à ce que nous attendons : la liste est simplement filtrée, les valeurs ne sont pas transformées.

Fonctions anonymes

Il est possible de déclarer une fonction sans nom. Par exemple, pour une fonction qui double la valeur de son argument, on peut écrire \ x -> 2 * x. Ce qui est pratique lorsque l’on a besoin d’une fonction, mais que l’on ne veut pas prendre la peine de la définir, parce qu’elle est très petite ou triviale.

A ceux qui se poseraient la question, le caractère \ a été choisi pour la définition de fonctions anonymes car il ressemble (un peu) au caractère λ.

Style « sans point » (pointless)

La fonction (.) permet de composer deux fonctions. Il faut lire le point comme le « rond » en mathématiques. Ainsi f(g x) est équivalent à (f . g) x.
De plus, une fonction s’écrivant h x = (f . g) x peut aussi s’écrire « sans point » h = f . g
Une source de confusion (et aussi de blagues) vient du terme pointless. Pourquoi appelle-t-on ce style « sans point », alors que justement on utilise le point ? En réalité, dans cette expression, le point ne fait pas référence au caractère, mais à l’argument d’une fonction (en anglais mathématique, on appelle cela le point). Et effectivement, dans une expression pointless, on n’écrit pas les arguments d’une fonction lorsqu’on la définit.

Compréhension de liste (list comprehension)

Les compréhensions de liste sont déjà connues des développeurs Python ou Erlang. Les programmeurs Scala pourront aussi trouver des similarités avec le for de ce langage.

La compréhension de liste permet de transformer et de filtrer des listes dans une même expression. On peut le voir comme une combinaison de filter et de map.

La syntaxe est très inspirée de la notation de définition des ensembles en mathématiques. Par exemple, nous définissons ici la « liste des élément x multipliés par 10, pour tout x dans la liste des entiers de 1 à 10 tels que x est impair »:

Les compréhensions de liste sont un élément syntaxique très intéressant pour l’expressivité et la clarté du code. Nous n’avons fait ici qu’effleurer les possibilités qu’elles offrent.

Pour aller plus loin

• Real world Haskell, un livre en ligne assez didactique.
• Le wiki book Haskell, une bonne référence pour apprendre.
• Learn You a Haskell for Great Good!, très progressif, mais un peu trop verbeux à mon avis.

Si vous avez apprécié cet article, sachez que d’autres sont en préparation. Nous aborderons la déclaration des type de données afin de modéliser une version simplifiée de réseau social, ainsi que d’autre manière de manipuler les listes.

Le mouvement NoSQL est issu d’un besoin de stockage de données important, scalable, performant, et robuste sans avoir toutes les fonctionnalités d’une base relationnelle. Ces besoins ont été ceux de gros sites comme google, facebook, twitter, amazon, linkedin, sourceforge, github…

Si certains discours ont été excessifs au départ (comme souvent lors d’une inversion de tendance), c’est en réaction à des années de domination du monde relationnel dans le domaine de la persistance, et aux difficultés des développeurs à s’interfacer avec ces systèmes. A présent beaucoup de produits ont été développés offrant de réelles alternatives au monde des SGBDR :

• le stockage par famille de colonnes (hbase, cassandra, hypertable)
• bases orientées document (MongoDB, CouchDB, Terrastore)
• bases clé-valeur/tuples (Redis, Riak, Maxtable)
• bases orientées graphe (Neo4J, HyperGraphDB)

Et les autres types de bases qui existaient avant le mouvement NoSQL comme bases objets (Versant, Objectivity), les bases XML (eXist, Qizx), qui bénéficieront peut-être d’un regain d’intérêt. Tant mieux. Au sujet des précurseurs, nous pouvons citer d’ailleurs BerkeleyDB (1986), base clé-valeur utilisée sur un nombre de projet impressionnant, et mnésia, base de tuples/records erlang.

Grâce à ce mouvement, aux nouveaux produits, aux besoins des sites internet de gros volume, au delà du mouvement NoSQL, une nouvelle vision du stockage des données apparaît : c’est le fractionnement des modes de stockage vers une persistance aux formes multiples. La programmation polyglotte représentait le choix du meilleur langage en fonction du besoin, nous avions vu cela par exemple à la Qcon en 2010. La persistance polymorphe, consiste à choisir le meilleur moyen de stockage de données en fonction de son usage, et d’en avoir éventuellement plusieurs pour un seul module applicatif.

Par exemple twitter a créé un module de chargement de page web pour les urls présentes dans les tweets. Appelé SpiderDuck, il utilise HBFS construit sur Hadoop, lui-même fondé sur Hbase, et Cassandra. HBFS sert à stocker les informations récupérées sur les sites pointés par les url. Cassandra sert à stocker les métadonnées des url. A noter également qu’ils utilisent memcached (qui est une structure de données clé/valeur en mémoire), pour cacher les fichiers robots.txt des sites.

D’autres fonctions d’une application paraissent assez proches des modèles proposés par ces bases. Par exemple :

• Redis pour le stockage de paramètres de session pour ses performances, sa simplicité et le format adapté clé/valeur
• MongoDB pour l’aggrégation de logs car il fait du sharding (partitionnement de données par enregistrement pour les répartir sur plusieurs serveurs). Également pour le stockage de modèle (au sens MVC) en Json
• Neo4j pour stocker des données sociales (ex facebook avec les graphes par « amis »)
• Riak pour stocker un grand nombre de données sensibles avec réplication sur plusieurs noeuds (cf la notion de Eventually Consistent)

Cette multiplicité technologique a un coût en complexité, comme l’introduction de plusieurs langages dans un projet. Martin Fowler l’évoque dans Polyglot Persistence, un très bon article sur le sujet. Mais cet investissement sera remboursé par l’intégration plus aisée de ces bases avec le code, la scalabilité horizontale des données, la performance, et les possibilités offertes en terme de découplage entre différentes parties du code.

Récemment nous avons travaillé sur la séparation de nos binaires et de nos configurations. Nous avons cherché comment stocker les paramètres extrinsèques de nos applications (ceux qui sont gérés par les opés: urls, nom d’hôtes, ports, etc.). Nous avons exploré plusieurs possibilités (fichiers sous git, cassandra, mongodb). Nous n’avons pas encore fait le choix, mais il est peu probable que nous utilisions au final notre base mysql. En effet, le mode relationnel est assez éloigné de l’état actuel des paramètres qui sont en fichiers properties. Et puis la gestion de l’historique de nos paramètres est à faire par programmation avec ce mode de stockage (alors que certaines bases apportent cette fonction en natif).

Nous avons testé MongoDB qui permet de stocker du json avec plusieurs clés (en javascript) :

db.configurations.insert({
     env: "itg",
     version: "1.0.9",
     appli: "pse",
     params: {"param1":"valeur1", "param2": "valeur2"}
});

et faire des requêtes :

db.configurations.find({'env': 'itg'});

Autre solution que nous avons exploré, c’est Redis pour conserver des structures de données comme des listes, des sets triés, etc. Nous évitons ainsi le mapping qui existait entre les paradigmes du monde des langages de programmation et du monde relationnel. Retrouvez une courte introduction à Redis sur barreverte.

C’est donc de nouvelles perspectives qui sont ouvertes. Il ne s’agit pas de mettre les bases relationnelles au rebut, mais de les utiliser pour des données « froides », dont les accès sont peu fréquents ; ou encore pour des données structurées, conservées sur une durée importante, et dont nous ne connaissons pas l’usage, comme le reporting, les données décisionnelles, juridiques, financières.

La prochaine fois que vous avez besoin de données persistantes, à vos explorations et prototypes, utilisez la meilleure base pour votre environnement (langage de programmation utilisé, structures à stocker, expressivité et souplesse offerte par le langage de requête, utilisation d’index, architecture plateforme, etc.) ! Nous essayerons de parler plus précisément de ce sujet sur ce blog.

Le mouvement NoSQL (comme Not Only SQL), nous propose des alternatives : bases clefs-valeurs, bases orientées document, bases orientées colonnes, bases orientées graphe ; Cassandra, MongoDB, Redis, Dynamo, Riak, Big Table, Voldemort sont souvent utilisés par les sites à gros trafic et à tendance « sociale » qui font le buzz : Google, Amazon, Facebook, Twitter, LinkedIn.

Aujourd’hui, nous allons explorer redis, ses principes, son API et ce qu’on peut en faire. Dans un prochain article, nous verrons une utilisation typique en écrivant un clone de twitter simple et sans prétention.

Redis est une base de données open source de type clefs-valeurs mono-threadée. C’est en gros une grosse HashMap, mais avec des données structurées que nous allons détailler : des chaînes de caractères, des listes, des hash, des set, des set triés. L’utilisation de redis est très simple et la vitesse de lecture et d’écriture est vertigineuse (plus de 100 000 insertions par seconde sur mon petit poste de travail). Toutes les opérations sont atomiques, vous ne risquez pas d’avoir des soucis de concurrence d’accès à vos données. Par contre, il est impossible de requêter les valeurs comme on le fait habituellement avec un WHERE en MySQL, mais avec un peu d’astuce, d’habitude et de dénormalisation de vos données, on arrive très vite à nos fins en demandant « la bonne clef ». Il faut également savoir que vous êtes limités par la taille de votre RAM car redis garde toutes ses données en mémoire (c’est aussi pour cela que c’est très rapide). Ne vous effrayez cependant pas, redis sauvegarde régulièrement (avec la possibilité d’un paramétrage poussé) ses données sur le disque et supporte également la réplication sur de multiples serveurs.

Si vous avez besoin de sauvegarder de grands volumes de données, vous pouvez stocker les données les moins lues dans un MySQL et garder les données volatiles et fréquemment lues dans redis, c’est même une configuration souvent rencontrée actuellement

Enfin, l’installation de redis est très simple : sur Ubuntu, le paquet s’appelle redis-server. Le serveur démarre immédiatement l’installation et un client en ligne de commande est  disponible : redis-cli. C’est avec cette interface que nous allons faire nos tests et découvrir redis. Vous pouvez également utiliser redis-bench pour constater la vitesse de redis sur votre machine. Parcourons dès à présent les différents types de données de stockage.

String

C’est le type le plus simple : à une clef, on peut y associer une valeur. Cette valeur peut-être une string de tout type (json, valeur d’une image jpeg), mais aussi un entier. La limite est de 1 Go. Les principales commandes associées sont SET, GET, INCR, DECR, et GETSET.

redis 127.0.0.1:6379> SET compteur 10
OK
redis 127.0.0.1:6379> INCR compteur
(integer) 11
redis 127.0.0.1:6379> INCR compteur
(integer) 12
redis 127.0.0.1:6379> GET compteur
"12"
redis 127.0.0.1:6379> GETSET compteur 123
"12"
redis 127.0.0.1:6379> GET compteur
"123"

redis 127.0.0.1:6379> SET clef valeur
OK
redis 127.0.0.1:6379> GET clef
"valeur"

Listes

Les listes de redis sont des listes liées (linked list). Cela veut dire que même si vous avez des millions d’enregistrement dans une liste, cela sera toujours aussi rapide d’insérer un élément en tête ou en queue de liste. La contrepartie de cette vitesse est l’accès à un élément dans la liste par son index. Les utilisateurs de ArrayList ou LinkedList en java connaissent bien cette différence. Les principales commandes commencent en général par L comme List et sont RPUSH et LPUSH (et leurs amies xPOP) qui permettent respectivement d’ajouter un élément en fin ou en début de liste, LRANGE pour obtenir une partie des éléments de la liste, LINDEX pour obtenir un seul élément de la liste, LLEN pour obtenir la taille de la liste.

Comme vous pouvez le remarquer, le résultat sort dans l’ordre dans lequel les données ont été rentrées, par besoin de ORDER BY de MySQL.

Hash

Une hash permet de stocker dans un même enregistrement plusieurs couples de clef/valeurs. Les commande de hash commencent… par un H comme Hash. On y trouve (vous avez déjà deviné je parie) HSET, HGET, HLEN, mais aussi HGETALL pour obtenir tous les couples clef-valeur, HINCRBY pour incrémenter un compteur dans la hash, HKEYS et HVALS pour obtenir toutes les clefs ou valeurs et HDEL pour faire le ménage.

redis 127.0.0.1:6379> HSET nosql redis "clef/valeur"
(integer) 1
redis 127.0.0.1:6379> HSET nosql mongodb document
(integer) 1
redis 127.0.0.1:6379> HSET nosql riak "fault tolerant"
(integer) 1
redis 127.0.0.1:6379> HGET nosql redis
"clef/valeur"
redis 127.0.0.1:6379> HGETALL nosql
1) "redis"
2) "clef/valeur"
3) "mongodb"
4) "document"
5) "riak"
6) "fault tolerant"
redis 127.0.0.1:6379> HKEYS nosql
1) "redis"
2) "mongodb"
3) "riak"
redis 127.0.0.1:6379> HVALS nosql
1) "clef/valeur"
2) "document"
3) "fault tolerant"
redis 127.0.0.1:6379> HLEN nosql
(integer) 3

Sets

Les Sets sont des collections d’objets non ordonnées. Les commandes commencent toutes avec un S comme Set, parmi celles-ci on trouve SADD pour ajouter une valeur à un set, SCARD pour obtenir la taille (cardinalité) d’un set, et surtout les commandes SINTER, SUNION, SDIFF qui permettent respectivement d’obtenir l’intersection, l’union et la différences entre 2 sets. Ces commandes existent en version « STORE » ; ainsi SINTERSTORE permet de stocker dans un nouveau set l’intersection de 2 autres. Dans l’exemple suivant, nous allons modéliser ce qui se trouve au supermarché du coin et ce que j’ai dans mon frigo (oui, certains éléments peuvent surprendre) :

redis 127.0.0.1:6379> SADD supermarche pommes
(integer) 1
redis 127.0.0.1:6379> SADD supermarche poires
(integer) 1
redis 127.0.0.1:6379> SADD supermarche scoubidous
(integer) 1
redis 127.0.0.1:6379> SADD monFrigo beurre
(integer) 1
redis 127.0.0.1:6379> SADD monFrigo pommes
(integer) 1
redis 127.0.0.1:6379> SADD monFrigo TddByExample
(integer) 1
redis 127.0.0.1:6379> SCARD monFrigo
(integer) 3
redis 127.0.0.1:6379> SINTER supermarche monFrigo
1) "pommes"
redis 127.0.0.1:6379> SUNION supermarche monFrigo
1) "scoubidous"
2) "pommes"
3) "poires"
4) "TddByExample"
5) "beurre"
redis 127.0.0.1:6379> SDIFF supermarche monFrigo
1) "scoubidous"
2) "poires"

Sets triés

Les sets triés (Sorted Set) sont similaires à des Sets mais ajoutent une notion de score aux valeurs ajoutées aux Set, ce qui permet de faire des tris. Les commandes commencent toutes par Z comme Zorted Set. On trouve donc les Zéquivalents des commandes précédentes, à savoir ZADD, ZCARD, ZINTER, ZUNION, ZDIFF mais aussi ZRANGE, ZRANGEBYSCORE et ZRANK qui tirent parti des scores des données stockées.

redis 127.0.0.1:6379> ZADD savants 1564 "Galilee"
(integer) 1
redis 127.0.0.1:6379> ZADD savants 1643 "Isaac Newton"
(integer) 1
redis 127.0.0.1:6379> ZADD savants 1571 "Johannes Kepler"
(integer) 1
redis 127.0.0.1:6379> ZADD savants 1879 "Albert Einstein"
(integer) 1
redis 127.0.0.1:6379> ZADD savants 1858 "Max Planck"
(integer) 1
redis 127.0.0.1:6379> ZADD savants 1887 "Erwin Schrodinger"
(integer) 1
redis 127.0.0.1:6379> ZRANGE savants 0 -1
1) "Galilee"
2) "Johannes Kepler"
3) "Isaac Newton"
4) "Max Planck"
5) "Albert Einstein"
6) "Erwin Schrodinger"
redis 127.0.0.1:6379> ZREVRANGE savants 0 -1
1) "Erwin Schrodinger"
2) "Albert Einstein"
3) "Max Planck"
4) "Isaac Newton"
5) "Johannes Kepler"
6) "Galilee"
redis 127.0.0.1:6379> ZREVRANGE savants 0 -1 WITHSCORES
 1) "Erwin Schrodinger"
 2) "1887"
 3) "Albert Einstein"
 4) "1879"
 5) "Max Planck"
 6) "1858"
 7) "Isaac Newton"
8 ) "1643"
 9) "Johannes Kepler"
10) "1571"
11) "Galilee"
12) "1564"

Ce qui est intéressant, c’est de pouvoir faire des requêtes sur les scores du set :

redis 127.0.0.1:6379> ZRANGEBYSCORE savants -inf 1800
1) "Galilee"
2) "Johannes Kepler"
3) "Isaac Newton"
redis 127.0.0.1:6379> ZRANGEBYSCORE savants 1800 2010
1) "Max Planck"
2) "Albert Einstein"
3) "Erwin Schrodinger"

On peut imaginer des tas d’applications de calcul de poids de tags dans un blog par exemple (avec in ZINCRBY du nombre d’occurrences du tag dans un corpus) ou à des fins de statistiques. Toutes ces commandes de lecture/écriture sont très rapides.

Bref !

A cette courte présentation, il faudrait ajouter les possibilité suivantes que nous n’explorerons pas dans le cadre de cet article :

• une API Pub/Sub qui permet de poster et de recevoir des messages sur des « channels » ; cela peut paraître hors sujet mais cela permet d’avoir un petit système de messaging pour pas cher (pas besoin d’installer un serveur RabbitMQ en plus de votre base Redis). Pourquoi pas ;
• donner une durée de vie à une clef (avec les commandes EXPIRE clef secondes ou EXPIREAT clef timestamp) : permet de laisser redis purger ses données sans avoir à écrire des scripts de purge ou de l’utiliser comme cache distribué ;
• passer une série de commandes dans une transaction (MULTI et EXEC) avec la possibilité de l’éxécuter seulement si la clef change (avec WATCH à la place de EXEC);
• utiliser plusieurs bases de données (16 disponibles) avec SELECT n ;
• brancher un ou plusieurs slaves (tous sur le master ou les uns à la suite des autres, en cascade) : la réplication est extrêmement rapide ;
• scripter des commandes dans le serveur avec le langage Lua, ce qui nous permet d’apprendre un nouveau langage par la même occasion !

Si vous avez de très nombreux accès en lecture par rapport à vos écritures, ce qui est le cas pour une vaste majorité de sites tel que twitter, vous pouvez multiplier les slaves pour accéder à vos données en lecture de manière très rapide et ne garder qu’un seul master pour toutes vos écritures. Ainsi, vos temps de réponses seront très faibles et vos utilisateurs seront époustouflés par la vitesse de votre site.

Enfin, comme redis est open source, on constate rapidement que :

• c’est bien écrit
• le code est lisible
• c’est court (moins de 20 000 lignes de C)
• il y a des tests unitaires

Tout ceci rassure, donne confiance dans un produit qui est encore amené à évoluer (scripting, clustering, réplication, performances…). La blogosphère parle souvent de redis, des tutoriaux sont publiés régulièrement et de nombreux clients sont supportés.

Clients

Il existe de nombreux clients redis dans de nombreux langages, vous trouverez forcément votre bonheur :

• C / C++ / C#
• Clojure
• Java
• Scala
• Erlang
• Ruby
• Python
• Haskell
• Go
• Lua

Quelques liens :

• le site de redis, avec sa documentation et son code source
• Short term Redis plans où l’auteur détaille l’avenir de Redis
• How to take advantage of Redis by just adding it to your stack où l’auteur de Redis donne de nombreux exemples d’utilisation
• l’excellent article Polyglot Persistence, par Martin Fowler
• the little redis book