Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Blog Individuel

LCC 176 - Le paradoxe de la fondation

Antonio, Arnaud, Vincent et Emmanuel commentent les informations de l’étĂ©: diversitĂ©, java dans un container, Java EE dans une fondation, les licences Facebook vs la fondation Apache et plus.

Enregistré le 1 septembre 2017

TĂ©lĂ©chargement de l’épisode LesCastCodeurs-Episode–176.mp3

Comment faire un crowdcasting

News

Les Ă©pisodes des cast codeurs en licence Creative Commons by-nc-nd

Langages

Java Still Number One, But What’s Taking Over? Le guide Bash ultime Ceylon rejoint Eclipse

Server JRE Garbage Collecteur G1 et comment le maitriser la bĂȘte dans tes microservices Java vs Docker: comment configurer sa JVM (Java SE support for Docker CPU and memory limits)

Les principaux paradigmes de programmation Excel est un Nonmonotonic dataflow programming :)

LĂ©gal

Facebook et sa licence BSD + brevet (react.js et RockDB):

Middleware

Java EE dans une fondation ? Bean Validation approuvé Java EE 8 approuvé aussi

Web

Bootstrap passe en béta

Loi, société et organisation

France: un pays de gros lourds Elles inventent un co-fondateur homme pour leur start-up, et c’est « le jour et la nuit »

Cefcys L’épisode de NoLimitSecu sur le Cefcys

Google et le mémo sur la chambre a echo de Google:

How to Raise a Feminist Son

Outils de l’épisode

Un Chromebook pour coder Site Reliability Engineering book

Conférences

JUGSummerCamp 15 septembre devops REX le 2 octobre Ă  Paris DevFest Nantes les 19 & 20 Octobre - Inscriptions Scala.io le 2 et 3 novembre Ă  Lyon - Inscriptions Devoxx Belgique du 6 au 10 novembre - Inscriptions BDX.io 10 novembre Devoxx Maroc 14–16 novembre Codeurs en Seine Ă  Rouen le 23 novembre 7Ăšme Ă©dition de SoftShake - GenĂšve (seulement 3h de Paris en train !) le CfP est ouvert 3eme Ă©dition du Paris OpenSource Summit les 6 & 7 DĂ©cembre (CfP ouvert jusqu’au 15 septembre) Snowcamp 2018 du 24 au 27 janvier ; le CFP est ouvert

Nous contacter

Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

LCC 175 - Interview sur la build avec CĂ©dric Champeau et Arnaud HĂ©ritier - partie 2

Guillaume, Cédric et Arnaud se retrouvent autour du micro pour parler pendant une session marathon de 3h30 du build, de Maven et de Gradle. Dans cette deuxiÚme partie, on y discute tests puis on aborde des questions spécifiques à chaque outil. On aborde enfin le dilemme: migrer ou ne pas migrer, telle est la question. Le tout basé sur les questions posées sur la mailing list des cast codeurs : merci à vous !

Enregistré le 19 juillet 2017

TĂ©lĂ©chargement de l’épisode LesCastCodeurs-Episode–175.mp3

Interview

 

Ta vie ton Ɠuvre

CĂ©dric Champeau Gradle Inc. Arnaud HĂ©ritier Cloudbees

Gradle Maven

Les tests

Gradle / Maven: Quelle est la philosophie officielle des deux outils pour la gestion des tests au delĂ  des tests unitaires (une fois les diffĂ©rents modules assemblĂ©s et dĂ©ployĂ©s) ? Dans des projets maven par exemple, je vois des fois des modules dĂ©diĂ©s, en scope test ou scope runtime et lancĂ©s Ă  la main, d’autres fois des projets indĂ©pendants. Chaque Ă©quipe a plus ou moins sa propre façon de gĂ©rer la chose mais rien n’a l’air vraiment normalisĂ© (ou du moins partagĂ© par la communautĂ©).

Gradle / Maven: Quels sont les ‘best practices’ pour faire du ‘test and watch’ (genre infinitest) avec maven et gradle ?

Les intégrations

Gradle: Pourquoi je ne peux pas faire de Run Tests sur un projet en Gradle dans IntelliJ alors qu’avec Maven je peux ? Gradle / Maven: Pour les deux, qu’en est il de l’intĂ©gration dans les diffĂ©rents IDE ? J’ai Ă©tĂ© agrĂ©ablement surpris par l’intĂ©gration de Gradle dans Netbeans, mais je n’ai pas beaucoup jouĂ© avec. Gradle / Maven: “Quid de l’intĂ©gration dans mon IDE prĂ©fĂ©rĂ© ?” Gradle / Maven: “Quid de l’intĂ©gration dans mon continuous build prĂ©fĂ©re ?”

Gradle en profondeur

Gradle: Y’a moyen de voir en Gradle à quel test je suis rendu ?

Gradlew/mvnw
  • Gradle: Pourquoi mvnw et gradlew ne downloadent par leurs jars au lieu de nous forcer Ă  les mettre dans .mvn et gradle ?
  • Gradle: Pour Gradle, vous ne trouvez pas affreux ces fichiers “gradlew” et “gradlew.bat” Ă  la racine de chaque projet dans github ?
Scripting vs XML
  • Gradle: Est-il prevu de pouvoir avoir un fichier build.gradle a chaque niveau de la hierarchie de tes modules au lieu d’avoir besoin de decrire manuellement tous les paths dans un fichier settings.gradle ? C’est un point que j’ai trouvĂ© penible (par ex https://github.com/xwiki/xwiki-commons/blob/master/settings.gradle et lĂ  je ne liste que qq modules - en pratique il y en a des centaines ds le build xwiki).
  • Gradle: Est-ce que Gradle travaille a essayer d’homogĂ©nĂ©iser encore plus les builds Gradle ? Qd j’ai essayĂ© de convertir le build Maven de XWiki en Gradle, j’ai lu la doc puis j’ai regarde 4–5 builds differents en gradle pour voir les bonnes practices. Et la j’ai ete embete car chacun avait des pratiques un peu differentes. Au debut j’etais meme paumĂ© et puis apres qq heures de recherches j’ai commencĂ© Ă  identifier des patterns communs mais qd meme avec pas mal de variations. Du coup je n’ai pas su trouver facilement les best practices et j’ai du me les faire et en consequence le build Gradle XWiki est lui aussi encore un peu different des autres probablement. Qu’est-il prevu sur le sujet ? En gros comme simplifier encore plus l’onboarding Gradle ?
BOM

Gradle: Le BOM de maven est-il une invention du malin ? Et quel est son Ă©quivalent pour Gradle ?

Android

Gradle: Pourquoi l’intĂ©gration de ces outils dans Android Studio est-elle aussi pathĂ©tiquement mauvaise ? (je suis obligĂ© d’utiliser ce sous-outil, et j’ai mal Ă  mon gradle : je ne peux pas voir mes dĂ©pendances facilement, et l’intĂ©gration se rĂ©sume Ă  une lecture de la liste des tĂąches et Ă  leur lancement).

Maven en profondeur

Maven: Quand est-ce que le bogue Maven du shade plugin qui ne remplace pas le jar d’origine pas le jar shadĂ© sera corrigĂ©? (et que donc l’équipe Maven reviendra Ă  la raison) ? Maven: Pour revenir au cycle de vie de Maven, serait-il possible de configurer des cycles de vies (notion de descripteurs de cycles de vie). En gros, pouvoir dire que mon projet suit un cycle de vie Ă  3 phases qui sont “resource, compile, install” et qu’un autre avec X phases comme compile, “prepare, 
, install, deploy-maven-repository, deploy-env”) Maven: Pour Maven encore, il y avait il me semble un projet polyglot pour les descripteurs, qu’en est-il ? Pourrait on imaginer des descripteurs en yaml et/ou json ? Maven: y’a t’il beaucoup de boites qui dev leurs petits plugins Maven perso pour adapter Ă  leurs problĂ©matiques ?

Granularité / découpage de modules avec Maven

Maven: comment gĂ©rer les builds oĂč l’appli finale est la rĂ©sultante de nombreux multi-module Maven project, chacun dans un repo git perso avec leur version. Nous avons des problĂšmes pour gĂ©rer les Ă©volutions de versions de chacun de ces multi-modules et faire en sorte que les modules qui en dĂ©pendent se MAJ vers la nouvelle version. Les BOM Maven sont une piste mais c’est pas clair
 Maven: est-ce une bonne pratique de considĂ©rer comme absolue la rĂšgle selon laquelle tous les modules d’un multi-module Maven project doivent avoir le mĂȘme numĂ©ro de version ? Maven: est-ce bien une mauvaise pratique que de mettre dans le mĂȘme repo Git 2 multi-module Maven projects qui ne partagent pas le mĂȘme parent ? Maven: les devs familiers avec Maven n’ont ils pas trop tendance Ă  dĂ©couper leurs appli en modules Maven alors qu’ils pourraient se contenter des package Java ? Je me rend compte que c’est mon cas perso
 Maven: Pour des grosses applis, faites-vous plusieurs petits builds et un meta-build d’assemblage final agrĂ©geant les petits morceaux ? Ou alors faites-vous un bon gros build qui dure longtemps mais recompile/repackage tout ? Ou alors vous laissez-vous le choix en faisant en sorte de pouvoir faire les 2 (sur Jenkins)

Maven: “classpath too long”: c’est la rĂ©sultante du point prĂ©cĂ©dant. Nous commençons Ă  nous heurter Ă  des problĂšmes de “classpath too long” sous Windows pour des Proof of Concepts mixant de nombreux projets. Le point de non-retour est-il proche ? (Pour info, nous contournons temporairement le problĂšme en ayant utilisĂ© la commande mklink pour simlinker le repo Maven sur c:\repo et gagner quelques caractĂšres sur chaque dĂ©pendance
 oui, c’est tres moche) Maven: quid du paramĂ©trage du build ? Par exemple actuellement nous avons une phase de packaging assez gĂ©nĂ©rique qui prend en entrĂ©e un numĂ©ro de version de l’application Ă  packager. Merci Jenkins.

Migration

Migrer vers Gradle, mais pourquoi (pas) ? Et la valeur du build dans tout ça 
 Gradle: Pourquoi est-ce que depuis 3 ans, je vais voir une prez de CĂ©dric sur Gradle, et j’en ressors en me disant “Gradle, ça a l’air quand mĂȘme vachement bien”, et que l’annĂ©e qui suit, je retourne voir une prez de CĂ©dric l’annĂ©e suivante sans avoir rien changĂ© sur mes projets Java ? Gradle: Suis-je tellement fainĂ©ant dans mon petit confort de build Maven pour reposer sur mes acquis et ne pas switcher ? Je veux dire 
 Ă  chaque fois j’ai de bons arguments apportĂ©s par CĂ©dric pour migrer, et pourtant, le switch ne se fait finalement pas. Gradle / Maven: ConsidĂšre-t-on aujourd’hui le build comme accessoire sur un projet Java pour ne pas vouloir engager un investissement de migration ? (je parle beaucoup de mon cas perso ici, mais j’ai l’impression qu’il n’est pas si isolĂ© que ça) Ou au contraire, est-ce tellement critique et relativement assez peu agile qu’on a trop peur d’en changer? Si on reprend le cas de Ant vs Maven, pas mal de gens ont traine a migrer, c’etait trop risque, les bonnes pratiques etaient encore peu connues, tout le monde avait peur de crasher son projet a cause de ca
 Personne ne veut essuyer les platres d’une “nouvelle” techno de build avec son projet. Gradle: Peut-etre Gradle en est-il encore la et a du mal a passer le cap des Early-Adopters (ceci dit, avec Android et son armee de developpeurs d’apps ca devrait changer vite si c’est le cas; tant qu’Android l’infidele decide de rester sur Gradle :P Gradle: Et enfin, LE point-cle: est-ce que la migration de Maven a Gradle amene une valeur ajoutee suffisante pour justifier l’effort et le risque? J’ai pas l’impression de lire beaucoup de retour d’experience de projets qui disent avoir gagne drastiquement en productivite en en qualite grace a une migration Maven->Gradle. Gradle / Maven: “je dĂ©marre un projet, Gradle ou Maven ?”

Conclusion

Gradle / Maven: les devs et le build: gĂ©nĂ©ralement, la grande majoritĂ© des devs ne s’y intĂ©ressent pas. A titre perso, je trouve ça fondamental, si le build est mal fait, ça handicap tout le projet sans que les gens ne s’en aperçoivent malgrĂ© les effets nĂ©gatifs, ils ne voient pas comment faire autrement => est-ce un ressenti que vous avez ?

Nous contacter

Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

LCC 174 - Interview sur la build avec CĂ©dric Champeau et Arnaud HĂ©ritier - partie 1

Guillaume, Cédric et Arnaud se retrouvent autour du micro pour parler pendant une session marathon de 3h30 du build, de Maven et de Gradle. A premiÚre partie pose les bases: introduction, java 9, performance, gestion de dépendances, cycle de vie

Enregistré le 18 juillet 2017

TĂ©lĂ©chargement de l’épisode LesCastCodeurs-Episode–174.mp3

Interview Ta vie ton Ɠuvre

CĂ©dric Champeau Gradle Inc. Arnaud HĂ©ritier Cloudbees

Liens généraux

Gradle Gradle Enterprise Maven

Guide modules Java 9 :

Liens Gradle

Maven vs Gradle (features) Maven vs Gradle (performance) Migrer vers Gradle Nebula plugins (Netflix) Plugin Go (gogradle) Spring Dependency Management Builds composites Build Cache

DĂ©finition et histoires

Ant

Pour s’échauffer, bon alors, c’est qui le plus fort Gradle ou Maven ? Est-ce que Gradle et Maven ont de la couleur dans la console ? Gradle / Maven: un pitch de 30 secs max pour chacun pour me faire faire mon choix

Support de Java 9

Gradle / Maven: Quand est-ce qu’ils vont supporter Java 9? Et la compilation multi-modules:

Gradle / Maven: Avez-vous eu de l’aide d’Oracle pour faire marcher Java 9? Gradle / Maven: Qu’est-ce que n’est pas prĂȘt pour Java 9?

La performance

C’est quoi le build cache de Gradle ? C’est gratuit ou c’est que dans la version payante ? Parle nous un peu plus de Gradle Enterprise, il y a quoi dedans ? Gradle Entreprise

J’ai fumĂ© la moquette

Quid de l’intĂ©gration avec jshell : je veux Ă©crire mon script de build en Java pas en Groovy (dĂ©solĂ©) ou en Kotlin (dĂ©solĂ©), et surtout que cela soit un fucking REPL (RĂ©mi Forax)

La totale depuis la ML Les projets

Maven, le projet Maven: Pour Maven, qui tient les rĂȘnes du projet ? Maven: La derniĂšre version de Maven est rĂ©cente, avec quelque bugfix (il semble
) La prĂ©cĂ©dente version date de fin 2015 : Maven meurt il Ă  petit feu ? Maven: Qu’est-ce qui fait que Maven n’évolue que trĂšs trĂšs trĂšs peu ? En particulier en terme de performance. Il est mort le projet ou quoi ? Maven: Qui paye le hosting de Maven Central ?

Gradle, le projet, Gradle.inc, l’entreprise Gradle: Gradle Inc propose des guides, des outils pour entreprise : Gradle veut devenir l’outil de build de rĂ©fĂ©rence en entreprise ? Gradle: Groovy va rester le langage principale des scripts Gradle (et Kotlin une alternative) ? Va cohabiter avec Kotlin ? va se voir remplacer par Kotlin ? Gradle: Les derniĂšres versions de Gradle se focalisent beaucoup sur les performances de build. Vers quoi l’outil va s’orienter par la suite ? Gradle: Gradle peut builder des projets en C, des projets Java, Android
. Il y aura un focus sur un Ă©cosystĂšme en particulier ou Gradle va continuer Ă  essayer de tout builder, quitte Ă  se disperser ? Gradle: Quelle est la proportion de projet utilisant Gradle pour construire des projets autres que des projets Java/Android ? Gradle: Gradle est indirectement poussĂ© par Google car utilisĂ© pour construire les applications Android. Gradle est Ă©galement utilisĂ© par Linkedin. Comment ces acteurs influent sur Gradle en terme de fonctionnalitĂ© ?

Et les autres (outils de builds)

Gradle / Maven: Ou en sont les autres, les javascripteurs ? sont-ils toujours Ă  rĂ©inventer x fois la roue ? Ou ont-ils des outils dont Gradle et Maven pourrait s’inspirer ? Gradle / Maven: Qu’est-ce qui a bien pu pousser les javascripteurs Ă  se dire qu’ils pourraient faire un outil intelligent quand ils semblent dĂ©pourvus du moindre bon sens ? Gradle / Maven: Il serait aussi sympa de comparer ces outils a ce qui se fait dans d’autres silos techniques (genre JS avec npm ou autre, C# avec dotnet et NuGet
), voir ce qui est mieux ou moins bien ailleurs. Gradle / Maven: Comment faire du build polyglotte, par exemple avec un mixe de Scala, Kotlin, Groovy, Java, et des sous projets Web (angular cli, webpack, gulp, 
) ? Gradle / Maven: Pourquoi les outils de build apparaissent aussi facilement que les champignons en automne ? Gradle / Maven: Qu’est-ce qui a fait le succĂšs de maven et gradle ? (aussi bien techniquement que d’un point de vue marketing)

La gestion des dépendances

Gradle / Maven: une question plus fondamentale sur gestion de deps vs build : Ă  un moment, dans le monde JS, il y avait une sĂ©paration assez nette entre gestion de dĂ©pendance (avec Bower ou npm je crois) et un outil de build/packaging (genre Gulp il me semble) et des fichiers de conf distincts; maintenant il semble que la mode n’ait pas pris et que npm rĂšgne en maitre et mĂ©lange les 2 sujets dans une meme conf. Est-ce que les experts de build Java pourraient partager leur avis sur la question: pourquoi on mĂ©lange gestion de dĂ©pendances et gestion de build ? Est-ce que c’est vraiment un choix de design ou juste que c’est pragmatiquement suffisant et plus efficace? Gradle / Maven: comment les outils de build permettent de gĂ©rer les dĂ©pendances non-Java ? Tant qu’on reste dans du Java, c’est simple, mais dĂ©s que l’on sort un peu de lĂ  ça se complique (nous on a du natif Windows/Linux, j’imagine que pour les devs Android c’est encore plus compliquĂ©). Peut t’il y avoir des interactions avec des repository non Maven-compliant ? On entend beaucoup parler de Conan pour les artefacts C/C++ ces temps-ci
 Que permet Gradle sur le sujet ? Pouvez-vous nous briefer sur le monde Android qui doit avoir ces problĂ©matiques ?

Le cycle de vie de l’application

Gradle / Maven: Sujet qui pourrait ĂȘtre intĂ©ressant Ă  dĂ©battre : comment est-ce que les deux outils abordent la livraison “en production” ? OĂč est-ce qu’ils s’arrĂȘtent dans leur philosophie (on peut assez facilement imaginer un DSL gradle par exemple pour gĂ©rer les dĂ©ploiements) ? En particulier, quid des environnements oĂč les plateformes de production n’ont pas accĂšs Ă  internet (et donc pas accĂšs aux dĂ©pĂŽts officiels et pas de miroir disponible/accessible, j’ai vu ça chez les opĂ©rateurs tĂ©lĂ©com). La solution mise en place ici, c’est livraison sous forme d’iso/de cd sur lesquels il y a toutes les dĂ©pendances, et cette iso est montĂ©e comme un repo Ă  partir duquel on installe la solution. Et Ă  partir de lĂ , viennent d’autres problĂšmes d’ordre juridiques : comment est pensĂ©e la gestion des licences, en particulier en ce qui concerne les dĂ©pendances transitives ? Gradle / Maven: Un peu liĂ© : quelles diffĂ©rences dans les deux outils pour la construction d’applis orientĂ©es serveur vs. appli orientĂ©es client ?

Nous contacter

Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

 

Catégories: Blog Individuel

JS et Programmation Fonctionnelle - Part 1

Taverne d'Arma - Programmation - mar, 09/13/2016 - 11:20

Je vais me lancer sur une série d'articles concernant la programmation fonctionnelle, appliquer au monde JS. L'objectif pour moi est de préparer, à terme, une présentation sur le sujet. Aujourd'hui, je vais donc commencer par les bases : c'est quoi au juste la programmation fonctionnelle.

Du rĂŽle de la fonction

Fonctionnelle comme fonction. Mais la fonction dont on parle ici correspond-elle au mots-clés 'function' de notre langage ? Presque, mais pas tout à fait. En fonctionnel, une fonction est un élément prévisible qui prend des paramÚtres entrants et qui renvoies une nouvelle valeur. Cela implique que :

  • Les paramĂštres entrants ne sont pas modifiĂ©s
  • Le retour de la fonction est un nouvel objet ou une nouvelle valeur
  • Tout appel avec des paramĂštres identiques renvoi le mĂȘme rĂ©sultat

Les avantages de ce type de fonction sont multiples :

  • Meilleure testabilitĂ© : elles ne dĂ©pendent pas d'un Ă©tat.
  • Meilleure reproductibilitĂ© : si l'on trouve un bug, il suffit de rappeler la fonction avec les mĂȘmes paramĂštres pour obtenir les mĂȘmes rĂ©sultats.
  • Meilleurs "scalabilitĂ©" : on ne mute pas les objets, il n'y aura donc pas de problĂšme de concurrences sur des threads diffĂ©rents.
De l'immutabilité

Je viens de glisser le point dans le dernier avantage, mais l'un des grands principes de la programmation fonctionnelle est de tirer Ă  maximum parti d'objet immutable : c'est-Ă -dire un objet qui ne peut pas ĂȘtre modifiĂ©. La consĂ©quence, c'est qu'Ă  chaque fois que l'on veut modifier un objet, nous allons crĂ©er une nouvelle instance complĂštement indĂ©pendant de l'objet.

Encore une fois les avantages sont multiples :

  • La scalabilitĂ©, comme abordĂ© plus haut.
  • La limitation des effets de bord : vu que l'on ne modifie pas un objet, l'on ne risque pas de modifier par inadvertance un objet qui aurait Ă©tĂ© transmis Ă  d'autres parties de l'application.

Bien entendu, la plupart des applications ne peuvent pas ĂȘtre 100% immutable : l'idĂ©e est d'isoler au maximum les endroits oĂč un Ă©tat est mĂ©morisĂ© et de ne faire ces mutations que de maniĂšres conscientes et complĂštement volontaire.

De la programmation déclarative

La programmation impérative met en avant le "comment" : ajoute 1 au compteur, passe à l'élément suivant, modifie tel caractÚre, ... L'objectif de la programmation déclarative est de s'attacher au "quoi". Pour s'approcher au maximum de ce style, la programmation fonctionnelle, mais en avant non pas les données, mais les traitements : le but est de décrire des chaßnes de traitement qui vont s'appliquer aux données.

Prenons l'exemple trÚs simple d'une somme. En impératif :

function sum(vals) {
  var total = 0;
  for(var i = 0; i < vals.length; i++) {
    total = total + vals[i];
  }
  return sum;
}

Et en fonctionnelle :

function sum(vals) {
  return vals.reduce(add);

  function add(e1, e2) {
    return e1 + e2;
  }
}

Le code est équivalent, mais dans le second cas, il décrit l'intention : réduire la liste en additionnant ses éléments.

Pour résumé

La programmation fonctionnelle a pour objectif :

  • d'amĂ©liorer la lisibilitĂ© du code (style impĂ©ratif).
  • de faire du code plus facile Ă  tester et Ă  debugger (pas d'effet de bord).
  • d'ĂȘtre plus rĂ©sistant aux concurrences.

Par contre, l'immutabilité est une contrainte qui demande une certaine discipline à l'usage.

Fonctionnelle versus POO

Souvent, ces deux paradigmes de programmations sont mis en oppositions. Faut-il faire de la POO, ou faut-il faire du fonctionnelle ? Aujourd'hui, je pense sincĂšrement qu'il faut faire les deux :

  • La POO permet de bien structurer son application et d'y faciliter la navigation
  • Le fonctionnelle permet de rendre son code plus lisible

Utiliser les deux, c'est avoir accĂšs aux forces de chacun. Pourquoi se priver ?

Catégories: Blog Individuel

Specification by example et documentation vivante

Specification by example & documentation vivanteEn 2015,  avec Brice nous avons prĂ©sentĂ© une session Ă  Agile Grenoble intitulĂ©e “Specification by example : venez assister Ă  la naissance d’une documentation vivante”. Depuis nous avons prĂ©sentĂ© Ă  plusieurs reprises cette session qui est Ă  chaque fois accueillie avec enthousiasme. Elle se compose en 3 parties : prĂ©sentation de la thĂ©orie, un exemple concret interactif et un retour d’expĂ©rience. La collaboration Ă©tant ag15_logo_speaker_blancau cƓur de ce processus, cette mĂ©thode implique tous les intervenants d’un projet : analystes mĂ©tier, dĂ©veloppeurs, testeurs et managers.

Des exemples utiles à différentes phases du projet

Comme l’explique le livre de Gojko Adzic, travailler avec des exemples est intĂ©ressant lors des diffĂ©rentes phases du projet :

  • ComprĂ©hension partagĂ©e : en amont du dĂ©veloppement, travailler avec des exemples permet de lever des ambiguĂŻtĂ©s et de s’assurer que l’on parle bien des mĂȘmes choses. De plus si tous les intervenants sont impliquĂ©s Ă  cette phase, cela joue aussi sur la dynamique d’équipe.
  • Acceptance test : dĂšs le dĂ©but du dĂ©veloppement, l’exemple est entrĂ© dans l’outil d’automatisation. Il devient un « acceptance test » de la double boucle TDD. Il prend alors un  rĂŽle de pense bĂȘte : il reste rouge tout le long du dĂ©veloppement et passe vert lorsque le logiciel satisfait toutes les exigences.
  • Regression test: une fois vert l’exemple change encore d’objectif. Il sert maintenant Ă  dĂ©tecter les rĂ©gressions. Un bon exemple nous indique dans quelle fonctionnalitĂ© s’est glissĂ© le bug.
  • Documentation vivante: un autre aspect est maintenant de jouer un rĂŽle  documentaire de l’application. Cette documentation Ă©volue en mĂȘme temps que le logiciel et est vĂ©rifiĂ©e en continu.  Il arrive parfois que l’ajout d’une fonctionnalitĂ© rende obsolĂšte certaines contraintes qui avaient Ă©tĂ© ajoutĂ©es prĂ©cĂ©demment. En passant rouge, les exemples nous indiquent l’impact du changement.
OĂč se trouve la poule aux Ɠufs d’or ?

8218-FX-6-0-13-6-9-0-90-5-5-95-95Cette mĂ©thode n’est pas magique. Son implĂ©mentation demande des efforts et un changement culturel. Aussi j’insiste rĂ©guliĂšrement sur le fait que cette mĂ©thode apporte Ă©normĂ©ment de valeur sur l’Ă©tape de comprĂ©hension partagĂ©e et de documentation vivante.

A mon sens, il n’y a pas d’autres mĂ©thodes qui challengent autant l’expression du besoin et la documentation. Aussi comme trop d’information tue l’information, quand je suis face Ă  des questions sur l’exhaustivitĂ© oĂč la qualitĂ© des exemples, j’essaye d’identifier Ă  quelle phase profite l’exemple. Si j’investis sur la documentation, l’exemple a certainement de la valeur. Par contre si je rajoute des exemples uniquement pour me protĂ©ger de la rĂ©gression, j’essaye de voir si je ne peux pas les rajouter dans d’autres tests (robustesse, intĂ©gration, etc
)

La phase de comprĂ©hension partagĂ©e porte en elle mĂȘme beaucoup de valeur. A cette Ă©tape c’est le besoin qui est challengĂ©. Les « product owners » doivent illustrer le besoin par des exemples concrets. En ayant des reprĂ©sentants de l’équipe mĂ©tier, dĂ©veloppement et test, l’interaction des diffĂ©rents points de vue va enrichir l’idĂ©e initiale.

Dans l’exemple pratique de la prĂ©sentation, nous tentons d’illustrer l’impact du changement en ajoutant une rĂšgle qui est incohĂ©rente avec une autre. Sur cette simulation cela semble simpliste, mais nous avons rĂ©cemment vĂ©cu cette illustration :

Nous voulions lĂ©gĂšrement modifier un calcul affichĂ© Ă  l’écran. Il Ă©tait difficile, tant le systĂšme Ă©tait complexe, de dĂ©tecter que cela rendait obsolĂšte une autre fonctionnalitĂ©.

Pour moi l’efficacitĂ© de cette mĂ©thode est Ă  rapprocher du principe « Mutal Benefit » de eXtrem Programming : une mĂȘme activitĂ© (la rĂ©daction d’un exemple) apporte de la valeur dĂšs l’instant prĂ©sent. Le principe est d’Ă©crire un exemple parce que cela est utile maintenant pour dĂ©finir ce que doit faire l’application. Pas uniquement parce qu’un jour il va potentiellement servir. En automatisant la vĂ©rification de l’exemple on rĂ©cupĂšre les fruits de cet investissement tout au long de la vie du projet.

Emblem-question.svgLes questions qui reviennent souvent

Lors de nos diverses présentations certaines questions sont récurrentes. En voici quelques-unes :

  • Vous parlez de pyramide des tests, n’ĂȘtes-vous pas en train de faire une pyramide inversĂ©s ?
    • Effectivement, le nombre d’exemples augmente avec le temps et le besoin de documentation. Cependant ce n’est qu’une partie des tests. Nous nous en servons comme test d’acceptance et de nombreux tests unitaires sont Ă©crits en mĂȘme temps que le code. Notez que cette documentation est trĂšs utile pour les testeurs pendant les recettes lors des phases de livraison.
  • Est-ce que l’approche est similaire Ă  celle du TDD ? C’est-Ă -dire que si on n’arrive pas Ă  tester c’est qu’il y a un problĂšme de design ?
    • Par le fait d’automatiser des exemples, il y a forcĂ©ment une influence sur le design. Cependant ce n’est pas son objectif, le besoin est beaucoup plus chahutĂ© par cette approche. Si le besoin n’est pas trĂšs clair, on a une opportunitĂ© de s’en rendre compte dĂšs la phase de comprĂ©hension partagĂ©e. A ce stade le changement coĂ»te moins cher.
  • A propos de l’impact au changement, n’y a-t-il pas moyen de l’identifier avant le dĂ©veloppement ?
    • Effectivement si une incohĂ©rence n’a pas Ă©tĂ© levĂ©e lors de la 1Ăšre phase, ce n’est que lorsque le code va ĂȘtre modifiĂ© que l’on va savoir quel est l’impact du changement. Cependant comme cette incohĂ©rence est connue, cela permet de statuer et de mettre Ă  jour la documentation. On a alors une nouvelle source de vĂ©ritĂ© sur ce que fait l’application (l’autre Ă©tant le code).
  • Quel est le coĂ»t pour la mise en place de cette mĂ©thode ?
    • Ce n’est pas facile de rĂ©pondre Ă  cette question quantitativement. Cela dĂ©pend de l’organisation mise en place. Sur notre projet, les dĂ©veloppeurs ont pris en charge une bonne partie (~20-30% temps de dĂ©veloppement). Cependant tout le monde s’accorde pour dire que cela vaut le coup : l’application a peu de bug, il y a moins d’incomprĂ©hension. C’est aussi l’unique documentation utilisĂ©e par le mĂ©tier, les dĂ©veloppeurs et les testeurs.

J’espĂšre vous avoir donnĂ© envie de tenter l’aventure Specification by example. La prĂ©sentation est disponible sous SlideShare et le code sous GitHub.

The post Specification by example et documentation vivante appeared first on Agilité, Architecture, C++ "in the mix".

Catégories: Blog Individuel

Ouvrir avec l’explorateur vos bibliothùques #SharePoint et #OneDrive


Le blog de Patrick Guimonet - sam, 09/10/2016 - 16:47
C’est l’une des demandes les plus frĂ©quentes des utilisateurs, comment manipuler les fichiers stockĂ©s dans SharePoint et OneDrive dans l’explorateur de Windows. En effet malgrĂ© des amĂ©liorations significatives dans l’interface, ...
Catégories: Blog Individuel

Contenu Festival #SharePoint et #Office 365 de mai 2016 Ă  Paris #SPSParis

Le blog de Patrick Guimonet - sam, 09/10/2016 - 15:44
Merci Ă  tous pour votre participation au Festival #SharePoint et #Office 365 de mai 2016 Ă  Paris ! En effet, c’est grĂące Ă  vous que ces Ă©vĂšnements et en particulier le SharePoint Saturday Paris ont Ă©tĂ© un trĂšs grand succĂšs ! Si ce...
Catégories: Blog Individuel

Productivité personelle - Mon organisation

Taverne d'Arma - Programmation - sam, 09/03/2016 - 09:10

J’ai rĂ©cemment effectuĂ© une prĂ©sentation au boulot concernant la productivitĂ© personnelle. Le but Ă©tait de parler des grands principes partagĂ©s par diffĂ©rentes mĂ©thodologies (Personal Kanban, GTD, ...). Je comptais partager les slides ici mais, en eux-mĂȘme, ils n’ont guĂšre d'intĂ©rĂȘt. A la place je me suis dit que parler de ma propre organisation serait probablement plus intĂ©ressant.

Personal Kanban

Vous avez surement dĂ©jĂ  aperçu ses tableaux de post-it a colonne multiple, contenant en gĂ©nĂ©ral au minimum “Todo, En-Cours, Done”. Personal Kanban est une mĂ©thode qui se base dessus et dont les grands principes sont :

  • Toutes nos actions sont des tĂąches Ă  mettre dans ce tableau.
  • Une tĂąche va toujours de l’avant, elle ne doit pas reculer.
  • Les colonnes correspondent au “en-cours” sont limitĂ© au nombre de tĂąche qu’elles peuvent contenir. Quand l’on arrive au plafond, il faut s’arranger pour terminer des tĂąches.
  • On choisit la tĂąche que l’on effectue en fonction du contexte (temps dispo, niveau de concentration, lieu, 
) et non pas seulement en fonction de la prioritĂ©.

Bref, on retrouve le principe de base des mĂ©thodes d’organisations, le recensement des tĂąches, et on y adjoint un mĂ©canisme nous forçant Ă  terminĂ© les tĂąches commencĂ©s plutĂŽt que d’en prendre une nouvelle.

Au quotidien j’utilise :

  • Des post-it papier, si possible, pour le boulot
  • Un outil informatique (Trello), pour le perso (histoire d’y avoir accĂšs de partout)

Quel que soit l’outil, le point important est de crĂ©er une tĂąche “rapidement” avec un libellĂ©, et potentiellement une “catĂ©gorie” (un projet par exemple).

C’est lĂ©ger et souple d’utilisation, bref, c’est une mĂ©thode qui me correspond bien. J’ai tellement fait rentrer le mono-tasking dans mes habitudes qu’en gĂ©nĂ©ral mon en-cours n’excĂšde pas une tĂąche.

Pomodoro

En complĂ©ment du Kanban, je pratique de temps Ă  autres la mĂ©thode Pomodoro. C’est en quelque sort mon “mode de productivitĂ©â€ quand j’ai besoin d’ĂȘtre concentrĂ©, d’aller vite, et d’abattre beaucoup de travail. Cette mĂ©thode est Ă  mon sens trĂšs efficace et prĂ©sente quelques avantages :

  • On se rend compte du temps qui passe.
  • On se force Ă  des crĂ©neaux ininterrompu de concentration.
  • Mais en se prĂ©voyant les breaks nĂ©cessaire Ă  ne pas saturer.

Revers de la mĂ©daille : elle demande une discipline que j’ai du mal Ă  appliquer en permanence. C’est pour cela que je la pratique “à la demande” uniquement.

Autres petites pratiques

En dehors de ces mĂ©thodologies, il y a aussi quelques principes que j’applique pour booster ma productivitĂ© :

  • Pas de notification visuel, ou trĂšs peu. Ma boĂźte reçoit ses mails discrĂštement et je les consulte quand j’en ai envie, et non dĂšs qu’ils arrivent. J’évite aussi de laisser ouvert les rĂ©seaux sociaux et autres petites pollutions de ce genre. Je prĂ©fĂšre me rĂ©server des moments pour aller les consulter.
  • Je connais mes moments “productifs” : ces pĂ©riodes de la journĂ©es oĂč vous abattez deux fois plus de boulot qu’à tout autre moment. Personnellement c’est entre 7h et 11h que je suis le efficaces. Entre 11h et midi, c’est la catastrophe. Je regagne un peu de productivitĂ© en dĂ©but d’aprĂšs midi et, fin d’aprĂšs midi, je commence Ă  saturer et Ă  avoir du mal. Du coup je m’assure de faire les tĂąches difficile dans ces crĂ©neaux lĂ .
  • Je profite de mes temps de transport pour faire ma veille. DĂšs qu’un article intĂ©ressant arrivent dans mon flux RSS, je l’envoi sur pocket pour que ma liseuse le rĂ©cupĂšre. Cela m’évite de lire Ă  un moment oĂč je pourrais faire quelque chose de plus profitable. Cerise sur gĂąteau, je sais aussi que je lit mieux sur ma liseuse que sur Ă©cran.
Catégories: Blog Individuel

Code fonctionnel en PHP

Taverne d'Arma - Programmation - lun, 08/29/2016 - 12:38

Ah le php... Une technologie que je n'apprécie guÚre pour des tas de bonnes et mauvaises raisons. Mais il faut bien lui reconnaßtre une qualité : il est trÚs facile de lui trouver un hébergement.

Mais lĂ  n'est pas le sujet du jour ! Un nouveau projet s'ouvre Ă  moi et, bien qu'il soit en php, je n'ai pas envie de mettre de cotĂ© mon centre d'interĂȘt du moment : la programmation fonctionnelle. Me voilĂ  donc Ă  chercher comment la mettre en oeuvre en php.

PHP et Closure.

La base de la programmation fonctionnelle, c'est de manipuler des fonctions. Et l'un des outils trĂšs utile autour des fonctions, ce sont les Closures : des fonctions qui "embarque" avec elle des variables en plus de leur paramĂštre entrant.

En php, la closure est un peu particuliÚre car il faut expliciter les variables qui sont utilisable à l'intérieur de la fonction. Elle se déclare ainsi :

function ($param) use ($varEmbarque1, $varEmbarque2) {
    // Mon corps de méthode
    // $varEmbarque1 et $varEmbarque2 sont accessible
}

Un exemple d'utilisation ?

public function raise($event) {
    Arrays::each($this->listeners, function($fn) use($event) {
        call_user_func($fn, $event);
    });
}

Je reviendrai plutard sur le Arrays::each. Ce qui est important ici c'est que each appelle la méthode pour chaque élement du table. La valeur de l'élement est alors donné en paramÚtre. Ici ma fonction a besoin de deux élements pour fonctionner : une callback contenue dans le tableau, et un évÚnement à transmettre. L'un est passé en paramÚtre, l'autre est passé via la closure.

Et si comme moi vous n'aimez pas spécialement les fonctions anonymes (question de lisibilité), vous pouvez appliquer le pattern builder :

public function raise($event) {
    Arrays:each($this->listeners, $this->emit(event));
}

// (DomainEvent) -> (Fn) -> ()
private function emit($event) {
    return function($fn) use($event) {
        call_user_func($fn, $event);
    };
}
Manipulations de collections et plus si affinité.

map, filter, ... Ces petites fonctions de manipulations de collections sont le premier outil issue du fonctionnel que j'ai utilisé. Je les trouve tellement confortable que je n'ai pas envie de m'en passer.

Malheureusement les fonctions fournies par php sont limitées (map, filter et reduce uniquement). En fouillant un peu sur internet, je suis tombé sur underscore.php, une librairie trÚs sympathique qui fournit le panel complet des fonctions de ce genre (all, any, find, ...).

Petit bonus, elle nous offre aussi des fonctions de manipulations de fonctions tels que compose, memoize, once et throttle qui peuvent s'avérer trÚs pratique.

Et enfin, les monades

Dernier outils du fonctionnel : les monades. Je ne les utilise pas encore tout à fait naturellement mais je reconnaßs ce qu'elles peuvent apporter. Cette fois-ci j'ai envie de les utiliser davantage et pour cela, j'ai trouvé la librairie php-functional.

Les monades, ce sont des outils trÚs utiles tels que Either qui présente deux "chemins" (réussite ou échec), avec deux types de retours différents, ou Maybe qui est une autre façon de gérer l'abscence de valeur.

Un exemple d'utilisation :

// (String, String) -> Either[FunctionalError, User]
protected function checkAuthentification($login, $password) {
    return $this->userRepository
        ->findByLogin($login)
        ->bind($this->checkPassword(Password::fromValue($password)));
}

$this->userRepository->findByLogin() est une fonction qui renvoi un Either. Bind permet d'appliquer à la valeur retourné une autre fonction qui renverra elle aussi un Either uniquement dans le cas Right (chemin de succÚs). La fonction donné à bind sera appellé avec la valeur en paramÚtre.

A l'intérieur de findByLogin, on va retrouvé deux retour possible :

\Monad\Either\Right::of($user);

ou

\Monad\Either\Left::of(new FunctionalError("Utilisateur inconnu"));

Dans un code classique, j'aurai utilisé un mécanisme d'exception qui aurait pas forcément été aussi lisible.

En sortie de checkAuthentification j'ai toujours une Either. L'appellant pourra donc faire quelque chose comme cela :

// (String, String) -> Either[FunctionalError, User]
public function exec($login, $password) {
    $user = $this->checkAuthentification($login, $password);
    $user->map($this->storeInSession())
         ->map($this->raiseUserConnected());
    return $user;
}

En cas de succĂšs de l'authentification, j'effectue deux fonctions :

  • Stockage en session
  • Lever d'un Ă©vĂšnement

Quand je veut extraire définitivement la valeur de la monade, je peut faire ceci :

$myEither->extract()

Je m'arrĂȘterais ici dans l'explication sur les monades : ils faudraient un article entier (voir plus) pour vraiment dĂ©montrer leurs valeurs.

Des commentaires Ă©tranges ?

Vous avez pu apercevoir au-dessus de mes fonctions des commentaires ayant cette forme :

// (String, String) -> Either[FunctionalError, User]

Ces commentaires sont uniquement présent à des fins de documentations. C'est une maniÚre de donner des indications sur les types utilisés sans passé par une phpDoc bien plus verbeuse : je trouve toujours les javadocs / phpdocs aussi useless...

Ces quelques indications me sont bien plus précieuses et sont suffisament légÚre pour que je garde la discipline de les rajouter à chaque fois.

Catégories: Blog Individuel

[Article extĂ©rieur] DĂ©ployer Let’s Encrypt sur Heroku et nom de domaine custom chez [OVH]

Mathieu Robin - ven, 08/26/2016 - 09:49

Salut à tous ! ça faisait un bail !

J’ai publiĂ© sur Medium (j’ai voulu essayer), un article nommĂ© « DĂ©ployer Let’s Encrypt sur Heroku et nom de domaine custom chez [OVH]« .

Je vous laisse tout le plaisir de le lire en cliquant sur le lien ci-dessus. Bonne lecture !

Flattr this!

Catégories: Blog Individuel

The Mostly Adequate Guide to FP

Taverne d'Arma - Programmation - jeu, 08/04/2016 - 07:19

En continuant mes recherches a propos de programmation fonctionnelle en javascript, je suis tombĂ© sur un ouvrage disponible gratuitement : The Mostly Adequate Guide to FP. Disponible en ebook ou pour une lecture «en ligne», ce livre d’environ 150 pages abordent les diffĂ©rents aspects de la programmation fonctionnelle de maniĂšre plutĂŽt didactique.

Au sommaire : currying, composition, monades et applicative. A mon sens les explications sont un peu moins facile Ă  apprĂ©hender que celle-prĂ©sente dans «Functional Programming in Javascript» mais elles sont tout de mĂȘme facile Ă  suivre.

Mention spĂ©ciale pour le chapitre sur la composition que je trouve vraiment trĂšs complet. Ici l’auteur nous prĂ©sente vraiment une autre maniĂšre de dĂ©veloppez et d’agencer nos fonctions. Les exemples donnĂ©s sont vraiment trĂšs parlant et illustre l’intĂ©rĂȘt de cette approche. Je pense notamment Ă  des dĂ©clarations comme celle-ci qui sont un exemple de concision :

var loudLastUpper = compose(exclaim, toUpperCase, head, reverse);

loudLastUpper(['jumpkick', 'roundhouse', 'uppercut']);
//=> 'UPPERCUT!'

AprĂšs la lecture de ces deux ouvrages, me voilĂ  complĂštement armĂ©e pour passer Ă  la pratique ! Et pour m’échauffer, j’ai suivi les exercices de NodeSchool sur le sujet ( «functional javascript» ). Ces exercices n’explore pas la composition ni les monades, mais le reste y passe.

Au passage pour ceux qui ne connaisse pas (et c’étais mon cas il y a quelques jours), NodeSchool est un site vraiment sympa bourrĂ© de «tutoriel» sous la forme d’exercice+corrigĂ©. Vraiment trĂšs sympa :)

Catégories: Blog Individuel

IaaR !

Être Agile - Thierry Cros - ven, 03/04/2016 - 20:06

etre-agile.png IaaR ! est un acronyme :

  • Intention
  • Attention
  • Action
  • RĂ©pĂ©tition.

C'est un "protocole" de transformation qui fait appel aux trois maĂźtrises de la voie toltĂšque (Attention, Transformation, Intention).

Intention

D'abord poser une intention.
Respecter ces trois recommandations :

  • Visualisation++ : faire appel Ă  l'imagination pour visualiser une scĂšne correspondant Ă  l'Ă©tat souhaitĂ© et atteint. Le "++" signifie que cette visualisation incorpore non seulement des images, Ă©galement des sons, des sensations... Bref fait appel Ă  plusieurs sens. Au-delĂ  de l'aspect sensoriel, cette visualisation crĂ©atrice possĂšde une dimension Ă©motionnelle : l'esquisse d'un lĂ©ger sourire pourrait apparaitre sur le visage pendant cette visualisation crĂ©atrice ;
  • 100% d'accord : autrement dit "ZĂ©ro doute". Du cĂŽtĂ© du pratiquant c'est comme si c'Ă©tait dĂ©jĂ  fait dans le monde de l'Intention et qu'il restait simplement Ă  rĂ©ifier - rendre rĂ©elle - cette visualisation ;
  • UC 10 : Universe Compliant level 10 se souvenir simplement que nous sommes dans un monde soumis Ă  diffĂ©rentes lois (lĂ©galitĂ© du pays, lois physiques...) et que la rĂ©alisation de l'intention s'inscrit dans ces lois. UC 10 signifie ainsi que le rĂ©sultat dĂ©pend aussi de ces lois.
Attention

Alors, Ă  quoi allons-nous prĂȘter attention afin que cette Intention se rĂ©alise ?
Notre perception de la réalité est-elle suffisamment... réaliste ?
Quels indicateurs, quel management visuel, que "sur-veiller"...

Action

Si ce cadre fonctionne grùce à la force de l'Intention, il reste que nous sommes acteurs de la réalisation. Quelles actions envisageons-nous ?

Répétition

Probablement un ingrédient "secret" de ce processus : selon le changement, il est vain d'imaginer qu'une habitude engrammée pendant des décennies va disparaßtre subitement. Il faudra donc répéter... Et répéter encore jusqu'au succÚs.
D'autant plus que ce processus itératif offre un espace - bien connu des Agilistes - à la fois de feedback (l'inspection des Scrumiens) et d'amélioration.

Magie !

Lorsque je présente IaaR ! en formation ou accompagnement, j'insiste sur le cÎté "magique" de cette pratique, fortement inspirée par la voie toltÚque telle qu'exprimée par Don Miguel Ruiz (IaaR est un acronyme que j'ai concocté à partir d'un protocole présenté par Don Miguel Ruiz).
Magique car elle fait appel à des "procédés psychologiques" peu ou pas connus généralement.
Magique car elle suppose un certain lĂącher-prise, une confiance dans ce pouvoir de l'Intention.

Pratiquer !

Je ne peux que vous engager Ă  pratiquer IaaR !.
Démarrez par une intention simple, qui puisse se concrétiser dans la journée par exemple, pour vous entraßner à cette pratique.
Et faites confiance dans le pouvoir de votre Intention !
Intention ou Foi ou Amour.

teo-compressee.jpg

ToltĂšque Agile

Catégories: Blog Individuel

Agile en 2016

Être Agile - Thierry Cros - mer, 03/02/2016 - 08:47

etre-agile.png L'histoire continue... Un nouveau billet, ma vision de l'agile en 2016. Entre mutations, sacrifices et heureuses surprises.
Mais... Que signifie agile aujourd'hui ? Entre un manifeste tout autant historique qu'abandonné, pertinent sur le fond et obsolÚte sur la forme... Nous trouvons autant de définition de l'agile qu'il y a d'Agilistes.

Agile : qu'es aco ?

Je tente une définition, sous forme de mindmap, de ce qu'est pour moi l'agile aujourd'hui.

agileMindmap.jpg

Ce triptyque décrit

  • le domaine d'application
  • l'essence de l'agile
  • son intention.
VICA

Une traduction de l'acronyme anglais VUCA. Si l'origine est finalement la prise de conscience de la complexité du développement logiciel, c'est bien de volatilité, d'ambiguïté... Que nous parlons aussi.
Et comme notre monde est de plus en plus complexe, l'agile devient d plus en plus pertinent.
Cela pose la question de la premiÚre valeur agile : les personnes et leurs interactions plus que les processus et les outils. Lorsque le systÚme est mieux maitrisé une approche qui priorise les "processus" redevient pertinente.

Empirique

L'image reprend les quatre axes qui me semblent essentiels dans une approche agile empirique. Grosso modo ce sont des principes de l'Extreme Programming.

Équilibres

AprÚs une quinzaine d'années de pratiques j'en arrive à me dire que la finalité de l'agile c'est l'équilibre.

  • Valeur et qualitĂ© : apporter de la valeur aux Utilisateurs, Ă  l'organisation, sans sacrifier la qualitĂ© interne (ou maintenabilitĂ©) dans une lucragilitĂ© dĂ©viante ;
  • responsabilitĂ© et bien-ĂȘtre : l'hĂ©donisme Ă©tait inscrit dans l'agile dĂšs le dĂ©but. Si certains parlent de "bonheur au travail' en ces temps de novlangue oĂč les mots perdent leur sens, je m'en tiens plutĂŽt au bien-ĂȘtre.



Et ToltĂšque Agile est mon nouveau site.

Agile en 2016 ?

Je constate sur le terrain plusieurs patterns qui reviennent réguliÚrement.
La qualitĂ© est bien souvent sacrifiĂ©e sur l'autel de la valeur ajoutĂ©e, elle-mĂȘme malmenĂ©e (voir plus loin). Il m'arrive plusieurs fois par an d'entendre un discours tel que "nous faisons de l'agile sur ce produit depuis plusieurs annĂ©es et nous avons de gros problĂšmes de qualitĂ©...".
De fait il s'agit bien souvent de Scrum et de sa vraie fausse bonne idée : la définition de fini.
Bien entendu, c'est une bonne idée... Lorsque ceux qui l'élaborent ont déjà une bonne notion de ce qu'est "fini" au sens professionnel du terme. Autrement dit, encore faut-il avoir conscience de la nécessité de code propre... Et de ce qu'est un code propre. Dieu merci, il existe des corpus tels que craftsmanship pour élever le niveau.

Valeur... Un glissement sémantique existe entre valeur et priorité. Trier un backlog par priorité, oui. Encore faut-il se poser la question de la qualité de la priorisation. Trop souvent, ce sont les classiques nécessités techniques et/ou fonctionnelles, les diminutions de risques... Qui dictent les priorités au détriment de la qualité.
Si en tant que Product Owner vous planifiez par story d'XP mais finalement avec une stratĂ©gie inchangĂ©e, ĂȘtes-vous vraiment agile ? Pour le moins, monitorez-vous la valeur mĂ©tier produite (et stockĂ©e...) Ă  chaque itĂ©ration ?

Versions frĂ©quentes... C'est une pratique emblĂ©matique de l'Extreme Programming, que l'on retrouve dans le premier principe agile. Or, le cĂ©lĂ©brissime 'produit partiel potentiel livrable" de Scrum est inconsĂ©quent. J'ai rencontrĂ© par exemple une Ă©quipe qui pratiquait Scrum tout en livrant une version par an... Scrum peut-ĂȘtre, agile certainement pas !

Valorisation des faiseurs... Si effectivement les équipes deviennent plus autonomes (voir toutefois la question du ScrumMaster), il reste que fondamentalement les commerciaux et autres managers sont généralement mieux payés et bénéficient de privilÚges (places de parking, voitures de fonction...) que n'ont pas les Faiseurs... It's a long way...

ScrumMaster omniprĂ©sent : sans ouvrir le dĂ©bat sur l'utlitĂ© d'un ScrumMaster, il faut quand mĂȘme se poser la question de sa pertinence dans une Ă©quipe agile (je ne parle pas de Scrum). Les DĂ©velippeurs ont-ils besoin d'un ScrumMaster ? Quand leur rĂ©ponse est oui, qui choisit la personne en charge de ce rĂŽle ? Au final, ce rĂŽle est-il compatible avec l'auto-organisation consubstantielle Ă  l'agile dans son cĂŽtĂ© systĂ©matique ?

Les Managers deviennent agiles : bien souvent sans avoir la moindre idée de ce que cela signifie, bien au-delà des quelques gentilles pratiques du Management 3.0.

Il reste que l'agile se généralise. Quelle (grande) société aujourd'hui n'a pas expérimenté voire déployé l'agile ?
Peu à peu, la nécessité d'autonomiser les équipes grandit.
La gamification (je t'aime... Ma non troppo) dĂ©tend un peu les relations. Les Managers prennent conscience que les personnes dans l'Ă©quipe sont des ĂȘtres humains avant d'ĂȘtre des ressources.

Dans cet ordre d'idée, la question du développement personnel (des Managers mais aussi de tout membre de l'équipe) se pose. Il n'est qu'à voir tous ces Coachs et autres spécialistes de la Mindfulness qui se précipitent vers nous.
Bref... Nous sommes au milieu du pont.
Ce Nouveau Monde que nous inventons est encore empreint de travers de l'ancien.
Mais la dynamique est bien en marche.

Catégories: Blog Individuel

"Exigence" : un terme vraiment agile ?

Être Agile - Thierry Cros - jeu, 02/11/2016 - 12:17

etre-agile.png Il vous arrive peut-ĂȘtre de lire ou d'entendre parler d'exigences dans un contexte agile. Avant d'indiquer pourquoi je crois que ce n'est pas trĂšs pertinent, je voudrais rappeler un postulat : les mots ont un sens. Non seulement un sens, une histoire.
Les exigences correspondent initialement Ă  une certaine technique d'expression de besoins.

Confusion entre expression de besoins et exigences

Que ce soit via

  • une liste d'exigences
  • une modĂ©lisation d'interactions en cas d'utilisation
  • un ensemble Ă©mergent de user stories de l'Extreme Programming
  • ...

Il s'agit bien d'exprimer des besoins. Autrement dit, le point commun à toutes ces techniques est leur finalité : exprimer des besoins.
Utiliser le terme "exigences" renvoie donc à cette technique ancienne basée sur des listes de besoins parfois classés en besoins fonctionnels, non-fonctionnels...

Exigence ?

Au-delà de l'aspect historique qui renvoie à des pratiques sensiblement différentes, ce terme d'exigence pose un problÚme sémantique.
La base d'une planification agile est qu'il existe, dans un environnement complexe, une variable d'ajustement des plans. Cette variable peut ĂȘtre

  • le budget
  • la date des livraisons
  • la qualitĂ© (en termes de maintenabilitĂ©, Ă©volutivitĂ©...)
  • le contenu.

Les méthodes agiles telles que XP recommandent de jouer plutÎt sur le contenu.
Ce qui signifie que les besoins ne sont - par nature et de façon générale - pas des exigences au sens autoritaire et définitif du terme.

Conduite du changement

Mais je crois que "le pire" dans l'utilisation de ce terme est en terme de conduite de changement. À ce compte-lĂ  continuons d'utiliser "chef de projet" pour ScrumMaster ou bien lotissement pour les versions frĂ©quentes mises en exploitation. Cela ne facilite pas la prise de conscience que nous Ă©voquons des rĂŽles, pratiques, principes radicalement diffĂ©rents.

Et donc...

Expression de besoins est le nom donné à cette activité. Remplacer "exigence" par "besoin" me semble donc plus pertinent, par exemple
outil d'expression de besoins plutÎt que outils de gestion d'exigences lorsqu'il s'agit de gérer des stories.

Par ailleurs, les rÚgles de gestion et autres "contraintes" à respecter sont reprises d'une part dans des tests d'acceptation (qui constituent une story tout autant que la carte) ou bien dans une définition de fini lorsqu'il s'agit d'éléments communs à plusieurs besoins.

Franchissons vraiment le pont vers la rive agile, ne restons pas au milieu !

Aigle

Catégories: Blog Individuel

SoftShake 2015 – Appel aux confĂ©renciers

Forum Logiciel - lun, 07/13/2015 - 13:55
La confĂ©rence SoftShake revient en 2015 pour sa 5Ăšme Ă©dition, et se tiendra les jeudi 22 et vendredi 23 octobre, en plein centre de GenĂšve, dans les locaux de l’hepia (comme ces derniĂšres annĂ©es). SoftShake vient d’ouvrir l’appel aux confĂ©renciers. N’hĂ©sitez pas Ă  vous porter candidat si vous souhaitez partager un sujet : * Les […]
Catégories: Blog Individuel

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux