Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.
Sun Tzu
Publicités
Note de lecture : CoreOS in Action, par Matt Bailey
Note 3 ; Malheureusement je ne suis pas un ops…
Je voulais vraiment en savoir plus sur CoreOS. Chemin faisant, je savais que je risquais une lecture qui pouvait s’avérer ennuyeuse pour moi, sinon hermétique. C’est surtout la brièveté de l’ouvrage qui m’aura permis de survivre, le texte n’étant vraiment pas fait pour moi.
Bref, le texte l’est avec seulement 175 pages et 10 chapitres (donc des chapitres assez courts en moyenne). L’ensemble est divisé en 3 parties. La première d’entre-elle « getting to know CoreOS » comprends 3 chapitres. Et on commence bien sûr par une introduction au système, d’une quinzaine de pages. Cette introduction doit nous donner une image de haut niveau de CoreOS, qui un OS « statique », dont les composants majeurs sont fleet et etcd. Mais pour moi, l’angle est déjà bien trop « système ».
Les 18 pages du chapitre 2 sont consacrées à faire fonctionner CoreOS sur une machine de dev, dans un environnement Vagrant, lui-même dans une machine virtuelle VirtualBox. En sachant que ce n’est pas un mais 3 CoreOs que l’on souhaite faire fonctionner, cela donne une idée de la configuration : pas vraiment une partie de plaisir pour moi. Je sombre encore un peu plus au chapitre 3 « expecting failure » qui rentre dans les arcanes d’etcd, le tout pimenté de configuration Ngnix !
Note de lecture : Implementing Domain-Driven Design, par Vaughn Vernon
Note 3 ; Quand implémentation rime avec confusion.
C’est un beau pavé de presque 600 pages que nous a produit l’auteur. J’avais pas mal d’espoirs sur celui-ci, en effet malgré l’ampleur du mouvement DDD suscité par Eric Evans, j’ai toujours eu pas mal de difficultés avec le niveau stratosphérique de son propos. Avec ce volume orienté implémentation, je pensais régler ce problème. Nous n’y sommes pas et il s’en faut de beaucoup. Certes il y a du code, quoique souvent avec des « leaky abstractions » : pourquoi donc le choix de la stratégie de persistance devrait-il influer le modèle du domaine ? On arrive au pire avec les « values object » où l’on dit à demi-mot qu’il s’agit d’un choix technique ! L’étude de cas n’aide malheureusement pas beaucoup : elle manque de vie, son propos est trop abstrait et bien que le choix du sujet soit très pertinent pour moi, j’ai eu toutes les difficultés à le suivre. J’oublie encore les interludes « cow-boy logic » sensés donner de la légèreté au texte, mais incompréhensibles pour les non-américains.
Le premier chapitre est en quelque sorte le « business case » du DDD. On n’y apprends pas grand chose mais au moins le texte est compréhensible ainsi que les extraits de code. Tout de même, 42 pages pour cela… C’est d’ailleurs la taille du second chapitre « domain, sub-domain & bounded-context ». Les 3 niveaux de structuration rendent le propos difficile à suivre et à mon avis d’une complexité non-nécessaire. De plus l’exemple choisi (identity & access control) n’est guère pertinent. Il en résulte que l’on sort du chapitre avec peu d’éléments pour déterminer la granularité du bounded context mais avec un gros mal de tête sur les notions avancées.
Le chapitre 3, context map est un court interlude qui évoque la projection d’un bounded context sur un autre. C’est intéressant sans être mortel. Polluer le propos avec du http ou du rest est non seulement inutile mais hors de propos. Malheureusement, c’est récurrent dans tout le livre. Contrastant avec cela, le chapitre 4 « architecture », c’est du sérieux avec ses 56 pages ! On y évoque différents types architecturaux comme le modèle en couche et l’architecture hexagonale d’Alistair Cockburn. Il évoque aussi le DIP qui n’est jamais que la même intention que l’Adapteur au centre de l’architecture hexagonale, ce qui ne semble pas effleurer l’auteur. Le CQRS est à peu près compréhensible, ce qui n’est pas le cas de l’Event-driven architecture, bien qu’il faille concéder une représentation intéressante intégrant l’architecture hexagonale. Le pipe and filter est juste évoqué et les « sagas » c’est à dire les transactions applicatives sont plus à décoder qu’à lire. L’Event-sourcing et les data frabric ont aussi doit à quelques mots. Dans l’ensemble le chapitre est bien trop long pour son contenu ?
A clear conscience is the sure sign of a bad memory.
Mark Twain
Note de lecture : Rupture Douce, saison 01, par Laurent Sarrazin edt.
Note : 3 ; Hétéroclite.
Laurent a invité de nombreux coaches à contribuer à cet ouvrage collectif. Il m’avait d’ailleurs invité également, je me suis contenté du rôle de relecteur. L’objectif était de constituer une grande fresque d’histoire de transitions agiles ou les propos des différents auteurs s’entremêleraient et se répondraient. Cela faisait d’ailleurs partie des contraintes de l’exercice : 3 références vers d’autres histoires.
En pratique, ce fut l’occasion pour nombre de ces coaches de se donner de la visibilité en inscrivant leur nom sur un livre. En soi rien de choquant : se rendre visible fait partie du business, je le fais aussi ! Malheureusement la fresque n’est pas si cohérente qu’on pourrait l’espérer : les histoires n’en sont pas toujours, le propos tourne assez régulièrement à l’auto-publicité dans des textes employant abondamment la première personne. Fort heureusement, la plupart de ces textes font moins de 10 pages, mais certains d’entre eux paraissent beaucoup, beaucoup plus longs ! Il faut dire que certaines productions, et malgré les relectures, manquent franchement de qualité rédactionnelle. C’est même parfois carrément pompeux, Claude Aubry a d’ailleurs haussé la voix lors des relectures à ce sujet.
N’allez pas croire que tout est à jeter. Il y a beaucoup de contributeurs à ce livre, des contributions courtes, je l’ai dit. C’est la bonne nouvelle : on a droit à beaucoup de variété et quelques pépites dans le tas. Je pense à Jean-Claude Grosjean et Damien Thouvenin, par exemple. Mais aussi à Axel Villechalane. Véronique Messager est égale à elle-même, mais Claude Aubry est un peu décevant lorsque l’on connaît ses qualités rédactionnelles.
Note de lecture : A Little Riak Book 2.0, par Eric Redmond & John Daily
Note : 2 ; Un livre à décoder plutôt qu’à lire !
Edité à compte d’auteur par un (gros) contributeur Riak, ce livre est assurément petit car il dépasse à peine la centaine de pages. Il n’a pas non plus d’ISBN ce qui est hélas un premier indice sur sa qualité éditoriale. Autant le dire tout de suite : elle est médiocre.
Je m’attendais à un petit tutorial pour mettre le pied à l’étrier. Si c’est effectivement la cible de ce texte, l’objectif est quand à lui bien raté. La prose fait de nombreux raccourcis qui nous font rater une bonne compréhension. Ainsi l’articulation entre bucket et bucket-type reste-t-elle nébuleuse. L’auteur semble parler de clés hiérarchiques mais … finalement non. Quand aux « rings » on en est encore à se demander comment cela fonctionne. L’ouvrage n’est pas dénué d’illustration ou d’extraits de code ou de configuration, mais c’est plutôt du matériel brut ne soulignant pas ce qu’il y a à voir. Bref : encore raté.
Le chapitre 1 est une courte introduction. Il liste les fonctionnalité de Riak 1 et met en évidence les nouveautés de Riak 2 avec des concepts qui ne sont pas expliqués, donc incompréhensibles. On est bien avancés. Le chapitre 2 aborde les concepts : ce devrait être le chapitre le plus intéressant. Mais là aussi les auteurs parviennent à introduire de la confusion. Il reste toutefois le chapitre le plus instructif.
A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.
Lao Tseu
Note de lecture : Designing for Growth, par Jeanne Liedtka & Tim Ogilvie
Note 6 ; Bon sur le framework et le mindset design thinking. Mais le propos se perd parfois un peu en route.
Il y a finalement assez peu de littérature sur le Design Thinking. J’ai profité du MOOC avec le Pr Liedtka pour me plonger parallèlement dans cette lecture. C’est un beau livre, à l’impression bi chromique et comptant environ 200 pages auxquelles il faut ajouter les annexes. Découpé en 5 sections, il suit la logique des 4 questions qui structurent l’approche des auteurs..
Le texte s’ouvre sur une partie introductive de 2 chapitres totalisant 40 pages. Les 20 pages du premier chapitre tentent de répondre à la question « pourquoi le design ». Ce sont avec des histoires et des témoignages que des réponses sont apportées. C’est bien vu, même si cela n’apporte qu’une réponse partielle à la question. Le second chapitre de cette introduction est la « big picture » du framework : 4 questions et 10 outils. Aussi émaillé de témoignages, même s’ils sont moins percutants, le chapitre permet de s’approprier la logique de la démarche, mais pas l’essence.
La seconde partie du livre est consacré à la première question : « what is ? » sur 55 pages et 4 chapitres. Cette partie s’ouvre sur un chapitre consacré à la visualisation. Il manque cruellement de contenu concret, on reste dans la déclaration d’intention et les bénéfices attendu. Difficile d’y décerner une matière concrète avec laquelle rentrer chez soi ! Le chapitre 4 est tout l’inverse : s’il est succinct, il décrit parfaitement l’approche et le tout est brillamment illustré. Le value chain analysis est expédié à toute vitesse et c’est le « mind mapping » qui conclut cette partie. Ce mind-mapping n’est pas à confondre avec les cartes heuristiques. Il s’agirait plutôt de safaris pour partager et brain-stormer.
Note de lecture : Kotlin in Action, par Dmitry Jemerov & Svetlana Isakova
Note : 5 ; Fait le boulot.
Kotlin est un langage de la JVM que je classe dans la catégorie des « better Java », aux côtés de Ceylon (qui hélas n’a pas encore d’ouvrage). Le parti-pris du langage est celui d’une très bonne intégration avec Java (le langage), la manière dont chaque concept se traduit et peut être utilisé de ce côté est un fil rouge du livre. Ce n’est pas celui qui m’intéresse le plus, mais c’est une fonctionnalité forte (et limitante) du langage, donc… L’autre parti-pris est de s’adosser à une version déjà ancienne de la JVM : Java 6, mais ce dernier point n’a pas d’influence sur le texte.
Il y a fort peu à dire de ce texte, ni en bien ni en mal. Il est plutôt sans surprise. Le texte est raisonnablement clair et les extraits de code font le boulot. D’un autre côté, pas de « waouh effect ». Avec 310 pages sur 11 chapitres regroupés en deux parties, on reste également dans le standard, bien que dans la partie haute.
La première partie « introducing Kotlin » compte 6 chapitres et couvre 170 pages. Le premier d’entre-eux se contente d’une quinzaine d’entre-elles. Il a pour but de faire le tour des caractéristiques principales du langage et de son positionnement. C’est bien écrit, mais on n’est en réalité pas tellement avancé. Par contraste, le chapitre 2 « Kotlin basics » et ses un peu plus de 25 pages font un bon boulot pour couvrir les bases du langage : déclaration de classes et de méthodes, les propriétés (et leurs petites particularités) ainsi que des structures de contrôle : boucles, switches, énumérations, etc. On couvre bien les base et c’est bien écrit.
True leadership must be for the benefit of the followers, not the enrichment of the leaders.
Robert Townsend
