Debrief : Devfest Lille

DevFest Lille 2018 - Débrief

21 juin 2018, fête de la musique ? Pas seulement, c’était également la deuxième édition de la conférence qui monte, j’ai nommé la DevFest Lille. Les Sfeiriens ont encore une fois répondu présents et ont pris place dans les amphis et salles de classe de l’IMT Lille-Douais. Une fois n’est pas coutume, nous vous proposons un petit tour d’horizon des conférences et codelabs auxquels nous avons participé. En bonus vous trouverez également nos photos de l’évènement ici et . Pour les vidéos des talks c’est sur la playlist GDG France

Keynote d’ouverture : UX design et jeux vidéo

Alexandra Nemery & Sarah Colmon font une introduction au User Experience design grâce à un parallèle avec les jeux vidéo.

Le premier prérequis nécessaire à un jeu pour atteindre son public est de connaître ses utilisateurs. Dans le cadre des jeux vidéo, il existe plusieurs profils de joueurs (rangés en 4 grandes catégories) qui n’ont pas les mêmes attentes (compétition, lien social, achievements, découverte, challenge, etc.).

En entreprise c’est la même chose, il est très important de définir précisément sa cible et les attentes auxquelles devra répondre une solution, sans quoi elle ne sera pas utilisée. C’est ce qu’on appelle l’UX search.

Alexandra et Sarah nous présentent ensuite tour à tour des cas de mauvaise gestion de l’expérience utilisateur dans différents jeux vidéo, qui peuvent directement être transposés au monde de l’entreprise :

  • Summoner War
    • Problème de manque d’homogénéité et de clarté pour des messages d’erreur adressés au joueur (concernant en l’occurrence un inventaire plein). Le joueur ne comprend pas le problème, ce qui rend son expérience de jeu moins fluide.
      ⇒ Idem pour une solution d’entreprise, il est important d’avoir des messages explicites et il faut faire attention au vocabulaire utilisé, notamment s’il est spécifique en s’assurant que l’utilisateur auquel il s’adresse peut le comprendre.
  • Heavy Rain
    • Problème de contrôles du déplacement à la manette, différent de ce qui se fait dans l’immense majorité des autres titres, ce qui complique l’immersion dans l’univers du jeu.
      ⇒ Attention aux habitudes de l’utilisateur
    • Difficulté d’une séquence de contrôles permettant au personnage de passer un obstacle particulièrement périlleux, séquence de contrôles qu’il est impossible de réaliser intuitivement, ce qui fait « sortir du jeu ».
      ⇒ Attention à l’écart entre la volonté derrière une fonctionnalité et la façon dont elle est perçue.
  • Dragon Age Inquisition
    • Impossible dans certains cas de comparer directement des pièces d’équipement, forçant le joueur à retenir les caractéristiques d’un objet pour les comparer à un autre, ce qui peut s’avérer gênant, même s’il y en a peu.
      ⇒ Il ne faut pas se reposer sur la mémoire ou les capacités de l’utilisateur pour effectuer une action.
  • Assassin’s Creed Origins
    • Curseur dans les menus et vaste arbre de compétences du joueur. Cela ne pose aucun souci sur PC (facile à manier à la souris), mais c’est peu ergonomique sur console (avec manette).
      ⇒ Attention à bien adapter les commandes au matériel utilisé pour interagir avec l’application (tactile, taille d’écran, etc.).
  • World of Warcraft
    • Densité visuelle des informations données au joueur, ce qui peut rebuter un néophyte… Bien que certains joueurs en soient demandeurs (et augmentent encore la densité d’informations à l’écran par le biais de mods).
      ⇒ Il faut laisser le choix à l’utilisateur : si des informations supplémentaires peuvent être fournies, ne pas les imposer, mais les proposer.

La keynote a été conclue par la présentation de concepts d’UX design déjà présents dans un vieux jeu bien connu : Mario, avec notamment la présentation de ce qu’est un élément affordant : un élément dont l’utilisation est intuitive sans besoin de renfort de documentation ou de tooltip.

Exemples dans Mario : la direction de jeu orientée vers la droite dès le premier écran (position initiale de Mario), les Goombas dont on comprend immédiatement le rôle d’ennemis et la façon de les éliminer (saut sur la tête), les tuyaux un peu plus grands que Mario dont on comprend intuitivement le rôle de passages, etc.

Shigeru Miyamoto, créateur de Mario, est souvent considéré comme un pionnier du domaine de l’UX.

Redécouvrir l’univers connu avec le dataset de la NASA

