Le 9 juin dernier se tenait le premier DevFest Lillois à l’initiative de son GDG éponyme. SFEIR était sponsor de l’événement et l’équipe a profité des nombreuses conférences et codelabs dans les locaux d’e-artsup. Vous retrouverez dans la suite de l’article les condensés des talks auxquels nous avons participé, bonne lecture !
Antoine : A la recherche de notre ikigai
Hubert Sablonnière ouvre cette journée en nous contant son histoire : “Si on prend l’intersection de tous les gens qui font du trampoline en club et de ceux qui font du japonais, au milieu il ne reste qu’une personne : moi”.
Lorsqu’on lui demande pourquoi il fait du japonais il répond “pour le plaisir d’apprendre”. Apprendre et découvrir de nouvelles choses est une fin en soi, une vraie passion pour lui, tout comme le développement logiciel.
Hubert nous résume : “J’ai choisi un métier qui fait appel aux mêmes compétences que celles que j’utilise dans ma passion”. Et pourtant les deux sont bien distinctes. En effet le soir ou le week-end nous ne travaillons (généralement) pas sur les mêmes projets que pendant la journée. Et lorsque nous ressortons notre “side project”, les règles du jeu sont complètement différentes : plus de délai, plus de comptes à rendre, plus de processus à respecter. Nous concentrons notre énergie sur des projets qui ne servent pas les mêmes objectifs, qui n’ont pas les mêmes buts que ceux sur lesquels nous travaillons la journée et nous passons du temps à expérimenter, à découvrir, et à apprendre, dans des conditions que NOUS définissons (même si une fois en production, nos “side projects” peuvent être parfois aussi contraignants que les “day jobs projects”). Le but est simple : continuer d’apprendre.
Nos passions ne sont pas plus sottes que celles des autres. La société définit des standards, des choses qu’on pourrait faire pour se divertir, et d’autres qui ne seraient pas aptes à être divertissantes. Pour certains, divertissement rime avec séries TV, films, jeux de société, trampoline ou japonais. Pour d’autres, cela rime avec informatique, électronique, veille technologique, etc. On nous appelle souvent “geeks”, avec nos passions un peu incomprises et nos t-shirts décalés.
Au final, nous avons tous été un jour les Pierre Brochant et les François Pignon de quelqu’un d’autre. Ouvrons nos esprits ! Et arrêtons d’avoir honte de nos tours Eiffels en allumettes. Car le but premier d’une passion n’est pas de faire plaisir aux autres, mais de s’amuser !
Hubert nous présente à travers un dernier diagramme de Venn ce vers quoi l’Homme tend : l’ikigai; afin de nous montrer que passion et profession sont bien deux choses distinctes, même s’il peut y avoir des intersections…
Le mot de la fin, à défaut de trouver votre ikigai, amusez-vous dans ce que vous faites…
Seb : Serverless juste un Buzzword ?
Les nantais Julien Landuré et Eric Briand ont fait étape à Lille pour un tour d’horizon en mode live coding du serverless, ces fonctions sans état exécutées dans le cloud : j’ai nommé le FaaS.
Google trends nous le confirme, le serverless fait parler de lui depuis 2015. Il a été rendu possible grâce aux technologies récentes, la containerisation notamment. Il permet l’exécution à la demande de fonctions simples sans état dans des limites de mémoire et temps. Il doit permettre la scalabilité et surtout pousse le paradigme du “Pay As You Go” à son maximum, l’unité minimale de facturation devenant la centaine de millisecondes.
Nos speakers nous présentent cette ultime abstraction du cloud computing sous forme de duel des géants que sont : Amazon Web Service et Google Cloud.
Premier constat quand on se lance dans le serverless, c’est encore très jeune :
- Comment développer, OK
- Comment déployer, OK
- Comment on fait pour mettre à jour 1 fonction parmi 50 ?
- Comment je teste mes fonctions ?
- C’est quoi les bonnes pratiques ?
- Stateless mais comment maintient-on des connections en BDD de manière efficace ?
Beaucoup de questions que l’on va se poser et dont il n’y a pas (encore) de réponse unanime.
Les deux fournisseurs de cloud mettent à disposition des interfaces Web et API complètes pour manager les cloud fonctions. Pour le choix des technologies avantage AWS qui propose du node.JS mais aussi du Java, du Python et du C# là où Google arrivé plus récemment ne propose officiellement que node.JS et des hacks pour d’autres langages comme le Golang.
Julien et Eric nous font également la démonstration du serverless framework, un outil en ligne de commande qui va vous permettre de créer vos functions pour le cloud provider de votre choix (aws, google, IBM OpenWhisk ou encore Azure), de les déployer ou encore en récupérer les logs. Attention n’imaginez pas avoir du “write once and run everywhere”, pour le moment pas d’initiative dans ce sens, la guerre du serverless à l’instar de celle du cloud fait rage.
Au final, nous avons eu les démonstrations des fonctions dans leur état actuel, vous pourrez vous faire votre propre idée en visionnant la vidéo de la session lorsqu’elle sera disponible.
En conclusion, il apparaît clairement que pour une utilisation “event driven” pour de la transformation de données en provenance de device IoT la question de l’utilisation des fonctions se posera, ne serait-ce que pour une question de coût. En revanche, dans leur état actuel, bien téméraire celui qui construirait un backend d’application complexe à base de serverless uniquement.
Manu : le changement c’est maintenant
Le GitHuber Alain HELAILI nous a expliqué le GitHub flow, ou comment GitHub met en production tous les jours.
Tout d’abord il faut comprendre comment GitHub fonctionne en tant qu’application. Ses développeurs sont répartis à travers le monde et pour la plupart en remote, ils ne peuvent pas attendre qu’un ops dans un autre fuseau horaire mette en production leur code. D’autre part la production est unique de par sa nature (nombre de serveur, charge…). De ce constat est apparu la nécessité de pouvoir mettre en production facilement, de n’importe où, n’importe quand et de manière automatisée et fiable.
Pour maintenir un niveau de qualité élevé du code, il faut également fournir aux développeurs des outils leur permettant de vérifier cette qualité mais aussi de pouvoir avoir rapidement un feedback humain sur le code. Pour cela une pull request est ouverte au plus tôt pour démarrer l’échange et vérifier automatiquement le code. Mais le test ultime reste tout de même la mise en production, c’est dans cet environnement que la phase de qualification se fera et si tout va bien, le code sera alors mergé dans master (oui ils déploient avant de merger, master est une sorte de backup).
Pour gérer ces mises en production Alain nous présente alors le meilleur travailleur de GitHub : Hubot, il s’agit d’un chat bot capable, entre autre, de déployer une branche sur un environnement :
deploy <branch> <env>
Alain nous demande alors si l’on est capable de corriger un bug en production en 10 minutes ? En effet, un bug peut toujours passer à travers les mailles du filet, 2 options s’offrent alors à nous :
- on a facilement identifié la cause et pu la corriger : on déploie un fix.
- on ne sait pas corriger : on redéploie master
Toujours avec le même processus que précédemment bien sûr. Ce qu’il faut se dire ici c’est qu’on n’a pas besoin de plusieurs branches permanentes, master se suffit à elle même, plus besoin de branche développement ou hotfix.
Pour savoir s’il y a un bug en production, le développeur doit disposer d’outils pour savoir ce qu’il s’y passe (monitoring, logs…).
Du fait de ces mises en production régulières un problème survient: comment gérer la mise à disposition d’une nouvelle feature ? Ici interviennent plusieurs outils permettant de décorréler mise en production et mise à disposition d’une feature :
- Scientist : pour pouvoir tester une nouvelle version du code en parallèle de l’ancienne.
- Flipper : du feature flipping, le marketing peut alors gérer la disponibilité d’une feature.
- Gh-ost : pour la migration d’une base de données MySQL.
En conclusion :
- Automatiser tout ce qui est automatisable
- Simplifier pour éviter le plus de risques possible
- Informer le développeur de la première ligne de code jusqu’à la production
Laisser les développeurs avoir la main sur la production peut sembler effrayant en premier lieu, mais comme nous l’a fait remarquer Alain, si l’on est capable de mettre en production en 5 minutes on sera capable de rollbacker ou corriger tout aussi vite.
Pour en savoir plus : Understanding the GitHub Flow.
Antoine : Atelier Jenkins Pipeline
Jean-Marc Messen et Damien Duportal de Cloudbees nous ont présenté les nouveautés de Jenkins 2, suivi d’un atelier d’introduction au pipeline. Pourquoi Jenkins 2, 12 ans après sa première release ? L’ambition de Jenkins n’est plus l’intégration continue, mais d’être un outil de delivery continu. Sans casser la compatibilité avec la version 1, Jenkins 2 propose maintenant de décrire ses pipelines “as code”.
L’atelier consiste justement à écrire notre premier pipeline. Une box Vagrant est disponible comprenant Gogs (serveur Git en Go), Jenkins, un terminal et un projet Spring Boot de démo permettant de pratiquer Jenkins Pipeline en autonomie, disponible via les slides.
L’une des difficultés lorsqu’on se lance dans les pipeline avec Jenkins est la syntaxe en Groovy, qui demande parfois pas mal d’essai à coup de commit, lancement de build, erreur, et rebelote. Cloudbees a donc répliqué avec le declarative pipeline, une syntaxe plus simple à prendre en main. Il est toujours possible d’écrire ses pipelines en Groovy, ou même d’inclure du Groovy dans du . Cloudbees préconise désormais d’utiliser la syntaxe déclarative par défaut.
Avec BlueOcean (la nouvelle interface de Jenkins) a été ajouté un éditeur de pipeline (caché pour l’instant), vraiment pratique pour commencer, à quand la release ? Nous découpons donc la construction du build Maven en étapes (stage), puis commençons à intégrer des tests d’intégration, et finalement on casse le build pour voir comment cela s’illustre dans l’interface.
Clairement le générateur de pipeline facilite les choses, on va pouvoir créer les différents “stages” de son pipeline et ajouter des steps comme exécuter une commande shell, archiver un artefact (et le réutiliser sur un autre agent …), attendre une condition (une validation manuelle par exemple), et bien d’autres choses.
Nous avons également l’occasion d’utiliser docker avec Jenkins pipeline. Il est possible d’utiliser ou d’exécuter une image docker, mais également de jouer des commandes à l’intérieur de l’image docker. Il est même possible d’utiliser le moteur Jenkins directement à l’intérieur de l’image.
Cloudbees veut clairement répondre à la problématique du ticket d’entrée élevé sur Jenkins pipeline avec le declarative pipeline. Jenkins qui est largement majoritaire dans les entreprises comme moteur d’intégration continue, est bousculé sur le cloud avec des outils parfois plus simple à mettre en place, comme Travis ou Circle. La difficulté à mettre en place des pipelines vient également du fait que tout le monde n’a pas à disposition tous les outils nécessaires (un Jenkins à jour par exemple) pour tester les pipelines. La box vagrant proposée lors de l’atelier est un outil qui devrait être plus mise en avant.
Clément & Quentin : Advanced Search for your Legacy Application
David Pilato, évangéliste Elasticsearch, nous a fait la démonstration des performances et de la facilité d’optimisation de la suite Elastic, avec pour seule arme une application legacy. Par legacy, comprenez ici, une application type CRUD, taillée pour la démonstration (à grand renforts de Bootstrap) et dont le but est d’effectuer des recherches au sein d’une base de données de personnes, dont l’insertion se fait en temps réel, unitairement, et de façon aléatoire. L’application est au commencement connectée à une base de données relationnelle (MySQL), et utilise les frameworks RESTX et Hibernate (pour servir l’application, et manipuler les données).
La démo commence par une insertion d’un lot de 1000, puis 10 000 personnes dans la base de données. Une barre de progression ainsi qu’un compteur nous informent de la progression de l’opération (plusieurs centaines d’insertion par secondes), mais le plus intéressant se cache dans la partie « recherche » de l’application où, au travers des champs classiques (nom, prénom, ville et pays) David nous fait la démonstration des fonctionnalités basiques de son application. Il nous explique enfin ce que nous sommes venus chercher : son application fait le travail qu’on lui demande, les recherches sont performantes, mais ses capacités restent limitées !
La recherche ne peut se faire que sur une colonne à la fois : la recherche nom-prénom devient compliquée.
Les résultats remontés ne sont pas forcément pertinents : les champs nom et pays ont le même « poids » , et « France Gall » se retrouve vite noyée dans les résultats des personnes habitants en « France »
La recherche reste stricte, et n’est pas tolérante à la faute de frappe.
L’occasion était trop belle, David nous a donc proposé de connecter le moteur de recherche à son application pour y dupliquer ses données. en commençant par la mise en place de la couche DAO ElasticSearch pour la sauvegarde des données (en parallèle à MySQL) ainsi que l’implémentation de la recherche (un terme est recherché sur plusieurs champs) :
Les 2 bases sont alimentées à la même vitesse que précédemment
La recherche est toujours aussi strict, et limitée, mais les résultats sont plus pertinents : la recherche semble privilégier les noms aux pays (qui sont moins discriminants)
Retrait de l’insertion MySQL pour ne garder qu’ElasticSearch : l’insertion du jeu de données est plusieurs fois plus rapide ! Plus de données sont insérées dans le moteur de recherche, qui encaisse la charge sans problème, avec une recherche toujours aussi efficace, tout en continuant à charger des données en parallèle. Après nous avoir expliqué les fondements du moteur de recherche – non transactionnel et ne consommant que du JSON – David nous a ensuite bluffé en mettant en place le chargement des données en utilisant un BulkProcessor permettant une indexation par paquet. La base est vidée et rechargée : 10 000 personnes sont générées et absorbées instantanément par ElasticSearch !
Pour parfaire la démonstration, notre speaker nous a initié à la recherche partielle (partial matching) en configurant son outil pour utiliser l’analyser NGram Tokenizer qui permet d’indexer (et donc de rechercher) sur des tronçons de champs : « france » devient ainsi cherchable via ‘f’, ‘fr’, ‘fra’, ‘fran’, ‘franc’ et ‘france’; mais également via ‘ra’, ‘ran’, ‘ranc’, ‘an’, ‘ans’ etc. Cette configuration de l’indexation est faite au sein même d’ElasticSearch. La recherche devient plus intéressante, et permet d’obtenir des résultats plus fins, mais ce n’est pas tout : on nous propose alors de mettre en place une recherche moins stricte, tolérante à la faute de frappe, et toujours aussi rapide. Pour ce faire, il utilise les FuzzyQuery, une nouvelle configuration d’ElasticSearch (n’impactant en rien l’application « legacy ») qui permettent d’être tolérant sur n caractères consécutifs (1 seul dans notre exemple). Ainsi, malgré une recherche comportant une faute de frappe telle que « France Gill », nous arrivons à retrouver ce que nous cherchons : « France Gall » , même si « France Gill » est retrouvée dans la résultats en priorités (car elles sont pertinentes, et la valeur des champs pondérées).
David Pilato est efficace dans sa présentation et nous impressionne par sa rapidité d’exécution dans la mise à jour de son application et la configuration de ses outils. Il parvient malgré tout à captiver son auditoire, tenu en haleine par la montée en puissance progressive de l’application. C’est une belle démonstration, efficace, abordant les concepts fondamentaux d’ElasticSearch, qui apparaît alors comme une solution abordable, facile à mettre en place, et dont les capacités semblent répondre à bon nombre de besoins.
Aurélien et Romain : Découverte du design génératif pour la création graphique et artistique
Sylvain Coste et Daishi Kaszer, de e-startup, sont venus avec l’idée de nous ouvrir au monde du design génératif. Le but de la session n’était donc pas de nous présenter les outils dédiés à la création d’oeuvre graphique, mais de nous présenter en un minimum de temps un maximum d’artiste, de réalisation.
Le principe du design génératif est d’utiliser un algorithme pour générer des formes en fonction d’un modèle. Historiquement, les modèles servent le monde de l’art. L’utilisation du plotter est un quasi pré requis lorsque l’on commence à s’intéresser à cette pratique. On trouve, par exemple, le travail de Eno Henze qui intègre son modèle dans une architecture existante :
Mais les représentations artistiques ne sont pas obligatoirement abstraites, certaines ont une approches très vivantes. Dans ce sens, le projet Light Kinetics des studios Espadaysantacruz met en évidence la propagation de la lumière. Celle-ci devient la matière et, pilotée par Unity3d, voyage dans un tube d’ampoule. Le résultat est bluffant !
Light Kinetics – Espadaysantacruz
Aujourd’hui, l’utilisation du design génératif est utilisé dans des contextes proches de notre quotidien. Il est ainsi possible de représenter les modèles Big Data grâce à ces techniques. Dans ce sens, Sylvain et Daishi ont présenté le projet 4010 facebook tree de onformative. Le but de ce projet, commandé par Deutsche Telekom, est de représenter sous forme d’arbre se rapprochant le plus possible de la nature, les interactions des clients avec leur page Facebook.
4010 Facebook Tree – Onformative
Dans la même idée, le projet cf. city flow tire un modèle théorique de l’utilisation des vélos en milieu urbain. En collectant les données des stations de départ et d’arrivée, le logiciel extrapole les chemins utilisés par les utilisateurs des services de locations pour en tirer un modèle génératif.
cf. city flows (2015 – 2016) – Till Nagel & Christopher Pietsch
Enfin, ce qui est intéressant dans l’approche design génératif c’est que c’est à notre portée. Avec un logiciel (https://www.processing.org par exemple) et une idée de data visualization, il est possible de créer une “oeuvre” ! Et si on veut aller plus loin, pourquoi ne pas s’affranchir du logiciel et laisser l’intelligence à un poisson rouge ! C’est ce qu’a réalisé Abovemarine en offrant la possibilité à José de voyager !
José and the Abovemarine (2014)
Nous espérons que, comme nous, cette courte introduction vous aura donné envie de devenir un artiste, aussi bien dans vos expériences personnelles que professionnelles.
Une belle première édition que ce DevFest Lille. Des conférences et ateliers de qualité et variés. L’équipe s’est creusée la tête pour avoir une programmation mêlant speakers nationaux et locaux. L’avantage des conférences à taille humaine est qu’elles permettent d’échanger avec les têtes d’affiches et de s’ouvrir à des sujets moins “mainstream”. En attendant la deuxième édition on va pouvoir regarder les vidéos de la session, je vous laisse notamment vous régaler avec la keynote de fermeture de l’équipe commit strip et son “qui veut gagner une carrière de développeur”, enjoy.
The post DevFest Lille 2017 appeared first on SFEIR Mag.