La Take Off renait avec une nouvelle équipe (mais soutenue par la précédente) pour une nouvelle édition très intéressante. Synbioz était à l’édition 2013 et voici un retour sur celle de 2016.
Les principaux thèmes qui se sont dégagés de cette édition sont les Bots et les changements qu’ils devraient provoquer, Docker et JavaScript qui n’est toujours pas boudé.
Angela Ricci et Emmanuel Demey | slides
Le HTML est la fondation de votre app et comme pour un bâtiment, de mauvaises fondations se manifesteront sous la forme de problèmes difficiles à résoudre plus tard.
Il est important de conserver la sémantique de votre HTML pour vos applications.
Par exemple, si vous utilisez un lien <a> sans lui donner de href alors il
est inaccessible par le clavier. Cependant, si vous créez un lien sans href,
vous aviez probablement besoin d’un <button>.
La conférence s’est basée sur la version mobile du site de Facebook qui (par
exemple) n’utilise que des <div> sur 6 niveaux de profondeur pour créer ses
boutons de navigations avec un <a> au lieu d’utiliser une liste dans un
élément <nav> et des <button> comme il est maintenant conseillé de faire et
ce qui réduirait la navigation à 2 niveaux de profondeur.
“Design like we give a damn!”
Léonie Watson
Le machine learning expliqué à partir du Titanic. Quelles sont vos chances de survivre en fonction du prix de votre billet, de votre âge et de votre sexe ? En analysant les données existantes, on peut faire une prédiction avec seulement ces informations.
Cependant, ces prédictions doivent être éduquées pour être fiable. Le modèle le plus simple de la data science est donc d’analyser les données, d’entrainer le modèle de code et de valider les prédictions en utilisant un jeu de données de tests dont on connait déjà le résultat. C’est le modèle scientifique classique : on vérifie les prédictions par des connaissances empiriques et quand ça fonctionne suffisamment longtemps, on considère le modèle comme correct.
Si vous souhaitez vous mettre au machine learning, Kaggle propose des exercices directement dans le navigateur pour expérimenter ce genre de chose. L’histoire du Titanic est d’ailleurs l’un des premiers exercices.
Docker est une technologie très pratique mais manager des milliers de conteneurs en production peut être complexe. Retour d’expérience de Scalingo après 3 ans de gestion d’infrastructure en tout genre : des bugs en tout genre, Docker a eu du mal à mûrir mais heureusement, ça va dans le bon sens et les outils qui sont apparus au fur et à mesure sont de plus en plus efficaces.
Il existe un biais mental fort présents dans les entreprises : le biais des coûts irrécupérables. Appliqué comptablement, cela sous entend qu’acheter un logiciel pour répondre à un besoin technique impose de l’utiliser pendant au moins 3 ans, la période d’amortissement. Sinon ce logiciel a coûté plus cher qu’il n’a rapporté.
Cette vision est, pour Quentin Adam, à l’origine de beaucoup de problèmes dans le milieu de l’informatique. Il faut cesser d’avoir une vision budgétaire qui provoque des situations absurdes comme l’équipe en charge de l’infrastructure qui refuse d’héberger un nouveau service nécessaire à l’entreprise parce que ça ferait exploser le budget annuel.
Pour cela, il ne faut pas considérer le devops comme un métier mais comme un processus où les devs et les ops travaillent ensemble pour l’entreprise et non l’un contre l’autre. Pour pousser le concept au maximum, voici ce qu’il faut retenir :
Tout dans l’entreprise doit avoir une API et un mail au CEO n’en est pas une.
Le Multi-Tenancy consiste à avoir une seule application qui gère plusieurs clients de manières totalement séparées. Chaque client a une plateforme complète avec potentiellement plusieurs utilisateurs chacun, en toute autonomie. Le problème de cette approche est de réussir à la rendre scalable.
Voici une approche de Nuxeo à base de conteneurs où chaque client dispose d’une application complète et séparée. Cette approche a malgré tout des défauts, notamment le prix des clients qui ne sont pas encore des clients payants. La solution que Nuxeo a choisi est d’éteindre et de rallumer les conteneurs à la demande et donc de développer des outils pour que ça se passe suffisamment rapidement pour être utilisable. Leur choix final a été d’utiliser Rancher et l’idée derrière tout ça est assez intéressante à mon avis.
Olivier Lance | La version blog de la conf
Comment Algolia a réussi à fournir une API capable de répondre en millisecondes n’importe où dans le monde. Cette conférence nous montre comment on peut partir d’une volonté de l’entreprise à une réalité sur le terrain.
On y apprend que pour augmenter les performances, les recherches d’algolia étaient faites en tant que module à nginx pour ne pas perdre de temps entre le traitement d’une requête et sa résolution.
A partir de là, il a fallu améliorer la redondance des machines, leurs disponibilités dans toutes les zones du globe et créer un système pour avoir une possibilité de rollback en cas d’erreur. Ceci après qu’un bug lors d’une mise à jour ait créé une panne de 8 minutes avant qu’un rollback n’ait pu être fait.
Un point intéressant quand on cherche la performance à ce point est qu’on peut tomber sur des failles du protocole DNS : le domaine algolia.io était à la mode mais les serveurs qui le gèrent n’étaient pas capables de tenir la charge. Il y a maintenant plusieurs domaines en .net et .com pour gérer tout ça.
Il est étrange que dès qu’on passe dans le monde du mobile, on en oublie qu’il faut respecter des règles simples de sécurité. Tour d’horizon des méthodes pour obfusquer son code pour éviter d’obtenir n’importe quoi simplement en décompilant une application web. Sans donner de nom, Marcos Placona nous a affirmé que des app mobiles très connues permettent trop facilement d’obtenir des informations sensibles (mais il craint le procès s’il donne des noms).
Des règles simples : utilisez du HTTPS ou des connexion sécurisées pour communiquer avec vos serveurs, chiffrez les valeurs sensibles, utilisez les options de sécurité quand elles existent (Certificate Pinning) et n’accordez aucune confiance à un appareil utilisateur, ça pourrait être un faux.
Un aperçu du concept de chatops vu par Heroku. Gérer vos opérations de déploiement, de mise à jour ou autre donne de la visibilité à toute l’équipe. Utilisez du two factor authentification pour les changements importants (déploiement en production par exemple) pour éviter des problèmes. Cependant, n’oubliez pas de construire vos bots pour qu’ils puissent s’adapter à d’autres plateformes que celle que vous utilisez actuellement (sans doute slack) au cas où vous seriez amené à changer.
Les bots sont en train de devenir les plus gros consommateurs d’API dans le monde et cette tendance va sans doute aller en s’intensifiant. L’arrivée d’outils comme l’Amazon Echo ou la Google Home est un bon indicateur.
Le problème qui va se poser dans les années à venir, c’est de fournir à ces bots, des APIs qu’ils peuvent facilement exploiter. Par exemple, si l’on demande à un Echo de nous expliquer ce que fait la startup Slack, on veut obtenir la description de Slack, et non pas une liste de toutes les startups qui ont “slack” dans leur nom. C’est pourquoi une API de ce type doit permettre d’obtenir des résultats immédiats en plus de la liste des correspondances. Ceci afin d’éviter de faire un appel qui renverra une liste de correspondances et devoir faire un second appel pour obtenir les informations sur le premier résultat.
Une API devra donc être pensée avec ce genre de contraintes et fournir les résultats dans un ordre pertinent pour être vraiment utile. Il peut être intéressant de se pencher du coté des API auto documentées. Les flux RSS vont probablement finir dans cet état eux aussi à n’être plus consommés que par des robots.
(Notez que ces slides sont censées fonctionner avec chrome mais n’ont pas de garantie avec les autres navigateurs)
Le compagnonnage est une vieille pratique de l’artisanat qui se termine après une
longue période d’apprentissage par la réalisation d’un chef d’œuvre pour
prouver qu’on n’est plus un compagnon mais un expert. Tim nous a montré ce qu’il
s’est mis en tête de réaliser pour son chef d’œuvre : reproduire tous les
drapeaux du monde en CSS avec un seul <div> par drapeau.
“Ce qui est important n’est pas le résultat mais le chemin”.
Le brexit pourrait bien provoquer la fuite de développeurs anglais vers le reste de l’Europe et donc la France. Dan nous a parlé des bonnes pratiques à avoir pour accueillir des développeurs étrangers dans son entreprise :
Et il faut être conscient qu’il peut y avoir des incompréhensions dues aux différences culturelles. Aussi bien au niveau de mauvaises traduction. Dan nous a donné un exemple, sa nourriture préférée : les pickles qu’il a essayé de traduire par “la nourriture dans des préservatifs” (“food in preservatives”). C’est quelque chose qui va arriver mais qu’il faut prévoir et expliquer quand ça arrive.
Présentation d’API Platform, un framework basé sur Symfony pour créer des API hypermedia auto documentées rapidement. Le principe de l’hypermedia est d’utiliser les URLs de l’API en tant qu’identifier de ressources qui gèrent de manière automatique la pagination et le filtrage des données.
Ce framework est compatible avec Swagger, Open API, Hydra, json-ld, … et promet de pouvoir créer une API qui fonctionne en quelques minutes que l’on pourra ensuite pousser grâce à docker.
NativeScript s’est allié à Google pour proposer un concurrent à React Native avec une très bonne intégration de Native Script et d’Angular2. Avec cette intégration, il suffit d’apprendre un nouveau langage de template pour transformer son application écrite en Angular2 en application mobile native.
La promesse est intéressante pour qui utilise déjà Angular et qui veut capitaliser sur ça pour développer une application mobile. Je ne suis pas certain que se mettre à Angular pour cette raison soit une bonne idée cependant. Mais NativeScript reste utilisable seul et avec n’importe quel autre système puisque ça reste du JavaScript.
Laurent Doguin | slides et demo
L’Internet des objets est actuellement ultra centralisé et les objets connectés ont pour énorme faille de devoir passer par un serveur pour communiquer entre eux. Deux ampoules connectées dans la même pièce vont devoir faire un aller retour sur internet pour avoir conscience l’une de l’autre. Ce n’est pas une fatalité et ce talk présente des pistes d’actions pour avoir un vrai réseau d’objet connectés qui soient réellement connectés entre eux.
Il était prévu une démonstration de cette technique avec une application codée pour le besoin du talk mais il y a une autre limitation à ce genre de chose : un routeur wifi doit être configuré pour autoriser la communication entre les différents appareils. Ce qui montre bien qu’il reste pas mal de travail pour atteindre un juste milieu entre sécurité et vie privée.
Christophe Philemotte | slides
Ce talk nous a présenté Hanami au travers de l’exemple d’une API simple. Hanami est fait pour être léger, thread safe, modulaire et non intrusif.
Quand on parle d’un framework Ruby, on ne peut pas s’empêcher de le comparer à Rails et il n’a pas été tendre : Rails est un bon framework pour une application qui fait du CRUD simple mais Hanami est plus facile à maintenir sur le long terme, au niveau de la partie métier qui est mieux à sa place complètement séparée de la logique applicative. Il existe aussi Sinatra mais qui lui est trop léger pour une application complète.
Au final, il est admis qu’il faudra plus de code pour obtenir un résultat similaire à Rails mais plus de code permet un meilleur découplage et de mieux percevoir l’intention de chaque partie de code.
Présentation d’Elixir et de ses apports à venir sur la façon de coder une application web dans les années à venir. Le futur est dynamique et concurrent. D’après, lui il faut limiter les contraintes au niveau du backend qui doit accepter des données provenant de sources diverses et donc être dynamique mais également pouvoir tenir la charge en toutes circonstances et donc être concurrent.
Elixir se base sur Erlang et plus précisément sur sa machine virtuelle BEAM. Ce qui permet à un programme en Elixir d’utiliser toutes les bibliothèques Erlang existantes, d’avoir une gestion des processus extrêmement performante (João nous a montré que son laptop pouvait faire tourner 1500 processus sur 8 cœurs sans problème). Sa syntaxe est inspirée de celle de Ruby, sa philosophie autour de l’expérience développeur également. Le langage est fonctionnel et permet tout de même de faire de la méta-programmation.
Synbioz est d’accord avec la promesse de base en tout cas : Elixir est le futur. En résumé, et comme le dit le co-créateur d’Erlang sur Elixir :
“This is good shit.”
Joe Armstrong
Présentation de Tensorflow, une bibliothèque python open source de machine learning. Au travers d’un exemple de reconnaissance de chiffres manuscrit, Martin Görner nous a montré comment améliorer les prédictions d’un algorithme étape par étape.
“Without a PhD” mais accrochez vous malgré tout. Le machine learning semble un peu plus accessible après ce talk mais n’en reste pas moins compliqué. En définitive, ce que j’en ai retenu, c’est qu’il fallait connaitre une série d’algorithme prédictif, leur donner des paramètres de base, choisir un nombre d’itérations et ensuite faire des essais pour obtenir de meilleurs résultats au fur et à mesure de nos essais. Ça et le fait qu’une découverte en biologie a permit de choisir un algorithme plus simple et plus efficace mais sans qu’on sache réellement pourquoi : vive la science !
Présentation de l’event sourcing, une autre façon d’envisager les bases de données qui consiste à enregistrer les évènements qui se produisent (nouvelle valeur du champ address) plutôt que d’écraser la donnée dans une table et de perdre l’ancienne irrémédiablement.
Une mise à jour de la base de donnée peut donc se contenter de contenir une date et la nouvelle valeur d’un champ. Pas besoin de réécrire toute les données d’une “table”. Bien entendu, il existe des optimisations (à base de snapshot) pour obtenir uniquement les dernières valeurs de chaque champ. Mais cette méthode permet de toujours conserver l’historique des modifications et de réaliser des undo/redo si l’on souhaite.
Pour ceux qui utilisent Redux ou Elm, l’event sourcing ressemble à la logique des reducers/update qui existent dans ces deux technologies. À la nuance près qu’on ne conserve pas forcément les anciennes données mais la logique est la même.
Quoi choisir à l’heure actuelle pour réaliser le frontend d’un produit comme Cozycloud ? Mathias Dugué a choisi une approche fonctionnelle du JavaScript et expliqué pourquoi des solutions comme Ember, Angular ou React ne lui convenait pas. React est une façon hype et moderne de construire des applications web mais selon lui, cette solution n’est pas vraiment de la programmation réactive, désespérément bloated et monoculturelle.
Sa recommandation actuelle est d’utiliser most.js pour la gestion de données ainsi que que Vue.js pour l’affichage et de ne pas se soucier de la mutabilité ou l’immutabilité des données mais plutôt de choisir un data store et de le garder propre.
Je ne suis personnellement pas d’accord avec tout son point de vue (“Elm est intéressant mais comme le dit Brendan Eich ‘Always bet on JS’”, “Stockez vos données dans le DOM”) mais chacun son avis. Mention spéciale au générique de fin de slides cependant.
Présentation des nouveautés de ES2016 et ES2017 (car ES2016 est très pauvre en fonctionnalité). Les nouvelles fonctionnalités de ES2016 sont donc :
** qui fait la même chose que Math.pow et qui peut aussi s’utiliser en tant qu’assignation avec **=
2 ** 3 === Math.pow(2, 3); // 8
let number = 2;
number **= 3 // number = number ** 3
true si l’élément passé en paramètre fait partie du tableau. Pourquoi includes et pas contains ? À cause de mootools
qui étend le prototype d’Array avec contains et qui ne se comporte pas tout à
fait de la même façon.ES2017 est lui plus complet et je ne vais pas entrer dans les détails mais voici la liste :
Array et les Object (Très peu de monde apprécie cette fonctionnalité :/).async/await : vous pouvez vous renseigner sur cet article de ponyfoo ou cette vidéo de dotJS
Quentin Hocquet | slides
Présentation d’Infinit : une solution de stockage open source décentralisée qui se marie bien avec la logique de conteneur Docker. Cette solution est purement logicielle et cette conférence montrait le cheminement pour arriver à obtenir un stockage fiable malgré l’éclatement des données et ce sans avoir un node principal.
Le principe est d’ajouter des nœuds de stockage aussi facilement que de lancer un conteneur Docker classique et de pouvoir scaler avec votre application. L’architecture est très intéressante, notamment au niveau de l’immutabilité des données (en dehors d’un block mutable qui contient la liste des autres blocs et des métadonnées) et des astuces pour améliorer les performances au delà des limites des systèmes de fichiers.
“Learn one, write everywhere” est la promesse de React. Le but est de pouvoir se servir des fondamentaux de React dans d’autre environnements (mobile, desktop,…). Par exemple, ce JSX pour le navigateur :
const Pokemon = ({image, name}) => (
<div>
<img src={image}/>
<span>{name}</span>
</div>
)
donnera pour React Native :
const Pokemon = ({image, name}) => (
<View>
<Image source={image}/>
<Text>{name}</Text>
</View>
)
Si cette syntaxe vous parait bizarre, n’hésitez pas à lire mon introduction à React.
Mais pourquoi ne pas envisager d’aller un peu plus loin et d’utiliser la deuxième version directement pour le navigateur. Après tout, on peut facilement recréer des composants qui auraient les mêmes noms et réimplémenter les composants natifs. C’est le principe de react-native-web qui permet donc malgré la jeunesse de ce projet (Hugo a du demander une mise à jour du projet pour son talk) d’envisager de n’écrire qu’une fois son code pour l’utiliser partout.
Cette reprise de la Take Off augure de bonnes nouvelles pour la suite. Les nouveaux organisateurs ont d’ores et déjà annoncé une nouvelle édition l’an prochain et ils devraient capitaliser sur leurs réussites de cette année pour s’améliorer par la suite.
L’avantage de la Take Off, c’est plein de petites choses : les soirées à Lille après la conférence, des séances d’étirements entre deux talks, des périodes de discussion régulières. Vivement l’année prochaine :)