Andy Hunt: Uncomfortable with Agility: What has Ten+ Years got us?
La propriété fondamentale de l’agilité est l’aptitude au changement, la capacité d’évoluer en utilisant le feedback comme moteur de cette évolution.
Nous découvrons de meilleures façon de travailler … tels sont les premiers mots du manifeste agile. Ils ne disent pas “nous connaissons”. Alors pourquoi l’agilité a si peu évolué ces 12 dernières années ? Nous restons ancrés sur XP et Scrum, peut-être un peu mâtiné de Lean…
Andrew Hunt revient sur ce que signifie être agile, et non “faire agile”. Une présentation qui retourne au coeur de l’état d’esprit agile, par l’un des auteurs du manifeste.
Il n’y a pas (encore) d’ouvrages traitant du Story Mapping, un technique développée par Jeff Patton. Elle comble une lacune de l’approche fonctionnelle agile basée sur les User Stories qui proposent une manière de cartographier ceux-ci sur des axes orthogonaux : le processus et la réalisation incrémentale. Pour moi, il s’agit d’un outil supplémentaire à embarquer dans ma besace de pratiques agiles. Je ne vais pas les considérer comme un passage obligé des projets agiles, tout comme je ne suis pas prêt à accepter l’idée que les User Stories sont le moyen unique d’exprimer un besoin utilisateur (ce qui nous conduit par ailleurs à la notion de “story technique” que je rejette purement et simplement). Le Story Mapping se situe au même niveau d’usage que les Cas d’Utilisation, une technique écartée par la plupart des agilistes, mais pas par moi (je reste en bonne compagnie sur ce point). Cette technique présente certains avantages par rapport aux cas d’utilisation, et ces derniers exhibent d’autres atouts. Nous reviendrons peut-être un autre jour là-dessus : Jean-Claude Grosjean et moi-même avions même évoqué l’idée de faire une présentation commune sur ce sujet un jour ! Pour le story mapping :
Structuration bottom-up des user stories.
Agencement des stories dans un processus (quand celui-ci reste simple)
Agencement par itération visible dans la map.
Un processus de travail collectif.
Pour les cas d’utilisation :
Une structuration “divide and conquer” top-down du besoin fonctionnel.
Une bonne structuration par unité fonctionnelle cohérente en lien avec des acteurs.
Un bonne structuration fonctionnelle intrinsèque avec l’articulation des scénarios.
Un niveau de structuration fonctionnel qui peut servir de charnière avec de nombreuses activités : UX, acceptante testing, etc…
A défaut d’avoir la référence ultime, j’ai essayé de collecter ici des ressources sur le sujet. Notons d’ailleurs au passage que la 3ème édition du livre de Claude Aubry évoque cette technique.
L’article de référence de Jeff Patton
Il décrit les étapes de la technique. Il n’a pas simplement un “intérêt historique”. Il reste tout à fait pertinent. En fait, je conseille de commencer par lire cet article !
Jeff Patton présente également son approche sur son site.
Pour ceux qui préfèrent le format “slides”, c’est juste ici:
La présentation de Steve Rogalsky
C’est un peu le “Story Mapping from the Trenches” : une présentation très visuelle sur la façon de faire du story mapping, où le présentateur montre comment lui-même opère concrètement. Une bonne illustration de l’article de Jeff Patton !
Par ailleurs, Steve Rogalsky a développé la matière de cette présentation via une série de posts :
Laurence Hanot : construisez votre produit en racontant des histoires !
J’avais assisté à la présentation de Laurence à Agile France, c’est une occasion de mettre en avant sa présentation qui est une introduction à la technique
De l’impact mapping au Story Mapping
Cette présentation m’a été indiquée par Gojko Adzic. A voir et revoir car elle fait le lien avec l’impact Mapping
Autres ressources
Un post d’Oana Juncu qui évoque le sujet, mais aussi l’articulation des tests d’acceptance sur cette expression des besoins.
En attendant que j’ai le courage de la terminer sous forme d’article, voici les slides de ma présentation à l’Agile Tour Bruxelles. Cette présentation est directement inspirée d’un conseil de conception de Scott Meyers : “Make your interfaces easy to use correctly and hard to use incorrectly”. Sur ce, je vous laisse vous essayer aux quizz contenus dans cette présentation !
Gérer son temps est un des grand challenge de notre époque. Henrik Kniberg nous propose de manière très graphique son approche qui combine Kanban, GTD et Lean (voir un peu de Pomodoro) et nous montre comment il s’en est servi pour fais le tour du monde pendant un an avec des enfants en bas âge !
Ce premier Octobre, Zenika accueillait de nouveau le groupe Meetup dédié à Neo4J. L’occasion de faire connaissance avec Spring Data grâce à Florent Biville.
Echauffement
Débuter un Meetup par l’interlude commercial, ce n’est pas nécessairement le meilleurs départ. Mais Cédric Fauvet connait au moins le public auquel il a à faire et il fut lui-même développeur. En fait, il a même évoqué deux ou 3 choses qui ont piqué ma curiosité !
La première réelle application de la théorie des graphes semble être celle des 7 ponts de Königsberg. Le seigneur du coin voulait savoir s’il était possible de faire un trajet dans la ville en passant une fois et une seule par chaque pont. Ce n’est pas possible et l’on peut s’en rendre compte de manière empirique, mais c’est Leonhard Euler qui le démontra mathématiquement.
Il n’y avait pas Neo4J à l’époque, mais aujourd’hui on en dispose et on résoud avec d’autres problèmes ayant trait à la théorie des graphes:
Bien sûr il y a déjà le cas classique des réseaux sociaux, comme les suggestions de contacts utilisés par Viadeo.
Les analyses d’impact sur les réseaux, mis en oeuvre chez SFR.
Les calculs de primes de commerciaux, chez Sisco (!) Il ne faut pas moins de 2 clusters pou gérer cela.
Le routage des colis chez un grand opérateur en Allemagne.
Aujourd’hui la communauté Française semble se porter plutôt bien, elle compte 362 personnes inscrites sur le Meetup et un nouveau Meetup va démarrer sur Lyon. Du point de vue de l’actualité, c’est la version 2.0 qui occupe le terrain et doit être le sujet principal de Graph Connect.
Après le pizza-break, place au sujet principale de la soirée.
Spring Data
Nous sommes face à un dilemme aujourd’hui : le monde devient de plus en plus dynamique, ce qui fait la part belle à des bases de données orientées graphe telle que Neo4J. Et pas seulement cette dernière d’ailleurs, mais aussi des solution empruntant le même paradigme:
Titan, une base de données orientée graphes distribuée.
Blueprint, qui est plutôt une abstraction au-dessus des bases de données graphe, mais aussi une stock logicielle offrant des fonctionnalités de plus haut niveau.
RDF, l’ancêtre de ces bases de données, qui est une normalisation par le W3C des représentations de données sous forme de triplets.
Orient DB qui mixte des fonctionnalités d’une base orientée documents avec une base orientée graphes.
Un dilemme disais-je, car si ces solutions adaptées aux problèmes actuels se développent, l’entreprise reste, elle, conservatrice. Elle continue de s’appuyer majoritairement sur les bases de données relationnelles et donc sur les ORM pour assurer la jonction avec le code applicatif.
Ces solutions ORM, tel que le standard JPA ne semblent pas poser de problème dans la plupart des cas, pourtant on fait rapidement face à “l’abstraction leak”, à savoir que les paradigmes fondamentaux des SGBDR et des applications sont différents et les ORM tentent de le masquer.
Les bases de données graphe offrent un mapping plus simple et plus naturel. Elles permettent en outre de satisfaire d’autres besoins :
L’hétérogénéité des propriétés associées aux noeuds.
L’absence de schéma prédéfini. Sur le papier, c’est un problème car il permet une discordance des donnés par rapport à l’intention de structuration. Mais avec Neo4J 2.0 le schéma existe de manière optionnelle.
Il y a-t-il un intérêt à proposer un mapping objet des bases orientées graphe ? Oui, si il offre une réelle simplification et des fonctionnalités intéressantes.
Hibernate OGM, une première approche
Hibernate OGM offre une approche inspirée de l’ORM qui ne convainc pas Florent. D’une part, à l’instant de JPA elle offre le plus petit dénominateur commun des bases orientées graphes, et l’idée de faire entrer toutes les bases de données NoSQL (pas seulement les bases orientées graphes) dans un même moule semble pour le moins un gros challenge…
Tinkerpop Frames
Cette solution se focalise également sur la construction d’une abstraction des bases orientées graphes (et seulement celles-ci). Elle propose son propre langage de requête, Gremlin. Las aujourd’hui le langage de requête de Neo4J, Cypher est l’un des atouts important du produit et de gros efforts sont consentis pour en améliorer les fonctionnalités. On se retrouve donc dans une course à la fonctionnalité… que Gremlin peut difficilement gagner.
Spring Data
Suivant l’idée d’origine de Spring, il s’agit d’une brique très légère. En fait, à l’origine même de ce sous-projet, il y a la rencontre entre Emil Eifrem et Rod Johnson, à savoir respectivement les créateurs de Neo4J et de Spring !
Un atout important de Spring Data est aussi son concept de “multi-store”. Nous avons évoqué la frilosité des entreprises par rapport aux nouveau paradigmes de bases de données. Spring Data adresse cela en permettant des ponts entre différents paradigmes (par exemple relationnel vers graphe) permettant des transitions douces vers ces nouveaux mondes ! D’un point de vue pratique, pour un repository standard, tout ce que l’on a à faire, c’est d’hériter de l’interface GraphRepository<> … et Spring Data s’occupe du reste ! Derrière le rideau, cette interface hérite de quelques autres (je ne vais pas les lister, elles sont sur le slide 31). Derrière le second rideau, au niveau de l’implémentation générée, cela va bien entendu être la “foire aux proxys” ! Bon, comme on dit : on ne peut pas tout avoir ! Spring Data offre d’importantes facilités pour écrire, ou plutôt ne pas écrire, des méthodes de recherches :
Des “find”, où la simple convention de hommage va permettre de connaitre les critères de recherche en les mappant sur les paramètres.
Des recherches plus complexes s’appuyant sur des clauses Cypher figurant en annotation @Query de la méthode.
En annotant des classes @NodeEntity, on peut spécifier ce qui est persisté et ce qui ne l’est pas, ce qui constitue des arcs, et bien d’autres choses encore ! Les templates Neo4J, à la façon de ce qui existe pour d’autres modules Spring, permettent d’opérer des requêtes de projection en éliminant la plomberie inhérente à l’utilisation brute de la base.
Spring Data offre de nombreuses fonctionnalités supplémentaires, comprenant bien entendu les famaux “cross store storage” que nous avons évoqué au début.
Pour conclure Une soirée instructive sur les possibilités de Spring Data, bien que j’ai regretté que cela aille un peu vite sur les NodeEntity et que l’on ne s’arrête guère sur les stores multiples, car cela me parait un point clé pour Neo4J en entreprise, bien plus que l’économie de code que permet le framework ! Par ailleurs Florent a initié une série d’articles très bien écrits pour s’initier à Neo4J : le premier de la série est ici.
… En fait, cela aurait dû être “le tour de Varnish en 80 jours” … cela s’est avéré trop long, nous nous sommes donc repliés sur 30 minutes !
Varnish, j’en entends parler régulièrement, surtout quand il s’agit de gros, de très gros sites. Mais jusqu’à présent, je ne savais pas vraiment ce que c’était. La présentation que nous a fait Dridi Boukelmoune chez Zenika nous a éclairé sur la bête.
Varnish, c’est quoi ?
C’est un cache HTTP. Plus exactement un reverse proxy cache HTTP. Ce n’est ni le premier, ni le seul. Pourquoi donc l’évoquer ? Comme je l’ai dit, on trouve Varnish dans les grosses, les très grosses infrastructures Internet. Car outre sa remarquable stabilité, ce sont ses performances très élevées qui ont fait la réputation de Varnish. Bien qu’issue de Varnish Software (la partie commerciale de Varnish), cette petite Vidéo fait un bon résumé de la situation.
Bref, Varnish, c’est un cache HTTP très performant car travaillant au plus près de la pile TCP/IP.
Pas d’IHM sexy pour configurer la bête. Varnish est fait pour les admmins sys barbus et se configure à l’aide d’un DSL : le VCL.
Configurer Varnish avec VCL
VCL c’est plus qu’un script de configuration, c’est un DSL qui est ensuite compilé en C. Pré-compilé, devrais-je dire, car bien sûr ce code C est lui même compilé ! Nous l’avons évoqué, Varnish est focalisé sur la performance, et on ne fait pas de choses performantes avec des mécanismes dynamiques ! Malgré tout, le changement de configuration peut être opéré à chaud.
Time to live
De base, Varnish gère son cache en TTL, mais on peut y inclure certaines variantes:
En fonction de l’encoding
En fonction du navigateur utilisé
En fonction de la compression
Les règles par défaut
Tout ne doit pas aller en cache ! Le VCL permet d’ajuster ces règles, mais par défaut Varnish stipule que :
Il n’y a pas de mise en cache d’une ressource si elle est liée à un cookie.
Pas de mise en cache si il y a des informations d’authentification.
Seules les requêtes GET et HEAD sont mises en cache. Les requêtes POST ne le sont pas.
Varnish gère les “variantes” en s’appuyant sur l’en-tête HTTP vary qui permet d’indiquer explicitement un élément à associer à la décision de cache.
Invalidation ou prolongation
Au-delà de la règle de fonctionnement de Varnish, qu’il s’agisse des règles par défaut ou d’une configuration qui s’en écarte, il est possible d’exclure des ressources du cache à l’aide de plusieurs mécanismes.
L’invalidation des ressources est possible, que ce soit sur une base individuelle ou suivant une expression régulière. Elle peut être opérée en ligne de commande ou via le VCL.
L’option la plus radicale d’invalidation est la purge. La ressource est retirée du cache, il n’y a plus moyen de la ressusciter une fois cela fait.
Varnish possède aussi une notion de ban. Il permet d’invalider un objet du cache, mais sans en entrainer son nettoyage.
A contrario on peut prolonger une ressource au-delà de ce que prévoit initialement les règles de Varnish, avec la notion de “grâce” qui permet de prolonger un contenu à priori périmé. Ce mécanisme peut s’avérer utile en cas de défaillance du back-end.
Mais comment ça fonctionne le VCL ?
Ecrire du VCL, c’est presqu’écrire du C (c’est probablement pour cela que c’est facile à compiler…). Varnish propose un certains nombre de “looks”, des template méthodes qui sont appelées par Varnish si elles sont implémentées. Il suffit alors d’implémenter la fonction en question pour s’insérer dans le cycle de vie du cache, et d’y utiliser les fonctions que Varnish met à notre disposition pour bannir un objet, par exemple.
Bien sûr, il faut pour cela connaitre le cycle de vie des objets
Et voici ce à quoi peut ressembler un bout de configuration Varnish :
sub vcl_recv {
if (req.request == "PURGE") {
if (!client.ip ~ purgers) {
error 405 "Method not allowed";
}
return (lookup);
}
}
Comme on peut l’imaginer, cet élément de configuration vient “hooker” l’état recv, en suivant le pattern “template method”.
Au-delà de la configuration
Director : Varnish fait du load balancing !
Enfin, pas tout à fait du load balancing, mais presque !
Un director est un groupe de back-ends clusterisés pour lesquels on établit une stratégie de redirection. Le but premier n’est pas de faire du load balancing, mais plutôt de maximiser les chances d’obtenir une ressource.
Maintenant, on peut aussi s’en servir pour faire du load balancing !
Etendre Varnish avec les modules
Outre la possibilité qu’offre le VCL d’y introduire du code en C, la méthode la plus élégante d’étendre Varnish est d’utiliser les modules, ce qui est possible depuis la version 3 de l’outil.
Dridi a d’ailleurs écrit un article (sinon l’article de référence) sur ce sujet, sur le Blog de Zenika.
Administrer l’outil
La console
On n’est pas chez les touristes. Ici de base, l’administration c’est la ligne de commande avec varnishadm ! Certaines des opérations que l’on peut faire avec sont même scriptables pour être intégrées dans un sh. Du classique pour les admins, donc.
Le bundle commercial de Varnish propose la Vanish Administration Console (VAC) qui est un outil Web. Mais comme toujours dans ces cas là, on ne peut quand même faire l’impasse sur la ligne de commande.
La gestion des logs
C’est un sujet d’attention particulier. Le loge peuvent rapidement ralentir terriblement les traitements. Varnish a pris une option radicale à cet égard : les logs sont en mémoire et sont en binaire ! Et Varnish propose un ensemble d’outils pour y accéder et les exploiter (varnishlog, varnishncsa)
Vers l’infini et au-delà…
En résumé
Le point essentiel, celui qui fait choisir Varnish, c’est qu’il s’agit d’un cache HTTP ultra-performant à même de décharger efficacement le back-end dans le cas de sites à très fort trafic. C’est LE cas d’utilisation. Pour un site n’ayant pas un très fort trafic, Varnish sera de très peu (et plus probablement d’aucun) intérêt.
Varnish en 5 étapes
Voici la démarche condensée de mise en oeuvre que nous propose Dridi :
Cacher le contenu statique
Configurer la compression
Cacher le contenu semi-statique
Automatiser l’invalidation
Améliorer le back-end
Les autres fonctions de Varnish
Bien que sa fonction essentielle soir le cache HTTP, on ne peut ignorer ce que Varnish sait faire d’autre :
Bien entendu, nous l’avons évoqué, Varnish peut servir de reverse proxy, bien que ce ne soit pas sa vocation première.
Merci Dridi !
Dridi n’est pas seulement un excellent collègue chez Zenika, son intérêt et sa maitrise croissante sur Varnish l’ont amené à en devenir un contributeur ! Il est entre autre chose l’auteur du module QueryString.
La présentation dont Dridi nous a gratifié fera partie de sa présentation des petits déjeunes planifiés sur Lyon et Paris, consacrés à Varnish. J’avoue que cette présentation en 30 minutes (30 minutes et 18 secondes, précisément) était un peu ardue pour moi, car faite un peu sans concession. C’est mon seul reproche. Elle présente clairement les fonctions et possibilités de l’outil et l’enthousiasme, la passion devrais-je dire de Dridi pour ce projet open-source font beaucoup au plaisir que j’ai eu à l’écouter.
Le consortium Web RTC est soutenu par Google et Mozilla, entre autres, avec le but avoué de supporter cela dans leurs browsers respectifs. C’est également un groupe de travail à l’IETF ainsi qu’au W3C.
Voir aussi l’excellente présentation faite par Google lors du Google IO 2013 ; la vidéo de cette présentation est incluse dans les slides. La présentation faite lors du Google IO de l’année précédente mérite aussi que l’on s’y arrête.
En pratique…
Dans la pratique, il s’agit de 3 ensembles d’API :
MediaStream API : Elle permet d’échanger vidéo et son, nottament.
RTCPeerConnexion : qui permet de maintenir des connexions pair à pair entre machines pour échanger des streams. Cette connexion peut être obtenue avec ou sans serveur intermédiaire en fonction du protocole retenu. Hadopi aura peut-être quelque chose à dire là-dessus…
RTCDataChannel : pour les échanges d’autres types de données, par exemple pour les jeux.
Comme l’année dernière, Devoxx proposait cette année des “BOF” dont l’accès était libre moyennant une inscription préalable. J’ai vite arrêté mon choix sur celle de Martin Odersky. Scala est un sujet d’actualité pour moi, je suis au milieu du cours Functionnal Programming in Scala sur Coursera par le créateur du language !
Autant l’avouer tout de suite, ce n’est donc pas spécifiquement les nouveautés 2.10 qui m’intéressaient ici. J’espérais aussi grapiller un peu des “pourquoi” qui ont présidé aux options du language.
DSDM continue d’intéresser son microcosme, mais celle que je considère comme la moins agile des méthodes agiles a échoué à mon avis à se répandre de manière majeure, contrairement à Scrum. “si tu ne peux vaincre ton ennemi, embrasses-le !”. C’est ce que fait Andrew Craddock, chairman de DSDM en proposant ce framework DSDM adapté à Scrum !
Un article complémente le propos de l’orateur, que je vous propose ici.
Software Freethinker 