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

Hackergarten printanier le 28 mars chez Xebia

Paris Hackergarten

Le printemps est là et avec lui bourgeonne le Paris Hackergarten. Venez coder et pique-niquer le 28 mars dans les locaux de Xebia, 156 boulevard Haussmann au 7e étage. Que vous fassiez du Java ou du Javascript, vous pourrez contribuer à de superbes projets open source.

Si vous ne connaissez pas le principe du meetup, voici quelques explications. Cette fois encore, nous réunirons les forces de futurs contributeurs motivés et de mentors brillants et pédagogues pour finaliser quelques améliorations ou corriger quelques bugs, le tout dans une ambiance détendue.

Au choix de ce mercredi :

Inscrivez-vous sur la page du meetup !

Catégories: Blog Société

Les Xebians seront de nouveau à Devoxx cette année.

Devoxx FranceDevoxx est LE rendez-vous incontournable pour tous les développeurs passionnés. Impossible donc que les Xebians ne soient pas de la partie.

En 2016, une dizaine de confĂ©rences Ă©tait prĂ©sentĂ©es par les Xebians. Pour les redĂ©couvrir, c’est par ici (ConfĂ©rences Xebia Ă  Devoxx 2016).

Plus d’un tiers des Xebians seront sur place pour vivre avec vous ces 3 jours intensifs de confĂ©rences, mais aussi partager leurs connaissances lors de 8 confĂ©rences. Pour suivre toute l’actualitĂ© des Xebians Ă  Devoxx, suivez #XebiaDevoxx sur Twitter.

Quelles conférences les Xebians vous préparent pour Devoxx 2017 ?

Cette année encore, les Xebians ne font pas les choses à moitié. Ils partagent encore et toujours lors de conférences sur leurs différentes expertises. Au programme :

Les Universités

L’année passée a vu converger les fonctionnalités des moteurs de conteneurs. L’enjeu de l’année à venir n’est plus sur les couches système mais bien sur l’orchestration des services. Nous vous proposons de comparer les trois orchestrateurs Mesos/Marathon, Swarm/Docker DC et Kubernetes au travers d’un cycle de vie devops : intégration continue, déploiement, “Infrastructure-as-Code” et exploitation.

Le mercredi 5 avril de 9h30 à 12h30.

Les Hands-On Lab

ElasticSearch vient avec un DSL très riche de requètage : recherche full text, recherche exact, analytiques, gĂ©olocalisation, « Search as you type »Â …
Nous vous proposons de venir découvrir avec ce hands-on, les possibilités offertes par ce moteur d’indexation en utilisant les différentes types de recherches proposées et en jouant sur le mapping.

Quelles requêtes pour quel besoin et comment les utiliser de manière efficace ?

Le mercredi 5 avril de 9h30 Ă  12h30.

Les conférences

L’Event Sourcing et CQRS sont sur toutes les lèvres en cette année 2017 qui marque l’avènement des systèmes dits « réactifs » ou « dirigés par les évènements ». Bien que leur présence ne date pas d’hier, peu d’applications en tirent aujourd’hui bénéfice.

Dans ce retour d’expérience, nous allons vous présenter dans le détail et en toute transparence, l’implémentation mise en place au sein d’une grande banque d’investissement française, ses avantages, ses inconvénients, ses compromis et les leçons que nous avons en tiré. Nous espérons vous donner ainsi le bagage nécessaire pour vous lancer à votre tour dans la grande aventure du réactif.

Le vendredi 7 avril de 12h55 à 13h40.

Nous proposons de jouer une mini pièce de théâtre montrant des questions et rĂ©ponses de la vraie vie lors d’une transformation vers l’Agile. Les rĂ©sistances sont nombreuses, les arguments anti-agile difficiles Ă  contrer et l’Ă©tat d’esprit pas toujours facile Ă  synthĂ©tiser et vulgariser. En jouant une suite de petites mises en situation de façon humoristique, nous dĂ©dramatisons le changement, et offrons au public des clĂ©s pour convaincre.

Le vendredi 7 avril de 17h10 à 17h55.

Quand Swift a Ă©tĂ© annoncĂ© en 2014, personne n’aurait imaginĂ© qu’un jour on aurait pu se servir de ce langage pour rĂ©aliser une application… cĂ´tĂ© serveur !

Ce talk a pour but de dĂ©montrer comment et dans quelle mesure nous pouvons Ă©crire et deployer une application Web en utilisant Swift 3.0, en utilisant les plates-formes proposĂ©es par le marchĂ©. Nous dĂ©couvrirons Ă©galement les forces et faiblesses actuelles, les frameworks et les outils Ă  utiliser aujourd’hui, ainsi que les extensions pour connecter notre application Swift cĂ´tĂ© serveur Ă  des services tierces, tels que les systèmes de gestion de base de donnĂ©es.

Le vendredi 7 avril de 16h10 à 16h55.

Le Tools in action

Vous trouvez que vous passez trop de temps Ă  prĂ©parer vos machines lors de vos dĂ©mos ? Vous organisez des formations mais vous avez du mal Ă  fournir Ă  vos Ă©lèves des environnements complets et identiques ? Grâce à Terraform, vous pourrez rĂ©pondre par la nĂ©gative Ă  toutes ces questions. Terraform est un outil d’infra-as-code dĂ©claratif et open source tout droit sorti des laboratoires HashiCorp. Il est Ă  la fois simple et puissant et s’interface très bien avec les fournisseurs de services cloud les plus populaires. Dans ce Tools in Action, nous verrons ensemble comment un dĂ©veloppeur peut simplement et rapidement mettre en place l’infrastructure dont il a besoin grâce Ă  Terraform, un peu d’Ansible et de services managĂ©s.

Le jeudi 6 avril de 18h10 à 18h40.

Les quickies

La loi de Conway nous explique que les organisations sont contraintes Ă  produire des designs copiĂ©s sur leurs structures de communication. Quand Melvin Conway a Ă©tabli cette thĂ©orie en 1967, il ne se doutait sans doute pas de la puissance de son constat. Il est aujourd’hui recommandĂ© de maitriser ce concept avant d’organiser vos Ă©quipes et les aider Ă  devenir DevOps. Je vous propose d’Ă©tudier quelques cas concrets qui vous permettront de comprendre les rĂ©percussions de vos choix d’organisations sur vos Ă©quipes IT et sur leurs livrables.

Le jeudi 6 avril de 12h05 à 12h20.

Dans sa version 2016.3, IntelliJ IDEA propose une fonctionnalitĂ© d’auto-testing, qui permet la mise en place d’une couverture du code par les tests actualisĂ©e en temps rĂ©elle pendant que vous codez. Ça n’a l’air de rien, dit comme ça, mais ça va rĂ©volutionner l’acceptation du TDD dans vos Ă©quipes.

Au programme, configuration d’une couverture du code automatisĂ©e, dĂ©monstration , continuous Testing & TDD.

Le vendredi 7 avril de 12h05 à 12h20.

 

Vous souhaitez découvrir qui sont les Xebians ? Rendez-vous sur notre site vismavie.xebia.fr.

Et nous vous donnons rendez-vous dans quelques jours au Palais des Congrès,  pour rencontrer les 34 Xebians qui seront sur place. Comment les reconnaitre ? Toujours grâce à leurs polos violets !

Catégories: Blog Société

My Atlassian tips: The risk of not managing your technical contact

Le blog de Valiantys - jeu, 03/23/2017 - 15:00

With license management, the devil is in the details. We’ve seen clients who have lapsed in their renewal date because their technical contact was not handled properly – causing a major headache over what should be a minor task. To help you avoid shooting yourself in the foot, we’ll walk you through the who, why ...

The post My Atlassian tips: The risk of not managing your technical contact appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Revue de Presse Xebia

Revue de presse de XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité Android O : developer preview http://www.gravatar.com/avatar/63d261113651caa0dc887445c61ea48ahttp://blog.xebia.fr/author/blacroixhttp://twitter.com/benjlacroixhttp://github.com/blacroixPar Benjamin Lacroix

La nouvelle version du système Android sera sous doute présentée à la Google IO en mai 2017. Google propose déjà une version Android O Developer Preview. La version est compatible Nexus et Pixel. Android O introduit des nouveautés concernant notamment :

  • L’exĂ©cution en tâche de fond (pour l’optimisation de la batterie) ;
  • La gĂ©olocalisation en tâche de fond (toujours pour optimiser la batterie) ;
  • Le bluetooth ;
  • La navigation (pour rendre Android plus cohĂ©rent avec les applications Chrome OS) ;
  • SĂ©curitĂ© (SECCOMP pour toutes les applications) ;
  • FenĂŞtres d’alertes (pour prĂ©venir l’utilisateur d’une information importante).

Google semble s’intĂ©resser principalement Ă  l’optimisation de la batterie et Ă  la sĂ©curitĂ©

Front Webpack-blocks : simplifiez votre configuration http://www.gravatar.com/avatar/1e0ca9963bcd96ba434e5e4ffd972c2fhttp://blog.xebia.fr/author/aletaxin1http://twitter.com/ModuloMhttp://github.com/ModuloMPar Antoine Le Taxin

Pour ceux d’entre-vous qui utilisent quotidiennement Webpack, vous savez que le fichier de configuration peut vite devenir important et obscure pour les non-initiĂ©s. webpack-blocks propose de simplifier la maintenance, la lisibilitĂ© et la prise en main de vos configurations. Il permet d’utiliser les loaders au travers de modules qui abstraient leurs complexitĂ©s. Cela facilite notamment la migration vers Webpack 2 : la seule action nĂ©cessaire sera de changer la version du module concernĂ©, sans avoir Ă  modifier votre implĂ©mentation. Dan Abramov lui-mĂŞme a saluĂ© l’initiative, un signe qui devrait vous encourager Ă  y jeter un Ĺ“il.

Observables natifs en Javascript http://www.gravatar.com/avatar/1e0ca9963bcd96ba434e5e4ffd972c2fhttp://blog.xebia.fr/author/aletaxin1http://twitter.com/ModuloMhttp://github.com/ModuloMPar Antoine Le Taxin

La proposition du TC39 visant Ă  intĂ©grer les observables dans EcmaScript va passer de stage 1 au stage 2. Pour les utilisateurs de librairies comme RxJS ou Bacon.js et tous les partisans de la programmation rĂ©active, c’est une nouvelle intĂ©ressante. Pour s’informer dès aujourd’hui sur la syntaxe et l’utilisation de cette API, je vous conseille de parcourir cet article sur le sujet.

DevOps Retour sur  l’indexation des milliards de messages de Discord http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Les ingĂ©nieurs derrière la plateforme de chat textuel et vocal Discord ont publiĂ© il y a une semaine un retour d’expĂ©rience passionnant sur leur manière d’indexer Ă  des fins de recherche les milliards de messages qui sont passĂ©s et qui continuent de passer par leur application.

La solution retenue a Ă©tĂ© une implĂ©mentation très originale d’ElasticSearch. En effet, afin d’Ă©viter la complexitĂ© pouvant dĂ©couler de la gestion de très gros clusters, Discord ont dĂ©cidĂ© de crĂ©er plusieurs petits clusters ElasticSearch et de gĂ©rer la partie sharding en amont, cĂ´tĂ© applicatif. Ils se servent donc de Cassandra pour stocker les informations sur ce sharding (cluster + index) eux-mĂŞme, tout en y associant un Redis Ă  des fins de cache.

En y ajoutant leur utilisation d’etcd pour du service discovery et les prĂ©cisions donnĂ©es sur des aspects très opĂ©rationnels de la gestion de leurs clusters ElasticSearch au quotidien telle que « Quelles mĂ©triques remonter ? » ou encore « Comment choisir l’intervalle de rafraĂ®chissement des index ? », on obtient au final un retour d’expĂ©rience vraiment très concret, appuyĂ© sur des faits et dont on peut comprendre le raisonnement. En rĂ©sumĂ© : une lecture très intĂ©ressante Ă  conseiller Ă  quiconque souhaiterait en comprendre d’avantage sur les problĂ©matiques de gestion de bases de donnĂ©es distribuĂ©es !

Docker s’apprĂŞte Ă  cĂ©der containerd Ă  la CNCF http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard Solomon Hykes, le dĂ©sormais cĂ©lèbre fondateur et CTO de Docker, vient d’annoncer leur intention de cĂ©der containerd Ă  la Cloud Native Computing Foundation. Pour rappel, containerd est la brique utilisĂ©e par Docker et se basant sur runC, permettant de crĂ©er et de gĂ©rer le cycle de vie de conteneurs. La Cloud Native Computing Foundation (CNCF) est quant Ă  elle une fondation visant Ă  « hĂ©berger » l’organisation de projets, qu’on pourrait comparer Ă  la fondation Apache bien que cette dernière soit beaucoup plus procĂ©durière. La CNCF a notamment sous sa gestion des projets tels que Kubernetes, Prometheus ou encore gRPC. On se retrouverait donc au final avec d’une part runC, implementation du standard de l’Open Container Initiative, et de l’autre containerd, sous l’aile de la CNCF : de quoi assurer une certaine indĂ©pendance et standardisation au futur des conteneurs !
Catégories: Blog Société

3 dotConférences en Avril : dotSecurity, dotScale et dotAI 2017

A Duchess Community Blog for France - jeu, 03/23/2017 - 08:29

En Avril il y a Devoxx France, MiXiT mais Ă©galement les dotConfĂ©rences. Vous ne savez pas quoi faire fin Avril ? Venez assister Ă  des confĂ©rences sur la sĂ©curitĂ©, la scabilitĂ© et l’intelligence artificielle !

dotSecurity – le 21 Avril 2017

dotSecurity aura lieu au le 21 avril au Théâtre des Variétés dans le 2ème arrondissement à Paris.

Lors de cette conférence le thème de la sécurité sera abordé sous toutes ses coutures.

Des experts venus des 4 coins du monde vous expliqueront les concepts essentiels de la sĂ©curitĂ©, vous montreront des outils et des pratiques que tout …

Cet article 3 dotConférences en Avril : dotSecurity, dotScale et dotAI 2017 est apparu en premier sur Duchess France.

Catégories: Association

Agile smells – Sprint planning

agile_smells

Suite de la sĂ©rie d’articles consacrĂ©e aux Agile smells, je vous propose, au travers de situations rĂ©ellement vĂ©cues, de faire un tour d’horizon des dĂ©rives, des fausses bonnes idĂ©es ou simplement des phrases prononcĂ©es qui peuvent vous amener Ă  vous dire que quelque chose sent mauvais. Aujourd’hui, parlons du Sprint Planning…

Si vous avez manqué le premier épisode de la série des Agile smells, vous pouvez le retrouver ici :

« 4h c’est un peu long non ? » La situation

L’Ă©quipe organise Ă  chaque dĂ©but d’itĂ©ration un Sprint Planning dont la durĂ©e est au minimum d’une demi-journĂ©e.

Pourquoi ça sent mauvais ?

Les participants sortent généralement lessivés après de telles cérémonies. Au fur et à mesure des itérations, ils verront cela comme une contrainte supplémentaire.

L’intĂ©rĂŞt premier du Sprint Planning est la discussion, mais lorsqu’elle devient interminable elle ne sert Ă  personne. La principale explication de la durĂ©e est la mĂ©connaissance du sujet : l’Ă©quipe cherche Ă  comprendre pendant la rĂ©union et dĂ©bute des investigations techniques. Un sujet complexe multipliĂ© par un nombre de personnes important cherchant Ă  le rĂ©soudre vous donnera forcĂ©ment un temps de traitement Ă©levĂ©.

Concrètement on fait quoi ?

Trois axes pour rĂ©ussir l’objectif de cette cĂ©rĂ©monie :

  • L’organisation

Le temps de concentration maximum d’une personne ne dĂ©passe gĂ©nĂ©ralement pas une heure. Par consĂ©quent, plutĂ´t que d’avoir une seule grosse rĂ©union, il suffit de la dĂ©couper en plusieurs petites de maximum une heure :

    • Une Backlog Review lors de l’itĂ©ration N-1 ou N-2, qui permettra au Product Owner de prĂ©senter les stories de l’itĂ©ration N. L’Ă©quipe se contentant de poser des questions pour comprendre les fonctionnalitĂ©s, et de nommer une personne ou un binĂ´me qui fera l’analyse technique de son cĂ´tĂ©.
    • Un Sprint Planning, en dĂ©but d’itĂ©ration N, qui servira Ă  dĂ©battre sur la base des analyses techniques, dĂ©couper en tâches et estimĂ©e.
  • La prĂ©paration

Pour certaines Ă©quipes, le dĂ©coupage en tâches techniques se ressemble souvent. Pourtant elles vont passer du temps Ă  rĂ©Ă©crire ces post-it lors de la cĂ©rĂ©monie. Un conseil bĂŞte mais qui pour certaines Ă©quipes leur ont fait rĂ©duire la durĂ©e de 10% : prĂ©parez les post-it Ă  l’avance, ou mieux, rĂ©cupĂ©rez les anciens.

Venez Ă©galement avec un panel de stories dĂ©jĂ  implĂ©mentĂ©es et reprĂ©sentatives des diffĂ©rents niveaux de complexitĂ©. C’est une aide non nĂ©gligeable Ă  l’estimation qui peut vous Ă©viter des dĂ©bats inutiles.

  • La facilitation

Lors de l’estimation, ne laissez pas les discussions aller trop loin. De mĂŞme, ne recherchez pas Ă  tout prix un consensus. Contentez vous de deux tours durant votre planning poker et la deuxième fois prenez le chiffre qui est le plus reprĂ©sentĂ©. Ce ne sont que des estimations et leur valeur n’est donc pas primordiale.

« Oui c’est normal c’est elle l’experte » La situation

Durant le Sprint Planning, l’Ă©quipe passe son temps Ă  Ă©couter l’expert(e) technique. Que ce soit lors de l’analyse, du dĂ©coupage en tâches ou de l’estimation, ses commentaires et dĂ©cisions sont rarement remis en question.

Trust me I am an expert

Pourquoi ça sent mauvais ?

Cette situation peut cacher différentes choses :

  • Equipe non pluridisciplinaire

Une Ă©quipe agile idĂ©ale se caractĂ©rise par des individualitĂ©s pluridisciplinaires, pouvant donc aborder diffĂ©rents sujets sans pour autant en ĂŞtre l’experte absolue. Si la voix d’un(e) expert(e) ne trouve aucune rĂ©ponse, c’est certainement qu’il manque des contrepoids techniques au sein de l’Ă©quipe.

  • Manque de prĂ©paration

Il existe deux types de personnes : celles qui ont besoin de prĂ©parer un sujet afin de pouvoir exprimer une opinion par la suite, et celles qui sont Ă  l’aise avec l’improvisation. Si vous avez des personnes compĂ©tentes qui ont besoin de se prĂ©parer mais qui ne le font pas ou n’ont pas le temps de le faire, elles se contenteront d’Ă©couter sagement durant le Sprint Planning si elles ne sont pas sĂ»res de maĂ®triser le sujet abordĂ©. D’autant plus si c’est un(e) expert(e) qui s’exprime.

  • PersonnalitĂ© trop forte

La personnalitĂ© des Ă©quipiers joue Ă©galement un rĂ´le primordial dans la manière dont se dĂ©roule ce genre de rĂ©union. Une personnalitĂ© forte peut, au fil du temps, Ă©craser toutes les autres. Parler plus fort, remettre en cause les compĂ©tences sous un trait d’humour, rappeler des erreurs passĂ©es, ou avoir une communication agressive sont autant de signes indiquant un problème.

Concrètement on fait quoi ?

Une nouvelle fois, un Sprint Planning ça s’organise. Comme indiquĂ© dans le smell prĂ©cĂ©dent, la mise en place d’une revue de backlog doit vous permettre de rĂ©partir les analyses au sein de l’Ă©quipe. Il n’y aura donc plus d’excuse pour ne pas s’exprimer.

Analyser c’est bien mais si cela se fait en dehors du domaine de compĂ©tence de chacun, c’est complexe. C’est dans ce cadre, il est important de mettre en place des pratiques comme le pair programming, les revues de code ou les coding dojo. Au fil du temps, les compĂ©tences devraient se lisser de manière Ă  rendre autonomes les membres de l’Ă©quipe.

Enfin une idĂ©e radicale mais qui peut porter ses fruits dans certains cas : demandez Ă  l’expert(e) de venir en simple observateur. Le but est qu’il ne parle que dans le cas extrĂŞme d’un oubli remettant en cause entièrement ce qu’il s’est dit pendant la rĂ©union. Cela n’a pas pour but de rĂ©gler les problèmes de personnalitĂ©, mais plutĂ´t de redonner confiance au reste de l’Ă©quipe sur ses capacitĂ©s Ă  prendre des sujets et Ă  les responsabiliser davantage.

« Normalement ils vont nous livrer le bon catalogue cette semaine » La situation

La story que prĂ©sente le Product Owner est dĂ©pendante de la livraison d’un catalogue de donnĂ©es par une autre Ă©quipe. Cette Ă©quipe s’est engagĂ©e Ă  livrer ce catalogue quelques jours après le dĂ©but de l’itĂ©ration, ce qui normalement laisse largement le temps Ă  l’Ă©quipe de l’intĂ©grer et de rĂ©aliser sa story.

image-le-chat-patience

Pourquoi ça sent mauvais ?

Les choses ne se passent gĂ©nĂ©ralement pas comme prĂ©vu. Commencer l’itĂ©ration en dĂ©pendant du travail d’une autre Ă©quipe est un risque non nĂ©gligeable car il Ă©quivaut Ă  s’engager sur un pĂ©rimètre que l’on ne maĂ®trise pas. Si l’Ă©quipe gĂ©rant le catalogue a un changement de prioritĂ© suite Ă  un problème de leur cĂ´tĂ© ou si le catalogue qu’elle livre n’est pas de bonne qualitĂ© et qu’il y a d’innombrables allers-retours, alors c’est autant de chances de ne pas avoir le temps de terminer la story qui en dĂ©pend.

Concrètement on fait quoi ?

Dans le cas de dépendance entre équipes, il existe deux choix immédiatement applicables :

  • Attendre que la dĂ©pendance soit livrĂ©e avant d’intĂ©grer la story dans une itĂ©ration : il suffit alors d’allouer un certain temps pour effectuer quelques tests afin de valider la qualitĂ© de la dĂ©pendance.
  • Si le besoin d’avoir la fonctionnalitĂ© est urgent, intĂ©grer physiquement dans l’Ă©quipe une personne de l’Ă©quipe gĂ©rant la dĂ©pendance : cette personne ne sera pas polluĂ©e par ce qu’il pourrait se passer dans son Ă©quipe initiale et sera donc totalement dĂ©vouĂ©e Ă  la bonne rĂ©alisation de la fonctionnalitĂ©.

De manière plus gĂ©nĂ©rale, l’organisation est certainement Ă  revoir. Y a-t-il besoin d’une Ă©quipe dĂ©diĂ©e ou les compĂ©tences peuvent-elles ĂŞtre rĂ©parties au sein des Ă©quipes ? En rĂ©sumĂ© « component team » vs « feature team ». Une petite lecture sur Feature teams : au service de la transformation digitale permet dĂ©jĂ  d’y voir plus clair.

« Si nous n’avons pas fini cette story c’est parce qu’on n’avait pas pu anticiper les nombreux impacts » La situation

Nous avons tous dĂ©jĂ  entendu ce genre d’explication pour justifier le fait qu’une story n’ait pas pu ĂŞtre terminĂ©e lors d’une itĂ©ration. En plein dĂ©veloppement, de gros impacts sont dĂ©tectĂ©s et vont remettre considĂ©rablement en cause les dĂ©veloppements effectuĂ©s jusqu’Ă  prĂ©sent et par la mĂŞme occasion le bon dĂ©roulement de l’itĂ©ration.

Pourquoi ça sent mauvais ?

Afin de dissiper tout doute, si l’on considère cette situation seule, cela n’a rien d’un smell. Le travail d’analyse et d’estimation devant rester approximatif et ne devant pas trop peser sur le temps d’un sprint, une erreur peut alors survenir et cela est parfaitement acceptable. En revanche, si ces erreurs sont rĂ©currentes, elles soulèvent un problème sur la manière dont l’itĂ©ration est prĂ©parĂ©e mais Ă©galement sur une probable mĂ©connaissance de l’Ă©quipe sur son produit.

Concrètement on fait quoi ?

Lorsque ce genre d’erreur se rĂ©pète, il faut changer la manière d’aborder le problème. Et quoi de mieux qu’une solution simple et radicale. Pour chaque story, prenez au maximum deux heures pour investiguer plus en profondeur, et ce, mĂŞme si vous Ă©tiez sĂ»r de vous concernant la solution Ă  mettre en place. Cela peut prendre la forme de spike si c’est anticipĂ© sur l’itĂ©ration prĂ©cĂ©dente, ou simplement d’une bande passante entre deux itĂ©rations.

N’oubliez pas qu’en fonctionnement normal, il est exagĂ©rĂ© d’en arriver lĂ , mais dans ce cas extrĂŞme, mieux vaut perdre une demi-journĂ©e Ă  analyser, plutĂ´t que deux jours Ă  refaire un dĂ©veloppement. Au fil du temps, l’Ă©quipe devrait mieux maĂ®triser son produit et ne plus ĂŞtre forcĂ©e Ă  faire ce genre d’analyse.

Conclusion

Au travers de quatre situations, nous avons dĂ©couvert comment le Sprint Planning pouvait rĂ©vĂ©ler des pratiques contre-productives, mais Ă©galement, comment il pouvait ĂŞtre une aide d’une grande efficacitĂ© pour amĂ©liorer de nombreux aspects de la vie d’une Ă©quipe. Ne jetez pas votre dĂ©sodorisant tout de suite, nous revenons bientĂ´t avec de nouveaux agile smells dĂ©diĂ©s cette fois-ci au sprint daily stand-up meeting.

Catégories: Blog Société

TensorFlow & Deep Learning – Episode 2 – Notre premier réseau de neurones

tensorflowMaintenant que nous avons vu les bases de TensorFlow, nous allons pouvoir commencer Ă  entrer dans le vif du sujet et implĂ©menter notre premier rĂ©seau de neurones. L’objectif de cet article est de dĂ©cortiquer les grandes Ă©tapes nĂ©cessaires Ă  la crĂ©ation et Ă  l’entraĂ®nement d’un rĂ©seau de neurones, jusqu’Ă  la visualisation finale des rĂ©sultats dans TensorBoard. Le rĂ©seau de neurones que nous allons dĂ©velopper ici est le plus simple qui soit : le Softmax Regression.

Ces Ă©tapes sont essentielles Ă  tout projet de Deep Learning. Nous verrons par la suite Ă  quel point il sera simple de modifier l’architecture du rĂ©seau de neurones sans toucher aux autres Ă©tapes, permettant ainsi de tester de nombreuses architectures simplement.

Vous pourrez trouver le code fourni dans cet article sur le projet Github associĂ©. Passons maintenant Ă  l’action !

Le cas d’usage traitĂ© Les donnĂ©es

Afin d’illustrer les propos de cet article avec un exemple concret, nous allons travailler sur une application de classification d’images. Le dataset utilisĂ© est NotMnist, une version similaire au cĂ©lèbre dataset MNIST, appliquĂ© Ă  de la reconnaissance de lettres. Notre objectif est d’ĂŞtre capable de reconnaĂ®tre et de distinguer 10 lettres distinctes : de A Ă  J. Voici Ă  quoi ressemblent les images Ă  disposition pour la lettre A :

nomnist_example

Nous aurons Ă  notre disposition 200 000 images pour l’entraĂ®nement, ainsi que 10 000 pour la validation et 10 000 pour le test final. La taille des images est fixe : 28×28 pixels.

NB: Ce dataset est utilisĂ© dans le MOOC d’udacity  sur TensorFlow

Softmax Regression

Le rĂ©seau de neurones que nous allons implĂ©menter dans un premier temps est le Softmax Regression. L’architecture de ce rĂ©seau est la plus simple qui soit :

image_reshaped_softmax

Tous les pixels de l’image (4 dans le schĂ©ma ci-dessus et 1 biais, 784  dans la rĂ©alitĂ©) sont Ă©clatĂ©s en un seul vecteur, et la valeur du neurone d’entrĂ©e correspond Ă  l’intensitĂ© du pixel associĂ©. Sont ensuite dĂ©finies autant de sorties qu’il y a de classes (2 dans le schĂ©ma, 10 dans notre cas d’application)  et chaque neurone d’entrĂ©e est reliĂ© Ă  chaque neurone de sortie via un poids (qui n’est autre qu’un coefficient multiplicateur).

Lorsqu’une image est envoyĂ©e dans le rĂ©seau, elle est donc d’abord Ă©clatĂ©e en un vecteur, puis les valeurs des pixels sont multipliĂ©s par leurs poids associĂ©s pour donner les valeurs des neurones de sortie. Un vecteur de constantes, appelĂ©s biais est ensuite ajoutĂ©. Le biais est un degrĂ© de libertĂ© supplĂ©mentaire Ă  notre modèle, et joue le mĂŞme rĂ´le que l’intercept dans une rĂ©gression linĂ©aire. Une dernière Ă©tape, appelĂ©e softmax, consiste Ă  normaliser les valeurs des sorties afin qu’elles correspondent Ă  des probabilitĂ©s (entre 0 et 1) et que leur somme soit de 1. La classe prĂ©dite correspondra alors au neurone de sortie indiquant la plus grande probabilitĂ©. Tout le travail pour entraĂ®ner ce rĂ©seau correspond donc Ă  trouver les meilleurs poids et biais qui permettent de passer des neurones d’entrĂ©e Ă  ceux de sortie.

En rĂ©alitĂ©, le calcul associĂ© pour traverser le rĂ©seau n’est autre qu’un produit matriciel du vecteur d’entrĂ©e avec une matrice de poids pour donner un vecteur de sortie. Mieux encore, le principe appliquĂ© est le mĂŞme lorsqu’il s’agit d’un batch d’images (un ensemble d’images). Un batch de 100 images correspond alors Ă  une matrice de taille [100, 4] sur le schĂ©ma, et la sortie obtenue après application des poids et des biais est une matrice de taille [100, 2].

Softmax Regression2

Quelles sont les grandes étapes à implémenter ?

Pour tout projet de Deep Learning, quelle que soit l’architecture choisie, certaines Ă©tapes sont obligatoires. On peut les rĂ©sumer en trois grandes catĂ©gories : gestion des donnĂ©es d’entrĂ©e, construction et gestion du rĂ©seau de neurones, et Ă©valuation du modèle.

Gestion des inputs

Nos inputs correspondent dans notre cas aux images prĂ©sentes dans le dataset d’entraĂ®nement. Nous n’entrerons pas dans le dĂ©tail de l’optimisation de l’apprentissage d’un rĂ©seau de neurones, mais il faut savoir que le fait d’utiliser toutes les images du dataset Ă  chaque itĂ©ration n’est pas la meilleure idĂ©e qui soit. Il est plutĂ´t recommandĂ© de travailler par batch d’images (un batch de 100 images, par exemple) reprĂ©sentatif des diffĂ©rentes catĂ©gories Ă  classifier. Cette manière de faire permet un apprentissage, une optimisation plus souple et une convergence plus rapide.

Au-delĂ  de la gestion des batches d’entrĂ©e, il est aussi frĂ©quent d’effectuer une phase de pre-processing des images avant de les envoyer dans le rĂ©seau de neurones. Cette phase peut inclure une grande variĂ©tĂ© de traitements: resizing, random cropping, flipping and rotating,   etc. Les avantages de ces phases sont nombreux, notamment pour la normalisation des images (un rĂ©seau de neurones n’accepte gĂ©nĂ©ralement qu’un seul type d’image et de taille), ainsi que pour l’augmentation artificielle de la taille du dataset (en appliquant des transformations alĂ©atoires, le rĂ©seau de neurones est confrontĂ© Ă  de nouvelles images).

Construction et gestion du réseau de neurones

On distingue 3 phases distinctes et essentielles pour la crĂ©ation et l’optimisation de la convergence du modèle :

  • InfĂ©rence : Cette Ă©tape correspond Ă  toutes les Ă©tapes nĂ©cessaires pour effectuer les prĂ©dictions des classes Ă  partir des inputs (les batches d’images). Cela correspond Ă  la dĂ©finition de l’architecture du rĂ©seau de neurones en lui-mĂŞme.
  • Fonction de coĂ»t : Afin de faire en sorte que le rĂ©seau de neurones puisse faire des prĂ©dictions correctes, il faut dĂ©finir une fonction de coĂ»t qu’il faudra chercher Ă  optimiser Ă  chaque itĂ©ration jusqu’Ă  convergence. On utilise gĂ©nĂ©ralement la cross-entropie comme fonction de coĂ»t.
  • EntraĂ®nement : Une fois dĂ©finies l’architecture du rĂ©seau ainsi que la fonction de coĂ»t Ă  optimiser, il faut passer Ă  l’Ă©tape d’optimisation Ă  proprement parler. C’est dans cette phase que nous allons dĂ©finir de quelle manière les poids du rĂ©seau vont ĂŞtre mis Ă  jour Ă  chaque itĂ©ration. GĂ©nĂ©ralement, ce sont des techniques de backpropagation qui sont utilisĂ©es, avec des algorithmes de type Stochastic Gradient Descent.

C’est au cours de cette Ă©tape que le rĂ©seau de neurones crĂ©Ă© va vraiment « apprendre » Ă  distinguer les classes. Il va en effet « visionner » Ă  chaque Ă©tape de nouvelles images, et mettre Ă  jour les poids en fonction des erreurs de prĂ©diction qui sont faites.

Evaluation du modèle

La cross-entropie est une bonne fonction de coĂ»t pour l’entraĂ®nement des rĂ©seaux de neurones, mais ce n’est pas la mesure la plus parlante lorsqu’il s’agit de dĂ©finir si le modèle a de bonnes performances. C’est pourquoi il n’est pas rare de se rajouter une dernière Operation correspondant Ă  un calcul de prĂ©cision sur un dataset de validation (un jeu de donnĂ©es sur lequel le rĂ©seau ne s’est pas entraĂ®nĂ©) afin de mesurer la capacitĂ© de gĂ©nĂ©ralisation du rĂ©seau et d’Ă©viter l’overfitting, ou apprentissage par coeur.

L’Ă©valuation du modèle ne se fait pas forcĂ©ment Ă  chaque Ă©tape de la phase d’entraĂ®nement, mais plutĂ´t Ă  intervalles rĂ©guliers afin de voir la progression gĂ©nĂ©rale des performances du modèle.

Réalisation des différentes étapes

Passons maintenant Ă  l’implĂ©mentation des diffĂ©rentes phases que nous avons dĂ©crites jusque lĂ .

Inputs

Comme expliquĂ© dans l’article prĂ©cĂ©dent, la gestion des inputs se fait grâce Ă  des placeholders, qui permettent de dĂ©finir la structure des Tensors sans avoir Ă  spĂ©cifier de valeur fixe. Le contenu du Tensor est ajoutĂ© et modifiĂ© Ă  chaque Ă©tape de l’entraĂ®nement du modèle via le paramètre feed_dict de la mĂ©thode run().

Voici le code associé à la création des placeholders nécessaires dans notre cas:

with tf.name_scope("input"):
    x = tf.placeholder(tf.float32, shape=(None, num_pixels))
    y = tf.placeholder(tf.float32, shape=(None, num_classes))

Comme on peut le voir, la première dimension du Tensor est fixée à None, ce qui nous permet de changer la taille des batchs comme bon nous semble.

Les donnĂ©es associĂ©es Ă  la validation et au test pourront ĂŞtre traitĂ©es telles quelles. Seules des donnĂ©es d’entraĂ®nement doivent ĂŞtre sĂ©parĂ©es par batch et fournies en entrĂ©e des placeholders.

Inférence

Comme dĂ©finie prĂ©cĂ©demment, la phase d’infĂ©rence nous permet d’appliquer les transformations nĂ©cessaires pour passer d’un input (un batch d’images) Ă  une prĂ©diction (pour chaque image, un vecteur de probabilitĂ©s). Voici le code associĂ© pour une Softmax Regression:

with tf.name_scope("softmax"):
    # Model parameters
    weights = tf.Variable(tf.zeros([num_pixels, num_classes]))
    biases = tf.Variable(tf.zeros([num_classes]))

    logits = tf.matmul(x, weights) + biases
    softmax = tf.nn.softmax(logits)

Tout le code pour le calcul du softmax est implĂ©mentĂ© dans un bloc spĂ©cifique, ce qui nous permettra de nous y retrouver dans TensorBoard. Dans un premier temps, il faut instancier les poids et les biais. Comme expliquĂ© dans l’article prĂ©cĂ©dent, le mieux est d’utiliser une Variable. Ils sont ici initialisĂ©s avec des zĂ©ros, mais nous les initialiserons dans les prochains rĂ©seaux avec de faibles valeurs alĂ©atoires afin d’Ă©viter que les diffĂ©rents neurones apprennent la mĂŞme chose.

Une fois toutes les variables instanciĂ©es, on passe au produit matriciel entre le batch d’images et les poids, puis on ajoute les biais. On peut enfin utiliser la fonction softmax sur le rĂ©sultat pour obtenir les probabilitĂ©s.

Afin de pouvoir visualiser par la suite la distribution des valeurs en sortie du softmax dans TensorBoard, il faut rajouter le summary associé dans le code:

# Softmax values histogram
tf.summary.histogram(softmax.op.name + '/activations', softmax)
Fonction de coût

Comme dit prĂ©cĂ©demment, nous allons utiliser la cross-entropie comme fonction de coĂ»t. C’est cette mĂ©trique qui nous permettra de mesurer Ă  quel point les prĂ©dictions (probabilitĂ©s) sont Ă©loignĂ©es de la vĂ©ritĂ©, et c’est Ă  partir de celle-ci que les poids et biais seront mis Ă  jour dans l’Ă©tape suivante. Voici le code associĂ© Ă  la crĂ©ation de la fonction de coĂ»t:

with tf.name_scope("cross_entropy"):
    labels = tf.cast(labels, tf.int64)
    cross_entropy = tf.nn.sparse_softmax_cross_entropy_with_logits(logits, labels)
    cross_entropy_mean = tf.reduce_mean(cross_entropy, name="cross_entropy")

    tf.summary.scalar("cross_entropy", cross_entropy_mean)

La cross-entropie pour chaque image est calculĂ©e via la mĂ©thode sparse_softmax_cross_entropy_with_logits. L’entropie moyenne sur le batch est alors calculĂ©e via la mĂ©thode reduce_mean. Il convient ensuite de dĂ©finir le summary associĂ© pour suivre l’Ă©volution de la cross-entropie moyenne en fonction de l’itĂ©ration en cours.

Entraînement

Afin de boucler la boucle pour la construction et la gestion du rĂ©seau de neurones, il reste maintenant Ă  dĂ©finir la phase d’entraĂ®nement, c’est Ă  dire la manière dont les poids et les biais vont ĂŞtre mis Ă  jour en fonction de la cross-entropie calculĂ©e prĂ©cĂ©demment ainsi que d’un learning rate permettant d’impacter de manière plus ou moins forte cette mise Ă  jour. Un learning rate Ă©levĂ© va mener Ă  des variations des valeurs des poids plus Ă©levĂ©s si l’erreur est importante. Tout l’enjeu est de choisir une valeur suffisamment importante pour que la convergence se fasse rapidement, mais suffisamment faible pour ne pas diverger.

Comme expliquĂ© prĂ©cĂ©demment, nous allons utiliser une descente de gradient stochastique pour gĂ©rer la mise Ă  jour des poids et biais. Voici le code associĂ© Ă  l’entraĂ®nement du rĂ©seau de neurones:

 with tf.name_scope("train"):
    # Optimizer
    optimizer = tf.train.GradientDescentOptimizer(learning_rate)

    # Use the optimizer to apply the gradients that minimize the loss (and also increment the global step
    # counter) as a single training step.
    train_op = optimizer.minimize(loss, global_step=global_step)

La descente de gradient stochastique est gĂ©rĂ©e via la classe GradientDescentOptimizer, instanciĂ© avec le learning_rate. L’optimiseur crĂ©Ă© possède alors une mĂ©thode minimize Ă  laquelle on fournit la loss de l’Ă©tape prĂ©cĂ©dente. La classe crĂ©Ă©e utilise aussi un global_step qui permet de tracer l’itĂ©ration en cours.

Evaluation

Cette dernière Ă©tape permet d’avoir un critère plus comprĂ©hensible pour observer la convergence du modèle et de s’assurer que l’on ne fait pas d’overfitting. Elle consiste en un simple calcul d’accuracy entre les classes prĂ©dites et rĂ©elles. Voici le code associĂ© Ă  la crĂ©ation de cette Operation:

with tf.name_scope("accuracy"):
    correct_prediction = tf.equal(tf.argmax(softmax, 1), tf.argmax(labels, 1))
    accuracy = tf.reduce_mean(tf.cast(correct_prediction, tf.float32))
 
    tf.summary.scalar("accuracy", accuracy)
Classes associées

Dans le code fourni, chacune de ces Ă©tapes sont sĂ©parĂ©es dans des classes associĂ©es. Cela permet un dĂ©coupage plus propre du code, et offre ainsi la possibilitĂ© par exemple de modifier le code d’une des Ă©tapes indĂ©pendamment des autres.

Voici un exemple pour la phase d’infĂ©rence:

class InferenceOp:
    def __init__(self, num_pixels, num_classes, name_scope="softmax"):
        self.num_pixels = num_pixels
        self.num_classes = num_classes
        self.name_scope = name_scope

    def add_ops(self, x):
        """
        Build the softmax op to make final predictions (probabilities)

        :param x: Input Tensor
        :return: softmax: Output Tensor with the computed logits.
        """

        with tf.name_scope(self.name_scope):
            # Model parameters
            weights = tf.Variable(tf.zeros([self.num_pixels, self.num_classes]))
            biases = tf.Variable(tf.zeros([self.num_classes]))

            logits = tf.matmul(x, weights) + biases
            softmax = tf.nn.softmax(logits)

        # Softmax values histogram
        tf.summary.histogram(softmax.op.name + '/activations', softmax)

        return softmax, logits

Ainsi, si je souhaite modifier l’architecture du rĂ©seau de neurones, il suffit d’apporter les modifications dans la classe InferenceOp, sans avoir Ă  se soucier des Ă©tapes de loss et d’entraĂ®nement, ce qui sera très pratique par la suite.

Exécution du code

Il ne nous reste maintenant plus qu’Ă  joindre les morceaux crĂ©Ă©s prĂ©cĂ©demment. Passons dès maintenant au code de l’entraĂ®nement du rĂ©seau de neurones, que nous commenterons ensuite.

NB: Pour exĂ©cuter le code, il faut crĂ©er les diffĂ©rentes variables qui y sont nommĂ©es (prĂ©sentes dans le code sur Github). Le but ici est d’expliciter chaque Ă©tape.

def main():
    """
    Train NotMNIST for a number of steps.
    """
    # Load data
    train_dataset, train_labels, valid_dataset, valid_labels, test_dataset, test_labels = DataLoader(
        data_dir=data_dir,
        image_size=28,
        num_labels=10).load()

    with tf.Graph().as_default():
        global_step = tf.Variable(0, name='global_step', trainable=False)

        # Start running operations on the Graph.
        sess = tf.Session()

        """
        Step 1 - Input data management
        """

        # Input data
        x, y = InputOp(num_pixels=IMAGE_SIZE*IMAGE_SIZE, num_classes=10).add_op()

        # Reshape images for visualization
        x_reshaped = tf.reshape(x, [-1, IMAGE_SIZE, IMAGE_SIZE, 1])
        tf.summary.image('input', x_reshaped, NUM_CLASSES)

        """
        Step 2 - Building the graph
        """

        # Build a Graph that computes the logits predictions from the inference model.
        softmax, logits = InferenceOp(num_pixels=NUM_PIXELS, num_classes=NUM_CLASSES).add_ops(x)

        # Calculate loss.
        loss = LossOp(name_scope="cross_entropy").add_op(logits, y)

        # Build a Graph that trains the model with one batch of examples and updates the model parameters.
        train_op = TrainingOp(learning_rate=learning_rate, name_scope="train").add_op(loss, global_step)

        """
        Step 3 - Build the evaluation step
        """

        # Model Evaluation
        accuracy = EvaluationOp(name_scope="accuracy").add_op(softmax, y)

        """
        Step 4 - Merge all summaries for TensorBoard generation
        """
        # Create a saver.
        saver = tf.train.Saver(tf.global_variables())

        # Build the summary operation based on the TF collection of Summaries.
        summary_op = tf.summary.merge_all()

        # Summary Writers
        train_summary_writer = tf.summary.FileWriter(summaries_dir + '/train', sess.graph)
        validation_summary_writer = tf.summary.FileWriter(summaries_dir + '/validation', sess.graph)

        """
        Step 5 - Train the model, and write summaries
        """

        # Build an initialization operation to run below.
        init = tf.global_variables_initializer()
        sess.run(init)

        for step in xrange(max_steps):

            start_time = time.time()

            # Pick an offset within the training data, which has been randomized.
            offset = (step * batch_size) % (train_labels.shape[0] - batch_size)

            # Generate a minibatch.
            batch_data = train_dataset[offset:(offset + batch_size), :]
            batch_labels = train_labels[offset:(offset + batch_size), :]

            # Run training step and train summaries
            summary_train, _, loss_value = sess.run([summary_op, train_op, loss],
                                                    feed_dict={x: batch_data, y: batch_labels})

            train_summary_writer.add_summary(summary_train, step)

            duration = time.time() - start_time

            if step % 10 == 0:
                num_examples_per_step = batch_size
                examples_per_sec = num_examples_per_step / duration
                sec_per_batch = float(duration)

                # Run summaries and measure accuracy on validation set
                summary_valid, acc_valid = sess.run([summary_op, accuracy],
                                                    feed_dict={x: valid_dataset, y: valid_labels})

                validation_summary_writer.add_summary(summary_valid, step)

                format_str = '%s: step %d, accuracy = %.2f (%.1f examples/sec; %.3f sec/batch)'
                print (format_str % (datetime.now(), step, 100 * acc_valid, examples_per_sec, sec_per_batch))

        acc_test = sess.run(accuracy, feed_dict={x: test_dataset, y: test_labels})
        print ('Accuracy on test set: %.2f' % (100 * acc_test))

Les grandes Ă©tapes d’exĂ©cution suivent l’ordre logique dĂ©taillĂ© initialement :

  1. Gestion des donnĂ©es d’entrĂ©e
    1. Chargement des datasets
    2. Création des placeholders
  2. Construction du graphe d’exĂ©cution
    1. Inférence
    2. Cross-entropie
    3. Entraînement
  3. Gestion de l’Ă©valuation du modèle (calcul de l’accuracy)
  4. Gestion des résumés présents dans TensorBoard
  5. Entraînement du modèle et écriture des résumés. Pour chaque itération :
    1. CrĂ©ation du batch de donnĂ©es d’entraĂ®nement
    2. run du rĂ©sumĂ© et de l’entraĂ®nement en fournissant le dictionnaire contenant les donnĂ©es d’entrĂ©e
    3. Ecriture des résumés
    4. RĂ©cupĂ©ration de l’accuracy sur le validation set et Ă©criture du rĂ©sumĂ© associĂ© toutes les 10 itĂ©rations
  6. Estimation des performances sur le test set

Voici les commandes à lancer pour exécuter le code à partir du projet fourni (il faut avoir un environnement Python avec TensorFlow installé):

cd ~/tensorflow_image_tutorial
python tensorflow_image_tutorial/train/train_softmax.py

Cette dernière commande va lancer le main détaillé précédemment. Comme vous pourrez le voir, les étapes de création des opérations se situent dans le sous-package operation, et le main se situe dans le sous-package train.

NB: Vous pourrez constater qu’il y a plusieurs fonctions d’entraĂ®nement dans le sous-package train, ainsi que plusieurs modules d’infĂ©rence dans le sous-package operation/inference. Ceux-ci correspondent aux Ă©volutions que nous proposerons dans le prochain article. Dans cet article, nous avons implĂ©mentĂ© les modules spĂ©cifiques pour le softmax.

Visualisation des résultats dans TensorBoard

En se fixant 5000 itérations, une taille de batch de 128 images et un learning_rate de 0.1, on converge vers un score de 83% de bonnes prédictions sur le validation set, et on obtient un score légèrement supérieur à 89% sur le test set.

Mais le mieux reste encore d’observer directement la convergence du modèle et les rĂ©sultats sur TensorBoard. Il suffit de lancer la commande suivante pour afficher le board sur votre navigateur:

tensorboard --logdir="/tmp/not_mnist/not_mnist_logs"

Voici quelques observations disponibles :

resultats-TensorBoard

TensorBoard méritant un article détaillé à lui tout seul, nous allons expliquer ces images de manière très simple.

  • En haut Ă  gauche : L’Ă©volution de l’accuracy en fonction des itĂ©rations. Elle augmente très rapidement dans les premières itĂ©rations (correspondant Ă  des grosses variations des poids pour se spĂ©cialiser) pour petit Ă  petit se stabiliser et converger vers 90%. Il est important de constater qu’il n’y ait pas de dĂ©crochage entre la courbe de train et de validation, ce qui signifie qu’il n’y a pas d’overfitting.
  • En haut Ă  droite : Le graphe qui a Ă©tĂ© crĂ©Ă© pour l’exĂ©cution. On y retrouve toutes les Ă©tapes que nous avons implĂ©mentĂ©es.
  • En bas Ă  gauche: On rentre plus dans le dĂ©tail du rĂ©seau de neurones crĂ©Ă© en observant la distribution de l’activation de la couche de softmax. Chaque courbe plus colorĂ©e reprĂ©sente un quartile.
  • En bas Ă  droite : Les histogrammes des valeurs des neurones de sortie. Il faut s’assurer que l’histogramme du softmax tende bien vers une distribution bimodale, avec la majoritĂ© des valeurs proches de 0 et une sous-partie proche de 1. Cela permet de s’assurer que le modèle est « sĂ»r de lui », tant pour les prĂ©dictions nĂ©gatives que positives.
Conclusion

FĂ©licitations ! Nous avons construit toutes les Ă©tapes nĂ©cessaires Ă  la crĂ©ation et l’entraĂ®nement d’un rĂ©seau de neurones simple (Softmax Regression). Bien qu’il soit indĂ©niable qu’il y a un certain gap Ă  franchir pour bien assimiler les diffĂ©rentes notions autour du fonctionnement de TensorFlow, nous avons pu constater que pour chaque Ă©tape principale que l’on souhaite implĂ©menter, il y a Ă  notre disposition un ou plusieurs opĂ©rations associĂ©es Ă  cette tâche.

Une fois toute cette mĂ©canique implĂ©mentĂ©e, tout devient plus simple. Nous verrons dans le prochain article Ă  quel point il sera aisĂ© de modifier l’architecture du rĂ©seau de neurones pour amĂ©liorer les rĂ©sultats en ne faisant qu’un minimum de modifications dans le code. En effet, hormis pour l’infĂ©rence, toutes les autres Ă©tapes implĂ©mentĂ©es restent identiques.

See you on the next episode.

Catégories: Blog Société

Dragonfly, Nginx et contenu partiel

L'actualité de Synbioz - mer, 03/22/2017 - 00:00

En utilisant Dragonfly nous nous sommes rendus compte qu’au moment de servir des vidéos pour Safari et Safari mobile depuis notre application Rails, cela ne fonctionnait pas.

En creusant un peu il s’avère que Safari est assez exigeant puisqu’il impose un support du byte-range de la part du serveur qui sert la vidéo.

Lire la suite...

Catégories: Blog Société

JIRA Service Desk: the pros and cons

Le blog de Valiantys - mar, 03/21/2017 - 15:05

Service Desk is a key driver for end-users satisfaction. A good experience and your IT team will be praised, a bad one will slow your business down and create frustration. In the end, a Service Desk is all about providing efficiency to your internal or external customers with solutions to their requests. Among the crowd ...

The post JIRA Service Desk: the pros and cons appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Jetez vos User Stories

Lors de mes accompagnements, je suis rĂ©gulièrement questionnĂ© sur le sujet de la gestion de la documentation dans les contextes agiles. Quand on me pose la question : « Comment doit-on gĂ©rer la documentation en agilitĂ© ? », en bon coach Agile, je rĂ©ponds : « Ca dĂ©pend ! ». Pour aller plus loin, je […]
Catégories: Blog Société

Le Mois de la Data en mai chez Xebia

Après le mois de du JavaScript l’annĂ©e dernière, Xebia Data Factory organise le Mois de la Data durant tout le mois de mai. Du Data Engineering Ă  la Data Science en passant par le Real Time, tous les champs d’application autour de la donnĂ©e seront abordĂ©s Ă  travers des problĂ©matiques concrètes d’actualitĂ©.

Le Mois de la Data sera articulé autour de 4 TechEvents avec pour chacun d’eux un thème dédié, présenté et organisé par des Xebians.

Au programme du Mois de la Data Deep into Data Science

Le 2 mai Ă  19 h

Du Text Mining, en passant par le Deep Learning, pour arriver enfin jusqu’au Reinforcement Learning, plongeons ensemble dans les profondeurs de la Data Science. Vive l’apprentissage automatique !

Inscrivez-vous au TechEvent deep into Data Science

Data Craftsmanship

Le 9 mai Ă  19 h

Ă€ l’heure oĂą de plus en plus de projets Data sont conduits, comment faire en sorte qu’ils aillent en production efficacement ? Les Proofs of Concepts sont terminĂ©s, et après ? Nous allons voir comment appliquer les bonnes pratiques du Software Craftsmanship Ă  la Data Science.

Inscrivez-vous au TechEvent Data Craftmanship

Real Time Data Architecture

Le 16 mai Ă  19 h

IntĂ©grer ses donnĂ©es au fil de l’eau, ajouter une dose de modèle de Machine Learning prĂ©alablement entraĂ®nĂ©, indexer le tout. Et voilĂ  ! Votre utilisateur final est informĂ© en temps rĂ©el.

Inscrivez-vous au TechEvent real time Data Architecture

Data in action

Le 23 mai Ă  19 h

Décortiquer le vote de nos députés, calmer un bébé qui pleure ou encore apprendre à mon téléphone à reconnaître un objet sont autant d’applications décalées de la Data Science que nous avons réalisées. Venez découvrir comment nous avons mixé du Machine Learning, de l’IOT et du Mobile pour y arriver.

Inscrivez-vous au TechEvent Data in action

Préparez-vous au mieux pour le Mois de la Data

Afin de vous prĂ©parer au Mois de la Data, n’hĂ©sitez pas Ă  revoir les confĂ©rences Data prĂ©sentĂ©es lors de notre Ă©vĂ©nement annuel, la Xebicon.

Et n’hĂ©sitez pas Ă  jeter un Ĺ“il sur les formations certifiantes Big Data/ Hadoop (Cloudera), Data Science,  Elasticsearch, Kafka et MongoDB, proposĂ©es chez Xebia.

Nous espérons vous voir nombreux en mai ! Rendez-vous au 156 boulevard Haussmann, 75008 PARIS (7e étage).

Catégories: Blog Société

Meetup le 29 mars : Concevoir une application scalable dans le Cloud

A Duchess Community Blog for France - lun, 03/20/2017 - 13:20

Ne manquez pas cette session de notre série de meetups sur le Cloud Computing qui aura lieu le 29 mars dans le centre de Paris

Après AWS, c’est au tour de Microsoft de nous prĂ©senter sa solution Cloud : Microsoft Azure.

 

Cette soirée est une excellente occasion de découvrir les architectures modernes et les grands principes du développement Cloud.

Notre speaker StĂ©phanie Hertrich aura une double casquette puisqu’elle est Architecte Cloud chez Microsoft et Ă©galement membre du board Duchess France.

 

Cette session s’adresse à tous les profils de dĂ©veloppeurs, toutes technos et langages confondus, qu’ils soient dĂ©butants …

Cet article Meetup le 29 mars : Concevoir une application scalable dans le Cloud est apparu en premier sur Duchess France.

Catégories: Association

Agile Games France 2017

Et voilĂ , la 6ème Ă©dition d’Agile Games France est finie et je suis dans le TGV de retour de Lille vers Grenoble.

Cette annĂ©e, comme les annĂ©es passĂ©es d’ailleurs, les grenoblois Ă©taient très bien reprĂ©sentĂ©s, comme d’ailleurs toutes les autres rĂ©gions de France. Et encore cette fois il y avait environ la moitiĂ© des personnes dont c’Ă©tait le premier AGFr, comme quoi, si vous n’ĂŞtes jamais venu, ce n’est pas un problème

Catégories: Blog Individuel

[PODOJO] Back to basics – La boite à outils du PO

Agile Nantes - jeu, 03/16/2017 - 15:40
 La boĂ®te Ă  outil du Product Owner. Faut-il une scie pour dĂ©couper mes stories ? Ai-je besoin d’ĂŞtre architecte pour monter ma cloison ? Est ce que je peux fixer mes post-it avec un marteau ? Le bricolage est une affaire de professionnels nous le savons bien. Mais si l’on est bien outillĂ© on peut faire […]
Catégories: Association

J’ai essayé MJML, le langage des emails responsive

Le blog Webnet - jeu, 03/16/2017 - 11:54

La création d’email est bien souvent un casse-tête pour les intégrateurs. Entre la compatibilité des messageries/clients mail et le responsive, les tableaux HTML se transforment rapidement en champ de bataille.

Mailjet a développé un langage afin d’optimiser la création d’emails responsive, le langage est basé sur une sémantique simple, ce qui ne déstabilisera pas un intégrateur après une étude rapide de la documentation et des possibilités qu’il offre.

Le langage MJML reste proche du langage HTML et offre un système de CSS en ligne simple à utiliser.

L’environnement

Lors de l’ouverture de l’application, 4 possibilités nous sont proposées, nous pouvons accéder à nos templates préalablement créés, accéder à des templates prédéfinis, en créer un nouveau.

L’environnement de l’application ressemble à un éditeur de texte épuré.
L’écran est scindé en deux, une partie pour la saisie du code MJML et une partie dédiée à la prévisualisation en temps réel du rendu de ce dernier. Notons que la prévisualisation de notre travail est possible sur un écran desktop ou mobile.

 

Pour réaliser des tests en conditions réelles, l’option « Send » nous permet de faire un envoi rapide depuis l’application vers une adresse mail. Vous devrez cependant créer un compte MailJet et renseigner le champ « API KEY » correspondant à votre compte pour profiter de cette fonctionnalité.

 

Afin d’enregistrer notre travail, ou plutôt, de l’exporter, 2 choix sont proposés par l’éditeur : un export HTML ou MJML. N’oubliez pas de toujours réaliser un export dans ce dernier format afin de pouvoir y revenir plus tard si vous le souhaitez.

A noter la présence d’une option « Gist » permettant d’envoyer directement le code créé sur un compte GitHub.

Rapide tour d’horizon

mjml-head

<mj-head>

Le contenu global de notre template est entouré des balises ouvrantes et fermantes <mjml> et </mjml> (équivalentes à <html> et </html>).

La balise <mj-head> (correspondant à l’entête <head> en HTML) permet de définir des styles par défaut, de créer des classes, d’importer des polices par exemple.

L’ajout de classes réalisé de la sorte peut nous faire penser aux variables des préprocesseurs SASS et LESS.

Pour avoir plus de renseignements sur les composant de la balise <mj-head> vous pouvez-vous reporter au lien de la documentation suivant : https://mjml.io/documentation/#standard-head-components

<mj-body>

Le corps de notre code sera initialisé avec la balise <mj-body>, contenant un container avec la balise <mj-container>. https://mjml.io/documentation/#standard-body-components

<mj-section> / <mj-column>

Les différentes sections de nos templates seront, un peu comme le fait la classe row dans bootstrap, définies avec la balise <mj-section>.

Pour terminer ce rapide tour d’horizon, nous évoquerons les balises <mj-column>, qui servent à définir le nombre de colonnes dans notre section.

A noter : Le nombre de colonnes par section est de 4 maximum (si l’on veut aller au-delà il faudra préciser la largeur de chaque colonne avec un width), la largeur de chaque section sera logiquement de 25% lorsque nous en avons 4, 33,3% lorsque nous avons 3 colonnes et 50% lorsque les colonnes sont au nombre de 2.

Là encore, je vous invite à étudier de plus près la documentation MJML J https://mjml.io/documentation/#getting-started

Les composants simples de contenu <mj-text>

La balise <mj-text> sert à ajouter du contenu. On peut également introduire des balises tel que des <h1> à l’intérieur.

<mj-image>

Cette balise nous sert à ajouter une image. Comme en HTML, l’attribut src= « » sert à indiquer le chemin afin de trouver l’image. Nous pouvons aussi noter qu’un attribut href= « » est disponible sur les images afin de rendre celles-ci cliquable et d’arriver sur une url voulue.

<mj-button>

Nous pouvons également rajouter de simples liens sous forme de bouton à l’aide de la balise <mj-button> comme ci-dessous.

Les composants avancés

Certains composants vont encore plus loin et offrent des fonctionnalités déjà prédéfinies.

Très pratique pour rendre nos newsletters plus vivantes.

<mj-social>

Nous remarquons de plus en plus la présence d’icônes pour les réseaux sociaux dans les newsletter, MJML permet d’insérer des call-to-action des différents réseaux existants de manière très simple.

<mj-navbar hamburger= «hamburger»

Tel un vrai site, MJML nous permet d’insérer une navigation à l’intérieur de notre email. Ceci peut s’avérer nécessaire lorsque l’on souhaite rediriger l’utilisateur vers différentes sections de notre site web.

A noter qu’un attribut burger menu pour les emails responsives est nativement présent dans l’application.

 

mj-navbar-hamburger-closedmj-navbar-hamburger-open

 

mj-navbar

<mj-carousel>

Souvent utilisé sur les sites web, les carousels peuvent s’avérer utiles afin d’afficher plusieurs images de manière dynamique.

mj-carousel2

mj-carousel

<mj-location>

On peut ajouter de façon rapide une adresse avec une localisation qui nous redirige au clic vers Google Maps.

mj-location2

mj-location

Avantages et inconvénients Avantages

Commençons tout d’abord ce point avec le fait que MJML est open source et donc gratuit.

Facile à appréhender et à utiliser, MJML reste un outil très intuitif pour rendre les newsletters responsives. En peu de temps d’apprentissage, il pourra vous faire gagner un temps certain dans vos intégrations. Utilisant des préceptes s’inspirant de frameworks CSS et de préprocesseurs tels que SASS et LESS, un intégrateur n’aura pas de mal à comprendre son fonctionnement et améliorera sa productivité.

L’export en .html ou .mjml se fait en … 3 petits clics !

Notons aussi que de travailler avec MJML est plaisant grâce au fait de voir le rendu de notre travail en temps réel.

Inconvénients

Nous pouvons toutefois relever quelques inconvénients à l’utilisation de MJML.

Tout d’abord, étant une application basée sur la technologie NodeJS, il est nécessaire d’installer préalablement le package npm sur le poste local. Nuançons toutefois ce propos avec l’installation rapide et fluide du soft une fois le package installé.

Nous avons également pu remarquer quelques bugs sur le client lourd Outlook, tels que des titres mal gérés et coupés en 2.

Autre petit bémol, nous ne pouvons pas inspecter le code et donc procéder efficacement aux corrections de bugs.

 

Conclusion

MJML est en langage jeune mais très porteur pour l’avenir avec une communauté de plus en plus active.

En plus des fonctionnalités déjà proposées il existe certains plugins pouvant être téléchargé via le compte GitHub https://github.com/mjmlio . Notons d’ailleurs qu’il existe un plugin pour l’IDE Atom qui peut s’avérer utile pour les personnes travaillant déjà avec cet éditeur (https://github.com/mjmlio/atom-linter-mjml), la prévisualisation devient même disponible directement dans Atom !
MJML est donc un langage prometteur, bien qu’il soit encore un peu jeune pour couvrir la multitude de spécificités liées à toutes les messageries disponibles.

Catégories: Blog Société

nFeed 5.10: a cleaner display, savvier JQL queries and JIRA Automation integration

Le blog de Valiantys - jeu, 03/16/2017 - 11:00

After a bit of a wait and some hard work, we are now pleased to announce new functionalities that should improve the user experience of your JIRA or JIRA Service Desk instances. What is our promise? An improved display of multi-value nFeed fields, more flexibility for your nFeed JQL queries and fast creation of automation rules for your nFeed fields. Pretty neat stuff! Unlock the power of ...

The post nFeed 5.10: a cleaner display, savvier JQL queries and JIRA Automation integration appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Revue de Presse Xebia

Revue de presse de XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Agilité Engagement Is a Means, Not an End http://blog.xebia.fr/author/gfontainehttp://twitter.com/fontgregoryPar Grégory Fontaine

Lorsque, dans le cadre d’une transformation agile par exemple, on parle de rendre aux manageurs leurs Ă©quipes autonomes et responsables, on a parfois l’impression qu’on leur demande un service. Certains le font, mais attendent presque des remerciements en retour. Dans cet article, Michael Schrage du MIT explique que l’autonomisation et la responsabilisation des Ă©quipes ne sont que des moyens pour atteindre des objectifs – d’efficacitĂ© notamment. A lire sur le site du Harvard Business Review.

Mobilité Java8 bientôt supporté nativement par le système de build Android http://www.gravatar.com/avatar/63d261113651caa0dc887445c61ea48ahttp://blog.xebia.fr/author/blacroixhttp://twitter.com/benjlacroixhttp://github.com/blacroixPar Benjamin Lacroix

Android Developers vient d’annoncer sur son blog que Java8 sera bientĂ´t supportĂ© directement par javac et les outils dx ! Excellente nouvelle qui va nous permettre d’utiliser directement les fonctionnalitĂ©s de Java8 dans nos applications Android sans passer par le compilateur Jack. Ce dernier et ses outils associĂ©s vont ĂŞtre petit Ă  petit passĂ©s Ă  deprecated. Pas de panique, si vous avez dĂ©jĂ  utilisĂ© Jack vous pourrez facilement migrer quasiment sans effort.

La mise Ă  jour sera disponible dans quelques semaines associĂ©e Ă  une mise Ă  jour d’Android Studio.

Cloud Google Cloud Next ’17 http://www.gravatar.com/avatar/3a75830f2dda4fb9b3363cc86b67cab2http://twitter.com/guyghostPar Guy Mandina

Du 8 au 10 mars 2017 à San Francisco s’est tenue la Google Cloud Next. Au programme de l’évènement, le Cloud sous toutes ses formes chez Google (De Google Cloud Platform à G Suite en passant par Apigee). L’ensemble des annonces se trouve par ici.

Le logo de google next cloud 17

Dans ce billet nous allons nous attarder sur les annonces concernant Google Cloud Platform.

App Engine

La plateforme de Google lancĂ©e en 2008, permet aux dĂ©veloppeurs de construire et de lancer des web apps ou des backends pour mobile dans des environnements managĂ©s. App Engine a bien Ă©voluĂ© au cours de ces dernières annĂ©es. Ă€ l’origine, il Ă©tait uniquement possible de dĂ©ployer des applications construites en Java et Python. Le support de Go et PHP est venu bien plus tard.

Aujourd’hui, la promesse faite aux dĂ©veloppeurs – “Apportez votre code, nous nous occupons du reste” – va ĂŞtre enfin tenue. App Engine s’ouvre encore plus et supporte aujourd’hui Node.js, Ruby, Java 8, Python 2.7, Python 3.5, Go 1.8. Ă€ cela s’ajoute le support en beta de PHP 7.1 et .NET Core.

Cloud Functions (BĂŞta Publique)

Cloud Functions est un environnement serverless pour construire et connecter les diffĂ©rents services Cloud sans avoir Ă  gĂ©rer une infrastructure. C’est la plus petite unitĂ© de calcul offerte par GCP ; elle est capable de lancer une fonction et de l’arrĂŞter instantanĂ©ment.

Cloud Functions est un excellent moyen de construire des backends lĂ©gers et d’Ă©tendre la fonctionnalitĂ© de services existants. Par exemple, Cloud Functions peut traiter des actions Ă  rĂ©aliser quand des fichiers changent dans Google Cloud Storage ou quand de nouveaux messages sont disponibles dans Google Cloud Pub/Sub. Il peut exĂ©cuter des travaux lĂ©gers de traitement des donnĂ©es (ETL) ou fournir une couche de logique pour rĂ©pondre aux webhooks Ă©mis par n’importe quel Ă©vĂ©nement sur Internet. Les dĂ©veloppeurs peuvent invoquer directement Cloud Functions via HTTP sans avoir besoin de services supplĂ©mentaires.

Cerise sur le gâteau, il est possible d’utiliser Cloud Functions sur la plateforme Firebase. Cette fonctionnalité permettra au développeur de réaliser des opérations backends.


Disponibilité de nouvelles régions

Trois nouvelles régions sont disponibles sur Google Cloud Platform: la Californie, Montréal et les Pays-Bas.

BigQuery Data Transfer Service (Bêta Privée)

Ce service automatise le dĂ©placement de donnĂ©es des applications SaaS (Adwords, DoubleClick & Youtube) vers Google BigQuery de manière programmĂ©e. Les analystes pourront poser les bases d’un entrepĂ´t de donnĂ©es sans Ă©crire une seule ligne de code.

Google Cloud Dataprep (Bêta Privée)

Ce nouveau service permet de rĂ©duire considĂ©rablement le temps nĂ©cessaire Ă  la prĂ©paration des donnĂ©es pour l’analyse, ce qui reprĂ©sente environ 80% du travail des data scientists.


What Next?

Grâce Ă  ces annonces, l’offre Cloud de Google s’Ă©toffe encore plus et reste compĂ©titive face Ă  Amazon Web Services et Microsoft Azure.

DevOps DĂ©prĂ©ciation de l’orchestrateur fleet par CoreOS http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

CoreOS ont annoncé la dépréciation de fleet, leur orchestrateur de containers basé sur systemd et etcd, il y a maintenant un mois.

En effet, fleet, crĂ©Ă© en 2014, a pu servir de base de rĂ©flexion solide au dĂ©veloppement de l’orchestration de containers, mais est maintenant dĂ©passĂ© par des alternatives telles que Kubernetes, qui selon CoreOS « est en train de devenir le standard de facto pour de l’orchestration open source de containers ».

Il est normal de voir CoreOS pousser Kubernetes, ce dernier étant au coeur de Tectonic, leur solution propriétaire de gestion de clusters de containers. Dans la suite de ce mouvement, ils arrêteront donc tout support de fleet en février 2018.

Mais malgrĂ© cette dĂ©cision de CoreOS de se tourner vers Kubernetes, n’oublions pas de que d’autres orchestrateurs de containers existent : Nomad de Hashicorp, le mode Swarm de Docker, ou encore Apache Mesos associĂ© Ă  Marathon de Mesosphère ; pour ceux ayant la chance d’ĂŞtre prĂ©sents Ă  Devoxx France 2017, nous vous y proposerons d’ailleurs une University de 3h sur le thème de l’orchestration de conteneurs couvrant Swarm, Mesos/Marathon et Kubernetes.

Docker annoncent leur version Entreprise http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Docker vient d’annoncer une nouvelle « version » de Docker : Docker Enterprise Edition (EE). Cette sĂ©paration fait donc du Docker que nous connaissons la Community Edition (CE) afin d’Ă©viter toute confusion.

Le cĂ´tĂ© business est mis en avant dans cette version Entreprise, avec 3 dĂ©clinaisons : la « Basic » incluant support et certification, la « Standard » y ajoutant Docker Datacenter, et enfin la « Advanced » insistant sur l’aspect sĂ©curitĂ© avec les scans de vulnĂ©rabilitĂ©s sur les images.

Docker en profite Ă©galement pour changer de schĂ©ma de release ; lĂ  oĂą actuellement les releases Ă©taient un peu hasardeuses, les versions seront dĂ©sormais dĂ©livrĂ©es de manière temporelle : une release tous les 3 mois + une « Edge » mensuelle. Afin de reflĂ©ter ce changement du cycle de release, Docker change Ă©galement de schĂ©ma de nommage pour les version en s’orientant vers un schĂ©ma « YY.MM » comme Ubuntu, ce qui fait de la version actuelle la 17.03 (2017.Mars) : ne soyez donc pas surpris si votre Docker 1.13.1 se transforme en 17.03, c’est tout Ă  fait normal ! On ne peut que se rĂ©jouir Ă  l’idĂ©e de ces releases rĂ©gulières tant ce principe a rĂ©ussit Ă  Gitlab, qui sortent une nouvelle version chaque 22 du mois avec une prĂ©cision d’horlogerie depuis octobre 2011, rendant les tâches de mise Ă  jour panifiables et la possibilitĂ© de savoir quand sera disponible quelque chose qui aurait Ă©tĂ© contribuĂ© au projet.

Catégories: Blog Société

Mon premier hackathon #HackEgalitéFH

A Duchess Community Blog for France - jeu, 03/16/2017 - 09:00

« Sexisme Pas Notre Genre » , c’était le nom de la compagne lancée par Mme Laurence Rossignol, la ministre des Familles, de l’Enfance et des Droits des femmes, le 8 septembre 2016, et qui a pris fin le 8 Mars 2017. Cette grande mobilisation de six mois avait comme but d’inviter l’ensemble des citoyen.ne.s à agir afin de faire reculer le sexisme. Plusieurs initiatives ont vu le jour à cette occasion. J’ai eu la chance d’assister à une d’entre elles grâce à Duchess France.

J’ai Ă©tĂ© prĂ©sente au hackathon #HackEgalitĂ©FH consacrĂ© Ă  l’égalitĂ© professionnelle. Du 3 au 5 …

Cet article Mon premier hackathon #HackEgalitéFH est apparu en premier sur Duchess France.

Catégories: Association

Agile smells – Management visuel

agile_smells

Dans cette sĂ©rie d’articles consacrĂ©e aux Agile smells, je vous propose, au travers de situations rĂ©ellement vĂ©cues, de faire un tour d’horizon des dĂ©rives, des fausses bonnes idĂ©es ou simplement des phrases prononcĂ©es qui peuvent vous amener Ă  vous dire que quelque chose sent mauvais. Commençons par le management visuel…

« J’aime les monochromes de Whiteman » La situation

La première chose que je regarde lorsque je rentre dans le bureau d’une Ă©quipe agile, ce sont les murs. Ce lieu, champs de bataille de nos post-it prĂ©fĂ©rĂ©s, est parfois Ă©trangement dĂ©laissĂ© par certaines Ă©quipes. Si vous n’utilisez vos murs que pour exhiber les affiches de vos films prĂ©fĂ©rĂ©s ou les publicitĂ©s de votre sociĂ©tĂ© alors il y a certainement une lĂ©gère odeur dans votre bureau…

Pourquoi ça sent mauvais ?

Trois principales causes peuvent expliquer cette situation :

  • Pression externe

Une personne externe Ă  l’Ă©quipe avec une capacitĂ© de dĂ©cision forte est un peu trop prĂ©sente, elle vient rĂ©gulièrement mettre un coup de pression Ă  l’Ă©quipe en grimaçant devant le burndown chart, ou simplement vient chercher des coupables lors de situations de crise. Pour se protĂ©ger, l’Ă©quipe a alors le rĂ©flexe d’afficher moins d’information.

  • Pas de vision produit

Lorsque l’Ă©quipe n’a pas de vision du travail Ă  effectuer au-delĂ  de deux semaines, il lui est difficile d’anticiper les risques ou de prendre des actions d’amĂ©lioration. Sans une vision long terme, le travail n’a plus vraiment de sens et la motivation en est grandement affectĂ©e. Dans la plupart des cas, l’Ă©quipe se contentera alors de tenir Ă  jour le taskboard de l’itĂ©ration en cours.

  • Le tout numĂ©rique

Si l’on met de cĂ´tĂ© le cas des Ă©quipes non co-localisĂ©es, le choix du tout numĂ©rique, bien que parfois apprĂ©ciĂ©, n’est pas idĂ©al dans la majoritĂ© des contextes. Via un assemblage d’outils, il est impossible de voir en un coup d’oeil l’Ă©tat d’avancement sur le court, moyen et long terme, de capter les ressentis, de savoir quels sont les risques levĂ©s ou encore les plans pour s’amĂ©liorer.

Concrètement on fait quoi ?

Bon nombre de problèmes que l’on tente d’Ă©viter se rĂ©solvent naturellement quand on agit en totale transparence au quotidien. Le visuel doit ĂŞtre lĂ  pour vous aider mais aussi pour faire ressortir les manquements et les amĂ©liorations qu’il vous reste encore Ă  accomplir.

Voici selon mon expĂ©rience les Ă©lĂ©ments indispensables d’un bon management visuel :

  • Le Taskboard : Suivre le travail quotidien et donc avoir une vision Ă  très court terme. C’est assurĂ©ment celui que l’on retrouve dans la majoritĂ© des Ă©quipes agiles. Petit conseil : ajoutez des photos ou avatar des personnes en face des tâches qu’ils effectuent. Cela rend le taskboard davantage vivant, et sur les projets avec plusieurs feature teams, la photo avec prĂ©nom est utile pour connaĂ®tre les gens.
  • La Story Map : Donner une vision produit Ă  moyen ou long terme. Sert de base au travail du Product Owner.
  • Les Definition of Ready (DoR) et Definition of Done (DoD) : Afficher les règles du jeu clairement et s’y rĂ©fĂ©rer lorsque quelqu’un essaie de s’en dĂ©tourner.
  • Le Burndown chart de la Release : Donner une vision d’avancement sur le moyen terme.
  • Les Ă©lĂ©ments prĂŞts Ă  ĂŞtre pris en compte par l’Ă©quipe : Donner une vision Ă  court terme. Evidemment liĂ© au DoR, ceci est le minimum pour savoir quels sont les prochains Ă©lĂ©ments prĂŞts Ă  ĂŞtre dĂ©veloppĂ©s.
  • La dette technique : Mettre en Ă©vidence les sujets techniques qui entraĂ®nent un coĂ»t supplĂ©mentaire dans le dĂ©veloppement des fonctionnalitĂ©s. Pratique si quelqu’un s’Ă©tonne des temps d’implĂ©mentation en augmentation.
  • Les risques : Afficher clairement les risques qui peuvent mettre en pĂ©ril n’importe quel aspect du projet. Comme la dette technique, ils doivent vous servir de support pour ĂŞtre pĂ©dagogue vis-Ă -vis des pressions externes.
  • Le rĂ©sultat de la dernière rĂ©trospective : Afficher ce qu’il s’est dit et les actions qui en sont ressorties. C’est le meilleur moyen d’ĂŞtre totalement transparent sur la vie de l’Ă©quipe.

Vous avez des idĂ©es supplĂ©mentaires ? ExpĂ©rimentez-les ! N’oubliez pas cependant que chaque Ă©lĂ©ment composant votre management visuel doit ĂŞtre le plus Ă©purĂ© possible.

« Le taskboard et JIRA ne sont pas synchro, je dois croire lequel ? » La situation

L’Ă©quipe dispose de deux taskboards : un physique et un numĂ©rique. Lors des stand-up, l’Ă©quipe se place devant le taskboard physique et le met Ă  jour. C’est celui qui sert de support pour n’importe quelle discussion d’Ă©quipe. La version numĂ©rique, qui est identique Ă  la version physique en terme de colonne, est mise Ă  jour n’importe quand dans la journĂ©e. Elle est utilisĂ©e par l’Ă©quipe pour voir le dĂ©tail des stories (critères d’acceptation, exemples) et par le Scrum Master pour suivre les mĂ©triques (vĂ©locitĂ©, burndown chart). RĂ©gulièrement, les deux taskboards sont dĂ©synchronisĂ©s.

Pourquoi ça sent mauvais ?

Avoir un outillage numĂ©rique qui reprend des informations du management visuel n’est pas un smell en soi. C’est mĂŞme assez courant, car le taskboard physique a des limites en termes de nombre d’informations qu’il peut apporter. Leur mise Ă  jour en revanche est vĂ©cue la plupart du temps comme un travail administratif par l’Ă©quipe. La cĂ©rĂ©monie du stand-up permet de rendre cette mise Ă  jour plus vivante en la ramenant comme simple support d’une annonce faite Ă  l’Ă©quipe entière. La mise Ă  jour de la version numĂ©rique par contre, est celle qui est le plus souvent oubliĂ©e, tout simplement car elle ne sert Ă  rien pour les membres de l’Ă©quipe. Du moins pas directement…

Concrètement on fait quoi ?

Le contexte est Ă©videmment important, on ne gère pas un projet de trois personnes de la mĂŞme manière qu’un projet de quatre-vingts personnes rĂ©parties en feature team. Pourtant, le recours Ă  un outillage numĂ©rique est systĂ©matique mais pas forcĂ©ment adaptĂ© pour la grande majoritĂ© des cas.

Il faut donc se questionner sur les intentions de chacun des deux taskboards. Dans la plupart des Ă©quipes, cela devrait ĂŞtre :

  • Taskboard physique : donne la visibilitĂ© du travail sur lequel l’Ă©quipe est focalisĂ©e. Sa mise Ă  jour est du ressort des membres de l’Ă©quipe lors du stand-up meeting par exemple.
  • Taskboard numĂ©rique : donne accès au dĂ©tail des items de travail et gĂ©nère des mĂ©triques d’itĂ©ration et de release. Sa mise Ă  jour doit ĂŞtre du ressort des Product Owner et Scrum Master uniquement.

Mais nous pourrions aller un peu plus loin en estimant finalement que le taskboard numérique pourrait tout simplement être abandonné au regard de sa plus-value par rapport à son prix. Voici quelques raisons :

  • le dĂ©tail des items : s’il s’agit uniquement d’Ă©crire des critères d’acceptation ou des exemples, un outil comme Excel peut ĂŞtre suffisant.
  • les mĂ©triques : la plupart des outils (si ce n’est tous) ne sont pas optimaux sur la gĂ©nĂ©ration de graphe. Au moindre changement non prĂ©vu, l’outil est vite dĂ©passĂ©. C’est pourquoi d’ailleurs, Ă©normĂ©ment de Scrum Master reprennent manuellement les donnĂ©es pour gĂ©nĂ©rer leurs propres graphiques.
  • Gestion des releases : une story map bien Ă©tablie doit amplement suffire au suivi des releases et des mises en production.
  • Suivi des Ă©pics : Lorsqu’il y a un vrai suivi des Ă©pics et que celle-ci sont dĂ©coupĂ©es en nombreuses stories, un outillage adaptĂ© peut se justifier. Cependant bon nombre de projets n’ont pas ces problĂ©matiques et une story map peut une nouvelle fois ĂŞtre suffisante.
« Et si on ajoutait une autre colonne au taskboard ? » La situation

L’Ă©quipe a un taskboard Scrum de 7 colonnes. On y retrouve : « A faire », « En cours », « A reviewer », « A tester », « A dĂ©ployer », « A valider », « TerminĂ© ».

Pourquoi ça sent mauvais ?

Dans la grande majoritĂ© des cas, l’ajout d’une colonne dans le taskboard s’apparente surtout Ă  une fausse bonne idĂ©e. La nouvelle colonne va servir Ă  cacher des problèmes d’organisation en devenant la plupart du temps une file d’attente et en autorisant les dĂ©veloppeurs au travail en parallèle.

Revoyons chacunes des colonnes de notre situation :

  • « A reviewer » : marquer l’Ă©tape de revue de code signifie qu’il n’y a clairement pas de pair programming et qu’une revue de code ne se fait jamais sur demande. Les personnes ne sont donc pas intĂ©ressĂ©es dans l’apport d’une aide Ă  un coĂ©quipier.
  • « A tester » : les tests sont totalement dĂ©corrĂ©lĂ©s du dĂ©veloppement puisqu’ils sont effectuĂ©s une fois l’implĂ©mentation terminĂ©e. Le dĂ©veloppement d’une story semble donc suivre le schĂ©ma d’un cycle en V, qui plus est si une personne diffĂ©rente est dĂ©diĂ©e Ă  la rĂ©alisation des tests. S’il y a des manquements graves dĂ©tectĂ©s dans cette phase, la story va certainement revenir en arrière dans la colonne « En cours ».
  • « A dĂ©ployer » : le dĂ©ploiement d’un composant sur un environnement est fastidieux. Cela nĂ©cessite l’intervention d’une personne pour une durĂ©e non nĂ©gligeable.
  • « A valider » : ici intervient le Product Owner. Comme il n’est pas toujours disponible, les stories s’amassent dans cette colonne en attendant qu’il puisse se libĂ©rer. Comme pour les tests, si des manquements sont constatĂ©s, la story va revenir dans la colonne « En cours » et va devoir reprendre tout le processus avant d’atterrir de nouvau dans « A valider ».

En rĂ©sumĂ©, les stories se baladent continuellement de gauche Ă  droite et inversement, les dĂ©veloppeurs ne sont pas encouragĂ©s Ă  trouver des solutions pour amener le plus rapidement possible la story vers le « TerminĂ© ». Chaque passage de story dans la colonne qui suit va leur permettre de dĂ©marrer une nouvelle story Ă©tant donnĂ© que la nouvelle colonne n’est pas de leur ressort. La rĂ©sultante est une Ă©quipe composĂ©e uniquement d’individualitĂ©s et un WIP (Work In Progress) trop Ă©levĂ©.

Concrètement on fait quoi ?

Rester simple en se contentant des colonnes « A faire », « En cours » et « TerminĂ© », doit suffire Ă  rĂ©pondre aux besoins de 99% des Ă©quipes.

taskboard

Si vous souhaitez marquer ce genre d’Ă©tape, un post-it comme tâche de la story doit suffire. De plus, les dĂ©veloppeurs qui prennent en charge une story ne doivent pas pouvoir changer de story tant qu’elle n’est pas terminĂ©e. Les ralentisseurs, s’ils existent toujours, seront alors vraiment ressentis et pourront donner lieu Ă  de vraies amĂ©liorations comme :

  • dĂ©finir des user stories propices au pair programming en amont de l’itĂ©ration. Pour les autres, Ă©tant donnĂ© que les dĂ©veloppeurs ne peuvent pas changer de story, cela les forcera Ă  harceler leurs camarades pour qu’ils se libèrent le temps de la revue de code. En dehors d’un bug urgent de production, les membres de l’Ă©quipe devraient prioriser la revue de code plus qu’une tâche de dĂ©veloppement (la revue de code signifiant qu’une user story est plus proche du « terminĂ© » et donc qu’une partie des objectifs de l’itĂ©ration sera plus rapidement atteinte).
  • Mettre en place des pratiques comme le TDD, l’ATDD ou le BDD, avec ou sans un rĂ´le dĂ©diĂ© de testeur, qui rendront l’Ă©criture des tests et de l’implĂ©mentation complĂ©mentaires.
  • Automatiser certains traitements manuels et mettre en place des outils pour viser un dĂ©ploiement simplifiĂ© sur un simple clic bouton.
  • AmĂ©liorer la collaboration avec le PO tout au long de l’itĂ©ration avec plusieurs crĂ©neaux de disponibilitĂ© chaque jour pour l’Ă©quipe.

Sur le mĂŞme thème je vous invite Ă  lire Ă©galement l’article de GrĂ©gory Fontaine sur Scrum ou Kanban : Je hais les colonnes.

« Non mais on n’est jamais au courant de rien dans ce bureau ! » La situation

L’Ă©quipe est rĂ©partie dans deux bureaux distincts. Le management visuel est installĂ© dans un des deux bureaux.

Pourquoi ça sent mauvais ?

L’aspect gĂ©ographique est très important pour une Ă©quipe agile. Parfois des espaces mal agencĂ©s peuvent empĂŞcher de rĂ©unir dans un mĂŞme bureau toute l’Ă©quipe. Il est alors Ă©tonnant de voir comment des frustrations et des problèmes de communication peuvent apparaĂ®tre alors mĂŞme que les deux bureaux sont en face l’un de l’autre.

Installer l’ensemble du management visuel dans un seul bureau aura pour consĂ©quence d’indiquer Ă  tout le monde que la vie de l’Ă©quipe se passe ici. La moindre activitĂ©, discussion ou prise de dĂ©cision avec des Ă©lĂ©ments extĂ©rieurs se passera dans ce bureau, laissant une partie de l’Ă©quipe Ă  l’Ă©cart.

Concrètement on fait quoi ?

Il n’y a pas de remède miracle. Essayer d’appeler toute l’Ă©quipe, dès qu’une conversation semble utile, est impossible. Faire un rapport de ce qu’il s’est dit est Ă©galement une solution mais le nombre d’oublis devient important avec le temps.

Certaines frustrations seront impossibles à supprimer, par contre certaines actions concrètes peuvent aider :

  • RĂ©partir le management visuel sur l’ensemble des deux bureaux : par exemple, le taskboard dans un bureau et tout le reste dans l’autre. La somme des conversations sera mieux rĂ©partie sur l’ensemble des bureaux et enlèvera une partie des frustrations gĂ©nĂ©rĂ©es.
  • Eviter Ă©galement de rassembler des rĂ´les clĂ©s de l’Ă©quipe dans le mĂŞme bureau : un bureau avec Product Owner, Scrum Master et Leader technique rĂ©unis est Ă©videmment une mauvaise idĂ©e mĂŞme si cela paraĂ®t pratique.
Conclusion

Au travers de quatre situations, nous avons dĂ©couvert comment le management visuel pouvait rĂ©vĂ©ler des pratiques contre productives, mais Ă©galement, comment il pouvait ĂŞtre une aide d’une grande efficacitĂ© pour amĂ©liorer de nombreux aspects de la vie d’une Ă©quipe. Ne jetez pas votre dĂ©sodorisant tout de suite, nous revenons bientĂ´t avec de nouveaux agile smells dĂ©diĂ©s cette fois-ci au sprint planning meeting.

Catégories: Blog Société

LCC 165 - Et toi tu scales comment tes données ?

Audrey, Antonio, Emmanuel et Guillaume discutent Google Cloud Next, quelques nouveautés de JDK 9, Docker EE (?!), Cloudbleed, SHAttered, Uber et sa culture poison et comment scaler une architecture horizontalement. Entre autre.

Enregistré le 14 mars 2017

Téléchargement de l’épisode LesCastCodeurs-Episode–165.mp3

News Langages

Emmanuel le nouveau Java champion !!!
55 nouvelles fonctionalites de JDK 9 jlink, multi jar file, repl, collection factory methods, HTML5 javadoc, SHA–3, G1, semantic versioning etc
Construire des JARs multi-release avec Maven

Nouvelle version de Groovy 2.4.9

Introduction Ă  CompletableStage en Java
Retrofit 2.2
Migration a Swift 3 - cest chaud reflexions sur la backward compatibility de Java
Unicode expliqué en 15 minutes

Middleware

Les librairies Java inratables en 2017

Blockchain Etherium en Java
Interview sur l’ORM Doctrine de PHP

Une overview de Spanner, la base qui taquine CAP
CockroachDB

Java EE 8 les dates affinees
gRPC donné à la Cloud Native Computing Foundation
Lagom 1.3 est sorti
Kubernetes et son abstraction du runtime de container
WePay et le change data capture
Vert.x 3.4.0

Infrastructure

Docker EE

Cloud

Post-mortem d’Amazon S3
Comment AWS voit sa competition

Google Cloud Next 2017

Les 100 annonces de Cloud Next

Free trial / Free tier amélioré
Compute: App Engine Flex (GA), Cloud Functions (beta) et Firebase Functions, new regions, committed use discount, Skylake et 64 vCPU
BigData: Dataprep, data transfer service pour BigQuery, Datalab (GA)
Databases: Spanner, PostgreSQL
Machine Learning: Cloud Machine Learning Engine (GA), video intelligence API, rachat de Kaggle
Security: KMS (GA), 2FA, Data Loss Prevention API, Identity-Aware Proxy, Titan security chip

Formations Google Cloud sur Coursera

Outillage

Adopte un desktop Linux par PAG
Chrome les dix ans et la genèse du projet

Apache Maven 3.5 avec de la couleur !
Gradle 3.4 dépote avec la compilation incrémentale

Sécurité

Le coût des Ransomware

CloudBleed - CloudFlare et l’overrun à un million de dollars
Le post-mortem de CloudFlare

SHA–1 et la premiere collision:

Loi et société et organisation

GitHub termes de service

Uber et segregation des femmes developpeurs
Le premier temoignage
Dernières évolutions 1/2
Dernières évolutions 2/2

Antoine Sabot-Durand est star spec lead

La transformation ING en equipes microservices
12 startups souhaitent inventer la ville de demain avec la Mairie de Paris et NUMA Tim Berners-Lee: I invented the web. Here are three things we need to change to save it

Question crowdcasting

Morgan Durand nous pose une question sur la scalabilité horizontale et les données.

Conférences

Devoxx France les 5–7 avril 2017
Devoxx4Kids Paris le 8 avril 2017
Mix-IT les 20–21 avril 2017
Breizhcamp les 19–21 avril 2017
RivieraDev les 11–12 mai 2017
Web2day 7–9 juin, le CfP est ouvert
DevFest Lille 9 juin - inscriptions et CfP ouvert
Voxxed Days au Luxembourg le 22 juin
Jenkins User Conference Paris - 11 juillet

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

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux