Catégorie : Conférence

RivieraDev 2018 : le débrief

RivieraDev s’est agrandie cette année avec une journée supplémentaire le mercredi pour une journée « deep dive » elle a permis de placer deux conférences qui approfondissent un sujet en particulier.
Les grands thèmes présents cette année ont été le Machine Learning, le devops-cloud-containers et l’architecture applicative en général et le développement web (JS). Cette orientation devops vient en partie du fait que le sponsor principal est Red Hat. Lequel a disposé d’une track « JUD Con » le long de ces 3 journées.
Les grands thèmes presque totalement absents furent Java ( :’-/ ) , et l’agilité.

Mercredi 16 mai : Journée Deep-Dive, machine learning

FROM 0 TO DEEP LEARNING IN 3 HOURS

YANNIS BRES twitter

Une grosse séance d’introduction au Deep Learning. Qui commence calmement avec des définitions et finit dans les dérivées partielles de fonctions intégrales.

La différence entre les systèmes experts et le deep learning est que le premier dépends du déterminisme d’un ensemble de règles préétablies alors que le deuxième est plus défini de manière floue (d’où l’accident survenu récemment)

le pionnier : la reconnaissance de caractères

La première application des réseaux de neurones fut la reconnaissance de caractères (code postaux et chèques).

La charnière a été en 2012. Avec le type de réseaux constitutionnels qui avaient le meilleur résultat de reconnaissance d’images de la base imagenet.
puis, la marge d’erreurs (< à 2%) est passée sous la marge d’erreurs d’un humain.
Aujourd’hui, la reconnaissance d’objet sur video (après apprentissage) fonctionne sur raspberry, la reconnaissance vocale et la modélisation (imitation) de voix devient presque parfaite.

l’accélération : GPU et Big Data

La première chose qui a permis d’accélérer les capacités de calculs plus vite que les CPU sont les GPU. (architectures plus spécifiques : plus de cœurs, accès mémoire plus rapide). Ils permettent les calculs massivement parallèle avec le General Purpose Computing sur les GPU.

La deuxième chose est la capacité à accumuler du big data pour permettre les apprentissages efficaces.

Systèmes « experts »

Accumulation de règles « if… then… else » : trouve ses limites dans un environnement complexes et imprévisibles.

Artificial Intelligence

Quand une machine semble prendre des décisions qui ressemblent à de l’intelligence.

Machine Learning :
Mise en place de méthodes génériques qui crée seules les règles de décision.
Les outils utilisés sont : les neurones, la forward et la backward propagation, l’architecture des neurones entre eux, l’entrainement dédié et le transfert d’apprentissage (reconnaissance de chiens sert à la reconnaissance de chats).

Deep Learning :
Le data scientist cumule les compétences de matheux, statisticiens, visualisation, communication, en accumulation, nettoyage et réorganisation de données. La promesse du deep learning est de traiter les données comme un data scientist.

Big data pipeline :
Synthétiquement :

  • acquisition -> curation -> storage -> ETL -> analysis -> training -> prediction -> rince -> repeat -> in line (streaming) et off line (batch) -> visualisation (oui, quand même).

Machine learnings

Le Supervised Learning par exemple avec la « regression » d’un ensemble d’input pour donner un output chiffré ou un label. (« spam » pour un mail), c’est à dire une classification.
L’ Unsupervised learning : recherche de cohérence automatique.
Par exemple le moteur de recommandation, clustering pour la catégorisation dans Google News utilisant le Mlib appelé K-Means algo, recommendation d’achats, dimension reduction.
Le Reinforcement learning : attribution de note ou de points en récompense de bonnes décisions. Exemple de la maximisation d’un score de jeu.

Python

Le langage de prédilection est Python parce que :

  • c’est du haut niveau, sans beaucoup de cérémonies.
  • le notebook jupyter est pratique pour mettre en oeuvre le langage.
  • c’est un langage non typé statiquement, interprété donc lent et plante au runtime. 🙂
  • ce qui est pratique, c’es le support des List, tuple, tableau multidimensionnels et surtout les slices (tranches de tableaux)
  • ce n’est pas un langage confidentiel (large communauté, open-source), il dispose d’un package manager.

Mise en oeuvre

La Regression linéaire (même concept que le « reduce » de « Map Reduce »).
Prenons l’exemple de l’estimation de la valeur immobilière d’un bien. On prends les différents paramètres du bien mais pour l’exemple, uniquement la superficie.
On dispose d’un training set : un tableau à deux entrées avec des entrées statistiques faisant correspondre une superficie et un prix.
On utilise Panda ou NumPy pour effectuer les calculs. avec les methodes polyfit ou poly1d.
Imaginons que le programme de ML suppose une ligne graphique, issue de la « cost » ou « loss » function qui permettra de mesurer la distance globale entre la réalité et la fonction de courbe supposée (calculée).

descente de gradient

La descente de gradient est une méthode itérative qui est la plus utilisée actuellement pour la recherche d’une modélisation.
On va effectuer une descente de « gradient » en utilisant les dérivées partielles de chaque variable et en les jouant sur tous les points de la courbe supposée. Les résultats de plusieurs itérations font varier la supposition, ces résultats permettrons de fournir la meilleure courbe supposée.
Les variations entre plusieurs suppositions est le « learning rate » : plus il est petit, plus c’est cher à calculer mais précis; plus il est grand, plus c’est rapide mais imprécis.

forward propagation

La forward propagation est la progression de la recherche du meilleur résultat à la fin de l’utilisation du learning rate.
Ce learning rate est utilisé au moment où on effectue la forward/backward propagation en changeant les gradients sur les paramètres.
On surveille l’asymptote de la cost function pour trouver la solution optimale.

Autre exemple : la base MNIST de 70000 chiffres écrits à la main.
On réduit la matrice de pixel 28×28 en un vecteur de 784 pixels.
La comparaison entre le chiffre deviné et le vrai est fait avec une fonction « softmax » qui renvoie des probabilité dont la somme est à 1.
La mesure de la précision est faite en comparant le nombre de succés sur la population totale.

TensorFlow

TensorFlow est le framework le plus utilisé, exploité commercialement par Google.

  • les placeHolders : les données en input.
  • les variables : ce que TF va essayer de trouver.
  • la vectorisation des calculs : « matmul » multiplication de matrices.
  • tf.reduce_mean(tf.nn.softmax_cros_entropy_with_logits( labels=Y, logits=Y_ )) où les « logits » sont les « prédictions »
  • définition de l’optimizer (= tf.train.GradientDescentOptimizer(alpha)), du step (= optimzer.minimize(J))
  • Le nombre d' »epoch » est l’ensemble des itérations qui effectue la forward ou Backward propagation. la variable NB_EPOCHS est utilisées dans une boucle for. Celle-ci execute le session.run( step, feed_dict ).
  • il est possible d’introduire un biais.

Deep Neural Network

Les opérations précédentes (softmax) sont répètées en réintroduisant un biais aléatoire à chaque fois.
chaque neurones refléchie avec :

  • une somme pondérée
  • un biais
  • une fonction logistic sigmoid de descente de gradient, à la place on peut utiliser une Relu (reduced linear) qui est moins couteuse en calcul.

Dans la vraie vie on divise les epochs en plusieurs batchs. On utilise aussi le le learning rate adaptif de différentes sortes. (SDG,…)
Malheureusement, il n’a pas eu à combattre l’overfitting car il était déjà 12h22…

 

 

FAST DATA PROCESSING PIPELINE FOR PREDICTING FLIGHT DELAYS USING APACHE APIS: KAFKA, SPARK ML, DRILL, WITH MAPR-DB JSON

CAROL MCDONALD twitter et TUGDUAL GRALL twitter

Le but du projet présenté : End to End distributed Pipeline for sort of Big Data, Kafka, SparkML, MapR : Machine Learning.

Carol a présenté son travail également en trois articles sur le site de MapR.

C’était une présentation en deux parties :

  1. La première partie concerne la construction d’un modèle de prédiction de délai de départ de vols « Real-Time Flight delay prediction ». Elle utilise Spark sur HBase pour affiner et conclure un modèle de prédiction par une méthode itérative.
  2. La deuxième partie fait la démonstration de l’utilisation du modèle de prédiction précédent dans un contexte temps réel par l’utilisation de Streams.

Construction du moteur de prediction

MapR organise le stockage en format HDFS et a forké Spark et Drill pour spécifiquement utiliser MapR et en faire une distribution complète opensource.

Dans Spark 2, le RDD est remplacé par le « DataSet » et est composé lui-même de DataFrame : les « tables ».

Dans un premier temps, il est pratique d’utiliser Zeppelin Notebook pour commencer un projet Big Data en dehors d’un IDE, Zeppelin permet de s’affranchir d’un IDE, d’autan que cette phase est normalement dévolue à un data scientist « non développeur » qui cherche à éviter les IDE dans la mise en œuvre de leurs recherches.
C’est le même esprit que Jupyter Notebook.

Zeppelin

Un projet Zeppelin permet d’attaquer un cluster spark/HBase :

  • en SQL avec des résultat en tableau ou en graphes.
  • en Scala pour mettre en oeuvre des filtres avant requêtes.

Sur Zepellin, l’exploration de données se fait en SQL c’est à dire en remplacement de Excel :-p, soit pour concevoir les projets d’analyse.

pipeline spark

Le Pipeline Spark est composé d’une séquence de traitement :

  1. Transformer pour mapper une colonne dans un nouvel DataFrame
  2. StringIndexer pour filtrer
  3. OneHotEncoder qui fait aussi partie du Transformer
  4. ensuite DecisionTreeClassifier
  5. enfin un *Evaluator pour comparer les prédictions et un jeu de test

Enfin, les iterations permettrons de diminuer l’écart entre les prédictions et le jeu de test.

Ce workflow permet de créer le modèle de prédiction et de le stocker sous forme de format de stockage Parquet (format compressé, distribué, pour une lecture rapide, mais non modifiable)

Utilisation du moteur de prédiction

MapR Streams est un outils de traitement de données en streaming distribué.

Le but ensuite est d’utiliser ce modèle en « temps réel » (d’un point de vue business) en mode streaming en Utilisant MapR Streams et Kafka. Kafka permet en tant qu’intermédiaire d’exposer les streams à éventuellement plusieurs consommateurs.
Dans le cas de données contenues dans un fichier stocké sur disque, on utilise ProducerRecord qui lit chaque ligne d’un fichier et le projette dans un topic Kafka. Spark va consommer ce topic Kafka avec ses DStream.

Le contexte est celui où le volume à traiter ne tient pas sur un seul serveur. Le besoin est celui d’une base distribuée. Alors on parle de « grosses » databases. Ainsi on peut faire des requêtes SQL sur ces données.
C’est possible avec Apache Drill, avant de monter un projet de développement d’application assis sur ces données.

DRILL

Drill permets d’interfacer n’importe quel type de data avec ou sans Schema, avec un front SQL, une API JDBC ou REST.

Drill est téléchargeable et exécutable en standalone avec ./drill-embedded
exemple :

select * from file.json.gz where ...

  • Il peut se poser en intermédiaire d’accès aux données hétérogènes dans la même requête car il supporte un système de table virtuelle ou des « vues ».
  • Il possède des extensions à SQL-ANSI pour traiter les données répétées. (FLATTEN, KVGEN, …)
  • Drill est 100% java. il peut aussi requêter des fichiers LOGS (Clever cloud l’a montré).
  • Drillbit : installé sur chaque shard d’une base distribuée. il forme alors un cluster de drill.
  • Drill cible l’un des noeuds et tous les Drillbit s’organisent pour répondre ensemble à la requête.
  • Drill sert uniquement à l’interactif : discovery et analyse de data et BI. Il n’est pas fait pour la montée en charge comme moteur de DB pour de l’opérationnel.

NB: Drill ne fait pas de continuous query (recordset ouvert sur un stream) comme peut le faire Apache Flink.
Par ailleurs Flink est plus orienté java que scala.

storage

Kafka (et MapR Streams) peut être utilisé au delà du messaging en tant que store accessible par requêtes.

HBase sur JVM utilise HDFS qui est aussi sur sa JVM, lequel écrit finalement sur le File System. Pour simplifier ce burger, MapR écrit sur le File Sytem. d’une manière compatible HDFS car très très proche d’HBase.

Dernier conseil : Considérer un moteur nosql qui puisse se connecter avec Spark, Drill, Hive,…

 

Jeudi 17 mai : Conférences et Talks

LES DESSOUS D’UN EMBARGO DE SÉCURITÉ

STEPHEN KITT twitter

Stephen, par son activité de développeur Debian, maintient plusieurs paquets et suit de très près les patchs de sécurité à mettre en oeuvre.
Il a présenté très clairement les conséquences d’une découverte d’une faille de sécurité. Notamment les conditions de divulgations de cette faille à un public restreint pour une période limitée dans le temps.
Cet aspect de divulgation soulève des questions de confiance, qui peuvent être réglé par la contractualisation lorsque l’enjeu le justifie.

SURPRISE DU CHEF !

QUENTIN ADAM twitter

Avec le talent d’orateur qu’on lui connait, son talk parlait de l’évolution des technologies, le fait qu’une technologie chassant une autre, la documentation de l’infrastructure et de l’architecture logicielle peut se perdre par obsolescence. Il propose alors de monter d’un niveau dans l’abstraction et mettre en place un  système de documentation des briques de notre infra par assemblage de concepts agnostique : des nœuds, (les serveurs de DB, d’applications) , relié par des liens (la couche réseaux). Le but est garder un fil rouge qui nous guiderait lors de la maintenance en cas d’incident mais aussi lors de migration de technologies.
De plus il propose que ces informations soient portés par des fichiers de configuration dédiés, rédigés dans un DSL conçu spécifiquement dans ce but, en cours de publication, et présenté par ailleurs lors de cette édition du Riviera dans un talk sur la description de dépendances de services sémantique. (talk auquel je n’ai pas pu assisté 🙁 )

MIXOLOGY OF TECHNOLOGY IN YOUR APPLICATIONS

STEVEN POUTSY twitter

