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

LeanKanban France
 la prochaine fois je reste 2 jours!

Qualitystreet - Jean Claude GROSJEAN - il y a 9 heures 50 min

C’Ă©tait ma premiĂšre venue Ă  cette confĂ©rence LeanKanban France dont le programme m’avait Ă  chaque fois tentĂ© les annĂ©es prĂ©cĂ©dentes mais Ă  laquelle je devais systĂ©matiquement renoncer pour des raisons d’emploi du temps. Pris par ma formation AgileUXLeanUX pour les Product Owner le jour 1 de cette Ă©dition 2016, je ne suis venu que le second jour…

The post LeanKanban France… la prochaine fois je reste 2 jours! appeared first on QualityStreet - Blog Agile depuis 2007.

Catégories: Blog Individuel

AGILE : 9 conseils pour un forum ouvert

Ces derniers temps, j’ai eu l’occasion de participer Ă  plusieurs forums ouverts avec diffĂ©rents rĂ©sultats plus ou moins magiques. Avant toute chose, revenons Ă  la base : Ă  quoi correspond un forum ouvert ?

Le forum ouvert est nĂ© du constat qu’avec un grand groupe de personnes (jusqu’Ă  plusieurs centaines), il est complexe d’animer une rĂ©union dans laquelle tout le monde se sent utile en apportant sa pierre Ă  l’Ă©difice. GĂ©nĂ©ralement, les discussions les plus utiles vont se dĂ©rouler Ă  la machine Ă  cafĂ©. CrĂ©Ă© il y a plus de 30 ans aux Etats-Unis, il s’exporte aujourd’hui dans tous les pays. À l’inverse d’une confĂ©rence ou grande messe d’entreprise, les participants ne sont plus dans une posture passive, mais active du dĂ©but Ă  la fin. Avant d’entrer dans les conseils voyons en quelques lignes le b.a.-ba. La base d’un forum ouvert Sans ordre du jour prĂ©Ă©tabli, sans tables et sans limitation sur les questions, ce format peut sembler de prime abord dĂ©sorganisĂ© et producteur de rĂ©sultats imprĂ©visibles. Pourtant, grĂące Ă  quelques rĂšgles fondamentales, l’encadrement d’un forum ouvert va permettre de structurer les Ă©changes. En s’appuyant sur l’auto-organisation et l’intelligence collective, il permet de faire travailler ensemble un grand nombre d’individus. La magie du forum ouvert nĂ©cessite de respecter quelques rĂšgles simples : Vous vous ĂȘtes certainement dans votre vie retrouvĂ©s Ă  une rĂ©union qui ne vous apportait plus. Pour ne pas froisser les autres membres, vous avez pris sur vous et attendu la fin. La loi des deux pieds vous libĂšre de ce poids, si vous n’apprenez plus ou ne pouvez plus aider alors sentez-vous libre d’aller vers un autre sujet. Dans les moments de discussions, partez du principe que les personnes prĂ©sentes veulent investir leur temps avec vous dans ce sujet. Elles seront engagĂ©es et donneront le meilleur d’elles-mĂȘmes ; construire ensemble est une clĂ© de la rĂ©ussite. Suite Ă  la session de travail, ne revenez pas en arriĂšre sur vos dires et dĂ©cisions, vos choix Ă©taient les meilleurs dans le contexte donnĂ© pour un temps donnĂ©. Enfin une session dĂ©marre Ă  un instant et fini Ă  un autre, respectez le timing et arrĂȘtez les discussions quand la cloche retentit.

Les 4 principes résument ces idées :

  • Les personnes qui sont lĂ  sont les bonnes personnes ;
  • ce qui arrive est la seule chose qui pouvait arriver ;
  • ça commence quand ça commence ;
  • quand c’est fini, c’est fini.

Certains participants se retrouveront dans l’attitude des animaux totems :
Les papillons suivent leurs envies, prennent une pause ou rĂ©flĂ©chissent. Souvent, ils vont encourager les Ă©changes informels et potentiellement recrĂ©er de nouvelles zones d’Ă©changes Ă  mi-chemin entre deux sujets.
Les abeilles butinent sur les ateliers et pollinisent les idées, elles vont faire circuler les idées entre les ateliers en apportant une cohérence et en faisant la promotion des bonnes idées.

Les grandes phases d’un forum ouvert Au dĂ©marrage, tous les participants se retrouvent en session plĂ©niĂšre pour dĂ©finir ensemble l’ordre du jour autour du thĂšme de la journĂ©e. L’ouverture se rĂ©alise gĂ©nĂ©ralement tous ensemble en cercle. Chaque participant amĂšne ses idĂ©es, ses questions ou mĂȘme des urgences Ă  traiter. L’objectif est simple, Ă©laborer ensemble l’ordre du jour. Tout le monde doit s’y retrouver pour que l’engagement soit maximal. Ensuite lors des sessions de travail, les participants vont tous ensemble dĂ©battre des diffĂ©rents sujets sĂ©lectionnĂ©s. En tant qu’organisateur ou sponsor, venir avec des rĂ©ponses prĂ©faites est Ă  Ă©viter, la dĂ©lĂ©gation de pouvoir doit ĂȘtre maximale. Enfin, la clĂŽture se passe Ă  nouveau en plĂ©niĂšre. Les participants vont partager leurs apprentissages en prĂ©sentant la restitution co-rĂ©alisĂ©e. Quelques ingrĂ©dients de la recette Travailler durant une session de plusieurs heures avec 50 personnes demande une certaine organisation pour dĂ©terminer qui sont les participants, la logistique nĂ©cessaire, le dĂ©roulĂ©, le produit en sortie, etc. Voici quelques conseils qui pourront vous aider Ă  Ă©viter certains piĂšges classiques d’un forum ouvert:
    1. Un lieu pour ouvrir
      Ce style d’atelier doit permettre de laisser libre cours Ă  ses idĂ©es, il faut donc veiller Ă  avoir une salle oĂč tout le monde peut apporter un sujet sans la moindre gĂȘne physique et/ou mentale. Lorsque nous sommes habituĂ©s Ă  des rĂ©unions et confĂ©rences nous sommes passifs. Nous ne sommes pas exposĂ©s aux regards de l’assemblĂ©e, se lever devant 100 personnes nous fera sortir de notre zone de confort. Pour Ă©viter une timiditĂ© accrue, crĂ©ez une zone oĂč tout le monde peut se voir, pas uniquement ceux qui vont sur le devant de la scĂšne. Favorisez la libre circulation avec une salle suffisamment grande et sans mobilier, il n’est pas imaginable de faire lever 10 personnes pour accĂ©der Ă  la zone de partage ou pire encore avoir des personnes qui ne la voient pas. Nous comprenons tout de suite qu’une ouverture n’est pas possible dans un amphithĂ©Ăątre par exemple.9conseils-agile

 

  1. Poser le cadre
    Le concept est assez simple et peut nĂ©cessiter un minimum de cadre. N’oubliez pas lors de l’introduction de rappeler les 4 principes, les 2 postures animales et la loi des deux pieds. Autant les principes sont faciles Ă  saisir, les autres sont moins Ă©vidents Ă  apprĂ©hender lorsque nous sommes dĂ©butants. Prenez du temps pour expliquer les concepts avec des exemples concrets.
  2. Le thĂšme
    Dans le cas d’un forum ouvert en entreprise, ne pas cadrer par une thĂ©matique va laisser place soit Ă  un vide d’idĂ©es soit Ă  une divergence trop accrue. La restitution risque ensuite d’ĂȘtre complexe Ă  animer. Ce type d’atelier peut gĂ©nĂ©ralement avoir pour but de rĂ©soudre plusieurs sujets d’un mĂȘme thĂšme (une offre, une organisation, des nouvelles pratiques, etc.), si besoin vous pouvez crĂ©er des zones par thĂšmes.
  3. Récolter les sujets 
    Lorsque le public est motivĂ© et comprend bien le fonctionnement, nous allons vite avoir plus de sujets que d’espace, la place du marchĂ© peut mĂȘme devenir inondĂ©e. Tout comme dans une rĂ©union l’ordre du jour doit pouvoir ĂȘtre traitĂ© dans le temps imparti. Limitez le nombre de sujets Ă  aborder. Cela ne veut pas dire arrĂȘter la collecte, mais permettre une sĂ©lection collective suite Ă  un pitch ou une discussion puis un vote.
  4. Timeboxer les sessions
    Portez le concept du principe « Quand c’est fini, c’est fini » aux sessions et non pas qu’au forum ouvert. Il faut savoir passer au sujet suivant et laisser la place. Le facilitateur devra veiller au grain!9conseils-agile-1
  5. Les lieux d’Ă©changes
    Une fois les sujets votĂ©s, ils vont ĂȘtre rĂ©partis gĂ©ographiquement pour permettre de ne pas dĂ©ranger les voisins (nuisance sonore). A contrario les Ă©loigner va forcer les participants Ă  faire de nombreux pas et perdre de prĂ©cieuses minutes. Ils ne voudront plus bouger et iront parfois mĂȘme Ă  l’encontre de la loi des deux pieds. Faites ressortir les zones de regroupement via des totems. PrĂ©fĂ©rez une zone repĂ©rable par une image plutĂŽt qu’un mot (ex: ampoule, bateau, cheval, vague, Ă©toile, etc.)

    9conseils-agile-2
          9conseils-agile-3

  6. Visualiser continuellement
    Une fois le forum dĂ©marrĂ© le public se sĂ©pare et va vers son centre d’intĂ©rĂȘt le plus fort. Ce dernier peut Ă©voluer, ils souhaiteront alors migrer vers un nouveau sujet. CrĂ©ez une zone de management visuel avec le programme et les premiĂšres restitutions sous forme de dessins, mindmap, nuage de mots, etc. (voir aussi « Forum ouvert, la salle des nouvelles »).9conseils-agile-4
  7. Restitution
    L’humain est curieux et souhaite souvent ĂȘtre partout. Malheureusement l’humain n’est pas divisible. Pensez donc Ă  faire une restitution oĂč chaque groupe partagera les apprentissages. Quel format, Combien de temps, Quel support ? Toutes les rĂ©ponses doivent ĂȘtre abordĂ©es lors de l’introduction. Profitez-en pour pousser les groupes Ă  Ă©lire un secrĂ©taire. Il prendra en notes les Ă©changes et en fera la retranscription. Il devra ĂȘtre autant que possible neutre pour ne pas ajouter d’interprĂ©tations personnelles. Une restitution durant les sessions de travail permettra Ă©galement aux nouveaux arrivants de s’intĂ©grer plus facilement.
  8. Cercle de clÎture
    En fin de forum ouvert, invitez tous les participants (qui se connaissent maintenant mieux) Ă  prĂ©senter les restitutions rĂ©alisĂ©es au cours des sessions de travail. PrĂ©fĂ©rez les paperboards gribouillĂ©s de schĂ©mas, dessins et graphiques, ils seront plus exploitables que les proses Ă©crites. C’est aussi le moment pour dĂ©finir un plan d’action global (en rapport avec le thĂšme de la journĂ©e). Profitez-en aussi pour rĂ©cupĂ©rer le ressenti des participants sur ce nouveau format et rĂ©cupĂ©rer du feedback en vue du prochain forum ouvert.

Le forum ouvert est un format incroyablement efficace Ă  condition qu’il soit suffisamment prĂ©parĂ©. Les participants ne doivent pas sentir un flottement par un manque d’organisation. Pour cela, je vous conseille au minimum de rĂ©pondre diffĂ©rents items de la mĂ©thode des 7P pour cadrer votre forum ouvert.

Un autre constat, gĂ©nĂ©ralement le public est assez frileux Ă  l’idĂ©e d’ĂȘtre un participant actif plutĂŽt que dĂ©voreur de confĂ©rences. Ils auront l’impression d’une session fourre-tout oĂč ils vont perdre leur temps. Une bonne communication pourra ĂȘtre nĂ©cessaire pour tuer les apriorismes.

Toutefois, nous ne pouvons jamais savoir avec exactitude ce qu’il va se passer, dans ce type d’Ă©vĂ©nement nous donnons la libertĂ© aux participants d’Ă©noncer, d’analyser les problĂšmes majeurs et de trouver des solutions par eux-mĂȘmes. Les dĂ©cisions et plans d’actions qui en ressortiront seront souvent plus solides et durables. Ils seront Ă©galement mis en place plus rapidement car tous auront fait partie du commencement et seront donc convaincus.

Maintenant il n’y a plus qu’Ă  se lancer et vivre l’expĂ©rience !

Catégories: Blog Société

Préparez votre Noël au prochain meetup Hackergarten

Comme chacun sait, pour avoir de beaux cadeaux Ă  NoĂ«l, il faut avoir Ă©tĂ© trĂšs sage. Et ça tombe bien ! Le Hackergarten est lĂ  pour vous permettre de vous rattraper et Ă©quilibrer votre karma avant les fĂȘtes. Venez coder demain jeudi 8 dĂ©cembre, dans les locaux de Xebia, 156 boulevard Haussmann, 7e Ă©tage.

Paris-Hackergarten

AprÚs une session trÚs réussie en collaboration avec le meetup CocoaHeads, le Hackergarten poursuit sa mission : réunir aspirants contributeurs et maintainers, pour ensemble construire les OSS de demain.
Au menu de cette session hivernale :

La sĂ©ance sera suivie d’un buffet pour rĂ©compenser les valeureux codeurs du jeudi.

Inscrivez-vous gratuitement sur le page du meetup.

Catégories: Blog Société

Meetup JHipster #6 “Focus sur JHipster 4: la migration vers Angular 2!”

Blog d’Ippon Technologies - mar, 12/06/2016 - 14:33

Nous avons le plaisir d’accueillir dans nos locaux le 6Ăšme Meetup JHipster le lundi 19 dĂ©cembre Ă  partir de 19h.

Au menu : “Focus sur JHipster 4: la migration vers Angular 2!”

Cette session sera animée par:

‱ William Marques, membre de la “core team”, travaillant actuellement chez Ippon Technologies. Lors de son stage chez Ippon Technologies, William a notamment menĂ© Ă  bien la migration vers le guide de style de John Papa, prĂ©parant ainsi la migration vers Angular 2. DĂ©couvrez son parcours chez Ippon du stage Ă  l’organisation du hackathon JHipster.

‱ Flavien Cathala, actuellement en stage chez Ippon Technologies depuis 3 mois, et travaillant à temps plein sur la migration Angular 2.

William et Flavien seront également épaulés par Victor Da Silva (nouveau stagiaire chez Ippon Technologies, travaillant sur JHipster à temps plein), et Julien Dubois (créateur de JHipster et organisateur du meetup).

Cette session aura un objectif double:

  • montrer comment JHipster va migrer vers Angular 2, et avoir ainsi une “preview” du futur JHipster 4
  • voir comment migrer un project AngularJS 1 complexe vers un projet Angular 2

Le Meetup sera suivi d’un buffet sur le Rooftop.

Pour en savoir plus et s’inscrire au Meetup rendez-vous ici.

 

Catégories: Blog Société

AWS re:Invent 2016 – Annonces de la 2nde keynote

AprĂšs une premiĂšre journĂ©e marathon d’annonces lors de l’Ă©vĂ©nement annuel d’Amazon Web Services animĂ©e par Andy Jassy, CEO d’Amazon Web Services, nous voici prĂȘts pour dĂ©marrer une seconde journĂ©e d’annonces cette fois-ci animĂ©e par Wernel Vogels, CTO d’Amazon.com qui arbore un T-Shirt Transformers. Un message Ă  faire passer ? Bon, ok, ce n’est pas trĂšs fin peut-ĂȘtre, mais Werner veut nous parler de transformation de l’IT. Pour dĂ©velopper ses nouveaux services Amazon Web Services s’appuie sur les retours faits par ses clients. L’objectif est d’ĂȘtre l’entreprise IT la plus au centre des besoins de ses clients. Pour cela, il donne 4 moyens:

  • Ecouter avec attention les besoins des clients
  • Donner aux clients le choix
  • Travailler depuis les besoins clients
  • Aider les clients Ă  se transformer

Finalement, rien que du bon sens, mais des Ă©lĂ©ments qui peuvent faire la diffĂ©rence vis-Ă -vis de la concurrence. Werner Vogels pense qu’AWS peut aider chaque entreprise Ă  ĂȘtre un « transformer » en terme de dĂ©veloppement, data et compute *. Le dĂ©veloppement est en train de changer et le DĂ©veloppement & le Test sont les Ă©lĂ©ments clĂ©s lĂ  oĂč l’agilitĂ© vit. Pour transformer le dĂ©veloppement, cela commence par un framework bien architecturĂ©. Pour cela, il fait rĂ©fĂ©rence au Twelve Factor App. Un framework bien architecturĂ© repose sur 4 piliers:

  • la sĂ©curitĂ©,
  • la fiabilitĂ©,
  • la performance et l’efficience, ainsi que
  • l’optimisation des coĂ»ts.

L’excellence opĂ©rationnelle passe par l’automatisation et la prĂ©paration avec des outils tels qu’Amazon CloudFormation. Les premiĂšres annonces dĂ©marrent avec de nouveaux sets d’outils liĂ©s au dĂ©ploiement. Vient tout d’abord AWS OpsWorks for Check Automate qui n’est autre qu’un server Chef complĂštement managĂ©, puis Amazon EC2 Systems Manager qui est une collection d’outils AWS pour packager les installations, les patcher, gĂ©rer la configuration de resources, et l’automatisation des tĂąches. Ces deux nouveautĂ©s sont disponibles dĂšs aujourd’hui.

aws-reinvent

AWS Code Build

Un 3Ăšme outil accompagne les 2 prĂ©cĂ©dents, il s’agit d’AWS CodeBuild. C’est un service de compilation de code source et d’exĂ©cution de tests unitaires. Entendons-nous, il s’agit d’une usine de build logiciel. AWS souhaite ĂȘtre prĂ©sent sur le marchĂ© de ce type d’outils car, c’est un « enabler » de changements dans la façon dont on produit et on fait fonctionner du logiciel. Le Continuous Delivery apporte des avantages qui changent les façons de fonctionner en se basant sur le principe de livrer de plus petits changements / incrĂ©ments, avec moins de risques et Ă  un coĂ»t moindre. L’exĂ©cution de tests automatisĂ©s augmente la fiabilitĂ© et la capacitĂ© Ă  scaler. L’idĂ©e est de livrer moins de fonctionnalitĂ©s Ă  chaque fois, mais des updates plus fiables avec moins de lignes de code et une sĂ©curitĂ© amĂ©liorĂ©e.

Monitoring