Aurélien Hebert, Horacio Gonzalez & Pierre Zemb d’OVH viennent nous montrer comment trouver des planètes en dehors de notre système solaire. C’est avant tout l’aventure humaine d’un passionné d’astronomie qui a su mélanger cette passion avec une autre : l’informatique (faire de l’astronomie à Brest est, paraît-il, compliqué. Une sombre histoire de météo…).

HelloExoWorld c’est une association dont le but est d’utiliser la technologie pour analyser le dataset de la NASA (25 To de données, on n’en utilisera qu’une partie)

La théorie: on utilise la méthode de transit, quand on observe une étoile sa luminosité peut varier à cause d’une planète qui passe entre l’étoile et l’observateur, si cette baisse est périodique on peut estimer qu’il y a une planète.

Le codelab nous guide à travers l’analyse du dataset de la NASA. On utilise la solution warp10 pour traiter ces données, on procède comme suit :

  1. FETCH : pour trouver dans un dataset une étoile en particulier.
  2. GET : pour sélectionner une time-serie en particulier (FETCH en renvoie plusieurs).
  3. TIMESPLIT : pour découper la time-serie, cette fonction permet (pour simplifier) de couper la time-serie en cas d’absence de données pendant une certaine période (le satellite se repositionne…).
  4. FILTER : pour sélectionner un sous-ensemble de split obtenu précédemment.
  5. BUCKETIZE : pour regrouper des points sur une période temporelle, ça permet de lisser les points et d’éliminer les petites variations qui ne sont pas pertinentes.
  6. MAP : pour faire la moyenne sur une fenêtre glissante, l’idée c’est d’avoir une vraie courbe de moyenne.
  7. APPLY : pour comparer deux splits, ici on va soustraire la courbe du BUCKETIZE (données brutes) à celle du MAP (la moyenne), on a alors une visualisation des variations.
  8. MAP : à nouveau, cette fois-ci pour chercher les valeurs en dessous d’un certain seuil, quand on s’éloigne trop de la moyenne c’est que quelque chose passe devant l’étoile (on a éliminé les faux positifs via le BUCKETIZE).
  9. MAP : (encore) là, on transforme les données pour juste avoir les possibles exoplanètes.

Tadaaa!!!

Les points bleus c’est (peut-être) des exoplanètes, la courbe c’est la luminosité (lissée). Le tout est envoyé à la NASA pour confirmation.

Cette technique ne s’applique pas qu’à la recherche d’exoplanètes, on peut aussi l’utiliser pour :

  • la médecine : comparer et identifier des motifs pour repérer des risques de maladie.
  • monitoring de serveur : scruter les logs pour trouver les problèmes avant leur apparition.

Les Principes de Base du Design

À travers de multiples exemples de « mauvais » et de “bons” designs, Angela Ricci nous présente les bases du design web, la perception cognitive et comment les lois de Gestalt appliquées au web design nous permettent d’obtenir un layout cohérent et engageant pour les visiteurs.

Similarité d’aspect, proximité, continuité – tant d’outils discrets à votre disposition pour réaliser des designs simples et agréables, même en tant que développeur !

Machine Learning par un imp-op-steur

Un talk intéressant qui repart des « bases » du machine learning sans travail prémâché par les outils dédiés à la tâche, comme Google Cloud AutoML.

Olivier Wulveryck introduit le sujet avec une anecdote : une rupture de petits pains chez le boulanger à 9h30. Le boulanger n’aurait-il pas pu avoir un modèle lui permettant de prévoir la quantité de petits pains vendus à chaque moment de la journée pour éviter cette situation de rupture ? C’est ce qu’a tenté de faire Olivier, en se basant sur les données de vente récoltées auprès du boulanger. À partir de ces données, on peut tracer des courbes et déduire une « moyenne » en faisant une régression linéaire, et “prédire” combien de petits pains seront vendus tel jour à telle heure… On demande à la machine une information qu’elle ne connaît pas à partir de l’apprentissage des données qu’on lui a fournies : c’est déjà du Machine Learning.

À partir de cet exemple, on peut donner quelques définitions :

  • Perceptron : réseau de neurones simple à n entrées et une sortie. Le perceptron est composé de n poids associés à chaque entrée et d’une fonction d’activation basée sur la somme des entrées pondérées permettant de déterminer une sortie (ex : transformer une probabilité en oui/non).

⇒ Exemple d’utilisation : Est-ce qu’à 10h j’aurais vendu plus de 100 petits pains ? L’apprentissage du modèle permettra de déterminer les poids associés à chaque entrée pour répondre le plus précisément possible à cette question.

  • Deep learning : ce sont des perceptrons chaînés, la sortie d’un perceptron est utilisée comme entrée d’un autre perceptron.
  • Réseau de neurones récurrent : c’est un réseau de neurones prenant en compte le contexte.

⇒ Exemples d’utilisation :

  • Habituellement à 10h j’ai vendu 100 petits pains, aujourd’hui j’en ai vendu 120, il faut que je revoie mes prévisions en conséquence.
  • Démo avec le « Shakespeare LSTM » : on encode un alphabet dans un tableau, on utilise un texte de Shakespeare (où en l’occurrence celui des Tontons Flingueurs), et le but va être d’utiliser ce texte pour déterminer à chaque fois la lettre suivante pour constituer un texte. Le contexte est ici nécessaire pour construire des mots avec des enchaînements de lettres différents.
  • Process de Markoff : c’est un process où le passé n’est pas utile pour déterminer un output.

⇒ Exemple d’utilisation : Pour une grille de morpion, il n’est pas nécessaire de connaître l’ordre des coups précédents pour déterminer un coup : la grille dans sa situation actuelle seule suffit. Démo avec un algorithme « brute force » permettant à la machine de jouer au morpion, en apprenant toutes les combinaisons gagnantes (sous forme de graphe).

  • Apprentissage supervisé : apprentissage par l’exemple, avec un jeu de données exemples. La machine confronte ses prédictions à la réalité et améliore son modèle en conséquence.
  • Apprentissage par renforcement : apprentissage par attribution de récompenses, positives ou négatives, le but étant de maximiser le score. Exemple pour le jeu de Go, une succession de coups permettant de capturer X territoires.

Application au métier d’Ops : est-il possible de transmettre le savoir d’un Ops à une machine ? Le métier d’Ops est constitué de beaucoup de graphes : topologie d’applications, configuration, etc. Le machine learning peut aider à « résoudre » et optimiser ces graphes.

Une machine peut en moins d’une heure acquérir dix ans d’expérience d’Ops sur des configurations amenant à un échec (plantage de prod pour raison matérielle ou logicielle, etc.), et de là, proposer des modèles évitant ces écueils, laissant l’Ops se concentrer sur des tâches plus intéressantes et gratifiantes.

Grâce aux outils facilitant le Machine Learning, il n’est pas nécessaire d’être data scientist pour se lancer.

Modern Authentication API

Léo Unbekandt partage avec nous l’expérience de Scalingo dans la mise en place d’une authentification solide et sécurisée.

Partant d’un simple token d’identification en première approche, le fait d’avoir un même token sur toutes les applications est vite devenu problématique pour Scalingo en termes de renouvellement et de révocation des tokens.

Une authentification moderne doit être compatible avec une utilisation de microservices d’API multiples, scalable et autoriser l’authentification via des applications tierces.

Tokens d’API

Un bon exemple est celui d’Algolia, qui fournit une interface très simple permettant de générer des token d’API configurables (permissions, expiration, throttling…).

Ces tokens sont très simples à utiliser via des headers et s’intègrent facilement avec tout client possédant une bibliothèque HTTP.

Malheureusement ces tokens possèdent des défauts : trop de standards, difficiles à distribuer et pas de délégation d’authentification. Autant de raisons qui ont convaincu Scalingo de passer à autre chose.

OAuth 2.0

OAuth 2.0 est un mécanisme de délégation d’autorisation. Il permet à un tiers d’utiliser un service avec vos données et votre consentement. C’est bien entendu le protocole utilisé par les services que nous connaissons tous (s’identifier avec Facebook, Twitter, etc.).

Il existe différents modes de délégation dans OAuth. Léo s’intéresse ici au cas précis des applications Scalingo qui demandent un accès à vos repositories GitHub pour en faire la mise en production.

Pour accéder à vos données, l’applicatif de Scalingo vous redirige en premier lieu vers le serveur d’authentification de GitHub. L’utilisateur est alors invité à se connecter à son compte GitHub et à autoriser l’application Scalingo à effectuer des opérations en son nom sur ses repositories.

Suite à cela, un code est renvoyé à Scalingo par GitHub lors d’une deuxième redirection, ce dernier associé à un client id et client secret spécifique à l’application Scalingo permettra d’obtenir dans une troisième phase un token unique permettant finalement l’utilisation des API de GitHub, le flow est complet. Un token de renouvellement pourra également être obtenu afin de ne pas avoir à redemander le consentement de l’utilisateur en cas d’expiration du token principal.

Qu’en est-il de l’identification des utilisateurs eux-mêmes ?

Le principe est très simple, l’utilisateur fournit son identifiant et mot de passe à un serveur d’authentification qui répond avec le contenu nécessaire à l’authentification de ses prochaines requêtes (typiquement un token).

Cependant, un token dans sa plus simple expression est une chaîne de caractères aléatoires et implique donc une vérification auprès du service d’authentification afin de savoir si ce dernier est valide à chaque appel. Cette pratique, bien que fonctionnelle, est inefficace en termes de charge et de latence et peut ralentir toute une infrastructure.

La solution, est apportée par les Json Web Token (JWT).

En couplant OAuth2 à JWT, on obtient un token contenant toutes les informations nécessaires à sa validation (date d’expiration, algorithme de chiffrement, checksum, etc.).

Quelques recommandations sont tout de même à connaître pour l’utilisation des tokens JWT :

  • Durée d’expiration courte en cas de compromission (à renouveler en fonction de son utilisation)
  • Configuration de la librairie JWT pour n’accepter qu’un seul algorithme de chiffrement
  • Changement régulier du secret de chiffrement

Scalingo a choisi une solution combinant les avantages des clés d’API et JWT en utilisant les clés d’API pour retourner des tokens JWT temporaires à utiliser au sein de chaque application.

En résumé, l’audience a bénéficié d’une introduction très efficace aux bases de l’authentification moderne à l’aide de l’expérience de Scalingo. Léo a su expliquer les avantages et inconvénients de chaque méthode et prévenir les éventuels problèmes de sécurité qui peuvent être rencontrés en fournissant les bonnes pratiques utilisées sur leur plateforme.

Tout le monde sait comment utiliser Angular / React / VueJS, mais savez-vous comment utiliser JavaScript ?

Un talk très intéressant sur le JavaScript, avec quelques pièges à éviter et la présentation de quelques nouveautés arrivées dans les dernières spécifications.

Aurélien Loyer et Nathan Damie ont enchaîné avec un live-coding et explications de code sur quelques fonctionnalités de base qu’on peut trouver dans les frameworks JS : binding entre un champ et un paragraphe, routeur, etc.

Il est bon de rappeler que JavaScript et les API disponibles dans le navigateur permettent déjà de faire beaucoup de choses ! Est-ce que nous utilisons trop les frameworks (parfois sans réel besoin) ?

Les slides.

Git dammit !

Maxime GHIGNET nous a présenté un certain nombre d’astuces et commandes Git qui permettent à une équipe de réduire le TDM/s, ou « T’as deux minutes » par seconde.

Avec l’objectif d’avoir un historique Git « propre », sans enchevêtrement de branches, Maxime nous a proposé diverses méthodes pour réécrire l’historique :

  • modifier le dernier commit :
git commit --amend
  • créer un commit de fixup sur un commit A existant :
git commit --fixup A
git rebase -i A~ --autosquash
  • annuler des modifications en cours : (avec les différentes options –hard, –mixed et –soft)
git reset HEAD~
  • rebaser une branche sur une branche dont l’historique a changé :
git rebase E~ --onto master

Toutes ces commandes nécessitant bien sûr un « force push » sur la branche distante pour écraser l’historique existant :

git push -f origin ma-branche

Et enfin, la commande qui donne son nom au talk : git dammit, qui permet d’annuler toutes les modifications locales et revenir à l’état de la branche distante :

[alias]
  dammit = !BRANCH=$(git rev-parse --abbrev-ref HEAD) \
               git fetch origin $BRANCH \
               git reset --hard origin/$BRANCH

Le mot de la fin

Ces retours sont loin de couvrir tout l’évènement. Ce sont des morceaux choisis par les Sfeiriens parmi les 30 sessions proposées par les speakers du DevFest (merci à Simon La Personne, Remy Gardette, Siegfried Ehret, Guillaume Mantopoulos, Emmanuel Longeau). Plus de 400 personnes ont pu assister cette année à la conférence et profiter (pour une somme raisonnable) des animations, sponsors, ateliers, repas et sont repartis les bras chargés de goodies, la tête pleine de nouvelles idées pour améliorer ou refondre leurs applicatifs et méthodologies. Parce qu’avant tout, ce type d’évènement doit permettre à tous de prendre le recul nécessaire sur son quotidien de développeur et mettre en lumière les nouveautés et opportunités qui sont disponibles ! Bravo à la team GDG Lille, l’identité de votre DevFest prend forme, rendez-vous l’an prochain pour une nouvelle itération.

PS : Après Commit Strip et SpeechLess, vous avez mis la barre bien haute pour les keynotes de clôture, on attend la suite avec impatience !

Vous aimerez aussi...