Steven Pousty s’intéresse aux architectures logicielles et dans son talk fort guilleret, il a mené une discussion sur les questions soulevées par les grands choix d’architecture. Il laisse chacun à ses réflexions au final.

Un premier message est qu’il ne faut pas céder aux sirènes de la « hype » sur une techno ou une autre. Et se livrer à une introspection :

Si je me lance dans une migration vers ce nouveau framework, est-ce utile pour le projet ou seulement pour moi ? est-ce une question de comfort parce que je veux éviter de choisir un autre framework plus complexe ?

Parfois la techno la plus cool n’est pas le meilleur choix, pourquoi devoir être à la mode ?

Pourquoi ne pas prends une techno que je connais et sur laquelle je suis productif ?

Dois-je prendre un outil surdimensionné et difficile à mettre en oeuvre pour une tache modeste qui ne le mérite pas ?

le « besoin » d’une technologie est différent du « désir » d’une technologie : le besoin exige des sacrifices (apprendre, expérimenter, échouer) dans l’adoption, le désir d’adopter une techno sans besoin est souvent inutile.

Le deuxième message concerne la maintenance logicielle :

Si vous avez un monolithe : laissez le tout seul, n’y touchez plus : vous créerez plus de valeurs ailleurs avec moins d’efforts et de risques.

 

 

CONTAINERS PATTERNS

MARIO LORIEDO twitter

Mario a présenté une « typologie de topologie » de containers. Il en a identifié 14 sur son github.
Il travaille sur Openshift et Eclipse Che qui est l’éditeur intégré dans Openshift.

Du temps de la hype docker, différents patterns émergent selon la manière de builder et déployer les containers.
3 catégories :

  1. patterns de développement,
  2. patterns d’exécution,
  3. patterns de distribution.

 

Quelques exemples :

MS : Mount Sources (de type développement)

Lancer un container et à ce moment partager un dossier de la machine dans le container avec un mount. Permet de changer à la volée le code source et qu’il soit exécuté avec le runtime du container précédemment lancé. Ainsi ce n’est pas une bonne pratique en production.
Mario montre comment avec l’appli : github/gabrielcirulli/2048 et en utilisant $docker run avec -v.

DYT : Dockerize Your Tools (de type développement)

Son exemple permet de faire tourner maven en remplaçant mvn avec un alias qui lance docker run. Grâce à l’image officielle maven (3.3.3 par exemple). Permet de lancer des outils d’une autre version que celle installée sur le poste du développement. Sans avoir à changer la version locale.

Pro-Tip : créer un alias pour docker ps …. et utiliser l’option –uid avec laquelle on peut lancer le container en tant qu’un user qui possède les bons droits dans le dossier local monté dans le docker.

CL : Containers launcher (type runtime et distribution)

Une commande unique docker « run » lance les différents docker dépendants (mongo + App).

Un fichier Dockerfile.launcher qui build à partir de l’image Alpine avec un autre docker installé dans l’Alpine.
Ce container lance des scripts qui lancent d’abord le container mongo puis le container d’application.
à la fin du lancement, le premier container « Launcher » s’éteint.
Ceci remplace de manière plus flexible docker compose, c’est l’intérêt. C’est plus simple et plus transparent pour une topologie simple.

HS : Host Spoofing (type runtime)

C’est l’exécution pour avoir des informations du host à partir du container lancé.

docker run --pid=host --uts=host --ipc=host --net=host -v/:/hostfs/

Il peut être utile ou nécessaire de voir tout le host à partir du container, afin de monitorer le host. On peut avoir besoin de l’adresse IP du host. Attention, Apparmor empêche ceci. C’est donc une mauvaise pratique 🙂 sauf dans des situations exceptionnelles où la config du container doit changer en fonction des ressources du host.

S2I : Source to Image (type dev et runtime par excellence)

une image JRE + maven et une deuxieme avec la JRE sans Maven. c’est un Dockerfile avec deux FROM.
Le premier prépare une image qui sera copiée dans la deuxième image au moment de son build. ça s’intègre très bien avec le dockerhub, en mettant ce Dockerfile sur git.

 

BRINGING ORDER TO THE CHAOS WITH ECLIPSE VERT.X

PAULO LOPES twitter

Paulo est contributeur pour Red Hat sur Vert.X. Sa présentation est disponible sur son github.
C’était une demo avec l’application « Pong As A Service » : dans une page web, on joue au pong contre un robot qui utilise websocket pour renvoyer la balle.

« shits happen… »

D’abord il rappelle que errare humanum est.
exemples :

  • 1987 wall street crash aggravé par une sorte de DDOS (too much selling orders) coût = 500 billion $ sur la seule journée.
  • 1993 : Pentium division bug : coût = 475 million $
  • 1999 : le bug y2k : coût = 500 billion $
  • 2018 : Spectre / meltdown, le coût sera de ?

Les problèmes ne sont jamais prévisibles, surtout les plus graves.

Chaos Engineering

Il a présenté le concept de Chaos engineering qui cible le contexte de PRODUCTION.

1. On fabrique des hypothèse sur la base du Steady State Behaviour.
2. On fait varier les évènements issus du Monde Vrai.
3. On exécute les expériences en production.
4. On automatise ces expériences continuellement.
5. On tend à minimiser le blast radius.

Ce Chaos engineering exige la conception d’un plan B de production pour faire face aux :

  1. bugs
  2. attaques ddos
  3. pannes de network
  4. machine crashes

Reactive Manifesto

La réponse à ce processus mène vers le Reactive Manifesto :

  • responsive
  • resilient.
  • elastic
  • message driven

Paulo rappelle qu’actuellement seulement Vert.X and Akka ont toutes ces caractéristiques. Il considère que les nouveautés réactives de Spring 5 sont « seulement » responsive car Spring WebFlux n’est pas « message driven ».

en démo : démarrage de openshift = oc cluster up; déploiement avec mvn clean fabric8:deploy.

Tooling

Comment s’équiper : les outils populaires sont :

  • netflix/chaosmonkey : mais des instances de cloud et une carte bancaire sont nécesssaires 😉
  • l’alternative : alexei-led/pumba : plus facile à monter sur des containers locaux. Utilise docker (image gaiadocker/iproute2) to simulate network outages. Avec l’option –kill permet de tuer aléatoirement des process et simuler des crashes
  • wg/wrk pour évaluer les latences et les pannes HTTP. Permet de tester les DDOS par bombardement soignés.
  • iproute2 disponible dans les repos des distributions Linux. c’est la commande « ip ».

Réduction des dégâts

Comment minimiser le souffle de l’explosion, le blast radius ?

  1. have fallback plan
  2. éviter l’application monolithe.
  3. déployer sur différents sites.
  4. Utiliser le pattern circuit breaker.
  5. Lire le awesome-chaos-engineering.
  6. be creative ! il n’y a pas de formule magique…

 

RECOMMANDATION & ELASTICSEARCH

MATHILDE LEMÉE twitter

Mathilde Lemée est actuellement CTO de jolimoi.com. Elle a cependant parlé de son expérience sur un chatbot de recommandation de vins.
Or, les recommandations sont critiques dans un process de vente :

amazon : 35%. des ventes en 2014.

Netflix :

  • « Top video NRanker »
  • « Tendances récentes »
  • « Continue Watching »
  • « parce que vous avez regardé… »

user based

le groupe est meilleur que le meilleur des individus. Ainsi les recommandations user based : c’est le rapprochement des profils et des historiques d’activité. mais c’est complexe à faire car la combinatoire users fois products est colossale.

item based

La recommandation item based  c’est à dire « ont aussi acheté » est seulement une matrice product fois product, c’est plus simple.

Problème du cold start : au démarrage, pas de passé… pas de données.

Concept de sparsity : étalement des données, d’où le besoin de large volume de données.

content based

A part l’IA collaborative, c’est le content based : on compare les produits et on cherche les similarités.

plus compliqué et rare : le knowledge based (immobilier) beaucoup de critère et donc difficile d’utiliser l’intelligence collective. car chaque critère est important. On peut choisir des critères sur une clé choisie (couleur du vin).

une recommandation est une sorte de recherche. un critère de recherche.

la classification

Etape 1 : quelles sont les catégories de mon produit ?
ils ont scrappé plein de vins des sites de vente en ligne partenaires. (5000 environ). Parmi ces 5000 vins, seuls 500 avait des métadonnées cohérentes.
la classification implique la construction de matrice pour catégoriser les vins, les appellations, les goûts,…

Au sujet des performances du moteur :
Les parents/enfants dans Elasticsearch posent problèmes car ces jointures ralentissent les recherches. Le pis-aller est la copie des parents pour accélérer l’obtention des résultats mais l’espace de stockage explose.
Comment recommander sur deux catégories qui n’ont pas de résultats mises ensembles ?
il faut utiliser les « boost« , et tester et mesurer les recommandation de l’un ou de l’autre des catégories.

Les notes de dégustation sont des textes qui font ressortir tout un vocabulaire qui est alors classé par synonymie.
problème : un vin sec qui dit trois fois dans sa description qu’il est sec ressortira avant un vin une seule fois « sec ».
pour corriger, les constant score d’elasticsearch furent utilisées.

création de règle de détermination de caractère de vins selon les niveaux préféré de :

  • sucre
  • acidité
  • amertume

mesurés en amont par la déclaration de préférence culinaires des utilisateurs.

Pour saler les résultats : un random_score avec une seed différentes à chaque session permets de faire varier les recommandations, (parce que il n’y a pas photos : c’est un peu toujours les mêmes vins qui reviennent dans les résultats à requêtes de recherche égales).

la compléxité

les slop d’ElasticSearch : permet de détecter les proximités textuelles « peaux grasses » est mieux que « peaux normale à grasses »

le scoring function_score attribue des poids a certains critères pour effectuer un scoring.

function script_score un script groovy est attribué à chaque produit pour éviter les enteurs, Elasti préconise de précalculer.

Le rescore permet d’optimiser le top des résultats à faible coûts.

l’aggregation et les significant terms ont aussi été utilisés.

 

1 YEAR AFTER, THEY UNDERSTOOD HOW TO CODE WITH REACTJS

GUILLAUME CRESPEL twitter et FABIEN JUIF twitter

Ils ont présenté une appli de todolist et le chemin de refactoring qu’ils ont suivi pour l’améliorer.

Les Higher order components

les HOC sont des fonctions  c’est à dire des composants et  ses options.
hoc-react-loader : empêche l’affichage d’un composant si il n’a pas reçu ses données
k-todomvc : utlilise la lib « recompose » de react.
Ainsi chaque todo porte son propre lifecycle

librairies ReactJS

Ils ont présenté quelques librairie ReactJS intéressantes :

La lib reselect permets de pointer un membre du state en particulier.
La lib redux-thunk permet à un reducer de ne recevoir qu’une partie du state au moment d’envoyer des nouvelles actions.
La lib k-redux-factory : une factory de reducer : set, add, remove, des selectors de state : get getKey…

Best Practices :
Extraire le cycle de vie et l’état du composant dans un container HOC.
Un container par component (optimized).
Redux utilisé en tant que key/value store.

Enfin la lib k-ramel voit tous les getState et tous les dispatch. C’est un wrapper de redux et donc il le remplace.

 

LA CRYPTO POUR LES DEVS

MATTHIAS DUGUÉ twitter

Les slides de m4dz.

Dans son talk m4dz revient sur les fondamentaux de l’utilisation du chiffrement.
D’abord selon le type de données, il faut identifier celles qui sont « sensibles » au titre de la RGPD, par exemple, ou au titre du secret professionnel.

La crypto en tant que telle est utilisé :
1. pour les hash, c’est à dire les calculs de sommes de contrôle ou d’unicité.
2. pour dissimuler une donnée qu’on désire tout de même stocker.
3. pour échanger des clés de chiffrement au moment où c’est nécessaire pour par exemple un dialogue ultérieur.
4. pour générer un signature en chiffrant avec sa clé privé.

Il évoque le salage rendu nécessaire pour améliorer le chiffrement en diminuant les risques de répétition et il existe des best practices du bon sel à ajouter à sa donnée avant chiffrement.

Il reprends la typologie de chiffrement symétrique /asymétrique:
symétrique : AES,IDEA, Blowfish, car DES est aujourd’hui compromis..

La leçon est : ne pas inventer soi-même d' »algoryme » (sic) de crypto et utiliser des solutions standards et open source.

 

Vendredi 18 mai : Conférences et Talks

JE ME LANCE ET DEVIENS CTO !

MATHILDE LEMÉE twitter

Une keynote où Mathilde a narré son expérience de CTO dans la startup de recommandation de produits de beauté Jolimoi, et comment elle a découvert les aspects du métier de CTO en tant que développeuse.

 

LE COMPONENT DESIGN PAR PERCEVAL ET KARADOC : BOTTES SECRETES ET COLIFICHETS

BENJAMIN PLOUZENNEC  twitter et CORENTIN COCOUAL

Une très agréable présentation autour d’une appli de couche sirop qui veut migrer vers une appli de cul de chouette.
Mais j’ai pas compris les règles.

TYPOLOGIE

le composant est un élément HTML qui reçoit des props , subit un state et rend une vue.
<NomComposant nomAttribut= » »/>

Un composant peut être conteneur de composants.

Comment on découpe un monolithe en composant ? L’atomic design.
D’abord identifier les plus petits éléments répétés.
Ensuite définir les molécules : rassembler les atomes de mêmes familles (userinfo=nom+avatar) le molécule est plus réutilisable
Les organismes rassemblent les molécules pour donner un corps composite. (userInfo+score). Ces assemblages sont moins réutilisables
Enfin le template présente les différents organismes.

Design Systems

La typologie de tous ces composants est un « design system »
Storybook fournit un outil de documentation de design system. exemple : http://gumdrops.gumgum.com
Storybook scan le codes et génère la doc. :  component +commentaires + read me

Jest est un framework de test qui permet entre autres d’effectuer un snapshot testing. snapshot du dom de la page. qu’il compare si le code source a changé.

Une bonne pratique est de externaliser la donnée du composant : utiliser un store qui contiendra les différents états (state) des composants. sous forme d’objet JS contenant des pairs clé/valeur