On nous parle maintenant de pratique en rappelant les outils disponibles: CloudWatch Metrics, CloudWatch Events, CloudWatch Logs, ainsi que CloudTrail. Mais pour avoir une meilleure comprĂ©hension de ce qui se passe dans l’exĂ©cution des services applicatifs, les clients d’AWS peuvent maintenant s’appuyer sur AWS X-Ray qui permet d’analyser et dĂ©bugger en production des applications de type distribuĂ©. Il est par exemple possible de faire un drill down sur la latence des Ă©lĂ©ments constitutifs de l’applicatif.

 

reinvent-1     reinvent-2

 

Répondre Réagir aux événements systÚmes

On nous a parlĂ© de monitorer, mais comment rĂ©pondre Ă  des Ă©vĂ©nements en production. Bien entendu, il est possible de positionner des alarmes et de rĂ©pondre en rĂ©action Ă  une notification d’alarme, mais pourquoi ne pas mettre en relation des Ă©vĂ©nement d’alarme (Real-Time Alarming avec CloudTrail et CloudWatch) Ă  des capacitĂ©s de rĂ©ponse automatique et des chemin d’escalade automatisĂ©s ?

Pour rĂ©pondre Ă©galement, il est essentiel d’avoir une vue sur la santĂ© des services. Wernel Vogels annonce en rĂ©ponse Ă  ce besoin, un nouveau service appelĂ©: AWS Personal Health Dashboard qui permet d’avoir une vue personnalisĂ©e des resources utilisĂ©es, et d’y automatiser les rĂ©ponses aux notifications d’Ă©vĂ©nements systĂšmes en utilisant des fonctions de type AWS Lambda.

Un peu de sécurité

La sĂ©curitĂ© est selon Werner Vogels la premiĂšre prioritĂ© d’AWS, et l’automatisation y joue un rĂŽle important. Parmis les Ă©lĂ©ments de sĂ©curitĂ© classiques sur lesquels nous appuyer, nous retrouvons: CloudHSM, CloudTrail, IAM, Config, ou encore KMS. Toutefois aborder la sĂ©curitĂ© par l’automatisation, nous protĂšge Ă©galement via, par exemple, l’usage de WAF (Web Application Firewall), ou encore en utilisant Amazon Inspector qui permet d’effectuer de façon automatisĂ©e des Ă©valuations de sĂ©curitĂ© pour amĂ©liorer la sĂ©curitĂ©.

Un enjeu grandissant dans le domaine de la sĂ©curitĂ© est la capacitĂ© Ă  se prĂ©munir d’attaques de type DDOS. Elles peuvent s’attaquer Ă  la disponibilitĂ© des services sous plusieurs forme: par une volumĂ©trie massive (rĂ©seau) submergeant les capacitĂ©s, par un Ă©puisement des resources, ou encore en s’attaquant Ă  des faiblesses plus spĂ©cifiques du design applicatif. Pour rĂ©pondre Ă  cette menace, AWS propose Ă  ses clients le service AWS Shield disponible par dĂ©faut et sans action particuliĂšre. Toutefois, il existe une version avancĂ©e qui permet de se prĂ©munir d’attaques larges et sophistiquĂ©es.

La data, un différentiateur dans la compétition

Depuis plusieurs annĂ©es maintenant, la maĂźtrise et l’exploitation de la Data sont devenus des Ă©lĂ©ments diffĂ©rentiateurs dans la compĂ©tition. AWS l’a mis au coeur de sa stratĂ©gie en proposant une large gamme d’outils permettant d’adresser tous les domaines classiques de la Data: le data processing, le data warehousing, le reporting, le processing temps rĂ©el, ou encore les analyses prĂ©dictives. La qualitĂ© de la data est en particulier un Ă©lĂ©ment clĂ©.

Amazon Pinpoint

Dans le sujet de la Data et du Mobile, manquait une brique importante, qui Ă©tait l’apanage de spĂ©cialistes du domaine comme Urban Airship: la capacitĂ© Ă  rĂ©aliser du targeting de notification push pour mobile. Il Ă©tait jusqu’Ă  prĂ©sent possible d’envoyer des notifications Ă  des devices, mais il fallait passer par un outil tiers, si nous souhaitions pouvoir cibler des segments d’utilisateurs via des campagnes. Pour cela, il est nĂ©cessaire de comprendre les comportements utilisateurs que nous souhaitons engager, avoir un outil qui permette de dĂ©livrer les notifications, mais Ă©galement des outils qui permettent de traquer l’efficacitĂ© et les rĂ©sultats des campagnes lancĂ©es. Amazon Pinpoint accompagnĂ©s des diffĂ©rents autres outils Data est censĂ© apporter cet Ă©lĂ©ment de rĂ©ponse.

Architecture Data modernes

Wernel Vogels présente les éléments clés de ce qui fait une architecture Data moderne, cela passe par un nombre de points, tels que:

  • La capacitĂ© Ă  ingĂ©rer de façon automatisĂ©e et sĂ»re de la donnĂ©e
  • PrĂ©server la version originale des sources
  • Manager la gouvernance, la sĂ©curitĂ© et la privacy des donnĂ©es

Pour gĂ©rer la donnĂ©e, en particulier l’ingestion, vous pouvez vous appuyer sur diffĂ©rents composants, tels que : S3 Upload, S3 Acceleration, Kinesis, Snowball ou encore DynamoDB Streams. Pour la prĂ©servation des donnĂ©es originales, vous pouvez de mĂȘme vous appuyer sur: S3, EFS, EBS, DynamoDB ou encore RDS. Des outils tels que S3 Storage Management et Glacier vous permettent de mieux gĂ©rer le cycle de vie de la donnĂ©e tout comme le storage Ă  froid, alors que des outils comme AWS Config, CloudTrail, KMS permettent de manager la gouvernance, la sĂ©curitĂ©, et privacy des donnĂ©es.

Amazon Glue

Pour faire le liens entre diffĂ©rents composant, il est nĂ©cessaire d’avoir des outils sur lesquels s’appuyer pour ne pas avoir Ă  rĂ©inventer la roue en permanence. C’est ce Ă  quoi se propose de rĂ©pondre AWS Glue, un nouveau service. AWS Glue est ni plus ni moins qu’un ETL managĂ© qui a pour objectif premier de permettre d’alimenter les data stores d’Amazon. AWS Glue est intĂ©grĂ© en particulier avec S3, RDS, Redshift, et tout data store compatible JDBC. L’outil permet de scheduler et exĂ©cuter des jobs, mais Ă©galement de construire un catalogue de donnĂ©es, ou encore de gĂ©nĂ©rer et Ă©diter des scripts de transformation.

 

reinvent-3 reinvent-4 reinvent-5

Pour se faire une idĂ©e de la big picture d’une architecture data moderne selon AWS, voici un schĂ©ma de synthĂšse qui permet d’avoir une vue globale des service orientĂ©s donnĂ©es, comment ils interagissent entre eux, et comment les classer :

 

reinvent-6

Avec tous ces outils adaptĂ©s Ă  chaque besoin, le but d’AWS est de permettre Ă  ses clients ne plus ĂȘtre dans 80% de prĂ©paration de donnĂ©es et 20% d’analytique, mais plutĂŽt l’inverse: utiliser 20% de son temps Ă  la prĂ©paration des donnĂ©es et 80% de son temps Ă  leur analyse.

AWS Batch

Partons maintenant pour un one more thing non nĂ©gligeable sur l’axe de la data: Amazon Web Services en a encore sous la pĂ©dale, et prĂ©sente un dernier service data clĂ© qui risque de faire mouche auprĂšs des clients: AWS Batch.

AWS Batch est un service managĂ© qui a permet de lancer des traitements batch Ă  n’importe quelle Ă©chelle. Il n’est plus nĂ©cessaire de provisionner de resources pour effectuer des traitements. AWS Batch provisionne lui-mĂȘme les quantitĂ©s nĂ©cessaires de resources pour exĂ©cuter les traitements en fonction des prĂ©-requis qui ont Ă©tĂ© soumis avec le job. Il n’y a plus besoin d’installer et d’exploiter de logiciel spĂ©cifique ni mĂȘme de cluster. Ainsi, il est possible de se focaliser sur l’analyse des rĂ©sultats et la rĂ©solution de problĂšmes (cf: 80% d’analyse vs 20% de setup). AWS Batch est capable d’exĂ©cuter du travail sur l’ensemble des services et fonctionnalitĂ©s de de calcul, telles que les instances EC2 et plus spĂ©cifiquement les instances Spot, ce qui permettra de tirer partides prix les plus bas.

AWS Batch n’ajoute pas de charges aux services utilisĂ©s. On ne paie que pour les resources AWS utilisĂ©es pour stocker et exĂ©cuter les jobs de batch. Le service est disponible dĂšs aujourd’hui.

Serverless et containers

Le focus de la keynote passe à présent sur le serverless. Werner Vogels fait une entrée en matiÚre en présentant les différents niveaux de compute disponibles au travers de leurs services :

reinvent-7

Containers

Plusieurs nouveautĂ©s autour du compute ont dĂ©jĂ  Ă©tĂ© prĂ©sentĂ©es dans la keynote du jour prĂ©cĂ©dent, et il est temps de parler maintenant d’Amazon ECS avant de passer Ă  Lambda dans un second temps.

Werner rappelle que le sujets des containers soulĂšvent de nombreux challenges:

  • La gestion de containers
  • Les pipelines d’intĂ©gration
  • La gestion d’infrastructure
  • L’accĂšs aux resources
  • La sĂ©curitĂ©
  • Le scheduling de tĂąches
  • Le service discovery, ou encore
  • La haute disponibilitĂ©

Toutefois Amazon ECS rĂ©pond Ă  plusieurs problĂ©matiques, et en particulier: la gestion de cluster, l’orchestration de container, mais Ă©galement sur la capacitĂ© ĂȘtre intĂ©grĂ© et tirer parti fortement des autres building blocks qui constituent le coeur des services autour du compute. NĂ©anmoins, tout n’est pas complĂštement parfait, et certains sujets restent non adressĂ©s comme le service discovery. Gageons qu’AWS aura sĂ»rement de nouvelles rĂ©ponses Ă  apporter aux challenges prĂ©cĂ©demment listĂ©s.

La premiĂšre amĂ©lioration apportĂ©e par AWS Ă  leur service ECS est un nouveau moteur de placement. Ce qu’on peut dire, c’est qu’il Ă©tait un peu rudimentaire dans sa configuration. Visiblement, il est possible maintenant de s’appuyer sur un plus grand nombre de critĂšres pour placer les containers:

reinvent-8

 

En complĂ©ment, des d’Ă©vĂ©nements relatifs Ă  l’Ă©tat des instances seront bientĂŽt disponibles, tout comment des Ă©vĂ©nements associĂ©s au tĂąches. Ils auront pour objects de donner un meilleur contrĂŽles au dĂ©veloppeurs. Ces derniers auront d’ailleurs la possibilitĂ© de crĂ©er des schedulers custom, ou encore d’intĂ©grer des schedulers tiers pour rĂ©pondre Ă  des besoins spĂ©cifiques, en exploitant des schedulers autres que ceux fournis par dĂ©faut par AWS. Enfin, il sera possible de dĂ©velopper et tester localement ces schedulers custom.

Pour faciliter le travail des dĂ©veloppeurs, AWS met Ă  disposition via GitHub une collection de projets open source pour la gestion et l’orchestration des containers. Cette collection de projets s’appelle Blox. Comme point de dĂ©part, deux projets sont immĂ©diatement disponibles:

  • cluster-state-service, d’une part, qui donne la possibilitĂ© de consommer des stream d’Ă©vĂ©nements relatifs aux changement des containers et instances Amazon des cluster ECS.
  • daemon-scheduler, d’autre part, qui permet d’exĂ©cuter exactement une tĂąche par hĂŽte sur chaque noeud du cluster. Chose qui n’Ă©tait pas possible jusqu’Ă  prĂ©sent sans bidouiller avec les ports allouer pour forcer le dĂ©ploiement d’une instance de container uniquement sur des machines qui disposent d’un port donnĂ© libre.

L’outil ligne de commande ECS CLI est maintenant proposĂ© sous le chapeau du projet Blox, pour donner de la cohĂ©rence en proposant toutes les resources relatives Ă  ECS en un point d’accĂšs unique.

Serverless

AWS Lambda reprĂ©sente sĂ»rement l’un des assets majeurs d’AWS en 2016, son intĂ©gration avec diffĂ©rents services AWS ne fait que se renforcer avec le temps, comme le rĂ©sume ce slide:

 

reinvent-9

 

Il faut s’attendre Ă  de nombreuses nouveautĂ©s Ă  ce re:Invent en lien avec AWS Lambda. La premiĂšre annoncĂ©e, sans doute majeure, et qui fera plaisir aux fans du monde DotNet, est la capacitĂ© nouvelle de coder des Lambda avec C# ! Et bonne nouvelle, cette capacitĂ© est disponible dĂšs aujourd’hui. L’intĂ©gration avec C# se base sur .NET Core 1.0 release. Elle supporte les fonctions packagĂ©es et les DLL, ainsi que NuGet, et fin du fin, il est possible de dĂ©velopper et dĂ©ployer des Lambda C# depuis Visual Studio.

Comme aime Ă  le rappeler Werner Vogels, il n’y a pas uniquement le bĂ©tail, il y a tout le troupeau. Ainsi, le serverless n’est pas reprĂ©sentĂ© uniquement par AWS Lambda, c’est un Ă©co-systĂšme complet de services qu’AWS fournit pour le concrĂ©tiser:

  • Amazon Api Gateway
  • S3
  • DynamoDB
  • ElastiCache
  • Athena
  • SQS
  • SNS
  • SES
  • Kinesis
  • ElasticSearch
  • X-Ray, ou encore
  • CloudFront.

AWS Lambda doit d’ailleurs Ă©galement ĂȘtre vu comme un mĂ©canisme d’extension des services existants: C’est le « tissu connectant » des environnements AWS.

 

reinvent-10

 

Lambda est d’ailleurs intĂ©grĂ© sur des services que l’on n’attend pas forcement, tels que AWS Greengrass, AWS Snowball Edge, ou encore Alexa Skills Kit.

Plus Ă©tonnant encore, AWS lambda@Edge permet d’exĂ©cuter des fonctions sur les Edge locations de CloudFront. ConcrĂštement, cela dĂ©multiplie les zones de calcul disponibles au-delĂ  des rĂ©gions classiques.

La vĂ©ritable nouveautĂ© relative Ă  AWS Lambda, annoncĂ©e cette annĂ©e 2016, sera sĂ»rement toutefois, AWS Step Functions, dont l’objet est de rendre facile la coordination des composants d’applications distribuĂ©es et de microservices au travers l’utilisation de workflows visuels. Step Functions fournit une console graphique qui permet d’arranger et visualiser les composants constituant les applications comme une sĂ©rie d’Ă©tapes, rendant simple la construction et l’exĂ©cution d’applications multi-Ă©tapes.

 

reinvent-11

En regardant de plus prĂšs, il est possible de voir ce nouveau service comme une machine Ă  Ă©tats hautement scalable et disponible, permettant la crĂ©ation de workflows de traitements dont l’exĂ©cution peut ĂȘtre suivie visuellement, ou comme encore un orchestrateur de fonctions Lambda. Ce service permet concrĂštement d’imaginer de nouveaux cas d’utilisation de Lambda comme le prĂ©sente le slide suivant:

 reinvent-12

Mais Ă©galement de manipuler les Lambda d’une maniĂšre qu’il n’Ă©tait pas possible d’imaginer avant :

reinvent-13

SynthĂšse des 2 premiers jours

Il est temps de faire la synthĂšse de ces 2 premiers jours, et il est presque impossible de ne pas se dire qu’on n’a pas oubliĂ© de parler de quelque chose tant les nouveautĂ©s sont nombreuses. L’indigestion n’est pas loin, mais ce sont autant de nouveautĂ©s qui vont nous faciliter la crĂ©ation de services Ă  valeur ajoutĂ©e qui reprĂ©senteraient de vĂ©ritables challenges Ă  relever si ces nouveaux services n’existaient pas. On peut le dire ainsi: aussitĂŽt prĂ©sentĂ©s, aussitĂŽt indispensables ! AWS semble avoir visĂ© juste et risque de donner quelques cheveux blancs Ă  la concurrence.

Vous retrouverez sur ce slide la synthÚse des nouveautés des 2 jours de keynote :

reinvent-14

Bonne digestion à vous ! Si le Cloud vous passionne et AWS fait partie de votre boßte à outil du quotidien, venez échanger avec nous, nous recrutons des passionnées du développement !

* En parlant de « transformers », est-ce que le Snowball Truck se transforme en Optimus Prime ?

Catégories: Blog Société

Efficiently managing Google Drive files inside JIRA with nFeed

Le blog de Valiantys - mar, 12/06/2016 - 09:45

Adding files from different storage services into your JIRA issues can be quite an adventure: first you need to leave your current JIRA issue and connect to your file storage service, before finding and downloading your file and then uploading it back into the JIRA issue. And then when the file is modified, you must start ...

The post Efficiently managing Google Drive files inside JIRA with nFeed appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

Une migration vers ES6 et un pas de plus en Ă©coconception

Barre Verte ! - mar, 12/06/2016 - 00:00

Actuellement je travaille sur un site web en mode SaaS pour travailleurs indĂ©pendants et professions libĂ©rales. Comme le javascript n’était pas ma tasse de thĂ©, j’avais nĂ©gligĂ© cet aspect, en accumulant le minimum de code (backbone/semantic-ui) dans de petits fichiers qui commençaient Ă  grossir. Conscient de cette dette technique qui s’y accumulait, il y a une dixaine de jours je suis allĂ© aux Javascript Les 10 Doigts Dedans (ou JSLDD pour les intimes) afin de rencontrer des fĂ©rus du JS qui pourraient me faire aimer un peu mieux le JS et prendre soin de cet aspect incontournable du site.

L’objectif est double :

  • diminuer la dette technique : rationnaliser l’utilisation du JS dans le HTML, amĂ©liorer la testabilitĂ© du code JS, la lisibilitĂ© du code de production, s’ouvrir des portes d’amĂ©lioration du design du code (par exemple pouvoir intĂ©grer plus simplement des librairies comme riot.js)
  • diminuer la taille des pages, en minifiant les fichiers javascript du site (pour les librairies, j’utilisais dĂ©jĂ  les versions minifiĂ©es)

Et enfin, pouvoir apprécier cet écosystÚme du frontend ?

amélioration du javascript

