They told me computers could only do arithmetic.
Grace Hopper
Agile Grenoble 2013
Organisé par le Club Agile Rhône-Alpes, cet évènement prévoit d’accueillir sur une journée plus de 500 professionnels de la région et proposera plus de 40 sessions dans des domaines variés (Agilité, Lean, Management, Jeux, Ingénierie du logiciel).
J’avais brièvement évoqué cet évènement cet été, pour vous suggérer de le noter dans vos agendas. Je serais présent cette année à la conférence où je présenterais un sujet. Teasing, teasing :
User stories, what else ?
Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.
Au cours de cette session, nous allons étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.
La conférence Agile Grenoble
Agile Grenoble existe 2008. C’est LA conférence incontournable sur l’agilité sur la région Rhone-Alpes et l’un des évènements majeurs consacré à l’agilité en France aux côtés d’Agile France et du Scrum Day (Je devrais sans doute ajouter Mix-IT, mais cet évènement n’est pas uniquement focalisé sur l’agilité). Avec 500 inscrits, elle se situe même devant les grandes manifestations Parisiennes en terme de fréquentation !
Zenika à la conférence
Zenika est fier de compter au nombre des sponsors de l’édition de cette année.
Mais il ne s’agit pas seulement de faire acte de présence, ce serait insuffisant.
Le leader en tant qu’hôte
En plus de ma session, Géry Derbier animera l’atelier “le leader en tant qu’hôte” auquel j’ai eu le plaisir de participer à Agile France cette année. En voici le teaser:
La métaphore du leader comme héros ne me satisfait bien évidemment pas. Celle du servant leadership ne me convient pas beaucoup plus d’autant que je l’ai rarement entendue traduite en français et je pense que dire à un exécutif qu’il doit devenir un serviteur est… source de résistance. Je propose d’explorer ensemble une métaphore ancienne proposée par Mark McKerkow, le leader en tant qu’hôte. Je propose d’étudier entre autres les aspects suivants : la notion d’hospitalité et le pouvoir de l’invitation, la co-création d’un moment comme une soirée ou une fête (en français hôte designe à la fois celui qui reçoit et l’invité), l’équilibre entre définir et participer, … Nous verrons ainsi comment utiliser, ou pas, cette métaphore dans la mise en oeuvre de l’agilité dans une organisation. Compte tenu du caractère co-créatif de la métaphore proposée tout le monde est concerné et bienvenu dans cette session.
See you soon !
Ce n’est d’ailleurs pas tout : Laurent Sarrazin présentera aussi une nouvelle session : Neurosciences pour transitions agiles. Une belle représentation du pôle agile de Zenika, donc.
Note de lecture : Succeeding with Open Source, par Bernard Golden
Note : 7 ; Quand le monde du développement organisé traditionnel rencontre le monde du développement communautaire.
Cet ouvrage traite de l’évaluation des prouits open source et de leur intégration au sein des systèmes d’information d’entreprise. Pour ce faire, l’auteur a développé une méthode d’évaluation (qu’il a appelé OSMM pour Open Source Maturity Model). Je dois dire que l’auteur m’a étonné, car venant de toute évidence d’un monde plus traditionnel, il n’essaye pas de comparer l’open source selon les canons des produits commerciaux. Au contraire, il apprécie leur qualité justement au regard de l’absence d’objectifs commerciaux qui amène ces développement à progresser d’avantage en terme de satisfaction des utilisateurs utôt qu’en terme d’attraction des clients potentiels qui entraine souvent une boulimie des fonctionalités qui se fait au détriement de la qualité. Au cours de ses périgrinations, l’auteur est devenu un fervent supporter de l’open source, tout e conservant un jugement serein, ce qui l’a entrainé à construire l’OSMM.
Le processus d’évaluation développé ici est bien adapté à l’open source, car il est simple. En effet, pourquoi développer un modèle compliqué, alors que celui-ci n’évitera pas l’évaluation technique ultérieure. En fait, ce processus a juste pour objet d’établir un « go / no go » basé sur des critères tels que achèvement du produit, disponibilité de support, de documentation et de formation, et de mettre ces informations en vis-à-vis du type d’utilisation que l’on désire en faire : expérimentation, production ou projet pilote. On ne reste pas dans la simple théorie, car chaque point développé est très concrètement illustré par l’évaluation d’un produit Open-source connu : JBoss. Il aurait certainement été intéressant d’y mettre en vis-à-vis un produit moins haut de game et moins abouti, bref plus dans la moyenne des produits open source disponibles, mais c’est très bien quand même.
J’ai bien aimé ce livre, sa simplicité et son pragmatisme. Le reproche le plus important que je lui ferai et de ne pas développer l’aspect communotaire (ou au moins l’évoquer), par lequel un utilisateur se doit quand il le peut, aider les autres par son expérience acquise. L’auteur a trop tendance à inciter les utilisateurs à se placer dans une position de pur consommateurs (pourqoi mutuliser les connaisances au sein de l’entreprise, alors que chaque utilisateur peut directement interroger (et donc poser plusieurs fois la même question) la mailing liste sans que cela ne coûte rien ? Ormis ce point, il est bien que ce livre participe à placer l’open source dans une optique d’utilisation d’entreprise et non plus comme des développements de hobystes.
Référence complète : Succeeding with Open Source – Bernard Golden – Addison Wesley / IT series 2004 – ISBN: 0-321-26853-9
Il ne faut pas désespérer des imbéciles. Avec un peu d’entraînement, on peut arriver à en faire des militaires.
Pierre Desproges
Lausanne
Note de lecture : Spring Batch in Action, par A. Cogoluègnes, T. Templier, G. Gregory & O. Bazoud
Note : 7 ; Une qualité de prose qui fait honneur à la « in action » series, mais une lecture un peu lourde au total.
Mon premier contact avec ce livre a été teinté d’appréhension : il compte pas moins de 440 pages hors annexes, ce qui me semble beaucoup, je le dis sans ambage ! Puisque l’on en est aux présentations : le volume est découpé en 14 chapitres, eux mêmes regroupés en 3 parties. Il faut en plus compter une vingtaine de pages d’annexes. Cela nous donne une moyenne d’une trentaine de pages par chapitre. C’est beaucoup à mon gré, mais consistent avec le standard de la « in action » series. A propos de cette série, Manning fait beaucoup d’effort pour maintenir une ligne éditoriale de bonne qualité qui permet d’être rarement déçu avec chacun des opus. Nous verrons que ce volume fait honneur à la série.
La première partie s’intitule « background » et regroupe les deux premiers chapitres pour un total de 50 pages. Le premier d’entre eux nous fait faire le tour du propriétaire. Non seulement on y comprends l’architecture logique (finalement, Spring Batch c’est un framework-ETL Java) mais on va jusqu’à faire une mini-application de traitement (lecture, traitement et écriture) avec la configuration Spring correspondante. Impressionnant pour un premier chapitre !
Le second chapitre rentre plus avant dans les concepts sous-jacents du framework : job, métadonnées du job, step, etc… Le but de ce chapitre est de nous donner les clés pour décomposer une spécification de traitement en étapes décomposées. Bon boulot, à nouveau.
La seconde partie « core spring batch » est de loin la plus imposante du livre. Elle compte 7 chapitres et 225 pages. C’est donc un mini-livre à elle toute seule. C’est d’ailleurs à mon avis le problème le plus important du livre, mais je reviendrais là-dessus plus tard ! Le chapitre 3 qui débute cette seconde partie nous immerge dans la configuration des batches. Plus clairement : comment s’articule la configuration Spring d’une application Spring Batch. Il y a 5 niveaux d’entités hiérarchiquement emboitées à configurer (sans compter le repository de jobs) et le chapitre passe par le menu la manière de configurer tout cela avec les attributs qui vont bien. C’est un poil lourd, mais bien écrit.
Le chapitre 5 explore en profondeur la manière de lancer (et arrêter) les jobs : en ligne de commande ou en planifiant de différentes manières. Le tout est bien illustré par des diagrammes de séquence, entre autre chose.
Avec le chapitre 5, on attaque réellement le développement de traitements Spring Batch, en débutant par les composants de lecture. Le sujet est largement balayé en largeur sur 40 pages, que ce soit sur des fichiers plat, du JSON, du XML ou de l’accès aux bases de données. Rien à dire sur la manière dont le sujet est abordé, mais c’est quand même un peu long quand ce que l’on souhaiterait, c’est arriver au bout du chemin pour voir ce que cela donne !
Le chapitre 6 aborde fort logiquement le composant d’écriture. Si les aspects de base (field extraction, formatage) sont fort logiquement abordés, là aussi le sujet est abordé en largeur, avec non seulement l’écriture sur fichier, mais la production de XML, de file sets et l’écriture en base de données. Mais on aborde aussi l’écriture en flux JMS et l’envoi de mails. Là aussi je trouve que cela fait beaucoup pour une première passe, et paradoxalement, certains de ces sous-sujets sont traités un peu rapidement !
Toujours dans la même veine, le chapitre 7 nous présente les composants de traitement. Les items processors de Spring Batch recèlent nombre de richesses et il me semble difficile de faire des impasses par rapport à ce qui figure dans le texte. La lecture du chapitre me laisse cependant un léger sentiment de confusion, mais rien de bien grave. Les excellentes illustrations graphiques ou en code permettent de toute façon de se raccrocher aux branches.
Le chapitre 8 compte à peine 30 pages, mais elles recèlent une expertise qu’il serait dommage de rater. Il s’agit de la conception des reprises sur erreur avec Spring Batch. Excellent !
Cette seconde partie s’achève avec le chapitre 9 qui couvre l’aspect transactionnel des batches. Le sujet est traité de manière solide et claire en 25 pages, que ce soit sur les erreurs à ne pas commettre, sur la portée des transactions et les différents niveaux de transaction disponible (job, chunk,…). Rien à redire.
La 3ème partie du livre est consacré aux « sujets avancés » et le premier chapitre de cette partie, le chapitre 10, dédie 25 pages au contrôle d’exécution. Partage de contexte, flux alternatifs et même externalisation des définitions de job sont parmi les sujets traités.
Avec le chapitre 11, on commence à toucher du lourd, à savoir l’intégration d’entreprise. Les auteurs évoquent d’abord les styles d’intégration d’un point de vue architecture logique. Il n’est pas étonnant qu’ils fassent référence aux Enterprise Integration Patterns de Gregor Hope ! D’un point de vue pratique, la quarantaine de pages de ce chapitre s’appuie sur 2 fondations : Spring Integration d’une part et Spring MVC pour illustrer une intégration http/ReST. Il est juste dommage que les 2 approches ne soient pas mieux abordées en séquence afin de rendre la prose plus claire.
Ce livre ne rate pas le, oh combien important, sujet du monitoring. Le chapitre 12 fait du bon boulot là-dessus, que ce soit pour décrire la structure BDD supportant cela, pour décrire l’intégration JMX ou même pour éclairer l’usage de l’outillage prêt à l’emploi de Spring batch à savoir Spring Batch Admin ou JConsole.
Le chapitre 13 est vraiment un sujet avancé car il traite de scaling. Un chapitre sur lequel il est possible de faire l’impasse en première lecture.
Ce n’est pas le cas du dernier chapitre qui aborde la problématique des tests. Il le fait à 3 niveaux : tests unitaires, tests d’intégration et tests fonctionnels. Ces 3 niveau s’appuient sur JUnit est sur des helpers fournis par Spring batch. Je ne suis pas convaincu par ce qui est proposé du côté tests fonctionnels, mais les 2 autres niveaux sont OK.
Spring Batch in action est une bonne surprise. Les auteurs ont fait globalement un très bon travail à rendre le propos clair et l’apprentissage progressif. L bouquin reste hélas un gros pavé. Mais le framework est aussi beaucoup plus riche que je ne l’avais pensé au début. Pour en rendre l’abord plus digeste, je pense que les auteurs auraient dû découper la seconde partie en 2 : en traitant d’abord d’un cas d’utilisation simple n’utilisant qu’un sous-ensemble de chacun des 3 types de composants, puis une seconde itération pour les autres cas de figure. Au final, le volume du livre aurait un peu augmenté mais cela aurait permis au lecteur de faire l’impasse sur une centaine de page en première lecture !
Ce livre s’adosse à la version 2.1 de Spring batch, il est donc toujours parfaitement d’actualité, mais une révision sera certainement nécessaire quand la version 3.0 sera en GA.
Référence complète : Spring Batch in Action – Arnaud Cogoluègnes, Thierry Templier, Gary Gregory & Olivier Bazoud – Manning 2012 – ISBN : 978 1 935182 95 5
Don’t interrupt me while I’m interrupting.
Winston S. Churchill (from “The C++ Language”, by B. Stroustrup)
Web RTC
“RTC” comme “Real Time Communication” !
Cette présentation faite sur Prezi par Enrico Marocco nous expose les principe d’architecture Peer to peer du Web RTC.
Web RTC, comment en savoir plus ?
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.
Note de lecture : C++ Programming style, par Tom Cargill
Note : 7 ; De bons conseils d’experts pour ceux qui pratiquent déjà le C++. Moins indispensable que les 2 livres de Scott Meyers.
Ce livre fait partie de la série d’ouvrages dont fait également partie “Effective C++”, qui constitue chacun des avis d’experts sur le développement en C++. Dans son volume, Tom Cargill s’attache à prodiguer des conseils sur la conception des classes en C++ : surcharge d’opérateur contre fonction membre, utilisation de l’héritage, etc… Il adresse donc des préoccupations différentes de celles de Scott Meyers. Un aspect non négligeable est la relative concision du texte qui noircit juste un peu plus de 220 pages avec une proportion de code je pense un peu supérieure à 30%. Le contenu, justement est divisé en 9 chapitre, le 10ème étant un résumé des règles établies au fil du texte.
Le premier chapitre couvre la notion d’abstraction. C’est réellement un fondamental de cet aspect de la conception, dans le principe indépendant de C++, mais illustré avec C++. Le second complète harmonieusement le propos en traitant de la consistance. Une approche intéressante qui consiste ici à s’intéresser à différentes facettes de la consistance d’une classe : contractuelle, sémantique et physique. Je mets dans le même lot de chapitres ayant d’avantage trait à la conception qu’au C++, le chapitre 3 traitant de « l’héritage inutile ». En gros, ce sont les cas où la délégation est préférable à l’héritage. Un chapitre un tout petit peu plus faible que les deux précédents.
On est d’avantage dans le C++ au chapitre 4 qui évoque les méthodes virtuelles. C’est un peu brouillon, difficile de voir où l’auteur veut en venir, Mais les conseils sont valables. J’ai préféré le chapitre 5 qui couvre la surcharge d’opérateurs, sujet délicat s’il en est.
Retour à des questions de conception au chapitre 6 qui est dédié au wrapping, en l’occurrence l’enrobage de familles de fonctions C dans des classes. Un sujet qui m’était important à l’époque et très bine traité ici.
Arrivée au choses sérieuse au chapitre 7 : l’efficacité. Un chapitre hélas un peu moins palpitant que ce que j’aurais escompté : ça tourne beaucoup autour de l’allocation dynamique, sur un cas d’étude « BigInt ». Les 35 pages de l’étude de cas qui suit ne sont pas mes préférées du livre. Un peu comme au chapitre 4, je ne vois pas trop où on veut en venir. Par contre le chapitre 9 sur l’héritage multiple est à lire absolument : il permet de bien appréhender les subtilités des différents cas de figure où l’héritage multiple peut vous entrainer.
C’est un livre moins indispensable que le Scott Meyers, mais d’une lecture agréable. Une des originalité du format de Tom Cargill est de proposer en fin de chapitre des références bibliographiques pour approfondir les sujets, et des exercices (hélas, sans les corrections). Comme je l’ai dit, le texte est concis : le lecteur non marathonien peur en venir à bout en une semaine ou deux. Si l’on peut s’estimer déçu en premier abord, je pense que ce texte permet surtout de renforcer les fondamentaux. A ce titre, c’est une très bonne lecture.
Référence complète : C++ Programming style – Tom Cargill – Addison Wesley 1992 – ISBN: 0-201-56365-7
Corrupt politicians make the other ten percent look bad.
Henry Kissinger
Software Freethinker 
