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.

Agrégateur de flux

Retour sur le SonarSource City Tour Ă  Paris

Blog d’Ippon Technologies - jeu, 09/29/2016 - 15:24

Le SonarSource City Tour 2016 est passĂ© par Paris le 13 septembre 2016. PassionnĂ© de DevOps et convaincu de la pertinence de l’intĂ©gration continue, l’occasion Ă©tait parfaite pour se rendre Ă  l’Ă©vĂ©nement.

Le circuit passe par 12 villes dont Santa Clara, New York, Francfort, Londres, etc. Arrivée un peu plus à mi-parcours, Paris est la ville qui accueille le plus de curieux avec plus de 120 personnes présentes. Parmi les orateurs SonarSource présent, Olivier Gaudin, Freddy Mallet, Fabrice Bellingart, Nicolas Peru ont été les plus actifs.

Outil populaire

D’abord grand fan de PMD, Findbugs et Checkstyle depuis mes jeunes annĂ©es de dĂ©veloppeur Java, je dois reconnaĂźtre que l’association de SonarQube avec Jenkins en a fait une rĂ©fĂ©rence, un standard de fait. C’est un acteur de premier plan dans une usine Ă  build. L’outil est populaire. Les organisateurs avancent mĂȘme le chiffre de 80 000 entreprises utilisatrices (volume mesurĂ© par l’update center).

Quelle approche pour faire de la qualité ?

La qualitĂ© intĂ©resse-t-elle tout le monde ? De la mĂȘme maniĂšre que l’écriture des tests, la plupart du temps elle est massacrĂ©e ou simplement ignorĂ©e. Dans la prĂ©cipitation et l’urgence des livraisons, on remets toujours Ă  demain, la revue de code n’est pas prioritaire.

Une fois le legacy existant que faire ? Confier le projet Ă  une Ă©quipe d’audit ? ils devront sermonner les dĂ©veloppeurs, qui traĂźneront des pieds pour corriger. Alors on nomme d’office une Ă©quipe pour corriger la dette : elle est en charge de fixer les violations les plus sĂ©vĂšres , ils tenteront de dĂ©piler la longue liste de bugs bloquants, puis critiques.. ils abandonneront avant : l’exercice est trĂšs dĂ©licat, trĂšs rĂ©barbatif, pas amusant du tout. Sans parler du risque de casser quelque chose.

Olivier Gaudin insiste : l’Ă©quipe de dev doit ĂȘtre responsable, fournir un livrable qui rĂ©pond dĂ©jĂ  aux critĂšres de qualitĂ©s. Attendre la release pour analyser c’est trop tard. En fait le feedback doit ĂȘtre le plus court possible. Il faut gĂ©rer la fuite au fur et Ă  mesure qu’elle se dĂ©clare. C’est la fameuse image de la fuite d’eau, le waterleak http://docs.sonarqube.org/display/HOME/Fixing+the+Water+Leak  l’idĂ©e est de se focaliser sur le robinet qui fuit (donc le nouveau code) et aprĂšs nous irons Ă©ponger l eau sur le sol (le code legacy). En effet l’eau dĂ©jĂ  rĂ©pandue peut attendre alors qu’il y a urgence sur le robinet. S’acharner Ă  Ă©ponger l’eau est une perte de temps ! C’est du code dĂ©jĂ  existant, dĂ©jĂ  en prod, alors laissons le lĂ  oĂč il est. Intercepter la fuite, c’est facile, c’est frais, c’est dans les tĂȘtes, une nouvelle dette est trĂšs peu chĂšre Ă  corriger. Personne n’ira grogner pour colmater la fuite, corriger son code. On peut mĂȘme parier que ce sera fixĂ© sans soucis, en un temps record, et surtout avec un coĂ»t humain nĂ©gligeable ! La responsabilitĂ© devient claire. la patate chaude n’est plus.

Nouveautés de la version 5.6

Comment la fuite est elle mesurĂ© ? Qu’est ce qui distingue concrĂštement la flaque dĂ©jĂ  rĂ©pandu de l’urgence de la fuite ? En fait, le nouveau code est mesurĂ© Ă  partir d’une version de son choix, une date prĂ©cise, ou juste depuis la derniĂšre analyse complĂšte.

Dans cette optique, le nouveau tableau de bord SonarQube 5.6 prĂ©sente des mĂ©triques uniquement axĂ©es sur le ‘nouveau’ code. La visibilitĂ© est immĂ©diate, vous savez si la version en cours introduit de la dette. Nombre de nouveaux bugs, couverture de code sur le ‘nouveau code’, etc. Poussant ce raisonnement plus loin, la pyramide de dettes technique, prĂ©sente encore sur la derniĂšre version, en a fait les frais, elle a disparu. Ce widget est devenu trop gĂ©nĂ©raliste, trop focussĂ© sur la dette ‘en gĂ©nĂ©ral’, il ne correspond plus Ă  la nouvelle approche ‘leak’. Petite dĂ©ception tout de mĂȘme pour ma part.

Autre absent, le plugin ‘views’ : il permettait d’agrĂ©ger les indicateurs de plusieurs projets en un seul. Une façon de voir comment son parc Ă©volue. En fait il est remplacĂ© par un nouveau plugin ‘Governance’. http://www.sonarsource.com/products/plugins/governance/ Mais pour cela il faut possĂ©der la version ‘Entreprise’ de SonarQube, autrement dit lĂ  oĂč une DSI pouvait utiliser la version communautaire de SonarQube (donc gratuite) et juste financer le plugin ‘views’,elle devra Ă  prĂ©sent acheter la version ‘entreprise’ Ă  un coĂ»t nettement plus Ă©levĂ©. L’annonce a plutĂŽt choquĂ© l’auditoire.

SonarQube 5.6 arrive aussi avec son lot de nouveautĂ©s techniques : la connexion directement Ă  la base de donnĂ©es n’existe plus. Pour des raisons de sĂ©curitĂ© dĂ©jĂ , les “clients” ne portent plus avec eux les credentials de la base de donnĂ©es. Les communications se font par webservice. C’est l’instance du serveur SonarQube qui gĂšre les lectures et Ă©critures en base. Ensuite, pour des raisons de performances : imaginons plusieurs serveurs jenkins qui remontent dans un laps de temps trĂšs serrĂ© un nombre Ă©levĂ© de rapports d’analyse : la base de donnĂ©es va se retrouver sous l’eau, entraĂźnant des retards dans les consultations de page sur l’ihm. Avec la version 5.6 c’est le ‘Compute Engine’ qui prend le temps de digĂ©rer les rapports reçus par webservice et d’injecter les donnĂ©es dans la base de donnĂ©es, de ce fait la communication avec le client ayant soumis le rapport est asynchrone, soulageant le client de l’attente de la fin du traitement.

En plus de cela, pour accélérer les temps de réponses, Elasticsearch est maintenant de la partie. Il indexe les erreurs et permets de gros gains dans les affichages de détail de classe et lors de recherche de modules, sous modules ou de classes.

En contrepartie, SonarQube 5.6  est plus gourmand, il y a 3 process java à présent (serveur web, ComputeEngine, Elasticsearch) contre un seul auparavant.

Citant la roadmap Ă  venir, Julien Peru est clair : SonarQube doit pouvoir scaler horizontalement, car la verticale a une limite:  demain on doit pouvoir Ă©tendre sur l horizontal, rĂ©partir la charge, avoir plusieurs Compute Engine si on le souhaite,  plusieurs Elasticsearch, plusieurs serveurs web, plusieurs bases de donnĂ©es. Un serveur classique mĂȘme gonflĂ© ne suffit plus. L’éditeur est directement concernĂ© par ce besoin de scalabilitĂ©, car il hĂ©berge gratuitement les analyses des produits open source  : https://sonarqube.com/

A noter l’intervention de Jean Marc Prieur, Program Manager chez Microsoft, qui a permis la coopĂ©ration entre la firme de Richmond et SonarQube pour rendre possible une analyse sonar sur la plateforme microsoft Azure.

im2

Quelle approche pour écrire de la qualité ?

Il existe 3 niveaux de retour d’analyse du code par SonarQube, ce qui permet d’entrevoir autant de scĂ©narios :

  • 1er niveau : dans le flow de dĂ©veloppement.

Freddy Mallet explique que le retour immĂ©diat passe par l’utilisation de Sonar Lint http://www.sonarlint.org/, un plugin pour Eclipse, intelliJ et VisualStudio.

L’utilisation est trĂšs simple : votre code (html, javascript, css, java, .) est de suite analysĂ©  dans votre IDE Ă  chaque enregistrement, soulignant les lignes ne rĂ©pondant pas au niveau de qualitĂ© requis. Le plugin peut mĂȘme ĂȘtre connectĂ© Ă  l’instance SonarQube appliquant ainsi le profil qualitĂ© de votre choix, telle qu’il est dĂ©fini sur le serveur. Ainsi tous les dĂ©veloppeurs traquent la dette en temps rĂ©el, elle n’a alors en principe que trĂšs peu temps Ă  vivre, le feedback est immĂ©diat.

  • 2eme niveau : dans les pull request

Si malgrĂ© tout, du code de mauvaise qualitĂ© venait Ă  ĂȘtre poussĂ© sous Git, SonarQube peut ĂȘtre reliĂ© aux pull request, prĂ©sentant ainsi lors du code review sous votre interface Github les parties de code dĂ©faillantes.http://www.sonarqube.org/github-pull-request-analysis-helps-fix-the-leak/

En plus de GitHub , il existe un plugin pour Bickbucket https://github.com/AmadeusITGroup/sonar-stash prĂ©sentĂ© durant cette mĂȘme journĂ©e par Antoine Copet de l’entreprise Amadeus.

  • 3eme niveau : l’analyse ‘full’

C’est l’analyse ‘complĂšte’ et la plus connue, qui parse le projet dans sa globalitĂ©. Pouvant prendre plusieurs heures et gourmand en ressource il est prĂ©fĂ©rable de l’exploiter sous forme de bilan qui tournerait une fois par nuit, par exemple via un job jenkins rĂ©glĂ© par un cron. Dans ce cas lĂ  le retour se fait par consultation du dashboard SonarQube, les dĂ©veloppeurs perdent en efficacitĂ©.

Et les rĂšgles ?

Chez SonarQube la moitiĂ© des Ă©quipes de dev travaillent sur les analyses de code, l’accent Ă©tant portĂ© actuellement sur les langages C, C#, C++ et Javascript.

Fabrice Bellingart nous explique qu’une rĂšgle c’est une implĂ©mentation mais aussi une documentation: pourquoi cette erreur, pourquoi cet endroit, comment corriger.

A ce propos j’insiste Ă  titre personnel sur le fait que dĂ©velopper avec les rĂšgles SonarQube et auparavant avec Pmd et findbugs m’ont permis d’apprendre Ă©normĂ©ment sur les bonnes pratiques, un peu comme si j’avais eu un coach Ă  mes cĂŽtĂ©s. C’est fun et pĂ©dagogique.