J’ai binĂŽmĂ© avec Paul qui m’a montrĂ© comment faire pour mettre en oeuvre une stack minimale ES6. En tant qu’expert frontend il m’a conseillĂ© de mettre en place un build JS pour le code du front. Il m’a montrĂ© le gestionnaire de packets JS yarn, babel pour la transpilation en ES5, mocha pour le test runner, expect pour les assertions. Nous avons pu transformer un bout de code que j’avais amenĂ© et des tests unitaires relatifs.

EmballĂ© par le rĂ©sultat (vous pouvez voir l’historique des changements),

export class Node {
  constructor(name, data, children = undefined) {
    this.name = name;
    this.data = data;
    this.children = children;
  }

  is_dir() {
    return this.children !== undefined;
  };
}

export class FileSystemTree {
  constructor(values) {
    this.root = build_tree(values);
  }
}

function build_tree(values) {
  let root = new Node('', {id: 'root', filename: ''}, []);
  values.forEach(value => {
    let path_items = value.filename.replace(/^\//, '').split('/');
    let node = new Node(path_items[path_items.length - 1], value);
    mkdir_p(path_items, root).children.push(node);
  });
  return root;
}

function mkdir_p(path_items, node) {
  let path_item = path_items[0];
  let n = node.children.find(_node => {return _node.name == path_item ? _node: undefined});
  if (n === undefined) {
    path_items.pop();
    let current_node = node;
    path_items.forEach(dir => {
      let new_dir = new Node(dir, {filename: current_node.data.filename + '/' + dir}, []);
      current_node.children.push(new_dir);
      current_node = new_dir;
    });
    return current_node;
  } else {
    path_items.shift();
    return mkdir_p(path_items, n);
  }
}

j’ai modifiĂ© la hiĂ©rarchie de mon source pour sĂ©parer le code backend et code frontend. Puis j’ai repris tous les bouts de code javascript du site et les ai transformĂ©s pour qu’ils puissent passer Ă  la moulinette babel. MĂȘme si je n’ai pas mis en oeuvre immĂ©diatement toutes les possibilitĂ©s de syntaxe offertes par ES6 (classes, etc), les impacts Ă©taient assez importants.

Ce que j’ai appris :

  • c’est un refactoring d’architecture, et je n’aurais pas pu Ă©viter des rĂ©gressions sans les tests unitaires JS et les tests d’acceptance sĂ©lĂ©nium
  • l’ES6 amĂšne une bien meilleure claretĂ© mĂȘme si les changements ne sont pas si drastiques que ça, en Ă©vitant les niveaux ({ ... }) et les dĂ©finitions MyClass.prototype.blah = function() {...}. L’encapsulation avec les classes, des boucles plus claires avec la flĂšche =>, des variables au scope limitĂ© avec let my_var. Une gestion des modules qui ressemblerait presque Ă  du python, et plein d’autres choses encore
  • webpack rocks ; j’ai ajoutĂ© webpack pour pouvoir packager le code et le dĂ©ployer dans le site. Cela permet notamment de regrouper ses fichiers javascript et de diminuer le nombre de requĂȘtes HTTP
  • j’ai un build js et un build python mais ça fonctionne bien : les tests unitaires sont lancĂ©s en ligne de commande (avant c’était avec jasmine dans un navigateur). La sortie de webpack (les fichiers JS minifiĂ©s et regroupĂ©s par page) est copiĂ©e dans la partie statique du module web python
des amĂ©liorations pour l’utilisateur et pour l’empreinte Ă©cologique du site

J’ai voulu alors constater la diminution de la taille des pages. Je me suis que je pouvais exĂ©cuter les tests d’acceptance avant et aprĂšs refactoring, en mesurant la taille des pages avec tcpdump :

sudo tcpdump -v  -i eth0 port 443 | grep -e 'length [0-9]*)' |  
  sed 's/.*length \([0-9]*\))/\1/' |  awk '{sum+=$1;print sum,$1}'

Je lance les tests, et observe les résultats :

Avant refactoring :

30156494 203
17126 packets captured

AprĂšs babel/webpack :

33176994 52
16874 packets captured

WOT ?!!? On observe moins de packets mais une taille plus importante de 10% environ.

Je vais voir ce qui se passe avec un navigateur. Je supprime le cache, charge la page de login et regarde ce que me dit firefox :

  • 11 requĂȘtes, 1.4 Mo de transfĂ©rĂ© en 333ms avec :
  • login.html : 2.6 Ko
  • vendor.js : 733 Ko
  • login.js : 664 octets

Avec l’ancienne version :

  • 14 requĂȘtes, 1 Mo de transfĂ©rĂ© en 268ms avec :
  • login.html : 3.1 Ko
  • semantic.min.js : 269 Ko
  • jquery.min.js : 82.6 Ko

Dans vendor.js, il y a semantic.js, jQuery.js, moment.js. Avant, j’avais des imports javascript un peu partout dans mon HTML (sauf jquery/semantic qui Ă©taient dans le layout), c’était plus difficile Ă  maintenir, mais c’était optimisĂ© car je ne chargeais par exemple pickadate.js juste Ă  l’endroit oĂč j’avais des sĂ©lecteurs de date.

Une fois chargĂ©, vendor.js est cachĂ© mais lorsque j’exĂ©cute les tests d’acceptance, Ă  chaque feature, je relance un navigateur frais (pour l’isolation des tests). Chaque test ne passe pas forcĂ©ment sur toutes les pages. Dans ces cas, moment/pickadate sont chargĂ©s systĂ©matiquement, ce qui n’était pas le cas avant.

Je continue mon auscultation de différentes pages du site, et relÚve les tailles et temps de chargement :

tests manuels

Si on fait la somme des tailles, il y a un lĂ©ger avantage pour la version sans webpack/babel, mais si on exclut la premiĂšre requĂȘte, le refactoring reprend l’avantage.

Pour simuler une utilisation plus longue, un injecteur de tests de charge pourrait aider. J’essaye funkload, sans succĂšs car il charge les CSS et les images, mais pas le javascript. Par ailleurs, funkload trace le traffic rĂ©seau global mais pas la taille par page.

Je me reporte sur JMeter que j’avais dĂ©jĂ  utilisĂ© il y a dĂ©jĂ  quelque temps. Il faut dĂ©passer l’IHM java/swing assez moche, se replonger dans les termes un peu baroques (Groupes d’unitĂ©, Fragment d’élĂ©ment, rĂ©cepteur d’assertions
) pour construire un plan de test.

Config jmeter

Ne pas oublier de cliquer sur “rĂ©cupĂ©rer les ressources incluses” dans les requĂȘtes HTTP, puis d’ajouter un gestionnaire de cache HTTP pour qu’il se comporte comme un navigateur avec les dĂ©pendances Javascript/CSS/Images. Mais une fois configurĂ© il fait bien son boulot, et me permet de faire 100 itĂ©rations avec un seul utilisateur sur un scĂ©nario qui charge toutes les pages. Ce scĂ©nario pourra toujours me resservir pour faire quelques tests de charge sur le serveur, je n’aurai qu’à modifier le paramĂštre du nombre d’utilisateurs concurrents.

A présent les résultats sont bien différents :

Diagramme synthĂšse

On passe d’une taille de page moyenne de 12,14 Ko Ă  9,78 Ko, c’est Ă  dire qu’on gagne 20%, avec un code JS plus clair et mieux intĂ©grĂ© au HTML. Nous gagnons Ă©galement 7% de temps de chargement (sur un lien local entre 2 containers docker). Le jeu en valait la chandelle. En revanche, on peut voir que les rĂ©sultats en terme de gains de bande passante d’un tel refactoring dĂ©pendent beaucoup de l’usage qui est fait du site par les utilisateurs. L’avantage, lorsque le pas a Ă©tĂ© franchi, c’est qu’on peut modifier assez facilement la structuration des fichiers source Javascript avec Webpack, pour adapter l’architecture des pages en fonction des usages.

L’étape suivante sera l’utilisation de fichiers javasript avec un hash code, pour recharger uniquement les fichiers modifiĂ©s. Actuellement nous utilisons des chemins virtuels avec la version du site. Cela oblige les navigateurs de chaque utilisateur Ă  recharger toutes les resources (js/css/images) lorsque le site a Ă©voluĂ©. Ou encore la gestion des ressources CSS avec webpack.

PS : merci à ut7 pour l’organisation du JSLDD et Paul pour son binîmage instructif

Catégories: Blog Individuel

AWS re:Invent 2016 – Annonces de la 1ùre keynote

Comme chaque annĂ©e, la confĂ©rence AWS re:Invent se tient Ă  Las Vegas. C’est l’occasion pour Amazon Web Services d’annoncer les grandes nouveautĂ©s qui trusteront l’innovation autour de leurs services au cours des mois Ă  venir. Cette annĂ©e la grand-messe a lieu du 28 novembre au 2 dĂ©cembre, et autant le dire dĂšs le dĂ©part, l’agenda est chargĂ© ; faire le tour des nouveautĂ©s risque de s’annoncer corsĂ©.

Les annonces ont Ă©tĂ© Ă©grainĂ©es au cours des 2 keynotes, les 30 novembre, 1er dĂ©cembre. Le plus simple sera donc sĂ»rement de suivre l’ordre chronologique des journĂ©es pour les rĂ©sumer. Retenons notre souffle, et commençons avec la premiĂšre keynote du 30 novembre.

1500x500.jpeg

Keynote du 30 novembre

C’est Andy Jassy, CEO d’Amazon Web Services qui prĂ©sente cette premiĂšre keynote. Le ton est donnĂ© dĂšs le dĂ©part, puisqu’Andy Jassy annonce cette annĂ©e plus de 1.000 nouveautĂ©s en 2016. Rien de moins. OK, bien entendu, chaque nouveautĂ© n’est pas forcĂ©ment majeure, mais chacune reprĂ©sente une Ă©volution, un enrichissement des services mis Ă  disposition. D’autre part, Andy Jassy annonce que l’activitĂ© Web Services pourrait bien devenir sous peu l’activitĂ© principale de la sociĂ©tĂ© en passant devant la vente de produit en ligne ! Les ambitions sont bien lĂ , comme nous le verrons avec le passage en revue des nouveaux services. Avant de commencer la prĂ©sentation des services, n’oublions pas de rappeler qu’en 2017 AWS prĂ©voit d’ouvrir la rĂ©gion France, qui risque bien d’ĂȘtre un game changer pour de nombreuses entreprises françaises.

Ne tardons plus et démarrons avec les annonces principales de la premiÚre keynote.

Elastic Compute: Nouvelles familles et Ă©volutions Famille T2

De nombreuses familles d’Elastic Compute Ă©voluent pour proposer de nouvelles capacitĂ©s, et tout d’abord la famille la plus accessible, soit la T2. Deux nouveaux types d’instances arrivent: T2.xlarge et T2.2xlarge. Elle reposent toutes deux comme le reste des instances de la famille T2 sur le principe de capacitĂ© CPU burstable. Ces 2 nouveaux types proposent par rapport au type T2.large, le mĂȘme nombre de cƓurs, soit 2 cƓurs, mais surtout plus de mĂ©moire, respectivement 16 Go et 32 Go. Vous pourrez en particulier apprĂ©cier ces nouveaux types d’instances si vous ĂȘtes gourmand en mĂ©moire, et que vous avez des besoins CPU limitĂ©s tout en ayant la capacitĂ© de burster.

Famille C5, I3, R4

La famille C5 reprĂ©sente la famille orientĂ©e usage CPU. AprĂšs les gĂ©nĂ©rations C3 et C4, la gĂ©nĂ©ration C5 vous propose des CPU reposant non plus sur l’architecture Intel Haswell, mais sur Skylake. Cette gĂ©nĂ©ration permet de doubler le nombre de vCPU disponibles par CPU, tripler les capacitĂ©s rĂ©seau et plus que doubler la mĂ©moire utilisable.

Les familles I3 (Support du NVMe) et R4 dédiées respectivement aux workloads orientés stockage et mémoire sont également annoncées, avec également des capacités largement améliorées.

N’oublions pas toutefois que ces resources par CPU, bien que largement amĂ©liorĂ©es sont re-dĂ©coupĂ©es pour ĂȘtre allouĂ©es par quotas aux clients d’AWS. Le gain n’est donc pas forcement palpable aussi directement qu’on peut l’imaginer.

Elastic GPU

Grande nouveautĂ©, les instances EC2 auront bientĂŽt la possibilitĂ© de se voir attacher de petites capacitĂ©s de traitement GPU, comme on a la capacitĂ© d’ajouter des interfaces rĂ©seau aux VM. Ce type de capacitĂ©s restent toutefois limitĂ©s Ă  certains usages, mais pourra sĂ»rement ravir les publics demandeurs de telles possibilitĂ©s. Pour en savoir plus sur ces nouvelles capacitĂ©s GPU des instances EC2, vous pouvez lire l’article du blog AWS prĂ©sentant la nouveautĂ©.

Amazon Lightsail

Les oreilles de certains hosteurs ont dĂ» siffler au moment de cette annonce d’Amazon Web Services. En effet, AWS s’attaque au marchĂ© des VPS, et propose un nouveau service autour du Compute qui a pour objectif de permettre la crĂ©ation et la gestion des instances de type VPS Ă  des prix bien plus raisonnables que des VM classiques. Le slogan est : « VPS made easy on AWS ».

Il est ainsi possible de créer facilement des VPS pour un prix commençant à 5 $ pour 1 CPU & 512 Mo de RAM. Ce tarif agressif est de bon augure pour les petits porte-monnaie et surtout vient titiller les tarifs de la concurrence qui ne manquera pas de riposter.

L’offre Lightsail rĂ©pond particuliĂšrement bien au besoin de crĂ©er facilement et rapidement des serveurs pour hĂ©berger des moteurs de blog comme WordPress ou encore Drupal.

Vous pouvez retrouver sur le blog d’AWS un article dĂ©taillant les possibilitĂ©s d’AWS Lightsail.

Famille F1

AprĂšs les Elastic GPU et Amazon Lightsail, la famille F1 est sĂ»rement l’autre nouveautĂ© majeure relative Ă  EC2. Cette famille apporte en effet l’accĂ©lĂ©ration matĂ©rielle Ă  base de FPGA (Customizable Field Programmable Gate Arrays). Cette nouvelle famille rĂ©pond particuliĂšrement aux besoins de type CPU intensive permettant de crĂ©er des traitements optimisĂ©s non plus uniquement au niveau software, mais via une programmation matĂ©rielle qui va permettre d’obtenir des capacitĂ©s optimisĂ©es pour vos traitements. Par exemple, dans les domaines spĂ©cialisĂ©s comme l’analyse gĂ©nomique ou sismique, il est possible d’obtenir des traitements 30 fois plus rapides.

SynthĂšse

La synthĂšse des nouveautĂ©s peut se retrouver en dĂ©tail dans un article du blog d’AWS.

Amazon X-Ray

Avec AWS X-Ray propose de donner la capacitĂ© d’analyser et de dĂ©bugger les workloads de production qu’ils soient simples ou distribuĂ©s, tels que des programmes bĂątis sur des architectures micro-services. AWS X-Ray agrĂšge des donnĂ©es de diffĂ©rents services et resources qui composent vos applications, il est capable de restituer une vue bout en bout des performances de l’application. Cela a pour but in fine de faciliter le tracking d’anomalies en production, mais Ă©galement de mieux comprendre oĂč se trouvent les goulets d’Ă©tranglement de vos applications et comment les rĂ©soudre. X-Ray fonctionne dĂ©jĂ  avec EC2, ECS et Beanstalk, et fonctionnera bientĂŽt avec AWS Lambda. il est particuliĂšrement apprĂ©ciable de savoir que les traitements sont traçables sur plusieurs comptes, rĂ©gions ou encore zones de disponibilitĂ©.

Amazon X-Ray

 

Services d’intelligence artificielle

Visiblement chez Amazon Web Services, tout comme chez ses concurrents, l’IA est un sujet sĂ©rieux, puisqu’on apprend que des milliers de salariĂ©s travaillent Ă  dĂ©velopper de nouveaux services et fonctionnalitĂ©s autour de l’intelligence artificielle et du Deep Learning. Echo et Alexa sont deux exemples connus de mise en Ɠuvre de l’intelligence artificielle chez Amazon.

Amazon Rekognition

Amazon Rekognition a pour objectif de fournir de la reconnaissance d’images Ă  tout un chacun sans ĂȘtre un expert du Machine Learning ou encore de la reconnaissance d’images, et ceci basĂ© sur le Deep Learning.

Le service est capable d’analyser les images et de les classifier par catĂ©gorie (ExtĂ©rieur, en journĂ©e, conduisant une voiture…) tout comme reconnaĂźtre les caractĂ©ristiques faciales (par exemple: Femme, souriante, portant des lunettes de soleil).

Le service permet de batcher les traitements, les analyses sont rĂ©alisĂ©es en temps rĂ©el, avec une capacitĂ© de reconnaissance qui s’amĂ©liore continuellement, tout en proposant des tarifs compĂ©titifs. Le service est disponible dĂšs aujourd’hui.

aws-rekognition

Amazon Polly

Le service Amazon Polly est dĂ©diĂ© Ă  la transformation de texte en langage du quotidien. Le service entiĂšrement managĂ© est capable de retourner un stream au format MP3. Les rĂ©sultat sont re-jouables autant de fois qu’on le souhaite. Le service propose pas moins de 47 voix et 24 langages. De nombreux cas d’utilisation sont prĂ©sentĂ©s sur la page d’accueil du service. Il est par exemple possible de convertir des articles en MP3, et donc transformer automatiquement des articles sous forme de podcasts :

Amazon PollyAmazon Polly Amazon Lex

Amazon Lex est la technologie prĂ©sente dans Alexa fournie sous forme de service intĂ©grable Ă  notre programme. Il permet la comprĂ©hension de langage naturel (Natural Language Understanding / NLU), tout comme la reconnaissance automatique de la parole (Automatic Speech Recognition / ASR). Ces deux sujets se rattachent au sujet plus gĂ©nĂ©ral du traitement naturel du langage (Natural Language Processing) au sein du domaine de l’intelligence artificielle.

Avec Lex, nous avons la possibilitĂ© entre autre chose de dĂ©clencher des traitements AWS Lambda qui permettent donc de rĂ©agir Ă  de la voix via le lancement de traitements qui peuvent tirer partie de cette reconnaissance. Ces deux technologies couplĂ©es permettent de rĂ©aliser des interfaces conversationnelles de type Bot avec un minimum d’effort et de complexitĂ©.

Un article de Jeff Barr, l’incontournable Ă©vangĂ©liste en chef d’AWS, permet de mieux dĂ©couvrir les capacitĂ©s du service.

amazon-lex

Amazon Athena

Le service Amazon Athena pourrait bien ĂȘtre le premier rĂ©el game changer avec effet immĂ©diat annoncĂ© cette premiĂšre journĂ©e. Il paraĂźt tellement Ă©vident et nĂ©cessaire qu’on se demandera rapidement comment on a pu s’en passer. Il permet ni plus ni moins de requĂȘter vos donnĂ©es stockĂ©es dans S3 avec du SQL standard. Ce nouveau service s’inscrit dans le principe de pouvoir interroger toutes vos donnĂ©es sur AWS sans avoir Ă  mettre en Ɠuvre des traitements complexes pour y arriver. Le but AWS ici est de simplifier l’exploitation de vos donnĂ©es, et Ă©viter qu’elles restent dormantes faute de services simples Ă  utiliser pour les exploiter.

Ici Ă©galement, nous avons le droit Ă  un slogan pour expliciter le principe: « Redshift, EMR & Athena: The right tool for the right job ». Athena est facturĂ© Ă  la requĂȘte, et coĂ»t 5 $ par Tera bytes scannĂ©s pour les requĂȘtes executĂ©es. Ainsi si nous souhaitons compter dans nos logs stockĂ©s sur S3 le nombre de rĂ©ponses par code HTTP, il sera possible de passer une requĂȘte du type :

select backgroundresponsecode, count(*) from elb_logs group by backgroundresponsecode;

Facile, n’est-ce pas ? Qu’aurait-on du faire sans cette nouvelle capacitĂ©, dĂ©jĂ  indispensable ?

Amazon Athena

Amazon Aurora Patience ! Les annonces de la premiĂšre journĂ©e ne sont pas encore terminĂ©es. Amazon Aurora, pour ceux qui ne connaissent pas, est la version optimisĂ©e de MySQL pour AWS. Cette version un peu spĂ©ciale de MySQL propose beaucoup de spĂ©cificitĂ©s qui en font une option de choix lorsqu’on souhaite faire de la base de donnĂ©es relationnelle chez AWS, et encore plus lorsqu’on souhaite faire du MySQL ! Entre autres choses, MySQL Aurora scale plus efficacement qu’une simple instance RDS MySQL de part sa conception, mais il est par exemple possible d’avoir plus de rĂ©plicas Ă  disposition. Difficile de faire le tour des avantages en quelques mots, mais sachez que la demande numĂ©ro 1 des clients d’AWS est d’adapter les mĂ©caniques proposĂ©es par Aurora pour PostgreSQL. Sachez, qu’AWS a Ă©coutĂ© les demandes de ses clients, et va dĂ©sormais fournir une version d’Aurora pour PostgreSQL avec la capacitĂ© de migrer simplement depuis la console une instance classique PostgreSQL vers une instance Aurora. Tout est dĂ©taillĂ© sur le blog technique d’AWS. AWS Greengrass

AWS Greengrass est une nouveautĂ© d’Amazon Web Services qui permet d’embarquer AWS Lambda (et d’autres services) sur des devices connectĂ©s. Qu’est-ce que cela veut dire ? En substance, il est possible d’installer Greengrass sur des device connectĂ©s ou bien d’avoir Ă  disposition des matĂ©riels directement compatibles (prĂ©-installĂ©s avec Greengrass) qui seront en mesure de faire tourner diffĂ©rents services (compute, communications sĂ©curisĂ©es, cache, ou encore messaging) localement sur le device, ce qui permet d’avoir les mĂȘmes modĂšles de programmation sur le device que sur le Cloud.

Le service peut paraĂźtre obscur au commun des mortels, mais pour les fendus d’IoT, vous pourrez trouver plus de renseignements sur la page d’accueil du service.

Une version amĂ©liorĂ©e du bouton AWS IoT Button est d’ailleurs disponible en prĂ©-commande (Disponible dĂ©but fĂ©vrier 2017). Toutefois, ne rĂȘvons pas trop, la v1 n’a jamais Ă©tĂ© disponible en France, alors pourquoi espĂ©rer que cela change !

En vrac AWS Snowball

AWS propose de passer Ă  l’Ă©tape supĂ©rieure avec Snowball en donnant la capacitĂ© de migrer par valises 100 To de donnĂ©es. Mais si cela ne vous contente pas, vous pourrez migrer Ă©galement par Exabytes. Vous vous doutez que 1 Exabyte (1 000 000 tĂ©raoctets, ou encore 1 000 pĂ©taoctets ??!) de donnĂ©es ne tient pas dans une valise, ni dans 10. Qu’Ă  cela ne tienne, AWS a la solution, ils vous envoient un camion ! Oui, un gros truck amĂ©ricain avec une remorque de 15 mĂštres de long ! Et en bonus, il vous faudra 10 jours pour le remplir de donnĂ©es Ă  la vitesse d’1 Terabyte par seconde ! Le transport d’un tel camion rempli de donnĂ©es coĂ»te dĂ©jĂ  250.000$. Que penser de la facture globale de clients prĂȘts Ă  utiliser ce service !

AWS SnowballAWS Snowball Certifications

Amazon Web Services propose de nouvelles certifications (en beta, les plus chanceux pouvaient la passer Ă  l’Ă©vĂ©nement re-Invent). Vous pourrez ainsi valoriser votre expertise dans de nouveaux domaines :

  • AWS Certified Advanced Networking
  • AWS Certified Security
  • AWS Certified Big Data
Programmes de compétences

Certains besoins correspondent sĂ»rement Ă  une telle demande qu’AWS a choisi de proposer des programmes de compĂ©tences dĂ©diĂ©s Ă  certains mĂ©tiers. De nouveaux programmes de compĂ©tences sont disponibles :

Programmes APN

Pourquoi s’arrĂȘter en si bon chemin ? AWS propose Ă©galement de nouveaux programmes partenaires autour du Service Delivery, Secteur Public, et du Cloud VMWare (Plusieurs nouveautĂ©s annoncĂ©es au re:Invent tournent autour de VMWare).

Conclusion de la premiÚre journée

On a beau vouloir faire une synthĂšse rapide des nouveautĂ©s, les paragraphes s’accumulent, et il est long de faire le tour ne serait-ce que des annonces, et cela seulement aprĂšs la premiĂšre journĂ©e. Vous retrouverez bientĂŽt les annonces des nouveautĂ©s de la seconde keynote dans un nouvel article qui arrivera Ă  la suite de celui-ci. Si vous ĂȘtes arrivĂ© en bas de cet article c’est que la plateforme AWS vous intĂ©resse sĂ»rement, sachez que Xebia recrute des passionnĂ©(e)s, ne soyez pas timide et venez en parler avec nous ! Nos clients sont friands de technologies Cloud, et nos projets Xebia Studio reposent souvent sur les services d’AWS !

Vous pouvez revoir la Keynote de la premiĂšre jour sur YouTube Ă  l’adresse suivante: https://www.youtube.com/watch?v=8RrbUyw9uSg

Catégories: Blog Société

RĂšgles de conversation pour un chatbot

Les chatbots font progressivement partie de notre quotidien dans nos applications de messagerie instantanĂ©e prĂ©fĂ©rĂ©es (Facebook Messenger, Slack, WeChat, Skype
). Ils nous apportent toutes sortes de services, de la mĂ©tĂ©o à la rĂ©servation d’avion en passant par les commandes de fleurs. Mais pour qu’ils proposent une expĂ©rience agrĂ©able et pertinente, il faut suivre des rĂšgles de design spĂ©cifiques.

Voici quelques rĂšgles Ă  respecter pour Ă©viter que votre chatbot ne reste qu’une expĂ©rience Ă©phĂ©mĂšre et que vous puissiez transformer ce nouveau moyen de communication en un canal fortement engageant.

Les interfaces conversationnelles

Les interfaces conversationnelles ou CUI (Conversational User Interface) sont une forme d’interface se basant sur des dialogues entre l’Homme et la Machine plutĂŽt que sur un rendu graphique (fenĂȘtres, menus, champs, pointeur, 
). Un dialogue est un Ă©change d’informations structurĂ©es incluant plusieurs aller-retours entre les participants.

Ces interfaces permettent au systĂšme de comprendre ce que souhaite faire l’utilisateur qui s’exprimera avec un langage dĂ©fini (langage naturel, iconographie, symboles…). Dans le cas d’une conversation textuelle, cela implique que les chatbots devront ĂȘtre capables d’interprĂ©ter des formulations diffĂ©rentes pour une mĂȘme intention.

Par exemple, “Quel temps fait-il aujourd’hui ?”, “Quelle est la mĂ©tĂ©o”, “Est-ce qu’il fait beau ?” seront compris comme la volontĂ© de l’utilisateur de connaĂźtre la mĂ©tĂ©o.

Un des avantages de ce type d’interface est qu’il n’est plus nĂ©cessaire Ă  l’utilisateur d’apprendre Ă  utiliser un logiciel mais il lui suffit de demander simplement ce qu’il souhaite faire.

Elles peuvent ĂȘtre soit textuelles soit vocales. Cet article s’applique Ă  ces deux types d’agents conversationnels.

Que demandent les utilisateurs aux chatbots ?

MĂȘme si les chatbots ont vocation Ă  rĂ©pondre Ă  des besoins bien prĂ©cis, les utilisateurs aiment bien “parler” avec eux.  Voici ce que demandent le plus souvent les utilisateurs Ă  un chatbot.

“Bonjour”

Comme il est naturel de dire bonjour à une personne, les utilisateurs commencent souvent leur conversation en saluant le chatbot. Ajouter une réponse appropriée permet donc déjà de bien démarrer la conversation et créer un premier lien émotionnel.

“Aide”

Les chatbots Ă©tant un nouveau type d’interface, il est normal que les utilisateurs souhaitent savoir quelles sont les possibilitĂ©s de leur interlocuteur. C’est alors un bon moyen de (re)prĂ©senter ce que le chatbot sait faire et sa valeur ajoutĂ©e.

“Qui es-tu ?”

Bien qu’il soit recommandĂ© au chatbot de se prĂ©senter dĂšs le dĂ©but de la conversation et d’expliquer ce Ă  quoi il sait rĂ©pondre, les utilisateurs aiment apprendre qui est leur interlocuteur. De mĂȘme, si le chatbot sait rĂ©pondre Ă  des questions comme “comment tu t’appelles ?”,  “es-tu rĂ©el ?”, “es-tu un bot ?”, “es-tu humain ?”, cela renforcera la relation de confiance avec l’utilisateur.

Quelques rĂšgles Ă  suivre pour concevoir un chatbot Ne pas mentir aux utilisateurs

MĂȘme si les chatbots ne rĂ©ussissent pas encore Ă  se faire passer pour des humains, mieux vaut qu’ils disent spontanĂ©ment ce qu’ils sont Ă  l’utilisateur, par correction pour celui-ci, qui peut lors des premiers mots avoir l’impression de parler Ă  un humain.

Humaniser votre chatbot

Une fois le point prĂ©cĂ©dent Ă©clairci, il est souhaitable de travailler la façon dont le chatbot “parle” pour qu’il ne “sonne” pas trop robotique. En effet, personne n’aime parler Ă  des serveurs vocaux froids et impersonnels. Les formulations sont Ă  adapter Ă  la cible Ă  laquelle le chatbot s’adresse afin qu’il puisse susciter de l’émotion et donc inciter Ă  continuer la conversation.

Se présenter

Comme Ă©voquĂ© prĂ©cĂ©demment, il est recommandĂ© que le chatbot se prĂ©sente dĂšs le dĂ©but de la conversation. Lui donner un nom permet dĂ©jĂ  de crĂ©er une premiĂšre accroche. Ensuite, c’est l’occasion d’expliquer ce qu’il sait faire et ce qu’il peut apporter comme informations.

présentation chatbot

Pas trop bavard

Inversement, il ne faut pas non plus que le chatbot soit trop verbeux et que ses rĂ©ponses soient des tirades Ă  n’en plus finir. Un chatbot est d’abord lĂ  pour rĂ©pondre Ă  un besoin ou des questions. Les utilisateurs souhaitent avoir une rĂ©ponse rapide et prĂ©cise.

Expliquer qu’une rĂ©ponse est attendue

Il n’est pas suffisant que le chatbot ne prĂ©sente que les options disponibles. Pour s’assurer que l’utilisateur donne un rĂ©ponse, le chatbot doit explicitement lui demander de faire un choix.

Ne pas prĂ©sumer que l’utilisateur sait ce qu’il doit faire

Les CUI sont nouveaux pour les utilisateurs, ils n’ont pas encore l’habitude d’en rencontrer. Il est donc nĂ©cessaire au chatbot de guider la conversation en indiquant quelles options sont disponibles.

Ne pas toujours demander de confirmation

Pour ne pas ajouter trop de lourdeur lors de la conversation, il n’est pas nĂ©cessaire que le chatbot demande toujours une confirmation. Mais il est important de demander une validation dans les cas suivants :

  • actions qui ont une portĂ©e publique. Ex : publication sur un rĂ©seau social
  • actions qui affectent une autre personne. Ex : envoi d’un message Ă  quelqu’un
  • actions qui impliquent une transaction bancaire. Ex : achat
Obtenir une information Ă  la fois

Il est trĂšs probable que l’utilisateur ne donne pas tous les Ă©lĂ©ments nĂ©cessaires pour une Ă©tape d’une conversation ou que celle-ci ne puisse pas ĂȘtre dĂ©duite du contexte courant. Le chatbot doit alors demander les informations manquantes une par une et non pas toutes en mĂȘme temps.

GĂ©rer les impasses

Un chatbot n’est jamais capable de rĂ©pondre Ă  tout. MĂȘme si vous arrivez Ă  concevoir une conversation fluide, il arrivera toujours un moment oĂč l’utilisateur se retrouvera dans une impasse.

Il est aussi frĂ©quent que les utilisateurs posent intentionnellement des questions hors du pĂ©rimĂštre du chatbot ou essaient de le piĂ©ger. RĂ©pondre simplement par une phrase trop gĂ©nĂ©rique comme “DĂ©solĂ©, je ne comprends pas” n’apporte ni de rĂ©ponse ni d’alternative. Le risque est alors de voir se terminer la conversation. Il faut que le chatbot aide l’utilisateur Ă  prĂ©ciser sa question, lui propose une alternative ou lui explique ses domaines de compĂ©tences.

Commencer simple

Contrairement Ă  une interface graphique, les chatbots laissent l’utilisateur devant un fil de conversation, porte d’entrĂ©e Ă  toutes les fonctionnalitĂ©s. Il est alors tentant d’en dĂ©velopper une multitude, mais c’est une erreur. Il est important que le chatbot sache rĂ©pondre efficacement Ă  quelques questions dans un domaine prĂ©cis puis d’élargir ses possibilitĂ©s une fois que les utilisateurs commencent Ă  vouloir d’autres informations.

Rien ne vaut une image

Bien que l’interface de communication avec un chatbot soit textuelle, les applications de messagerie peuvent aussi afficher des images et autres composants graphiques beaucoup plus parlants que du texte. Parfois, au lieu d’essayer de dĂ©crire un objet, il vaut mieux afficher une photo.

image pour un chatbot

Les Ă©moticĂŽnes

De mĂȘme que les images vĂ©hiculent plus facilement certains types d’information que des paragraphes descriptifs, les Ă©moticĂŽnes sont le moyen le plus simple de transmettre des Ă©motions.

En comprenant et rĂ©pondant Ă  des Ă©moticĂŽnes, les chatbots prennent soudainement plus de vie et crĂ©ent plus d’empathie avec les utilisateurs.

Il est nĂ©anmoins nĂ©cessaire de ne pas non plus en abuser et gĂ©rer leur encodage (selon les plateformes, la chaĂźne de caractĂšres sous-jacente, n’est pas la mĂȘme).

emoticone pour un chatbot

Les boutons

Les applications de messagerie peuvent afficher des boutons correspondant Ă  des rĂ©ponses prĂ©dĂ©finies. Cela a l’avantage de guider la conversation et de s’assurer que l’utilisateur reste dans le flow de la conversation et le scope du chatbot.

Il reste tout de mĂȘme possible Ă  l’utilisateur de s’exprimer librement pour changer de sujet.

bouton pour un chatbot

Les sliders

Encore plus avancés, les sliders permettent aux chatbots de proposer plusieurs liens vers des liens ou articles.

sliders pour un chatbot

GĂ©rer le contexte

Afin de ne pas re-demander des informations qui ont déjà été évoquées précédemment, il est important que le chatbot mémorise des réponses ou des éléments de contexte lors de la conversation.

Rendre la main Ă  un vrai humain

Si la demande est trop complexe pour le chatbot, il ne faut hésiter à faire appel à un humain qui prendra le relais.

Conclusion

Pour rendre une conversation fluide et crĂ©er une adoption, une importante phase de design (CUI) doit ĂȘtre rĂ©alisĂ©e.

La maniùre dont le chatbot communique influera sur la confiance que voudra lui accorder l’utilisateur.

Dans le futur, les chatbots devront avoir une “mĂ©moire” long terme, capable de se souvenir d’échanges passĂ©s, de la mĂȘme maniĂšre qu’en discutant avec un ami, nous faisons rĂ©fĂ©rence Ă  des souvenirs communs.

L’analyse du niveau de langage et la capacitĂ© de rĂ©pondre sur le mĂȘme ton que l’utilisateur permettra une plus forte adhĂ©sion quel que soit le public utilisateur.

Combien de fois nous sommes-nous retrouvĂ©s en colĂšre face Ă  une boĂźte vocale ne prĂ©sentant pas l’option que nous recherchons ou face Ă  une FAQ ne nous donnant pas la rĂ©ponse attendue ? La frustration gĂ©nĂ©rĂ©e voire l’énervement ne faisant ni chaud ni froid aux machines, nous finissons presque toujours par baisser les bras devant l’incomprĂ©hension de la machine. Mais lorsque l’intelligence artificielle sera capable d’interprĂ©ter nos sentiments et de les prendre en considĂ©ration dans ses rĂ©ponses, nous ne serons plus simplement devant une machine, mais dans une relation engageante et durable.

Articles suggested :

  1. Les chatbots
  2. Chronique de la réalité virtuelle: quels usages en 2016 ?
  3. Améliorer sa productivité avec les expériences immersives

Catégories: Blog Société

#PortraitDeCDO – Rodolphe Roux – Wiko

#PortraitDeCDO – Rodolph Roux – Wiko

DĂ©couvrez pour ce deuxiĂšme #PortraitDeCDO, aprĂšs celui de Delphine Asseraf – Chief Digital Officer d’Allianz France, le portrait de Rodolphe Roux – Chief Digital Officer de Wiko. 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.

rodolphe roux

 

En une phrase, comment définiriez-vous la notion de transformation digitale ?
La transformation digitale c’est un gros mot, que j’utilise quand je ne veux pas rentrer dans le dĂ©tail de ce que je fais. Mais en une phrase ça donne :

Le monde Ă©volue Ă  une vitesse incroyable, les usages changent, les attentes Ă©voluent, les entreprises, les Ă©tats, les administrations doivent s’adapter mais ce n’est pas un sujet digital, c’est juste la vraie vie. Pour moi c’est la capacitĂ© des organisations Ă  muer et Ă  construire des produits, des services dans l’ùre digitale.

Comment décririez-vous votre rÎle de CDO ?
Ma principale mission est de crĂ©er et de piloter la stratĂ©gie de Wiko dans l’ùre digitale.

Mon rĂŽle chez Wiko est d’infuser dans l’ensemble des services de l’innovation tant au niveau des projets clients que des relations humaines Ă  l’intĂ©rieur.

Quelles difficultés rencontrez-vous au quotidien ?
La rĂ©silience fait partie du job, c’est comme un package inclus dans le mĂ©tier de CDO. Mais la principale difficultĂ© que je rencontre tourne autour de la notion de normalitĂ©. Souvent on me dit que je ne suis pas normal alors que fondamentalement je pense que ce sont les autres qui ne le sont pas.

Pensez-vous qu’il faille ĂȘtre technophile pour exercer le mĂ©tier de CDO ?
Quel mĂ©tier aujourd’hui ne demande pas d’ĂȘtre technophile ? La technologie est devenue un Ă©lĂ©ment de base de notre monde. Tout le monde doit l’intĂ©grer, vivre avec et accompagner la vulgarisation au profit des usages et des usages clients.

Pensez-vous que CDO est un mĂ©tier d’avenir ?
J’ai bien peur que le CDO soit Ă©ternel contrairement Ă  ce que certains pensent.

  1. les organisations hiĂ©rarchiques sont remises en cause. L’ownership digital a de l’avenir et donc il faudra garder un porte-parole.
  2. le digital est structurant pour une entreprise et l’enjeu des entreprises c’est surtout de fidĂ©liser des profils qui portent des projets stratĂ©giques.
  3. le CDO ne porte pas que des projets techniques, il porte surtout des projets de nouveaux business model éternels car adaptés et ancrés dans les usages.
  4. pour finir je pense que c’est un trĂšs mauvais message que de penser que c’est un poste Ă©phĂ©mĂšre car ça donne la sensation que c’est superflu or on parle de fondamentaux.

Quelle est pour vous la prochaine innovation qui risque de chambouler votre secteur d’activitĂ© ?
Ma principale innovation est live depuis quelques jours, c’est la Wiko Experience. Un projet d’entreprise qui nous amĂšne Ă  crĂ©er un tĂ©lĂ©phone qui rapporte de l’argent. Mieux une marque de tĂ©lĂ©phone qui propose Ă  ses clients de transformer leurs usages mobiles en une source de revenue. Elle est pas belle la vie ?

Quels sont les enjeux de digitalisation de votre entreprise à l’heure actuelle ?
Les enjeux de Wiko, c’est de croitre vite et bien. Le digital va aider Ă  cela en proposant des nouvelles opportunitĂ©s, des nouveaux marchĂ©s, de saisir des nouveaux usages et une nouvelle relation avec nos clients.

Citez-moi une marque/entreprise qui, pour vous, a clairement réussi à adresser les enjeux du digital ?
Tesla, Uber, Google, Redbull, Facebook, Blablacar, Airbnb, et bientĂŽt Wiko ;-)

