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

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

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

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

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

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

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

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

Note de lecture : Vous allez commettre une terrible erreur ! par Olivier Sibony

Note : 3 ; Plus une tribune pour que l’auteur clame ses idées, qu’un véritable travail d’étude.

De prime abord, le titre semblait prometteur sur l’investigation des biais cognitifs. Hélas, Olivier Sibony essaie de faire « comme les grands » mais n’y parvient pas. Le texte vise les décideurs et l’auteur se livre au long des pages à une danse de séduction à leur égard qui nuit gravement à la force du texte aussi bien qu’à son contenu même. Nous reviendrons là-dessus en conclusion de cette note.

L’ouvrage lui-même compte 330 pages (hors annexes) divisées en 3 parties, le tout totalisant 16 chapitres. La première partie compte 176 pages sur 9 chapitres. C’est la partie la plus longue, de loin, mais aussi la plus intéressante. Ça tombe bien. C’est justement la partie qui évoque les biais cognitifs. On commence au chapitre 1 par « le piège du storytelling ». Ce chapitre regroupe 3 biais : le biais de confirmation, le biais du champion et le biais d’expérience. Le tout est illustré … par une histoire ! Il s’agit de celle des avions renifleurs. Toutefois le propos et les biais sont clairement expliqués. Mais, et l’on retrouvera cela tout au long du livre, l’auteur manipule bel et bien les éléments dans une direction qu’il souhaite donner. Pour quelqu’un qui prône « les faits, rien que les faits » …

Le second chapitre évoque le piège de l’imitation. Il regroupe l’erreur d’attribution (où l’on corrèle trop vite un résultat avec un facteur), l’effet de halo où seuls les traits qui attirent notre regard sont notés à l’exclusion des autres éléments et le biais du survivant où les ratages sont ignorés. Un bon chapitre bien et clairement illustré. Le chapitre 3 nous emmène vers les pièges de l’intuition : en relatant Kahneman, nous y voyons plus clair sur le champ d’application de l’intuition et du danger de l’extrapoler. Un sujet clairement traité.

Lire la suite

Note de lecture : The Rational Unified Process, an introduction, 3rd edt., par Philippe Kruchten

Note : 6 ; Une importante revue de l’ouvrage

Rational Unified Process fut la méthode tendance jusqu’au milieu des années 2000. Cette 3ème édition est en quelque sorte la mouture ultime (en attendant sa renaissance dans les années 201x, sous le nom de SAFe). Chaque workflow de RUP est riche de descriptifs, de rôles et de pratiques, au point que chacun d’entre eux nécessite au moins un ouvrage pour couvrir le sujet. Ici, il s’agit plutôt d’un tour d’horizon de l’ensemble de ces workflows.

Contrairement à l’édition précédente qui ne représentait qu’une évolution mineure de livre (et du processus), celle-ci a fortement évolué, gonflant également l’édition d’une bonne quarantaine de pages, pour un total de 270 pages hors annexes. Le tout est divisé en deux parties inégales. La première compte 110 pages sur 6 chapitres et traite du processus dans sa globalité. Le premier chapitre est certainement particulier, car il traite de la notion de « best practices », mais surtout il est signé Grady Booch. Après une courte introduction sur cette notion de best practices et de développement itératif et incrémental, l’auteur nous évoque les propriétés d’un bon processus : gestion des exigences, modélisation visuelle, gestion du changement, etc… Bref, les propriétés mises en avant par RUP (ou UP).

Le second chapitre fait écho à ce premier chapitre en déclinant les propriétés évoquées sur RUP, puis en évoquant la structure en 2 dimensions du framework. Tout cela se lit facilement mais il est clair que l’on n’est pas rentré dans le vif du sujet. Le chapitre 3 reste très abstrait car il décrit le méta-modèle du framework : rôles, artéfacts, activités (et étapes d’activités), workflows et disciplines ! Les couches de « pilotage » que sont les guidelines et autres templates ne sont que brièvement décrits. L’ensemble revêt une certaine esthétique pour l’académicien ou le théoricien (moi par exemple) mais va sembler austère et très abstrait pour qui ne porte pas un intérêt aiguisé aux processus de développement !

Lire la suite

Note de lecture : More effective C++, par Scott Meyers

Note : 9 ; De la même veine et de la même qualité que le 1er volume

Effective C++ fut indéniablement un succès. La formule a depuis été reprise par d’autres auteurs, empruntant souvent la même qualité de pertinence technique. Mais ces autres textes n’ont pas la verve d’un Scott Meyers ! Ce second volume est de la même eau que le premier. Ici les centres d’intérêts se focalisent sur un certain nombre de sujets précis (exceptions, casts, etc…) et l’auteur développe plus son propos. D’ailleurs le nombre de règles est plus réduit, tandis que le nombre de pages a augmenté, passant à 290 pages.

L’auteur a structuré son propos en 6 thèmes. Les « basiques » couvrent 4 items plutôt simples sur une quinzaine de pages. La seule « nouveauté » étant les cast C++ apparus depuis peu (à l’époque). La seconde partie couvre aussi 4 items, cette fois sur une vingtaine de pages et sur un sujet plus particulier : les opérateurs. Outre les subtilités dont l’auteur nous régale comme à son habitude, je relève ici deux items particulièrement importants : les écritures idiomatiques des opérateurs pré et post incréments, et les différentes formes des opérateurs new et delete.

La troisième partie nous conduit vers un sujet délicat avec les exceptions : 7 items leur sont dédiés sur 35 pages. Ici, il s’agit tout au long de ces items de nous faire prendre conscience des implications et des limites de leur usage : fuite de mémoire, contraintes au sein des constructeurs et des destructeurs, impact sur les performances, etc. Il y a de quoi s’enfuir, ce qui n’est pas le propos de l’auteur.

Lire la suite