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 !

Lire la suite

Publicités

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.

Lire la suite

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.

Lire la suite

Note de lecture : The Unified Process Inception Phase, par Scott W. Ambler & Larry L. Constantine

Note : 2 ; Pratiquement le désappointement annoncé !

Autant prévenir tout de suite, ce livre est une compilation d’articles parus dans « Software Development », ce qui peut expliquer l’aspect quelque peu hétéroclite de l’opuscule. L’intérêt des textes eux-mêmes est assez variable et va de passable à intéressant.

Les 280 pages de ce volume sont structurées en 7 chapitres qui sont autant de thèmes. Chaque chapitre rassemble lui-même plusieurs articles. Aucune originalité dans le premier d’entre-eux qui s’intitule sobrement « introduction ». Pour me faire mentir, ce chapitre-ci n’est pas une compilation d’article, mais une introduction, à Unified Process d’abord et à la phase d’inception ensuite. Ce n’est pas mal du tout en fait.

On rentre dans le dur au second chapitre « Best practices for business modeling » qui rassemble 5 articles sur 45 pages. A part peut être l’article consacré aux cartes CRC, les autres donnent vraiment l’impression d’être rentrés aux forceps dans ce thème. Le pire étant je pense la présentation d’UML par Scott Ambler qui n’a pas grand-chose à voir avec la choucroute. Si les contributeurs ont du mal à comprendre ce qu’est la modélisation métier, cela s’arrange au chapitre 3 consacré aux exigences. Et cela commence même très bien avec l’article d’Ellen Gottesdiener dédié au décodage des besoins métier. J’approuve aussi l’article suivant qui clame les droits du client, signé par Karl Wieger. L’article sur le JAD et les règles métiers méritent aussi une mention. Finalement seul le papier de Scott Ambler (encore lui) finira dans la corbeille du même nom.

Lire la suite

Note de lecture : Les JSP, par Eric Chaber

Note : 2 ; Un peu d’arnaque à l’horizon

Eh bien oui : je cherchais un texte assez simple et facile d’accès pour écrire quelques pages JSPs, juste de quoi me faire de l’auto-formation. Un livre ne français m’était apparu être un bon choix. Ce ne fut pas le cas, nous allons voir pourquoi.

L’ouvrage est assez modeste avec ses 190 pages sur 10 chapitres. Cela commence vraiment très bas avec les deux premiers chapitres. Certes ils sont courts, mais je ne m’attendais pas à ce que moi lecteur je sois pris aussi bas qu’une explication sur le langage java s’impose… Par comparaison, les 20 pages du troisième chapitre paraissent costauds, surtout que l’on passe en un clin d’œil de la présentation de Java EE aux JSP. Au moins, même s’il ne fait pas rêver, ce chapitre nous montre-t-il les fondements des JSP !

Place au chapitre 4 … et à la connexion aux bases de données. Car l’auteur fait tout depuis les pages JSP, y compris du code JDBC. La mise en tableau des résultats fait partie du package, on s’interrogera juste sur la pertinence du design… Le chapitre 5 est court et nous permet de reprendre notre souffle. Il traite exclusivement des cookies. Au chapitre 6 on attaque du lourd avec les Java Serveur Tags. Malheureusement, ce chapitre ressemble surtout à un manuel de référence où l’auteur nous dispense de temps à autre (visiblement à contrecœur) quelques exemples. Bref, passons.

Lire la suite

Note de lecture : Camel in Action, par Claus Ibsen & Jonathan Anstey

Note : 7 ; La qualité des grands classiques “in action”

La série « in action » chez Manning est en principe une recette éprouvée. Elle doit permettre de rencontrer des ouvrages solides, dont les sujets sont bien abordés de manière progressive et illustrée en se salissant les mains. Malheureusement trop de titres échouent aux portes des critères qualité. Rien de tout cela ici. Le texte est solide, abondement pourvu d’illustrations (parfois trop, certaines ne servent à rien) et d’exemples de code.

Camel est un framework recelant de nombreuses facettes, parfois insoupçonnées. Les auteurs les abordent de manière systématique avec un bon niveau de profondeur. Voyons cela. D’abord ce volume nous assène 460 pages hors annexes. Sérieux me direz-vous ? La seconde édition sortie depuis accuse elle dans les 900 pages ! Revenons à celle-ci. L’ensemble est structuré en 3 parties pour un total de 14 chapitres. Oui, cela signifie donc des chapitres plutôt conséquents.

La première partie « first steps » est aussi la plus courte : moins de 60 pages avec seulement deux chapitres. La première partie « Meeting Camel » nous permet de faire le tour du propriétaire et de découvrir notre premier « hello world » de manière très agréable. C’est aussi l’occasion de faire connaissance avec les concepts de base de Camel. Les Enterprise Intégration Patterns (EIP) sont même évoqués mais sans plus. Coup de zoom au second chapitre « Routing with Camel » qui va en fait assez loin dans les différents concepts de routage, allant jusqu’au multicast ! L’étude de cas abordée ici n’est pas utilisée au fil de l’ouvrage de façon mortelle, mais au moins sert-elle de point d’ancrage. Les auteurs switchent aussi beaucoup entre le « Java DSL » et le « Spring DSL » allant jusqu’à utiliser le Java DSL avec Spring (en fait leur cocktail préféré ». Cette bascule permanente permet certes d’aborder de manière exhaustive les deux manières de faire sur tous les sujets mais est aussi assez fatigante.

Lire la suite

Note de lecture : From Java to Ruby, par Bruce Tate

Note : 5 ; Un pamphlet pour la transition vers Ruby.

Ou comment l’un des chefs de file du monde Java prend le virage vers Ruby ! Ce livre est à la fois un argumentaire et une base de construction de stratégie de passage à Ruby. Un objectif limité en 8 chapitres seulement et 150 pages. Certes, l’enthousiasme de l’auteur éveille pour le moins l’intérêt et l’argumentaire est bien construit :

  • Un langage à typage dynamique, dont la productivité est dcuplée par rapport à Java.
  • En lieu et place d’une profusion de frameworks, un petit nombre de frameworks très en vue, dont le vaisseau amiral : le très remarqué Ruby on Rails.
  • Une réponse simple aux problèmes les plus fréquents, au lieu d’une solution complexe et généraliste.

Lire la suite

Note de lecture : Testing Java Microservices, par Alex Soto Bueno, Andy Gumbrecht & Jason Porter

Note : 6 ; Très pertinent sur la stratégie et la mise en œuvre des tests, souvent moins sur la clarté des explications.

Voici un livre qui s’est fait attendre plusieurs années. Au début, il s’agissait de produire un texte consacré à Arquilian. Finalement, le contexte s’est élargi aux tests de microservices de manière plus générale, Arquilian continuant à se tailler la part du lion, mais d’autres outils de test complétant le paysage, comme nous le verrons.

L’ouvrage totalise 260 pages réparties en 10 chapitres. Cela donne une moyenne de taille par chapitre relativement raisonnable mais quand même un peu plus élevée que ce que j’apprécie généralement. On démarre fort logiquement par un premier chapitre très court pour introduire les microservices. Il s’agit de présenter l’architecture microservices au niveau conceptuel. Une présentation pas vraiment fameuse, avec une représentation qui ne me parle guère et une architecture s’éloignant un peu de celle de Newman et où j’aurais aimé une pincée d’architecture hexagonale.

Le second chapitre présente l’application de test, ou plutôt l’architecture de test, sur une petite trentaine de pages. En fait, les auteurs ont fait le choix de rassembler des architectures techniques différentes : Spring Boot, TomEE et WildFly Swarm. A l’exception du vidéo service sur Spring Boot, le reste s’adosse à Java EE 7 ! Un choix dépassé depuis longtemps, peut-être justifié par le fait que les auteurs sont employés de JBoss ou parce qu’initialement Arquilian était dédié à JEE ? Quoi qu’il en soit, ce choix aurait dû être abandonné, il y avait déjà fort à faire en se contentant de Spring Boot et cette multiplicité introduit une regrettable complexité et de la confusion.

Lire la suite

Note de lecture : La structure des revolutions scientifiques, par Thomas S. Kuhn

Note : 4 ; Attention, lecture difficile !

Ce livre est un grand classique, peut-être pas en littérature informatique, mais au moins en histoire des sciences et peut-être en philosophie des sciences. Je m’y suis intéressé car il a été évoqué par Craig Larman lors d’une de ses conférences.

Le texte de Kuhn s’articule autour d’une idée forte et novatrice en ce qui concerne l’évolution des sciences les avancées dues aux grandes découvertes sont en fait des changements de paradigmes « non cumulatifs » par rapport aux périodes dites « normales » précédentes. Lors de ces périodes « normales », une communauté de scientifiques se reconnaissant autour d’un paradigme emploie celui-ci pour résoudre des énigmes proposées par la nature en améliorant les lois s’appuyant sur ce paradigme. La sciences « extraordinaire » est précédée de crises où le paradigme précédent s’avère impuissant à résoudre de nouvelles énigmes et où le nouveau paradigme propose des solutions plus simples tout en adressant les problèmes déjà résolus.

Dans les premiers chapitres, l’auteur s’efforce de définir la notion de science de normale et de revisiter la notion de paradigme. Ce dernier définit aussi le groupe et les protocoles qui entoure celui-ci : règles admises non-écrites et processus d’adoption des membres.

Lire la suite

Note de lecture : Comment leur dire … La Process Communication 2nd édition, par Gérard Collignon

Note : 4 ; Un tour assez honnête de la Process Com, mais qui en garde sous le pied.

La process com est un des outils fortement médiatisés du coaching. Il m’apparaissait important d’attaquer ce domaine par un ouvrage adéquat. Mais la process com, c’est aussi un business model, et c’est là que cela se gâte. Voyons cela.

Le texte compte 260 sur 13 chapitres, le tout structuré en 2 parties. La première d’entre-elles, consacrée aux fondements couvre 150 pages sur 8 chapitres. Les types de personnalité, abordés au premier chapitre est un élément primordial de la Process Com. C’est bien illustré ici, via le fil rouge de l’ouvrage. Le style est un peu ampoulé, mais ça passe. C’est assez logiquement que le second chapitre est là pour expliquer la structure de personnalité, la fameuse pyramide de la Process Com, en expliquant les concepts de phase et de base, par exemple. C’est clair mais cela donne une impression de superficialité, en étant trop descriptif et pas assez explicatif. Le biais « plaquette publicitaire » commence à apparaitre.

Le chapitre 3 revient sur les types de personnalité en détaillant leurs besoins. Étrange d’avoir placé ce chapitre ici et non dans la continuité du premier. Cela apporte certes quelques éclaircissements, mais sans être éblouissant pour autant. On rentre dans des considérations un peu complexes au chapitre 4 avec les canaux de communication : différents types de canaux de communication (nourricier, informatif, émotif, etc.) fonctionnant ou ne fonctionnant pas avec des « parties de personnalité (directeur, ordinateur, protecteur, etc.) et bien sûr… Chaque type de personnalité a une partie de personnalité prédominante. Intéressant, mais bien complexe à utiliser dans la réalité.

Lire la suite