Sans contrainte, vous avez la possibilité de commencer 3 projets de transformation dans votre entreprise : quels seraient-ils ?
Ceux que j’ai lancĂ©s chez Wiko et sans langue de bois.

  1. Le lancement d’une plateforme e-commerce Ă  dĂ©ployer dans nos 30 marchĂ©s
  2. La crĂ©ation d’une expĂ©rience de marque vraiment Game changer : un tĂ©lĂ©phone qui n’est plus un coĂ»t mais un tĂ©lĂ©phone qui vous rapporte de l’argent.
  3. Un fond d’investissement pour aider des startups Ă  accĂ©lĂ©rer leur dĂ©veloppement au profit de nos clients.

Quel projet de transformation vous semble le plus risqué et pourquoi ? Celui qui apporterait le plus de valeur et pourquoi ?
L’échec dans le digital est une forme de succĂšs, le risque ce n’est pas de se tromper c’est de ne rien faire. Je ne vois pas de projets plus risquĂ©s que d’autres.

Quel est l’impact de la transformation sur la culture et l’organisation de votre entreprise ?
Les principaux impacts de la transformation d’entreprise sont culturels, d’ailleurs ce sont les freins majeurs que rencontrent un CDO. Bouger la culture d’une entreprise c’est le sujet le plus complexe et en mĂȘme temps le plus passionnant.

