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