Note de lecture : L’art de devenir une équipe agile, par Claude Aubry, illustré par Etienne Appert

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Une réussite !

Je pense qu’à un moment donné, Claude Aubry en a eu marre d’être enfermé dans Scrum. Au bout de 5 éditions de son best-seller, on le serait à moins. Ici c’est de culture agile dont il est question (bien que le cadre s’appuie très fortement sur Scrum).

Le format de l’ouvrage est atypique : la taille est large mais ne compte que 170 pages, bien que le grammage du papier laisse penser qu’il en contient 250. L’impression est bichromique, mais surtout les illustrations d’Etienne Appert se taillent la part du Lion. On aurait presque l’impression de lire « Martine s’essaie à l’agilité ». Si le texte de Claude forme la portion congrue (bon j’exagère un peu), il a en fait déployé tout son talent, car on savait déjà qu’il savait écrire, pour condenser son propos en peu de mots sans qu’il en coûte en fluidité de lecture. Un magnifique tour de force !

Le texte compte 7 chapitres et débute par une question cruciale : pourquoi devenir agile ? On y parle valeurs et principes, raison d’être et sens, le tout saupoudré d’un peu d’historique. Mais on y évoque aussi le faux-agile et une démarche pour réellement devenir agile s’appuyant sur l’agile fluency. Le tout est abondamment illustré, d’images mais aussi d’exemples, avec les « lapins agiles ». C’est excellent.
Le second chapitre aborde la question cruciale de l’équipe. Et l’auteur de nous proposer l’acronyme TAPIS pour résumer les propriétés d’une équipe agile. Claude Aubry aura été très créatif en acronymes tout au long du livre et ils sont très bons. Claude, c’est un peu notre Mike Cohn français. L’auteur s’appuie sur Scrum pour aborder les rôles dans l’équipe, alors même qu’il nous avait dit qu’il serait agnostique. L’angle se défend car l’alternative serait d’être trop abstrait. J’aurais aimé deux mots sur « compétences versus rôles », mais j’accorde un bon point à la section consacrée à la confiance. Encore une fois le chapitre est remarquable de clarté et d’efficacité, mais c’est vrai pour tout le livre.

Lire la suite →

Note de lecture : Production-Ready Microservices, par Susan J. Fowler

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une vue bien trop généraliste des microservices depuis un point de vue « ops ».

J’étais impatient d’entamer la lecture de ce petit volume (il compte 130 pages pour sa partie principale). En effet bien qu’il s’agisse d’un texte de plus sur les microservices, il le fait avec une optique « ops » sous la plume de Susan Fowler, à l’époque SRE chez Uber. Dès l’avant-propos, l’auteur nous prévient : on ne rentrera pas dans les détails ici qui nous conduiraient trop loin. Il s’agit de poser les principes généraux et génériques qui permettent l’opérabilité d’une architecture microservices.

Pour mener à bien cette mission, le livre est découpé en 7 chapitres plus 2 annexes. L’entrée en matière s’intitule sobrement « microservices » et pèse 25 pages. Elle ne détaille pas les principes d’un microservice à la Sam Newman. Ici, il est plutôt question de scaling et surtout de présenter le modèle en 4 couches de l’écosystème microservices, qui servira de trame aux différents chapitres. Le chapitre 2 construit pour sa part la structure des chapitres restant, en évoquant la notion de « production ready ». Pour Susan Fowler, cela regroupe un ensemble de propriétés : stabilité, fiabilité, scalabilité, tolérance aux pannes, performance, monitoring et documentation. C’est déjà ici que l’on perçoit le regard du SRE : l’auteur prône la standardisation en toute chose ! Certes, elle évoque la promesse d’hétérogénéité prônée par l’approche microservices mais préfère refermer celle-ci au nom de l’opérabilité !

Le chapitre 3 s’attaque à la stabilité et à la fiabilité, les deux premières propriétés évoquées au chapitre précédent. La cible du propos est d’abord la standardisation des cycles de développements et du pipeline de déploiement. Bien que le terme « standardisation » me donne des frissons, j’appuie le propos développé ici. Un bon point pour le développement des environnements de stagging, partiel ou complet que je trouve pour la première fois bien évoquées ici. Scalabilité et performance sont au menu du chapitre 4. Le propos reste très général sur la notion de scaling, abordant les aspects qualitatifs et quantitatifs, ainsi que la gestion des ressources contraintes. Le capacity planning est brièvement abordé, j’attendais mieux d’un livre labellisé ops. L’efficience du modèle de tâches, du choix du langage ou des caractéristiques des bases de données sont tout autant mentionnées. Un chapitre décevant et frustrant.

Lire la suite →

Note de lecture : The Cathedral & The Bazaar, par Eric S. Raymond

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un texte historique, mais qui a mal résisté à l’assaut du temps

Voici un livre assez court : environ 200 pages en petit format. Il tire son titre du premier essai de ce volume qui en compte 4. J’ai parié l’avoir fini rapidement, j’aurais perdu !

Le premier essai est une sorte de mise en bouche : « a brief history of hackerdom » compte seulement 19 pages. Ce prologue retrace l’histoire des hackers ou des « real programmers » auxquels l’auteur les assimile. Le vrai hacker refuse de se laisser enfermer dans une logique de vendeurs. Ainsi Eric Raymond ancre cette culture au début des années 60 au MIT avec le rejet du PDP-1. A la fin des années 60, puis au début des années 70, ce sont Arpanet et Unix qui seront le vecteur de cette culture. Cette première vague sera émoussée par les Unix propriétaires (et Microsoft, l’incarnation de Satan pour l’auteur), pour renaitre avec Linux et l’explosion du Web.

La cathédrale et le bazar est un article long de 42 pages consacré à l’open-source. Il ne se lit pas aisément. C’est la révolution Linux qui a inspiré cette métaphore à l’auteur, une révolution sociale plutôt qu’une révolution technique qui permit d’amener l’open-source à un niveau d’échelle qui ne semblait pas imaginable. Mais les deux tiers de cet article sont consacrés à l’un des projets open-source majeur de l’auteur et des enseignements de son histoire : Fetchmail. Ce sont 19 enseignements qui nous sont distillés au fil des pages, concernant aussi bien l’implication de la communauté, la manière de penser le design et de réutiliser le code que sur la manière de de faire émerger la roadmap. Finalement l’auteur analyse les conditions nécessaires au succès.

Lire la suite →

Note de lecture : Building Evolutionary Architecture, par Neal Ford, Rebecca Parsons & Patrick Kua

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; De bons moments mais des considérations bien trop générales la plupart du temps.

Je suis en grand fan d’architecture émergentes. Je n’avais pas de doute sur le fait que ce texte allait alimenter mon enthousiasme. Finalement, le livre refermé, le sentiment est mitigé. Nous allons voir pourquoi.

L’ouvrage est un format court, il ne compte que 164 pages sur 8 chapitres. Le premier chapitre compte une quinzaine de pages et couvre surtout des généralités. D’une part on y évoque les « ilités » et de l’autre la question de la conception émergente et pourquoi les auteurs préfèrent le terme « évolutionnaire ». Bref, il s’agit surtout de généralités. Le second chapitre aborde une notion très conceptuelle, celle de « fitness function », une notion que l’on retrouvera au fil des pages. L’idée est intéressante, à savoir établir une formule combinant les différentes propriétés attendues de l’architecture dans des proportions correspondant à nos attentes. La pratique est beaucoup plus floue, avec des concepts tels que « holistique » versus « atomique » …

Le chapitre 3 est bien plus conséquent, car il compte une vingtaine de pages pour évoquer la question des changements incrémentaux. Le cas d’utilisation choisi « penultimate widget » est bien abstrait, je n’ai pas compris ce que cela faisait (apparemment, ce n’est pas le sujet). Évidemment, il est question ici de pratiques devops et de déploiement continu, mais pas seulement. On évoque aussi la testabilité et de nouveau les fameuses fitness functions. Ce n’est pas mon chapitre préféré. On arrive aux choses sérieuses avec le chapitre 4 traite de « couplage architectural ». D’ailleurs le chapitre compte 35 pages. Tout d’abord la notion de « quanta architectural » définit la plus petite unité déployable indépendamment. Autant dire qu’il est gros pour le monolithe dont les auteurs se moquent à loisir. Le « monolithe modulaire » abordé ensuite (et rarement évoqué) mérite nettement moins de risées. Suivent : Micro-kernel, EDA, SOA, Microservice et serverless !

Lire la suite →

Note de lecture : Event Streams in Action, par Alexander Dean & Valentin Crettaz

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Une architecture intéressante rendue difficile d’accès par trop de foisonnement technologique !

Le titre initial de cet ouvrage était « unified log processing ». Et c’est souvent de cela qu’il est question ici. Mais le propos a été quelque peu élargi en cours de route, tout en tournant quand même essentiellement autour des grands bus de messages que sont Kafka et Kinesis. Voyons ce qu’il en est.

Le livre compte près de 300 pages, structurées en 3 parties pour un total de 11 chapitres. La première de ces parties se focalise sur l’aspect Unified Log. C’est la plus conséquente du volume, car elle contribue pour 5 chapitres et noircit près de 115 pages ! Fort classiquement, le premier chapitre introduit quelques grands principes d’architecture de l’event stream, ainsi que des cas d’usage. Tout cela est fort agréablement écrit et très bien illustré. On rentre un peu plus dans le dur au chapitre 2, non pas avec la première partie qui détaille l’event log et la structure d’un évènement (en JSON), mais plutôt par l’illustration de la chose avec Kafka et son installation !

Le 3ème chapitre est assez gourmand. Il nous conduit à écrire notre premier worker Kafka. Cela veut dire aussi mettre en place un environnement de développement avec Vagrant et une architecture comprenant du Zookeeper et tout le toutim. Ce n’est pas très facile à suivre. En fait, on n’a guère le temps de reprendre notre souffle au chapitre 4 qui remet ça, mais avec Kinesis ! Dans son ensemble, le chapitre n’est pas super-agréable à lire : beaucoup de setup AWS (forcément) et de longs listing JSON assez ennuyeux en sont la cause principale. De plus, même si c’est assez logique, le code Kinesis est en Python, ce qui n’est pas ce que je préfère.
Au-delà d’être un chapitre douloureux, le va et vient entre Kafka et Kinesis afin de couvrir beaucoup de terrain est une surcharge technologique qui nuit à l’objectif du livre : nous permettre d’appréhender l’architecture « log unifié ». Cette première partie se conclut sur un chapitre au titre paradoxal : le stateful stream processing. Cela commence de manière fort sympathique avec des concepts tels que les évènements dérivés et le fenêtrage de traitement. C’est plus rugueux en seconde partie de chapitre où les auteurs nous introduisent la suppression de paniers avec Apache Samza, avec le code, l’installation et la configuration qui vont avec…

Lire la suite →

Programming Concurrency on the JVM, par Venkat Subramaniam

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Essentiellement intéressant pour la programmation par acteurs, bien que le traitement du sujet soit largement perfectible.

Ce livre a attiré mon attention, car il traite de programmation concurrente, non spécifiquement en Java, mais sur différents langages de la JVM. Dans la pratique, on parle presqu’exclusivement de Java et de Scala. Clojure parvient à se ménager une petite place, surtout que STM vient de là, mais JRuby et Groovy sont abordés de manière vraiment très succincte en fin de livre.

Du livre, parlons-en : il s’agit d’un texte de 250 pages découpé en 5 parties (la 5ème ne contient qu’un court chapitre de conclusion) et totalisant 10 chapitres. Le premier chapitre est une courte introduction illustrée par du multithread « de base » en Java. Il nous présente le thème récurrent du texte : « shared mutability is pure evil ! ».

La première partie s’intitule « stratégies for concurrency » et se contente de 2 chapitres sur 30 pages. Le chapitre 2 « division of labour » évoque le mapping des tâches avec des threads dans différentes configurations applicatives. C’est un sujet instinctivement naturel mais bien illustré ici. Le texte ayant pris quelques rides, il ne pouvait évoquer les co-routines popularisées par Go et désormais disponibles sur la JVM. Au chapitre 3, on prépare la seconde partie en évoquant, hélas de manière légère, des options de conception liées à la gestion des états, et plus précisément l’impact de la mutabilité. Un chapitre un peu décevant.

Lire la suite →

Note de lecture : Effective Modern C++, par Scott Meyers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une verve et une pédagogie toujours présente, mais dans un ouvrage (et un sujet) plus difficile d’accès.

Je suis bien rouillé sur le C++. Je le savais déjà, mais ce texte m’en a fait prendre conscience de manière nette. Par ailleurs le C++ et la manière dont on doit penser son code ont aussi évolué de manière radicale, et ce texte plus que tout autre m’en a fait prendre conscience.

Ce sont 300 pages qui sont consacrées à couvrir les 42 items de ce texte. L’ensemble est regroupé en 8 chapitres. La place dédiée à chaque item est significativement plus importante que dans « effective C++ ». Le premier chapitre « deducing types » fait un peu moins de 30 pages et couvre 4 items. Il fait un choc car on prend de face l’un des aspects du C++ 11 les plus complexes : la gestion des types. Et là il faut bien comprendre les notions de lvalue, de rvalue (à propos, ne sautez pas l’introduction) et de référence universelle. Ajoutons-y l’inférence de type et une touche de template métaprogramming, vous vous dites que le livre va être très long, d’autant que l’auteur semble avoir perdu son humour au passage.

Sans être hilarant, le court chapitre 2 dédié à l’inférence de type avec auto nous permet de reprendre notre souffle. Peut-être ces explications nous auraient même été utiles au premier chapitre ? Je retrouve vraiment le style inimitable de Scott Meyers au chapitre 3. Les sujets traités sont moins ardus, mais ce chapitre couvre quand même 11 items sur 70 pages où l’auteur nous fait découvrir « in situ » les nouveaux mots-clés, les nouvelles constructions du C++ … et leurs sombres recoins. Un chapitre vraiment instructif et agréable.

Lire la suite →