C’est avec des souvenirs encore frais que Jonathan & Théo nous font un debrief’ des conférences auxquelles ils ont pu assister lors des trois journées du Web2Day édition 2017.
Pour ceux qui n’ont pas le temps :
- Il faut faire du DevOps pour répondre aux contraintes projet actuelles qui demandent de plus en plus d’Agilité. Un buzz word que l’on a beaucoup entendu.
- Pour cela, on peut s’appuyer sur les structures Cloud qui permettent de faire/défaire à volonté des environnements complets à la demande (sous réserve d’avoir un devOps pour coder les déploiements).
- Certaines conf’ ont été filmées et seront disponibles sur la chaîne Youtube du Web2Day sous peu.
De dev’ junior à leader, comment décupler son impact
Présenté par @Pascal Corpet (Lead Dev’ / Manager chez Google)
Les slides : Comment décupler son impact
Le résumé :
Cette première session a fait office de bonne piqure de rappel sur notre métier de développeur logiciel. Avant de parler d’améliorer son impact, à son échelle (au niveau de son équipe pour un dev’, au niveau de son entreprise pour un lead dev’, au niveau du monde pour une entreprise), il a défini ce qu’était l’impact.
Il a ensuite abordé les grands axes qui pour lui permettent d’augmenter son impact, à un niveau développeur d’abord (Getting things done, Vitesse d’exécution, Clean Code, …) puis à un niveau lead dev’ / manager (amélioration des processus, produit, recrutement, meetup …)
Il a consacré la dernière partie à l’aspect management de croissance d’un développeur au cours de sa carrière. C’est la partie que j’ai trouvé la plus intéressante où j’ai découvert la notion de Situational LeaderShip
Du craft chez les ops
Présenté par @François-Xavier Vende et @Matthieu Herbert
Les slides : Du craft chez les ops
Le résumé:
« SI as a service » : La session a commencé par un peu d’auto-promo pour leur boîte qui propose de fournir une infrastructure entière, hébergée sur le cloud et connectée à l’infra du client. L’avantage étant qu’on peut défaire/refaire/répliquer les environnements complets pour les besoins du projet. On retrouve donc la notion d’agilité / intégration continue.
Dans un deuxième temps, ils ont centré la présentation sur le rôle du DevOps, un ops (technicien en charge du déploiement d’une application, qui gère la partie infrastructures) qui code toutes ses opérations pour permettre la réutilisabilité. Et qui dit code, dit bonnes pratiques, même(surtout?) dans des scripts de déploiement (principes KISS, YAGNI, TDD, refactoring, etc).
Ils ont illustré une partie de ces bonnes pratiques avec une démo de tests d’intégration.
Je suis donc sorti de cette session avec cette idée plus clair d’infra as code (applicable aussi bien sur le cloud qu’avec une infrastructure interne à l’entreprise).
Multipliez vos rapports avec JSON
Présenté par @David Grelaud
Le résumé:
Entrée sur scène du speaker déguisé en super-héros rose, tout gesticulant, j’avoue qu’à ce moment, je ne savais pas trop à quoi m’attendre lors de cette session, et pourtant… !
Derrière le masque se cachait le co-fondateur d’une boîte Nantaise : Ideolys dont l’une des activités est de générer des menus pour les restaurants de la France entière (de mémoire, on parlait en milliers de restaurants). Il fallait donc mettre à jour les menus chaque semaine, sous format … PDF. Et c’est là tout l’intérêt de la présentation. Ideolys vient d’Open Sourcer leur librairie JS génératrice de PDF : Carbone.IO.
Cette librairie a la particularité de générer du PDF à partir d’un objet JSON. La solution a l’air très complète. Elle est basée sur NodeJS (il faut toujours un serveur pour générer les docs) et utilise Libre Office pour la génération. Elle fournit un moteur de templating/tags puissant.
A noter également une démo sympathique d’une application web qui permet d’avoir un aperçu du document, avec un panneau pour modifier en live le JSON source, qui sera normalement disponible en libre aussi.
Librairie à suivre, donc.
Ce que j’aurais aimé savoir quand j’ai commencé mon App React Native + Redux
Le résumé:
Un retour d’expérience qui n’en était pas complètement un, puisque l’application présentée n’est pas encore en production. J’ai pu néanmoins découvrir Code Push , un service Microsoft qui permet de « forcer » les mises à jour de l’application en silencieux, sans que les utilisateurs n’aient besoin de faire la mise à jour eux-même. Idéal pour déployer un bug fix majeur après une mise en production.
Pour la partie Redux, l’intervenant est passé très vite sur le concept de gestion d’état de l’application. Donc une session relativement décevante, avec peu d’informations. Je retiendrais tout de même Code Push et MobX, une alternative pour la gestion des states.
Au secours, mon chef m’a demandé de passer Dev Ops
présenté par @aguilloteau (Fenikso) (travail chez SNCF en tant que Scrum Master)
Les slides: Au secours, mon chef m’a demandé de passer Dev Ops
Le résumé:
En partant du constat que la gestion de projet en cycle en V fonctionne mal (32% de projets réussis), l’intervenant préconisait une démarche Agile.
Au programme de cette session, rappel sur des 4 piliers de l’Agilité (et son application concrète : Scrum). Pour ensuite parler du rôle du DevOps qui permet de l’appliquer.
L’activité d’un développeur aujourd’hui ne s’arrête pas au code métier. Pour illustrer cela, Un dev’ passe effectivement beaucoup de temps à coder l’application (environ 40% du temps). Mais les développeurs dans l’équipe SNCF alloue également une bonne partie de leur temps au tests unitaires, d’intégrations et aux scénarios fonctionnels (30% de leur temps). Un développeur doit être capable de livrer la solution, c’est à dire créer une release à n’importe quel moment (pour éviter le Bus Factor), cela représente environ 20% de son temps. Enfin, il passe aussi du temps en opérationnel (sur la production), cela occupe les 10% restants de son temps.
Toutes ces actions doivent être automatisées au maximum, via du code, on reste donc dans le cœur de métier du développeur.
Devenir hacker en 10 min
Le résumé:
Présentation du proxy ZAP proposé par l’OWASP.
Conférence très intéressante, consistant à la prise en main de l’outil sur des exemples concrets.
ZAP est un proxy, qui fonctionne avec des applications locales ou distantes, on a juste à configurer le proxy dans son navigateur préféré pour que le flux transite par ZAP.
Ensuite, on navigue sur notre application et on peut voir les requêtes émises dans ZAP, et là où ça devient intéressant c’est qu’on peut « attaquer » telle ou telle requête. ZAP va alors tester les attaques classiques et essayer de trouver des failles (injections SQL, XSS, récupérations d’infos sur le server, etc.).
Par défaut, il y a pas mal de vecteurs d’attaques disponibles et on peut les customiser et en ajouter de nouveaux.
Il est possible d’écrire des scénarios et de les exécuter automatiquement (il existe un plugin Jenkins par exemple).
A mon sens c’est très intéressant et tout à fait exploitable chez A5sys, on pourrait facilement le mettre en place et ainsi améliorer la sécurité de nos applis en vue de la loi du 24 mai 2018.
Domain Driven Design et REST
Le résumé:
Principe de développement qui consiste à partir du domaine métier, et à isoler celui-ci dans le code. On définit d’abord les entités métiers pures et ensuite on construit le reste autour.
Cela revient à une architecture par couches concentriques : au centre les entités purement métiers, ensuite les services métiers, ensuite les entités applicatives, les services/contrôleurs applicatifs et enfin le Front/UI.
Ce type de conception revient à d’abord analyser le métier pur et ensuite à en faire une application. De cette manière on a une couche métier qui est presque agnostique de l’application, qui peut donc être réutilisée facilement dans d’autres applications, qui est pérenne (car généralement le domaine métier ne change pas trop alors que les applications oui), et elle est compréhensible par les personnes fonctionnelles.
En terme d’architecture API REST, on va exposer nos entités métier aux travers d’API REST explicite et la doc générée doit être compréhensible par les fonctionnels afin qui la valident (elle fait office de spec).
Dans le cas d’API REST, on tend à parler également de RDD (Resources Driven Design) vs DDD.
Cette approche est intéressante, elle formalise ce que l’on fait déjà chez A5sys mais en le poussant à l’extrême. L’inconvénient étant pour moi qu’il est souvent nécessaire de dupliquer une entité pour avoir son pendant purement métier technique, et son pendant applicatif agrémenté de quelques champs nécessaires au bon fonctionnement de l’application.
Cloud patterns – Applications that scale
Le résumé:
Présentation des bonnes pratiques pour réaliser des applications qui se déploient bien dans le cloud et sur qui peuvent être scalées horizontalement.
Ces bonnes pratiques sont illustrées par 12-factor apps. Je ne les détaille pas ici, allez voir le site.
Quelques patterns ajoutés par le présentateur :
- Circuit breaker = réponse en erreur rapide et on réessaie plus tard (mieux pour l’utilisateur que de bloquer longtemps)
- Cache = plusieurs niveaux de cache : cache d’instance, cache distribué, cache navigateur, etc. Le cache de plus haut niveau (HTTP) est le plus performant, car même pas besoin d’exécuter la requête et donc de mettre en branle le framework, etc.
- Asynchrones = Think CQRS
- Use the right tool = beaucoup d’outils disponibles et utilisables facilement dans le cloud (Firebase, DynamoDB, etc.)
- Pay for actual use : code optimisé = moins de coûts sur cloud
Conférence très intéressante, les principes énumérés sont à appliquer et à diffuser en interne. Ils ne sont pas seulement utiles pour le cloud, à mon sens ce sont des bonnes pratiques pour le développement web en général.
Le web de demaintenant
Le résumé:
Présentation de quelques technos et API récentes qui vont permettre de nouveaux usages.
Cela concernait surtout les objets connectés. Les 2 présentateurs ont notamment parlé de :
- Web speech
- BLE (Bluetooth Low Energy)
- Physical web : l’objet émet l’URL = BLE Beacon
- WebUSB : aux fabricants de le supporter, pas besoin de driver
- Image Capture API : contrôler la caméra du téléphone en gérant ses paramètres également
- WebNFC qui arrive
Conférence intéressante, on aura sûrement bientôt l’occasion de manipuler certaines de ces technos.
Automating developer environments
Le résumé:
Présentation en anglais d’un outil permettant d’automatiser l’installation d’un projet en dev et les tâches en cours de dev (lancer un serveur local, vider le cache, etc.).
L’outil a été développé par le présentateur en collaboration avec un collègue. Il se base sur Docker pour l’environnement d’exécution et Make pour la préparation de cet environnement.
Au lieu d’écrire un README souvent fastidieux et jamais tout à fait à jour, on écrit un script simplifié ou on vient définir un certain nombre de commandes normées qui restent les mêmes d’un projet à l’autre : build, run, restart, clear, etc.
Le seul logiciel à installer sur son poste est donc Docker, pas besoin d’installer php, apache, node, mysql, etc.
A noter également qu’on peut définir des comportements de refresh / restart automatiques du container, par exemple si on a changé les dépendances (modification composer.json ou package.json).
Outil très intéressant pour A5sys qui rentre tout à fait dans la réflexion sur la productivité et le passage à Docker pour simplifier les environnements de développement et de qualif.
10 méthodes pour rendre les devs heureux
Le résumé:
Conférence du fondateur de JeChercheUnDev qui a parfaitement résumé toutes ces choses essentielles pour le bien-être et l’efficacité d’un développeur, et qui sont souvent mal comprises par les non-développeurs.
Les 10 méthodes évoquées :
- L’importance de favoriser l’apprentissage continu et de ne pas enfermer les devs sur une seule techno, mais au contraire de permettre de changer régulièrement de technos. Il faut tordre le cou au préjugé qui impose aux devs de se spécialiser dans une seule techno pour répondre aux offres qui demandent « Angular 2 avec 10 ans d’expérience ». Les technos changent et évoluent, un bon dev sait s’adapter en apprendre de nouvelles.
- Concept de la feature team : un dev back, un dev front (ou +) qui travaillent conjointement au développement d’une fonctionnalité métier de bout en bout. Cela favorise l’efficacité, encourage le peer programming et apporte un sentiment d’accomplissement une fois la feature terminée.
- Les grands open spaces nuisent à la concentration et ne sont pas une bonne solution. Certaines règles y sont nécessaires : respecter la concentration des devs, pas de bataille de nerfs en permanence, mettre en place des indicateurs pour montrer aux autres que l’on est concentré.
- L’équipement de travail est primordial : une bonne chaise, du matériel au top, de bons outils. Les développeurs sont pour la plupart des ingénieurs, ils savent ce dont ils ont besoin, et quand ils le font savoir, il faut respecter leurs demandes et arrêter de les remettre en question. Une licence pour un logiciel permettant de travailler plus efficacement, même si le prix peut paraître élevé sera vite rentabilisée, idem pour le matériel. Le télétravail est également extrêmement bénéfique pour le développeur et l’entreprise.
- Les développeurs sont quelque part des artisans car ils créent, il assemble, en essayant que le résultat soit élégant, performant, etc. Il faut investir du temps afin d’encourager et de transmettre cette passion au sein de l’entreprise.
- Il faut impliquer les développeurs dans le processus de recrutement, car ce sont eux les plus à même de juger les compétences techniques et la passion d’un candidat. Cela permet également d’éviter les offres d’emplois aberrantes dans lesquelles soit c’est trop vague, soit on demande un mouton à cinq pattes (10 ans d’expérience dans une techno qui existe depuis 2 ans…).
- Faire le lien avec les utilisateurs est important, la technique ne doit pas être le seul but du développeur, il faut qu’il constate l’impact pour les utilisateurs.
- Les sociétés d’informatique sont majoritairement constituées de développeurs, c’est à eux de faire la culture d’entreprise, à eux d’intégrer au mieux les autres développeurs.
- Il faut éviter l’effet tunnel, c’est-à-dire s’enfermer dans de mauvaises pratiques en tant qu’entreprise (process de dev, de qualif, etc.). Pour cela il faut s’informer, participer à des meetups, participer à des conférences, échanger avec d’autres sociétés, etc.
- La contribution à l’Open Source est primordiale, et ne devrait jamais être optionnelle. Beaucoup d’entreprises profitent de l’Open Source sans contribuer en retour, sans prendre le temps de signaler ou de corriger un problème dans un outil utilisé, etc.
Très très bonne conférence qui fait beaucoup de bien. En tant que développeurs chez A5sys, nous sommes nombreux à parler de ces sujets entre nous, parfois avec nos managers. Là, de voir que non seulement tous ces sujets sont évoqués, mais qu’une salle comble acquiesce à chacun, ça fait chaud au cœur.
