Retour codeurs en seine 2019
December 11th, 2019 · 10 min read
Deuxième année pour moi où j'ai la chance d'aller à "codeurs en seine".
Codeurs en seine c'est une journée de conférences autour du monde du développement qui accueille 1000 personnes à Rouen.
Je tiens à remercier tous les membres de l'association et les bénévoles pour leurs implications, qui nous permettent d'avoir des conférences de qualitées et GRATUITES.
Voici donc quelques mots sur les interventions auxquelles j'ai assisté.
## Simple n'est pas stupide par [Thierry Croix](https://twitter.com/thierrycrx)
Keynote que j'ai beaucoup aimé pour son rythme et son contenu.
Thierry Croix commence par nous parler de l'évolution de 2009 à 2019 du nom des métiers dans le Web, en se moquant de certains termes trop utilisés (UX quelquechose Expert).
Il fait le constat que tout le monde est expert. Nous avons évolué dans un système compliqué et non complexe. Pour lui il n'y a pas assez de réflexion sur les problèmes de bases. Il est difficile de dire en tant qu'expert auprès de ses clients c'est "juste ça" car souvent pour le client la taille de la solution justifie son prix .
## Et si on se préoccupait plus des patterns par [Laurent WROBLEWSKI](https://twitter.com/LaurentWrob)
Conférence technique pour continuer. Laurent nous parle de JavaScript fatigue et des évolutions rapides de l'écosystème web/mobile depuis 2009.
Avec ce constat il est important de reconnaitre les patterns, beaucoup de frameworks sont semblables et implémentent ses patterns.
Voici la liste des patterns présentés lors de cette conférence:
1. MVC avec les évolutions dans le temps (MVVM et MVP)
1. Réactive programming
1. Singleton
1. Factory
1. Strategy
1. Declarative ui
1. Mixin
Il y a eu de nombreux exemples sur Angular et Android.
En conclusion il est important de voir les patterns avant les frameworks.
J'aimerais beaucoup une suite pour cette conférence, l'évolution des frameworks et les patterns utilisés pour répondre aux nouvelles problématiques.
## Concevoir des applications résilientes en 2019 par [Mickaël Andrieu](https://twitter.com/mickael_andrieu)
Mickael est développeur chez Prestashop. Il nous parle d'un problème survenu chez Prestashop empéchant les utilisateurs de se connecter aux BackOffice.
C'est suite à cette interruption de service que la résilience est devenue primordial dans le projet.
Il nous décrit les notions de Service Level Agreement ([n9](https://en.wikipedia.org/wiki/High_availability#Percentage_calculation): 99.9, 99.99, 99.999) fournit par les tiers et comment calculer le SLA de son propre service.
La résilience est le fait de gérer le cas où un service tiers tombe et ainsi prévoir un mode dégradé.
Lors de cette conférence nous avons le droit à quelques "tips" globaux et en PHP.
Il faut toujours mettre un timeout sur les requêtes HTTP, faire du code non bloquant pour les appels aux dépendances, prévoir un fallback en cas d'erreur.
Ensuite nous voyons le pattern Circuit Breaker et son implémentation en PHP avec différentes librairies disponibles.
En conclusion le pattern Circuit Breaker est intéressant mais limité aux indisponibilités (timeout) et il faudra également implémenter la gestion d'erreur provenant des services tiers (Erreur HTTP 50X).
## Pourquoi ça rame ? Deboguer le front avec Webpagetest et Chrome Dev Tools Par [Jean-Pierre Vincent](https://twitter.com/theystolemynick)
Ce quicky commence par le constat que la performance Web est importante pour l'expérience utilisateur, l'accessibilité et l'écologie.
Cependant les organisations investissent dans la performance Web car ça rapporte de l'argent surtout en e-commerce.
Lors de la première partie nous nous intéressons à Webpagetest, un outil qui existe depuis longtemps qui est toujours intéressant.
Jean-Pierre nous explique comment lancer des tests et comprendre les indicateurs principaux:
* Temps de chargement
* Temps d'interaction
* TTFB = le lag entre le backend et le frontend
* Waterfall = le chargement des différents assets
* Visualisation des écrans (captures d'écrans)
Il est également possible de bannir un sous-domaine afin de voir l'implication des services tiers sur la performance.
Webpagetest permet également de comparer deux tests et la vitesse de rendu via les captures d'écrans.
Nous passons ensuite sur le profiler de chrome.
Jean-Pierre nous rappelle qu'il est important de tester avec un appareil et une connexion correspondant à celui des utilisateurs finaux.
Avec le profiler nous pouvons inspecter les animations, la stack javascript et voir quel sous-domaine est trop gourmand en ressources.
En conclusion ces outils nécessitent un temps d'apprentissage important, mais sont nécessaires pour comprendre quelles sont les causes des ralentissements.
J'ai regretté que ce soit un quicky car le sujet mériterait plus de temps.
Il est intéressant de noter que le profiler de Firefox avait beaucoup de retard, même si l'écart se réduit. Les parts de marché restent en faveur de chrome.
Concernant Lighthouse cela reste un outil de découverte.
## Du sang, des larmes et des pixels Par [Benjamin Anseaume](https://twitter.com/Anseaume)
Keynote après la pause déjeuner.
Benjamin nous raconte l'histoire de son entreprise via les différentes étapes cruciales:
1. Community Management
1. Prestation de création de jeux vidéos
1. Croissance de l'entreprise
1. Rencontre et travail avec SquareEnix
1. Lancement de jeux via Kickstarter
1. Arrêt des prestations
1. Lancement des jeux
1. Fermeture de l'entreprise
Ensuite nous revenons sur les causes possibles de cette fermeture d'entreprise:
* Le pivot lors de l'arrêt des prestations
* La croissance de l'équipe ainsi que les besoins de culture d'entreprise.
* Les emprunts bancaires
Ce fut un retour d'expérience très intéressant.
## 10 incohérences dans les langages informatiques (la quatrième est tellement vraie !) Par [Pierre LACHEVRE](https://twitter.com/PierreLachevre)
Quicky orienté Troll. Que ce soit le JavaScript, Python, PHP, Java, C# nous avons vu avec humour certaines incohérences via des exemples.
A la fin du talk Pierre nous laisse un lien vers un [github](https://github.com/pierreLachevre/ten_weird_quirks_coding) qui fournit les explications du comportement des langages dans les situations citées.
## Montée de version sans interuption par [Nelson Dionisi](https://github.com/ndionisi)
Nelson a commencé le talk par nous présenter les problèmes qui les ont poussés à aller vers une montée de version sans interruption.
Petit retour en arrière en 2017 ou l'entreprise faisait un déploiement tout les 3 mois. Du coup avec le nombre de clients augmentant il fallait maintenir jusqu'à 6 versions du soft. Les montées de versions pouvaient prendre plusieurs heures.
Ensuite en décrivant l'architecture load-balancer => plusieurs serveurs applicatifs => une base de données.
En 2017 il fallait couper toutes les applications du load-balancer lors de l'update.
Ils ont choisi de faire des versions de schemas de base de données et software toujours compatibles avec la version précédente.
Grâce à cela il est possible de modifier la DB ensuite upgrade les applications. C'est grâce à la compatibilité des versions vN et vN+1 peuvent cohabiter le temps de tous passer en vN+1.
Nous avons eu ensuite quelques exemples (l'ajout d'une colonne en plusieurs étapes, la suppression).
Pour terminer Nelson nous a partagé quelques tips pour ne pas reproduire les mêmes erreurs.
Il ne faut pas faire de select * car les plans d'exécution ne sont plus bons ensuites.
Faire attention aux locks de la base de données lors de l'update. Utiliser les mots-clés validate/novalide. Ne pas attendre trop longtemps pour les migrations (timeout) et essayer de la jouer à un autre moment. Avoir la dernière version son SGBD permet d'avoir des temps de locks plus courts.
Avec cet ensemble d'actions, ils peuvent maintenant faire des upgrades de façon quotidienne.
## Le deep-learning démystifié par [Florent D'halluin](https://twitter.com/flal)
Les algorithmes font peurs. Le deep learning n'est pas une forme d'intelligence. Nous n'avons pas de vocabulaire commun avec la machine pour apprendre il faut donc faire une approche itérative. Il faut pouvoir donner du feedback à son model. L'algorithme ressort des estimations pour les différentes sorties possibles. Florent nous parle de Stochastic gradient descent.
Dans une seconde partie nous voyons l'architecture du réseau de neurones et comment l'information se propage. Le principe de backpropagtion permet d'améliorer le model.
Il faut faire attention au sur-apprentissage qui fausserait les résultats, il ne sera efficace que sur un jeu de données restreint.
Il est nécessaire d'avoir un jeu d'apprentissage et un jeu de validation. Le jeu d'apprentissage doit être suffisament varié, pour que le model ne prenne pas de "raccourcis", exemple de classification chiens/chats, les chiens sont souvent sur fond verts dans l'herbe.
Il faut savoir stopper l'apprentissage même si le taux de réussite n'est pas de 100%.
Florent nous a ensuite présenté son "bestiaires" les réseaux neuronnaux actuels.
Les réseaux neuronaux et le deep learning sont de superbes outils, mais Florent nous rappelle que nous transférons nos biais au model. Et pour le moment il n'est pas simple d'expliquer comment le réseau est arrivé à ce résultat.
## 20 choses à connaitre quand on fait du Kubernetes par [Alain Regnier](https://twitter.com/altolabs)
Cette conférence à commencer par un rappel sur la différence entre les machines virtuels et les containers. Puis nous avons eu une brève présentation de kubernetes qui orchestre les containers.
Kubernetes provient de Google Borg. Google qui utilise énormément les containers et cela depuis bien avant Docker.
Voici la liste des tips :
* Utiliser Google Kurbenetes Engine, pour faire des tests
* Faire des alias bash + activer l'autocomplétion pour kubectl
* Il est possible de spécifier le format de sortie. Ex json + utilisation de jq
* Utiliser la console shell de Google Kubernetes Engine
* kubectl top, kubectl proxy
* Il est préférable d'utiliser Ingress pour exposer les services
* Ne pas utiliser kubectl run mais les fichiers de conf
* Mettre la configuration dans un repo git
* ne pas utiliser le default namepsace
* Il est possible de faire du port forward sur un service/pod
## Carte blanche à [Frédéric Leguédois](https://twitter.com/f_leguedois)
Pour terminer la journée j'ai eu le plaisir d'assister pour la première fois à une représentation de M. Leguédois.
Carte blanche qui a commencé par le concept de retro-action.
Cette carte blanche aux apparences de OneManShow se moque des méthodes agiles dans certaines organisations:
* Sprint = planning car ce sont des features à déployer à une date précise
* Il est important de livrer une fonctionnalité pour savoir ce quelle doit faire
* On apprend lorsque l'on met en prod, avant la mise en production ce n'est que spéculation
* Le fait d'accroître les ressources ne fait pas terminer le projet + rapidement mais permet de délivrer plus de fonctionnalités
* Utilisation à plusieurs reprises de l'expression "ça tombe en marche"
* Il est inefficace de mettre la pression sur les développeurs
* Il est important de faire des features les plus petites possibles
* Pour le client réactivité = vitesse
* Il est important de faire simple
* Tacle sur les certifications agiles
* Les DevOps n'existent pas 🦄
* L'importance de mettre en relation les développeurs et les utilisateurs
* Il est primordial de faire un découpage fonctionnel et non technique
## Conclusion
Superbe journée, "étonnamment" j'ai beaucoup apprécié les conférences non techniques, alors que je venais principalement pour la technique.
Je pense que cela est dû à mon statut de "senior UX expert" développeur 😉.
Je repars avec de nombreux concepts que ce soit technique ou organisationnel à étudier et pourquoi pas les mettre en place.
Ci-dessous voici les liens pour codeurs en seine, les slides des talks, les retours, que j'ai glané sur le Web.
* [Le programme codeurs en seine 2019](https://www.codeursenseine.com/2019/programme)
* [Dockerfile best pratices](https://docs.google.com/presentation/d/1nnXIp8Zhc1Tr9LiwG0xvF8KGLcPOpOWZEjHncY8xTLQ/mobilepresent#slide=id.p)
* [Notre première conférence](https://sarvhangel.home.blog/mes-passions-etre-speakeuse-2/)
* [Architecture CSS](https://slides.inseo.fr/2019/codeurs-en-seine/architecture-css.html)
* [Asynchronisme et Event Loop en Javscript](https://docs.google.com/presentation/u/1/d/1DRNy019l4pPiCTu2L5adw8fHhN9WM4DObbk2qwrp5BQ)
* [Retour sur Codeurs en Seine 2019](https://t.co/MlArrUNCbZ?amp=1)
* [Full-remote comment réussir à travailler en équipe](https://docs.google.com/presentation/d/e/2PACX-1vSwQNL8U42byR5xZClJ7NkQl7ClyzjDi3GiEEtevbuiKGEZofRfJzvcRccWk2SIlw1fNo-BIukBVscm/pub)
* [Comment se faire hacker bien comme il faut](https://slides.com/julientopcu/comment-se-faire-hacker-bien-comme-il-faut#/)
* [J'ai demandé mes données personnelles grâce au RGPD](https://files.antoine-augusti.fr/2019/codeurs-en-seine.pdf)
* [Comment j'ai arrêté les boucles for](https://docs.google.com/presentation/d/1zOQ2OD_J7VpqobgA4OhXW7yqw3S7_HCFoh1roEiotuY/edit#slide=id.g65a1ebabba_1_0)
* [Codeurs en Seine 2019, des devs, de l’ux et de l’agilité !](https://www.bearstudio.fr/blog/codeurs-en-seine-2019-des-devs-de-lux-et-de-lagilite)
## Feedback
N'hésitez pas à me contacter sur [twitter](https://twitter.com/sviande) si vous avez des retours, des liens à ajouter.
*[MVC]: Model View Controller
*[MVVM]: Model View VewModel
*[MVP]: Model View Presenter
*[SLA]: Service Level Agreement
*[TTFB]: Time To First Byte
*[SGBD]: Système de Gestion de Base de Données
*[DB]: Base de donneés
