Educated guesswork is no substitute for thoughtful observation.
Jim Benson
Publicités
Note de lecture : Release It ! 2nd edition, par Michael T. Nygard
Note : 9 ; Actualisé et repensé, mais toujours aussi riche et pertinent !
11 ans se sont écoulés depuis la parution de la première édition. De mon point de vue, c’était le premier vrai texte évoquant la culture devops. A vrai dire, j’ai continué à le considérer ainsi jusqu’à la parution de cette nouvelle édition. De prime abord, celle-ci semble avoir subi une cure d’amaigrissement… en fait, c’est le papier qui est plus fin, car celle-ci compte le même nombre de pages, mais réparties en 17 chapitres (au lieu de 18) sur 3 parties. Il s’est passé des choses en 11 ans, et nous allons voir que le texte le reflète bien.
Le chapitre d’introduction n’a guère bougé dans son essence avec son fameux « un million par ci, un million par là… », mais sa forme a été remaniée. La première partie « create stability » compte aussi toujours 4 chapitres. Je retrouve au chapitre 2 la même histoire horrible de l’exception qui a mis un aéroport en rideau. L’erreur dans le code est visible sans être grossière, mais les conséquences sont catastrophiques. L’ambiance est campée pour ce livre emblématique. Le chapitre 3 développe sur cette base la notion de « cracks propagation » en faisant référence au livre de James Chiles « Inviting Disaster ». Je ne retrouve pas dans ce chapitre le diagramme de patterns de l’édition précédente : dommage.
Au chapitre 4, on retrouve les antipatterns de stabilité. C’est un chapitre particulièrement conséquent avec 60 pages. Sa structure épouse celle de l’édition précédente, mais le propos est sensiblement modernisé dans cette seconde édition. Cela dit, j’avais trouvé l’édition précédente plus pédagogique à cet égard. L’auteur semble avoir voulu gagner en efficacité dans son propos. Cela a un prix. Après les antipatterns, les patterns. Ils sont présentés au chapitre 5. Les patterns sont les mêmes d’une édition à l’autre, mais l’auteur a fait le choix de les modifier dans le détail. L’ensemble est un peu modernisé sans que la différence soit notable.
Note de lecture : Les Innovateurs, par Walter Isaacson
Note : 8 ; La grande saga de l’informatique … avec un point de vue subjectif.
Walter Isaacson est le biographe de Steve Jobs, entre autres chose. Il fut aussi journaliste au Times. Bref, il sait écrire et raconter, on s’en rend très vite compte. Le format poche du livre fait 860 pages, mais c’est au format Kindle que je l’ai lu. Il est structuré en 12 chapitres qui chacun couvre une période de l’histoire de l’informatique.
L’auteur a décidé de remonter aux prémices avec un chapitre consacré à Ada Lovelace ou plus exactement à Ada et Babbage, mais centré toutefois sur la fille de Lord Byron. Un chapitre sans concessions sur celle que l’on considère comme la pionnière de la programmation, mais qui vantait sans retenue ses capacités intellectuelles. C’est sur la publication « Sketch of the Analytique Machine » par LF Menebrea, mais traduit en Anglais par Ada et augmenté de ses notes que s’attarde Walter Isaacson. Ce sont ces notes (qui occupent d’ailleurs plus de place que le texte original) que se trouvent toutes les trouvailles et les projections concernant la machine analytique et cela est fort bien analysé par l’auteur.
Le second chapitre s’intitule « l’ordinateur », il s’agit bel et bien de l’invention de l’ordinateur. L’auteur nous dresse le paysage des prémices de l’ère numérique avec les Shannon, Lorenz, Aiken, Atanasoff et surtout Mauchly, car l’auteur ne peut se vanter d’être objectif en dédaignant l’aspect programmable du Mark I et II au profit du fonctionnement à lampe du non-programmable Eniac. Le rôle Von Neumann dans ce projet y est clarifié, entre autre qu’il permit à l’industrie informatique d’éclore à cette époque en coupant l’herbe sous le pied de la brevetabilité de l’architecture des machines. Ce second chapitre est assurément l’un des plus passionnants.
Your best software product has zero lines of code, and after that it gets worse.
Craig Larman
Note de lecture : Seven Databases in Seven Weeks, par Eric Redmond & Jim R. Wilson
Note : 4 ; 7 livres compressés en un seul.
Je sais que j’aurais dû, mais non je n’ai pas pris plaisir avec ce livre. Mais reprenons depuis le début. Cet ouvrage est calqué sur l’approche de « Seven Languages… ». Le principe est simple : les auteurs abordent 7 bases de données en nous proposant une initiation à chacune d’entre-elle sur 3 jours.
Chaque chapitre est consacré à une base de données, et chacun d’entre-eux est effectivement structuré en 3 parties, soit 9 chapitres en comptant introduction et conclusion pour un total de 310 pages environ. Le tout est très dense et la pente est rude pour chaque chapitre. Elle est d’autant plus rude pour moi que les langages de prédilection choisis sont Ruby et JavaScript (même quand ce n’est pas le langage naturel de la base), que je ne connais pas plus que je ne les apprécie car il s’agit de langages dynamiques.
Je passe l’introduction qui dresse un panel des différentes bases et des paradigmes sur lesquels elles s’appuient. Le second chapitre est consacré à PostgreSQL. C’est du relationnel, je suis en terrain connu. Les premier et second jour vont assez bien, même si on monte assez vite dans les tours avec les fondements mathématiques, les Windows functions et autres triggers. On ne perd pas de temps ! Le 3ème jour nous conduit directement dans les spécificités de PostgreSQL avec les cubes multidimensionnels et l’indexation full text. Je me retrouve aux limites de mes connaissance bien plus vite que prévu.
Note de lecture : The Unified Process Transition and Production Phases: Best practices in implementing the UP, par Scott W. Ambler & Larry L. Constantine
Note : 3 ; Un quatrième opus de la suite dédie à UP, d’avantage cohérent avec le sujet
Dernier opus de la série consacrée à Unified Process, celui-ci reprend la formule qui nous a tellement enchantée dans les volumes précédents. Celui-ci est fort de 280 pages et compte 8 chapitres, introduction et conclusion incluses. L’introduction, justement, est le seul chapitre réellement écrit pour correspondre au titre de l’ouvrage. Il compte une douzaine de pages et cherche à replacer chaque workflow dans le contexte de la phase de transition.
Le second chapitre va couvrir 35 pages et se focalise sur le workflow de déploiement. Il compte 6 articles dont 3 sont signés Scott Ambler (l’éditeur de l’ouvrage si vous avez suivi). Contrairement aux ouvrages précédents, la plupart de ces articles ont effectivement trait au déploiement et au rollout en phase de transition. Leur lecture nous laisse apparaitre le chemin parcouru depuis lors grâce au mouvement devops !
Le chapitre 3 traite du workflow « tests », et ce ne sont pas moins de 8 articles que nous retrouvons là ! Cem Kaner nous parle du recrutement de testeurs. Cela a peu à voir avec la phase de transition, mais non seulement l’idée est intéressante, mais on y trouve beaucoup de matière pertinente. Dans la même veine, James Bach évoque la formation des testeurs. Le propos mériterait toutefois d’être actualisé. Dans le style nostalgie, McGregor & Major nous parlent de « maximiser le ROI en sélectionnant les cas de test » ! Voilà une pensée définitivement issue de l’ancien monde ! Plus original, « don’t waste your bugs ! » nous propose une analyse qualitative des bugs pour estimer la maturité du code ! Le worflow « Project Management » est au menu du chapitre 4 et nous propose 6 articles. Bien qu’ils aient peu à voir avec le sujet, « making lemonade with lemon » aborde les besoins psychologiques des équipes. Un des rares écrits de Norman Kerth, donc à ne pas rater. « Looking back » est co-signé par Karl Wiegers et Johanna Rothman ce qui est en soi une raison de s’y arrêter. L’autre est que l’on y décrit la démarche de rétrospective.
Note de lecture : The Unified Process Elaboration Phase, par Scott W. Ambler
Note : 2 ; Une compilation bien hétéroclite !
Tout comme le volume dédié à la phase « d’inception », ce volume regroupe un ensemble d’articles en provenance de Software Développement Magazine. Ils sont globalement organisés en worflows, ce qui nous donne 8 chapitres (en comptant introduction et conclusion), pour un total de 260 pages hors annexes.
Le premier chapitre est purement introductif. Il met en contexte le processus itératif par rapport aux processus en cascade et donne un aperçu des différents workflows, puis plus précisément de la phase d’élaboration. Tout cela ressemble pas mal au premier chapitre du volume consacré à la phase d’inception. Cela reste aussi très général. Place au workflow « Project management » au chapitre 2, qui va regrouper 6 articles. J’en retiens essentiellement deux : « managing collaborations » par Mary Loomis évoque les propriétés essentielles du cadre pour rendre possible cette collaboration. « implementing feature teams » par Jim McCarthy préfigure les équipes pluridisciplinaires que l’on retrouvera dans le fonctionnement agile. Aucun des 6 articles n’est lié à la phase d’élaboration ni même à Unified Process.
Le chapitre 3 aborde le workflow « business modeling” et ce sont 4 articles qui sont mis en avant ici. Malgré la présence d’un article de Martin Fowler, aucun d’entre eux ne retient mon attention. Ce workflow semble décidément une source d’embarras à décrire… Nous arrivons maintenant au chapitre 4 qui va évoquer le workflow de gestion des exigences. Nous avons 5 articles ici. Karl Wiegers nous offre toujours une prose de qualité et « Writing Quality Requirements » s’inscrit dans cette mouvance. Je garde. Puis « Prototyping from the User’s Viewpoint » est un des rares articles qui cadre vraiment avec la phase d’élaboration d’UP. Je garde également !
Returning from work feeling inspired, safe, fulfilled and grateful is a natural human right to which we are all entitled and not a modern luxury that only a few lucky ones are able to find.
Simon Sinek
Note de lecture : Lex & Yacc, par John R. Levine, Tony Mason & Doug Brown
Note : 8 ; Une référence de grand choix pour Lex et Yacc. En tout cas, la mienne !
Comme son nom l’indique, ce volume traite les utilitaires de la famille Lex & Yacc, dont Flex et Bison, du GNU, qui ont la préférence des auteurs. Ce guide introduit progressivement l’outil d’analyse lexicale d’abord, puis l’outil grammatical ensuite, en introduisant progressivement les concepts particuliers de ces outils.
Le texte tient en 240 pages structurées en 9 chapitres. Il ne faudra pas oublier les 70 pages d’annexes dont l’utilité est assez variable, mais précieuses pour certaines. Le premier chapitre s’intitule sobrement « Lex & Yacc » et nous invite à produire un premier analyseur syntaxique avec son analyseur associé. Les 25 pages de cette mise en bouche sont pas mal denses, et sont d’ailleurs bien plus qu’une mise en bouche : on un produit un analyseur syntaxique simple avec toutes ses composantes !
Le second chapitre se focalise uniquement sur Lex et au travers de deux exemples en explore tout le potentiel. Un travail soigné même si là encore il n’est pas question de relâcher son attention ! Au chapitre 3, l’analyseur syntaxique Yacc a droit au même niveau d’attention. On y développe la notion d’arbre syntaxique et toutes les subtilités de la construction d’une grammaire. C’est du solide.
Note de lecture : Java Beans : Guide du programmeur, par Robert Englander
Note : 6 ; Voyage tranquille au temps des Java Beans
Les Java Beans sont un sujet des premiers temps de Java, il en est devenu désuet. Alors que JEE était en train de promettre aux oubliettes ce fier modèle de composant, Spring lui aura offert une seconde jeunesse. Par un étrange trait du destin, c’est JEE qui se sera offert son ticket pour le musée d’archéologie !
Bien que le sujet soit assez basique, Robert Englander nous aura produit un ouvrage de 260 pages ! Celui-ci compte 10 chapitres que nous allons explorer. Le premier chapitre nous propose sur une dizaine de pages un tour d’horizon des propriétés des Java Beans, mais sans réellement rentrer dans ce qu’ils sont réellement. C’est assez superficiel. Beaucoup plus sérieux, le second chapitre explore en profondeur le modèle d’évènements des Java Beans. Passé de mode (et je suis gentil), ce chapitre est l’un des intérêts de ce texte vieux de plus de 20 ans. D’autant que le sujet est traité de manière exhaustive et avec pédagogie. Je regrette juste que ne soit pas adressé la représentation interne et le mécanisme de dispatching de ces évènements. Oh nostalgie, le chapitre se termine par AWT (paix à son âme) grand consommateur d’évènements Java Beans.
On continue sur le thème des évènements au chapitre 3, avec les adaptateurs d’évènements (qui sont en fait des listeners) et une pincée de réflexion pour rendre cela générique. Et toujours la déclinaison AWT en fin de chapitre. Eh oui, en 1997, c’était important. Le chapitre n’est pas grandiose, mais bien expliqué et bien illustré. Place aux propriétés au chapitre 4. Le chapitre est assez exhaustif sur la question, avec entre autres les évènements de changement de propriétés.
