SimpliField au Web2Day — Part 2
Pour la suite de notre trilogie concernant l’aventure de SimpliField au Web2Day, on vous propose de vous partager quelques présentations techniques qui nous ont plu.
Pour rappel, vous pouvez retrouver:
- L’introduction ainsi que les présentations concernants l’entreprenariat
- Les présentations concernant le design et divers sujets
Dans ces présentations, vous pouvez retrouver des sujets comme Javascript, API, React Native, Flutter, Haskell et bien d’autres. Des sujets donc qui animent l’actualité technique du moment.
Votre API web passe-t-elle le contrôle technique ?
Francois-Guillaume RIBREAU @ OUEST FRANCE
Durant le design d’une API, il est crucial d’avoir une connaissance profonde du besoin auquel elle répond, mais aussi de ses indicateurs de succès. Ces points sont capitaux et seront des valeurs de conformités suivis à travers le projet.
François-Guillaume énumère nombre de ces indicateurs à travers plus de 70 points de contrôle. De la nécessité du nommage explicite à la backward-compatibility, la présentation de François-Guillaume est une source d’information abondante tant pour les Juniors que les plus aguerris.
Il mentionne un point très intéressant: les développeurs sont des utilisateurs (i.e. clients) de leur propre API. La séparation du développement en plusieurs environnements est commune lors de la création d’une API, mais le découpage de celle-ci en plusieurs “mondes”/”royaumes” n’est pas inné. Lorsqu’on utilise une API externe (e.g. Google Maps API) lors du développement, on cherche juste à séparer le “royaume” de celle-ci via un token ou un sous-projet différent. De la même manière, pour le développement d’API en interne, on peut appliquer ce même principe cross-équipe et fluidifier le développement de celles-ci. C’est le principe de Multitenancy.
La Multitenancy n’est qu’un exemple parmi tant d’autres. Chaque slide est un condensé de bonnes pratiques, ce qui fait de cette conférence, selon moi, un must see. Un grand merci à @FGRibreau !
Automating software dependencies — fire alarms vs firehoses
Rhys ARKINS @ RENOVATE
À l’ère de l’open source et du partage, il est devenu extrêmement rare de développer un produit sans importer une librairie externe. NPM, Maven et tant d’autres gestionnaires de paquets offrent de nombreuses fonctionnalités rendant l’utilisations des librairies externes triviales.
L’évolution de ces dépendances n’étant pas liée à leurs utilisateurs, il devient compliqué de vérifier le contenu de chacune d’entre elles. On cherche donc à mettre en place une routine de mise à jour de dépendance, ce pour fixer des bogues plus ou moins majeurs.
Une solution dite de “fire alarm” est de ne mettre à jour celles-ci que dans deux cas:
- La dépendance offre une nouvelle fonctionnalité souhaitée
- La dépendance à la version actuelle a une faille de sécurité/un bug
Dans le premier cas, on va souvent prendre le temps nécessaire à l’implémentation du test de la nouvelle feature. En revanche, dans le second cas, beaucoup plus fréquent, on subit la mise à jour de la dépendance qui peut amener de nouveaux bugs dans notre projet. Malgré la ferveur de la communauté Open Source, ces upgrades de dépendances sont incontournables.
La solution proposée par Rhys Arkins est de mettre en place une plateforme permettant, aux projets privés comme publics, de communiquer sur l’utilisation d’une dépendance X ainsi que sa version Y. La plateforme permettrait de voir, par exemple, qu’étant donné une dépendance X étant utilisée en version 1.2.7 par 1500 projets, 50 d’entres eux sont passés en version 1.3.0 puis ont rollback.
Cela permettrait donc de streamliner le flux de mise à jour de dépendance, offrant la possibilité aux développeurs de mettre en place des conditions de mise à jour telles que “mettre à jour la dépendance X que si 90% des projets ayant fait la mise à jour n’ont pas rollback pendant 2 semaines”. On aurait donc un joli flux de mise à jour, de l’eau sur le feu, petit à petit. Un “firehose”.
Rhys Arkins propose déjà un excellent entre-deux puisqu’il est l’un des auteurs de Renovate Bot : https://renovatebot.com/
Javascript infrastructure at scale
Maël NISON @ DATADOG
La gestion des dépendances est devenue un enjeu majeur dans l’écosystème Javascript. Pour optimiser le temps d’installation et garantir la bonne résolution des versions, Facebook a lancé yarn en 2016. La v1 de yarn nous a offert un lockfile, un temps d’installation réduit, la gestion des monorepos avec les workspaces, le plug and play ( — pnp) mais Maël NISON souhaite aller encore plus loin avec la v2 (https://github.com/yarnpkg/yarn/issues/6953). La principale fonctionnalité annoncée sera le “zéro install” qui permettra au développeur de lancer le projet sans avoir à installer les dépendances. Pour ce faire, il a été choisi de stocker tous les dépendances dans le gestionnaire de version (git) sous forme de fichier zip.
Mais les nouveautés ne s’arrêtent pas là : un mode interactif sera disponible pour ajouter des dépendances, une commande pour exécuter un package sans l’installer, un linter en prolog pour définir des contraintes de version, la possibilité de faire des “sous workspaces” et encore bien d’autres…
Une API GraphQL: du hype à la prod
Aurélien DAVID @ CAP COLLECTIF
Après le RPC et les API REST, GraphQL est maintenant la nouvelle technologie à la mode pour requêter des données distantes.
Pour la partie frontend, le framework relay (https://relay.dev) permet d’agréger les besoin des différents composants pour construire une unique requête GraphQL.
Coté serveur, la librairie Apollo (https://www.apollographql.com) permet de rapidement monter un serveur et d’exposer une api GraphQL. Cependant GraphQL introduit pas mal de nouvelles problématiques, que ce soit pour la mise en cache, les droits, la complexité / performances des requêtes avec le risque de DOS et le monitoring. Attention toutefois, GraphQL ne gère pas de version, il est seulement possible d’ajouter ou de déprécier des nœuds. Nous vous invitons donc à explorer les API existantes:
- https://developer.github.com/v4/
- https://help.shopify.com/en/api/graphql-admin-api/examples/customer
- https://granddebat.fr/developer
avant de vous lancer dans la spécification de votre API !
Votre mission ? Découvrir Haskell et le mettre en prod
Céline LOUVET @ FAIRVIOO
Titre de la conférence un peu trompeur ; il s’agissait ici plutôt d’un retour d’expérience sur l’apprentissage d’un nouveau langage.
Céline LOUVET (@celine_louvet), développeuse avec une forte expérience Java, nous a fait part de son apprentissage sur le tas d’Haskell en tant que CTO de Fairvioo.
En sont ressorti les points suivants:
- Haskell est un langage de programmation difficile d’accès, mais le coût d’investissement en vaut la chandelle.
- Langage difficile parce qu’il force la méthodologie : ce sera fonctionnel, statiquement typé, orienté récursivité. Il y a une et une seule manière de faire et les premières lignes de code sont compliquées à faire tourner.
- Une fois cette étape initiale passée, l’apprentissage est plus progressif, puisqu’on est plus à même de découvrir la multitude d’opérateurs présents dans le langage ainsi que de profiter de la robustesse induite par les contraintes citées précédemment.
- Coder en Haskell fait intervenir de nombreuses notions de programmation fonctionnelle théorique, les apprendre feront de vous, quel que soit votre langage de prédilection, un meilleur développeur.
- Il semblerait qu’une fois adopté, ce langage peut vite devenir votre langage préféré !
Config-as-code? Ok, mais proprement. Goûtez au dhall
Clément DELAFARGUE @FRETLINK
Un constat : la quasi intégralité de nos infrastructures est basée sur des fichiers de config.
L’état de l’art aujourd’hui est de les écrire sous forme de fichiers JSON ou YAML, mais ces derniers sont extrêmement pénibles à manipuler et maintenir: impossibilité de commenter un .json, syntaxe et sensibilité à l’indentation pour YAML, sans parler des diverses subtilités (wtf) de parsing/casting de ces derniers.
Il y a un vrai besoin de pouvoir abstraire l’écriture de ces fichiers de config, à l’aide d’un langage dédié à cet usage.
En bref, nous avons besoin des notions présentes dans nos langages de programmation high level: modularité, configurabilité, composabilité, reproductibilité, typage, …
Dhall est un langage non Turing-Complet (un programme écrit en Dhall finira forcément par se terminer) spécialement conçu pour la génération de fichier de config.
Un programme dhall peut être utilisé de deux manières:
- En guise de config dans un écosystème capable de l’exécuter (Haskell, Java, Ruby)
- Pour générer des fichiers de config en Yaml ou Json (dhall-json)
Un premier pas pour son adoption est de ne pas utiliser les fonctionnalités du langage tout de suite mais de s’en servir pour statiquement typer ses fichiers de config, puis d’ensuite abstraire les répétitions. Pour enfin faire les malins avec les possibilités qu’il offre.
Flutter ou React Native, comment faire son choix ?
Tech & Governance — Simon GALET @TheTribe & Jordan LE LAY @TheTribe
Développement mobile hybride
Le développement mobile hybride est construit en réponse aux problématiques imposées par le développement natif. En effet, ce dernier impose de développer une base de code par système. Par exemple, pour iOS et Android, cela implique deux fois plus de temps de développement, un coût accru, et potentiellement deux sources d’erreurs différentes. De plus, les expériences utilisateurs peuvent alors être différentes.
Le développement hybride permet de n’avoir qu’une seule base de code pour chaque plateforme. Parmi les solutions possibles, il existe Flutter et React Native.
Ces deux frameworks sont open source, il s’agit d’une volontée de leurs éditeurs de les rendre populaires et accessibles à tous.
Flutter
Flutter est un framework lancé par Google en 2017. Il permet le développement d’application mobile et desktop nativement. L’approche de la gestion du style se fait via des widgets.
React Native
React Native est un framework lancé par Facebook en 2015. Il permet le développement d’application mobile et desktop via des librairies tierces. Les styles sont gérés par du CSS.
Comment construire des skills Alexa que vos clients adoreront ?
Benoit NACHAWATI @AMAZON ALEXA
Benoît NACHAWATI, employé d’Amazon sur la partie Alexa de la firme, propose un workshop consistant à la réalisation d’une extension d’Alexa appelée “Skill” afin d’étendre ses capacités.
Pour les plus novice, Alexa est l’enceinte connecté commercialisée par Amazon.
Au programme, un tutoriel réalisé par les soins de Benoît à suivre scrupuleusement.
Pour les plus curieux, ce tutoriel est disponible sur GitHub ici.
Pour résumer, l’exercice consiste à permettre à Alexa de réagir à un mot déclencheur afin d’exécuter notre Skill via des interactions dans différentes langues et tonalités. Le speaker a donc présenté la possibilité de créer une Skill via un process typique de développement avec un passage par GitHub et de l’intégration continue.
A la fin de ce workshop, nous savions tous créer une Skill Alexa simple et utilisable en moins de 2 heures.