Demain, qu’est-ce qui vous fera dire que votre entreprise a rĂ©ussi sa transformation ?
Si l’entreprise attend ses innovations comme un cadeau, si l’entreprise fait Ă©merger ses talents, si l’entreprise rĂ©ussit toujours Ă  valoriser l’audace et l’entreprise en sort grandit Ă©conomiquement et culturellement.

Quel livre vous a récemment le plus influencé ?
« The Tipping Point » est le livre que je cite rĂ©guliĂšrement, il fait l’apologie des petites choses qui peuvent faire basculer le monde.

Twitter : https://twitter.com/RodolpheRoux
LinkedIn : https://fr.linkedin.com/in/chiefdigitalofficer/en
Site Internet : https://fr.wikomobile.com

#PortraitDeCDO – Rodolphe Roux – Wiko from OCTO Technology

Retrouvez les derniers #PortraitDeCDO

#PortraitDeCDO – Delphine Asseraf – Allianz France from OCTO Technology

Catégories: Blog Société

ScalaIO 2016

Les 27 et 28 octobre 2016 a eu lieu la 3e édition de scala.io à Lyon. L’absence de l’Ă©vĂ©nement l’annĂ©e derniĂšre n’a fait qu’augmenter nos attentes ! Il y a eu des confĂ©rences pour tous les niveaux. On vous prĂ©sente nos coups de cƓur.

Six years of Scala and counting – Manuel Bernhardt

Scala-io

Manuel Bernhardt est un dĂ©veloppeur Scala senior, formateur certifiĂ© Lightbend pour Scala et Akka et l’auteur du livre Reactive web applications. Cette confĂ©rence est une prise de recul sur l’apprentissage et l’utilisation de Scala.

D’aprĂšs Manuel Bernhardt, l’intĂ©rĂȘt et l’adoption de Scala sont grandissants. Par exemple, le cours Coursera Functional Programming Principles in Scala  – donnĂ© par Martin Odersky – a connu un nombre de participants et un taux de complĂ©tion trĂšs Ă©levĂ©e. De mĂȘme, certaines universitĂ©s choisissent maintenant Scala en tant que langage d’initiation Ă  la programmation. Les opportunitĂ©s de partage autour de Scala se multiplient aussi au travers des confĂ©rences et de meetups tel que le Scala user group. Manuel nous prĂ©sente aussi ses fonctionnalitĂ©s favorites de Scala qui sont les typeclasses, les case classes et bien Ă©videmment les fonctions.

L’utilisation de Scala au quotidien est diffĂ©rente de Java. Par exemple, les NullPointerException font partie du passĂ© car null est absent de la bibliothĂšque standard et son utilisation, mĂȘme si elle est possible, est forcĂ©ment intentionnelle. Autre point, qui rejoint le prĂ©cĂ©dent, Scala permet de façon gĂ©nĂ©rale une sĂ»retĂ© d’exĂ©cution plus grande que Java car le nombre d’erreurs dĂ©tectĂ©es Ă  la compilation est plus Ă©levĂ©. Cela est permis par une utilisation abondante du systĂšme de type et de frameworks tel que Play! qui compilent URL et templates (et vĂ©rifient donc leur validitĂ©). Manuel Bernhardt revient aussi sur le support IDE qui est maintenant trĂšs bon, et la compilation dont le temps est toujours Ă©levĂ© mais qui est devenue incrĂ©mentale grĂące Ă  SBT.

En conclusion, Manuel Bernhardt donne quelques conseils pour apprĂ©hender le langage. PremiĂšrement, il conseille aux dĂ©veloppeurs non Scala de ne pas se laisser dĂ©courager par l’apparente complexitĂ© du langage. En effet, ce dernier fait beaucoup parler de lui autour de fonctionnalitĂ©s avancĂ©es tel que la mĂ©ta-programmation, les macros ou encore l’utilisation avancĂ©e du systĂšme de type. Mais ce sont des utilisations aux limites qui ne reflĂštent nullement la nature du dĂ©veloppement d’applications de gestion. Scala est un langage sans complexitĂ© inhĂ©rente qui concilie les paradigmes objet et fonctionnel avec une inclinaison vers ce dernier. Finalement, Manuel Bernhardt nous conseille de limiter l’utilisation de la boĂźte Ă  outils Scala au strict nĂ©cessaire afin de rĂ©duire la complexitĂ©, ce qui n’est pas sans rappeler le Principle of least power.

Practical Scalacheck – Noel Markham

 

scala-io-2

Noel est un consultant senior de 47 deg. Dans cette prĂ©sentation, il discute de l’importance des tests basĂ©s sur les propriĂ©tĂ©s et leur implĂ©mentation avec Scalacheck. Il montre comment Scalacheck nous permet de changer le paradigme dans lequel on fournit les donnĂ©es de notre test vers un autre dans oĂč on spĂ©cifie les rĂšgles que doit respecter notre code. Ce changement d’approche nous aide Ă©galement à Ă©viter la construction des stubs et mock, trĂšs populaires dans d’autres frameworks de test.

Ensuite, on discute un cas pratique mais typiquement compliqué : tester une implémentation du jeux Yahtzee.

forAll(chooseNum[Int](1, orderedGens.length - 1)) { idx =>
 val (winningGens, losingGens) = orderedGens.splitAt(idx)
 forAll(oneOf(winningsGens), oneOf(losingGens)) { (winningHand, losingHand) =>
  collect(s"${winningHand.score} vs ${losingHand.score}") {
   (winner(winningHand, losingHand) ?= winningHand) && (winner(losingHand, winningHand) ?= winningHand)
  }
 }
}

On aborde principalement des questions plus pointues :

  • Comment ne pas rĂ©-implementer le code mĂ©tier dans les tests ?
  • Éviter la croissance exponentielle des cas de test ?
  • Comment gĂ©nĂ©rer les donnĂ©es ?

À la fin, NoĂ«l nous conseille quelques bonnes pratiques :

  • Il faut utiliser les gĂ©nĂ©rateurs Ă  la place de l’opĂ©rateur ‘==>’
  • Il faut nommer les gĂ©nĂ©rateurs avec ‘|:’
  • Il faut crĂ©er des donnĂ©es pour le cas de succĂšs et pour les cas Ă©chĂ©antes

Finalement, Noël nous informe que bientÎt, on aura à disposition un projet créé pour 47 degrés pour nous aider à générer les dates.

CQRS + ES > CRUD, CQFD – Damien Gouyette et Valentin Kasas

Damien Gouyette et Valentin Kasas nous font un retour d’expĂ©rience sur la mise en place d’un modĂšle ES + CQRS dans le cadre du projet HamaK incubĂ©e par PagesJaunes.

Damien et Valentin ont commencĂ© par nous rappeler les inconvĂ©nients de l’approche CRUD classique. On citera notamment les problĂ©matiques de locking et de transactionalitĂ© ainsi que la perte d’information lors d’une mise Ă  jour ou d’une suppression Ă  l’opposĂ© de l’approche ES qui est fondamentalement diffĂ©rente.

Une persistance par ES modĂ©lise tout changement au travers d’Ă©vĂ©nements sĂ©quentiels et immuables. Cette approche apporte donc un audit/historique en plus d’ĂȘtre trĂšs efficace dans un environnement concurrentiel de par sa nature immuable.

Cependant, cette approche ES apporte son lot de difficultĂ©s. PremiĂšrement, ce modĂšle de persistance n’est gĂ©nĂ©ralement pas viable d’un point de vue lecture, c’est pourquoi il est quasi systĂ©matiquement couplĂ© Ă  du CQRS pour garantir des performances constantes. À cela s’ajoute la difficultĂ© face aux inĂ©vitables changements de modĂšle. En effet, contrairement Ă  une persistance CRUD classique oĂč les donnĂ©es peuvent ĂȘtre migrĂ©es d’une version Ă  une autre, l’approche ES interdit la modification d’Ă©vĂ©nements immuables. De plus, il peut persister des Ă©vĂ©nements de la version antĂ©rieure dans les queues de messages, c’est pourquoi il sera nĂ©cessaire de supporter les deux versions.

Finalement, Damien et Valentin nous montrent quelques patterns adroitement utilisés tel que les typeclasses, Reader et ValidationNel de ScalaZ.

À la dĂ©couverte d’Idris et de ses types dĂ©pendants – BenoĂźt Lemoine

Dans ce quickie, BenoĂźt nous fait un live coding en Idris, un langage supportant les types dĂ©pendants. Les types dĂ©pendants sont une fonctionnalitĂ© qui permet Ă  un type de dĂ©pendre d’une valeur. On mĂ©lange donc deux dimensions habituellement distinctes dans les langages de programmation. On note que cette fonctionnalitĂ© est absente de la plupart des langages de programmation y compris Scala (certains diront que les “path dependent types” sont une forme de typage dĂ©pendant).

Durant ce live-coding, Benoßt implémente le « hello world » du typage dépendant : une liste qui encapsule sa taille dans son type.

Voici un exemple de dĂ©finition et d’utilisation d’un constructeur de type liste paramĂ©trĂ© avec un entier (Nat) et un type (Type)

data   List   :   Nat   ->   Type   ->   Type

append   :   List n a ->   List m a ->   List (n + m) a

La fonction append ci-dessus permet de concatĂ©ner deux listes de taille n et m et de crĂ©er une liste de taille n + m. On insiste de nouveau sur le fait que la taille fait partie du type et que la vĂ©racitĂ© de la signature est donc vĂ©rifiĂ©e par le compilateur. Un effet de bord de ce typage extrĂȘmement puissant est une infĂ©rence trĂšs forte qui ressemble presque Ă  de la gĂ©nĂ©ration de code. Cela est possible car le compilateur possĂšde beaucoup d’informations et que les implĂ©mentations possibles pour une signature donnĂ©e minimes voire uniques. 

Easy and efficient data validation with Cats – Daniela Sfregola

Dans ce talk, Daniela nous parle de la validation de données de maniÚre élégante avec cats.

Elle nous explique qu’en Scala, il est possible de « sĂ©curiser » une suite de traitements grĂące Ă  la monade Option. Cependant, si une erreur survient, on ne peut pas dĂ©terminer quelle partie du traitement a Ă©chouĂ©, ni savoir quelle est l’erreur.

Daniela nous prĂ©sente alors la monade Xor (qui sera supprimĂ©e au profit de la monade Either dans scala 2.12) qui permet de dĂ©terminer quelle Ă©tape du traitement a Ă©chouĂ© et pour quelle raison. Cependant, il s’agit d’un « court-circuit » en cas d’erreur, c’est-Ă -dire que c’est idĂ©al si l’on souhaite un fail fast ou si les diffĂ©rents traitements sont dĂ©pendants. Par contre, elle n’est pas adaptĂ©e pour la validation de donnĂ©es mĂ©tiers oĂč l’on souhaite enchaĂźner les traitements et accumuler les erreurs.

Daniela nous prĂ©sente alors Validated qui, contrairement Ă  Option et Xor/Either, n’est pas une monade mais un foncteur applicatif. Si on ne peut plus faire un flatMap, il est en revanche possible de chaĂźner les validations, nous offrant ainsi une validation Ă©lĂ©gante des donnĂ©es.

case class Person(mail: String, name: String)

def isEmail(mail: String): Validated[NEL[String], String] =
 if (mail.contains("@")) { valid[NEL[String], String](mail)} 
 else { invalid[NEL[String], String](NEL.of("underage"))}


def nameNonEmpty(name: String) =
 if (!name.isEmpty) { valid[NEL[String], String](name)} 
 else { invalid[NEL[String], String](NEL.of("invalid name")) }


def validatePerson(mail: String, name: String): ValidatedNel[String, Person] = {
  val validAge  = isEmail(mail)
  val validName = nameNonEmpty(name)
  (validAge |@| validName)
    .map{ case (vAge, vName) => Person(vAge, vName)  }
}
DĂ©velopper des APIs Hypermedias simplement avec Scala – Antoine Michel

Antoine Michel (CTO de Zengularity) nous rĂ©vĂšle un projet que sa sociĂ©tĂ© compte open-sourcer s’il intĂ©resse suffisamment de monde : une bibliothĂšque facilitant le dĂ©veloppement d’API Hypermedia. Il faut bien comprendre que l’on vise lĂ  le REST au sens originel du terme, plus connu actuellement sous le terme de HATEOAS.

Les promesses de la bibliothĂšque sont :

  • de pouvoir faire une API auto-documentĂ©e, sans passer par un gĂ©nĂ©rateur ;
  • de simplifier le dĂ©veloppement : pas besoin de maĂźtriser tous les aspects de REST, il suffit de dĂ©crire les propriĂ©tĂ©s et contraintes de ressources.

Antoine Michel fait partie de ces rares personnes dans le monde REST qui ont compris la nĂ©cessitĂ©, dans ce style d’architecture, de gĂ©rer la partie cliente. Le client est souvent un navigateur pilotĂ© par un ĂȘtre humain, ce qui rend particuliĂšrement difficile la transposition du Web (naturellement RESTful) au monde des API, consommables par des automates. Cette partie, pas encore rĂ©alisĂ©e, pourrait aider les SPA Ă  trouver les ressources et Ă  crĂ©er automatiquement des rĂšgles de validation pour les formulaires. React est la premiĂšre technologie front qui serait supportĂ©e. Au final, quelque soit le langage client, il y aura la possibilitĂ© de gĂ©nĂ©rer la couche d’accĂšs aux ressources.

Le travail le plus avancĂ© est la partie back. Elle repose sur le format JSON-LD, qui apporte la partie « liens » manquante Ă  JSON pour en faire un hypermedia. JSON-LD permet d’aller plus loin que ce qui est nĂ©cessaire pour une API REST consommĂ©e par des automates, Ă  savoir la description des contraintes nĂ©cessaire Ă  la crĂ©ation d’une IHM. On notera d’autre points forts :

  • routes explicites mais aussi dĂ©ductibles du contexte ;
  • reverse-routing obtenu by design ;
  • gĂ©nĂ©ration d’un AST qui permet dĂ©tendre l’implĂ©mentation pour supporter d’autres maniĂšres de naviguer dans les ressources, comme GraphQL ;
  • possibilitĂ© d’utiliser la bibliothĂšque en mode CQRS.

En rĂ©sumĂ©, nous souhaitons vivement qu’une suite soit donnĂ©e au projet qui est un changement majeur dans le monde des frameworks REST !

La programmation fonctionnelle, c’est pas juste des lambdas – David Sferruzza

OrientĂ©e dĂ©butant, cette prĂ©sentation de David Sferruzza vise Ă  faire dĂ©couvrir les principes programmation fonctionnelle (PF). Elle s’inscrit dans la politique d’ouvrir le Scala et plus gĂ©nĂ©ralement la PF aux dĂ©veloppeurs habituĂ©s au paradigme objet classique.

Les fondamentaux sont présentés :

  • Comment la PF rend la chaĂźne de traitement plus claire en Ă©vitant par exemple de mĂ©langer l’implĂ©mentation d’un parcours de boucle et avec le traitement utile comme ce serait fait en programmation impĂ©rative
  • Les fonction de base sur la classe List : map, filter, fold et autres fonctions d’ordre supĂ©rieur
  • MaĂźtrise de stratĂ©gie d’Ă©valuation (par exemple, une stratĂ©gie « lazy » permet dĂ©valuer des structures infinies)
  • DiffĂ©rences entre val, lazy val, def
  • L’immuabilitĂ© et ses avantages. David nous rappelle que l’immuabilitĂ© est parfois perçu Ă  tort comme pĂ©nalisant pour les performances. Au contraire, cela permet de faire des copies superficielles de structure sans risques !

David Sferruzza termine par une bibliographie pour bien commencer en programmation fonctionnelle. Il y inclut un ouvrage sur Haskell, car ce langage fonctionnel pur permet d’aprĂšs lui de mieux saisir certains principes quand on revient au Scala.

Applying Functional Programming Patterns – Markus Haulk

Dans ce talk, Markus Haulk nous présente différents patterns issus de la programmation fonctionnelle.

Markus commence par nous expliquer sa vision de la programmation fonctionnelle par rapport Ă  la programmation orientĂ©e objet (POO). Pour lui, la POO est comparable Ă  des Duplo, on peut construire de grosses briques qui s’imbriquent facilement dans l’environnement oĂč elles sont prĂ©vues pour aller, mais sont pour la plupart spĂ©cifiques, pas facilement rĂ©utilisables. En revanche, il voit la programmation fonctionnelle comme des Lego. Celle-ci est constituĂ©e de quelques briques Ă©lĂ©mentaires simples bien dĂ©finies, composables et rĂ©utilisables Ă  l’infini , permettant ainsi de construire de grands Ă©difices.

Markus nous montre alors deux exemples notables de cette composabilité et son utilisation :

  • Les Monoid : Il s’agit d’une structure munie d’un Ă©lĂ©ment neutre, d’une fonction de combinaison et de certaines lois sur cette fonction. À partir de cette structure simple, Markus expose quelles possibilitĂ©s de combinaisons nous sont offertes et nous prĂ©sente un exemple d’utilisation des Monoid dans Spark.
  • Validated : Autre structure munie d’une opĂ©ration de composition, celle-ci permet de tester la validitĂ© d’une donnĂ©e et se compose aisĂ©ment avec d’autres Validated. C’est une structure trĂšs puissante lorsque l’on souhaite valider un ensemble de donnĂ©es tout en cumulant l’ensemble des erreurs rencontrĂ©es, comme par exemple lors de la validation d’un formulaire.
Quelques photos

Et pour finir… rien de mieux que quelques photos !

scala

scala

scala

Catégories: Blog Société

LCC 158 - Interview sur Elasticsearch avec David Pilato

Emmanuel et David discutent d’Elasticsearch, des cas d’utilisations, de comment ça marche sous le capot et de la derniùre version 5.

Enregistré le 7 novembre 2016

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

Interview Ta vie ton Ɠuvre

David Pilato
@dadoonet

La technologie

Qu’est ce qu’Elasticsearch en 2 minutes
La concurrence

Elasticsearch
Apache Lucene

Cas d’utilisation

Quels sont les grands use cases pour ElasticSearch ?

  • Recherche full-text
  • Analyse de logs
  • Business Intelligence
  • Faceting

L’écosystĂšme autour d’Elasticsearch

  • Kibana
  • Logstash
  • Beats
  • Grafana
Le cycle de development

J’ai des donnĂ©es, comment je les indexe

  • code manuel pour extraction de la donnĂ©e ?
  • d’autres outils
  • le cas des logs

Java client
Hibernate Search
Jest

Mapping
Analyzer

Log Structured Merge tree

Les requĂȘtes
Les requĂȘtes disponibles
Ça ramùne pas ce que je veux, comment faire ?

Blog de Lucian sur les analyzers

Elasticsearch Skywalker

Tester / amĂ©liorer la perf de mes requĂȘtes

Quid des aggregations, je peux faire quoi

Un cluster, des replicats, des indexés, des shards.
Quels sont les notions importantes pour le développeurs

Scaler
Comment ça se passe pour scaler
Les ops ils aiment ou pas Elasticsearch ?

Autre

La v5 est sortie, quoi de neuf ? Nouvelles fonctionnalités
Migration
modules / plugins

Nous contacter

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

 

Catégories: Blog Individuel

Architecture microservices de la théorie à la pratique

Blog d’Ippon Technologies - jeu, 12/01/2016 - 14:52

Ce REX a Ă©tĂ© mis en place afin de dĂ©crire la procĂ©dure de crĂ©ation d’une architecture orientĂ©e microservices de toutes piĂšces.

Ces articles ont pour but de proposer une architecture permettant de concevoir une application basĂ©e sur des microservices, en utilisant les outils de la stack Netflix OSS. C’est un guide, Ă©tape par Ă©tape, permettant d’explorer les applications mises Ă  disposition par Netflix pour mettre en oeuvre leur utilisation.

Les outils proposĂ©s ont Ă©tĂ© testĂ©s par David Martin (Directeur du PĂŽle Conseil et Formation d’Ippon) et Christophe Lopes (IngĂ©nieur Etudes et DĂ©veloppement chez Ippon).

TĂ©lĂ©chargez “Architecture microservices de la thĂ©orie Ă  la pratique”.

Catégories: Blog Société

Capital Ă  la rencontre de Synbioz

L'actualité de Synbioz - jeu, 12/01/2016 - 00:00

En cette fraiche fin d’annĂ©e Capital est venu nous rendre visite armĂ© de ses camĂ©ras :

Capital Ă  la rencontre de Synbioz via synbioz sur Vimeo.

Lire la suite...

Catégories: Blog Société

Meet our superhero Atlassian consultants!

Le blog de Valiantys - mer, 11/30/2016 - 14:45

As HR Manager at Valiantys, I spend a great deal of time finding our next superhero Atlassian consultants. That’s why I’ve decided in this blog to take a closer look at them – who are the Valiantys superhero consultants? How do they work? And do they really wear capes? The only way to find out ...

The post Meet our superhero Atlassian consultants! appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

Scala 2.12 : Lambda expression

Blog d’Ippon Technologies - mer, 11/30/2016 - 14:26

Jusque lĂ , nous avons fait un tour des nouveautĂ©s de Scala 2.12 et nous avons observĂ© de prĂšs l’unification entre les interfaces de Java 8 et les traits. Pour clore notre sĂ©rie, nous allons nous intĂ©resser dans cet article aux lambda expressions dans Scala 2.12 et le rapprochement fait avec cette mĂȘme fonctionnalitĂ© dans Java 8.

Lambda expression

Les lambda expressions en Java 8 reprĂ©sentaient jusqu’Ă  prĂ©sent un net avantage sur Scala : elles peuvent en effet s’appliquer Ă  toutes sortes d’interfaces fonctionnelles. Les interfaces fonctionnelles sont des interfaces n’ayant qu’une seule mĂ©thode Ă  implĂ©menter (aussi appelĂ©es SAM pour Single Abstract Method). Du cĂŽtĂ© de Scala jusqu’Ă  la version 2.11, les expressions de ce type Ă©taient limitĂ©es Ă  ĂȘtre transcrites uniquement sous la forme de Function0, Function1, Function2, etc., en fonction du nombre de paramĂštres en entrĂ©e de la fonction.

Ce point a Ă©tĂ© revu dans la version 2.12 de Scala. Si par dĂ©faut, le comportement ne change pas pour ce qui concerne la transcription en Function0, Function1, Function2, etc., il en va diffĂ©remment Ă  partir du moment oĂč le contexte est prĂ©cisĂ©.

Prenons l’exemple de la crĂ©ation d’un thread pour des versions de Scala antĂ©rieures.

val thread =
  new Thread(new Runnable {
    override def run(): Unit = println("hello world!")
  })

À partir de Scala 2.12, nous pouvons l’Ă©crire de la façon suivante.

val thread =
  new Thread(() => println("hello world!"))

Rentrons dans le détail de ce qui se passe.

Voyage au coeur des lambda expressions

Observons un exemple montrant le comportement par dĂ©faut, autrement dit si on ne prĂ©cise pas l’interface Ă  implĂ©menter. Si on ouvre le REPL, nous avons le rĂ©sultat suivant :

val f1 = (x: Int) => x + 1
f1: Int => Int = $Lambda$1610/845028109@3a3b07ee

Int => Int est l’Ă©quivalent de Function1[Int, Int]. Ainsi est transcrite par dĂ©faut une lambda expression.

f1: Int => Int = <function1>

Nous voyons que la fonction est Ă  prĂ©sent transcrite sous la forme Lambda de Java. Mais en dehors de cet affichage, il semble n’y avoir aucun vĂ©ritable changement.

Regardons au niveau bytecode. Pour cela, mettons et utilisons f1 dans une classe appelée UseLambda.

class UseLambda {
  val f1 = (x: Int) => x + 1

  def useFunction() = println(f1(2))
}

En jouant avec javap et les options -c (désassembler le code) et -p (afficher tous les membres de la classe), nous voyons cette signature :

private final scala.Function1<java.lang.Object, java.lang.Object> f1;

À partir de lĂ  se posent deux questions. 1/ Comment accĂ©dons-nous Ă  f1, puisque le champ est privĂ© ? 2/ Comment est-il initialisĂ© ?

Pour l’accĂšs Ă  f1, il suffit de regarder un peu plus loin :

public scala.Function1<java.lang.Object, java.lang.Object> f1();
    // ...
    getfield #19 // Field f1:Lscala/Function1;
    // ...

getfield fait bien rĂ©fĂ©rence Ă  la variable d’instance f1 de type scala.Function1[_, _]. Donc, l’accĂšs au champ f1 se fait par la mĂ©thode f1().

public void useFunction();
    // ...
    4: invokevirtual #34       // Method f1:()Lscala/Function1;
    7: iconst_2
    8: invokeinterface #40, 2  // InterfaceMethod
         // scala/Function1.apply$mcII$sp:(I)I
   13: invokestatic #46        // Method
         // scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
    // ...

En 4, nous avons l’appel Ă  la mĂ©thode de f1() qui nous retourne le contenu de du champ f1. En 8, c’est la mĂ©thode scala.Function1.apply$mcII$sp() qui est appelĂ©e sur ce qui est retournĂ© par f1. Cette mĂ©thode n’existe pas dans scala.Function1. Elle est ajoutĂ©e au runtime. Nous allons voir comment.

Le champ f1 est initialisĂ© dans le constructeur de UseLambda, au travers de l’appel Ă  l’instruction invokedynamic :

public UseLambda();
    // ...
    invokedynamic #71, 0 // InvokeDynamic
        // #0:apply$mcII$sp:()Lscala/runtime/java8/JFunction1$mcII$sp;
    putfield #19 // Field f1:Lscala/Function1;
    // ...

C’est de lĂ  que vient la mĂ©thode mystĂšre apply$mcII$sp(). Mais regardons de plus prĂšs cette instruction invokedynamic et ce qui se passe dans f1.

Invokedynamic

invokedynamic (aussi appelĂ©e indy) est la nouvelle instruction de la JVM apparue sous Java 7 avec la JSR-292. Elle permet de lier un appel de mĂ©thode avec n’importe quelle autre mĂ©thode ayant une signature identique au runtime (ça vous rappelle le duck typing ?), alors que les autres types d’invocation (invokestatic, invokevirtual, invokespecial) sont rĂ©solus au compile-time.

Cette instruction est utilisĂ©e dans Java 8, pour lier dynamiquement les lambda expressions Ă  une mĂ©thode locale et faire l’Ă©conomie de la crĂ©ation d’une classe anonyme. Afin de rentrer dans les dĂ©tails du fonctionnement d’invokedynamic, cette instruction Ă  besoin de connaĂźtre la mĂ©thode qui est censĂ©e ĂȘtre appelĂ©e (le call site) et une mĂ©thode de bootstrap. La mĂ©thode de bootstrap est appelĂ©e au runtime pour lier le call site Ă  une mĂ©thode cible ayant une signature Ă©quivalente et contenant l’implĂ©mentation. Cette mĂ©thode cible est reprĂ©sentĂ©e par un MethodHandle. Dans Java 8, la mĂ©thode de bootstrap est unique pour toutes les lambda expressions. Il s’agit de java.lang.invoke.LambdaMetaFactory#metafactory().

Non seulement, nous faisons l’Ă©conomie d’une classe anonyme, mais l’utilisation d’invokedynamic permet aussi de choisir plus tard d’autres stratĂ©gies de liaison au dernier moment de façon transparente. Sachant que cette stratĂ©gie peut changer d’un JRE Ă  un autre. Fabien Arrault avait dĂ©jĂ  sur ce blog dĂ©crit le fonctionnement de l’instruction invokedynamic dans un cadre plus large que Java 8 (Devoxx France 2015 Jour 3 : Proxy 2.0). L’article de “Java 8 Lambdas – A Peek Under the Hood” donne plus de dĂ©tail sur le fonctionnement de l’instruction invokedynamic dans le cadre de Java 8.

Invokedynamic dans Scala

Scala 2.12 se base globalement sur le mĂȘme principe que Java 8 pour la conversion des lambda expressions. Une diffĂ©rence rĂ©side dans la mĂ©thode de bootstrap. C’est la mĂ©thode java.lang.invoke.LambdaMetaFactory#altMetafactory() qui est utilisĂ©e. altMetafactory() est une version gĂ©nĂ©ralisĂ©e de metafactory(), permettant plus de flexibilitĂ© et plus de contrĂŽle sur l’appel Ă  la mĂ©thode cible.

L’affichage des mĂ©thodes de bootstrap est un peu particulier, car elle n’apparaĂźt pas dans l’interface de la classe, mais plutĂŽt dans une section dĂ©diĂ©e du bytecode. Pour l’afficher avec javap, il faut ajouter l’option -v (mode verbeux). Pour UseLambda, nous voyons apparaĂźtre :

BootstrapMethods:
  0: #60 invokestatic java/lang/invoke/LambdaMetafactory.altMetafactory:(
            Ljava/lang/invoke/MethodHandles$Lookup;
            Ljava/lang/String;
            Ljava/lang/invoke/MethodType;
            [Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      // ...
      #64 invokestatic UseLambda.$anonfun$f1$1:(I)I
      // ...

La méthode de bootstrap #0 fait bien un appel static à la méthode java.lang.invoke.LambdaMetaFactory#altMetafactory(). Celle-ci fait référence à la méthode $anonfun$f1$1() définie dans la classe UseLambda et qui contient le code de f1. Sa signature est la suivante :

public static final int $anonfun$f1$1(int);

Donc, lors de la construction de l’instance de UseLambda, la mĂ©thode permettant d’exĂ©cuter la fonction f1 sera au final liĂ©e Ă  $anonfun$f1$1().

Initialisation des lambda dans Scala

Reprenons les lignes du constructeur de UseLambda (vues plus haut) avec l’invokedynamic qui initialise f1 :

invokedynamic #71, 0 // InvokeDynamic
    // #0:apply$mcII$sp:()Lscala/runtime/java8/JFunction1$mcII$sp;
putfield #19 // Field f1:Lscala/Function1;

Ici, la méthode appelée pour la liaison, le call site est scala.runtime.java8.JFunction1$mcII$sp#apply$mcII$sp().

scala/runtime/java8 est un impressionnant rĂ©pertoire contenant des interfaces fonctionnelles de la forme JFunction{{A}}$mc{{IO}}$sp et Ă©tendant chacune scala.Function0, scala.Function1 et scala.Function2. A correspond Ă  l’aritĂ© de la fonction (nombre de paramĂštres en entrĂ©e, variant entre 0 et 2) et IO correspond au type des paramĂštres de sortie et d’entrĂ©e. Ces interfaces sont des fonctions permettant de gĂ©rer le boxing / unboxing de types primitifs. La classe JFunction1$mcII$sp est donc une interface fonctionnelle (au sens Java) reprĂ©sentant une fonction ayant une entrĂ©e de type int (I) et retournant un int (I). Elle prĂ©sente la mĂ©thode abstraite apply$mcII$sp(). C’est cette mĂ©thode abstraite qui est la cible dans l’instruction invokedynamic vue plus haut. Sa signature est la suivante :

int apply$mcII$sp(int v1);

On peut remarquer l’Ă©quivalence en terme de signature avec $anonfun$f1$1(), que nous avons vu dans la section prĂ©cĂ©dente.

En résumé

Le champ f1 est initialisé au runtime avec JFunction1$mcII$sp. Le call site JFunction1$mcII$sp#apply$mcII$sp() est greffé indirectement en local dans le bytecode à scala.Function1. Il est aussi associé au runtime à la méthode $anonfun$f1$1(). Avec ça, les appels à la fonction f1() sont convertis en appels vers le call site scala.Function1.apply$mcII$sp() et sont ainsi redirigés vers $anonfun$f1$1().

L’instruction invokedynamic permet donc de transformer un appel vers une fonction en appel local. Cette transcription est proche de celle rĂ©alisĂ©e en Java 8 pour les lambda expressions pour ce qui concerne la transformation d’un appel externe en appel local.

Pour plus de prĂ©cisions sur l’utilisation d’invokedynamic en Scala, Jason Zaugg a Ă©crit un Gist Ă  ce sujet.

Autres exemples de lambda expressions

Il est possible d’associer des lambda expressions Scala Ă  d’autres interfaces fonctionnelles, notamment avec celles dĂ©finies en Java.

val f2: java.util.function.Function[Int, Int] = (x) => x + 1
f2: java.util.function.Function[Int,Int] = $Lambda$1611/1221520969@2762891e
val f3: java.util.function.IntUnaryOperator = (x) => x + 1
f3: java.util.function.IntUnaryOperator = $Lambda$1612/5779187@5ba4d579

Par contre, une fois l’interface dĂ©terminĂ©e, il n’est plus possible de rĂ©aliser de conversion.

val f4: Int => Int = f2
Error:(8, 24) type mismatch;
    found   : java.util.function.Function[Int,Int]
    required: Int => Int
    val f4: Int => Int = f2
                         ^

Le code prĂ©cĂ©dent donne une erreur de compilation. La conversion de java.util.function.Function[Int, Int] vers Int => Int (c’est-Ă -dire scala.Function1[Int, Int]) ne peut ĂȘtre faite implicitement. L’inverse donne la mĂȘme erreur.

val f5 = () => println("hello")
f5: () => Unit = $Lambda$1613/1388667714@47581aa2
val f6: Runnable = () => println("hello")
f6: Runnable = $Lambda$1614/95047245@15dea018

L’intĂ©rĂȘt des lambda expressions en Scala ne se trouve pas tant dans les performances. Il se trouve surtout dans la capacitĂ© Ă  appliquer les lambda expressions Ă  n’importe quelle interface fonctionnelle.

Référence sur des méthodes

Java 8 permet d’appliquer des rĂ©fĂ©rences sur des mĂ©thodes, qui seront converties intrinsĂšquement en lambda expressions . Scala permet dans certains cas de rĂ©aliser la mĂȘme chose.

val printer: Consumer[String] = println
printer: java.util.function.Consumer[String] = $Lambda$1623/1450301379@2dd0526e

Mais ce n’est pas applicable Ă  tous les appels de mĂ©thode.

Prenons une interface Message contenant une méthode message(). En Java, on ne peut faire que ça :

Stream<String> export(Stream<Message> messages) {
    return messages.map(Message::message);
}

En Scala, on est limité à cette écriture :

def export(messages: List[Message]) =
  messages.map(m => m.message())

Par contre, en utilisant la notation _, on peut transformer la méthode précédente de la maniÚre suivante :

def export(messages: List[Message]) =
  messages.map(_.message())

Cette Ă©criture n’est qu’un sucre syntaxique et est totalement Ă©quivalente Ă  sa premiĂšre version. Ceci dit, on bĂ©nĂ©ficie d’une optimisation Ă©quivalente Ă  Java, qui consiste Ă  utiliser invokedynamic pour dĂ©terminer la mĂ©thode cible. Scala ajoute en plus une indirection se basant sur une mĂ©thode anonyme.

Conclusion

Les principales nouveautĂ©s de Scala 2.12 permettent de rapprocher le langage de la direction prise par Java 8. En dehors de l’amĂ©lioration de l’interopĂ©rabilitĂ© Java / Scala, l’effet obtenu est la possibilitĂ© d’ĂȘtre en prĂ©sence d’un code encore plus concis et d’avoir moins de fichiers .class gĂ©nĂ©rĂ©s. Ceci fait de la nouvelle version de Scala un cru intĂ©ressant.

Du cĂŽtĂ© des frameworks et API, il faudra attendre les mises Ă  jour avant de profiter pleinement de l’Ă©cosystĂšme Scala dans cette nouvelle version. En effet, si Akka, ScalaTest ou ScalaZ sont prĂȘts pour la 2.12, ce n’est pas encore le cas de Spark ou Play.

Et aprĂšs…

Scala 2.12 sorti, Scala 2.11 continuera Ă  ĂȘtre maintenu pour ceux qui utilisent la version 6 ou 7 de Java. En parallĂšle, les dĂ©veloppeurs du langage prĂ©parent dĂ©jĂ  la version 2.13. Cette version devrait intĂ©grer une rĂ©novation de l’API Collection, avec l’intĂ©gration de la notion de vue et en particulier un rapprochement de l’usage rĂ©alisĂ© avec Spark. On attend aussi l’arrivĂ©e du nouveau compilateur Dotty (prĂ©vue pour le 2e trimestre 2017) et CBT, le futur remplaçant de SBT.

Reportez-vous à la keynote de Martin Odersky de Scala.io 2016 pour plus de détails sur les autres nouveautés à venir dans Scala : https://www.youtube.com/watch?v=jHoIzOdUn4c&t=638s

Catégories: Blog Société

Android : Mes raccourcis préférés sur Android Studio / IntelliJ IDEA

Android Studio est l’IDE officiel pour le dĂ©veloppement Android, il est utilisĂ© par plus de 90% des dĂ©veloppeurs. BasĂ© sur JetBrains‘ IntelliJ IDEA, il possĂšde les mĂȘme raccourcis.

Voici une liste non exhaustive des raccourcis les plus utiles pour améliorer sa productivité.

Le keymap utilisé est : Mac OS X 10.5+.

Une excellente façon de partager et d’apprendre davantage est de faire du pair programming. Vous serez surpris de voir comment font vos collĂšgues (euh, comment t’as fait ça ?) et rĂ©ciproquement.

Mon projet est trop gros, c’est oĂč ce truc ?

La recherche rapide dans un projet pour :

  • Cmd + O : trouver une classe
  • Cmd + Alt + O : trouver un symbole (mĂ©thode, variable, id, classe, etc)
  • Cmd + Shift + O : rechercher un fichier (build.gradle, strings.xml, etc)
  • Cmd + E : afficher la liste des fichiers rĂ©cents

Une fois un fichier ouvert, pour le retrouver facilement :

  • Alt + F1 puis 1 : ouvrir dans l’arborescence le fichier ouvert
    Ou Ă  la souris :

 MES RACCOURCIS PRÉFÉRÉS SUR ANDROID STUDIO / INTELLIJ IDEA

Trouver une classe, un symbole ou un fichier.

look_for_stuff.gif

Se déplacer dans son projet
  • Cmd + Shift + T : pour naviguer entre sa classe et son(ses) test(s) et par la mĂȘme occasion le crĂ©er s’il n’existe pas
  • Cmd + Shift + [ ou ] : pour naviguer entre ses onglets
  • Cmd + Alt + B (Curseur sur le nom de l’interface) : dans une interface, permet d’aller dans l’implĂ©mentation ou d’afficher la liste des implĂ©mentations
    Ou Ă  la souris :

 MES RACCOURCIS PRÉFÉRÉS SUR ANDROID STUDIO / INTELLIJ IDEA

Ce qu’on prĂ©fĂšre : Refactorer son code
  • Shift + F6 : refactorer
  • Alt + Cmd + V ou .var à la fin de l’expression + EntrĂ©e :  pour extraire une variable
  • Alt + Cmd + F ou .field Ă  la fin de l’expression + EntrĂ©e : pour extraire un attribut de classe
  • Alt + Cmd + P : pour extraire un paramĂštre Ă  la mĂ©thode
  • Alt + Cmd + M (sĂ©lection du code) : pour extraire une mĂ©thode
  • Cmd + Shift + U : passer de majuscule Ă  minuscule et vice versa
Dans un fichier

Les classiques (on ne sait jamais)

  • Alt + ← ou → : dĂ©placer le curseur au mot suivant
  • Cmd (ou Fn) + ← ou → : dĂ©placer le curseur au dĂ©but ou Ă  la fin de la ligne
  • Ctrl + J : pour afficher la Javadoc de ce qui est sous le curseur
  • Cmd + Y : pour afficher la dĂ©claration de ce qui est sous le curseur
  • Cmd + Shift + « +/-«  : pour Ouvrir ou tout Fermer (fonctions, bloc de commentaire, inner class)
  • Alt + ↑ ou ↓ : permet d’augmenter ou de rĂ©duire la sĂ©lection
  • Alt + Shift + ↑ ou ↓ : dĂ©placer la sĂ©lection (ou ligne courante)
  • Cmd + X : supprimer la ligne
  • Cmd + D : dupliquer la ligne
expandAndCollapse.gif En vrac
  • Cmd + Shift + A : chercher une action ou une option
  • Ctrl + R : relancer le dernier build
  • Ctrl + Shift + R : lancer le build de la selection
  • Cmd + W : fermer l’onglet actif
Et enfin le plus cool de tous : Le Multi Cursor

Quand on n’a pas la possibilitĂ© de faire un refactoring (Shift + F6) et que l’on veut Ă©diter plusieurs lignes Ă  la fois, le multi-cursor est lĂ  pour nous faciliter la vie.

La multiplication du curseur se fait de différentes maniÚres :

  1. Alt + Alt + ↑ ou ↓ : si tous les champs sont à la ligne
  2. Alt + Shift + click : pour placer le curseur à différents endroits
  3. Ctrl + G : pour sĂ©lectionner l’occurrence suivante

 MES RACCOURCIS PRÉFÉRÉS SUR ANDROID STUDIO / INTELLIJ IDEA

VoilĂ , j’espĂšre que vous avez dĂ©couvert un raccourci qui facilitera votre travail de tous les jours.

Et pour aller plus loin voici la liste complÚte des raccourcis qui contient notamment une correspondance pour les utilisateurs de Windows et Linux.

Si vous souhaitez en proposer d’autres, n’hĂ©sitez pas Ă  les mettre en commentaire, je les rajouterai Ă  l’article afin de les partager Ă  tous.

Catégories: Blog Société

Asynchronous data exchanges, dĂ©coupler avec classe – partie 1

DĂ©porter des traitements lourds, transfĂ©rer des logs, gĂ©rer des pics de charges, architecture rĂ©active
 Il existe de nombreux cas d’utilisation du design pattern Asynchronous data exchanges qui permet de gĂ©rer la communication de message en mode asynchrone.

De nos jours, plein de solutions existent pour l’implĂ©menter :

  • Utilisation de mĂ©thode intĂ©grĂ©e aux langages :
    • Futures en Java
    • Actors et Futures en Scala
    • Delegate en .Net
  • Utilisation d’outil comme Netty
  • Utilisation de serveur de message ou MOM (Message Oriented Middleware)
  • Etc.

Dans cette sĂ©rie d’articles, nous allons regarder l’utilisation d’un MOM.

Pour cela nous allons voir trĂšs rapidement la thĂ©orie, les points d’attention et finir avec des cas d’utilisations dans le deuxiĂšme article.

Un peu de théorie

Un MOM nous permet d’envoyer et de recevoir des messages de maniĂšre asynchrone afin de dĂ©coupler le producteur et le rĂ©cepteur.

Modes de fonctionnement

Il existe trois modes de fonctionnement principaux (qui peuvent avoir des noms différents selon la norme).

Point Ă  point/Direct exchange

Le producteur envoie un message dans le MOM qui l’envoie à un ou plusieurs consommateurs. Par contre un seul consommateur lit le message.

Point Ă  point

 

Il est possible d’avoir plusieurs consommateurs en mĂȘme temps.

Point Ă  point

 

De mĂȘme pour les producteurs.

Plusieurs producteurs peuvent Ă©crire sur la mĂȘme file de messages, mais il y a toujours un seul consommateur qui lit le message.

Point Ă  point

 

Pour résumer, le message est transmis à 1 seule file de messages identifiée.

Nous utiliserons ce mode d’échange lorsque le message sera traitĂ© par un seul consommateur.

Publish-subscribe/Topic exchange

Les consommateurs s’abonnent Ă  un topic. DĂšs qu’un message arrive dans ce topic, il est lu par tous les consommateurs prĂ©sents Ă  ce moment.

 

Publish/subscribe

 

Si un consommateur arrive aprĂšs (et que la file de messages est non durable), il ne lira que les messages suivants.

Publish/subscribe

 

Nous utiliserons ce mode d’échange lorsque le message pourra ĂȘtre traitĂ© par plusieurs consommateurs. Par exemple pour implĂ©menter des fils d’actualitĂ©, des notifications d’évĂ©nements, etc.

Broadcast/Fanout exchange

Le producteur envoie un message dans le MOM qui l’envoie Ă  toutes les files de messages qui y sont connectĂ©es Ă  ce moment.

fanout

 

Les cas d’utilisation sont les mĂȘmes que pour du broadcast classique.

Quelques normes/protocoles

De nombreuses normes/protocoles existent :

  • L’API JMS dans le monde Java
  • Le protocole AMQP
  • Le protocole MQTT adaptĂ© au monde de l’IoT
  • Le protocole STOMP plus lĂ©ger et simple Ă  implĂ©menter
  • La solution Websphere MQ qui supporte JMS, mais a aussi son propre protocole et est adaptĂ©e au monde du Mainframe
  • La solution Apache Kafka adaptĂ©e pour les trĂšs grosses volumĂ©tries
  • Etc.
Quelques outils

Une fois la norme choisie, il nous reste Ă  choisir le bon outil

Pour vous aider, voici une liste non exhaustive :

  • AWS SQS, service cloud d’Amazon AWS
  • Apache ActiveMQ, la rĂ©fĂ©rence
  • RabbitMQ, le petit frĂšre d’ActiveMQ
  • Apache Kafka
  • Redis, utile si vous l’utilisez dĂ©jĂ  pour du cache et que vous ne voulez pas ajouter une nouvelle brique
  • ZeroMQ, une API lĂ©gĂšre de messaging

Notez que :

  • Certains des outils listĂ©s supportent plusieurs protocoles
  • En fonction du cas d’utilisation (mode distribuĂ©, mode dĂ©centralisĂ©, besoin d’une faible latence…), certains outils sont plus adaptĂ©s que d’autres
Points d’attention

Avant d’Ă©ventuellement choisir une des solutions (qui offre plein de bonne raison de les utiliser), il est prĂ©fĂ©rable de se poser un peu et de rĂ©flĂ©chir aux points suivants.

Plus de complexité pour la supervision et le débogage

Quel que soit l’outil utilisĂ©, nous aurons accĂšs Ă  des mesures nous permettant de comprendre son fonctionnement.

Par contre le suivi de bout en bout d’une requĂȘte devient plus complexe et doit ĂȘtre pris en compte dĂšs la phase de design.

Par exemple en utilisant le design pattern correlation id qui consiste Ă  l’ajout d’un identifiant dans chaque requĂȘte pour suivre une transaction de bout en bout dans le SI.

correlationID

Ou en utilisant un APM (Application Performance Management) qui supporte la technologie utilisée.

Plus de complexité lors du développement

En fonction de l’outil choisi et de comment il est configurĂ©, on devra faire attention Ă  :

  • L’ordre des messages n’est pas garanti (solution possible avec ActiveMQ)
  • La possibilitĂ© d’avoir des messages en doublon
  • La prĂ©sence ou non de transaction

Cela implique une autre difficultĂ© : garder une cohĂ©rence Ă  terme (qui dĂ©signe un modĂšle dans lequel la cohĂ©rence n’est garantie qu’à la « fin », la « fin » Ă©tant relative Ă  votre cas d’utilisation).

indempotence

Une bonne configuration et utilisation de l’outil choisi associĂ© Ă  des messages idempotent pourra faire l’affaire dans de nombreux cas d’utilisation.

Bien maütriser l’outil choisi

Les MOM permettent de faire du synchrone et de l’asynchrone.

Par exemple la fonction de failover d’ActiveMQ peut bloquer le producteur. Et donc il faut une bonne connaissance de l’outil pour ne pas tomber dans les piùges.

Attention Ă  ce que le MOM ne devienne pas le SPOF du systĂšme

Un SPOF (Single Point Of Failure) est une brique du systĂšme dont une panne entraĂźne l’arrĂȘt complet du reste. Et donc si on veut un systĂšme rĂ©silient, il faut aussi que notre MOM le soit.

Qui dit asynchrone, dit back-pressure

Lorsqu’on est en synchrone, le producteur est obligĂ© d’attendre que le consommateur rĂ©alise son traitement.

Back pressure

Et donc lorsque la charge va augmenter et si le consommateur ne suit pas, la contention va ĂȘtre au niveau du producteur qui va empiler les tĂąches Ă  rĂ©aliser.

Back pressure

Avec de l’asynchrone, c’est l’inverse, la contention va ĂȘtre au niveau du consommateur, car il va se retrouver avec toutes les tĂąches Ă  rĂ©aliser, car le producteur n’aura pas fait barrage.

Back pressure

 

Et donc il est important de mettre en place une stratégie de back-pressure.

La stratĂ©gie de back-pressure consiste Ă  gĂ©rer la rĂ©action d’un systĂšme en prĂ©sence de charge consĂ©quente dans une chaĂźne de traitement. Sa maĂźtrise et son utilisation permettent d’augmenter la rĂ©activitĂ© et la rĂ©silience des systĂšmes dans des conditions extrĂȘmes.

Par exemple en utilisant la fonctionnalitĂ© de Producer Flow Control d’ActiveMQ.

Attention aux “poison messages” ou Dead Letter

Un “poison message” est un message qui va faire tomber le consommateur.

Par exemple avec un message mal formé ou avec un consommateur bogué qui ne prend pas en charge certains messages (taille, caractÚres non prévus
).

poison message

 

Le message n’ayant pas Ă©tĂ© consommĂ©, lorsque le consommateur sera de nouveau disponible, sera traitĂ© Ă  nouveau avec les mĂȘmes consĂ©quences (crash du consommateur).

poison message

 

Et ainsi de suite.

Encore une fois, une bonne configuration de la solution nous Ă©vitera ce type de problĂšme.

Par exemple en utilisant le mĂ©canisme de Dead Letter Exchanges de RabbitMQ ou de dead-letter queue d’ActiveMQ.

Pas adaptĂ©e Ă  tous les cas d’utilisation, la taille compte La taille du message

Pour des messages de trĂšs grande taille, il est prĂ©fĂ©rable d’utiliser une autre solution (par exemple un ETL ou un batch).

Le nombre de messages dans la file de messages

En plus de la taille des messages il faut ĂȘtre prudent avec leur nombre dans la file de messages. Car si ce nombre augmente trop, il y a un risque de consommation Ă©levĂ© de la mĂ©moire et donc d’un crash.

Pour Ă©viter cela, il y a plusieurs solutions :

  • Augmenter le nombre de consommateurs
  • Bien paramĂ©trer le TTL (Time To Live) des messages
  • etc.

Persister les messages sur disque/base de donnĂ©es, au prix d’une perte de performance, peut Ă©viter de perdre des messages en cas de crash (sauf bien sĂ»r si le disque/base de donnĂ©es crash aussi).

Quelle que soit la solution retenue, une supervision de cette métrique sera toujours utile.

Pour cela il existe plusieurs solutions :

  • Utilisation de la console de supervision intĂ©grĂ©e au MOM (par exemple pour RabbitMQ)
  • Utilisation d’outil de supervision supportant le MOM choisi (par exemple hawtio)
  • Utilisation des API fournis par le MOM
Conclusion

Une des solutions pour implĂ©menter le design pattern Asynchronous data exchanges est d’utiliser un MOM.

Nous avons vu le fonctionnement d’un MOM (point à point, publish/subscribe) et quelques outils.

Petit rappel l’ajout d’un MOM et d’appel asynchrone dans une application n’est pas anodin et donc il faut que cela rĂ©ponde Ă  un vrai besoin.

Cas d’utilisation que nous verrons dans le prochain article.

 

Pour aller plus loin, notre nouveau livre blanc sur le sujet vient de sortir :

TELECHARGER LE LIVRE BLANC

 

Articles suggested :

  1. Circuit breaker, un pattern pour fiabiliser vos systÚmes distribués (ou microservices) : partie 1
  2. Circuit breaker, un pattern pour fiabiliser vos systÚmes distribués (ou microservices) : partie 2
  3. Circuit breaker, un pattern pour fiabiliser vos systÚmes distribués (ou microservices) : partie 3

Catégories: Blog Société

[Session Mensuelle] REX sur une implémentation SAFe

Agile Nantes - mar, 11/29/2016 - 11:16
Ce mois-ci, c’est l’implĂ©mentation SAFe qui est Ă  l’honneur avec un speaker venu directement du QuĂ©bec pour l’occasion Venez nombreux pour dĂ©couvrir et approfondir vos connaissances sur le sujet ! RĂ©sumĂ© Si l’agilitĂ© Ă  grande Ă©chelle vous intĂ©resse et que vous souhaitez comprendre SAFe et ses applications concrĂštes, nous vous invitons Ă  cette session dĂ©diĂ©e [...]
Catégories: Association

Testez vos invariants avec Scalacheck

Nous en sommes tous convaincus, le TDD, c’est bien ! Seulement, il nous arrive parfois de ne pas trouver la granularitĂ© de test adaptĂ© au besoin : 1 par cas d’utilisation, 1 par fonctionnalitĂ©… Existe-t-il un cas « nominal reprĂ©sentatif » ? Pour certains algorithmes, les tests unitaires « simples » ne suffisent pas. Je vous propose ici de dĂ©couvrir une nouvelle approche du test unitaire : le « property-based testing » ou « test d’invariants ». C’est une forme de test rĂ©pandue dans le monde de la programmation fonctionnelle grĂące Ă  son approche formelle.

Scalacheck est un framework de test de l’Ă©cosystĂšme Scala. Il est le petit frĂšre de Quickcheck, Ă©crit en Haskell. Son approche de test n’est pas sans rappeler les tests paramĂ©triques de JUnit. Il s’agit de crĂ©er des tests de « haut niveau » plutĂŽt qu’un test unitaire par branche d’algorithme. Ces tests apportent une couverture plus Ă©levĂ©e (voire exhaustive) et apportent un niveau de confiance Ă©levĂ© du code testĂ©. Dans un objectif de documentation et mĂȘme de spĂ©cification du code au travers de tests, le property-based testing apporte une nouvelle forme d’expressivitĂ©. On tentera de prouver la validitĂ© d’un algorithme non pas au travers de scĂ©narios passants mais par le respect d’invariants.

Contrairement Ă  JUnit, ScalaCheck vient avec une batterie de gĂ©nĂ©rateurs de valeurs pseudo-alĂ©atoires. Cela donne la possibilitĂ© au dĂ©veloppeur de gĂ©nĂ©rer des jeux de tests pour la description d’invariants.
Je vous propose ici un retour d’expĂ©rience sur l’utilisation de ce framework pour un projet qui gĂšre des orchestrations de dĂ©ploiement d’application.

Scalacheck est donc un outil de test capable de gĂ©nĂ©rer des valeurs et d’exprimer des contraintes afin de dĂ©crire des invariants. L’approche se nomme en anglais « property-based testing ». Par « propriĂ©tĂ© », il faut comprendre ici « invariant ». Un invariant est une rĂšgle intangible et assurĂ©e en toutes circonstances. Prenons pour exemple la fonction trim (suppression des espaces aux extrĂ©mitĂ©s) sur une chaĂźne de caractĂšres. Si on compare la longueur de la chaĂźne avant et aprĂšs l’opĂ©ration trim, il paraĂźt logique de dire que la chaĂźne aprĂšs l’opĂ©ration est Ă©gale ou plus courte que sa source :

val s: String = ...
s.trim().length should be <= s.length

Nous voyons bien que cette rĂšgle doit tenir quelle que soit la valeur de s. La dĂ©marche ici s’apparente Ă  la recherche de preuves en mathĂ©matiques. C’est une des raisons qui fait que ce type de tests existe dans l’univers Haskell.
Cela vient de la volontĂ© de s’approcher d’une preuve formelle pour dĂ©montrer que l’algorithme fonctionne. Cette dĂ©marche est rendue possible si l’on respecte la « puretĂ© » des fonctions. Cela a son importance, nous allons vite le voir.

Domaine de définition et preuve formelle

Le domaine de dĂ©finition d’une fonction reprĂ©sente l’ensemble des valeurs possibles que la combinaison des paramĂštres en entrĂ©e peut prendre. L’ensemble des valeurs d’arrivĂ©e d’une fonction est appelĂ© codomaine.

Prenons l’exemple d’une fonction pure qui prend en entrĂ©e un boolĂ©en. Un boolĂ©en possĂšde deux valeurs, TRUE ou FALSE. Si cette fonction est dite « pure », sa valeur de sortie ne dĂ©pend que du paramĂštre en entrĂ©e. Il est donc trivial de mettre en place un test unitaire qui vĂ©rifie l’intĂ©gralitĂ© du domaine de dĂ©finition de la fonction.
Le test de l’intĂ©gralitĂ© du domaine de dĂ©finition nous apporte la preuve formelle que le code fonctionne comme attendu dans TOUS les cas possibles.

Si je travaille maintenant sur une fonction avec deux boolĂ©ens en entrĂ©e, le domaine de dĂ©finition comprend 4 valeurs qui sont toutes les combinaisons de deux boolĂ©ens. Obtenir la preuve formelle reste accessible. Mais il faut bien dire qu’en dehors des types Ă  faible cardinalitĂ© (Enum, BoolĂ©en…), la tĂąche est impossible.
Dans la pratique, on ne peut tester tous les cas possibles, on se contentera alors de prouver que la fonction n’est pas fausse pour une partie du domaine.

Prenons l’exemple d’une fonction de concatĂ©nation de chaĂźnes de caractĂšres. Ci-dessous un test unitaire tout Ă  fait raisonnable :

test("concat"){
 val left = "abc"
 val right = "def"

 left + right should be("abcdef")
}

Le domaine de dĂ©finition de la fonction est sans limite thĂ©orique Ă  cause des chaĂźnes de caractĂšres. Avec ce test, j’ai prouvĂ© que mon code n’est pas faux pour une seule combinaison ("abc";"def"). Impossible ici d’avoir la preuve formelle par un test automatisĂ© que l’algorithme est correct. Mais que dire d’autres cas comme ("";""), ("a";""), ("";"1")…
Il y a bien sĂ»r une infinitĂ© de combinaisons Ă©quivalentes qui n’ont pas d’influence sur l’algorithme. Mais ce qui est intĂ©ressant c’est l’Ă©tude de quelques cas aux limites. L’utilisation d’outils comme Scalacheck va permettre de systĂ©matiquement travailler sur les cas particuliers pour nous aider dĂ©velopper une implĂ©mentation correcte.

Comment tester les invariants

Le but de tester des invariants est de s’assurer que, pour un grand nombre d’exemples du domaine de dĂ©finition d’une fonction, le code est correct. Pour ce faire, on va dĂ©lĂ©guer Ă  Scalacheck le soin de gĂ©nĂ©rer des valeurs de test. Scalacheck fourni des gĂ©nĂ©rateurs prĂ©dĂ©finis pour les types de base, les chaĂźnes de caractĂšres en font partie.

Reprenons notre test de concatĂ©nation. On note rapidement que les valeurs dans left et right ne sont pas intĂ©ressantes pour la comprĂ©hension du test. Avec Scalacheck et son intĂ©gration dans l’excellent Scalatest, la structure du test ressemble Ă  cela :

forAll(Gen.alphaStr: Gen[String], Gen.alphaStr: Gen[String]) {
  (left: String, right: String) =>
 //tester l'invariant ici
}

J’ai ajoutĂ© ici le type des variables pour expliquer le rĂŽle de chacune. Gen.alphaStr est un gĂ©nĂ©rateur de chaines alpha-numĂ©riques. J’ai deux valeurs Ă  tester, j’ai donc deux gĂ©nĂ©rateurs sĂ©parĂ©s. Les valeurs gĂ©nĂ©rĂ©es sont utilisables dans le corps de la fonction. Il suffit ensuite d’y implĂ©menter notre test. On pourrait lire ce test en français :

*Pour toute chaĂźne de caractĂšres «left» et toute chaĂźne de caractĂšres «right», alors …*

Mais quelles sont les assertions? Il ne faut surtout pas rĂ©Ă©crire l’implĂ©mentation dans le test. Il est donc interdit de concatĂ©ner les chaĂźnes dans le code pour vĂ©rifier la valeur de la chaĂźne en sortie. Tester les invariants demande un peu plus de recul. Il faut plutĂŽt se demander quelles propriĂ©tĂ©s sont continuellement admises par l’opĂ©ration de concatĂ©nation. On peut tester que la longueur de la chaĂźne de rĂ©sultat est strictement supĂ©rieure Ă  la longueur de left, qu’elle commence bien par left, et se termine par right.

forAll(Gen.alphaStr, Gen.alphaStr) {
  (left, right) =>
    val result = left + right

    result should startWith(left)
    result should endWith(right)
    result.length should be > left.length
}

Au premier abord, cet invariant semble correct. Si je l’Ă©value de tĂȘte avec «abc» et «def», il fonctionne. Mais en le lançant, il Ă©choue :

Message: 0 was not greater than 0
Occurred when passed generated values (
  arg0 = "",
  arg1 = ""
)

En effet, si « right » est vide, la troisiÚme condition du test est fausse. Corrigeons le test :

forAll(Gen.alphaStr, Gen.alphaStr) {
  (left, right) =>
    val result = left + right

    result should startWith(left)
    result should endWith(right)
    result.length should be >= left.length
}

La dĂ©marche qu’impose Scalacheck permet de voir ses algorithmes d’une autre maniĂšre. Il tire vraiment toute sa puissance sur des structures de donnĂ©es plus complexes. Voyons comment le mettre en place sur un projet de la vraie vie.

Un cas de la vraie vie

Nous sommes dans le contexte d’une application de gestion de dĂ©ploiement. Voici les grandes notions fonctionnelles :

  • un dĂ©ploiement est un plan composĂ© de blocs
  • un bloc est une structure composite qui peut contenir d’autres blocs (CompositeBlock) ou une liste de tĂąches (StepBlock)
  • une tĂąche (Task) est un script Ă  exĂ©cuter

Cette structure composite nous permet de voir un dĂ©ploiement comme un arbre. Les blocs sont des nƓuds et les tĂąches des feuilles. Une tĂąche peut possĂ©der un tag qui correspond Ă  un groupe de serveurs sur lequel la tĂąche va ĂȘtre exĂ©cutĂ©e.

Pour des raisons d’optimisation de dĂ©ploiement, on souhaite pouvoir envoyer sur le serveur le plus grand nombre de tĂąches consĂ©cutives en une seule fois. Pour cela, nous devons faire remonter les tags des tĂąches vers les blocs.

La story nous a été présentée avec deux cas fonctionnels différents :

  • Si toutes les tĂąches d’un mĂȘme StepBlock contiennent le mĂȘme tag, ce bloc porte lui aussi le tag
  • Si tous les blocs d’un mĂȘme CompositeBlock possĂšdent le mĂȘme tag, ce bloc porte lui aussi le tag

Les cas sont relativement simples mais la combinatoire est Ă©levĂ©e de par la nature de la structure en arbre. Quels sont les invariants de ce systĂšme ? À partir des rĂšgles et du schĂ©ma ci-dessus on en trouve au moins deux :

  • Si un bloc a un tag, alors tous ses fils le possĂšdent aussi
  • Si un bloc n’a pas de tag, les fils ne possĂšdent pas de tag en commun

Il nous faut maintenant mettre en place les tests associés.

Développer un générateur personnalisé

Une instance de Task contient un attribut « tag » qui est une chaĂźne de caractĂšres. Scalacheck vient avec plusieurs gĂ©nĂ©rateurs de base qu’il est possible de rĂ©utiliser. J’utilise donc ici un gĂ©nĂ©rateur de chaine de caractĂšres pour le tag. En le combinant avec la mĂ©thode map, je crĂ©e un gĂ©nĂ©rateur de Task.

def tags: Gen[String] = Gen.listOfN(10, Gen.alphaNumChar).map(_.mkString)
def tasks: Gen[Task] = tags.map(tag => Task(tag))

tasks est un gĂ©nĂ©rateur de Task. Vous pouvez le tester en appelant tasks.sample. De la mĂȘme maniĂšre, par composition, je peux avoir un gĂ©nĂ©rateur de StepBlock.

def stepBlocks: Gen[StepBlock] = Gen.nonEmptyListOf(tasks).map(taskList => StepBlock(taskList))

Pour un CompositeBlock, le cas est diffĂ©rent car la structure est rĂ©cursive. Il nous faut un gĂ©nĂ©rateur de Block et de CompositeBlock, sachant qu’un CompositeBlock contient des Blocks.

def blocks: Gen[Block] = Gen.oneOf(stepBlocks, compositeBlocks)

def compositeBlocks: Gen[CompositeBlock] = Gen.nonEmptyListOf(blocks).map(blockList => CompositeBlock(blockList))

Mais un problĂšme se pose. Cette gĂ©nĂ©ration pseudo-alĂ©atoire a de fortes chances de ne jamais terminer Ă  cause de cette rĂ©cursion. Encore une fois, Scalacheck possĂšde les bons outils. Il faut changer le gĂ©nĂ©rateur de CompositeBlock pour ĂȘtre sĂ»r qu’il converge, car c’est lui qui porte la rĂ©cursivitĂ©.

def compositeBlocks: Gen[CompositeBlock] = Gen.sized { size =>
  for {
    convergenceRate <- Gen.choose(0, size)
    nextIterationSize = size / Math.max(1, convergenceRate)
    convergingGenerator <- Gen.resize(nextIterationSize, blocks)
    blockList <- Gen.listOfN(size, convergingGenerator)
  } yield new CompositeBlock(blockList)
}

En assemblant toutes ces briques, j’ai maintenant Ă  disposition un gĂ©nĂ©rateur Ă©voluĂ© d’objets, capable de gĂ©nĂ©rer des cas de tests complexes et variĂ©s.
S’il est possible d’indiquer le nombre de valeurs gĂ©nĂ©rĂ©es souhaitĂ©, avec Gen.listOfN par exemple, il est souvent souhaitable de laisser Scalacheck proposer des valeurs sensibles. C’est ce qui a Ă©tĂ© fait dans l’exemple ci-dessus. En utilisant le combinateur Gen.sized, on peut rĂ©cupĂ©rer le paramĂštre fourni par Scalacheck pour gĂ©nĂ©rer la liste de blocks. L’appel Ă  Gen.resize(nextIterationSize, blocks) nous permet de mettre Ă  jour ce paramĂštre de taille afin de le faire converger. On remarquera aussi que le facteur de convergence est choisi alĂ©atoirement lui aussi afin de varier la forme et la profondeur de l’arbre.

Un petit exemple :

//Generating tasks
scala> tasks.sample.get
res2: Task = Task(nBsgcqhzex)

//Generating stepBlocks
scala> stepBlocks.sample.get
res9: Block = StepBlock(List(Task(7ldqHh2svr), Task(ndglgv8gtC), Task(xcwarjN3kj), Task(snc6eeyXul)))

//Generating blocks
scala> blocks.sample.get
res13: Block = StepBlock(List(Task(dpvKbGgoce))

scala> blocks.sample.get
res14: Block = 
CompositeBlock(
 List(
  StepBlock(List(Task(dpvKbGgoce))), 
  StepBlock(List(Task(iuqfaQIJSD),Task(qqsdqccgZE)))
 )
)

Reste maintenant Ă  Ă©crire notre test :

forAll(blocks)(checkTagRecursively)
 
private def checkTagRecursively(block: Block): Unit =
  block match {
    case CompositeBlock(blocks, Some(tag)) =>
      val blockTags = blocks.map(_.tag).toSet
      assertCommonTag(blockTags.flatten, tag)
      blocks.foreach(checkTagRecursively)

    case CompositeBlock(blocks, None) =>
      val blockTags = blocks.flatMap(_.tag).toSet
      assertNoCommonTag(blockTags)
      blocks.foreach(checkTagRecursively)

    case StepBlock(tasks, Some(tag)) =>
      val taskTags = tasks.map(_.tag).toSet
      assertCommonTag(taskTags, tag)

    case StepBlock(tasks, None) =>
      val taskTags = tasks.map(_.tag).toSet
      assertNoCommonTag(taskTags)
  }

private def assertCommonTag(tags: Set[String], tag: String): Unit =
  tags should be(Set(tag))

private def assertNoCommonTag(tags: Set[String]): Unit =
  tags.size should not be 1
Conclusion

Ce test nous a permis de tester un ensemble de rĂšgles sur des jeux de donnĂ©es variĂ©s. Hormis la construction du test, ce mode de pensĂ©e nous a amenĂ© Ă  prendre du recul sur la fonctionnalitĂ© dans son ensemble et ainsi avoir une solution plus simple et plus complĂšte qu’en accumulant les cas les uns aprĂšs les autres.

Cependant, la courbe d’apprentissage du framework est plutĂŽt difficile. Il faut se familiariser avec les diffĂ©rents gĂ©nĂ©rateurs de base et apprendre Ă  les composer.

On notera Ă©galement que la gĂ©nĂ©ration des valeurs n’est pas totalement alĂ©atoire. Le moteur de Scalacheck choisit en effet des valeurs « remarquables » (chaine vide, 0, -1, Int.MAX_VALUE…) pour tester rapidement les cas aux limites. Les messages d’erreurs fournies sont parfois cryptiques mais fournissent le jeu de donnĂ©es (gĂ©nĂ©rĂ©) qui a causĂ© l’Ă©chec du test ce qui permettra de facilement le reproduire.

Ce type de test n’est pas applicable partout et ne devrait pas ĂȘtre utilisĂ© systĂ©matiquement Ă  cause de sa complexitĂ© accrue. Cependant, si vous sentez que les cas testĂ©s ne sont pas reprĂ©sentatifs de la fonctionnalitĂ©, il peut ĂȘtre intĂ©ressant de tenter une approche par test d’invariant.

Pour aller plus loin, je vous conseille vivement le livre suivant: Scalacheck: The Definitive Guide.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux