Note de lecture : Continuous Integration, par Paul M. Duvall

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Trop creux !

J’attends incontestablement de la « signature series » d’Addison Wesley qu’elle ne comprenne que des ouvrages de référence. Ce n’est pas le cas ici. Certes, le livre effectue un bon travail pour introduire et convaincre les nouveaux venus des vertus de l’intégration continue, en édictant les principes de base (que j’estime pour ma part connus) et en hésitant pas à les répéter (ce qui est parfois nécessaire).

Cet aspect introductif est en fait l’objet de la première partie, longue de 100 pages. Bien qu’à mon avis la cible de ce type d’ouvrage ne soit pas d’introduire le sujet, mais une expertise sur la mise en pratique, je n’ai rien contre une petite introduction. Mais 20 pages auraient suffi, surtout si l’on considère la teneur. En fait, on y trouve un peu trop de propos de haut niveau, qui me rappellent certains des moins bons volumes de « l’Object Technology series » du même éditeur. Bref, j’arrive à la fin de cette partie, non seulement sans avoir rien appris, mais avec l’impression que j’en sais plus que les auteurs.

La seconde partie est dédiée au traitement en profondeur de l’intégration continue. Le découpage en chapitres est plutôt pertinent : intégration continue des bases de données, tests, inspection, déploiement et feedback. Hélas le traitement des différentes parties manque carrément de profondeur. Les auteurs abordent bien le « ce qu’il faut faire » mais assez peu le « comment faire », hormis quelques exemples de scriptes Ant. À noter, en passant, que la quasi-totalité de l’ouvrage est basée sur le postulat de l’utilisation de Ant et Cruise Control (et de leur équivalent .NET), je suis donc frustré (avec bien d’autres, certainement), moi qui utilise Maven et Hudson (ce dernier outil n’est même pas évoqué dans la liste des outils en annexe, peut-être parce qu’il aspire trop d’utilisateurs de Cruise Control ?).

Bref, on est non seulement déçu par l’absence de recettes concrètes, mais aussi par l’étroitesse des typologies de projets abordés. Je suis déçu également par le discours : n’y a-t-il donc qu’une seule façon d’appréhender l’intégration continue ? Les auteurs posent pourtant de nombreuses questions pertinentes qui sont autant d’obstacles à la mise en œuvre de l’IC, mais leur seule façon d’y répondre est l’objection.  L’expérience nous montre pourtant que l’IC est quelque chose de facile à casser, jamais ce point n’est abordé. Les vraies questions sur la complexité de mise en œuvre de l’IC ne sont jamais évoquées : Commit en deux temps pour les IC cassant trop souvent, cadre technologiques ancien ou hétérogène, équipes nombreuse, build long ou tests volumineux.

Les auteurs se réfèrent souvent à deux textes : le livre de Brad Appleton sur les patterns de gestion de configuration et l’article de Martin Fowler sur l’IC. J’aurais aimé que ce texte ait la profondeur et la pertinence du « Patterns on Configuration Management ». Pour ce qui est de se référer à l’article de Martin Fowler, j’attends simplement mieux d’un livre de 220 pages que de se comparer à un article qui en compte une dizaine.

Donc, grosse déception. Passez votre chemin.

continuous-integration

Référence complète : Continuous Integration, Improving software quality and reducing risk – Paul M. Duvall, with Steve Matyas & Andrew Glover – Addison Wesley / Signature series 2007 – ISBN : 0-321-336338-0 ; EAN : 978 0 321 33638 5

Continuous Integration: Improving Software Quality and Reducing Risk


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

Scrum Night III : l’appel à orateurs

Le par addinquydans ArticlesLaisser un commentaire

La Scrum Night III se déroulera chez Google, les inscriptions ont rencontré un grand succès !

Mais qu’est-ce qu’une Scrum Night sans ses ateliers ? Il y a déjà des propositions, il est encore temps d’en faire !

Rejoingnez-nous sur Ideascale pour proposer vos ateliers, jeux, etc…

Bref, suivez le lien !

Scrum Night III : l’appel à orateurs

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