Note de lecture : Logging in Action, par Phil Wilkins

Note : 6 ; Comprendre le “log shipping” avec fluentd !

Avec 300 pages, l’ouvrage est légèrement au-dessus de la moyenne, il compte 11 chapitres répartis en 4 parties, ce qui est un découpage également raisonnable. La première partie « From zero to hello world » ne cache pas son caractère introductif et nous propose 2 chapitres sur une soixantaine de pages. S’il est déjà bien focalisé sur Fluentd, le premier chapitre d’une trentaine de pages couvre bien les problématiques du « log shipping » en corrélation sur ce qu’est un élément de log. Il ne manque pas non plus d’évoquer son concurrent de toujours, Logstash. C’est une bonne introduction, fort prometteuse. Le second chapitre nous fait découvrir à haute altitude les éléments structurants de Fluentd. Cela permet de mieux le conceptualiser en tant que « ESB pour les logs ». Mais le gros du chapitre est consacré au déploiement et aux nombreuses options possibles. C’est certes intéressant, mais je trouve le propos assez déséquilibré dans ce chapitre.

La seconde partie « Fluentd in depth » explicite bien le titre sa finalité. Il couvre une centaine de pages avec 4 chapitres. Le chapitre 3 nous permet de rentrer dans l’action en mettant en œuvre pour capturer les évènements de log à la source, mais en l’occurrence uniquement sous forme de fichiers. C’est dommage, car Fluentd permet aussi de capturer d’autres sources, mais ce sera en partie traité plus tard. Le second volet traite du parsing permettant d’imposer une structure au log dès leur capture. Au final une bonne couverture du sujet, même si elle est limitée aux fichiers. C’est fort logiquement à l’ouput qu’est consacré le chapitre 4. On y découvre des possibilités que l’on ne soupçonnait pas : buffering (pour grouper les évènements à des fins d’optimisation), compression, etc. Contrairement au chapitre 3, l’auteur nous met en perspectives la mise en œuvre sur plusieurs destinations, de quoi nous donner envie !

Les choses se compliquent au chapitre 5 où il est question de routage. C’est le côté ESB de Fluentd. Il faut un peu s’accrocher pour bien saisir les notions de copie d’évènements et surtout de réécriture des tags, car l’outils utilise essentiellement ceux-ci pour le routage, ce qui fait un peu bricolage de mon point de vue. On termine en beauté avec la notion de pipeline qui donne toute sa dimension à Fluentd, mais il faut s’accrocher un peu. Cette seconde partie se referme sur un chapitre 6 consacré au filtrage et à l’enrichissement des évènements. Là encore, on découvre la puissance insoupçonnée du log shipping. Si les filtres nous permettent de déclencher des actions spécifiques sur certains logs, l’enrichissement nous ouvre les portes sur l’ajout d’informations de contexte ou la « rédaction » de logs qui permet d’éliminer de ceux-ci les données à caractère personnel ! Bref, là encore de belles perspectives.

Lire la suite

Note de lecture : The Agile Leader, par Zuzana Sochova

Note : 3 ; Beaucoup d’éléments d’intention, mais pas grand-chose pour aider ni même faire comprendre ce qu’est un leader agile…

C’est le second livre en langue anglaise de cette auteure en langue anglaise qui nous a gratifié d’un premier volume sur le Scrum Mastering. Le parcours professionnel de Zuzana Sochova mérite le respect, non seulement sur ses accomplissements au sein de la Scrum Alliance que dans ses expériences. L’avant-goût est prometteur. Comme nous le verrons hélas, tout cela a bien du mal à se concrétiser dans le texte !

L’opuscule ne nous fera pas souffrir trop longtemps : malgré ses 310 pages, son format plus réduit qu’à l’accoutumée et ses nombreuses illustrations (en fait des scribings, souvent très bons, de la main de l’auteure) lui rendent l’équivalent d’à peu près 200 pages d’un format plus habituel. Le découpage en 12 chapitres semble plus pertinent sachant cela. Le tout est structuré en 2 parties inégales. La première « unleash your leadership potential » compte 200 pages pour 8 chapitres. Dans le chapitre introductif, l’auteur fait état de sa propre expérience pour pousser le besoin d’un changement : une organisation sans management !

Lire la suite

Note de lecture : L’entreprise altruiste, par Isaac Getz & Laurent Marbacher

Note : 9 ; L’après « entreprises libérées, construit sur une analyse riche et un fil d’histoires inspirantes !

Depuis l’entreprise libérée, Isaac Getz a produit quelques écrits s’inscrivant dans la lignée de ce texte marquant. Beaucoup (dont moi) se demandaient si cette démarche allait le conduire à une nouvelle étape majeure. C’est bien le cas, ce nouvel opus nous conduit vers un type d’entreprise dont le sous-titre stipule « s’enrichir en donnant tout » de manière un peu racoleuse, mais qui va tout de même nous interpeler.

La célèbre collection « clé des champs » à couverture jaune est un format de poche. Celui-ci compte 374 pages, ce qui en fait un ouvrage de taille moyenne. Le texte est découpé en 9 chapitres, mais je devrais plutôt dire « jalonné », car ceux-ci marquent une progression du propos et ne sont donc pas indépendants. Ce choix nous donne un narratif qui évolue sans heurts du début à la fin, ce qui est franchement plaisant.

Le premier chapitre nous fait découvrir la notion d’entreprise altruiste : des entreprises dont l’objectif qui servent l’autre (la communauté, les clients, les fournisseurs) de manière inconditionnelle sans rechercher la valeur économique. Celle-ci est obtenue par effet de bord selon le principe « d’obliquité » qui reviendra tout au long du livre. A ce stade, le principe parait idéaliste ou farfelu, Les chapitres suivant auront pour objet de donner corps à ce principe en les illustrant des entreprises étudiées.

Lire la suite

Note de lecture : Les employés d’abord les clients ensuite, par Vineet Nayar

Note : 8 ; L’épopée d’un dirigeant et de son entreprise pour retourner la pyramide managériale. Passionnant !

Cet ouvrage fait partie des classiques incontournables de « l’entreprise libérée ». On ne s’attendrait certainement pas à ce que cela vienne d’un chef d’entreprise indien ! Mais il apparait rapidement que le texte a bel et bien sa place parmi ces classiques.

La traduction française de cette édition augmentée compte 230 pages répartis en 6 chapitres. Elle est de plus illustrée par Etienne Appert qui n’en est pas à son coup d’essai. Toutes les illustrations ne sont pas heureuses mais le ratio de réussies est fort bon. Sans parler de processus, il y a une démarche que l’auteur à construit ou discerné au fur et à mesure de sa progression. C’est l’objet des 4 premiers chapitres. Le premier « miroir, mon beau miroir » compte une trentaine de pages. La démarche rappelle Joh, Kotter : provoquer le sentiment d’urgence. L’auteur provoque cela en conduisant l’ensemble des employés de HCL à regarder la situation sans concession aucune et à décider de là où ils veulent aller. Plus qu’une étape, Vineet Nayar nous comte cela sous l’angle personnel : sa démarche ses doutes et le tour du monde qu’il a entrepris pour rencontrer l’ensemble de son groupe ! L’objectif devient rapidement clair : se mettre au service de l chaine de valeur. Or ce sont les employés de première ligne qui servent la valeur au client, donc l’entreprise doit se mettre entièrement à leur service !

La seconde étape est la création de la confiance au travers de la transparence. L’auteur touche un point délicat, ce qu’il appelle le « quotient de confiance », et il s’appuie sur les 4 dimensions de la confiance de Maister (The trusted advisor) pour la mesurer : crédibilité, fiabilité, intimité et motivations personnelles. Et comme le titre du chapitre l’indique, pour l’auteur, la transparence marche main dans la main avec la confiance, d’abord pour permettre l’alignement sur les valeurs de l’entreprise et pour s’assurer de la sincérité de l’engagement des parties prenantes. C’est pour cela que Vineet Nayar a commencé par lui-même, puis l’exemplarité aidant, par son premier cercle de directeurs, puis… La création de cette relation de confiance l’a conduit vers une nouvelle étape : donner la priorité aux employés, les véritables créateurs de valeur, devant les clients !

Lire la suite

Note de lecture : Use Case Modeling, par Kurt Bittner & Ian Spence

Note 6 ; Cas d’utilisation & Unified Process !

Cela n’apparaît pas dans le titre, mais voici le livre officiel sur l’utilisation des cas d’utilisation dans le RUP. Cela explique, comme nous le verrons, une orientation de l’ouvrage clairement orientée vers le processus, plutôt que vers la modélisation. Le cadre est donc franchement prescriptif, mais aussi avec quelques avantages à ce positionnement : l’articulation avec d’autres éléments du processus.

Le texte en lui-même couvre 300 pages sur 12 chapitres. Quand on considère le thème, on peut considérer que c’est un ouvrage franchement volumineux. Mais les chapitres restent de taille raisonnable. Le tout est structuré en deux parties. La première couvre 145 pages pour 5 chapitres. Son objectif est de nous mettre le pied à l’étrier avec les cas d’utilisation. Le premier chapitre est la très classique introduction, destinée à nous permettre d’appréhender la place des cas d’utilisation au sein de la gestion des exigences. Le style est plutôt guindé, mais néanmoins efficace pour à la fois donner un peu de contexte Unified Process et évoquer les finalités des cas d’utilisation sans les trahir.

Le second chapitre s’attaque aux éléments fondamentaux des cas d’utilisation. En réalité il couvre bien tous les éléments nécessaires pour les mettre en œuvre à l’exception des éléments les plus exotiques. L’approche consiste en une déconstruction systématique des éléments méthodologiques : éléments du modèle, acteurs, flux d’évènements, mais aussi artéfacts support. Le tout hélas sans exemple et sans aborder le fond de ce que sont les cas d’utilisation au long de ces 30 pages. Bref, tout y est, sauf l’essence même des cas d’utilisation. Le chapitre 3 parle d’établir la vision, mais en fait le titre est un peu trompeur : il traite de manière plus générale de l’approche « feature » telle qu’elle est proposée par Dean Leffingwell dans « Managing the Requirements process ». Une approche une fois encore très orientée processus à tel point que les presque 40 pages du chapitre s’articulent en étapes ! Cette approche vient, en théorie, intersecter l’approche Cas d’Utilisation qui a une orientation plus comportementale. Dans la pratique, les deux approches ne se rencontrent guère ici. L’un des points forts de ce chapitre est l’étude minutieuse des parties prenantes et de leurs représentants.

Lire la suite

Note de lecture : Pragmatic Version Control using Subversion 2nd edition, par Mike Mason

Note : 5 ; Une simple mise à jour.

Successeur de CVS, Subversion n’a pas encore complètement disparu du paysage, mais il est déjà un outil du passé. Cet ouvrage qui date du milieu des années 2000 nous rappelle qu’il n’en a pas toujours été ainsi. Cette seconde version couvre la version 1.3 de Subversion. Le texte grossit d’une dizaine de pages, et les annexes aussi, emmenant l’ensemble à 220 pages contre 200 précédemment. Le texte ne change guère sur le fond, il est juste annoté de quelques évolutions liées à la version 1.3 de subversion. L’esprit de cette série « starter kit » n’a pas changé : ni un manuel de référence, ni un guide de l’utilisateur, mais une manière de mettre en œuvre concrètement l’outil sur nos activités quotidiennes de développement !

Le texte principal compte à peine plus de 150 pages, structurés en 11 chapitres, auxquels il ne faut pas oublier d’ajouter pas moins de 70 pages d’annexes. Le texte s’ouvre sur un classique premier chapitre d’introduction. Il n’apprend pas grand-chose aux praticiens aguerris de la gestion de version, mais permet quand même d’évoquer quelques aspects particuliers à Subversion, tels que les changeset.

On attaque les choses sérieuses avec le chapitre 2 et les concepts essentiels de Subversion : repository, branches, tags, etc. ainsi que les actions classiques telles que check-in, check-out, merge ont au menu. Ce sont des fondamentaux clairement expliqués, mais nous ne sommes pas encore dans l’action. L’action, justement, elle commence au chapitre 3 où il faut installer l’outil, se familiariser avec la ligne de commande, créer repository et projet et mener à bien notre « hello world ». En réalité, on va un tout petit peu plus loin que le « hello world », mais si on a touché du doigt les commandes de base, on n’a pas encore travaillé en « grandeur réelle ».

Lire la suite

Note de lecture : XML Schéma, par Eric Van Der Vlist

Note: 4 ; Sérieux, mais modérément passionnant.

Il semble difficile de trouver un ouvrage sur XML Schéma titrant moins de 1000 pages! En voilà pourtant un. Le sujet abordé est à la fois un point fort de XML et le sujet d’acerbes critiques, car les schémas XML sont à la fois indûment compliqués et terriblement verbeux. Ce texte, nous allons le voir, n’est peut-être pas le meilleurs, le texte est souvent un chouia laborieux, mais il fait le travail.

Avec près de 400 pages pour sa partie principale, le volume brut reste conséquent. Mais il a au moins la bonne idée d’être divisé en 2 parties : une partie « guide de l’utilisateur », puis une partie « manuel de référence ». La première partie consacrée à l’apprentissage du langage couvre la majeure partie du texte, avec 14 chapitres sur 225 pages. Passons rapidement le premier chapitre qui évoque plutôt succinctement l’utilisation des schémas. Ce n’est pas le plus marquant de l’ouvrage. Le chapitre 2 est un peu le « hello world » du XML schéma. On voit déjà que même pour des choses simples, on arrive vite à un schéma très verbeux. Cela dit, c’est plutôt bien expliqué, même si le style n’est pas particulièrement enjoué.

C’est plutôt une bonne idée de partir de cette base pour enrichir cette grammaire au chapitre 3. Toutefois, cela se complexifie pas mal et l’auteur nous assène déjà certains choix de conception que permet la souplesse (que l’on paie en complexité) de XML schéma. Comme le texte est un peu avare de développements pédagogiques, il faut s’accrocher un peu. Cela se calme un peu au chapitre 4 où l’on passe en revue, de manière plutôt exhaustive, les types simples prédéfinis. Voilà un chapitre qui ressemble un peu à un manuel de référence.

Lire la suite

Note de lecture : Multi-Paradigm design for C++, par James Coplien

Note : 3 ; Un livre décevant, échouant sur C++ et sur la méthode.

Le titre de l’ouvrage était prometteur : C++ est le langage multi-paradigmes par excellence. Le livre de Bjarne Stroustup sur le langage commence même par une phrase en faisant mention. Et j’avoue que concevoir des structures intégrant objet, types abstrait des données et templates est l’un des exercices que je trouve le plus stimulant avec ce langage. Bref, j’avais des attentes assez élevées concernant cet ouvrage. Elles ont été un peu douchées.

Avec 260 pages découpées en 9 chapitres, le texte n’a pas un abord inquiétant, il promet même un rythme de lecture assez soutenable avec des chapitres pas trop longs. Le premier chapitre, avec ses 27 pages introduit justement cette question du multiparadigme et l’erreur de casting va commencer à apparaitre. L’auteur y évoque les variabilités et les « commonalités » ainsi que du domaine de l’analyse et du domaine de la solution. L’auteur s’y perd quelque peu et nous perd encore plus. Tout cela ne commence pas bien.

L’identification des commonalités dans le domaine de l’analyse est le sujet du chapitre 2. Après la confusion du premier chapitre les choses semblent plus claires ici : c’est la recherche des dénominateurs communs dans les concepts de l’application. J’ai l’impression de revivre les temps d’OMT (même si UML était déjà là et bien là en 1999). En fait l’auteur se prévaut de références plus anciennes : David Parnas et Ed Yourdon, donc datant des années 80 voir avant ! La tentative d’accoster du code C++ à cela parait bien poussive.C’est au tour de la variabilité d’être investiguée au chapitre 3. L’auteur y distingue différents types de variabilité, qui s’expriment dans le langage avec différents « binding times ». L’idée est intéressante et originale. Ainsi l’auteur décline ces différents binds : à la compilation avec la compilation conditionnelle, au link avec les templates et bien sûr à l’exécution avec les méthodes virtuelles. La projection du volet conceptuel vers le volet technique est hélas moins clair.

Lire la suite

Note de lecture : Pragmatic Version Control using CVS, par Andrew Hunt & David Thomas

Note : 6 ; “Best practices” et utilisation de CVS parfaitement intégrés.

Quand les Pragmatic Programmers » ont décidé d’ouvrir boutique en devenant éditeurs, ils ont commencé par publier des « starters kits » destinés à permettre l’utilisation d’outils labellisés « pragmatiques » avec les recettes agiles qui vont avec. Le roi de la montagne des gestionnaires de version était alors Subversion, mais CVS (qui nous intéresse aujourd’hui) était encore utilisé, tandis que Git n’était pas encore né. Peu de monde se souvient encore du successeur de RCS (dont encore moins de personnes se souviennent), et ce guide pratique va nous permettre de le maitriser au quotidien. Bien sûr aujourd’hui le texte a d’avantage un intérêt historique, voir archéologique.

L’ouvrage ne pèse gère lourd avec moins de 140 pages auxquelles il faut ajouter une quinzaine de pages d’annexes. Le tout est structuré en 10 chapitres. Le premier chapitre cueille bien tôt le développeur débutant pour lui faire appréhender l’intérêt d’un gestionnaire de version, au travers d’une courte histoire. Quelques pages qui ne seront utiles qu’au grand débutant. Le second chapitre attaque les choses sérieuses, avec les concepts gravitant autour de la gestion de configuration, et surtout les cas d’usage de ce type d’outil : branche de développement, bug fixes, conflits, etc. Le tout bien illustré et expliqué efficacement. Le tout reste générique, sans aborder les spécificités de CVS.

C’est au chapitre 3 que l’on attaque véritablement la prise en main de CVS, depuis l’installation, jusqu’au gestes de base évoqués au chapitre précédent, en passant par la configuration et la gestion de projet. Les lignes de commande sont développées et expliquées, comme on peut s’y attendre de ce type d’ouvrage. Ces 3 premiers chapitres étaient en quelque sorte l’introduction. Je passe sur le chapitre 4 qui est en quelque sorte le préambule du reste du livre.

Lire la suite

Note de lecture : Leadership is Language, par L. David Marquet

Note : 8 ; Pour créer le “playbook” du management au travers d’un langage déclenchant les bons comportements !

Il est rare qu’un second ouvrage se montre à la hauteur d’un exceptionnel premier ouvrage. C’est pourtant bien le cas ici. L’ouvrage reprend une formule qui a déjà bien réussie précédemment : l’utilisation d’un fil narratif, bien évidemment dans le domaine maritime, celui du naufrage du El Faro. Contrairement au récit précédent, celui-ci ne s’appuie sur aucun témoignage, les protagonistes étant tous morts au cours du naufrage. Mais tous les échanges enregistrés sur la passerelle ont été récupérés, et leur analyse sert de fil conducteur au livre.

Celui-ci est de taille raisonnable, plus que ne le laisse penser les 310 pages du livre découpé en 11 chapitres. Ceux-ci sont précédés d’une introduction où l’auteur fait le lien avec « Turn the Ship Around », son ouvrage précédent que je ne peux que vous recommander. Il conclut de cette expérience que lui et son équipage ont changé de langage de plusieurs manière, l’amélioration de leur performance n’en étant que la conséquence. Les 20 pages du premier chapitre nous relatent le naufrage du El Faro, analysant au passage le langage (celui de l’invulnérabilité) et la domination du capitaine factualisée au travers du partage du temps de parole. Ces marins n’étaient pas de mauvais marins, nous confie David Marquet, mais ils obéissaient aux mauvaises règles du jeux.

Les nouvelles règles du jeu, c’est justement le thème du second chapitre. Il y a 6 règles du jeu qui seront développées des chapitres suivants et un message principal : adopter un langage permettant de mieux réfléchir à ce que nous faisons à chaque niveau de la hiérarchie, et pas seulement au sommet de celle-ci. La question centrale de ce chapitre est toutefois la variabilité et la manière de l’appréhender. Elle transparait au travers de la manière d’appréhender le « blue work » (la réflexion) et le « red work » (l’action). Autrefois bien séparés et hiérarchisés dans le Taylorisme, ils doivent aujourd’hui être abordés de manière complémentaire pour embrasser la variabilité. Le titre du chapitre 3 est cryptique de prime abord : « contrôler l’horloge » (disons plutôt contrôler le temps). Il s’agit plutôt finalement de se ménager et même planifier des « pauses » pour ne pas être prisonnier de l’exécution (le mode « rouge »). C’est ce que nous faisons dans nos fonctionnements agiles, avec les revues de code, raffinements ou validation de stories et bien sûr surtout avec les rétrospectives. Ainsi nous contrôlons le temps et nous donnons le moyen de réviser nos plans plutôt que d’être prisonniers de l’exécution.

Lire la suite