Les rĂšgles implĂ©mentĂ©s dans SonarQube ne sont pas lĂ  par hasard, elles sont issues d’organismes de rĂ©fĂ©rences tels CWE, CERT et OWASP.

Elles sont regroupées dans le JIRA https://jira.sonarsource.com/browse/RSPEC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel .

La mailling liste SonarQube est ouverte pour recevoir les avis, demandes et critiques sur les rĂšgles.

https://cwe.mitre.org/

https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards

https://www.owasp.org/index.php/OWASP_SonarQube_Project

Nicolas Peru nous rappelle que SonarQube est un outil d’analyse de code statique, on y distingue 3 niveaux d’analyses :

lexical (suite de mots ou présence de mots )

syntaxique (un sujet, un verbe)

A ce stade beaucoup de rĂšgles peuvent exister.

Le dernier niveau, l’analyse sĂ©mantique, est la plus gourmande : tous les chemins d’exĂ©cutions sont parcourus, pas Ă  pas chaque variable est suivi. On identifie ainsi par exemple les risques de Null Pointer Exception, les conditions qui ne servent Ă  rien, les divisions par zĂ©ro, ..

Par contre cette analyse ne suit pas les variables  entre les appels de méthodes. (ce qui est prévu dans la roadmap)

im3

Le futur

Des outils comme checkmarx qui traquent les failles de sĂ©curitĂ© devraient ĂȘtre Ă  terme intĂ©grĂ©s dans le moteur SonarQube. (Avec un moteur et une analyse pur jus SonarQube)

Une meilleur la gestion des branches : aujourd’hui un projet github qui comporte plusieurs branches a pour consĂ©quences d’avoir autant de projet dans SonarQube ce qui demande de dupliquer les configurations. Il faut aussi utiliser un paramĂštre sonar.branch pour distinguer la branche du master et ainsi s’assurer que les analyses ne remontent pas sur le projet principal. Ce point fait partie des tĂąches prioritaires pour les Ă©volutions Ă  venir.

A noter que la derniĂšre version de SonarQube propose une API REST toujours plus riche. L’interaction dans un environnement d’intĂ©gration continue est en renforcĂ©e, exploitable par exemple dans des scripts shell ou groovy ou bien des plugins java.  https://sonarqube.com/web_api

Conclusion

SonarQube devient encore un peu plus un Ă©lĂ©ment central dans l’intĂ©gration continue. La qualitĂ© est maintenant concevable directement depuis l’IDE sans attendre les rapports colossaux indigestes. La productivitĂ© se retrouve grandie et coder reste fun. En outre L’API REST permets Ă  SonarQube d’interagir avec les autres acteurs de l’usine logiciel et de ne pas l’isoler Ă  un simple rĂŽle du ‘catalogue des bugs’.

Merci à SonarQube pour cette journée enrichissante et à Fabrice Bellingart pour sa disponibilité pour mes différentes questions.

Catégories: Blog Société

Culture Change : “Hack the invisible to make results visible”

Les projets de transformation s’enchaĂźnent et se ressemblent : digital, lean, agile, bonheur au travail, etc. Ces programmes ne font-ils pas toujours la mĂȘme chose ?

En 1995, une Ă©tude publiĂ©e dans Harvard Business Review affirmait que seuls 30 % des changements organisationnels rĂ©ussissaient. En 2006, une recherche de McKinsey&Co confirmait la mĂȘme tendance.

Ce qu’il y a de commun dans ces Ă©checs ? C’est notre incapacitĂ© Ă  apprĂ©hender collectivement la dimension culturelle des organisations.

Culture Hacking

 

Face Ă  cette rĂ©alitĂ©, chez OCTO, nous croyons que c’est une opportunitĂ© :

  • de rĂ©inventer nos maniĂšres d’accompagner le changement dans les organisations
  • de rĂ©Ă©duquer nos regards
  • de repenser nos modĂšles et nos outils pour ancrer durablement les changements

C’est la proposition de valeur d’OCTO Academy. Explorez de maniĂšre expĂ©rientielle, co-constructive et participative la complexitĂ© du changement et sa dimension culturelle. Notre Ă©quipe Culture Hacking vous assiste dans la construction et l’animation de vos formation au service du changement. 

Marc CHERFI, Culture Hacking
Stéphanie MARCHAL, Spécialiste en ingénierie de formation

Nos formations « Culture Change »

+ DÉCOUVRIR NOS FORMATIONS >

Quelques pistes de rĂ©flexion Culture Hacking Le petit-dĂ©jeuner Culture Hacking, organisĂ© par OCTO, Ă©tait dĂ©finitivement placĂ© sous le signe du changement. À commencer par le lieu : la terrasse du Numa, une premiĂšre pour ce type d’évĂšnement OCTO, et le parfait terrain de jeux pour les intervenants de cette matinĂ©e, Lan Levy, Marc Cherfi et Alexis Nicolas. –

+ LIRE LA SUITE >

 

« Rien n’est permanent, sauf le changement. »

HĂ©raclite d’EphĂšse

www.octo.academy

Articles suggested :

  1. Vivez l’expĂ©rience formation avec OCTO
  2. Formations OCTO : rentrée 2015
  3. Formation Data Science : Paris – GenĂšve

Catégories: Blog Société

Self service with JIRA Service Desk

Le blog de Valiantys - jeu, 09/29/2016 - 09:00

In the fast-moving world we currently live in, customers want to wait less and access information faster. But most importantly, customers like to help themselves. In fact, more customers prefer to use self service tools rather than contacting a help desk, and this is is a driving force behind how companies chose their service desk, according ...

The post Self service with JIRA Service Desk appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

[Session Mensuelle] Le Software Craftsmanship, un nouvel Eldorado ?

Agile Nantes - mer, 09/28/2016 - 17:45
Venez comprendre le Software Craftmanship le mercredi 05 octobre prochain avec Maxime Sanglan-Charlier ! RĂ©sumĂ© MĂȘme si le terme existe depuis environs 8 ans, on entend de plus en plus parler de Software Craftsmanship. De nombreuses sociĂ©tĂ©s mettent en avant le Software Craftsmanship comme un atout dans le recrutement et d’autres vous promettent mĂȘme depuis [...]
Catégories: Association

Scrum ou Kanban : Je hais les colonnes

Amis Agilistes, il faut que je vous fasse une confidence. Je hais les colonnes dans vos boards ! Chaque fois que vous me montrez fiĂšrement vos tableaux de 4 mĂštres de large et que vous me voyez dodeliner de la tĂȘte, je n’ai qu’une envie, c’est de prendre des ciseaux (ou hache, scie Ă  mĂ©taux, brosse, gomme, selon le support utilisĂ©) et d’en enlever les trois quarts.

Voilà pourquoi 


Parmi ces colonnes, certaines matĂ©rialisent un travail rĂ©alisĂ© par l’équipe, d’autres sont des colonnes d’attente, des queues. Kanban commençant « lĂ  oĂč vous ĂȘtes », et le board Kanban ayant vocation Ă  visualiser le process (ce qui apporte dĂ©jĂ  de nombreux bĂ©nĂ©fices en soi), il n’est pas surprenant d’y voir de nombreuses colonnes me direz-vous. Par exemple, si aujourd’hui vos phases de « tests de non-rĂ©gression » n’ont lieu qu’une fois par semaine, il vous faut bien une colonne « En attente de test » ! Le hic, c’est que trop d’équipes (et d’organisations) s’arrĂȘtent lĂ . OĂč en tout cas, ne sont pas plus affolĂ©es que cela par les multiples files d’attente dans le flux de travail, et ce qu’elles engendrent comme inefficacitĂ©.

Dans de nombreuses Ă©quipes Scrum, c’est la mĂȘme chose. On fait s’asseoir tout le monde dans un mĂȘme bureau, mais on continue de travailler chacun dans son coin et d’ĂȘtre rĂ©ticent Ă  l’idĂ©e d’interrompre son voisin. Etat de fait que l’on se sent obligĂ© de matĂ©rialiser par des colonnes « En attente de Code Review » et autres « En attente de Test ».

On passe donc selon moi Ă  cĂŽtĂ© de l’essentiel : la recherche du « One Piece Continuous Flow ». L’état idĂ©al dans Lean. Dans lequel chaque Ă©lĂ©ment traverse le board sans interruption pour minimiser le Temps de Cycle, minimiser l’inventaire, et accĂ©lĂ©rer.

Continuum-of-flow.png

 

Extrait de « The Toyota Way », Jeffrey Liker

TrÚves de bavardages, je vous propose donc 4 étapes pour vous aider à réduire le nombre de colonnes dans vos boards, et, lentement mais surement, vous rapprocher du Continuous Flow !

Etape n°1 : Mesurez !

Avant toute chose, mesurez votre Temps de Cycle actuel. Si vous entreprenez de convaincre vos collĂšgues qu’il y a un problĂšme avec votre maniĂšre actuelle de travailler, il va vous falloir ĂȘtre percutant et convaincant. Or il y a fort Ă  parier qu’un pitch thĂ©orique dans le genre de mon introduction ci-dessus n’interpelle pas grand monde. En revanche essayez de dire Ă  vos collĂšgues « le dernier bug majeur en production, il nous a fallu 11 jours pour le corriger », ou encore « si le Product Owner veut changer une virgule dans l’interface, il doit attendre 6 jours en moyenne ». A mon avis, vous aurez plus de chance.

De plus, ne vous contentez pas de mesurer le Temps de Cycle global. Mesurez le temps passĂ© dans chacune des colonnes. Vous pourrez alors identifier les colonnes les plus problĂ©matiques. Vous pourrez aussi calculer le ratio entre le temps passĂ© dans les colonnes « productives » et le temps passĂ© dans les colonnes d’attente. Vous serez alors en mesure de dire : « le dernier bug majeur en production, il nous a fallu 11 jours pour le corriger
 et 70% du temps, on ne travaillait mĂȘme pas dessus ! ». Et ça, c’est percutant.

Ces mĂ©triques seront par ailleurs nĂ©cessaires pour vĂ©rifier que les actions correctives que vous entreprendrez ont rĂ©ellement l’effet escomptĂ©.

Etape n°2 : Enlevez des colonnes et voyez ce qui se passe

Dans certains cas, les colonnes sont lĂ  par habitude. Typiquement : la colonne « Code Review » (et son amie « En attente de Code Review »), ou encore les colonnes « Merger » / « A Merger ». Mais leur simple prĂ©sence dans le board conduit l’équipe Ă  apprĂ©hender le travail de maniĂšre sĂ©quentielle. Elles crĂ©ent par ailleurs une occasion pour le dĂ©veloppeur de changer de sujet : « puisque cette User Story est en attente que quelqu’un se libĂšre pour faire la Code Review (et comme il est mal vu de se tourner les pouces), je vais commencer autre chose ».

Si au contraire vous dĂ©cidez d’intĂ©grer l’activitĂ© de Code Review dans la colonne prĂ©cĂ©dente (typiquement « En cours » ou « ImplĂ©mentation »), alors vous rĂ©duisez ce phĂ©nomĂšne. Le dĂ©veloppeur ne pourra pas faire avancer « sa » User Story dans le board. Il sera encouragĂ© Ă  trouver rapidement un moyen de faire revoir son code.

Etape n°3 : CO-LLA-BO-REZ

La chose qu’on me rĂ©pond lorsque je parle de supprimer la colonne Code Review, c’est que cela signifie que l’on va devoir interrompre ses collĂšgues. Et que tout le monde sait bien que les interruptions c’est mal !!!

Oui 
 mais Non ! Si vous interrompez votre collĂšgue MAINTENANT, afin de vous Ă©viter Ă  vous d’ĂȘtre interrompu PLUS TARD, lorsque vous serez passĂ© Ă  autre chose, pour prendre en compte les remarques qu’il aura faites sur votre code (code qui aura pris un peu de poussiĂšre dans votre esprit entre temps), et si cela permet de rĂ©duire le Temps de Cycle, alors interrompre votre collĂšgue est la meilleure chose Ă  faire ! Pour cadrer ces interruptions sans perdre grand chose en terme de rĂ©activitĂ©, vous pouvez Ă©galement essayer la technique Pomodoro.

Plus gĂ©nĂ©ralement, chaque membre de l’équipe doit arrĂȘter de chercher Ă  optimiser l’allocation de son temps Ă  lui. Etre Lean, c’est optimiser le Temps de Cycle global !

Vous pourriez mĂȘme vouloir essayer des pratiques plus radicales, comme le Pair Programming en remplacement (total ou partiel) de la Code Review. Et si vous avez peur que cela impacte nĂ©gativement votre VĂ©locitĂ©, pourquoi ne pas essayer pendant quelques temps et voir ce que ça donne ? Vous pourriez bien ĂȘtre surpris.

MĂȘme chose concernant le test. Trop d’équipes Agile continuent de considĂ©rer le test comme une Ă©tape;  une Ă©tape arrivant nĂ©cessairement aprĂšs l’implĂ©mentation du code, et devant nĂ©cessairement ĂȘtre rĂ©alisĂ©e par un « testeur » (cf. 2 dans le graphe ci-dessous). A l’aide de pratiques telles que l’Acceptance Test-Driven Development (ATDD), l’équipe est amenĂ©e Ă  collaborer et Ă  reconsidĂ©rer l’ordre dans lequel elle Ă©crit le code et le teste, avec un impact important sur le Temps de Cycle et l’efficacité (cf. 3 dans le graphe ci-dessous).

 

sprint

Etape n°4 : DĂ©veloppez progressivement une Ă©quipe de “T-shaped specialists”

Les Ă©quipes les plus performantes avec lesquelles j’ai travaillĂ© Ă©taient composĂ©es de gens Ă  la fois trĂšs bons dans leurs spĂ©cialitĂ©s respectives, mais relativement compĂ©tents aussi dans les spĂ©cialitĂ©s de leurs collĂšgues. Un « DĂ©veloppeur back-end » avec des connaissances en « front-end », une sensibilitĂ© pour l’UX, et une appĂ©tence pour le test par exemple. Ou encore un « IngĂ©nieur Qualité » capable de participer Ă  des revues de code ou de faire une premiĂšre analyse des anomalies en lisant des logs.

On parle de « T-shaped specialists ».

Mais pourquoi a-t-on besoin de « T-shaped specialists » ?

 

t-shaped.JPG

D’abord, car les colonnes matĂ©rialisent bien souvent des passages de mains. D’un corps de mĂ©tier Ă  un autre, d’une expertise Ă  une autre. Or pour qu’une Ă©quipe collabore et commence Ă  envisager sereinement de supprimer ces passages de mains, il est nĂ©cessaire que chacun comprenne un minimum les problĂ©matiques de l’autre.

Par ailleurs dans une Ă©quipe mĂ©langeant plusieurs spĂ©cialitĂ©s, Ă  chaque instant, l’une des spĂ©cialitĂ©s est forcĂ©ment sur le chemin critique de l’équipe. Impactant de fait le Temps de Cycle. Avec des « T-shaped specialists », l’équipe gagne donc en souplesse, et s’ouvre des portes en matiĂšre de rĂ©partition du travail au quotidien.

Pour dĂ©velopper une Ă©quipe de « T-shaped specialists », la premiĂšre chose que je recommanderai – la solution de facilitĂ© en quelque sorte – c’est de chercher les « T-shaped specialists » dĂšs l’embauche. Le candidat a-t-il l’habitude de travailler en Ă©quipe ? De sortir de sa zone de confort ? Y voit-il un intĂ©rĂȘt pour l’équipe ? Y consent-il par nĂ©cessité ou en tire-t-il de la satisfaction ?

Avec une Ă©quipe existante, commencez par mettre en Ă©vidence le manque Ă©ventuel de redondances, Ă  travers par exemple une matrice des compĂ©tences [1] nĂ©cessaires Ă  la rĂ©alisation du travail de l’équipe. Puis, demandez Ă  chaque membre de l’équipe quelles compĂ©tences il possĂšde, et celles qu’il souhaite acquĂ©rir. Vous aurez souvent de bonnes surprises. Beaucoup de gens se dĂ©clarent intĂ©ressĂ©s par le travail des autres, mais regrettent simplement d’ĂȘtre pris par le quotidien et de manquer de temps pour monter en compĂ©tences. Vous identifierez aussi certainement des activitĂ©s ou compĂ©tences sur lesquelles personne ne souhaitera s’investir d’avantage. Vous aurez au moins rendu le problĂšme visible. Le premier pas ! L’équipe pourra alors rĂ©agir de diffĂ©rentes maniĂšres :

  • Chacun consentira peut-ĂȘtre Ă  « prendre sur lui », en mettant la main Ă  la patte, Ă  tour de rĂŽle par exemple, sur ces activitĂ©s qui ne l’intĂ©ressent pas, pour le bien du groupe.
  • L’équipe trouvera peut-ĂȘtre un moyen de, tout simplement, ne plus avoir Ă  faire ces activitĂ©s. S’il s’agit de l’exĂ©cution d’une tĂąche manuelle, l’équipe dĂ©cidera peut-ĂȘtre de l’automatiser. Si c’est liĂ© Ă  une technologie obsolĂšte, l’équipe dĂ©cidera peut-ĂȘtre de refaire la chose dans une autre technologie. Etc.

Au quotidien, vous pouvez aussi faire remarquer Ă  l’équipe chaque fois qu’une compĂ©tence se retrouve sur le chemin critique, et encourager Ă  dĂ©bloquer la situation. Petit Ă  petit, par la force des choses, chacun progressera de fait dans des domaines autres que son domaine de prĂ©dilection.

VoilĂ , j’espĂšre vous avoir donnĂ© quelques pistes pour rĂ©duire le nombre de colonnes dans vos boards et par la mĂȘme devenir plus « Lean ». Alors tous Ă  vos ciseaux (ou haches, scies Ă  mĂ©taux, brosses, gommes, selon le support utilisĂ©).

[1] Pour aller plus loin, je vous recommande vivement la lecture de cet article d’Anders Laestadius : Market of skills and competence matrix

Catégories: Blog Société

Big Data 2.0 ?

Blog d’Ippon Technologies - mer, 09/28/2016 - 10:55

Dans cet article je vais vous prĂ©senter les conditions de crĂ©ation du livre blanc Big Data 2016 architectures et solutions disponible Ă  l’adresse suivante : http://explore.big-data.fr

Il y a eu le web 2.0 qui a lancé la révolution web et il y aurait donc le Big Data 2.0.

J’aime bien cette idĂ©e du Big Data qui Ă©volue techniquement bien sĂ»r mais aussi son impact actuel et futur sur les entreprises.

En effet selon une Ă©tude IDC :

En 2012, seulement 7 % des entreprises accĂ©lĂ©raient dans la data. Cette annĂ©e, 51 % d’entre elles assurent avoir dĂ©marrĂ© des projets dans l’analyse de multiples donnĂ©s. (source http://www.lebigdata.fr/marche-france-big-data-2209)

Cette effervescence se ressent Ă©videmment sur le terrain oĂč l’on est passĂ© du « Pourquoi pas le Big Data ? » Ă  « OĂč en ĂȘtes vous du Big Data ? »

Cela dit, il n’y a pas un Big Data mais des Big Data. Le type de missions et les technologies abordĂ©es sont multiples. Le rĂŽle du Big Data reste le mĂȘme : valoriser les donnĂ©es de l’entreprise.

Extrait du type de missions que j’ai rencontrĂ© cette annĂ©e ;

  • AmĂ©liorer le temps rĂ©el et rĂ©duire les coĂ»ts de licence : Spark, Cassandra
  • SĂ©curitĂ© et sĂ©paration des donnĂ©es : Hadoop
  • Vision client 360 et DMP : Data Lake Hadoop
  • RĂ©partitions des responsabilitĂ©s au sein d’une Ă©quipe Big Data

C’est pourquoi la liste des thĂšmes abordĂ©s dans le livre blanc est large :

  • Freins & opportunitĂ©s du Big Data
  • MĂ©thodes
  • Mise en Ɠuvre
  • Solutions
  • Architectures
  • SĂ©curitĂ© & Tests

Le Big Data Ă©volue dans des directions multiples.
Certains aspects du Big Data sont matures, comme le stockage et le traitement, tandis que d’autres n’en sont qu’aux balbutiements :

  • SĂ©curitĂ©,
  • Internet des objets

Bonne lecture et n’hĂ©sitez-pas Ă  faire des remarques.

Catégories: Blog Société

Les Octos dĂ©barquent Ă  l’Agile Tour Lille 2016 !

Les 13 et 14 Octobre prochains, les ch’tis nous invitent Ă  l’Agile Tour Lille. L’occasion pour les Octos de venir rencontrer la communautĂ© locale des agilistes et d’échanger sur nos bonnes pratiques.

6 conférences, 6 pépites

Photo d'une session OCTO Ă  l'Agile Tour Lille 2015

Retrouvez les speakers OCTO sur les diffĂ©rents sujets de confĂ©rence. Nous vous invitons Ă  passer discuter avec eux sur l’espace OCTO !

Un logiciel qui fonctionne est un logiciel que l’utilisateur a plaisir Ă  utiliser

Antoine Peze (UX Designer@OCTO) et Fabien Arcellier (TechLead/Craftsman@OCTO) vous invitent Ă  rĂ©flĂ©chir sur la notion de qualitĂ© d’un logiciel, par le prisme des Ă©motions que ce dernier provoque chez l’utilisateur. ColĂšre, tristesse, joie, peur, dĂ©goĂ»t ; l’observation des Ă©motions complĂšte l’analyse de la satisfaction utilisateur et guide l’équipe dans la priorisation des dĂ©veloppements.

#UX #agilitĂ© #feedback #Ă©motions  – Le 13 Octobre Ă  10h45, salle de confĂ©rence 1

Du craft chez les OPS

François Xavier VENDE (Expert DevOps@OCTO) et Mathieu Herbert (Expert DevOps@OCTO) vous plongent dans la rĂ©alisation d’un « SI as a Service ». Une solution dĂ©veloppĂ©e en mode Produit et dont les utilisateurs sont des dĂ©veloppeurs.

Et comme tous les produits, il est tout Ă  fait envisageable de le faire vivre selon les principes de l’agilitĂ© en appliquant les pratiques de la qualitĂ© logicielle (software craftsmanship)

Les OPS deviennent des développeurs agiles, étonnant non ?! :D

#devops #InfraAsCode – Le 13 Octobre Ă  11h45, salle de confĂ©rence 2

Atelier – Évitez la lassitude, crĂ©ez vos propres formats de rĂ©trospective

Alban Dalle (Coach Agile et Leader de la Tribu ScalingAgile@OCTO) vous propose un atelier pratique pour Ă©laborer vos propres supports de rĂ©trospective. Le but est de renouveler les animations de rĂ©tro pour stimuler l’intĂ©rĂȘt et la participation des Ă©quipes autour d’histoires/scĂ©narios innovants.

L’imagination est votre seule limite ! :D

#CreativeWorkshop #retrospective #storytelling – Le 14 Octobre Ă  10h45, Atelier B

Mon processus de design en tant que Product Owner sans UX designer

Anael Ichane (Product Manager@OCTO) propose de synthĂ©tiser le cheminement de son design d’application lorsque l’équipe ne bĂ©nĂ©ficie pas de l’expertise d’un UX designer. Quelques tips Ă  prendre et Ă©cueils Ă  Ă©viter pour un produit applicatif mieux adaptĂ© aux usages.

#noUX #ProductManagement #design – (Lightning Talk) Le 14 Octobre Ă  15h00, salle de confĂ©rence 3

Les Feature Teams, du rĂȘve Ă  la rĂ©alitĂ©

Basile du Plessis (Coach Agile@OCTO) possĂšde une expĂ©rience extensive de la mise en place d’organisations en Feature Teams. Il nous propose une synthĂšse de ses apprentissages sur l’impact de cette transformation sur les membres de l’équipe, leur management, les parties prenantes (mĂ©tier, exploitation, PMO, RH, 
).

#FeatureTeams #organisation #management – Le 14 Octobre Ă  16h15, Auditorium

Transition agile 4 real @meetic

Nicolas Kalmanovitz (Coach Agile@OCTO) propose un talk sur la transformation Agile qu’il a menĂ© pendant 5 ans chez Meetic. La colocalisation des mĂ©tiers, designers et des dĂ©veloppeurs, le rapprochement avec les OPS, l’évolution de la stack technique, la collaboration : vous aurez le droit Ă  un aperçu Ă  360° d’une transformation agile mature, avec de gros morceaux de retour d’expĂ©rience Ă  l’intĂ©rieur.

#TransformationAgile  #devops #methodo – Le 14 Octobre Ă  17h15, salle de confĂ©rence 2

Venez nous rencontrer !

OCTO est sponsor de l’Agile Tour Lille ; retrouvez les Octos et venez discuter des confĂ©rences sur notre espace. #goodiesgarantis !

Articles suggested :

  1. Agile france 2012 : 7 sessions by OCTO
  2. Petit-dĂ©jeuner : ITaaS ou l’infrastructure au service de ses projets – le mardi 8 dĂ©cembre
  3. TechDays 2015: Retrouvez toute l’actualitĂ© des technologies Microsoft avec OCTO

Catégories: Blog Société

Meetup 4 Octobre 2016 – Gribouille AcadĂ©mie, on ne lĂąche rien !

AprÚs la rentrée tonitruante en septembre, la Gribouille Académie reprend ses marqueurs. On passe à la vitesse supérieure et on essaye de garder le rythme.

Pas d’inquiĂ©tudes, on y va doucement pour ne rien oublier de ce que nous avons appris la fois derniĂšre :

  • On continue Ă  enrichir notre vocabulaire visuel,
  • On rajoute une pincĂ©e de grammaire pour structurer notre visuel et faciliter sa lecture,
  • On continue Ă  partager des astuces,
  • Et on finit par un petit exercice de mise en pratique comme d’habitude.

Cette fois encore, Xebia nous héberge au 7e du 156 Boulevard Haussman, 75008 Paris. Nous vous attendons le 4 octobre avec Jean-Pierre Bonnafous à partir de 18 h 45. Démarrage prévu vers 19 h.

Et pour les nouveaux, venez serein, on reste abordable mĂȘme pour le dĂ©butant. Amenez quelques feuilles, des marqueurs et c’est parti !

Pour les inscriptions ça se passe par le Meetup ici, oĂč vous trouverez aussi quelques photos des sessions prĂ©cĂ©dentes :

Gribouille-26-09.png

Catégories: Blog Société

Rejoignez le 2eme Meetup « Start Me Up » le 10 Octobre

OCTO Technology lance le meetup « Start Me Up »

Pour partager sur le dĂ©veloppement de l’innovation au sein des grandes organisations publiques ou privĂ©es, OCTO Technology a lancĂ© son meetup « Start Me Up », c’est par ici : Meetup – Start Me Up

stup1

Ce groupe s’adresse Ă  tous ceux qui sont intĂ©ressĂ©s par le corporate intrapreneuriat et l’innovation. Tous les niveaux de connaissance et d’acculturation sont les bienvenus. Rejoignez-nous pour dĂ©couvrir des pratiques intrapreneuriales, des dĂ©marches de conceptions innovantes et surtout partager des retours d’expĂ©riences, Ă©chec ou succĂšs, issus du monde corporate.

DeuxiĂšme session le 10 Octobre Ă  19h

Nous aurons le plaisir de partager deux retours d’expĂ©riences trĂšs intĂ©ressants d’innovateurs et startupers « internes » Ă  de grandes organisations : PrivĂ© et Public. En particulier :

  • Alain Buzzacaro : Alain partagera son expĂ©rience au sein de France TĂ©lĂ©visions et des FurĂȘts : Ancien CTO de start-up, il a appris les bĂ©nĂ©fices des approches Lean startup et du focus utilisateur. Humble acteur du changement, il s’applique Ă  comprendre, apprendre et mettre en pratique des approches d’amĂ©lioration continue. Il recherche les meilleures pratiques, les organisations, pour crĂ©er une culture de la performance et du bien-ĂȘtre au travail.
  • Laurent Ovion : Responsable Marketing Web & Innovation puis Innovation & Transformation Digitale au sein de la banque CrĂ©dit Mutuel ArkĂ©a pendant six ans, Laurent est Ă©galement un serial entrepreneur. Agir est son maĂźtre mot : transformer les intentions en action !

Un moyen trĂšs concret de partager les rĂ©ussites et difficultĂ©s de l’innovation dans de grandes organisations.

Une sĂ©quence d’Ă©changes et networking suivra ces deux retours d’expĂ©riences.

 

 

Articles suggested :

  1. Rejoignez le premier meetup « Start Me Up » le 28 Juin
  2. Appaloosa-Store, la filiale d’OCTO, s’exporte aux États-Unis !
  3. elCurator, la startup qui va booster votre veille !

Catégories: Blog Société

JIRA for project management teams

Le blog de Valiantys - mar, 09/27/2016 - 09:00

Back to the future    For some time, the tools used within project management have been in a bit of a catatonic state. Many individuals were given very few to no options when selecting the weapon of choice in the battle for project management victory. Often, the project management tool is an extremely light web application ...

The post JIRA for project management teams appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

dotGo revient le 10 octobre !

A Duchess Community Blog for France - mar, 09/27/2016 - 08:02

La saison des dotConfĂ©rences 2016-2017 commencera avec une nouvelle Ă©dition de la dotGo, le 10 octobre 2016 au ThĂ©Ăątre de Paris.Comme les autres dotConfĂ©rences, vous assisterez Ă  une journĂ©e de confĂ©rences totalement en anglais. La dotGo sera consacrĂ©e, comme son nom l’indique, au langage Go et rassemblera plus de 600 Gophers.

 

dotgo_speakers

Quelques speakers sont d’or et dĂ©jĂ  annoncĂ©s :

 

Les dotConfĂ©rences nous permettent …

Cet article dotGo revient le 10 octobre ! est apparu en premier sur Duchess France.

Catégories: Association

En exclusivité : La Keynote de la XebiCon se dévoile

xebicon

La XebiCon ’16 arrive Ă  grands pas !

L’annĂ©e derniĂšre, vous avez Ă©tĂ© nombreux Ă  apprĂ©cier la qualitĂ© des interventions, notamment celle d’Yves Caseau, Keynote d’ouverture, unanimement saluĂ©e comme trĂšs inspirante.

Et pour 2016 ?

Cette année, nous vous avons préparé une Keynote trÚs spéciale (et trÚs risquée pour nous).

En effet, j’ai demandĂ© aux Xebians de faire une dĂ©mo live de toutes les derniĂšres technologies que nous utilisons chez nos clients.

Ainsi, et pour couronner le tout, une maquette de train de 8m de long présente dans la salle servira de support pour vous présenter les innovations technologiques montrées au cours de cette keynote. Les déplacements seront filmés sur écran géant. Les choix et implémentations technologiques seront expliqués par Thibaud Cavin, Directeur de Xebia Studio et Pablo Lopez, CTO de Xebia.

DĂ©couvrez en 30 secondes ce qui vous attend lors de la keynote de la XebiCon’16 :

Envie d’ĂȘtre parmi nous ? Profitez des tarifs Early Bird jusqu’au 8 Octobre.

La XebiCon 2016 en chiffres 

1 journée, le 9 novembre 2016

700 personnes

51 conférences technologiques

13 retours d’experiences client

3 hands-on

et de nombreux temps d’Ă©change. 

Toutes les informations sur la conférence, le programme et la billetterie sont disponibles.

Catégories: Blog Société

William et Pierre, du stage à l’organisation du Hackathon JHipster

Blog d’Ippon Technologies - lun, 09/26/2016 - 16:56

Mercredi dernier dans les locaux d’Ippon s’est dĂ©roulĂ© le premier hackathon JHipster. Pierre Besson et William Marques, deux stagiaires JHipster dĂ©sormais consultants chez Ippon reviennent avec nous sur cette journĂ©e assez incroyable !

Waiting for people at the Paris JHipster hackathon! Breakfast is ready! pic.twitter.com/xcgmYKbgfn

— JHipster (@java_hipster) 21 septembre 2016

At the @java_hipster hackathon. This morning is about Angular2 and this afternoon I’ll try to integrate Consul and/or Swagger Maven plugin — Antonio Goncalves (@agoncal) 21 septembre 2016

Vous avez participĂ© Ă  l’organisation du hackathon JHipster, quel fut la genĂšse de cet Ă©vĂšnement ?

Pierre : Julien a trouvĂ© que le format des meetups Ă©tait trop court pour discuter de l’avenir de JHipster. Le hackathon pouvait ĂȘtre une rĂ©elle opportunitĂ© pour impliquer plus de monde sur une journĂ©e entiĂšre. Ce fĂ»t un vĂ©ritable succĂšs, les parisiens Ă©taient minoritaires, il y a eu des personnes de DubaĂŻ, Belgique, Lille, Bordeaux et mĂȘme un Java Champion (Antonio Goncalves) ! C’était impressionnant de voir des passionnĂ©s d’horizons variĂ©s, JHipster est vraiment utilisĂ© dans tous les secteurs d’activitĂ©, mĂȘme le gouvernement amĂ©ricain l’utilise !

I had so much fun today hacking on @java_hipster at the @ippontech hackaton.Great to meet other passionate Java Hipsters ! — Pierre Besson (@pibesson) 21 septembre 2016

William : J’ai eu l’occasion d’animer une partie du hackathon avec la migration sur Angular 2. Ce fut un grand moment d’échange. J’ai ainsi pu passer quelques heures avec des spĂ©cialistes du blockchain, ce fut trĂšs enrichissant !

Nous accueillons pour la journée un hackathon @java_hipster animé par @juliendubois avec @agoncal parmi les participants ! #Java #Dev #Code pic.twitter.com/vIJRD167Ux

— Ippon Technologies (@ippontech) 21 septembre 2016

Pouvez-vous nous raconter votre parcours Ă  Ippon ?


Pierre : J’ai voulu rejoindre Ippon pour travailler sur le projet JHipster avec Julien Dubois. Travailler dans l’Open Source permet de collaborer de façon totalement transparente, en plus du code ouvert, c’est tout le processus de dĂ©veloppement qui est public et ouvert aux contributions externes. J’ai intĂ©grĂ© l’équipe en janvier afin de travailler au support des  microservices dans JHipster. Nous avons mis en place une architecture orientĂ© microservices basĂ©e sur les stack Spring Cloud et Netflix Open Source et utilisant Docker. J’ai Ă©galement eu pour mission de participer au dĂ©veloppement du JHipster-Registry, un serveur permettant la dĂ©couverte et la configuration de services.

William : Je connaissais de nom JHipster, j’avais pas mal d’a priori sur les gĂ©nĂ©rateurs de code et ce stage m’a permis de changer d’avis sur le sujet ! GrĂące aux formations internes de Julien Dubois j’ai rapidement compris comment s’organise un projet Spring / AngularJS.

Ma premiĂšre mission fut de refactorer avec le style John Papa la partie front de JHipster.

Puis aprĂšs j’ai travaillĂ© avec Pierre et Julien sur la partie microservices et actuellement je travaille sur la migration vers Angular 2.

Vous avez d’ailleurs eu l’occasion de prĂ©senter votre travail Ă  un Meetup JHipster


William : Ce fut une superbe expĂ©rience, Ă  l’avenir j’aimerais prĂ©senter des Ippedejs et pourquoi pas des Ippevents !

La salle Jobs est pleine Ă  craquer pour le #meetup @java_hipster @juliendubois #Paris #Devoxx #java #dev pic.twitter.com/58FMKU576I

— Ippon Technologies (@ippontech) 11 avril 2016

AprĂšs vos missions sur JHipster vous avez eu l’opportunitĂ© de contribuer au projet Data MC, quelles ont Ă©tĂ© vos missions ?  

Pierre : Nous avons dĂ©veloppĂ© la console d’administration de DataMC qui est une application fullstack dĂ©veloppĂ©e Ă  l’aide de JHipster et intĂ©grĂ© Ă  Blackfish, le socle d’orchestration de cette plateforme big data.  

Vous avez apprécié travailler en binÎme sur ces différentes projets ?  

William : Pierre est plus back, je suis plus front donc on est trÚs complémentaires !  

Quel fut le bilan de votre stage ? Pierre : TrĂšs positif, j’ai appris beaucoup de choses sur l’utilisation des frameworks, comment travailler sur l’open source avec des communautĂ©s externes, comment travailler avec des contributeurs Ă©trangers… Les Ippons sont trĂšs expĂ©rimentĂ©s, il y a un gros potentiel au niveau de la technique.  

We have @saturnism from Google US coming to see @pibesson at the @ippontech office! pic.twitter.com/dzEOwZjNLD — Julien Dubois (@juliendubois) 22 avril 2016

L’esprit Ippon pour vous c’est quoi ?

Willian : Il y a vraiment un esprit d’entraide, mĂȘme les gens en mission participent aux discussions sur les diffĂ©rents rĂ©seaux. C’est une boite Ă  taille humaine. L’équipe commerciale sait prendre en compte mes envies et mes compĂ©tences. J’ai intĂ©grĂ© en septembre Ippon en CDI et je participe Ă  des missions passionnantes dans des secteurs trĂšs variĂ©s.

Un grand bravo Ă  nos trois gagnants du concours de pronostics #Euro2016 #WeAreIppon https://t.co/XT4coXC90V pic.twitter.com/6fLUQY3Qgh — Ippon Technologies (@ippontech) 4 aoĂ»t 2016

Catégories: Blog Société

Formation aux Techniques d’Animation de RĂ©unions CrĂ©atives

animations-reunions-2La semaine passĂ©e, j’ai eu la chance d’animer une formation avec @romaincouturier en intra pour un client du sud de Lyon. Nous pensions avoir une 20aine de personnes, d’oĂč la co animation, et comme il est toujours difficile de rĂ©unir autant de personnes, aprĂšs quelques dĂ©sistements, ce sont 13 individus trĂšs motivĂ©s qui se sont retrouvĂ©s avec nous pour 2 jours sur les Techniques d’Animation de RĂ©unions CrĂ©atives.

Je pense que les participants ont vraiment vécu un moment magique, avec beaucoup de plaisir, le tout rythmé par quelques fous rires.

 

animations-reunions

Nous avions prĂ©parĂ© un programme en 4 temps, avec des techniques d’animation de rĂ©union, des ateliers ludinnovants, de la facilitation graphique et des Ă©changes sur la posture de l’animateur.

Notre objectif Ă©tait de faire pratiquer et d’apprendre l’animation des rĂ©unions afin que les participants soient autonomes pour animer un atelier lors de leur sĂ©minaire prĂ©vu en dĂ©cembre.

 

Si les techniques d’animation de rĂ©union comme le World CafĂ© ou le Fishbowl ont Ă©tĂ© trĂšs apprĂ©ciĂ©es, les participants ont largement plĂ©biscitĂ© le TRIP et les DESSINS.

Les commentaires en fin de session Ă©taient explicites :

  • Demain, je commence Ă  TRIPer
  • Demain, je fais des dessins dans mes comptes-rendus
  • Demain, j’arrĂȘte de m’ennuyer en rĂ©union
  • Demain, je me jette Ă  l’eau en animant une rĂ©union crĂ©ative
  • Demain, je dessine au travail
  • Demain, j’arrĂȘte de m’autocensurer
  • Demain, je fais TRIPer mon Ă©quipe en rĂ©union
  • Demain, je continue de faire des slides … mais plus fun :)
  • Demain, je vais diminuer le nombre de rĂ©unions assises

Et cerise sur le gĂąteau :

  • Je n’ai jamais vu les participants utiliser aussi peu leur tĂ©lĂ©phone durant 2 jours !

Intéressez par en apprendre autant, dites le moi et cela nous donnera une raison supplémentaire pour monter une session en inter-entreprise avec Romain en 2017.

Catégories: Blog Individuel

Meetup JHipster le 29 septembre

Blog d’Ippon Technologies - lun, 09/26/2016 - 13:26

Ippon Technologies reçoit dans ses locaux parisiens, le 29 Septembre 2016, le 5Úme Meetup JHipster. Il sera animé par Julien Dubois, Chief Innovation Officer chez Ippon Technologies, et surtout créateur et principal développeur de JHipster.

Au menu, retour d’expĂ©rience d’un “grand” utilisateur : Orange !

Ludovic Chanal (leader technique Java et AngularJS) et Valentin Magne (dĂ©veloppeur fullstack) nous expliqueront comment JHipster a permis d’offrir aux conseillers clients des smart store Orange le SI sur une tablette iPad.

Puis ensuite, Julien Dubois nous fera un retour sur l’un de ces projets en cours qui traite de Data vizualisation avec Kafka & Websockets.

Informations pratiques :

3 mars 2016 Ă  partir de 19h00

47 avenue de la grande armĂ©e – 75116 Paris

MĂ©tro : Argentine

Catégories: Blog Société

Assistez Ă  notre concours de programmation maison : le SOAT Challenge

CĂ©cile Hui-Bon-Hoa et David Wursteisen vous donne rendez-vous le 20 octobre ! L’objectif de ce challenge est simple : produire le meilleur algorithme capable de rĂ©soudre un problĂšme spĂ©cifique. Pas de contraintes de langage imposĂ©, seul ou en Ă©quipe, Ă  toi de jouer ! Si vous ĂȘtes en manque de challenge, que vous souhaitez montrer […]
Catégories: Blog Société

Formats et méthodes de sérialisation REST

Blog d’Ippon Technologies - lun, 09/26/2016 - 09:00

Les services Web sont devenus prĂ©pondĂ©rants dans les architectures techniques actuelles, les notions de micro-services et de services API-first en sont l’exemple parfait. Bien souvent lors de la crĂ©ation de ces services, nous ne rĂ©flĂ©chissons que trĂšs peu au format d’échange, nous avons tendance Ă  utiliser des messages sĂ©rialisĂ©s en JSON ou en XML par simplicitĂ© et habitude. NĂ©anmoins, la multiplication des services Web qu’une entreprise possĂšde et la communication entre ces derniers peut rapidement crĂ©er des situations problĂ©matiques lors de montĂ©es en version ou de crĂ©ation d’un nouveau service. Il faut donc prendre en compte plusieurs facteurs afin de dĂ©terminer la solution technique Ă  utiliser pour la crĂ©ation d’un service :

  • la facilitĂ© d’utilisation,
  • la flexibilitĂ©,
  • le support (communautĂ© ou entreprise),
  • la performance.

Il faut en effet ĂȘtre capable de mettre rapidement la solution en place, de pouvoir l’utiliser avec diffĂ©rents langages selon le contexte, de disposer d’une communautĂ© suffisamment large soutenant le produit (ou une entreprise) et ĂȘtre performant afin de rĂ©pondre le plus rapidement possible.

Dans cet article nous allons parler des diffĂ©rentes autres possibilitĂ©s qui s’offrent Ă  vous lors du choix du format de sĂ©rialisation de vos services Web et comment choisir le format correspondant Ă  vos besoins.

Pourquoi changer ?

Il existe de trĂšs nombreux formats de sĂ©rialisation : JSON, SOAP, XML-RPC, Protocol Buffers, Avro, Apache Thrift, etc. Historiquement, les premiers schĂ©mas utilisĂ©s dans les applications de service (Ă  grande Ă©chelle) sont apparus avec des formats SGML (via DTD), XML (via XSL), etc. Le protocole SOAP par exemple permet de valider les donnĂ©es transitant, mais il pose un problĂšme de lourdeur de crĂ©ation et d’utilisation de l’application. En effet, la rigiditĂ© et la verbositĂ© du XML entraĂźne des surcoĂ»ts au niveau du dĂ©veloppement. Notamment au niveau des tests oĂč la construction des requĂȘte peut nĂ©cessiter l’utilisation de programme extĂ©rieurs comme “SOAP UI” par exemple. C’est une des raisons qui a entraĂźnĂ© l’ascension du JSON, bien plus clair, mais qui oublie un peu l’aspect validation. Le JSON, trĂšs largement utilisĂ© dans les Ă©changes entre services, a permis de mettre en lumiĂšre de nombreuses solutions de sĂ©rialisation lĂ©gĂšres et sĂ©curisantes. Pour toutes ces raisons, nous n’Ă©tudierons pas le format XML dans cet article. On peut alors se poser la question du changement de format.

Les contrats de service…

Lors de la crĂ©ation d’un service Web utilisant des donnĂ©es plus ou moins complexes, il est nĂ©cessaire de dĂ©finir les types d’objets Ă©changĂ©s. Bien souvent, il faut crĂ©er les classes reprĂ©sentant ces objets et c’est directement en lisant le code source que l’on obtient des informations sur leur contenu. L’utilisation de schĂ©mas permet de reprĂ©senter les donnĂ©es transitantes de maniĂšre simple et comprĂ©hensible par le plus grand nombre. C’est un moyen efficace de savoir quel objet est obtenu ou attendu par n’importe quel utilisateur du service. On peut ainsi dĂ©finir les objets transitants de façon plus structurĂ©e et donner plus de sens Ă  la donnĂ©e tout en facilitant la comprĂ©hension.

On peut aussi parler des fonction de dĂ©finition de contraintes Ă  appliquer sur chaque champ. Ces contraintes portent sur plusieurs aspects comme le type, le nombre d’occurrences ou les cardinalitĂ©s et les restrictions de champs obligatoires. On peut ainsi dĂ©finir des modĂšles de donnĂ©es structurĂ©es et les valider au runtime sans avoir Ă  Ă©crire des lignes de code dans chaque application (sĂ©rialisation / dĂ©sĂ©rialisation des donnĂ©es). On Ă©vite l’écriture de code de validation et on s’abstrait encore un peu plus du langage de programmation pour permettre au plus grand nombre de consommer ou produire pour notre service Web.

Le JSON dispose d’un systĂšme de schĂ©ma avec json-schema par exemple. Mais cette solution est trĂšs basique et ne procure pas de solution de gestion de contrat de service avancĂ©.

Et leur usage avancé

Ainsi de nombreuses autres fonctionnalitĂ©s accompagnent l’utilisation des contrats de service avec certains nouveaux formats de sĂ©rialisation. Il existe par exemple des mĂ©canismes d’enregistrement de schĂ©mas pour ne pas avoir Ă  dupliquer les schĂ©mas de chaque cĂŽtĂ© (client / serveur) du service et ainsi faciliter encore plus leur partage et leur utilisation.

De mĂȘme les formats comme Avro permettent de gĂ©nĂ©rer des classes d’accĂšs aux donnĂ©es s’adaptant au schĂ©ma ce qui peut simplifier l’utilisation.

La plupart des technologies que nous allons dĂ©crire disposent d’un systĂšme d’Ă©volution de schĂ©ma. Ce systĂšme permet par exemple de dĂ©finir de nouveaux champs attendus par un service Web, pour ajouter une fonctionnalitĂ© par exemple, sans impacter les client du service. Cela Ă©limine tous les codes basĂ©s sur une version donnĂ©e et notamment les imbrications de “if” permettant de traiter chaque version. Cela permet de limiter les modifications bloquantes sur les types des champs ou encore le respect des contraintes entre les diffĂ©rentes Ă©volutions d’un mĂȘme schĂ©ma. En effet, la plupart du temps, un champ marquĂ© comme requis ne peut pas devenir optionnel dans une nouvelle version du schĂ©ma (Ă  moins de changer complĂštement le type de retour). Un utilisateur d’une ancienne version du schĂ©ma sera toujours en capacitĂ© d’envoyer des donnĂ©es grĂące Ă  cette contrainte. C’est ce qu’on appelle de la rĂ©tro-compatibilitĂ©. C’est donc un outil trĂšs utile mais aussi dangereux : il ne faut pas tout dĂ©clarer en required sous peine d’obtenir un schĂ©ma peu flexible ! Par exemple, si on ajoute un champ required, il faut que tous les utilisateurs l’aient prĂ©alablement inclus pour Ă©viter une erreur de validation de schĂ©ma (cette fonctionnalitĂ© a d’ailleurs disparue dans proto3).

Mise en place des solutions

En se basant sur la partie prĂ©cĂ©dente nous allons donc comparer trois formats actuels : le JSON, Protocol Buffers et enfin Avro. Pour comparer les diffĂ©rentes mĂ©thodes, l’idĂ©e est simple. On va utiliser deux applications Java, une serveur et une cliente, exposant quelques mĂ©triques pour la performance. Nous mesurerons principalement les temps d’exĂ©cution Ă  divers instants de l’application et la taille des messages HTTP. Nous utiliserons Spring Boot pour ces applications et le message envoyĂ© sera une map contenant un type complexe (des personnes).

protocols_app

On a ajoutĂ© un filtre sur les requĂȘtes HTTP permettant de rĂ©cupĂ©rer la taille du contenu.

@Configuration
public class Filter {

    /**
     * Filter used to add various header to http responses.
     * We are particularly interested by the content-length.
     */
    @Bean
    public FilterRegistrationBean filterRegistrationBean() {
        FilterRegistrationBean filterBean = new FilterRegistrationBean();
        filterBean.setFilter(new ShallowEtagHeaderFilter());
        filterBean.setUrlPatterns(Collections.singletonList("*"));
        return filterBean;
    }
}

On utilisera la mĂȘme application (en modifiant l’utilisation du protocole) afin de valider les diffĂ©rences entre les solutions.

JSON

Commençons par la solution la plus conventionnelle pour la crĂ©ation d’une API, l’utilisation du JSON. Aujourd’hui le JSON est roi et ce pour plusieurs raisons :

  • Facilement lisible pour les humains et trĂšs facile Ă  mettre en place,
  • Multi-langage / plateforme, actuellement des parseurs sont disponibles pour la grande majoritĂ© des langages de programmation.

Pour retourner des valeurs sous forme de JSON il suffit de crĂ©er un objet Java. Par dĂ©faut dans Spring Boot c’est le Jackson2HttpMessageConverter qui est utilisĂ© pour sĂ©rialiser l’objet JSON pour le message HTTP.

Voici le contrĂŽleur permettant de retourner du JSON:

@RestController
public class Controller {

    private ObjectBuilder objectBuilder;

    @Autowired
    public Controller(ObjectBuilder objectBuilder) {
        this.objectBuilder = objectBuilder;
    }

    @RequestMapping(value = "/json", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public Map<String, JsonPerson> getJsonPeople(@RequestParam(required = false) Integer size) {
        return objectBuilder.jsonBuilder(size);
    }
}

Comme on peut le constater c’est on ne peut plus simple et c’est pourquoi on ne creuse souvent pas plus loin. Mais qu’en est-il des aspects performances ?

Protocol Buffer

Protocol buffer est Ă  l’origine un protocole dĂ©veloppĂ© par Google. Il permet de dĂ©finir des structures de message ou schĂ©mas et de les utiliser pour crĂ©er du contenu binaire de façon optimisĂ©e (le plus lĂ©ger possible). L’application cliente devra disposer du schĂ©ma pour rĂ©cupĂ©rer le contenu original. Voici le schĂ©ma .proto concernant notre modĂšle de test :

option java_package = "fgarcia.test.protocols.protobuf";
option java_outer_classname = "ContentProtos";

message Person {
    required string firstName = 1;
    required string lastName = 2;
    required string address = 3;
    required int32 age = 4;
    repeated string moreInfo = 5;
}

message MapEntry {
    required string key = 1;
    required Person value = 2;
}

message PeopleList {
    repeated MapEntry entry = 1;
}

Le format d’un fichier .proto est trĂšs simple. Il ressemble Ă  la dĂ©claration d’une structure en C par exemple. Il suffit de spĂ©cifier le package Java et le nom de la classe qui contiendra le code gĂ©nĂ©rĂ© et de spĂ©cifier le format des messages. Des mots clĂ©s tel que “required”, “optional” ou “repeated” permettent de donner des contraintes sur les schĂ©mas (attention Ă  la rĂ©trocompatibilitĂ©). Ici on a recrĂ©Ă© la structure de notre Map<String, Person> sous forme de schĂ©ma Protobuf.

Des plugins Maven existent pour permettre de gĂ©nĂ©rer les classes correspondant aux schĂ©mas et les classes gĂ©nĂ©rĂ©es permettent de crĂ©er des instances Ă  l’aide du pattern builder :

    /**
     * Create a single protobuf Person.
     */
    private ContentProtos.Person createProtoPerson(int i) {
        return ContentProtos.Person.newBuilder()
                .setFirstName("Foo " + i)
                .setLastName("Bar " + i)
                .setAge(i)
                .setAddress(i + " bar street Paris")
                .addAllMoreInfo(Arrays.asList("foo", "bar", "babar", "foofoo"))
                .build();
    }

Il suffit ensuite de configurer RestTemplate afin qu’il puisse sĂ©rialiser / dĂ©sĂ©rialiser les messages. C’est assez simple car la librairie protobuf-java intĂšgre le ProtobuffHttpMessageConverter.

@Bean
public RestTemplate restTemplate() {
    RestTemplate restTemplate = new RestTemplate();
    restTemplate.getMessageConverters().add(protobufHttpMessageConverter());
    restTemplate.getMessageConverters().add(avroHttpMessageConverter());
    return restTemplate;
}

@Bean
public ProtobufHttpMessageConverter protobufHttpMessageConverter() {
    return new ProtobufHttpMessageConverter();
}
Avro

Avro, Ă  l’instar de Protocol Buffer, utilise des schĂ©mas pour convertir le texte en contenu binaire (le plus lĂ©ger possible). Ce protocole est maintenu et dĂ©veloppĂ© par la fondation Apache et connaĂźt un grand essor. Il possĂšde la mĂȘme philosophie que Protocol Buffer. Contrairement Ă  ce dernier, il permet nĂ©anmoins de se passer de la gĂ©nĂ©ration de code pour les langages non typĂ©s et il permet de schĂ©matiser des appels RPC
 Il est utilisĂ© par divers acteurs importants, par exemple par la solution Confluent encapsulant le broker Kafka.

La crĂ©ation de schĂ©ma est cette fois uniquement utile pour les langages fortement typĂ©s. C’est le cas du Java, il faut donc dĂ©finir un schĂ©ma et utiliser un outil de gĂ©nĂ©ration de classes.

Le format de schĂ©ma est encore une fois assez simple. Il correspond en fait Ă  un JSON dĂ©crivant le schĂ©ma. Cela permet de faciliter l’utilisation des schĂ©mas avec des librairies existantes.

[{
 "namespace": "fgarcia.test.protocols.avro",
 "type": "record",
 "name": "Person",
 "fields": [
     {"name": "firstName", "type": "string"},
     {"name": "lastName",  "type": "string"},
     {"name": "address", "type": "string"},
     {"name": "age", "type": "int"},
     {"name": "moreInfo", "type": {"type": "array", "items": "string"}}
 ]
},
{
 "namespace": "fgarcia.test.protocols.avro",
 "type": "record",
 "name": "PeopleList",
 "fields": [
    {"name": "items", "type": {
        "type": "map", "values": "fgarcia.test.protocols.avro.Person"}
    }]
}]

On peut remarquer l’utilisation du type “record” ou encore “map” pour dĂ©finir des formats de contenu et l’utilisation de types simples pour dĂ©crire les valeurs que prendront chacun des champs. Les contraintes d’obligation de champs sont faites en fonction des types de ces derniers, si “null” est indiquĂ© alors le champ est optionnel.
AprĂšs gĂ©nĂ©ration du code Ă  l’aide d’un plugin Maven, on peut crĂ©er des objets Avro Ă  l’aide soit du pattern builder pour une validation automatique et une initialisation des variables ou bien de maniĂšre classique avec un constructeur.

/**
* Create a single avro Person.
*/
private Person createAvroPerson(int i) {
    return Person.newBuilder()
            .setFirstName("Foo " + i)
            .setLastName("Bar " + i)
            .setAge(i)
            .setAddress(i + " bar street Paris")
            .setMoreInfo(Arrays.asList("foo", "bar", "babar", "foofoo"))
            .build();
}

RestTemplate ne fournissant pas la compatibilité avec Avro, nous avons dû créer la classe AvroHttpMessageConverter. Implémentation de AbstractHttpMessageConverter, elle convertit les objets java en messages HTTP au format Avro. Cette implémentation est disponible sur GitHub.

Comparatif La facilitĂ© d’utilisation

Comme vu dans la partie prĂ©cĂ©dente, c’est de loin le JSON qui est le plus simple Ă  mettre en place. Il est utilisĂ© de façon native avec Spring Boot et ne nĂ©cessite pas de code spĂ©cifique. Protobuf et Avro requiĂšrent par contre quelques modifications au niveau sĂ©rialisation et dĂ©sĂ©rialisation. Elles sont nĂ©anmoins assez simples Ă  mettre en oeuvre. Il existe aussi des librairies permettant de faciliter la conversion de types (binaire => Avro par exemple) et qui rĂ©duisent la nĂ©cessitĂ© d’utiliser la gĂ©nĂ©ration de code. Bijection (librairie open source dĂ©veloppĂ©e par Twitter) rentre par exemple dans cette catĂ©gorie.

La flexibilité et support

En terme de flexibilitĂ©, c’est ex ĂŠquo pour les diffĂ©rents formats prĂ©sentĂ©s. Ils sont tous compatibles avec les langages de programmation majeurs, parfois mĂȘme avec des fonctionnalitĂ©s de prise en compte de schĂ©ma automatique avec les langages non typĂ©s par exemple.

Concernant le support, le JSON est universel et est le format par dĂ©faut sur Spring Boot, il est donc largement supportĂ© par la communautĂ©. On peut en dire de mĂȘme pour Avro qui est maintenu par la fondation Apache et dont la derniĂšre version date de mai 2016. Enfin Protobuf, historiquement crĂ©Ă© par Google est aujourd’hui sous licence libre et vient d’ĂȘtre releasĂ© en version 3.0.0.

Utilisation des contrats de service

Nous disions prĂ©cĂ©demment que les trois formats peuvent dĂ©finir des contrats de service mais avec une granularitĂ© diffĂ©rente. Pour le JSON c’est un support basique avec dĂ©finition et validation des donnĂ©es. 

 Pour Protobuf et Avro ce sont des solutions complĂštes. On dispose des fonctionnalitĂ©s de base auxquelles on peut ajouter un schĂ©ma registry, un systĂšme de versionning poussĂ© et des classes d’accĂšs simples gĂ©nĂ©rĂ©es Ă  partir des schĂ©mas. Il existe mĂȘme un framework pour effectuer du RPC avec Protobuf.

Performances

Sur 100 requĂȘtes contenant 1000 objets dans la map, nous obtenons les valeurs moyennes suivantes :

JSON JSON
(GZIP) Protobuf Protobuf
(GZIP) Avro Avro
(GZIP) Temps serveur (ms) 339,96 63,5 289,22 93,32 241,04 88,21 Temps client (ms) 6,52 8,43 21,68 24,64 10,29 12 Temps total (ms) 346,48 71,93 310,9 117,96 251,33 100,21 Taille (kilobytes) 132.3 74.6 63.9

Deux jeux de tests ont été effectués : un avec compression GZIP et un sans. Commençons par analyser le cas sans compression.

Pour le JSON on remarque donc que les messages sont assez volumineux et que le traitement total (temps serveur plus temps client) est d’environ 346ms. Les messages sont les plus volumineux de nos tests et le temps de traitement cĂŽtĂ© serveur est trĂšs long. Par contre le temps de dĂ©sĂ©rialisation et le traitement cĂŽtĂ© client sont trĂšs courts. C’est donc le facteur taille des messages qui conditionne le plus le temps serveur pour le JSON.

Pour Protobuf on remarque que les messages sont un peu moins volumineux et que le traitement total est lĂ©gĂšrement plus court (310ms). La taille des messages influe sur le temps de traitement cĂŽtĂ© serveur qui est plus rapide mais la dĂ©sĂ©rialisation cĂŽtĂ© client est en revanche bien plus longue (quasiment 4 fois plus long que le JSON). C’est donc un facteur Ă  prendre en compte, Ă  savoir si augmenter le traitement du client est acceptable.

Avro crĂ©e les documents les plus petits et dispose du temps de traitement total le plus faible (251ms). Le temps de traitement cĂŽtĂ© client est plus long que pour le JSON mais le temps de transfert serveur est bien plus court. C’est donc la solution la plus performante de ce comparatif. Elle peut ĂȘtre trĂšs intĂ©ressante dans le cadre d’applications mobiles en Javascript par exemple car elle rĂ©duit grandement la taille des objets transfĂ©rĂ©s, ce qui est fondamental pour les connections mobiles.

Si l’on prend en compte la compression GZIP, tout bascule. Le JSON profite Ă©normĂ©ment de la compression des donnĂ©es pour une trĂšs lĂ©gĂšre augmentation du coĂ»t de dĂ©sĂ©rialisation. Ce gain est bien plus significatif que pour les autres formats car la taille de l’objet permet d’avoir un rĂ©el impact sur le coĂ»t rĂ©seau. Il est important pour les autres formats mais ces derniers ont dĂ©jĂ  optimisĂ© leurs contenus binaire, l’impact est donc moindre.

Ainsi en terme de performance pure on obtient le classement suivant :

  1. Json Gzippé
  2. Avro Gzippé
  3. Protobuf Gzippé
  4. Avro
  5. Protobuf
  6. Json
Conclusion

On peut dire qu’il n’y a pas de solution miracle. Il faut utiliser le bon outil en fonction du besoin. Le JSON est un format qui a fait ses preuves et qui a la grande force d’ĂȘtre trĂšs lisible, et ce directement au sein du navigateur. Ce format est quasi parfait pour tous les points mais est trĂšs basique dans son utilisation et peut montrer des limites dans des entreprises de taille importantes ou la multiplication des services demande l’utilisation de fonctions avancĂ©s de contrats de service.

Protobuf contrairement Ă  la sĂ©rialisation du JSON envoie du binaire, sa lisibilitĂ© est donc rĂ©duite. Il est dĂ©pendant d’un schĂ©ma et cela lui confĂšre de bien meilleures performances que le JSON (en non GzippĂ©) mĂȘme s’il est assez lourd au niveau dĂ©sĂ©rialisation (cĂŽtĂ© client). C’est un facteur Ă  prendre Ă  compte pour le choix du format.

Pour finir, Avro pousse un peu plus loin que Protobuf avec des schĂ©mas Ă©crits en JSON pour la lisibilitĂ© et la facilitĂ© d’utilisation. Cela semble ĂȘtre la meilleure alternative si l’on dĂ©cide de s’éloigner du JSON pour gagner en industrialisation et en fiabilitĂ© en perdant le moins de performance et en sacrifiant un peu de simplicitĂ© et de lisibilitĂ© (format binaire).

On ne connait pas encore les formats qui vont emmerger dans le futur, Protobuf et Avro permettent de s’affranchir du langage et du format pour la transition des donnĂ©es et est notamment utile pour la communication dans des systĂšmes distribuĂ©s (comme  HDFS par exemple). Protobuf et Avro entrent aussi en rĂ©sonance avec l’émergence des technologies d’enregistrement de schĂ©mas et de validation des applications de services. Ce sont des outils qui permettent de mutualiser les schĂ©mas des protocoles afin qu’ils soient utilisĂ©s par diffĂ©rentes Ă©quipes, avec diffĂ©rents langages de programmation. Ainsi on valide les donnĂ©es transitant et on Ă©vite les incohĂ©rences lors de mises Ă  jour de contenu (les schema-registry assurent la rĂ©trocompatibilitĂ©). Le changement de format de donnĂ©es permet donc d’apporter plus que la performance. Comme avec SOAP par le passĂ© on dispose donc maintenant de moyens de garder un aspect validation du format de contenu avec des performances aussi bonnes voire meilleures que le standard JSON. MĂȘme si ce n’est pas le cas dans les exemples de l’article, il existe des dizaines de formats de sĂ©rialisation, plus ou moins connus ou supportĂ©s, il est nĂ©anmoins peu intĂ©ressant d’en comparer des centaines. Vous pouvez tout de mĂȘme trouver des comparatifs de performance (uniquement) ici par exemple.

L’ensemble du code source est disponible ici : https://github.com/garciafl/protocols

Sources:

Catégories: Blog Société

En une image : Pourquoi l’agilitĂ© ne fonctionne pas

Cargo Culte Agile


Et vous ? À quels cultes participez-vous ? 

 

Origine du « culte du cargo » : Au XXe siĂšcle, des aborigĂšnes MĂ©lanĂ©siens crurent que les provisions reçues par leurs colonisateurs via avions-cargo étaient dues Ă  une faveur divine invoquĂ©e par le biais de leurs antennes radios !

Ils construisirent alors des imitations de ces antennes en espĂ©rant eux aussi profiter de cette faveur divine…

Explication du "culte du cargo"

Force fut alors de constater qu’il ne suffisait pas d’imiter les pratiques et coutumes apparentes d’autrui pour obtenir les mĂȘmes rĂ©sultats !

 

Originellement publié sur bloculus.com
 

Articles suggested :

  1. Compte-rendu du Petit-déjeuner Culture Hacking ou comment changer le changement ?

Catégories: Blog Société

Garde fou

Une discussion lancĂ©e par @gregalexandre avec @xnopre sur les gardes fous… et TDD.
Mettre en place des garde-fous génÚre des comportements de fou
@pierre_fauvel:@gregalexandre precise
@gregalexandre:@pierre_fauvel qu’est-ce que ça t’inspire ?
@pierre_fauvel:@gregalexandre Sentiments mĂȘlĂ©s. S’il s’agit de crĂ©ativitĂ© ou de dynamique coll. je plussoie. Dans d’autres contextes je suis moins pour.[1]
*1@gregalexandre:@pierre_fauvel l’effet pervers des cadres de contrĂŽle qui peuvent dĂ©responsabiliser voir lĂ©gimiter de mauvais comportements.[2]
*2@pierre_fauvel:@gregalexandre en koi un cadre legitime-t-il un mauvais comportement ? Un exemple ?
@gregalexandre:@pierre_fauvel exemple : mĂ©comprĂ©hension du rĂŽle de Scrum Master gardien du cadre, en posture haute qui fait que…
@gregalexandre:@pierre_fauvel …l’Ă©quipe n’est plus responsable de son cadre. SM pas lĂ , plus de cadre. C’est normal c’est lĂ©gitime[3]
*3@pierre_fauvel:@gregalexandre mais je te rejoins : poser une regle deresponsabilise un peu.
@gregalexandre:@pierre_fauvel je prĂ©ciserais par « SE FAIRE IMPOSER une rĂ©gle dĂ©responsabilise un peu » :)
@pierre_fauvel:@gregalexandre oui, par le sm ou par le service qualitĂ©. On ne se l’approprie pas, on ne se sent pas responsable
@gregalexandre:@pierre_fauvel exemple : DoD dĂ©finie par le service qualitĂ©, le contrat de prestation, le kit de dĂ©marrage agile d’une entreprise…[4]
*4@pierre_fauvel:@gregalexandre les dod predefinies, kits de demarrage sont Ă  remplacer par une bonne formation et biblio et une capi des projets exemplaires
@gregalexandre:@pierre_fauvel aha, qu’est-ce qu’un projet exemplaire ? Les pratiques d’un projet, mĂȘme exemplaire, peuvent elles ĂȘtre appliquĂ©es Ă  tous ?
*4@pierre_fauvel:@gregalexandre l’equipe presta doit se sentir engagee par le contrat de prestation sinon la prestation va mal se passer
*3@pierre_fauvel:@gregalexandre dans garde fou je vois « mettre une limite a un espace de libertĂ© » pas « organisation fine de l’espace »
@gregalexandre:@pierre_fauvel mea culpa sur le deuxiĂšme exemple. Oui garde fou = ce qui empeche de faire des folies, des imprudences[5]
*5@gregalexandre:@pierre_fauvel c’est marrant mais je me rends compte que ma phrase peut servir d’argument pour les anti-TDD…[6]
*6@pierre_fauvel:@gregalexandre tdd est un garde fou qui permet de faire des refactorings profonds sans risque
*6@gregalexandre:@pierre_fauvel … j’ai dĂ©jĂ  entendu que le pb du test Ă©tait que les dĂ©veloppeurs diminuaient leur vigilance…
@pierre_fauvel:@gregalexandre jamais vu moins de bug que dans une equipe full tdd
@gregalexandre:@pierre_fauvel ah, encore un lien de comportement. Dans quelle mesure faire du full TDD s’inscrit-il dans une volontĂ© de faire du bon code ?
@pierre_fauvel:@gregalexandre ben ca elimine les bugs et a plein de vertus ( conception basee sur le comportement )
@gregalexandre:@pierre_fauvel je veux dire : quand tu fais de la TDD, n’est-ce pas que tu es dĂ©jĂ  dans une recherche du meilleur livrable possible ?
@pierre_fauvel:@gregalexandre je pense qu’il y a un large spectre entre zero tdd et full tdd. Et que certaines habitudes de tdd tuent la vigilance
@gregalexandre:@pierre_fauvel y a-t-il des devs dans la salle qui aimeraient participer Ă  la discussion ? Qu’en penses-tu @xnopre ?[7]
*7@xnopre:@gregalexandre @pierre_fauvel Avec plaisir, mais Twitter risque de nous limiter
 « certaines habitudes de tdd tuent la vigilance » ???[8]
*8@pierre_fauvel:@xnopre @gregalexandre les habitudes tuent la vigilance, plus largement.
@gregalexandre:@pierre_fauvel @xnopre ouiiiii la discussion repart ! Est-ce que dans habitude (dans ce cas lĂ ) on peut parler de « tester le test » ?[9]
*9@xnopre:@gregalexandre @pierre_fauvel Je n’ai pas encore vu du #TDD mis en oeuvre au pt d’avoir des habitudes
 en encore – de tuer la vigilance[10]
*10@pierre_fauvel:@xnopre @gregalexandre ben par exemple ce qu’on choisit de ne pas tester parce que ca marche toujours
@xnopre:. @pierre_fauvel @gregalexandre Lorsque je propose aux Ă©quipe de ne pas tout tester, ce n’est jamais pour cette raison
 ;-)[11]
*11@pierre_fauvel:@xnopre @gregalexandre precise pour quelle raison ?
@xnopre:. @pierre_fauvel @gregalexandre Ne pas tester si on ne sait pas tester (IHM, framework, 
) mais dans ce cas, code minimum[12]
*12@gregalexandre:@xnopre @pierre_fauvel pas compris le « dans ce cas, code minimum »
@xnopre:. @gregalexandre @pierre_fauvel On ne sait pas tester une partie du code ? OK mais on y laisse un minimum du code …
@xnopre:. @gregalexandre @pierre_fauvel 
 et on sort tout le reste ailleurs en le couvrant par les TU ;-)[13]
*13@xnopre:. @gregalexandre @pierre_fauvel Tiens, un bon sujet d’article de blog 
 ;-)
@gregalexandre:@xnopre @pierre_fauvel que j’aurai plaisir Ă  lire :)
@xnopre:@gregalexandre @pierre_fauvel que je risque de ne pas avoir le temps d’écrire
 ;-)[14]
*14@pierre_fauvel:@xnopre @gregalexandre a defaut d’ecrire un article, et avec votre accord, je mettrai cette discussion sur mon blog.[15]
*15@xnopre:. @pierre_fauvel @gregalexandre Pourquoi pas, mais ça mĂ©riterait plus de dĂ©tails et d’arguments, impossible sur Twitter
 :-([16]
*16@pierre_fauvel:@xnopre @gregalexandre hangout publié sur youtube ?
@gregalexandre:@pierre_fauvel @xnopre as usual pour moi, je ferais un hangout youtube si on avait un dĂ©bat, lĂ  on est tous d’accord c’est moins fun
@xnopre:@gregalexandre @pierre_fauvel :-) 
 donc faut trouver des personnes moins ou pas d’accord 
 ;-)[17]
*17@gregalexandre:@xnopre @pierre_fauvel non je pense que ça peut ĂȘtre intĂ©ressant avec d’autres praticiens (chose que je ne suis pas)[18]
*18@pierre_fauvel:@gregalexandre @xnopre ca vaudrait la peine de faire un atelier : le meme kata avec des equipes en parallele, des strategies tdd différentes
@xnopre:@pierre_fauvel @gregalexandre Une idée intéressante à creuser ! ;-)
@xnopre:. @pierre_fauvel @gregalexandre Ou quelques praticiens qui rĂ©solvent chacun Ă  leur maniĂšre un mĂȘme Kata
@xnopre:. @pierre_fauvel @gregalexandre ProblĂšme, Ă©viter les influences, donc pourquoi pas via video-cast ?[19]
*19@pierre_fauvel:@xnopre @gregalexandre chacun dans son coin et on regarde les videos aprĂšs ?[20]
*20@xnopre:@pierre_fauvel @gregalexandre Oui, pour Ă©viter les influences, sinon le premier Ă  passer pourrait influencer les suivants, non ?[21]
*16@xnopre:@pierre_fauvel @gregalexandre Une idĂ©e de solution pour Ă©changer plus largement ? G+ ? …
@gregalexandre:@xnopre @pierre_fauvel un café ou Agile Grenoble ? :)
*10@xnopre:. @gregalexandre @pierre_fauvel De mes rencontres et interventions, le #TDD est trĂšs peu pratiquĂ© :-( , y’a encore du boulot ! …[22]
*3@gregalexandre:@pierre_fauvel ou encore : mise en place d’indicateurs de qualitĂ© de code (par une personne extĂ©rieure Ă  l’Ă©quipe)…
@gregalexandre:@pierre_fauvel …gĂ©nĂšre des techniques pour mettre l’indicateur au vert sans pour autant amĂ©liorer la qualitĂ© du code
@gregalexandre:@pierre_fauvel … aux yeux de l’Ă©quipe, ce comportement est lĂ©gitime face Ă  un indicateur qui parait abusif
*1@gregalexandre:@pierre_fauvel j’Ă©tais, de mon cĂŽtĂ©, plus sur la dynamique collective


Catégories: Blog Individuel

Gagne ta place pour Bdx.io

Blog d’Ippon Technologies - ven, 09/23/2016 - 13:47

Le 21 octobre 2016 Ippon sponsorise le Bdx.io.

 

Le Bdx.io est clairement LA journée bordelaise pour les développeurs sur les technologies de demain.

A cette occasion Ippon vous propose de gagner 3 places en participant à notre jeu concours !

Tentez votre chance jusqu’au 16 octobre, les rĂ©sultats seront annoncĂ©s par mail le 17 octobre.

icc_affiche_bdx-io-1

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux