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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans CitationsLaisser un commentaire

In one inquiry, it was found that a successful team of computer specialists included an ex-farmer, a former tabulating machine operator, an ex-key punch operator, a girl who had done secretary work, a musician and a graduate in mathematics. The last was considered the least competent.

Hans Albert Rhee, Office Automation in Social Perspective, 1968

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Portfolio agile : de la visibilité au pilotage, par Caroline Damour-Nobi

Le par addinquydans PresentationLaisser un commentaire
Caroline Damour-Nobi a eu la gentillesse de m’autoriser à faire figurer sa présentation dans mon blog.
La gestion d’un portefeuille de projets est un sujet difficile, tiraillé entre les vertus de vision et de transparence qu’elle apporte et l’idée de “stock” qu’elle sous-tend ! Cette présentation fait le point sur la démarche et l’évolution de la mise en place de la roadmap telle que l’a vécue Caroline.