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

CRAFT et obsession de la mesure : auto-Ă©valuez vous !

Il y a un an

Chez OCTO, nous sommes organisĂ©s en tribu. La tribu CRAFT a pour but d’accompagner Ă  l’adoption des pratiques du software craftsmanship pour nos clients mais aussi pour nous-mĂȘme.

Or, il y a un peu plus d’un an, des “anciens” octos ont constatĂ© des projets de delivery en souffrance. Nous avons Ă©tĂ© plusieurs Ă  constater que les pratiques crafts n’étaient pas toutes adoptĂ©es sur ces projets, notamment le TDD et les revues de code. De lĂ  sont parties plusieurs discussions, hypothĂšses et autres conjonctures. Mais la vraie question Ă©tait : nos recrues sont-elles formĂ©es Ă  ces pratiques ?

Le meilleur moyen qu’on ait trouvĂ© pour avoir la rĂ©ponse, c’est de leur demander : on ne pilote que ce qu’on mesure.

Sondage et initiatives

Nous avons donc lancĂ© un sondage le plus factuel possible Ă  destination des octos. Nous avons obtenu une centaine de rĂ©ponses qui Ă©tait en plus reprĂ©sentative de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous avons publiĂ© ces rĂ©sultats en interne dans un souci de transparence et pour susciter des initiatives.

Les premiĂšres initiatives Ă©taient l’accompagnement de craft·wo·men au sein d’équipe OCTO sur des projets de delivery, la tenue de BOF, REX et autre BBL pour sensibiliser aux pratiques de TDD et de code review.

Le timing correspondait aussi au lancement de notre livre blanc sur les pratiques craft : Culture Code. Initialement prévu pour sensibiliser nos clients, Culture Code a eu comme bénéfice de sensibiliser également en interne.

Autre timing parfait, la mise en place d’OCTO Skool, dont l’objectif sera dĂ©taillĂ© dans un prochain article, est de former nos recrues juniors aux pratiques agile et craft en proposant un cursus de formation intense lors de leurs premiers mois parmi nous.

Un an aprĂšs

Un an aprĂšs, nous avons proposĂ© exactement le mĂȘme sondage. Nous avons Ă©galement obtenu une centaine de rĂ©ponses qui Ă©tait tout aussi reprĂ©sentative de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous vous partageons les rĂ©sultats plus bas.

Nous avons la faiblesse de croire que la mise en place de nos initiatives ont eu comme consĂ©quence l’amĂ©lioration des rĂ©sultats. Autre constat : les projets sur lesquels ont Ă©tĂ© mis en place les pratiques de TDD et code review ne souffrent pas de problĂšmes de qualitĂ©.

Moralité

Si, comme nous, vous ĂȘtes convaincus que les pratiques craft vont vous permettre de faire du dĂ©veloppement durable, inspirez-vous du questionnaire en bas de l’article pour dĂ©tecter vos prochains chantiers (formations / accompagnements / coaching).

Pour constater les bĂ©nĂ©fices de vos initiatives, rejouer rĂ©guliĂšrement vos sondages pour trouver d’éventuelles corrĂ©lations et enclencher les prochains chantiers de votre amĂ©lioration continue.

Les résultats de 2017

C’est mieux sur la revue de code :

– comparĂ© Ă  l’annĂ©e derniĂšre, les revues sont plus variĂ©es, plus frĂ©quentes et plus collectives.

– seul 4,1% ne fait aucune revue de code (12,6% l’annĂ©e derniĂšre)

Fréquence des types de revues de code

Taux de ceux qui ne pratique aucune revue de code

 

C’est mieux sur les tests unitaires :

– La grande majoritĂ© teste unitairement (stable par rapport Ă  2016)

– Il y a nettement plus de personnes qui testent avant : 78,2% (60,7% en 2016)

– Il y a plus de personnes qui refactor aprĂšs que les tests soient au vert => TDD rules !

La pyramide des tests est mieux connue des octos : 91,8% (76,8% en 2016)…  

– … et est nettement plus respectĂ©e sur leurs projets : 61,8% (34,2% en 2016)

Testes-tu ton code unitairement ?
Testes-tu unitairement avant ou aprÚs l'implémentation ?

Pratiques-tu un refactoring une fois les tests passés au vert ?

Connais tu la pyramide des tests ? Est-elle respectée sur tes projets actuels ?

C’est mieux sur la partie clean code :

– 77,3% ont des standards de code sur leur projet (62,1% en 2016)

– les pratiques sont assez connues => un Ă©claircissement sur certaines pratiques est nĂ©cessaire

Ton équipe a-t-elle défini des standards de code ?Pratiques Clean Code

 

Le questionnaire complet

Quel est ton poste ?

Quel est ton ancienneté ?

Testes-tu ton code unitairement ?

  • Oui
  • Non

Testes-tu unitairement avant ou aprĂšs l’implĂ©mentation ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Pratiques-tu un refactoring une fois les tests passés au vert ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Connais-tu la pyramide des tests ?

  • Oui
  • Non

Est-elle respectée sur tes projets actuels ?

  • Oui
  • Non

Sur tes projets actuels , pratiques-tu la revue de code ?

  • Pair Programming
  • Peer Review Synchrone (cĂŽte Ă  cĂŽte en face de l’Ă©cran)
  • Peer Review Asynchrone (en faisant des commentaires dans un outil github, gitlab, sonar, gerrit, …)
  • Collective (Ă  3 ou plus devant un Ă©cran)]

Trouves-tu ça … ?

  • Facile
  • Difficile

Ton équipe a-t-elle défini des standards de code ?

  • Oui
  • Non

Pratiques-tu ces principes ? (si tu ne connais pas, réponds non)

  • Don’t Repeat Yourself (DRY) [Oui / Non]
  • Keep It Simple, Stupid (KISS) [Oui / Non]
  • You aren’t gonna need it (YAGNI) [Oui / Non]
  • Boy Scout Rule [Oui / Non]
  • Single Responsibility Principle (SRP) [Oui / Non]
  • Dependency inversion principle (DIP) [Oui / Non]
Catégories: Blog Société

Meetup PerfUG : Optimisations et Performances d’un POC en prod @ plusieurs millions de requĂȘtes

Ogury est la plateforme de data mobile qui permet d’accĂ©der aux donnĂ©es comportementales des profils de plus de 400 millions de mobinautes rĂ©partis dans plus de 120 pays. Monter une stack haute frĂ©quence n’est pas facile, David et Carles vous parleront de leur retour d’expĂ©rience.

Durant cette prĂ©sentation, Carles et David vous propose de revivre avec eux l’évolution de l’architecture d’Ogury. D’un POC monolite Ă  une architecture micro-service orientĂ© perf, constituĂ©e des 700 instances chez AWS.

David Caramelo, DĂ©veloppeur Craftsman passionnĂ© depuis 12 ans, actuellement Tech Lead full stack chez Ogury. David s’est forgĂ© son expĂ©rience essentiellement dans des startups parisiennes comme Viadeo ou Ogury et dans des cabinets conseil IT comme Xebia.

Carles SistarĂ©, Architecte-DĂ©veloppeur dans les clouds, actuellement Tech Lead de la team Delivery et co-fondateur d’Ogury. Carles a Ă©voluĂ© dans le monde de la AdTech en passant par Ad4Screen et en tant qu’amateur de l’open-source en tant que commiteur Node-Kafka et crĂ©ateur du module grpc-promise.

Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’OCTO.

logo

Le PerfUG est un meetup parisien qui a pour objectif d’offrir un lieu d’échanges informels oĂč toutes les personnes intĂ©ressĂ©es par l’optimisation et la performance sont les bienvenues quel que soit leur niveau. Nous sommes convaincus que la performance est une feature implicite et non nĂ©gociable d’une application et pourtant bien souvent oubliĂ©e. Le PerfUG permet d’Ă©changer idĂ©es et pratiques sur ces sujets pour obtenir plus simplement des systĂšmes performants. Le PerfUG souhaite faciliter la diffusion des derniers outils et des meilleures techniques pour maĂźtriser au plus tĂŽt la performance d’un systĂšme informatique.

imgres

Pour en apprendre davantage sur la Performance, retrouvez notre formation OCTO Academy : Performance des applications et du SI Ă  l’Ăšre du digital

Articles suggested :

  1. PerfUG : DynaTrace pour monitorer tous vos problĂšmes de performance
  2. Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)
  3. PerfUG : High Performance Java

Catégories: Blog Société

DevOps – OĂč s’arrĂȘte la responsabilitĂ© d’une feature team ?

 

 

Une Ă©quipe agile doit ĂȘtre autonome et responsable de bout en bout, voilĂ  le casse-tĂȘte qu’il faut se prĂ©parer Ă  rĂ©soudre quand on se lance dans une organisation en Feature Teams. Autonome ne veut pas dire libre ! Quand on oublie le monde des start-ups et qu’on cherche Ă  appliquer ce modĂšle organisationnel dans une grande entreprise, la confrontation Ă  la rĂ©alitĂ© est dure. Afin de rendre ce modĂšle possible, il faut construire des Ă©quipes au service des Feature Teams : bienvenue dans une organisation « as-a-service ».

Une équipe capable de livrer un incrément de valeur

Nous parlons réguliÚrement de Feature Teams sur le blog de Xebia. Prenons la définition du framework agile LeSS qui définit une Feature Team avec les caractéristiques suivantes :

  • elle a un backlog orientĂ© fonctionnalitĂ©
  • elle est cross fonctionnelle et cross composant
  • elle est stable et durable
  • elle est capable de livrer un incrĂ©ment de valeur.

Ces caractĂ©ristiques vont donner de l’autonomie Ă  l’Ă©quipe, moins il y a de dĂ©pendances, plus l’Ă©quipe sera en mesure de limiter les temps morts et les blocages. La complexitĂ© des plannings sera rĂ©duite par la mĂȘme occasion.

Les responsabilitĂ©s d’une Feature Team

Quand on parle de responsabilitĂ©s, ça commence Ă  se compliquer. Il vous est peut-ĂȘtre arrivĂ© d’entendre un ops dire aprĂšs un week-end d’astreinte :  » c’est pas le dev qui va se lever la nuit quand un serveur tombe ! « . Dans une organisation en Feature Team, il faut assumer le revers de la mĂ©daille : pour aller plus vite, il faut endosser plus de responsabilitĂ©s. Si je veux choisir une stack technique plus spĂ©cifique ou un OS diffĂ©rent des standards de l’entreprise, je ne peux pas attendre de support d’une Ă©quipe tierce : il faudra l’assumer soi-mĂȘme. RĂ©duire ses dĂ©pendances est allĂ©chant mais il faudra accepter les inconvĂ©nients de cette stratĂ©gie.

Les Platform Teams, une nouvelle organisation des « ops »

Pour que les Feature Teams ne deviennent pas des usines Ă  produire des fonctionnalitĂ©s impossibles Ă  maintenir, il faut les aider. L’importance des fournisseurs « as-a-service » dans le modĂšle d’organisation en Feature Teams est fondamentale. Pour aller vite, une Feature Team cherchera sans doute Ă  prendre le service le plus simple pour pouvoir le rendre spĂ©cifique Ă  son besoin. C’est le IaaS (Infrastructure as a Service) : « un serveur et les clĂ©s du camion ».

Certains fournisseurs vont plus loin et proposent des services plus Ă©voluĂ©s avec une garantie de maintien en service : le PaaS (Platform as a Service). Ils se peut que les Feature Teams soient heureuses d’utiliser ce service. Attention ! Ce service devra ĂȘtre construit en collaboration pour favoriser l’expĂ©rience utilisateur des membres de la Feature Team. Sans ce prĂ©-requis les Feature Teams se tourneront vers le IaaS. Oublier ses utilisateurs en interne a les mĂȘmes rĂ©percutions que de ne pas Ă©couter ses clients : ils s’Ă©loignent. Il faudra alors obliger l’utilisation des services PaaS pour des raisons stratĂ©giques ou sĂ©curitaires… Mauvaise idĂ©e !

DerniĂšre possibilitĂ©, le SaaS (Software as a Service). Une solution dans laquelle les Feature Teams utiliseront un logiciel clĂ© en main, avec les garanties et bien sĂ»r les contraintes. Les Platform Teams pourront soit dĂ©velopper et proposer la solution logicielle, soit acquĂ©rir une solution et la proposer. Dans tous les cas, il s’agit de solutions en libre-service mises Ă  disposition sur une plateforme.

 

Appelons ces Ă©quipes des Platform Teams. À l’instar des Feature Teams, ces Ă©quipes sont cross fonctionnelles, cross composant, stable et durable. Elles fonctionnent de maniĂšre agile et travaillent avec un product owner. Si vous ĂȘtes familier du modĂšle spotify, elles portent le nom d’infrastructures squads et elle ont le rĂŽle de « enable and support » (permettre et supporter). Ces Ă©quipes ops « as-a-service » sont des piĂšces importantes d’une organisation qui se veut devops.

Définir une limite de responsabilité

Afin que les Feature Teams et les Platform Teams puissent travailler ensemble sans se marcher dessus, il faut dĂ©finir la limite de responsabilitĂ© de chacune. C’est le point de dĂ©couplage. Les Platform Teams doivent livrer sur une plateforme self-service. Ce produit “as-a-service” requiert de la maintenance, de l’innovation et des responsables. Ce modĂšle permet aux Feature Teams de dĂ©velopper des produits dont elles vont pouvoir garder la responsabilitĂ© du cycle de vie en entier. Elles bĂ©nĂ©ficieront de services avec un support, d’une stack technique et de configurations validĂ©es par l’entreprise. Par exemple des distributions d’OS validĂ©es, des serveurs avec les patchs de sĂ©curitĂ© Ă  jour.