Un composant pourra observer un store. Le composant pourra demander une action qui aura le droit de mettre à jour le store. Ce flux circulaire devient prédictif. Pour monitorer l’application et son store, et les events/actions, peuvent aussi requêter l’outil Sentry afin de loguer sur serveur la vie de l’application cliente.

DUMB/SMART COMPONENT

dumb/smart component : Assez similaire au HOC : Higher Order Component.
dumb : supprimer le state interne au componenet
smart : on supprime le rendu de vue du component et remplace avec un dumb component.

proposition : utiliser les webWorker pour exécuter les conteneurs de state
surcharger les composants de lib de design avec un wrapper qui permettra de changer de Material à Bootstrap ou autre.

Dan Abramov conseille de rester pragmatique  » si vous avez besoin de store, c’est come les lunettes vous saurez quand. »

 

10 CHOSES (QUE TOUT LE MONDE FAIT) QU’IL NE FAUT PAS FAIRE AVEC JENKINS

ADRIEN LECHARPENTIER twitter

SpeakerDeck : les 10 choses à ne pas faire avec jenkins.

1. curl + java run

Utiliser plutôt les packages deb, docker, yum,….

2. la dernière version

Le dernier build est peut-être bugué. utilser la LTS toutes les 12 semaines.

3. utiliser JENKINS_HOME

rester dans le workspace, evter les cd ../../../
la structure peut changer.

4. tout sur master

risque de « rm -rf $(variable inconnue)  »
utiliser des agents (sur ec2, docker swarm kubernetes, jclud, )
1 serveur == 1 agent, 1 core == 1 executeur

5.Projet maven freestyle

Utiliser les pipelines car il y a problème de la copie bordelisante de job.
pipeline : simple , multibranch, organization folder, script groovy presque groovy 😉
Un pipeline peut impliquer plusieurs agents dans le process.
il y a des générateur de snippets pour ensuite les mettre dans les shared libraries pour factoriser les jenkinsfile. de ouf.

6. garder tous les builds

jenkins n’est pas un storage de binaire, ça ralenti les graphes d’historique
Aller voir l’options { builddiscarder(logrotator())}

7. accès au workspace

Aucuns dans le cas pipeline. utiliser archiveArtifact.
JENKINS N’EST PAS UN SERVEUR WEB.
stash/unstash pour passer les builds d’un jobs à l’autre. d’un agent à l’autre et disparaît à la fin du build

8. $(JENKINS_HOME) laissé à lui -même

Lui permettre de grossir, surveiller sa taille , sur un san, par exemple. mais attention :
./plugins/  à mettre sur disque rapide (ramdisk)
./war : idem
./workspace : idem

9. backup tout JENKINS_HOME

Non, le quiet mode laisse atterrir jenkins et fini les builds en cours avant backup. timestamper le backup, sortir le backup du serveur.

10. One jenkins to rule them all

Problème de droits (GDPR), plus on divise, multiplie les instances de plugins, plus on pourra limiter chaque config au minimum nécessaire.
un jenkins pour 4-5 personnes, c’est bien.

11. pas de mise à jour

Ne pas utiliser la 1.609.1 LTS. Oui mettre à jour. idem pour les plugins. idem pour la JVM.
Sécurité : les credentials sont-ils dans jenkins_home ?

12. downgrader en cas d’upgrade en échec

Utiliser le backup d’avant backup. tester les backups avant tout. bien sûr.

13. Se plaindre du bleu qui dit « build OK »

Pourquoi le build OK est bleu ? à cause de « vert » : en japonais c’est bleu. utiliser blue ocean, puisque on fait du pipeline 🙂

14. pluginmanager c’est pas utile

Si. surveiller les github des plugins pour voir si il y a de l’activité. et utiliser l’UI pour installer car il vérifie les dépendances. (ne as le faire à main en download & tar ).

15. se plaindre des mauvaises performances

Lire le blog cloudbees joining big leagues yuning jenkins gc responsivenecc and stability
par exemple : lui donner de la RAM. plugin « suppport core » indique les perfs de jenkins.
tout est en filesystem, donc il faut du SSD.

16. SSH acces denied

c’est mal, il faut un accès d’admin sur le host de jenkins pour avoir un minimum de visibilité. diagnostiquer les OOM, backuper/restore, etc…

17. REST API

elle dump trop et renvoie des gros arbres et font tomber jenkins donc ajouter ces paramètres : ?tree=jobs(name)&depth=2

18. new way

« jenkin X » sur kubernetes.
« jenkins essentials » bien pour les startups.
« Configuration as a code » encore en alpha

19. on peut acheter du support chez cloudbees.

Pour qu’ils puissent se nourrir (dixit).

42. il faut participer à la communauté

Monter des bugs, poser des questions, voter pour les LTS, etc …

Oui, il a menti dans le titre, en fait il y avait 42 choses à ne pas faire dans Jenkins.

 

APACHE KAFKA: TURNING YOUR ARCHITECTURE INSIDE OUT

TOM BENTLEY

Mes notes en anglais (as he spoke english, i didn’t translate)

Définition

Kafka : It’s mainly an horizontally scalable pub/sub message broker, where one message = one record = key & value. Non -typed.

partitionning

The messages are passing through pipes names topics that are also partitionned based on :
– semantic partionning (after the first letter of the key)
– based on a hash de la key
– round robin
The partitioning is for scalability.

storing

How does Kafka store messages in time :
– size or time based
– compacted : if an existing key arrive, it replaces the value.

reading

The read action is using the offset that moves accordingly. it can be reread (rewind) to a previous offset, and messages can be skipped.

There’s Consumer groups against a Kafka cluster of brokers :
Consumers from different process and different machines discover each others and optimize the attribution consumer/partition, all using Kafka protocol

resilience

The partions replica is about fault tolerance. The partitions are replicated on other brokers.
in case of overload on a specific partition, it can be spread amongst other nodes but it can take time when the data size is big.

mise en oeuvre en micro-services

Producing is easy :

new KafkaProducer <>(properties, keySerializer, valueSerializer) avec Properties
new ProducerRecord<>(topic, key, value)

Consuming also : it’s the same :

new KafkaConsumer and ConsumerRecords<String, String> records

Features of core kafka for microservices :
history (audit log included), and by design loosely coupled between producers and consumers.

Examples of architecture microservices

  1. topic order.created produced by OrderService -> consumed by StockService
  2. topic stock.reserved produced by StockService, -> consumed by PaymentService
  3. topic payment.result (success/failure) produced by PaymentService -> …

Kafka Streams

Kafka offers Kafka Streams API : events & tables
« tables are events in a snapshot », (yes he said that :-). events are the lecture of a table 😉
it’s a development mode with table concepts. it’s built on top of topic api on a higher level. It supports the concept of tables as it can do aggregation and joins and windowing in case of stateful operations.
in case of stateless, it’s only Streams of events.

see kafka docs diagrams with KStream, Ktable, KGroupedStream, KGroupedTable

 

JAVA CONTAINERS IN PRODUCTION – MASTERING THE « BANANA BOX PRINCIPLE »

ROLAND BRACKMANN

Roland est Solutions engineer chez Amadeus. Sa presentation et sa matière première se retrouvent sur son repository banana-box.
Il travaille sur Openshift et a discuté du comportement des containers vis-à-vis des JVM.

perfect fit

Soit la JVM une banane. Une box pour banane c’est le « perfect fit » :

La box, c’est un container au sens Docker. Le talk discute des problématiques de sizing de cette banana box : le cpu et la mémoire.

Pour la mémoire, il faut faire usage des ergonomics de la JVM. Initialement la JVM s’auto configure en utilisant le contexte du l’Operating System de l’hôte. Des paramètres – flags existent pour modifier ce comportement du Garbage Collector de la JVM et il est important de noter qu’ils évoluent entre la JVM 8 et la JVM 11.

De même des options Docker fonctionnent sur JVM v11 (et non sur la v8) car cette version améliore le support des cgroups de linux qui font apparaître localement des ressources globales pour la mémoire et le cpu. :

  • docker « –memory=500m »
  • docker « –cpu-shares=2048 »

stack openshift utilisée

logstash + (java +jolokia + JBoss EAP) pour des JMX metrics vers influxdb et grafana.
Openshift permets de killer automatiquement les JVM qui ont fait Out Of Memory.
Petit give away : ContainerCoreInterceptor, openSource et permet de gérer des dumps de JVM plantées dans un container.

 

TESTS DE CHARGE AVEC GATLING

STÉPHANE LANDELLE twitter

Les slides du talk sont sur slideshare.

Pourquoi

Les tests de performances sont importants  : les failures coûtent de l’argent et de l’image de marque et par ailleurs, ils permettent de maîtriser les coûts de l’infrastructure.
Ils permettent d’anticiper (événements), de reproduire par itération, de s’entraîner à dompter les outils de monitoring. Ces tests de charges sont à faire ensemble en interne avec les DBA, les OPS, et aussi le business qui peuvent définir les objectifs de performance. Les tests de charge évitent d’assumer les distributions des résultats (il vaut toujours mieux mesurer et décrire puis faire les stats après)

Les outils à mettre en oeuvre doivent permettre de faire du provisioning de serveurs « crashable » à l’envie, de monitoring (de la JVM notamment), d’injecter des paramètres changeant à chaque itération.

Quand

Les tests de charge sont en général apporteur de mauvaise nouvelles. Autant les recevoir au plus tôt. Pourquoi pas dans une démarche de tests continus ?

CommenT

Gatling définie le test avec du code plutôt qu’une UI, ainsi la définition du test profite des outils de code (IDE, versioning). Oui, c’est du scala.
on code avec une API type DSL (fluent c’est à dire utilise le method chaining). il propose des checks, repeat, aslongas, error handling, …
il dispose de feeders de données pour nourrir les cas de tests : csv, tsv, jdbc,…

Le load injector permets de partir d’un comportement réel (du navigateur et de l’utilisateur) et de l’injecter dans une configuration de test Gatling. Cela permets de simuler les sessions statefull des comportement utilisateurs en haute charge.
curl, ab ou wrk (url basher) ne sont à prendre pour cette utilisation, ce sont des outils de tests de cache, en fait, pas de tests d’application. ;-), le web browser non plus.

Gatling est open source, Frontline est payant et fournit des services supplémentaires de reporting principalement.

L’architecture de gatling : messaging : akka, non blocking IO : netty, cette stack offre la capacité à monter en charge jusqu’à saturer la couche réseau comme un switch 1Gbs …

Le reporting

Les moyennes ne servent à rien en général : où sont les peaks dans une liste de moyennes ?
Les écarts types autour de la moyenne ne sont pas plus utile avec une distribution anormale (encore les peaks rodent tapis dans l’ombre, n’importe quand)
Il vaut mieux utiliser des quantiles (centiles, percentiles in english) qui permet au métier d’exprimer ses exigences de performances.
Il est possible de définir des critères d’acceptance qui fasse planter un build par exemple.

Un plugin sur les IDE fournis un support maven /gatling avec des helpers sous forme de GUI. Une fenêtre swing apparaît on  y importe les requetes exportées du navigateur pour y produire un cas de test. Il dispose aussi d’un recorder de navigation.

Nota Bene : attention au mode de connexion réseaux : le handshake tls, socket open/close ou sinon en mode keepalive, tout ça peut être des goulots d’étranglement à hautes charge.

 

UNE USINE LOGICIELLE POUR VOS WEB AGENCIES : NOTRE SOLUTION AVEC OPENSHIFT

CHARLES SABOURDIN twitter

C’était un retour d’expérience sur la mise en oeuvre d’Openshift dans une grande compagnie d’assurance.
La motivation du projet était d’internaliser une infrastructure de hosting afin de reprendre en main notamment la gouvernance des multiples sites internet que la société a pu publié à l’initiative de ses différents services communications et marketings.

Openshift gère Kubernetes

Les fonctionnalités recherchées étaient la faculté de faire du rolling update et la capacité a une grande résilience aux pannes.

Openshift est une surcouche open source à Kubernetes, elle est promue par Red Hat et ajoute la gestion de sécurité, ce qui facilite l’adoption par les ops, chargés de la sécurité des accès sur le Systèmes d’Informations. Il empêche les images Docker de tourner en root.
Openshift est donc une « distribution » de kubernetes.
A noter que Red Hat contribue à au projet Kubernetes et en profite pour basculer au fur et à mesure des features d’Openshift vers kubernetes.

la stack entière sur ce projet contient :

  • un keycloak
  • des nodes labellisés
  • des nodes de routeurs, des nodes d’infra
  • des nodes de build
  • des nodes de prod

Valeur ajoutée d’Openshift

Spécifiquement, Openshift propose

  • le BuildConfig (BC)
    instancie une image source to image permets de former une image de run à partir d’une image de build.
  • l’ImageStream (IS)
    permet de spécifier l’image à manipuler en utilisant le tag (label) de l’image.
  • le DeploymentConfig (DC)
    gère la stratégie de déploiement (blue-green par exemple) et de rollback (« oc rollback »). Avec un tag différent, c’est la stack de dev ou celle de prod qui est déployée par le même DC.
  • PersistenceVolumeClaim (PVC)
    pour réserver un PersistenceVolume (PV) (avec « oc volume »)  permet de disposer des ressources du cluster NFS, clusterFS, … partagé entre les pods.

retours d’expériences

Les PV : ils ont constatés des blocages IO avec le volume NFS. De plus ils étaient en aveugle sur l’état du volume car openshift ne voit pas la capacité maximale. les concepts de containers docker. Il était nécessaire de monter des alertes parallèles par cron + script ($ df) pour surveiller l’espace disque.
La documentation Openshift suppose que la documentation kubernetes ait été lue et comprise 🙂 Elle est peut être ainsi absconse si on n’y est pas préparée.

les gains :

  • Traçabilité de l’architecture
  • Réactivité dans la minute.
  • Sécurité (facilité de planification d’application de patch de sécurité sur les images)
  • source-to-image était un plus prépondérant par rapport à Kubernetes

 

Conclusion personnelle

