J’aurais le plaisir de présenter lors d’un “lightning talk”, c’est à dire sur un format court de 15 minutes, une sélection de ma chronique de l’été : “en finir avec …
Un grand merci aux organisateurs qui ont retenu mon sujet !
Tout dans la vie est une affaire de choix, ça commence par la tétine ou le téton, ça se termine par le chêne ou le sapin.
Pierre Desproges
Note de lecture : Design Patterns, par Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides
Note : 10+ ; LE livre de la décennie 90 !! Book of the year 1995 & Book of the decade ‘90!
Il y a un « avant » et un « après » Design Patterns. Il y a tellement de choses à dire sur ce livre emblématique qu’il est même difficile de trouver par où commencer. Commençons par « avant ».
Dans les années 80, jusqu’au début des années 90, on parlait bien d’activité de conception (par opposition à l’activité d’analyse) mais sans parvenir vraiment à identifier ce en quoi cela consistait. « montre-moi ton arbre d’héritage » était alors l’aulne à laquelle on mesurait la qualité d’une conception objet. Evidemment un arbre large et profond était jugé meilleur qu’un arbre rabougri. Pour certains gourous, seuls les objets issus du domaine métier étaient des éléments valides de conception. Je garde un souvenir vivace de m’être fait tancé vertement pour avoir introduit dans ma conception des objets qui n’en étaient pas. Bref l’activité de conception était alors généralement considéré comme le tartinage de code dans les classes identifiées en analyse. Sauf pour quelques uns qui se disaient qu’il y avait plus…
Puis est arrivé le Design Patterns. Un ouvrage tellement emblématique qu’il porte même un nom alternatif dans la communauté des patterns : le GoF, c’est à dire le « gang of four » par référence à ses quatre auteurs.
Continuer à lire « Note de lecture : Design Patterns, par Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides »Note de lecture : MDA, conception orientée objet guidée par les modèles, par Hubert Kadima
Note : 3 ; Trop vague ou trop près du code !
Ce livre est une déception. Tout d’abord, ce n’est pas le bon livre pour comprendre MDA : les chapitre 1 à 3 sensés le décrire sont brumeux, énumérant (répétant même, assez souvent), ce que MDA permet de faire, sans vraiment expliquer la chose. Je n’aurais pas appris MDA par ailleurs, je n’aurais rien compris !
Le chapitre 4 apparaît soudainement, en décalage : alors que l’on dissertait vaguement de principes généraux, voici (boum !) un chapitre est dédié à Rational XDE, qui n’est même pas vraiment un outil MDA. Qu’importe, on nous inonde de copie d’écrans et de scripts de génération de code ! Puis succède le chapitre 5, qui n’est pas non plus dédié à MDA mais au processus de développement.
En fait, les éléments m’intéressant ont débuté au chapitre 6, où l’on présente l’étude de cas de la chaîne logistique. En fait, ce chapitre n’est pas non plus orienté MDA, mais j’ai trouvé l’exposé du sujet intéressant, ainsi que l’évocation des normes s’y rattachant : SCORE, Rosetta Net, etc.. Le chapitre 7, qui lui est vraiment MDA, a l’intérêt de traiter correctement du sujet : l’approche MDA avec le profil J2EE. Au moins entre-t-on dans le vif du sujet.
Les chapitres 8 et 9 (qui sont les derniers) font l’originalité du livre et par là même en relèvent un peu la note. Dans le premier, on évoque le profil UML pour Corba CCM, avec une longue mais très intéressante introduction au modèle CCM. Dommage que le traitement de l’étude de cas sur ce profil soit un peu bâclé. Le dernier chapitre est encore plus intéressant, puisqu’il traite du CWM, le métamodèle dédié aux entrepôts de données. Ce métamodèle, avec ses sous-ensembles est expliqué, tout comme l’est succinctement Jolap, l’interface Java-OLAP. Hélas, la transformation UML – CWM n’est pas évoquée.
En bref, un ouvrage bien décevant, où seul les 3 derniers chapitres présentent quelque intérêt. Pour ce qui est de comprendre MDA, allez voir ailleurs. Et pour ce qui est de comprendre la mise en œuvre, mieux vaut aller voir des outils qui convergent réellement vers MDA et non des AGL générant du code ! Si vous cherchez un livre en français sur MDA, celui de Xavier Blanc est bien meilleur à tous égards.
Référence complète : MDA, conception orientée objet guidée par les modèles – Hubert Kadima – Dunod 2005 – ISBN : 2-10-007356-7
Note de lecture : Blade Servers and Virtualization, par Barb Goldworm & Anne Skamarock
Note : 5 ; Un bon guide pour le décideur, toujours intéressant sur les concepts, vieillissant sur les aspects et peu précis sur la techniques et obsolète sur la 3ème partie.
Cet ouvrage est en fait le seul que j’ai pu trouver traitant des serveurs blade. En fait, peut-être n’y a-t-il pas assez à dire pour susciter une littérature assez large ? Quoi qu’il en soit, celui-ci correspond à mes attentes : évoquer les architectures matérielles à base de serveurs blades. C’est donc assez naturellement que sont évoquées la mutualisation d’infrastructure, et notamment la connectivité, mais aussi l’alimentation électrique et le refroidissement.
Ces deux derniers sujets méritent certainement deux mots d’explications. En effet, les centres de calculs sont connus pour poser de gros problèmes de refroidissement, qui s’accentuent avec la puissance croissante des serveurs. Il est également connu que les coûts d’exploitation sont directement corrélés à la consommation électrique (avec un coût de l’électricité lui-même en forte augmentation). Le dernier paramètre étant l’occupation au sol, qui est lui-même lié aux problématiques de câblages et de refroidissement. Les serveurs blades améliorent la situation sur ces différents paramètres, tandis que la virtualisation améliore l’utilisation des serveurs et par là-même le coûts d’exploitation. La première partie du livre est consacrée à l’ évocation de ces points. Il ne s’agit que de 45 pages, la partie suivante, qui en compte 90, rentre au cœur du sujet.
La seconde partie est consacrée à l’évocation des différents aspects des blades et de la virtualisation. Elle fait bien son œuvre, sauf dans la partie dédiée à la connectivité, où d’avantage de précisions, de schémas et d’exemples auraient été bienvenus. Cette partie s’étend même aux problématiques de stockage (donc la relation avec les SANs), à la supervision et au clustering !
La troisième partie ressemble à un « guide d’achat » » : quelles sont les bonnes questions à se poser, les points à vérifier, le tout complété de matrices de comparaisons sur les différentes solutions du marché. Cela a été une présentation judicieuse du paysage à l’époque, mais elle n’est plus d’actualité.
La quatrième partie consacrée aux solutions s’est fanée avec l’âge, comme on pouvait s’y attendre. C’est dommage, car non seulement le tour du marché nous permet d’appréhender celui-ci, mais surtout les retours d’expérience du chapitre 17 sont particulièrement précieux.
Bref, voici un livre plutôt facile à lire, offrant un bon instantané sur la situation du marché et les tenants et aboutissants d’un choix. J’ai quand même été un peu frustré sur les éléments pouvant me permettre de comprendre la connectivité et donc d’établir un choix d’architecture.
L’obsolescence inévitable de l’ouvrage nécessiterait une nouvelle édition, en fait une nouvelle édition tous les deux ou trois ans au moins. Ce n’est pas le cas et c’est dommage.
Référence complète : Blade Servers and Virtualization, transforming enterprise computing while cutting costs – Barb Goldworm & Anne Skamarock – John Wiley & sons 2007 – EAN : 978 0 471 78395 4
Acceptez le fait que nous devions traiter pratiquement tout le monde comme des volontaires.
Peter Drucker
Le premier bug de l’histoire de l’informatique
Il a été mis en évidence par l’équipe de Grace Hopper et référencé en tant que tel par cette dernière le 9 Septembre 1947 sur le journal de l’ordinateur Harvard Mark II où il a été trouvé. La page de journal est visible au Smithonian institute auquel il a été donné (Object ID: 1994.0191.01)
Note de lecture : Lean Software Development, An agile toolkit, par Mary Poppendieck & Tom Poppendieck
Note: 8 ; L’anti-taylorisme tel que nous l’enseigne l’industrie !
Le « Lean Développement » dont Mary Poppendieck est l’une des figures de proue est l’adaptation au monde du développement logiciel du mouvement « Lean production » issue de l’industrie, pratiqué notamment chez 3M et Toyota. L’ouvrage n’hésite d’ailleurs pas à illustrer les concepts évoqués par des exemples tirés de l’histoire de ces 2 sociétés (et d’autres).
Le Lean Développement, comme la plupart des méthodes agiles, ne propose pas un cadre prescriptif pour la construction logicielle, mais un ensemble de 7 principes et de 22 pratiques.
- Eliminer le déchet : c’est l’un des principes fondamentaux du Lean développement (et des méthodes agiles en général). Il s’agit de se débarrasser de ce qui est inutile et ne participe pas à la chaîne de valeur, en utilisant deux outils que sont le repérage du gâchis et le « value stream map ».
- Amplifier l’apprentissage : le développement d’un système informatique n’est pas une activité de production, mais un travail de développement (comme son nom l’indique), où la découverte et l’expérience jouent un rôle prépondérant. Ce principe est supporté par des outils tels que le feedback, les itérations, la synchronisation des acteurs et le « set based développement » qui privilégie la communication basé sur les contraintes (qui permet de laisser les options ouvertes) plutôt que celle basée sur les choix (qui ferme ces options).
- Décider aussi tard que possible : Ne pas s’enfermer dans le choix de certaines options tant que l’on peut garder les options ouvertes ! Ce principe est soutenu par des outils tels que « l’option thinking », le « dernier moment raisonnablement possible » par l’utilisation d’abstraction d’interfaces ou de paramètres lors de la conception
- Délivrer aussi rapidement que possible : cette pratique dont le nom est auto explicite s‘appuie sur des outils tels que le « pull system », où le travail est tiré, choisi au moment où l’on peut l’effectuer plutôt que d’être assigné à l’avance de façon autoritaire ; une approche directement héritée des « kanban » , la « théorie des queues », le « coût des délais ».
- « Team empowerment » est un des fondements des méthodes agiles, mais aussi de ce que l’on appelle parfois le « Toyotisme ». Il s’agit ici de descendre le pouvoir de décision au niveau de ceux qui réalisent le travail, une approche servant-based management en rupture totale avec le taylorisme.
- L’intégrité : Ce principe se décline en « intégrité conceptuelle » dans laquelle les principes centraux du système fonctionnent de façon cohérente, et en « intégrité perçue » dans laquelle le système assure le bon équilibre entre fonctionnalités, ergonomie, fiabilité et critères économiques.
- Voir l’ensemble : ce principe nous invite à améliorer le processus de développement en le considérant dans sa globalité plutôt que par optimisations locales, en utilisant des outils tels que les mesures ou les contrats.
Cet ouvrage est à mon avis hautement instructif, pratique et éclairé, il considère le développement logiciel comme une activité exploratoire, donnant la part belle à l’initiative, à l’organisation émergente et au leadership, par opposition aux processus prescriptifs, gérés par le contrôle de la conformité aux plans. Le texte rompt l’idée préconçue que le processus de développement doit être identique au processus de production et que le taylorisme est la réponse ultime de l’organisation, alors même que cette illusion a pris fin depuis plus d’un demi-siècle.
Ce livre n’évite aucun sujet épineux et traite même des aspects contractuels de la réalisation de projets, qui est un sujet hautement problématique des méthodes agiles. Les apports de la logistique industrielle que nous offrent les auteurs sont originaux et particulièrement instructifs, le plus souvent en rupture avec les idées préconçues que nous pouvons avoir sur le sujet.
La compacité du texte (186 pages) sera, j’espère, un argument supplémentaire pour vous décider à en aborder la lecture. A dévorer sans réserve !
Référence complète : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3
Note de lecture : The Art of Lean Software Development, par Curt Hibbs, Steve Jewett & Mike Sullivan
Note: 3 ; Tour d’horizon superficiel du développement agile .. sans vision particulièrement « lean » !
J’ai l’habitude d’apprécier les livres succincts. Ils ont le bon goût d’aller à l’essentiel et ainsi de distiller efficacement une information utile. J’étais curieux de voir ce qu’il en allait être de cet ouvrage à la fois particulièrement court (120 pages) et pas spécialement bon marché ! Une autre source de curiosité était la juxtaposition des mots « Lean » et « développement ». Si le sujet est à la mode et que l’on développe largement la pensée « lean » dans la communauté agile, j’avoue avoir encore du mal à cerner en quoi le lean influence les pratiques de développement popularisées par les méthodes agiles.
Globalement, ce livre est hélas une déception. Il constitue certainement une bonne approche pour sensibiliser des managers aux grands principes du développement agile : il reste au niveau des grands principes et fait le tour d’horizon des pratiques agiles en expliquant leur utilité. Ainsi 6 chapitres sur les 9 que compte l’ouvrage sont dédiés aux principales pratiques de développement déjà promues par Scrum, XP ou les pragmatiques programmeurs :
- Scripter les builds et utiliser un gestionnaire de version, plutôt que de compter sur une procédure interactive pour rendre un « build » répétable.
- Automatiser les tests, au niveau des tests de développements ou des tests comportementaux (tests d’intégration ou de recette). Ce chapitre présente d’ailleurs un condensé plutôt réussi du sujet, même s’il reste un peu superficiel.
- Mettre en place une intégration continue.
- Optimiser le volume de code, en ne gardant que le code utile. Ce qu’on appelle le YAGNI (you ain’t gonna need it) dans XP.
- Petites itérations. Inutile d’épiloguer, le titre parle de lui-même.
- L’implication continue de l’utilisateur, en l’impliquant dans la boucle de feedback de l’itération. Ce que les auteurs appellent aussi le « CRACK customer » (Collaborative, Representative, Authorized, Commited, Knowledgeable).
Finalement, seul le chapitre 9 approche les pratiques Lean et leur application au développement logiciel. Les auteurs évoquent ici les ateliers Kaizen et le value stream mapping essentiellement et mentionnent les autres pratiques Lean (ainsi que des approches complémentaires comme la théorie des contraintes).
L’intérêt de sortir un livre de sensibilisation sur les pratiques de développement agile en 2009 alors que le sujet est déjà bien couvert m’échappe un peu, je dois dire. Je mettrais celui-ci au niveau du livre de Craig Larman (agile and iterative development, a manager’s guide) pour ce qui est du public visé, avec un très gros point en faveur de ce dernier ouvrage. Enfin, le titre du livre est assez trompeur, comme j’ai pu le dire.
Sans doute pourrais-je proposer de lire cet opuscule à un développeur ou à un manager désireux d’acquérir une compréhension de premier niveau des principales pratiques agiles. La brièveté du texte sera là une réelle qualité.
En conclusion : un livre bien trop cher eut égard au contenu et dont l’intérêt est peu probant par rapport à la bibliographie existante. Il reste toutefois une petite niche de lecteurs potentiels auxquels je pourrais même conseiller l’ouvrage. Le passionné n’y trouvera pas son compte.
Référence complète : The Art of Lean Software Development – Curt Hibbs, Steve Jewett & Mike Sullivan – O’Reilly 2009 – EAN : 978 0 596 51731 1
Never be afraid to try, remember, amateurs built the ark. Professionals built the Titanic.
(via niptech)
Software Freethinker 