Quelles Platform Teams pour mon organisation ?

DerriĂšre chaque service qui fonctionne avec un systĂšme de ticket, il y a sans doute la possibilitĂ© de crĂ©er une ou plusieurs Platform Teams. Cela implique des changements. Le premier est de passer d’une activitĂ© de run Ă  une activitĂ© de mise Ă  disposition de service. Ceci se fait concrĂštement par la production d’API’s qui seront mises Ă  disposition des Feature teams. Par exemple, des DBA’s qui proposent une API de refresh des bases de donnĂ©es ou des administrateurs systĂšmes qui proposent une API pour redĂ©marrer des serveurs automatiquement. A chaque action automatisĂ©e et « APIsĂ©e », le temps gagnĂ© devra ĂȘtre rĂ©investi dans la transformation en Ă©quipe « as-a-service ». Chaque service de ce type mis Ă  disposition permettra aux Platform Teams de se libĂ©rer du temps. Temps qu’il faudra mettre Ă  profit pour Ă©tudier les besoins des Feature Teams et proposer des services Ă  forte valeur ajoutĂ©e, comme n’importe quelle Ă©quipe agile. Peu a peu les Platform Teams apprendront Ă  comprendre leurs utilisateurs pour gagner le badge « build the right thing » en plus de « build the thing right » dans le challenge du continuous delivery.

A la recherche du point D

C’est maintenant le moment de faire une introspection sur votre systĂšme d’information. Il n’y a Ă©videmment pas de rĂ©ponse universelle dans le choix de votre ou vos point(s) de dĂ©couplage. Par culture, de nombreuses organisations sont trĂšs prescriptives et vont vouloir tout encadrer (PaaS voir SaaS) mais est-ce bĂ©nĂ©fique dans un contexte agile oĂč les Ă©quipes gagnent en autonomie et en responsabilitĂ© ? Est-ce que l’Ă©nergie, et donc le budget, investis en valent vraiment la peine? Dans ce cas, un point de dĂ©couplage IaaS donnera sans doute la possibilitĂ© de commencer dĂšs demain. Autre exemple, si le service n’est pas critique ou diffĂ©renciant pour votre mĂ©tier, le SaaS sera sans doute une alternative intĂ©ressante. DĂ©velopper son outil de post-it virtuel ou son pipeline de dĂ©ploiement est rarement une stratĂ©gie gagnante. Il vous reste donc Ă  vous lancer dans votre transformation en Feature Team avec la dĂ©finition des responsabilitĂ©s Ă  l’esprit.

Catégories: Blog Société

Insert KOIN for Dependency Injection

ekito people - lun, 06/26/2017 - 08:00

KOIN is a dependency injection framework that uses Kotlin and its functional power to get things done! 

TL;DR: We have just released the first version of Koin, an open source Kotlin dependency injection framework: github/koin and github/koin-android. This is a more compact repost of my “Better dependency injection for Android” article.

In every dependency injection framework we usually have the same concepts: instances container, reference binding, module definitions, graph dependency
 The injection of components is generally done by introspection (scan your class to look for attributes to be injected), which can be costly on mobile devices. That’s why solution such as Dagger emerged with the idea of processing everything and generating source code injection plumbing for you. On Android development platform, as an alternative to the top used Dagger framework, you can see interesting initiatives like Toothpick that avoid the need for generated code (but use introspection–there is no magic). Keep in mind that all of these solutions have been made in the Java language context.

A few month ago, Sebastien Deleuze proposed a functional way of declaring dependencies into Spring Framework thanks to Kotlin. The gain is quite clear. No need for proxies, introspection or code generation. Just declare your components, assemble it and reuse it thanks to lambda expressions, functions and DSL. All the plumbing behind it is highly simplified, and its global overhead reduced too.

 

The KOIN DSL

Why we are writing a new project when there are already have projects such like Kodein? The proposition of the Koin framework is not dissimilar, but the main idea is behind is to be compact and straight forward to ensure the main value: to allow you to describe your app context in a few lines and reuse it easily everywhere!

This KOIN DSL provides you a simple way to declare your content within lambdas:

The Module class brings the main DSL for your components definition. You can now declare your dependencies in the onLoad() method, within the declareContext function:

  • provide – allows to provide a component in a functional way
  • get – retrieves your component

Note that all your bean definitions are lazily declared. An instance will be made only when an injection is called. We resolve dependencies from context directly with the get() function, which makes bean resolution for you (no need to specify typing, Kotlin is strong enough). You can check the Koin documentation page, for more information on the core features.

Now just build your module context and inject your components from it. That’s all!

 

Insert Koin and start injecting!

Let’s build an Android app with Koin-Android, an Android specific Koin library. You can find the complete sample app available here. Start with an update of your build.gradle:

// repository if needed
allprojects {
    repositories {
        jcenter()
    }
}
// Koin for Android
dependencies {
   compile 'org.koin:koin-android:0.1.2'
}

Write your module class and describe your dependencies (here we have okhttp, retrofit and a WeatherService class):

The AndroidModule is a module class specialized for Android needs: you can get your injections and applicationContext, resources & assets within your dependencies. e.g: I need my server url here.

Extend KoinApplication (or KoinMultiDexApplication) in your Android Application class, to help you build your module and in a single swoop, provide access to all Android extensions:

That’s it! You’re now ready. You can access your Koin context and inject your dependency in your Activity (or Fragment) with the getKoin() function. Below is a way of lazy injecting my WeatherService class:

Note: I use lazy val injection to give my value a lazy evaluation (avoiding the need to evaluate it at init phase). If you use var, you will have to inject it later and use lateinit. That’s why I prefer using lazy val if I can. Note that it could be also done by delegate.

Dependency injection done in just a few lines 

Catégories: Blog Société

Revue de Presse Xebia

revue de presse 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é Swift 4 rétropédale http://blog.xebia.fr/author/nullhttp://twitter.com/nullhttp://github.com/mbretonPar JC Pastant

Suite aux retours de la communautĂ© aprĂšs la premiĂšre bĂȘta de Swift 4, la Core team a dĂ©cidĂ© de retirer la proposal SE-110 de la release finale.

Cette proposition supprimait le coalescing implicite entre f(x,y) et f((x,y)) ce qui, au regard des retours particuliÚrement négatifs, engendrait une verbosité accrue non négligeable.

Si vous aviez déjà migré sur Swift 4 beta 1, attendez-vous à devoir dé-migrer une partie de votre code ! ;)

Data Google permet d’entraĂźner un modĂšle multi-tĂąches avec MultiModel http://blog.xebia.fr/author/ybenoithttp://twitter.com/%40YoannBENOIThttp://github.com/ybenoitPar Yoann Benoit

Dans un rĂ©cent article de leur blog, Google Research prĂ©sente MultiModel, un modĂšle capable d’ĂȘtre entraĂźnĂ© sur plusieurs tĂąches (image recognition, translation, speech recognition). Cette implĂ©mentation ouvre les portes aux systĂšmes d’Intelligence Artificielle gĂ©nĂ©rale, capables de prendre des dĂ©cisions dans plusieurs domaines grĂące Ă  un seul et mĂȘme modĂšle. Il est intĂ©ressant de constater que les donnĂ©es par rapport Ă  un domaine spĂ©cifique (image captionning par exemple) permettent aussi d’amĂ©liorer les performances dans d’autres domaines. MultiModel a Ă©tĂ© rendu open-source avec la nouvelle librairie Tensor2Tensor de TensorFlow.

DevOps DĂ©ploiement de modĂšles de machine learning sur Kubernetes par Domino http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Domino, proposant Ă  ses utilisateurs de publier leurs modĂšles de machine learning en Python ou R sous forme d’API REST pour eux, viennent de complĂštement rĂ©-architecturer leur infrastructure en se basant sur Kubernetes, et nous proposent un retour sur cette mise en place.

Le point principalement mis en avant est celui de la facilité de déploiement offerte par Kubernetes, qui permet en effet de déployer les nouvelles versions de modÚles de maniÚre vraiment simple et automatisée.

MalgrĂ© cette facilitĂ©, la problĂ©matique d’exposition des services de maniĂšre tout aussi automatique et transparente s’est posĂ©e : pour y rĂ©pondre, ils ont choisi de se tourner vers Traefik, le reverse-proxy/load-balancer dynamique en Go capable de directement se connecter Ă  Kubernetes pour exposer et load-balancer des services.

4 rĂŽles pour un leader DevOps http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Mettons pour une fois le cĂŽtĂ© technique de cĂŽtĂ© avec cet article de Jaxenter sur les 4 rĂŽles d’un leader DevOps.

Les 4 roles évoqués sont les suivants :

  • Role 1 – Tell the Story
  • Role 2 – Be the safety guard!
  • Role 3 – Build the Kernel team
  • Role 4 – Be the communication enabler

En rĂ©alitĂ©, cet article adresse de maniĂšre large la problĂ©matique du leadership face au changement, s’appliquant donc logiquement Ă  toute dĂ©marche de transformation DevOps. On parle bien ici de leadership, permettant d’inciter ceux concernĂ©s par le changement Ă  en ĂȘtre eux-mĂȘmes les acteurs, et non pas de management.

Le Role 1 évoqué ici (« Tell the Story ») correspond au final trÚs bien à ce que Simon Sinek décrit dans sa conférence « Start With Why »; une conférence à regarder pour quiconque intéressé par ces problématiques de leadership !

Catégories: Blog Société

Managing Customer Accounts with Tempo and nFeed

Le blog de Valiantys - jeu, 06/22/2017 - 15:35

The following is a guest blog written by Marta Schluneger, the Product Marketing Manager at Tempo. Tempo is a cloud-first software company that helps teams at 10,000 companies—SMBs and large-scale enterprises—collaborate, plan and schedule resources, manage budgets, and track time directly from their daily workflow.   Tempo Timesheets helps software, IT services, and business teams track their ...

The post Managing Customer Accounts with Tempo and nFeed appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Elm Europe 2017

L'actualité de Synbioz - mer, 06/21/2017 - 23:00

Nous sommes de plus en plus nombreux Ă  dĂ©couvrir de nouvelles technologies et de nombreux langages de programmation. Chez Synbioz, nous tentons quotidiennement d’explorer cette Voie LactĂ©e numĂ©rique qui ne connait plus de frontiĂšres.

Et parfois, nous tombons nez Ă  nez sur des ovnis qui ont une autre vision du monde, et Ă  plus forte raison, en ce qui concerne cet univers numĂ©rique. Dans cet article, nous n’allons pas nous contenter de vous parler de Elm, ce langage prometteur qui rassemble des dĂ©veloppeurs de tous horizons et qui suscite de plus en plus d’intĂ©rĂȘt.

Nous allons rencontrer sa communauté !

Lire la suite...

Catégories: Blog Société

[Agile Tour 2017]

Agile Nantes - mer, 06/21/2017 - 18:04
SAVE THE DATE C’est le jeudi 16 novembre 2017 que se dĂ©roulera la 9Ăšme Ă©dition à l’IMT Atlantique (4 Rue Alfred Kastler, 44300 Nantes). Le thĂšme de cette annĂ©e : Rendez vous en terre inconnue… Cet Ă©vĂ©nement ne pourrait pas exister sans son public, ses orateurs et ses sponsors, alors nous comptons sur votre prĂ©sence ! APPEL À ORATEURS Envie de […]
Catégories: Association

Feedback sur la Product Conf de Paris

Blog d’Ippon Technologies - mer, 06/21/2017 - 14:41

Voici quelques jours que la confĂ©rence 2017 de Paris est terminĂ©e. Ce jeudi 1er juin lĂ , j’y Ă©tais, vous aussi ? Il faut qu’on parle.

Cette seconde session en quelques chiffres : 16 speakers, 12 talks, 2 salles et plus de 400 participants. Soit le double de l’annĂ©e derniĂšre, ce qui montre l’engouement pour le sujet du Product Management et de ses activitĂ©s. L’organisation nous a dĂ©nichĂ© un lieu magique, la Grande Crypte sous l’Ă©glise Saint HonorĂ© d’Eylau en plein coeur du 16Ăšme arrondissement de Paris. Un lieu que personnellement je ne connaissais pas.

Parlons un peu du casting et des sessions que j’ai pu voir.

La keynote d’ouverture sous forme d’interview a bien lancĂ© la journĂ©e. Paulin Dementhon, CEO de Drivy, nous a expliquĂ© la genĂšse de l’entreprise, son extension pragmatique Ă  l’international, son organisation en Feature Team ainsi que de ses envies et opportunitĂ©s autour de la voiture autonome. Sa crainte Ă©galement qu’un Uber puisse devenir un Drivy, et l’éventuelle arrivĂ©e de ses redoutables concurrents amĂ©ricains sur le marchĂ© français. L’organisation avait mis en place l’application Wisembly pour poser les questions, idĂ©e de gĂ©nie qui permettra de rendre fluide cette phase qui clĂŽture chaque fin de session. A ma grande surprise, ce n’était que le dĂ©but d’une longue journĂ©e, de trĂšs nombreuses questions portaient sur le thĂšme de l’organisation des Ă©quipes et de l’entreprise. Ce thĂšme sera rĂ©current dans plusieurs de mes sessions.

La seconde session de ma matinĂ©e Ă©tait celle de Brian Crofts, VP Produit de Pendo. Rien de particulier Ă  ajouter sur cette session, si ce n’est une question anodine Ă  premiĂšre vue et qui reviendra Ă  plusieurs reprises dans les session suivantes. Vous savez cette question dĂ©licate et gĂȘnante oĂč l’on fait semblant de ne pas l’avoir entendu afin de ne pas y rĂ©pondre. Quelle est la diffĂ©rence entre un Product Manager et un Product Owner ? Brian a prĂ©fĂ©rĂ© parler de Product Leader, intĂ©ressant, cependant cette question est revenue par la suite dans d’autres sessions comme quoi il y a bien un malaise sur ce sujet prĂ©cis.

Finalement nous arrivions Ă  la pause dĂ©jeuner. Un repas simple et lĂ©ger, qu’il fallait nĂ©cessairement clĂŽturer avec une bonne glace et profiter d’une terrasse ombragĂ©e avec mes collĂšgues.

Je dĂ©marrais cet aprĂšs-midi lĂ  par une magnifique session et un speaker hors norme. Cela reste pour ma part LA session de cette confĂ©rence, celle de Luc Behar, CMO de Molotov TV. Une merveille. Difficile d’en faire un rĂ©sumĂ© de peur d’oublier quelque chose, tant la session Ă©tait riche d’enseignement concernant les (contre)vĂ©ritĂ©s sur le Product Management.
Je partage l’idĂ©e de Luc concernant le danger de rĂ©aliser des dĂ©veloppements incrĂ©mentaux, la premiĂšre prioritĂ© reste de corriger les anomalies et de supprimer les frustrations des utilisateurs avant mĂȘme d’ajouter des nouvelles fonctionnalitĂ©s. Il a fait allusion au framework AARRR (Acquisition, Activation, Retention, Referral, Revenue), trĂšs Ă  la mode, notamment le haut de la pyramide (Acquisition, Activation) qu’il met plus en lumiĂšre que la rĂ©tention car un super produit bĂ©nĂ©ficie toujours du bouche Ă  oreille. Également se poser les bonnes questions, notamment celle de savoir si l’on mesure bien l’activation et l’abandon ? Lorsque le client est parti, c’est trop tard.

La session suivante fut celle de Jean-Charles Samuelian, cofondateur et CEO de Alan. Cette startup a l’ambition de devenir leader du secteur de l’assurance santĂ© (souvent appelĂ©e mutuelle). Avec une premiĂšre levĂ©e de fond de 12 millions d’euros et une politique de pricing agressif via du hacking tarifaire chez les concurrents, l’entreprise a obtenu l’agrĂ©ment officiel pour devenir une sociĂ©tĂ© d’assurance notamment via l’entrĂ©e au capital de CNP.
Le message de Jean-Charles est simple mais terriblement percutant et efficace, faire simple et vite dans un secteur sclĂ©rosĂ© et compliquĂ©. En cela le produit va servir l’acquisition, ĂȘtre Ă  l’écoute des utilisateurs en proposant toujours plus de valeur sur l’intĂ©gralitĂ© de la chaĂźne. L’organisation de l’entreprise est inspirĂ© de Google Ventures, cela fait le buzz, et semble tout de mĂȘme assez bordĂ©lique. Objectif Ă  la semaine, pas de Product Management, petite Ă©quipe oĂč tout le monde fait tout. Est-ce que cela peut perdurer dans le temps ? A suivre.

La session suivante fut celle de Jessy Bernal et Florian Duchene, respectivement CTO et PM de Doctolib. IntĂ©ressante session, je suis moi mĂȘme utilisateur du service, on apprend comment l’aventure a dĂ©marrĂ© avec la mise en place de la plateforme technique en moins de 3 mois, la rĂ©alisation des fonctionnalitĂ©s basiques de prise de rendez-vous et de gestion de planning Ă  minima puis la dĂ©marche de trouver 30 clients afin de pouvoir lever les fonds.
AprĂšs 3 ans d’anciennetĂ©, 21 000 praticiens et 9 millions de patients. Un catalogue de quelques 300 fonctionnalitĂ©s juste sur la fonctionnalitĂ© calendrier. Une organisation Ă  taille humaine, 320 personnes dont juste 40 personnes Ă  la DSI et seulement 10 dĂ©veloppeurs. 4 Ă©quipes organisĂ©es en Feature Teams et une seule Ă©quipe Design transverse, des PO organisĂ©s sur les axes praticien et patient. Jessy avouera la complexitĂ© croissante et exponentielle du logiciel.
IntĂ©ressant, les deux speakers nous parlerons des 4 axes d’innovation Ă  venir : organisation des cabinets, relation entre le patient et les praticiens, relation entre les praticiens via doctolib network et la gestion de la santĂ© des patients.

Finalement la journĂ©e se termine par la keynote de clĂŽture, encore une fois sous forme d’interview avec les deux co-fondateurs de Heetch, Teddy Pellerin et Mathieu Jacob.
Le retour d’expĂ©rience est intĂ©ressant car la solution part d’une idĂ©e toute simple, comment se dĂ©placer la nuit dans la capitale. L’aventure dĂ©marre en 2013, l’idĂ©e est de mettre en relation des conducteurs et des particuliers pour se dĂ©placer et ainsi partager les frais. La cible de dĂ©part, les 18-25 ans comme early adopters, pas de communication, pas de presse, juste le bouche Ă  oreille.
La premiĂšre version de l’application sort en septembre 2013 sous forme de marketplace, 2 communautĂ©s qui doivent grossir en mĂȘme temps, celles des conducteurs et celles des passagers. Objectif prioritaire, acquĂ©rir des passagers. Le business model repose sur la mise en relation et le paiement d’une commission.
Le succĂšs du dĂ©but n’est pas le fait du produit, Heetch rĂ©alise plus de trajet que les autres tout simplement. Une part de chance aussi avoueront les deux fondateurs, et un bouche Ă  oreille de folie. Ils seront sur le terrain, Ă  la sortie des boĂźtes de nuit et des bars parisiens tous les vendredis, samedis et dimanches.

Cette confĂ©rence est un bon cru : une belle journĂ©e, une belle organisation, des sujets passionnants et des speakers pertinents. Pour autant, je dois reconnaĂźtre que j’ai quelques remarques. J’ai entendu, notamment lors des diffĂ©rentes pauses, que certains participants semblaient un peu déçus du contenu. Certes il y a beaucoup de storytelling et un peu de discours commercial, il faut le reconnaĂźtre, mais certains participants s’attendaient Ă  plus de concret. C’est Ă  dire de la mĂ©thode et des outils afin de se perfectionner. Est-ce le lieu pour cela ? Je pense que oui mais il faut prĂ©ciser qu’il ne s’agit pas d’une confĂ©rence Agile.
Cette confĂ©rence doit exister et perdurer car nĂ©cessaire mais elle doit s’amĂ©liorer. Je serai fidĂšle au poste, prĂ©sent. Je vous dis donc Ă  l’annĂ©e prochaine.

L’article Feedback sur la Product Conf de Paris est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

C’est dĂ©cidĂ© : je passe indep’ Ă  la rentrĂ©e !

A Duchess Community Blog for France - mer, 06/21/2017 - 10:16

Depuis un petit moment, nous croisons lors des événements pas mal de personnes qui souhaitent se lancer en freelance mais qui ont beaucoup ( trop ) de doutes. A peine remises de la soirée avec Jessie Frazelle et le Paris Container Day, nous organisons mardi 27 Juin, en partenariat avec Hopwork, une soirée consacrée à ce statut synonyme de liberté pour beaucoup, mais qui peut aussi faire peur.

 

Inscription ici Programme de la soirée 19:00-19:10  Arrivée et accueil par Duchess France

 

19:15-19:30  Le freelancing, par Jean-Baptiste Lemée

Jean-Baptiste, CTO et co-fondateur de Hopwork et ancien

Cet article C’est dĂ©cidĂ© : je passe indep’ Ă  la rentrĂ©e ! est apparu en premier sur Duchess France.

Catégories: Association

LCC 171 - Et sinon, ton micro est branché ?

Arnaud, Audrey, Guillaume et Vincent discutent Jigsaw, NPM, Codenvy, Google I/O, clavier, JMeter, JIT et d’autres choses. Vincent Ă©tait lĂ  on vous jure, il a juste oubliĂ© d’allumer son micro.

Enregistré le 9 juin 2017

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

Comment faire un crowdcasting

News Langages et JVM

Java 9 et Jigsaw, Mark Reinhold tient toujours la barre du navire
 le titanic arrivera-t’il à quai ?

Plateformes

NPM 5.0

Kubernetes

Oracle rejoins la dance Kubernetes

Cloud

Codenvy racheté par Red Hat
AWS embauche James Gosling
(XWiki news: Daniel Glazman rejoint XWiki SAS)

Google I/O

All 101 announcements from Google I/O ‘17
Google Cloud TPUs
Tensor Flow Research Cloud
AutoML
Google Lens
Android O
Android Instant Apps
Google Assistant SDK
Polymer 2.0
Lighthouse
Workbox
What’s new from Firebase at Google I/O 2017
Firebase SDKs are going open source
Retour de Jean-François Garreau

Outillage

GitHub lance sa marketplace + une nouvelle API GraphQL
Certbot Un “bot” pour automatiquement passer en HTTPS vos sites avec Let’s encrypt
Java Stream Debugger Plugin Un plugin pour debugger vos streams dans Intellij Idea.

Autre

L’AFNOR ouvre le projet de norme du clavier français aux commentaires
Quoi d’neuf Docker ? revient !!! Enfin peut-ĂȘtre 


Loi et société et organisation

Bilan mitigĂ© un an aprĂšs l’adoption du rĂšglement de l’internet ouvert
Coder, ce n’est ni facile, ni marrant

Outil de l’épisode Apache JMeter par Vincent Daburon (crowdcasting)

Les nouveautés de JMeter

JMeter Plugins

Plugins de Vincent DABURON

Nombreux liens atour de JMeter

Awesome JMeter

Rubrique débutant

Just-in-time compilation

Conférences

Voxxed Days Luxembourg le 22 Juin - Il reste quelques places, dĂ©pĂȘchez vous
Jenkins Community Day à Paris le 11 Juillet - Inscriptions ouvertes (avec discount sur la liste du Jenkins Area Meetup Paris - ne le répétez pas)
Jug Summer Camp le 15 Septembre à La Rochelle - CfP ouvert (jusqu’au 23 juin)
DevFest Toulouse le 28 septembre - Inscriptions et CfP ouvert
DevFest Nantes les 19 & 20 Octobre - Inscriptions et CfP ouvert (jusqu’au 30 juin)
Scala.io le 2 et 3 novembre à Lyon - Inscriptions et CfP ouvert (jusqu’au 8 sept)
Devoxx Belgique du 6 au 10 novembre - Inscriptions et CfP ouvert
Codeurs en Seine Ă  Rouen le 23 novembre - CfP ouvert (jusqu’au 31 aoĂ»t)

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?

Catégories: Blog Individuel

Exocet 2.12: One operation automatically creates multiple issues

Le blog de Valiantys - mar, 06/20/2017 - 10:00

In typical Agile fashion, every few weeks we try to make the tasks for JIRA admins slightly easier. During this sprint our main focus was to minimise the tedious work by allowing you to create multiple issues with one operation. Exocet 2.12 also allows you to direct projects only to the relevant teams and have more control over your post ...

The post Exocet 2.12: One operation automatically creates multiple issues appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Retour sur l’aprùs-midi du Domain-Driven Design

Le 7 juin dernier s’est dĂ©roulé l’aprĂšs-midi du Domain-Driven Design au centre de confĂ©rence Microsoft, Ă  Issy-les-Moulineaux. Cet Ă©vĂšnement, animĂ© par Thomas Pierrain, Bruno Boucard et JĂ©rĂ©mie Grodziski (co-organisateurs du meetup DDD Paris et fondateurs du mouvement « Let’s reboot DDD »), avait pour objectif l’introduction aux patterns techniques et Ă  l’approche du DDD au travers d’un live-coding longue durĂ©e sur un code legacy. Autrement dit, les conditions que nous, dĂ©veloppeurs, rencontrons au quotidien par opposition aux prĂ©sentations partant habituellement d’une feuille blanche.

Xebia Ă©tait prĂ©sente Ă  cet Ă©vĂšnement et vous propose de revenir sur ce dernier en vous fournissant un certain nombre de pointeurs pour creuser le sujet et ĂȘtre en mesure de l’appliquer dĂšs Ă  prĂ©sent sur vos bases de code.

L’aprĂšs-midi s’est articulĂ© autour d’une keynote revenant sur la genĂšse du DDD suivie de 3 sessions de live-coding respectivement dĂ©diĂ©es Ă  la pose d’un harnais de tests, Ă  l’utilisation des patterns techniques du DDD et Ă  celle des concepts d’une architecture hexagonale. Nous vous proposons de suivre ce mĂȘme cheminement dans ce compte-rendu.

Keynote

Le DDD trouve son origine dans un constat simple : il est devenu aisé de faire du logiciel mais les coûts de maintenance restent trop élevés, dû notamment à la complexité. Cette derniÚre est de 3 types : le domaine, le logiciel et les individus.

Combattre la complexité au coeur du logiciel

Le best-seller d’Eric Evans, Ă  l’origine du DDD, propose de « combattre la complexitĂ© au coeur du logiciel ».
JĂ©rĂ©mie Grodziski dĂ©finit ce dernier comme « l’ensemble des concepts qui permettent de rĂ©soudre des problĂšmes Ă  travers des cas d’utilisation ».
Ce coeur varie bien Ă©videment d’un contexte Ă  l’autre.

