Retours sur l’agile tour Bruxelles 2012

Le par addinquydans Compte-renduLaisser un commentaire

Je m’étais fixé dans mes objectifs sur ce second semestre, de me joindre à la communauté agile Belge à l’occasion de l’agile tour Bruxelles. je n’ai pas hésité longtemps à répondre à l’appel à orateurs de Bruno Sbille. Plusieurs raisons à cela:

  • L’opportunité de faire une présentation en Anglais. Il faut bien garder la forme !
  • L’occasion de rendre la politesse à Bruno qui nous avait fait le plaisir de venir faire une présentation dur la Programmation Neuro Linguistique lors d’une soirée du Scrum User Group.

J’espérais donc bien être retenu. Je l’ai été : merci au comité d’organisation !

L’aller-retour dans la journée, ça fait une grosse journée, mais ça valait le coup.

Pascal Van Cauwenberghe : 11 steps to perfect code

Pascal s’est présenté comme un “recovery bug writter”. Il nous a présenté son processus destiné à éliminer les bugs. Il compte 11 étapes, pas moins.

La qualité dépend-t-elle des testeurs ? La réponse est non. En fait, elle est souvent inversement proportionnel au nombre de testeurs. Cela peut paraitre provocateur, voir choquant. mais réflechissez à l’impact psychologique sur les développeurs d’‘une très importante équipe de testeurs.

1 – Mettre en évidence le bug. Jusqu’ici tout va bien.

2 – Votre réaction : et meeeerde ! Non, justement. Il faut remercier le rapporteur. Pascal nous fera faire l’exercice plusieurs fois durant cette heure: remercier à haute voix: Thank you !

3 – Reproduire le problème. Identifier les conditions sous lesquelles ce bug se manifeste est une simple question de bon sens.

4 – Ajouter (au moins) un test qui échouera suivant ces conditions.

5 – Corriger le problème. Vous suivez toujours ?

Bon ça y est, on a fini. Comment ça “non” ?

6 – Rejouer la totalité des tests unitaires. La correction d’un bug peut introduire une régression. Nous le savons tous. Mais prenons-nous tous la peine de rejouer la totalité des tests ? Bien sûr le but n’est simplement de les rejouer, mais de les rejouer jusqu’à ce qu’ils passent tous !

7 – Faire une analyse causale : pourquoi ce bug n’a pas été intercepté précédemment ? Il faut toujours faire attention aux objectifs que l’on fixe : on risque de les atteindre. Si le but est la couverture du code, est-on certain qu’elle est synonyme de tests associés ? Le véritable objectif n’est pas la couverture du code, mais la qualité de celui-ci.

8 – Améliorer les tests.

Là, ça devrait être terminé. Non, toujours pas ?

9 – Améliorer la façon dont les tests sont écrits. Mais ceci est autre chose, n’est-ce pas plutôt un point qui devrait être remonté en rétrospective ? La rétrospective ce n’est pas pour la fin de sprint. La démo ce devrait être tout le temps.

10 – “Un bug ne voyage jamais seul” : à la recherche des bugs similaires !

11 – Faites que ce bug soit impossible à reproduire !

Traquer les bugs ainsi peut sembler coûteux. En fait, ça l’est au début. Pascal s’appuie sur la théorie des contraintes pour expliquer que cette approche permet finalement de livrer plus vite ! En l’occurrence sur un projet, au bout de 5 mois au lieu de 8 !

Jan De Baere : Kaban at different levels

Jan a choisi de nous présenter Kanban tel qu’il est utilisé réellement dans les projets auxquels il a participé, avec les leçons qui ont accompagné sa mise en oeuvre.

La règle de conduite que nous propose Jan repose sur 3 axes:

  • Visualiser le workflow.
  • Limiter le “work in progress”, en s’appuyant sur l’expérimentation.
  • Mesurer et gérer le workflow.

L’exemple d’une circulation sur une autoroute illustre assez bien ces 3 points, même si les paramètres conduisant à la formation des bouchons sortent des fondements théoriques de Kanban (eh oui, il n’y a pas que la théorie des contraintes…).

Cette session avait pour but de nous exposer cette mise en oeuvre dans différents contextes:

  • Un projet classique.
  • Un projet distribué
  • Le Kanban au niveau individuel
  • la gestion d’un portefeuille de projets.

Plutôt que d’asséner les différents éléments de la présentation je préfère mettre en avant les éléments principaux:

  • Les “expedites”: lorsqu’ils sont trop nombreux, il ya un problème à régler !
  • Mettre en évidence les éléments qui sont attendus. Là encore, ils peuvent stigmatiser des problèmes à régler au niveau organisationnel.
  • Les “buffers”: ils peuvent apparaitre utiles dans le workflow, mais sont à utiliser avec parcimonie. Ce sont des sources de gâchis, au sens Lean.
  • Il y a un lien direct entre le “work in progress” et le “lead time”. Ils croissent de concert.

L’un des grands moments fut certainement la présentation du “kanban portable” (et pliable) réalisé par Jan !

atbru2012-JanDeBaere

Pour ma part, je garderais dans mes notes l’usage du “personnal kanban” avec ses limites de WIP adaptatives:

  • Les tâches “high energy” : la limite de WIP est de … 1 ! Ce sont les tâches qui demandent un haut niveau de concentration.
  • Les tâches “medium”, c’est le travail ordinaire. La limite de WIP est de 2.
  • Les autres tâches, celles qui ne nous donnent pas vraiment de faire un travail correspondant à notre niveau de qualification. Il n’y a pas de limites de WIP pour celles-ci.

Ce peut être du bon sens, mais c’est sans aucun doute un point à garder !

Alan Holtz : Lessons learned from the Scrum Master

J’espère qu’Alan me pardeonnera de ne pas avoir pris de note lors de sa session. J’étais en fait en train de faire l’ultime préparation de la mienne ! Si une photo vaux mieux que de grands discours, en voici donc une !

atbru2012-SMLessonsLearned

Yves Hanoulles : How 146 people made 13 projects

Yves a acquis une grande notoriété dans la communauté agile, par son implication dans de nombreux projets. J’avoue que j’avais du mal à comprendre comment il pouvait mener à bien cette activité débordante. Cette session répond à ces questions.

atbru2012-YvesHanoulles

Comment nait un projet ?

Yves débute simplement un projet par un problème qu’il rencontre et sur lequel il ne trouve pas sur le net de ressources pouvant l’aider.

Comment construire une communauté de contributeur ?

Simplement en demandant autour de lui, mais en s’adressant de manière directe aux intéressés, s’ils peuvent et souhaitent l’aider sur son projet. C’est une question franche et directe qui n’appelle pas obligatoirement de réponse positive : on peut ne pas avoir le temps, ne pas être intéressé par ce projet, etc… Yves accueille de manière factuelle et simple cette réponse.

A partir de là, Yves accorde une complète confiance aux collaborateurs dès le départ, avec complet accès en lecture et écriture aux ressources du projet : la confiance n’est devrait pas être “gagnée”, mais donnée !

Surtout Yves nous rappelle qu’il faut toujours penser à remercier une personne qui se propose de contribuer.

Collaboration et outillage

Tous ces projets se déroulent sans aucune rencontre face à face : tout est mené et coordonné à distance, l’outillage permettant cela est donc important. Les principaux que j’ai noté :

  • Skype
  • email: Oui, bien qu’Yves soit un fervent défenseur de la limitation de l’usage de l’email en entreprise, il reste un média essentiel pour ces projets collaboratifs.
  • Google doc.

Si les projets agiles défendent la co-location, Yves nous rappelle que selon Jim McCarthy, celle-ci n’est pas une nécessité : ce qui est nécessaire, c’est une communication avec une large bande passante.

Who is agile ?

Yves a terminé sa session sur quelques reflexions sur la rédaction d’un livre en mode agile, tel que “who is agile ?” a été rédigé.

  • La rédaction d’un livre en mode agile est possible, intégrant des itérations et du feedback. C’est non seulement possible et même souhaitable. Une plateforme comme Leanpub est un grand facilitateur en ce sens.
  • La lecture d’un livre réalisé en mode agile est pr contre moins sympathique.

Jeff Cumps : How to solve your thoughthests impediments

Jeff nous invitait à une session-atelier sur le A3 problem solving. Un réel challenge d’ailleurs car il ne disposait que d’une heure pour nous exposer les principes et nous permettre de les mettre en oeuvre sur une problématique de notre choix.

Je ne vais pas détailler l’atelier ici. Le timing était un peu serré, mais nous avons pu avoir la satisfaction de bien avancer sur nos exemples. Disons que 1h30 aurait probablement été un créneau plus confortable. Mais peut-être pas plus, non plus !

En fait le point positif du temps limité était d’aller droit à l’essentiel sur l’exercice pour en comprendre les points principaux. Ce que Jeff a fait avec clarté. Une très bonne session pour conclure cette journée !

Ambiance, boissons et rencontres

Chaque conférence agile est l’occasion de croiser ou recroiser des passionnés. L’évènement a été ciblé petit par les organisateurs : 70 personnes, donc volontairement peu de buzz autour de ce premier Agile Tour Bruxelles. Un grand “up” pour les organisateurs à propos de la convivialité et de l’ambiance sur cet Agile Tour Belge. Ca donne vraiment l’envie d’y revenir.

Couleur locale oblige, nous avons conclu la journée autour d’une bière.

Un geste sympathique pour les orateurs : un assortiment très couleur locale une fois encore. Que je vous laisse découvrir.

atbru2012-orateursgifts

Note de lecture : A Requirements Pattern, par Patricia L. Ferdinandi

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 2 ; Creux et peu concret!

Tout avait pourtant bien commencé: le titre de l’ouvrage regroupant “pattern” et “requirements”, je ne pouvais l’éviter. Las, l’auteur remplis visiblement son ouvrage en se répétant une multitude de fois, au point que je pense qu’il n’y a de quoi remplir qu’un article. De quoi s’agit-il en fait ? Patricia Fernandini nous expose comment organiser les exigences en une matrice, version élargie du framework de Zachman, selon 3 dimensions représentant: 1) les perspectives, en fait les étapes de raffinement des exigences 2) le focus (qui, quoi, où, pourquoi et comment, plus les contraintes produit et projet) 3) les communautés (IT, business, etc..). L’originalité et l’intérêt de l’approche (celle qui justifie que la note n’est pas zéro) est que l’auteur ne s’arrête pas aux exigences logicielles, mais élargit celles-ci de façon intégré à tous les domaines de l’entreprise qui peuvent être concernés par l’idée ou besoin initial qui est investigué. Malheureusement, en essayant de rendre abstrait cette approche, c’est à dire non dépendante d’une méthodologie de capture des exigences particulière, l’auteur rend intangible la concrétisation de son approche, les exemples donnés en annexe ne nous éclairant guère car il ne s’agit juste que de résumés de retour d’expérience. L’aspect “pattern” est visiblement mal compris de l’auteur qui s’emmêle entre les notions de patterns, méta-patterns, anti-patterns et framework, embrouillant le lecteur au passage. Des patterns d’exigence pour l’internet: il y avait sans problème de quoi faire, mais c’est raté!

requirements-patterns

Référence complète : A Requirements Pattern, Succeeding in the Internet economy – Patricia L. Ferdinandi – Addison Wesley / I.T. series 2002 – ISBN: 0-201-73826-0

A Requirements Pattern


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

The virtues of emergence

Le par addinquydans PresentationLaisser un commentaire

J’ai eu de nouveau le plaisir de donner mon lightning talk “les vertus de l’émergence” lors de l’agile tour Bruxelles. Cette fois, c’était en Anglais, l’exercice était donc un peu plus difficile. Voici le support de cette présentation, un peu modifié par rapport à la langue et au modèle graphique de l’évènement.

Le slide-show ne rend pas bien compte de la présentation. J’avais posté ici-même cette présentation sous forme d’article. Mais c’est uniquement en français pour l’instant.

La même présentation est aussi accessible en français, avec le modèle graphique du Scrum Day 2012.

I was lucky enough to give my lightning talk “the virtues of emergence” during the Bruxelles agile tour. This time, it was in English, so a little bit more difficult for me. Here is the slide show, slightly modified from my first presentation.

As you will see, this doesn’t reflect the presentation. That’s why I wrote an article from this, accessible from here. But it’s only in French for now. I won’t guarantee I’ll perform a translation, but I’ll take that in consideration.

Note de lecture : SQL Server Hardware par Glenn Berry

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Passionnant et frustrant tout à la fois

Voilà un livre tout à fait original, mais combien important. Il est en effet peu réaliste d’effectuer un déploiement optimisé de base de données sans prendre en considération l’aspect matériel. Et là on est souvent obligé de se débrouiller avec des informations glanées à droite ou à gauche.

Tout d’abord la taille du livre : s’il compte 320 pages, il faut prendre en considération la taille de la police de caractères qui est très grande. Je dirais qu’au final on est plus proche d’un livre classique de 200 pages environs.

Pourquoi ai-je trouvé ce livre passionnant ? Il est éclairant sur de nombreux points : décodage des roadmaps processeurs, choix des architectures machine multi-core, stockage RAID, SAN et SSD et pas mal de choses encore. On y évoque des points de configuration tout à fait pertinents : réglage énergétique, hyper threading, filegroups, etc.. De plus l’auteur prend de réelles positions par rapport à ces choix et c’est bien ce que j’attend d’un ouvrage.

Pourquoi l’ai-je trouvé décevant ? Tout d’abord j’ai trouvé le texte hors sujet sur le détail des fonctionnalités des différentes éditions et versions de SQL Server. On est loin du hardware et ce genre d’information traine ailleurs. Le dernier chapitre sur l’installation et la configuration ressemble carrément à du remplissage et je reste mitigé sur le chapitre concernant le système d’exploitation. D’un autre côté, si les chapitres purement destinés u matériel sont riches d’information, j’aurais aimé une étude plus approfondie du fonctionnement comparé de SQL OS versus l’hyper threading ou la virtualisation (voir même les deux). Le fonctionnement de la lecture/écriture de blocs avec le fonctionnement d’un SAN ou du SSD, les impacts sur l’utilisation en I/O d’un iSCSI ou d’un fiber channel, idem pour l’alignement des partitions.

Bref, si l’on a un point de vue « utilisateur » d’un DBA très averti sur les aspects matériels d’un SQL Server, il manque de mon point de vue une analyse en profondeur de ces aspects pour en saisir toutes les susceptibilités.

Au final, voici un livre qui aurait pu être mieux, bien mieux ! Mais il se lit bien et même très vite, et donne beaucoup d’indications et d’informations pour réussir son choix matériel et la configuration d’une machine SQL Server. N’est-ce pas l’essentiel ? Et ne serait-ce que pour cela, j’en recommande la lecture.

sql-server-hardware

Référence complète : SQL Server Hardware – Glenn Berry – Simple Talk Publishing 2011 – ISBN : 978 1 906434 63 2

SQL Server Hardware


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

Note de lecture : Modular java, par Craig Walls

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 8 ; Vraiment un excellent tutorial, sur OSGi d’abord, puis sur Spring DM ! Bravo !

Craig Walls est déjà l’auteur de l’excellent « Spring in Action ». Je connaissais donc déjà ses talents d’auteur. Il n’a pas failli à sa réputation ici. En fait, je pense qu’il a fait encore mieux ! Le challenge de réussir ce tutorial en 200 pages, se partageant entre OSGi « brut » d’abord, puis ensuite sur Spring DM y est aussi pour beaucoup.

Dès le premier chapitre, on est séduit par la limpidité de la présentation d’OSGi et de l’intérêt d’un approche « composant runtime ». On n’en a que d’avantage l’eau à la bouche pour attaquer la première partie, celle qui présentera le développement OSGi sans Spring, soit 90 pages sur 4 chapitres.

Très intelligemment, le chapitre 2 présente la construction d’un bundle OSGi minimaliste, mais où l’on construit toute la plomberie à la main ! C’est bel et bien la meilleure façon de comprendre cette plomberie. Jouer avec la console OSGi (un outil dont la compréhension est indispensable), est le complément naturel de cette approche. C’est l’occasion d’aborder les différentes implémentations d’OSGi et principalement les deux implémentations open source : Equinox et Apache Felix. L’auteur penche pour Equinox, c’est visible.

Le troisième chapitre peut paraître curieux, car on y découvre peu de choses sur OSGi ! L’auteur nous y présente l’architecture de l’application que nous allons construire, mais surtout il introduit les outils PAX construct, une boit à outil qui va vite s’avérer indispensable pour construire et tester les bundles OSGi.

Les chapitres 4 et 5 abordent enfin la création de différents types de bundles et le développement de services. Au bout du 5ème chapitre, nous sommes devenus opérationnels pour construire des bundles OSGi qui coopèrent ensemble. Toute cette première partie constitue un tutorial remarquable.

La seconde partie va aborder l’utilisation de Spring DM afin de faciliter le développement de bundles OSGi en en masquant la complexité. 3 chapitres et 65 pages suffisent à la tâche. Le chapitre le plus important est d’ailleurs le premier de cette partie (le chapitre 6) car il explique comment la plomberie du bundle est prise en charge par le contexte Spring et l’injection de dépendances inter bundles !

C’est aux « web bundles » que ce se consacre le chapitre 7. Je l’ai trouvé personnellement assez complexe, car il a trait à beaucoup de problématiques de configuration, pour déployer des bundles sur Tomcat et sur Jetty et pour régler des problématiques de listener http et autres… Disons que c’est un mal nécessaire (ou incontournable).

Le chapitre 8 revient au développement et nous présente la création de fragments. Je pense que cela aurait pu être présenté en première partie, mais ça marche aussi ici ! Petit détail, cela ne profitera qu’à ceux qui développent avec Equinox. Dommage pour ceux qui ont choisi Apache Felix !

La dernière partie, constituée de deux chapitres, adresse le passage en production : déploiement, administration, configuration et suivi d’exploitation. Tout cela est remarquablement expliqué en peu de pages.

Ce livre ne vous donnera peut-être pas des informations complètes sur tout ce que vous pourriez savoir sur OSGi et Spring DM, ce n’est pas une bible ! Mais je pense que c’est sa qualité première, il se débarrasse du superflu pour se concentrer sur l’indispensable et nous mettre le pied à l’étrier du développement avec Spring DM. Un tutorial, un vrai. La mission est remplie à 100% ! Je conseille sans réserve ce livre qui fut une bonne surprise.

modular-java-pragprog

Référence complète : Modular java, creating flexible applications with OSGi and Spring – Craig Walls – The Pragmatic Bookshelf 2009 – ISBN: 1-934356-40-9 ; EAN: 978 1934356 40 1

Modular Java: Creating Flexible Applications with Osgi and Spring


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

Note de lecture : UML pour les décideurs, par Franck Vallée

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Le cycle en « Y » n’est pas mort, il bouge encore… « UML pour les vieux » aurait-il été un meilleur titre ?

UML peut-il réellement être un outil pour le décideur. Personnellement j’en doute, bien que la finalité d’une notation soit d’être un vecteur de communication. Le pari est en tout cas ambitieux, voyons s’il est réussi, et pour se faire passons en revue le contenu du livre. Celui-ci compte 270 pages découpés en 8 chapitres formant 2 parties : « UML en puissance » et « Déployer UML dans l’entreprise ». On peut en conclure que l’on va avoir des chapitres relativement gros, disons selon la tendance française plutôt que selon le mode américain.

Le premier chapitre, UML et le génie logiciel, est un tour rapide d’UML. Il compte tout de même 65 pages et fait un tour très complet de la notation UML 2. Elle replace l’utilisation de la notation dans une gestion de projet classique « phasée » séparant distinctement l’analyse de la conception. Ce dernier point était l’un des axes prépondérants de l’approche en « Y » que je dénie complètement.

Au chapitre 2, on se concentre sur les cas d’utilisation. Je n’y ai rien trouvé de neuf, à part 6 pages sur les 50 de ce chapitres dédiés au ROI à partir des cas d’utilisation.

Le chapitre 3 couvre aussi 50 pages et est dédié à l’utilisation d’UML en conception. Enfin quand je dis en conception, je devrais dire en implémentation, car on court-circuite joyeusement une vraie conception objet, pour passer directement de l’analyse à sa projection sur l’infrastructure technique. Je ne suis pas un grand supporter du phasage, mais je ne le suis pas non plus de l’approche consistant à tartiner la coloration technique sur un modèle d’analyse ! Pas convaincant !

Le chapitre 4 nous parle processus, organisation du projet et rôles. Effectivement, on y ressort le cycle en « Y ». Je croyais pourtant qu’il était mort, mais il semble qu’il bouge encore…

Le chapitre 5, le premier de la seconde partie est très court : 10 pages. Son but est de formuler les objectifs de changements avec UML. Ca c’est le titre du chapitre. Dans la pratique, je n’ai pas compris le but de ce chapitre.

Le chapitre 6 « méthodes et outils » couvre sur 40 pages la question des différents types de cycle de développement. C’est relativement intéressant (XP y est rapidement classé comme un procès pour les petits projets ne posant de toute façon as de problème). L’affinité de l’auteur pour Unified Process et MDA arrive assez rapidement.

Le chapitre 7 « changer pour UML » nous apporte une analyse assez précise en terme de coût et d’impact du passage sur UML. Enfin le chapitre 8 « aider la prise de décision » conclut sur 6 pages en disant qu’UML, c’est bien.

Je connais Franck Vallée et l’apprécie. Mais je trouve que ce livre apporte peu de choses, surtout en 2005. Les points différenciant par rapport à un ouvrage pur UML sont peu évident. En tout cas ils ne m’apparaissent pas. Le focus méthodologique qui y est décrit me replonge dans un monde ancien, sclérosé et poussiéreux avec lequel je ne veux plus rien à voir. Quand à la relation avec le titre elle est presque inexistante. Je dénombre environ 20 pages du livre qui semblent à mon avis adresser le sujet.

Pour ce qui est d’évoquer UML de manière plus large (si l’on oublie la question du « processus pour les vieux »), eh bien Franck Vallée écrit très bien, sa description d’UML est claire et pertinente. L’analyste pourra lire cette prose avec profit.

uml-decideurs

Référence complète : UML pour les décideurs – Franck Vallée – Eyrolles 2005 – ISBN : 2-212-11621-7

UML pour les décideurs


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

Note de lecture : Ruminations on C++, par Andrew Koenig & Barbara Moo

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Amis touristes, ce livre n’est pas pour vous !

Au premier abord, l’ouvrage n’en impose pas trop, le volume semble modeste sans parler du design de la couverture façon vache qui rit. Mais rapidement, on se rend compte déjà que la finesse du papier nous avait dissimulé ses 370 pages.

Ce livre qui est plutôt un recueil, est un compilation des articles d’Andrew parus essentiellement dans JOOP (Journal of Object-Oriented Programming), mais aussi dans C++ Report et dans C++ Journal pour une petite partie d’entre eux. C’est donc dans une sélection de 98 articles publiés sur une durée de 8 ans que les auteurs ont fait leur choix. Ils sont regroupés sur 32 chapitres, pardon 33 car Andrew Koenig, en bon informaticien commence par un chapitre 0 ! Ces chapitres sont eux-mêmes rassemblés en 6 parties.

La première partie « motivations » présente assez peu de code. L’auteur y développe son crédo personnel envers C++, essentiellement en le comparant au langage C auquel il donne clarté et sécurité. Le style y est aussi plus personnel que dans les parties suivantes.

La seconde partie « classes and inheritance » est le prétexte pour revisiter les grands thèmes du C++ classique : héritage, polymorphisme et surcharge, constructeur copie, virtualité, etc… Nous avons même droit à une petite variation sur le thème du smart pointer. Il s’agit plus de l’usage du paradigme objet du C++ que d’un cours sur l’orienté objet.

La troisième partie est consacrée aux templates. En fait, il est consacré à la compréhension de la STL. Cela commence doucement par les conteneurs, puis par les itérateurs, les algorithmes et fonctions pour finalement aborder les adaptateurs. Ce n’est pas à proprement parler un tutorial STL, mais plutôt un apprentissage par la construction de ses mécanismes fondamentaux.

La quatrième partie se focalise sur les principes de conception des librairies. Honnêtement, j’ai trouvé cette partie difficile à aborder, les points fondamentaux des auteurs m’ont paru confus, ainsi que le message d’ensemble.

Si elle est courte, la cinquième partie n’est pas la moins intéressante. Intitulée « techniques » c’est en fait une boite à outil à utiliser pour débugger, tracer, gérer des clusters d’objets, etc…

La sixième partie « wrap up » conclut l’ouvrage. Elle est très courte, il y a peu à en dire.

Ce livre à recommander aux personnes fortement motivées pour approfondir leurs connaissances sur le C++. Même s’il prétend le contraire, la prose d’Andrew Koenig n’est pas du Scott Meyers. Le style est plutôt sec, parfois même un peu confus. Mais le niveau de technicité est au rendez-vous, bien qu’il faille quand même un bagage minimum assez conséquent en C++ pour tenir la distance… Le texte a été remanié afin de ne pas donner une impression trop forte de juxtaposition d’articles. C’est gagné de ce côté, même si tout n’est pas lisse. Les parties plus anciennes ont été remises au goût du jour, c’est à dire celui du pré standard 98, même si les auteurs ne cherchent pas à tout prix à dégainer les dernières nouveautés du langage. Il préfèrent se concentrer sur le « core langage ».

Quel que soit votre niveau, il serait surprenant que vous n’en retiriez pas quelque chose. A une exception près : je déconseille fortement aux débutants !

ruminations-c++

Référence complète: Ruminations on C++ – Andrew Koenig & Barbara Moo – Addison Wesley 1997 – ISBN: 0-201-42339-1

Ruminations on C++: A Decade of Programming Insight and Experience


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