Suivre les conférences comme RivieraDev est très important pour plusieurs raisons :

  • s’informer de l’état de l’art dans différents domaines qui ont en commun de beaucoup bouger d’une année à l’autre.
  • recueillir des retours d’expériences auprès des speakers et des autres auditeurs.
  • acquérir des bases dans un domaine inconnu afin de pouvoir se lancer sans se disperser.
  • évaluer la complexité d’un domaine pour déterminer ses besoins en formation ou support.
  • manger des pan bagnats et de la socca en écoutant du Muse.

Pour toutes ces raisons j’ai trouvé que RivieraDev 2018 a rempli son contrat avec brio.

J’ai ainsi vu que l’écosystème Big data / Machine learning n’a rien à envier l’écosystème Javascript du développement Web en terme de Jungle. Des solutions apparaissent constamment.

Dans le choix des sessions, le devops, le cloud, les containers était très présents, et j’ai constaté que cette tendance venait aussi de la présence bien naturelle de partenaires et sponsors qui était aussi vendeurs de solutions. On n’y échappe pas.

Cependant l’ensemble des talks et conférences ont constitué un tout cohérent, souvent très accessible, parfois pointu techniquement, toujours enrichissant.

DEVOXX France 2018 : le débrief

devoxx

Les présentations se sont enchaînées lors du DEVOXX France 2018.

Nous avons participé au Devoxx France 2018 qui s’est déroulé du 18 au 20 avril 2018. Dans cet article, nous allons vous présenter quelques conférences intéressantes que nous avons pu suivre. Ces retours sont basés sur notre compréhension personnelle, chacun est accompagné de la présentation YouTube. Libre à vous de les regarder pour vous forger votre propre opinion !

 

Cloud Native Spring, chapitre deux youtube

Josh Long twitter

Josh nous a donné un très bon aperçu des possibilités offertes par Spring Cloud. Il a commencé par évoquer le fait qu’il existe deux problèmes principaux lorsqu’on veut s’attaquer aux microservices. Le premier est le temps; il existe beaucoup d’outils différents il faut donc prendre le temps de bien les choisir, ce que nous n’avons pas forcément. Le deuxième est la communication entre les microservices.

Josh nous a ensuite réalisé une démonstration de deux microservices complètement réactifs communicants entre eux. Il nous a monté les streams réactifs, le driver réactif pour MongoDB et Spring Actuator pour les métriques.

Il évoque également les possibilités qui s’offrent à nous avec Spring Cloud, à savoir l’utilisation de service registry avec Netflix Eureka, de rate limiter avec Redis, de circuit breaker avec Hystrix, de messaging avec Kafka. Spring peut également fournir un serveur de configuration qui centralise toutes les propriétés de nos applications et permet notamment l’utilisation de feature flags.

 

Reactive Spring youtube

Juergen Hoeller twitter et Josh Long twitter

Cette présentation était pour ainsi dire un résumé de la précédente, « Cloud Native Spring, Chapitre deux ». La différence était que sa durée était de seulement 45 minutes, contre 3 heures pour l’autre. Vous pouvez regarder une des deux vidéos en fonction de votre temps disponible, celle de 3 heures étant évidemment plus poussée dans les explications.

 

Migrer à Spring Boot 2 lorsque l’on a une « vraie » application youtube

Julien Dubois twitter

Julien nous a présenté les problématiques rencontrées par JHipster lorsqu’ils ont migré de Spring Boot 1 vers la version 2.

  • Il a fallu dans un premier temps migrer les librairies tierces afin quelles soient compatibles avec la dernière version de Spring.
  • Une migration des fichiers properties a également été nécessaire, car certaines propriétés ont été renommées.
  • Le format JSON de retour de Spring Actuator a été modifié, il a donc fallu adapter les outils qui l’utilisait.
  • Spring Data a subi quelques changements d’API et utilise maintenant les Optionals.

En plus de ces modifications plus ou moins coûteuses en refactoring, de nouveaux outils sont apparus et ont été pris en compte dans leur migration. Il s’agit de Spring Webflux qui permet une programmation réactive, Spring Security supportant également la programmation réactive ainsi qu’OAuth 2. Micrometer, pour de la gestion de monitoring, a aussi été mis à disposition.

Spring Cloud quant à lui n’a pas pour l’instant eu d’impact. Toutefois, sa version supportant Spring Boot 2 n’est pas encore sortie officiellement.

Dans l’ensemble, le coût de refactoring a été assez cher et plus encore il a fallu tester de nouveau toute l’application.

 

Glowroot, le petit APM qui vous veut du bien youtube

Henri Gomez twitter

Henri nous a présenté l’Application Performance Management (APM) Java Glowroot. Contrairement à la plupart des APM, celui-ci est open source et gratuit. Son overhead est inférieur à 100 µs et sa consommation mémoire minime.

Glowroot a deux modes de fonctionnement. Le mode autonome en spécifiant seulement le chemin du jar au lancement du serveur, ou le mode centralisé qui nécessite une base Cassandra et permet de monitorer une ferme d’applications.

Il comporte l’ensemble des fonctionnalités attendues d’un APM comme l’affichage des slow traces. Il fonctionne avec tout protocole, frameworks et serveurs d’application.

 

Java dans Docker : Bonnes pratiques youtube

Charles Sabourdin twitter et Jean-Christophe Sirot twitter

Charles et Jean-Christophe nous ont parlé d’un ensemble de bonnes pratiques pour utiliser des applications Java avec Docker. La présentation était axée sur la gestion de la mémoire.

Le paramètre « memory » peut être utilisé au démarrage d’un conteneur Docker afin de spécifier le montant maximum de RAM qu’il peut utiliser. Il est conseillé de l’utiliser, ainsi que le paramètre « memory-swappiness » afin de désactiver le swap qui diminuerait grandement les performances.

Côté Java, la gestion de ressources dans un conteneur a été amélioré en Java 9 et backporté en Java 8u131. Toutefois, il est nécessaire d’utiliser les flags UnlockExperimentalVMOptions et UseCGroupMemoryLimitForHeap. En Java 10, la fonctionnalité est stable et activé par défaut.

Tous ces principes s’appliquent également pour la gestion de ressources CPU.

 

Container security tips for developers youtube

Justin Cormack twitter

Justin nous a donné un ensemble de conseils de sécurité pour l’utilisation des conteneurs avec Docker.

Docker est plutôt bien sécurisé par défaut, il y a toutefois un ensemble de bonnes pratiques à suivre pour éviter tout désagrément. Il est recommandé de toujours utiliser des images officielles. Il faut privilégier par exemple les images Java officielles plutôt que celles réalisées par une personne lambda. Les images officielles sont régulièrement mises à jour pour patcher des vulnérabilités, donc il faut également veiller à mettre à jour nos images qui se basent dessus.

Il est conseillé de signer nos images afin d’être sûr que le cluster de production récupère bien une image reconnue qui a été buildée par notre serveur d’intégration continue. Il est également possible et utile de scanner régulièrement les images utilisées afin d’y trouver des vulnérabilités connues et pouvoir les corriger.

Enfin, il faut éviter de commiter les secrets de nos applications sur GIT ainsi qu’utiliser les variables d’environnement et privilégier plutôt l’utilisation de Vault ou des systèmes intégrés à Docker et Kubernetes pour gérer identifiants et mots de passe.

 

Les 12 factors Kubernetes youtube

Etienne Coutaud twitter

Etienne nous a présenté sa version des Twelve-Factor App appliqués à Kubernetes.

Les bonnes pratiques à suivre pour déployer des applications dans un cluster Kubernetes sont les suivantes :

  • Il faut garder en tête qu’un Pod signifie un ou plusieurs conteneurs.
  • Utiliser les labels à profusion. Cela permettra de gérer plus facilement un cluster qui comporte des dizaines, voire des centaines de pods. Chaque commande Kubernetes peut être exécutée en précisant un namespace ou un label et ainsi cibler son impact.
  • Les fichiers de configuration YAML de Kubernetes doivent être traités comme du code et versionnés. De plus, la commande apply pourra être utilisée sur un ensemble de fichier et Kubernetes se chargera d’appliquer uniquement ce qui a été modifié.
  • Les services permettent d’exposer des pods et de gérer du load balancing.
  • Utiliser les ConfigMaps et Secrets pour gérer les identifiants de nos applications. Ils seront ensuite injectés et accessibles depuis nos pods.
  • Utiliser les requests et limits pour gérer les ressources de notre cluster.
  • Les pods doivent être déployés via un fichier de Deployment et non pas directement en tant que pod. Dans le cas contraire, aucun ReplicaSet ne sera créé, leur cycle de vie de ne sera pas correctement géré et ils ne pourront pas être redémarrés automatiquement en cas de problème par exemple.
  • Utiliser les paramètres LivenessProbe et ReadinessProbe. Le premier permet à Kubernetes de savoir lorsqu’un pod a bien été démarré et le second de savoir lorsqu’il est réellement prêt à être utilisé (après une connexion à une base de données par exemple).
  • Ne pas utiliser la version « latest » pour les images. Privilégier plutôt l’id de commit GIT par exemple. Cela permettra de savoir plus facilement quelles fonctionnalités et corrections sont disponibles en production.
  • Les pods sont stateless et éphémères. Il faut donc y penser lors du développement de l’application. S’il est nécessaire de garder une session par exemple, il faudra utiliser un pod explicitement déclaré statefull et contenant une base Redis.
  • Les volumes doivent être montés sur des stockages distribués. Vu que nos pods sont stateless, toute donnée sera perdue à leur redémarrage. Il faut donc configurer le pod pour qu’il ait accès à des volumes mis à disposition généralement par notre fournisseur Cloud.
  • Les microservices déployés doivent suivre les Twelve-Factor App.

 

Docker, Kubernetes et Istio, c’est utile pour mon monolithe ? youtube

David Gageot twitter

David nous a présenté une transformation de l’application classique « Pet Store » en microservices.

Il a commencé par la création d’une image Docker pour l’application afin de pouvoir la déployer dans un cluster Kubernetes. La configuration pour ce déploiement se présente sur la forme de fichiers YAML.

La première étape de la migration consiste à intégrer un conteneur Nginx et un conteneur contenant l’application dans un même pod Kubernetes. Le conteneur Nginx est embarqué en mode « sidecar » et permet d’intercepter les requêtes du Pet Store afin de les compresser, ainsi que faire de la réécriture d’URL.

La deuxième étape consiste à ajouter un autre sidecar, Envoy. Il s’agit d’un proxy qui va être rajouté automatiquement par le service mesh nommé Istio. Ce dernier ajoute un grand nombre de fonctionnalités à Kubernetes. Il va permettre notamment de chiffrer les communications entre chaque microservice grâce à Istio Auth. Cet ajout de proxy en sidecar de chaque pod va également permettre à Istio Mixer d’agréger des métriques et les envoyer à Prometheus et Grafana afin d’avoir un dashboard d’analyse de notre cluster.

Istio a un grand nombre d’autres fonctions. Il est possible de l’utiliser pour gérer des déploiements en blue/green, timeouts, retries, health checks, mirroring, circuit breaker, rate limits, telemetry, reporting, traces distribuées avec Zipkin, etc.

Avec toutes ces fonctions, il est possible de migrer graduellement une application legacy vers des microservices.

 

Troubleshooting & Debugging Production Microservices in Kubernetes youtube

Ray Tsang twitter et Baruch Sadogursky twitter

Ray et Baruch nous ont présenté des pistes afin de débugger des microservices en production sous Kubernetes.

Côté best practices pour faciliter l’analyser, il est conseillé de ne pas utiliser la version « latest » pour les images, mais plutôt l’id du commit GIT par exemple. Partant d’une application ne suivant pas ce conseil, ils ont dans un premier temps comparé les hashs des images Dockers avec la version précédente, ainsi que le hash du jar embarqué dans le conteneur afin de pouvoir connaître la version réelle de l’application qui tourne en production.

Les logs des pods sont redirigés sur la sortie standard. Comme il peut avoir un grand nombre de pods répliqués sur plusieurs serveurs, il existe des outils comme stern ou ktail qui permettent d’agréger les logs de tous les pods d’un même ReplicaSet. Dans le meilleur des cas, nous pouvons utiliser par exemple une stack ELK qui va permettre de centraliser tous les logs sur Kibana.

Une fois le pod défaillant ciblé, il est possible de le sortir du cluster afin de l’analyser plus en détails. Il est possible de tracer précisément la requête effectuée avec l’aide de Zipkin.

Enfin, l’utilisation du Google Cloud Engine (GKE), pour gérer notre cluster Kubernetes, permet d’avoir accès à ensemble d’outils facilitant le debugging. Nous pouvons noter par exemple le debugger de GKE qui permet d’ajouter à la volée des logs dans le code s’exécutant en production grâce à de la bytecode instrumentation.

 

Du mutualisme à l’Open Source youtube

Alexandre Delègue twitter Mathieu Ancelin twitter et François Desmier twitter

Alexandre, Mathieu et François nous ont parlé de la transformation de leur entreprise, la MAIF, ainsi que du développement de certains outils open sources.

La MAIF est une société d’assurance qui s’est rendu compte que sans évoluer, elle était vouée à disparaître. En effet, nous pouvons imaginer que d’ici quelques années le besoin d’assurance sera moins nécessaire, notamment grâce (ou à cause, selon le point de vue) aux voitures autonomes qui vont se démocratiser. Dans tous les cas le modèle actuel va évoluer et l’entreprise se doit également d’évoluer. Une diversification est nécessaire.

Dans cette optique, la MAIF a sorti déjà deux outils open sources : Otoroshi et Izanami.

Otoroshi est un outil permettant de gérer API management, circuit breaker, load balancing, throttling, quotas et métriques. Il dispose également d’une interface d’administration REST et web.

Izanami est un outil permettant de gérer feature flipping, configuration partagée et tests A/B.

D’autres outils sont en préparation et l’ensemble de ce qui a été développé permet une gestion facilitée des architectures microservices.

 

Using Kubernetes for Continuous Integration and Continuous Delivery youtube

Carlos Sanchez twitter

Carlos nous a présenté un workflow d’intégration continue et déploiement continu via l’utilisation de Jenkins X, qui s’appuie sur Kubernetes. Le workflow peut s’effectuer de la manière suivante : un push puis une pull request sont effectués sur GitHub, un build Jenkins est automatiquement déclenché, s’il passe correctement le merge de la pull request est fait, enfin d’un clic de bouton l’application est déployée dans l’environnement choisi.

Jenkins X se compose également d’un grand ensemble de plugins et permet d’automatiser certaines tâches liées au déploiement d’une nouvelle version comme la génération automatique de changelog.

 

Maitriser sa gestion de l’identité avec Keycloak youtube

Lilian Benoit twitter Thomas Recloux twitter et Sebastien Blanc twitter

Lilian, Thomas et Sébastien nous ont présenté Keycloak et ses possibilités en profondeur. Il s’agit d’une solution open source permettant de faciliter la gestion de l’authentification et de l’identité de nos applications. Il supporte les protocoles OpenID Connect 1.0, OAuth 2.0 et SAML 2.0.

Le principe d’OAuth 2 est de récupérer un authorization code, puis un access token, puis utiliser ce dernier pour s’authentifier.

OpenID Connect permet d’allier OAuth 2 et JWT. Ce dernier consiste en un header, un payload et une signature. Le payload peut être utilisé pour passer n’importe quel type d’information (non compromettante) utile à notre application. En comparaison avec OAuth 2, OpenID Connect est un protocole d’authentification et d’autorisation complet.

Une bonne pratique dans la gestion des tokens est de faire des access token à durée de vie courte (quelques minutes). Un refresh token, avec durée de vie beaucoup plus longue, permet ensuite de récupérer un nouvel access token valide. Ceci permettra par exemple qu’au bout de quelques minutes, les droits éventuellement mis à jour d’un utilisateur soient pris en compte à la régénération d’un access token.

Le SAML 2.0, beaucoup plus ancien pour sa part, car défini en 2005, permet notamment l’échange d’information d’authentification entre partis. Il permet une gestion du SSO et il n’est pas uniquement utilisable en HTTP, car il s’agit simplement d’un format XML.

Pour ce qui est de Keycloak lui-même, il se compose de Realms et de Clients. Un client sera une application et le realm sera l’entité regroupant nos différentes applications qui ont un certain lien entre elles, comme la nécessité d’utiliser du SSO.

La customisation est très poussée sur tout ce qui touche à l’authentification. A titre d’exemple, les fonctionnalités pouvant être activées sont : rester connecté, mot de passe oublié, enregistrement, captcha, vérification d’email, protection brute force, politique de mot de passe, double authentification, etc.

En plus d’une bonne intégration à Spring Boot et Spring Security, un ensemble d’adaptateurs sont fournis, ainsi qu’un proxy fonctionnant en mode « sidecar », sur le même principe qu’Istio dans un cluster Kubernetes.

Keycloak est ainsi une solution complète fournissant toutes les fonctionnalités nécessaires pour la gestion de l’authentification et des droits de nos applications.

 

Chaos Engineering, principes et mise en application youtube

Benjamin Gakic twitter

Benjamin nous a présenté le Chaos Engineering, initié par Netflix, et sa mise en application chez OUI.sncf.

Dans une situation chaotique, habituellement nous agissons d’abord, puis observons et enfin seulement répondons au problème. Le but va être d’éviter de se retrouver dans ce genre de situation en la provoquant nous-même et la résolvant. Le chaos engineering est non déterministe et s’effectue en production. Il s’agit de faire de l’expérimentation sur un système distribué afin de renforcer notre confiance dans la capacité du système à résister à des conditions turbulentes.

D’après de récents sondages, la sécurité devient maintenant moins prioritaire pour les entreprises que le downtime de leur application. Les indisponibilités sont de plus en plus médiatisées et font de la mauvaise publicité. Deux exemples récents sont OVH et GitLab qui ont chacun eu un épisode de downtime important très médiatisé.

Pour faire du Chaos Engineering, plusieurs outils sont à notre disposition, le premier étant Chaos Monkey. Pour simuler des pannes, cet outil va mettre hors service des instances de production de manière aléatoire. Les autres outils disponibles sont notamment Latency Monkey, Fill Disk Monkey, Process Killer Monkey, Properties Monkey, etc. Chacun va tenter de « casser » nos applications d’une manière différente afin de cibler des vulnérabilités dans notre architecture et pouvoir les corriger avant qu’elles ne se produisent réellement.

En plus de mettre ces outils en place, d’abord en pré-production, OUI.sncf met en place des journées « Game day » dont le but est également de trouver des vulnérabilités. Des équipes d’opérateurs se chargent de « casser » l’environnement de différentes façons et des équipes de développeurs doivent ensuite arriver à les détecter, diagnostiquer puis les résoudre le plus rapidement possible.

 

Lighthouse: mesurer et améliorer votre performance web youtube

Sara Harkousse twitter et Philippe Antoine twitter

Sara et Philippe nous ont présenté Lighthouse. Celui se présente sous la forme d’un module NodeJS, ou bien directement intégré dans les DevTools de Google Chrome.

Lighthouse permet d’analyser une page web et fourni un ensemble d’indicateurs sur celle-ci, avec un score sur 100 pour chacun. Les indicateurs sont les suivants :

  • Performances
  • Progressive Web App
  • Best practices
  • Accessibility
  • SEO

Pour chaque amélioration possible, une todo list est proposée avec des conseils sur les mesures à mettre en place ou ce qu’il faudrait ajouter/modifier sur notre site.

Parmi les aides proposées, on peut noter par exemple un scan automatique des librairies utilisées (fourni via Snyk). Pour le reste, les DevTools permettent également d’améliorer performances et accessibilité.

 

Réconciliez vous avec le JS grâce à Flow youtube

Trung Nguyen twitter

Trung nous a fait un tour rapide des fonctionnalités proposées par Flow. Il s’agit d’un vérificateur de type statique, développé et largement utilisé par Facebook.

Une fois le module NPM installé, Flow pourra analyser les fichiers de notre projet annotés avec // @flow. Il nous présentera un ensemble de warnings et d’erreurs permettant de détecter des bugs avant le runtime. Pour cela, Flow fait du type checking en essayant d’inférer les types.

Flow apporte également un ensemble de syntaxes supplémentaires au JavaScript afin de définir nous-même les types utilisés.

 

Accélerez vos tests end-to-end avec Cypress youtube

Rodolphe Bung twitter

Rodolphe nous a présenté un outil de test end-to-end nommé Cypress. Contrairement à Selenium, il est exécuté directement dans le navigateur et permet par conséquent une meilleure gestion des applications single page.

Cypress est centré sur l’expérience développeur. Son installation et son API sont simples. Il propose en plus des fonctionnalités très utiles telles que le live reload, le mocking, la mise à disposition automatique de vidéos des tests effectués, des tests de régression visuelle et des tests unitaires de composants React et Vue.js. Des plugins sont également disponibles.

Le seul reproche qui pourrait lui être fait actuellement est qu’il ne soit pas multi-navigateur. Il fonctionne uniquement sur Google Chrome, mais le développement sur d’autres navigateurs est en cours.

 

GraphQL vs Traditional Rest API youtube

Vladimir Dejanovic twitter

Vladimir nous a présenté le langage de requête pour APIs nommé GraphQL. Cette spécification a été décrite par Facebook en 2012 puis publiée en 2015. Comme il s’agit d’une spécification, chaque implémentation peut différer et ne pas forcément implémenter toutes les fonctions possibles.

Une API REST classique est basée sur une architecture client-serveur, est stateless, est cacheable, a une interface uniforme entre le client et le serveur.

Une API GraphQL possède également ces fonctionnalités et aura en plus notamment un schéma disponible. Ce schéma définira toutes les opérations possibles sur l’API; les query (de la lecture de données) et les mutations (de la modification de données). L’avantage d’avoir ce schema est de pouvoir savoir exactement ce qui est disponible et d’ainsi d’avoir une documentation.

Les clients appelant une API GraphQL choisissent quels objets et quels champs récupérer. Contrairement à REST, le client peut donc utiliser l’API comme il le souhaite en fonction de ses besoins, sans avoir forcément à appeler plusieurs endpoints pour récupérer des sous objets. Comme le client a plus de liberté, il existe des mécanismes de protection pour éviter qu’une requête soit beaucoup trop lourde à exécuter, à savoir des timeouts, des niveaux maximum de profondeur pour récupérer des objets enfants, des niveaux maximum de complexité et du throttling.

Certaines implémentations peuvent aussi fournir un système de souscription pour que le client soit alerté lorsqu’une donnée est modifiée.

 

Agile France 2017 : l’expérience Viaxoft

Agile France 2017Cette année, nous étions 5 émissaires de Viaxoft, 4 POs et 1 SM, à passer les portes rouges du Chalet de la Porte Jaune, les 15 et 16 juin lors de l’Agile France 2017. La convention commence par un petit atelier pliage pour faire rentrer le planning dans le porte badge (ce qui n’est pas aussi simple qu’il n’y parait).Ensuite après un warm-up animé et quelques exorcismes pour se connecter au wifi, et les différents pitchs des speakers, les premières sessions sont lancées.

Jeudi 9h40 – Montessori Insight

Mija Rabemananjara twitter Nadia Hamidi twitter

« Larry Page et Sergey Brin, les fondateurs de Google ont récemment déclaré à ABC News que l’éducation Montessori était une des principales raisons de leur réussite. »

Mija, agiliste apprenante, et Nadia, directrice pédagogique Montessori, nous ont présenté la pédagogie Montessori – du Docteur Maria Montessori, et les raisons pour lesquels elle peut tout à fait être considérée comme une des méthodes agiles.

L’homme, au sens de l’humain, est-il bon ? L’humain naît-il bon ? L’enfant, lorsqu’il naît, est vierge de tout environnement, son cerveau n’est pas mature, tout est à construire, et si on le met dans un environnement bienveillant, il grandira et sera bienveillant à son tour.

Les tendances humaines

Pour Maria Montessori il existe plusieurs tendances humaines qui doivent être respectées pour évoluer sereinement : orientation/ordre, exploration, communication, abstraction, esprit mathématique, répétition, exactitude/auto-perfectionnement, compréhension, imagination, mouvement/activité/travail, manipulation, adaptation, religion/morale.

Il existe également 4 périodes, 0-6 ans ou l’indépendance  physique, l’enfant apprend à grandir, 6-12 ans ou l’indépendance psychique, l’enfant apprend à penser, 12-18 ans ou l’indépendance sociale, l’enfant apprend à vivre avec les autres, et 18-24 ans qui est le passage à l’âge adulte.

Les enfants d’une école Montessori apprennent les mathématiques par la manipulation, avec du matériel spécifique, comme le carré(10*10) ou le cube(10*10*10) Montessori. Ils ont beaucoup de liberté et de responsabilités, ils font le choix des matières qu’ils souhaitent étudier. L’apprentissage se fait par la répétition. Il ne faut pas être dans le jugement (Par ex : « Wahou ton dessin est beau »/ »Mais c’est quoi ce gribouillage? »), mais valoriser ce qui est fait ( « Tu as mis du rouge et du bleu. C’est un bonhomme avec un grand sourire! ») et être dans le ressenti (« Tiens, je vois que ton bonhomme est triste, pourquoi ? »)

Les niveaux de classe sont mélangés, entre 6 et 12 ans par exemple les plus petits prennent les plus grands pour modèles, et les plus grands sont ravis d’expliquer aux plus petits et de leur donner envie. La motivation intrinsèque est très importante.

Jeudi 11h – Les forces de la nature gouvernent l’entreprise

CÉDRIC Bodin  twitter

Les forces fondamentales qui gouvernent notre monde sont cachées à nos yeux mais visibles dans les formes de la nature. Pendant 20 minutes, Cédric  a comparé les diverses forces naturelles et celles qui régissent une entreprise.

La force de gravité est ainsi mise en parallèle avec une pyramide haute. Si la pression qui vient du haut est trop forte, la couche du bas fini par se rompre. Et la pyramide s’écroule. La force électromagnétique peut se retrouver dans un sociogramme.

Les figures géométriques ne sont pas en reste, la symétrie linéaire, comme dans une méduse, st comparée à une certaine forme de travail, la symétrie radiale, celle d’un virus, qui comme la méthode scrum, itère, pour produire du matériel de plus en plus performant, et la symétrie bi-latérale, ou celle du triangle, qui représente également le lien PO/SM/DEV.

JEUDI 11H30 – TOP 10 des pratiques agiles à fort R.O.I.*

CÉDRIC BODIN  twitter

*Return On Investment 

 

De nouveau avec Cédric, qui nous présente 10 pratiques agiles, suivant un atelier limité à 20 personnes. Les autres dont nous faisions partie, ont heureusement pu observer.

Check-in

Le check-in consiste à briser la glace, commencer une activité, se mettre dans le bain… Celui-ci était tout simple, Je m’appelle (prénom), je suis (humeur/profession) et j’adore (passion insolite). Par exemple pour moi ça ferait « Je m’appelle Natacha, je suis Graphiste/Scrum Master et fatiguée par la chaleur. Et j’adore manger des frites froides. » No comment.

Matrice des compromis

Il s’agit de classer de 1 à 4 les différentes composantes d’un projet, le budget, le temps, la qualité et le périmètre afin de déterminer quelles sont celles sur lesquelles on est le plus d’accord pour s’ajuster. Par exemple ici :

  • 1 était le budget – qui n’allait pas entrer en compte
  • 2 la qualité – personne ne voulait des ateliers de moins bonne qualité
  • 3 le temps – si on finit 5 minutes plus tard ce n’est pas grave
  • 4 le périmètre – si on ne voit que 9 pratiques au lieu de 10 ce n’est pas grave, pourvu que ces 9 soient de qualité
Board & Burndown

Le board est la figure qualitative du projet, ici les différentes techniques et leur état A faire / En cours / Terminé, et le burndown la figure quantitative. Au fur et à mesure du temps qui passe, combien de techniques ont été vue ?

Les rôles délégués

Distribuer des rôles délégués au moment d’un atelier, une réunion, une rétrospective permet de dynamiser le groupe. Exemple de rôles : animateur, scribe (il prend des notes, déplace des post-its), Mr/Mme Positif-ve (Est toujours très enthousiaste et d’accord avec tout), Mr/Mme Grincheux-se (Râle tout le temps, sert de lanceur d’alerte), le gardien du temps (signale lorsqu’on prend plus de temps que prévu sur une tache), Mr/Mme Bisous (chargé de réconcilier les conflits), Mr/Mme Carton Jaune (à sortir lorsque quelqu’un ne respecte pas les règles, coupe la parole etc…) et ainsi de suite il n’y a que l’imagination comme limite…

Découpage & Dot-voting

On découpe un projet en plusieurs sous-projets. Puis chaque acteur vote avec trois gommettes à poser comme il le veut pour celui qu’il considère comme le plus important. L’inconvénient du dot-voting est que les derniers à voter peuvent être influencés par le vote des autres. Voire même, avoir l’impression que leur vote ne sert à rien. Pour contrer cela, on pourrait avec des bulletins/post-its, tout en gardant à l’esprit que ce ne sera forcément qu’un ordre d’idée.

Technique du R.O.T.I

Return On Time Invested, ou retour sur le temps investi, à la fin d’une réunion, un atelier ou peu importe, chaque personne vote à main levée, ou plutôt doigts levé, 0 étant « j’ai perdu mon temps » et 5 « je ne pouvais pas mieux faire pour investir du temps ».

Story Mapping

Classer les Stories selon la technique du MoSCoW :

  • Must (ce qu’ont doit faire absolument)
  • Should (ce qu’on ferait mieux de faire)
  • Could (ce qu’on fera si on le peut)
  • Wish (ce qu’on aimerait faire si tout le reste est fait).

Remarque : le temps alloué à cette activité est très important, trop court, tout part dans le Must par reflexe, juste un peu plus long, ça s’équilibre, mais trop long certaines Story repartent dans le Must parce que « c’est quand même important ».

Chiffrage

Chiffrage des différentes User Story par point d’effort selon la suite de Fibonacci (ou presque). Une story sert d’étalon en considérant qu’elle est moyenne, et en la posant sur le 5. Le chiffrage se fait dans le silence et chaque déplacement doit être tracé par une flache sur le post-it. Ainsi celles qui ont eu plusieurs déplacements contradictoires, ou très importants pourront générer un dialogue, tandis que ce n’est pas la peine de s’attarder sur celles qui font consensus.

Perfection Game

Le perfection Game étant de noter un événement, 0 étant complètement nul, et 10 la perfection, quelle note mettriez vous. Si vous avez mis 5 (autre chose que 10 quoi), pourquoi ? Et que faudrait-il pour atteindre 6 (votre note plus 1) la prochaine fois ?

Feed Back Door

Enfin la dernière pratique consiste à noter une activité à l’aide de smileys sur un papier affiché à la sortie.

 

Jeudi 14h30 – Open Space (Forum Ouvert)

Pour ceux qui ne connaîtraient pas, un Open Space ou Forum Ouvert consiste à un échange sans ordre du jour, sur une durée donnée. Il comporte une seule loi, celle des deux pieds, à savoir « Si vous n’êtes ni en train d’apprendre, ni en train de contribuer, suivez vos deux pieds et passez à autre chose » et 4 principes :

  • tous ceux qui viennent sont les bonnes personnes
  • quoi qu’il se passe c’est la seule chose qui aurait pu se passer
  • ça commence quand ça commence
  • quand c’est fini, c’est fini !

Il existe également deux animaux totems, les abeilles qui circulent d’ateliers en ateliers et les papillons qui prennent une pause ou réfléchissent.

La charge mentale

Inspirée par une bande dessinée d’Emma « Fallait demander », le questionnement était sur la répartition des taches domestiques et l’agilité à la maison. Une discussion ouverte sur celles (et dans une moindre mesure ceux) qui considéraient qu’elles assumaient la charge mentale, c’est à dire le fait de devoir penser à faire les choses, qui avaient ou non réussit à répartir les taches, et quelles pratiques agiles avaient été mises en place à la maison. Certains ont mis en place un Kanban. D’autres un système de remerciement à chaque tache accomplie, ce qui implique de communiquer sur le fait que la tache ait été faite.

Comment mieux gérer son temps ?

Tout d’abord, faire la différence entre productivité et temps de travail. Mettre deux heures à faire quelque chose parce qu’on est sans arrêt interrompu rend improductif. Le temps est perdu à se remettre dans ce qu’on faisait.

La méthode GTD (Geting Things Done) permet de s’organiser pour faire les choses et avoir des résultats. Elle est basée sur trois principes : on choisit à chaque fois en pleine connaissance de cause ce que l’on fait. On ne porte son attention que sur ce qui est actionnable maintenant. On est tranquille sur ce que l’on ne fait pas : soit on a choisi de ne pas y donner la priorité, soit ce n’était pas faisable maintenant. Toute l’attention, la créativité et l’énergie sont mobilisées sur la seule action qu’on a délibérément choisi de faire. Cette méthode demandant une certaine rigueur, et étant une habitude à prendre, c’est plus facile de la mettre en place en la couplant à une habitude déjà prise (juste avant ou juste après).

Certains ont de petites astuces : mettre un totem qui signale qu’on ne peut pas être dérangé (puis reporter les jours sur un calendrier à la vue de tous), ou couper toutes les communications de temps en temps. Koober est une entreprise dont le travail consiste à faire des résumés de livres à lire en 20mn ce qui permet de gagner du temps sur les sujets techniques. On peut aussi faire des filtres dans les mails, et les envoyer directement dans des dossiers. Et ne les lire qu’une fois par semaine. Et virer les notifications (surtout celles qui font un son)

Les doléances de l’agile france 2017 / la parité qui chute

Point original, qui m’a permis de faire remonter le manque (voire l’absence) de choix végétalien lors du repas du midi. Je me suis contentée de pain et de riz nature. Et d’une tomate qui servait à décorer un plateau de fromage. Ce fut pertinent car le tir a été corrigé dès le soir au repas (auquel nous n’étions malheureusement pas). Le lendemain midi il y avait même tout un banquet végétarien/végétalien.

La suite de la session concernait le nombre de femmes présentes à Agile France 2017. Celles-ci étaient en effet beaucoup moins nombreuses par rapport à l’année dernière. Et, du coup, comment faire pour les faire venir? Moi j’ai fait le papillon donc je n’ai pas la réponse, on ne juge pas.

 

Vendredi 9h20 – De SAFe à Scrum

Arnaud Villenave twitter Sarine

Arnaud et Sarine nous font un retour d’expérience sur leur produit Libon, un service de téléphonie ip. Notamment, le contrôle des transformations qui a été difficile suite au départ du coach. Ils font des sprints d’une semaine, et la fin de sprint est le jeudi. Ainsi la journée du vendredi est libre, ce qui laisse le temps aux développeurs de travailler sur des projets de manière autonome, et au PO de récolter et noter le feedback en vue du prochain sprint. Ils ont animé un atelier afin de déterminer les rôles de chacun.

Un livre qui les a inspiré : la vérité sur ce qui nous motive, de Daniel H. Pink. Un principe : KISS, Keep It Simple. Stupid.

Ils ont mis en place des tests de type A/B Testing, afin de pouvoir avoir un feedback utilisateur sur une fonctionnalité.

Concernant le personnel, autonomie et responsabilité sont mises en valeur. Le but étant de réduire une équipe devenue trop grosse, revenir à l’humain et aplatir l’organisation. Pour se faire il a fallu pousser les gens à s’exprimer. Les compétences des personnes sont plus importantes que leur rôle.

En engageant par la motivation, valorisant et favorisant la prise d’initiative, et en donnant le droit à l’erreur les résultats sont beaucoup plus efficaces qu’avec un nombre plus important d’employés. Il est apparu comme essentiel de prioriser et faire des choix plutôt que grossir. Livrer un Produit Minimum Viable (MVP) et le libérer des croyances.

 

Vendredi 10h30 – Lancer un projet agile en 5 jours chrono

Yann Gensollen twitter

Yann est le co-fondateur de #play14 une série de conventions qui regroupe de personnes qui pensent que jouer est la meilleure façon d’apprendre et de comprendre. Il est également consultant pour Marmelab.

Son travail consiste à préparer le terrain pour les développements à venir dans un projet agile. Il a fait le tour de force de nous parler durant une heure avec une seule slide, et sans que ce soit ennuyant. Sa façon de faire est toujours facturée 5JH répartis sur deux semaines à un mois. Dix étapes incontournables (pour la plupart) que vous pouvez retrouver en détail sur son blog.

Tout d’abord en collaboration avec le client, il définit la Vision permet de faire ressortir les objectifs. Ensuite, les KPI sont les indicateurs à prendre en compte afin de vérifier la tenue de ces objectifs. En troisième vient une étude des risques liés au projet, puis quasiment imbriqué celle de la concurrence.

Une fois les quatre premières étapes effectuées, viennent les Personas, une vision d’un utilisateur imaginaire représentant un groupe de personnes dont les motivations, comportements et buts sont proches. Les personas aident à déterminer ce que le produit doit faire et comment il devrait fonctionner.

Ensuite il construit l’Ubiquitus Langage est un dictionnaire  de langage partagé, qui permet de mettre en place des concepts clés. Les mots clés sont en anglais et seront utilisés pour le code, les déclaration de variables…

Le Parcours utilisateur se met en place via le story mapping. La combinaison de tout ce s éléments permet de mettre en place l’architecture du projet, puis de commencer à construire le backlog – avec l’aide du PO.

Et enfin en dernier, l’organisation du projet consiste à récolter les divers accès et contacts dont les devs pourraient avoir besoin

 

Vendredi 11h30 – Les dailies

Jonathan Boccara twitter

Un problème récurent dans les entreprise est la gestion des formations. La plupart du temps, les employés n’ont pas le temps, sont trop pris par leur travail, autant ceux qui ont le besoin d’être formés que les formateurs (dans le cas de formations internes).

Pour contrer ça, l’entreprise de Jonathan a mis en place les dailies. Ce sont des formations courtes (10 à 15 minutes), tous les jours, en interne et dans les bureaux. Chaque session est filmée et postée sur un wiki, pour que ceux qui souhaitent la consulter, ou revoir puissent le faire. Les sessions sont filées sur un mois, découpées en tout petits bout. A la fin d’une session ceux qui sont intéressés peuvent rester et poser des questions, les autres se remettent simplement au travail.

 

 

Pour le formateurs les avantages sont nombreux, cela lui permet de progresser sur son sujet (préparation d’un quart d’heure avant), et l’entraine à la présentation. Dans les grandes entreprises c’est aussi un moyen de rencontrer des gens à qui on ne parle pas tous les jours.

On peut le trouver sous twitter avec le hashtag #devDailies

 

Vendredi 12h – Parents Positifs, enfants agiles

Gaelle Bourven

Personne ne nous apprend comment fonctionnent les gens, la gestion des conflits, la motivation de chaque personne…

Pour être bienveillant, il faut reconnaître que les gens font du mieux qu’ils peuvent avec les moyens qu’ils ont. D’autant plus avec les enfant. Il faut savoir que la maturité du cerveau arriver entre 20 et 30 ans et en tenir compte. Faire des phrases affirmatives, car la négation entraîne de la complexité. (Qui ne s’est jamais fait de nœud au cerveau en essayant de décortiquer une double voir triple négation ? N’essayez pas de ne pas y penser !)

On devrait plus exprimer ce qu’on voudrait plus que ce qu’on n’aime pas. (Par exemple « Je voudrais savourer mon café dans le silence » plutôt que « je n’aime pas que tu viennes me parler pendant que je bois mon café »). Le cadre doit être clair et orienté vers l’objectif, sans oublier l’importance du respect de chacun.

 

Certaines personnes font des dailies en famille, ce qui leur permet de se mettre au point sur les choses à faire, et ce qui s’est passé la veille ou durant la journée (selon l’heure du daily).

La bibliographie  :

C’est pour ton bien – Alice Miller

Parler pour que les enfant écoutent, écouter pour que les enfants parlent – Adèle Faber et Elaine Mazlish

Vendredi 14h10 – Réinventez vos cérémonies

Blog de Jean-Pierre Lambert autodidacte sur le métier de Scrum Master

Cet atelier participatif était conçu pour nous permettre de trouver de nouvelles idées pour les cérémonies. Le but étant dans un premier temps de sortir un nombre important d’idée, et d’en créer de nouvelles par effet de rebond. Par exemple « Faire la rétrospective dehors » a entraîné par rebond « Aller faire un pique-nique ». Ensuite une fois la masse d’idée récupérée chaque personne devait en défendre une et les soumettre au vote des autres, sachant que si au moins un vote contre, l’idée est rejetée et doit être abandonnée où avoir une contre proposition. Si elle est rejetée trop souvent, on abandonne l’idée et on passe à la suivante.

Dans un troisième temps, on récupère toutes les idées validées et on les fait passer dans une grille NUFF pour savoir si l’idée est Nouvelle, Utile, Faisable, et Fun. Chaque personne vote à main levée avec un nombre de doigts, 0 correspondant à pas du tout, et 5 à totalement, et on comptabilise le total des points. Ensuite il convient d’identifier l’idée totalisant le plus de points.

Avec cette idée, en groupe une personne fait le scribe, une l’avocat du diable (il va contrer l’idée par tous les moyens) et les autres sont les anges. L’avocat du diable doit avancer un contre-argument, et les anges trouver un arrangement. Le scribe note tout ce qui se dit.

A la fin de chaque étape, un petit questionnaire circulait avec des questions auxquelles sur les pièges, l’auto-censure, et notre état d’énergie.

Vendredi 16h20 – La CNV

Qu’est-ce que c’est, comment l’utiliser?

L’observation est différente de l’évaluation. La communication non violente est un langage dynamique. Il ne faut pas faire de généralités. De même il faut éviter les négations qui enferment, figent et invitent au jugement. Le jugement doit être à tout prix évité car il ferme la conversation, la personne jugée se sentant agressée (à juste titre).

Par exemple. « Il y a des gens vraiment mal élevés qui ne nettoient pas » devient « A midi Claire et Marc ont sali la table et laissé des traces de leur repas. »

De même on ne doit pas interpréter les sentiments des autres ou faire des diagnostiques et des pronostiques. Ce qui est dit doit être mesurable par une personne extérieure.

Qu’est-ce que j’éprouve ? « Mon besoin d’hygiène n’est pas respecté »

Esclavage affectif : il faut comprendre qu’on n’est pas responsable des sentiments des autres. De même ils ne sont pas responsable de nos sentiments. Nous sommes les propres responsables de nos propres sentiments.

Le bonhomme OBSD résume la CNV.

Dans notre exemple :

  • O : A midi Claire et Marc ont sali la table et laissé des traces de leur repas. (C’est un fait, et pas un jugement)
  • S : Je trouve désagréable que la table soit sale lorsque j’arrive pour manger. (J’exprime mon propre sentiment)
  • B : J’ai besoin que la table soit propre. (Et le besoin réel que j’ai, sans demander d’action)
  • D : Claire, Marc, pouvez-vous nettoyer derrière vous après votre repas s’il vous plait ? (Être prêt à essuyer un refus, mais dans les faits demandé de cette manière, cela arrive rarement)

 

DEVOXX France 2017 : le débrief

devoxx

Les présentations se sont enchaînées lors du DEVOXX France 2017.

Nous avons participé au Devoxx France 2017 qui s’est déroulé du 5 au 7 avril 2017. Dans cet article, nous allons vous présenter quelques conférences intéressantes que nous avons pu suivre. Ces retours sont basés sur notre compréhension personnelle, chacun est accompagné de la présentation YouTube. Libre à vous de les regarder pour vous forger votre propre opinion !

 

PRÉPAREZ-VOUS A LA MODULARITÉ SELON JAVA 9 youtube

Alexis Hassler twitter ET Remi Forax

Cette université de 3h portait sur le projet Jigsaw de Java 9. Il est censé régler les problèmes de dépendances et classpath (en le remplaçant par un module path), les problèmes de librairies présentes dans différentes versions dans le classpath… Cela a permis un découpage du JDK pour pouvoir le distribuer sans forcément tout inclure, juste le nécessaire. Pour les librairies externes aussi, par exemple si on veut juste la partie injection de dépendances de Spring, cela pourra être un jar de quelques kilos au lieu de quelques mégas aujourd’hui.

La config des modules de nos applications va passer par la définition de fichiers « module descriptor » qui vont spécifier notamment quels packages exposer aux autres modules et quels modules importer. Dorénavant, les classes publiques ne le seront plus pour toute l’application, mais uniquement pour le module. Avec ceci, Java 9 va passer également pas mal d’API en deprecated. A partir de maintenant et des prochaines versions, il va avoir du ménage et des deprecated seront supprimés, il faut s’attendre à pas mal de breaking changes potentiellement.

Une bonne partie de la conférence était ensuite de migrer une appli en Java 8 vers Java 9 en la découpant en modules. A noter qu’un bypass de cette utilisation par module sera possible pour inclure d’anciens jar par le biais d’un classpath dédié, de façon à pouvoir toujours utiliser d’anciennes librairies qui ne migreraient pas sous ce style d’architecture.

 

TENSORFLOW ET L’APPRENTISSAGE PROFOND, SANS LES ÉQUATIONS DIFFÉRENTIELLES youtube

Martin Görner twitter

Le but de cette université était de présenter le framework Tensorflow, rendu opensource par Google. Il s’agit d’un framework qui permet de manipuler des réseaux de neurones « simplement » (ou en tout cas plus simplement que ce que cela pouvait l’être jusqu’à maintenant). La conférence a été illustrée par deux exemples qui ont permis de présenter pas mal de fonctionnalités et fonctions mathématiques intégrées au framework.

Le premier exemple était la reconnaissance de chiffres. Il y avait un jeu de données de plus de 60 000 chiffres écrits de façon manuscrite que le réseau devait reconnaître au mieux. Nous allons écrire quelques principes qui ont été décrits, mais pour l’explication assez complexe il faudra regarder la rediffusion de la conférence ! Malgré le fait que le conférencier a bien vulgarisé les principes, cela reste assez dur à retranscrire.

Il a évoqué les matrices multidimensionnelles, les fonctions Softmax, Sigmoid et RELU (Rectified Lineara Unit), la cross entropy, l’algorithme d’optimisation gradient descent, la fonction de régularisation Dropout… Les réseaux convolutionnels ont aussi été évoqués, ainsi que les réseaux récursifs. Ces derniers sont très puissants et permettent de mettre en relations des couches de réseaux de neurones afin d’analyser plus finement les données. A la moitié de la conférence, nous sommes arrivés à un taux de reconnaissance des chiffres de plus de 96%, avec seulement une trentaine de lignes de code.

Le deuxième exemple était de faire intégrer l’ensemble des oeuvres de Shakespeare à un réseau récursif, afin de générer de nouveaux textes. L’oeuvre qui a été générée en live était assez impressionnante, avec des actes, des personnages inventés, des dialogues… En regardant de plus près l’ensemble du texte n’avait pas vraiment de sens, mais on arrive à un résultat assez cohérent sur la structure, l’agencement des mots, etc. Le même principe avait d’ailleurs été appliqué aux oeuvres de Rembrandt, suite à quoi un réseau neuronal avait produit une peinture totalement inédite de cet artiste, respectant l’époque, sa manière de peindre, … On en vient à se demander si on peut considérer cette oeuvre comme un original de Rembrandt ou non.

Ces systèmes sont également utilisés de nos jours pour Google Traduction, la reconnaissance d’images, bientôt la médecine pour détecter des cancers… et bien d’autres domaines.

 

JAVA 8, C’EST BIEN. JAVASLANG, C’EST MIEUX youtube

Mathieu ANCELIN twitter

Cette conférence avait pour but de présenter la librairie Javaslang et son avantage par rapport aux API standards de Java 8. Cela a été fait sous la forme d’une démo de refactoring d’une application.

La librairie présente des fonctionnalités utilisées telles que des List.of ou HashMap.of pour instancier facilement des collections avec des données. On peut noter aussi un type Either<Trowable, Objet> qui permet à une fonction de retourner soit son résultat attendu soit l’erreur qui s’est produite. Il y a également des fonctionnalités pour faciliter l’utilisation des streams, qui permettent, entre autres, de se passer des collectors. A noter que toute collection de Javaslang peut être transformée en collection classique avec une méthode .toJavaList().

 

JAVA 9 MODULO LES MODULES youtube

Jean-Michel Doudoux twitter

Cette présentation consistait à lister les nouveautés de Java 9, sans parler du projet Jigsaw et ses modules. On va avoir :

  • Des try with ressources plus concis.
  • Les opérateurs diamants seront possibles sur les classes anonymes.
  • Les interfaces pourront avoir des méthodes privées.
  • Des factory seront disponibles pour créer des collections immuables.
  • De nouvelles méthodes seront disponibles sur les streams, comme les takeWhile et dropWhile, ou encore les Stream.ofNullable.
  • L’organisation des fichiers du JDK va changer, le JRE et le JDK ne seront plus séparés comme avant.
  • L’utilisation de java en ligne de commande supportera les options standards GNU.
  • Les jar pourront contenir plusieurs releases d’une même librairie.
  • L’outil jshell sera disponible pour avoir une console Java et exécuter des bouts de code.
  • Certains outils du JDK seront retirés, comme le rt.jar et tools.jar.
  • Les numéros de version du JDK auront un nouveau format, de type MAJOR.MINOR.SECURITY.PATCH, par exemple 9.2.3.1.
  • Les objets String prendront moins de place en mémoire.
  • L’outil jdeprscan permettra de scanner nos projets pour savoir si on utilise des API deprecated.
  • L’API StackWalker pour une meilleure lecture des stacks d’erreurs, mieux filtrées et plus claires.

 

LE STREAMING D’API : POURQUOI ET COMMENT TRANSFORMER VOS APIs STATIQUES EN DONNÉES EN TEMPS RÉEL ? youtube

Audrey Neveu twitter

Cette présentation consistait à présenter les différentes méthodes disponibles pour faire des API utilisables en streaming :

  • Long polling : à bannir car il bloque le client et la communication n’est que dans un sens. Une nouvelle connexion est créée à chaque fois, on a aucune idée de si une requête est nécessaire, si les données sont changées ou pas.
  • Webhooks : l’utilisateur renseigne au service l’URL qu’il doit appeler. Cela est assez contraignant, compliqué à debugger et ne fonctionne pas sur smartphone.
  • Websockets : la communication est bidirectionnelle et réalisée en binaire. Le client redémarre la connexion si elle est perdue. Un point négatif est la méthode de connexion un peu particulière qui peut nécessiter de devoir reconfigurer les firewalls. Cette méthode est généralement plus utilisée pour les chats et jeux vidéos.
  • Server Sent Event (SSE) : les performances sont meilleures mais la communication est unidirectionnelle (le serveur push les données au client). Cela fonctionne par le protocole HTTP standard. Pas de support par IE ni Edge mais des polyfills existent.

La présentation s’est terminée par l’utilisation d’une api SSE connectée au cours du Bitcoin et à un drone sur scène afin de le faire décoller ou atterrir en fonction de ce cours.

SPRING FRAMEWORK 5.0 youtube

Stéphane Nicoll twitter

La présentation a fait un petit overview de la nouvelle version de Spring à venir. La RC est disponible et la finale sortira légèrement avant Java 9.

Les performances de démarrage ont été grandement améliorées. Certains cas montrent un démarrage en 100ms au lieu de 6s, cela grâce à une meilleure gestion du contexte. Avant les classes étaient scannées au démarrage pour analyser toutes les annotations, maintenant cela est fait à la compilation en gardant un fichier mapping. Java 9 sera bien sûr supporté, ainsi que le protocole HTTP 2 et le langage Kotlin. Le framework pourra fonctionner avec une programmation Reactive de bout en bout. Il sera ainsi possible d’appeler une API qui streamera directement le contenu de la base en un flux infini (ou pas) de données, et non plus attendre que toutes les données soient transmises d’un coup. Des types Flux et Mono ont été ajoutés pour cela.

Les API pourront également être utilisées en mode fonctionnel et non plus forcément par annotations.

 

10 MÉTHODES POUR RENDRE HEUREUX LES DÉVELOPPEURS, LA 7EME VA VOUS ÉTONNER ! youtube

Cyril Lakech twitter ET Romain Linsolas twitter

Un développeur de chez Axa et un de la Société Générale nous ont parlé de leur vision pour rendre les développeurs heureux en entreprise. Il faut pour eux :

  • Investir dès le recrutement, ne pas mentir au candidat, parler de code avec lui pour savoir si les pratiques de l’entreprise correspondent à ce qu’il attend… Pourquoi pas l’intégrer une demi journée à l’équipe, parler de la culture, la vision, etc.
  • Proposer une perspective de carrière pour que les développeurs restent plusieurs années. Ne pas être toujours dans le rush, prévoir du temps pour qu’ils puissent apprendre, découvrir de nouvelles choses.
  • L’environnement est important. L’Open Space est déconseillé, ou il faut en tout cas mettre à disposition des bureaux flexibles (endroits pour s’isoler), des espaces de détente, des bureaux adaptés aux envies de chacun (debout ou assis). Un bon matériel et de bons logiciel sont aussi importants pour ne pas être frustré, permettre le télétravail.
  • Organiser son travail, découper en petites équipes, feature teams, devops.
  • Software Craftsmanship : bien concevoir le logiciel, penser à la valeur ajoutée de chaque évolution, faire des codes review, du pair programming.
  • Avoir une ouverture technologique.
  • Faire plaisir aux développeurs ce n’est pas que le café gratuit, les pizzas, les nerfs, le baby-foot… Tout ceci est juste un plus et il ne faut pas perdre de vue le reste. Les autres sociétés proposent la même chose et les autres éléments de cette liste vont aussi être déterminants.
  • S’organiser en communauté, pouvoir trouver de l’aide dans les équipes et se rendre utile en aidant les autres.
  • Contribuer à l’open source. Cela permettra de continuer l’apprentissage, de recevoir des critiques constructives et de s’améliorer.
  • Participer aux événements, Devoxx, Meetups, BBL, hackatons (1 à 3 jours), conférences interne, sponsoring d’événements… Toujours dans un but d’apprentissage, d’ouverture d’esprit.
  • Valoriser les développeurs pour qu’ils puissent apprendre tout le temps.

 

SOYEZ HOLOGRAPHIQUE ! youtube

Michel Rousseau twitter

Présentation des HoloLens par Microsoft. Très beau produit, unique en son genre qui permet une projection (et non un affichage) d’hologrammes sur des « lunettes ». L’orientation du produit est plus professionnelle pour l’instant et permet par exemple à un mécanicien d’avoir les plans d’une voiture sous les yeux en permanence, de faire des appels Skype… L’avantage ici est vraiment d’avoir des hologrammes qui se superposent au réel et qui enrichissent le quotidien. Le « casque » capte son environnement grâce à la même technologie qui avait été utilisé dans Kinect et il est complètement indépendant (environ 2h30 d’autonomie), il intègre CPU, GPU, RAM, DD, …

Il est cependant très cher : 3299€ pour l’édition de dev, 5499€ pour l’édition commerciale.

La conférence s’est finie avec la présentation d’un nouveau concept en cours de recherche par Microsoft. Il s’agit « simplement » de pouvoir afficher l’hologramme d’une autre personne, dans la pièce où vous êtes. Ils ont appelés ça l’Holoportation et cela ressemble très fortement à ce qui est montré dans les films Star Wars… C’est encore en développement et cela nécessite notamment une dizaine de Kinect dans toute la pièce pour fonctionner !

 

UNE APPLICATION QUI VOIT, ENTEND ET RÉPOND youtube

Christophe Jollivet twitter ET Mickael Debonnaire twitter

Cette présentation montrait comment construire simplement une application utilisant les dernières avancées en terme d’intelligence artificielle. Pour cela quatre services nous ont été présentés :

  • Beta face pour faire de la reconnaissance d’image, et de visages plus précisément.
  • Speech recognition afin de transformer en texte ce que dit l’utilisateur à voix haute.
  • Api.ai pour reconnaître ce texte et faire des actions en fonction de ce que demande l’utilisateur.
  • Les APIs standards des OS pour générer de la voix et répondre à l’utilisateur.

 

PATTERN MATCHING EN JAVA (10 ?) youtube

Remi Forax

Cette présentation nous a donnée un aperçu de ce qui est dans les chantiers pour Java et ce qui pourrait être intégré à la version 10 ou plus. Les trois projets les plus important ont été détaillés.

  • Valhalla, apportant les Value Types et la Generic Specialization.
  • Panama, pour pouvoir manipuler plus facilement le code natif, notamment pouvoir appeler des fonctions C/C++ depuis la JVM.
  • Amber, apportant l’inférence des types. On pourra faire var name = « Julien » au lieu de String name = « Julien ». Les énumérations sont améliorées avec la possibilité de les rendre génériques. Les lambdas seront améliorées avec quelques idées qui avaient été laissées de côté. Des classes « data » qui permettraient de pouvoir juste déclarer les champs, le compilateur générera les accesseurs et constructeurs. Le Pattern Matching pourra également être de la partie.

Une bonne partie de la présentation était dédiée à ce dernier, avec une proposition de l’implémentation future possible. Il permettrait d’améliorer grandement les switch et de se passer des if-else-if-else-if à la chaine.

 

DE BRONZE A LÉGENDAIRE, COMMENT RÉUSSIR VOS IA DE BOTS youtube

Grégory Ribéron twitter

La présentation était vouée à nous expliquer comment créer des IA de bots efficaces qui peuvent atteindre le top 100 sur des sites tels que CodinGame. L’essentiel est de progresser pas à pas, bien comprendre l’énoncé, mapper correctement les mécanismes du jeu, regarder notre bot jouer, s’inspirer des autres…

Une des techniques est notamment l’utilisation d’algorithmes génétiques, qui permettent de prévoir certaines issues du jeu et ainsi corriger le comportement du bot en temps réel.

 

RECETTES, OUTILS, API ET SERVICES POUR CONSTRUIRE SON EQUIPE OU SA STARTUP youtube

Nicolas Martignole twitter

Trois maîtres mots pour le conférencier : rapidité, transparence et intensité.

On dénombre certains outils et/ou api externes pour simplifier la vie des codeurs et de l’entreprise. Cela passe par des outils de gestions de mail avec Mailjet et Mailgun.
Un point était axé sur la sécurité avec la gestion de double authentification et les réinitialisations de mot de passe par sms.
Egalement le monitoring de services avec des scénarios pour la gestion des temps de traitements avec Runscope.

Puis un gros point sur la communication interne et externe avec des outils performants de live chat pour augmenter la réactivité comme Slack et ses différents modules connectés (runscope, jenkins, etc).

 

JUnit-Docker youtube

Xavier Detant twitter ET Vincent Demeester twitter

Présentation rapide de la libraire JUnit-docker pour JUnit 5. Elle permet grâce à des annotations de lancer des conteneurs au démarrage d’une suite de tests. Plusieurs options sont disponibles, notamment pour spécifier l’image à démarrer et les ports à exposer. Le conteneur peut être redémarré pour chaque test ou réutilisé pour l’ensemble.

 

Log me Tender youtube

Olivier Croisier twitter

Discussion intéressante sur la mise en place d’une couche de service pour gérer les logs au sein d’une application. Cela permettrait de faire évoluer tout un log orienté métier avec des précisions comme les horaires de démarrage et fin, la durée, etc.. Tout ceci par la modification d’une seule méthode appelante. Cela permettrait également d’utiliser du java 8 dans le traitement de la couche de log car actuellement Log4j n’est pas migré et donc pas d’utilisation possible de lambda par exemple.

 

Retours sur Devoxx France 2016 : le jeudi

Devoxx 2016

 

Le but de cet article est de vous présenter quelques conférences intéressantes que j’ai pu suivre cette année, le jeudi 21 avril 2016, au Devoxx France, afin de vous donner envie de les consulter par vous-même. Ces retours sont basés sur ma compréhension personnelle et mes souvenirs, il se peut donc que cela ne soit pas complet ou ne reflète pas complètement la réalité ! Les liens vers les conférences sont donnés à chaque fois pour vous permettre de juger par vous-même.

 

La médecine de demain youtube

Jean-Michel Billaut twitter

Cette première keynote de Devoxx 2016 a permis d’avoir un aperçu de ce que pourra être la médecine demain. Le séquençage de nos génomes devrait devenir un standard pour arriver à une médecine de précision; les traitements seront adaptés à notre organisme et ne seront plus génériques. Cela servira à évaluer notre état de santé et détecter plus en amont cancers et autres maladies. Le séquençage de génomes est déjà possible à l’étranger, mais illégal en France et puni par la loi. La France accuse donc un retard là-dessus. Des startups anglaises, américaines et chinoises ont déjà une grosse base commune de génomes à des fins d’analyses. Une startup chinoise est d’ailleurs déjà évaluée à un milliard de dollars dans ce domaine.
D’autres technologies pourront par exemple nous permettre d’analyser nos aliments en temps réel, d’en connaître leur composition et faire le lien avec notre génome et état de santé pour savoir s’il est recommandé de manger telle ou telle chose.

 

The impact of code in society youtube

Joel Spolsky twitter

Deuxième keynote de la journée. Un des fondateurs de Stack Overflow nous a fait réfléchir sur l’impact des développeurs sur notre vie quotidienne. La décision d’un développeur peut impacter des milliers de personnes, comment celles-ci vont se réveiller le matin, comment elles vont faire du sport… Mais aussi changer l’humeur des personnes. L’exemple de Facebook était évocateur. Facebook n’affiche pas toutes les publications de tous vos amis, un algorithme se charge d’en afficher une plutôt qu’une autre. Il revient donc aux développeurs notamment de choisir que montrer à l’utilisateur. Uniquement des publications qui le rendront heureux ? Et dans ce cas cacher l’annonce d’une maladie d’un ami ? Faut-il que Facebook affiche la photo de votre ex avec son/sa nouveau/nouvelle copain/copine ? Il y a des décisions morales à prendre qui impactent plus d’un milliard de personnes. De même, qu’est-ce qui empêcherait Facebook d’influencer l’opinion des gens et de prendre un parti politique en mettant plus en avant un certain candidat et ainsi lui apporter plus de voix ?
Un autre exemple est celui de l’employé Amazon qui déplace des cartons toute la journée dans un entrepôt, en suivant les instructions données par un logiciel. Celui-ci dicte les pas et « contrôle » en quelque sorte tous les jours des centaines d’employés.
En conclusion, nous ne passons pas 5 minutes sans utiliser un logiciel qui impacte notre vie, d’une certaine manière décidée par un développeur ou une société et cela n’ira qu’en empirant.

 

L’entrepreneuriat au féminin youtube

Natacha Quester-Séméon twitter

Dernière keynote de la journée, intéressante et orientée féministe. La speakeuse nous a parlé notamment de Ada Lovelace et Margaret Hamilton, deux femmes sans qui les langages de programmation n’auraient pas été inventés et l’homme n’aurait pas marché sur la lune. Elle nous a également parlé du collectif JamaisSansElles, qui soutient les femmes un peu à la manière du mouvement solidaire international HeForShe. JamaisSansElles a été initié par le club des gentlemen et toutes les personnes adhérant à ce mouvement s’engagent à ne plus participer à une réunion ou débat public s’il n’y a pas au moins une femme participante. Elle nous a parlé ensuite de l’association qu’elle a créée, Girl Power 3.0 qui est composée d’entrepreneuses et innovatrices.
Dans l’ensemble, elle nous a parlé de la place des femmes dans le milieu informatique, de la nécessité de les intégrer dans les projets, organisations et débats.

 

Java SE 8 pour les développeurs Java EE youtube

José Paumard twitter et David Delabassee twitter

Cette session été axée sur la présentation des fonctionnalités de Java SE 8 appliquées à Java EE 7, ce qu’il est possible d’utiliser et ce qui ne l’est pas. Je vous laisse consulter la vidéo pour en savoir plus, elle est agrémentée de nombreux exemples sur notamment la nouvelle API Date, les annotations multiples, la validation de Bean, les streams, etc.

 

Analyzing Images with Google’s Cloud Vision API Speaker Deck

Sara Robinson twitter

Présentation par une Américaine fan de Harry Potter. Elle nous a présenté les possibilités des API de Google, notamment de l’analyse d’images via du machine learning. Il est possible d’envoyer des images à Google et ceux-ci vont nous retourner un ensemble de tags qui décrivent la photo (c’est donc l’inverse de la recherche Google Images). Cette API est très puissante et capable par exemple de faire la différence entre la tour Eiffel de Paris et la réplique à Las Vegas. L’API peut également détecter les visages et l’humeur des personnes. Il y a également une API de speech qui retourne à partir d’un fichier audio le transcript de celui-ci.

 

Stack Overflow behind the scenes – how it’s made youtube

Oded Coster twitter

Un développeur de Stack Overflow nous a présenté leur architecture. Il nous a exposé quelques chiffres impressionnants (à retrouver ici), comme leurs seulement 4 serveurs SQL notamment avec entre 384Go et 768Go de RAM chacun. Ils ont une stack essentiellement Microsoft, mais leur philosophie est simple, ce qu’ils ont actuellement fonctionne très bien, donc pourquoi le changer. Si un jour, dans leurs expérimentations, ils trouvent quelque chose de plus adapté et qui fonctionne mieux pour eux, alors ils migreront. Il n’y a aucun intérêt de migrer juste pour migrer. Leurs 9 serveurs Web leur permettent de faire des mises en production sans downtime, vu qu’ils sont tous en load balancing.
De la même manière, une migration vers le cloud leur coûterait plus cher et il faudrait refaire complètement leur architecture, donc ils n’ont pas souhaité migrer et on gardé leur propre architecture.

 

Retours sur Java 8 youtube

Jean-Michel Doudoux twitter

La présentation était un petit tour des nouveautés de Java 8, avec des bonnes pratiques recommandées par le présentateur.
Par exemple, il est inutile de mettre des Optional de partout, cela ne fait qu’introduire de la complexité. Les Optional peuvent être évidemment utiles, mais cela ne sert à rien de les utiliser à tout prix.
Autre exemple, inutile de vouloir mettre des lambdas à tout bout de champ. Il faut plutôt essayer de faire uniquement des lambdas d’une seule instruction, sinon le débug peut devenir trop complexe. Dans l’ensemble, il faut faire en sorte de garder des instructions lisibles, quitte à sortir les 5 lignes de code d’une lambda dans une méthode à part.
Il faut également faire très attention à la possibilité de lancer des streams en parallèle. Même si le faire est très simple, dans la plupart des cas cela peut ralentir les traitements plutôt que les accélérer… Il ne faut pas hésiter à faire des tests de performance pour s’assurer que l’utilisation du parallel() est bénéfique.
D’autres points sont également abordés dans la conférence, je vous invite à regarder la rediffusion pour en savoir plus.

 

High-Performance Hibernate youtube

Vlad Mihalcea twitter

Présentation très intéressante et assez complexe sur l’utilisation d’Hibernate et comment en tirer un maximum de performances.
Il a parlé des différentes étapes d’une requête (temps d’acquisition de la connexion, logique d’accès aux données, temps de soumission, temps d’exécution, temps de récupération et temps d’inactivité avant release de la connexion) et ce qui peut être fait pour accélérer les traitements. Il a notamment évoqué l’utilisation des batchs insert et update, des relations entre les entités, de cache de données, des paramètres qui ont pu changer entre les différentes versions d’Hibernate, etc.
Le présentateur a d’ailleurs un blog sur lequel il a écrit un bon nombre d’articles sur le framework et un livre sur le sujet.

 

String Concatenation de 1 à 9 youtube

Remi Forax

La présentation a été menée par un maître de conférence à l’université Paris Est Marne-la-Vallée, développeur sur l’OpenJDK et expert JCP sur 3 JSR (invokedynamic, lambda et Jigsaw).
Le but de la présentation était de savoir comment concaténer des strings de manière la plus performante possible.
Après une analyse du bytecode et du code assembleur géré par la JVM, la conclusion contre toute attente était que le plus rapide, dans son cas présenté, est l’opérateur + et non le StringBuilder. Ceci à cause du JIT qui reconnaît certains patterns de code, certaines méthodes communes et les remplace à la volée par du code assembleur optimisé au runtime. Il nous a ainsi conseillé de coder comme la majorité des gens le font pour que le code soit reconnu par le JIT et soit plus performant. Dans l’ensemble, il est donc plutôt conseillé d’utiliser l’opérateur + pour des concaténations simples et le StringBuilder en cas de boucles, tout en gardant des instructions simples dans ce dernier (pas de i++, pas de Object.toString()), sinon les optimisations ne fonctionneront pas.
Il nous a ensuite expliqué que cela sera réglé avec Java 9 grâce notamment à son travail sur la JSR invokedynamic, mais que le comportement des strings risque d’être altéré. Il nous conseille donc dès maintenant de tester les early builds du JDK9 afin de voir s’il n’y a pas de régression et ainsi les reporter.

 

Modular monoliths youtube

Simon Brown twitter

Présentation discutant des architectures monolithiques et microservices. Le speakeur propose tout au long de la conférence une architecture orientée module, organisée par fonctionnalité plutôt que par service, ou DAO ou contrôleur… Selon sa présentation, cela règle la plupart des problèmes d’architecture qui surviennent au bout d’un moment sur les projets. Il a commencé la conférence par la phrase « Monolith are big balls of mud » et fini en disant que si on ne sait pas bien organiser un gros projet, un ensemble de petits projets ne sera pas mieux et ce n’est pas la solution. Sa phrase de fin était donc « Microservices are a distributed big ball of mud ».

 

Performance: Java vous déclare sa flamme youtube

Vincent Beretti twitter et Nicolas Peters twitter

Présentation sur comment débugger plus facilement des problèmes de performances sur des applications Java, ou autre, avec les Flame graphs. Ils ont présenté les outils créés par un développeur de chez Netflix (Brendan Gregg) spécialiste des Flame graphs, afin d’en générer depuis des threads dump. Ils ont pris un cas concret pendant leur présentation et ont analysé les problèmes de performances avec ces outils.

Loading...
X