Par exemple, dans le domaine de la comptabilitĂ© Ă  double entrĂ©e, on utilise les concepts de compte, dĂ©bit, crĂ©dit, montant, etc. pour rĂ©soudre des problĂšmes de traçabilitĂ© et de robustesse. Autre exemple, dans le domaine des environnements de dĂ©veloppement intĂ©grĂ©s, on utilise les concepts de projet, fichier, refactoring, analyse, etc. pour rĂ©soudre des problĂšmes d’intĂ©gration et de productivitĂ©.

Pour traiter cette complexitĂ©, on cherche un meilleur alignement entre l’espace du problĂšme et l’espace de la solution. Et celui-ci passe incontestablement par une meilleure comprĂ©hension entre les personnes. Pour reprendre le mojo de Thomas et JĂ©rĂ©mie : « Make the implicit, explicit » (« Explicitez les implicites ! »).

DDD, une boite Ă  outils des plus riches

DDD peut ĂȘtre vu comme :

  • une approche de conception (prendre des dĂ©cisions plus ou moins impactantes mais de maniĂšre consciente).
  • et une boite Ă  outils Ă  2 Ă©tages :
    • lorsque l’on code, via les patterns tactiques (entitĂ©s, values objects, fonctions pures, etc.).
    • lorsque l’on architecture, via les patterns stratĂ©giques (bounded contexts, couches d’anti-corruption, architecture hexagonale, etc.).

Attention ! DDD n’est surtout pas un processus ou une mĂ©thode qui nous dit quoi faire Ă  chaque instant.
Il s’agit de faire usage de cette approche et de cette boite Ă  outils pour connecter nos dĂ©cisions aux objectifs du mĂ©tier.

En résumé, le DDD cherche à répondre à la question suivante : « comment intégrer au mieux le domaine dans le logiciel ? »

Contexte du live-coding

Thomas, Bruno & JĂ©rĂ©mie se sont inspirĂ©s du kata TrainReservation d’Emily Bache pour mener Ă  bien leur aprĂšs-midi de live-coding (4h au total, respect !).
Dans ce dernier, il s’agit de rĂ©server des billets de train en tenant compte d’un certain nombre de rĂšgles telles que :

  • Ne pas dĂ©passer 70% des places rĂ©servĂ©es dans le train (pour laisser la possibilitĂ© de mener des opĂ©rations de derniĂšre minute).
  • Ne pas dĂ©passer 70% des places rĂ©servĂ©es dans chaque voiture (on n’aime pas voyager dans un train bondé !).
  • Garder les siĂšges d’une mĂȘme rĂ©servation dans la mĂȘme voiture.

#AMDDD du legacy jusque dans les blagues

Catégories: Blog Société

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

DĂ©couvrez pour le SeiziĂšme #PortraitDeCDO, avec le portrait de SĂ©bastien Imbert Chief Digital Marketing Officer de Microsoft. Vous allez pouvoir dĂ©couvrir les enjeux du numĂ©rique pour son entreprise, ses contraintes au quotidien ou encore son rĂŽle au sein de sa sociĂ©tĂ© pour faire bouger les lignes du digital. Des insights prĂ©cieux que vous pourrez comparer au fur et Ă  mesure que les portraits s’Ă©graineront dans les semaines Ă  venir.

microsoft

En une phrase, comment définiriez-vous la notion de transformation digitale ?
Vaste « notion » qui a gĂ©nĂ©rĂ© plus d’une phrase dans de trĂšs nombreux ouvrages, mais en en quelques mots je dirais que c’est une capacitĂ© et une condition ; une capacitĂ© d’intĂ©grer dans sa stratĂ©gie les infinies possibilitĂ©s du « Digital » au bĂ©nĂ©fice de la crĂ©ation de valeur pour les clients, les employĂ©es, les partenaires de l’entreprise et une condition de survie de l’entreprise elle-mĂȘme Ă  moyen ou long-terme.

Comment décririez-vous votre rÎle de CDO ?
Souvent pour dĂ©crire mon rĂŽle j’utilise l’image d’une mappemonde. Quand on regarde l’ensemble des territoires sur une mappemonde on voit un univers oĂč les limites, les frontiĂšres Ă©voluent extrĂȘmement lentement. Si on transpose cette mappemonde dans univers digital oĂč les continents, les pays sont constituĂ©s d’utilisateurs de services numĂ©riques (i.e. Facebook, LinkedIn, Office365, 
) on arrive dans un univers oĂč les limites, les frontiĂšres sont en Ă©volutions et variations permanentes. Un univers ou aucune boussole de rĂ©fĂ©rence n’a vĂ©ritablement Ă©tĂ© inventĂ©e. En rĂ©sumĂ©, dans cet univers oĂč aucune boussole de rĂ©fĂ©rence n’a Ă©tĂ© crĂ©Ă©e, le rĂŽle du CDO, mon rĂŽle de CDO, est de contribuer :

1) à identifier les destinations futures et 2) à organiser la « logistique » de ce « voyage »

3) Ă  atteindre les prioritĂ©s marketing et business en Ă©vitant de tomber dans l’activation/la crĂ©ation de tactiques permanentes ce qui peut trĂšs facilement arriver « au milieu » de l’ocĂ©an digital.

Quelles difficultés rencontrez-vous au quotidien ?
Le mĂ©tier de CDO porte en lui deux Ă©lĂ©ments intrinsĂšquement abstraits. C’est Ă  la fois un point d’équilibre et Ă  la fois un paradoxe.

Un point d’équilibre entre l’infiniment grand et l’infiniment petit. Tel un « tai-chi master » le CDO fait un grand Ă©cart au quotidien entre des donnĂ©es, des points de contacts clients, des services, des fonctionnalitĂ©s, des technologies, des outils (cf. « Marketing Technology Landscape Supergraphic (2017): Martech 5000 »  de Chiefmartec.com) , des attentes,
 en super-croissances permanentes et des clients qui ont une bande-passante temps de plus en plus en Ă©troite (NB : certaines Ă©tudes indiquent que l’attention de l’humain est devenue infĂ©rieure Ă  celle du poisson rouge !) et des budgets bien souvent sous contraintes.

Qu’est-ce que j’entends en parlant de paradoxe ? CDO, c’est :

  • un mĂ©tier qui est Ă  la fois de plus en plus nĂ©cessaire et qui est Ă  la fois supposĂ© comme souvent soulignĂ© disparaitre prochainement (Ă  chacun son point de vue Ă  ce niveau).
  • un mĂ©tier qui est Ă  la fois dans le physique est dans le digital ; un mĂ©tier qui est par essence « phygital ».
  • un mĂ©tier oĂč il est absolument nĂ©cessaire d’avoir une hauteur de vue Ă  360° dans l’entreprise tout en Ă©tant capable de faire du « deep zoom » sur des micro-points, des micro-actions qui sont pourtant essentielles.
  • un mĂ©tier qui nĂ©cessite des expertises sans devenir un expert sur toutes les technos, sur les tous les outils ou process dont il va s’assurer le bon fonctionnement, la bonne coordination au quotidien.
  • un mĂ©tier qui opĂšre sur un univers omniprĂ©sent dans le quotidien de toutes et tous, le digital, mais pour lequel on n’a jamais eu autant besoin de formations internes et externes.

Pensez-vous qu’il faille ĂȘtre technophile pour exercer le mĂ©tier de CDO ?
Il n’est pas nĂ©cessaire d’ĂȘtre un technologue ou un « distinguish engineer » pour ĂȘtre un bon CDO ; en revanche ĂȘtre « technophile » est une condition absolument nĂ©cessaire tant le spectre des mĂ©tiers experts et technos avec lesquels on opĂšre au quotidien est large. Sans cela il me semble difficile pour un CDO de gĂ©nĂ©rer un Ă©lĂ©ment essentiel pour la croissance des entreprises : de « l’impact ».

Et au-delĂ  d’ĂȘtre « technophile », ĂȘtre « curieux » et « ouvert » sont selon-moi des qualitĂ©s essentielles pour avoir un « digital mindset » porteur.

Pensez-vous que CDO est un mĂ©tier d’avenir ?
Contrairement Ă  ce que l’on peut gĂ©nĂ©ralement lire, j’en suis convaincu. A un point prĂšs, c’est que l’intitulĂ© du titre Ă©voluera probablement. A l’ùre oĂč tout est numĂ©rique et oĂč le numĂ©rique est dans tout, c’est vraisemblablement le terme « Digital » qui disparaitra. On Ă©volue, on Ă©voluera vers des titres du type « Omnicanal Lead Director » « Chief Transformation Officer », « Chief Revenue/Demand Gen Officer », ou plus traditionnellement « CMO » voire « CEO » ;)

Et quoi qu’il arrive, comme on dit « ce n’est pas le titre qui fait l’homme, c’est l’homme qui fait le titre ».

Quelle est pour vous la prochaine innovation qui risque de chambouler votre secteur d’activitĂ© ?
Sans aucun doute, une « innovation » qui chamboule mon secteur d’activitĂ©, voire tous les secteurs d’activitĂ© Ă  l’échelle planĂ©taire, est l’intelligence artificielle. Pour notre CEO, Satya Nadella, l’intelligence artificielle « is the ‘ultimate breakthrough » – Progressivement, en lien avec le cloud, le « computing » gĂ©nĂ©ralisĂ©, l’intelligence artificielle sera partout, disponible depuis tout objet ou service connectĂ©. De la capacitĂ© Ă  interprĂ©ter des donnĂ©es structurĂ©es/non structurĂ©es en trĂšs grand nombre, Ă  la capacitĂ© d’interprĂ©ter des images (vision), des textes, des langues ou Ă  Ă©tablir des modĂšles de dĂ©tection de la fraude ou de marketing prĂ©dictif, nous ne sommes qu’au dĂ©but de multiples transformations et innovations associĂ©es Ă  l’intelligence artificielle.

Plus que jamais il est trĂšs difficile de prĂ©dire quelle sera telle ou telle technologie innovante Ă  trĂšs fort potentiel transformationnelle mais pour ma part et comme de nombreux autres j’estime que dans les 20 ans Ă  venir la combinatoire [Intelligence Artificielle/BlockChain/Quantum Computing] sera un « game changer ultime. »

Quels sont les enjeux de digitalisation de votre entreprise à l’heure actuelle ?
Aujourd’hui Microsoft est une « Cloud Company » qui se transforme tout en contribuant Ă  la transformation de ses clients et partenaires.

D’un point de vue enjeux marchĂ©, il y a trois domaines oĂč Microsoft se positionne de façon claire et marquĂ©e tant d’un point de vue crĂ©ations de nouveaux services que de nouveaux usages innovants :

  • Comme dĂ©jĂ  Ă©voquĂ© il y’a l’intelligence artificielle qui fait partie aujourd’hui de tous nos produits et que l’on rend accessible sur n’importe quels types de « pĂ©riphĂ©riques » ou systĂšmes. Je pense notamment Ă  Cortana qui est Ă  la fois un agent numĂ©rique et une plateforme. Illustrations concrĂštes : les nouveaux speakers de Harman Kardon, Invoke ou « Cortana Intelligence Suite »
  • La confiance numĂ©rique ou comment faire en sorte que chacun puisse innover en toute sĂ©curitĂ© et en respectant sans compromis l’intĂ©gritĂ© des donnĂ©es collectĂ©es et traitĂ©es. Un enjeu de premier plan dans les « heures » prĂ©cĂ©dents l’arrivĂ©e de GDPR.
  • Le « future of work » avec la crĂ©ation de nouveaux produits tels que le « Surface Hub » ou Microsoft « Office Delve » qui fait partie d’Office 365.

Les enjeux de digitalisation font partie par dĂ©faut du nouvel ADN de Microsoft. Ils sont multiples et larges mais je dirai son enjeu principal est de continuellement s’appliquer Ă  elle-mĂȘme ce que Microsoft propose Ă  ses clients et partenaires en matiĂšre de transformation :

  • DĂ©velopper le meilleur niveau d’expĂ©rience et d’engagement clients,
  • Contribuer Ă  l’efficacitĂ© et Ă  l’agilitĂ© des employĂ©s,
  • Optimiser, « fluidifier » les processus de l’entreprise pour dĂ©cloisonner voire effacer la notion de « silo »,
  • Transformer les processus de crĂ©ations de produits, en intĂ©grant notamment les retours des utilisateurs.

Citez-moi une marque/entreprise qui, pour vous, a clairement réussi à adresser les enjeux du digital ?
A mon sens, Ă  ce niveau, intĂ©ressant de se pencher sur des entreprises « brick & mortar » plus que centenaires. Il est beaucoup plus difficile de remettre en cause des modĂšles Ă©tablis depuis de longues annĂ©es dans ce type d’entreprise que d’en crĂ©er des tous nouveaux « from scratch » pour des nouveaux entrants (i.e. start-up).

Contexte donnĂ©, pour moi, une entreprise qui a rĂ©ussi Ă  trĂšs bien adresser les enjeux du digital est Schneider Electric. Aujourd’hui Schneider n’est pas qu’un groupe industriel c’est Ă  la fois un groupe industriel et Ă  la fois une « Digital Company ». Elle incarne pleinement ce qui a Ă©tĂ© soulignĂ© par Marc Andreesen il y a quelques annĂ©es « today, every company is a software company ».

Schneider a notamment rĂ©ussi Ă  mettre en musique les possibilitĂ©s du digital/du cloud pour proposer des services Ă©volutifs d’équipement connectĂ©s et d’analyse de donnĂ©es. Et ce pour de nombreuses industries majeures telles que la santĂ©, l’énergie ou la construction.

Egalement, au cours des derniĂšres annĂ©es Schneider a procĂ©dĂ© Ă  de nombreuses acquisitions et a rĂ©ussi dans un esprit « software company » Ă  orchestrer au mieux les diffĂ©rentes expertises anciennes et nouvelles de l’entreprise au profit de la mise en place de nouveaux produits ou services.

C’est pour ces raisons que Schneider est selon-moi un trĂšs bon exemple de transformation digitale rĂ©ussie.

Sans contrainte, vous avez la possibilité de commencer 3 projets de transformation dans votre entreprise : quels seraient-ils ?
On est dĂ©jĂ  d’une certaine maniĂšre une entreprise « GloCal », Globale et Locale.

  1. Sans contraintes je continuerai Ă  faire Ă©voluer voire Ă  transformer notre « MartTech » architecture que j’estime dĂ©jĂ  ĂȘtre extrĂȘmement robuste et innovante (voir cet article Frenchweb pour en avoir un aperçu). Comment ? En permettant Ă  chaque filiale d’y avoir un nombre dĂ©terminĂ© d’acteurs locaux de leur Ă©cosystĂšme (partenaires/start-up) et de regarder rĂ©guliĂšrement, filiale par filiale les nouveaux services disruptifs Ă  plus fort niveau d’impact client et business. C’est par exemple quelque chose que nous avons fait en France avec l’activation au niveau mondial du service français « d’employee brand advocacy » www.sociabble.com
  2. Un parcours « phygital » certifiant de « Transformation Digitale » pour les PME et TPE
  3. “Content is king, media is queen and context takes it all”, je crĂ©erai, au-delĂ  de la France une « Modern Content Management Team » transverse pour offrir de façon individualisĂ©e le meilleur niveau d’expĂ©rience Ă©ditoriale de marque quelque-soit le pĂ©riphĂ©rique utilisĂ© par chaque client Ă  un instant t.

Quel est l’impact de la transformation sur la culture et l’organisation de votre entreprise ?
DĂ©finitivement un des impacts de la transformation sur Microsoft est de l’ordre du collaboratif. Aujourd’hui, l’impact d’un collaborateur de Microsoft est essentiellement associĂ© Ă  la maniĂšre dont il a contribuĂ© aux succĂšs des autres et Ă  la maniĂšre dont il a intĂ©grĂ© les idĂ©es des autres au profit du succĂšs de ses projets. Et au-delĂ  du succĂšs, on cĂ©lĂšbre, on considĂšre aussi plus que jamais l’échec comme une source d’apprentissage extrĂȘmement prĂ©cieuse.

Egalement, on peut noter que la transformation Ă  dĂ©finitivement fait Ă©voluer Microsoft dans sa relation avec l’écosystĂšme du numĂ©rique. Des concurrents d’hier sont des partenaires d’aujourd’hui ou plus que jamais des « coopĂ©titeurs » (Apple, Google, RedHat/Linux, SAP, Oracle, Salesforce etc.)

Demain, qu’est-ce qui vous fera dire que votre entreprise a rĂ©ussi sa transformation ?
Je ferais une rĂ©ponse trĂšs corporate mais dans laquelle je crois fondamentalement. Je dirais que Microsoft aura rĂ©ussi sa* transformation quand unanimement et spontanĂ©ment l’ambition dressĂ©e par Satya Nadella « to empower every person and every organization on the planet to achieve more » sera incontestablement reconnue Ă  l’échelle planĂ©taire.

Quel livre vous a récemment le plus influencé ?
« The Internet is My Religion » http://www.internetismyreligion.com/ de Jim Gilliam crĂ©ateur/fondateur de nationbuilder.com. Pourquoi en une phrase ? Car c’est un ouvrage qui incarne trĂšs bien l’aphorisme « ce qui ne tue pas rend plus fort. »

Twitter : https://twitter.com/sebimbert
LinkedIn : http://www.linkedin.com/in/sebim
Site Internet : https://www.microsoft.com/fr-fr/

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft from OCTO Technology

Retrouvez les derniers #PortraitDeCDO

#PortraitDeCDO – François-RĂ©gis Martin – BNP Paribas Leasing Solutions from OCTO Technology

#PortraitDeCDO – Marion Vincent-Ceyrat – Comexposium from OCTO Technology

#PortraitDeCDO – MACSF – Edouard Perrin from OCTO Technology

PortraitDeCDO – Toupargel – JĂ©rĂŽme Dalidet from OCTO Technology

EnregistrerEnregistrerEnregistrerEnregistrer

Catégories: Blog Société

[PODOJO] Jeu collaboratif – Innovation game : Prune the product tree

Agile Nantes - dim, 06/18/2017 - 21:46
Le jeu est un conteneur idĂ©al. Son utilisation lors d’ateliers collaboratifs est recommandĂ© car il possĂšde 4 caractĂ©ristiques souhaitables : –          objectif clair : on sait pourquoi on est lĂ  –          rĂšgles claires : on sait comment cela va se passer –          feedback encouragé : chacun est libre d’exprimer son ressenti et son point de vue –          principe d’invitation : […]
Catégories: Association

Conférence Best of Web 2017

Conférence Best of Web

La troisiĂšme Ă©dition de Best Of Web a eu lieu les 8 et 9 Juin derniers, ce fut l’occasion de retrouver les meilleurs talks des 19 meetups web que regroupe cette confĂ©rence annuelle. Quelques Xebians ont assistĂ© Ă  cette Ă©dition dont voici un petit compte-rendu :

La Keynote

Thomas Guenoux (@thomasgx), co-fondateur de @commitStrip a introduit cette journĂ©e en abordant l’avenir du mĂ©tier de dĂ©veloppeur. Il note la fin du dĂ©veloppeur full stack, avec la spĂ©cialisation des compĂ©tences dans diffĂ©rents domaines que sont l’IoT, l’ops, la sĂ©curitĂ©, la blockchain, le machine learning, les bots, l’IA,… Il situe l’Ă©poque actuelle dans la quatriĂšme rĂ©volution industrielle, celle qui amĂšnera au dĂ©veloppement d’une intelligence artificielle qui dĂ©passera celle des Hommes, et qui pourrait Ă  terme mettre fin Ă  des mĂ©tiers comme celui d’avocat ou de mĂ©decin.

On estime Ă  2040 la date Ă  laquelle les machines atteindront le niveau d’intelligence des hommes. Thomas pose alors la question de la responsabilitĂ© du milieu de l’informatique et de l’Ă©thique nĂ©cessaire pour les choix qui devront ĂȘtre faits. Il estime qu’une majoritĂ© des dĂ©veloppeurs actuels se spĂ©cialiseront dans le domaine de l’intelligence artificielle dans un avenir proche et appelle Ă  se positionner en dĂ©veloppeur universel, un dĂ©veloppeur qui saura penser Ă  sa place dans le monde, Ă  ses actions, aux valeurs qu’elles peuvent crĂ©er mais aussi aux Ă©ventuelles consĂ©quences nĂ©fastes qui pourraient en dĂ©couler.

La technique des Fab Four

RĂ©mi Parmentier (@HTeuMeuLeu) est intĂ©grateur HTML et CSS. Il a eu Ă  se confronter Ă  l’Ă©dition d’un email en Responsive Design, qui devait ĂȘtre rendu dans la plupart des clients mails. Sa premiĂšre idĂ©e fut d’utiliser les Media queries, mais voilĂ  ce qu’il a remarquĂ© :

support de media sur mobile

Il s’est alors demandĂ© si l’usage de flexbox pouvait ĂȘtre une solution. Cependant, le rendu dans Gmail Ă©tait dĂ©sastreux.

C’est en remarquant la prioritĂ© de ‘min-width‘ appliquĂ©e Ă  un mĂȘme Ă©lĂ©ment dans le cas suivant :

  • min-width: 480px
  • width: 320px
  • max-width: 160px

dont la taille rendu Ă©tait de 480px qu’il a crĂ©Ă© la technique des « Fab Four« .

Cette technique s’Ă©crit de la maniĂšre suivante :

technique

Elle est utilisable sur la plupart des clients web.

Vous pouvez retrouver ses diapositives sur https://speakerdeck.com/hteumeuleu

SOLID principles for Front-End Developers

GrĂ©gory Ruiz (@gregoryruiz) nous parle du design orientĂ© objet appelĂ© SOLID. Il travaille sur un projet front-end impliquant beaucoup de monde et sur lequel certains dĂ©parts ont amenĂ© Ă  perdre la maĂźtrise d’une partie du code. GrĂ©gory a dĂ» trouver des solutions pour amĂ©liorer la cohĂ©rence du code au sein de l’Ă©quipe, notamment :

  • re-travailler les tests
  • crĂ©er une documentation vivante
  • revoir le nommage du code
  • rĂ©-organiser le code
  • appliquer des designs patterns
  • mettre en pratique certains principes : KISS, DRY, YAGNI,… et SOLID

GrĂ©gory nous livre son retour d’expĂ©rience de la mise en pratique de SOLID. GrĂące Ă  l’usage de Typescript, il a rĂ©ussi Ă  respecter ses principes en s’inspirant des design patterns de Java et en utilisant en particulier les interfaces et les classes abstraites. Vous pourrez trouver davantage de prĂ©cision sur les principes SOLID sur cet article de blog : http://blog.xebia.fr/2011/07/18/les-principes-solid/.

React Storybook : Concevoir, DĂ©velopper, Documenter et DĂ©bugger ses composants d’interface React

Marie-Laure Thuret (@mlthuret) nous prĂ©sente un outil qui lui est devenu indispensable aujourd’hui en tant que dĂ©veloppeuse ReactJs chez Algolia, il s’agit de React Storybook.

Cet outil :

  • offre un environnement de dĂ©veloppement des composants React totalement isolĂ©, en hot reload
  • du fait de l’isolement du composant, il favorise le dĂ©veloppement en API-first
  • permet Ă©galement de tester le composant et de manipuler les props pour voir les effets sur le rendu
  • peut ĂȘtre mis en ligne, et offrir une documentation vivante. C’est le choix qu’Ă  fait Algolia, Ă  titre d’exemple voici le lien vers leur storybook : https://community.algolia.com/react-instantsearch/storybook/

Marie-Laure nous a expliquĂ© qu’une version est Ă©galement en dĂ©veloppement pour VueJs.

Service-Public.fr : Accessibilité et Agilité

Adrien Saunier (@adriensaunier) est dĂ©veloppeur sur le projet www.service-public.fr. Ce site recense 10 millions de visiteurs par mois et plus de 178 000 pages, pour autant il a reçu le label e-accessible. Obtenir ce label, c’est respecter les directives en vigueur : internationales avec WCAG, nationales avec RGAA qui contient des tests avec plus de 130 critĂšres. Il s’agit en particulier de permettre de naviguer en utilisant uniquement le clavier, d’avoir une diffĂ©renciation claire des couleurs, de permettre un accĂšs rapide Ă  toutes les fonctionnalitĂ©s ou bien d’ĂȘtre adaptĂ© Ă  l’usage d’un outil de synthĂšse vocale.

Adrien a expliquĂ© comment le projet s’est adaptĂ© pour permettre la mise en place des contraintes induites par une bonne accessibilitĂ© et pour Ă©voluer en les conservant. Il s’agit principalement d’impliquer tout le monde : PO, UX, dĂ©veloppeurs, testeurs pour que chacun se sente concernĂ© et surtout pour anticiper les implications des contraintes Ă  respecter et Ă©viter les bugs qui sont sources de douleur. Des experts sur le sujet sont Ă©galement intervenus, et ont intĂ©grĂ© l’Ă©quipe.

Adrien a prĂ©sentĂ© quelques points qu’il est bon de suivre :

  • une syntaxe HTML valide
  • l’utilisation du site au clavier
  • la hiĂ©rarchie des titres
  • avoir des noms de pages signifiants
  • ne pas avoir une information portĂ©e uniquement par les couleurs
  • avoir des images avec une alternative textuelle qui les dĂ©crivent
  • permettre de zoomer, dĂ©-zoomer sans perte d’information
Elm + Web Components = <3

KĂ©vin Lebrun (https://github.com/kevinlebrun), tech-lead chez Meetic, s’est intĂ©ressĂ© Ă  Elm. Ce langage vise Ă  faciliter le dĂ©veloppement fonctionnel dans le Web, avec pour avantages :

  • intĂ©gration avec des projets web JS : se compile vers javascript
  • pas d’exception en runtime : lors de la compilation, il dĂ©tecte les infĂ©rences de type
  • de trĂšs bonnes performances :
    performances elm
  • dĂ©tecte les changements de version des modules utilisĂ©s pour Ă©viter les « surprises » de patch
  • plus qu’un langage, il dĂ©finit une architecture de dĂ©veloppement

KĂ©vin nous a montrĂ© le dĂ©veloppement d’un petit compteur ainsi que les interactions Elm, Polymer, et Vue.js.

Faire du bruit avec Pizzicato.JS

Impressionnante prĂ©sentation d’Alejandro Mantecon Guillen (@alemangui), il a jouĂ© de la guitare pour montrer les capacitĂ©s de sa bibliothĂšque Pizzicato.JS. En utilisant l’API de Web Audio disponible sur les navigateurs, la bibliothĂšque :

  • permet de rĂ©cupĂ©rer des sons (via un fichier, le micro ou l’entrĂ©e audio)
  • de transformer le son Ă  la maniĂšre d’une pĂ©dale d’effets
  • de jouer plusieurs pistes en parallĂšle !

Un bon moyen de s’amuser, aussi bien en musique qu’en informatique, d’autant plus que l’usage est facile et le rendu de qualitĂ©.

Faire cohabiter React et d3.js

Christophe Rosset (@topheman) nous a prĂ©sentĂ© comment combiner l’usage de d3.js, qui permet de gĂ©nĂ©rer des graphes de donnĂ©es dynamiques et de React. Les approches des deux bibliothĂšques sont trĂšs diffĂ©rentes car d3 rĂ©cupĂšre les donnĂ©es fournies en entrĂ©e et crĂ©e des mutations sur le DOM alors que React ne manipule jamais directement le DOM. On trouve donc deux approches pour le rendering :

  • qu’il soit fait par d3 en l’adaptant pour qu’il n’interfĂšre pas avec le React lifecyle
  • qu’il soit fait par React en re-implĂ©mentant le travail fait par d3 sur le DOM (en wrappant svg dans jsx)

Vous pouvez trouver toutes les expérimentations de Christophe sur son repo Github : https://github.com/topheman/d3-react-experiments.

Reverse engineering d’une API SOAP chiffrĂ©e

Kévin Raynel (@kraynl) a été confronté à un logiciel de systÚme de paie bien peu pratique, fonctionnant uniquement sous Windows et en a eu assez de passer par une machine virtuelle pour récupérer ses bulletins.

C’est en sniffant les requĂȘtes du logiciel vers l’API qu’il a remarquĂ© qu’elles Ă©taient en HTTP, avec un systĂšme d’authentification custom. Alors, il s’est dit qu’il allait pouvoir faire de la ‘rĂ©tro-ingĂ©nierie’ pour essayer d’utiliser l’API sans passer par le logiciel. Son talk nous explique comment, en sniffant les requĂȘtes avec Charles, en jouant le rĂŽle du « man in the middle » pour outrepasser l’encodage RSA et en dĂ©compilant le code .Net avec reflector, il a pu rĂ©cupĂ©rer ses bulletins de paie en un clic !

Créer une expérience WebVR sur toutes les plateformes

David Rousset (@davrous) dĂ©veloppeur et Ă©vangĂ©liste Microsoft dans la rĂ©alitĂ© virtuelle, nous prĂ©sente le framework dont il est le co-auteur avec David Catuhe (@deltakosh) : babylon.js. Ce framework est un moteur 3D basĂ© sur WebGL et Javascript et fournit une API qui permet de crĂ©er des objects, des scĂšnes et d’interagir avec l’environnement virtuel. Le point fort de l’usage de cet outil pour crĂ©er des environnements virtuels est qu’il se dĂ©ploie en ligne. Il est donc disponible sur toutes les plateformes et permet de toucher une base d’utilisateur trĂšs vaste.

La bibliothĂšque met Ă©galement Ă  disposition un outil pratique pour s’amuser avec les exemples de babylon, il s’agit d’un IDE dans le navigateur qui permet d’afficher le rendu 3D : https://www.babylonjs-playground.com/.

Vous trouverez sur le site www.babylonjs.com plein d’exemples et de documentation sur l’usage du framework.

Tour d’horizon des 3 grandes mĂ©thodologies CSS

Jonathan Verrecchia (@verekia) nous présente les trois grandes méthodes actuelles pour développer son style en CSS :

  1. CSS en CSS
    Le plus simplement du monde, utiliser CSS pour faire du CSS, mais pas sans les outils actuels, David nous donne quelques conseils :

    • prĂ©-processeur : SaSS, qui est le plus rĂ©pandu, pour faciliter l’Ă©criture, utiliser des variables,…
    • conventions de nommage : BEM, SUITCSS ou bien SMACSS
    • post-precesseur : PostCSS, qui permet de rajouter des plugins, vous pouvez les trouver sur ce site : http://postcss.parts/
    • « nettoyeur » : purifyCSS, qui rĂ©cupĂšre uniquement le contenu CSS qui est utilisĂ© dans l’application en analysant le code
  2. CSS en HTML
    Le CSS est écrit en inline, mais avec des classes utilitaires et des variables. On trouve trois principales bibliothÚques : Tachyon, Basscss et Atomic CSS (la plus répandue).
    Il s’agit d’associer une classe Ă  un Ă©lĂ©ment pour un rĂšgle (de type margin-left par exemple). Les avantages sont le poids du CSS qui est constant et le dĂ©veloppement rapide.
    Voici un exemple Atomic, représentant un div de type inline-box, de largeur 33%, padding de 20px et ayant une background-color valant #0280ae.5 : 

    <div class="IbBox W(1/3) P(20px) Bgc(#0280ae.5)"/>
  3. CSS en JS
    Ce sont des feuilles de style que l’on peut importer dans des composants, tout comme le javascript. On trouve plusieurs outils, notamment Webpack qui permet de rĂ©soudre les imports CSS avec css-loader ou styletron. Pour React, on trouve Ă©galement d’autres outils comme styled-components ou glamorous.

En résumé, Jonathan donne ces conseils pour le choix de la méthode :

  • si l’on ne dĂ©veloppe pas en javascript : CSS in CSS
  • pour un projet rapide : CSS in HTML
  • pour la majoritĂ© des cas : CSS in JS
Construction d’une « Raspberry Pi home alarm » en moins de 3h

RaphaĂ«l Dubigny (@rdubigny) vivait dans un appartement dont la capacitĂ© de la porte d’entrĂ©e Ă  empĂȘcher l’intrusion laissait Ă  dĂ©sirer. En rassemblant chez lui ce qui pouvait lui servir, il a trouvĂ© un Raspberry Pi, une camĂ©ra infrarouge, et quelques cĂąbles. Il nous explique dans ce talk comment il a mis en place une alarme connectĂ©e dans son appartement.

Au-delĂ  de son projet, qui lui a permis tout de mĂȘme de mettre en place un dĂ©tecteur de mouvements sur la porte, de prendre des photos du suspect, de stocker ces photos sur GDrive, d’activer une alarme, RaphaĂ«l nous montre l’intĂ©rĂȘt qu’il a trouvĂ© Ă  dĂ©velopper un projet personnel. Non seulement il en retire de la fiertĂ©, mais aussi tout ce qu’il a appris comme le python, la programmation rĂ©active ou bien encore la soudure. Pour motiver son public a faire la mĂȘme dĂ©marche que lui, il explique dans un de ses derniers slides comment se lancer dans un projet personnel :

  • arrĂȘter avec les excuses du type : « j’ai pas le temps »,…
  • rĂ©soudre des problĂšmes utiles
  • itĂ©rer sur des « Petits Trucs Moches Qui Marchent » (PTMQM)
  • aller en production au plus vite (1h)

D’ailleurs, en y regardant de plus prĂšs, on peut Ă©galement penser Ă  ces principes pour ses projets professionnels.

Comment tirer le maximum de vos contributeurs

Vincent Voyer (@vvoyer), d’Algolia, nous explique comment il attire des contributeurs sur ses projets, aussi bien privĂ©s que publics et comment il met au maximum leurs compĂ©tences Ă  profit. Il explique notamment la mĂ©thode mis en place chez Algolia lorsqu’un utilisateur crĂ©e une « issue ». Une sĂ©rie de questions lui ai posĂ©e dans le template de l’issue, afin de prĂ©ciser au maximum le problĂšme :

  • Do you want to request a feature or report a bug?
  • Bug: What is the current behavior?
  • Bug: What is the expected behavior?
  • Bug: What browsers are impacted? Which versions?
  • Feature: What is your use case for such a feature?
  • Feature: What is your proposed API entry? The new option to add? What is the behavior?
  • What is the version you are using? Always use the latest one before opening a bug issue.

D’autre part, il prĂ©cise de garder en tĂȘte les principes suivants lors des rĂ©ponses aux contributeurs :

  • l’utilisateur contribue : apprĂ©cier sa bonne volontĂ©
  • si l’utilisateur est mĂ©content, Ă©viter Ă  tout prix la confrontation
  • ne pas faire d’hypothĂšse ou de supposition a priori sur l’utilisateur ou bien le bug ou la feature
  • essayer d’ĂȘtre le plus clair possible, car la communication Ă©crite est complexe
  • supposer a priori qu’une issue est un problĂšme Ă  rĂ©soudre

Appliquer ces principes permet une forte implication des contributeurs et un gain d’efficacitĂ©.

Conclusion

Best Of Web nous a offert une Ă©dition riche tant en qualitĂ© des talks qu’en variĂ©tĂ© des sujets. Une bonne annĂ©e pour une confĂ©rence qui a su trouver sa place dans les rendez-vous annuels des technologies du Web Ă  Paris.

conférence best of web 2017

Catégories: Blog Société

BizDevOps, véritable marqueur du Time to Market

Blog d’Ippon Technologies - ven, 06/16/2017 - 08:16

 

Un KPI majeur de la Transformation Digitale, le Time To Market

L’Experience Economy amĂšne de nouveaux modes de consommation dans lesquels la logique consumĂ©riste s’impose avec un rapport de force inversĂ© avec les clients. Ces derniers deviennent acteurs des produits qu’ils consomment. Ils sont proactifs, responsables de leurs choix et dĂ©cident avec qui, quand et comment ils vont consommer un produit qu’il soit bancaire, d’assurance, de grande consommation ou de luxe. SimplicitĂ©, rĂ©activitĂ©, disponibilitĂ© et immĂ©diatetĂ© sont devenus le standard. Aussi, dans cette course effrĂ©nĂ©e, le Time To market, Ă  savoir l’écart entre la crĂ©ation ou l’émergence d’un usage et le moment oĂč il est disponible sur le marchĂ©, devient le KPI principal. Ce nouvel usage est soit une rĂ©ponse Ă  un besoin du marchĂ©, soit la crĂ©ation d’un avantage compĂ©titif face aux concurrents. La rapiditĂ© d’une entreprise Ă  apporter des amĂ©liorations rapides, incrĂ©mentales et continues devient un facteur dĂ©terminant pour conserver l’avantage concurrentiel.

 

MaĂźtriser la chaĂźne de valeur complĂšte

Le seul moyen d’agir efficacement sur ce KPI est de maĂźtriser toute la chaĂźne de valeur de construction. Ainsi, idĂ©ation pour faire Ă©merger les nouveaux usages, comprĂ©hension des besoins utilisateurs, segmentation clients, POC (Proof Of Concept), validation des usages et stack technique au travers d’un  Minimum Viable Product (MVP), pĂ©rennisation du Go To Market via un Minimum Marketable Feature (MMF), industrialisation du Soft disponible en production constituent le cercle vertueux d’adressage du Time To Market. Il convient de disposer des dispositifs permettant de rendre les actions concrĂštes et de matĂ©rialiser rapidement la vision produit.

 

Cette vitesse d’exĂ©cution doit, Ă  l’heure du Fail Fast, intĂ©grer la  limitation des risques par la rĂ©sorption du cĂŽne d’incertitude afin d’accroĂźtre la maturitĂ© du Business Model. Pour cela, dĂ©cideurs MĂ©tiers, Études et surtout Production doivent avoir une vision commune et partagĂ©e du produit tant dans sa finalitĂ© et sa mise en oeuvre que dans la façon dont il sera dĂ©ployĂ© puis consommĂ©. L’articulation la plus efficiente consiste Ă  dĂ©ployer agilitĂ© et devops au travers de l’alignement MĂ©tier – Etude – Production. C’est la genĂšse de BizDevops : “Business”, “Development”, “Operations”.  BizDevOps, encore appelĂ© Devops 2.0 encourage cet alignement pour la production logicielle de façon Ă  ce que les organisations dĂ©veloppent plus vite, soient plus sensibles aux demandes des utilisateurs et maximisent leurs revenus. L’association de clients, lorsque c’est possible, et donc l’approche centrĂ©e client permet d’opĂ©rer et de complĂ©ter cet alignement. On parle alors de UserBizDevOps.

 

Sur quels axes adresser BizDevops ?

BizDevOps doit ĂȘtre adressĂ© au niveau culturel, processus et technologique.

  1. Culturel car nous avons tous dĂ©jĂ  entendu des responsables mĂ©tiers dire que leur IT n’était pas en capacitĂ© de leur dĂ©livrer des projets de qualitĂ© dans les dĂ©lais souhaitĂ©s et inversement l’IT se targuer d’ĂȘtre garant de la dĂ©marche industrielle de l’entreprise et ne pas pouvoir prendre en charge des dĂ©veloppements rapides et pas complĂštement dĂ©finis, demandĂ©s par le marketing et les mĂ©tiers.
    Il faut donc abattre les murs, faire sauter les cloisons qui coexistent dans l’entreprise. Plus que jamais, cette transition culturelle s’effectue avec les femmes et les hommes de l’entreprise. Des notions importantes telles que la confiance, la dĂ©lĂ©gation, la responsabilitĂ© vont ressurgir. On passe ainsi du mode Leader-Follower au mode Leader-Leader. La rĂ©flexion et le plan d’action de cette Ă©volution doivent intĂ©grer une dĂ©marche itĂ©rative et transversale pour que chacun s’exprime et que la cible soit collective.
  2. Processus car le point d’induction Ă  partir duquel il faut agir est l’usage. Cet usage prĂ©figure l’offre et le marketing qui en dĂ©coulent. Cela oblige Ă  maĂźtriser le cycle de vie des rĂšgles mĂ©tiers (sans oublier les contingences rĂ©glementaires et rĂ©galiennes) dans une agilitĂ© mĂ©tier qui doit ĂȘtre acquise et partagĂ©e avec l’IT afin de mettre en oeuvre les dĂ©veloppements agiles et les environnements Ă  la demande. Ce dernier point permet de boucler la chaĂźne devops.
  3. Technologique car il faut mettre  en oeuvre et gĂ©rer les nouveaux usages en s’affranchissant des contraintes liĂ©s Ă  l’infrastructure. Ainsi, il faut utiliser la souplesse apportĂ©e par le Cloud pour non seulement accĂ©lĂ©rer les processus de dĂ©veloppement, mais aussi simplifier et assouplir l’exploitation.
    Aussi, les architectes doivent proposer des environnements qui soutiennent productivitĂ©, Ă©volutivitĂ© et sĂ©curitĂ©, avec maĂźtrise des coĂ»ts et des risques. Les plateformes applicatives et les suites d’automatisation de nouvelle gĂ©nĂ©ration doivent disposer de mĂ©canismes d’installation, de configuration et d’intĂ©gration automatisĂ©es.
    Les dĂ©veloppeurs peuvent ainsi se concentrer sur la valeur mĂ©tier et la pertinence de mise en oeuvre applicative. Par exemple, grĂące aux conteneurs lĂ©gers, les dĂ©veloppeurs peuvent dĂ©composer leurs applications en microservices qu’ils peuvent exĂ©cuter sur des infrastructures bien plus modestes que prĂ©cĂ©demment. L’approche Platform As A Service permet dans le mĂȘme temps de simplifier dĂ©ploiement, maintenance et Ă©volution indĂ©pendante des microservices. Technologiquement, le triple adressage conteneurs, microservices, Platform As A Services constituent l’axe nĂ©vralgique d’évolution.

La combinatoire des trois axes “Culturel”, “Processus” et “Technologique” constitue la clĂ© de voĂ»te pour que les entreprises puissent crĂ©er et mettre Ă  disposition de leurs clients, dans des Time To Market agressifs, des usages clivants et structurants par rapport Ă  leur segment de marchĂ©.

 

Comment opĂ©rer l’alignement BizDevops?

Plusieurs Ă©tapes peuvent ĂȘtre envisagĂ©es pour opĂ©rer l’alignement BizDevOps. Le point structurant est que la transition doit se faire pas Ă  pas et de façon itĂ©rative. Ensuite, il est important d’impliquer le top management et de ne laisser aucun mĂ©tier sur la touche. Il y a, enfin, des moments privilĂ©giĂ©s qui peuvent servir de laboratoire Ă  la mise en oeuvre de l’alignement BizDevOps.   

  1. Le cadrage stratĂ©gique : Dans le cas de la construction d’une proposition de valeur pour l’entreprise par exemple, l’alignement doit ĂȘtre opĂ©rĂ© dĂšs les phases de cadrage stratĂ©gique. Cette proposition de valeur qui doit permettre soit de faire Ă©voluer, soit de rĂ©inventer le business model de l’entreprise est le catalyseur parfait. Tous les mĂ©tiers (Marketing, MĂ©tier, Etude, Exploitation) doivent ĂȘtre alignĂ©s sur trois piliers :
    • La cible, Ă  savoir, la proposition de valeur proposĂ©e aux clients.
    • Le moyen, la façon dont l’entreprise Ă©labore et dĂ©livre la proposition de valeur.
    • Le montage Ă©conomique, l’identification d’un modĂšle de revenus viable.

La rĂ©flexion commune sur ces 3 piliers va faire Ă  ce que la contribution de chacun apporte Ă  la stratĂ©gie globale,  à ce que chacun s’identifie Ă  cette stratĂ©gie et reconnaisse la valeur ajoutĂ©e des autres mĂ©tiers, et surtout que chacun perçoive la puissance de l’intelligence collective.

Les objectifs Ă©tant communs et partagĂ©s, ce premier niveau d’alignement BizDevOps tant dans la cible que dans les moyens mis en oeuvre, constitue le point de dĂ©part d’une chaĂźne de transformation rĂ©ussie.

  1. L’idĂ©ation : un autre use case intĂ©ressant pour favoriser l’alignement BizDevops est la participation Ă  des ateliers d’idĂ©ation. En effet, pour favoriser l’émergence d’idĂ©e et ainsi faciliter l’innovation, des ateliers de brainstorming avec facilitateurs et spĂ©cialistes de la transformation digitale sont d’excellents catalyseurs. Il convient que les grands mĂ©tiers de l’entreprise soient reprĂ©sentĂ©s pour crĂ©er un terrain propice Ă  l’innovation. Des approches telles que le brainstorming par le jeu (gamestorming) avec Proof Of Concept (POC) Ă  la volĂ©e sont particuliĂšrement adaptĂ©es. Ce POC doit ĂȘtre disponible dans le Cloud sous quelques jours et manipulable par tous. Ce modus operandi favorise l’échange, permet de comprendre les contraintes des uns et autres et surtout une fois encore, de mesurer la puissance de l’intelligence collective.
  2. La construction d’un MVP constitue un test “grandeur nature” de l’alignement BizDevops. Les Ă©quipes MĂ©tiers travaillent directement avec les dĂ©veloppeurs afin de faire converger la vision produit et pensent dĂ©ploiement et exĂ©cution (run) dĂšs le dĂ©part. C’est ensemble qu’ils vont rĂ©duire le cĂŽne d’incertitude, rĂ©duire les risques tant fonctionnels, qu’au niveau de la stack technique que pour le dĂ©ploiement. C’est aussi ensemble qu’ils vont pouvoir expĂ©rimenter rapidement et, soit identifier les Ă©checs (fail fast) pour apporter les modifications nĂ©cessaires, soit continuer sur les bonnes pratiques. Cette concrĂ©tisation effectuĂ©e avec les diffĂ©rents mĂ©tiers de l’entreprise, quelque soit leur domaine d’obĂ©dience (Business, DĂ©veloppement et Exploitation), est structurante. C’est elle qui est le point de dĂ©part de la dĂ©marche d’industrialisation et donc de la rĂ©alisation du logiciel.
  3. Durant la phase d’industrialisation, tous les prĂ©ceptes du BizDevOps acquis dans les phases prĂ©cĂ©dentes sont mis en oeuvre.
    • Ainsi, les dĂ©partements mĂ©tiers peuvent exprimer et revoir leur exigences de façon trĂšs efficace, rĂ©duisant le transfert de connaissances et permettant des cycles de retours  extrĂȘmement rapides, le Biz
    • Les Ă©quipe IT pilotent le processus de dĂ©veloppement de façon complĂštement corrĂ©lĂ©e aux besoins des mĂ©tiers et  peuvent se concentrer sur la qualitĂ© de la valeur Ă  produire, le Dev.
    • Les Ă©quipes d’exploitation offrent une automatisation complĂšte de la chaĂźne d’intĂ©gration et de la phase de dĂ©ploiement, ce qui permet encore d’accĂ©lĂ©rer le rythme des dĂ©veloppements, les Ops.

 

VĂ©ritable marqueur du Time to Market et de la satisfaction client

En dĂ©veloppant une culture de la collaboration entre les Ă©quipes, BizDevOps vise Ă  favoriser les intĂ©rĂȘts partagĂ©s dans une entreprise. BizDevOps met ainsi un objectif “Business” au centre des diffĂ©rents corps de mĂ©tiers qu’il responsabilise, de surcroĂźt, autour du processus d’alignement. Ainsi, il assure que les Ă©quipes IT, Exploitation et MĂ©tiers restent concentrĂ©es sur la performance de l’entreprise et l’expĂ©rience des utilisateurs. Les pratiques rĂ©ussies de DevOps associĂ©es Ă  une approche unifiĂ©e de l’expĂ©rience utilisateur permet Ă  ces entreprises une meilleure exĂ©cution des objectifs “Business”, d’accroĂźtre la satisfaction client, d’avoir des Time To Market trĂšs optimisĂ©s, de renforcer la compĂ©titivitĂ© et enfin d’amĂ©liorer les rĂ©sultats d’exploitation.

 

Patrick Jean-François Digital Consulting Director chez Ippon

 

L’article BizDevOps, vĂ©ritable marqueur du Time to Market est apparu en premier sur Le Blog d'Ippon Technologies.

Catégories: Blog Société

Meet our Software Development Manager Superhero

Le blog de Valiantys - jeu, 06/15/2017 - 14:00

Like a rare Pokemon, our Software Development Manager Christophe was hard to catch! But I was able to lure him in with jokes and cool use cases of different Marketplace add-ons. After some intense questioning, I was able to find out what makes this Valiantys superhero tick. Who is Christophe? If Christophe had a superpower, it would ...

The post Meet our Software Development Manager Superhero appeared first on Valiantys - Atlassian Platinum Partner.

Catégories: Blog Société

Monitorer votre infra avec Telegraf, InfluxDB et Grafana

Dans un article précédent, nous avons vu comment monitorer avec Prometheus et Grafana une infrastructure dynamique basée sur Kubernetes.

Nous allons voir aujourd’hui comment monitorer une infrastructure plus classique avec Telegraf pour la collecte de mĂ©triques, InfluxDB pour le stockage et Grafana pour l’affichage et l’alerting. Nous nommerons cette solution TIG, dans la suite de cet article. Nous avons choisi ces outils, mais ils peuvent ĂȘtre remplacĂ©s par d’autres. Nous allons comparer Ă©galement cette solution Ă  d’autres outils du marchĂ© (Zabbix et Prometheus)

Architecture

Telegraf Architecture

Telegraf

Telegraf est un agent de récupération de métriques, 1 seul agent est nécessaire par VM. Cet agent sait récupérer des métriques exposées au format Prometheus et propose 2 modes de récupération des métriques, via :

  • push : la mĂ©trique est poussĂ©e dans Telegraf par le composant qui l’expose
  • pull : Telegraf rĂ©cupĂšre la mĂ©trique en interrogeant le composant qui l’expose (le mode le plus utilisĂ©)

Les mĂ©triques sont insĂ©rĂ©es au fil de l’eau dans InfluxDB.

InfluxDB

InfluxDB est une Time Series Database (TSDB) écrite en Go dont les principaux avantages sont les performances, la durée de rétention importante et la scalabilité (nous verrons plus loin sous quelles conditions).

Grafana

Grafana est un outil supervision simple et Ă©lĂ©gant, permettant de s’intĂ©grer Ă  une TSDB, ici InfluxDB. Grafana expose dans des dashboards les mĂ©triques brutes ou agrĂ©gĂ©es provenant d’InfluxDB et permet de dĂ©finir de maniĂšre honteusement simple des seuils d’alertes et les actions associĂ©es.

 

Cas d’utilisation

Dans cet article, nous allons monitorer une architecture simple :

  • une application web en Go exposĂ©e derriĂšre un Nginx
  • une base de donnĂ©e Mysql sollicitĂ©e par un cron

Telegraph permet de rĂ©cupĂ©rer par le biais de plugins les mĂ©triques des composants, ainsi que les mĂ©triques systĂšmes. Dans le cas nominal, Telegraf rĂ©cupĂšre ses mĂ©triques en mode pull. Cependant, dans le cas d’un cron ou d’un batch qui s’exĂ©cute pĂ©riodiquement, la rĂ©cupĂ©ration des mĂ©triques se fait en mode push (c’est au cron ou au batch d’envoyer les mĂ©triques Ă  Telegraf). Pour ce cas d’usage, nous allons utiliser le plugin http_listener qui permet Ă  Telegraf d’écouter en http sur un port afin de rĂ©cupĂ©rer les mĂ©triques envoyĂ©es par le cron/batch.

Telegraf cas d'utilisation

 

Installation

Pour cet article, l’installation se fera sous Ubuntu 16.04 LTS.

InfluxDB

Ajoutons le repo APT officiel d’InfluxDB :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install influxdb

DĂ©marrons le service :

sudo systemctl start influxd
Telegraf

Ajoutons le repo APT officiel de Telegraf :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install telegraf

DĂ©marrons le service :

sudo systemctl start telegraf
Grafana

Ajoutons le repo APT officiel de Grafana :

curl https://packagecloud.io/gpg.key | sudo apt-key add -
echo "deb https://packagecloud.io/grafana/stable/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/grafana.list

Installons le package :

sudo apt-get update
sudo apt-get install grafana

DĂ©marrons le service :

systemctl daemon-reload
systemctl start grafana-server
Configuration

InfluxDB

Nous allons créer une base de données pour pouvoir pousser les données remontées par Telegraf :

influx -execute "CREATE DATABASE influx_db"

CrĂ©ons l’utilisateur influx_user :

influx -execute “CREATE USER influx_user WITH PASSWORD 'influx_password'”
influx -execute “GRANT ALL ON influx_db TO influx_user

Il est possible de créer une retention policy pour déterminer la durée de conservation des données :

influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d’
Telegraf

Telegraf fonctionne sous forme de plugin Ă  activer pour rĂ©cupĂ©rer les mĂ©triques. L’écosystĂšme de plugins est riche : il y a des plugins pour monitorer nginx, cassandra, haproxy, postgresql
 Nous allons nous intĂ©resser Ă  quelques plugins en particulier pour notre exemple. Dans l’ensemble, les plugins sont simples Ă  configurer.

Nous allons voir ici des extraits de configuration.

Mode pull MĂ©triques systĂšmes

Les plugins permettant de remonter les métriques systÚmes :

  • cpu
  • disk
  • diskio
  • kernel
  • mem
  • processes
  • swap
  • system
$ head /etc/telegraf/telegraf.d/system.conf
 
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false


MĂ©triques MySQL
$ head /etc/telegraf/telegraf.d/mysql.conf

[[inputs.mysql]]
servers = ["db_user:db_password@tcp(127.0.0.1:3306)/?tls=false"]


MĂ©triques au format prometheus

Pour notre exemple, nous avons une application en Go qui expose des mĂ©triques au format prometheus sur l’url http://localhost:8080/metrics.
Nous allons utiliser le plugin prometheus pour récupérer ces données :

$ cat /etc/telegraf/telegraf.d/app.conf

[[inputs.prometheus]]
urls = ["http://localhost:8080/metrics"]
Mode push Plugin HTTP_LISTENER

Le plugin http_listener fonctionne en mode push. Il ouvre un port http et attend qu’on lui pousse des mĂ©triques.

$ cat /etc/telegraf/telegraf.d/http_listener.conf

## Influx HTTP write listener
[[inputs.http_listener]]
## Address and port to host HTTP listener on
service_address = ":8186"

## timeouts
read_timeout = "10s"
write_timeout = "10s"

Il faut ensuite envoyer les métriques au format InfluxDB line-protocol :

$ curl -i -XPOST 'http://localhost:8186/write' --data-binary 'account_deleted,host=server01,region=us-west value=32 1434055562000000000'
Configuration du backend

Pour configurer le backend, nous allons utiliser le plugin output InfluxDB.

$ cat /etc/telegraf/telegraf.conf


[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "influx_db"
username = "influx_user"
password = "influx_password"



Pour finir, redémarrons le service pour prendre en compte la configuration :

sudo systemctl restart telegraf

La configuration des plugins est documenté exhaustivement dans le fichier de configuration de base : /etc/telegraf/telegraf.conf

Grafana

La premiĂšre Ă©tape dans Grafana est d’ajouter la source de donnĂ©e (InfluxDB dans notre cas). Allons dans “Datasource” puis “Add Datasource” et ajoutons la base Influxdb.

Database : influx_db
Username : influx_user
Password : influx_password

Grafana - Add data source

Ensuite pour créer les dashboards, vous pouvez récupérer des dashboards de la communauté Grafana ou créer vos propres dashboards. Pour notre exemple, nous avons importé le dashboard suivant prévu pour Telegraf.

Grafana - Dashboard

Il est possible d’ajouter des alertes dans les dashboards, mais nous n’allons pas dĂ©tailler ce point dans cet article. Vous pouvez trouver des informations dans la documentation.

Note : Si vous utilisez Grafana en HA, pour le moment l’alerting n’est pas implĂ©mentĂ© en mode cluster. Du coup, il faut s’assurer de l’activer sur un seul des noeuds pour ne pas recevoir les alertes en double. NĂ©anmoins, si le noeud tombe, il n’y a plus d’alerting.

Comparaison TIG vs Zabbix

Avantages de TIG :

  • La configuration est plus simple (mĂ©triques et graphes)
    • Pour rĂ©cupĂ©rer une nouvelle mĂ©trique, il suffit de configurer en quelques lignes un plugin dans Telegraf, puis crĂ©er un dashboard dans Grafana.
  • La configuration est plus souple
    • Dans Zabbix on a besoin de dĂ©crire prĂ©cisĂ©ment chacune des mĂ©triques remontĂ©es, alors que dans TIG, InfluxDB n’a pas besoin de connaĂźtre la mĂ©trique Ă  l’avance pour pouvoir la stocker.
  • Simple sur une infra dynamique
    • Exemple: Autoscaling sur les principaux cloud provider, les VMs nouvellement crĂ©Ă©s (avec Telegraf configurĂ©) poussent auto-magiquement (sans configuration supplĂ©mentaire) dans InfluxDB.
  • Historique plus complet
    • La profondeur d’historique de Zabbix et d’InfluxDB est Ă©quivalente, nĂ©anmoins  Zabbix dispose d’une stratĂ©gie d’échantillonnage (configurable) entraĂźnant une dĂ©gradation de la qualitĂ© de la donnĂ©e sur le long terme.
  • Les dashboards dans Grafana sont plus conviviaux et plus simples

 

Avantages de Zabbix :

  • Gestion des droits
    • La gestion des droits est plus fine sur Zabbix
  • UtilisĂ© en prod depuis des annĂ©es
    • Release 1.0 sorti le 23 mars 2004
    • Stable, complet et reconnu
  • Ressources de la communautĂ© (templates, alertes, agent 
)
    • Les agents Zabbix sont disponibles pour de nombreux systĂšmes d’exploitation
    • De nombreux templates pour configurer les mĂ©triques/alertes/graphes sont disponibles sur internet

 

TIG vs Prometheus TIG vs Prometheus

Avantages de  TIG :

  • Historique plus complet (plusieurs annĂ©es vs plusieurs heures/semaines)
    • Le but premier de Prometheus est le monitoring temps rĂ©el, la rĂ©tention par dĂ©faut est de 1 mois. Il est cependant possible d’augmenter cette rĂ©tention.
  • Besoin d’un seul agent par VM
    • Telegraf permet de rĂ©cupĂ©rer plusieurs mĂ©triques avec un seul agent et pousse les donnĂ©es dans InfluxDB.
  • C’est l’agent Telegraf qui envoie les donnĂ©es Ă  InfluxDB
    • Pas besoin d’ouvrir de multiples ports comme c’est le cas avec Prometheus.

 

Avantages de Prometheus :

  • Prometheus peut utiliser des services discovery pour savoir quels sont les services Ă  monitorer
    • Exemple: Dans des environnements type Kubernetes, Docker, Prometheus est particuliĂšrement adaptĂ© pour rĂ©cupĂ©rer les mĂ©triques de conteneurs Ă  durĂ©e de vie variable.

 

Conclusion

Dans la stack TIG nous avons apprĂ©ciĂ© la simplicitĂ© d’installation et de configuration, la souplesse de collecte des mĂ©triques et la profondeur d’historique.

La version opensource d’InfluxDB ne scale pas mais il est possible de scaler en passant sur les versions payantes InfluxEnterprise ou InfluxCloud. Nous n’avons, Ă  l’heure actuelle, pas de retour d’expĂ©rience concernant ces deux derniers produits.

Pour la scalabilitĂ©, il est Ă©galement possible d’utiliser OpenTSDB qui est une “Time Serie Database” open source, mais elle est bien plus compliquĂ©e Ă  installer, et nous n’avons pas de retour sur son utilisation.

Il est possible de mettre Grafana en HA. NĂ©anmoins, le mode cluster de l’alerting n’est pas encore implĂ©mentĂ©. Cela signifie que soit on ne dĂ©finit les alertes que sur un nƓud, soit on les dĂ©finit sur tous les nƓuds mais les notifications seront dupliquĂ©es.

La modularitĂ© de cette stack nous permet si besoin d’utiliser :

  • d’autres collecteurs tels que Snap  (dans le cas, par exemple, oĂč Telegraf ne proposerait pas de plugin adaptĂ©).
  • d’autres outils d’alerting tels que Kapacitor que nous Ă©tudierons prochainement.

Le cas d’utilisation que nous avons prĂ©sentĂ© est disponible sur ce repo : https://gitlab.octo.com/tpatte/monitoring_influxdb

 

 

Articles suggested :

  1. Exemple d’utilisation de Prometheus et Grafana pour le monitoring d’un cluster Kubernetes
  2. Nous Ă©tions Ă  la KubeCon Europe (2/2)

Catégories: Blog Société

Revue de Presse Xebia

revue de presse 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é How to speed up your slow Gradle builds http://www.gravatar.com/avatar/15de70d494a999da31d0a8dbd0bb38e6http://blog.xebia.fr/author/nullhttp://twitter.com/bonbonkinghttp://github.com/jinqianPar Qian Jin

Quelques semaines aprÚs le Google I/O, voici une compilation des astuces extraites depuis la session « Speeding Up Your Android Gradle Builds » avec des explications pour accélérer les builds Gradle dans vos projets Android.

MobileNets: Open-Source Models for Efficient On-Device Vision http://www.gravatar.com/avatar/37a6259cc0c1dae299a7866489dff0bdhttp://blog.xebia.fr/author/nullhttp://twitter.com/bonbonkinghttp://github.com/jinqianPar Qian Jin

Google vient de publier MobileNets, une série des modÚles Mobile-First pour TensorFlow. Ces modÚles sont conçus pour maximiser efficacement la précision tout en étant conscient des ressources restreintes pour une application sur les devices mobiles. La release contient la définition du modÚle en utilisant TF-Slim, ainsi que 16 checkpoints de classification ImageNet pré-entrainés pour les utilisations dans les projets mobiles des toutes les tailles.

Data Le streaming avec Spark, plus rapide que jamais http://www.gravatar.com/avatar/ea9359b0d59422804330a542a4b7f20chttp://blog.xebia.fr/author/ldivadhttp://twitter.com/loicMDivadhttps://github.com/DivLoicPar LoĂŻc DIVAD

Lors du Spark Summit 2017 qui a eu lieu entre le 5 et 7 Juin un nouveau module de Spark a Ă©tĂ© annoncĂ© : Continuous Processing. Un an aprĂšs le lancement de Structured Streaming, le composent unifiant l’écriture des traitements batch en temps rĂ©el, c’est sur les temps de latence que l’entreprise Databricks a dĂ©cidĂ© de mettre l’accent cette annĂ©e. Apache Spark est connu pour avoir un mode streaming basĂ© sur un modĂšle micro-batch.
L’objectif de ce nouveau module est d’aller plus loin et de permettre l’application continue des requĂȘtes dĂ©finies via Structured Streaming. La sortie du mode micro batch promet un passage des latences minimales de 100 millisecondes Ă  moins d’une milliseconde. Ce mode d’exĂ©cution est disponible sur la plateforme cloud de Databricks et son intĂ©gration Ă  Spark est prĂ©vu pour la version 2.3.0.

Il a longtemps Ă©tĂ© question de faire de Spark le moteur de stream processing le plus facile Ă  utiliser, avec Continuous Processing il s’agit maintenant de dĂ©crocher le titre de moteur le plus rapide.

Sparkdl, une nouvelle librairie de Deep Learning pour Spark http://www.gravatar.com/avatar/ea9359b0d59422804330a542a4b7f20chttp://blog.xebia.fr/author/ldivadhttp://twitter.com/LoicMDivadhttp://github.com/DivLoicPar LoĂŻc DIVAD

Le Spark Summit a aussi Ă©tĂ© l’occasion d’introduire une nouvelle librairie open source dĂ©diĂ©e au Deep Learning sur Spark : Deep Learning Pipeline. MĂȘme si il existait dĂ©jĂ  des initiatives comme TensorFrame ou TensorFlowOnSpark cette nouvelle librairie apporte plusieurs nouvelles fonctionnalitĂ©s :

  • Un import et dĂ©codage distribuĂ© d’image pour de la classification.
  • Le transfert learning qui permet d’apprendre Ă  partir de modĂšles dĂ©jĂ  entraĂźnĂ©s.
  • L’interaction avec des modĂšles dĂ©veloppĂ©s avec Kearas ou TensorFlow.
  • L’intĂ©gration aux pipelines de Machine Learning dĂ©jĂ  existantes dans le cadre de tuning de paramĂštres.
  • La possibilitĂ© d’enregistrer des rĂ©seaux entraĂźnĂ©s sous forme d’UDF utilisables en SQL.

Malheureusement cette librairie n’est disponible qu’en python pour l’instant. Aucune information n’a Ă©tĂ© donnĂ©e sur l’intĂ©gration de cette librairie dans Pyspark. La question maintenant est de savoir si elle remplira son objectif en rendant accessible le Deep Learning Ă  une population encore plus grande.

Cloud Enfin de l’autoscaling pour DynamoDB ! http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Amazon vient tout juste d’annoncer son ajout de la capacitĂ© d’autoscaler DynamoDB, une de ses bases de donnĂ©es as a service.

En effet, jusqu’Ă  maintenant, il n’Ă©tait possible de dĂ©finir les « read capacity » et « write capacity » que manuellement, forçant Ă  prĂ©voir la charge soi-mĂȘme et Ă  adapter ces capacitĂ©s en consĂ©quence.

DĂ©sormais, il sera possible d’automatiquement augmenter ou diminuer ces capacitĂ©s en se basant sur des mĂ©triques remontĂ©es par DynamoDB dans CloudWatch.

DevOps Google et Netflix lancent Spinnaker http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Google et Netflix viennent d’officialiser la version 1.0 de Spinnaker, la plateforme de gestion de dĂ©ploiement sur du cloud.

Alors que certains se reposent dĂ©sormais sur les orchestrateurs de conteneurs (Mesos/Marathon, Swarm, Nomad, Kubernetes), d’autres travaillent toujours avec des machines virtuelles sur des Cloud publics ou privĂ©s. Dans ce cadre, une problĂ©matique constante Ă  l’heure du continuous delivery est « comment dĂ©ployer proprement et automatiquement ? »; canary release, blue/green deployment, et tant d’autres mĂ©thodes chacune adaptĂ©e Ă  des besoins diffĂ©rents.

Spinnaker, crĂ©Ă© par Netflix il y a 3 ans, a pour objectif d’ĂȘtre ce gestionnaire de dĂ©ploiement. Un remplacement Open Source qui semble trĂšs crĂ©dible face au « scotch » habituel avec CloudFormation (cĂŽtĂ© AWS) et leurs « ReplacingUpdates » et « RollingUpgrades » qui ne vont souvent pas assez loin et forcent Ă  finir le travail soi-mĂȘme avec des lambdas.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux