Note de lecture : Practices of an Agile Developer, par Venkat Subramaniam & Andrew Hunt

Note : 3 ; Le petit frère simplet du « pragmatic programmers »

Tout a-t-il été dit sur le développement agile ? Si l’on est en droit d’en douter, la lecture de ce livre nous laisse penser le contraire. Car, franchement, à la lecture de cet opuscule on ne voit rien de neuf. Donc, je suis déçu, et étonné d’être déçu en ayant constaté qu’Andrew Hunt avait cosigné ce livre ! Au-delà d’une introduction et d’une conclusion destinés à parler de la migration vers l’agilité (mais sans propos utiles, je dois dire), le texte se compose de 7 chapitres :

  • Begining agility : Donne des pistes sur le « par où commencer », et comment se comporter au sein de projets agiles.
  • Feeding agility : Aborde les points sensibles, les « accélérateurs agiles », destinés à faire passer les projets à la vitesse supérieure.
  • Delivering what users want : Aborde le point crucial de la réalisation du projet par rapport à la demande utilisateur ; comment prioriser et comment obtenir du feedback.
  • Agile feedback : Aborde spécifiquement l’aspect retour d’expérience, comment mesurer les progrès et estimer la qualité et la pertinence de ce qui est réalisé.
  • Agile coding : Traite des pratiques liées au codage. Ces pratiques se rapprochent de celles de l’extrême programming.
  • Agile debugging : Ce chapitre se focalise sur la recherche des anomalies, mais aussi sur la façon d’en garder trace et de les capitaliser.
  • Agile collaboration : Donne des indications sur les façons d’interagir au sein d’une équipe de développement, mais aussi hors de cette équipe de développement.

L’ouvrage, bien Que découpé en chapitres est essentiellement constitué d’un ensemble d’items, traités de façon similaires : tout d’abord les auteurs énoncent l’anti-pattern (illustré d’une icône représentant un diable). Il s’en suit une discussion sur le sujet pour expliquer le bien fondé d’opérer différemment. Les auteurs énoncent ensuite une contre-proposition (illustré d’une icône d’ange). L’item se termine par deux paragraphes : le « what it feels like » expose les conséquences du changement opéré, tandis que le « keeping your balance » donne les pours et contres de l’item, en mettant l’accent sur les facteurs défavorisant qui peuvent être rencontrés.

En conclusion, ce court opuscule de 170 pages n’est guère une lecture indispensable. Bien au contraire, on lui préfèrera son grand frère, le « Pragmatic Programmer ».

practices-agile-dev-pragprog

Référence complète : Practices of an Agile Developer – Venkat Subramaniam & Andrew Hunt – Pragmatic Bookshelf 2006 – ISBN : 0-9745140-8-X

Practices of an Agile Developer: Working in the Real World

http://www.goodreads.com/book/add_to_books_widget_frame/097451408X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

http://www.goodreads.com/book/add_to_books_widget_frame/1934356816?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Agile Coaching, par Rachel Davies & Liz Sedley

Note : 5 ; Une vision claire de ce qui est nécessaire à un projet agile, mais un texte plutôt entre la conduite de projet et le coaching proprement dit.

Coacher une équipe pour la rendre agile est sans aucun doute un exercice difficile. Que faire ? Comment interférer, comment aider l’équipe à se prendre en main, à quel moment faut-il faire preuve de fermeté ? Bref, faire les bonnes actions, adopter les bonnes approches et les bonnes attitudes ne sont pas choses aisées et la frontière entre le succès et l’échec est parfois bien mince.

L’objectif de ce nouvel opus des pragmatic programmers est d’aider le coach à agir de manière opportune le long des pratiques agiles classiques. L’écueil de ce type d’ouvrage est de tomber dans une nouvelle description des pratiques agiles en négligeant la façon dont le coach doit ou peut entreprendre l’équipe sur chacun de ces sujets.

Je ne vais pas revenir sur chacun des chapitres, il y en a 14, pour 200 pages, sachez donc que la brièveté des chapitres joue en faveur de l’efficacité du texte et donne un rythme à la lecture, celle-ci n’est donc pas pesante. Je peux toutefois dire quelques mots à propos des 4 parties qui découpent le livre.

La première partie (ainsi que la dernières) sont celles qui concernent réellement la partie coaching « humain ». Les 4 chapitres couverts sur 58 pages sont consacrées au travail avec les personnes et avec les équipes. Le parti pris est ici de « coacher par l’exemple » et non de se ternir en retrait. Bien sûr l’observation, le feedback et la communication font partie des outils abordés. C’est fort peu à propos que je parle d’outil, car le texte montre plutôt des directives et si j’ai certaines idées générales une fois la dernière page tournée, je me suis quand même senti plutôt démuni.

La seconde partie nous montre clairement que l’expérience des auteurs vient plus des projets agiles que du pur coaching. En effet cette partie est consacrée aux pratiques de projet : planning meeting, stand-up, etc… Le tout sur 4 chapitres et un nombre de pages qui va de pair avec la première partie. Ici on est en terrain solide et les auteurs savent parler de la matière. Dommage que la matière n’ait plus l’attrait de la nouveauté car ces sujets ont déjà été largement traités par ailleurs. Le texte est intéressant mais devrait prendre place dans un ouvrage sur les projets agiles plus que dans un texte consacré au coaching.

Un pas plus loin, la troisième partie traité des pratiques de craftmanship : qualité du code, build, définition du « done ». Là encore les auteurs connaissent leur sujet, mais on en est plus à donner des conseils sur les pratiques de développement qu’à guider l’équipe ou ses membres.

La quatrième partie est dédiée au feedback : démo, rétrospective et progression du coach lui-même. Le chapitre sur la démo est dans la continuité des chapitres précédents, donc d’avantage lié à la conduite de projet qu’au coaching tandis que le chapitre sur la rétrospective, s’il est plus dans la continuité de ce à quoi je m’attendais n’est qu’un condensé de « Agile retrospective » d’Esther Derby, lecture que l’on préfèrera. Cette partie me laisse un goût d’inachevé.

Au final, le bilan est assez mitigé. J’ai trouvé que l’ouvrage insistait trop sur les pratiques déjà bien connues : standup, planning meeting, rétrospectives, démonstrations, ainsi que sur les activités d’ingénierie (build, design, tests). Fort heureusement, le tout est émaillé de conseils et d’histoires venant de l’expérience des auteurs. Mais ceux-cis ne constituent pas une part assez importante du livre à mon goût. J’avoue avoir quand même apprécié les sections « hurdle » et « check-list » à la fin de chaque chapitre.

Si je semble quelque peu déçu (et peut-être un peu sévère dans a notation), c’est sûrement que j’attendais beaucoup de ce livre en particulier et du « pragmatic bookshelf » en général, dont la qualité s’avère quand même élevée de manière récurrente. Mais je n’irais pas jusqu’à déconseiller la lecture de ce livre. Au pire, vous y aurez appris des choses sans consacrer trop de temps à la lecture !

agile-coaching-pragprog

Référence complète : Agile Coaching – Rachel Davies & Liz Sedley – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 643 2

Agile Coaching


http://www.goodreads.com/book/add_to_books_widget_frame/1934356433?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Blue Ocean Strategy par W. Chan Kim & Renée Mauborgne

Note : 7 ; La stratégie de la non compétition expliquée

Le « blue ocean strategy » est devenu un grand classique du marketing, et ce livre en est la bible. La première partie explique (exemples à l’appui) ce qu’est cette stratégie et pourquoi elle est si porteuse. Les exemples sont clairs tout comme l’est le raisonnement.

En deux mots, et en simplifiant beaucoup : plutôt que de combattre dans un secteur d’activité fortement concurrentiel où l’on se comparera aux compétiteurs en terme de prix d’images ou de performance (le red ocean), l’idée est de créer son propre espace (le blue ocean) où l’on ne peut être comparé aux autres acteurs du marché. Bien sûr, c’est plus facile à dire qu’à faire. Tout d’abord cela à fort à voir avec l’innovation et ensuite il faut s’assurer que la création de ce nouveau marché attirera des clients, que ce soient les anciens ou un nouveau segment.

La suite du livre se focalise sur la démarche pour arriver dans ce type de positionnement. La aussi, et toujours bien aidé par des exemples on comprend ce qu’il faut faire et ne pas faire. Cela commence par les « principes de formulation » : se focaliser sur la « big picture », aller chercher au-delà de la demande directe formulée par le marché, etc.. Pour cela on utilise la nouvelle courbe de valeur : quels facteurs doivent être réduits ? Lesquels doivent être augmentés ? Lesquels doivent être éliminés ? Lesquels doivent être créés, que l’industrie n’a jamais offert ?

La seconde partie « formuler le blue ocean » se focalise sur la façon de faire émerger celui-ci d’un marché existant. La chapitre 3 évoque la reconstruction des limites du marché. Les auteurs proposent 6 chemins pour cela :

  • Examiner les autres secteurs industriels susceptibles de proposer une alternative.
  • Examiner les sous-ensembles de stratégies au sein du secteur industriel où l’on opère.
  • Explorer la chaine d’achat.
  • Evaluer l’offre des produits et services complémentaires.
  • Evaluer l’attraction fonctionnelle et émotionnelle des acheteurs.
  • Regarder les tendances à travers le temps.

Les 6 directions qui devront être explorées serviront à construire le planning stratégique. C’est le sujet du chapitre 4 : construire la « big picture ». Celui-ci propose de Visualiser cette stratégie en 4 étapes :

  • Visualiser la prise de conscience.
  • Visualiser l’exploration (en s’appuyant sur les 6 chemins vus précédemment)
  • Visualiser la stratégie à venir.
  • Visualiser la nouvelle stratégie en terme de « avant / après ».

A partir de là, le chapitre 5 évoque la façon de dépasser la demande existante. C’est le principe des trois tiers de « non clients » qu’il faut identifier, au-delà de ce qui est notre marché actuel : ceux qui sont prêts à devenir nos clients, ceux qui refusent d’être nos clients et ceux qui ne sont simplement pas explorés.

Le chapitre 6 se concentre sur l’exécution du plan stratégique : évaluer l’utilité pour l’acheteur, cibler le prix, calculer les coûts et construire l’adoption.

Il faut maintenant exécuter un plan qui nous y amènera : c’est le sujet de la troisième partie.

Le chapitre 7 évoque les obstacles organisationnels. Ils peuvent être cognitifs (le blocage sur le statu quo), politiques (l’opposition de ceux qui n’ont pas intérêt à sortir de la situation existante), motivationnels ou liés aux ressources existantes limitées.

Le chapitre 8 se focalise sur le « fair process » : comment mettre en action une nouvelle stratégie dans l’entreprise en engageants les personnes qui y participeront ?

La stratégie « blue ocean » n’est pas un processus statique, elle s’entretient et évolue dans le temps. Le chapitre 9 évoque la tenue de ce processus dans le temps.

Personnellement, étant un béotien du marketing, ce fut une découverte, une nouvelle façon de voir le positionnement d’un produit. Il s’agit d’une nouvelle façon de dire : « si les règles du jeu ne te plaisent pas, change les règles ! ». Il s’agit aussi probablement d’une application particulière de certains préceptes de l’art de la guerre.

Je recommande vivement !

Blue Ocean Strategy

Référence complète : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M (Kindle edition)

Vous trouverez aussi en ligne une mind map reprenant les éléments du livre

Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant


http://www.goodreads.com/book/add_to_books_widget_frame/1591396190?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Concurrent Programming in Java, second edition, par Doug Lea

Note : 9 ; Un remarquable ouvrage sur le multithreading, pour Java et pour les autres langages également … même si on accueillerait volontiers une mise à jour !

J’ai écrit cette note en 2005. Les livres liés à des technologies particulières ont fâcheusement tendance à mal accueillir le passage du temps. Celui-ci subit moins cette tendance car il s’intéresse plus aux concepts sous-jacents mais il vous faudra certainement relativiser certaines parties de mon propos.

S’il est un sujet d’importance sur le développement Java peu abordé aujourd’hui, c’est bien la programmation concurrente. Sans être ignoré, le multi-threading est largement mis de coté, ne serait-ce que parce que le développement coté serveur ne permet pas sa mise en œuvre. Or, il s’agit bien là d’un aspect majeur de conception, important coté client, et plus important encore avec l’avènement des clients riches. O, développeur Java, tu as bien de la chance dans ta misère, car à ta disposition un livre sur le multithreading tu as ! Nous parlons bien entendu du livre de Doug Lea. Bien sûr, il existe d’autres livres sur le sujet, ne vous attardez pas sur ceux-là : le livre de Doug Lea est LE livre. En fait, Doug Lea est le multithreading en Java, car depuis la version 1.5, l’API officielle dédiée au multi-threads est celle développée par l’auteur.

Mais revenons au livre lui-même. Et là, comme disent les jeunes : c’est du lourd ! La lecture des 380 pages du volume n’a rien d’une promenade bucolique, le texte et l’information sont denses. On aurait pu s’attendre à un livre traitant des spécificités de Java sur le multithreading, cet ouvrage va bien au-delà. Comme indiqué dans le titre, on parle avant tout de principes de conception et de patterns, puis de mise en œuvre en Java. C’est l’une des forces du livre : focaliser sur des principes de conceptions à l’aide de patterns, décrivant ainsi le contexte d’utilisation. L’ensemble est supporté par des représentations UML lorsque c’est nécessaire et du code Java avec juste le niveau de détail qui convient. On dénombre ainsi 17 patterns, répartis en 4 chapitres seulement, couvrant les sujets suivants :

  • La programmation concurrente : Ce chapitre évoque les principes de base de la programmation multithreads et des concepts liés tels que la synchronisation, les queues d’évènements, les pools de threads, etc. La base, quoi !
  • Les exclusions : On attaque les choses sérieuses, ou quelles sont les stratégies de base sur l’exclusion (l’élimination, la gestion dynamique ou la gestion structurelle), et comment celle-ci se déclinent en 5 patterns.
  • Les dépendances d’états : Ce chapitre nous montre comment géré en environnement concurrent des comportements dépendants d’états.
  • La création de threads : On couvre ici les choix de conception lié à la gestion au partage et à la création de threads.

Au cas où ce matériel ne suffirait pas à assouvir votre soif de savoir, l’auteur dispense 2 ou 3 pages de références de « lectures supplémentaires » en fin de chaque chapitre. De quoi satisfaire n’importe quelle boulimie ! Les chapitres en eux-même sont hélas un peu volumineux, ce qui conduit à un chapitrage à 4 niveaux, ce qui est trop. L’auteur aurait dû découper le livre en autant de parties et réaliser des chapitres plus courts. Ce sera peut-être ma seule critique.

La qualité de ce livre est en tout point remarquable, c’est en fait une référence incontournable pour quiconque désire s’attaquer au multithreading sur des systèmes objet, même au-delà du langage Java !

Ce livre fait sans contestations possibles, partie de la catégorie des excellents surprises, il est en tout point remarquable, aussi bien par sa couverture du sujet que par sa qualité pédagogique, et ce malgré le niveau relevé du texte. C’est de fait une référence incontournable pour quiconque désirerai s’attaquer au multithreading sur des systèmes objet, même au-delà du langage Java ! Finalement, j’ai un autre regret à formuler : cette édition accuse 5 ans, une 3ème édition mise à jour par rapport à Java 1.5 serait la bienvenue.

Allez Doug, t’as bien mérité ton 9 !

concurent-programming-java

Référence complète : Concurrent Programming in Java, second edition: Design principles and patterns – Doug Lea – Addison Wesley / Java series 2000 – ISBN: 0-201-31009-0

Concurrent Programming in Java: Design Principles and Pattern


http://www.goodreads.com/book/add_to_books_widget_frame/0201310090?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : SQL Antipatterns, par Bill Karwin

Note : 7 ; Au croisement des préoccupations du développeur et du concepteur de base de données

Le pluriculturalisme est un véritable problème en informatique. Prenons le cas qui nous intéresse aujourd’hui : comment concilier le point de vue (valide) du concepteur de base de données, avec les questions d’efficacité d’accès aux données, de normalisation du modèle et de requêtage SQL, avec le point de vue tout autant valide du développeur s’adossant à cette même base de données, pour qui celle-ci n’est qu’un support de persistance ? La réponse est : ces points de vue sont rarement conciliés. En cela ce livre est réellement intéressant car il considère ensemble ces deux points de vue tout au long de nombreux cas de figure de conception de modèles de données constituant autant d’antipatterns. On notera aussi au passage que les exemples sont toujours donnés avec MySQL, toutefois lorsque des spécificités de certains SQBD s’appliquent, l’auteur en fait part.

Le texte est articulé autour de 24 antipatterns constituant autant de chapitres. Leur structure est invariable : objectif, antipatterns, comment le reconnaître, usages légitimes et solution. Cette structure qui montre une bonne appréhension du principe des patterns s’avère très efficace, aussi bien dans le diagnostique du problème que dans l’émergence de la solution. Ces patterns se répartissent par ailleurs en 4 parties dans l’ouvrage.

La première partie est constituée de 8 antipatterns occupant 100 pages ! Elle traite de la structure logique de la base. On y parle de l’usage irraisonné de champs blob, du bon usage des contraintes et des cardinalités (entre autre lorsqu’il faut user de tables intermédiaires). Ces règles paraissent de bon sens aux vieux routiers de la modélisation, mais elles sont souvent enfreintes par les développeurs d’applications peu enclins à passer beaucoup de temps et d’attention sur le modèle et donc prêts à « couper les virages » !

La seconde partie traite de la structure physique de la base. Elle compte 135 pages et 4 antipatterns. On y évoque l’usage intelligent des différents types de champs, mais aussi de clés primaires et d’index secondaires pertinents. Là encore, il s’agit des éléments de base du DBA … qui devraient l’être aussi pour le développeur. Mais l’expérience montre…

Dans la troisième partie (6 patterns, 60 pages) on évoque les requêtes, le bon usage de la valeur « null », des regroupements, mais aussi de l’écriture des « requêtes à tout faire ».

La dernière partie est longue de 6 patterns couvrant 70 pages. On trouve ici diverses bonnes pratiques applicatives pour couvrir par exemple des problèmes de sécurité. Hélas les exemples sont développés en PHP, bien loin de ce que je ne saurais utiliser (aussi bien sur le langage que sur l’architecture). C’est donc le chapitre qui m’a le moins intéressé.

En lisant ce livre j’ai eu l’impression (non la certitude) de lire des choses que je connaissais déjà. Mais j’ai eu aussi l’impression de croiser des cas de figure que j’ai vu appliqués plus ou moins souvent, mais que j’ai tous vu ! J’en conclu que cette lecture devrait faire partie du bagage de tout développeur applicatif, aussi basique que semblent parfois ces concepts ! Le ciblage de l’ouvrage est clair : il s’adresse aux développeurs qui va souvent considérer la base de données comme un artefact de second ordre, un simple moyen de persistance des données qu’il va traiter dans son application.

La vérité est qu’appréhender l’association d’un développement objet (au hasard) et d’une base de données, c’est devoir faire face à la question des paradigmes multiples. Ce livre est original à ce titre car il fait face à cette réalité et va aider le développeur souvent peu sensibilisé à ce problème à monter en compétence.

De plus le texte est clair et bien écrit. Pourquoi se priver de cette lecture ?

sql-antipatterns-pragprog

Référence complète : SQL Antipatterns, Avoiding the pitfalls of database programming – Bill Karwin – Pragmatic Bookshelf 2010 – ISBN : 978 1 93435 655 5

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

http://www.goodreads.com/book/add_to_books_widget_frame/1934356557?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Patterns for Parallel Programming, par Mattson, Sanders & Massingill

Note: 5 ; Le grid computing sous forme de patterns, mais pas à l’usage des débutants!

Difficile de classer ce livre! De prime abord, il est destiné à aborder le grid computing sous l’angle conceptuel, plutôt que par le biais d’une technologie particulière. Cela dit, le texte s’appuie de façon extensive sur 2 environnements parallèles: OpenMP et MPI. Ils sont d’ailleurs introduits de façon conséquente en annexe, pour ceux qui (comme moi) n’ont pas une culture “parallèle” étendue. Pour mener à bien leurs propos, les auteurs proposent une démarche en 4 étapes:

  • Les “finding concurrency” patterns: il ne s’agit pas vraiment de patterns ici, mais d’étape d’analyse, tel qu’on peut les trouver dans une méthode prescriptive.
  • Les “algorithm structure” patterns: ressemblent eux d’avantage à des patterns et proposent des solutions architecturales de traitement, telles que le “divide & conquer”, le “pipeline” ou le “event-based coordination”
  • Les “supporting structure patterns” décrivent les constructions logicielles, les briques de conception permettant la mise en oeuvre des architectures parallèles. La plupart d’entre elles peuvent être utilisées dans le cadre de plusieurs architectures, bien qu’avec des adéquations inégales. Ce sont probablement les “vrais patterns” de cet ouvrage, ils se nomment “master / worker” ou “fork / join”. A ce niveau, les patterns sont illustrés par du code en C, et discutés de façon plutôt exhaustive sur les détails.
  • L’”implémentation mechanism design space” décrit les mécanismes élémentaires sur lesquelles les briques de conception précédemment décrites vont s’appuyer. Nous parlons ici de gestion de threads, d’exclusion mutuelle, de partage mémoire ou de passage de messages, entre autre. Ces mécanismes sont décrits séparément pour les environnements OpenMP et MPI.

En conclusion, j’ai trouvé le livre plutôt “dense”, ce qui est probablement normal vu le sujet traité. Toutefois, il est plus difficile qu’il ne devrait être pour les non initiés, car on plonge trop vite dans les détails de code, et la conceptualisation manque cruellement, ou elle est en tout cas insuffisante, car ce devrait être le propre des patterns.

patterns-parallel-programming

Référence complète : Patterns for Parallel Programming – Timothy G. Mattson, Beverly A. Sanders & Berna L. Massingill – Addison Wesley / Software Patterns Series 2004 – ISBN: 0-321-22811-1

Patterns for Parallel Programming


http://www.goodreads.com/book/add_to_books_widget_frame/0321228111?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Agile Estimating and Planning, par Mike Cohn

Note: 8; La mine d’information de la gestion de projets agile

Déjà auteur d’un ouvrage sur les “User Stories” (et futur auteur d’un autre livre sur la transition vers Scrum) Mike Cohn nous livre ici un texte complet sur les estimations et la planification agile, et c’est vraiment une bonne surprise. A la différence de certains livres qui entretiennent un flou artistique, l’auteur a vraiment fait l’effort de couvrir le terrain du sujet, en découpant le texte en 7 parties, qui totalisent 23 Chapitres (soit 312 pages) !

La première partie “problems and goals” traite des défaillances de la planification classique, pourquoi elle échoue et en quoi l’approche agile est radicalement différente. Les 3 chapitres constituant cette première partie se résument à 32 pages. On débute par la question de l’estimation par le biais du cône d’incertitude. De là, le chapitre 2 aborde les causes d’échec des estimations classiques : multitâche, ignorance des dépendances et estimations se transformant en engagements ! On conclut logiquement cette première partie par un chapitre 3 mettant en relief les vertus de l’approche agile : planification à plusieurs niveaux, boucle de feedback, planification par la valeur métier.

La seconde partie traite de l’estimation. Forte de 5 chapitres totalisant 44 pages, l’auteur a réellement privilégié ici les petits chapitres, condensés et efficaces ! Les deux premiers chapitres expliquent l’approche de l’estimation en “story points” puis en “jours idéaux”, avant d’aborder les techniques collaboratives (planning poker, analogies, wide band delphy, etc.). Plus original, le chapitre 7 évoque la réestimation ! Cette partie se conclut logiquement par une discussion du choix entre story points et jours idéaux.

Prioriser par la valeur est le thème de la troisième partie (50 pages, 4 chapitres). C’est à mon avis la partie la plus ludique de l’ouvrage, car on y découvre l’évaluation par le modèle des cash flows, l’utilisation d’abaques « risque vs valeur » ou encore l’utilisation du modèle de Kano. L’utilisation de ces techniques révèlent parfois certaines user stories comme ambivalentes. Le dernier chapitre de cette partie traite du découpage de ces stories.

Avec la quatrième partie, on aborder le second grand thème du livre : la planification. Il est logique que cette partie soit la plus longue, avec 80 pages découpées en 6 chapitres. Les deux premiers chapitres couvrent les deux niveaux principaux de la planification agile : le release plan, puis la planification d’itération. Les autres aspects couverts dans cette partie sont l’évaluation de la vélocité et les problématiques de synchronisation entre équipes (buffering, planification avec plusieurs équipes). Cette quatrième partie est assez dense, croyez-moi !

C’est au suivi de la réalisation qu’est consacré la cinquième partie. Ce n’est pas un sujet sur lequel l’approche agile met un accent particulier, aussi est-il logique qu’il ne couvre que 34 pages (3 chapitres). Bien entendu, on y parle burndown charts, suivi de l’accomplissement des tâches et communication avec le management.

Les sixième et septièmes parties ne comportent qu’un seul chapitre chacune. Si la sixième partie forme une sorte de conclusion (ou devrais-je dire d’ode) à la planification agile en en listant les qualités, La dernière partie reprend elle l’ensemble des thèmes via une étude de cas. Ce chapitre (assez long) est intéressant car il recolle les morceaux directement en situation, l’ensemble étant narré via des dialogues entre membres d’une équipe de développement, le management et un coach.

On pourrait en douter de prime abord, mais l’estimation et la planification agile couvrent un grand nombre de sujets et de techniques. Le tour de force de l’auteur est de nous présenter une boite à outil très complète de manière concise, efficace et agréable à lire.

C’est tout simplement un incontournable d’une bibliothèque « agile » digne de ce nom!

agile-estimating-planning

Référence complète : Agile Estimating and Planning – Mike Cohn – Prentice Hall 2006 – ISBN: 0-13-147941-5; EAN: 978-0-131- 47941-8

Agile Estimating and Planning


http://www.goodreads.com/book/add_to_books_widget_frame/0131479415?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Performance des Architectures IT par Pascal Grojean, Médéric Morel & Guillaume Plouin

Note : 2 ; Pas aussi bien qu’espéré et souvent hors sujet

Voilà bien un sujet qui me touche de près : comment s’assurer qu’une architecture d’entreprise, composée de multiples applications interagissant, déployées sur une infrastructure ad hoc, fonctionne de façon optimale ? Quels sont les points à vérifier et les pièges à éviter ? Comment mesurer l’ensemble et surtout quoi mesurer ? Si j’ai trouvé là parfois des éléments de réponse, le livre m’a largement déçu.

Celui-ci est long de 260 pages découpées en 4 parties comptant au total 16 chapitres. Donc les chapitres ne sont pas trop longs, ce qui est une bonne nouvelle.

La première partie est consacrée à des généralités « problématiques de performance des SI ». On en prend pour 30 pages et 3 chapitres, ce qui est déjà trop car le propos est complètement creux.

La seconde partie (4 chapitres, 90 pages) est moins creuse mais d’avantage hors sujet. J’ai bien aimé les anti-patterns du chapitre 4, mais qui me disent ce que je sais déjà, sans y apporter de solution. Je n’ose même pas parler de la discussion Web Services versus Rest qui est un propos de développeur, pas d’architecte IT. Un architecte IT doit travailler avec le contexte qui s’offre à lui, il n’a pas le luxe de créer le sien. Le reste de cette partie évoque beaucoup SOA, ce qui n’est pas la raison pour laquelle j’ai acheté ce livre, et souvent n traitant des points qui sont plutôt du ressort de l’architecture logicielle (et j’ai passé l’âge de « l’architecture logicielle pour les nuls »).

La troisième partie a enfin trait au sujet du livre (on est quand même page 127). Elle revendique 70 pages sur 5 chapitres. Chaque chapitre est donc succinct, et en fait superficiel. C’est bien dommage car chacun traite d’un volet important qui mériterait que l’on s’y attarde. En fait, j’aurais bien aimé une partie pour chacun de ces chapitres, en faisant table rase du reste du bouquin ! Les sujets traités sont : les réseaux, le stockage, le clustering, les bases de données et les serveurs d’application. Comme je le disais, difficile d‘être pointu quand chaque chapitre compte à peine 15 pages. Là encore, on ne va pas très loin, vous trouverez mieux sur Wikipedia.

La quatrième partie couvre 60 pages sur 4 chapitres et s’intéresse aux sujets suivants : les techniques de programmation (pas éblouissant et hors sujet), les tests de performances (en soi pas inintéressant, mais on a là qu’une introduction), la gestion de la production quelques bonnes idées à prendre concernant le monitoring), la gestion de projet (bien bateau).

Bref, un livre raté. Les auteurs se sont perdus dans des considérations complètement en dehors du sujet. C’est certainement ce qui arrive quand on se pique d’architecture IT alors que votre véritable centre d’intérêt est l’architecture et la conception logicielle. 

Performance des architectures IT
Référence complète : Performance des Architectures IT : Disponibilité, temps de réponse, robustesse, montée en charge – Pascal Grojean, Médéric Morel & Guillaume Plouin – Dunod 2007 – ISBN : 978 2 10 051262 1 (une seconde édition est aujourd’hui disponible)
Performance des Architectures IT


http://www.goodreads.com/book/add_to_books_widget_frame/6639603?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : UML 2 par la pratique : études de cas et exercices corrigés 4ème édition, par Pascal Roques

Note : 7 ; Plus qu’une mise à jour !

Déjà la 4ème édition de ce livre ! J’en ai donc raté 2, et j’aurais aussi raté celui-ci si Pascal ne m’en avait pas fait cadeau. L’un des objectifs majeurs de cette nouvelle édition était la mise à jour par rapport à UML 2 : de ce coté l’objectif est atteint. On notera, par exemple, l’utilisation abondante des « frames » (mais pas de l’interaction overview, pourtant si utile). Autre nouveauté majeure, les « composite structure diagram » sont dorénavant présentés, mais avec un traitement peu en mesure avec leur importance. Les « timing diagram », de leur coté, sont juste évoqué en passant mais j’en fais moins de cas, car cette innovation outre sa séparation par rapport aux autres concepts d’UML2, me semble de moins d’importance. Pascal aime beaucoup les diagrammes d’état, aussi leur réserve-t-il traditionnellement une part importante, y compris les trucs quasi-inutiles comme les états historiques. Cette édition suit la tradition et les nouveautés concernant les automates d’état sont extensivement passées en revue. Je continue à trouver surdimensionné l’importance accordée à cet aspect, mais on reconnaitra que celui-ci est au moins traité « in extenso » ! On n’en dira pas autant des diagrammes de communication (les anciens diagrammes de collaboration) : assez peu évoqués, ils sont de plus utilisés avec les stéréotypes Jocobsoniens (déjà présents dans la première édition, à mon grand désarroi, et qui persistent dans cette dernière mouture), je n’en suis pas un grand fan, car ils induisent des choix de modélisation particuliers et rendent la lecture des diagrammes d’autant plus difficile que le lecteur du livre sera généralement débutant en UML. Autre nouveauté : Pascal nous propose une analyse linguistique, si l’exercice est intéressant et bien mené, son intérêt pratique est questionnable, mais comme on dit : c’est bien de le faire au moins une fois.

Au-delà de la mise à jour UML 2, cette nouvelle édition a pris un peu d’ampleur, passant de 290 à 320 pages. On a vu pire, d’autant qu’il faut bien l’avouer : les qualités pédagogiques de l’auteur rendent cela extrêmement digeste. Le principe du livre est toujours le même : la présentation d’UML se fait au travers d’exercices durant les 3 premiers chapitres, ce qui permet de présenter les concepts de façon progressive. La quatrième partie dédiée à la conception s’appuie sure 2 études de cas. Ceux qui connaissent le cours Valtech UML reconnaitront la trame et les exercices. On remarquera au passage les emprunts à l’approche de Craig Larman, au travers des contrats d’opération, entre autre chose.

Si vous cherchez un ouvrage sur UML, vous voici donc face à 3 choix principaux :

L’UML distilled de Martin Fowler : Condensé et efficace, il présente la notation UML aux lecteurs déjà aguerris dans l’utilisation d’un langage de modélisation graphique

L’UML Reference Guide des 3 amigos : C’est la référence sur UML et ne s’adresse pas au débutant, car si le texte est pédagogique, il ne fait grâce d’aucune des subtilités du standard. Le débutant risquera fort d’être noyé.

L’UML par la pratique de Pascal Roques : Un bon moyen (la référence devrai-je plutôt dire) de s’auto former à UML, avec des exercices et une présentation progressive des concepts. Toutefois, le format retenu ne le rend pas tellement pratique pour s’en servir après coup comme un manuel de référence. Ce n’était pas le but de l’auteur, et l’exercice ne parait pas tellement praticable de toute façon.

UML 2 par la pratique

Référence complète : UML 2 par la pratique : études de cas et exercices corrigés, 4ème édition – Pascal Roques – Eyrolles 2005 – ISBN : 2-212-11680-2 (une 7ème édition est aujourd’hui disponible).

Uml 2 Par La Pratique: Études De Cas Et Exercices Corrigés


http://www.goodreads.com/book/add_to_books_widget_frame/2212116802?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on