Retrouvez les chroniques de l’auteur de la revanche du rameur dans l’émission La Tête au Carré de Mathieu Vidard sur France-Inter, et ses déjà célèbres “stats à la con” !
A scientist build in order to learn ; an engineer learn in order to build.
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.
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:
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.
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:
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 :
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 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…
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.
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 :
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.
Cogito ergo sum.
Note : 7 ; Une très bonne introduction à Scrum pour l’impatient : brève, claire et bien écrite.
Plutôt qu’un livre, il s’agit d’un livret. Sous sa forme papier il pèse moins de 50 pages (et encore, des pas bien longues). Ce texte se situe à mi-chemin entre le « Scrum en 5 minutes » et le fameux « Scrum and XP from the Trenches » d’Henrik Kniberg. Il se situe plus près du premier titre et ne saurait se comparer au best-seller de notre Suédois préféré.
S’il ne prends pas 5 minutes, il ne nécessite pas tellement plus d’une heure. Le texte se lit d’autant plus vite que le style est vraiment concis et alerte : un vrai plaisir pour le lecteur.
Après une courte introduction (vraiment courte : une page pour expliquer « pourquoi Scrum »), le texte se présente en 3 parties :
La première présente les 3 rôles. C’est clair et le partage des responsabilités et l’état d’esprit attendus sont sans équivoques. Chacun des 3 aspects est plié en une paire de pages, ou peu s’en faut !
La seconde partie traité des « artefacts » : le product backlog, le sprint backlog, le burdown / burnup chart, le tableau des tâches et la définition de terminé. Encore une fois la clarté prime, mais les auteurs ne font pas de raccourcis pour expliquer par exemple l’aspect adaptatif du détail du backlog ou encore comment se présente une User Story.
La troisième partie nous fait voyager au sein d’un Sprint. Si les auteurs parlent de sprint d’une ou deux semaines, ils font le choix de nous présenter un sprint d’une semaine. Les cérémonies sont présentées de manière précise et concise : qu’est-ce qu’on y fait et dans quel ordre.
Petite particularité de l’ouvrage, il parle du « story time », temps dédié à la préparation du Sprint suivant. De l’aveu des auteurs, cela ne fait pas encore partie de Scrum et c’est la première fois que je vois cela évoqué, même si je l’ai moi-même pratiqué.
En appendice, on trouve les valeurs et pratiques agile, donc le fameux manifeste, mais curieusement pas la liste des pratiques et valeurs de Scrum !
Ce texte est un condensé d’un autre ouvrage des mêmes auteur : « The Elements of Scrum » qui en constitue en quelque sorte la version longue. La version électronique coûte moins d’un euro et je recommande sans réserve ce texte pour initier rapidement un équipier à Scrum. Plus encore que le Scrum en 5 minutes !
Référence complète : Scrum, a Breathtakingly Brief and Agile Introduction – Hillary Louise Johnson & Chris Sims – Dymaxicon 2012 – ASIN : B007P5N8D4 (Kindle edt.)
Il me semble qu’il n’y a pourtant pas si longtemps que j’ai marqué d’une pierre blanche la première année de mon blog. Oui, c’était il y a à peine plus d’un an. Mon rythme est donc disons… honorable ! Revoyons tout cela en chiffres !
Il y a un an, je me réjouissais de mes 221 posts. Un an et deux semaines plus tard, ce sont donc 279 nouvelles entrées qui s’y sont ajoutées.
Au niveau rythme, après un petit creux de début d’année, je tourne à une moyenne d’un peu plus de 20 posts par mois. Considérez quand même qu’un post sur trois est une citation et cela rend la chose moins démente.
Plus intéressant à mon goût : l’évolution des Notes de lectures si je les compare aux autres billets (en excluant les citations). Sur les 12 derniers mois, la tendance s’est inversée par rapport à l’année précédente. Les billets dépassent en nombre les notes de lecture, parfois de beaucoup.
Elle semble en augmentation !
En fait, il faut la rapprocher de celle de l’année précédente. Toutefois comme je n’ai mis en place les analytics qu’en Mars 2012, il me faut “normaliser” les données sur les deux années. J’ai donc multiplié les données de la première année par 1,5 ; ce n’est pas tout à fait juste, mais disons que c’est une approximation acceptable.
Les chiffres font apparaitre une augmentation substantielle des visites, ou plutôt des visiteurs uniques (le chiffre que je préfère suivre).
Les rebonds paraissent important (en baisse insignifiante), mais c’est plus probablement lié au fait que la plupart des visites viennent des liens Twitter. Malgré tout, deux chiffres me surprennent : la diminution très sensible des pages vues par visite : de 2,72 à 1,7 ! Cela se traduit de manière naturelle par une diminution du temps passé à chaque visite : de 2,72 mn à 1,77 mn. Normalisé à une page, cela fait 57 sec par page sur la première année et 1,13 min par page sur cette dernière année.
Qu’en est-il des browsers ? C’est assez stable, avec un poil de perte de terrain de Firefox et un poil de regain côté Safari, mais pas de gros changements à part ça…
Déjà 500 posts. Peut-être devrais-je réduire le rythme ? Hélas, j’ai encore quelques sujets sur la pile. La prochaine synthèse est prévue pour mon millième post. Espérons que ce soit dans un bout de temps !
Talent wins games, but teamwork and intelligence wins championships.
Note : 7 ; Un ouvrage vraiment fait pour bien utiliser SSIS et pas seulement l’expliquer
Pas facile de trouver un ouvrage sur SSIS en expliquant le fond, le bon usage et ne se limitant pas à la description de l’outil ! Ce livre est celui-ci. Il s’adresse au praticien déjà expérimenté de l’ETL de Microsoft et propose une série de patterns de mise en œuvre afin de bien architecturer un projet SSIS ! Franchement c’est tout simplement la seule source d’information (livres et Web inclus) que j’ai peu identifier faisant cela !
Le biais du livre, désavantageux du point de vue de ma propre utilisation, est qu’il est orienté solution BI. Ainsi les 12 chapitres de ce livre de 420 pages s’orientent-ils dans ce sens selon les étapes logiques de réalisation d’un projet SSAS. Mon intérêt direct d’arrêtant donc vers les chapitres 6 ou 7. Mais je ne doute pas que le développeur BI trouvera beaucoup d’intérêt au reste du livre.
Je dois bien aussi avouer que même si seule la première moitié du livre m’a intéressé (la seule que j’ai lu, en fait), j’ai considéré mon achat amorti sur cette seule partie !
Le premier chapitre évoque les architectures de déploiement possibles avec SSIS. Pour chacune d’entre elle, on évalue ainsi les bénéfices et les aspects négatifs. Tout ce qu’il faut pour arrêter un choix en connaissance de cause.
Au chapitre 2, on traite la mise en place d’un « Framework » dans lequel vont s’inscrire les intégrations. Cela recouvre les problématiques de configuration d’auditabilité, de logging et de gestion d’erreur. Là encore des domaines où sont plus détaillées les caractéristiques de SSIS que la façon intelligente de les mettre en œuvre. Comme ici. Oserai-je dire qu’à ce point, j’avais déjà de quoi être satisfait de mon achat ?
Le chapitre 3 est assez court, il traite des options de déploiement des packages SSIS. Il y en a plusieurs, mais jamais avant cela on ne m’avais expliqué les traits des différentes options. C’est chose faite, je comprend mieux et saurais désormais décider en connaissance de cause !
A partir du chapitre 4, on rentre dans l’usage des tâches de SSIS. Et pour commencer le traitements des fichiers. Les auteurs présentent ici leur approche encore une fois, pas seulement l’utilisation de l’outil. Même si j’ai moins appris que sur les chapitres précédents, il y a clairement du savoir faire à réutiliser…
Le chapitre 4 propose des « bests practices » pour les problématiques d’extraction et de stagging des données. Même s’il est d’usage général, ce chapitre s’inscrit plus dans une optique de projet BI.
Il en va de même pour les chapitre 6 (où j’ai arrêté ma lecture) qui s’attache aux problématiques de nettoyage des données.
Je reprendrais certainement cette lecture un jour, en fait les problématiques BI m’intéressent également. Quoi qu’il en soit, j recommande sans réserve ce livre pour le praticien déjà aguerri de SSIS : le savoir-faire qu’il propose n’existe pas ailleurs !
Référence complète : SQL Server 2008 Integration Services : problem, design, solution – Erik Veerman, Jessica M. Moss, Brian Knight Jay Hackney – Wrox 2010 – ISBN : 978 0 470 52576 0
En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.
De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.
Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !
Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.
L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe !
Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ?
Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:
Enfin oui, Joanne utilise un backlog.
Un backlog très mouvant, il faut bien le dire, car :
Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog…
Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause.
Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !
Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ?
Traditionnellement, la structure d’une telle équipe serait :
Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :
En conclusion…
En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir !
La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.
C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !
La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…
Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée !
Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets.
Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.
Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :
Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :
L’architecture EDA implique aussi de nombreux corollaires :
L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres.
La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0
Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…
Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.
C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !
Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…
Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).
J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…
Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…
Software Freethinker 
