REX : La nuit des Meetups 2023
Pour sa seconde édition, la Nuit des Meetups à Nantes a réuni 300 participants à la Cantine Numérique, au coeur de L’Ile de Nantes.
Co-organisé par La Cantine Numérique, Externatic et les différentes communautés locales, cet événement réunit exceptionnellement ces dernières le temps d’une soirée.
Porté à l’échelle de l’ensemble de la communauté Nantaise, on retrouve le modèle conventionnelle de leurs rencontres: des présentations par des membres de la communauté et un temps d’échange et de rencontre. Le tout accompagné d’un espace restauration financé par quelques sponsors présents sur place (s’ils n’étaient pas visibles, il ne faut pas oublier les sponsors réguliers de ces communautés qui les soutiennent tout au long de l’année).
Les communautés
La majorité des communautés nantaises ont répondu présents, disposant à la fois d’un espace pour s’identifier et faciliter les échanges, ainsi que d’un créneau de présentation.
Si les communautés utilisent différentes plateformes (Meetup, Eventbrite..) pour communiquer, vous pouvez toutes les retrouver ici.
Le programme
Retrouvez l’ensemble du programme et des présentations sur le site de la Nuit des Meetups.
Retour d’expérience des présentations
Parmi les 30 conférences au programme, trois d’entre elles ont particulièrement retenu mon attention:
- Design System x Web Components : une histoire d’amour compliquée
- “J’ai documenté sans compter” : de la DX dans ma doc Produit avec Docusaurus
- Gérer (ou pas) ses propres runners Github Actions
Design System x Web Components : une histoire d’amour compliquée
par Thibault Mahé
Abstract
Porté par ses nombreux frameworks front-end et la popularisation des design systems, le monde du web se concentre toujours plus autour de l’approche en composants. Dans ce contexte, les nouveaux-vieux standards des Web Components restent une source inépuisable de drama dans la communauté. Petit retour succinct sur ces standards clivants, leurs intérêts pour les design systems et leurs inconvénients.
Notes
Un voyage dans le temps nous ramène aux débuts des navigateurs et aux enjeux qui se jouent déjà à l’époque sur la mise en place de règles communes pour un web unifié.
Ce voyage nous emporte jusqu’à la situation actuelle des WebComponents, dans un monde dominé par les frameworks. Dans un contexte entreprise où les stacks tecghniques diffèrent, les WbeComponents restent en capacité à unifier par un socle commun qui se soustrait des contraintes de compatibilité.
On notera néanmoins que si l’intérêt des WebComponent est indéniable, leur usage reste malgré tout aujourd’hui très discret, en dépit d’une adoption par de gros projets reconnus, comme le design system de Clever Cloud. Il faut cependant compter sur des projets comme Lit pour nous proposer unex expérienc développeur améliorée et s’affranchir du boilerplate conséquent nécessaire à la mise en place de WebComponents.
Poursuivez la découverte et les enjeux de pérennité avec WeLoveDevs.
“J’ai documenté sans compter” : de la DX dans ma doc Produit avec Docusaurus
Abstract
Grâce à cette présentation en action de Docusaurus, venez découvrir le tout nouveau “Documentation Park” ! Des composants React dans votre Markdown, un moteur de recherche optimisé, du versionning et de l’internationalisation en quelques clics ! Et si les créateurs du parc avaient enfin remis la Developer Experience au cœur de la documentation ? Lors de ce Tool in action, on découvrira comment nous avons utilisé Docusaurus pour centraliser nos documentations techniques, nos supports de formations et bien plus !
Notes
Documenter, c’est aussi se poser la question de la perennité de la solution choisie et la facilité d’utilisation et d’extension de celle-ci.
Si Kanoma avait fait le choix de GitBook, des changements sur le pricing (tout particulièrement dû à une facturation par utilisateur) ont amené à challenger les alternatives disponibles.
L’objectif pour une documentation développeur est d’arriver à lier la facilité à enrichir la documentation tout en proposant une capacité à étendre les fonctionnalités.
Docusaurus propose un socle solide pour une documentation facile à construire et à explorer. Au delà d’une configuration simple et d’un contenu facilement éditable en md/mdx, c’est un panel de plugins qui s’offre à l’équipe parmi lesquels un outil de versioning, l’internationalisation ou un moteur de recherche avec Algolia.
Docusaurus est aussi le choix que j’ai fait pour améliorer la documentation de RealWorld. Auparavant composée de simple fichiers markdown au sein du projet sur GitHub, son exploration en était donc limitée. Grâce à son core en React, Docusaurus facilite l’usage de libraries pour étendre ses fonctionnalités. Swagger UI nous permet ainsi d’intégrer la documentation d’une API avec quelques lignes de code.
Il me reste à explorer les plugins pour Draw.io et ExcaliDraw dont Pierre a fait une très belle démonstration pour créer du contenu visuel avec aisance et simplicité.
Gérer (ou pas) ses propres runners Github Actions
par Julien Tanay
Abstract
Chez Doctolib, on utilise Github Actions comme moteur de notre intégration continue (CI). En un peu moins d’un an, l’équipe Developer Experience a migré toute l’organisation technique sur cette nouvelle plateforme et mis en place une stratégie de gestion des “runners” (les machines qui exécutent les travaux de CI).
Je suis Engineering Manager chez Doctolib et je pilote les sujets de Developer Experience au sein d’un équipe de Platform Engineering: c’est à dire que nous sommes des fournisseurs de services internes à l’organisation Je vous présenterai nos challenges (qui sont surement les votres!) et les différents choix, motivés, que nous avons du faire. Spoiler alert: aujourd’hui, on ne gère qu’une partie de nos runners, l’autre partie étant gérée par Github pour nous. Cette stratégie hybride nous permet de répondre au mieux aux besoin de nos utilisateurs: les développeurs et développeuses de Doctolib.
Notes
500k minutes par mois, c’est le temps d’exécution cumulé des GitHub Actions chez Doctolib.
Julien Tanay nous offre une très belle narration et nous embarque dans cette migration de TeamCity vers GitHub Actions chez Doctolib.
Via un composition de runners self-hosted et managés, L’objectif pour l’équipe de 5 personnes au service d’une population de 300 développeurs est de pouvoir cocher toutes les cas des besoins tout en offrant une expérience simplifiée aux devs responsables des pipelines de leurs projets.