Chaque année, l'association HackYourJob organise plusieurs unconferences (forums ouverts) à Lyon.
À l'instar de mon précédent article à ce sujet, je vous propose de revenir sur celle qui s'est déroulée le 27 septembre 2024.
Pour rappel, une unconference est une conférence sans conférencier : ce sont les participants qui proposent et animent les sujets.
Cette édition s'est déroulée dans le lieu de coworking de La Source (6ᵉ arrondissement de Lyon) qui dispose de nombreux espaces, ce qui rend pratique ce format.
Je vous propose de revenir, dans cet article, sur des sujets que j'ai pu suivre.
Kata Nearest Color
Sylvain Coudert nous propose un Coding Dojo pour démarrer la journée.
Je le complète en proposant le Kata Nearest Color que j'avais proposé sur CodingDojo.org.
Après un petit peu de retard et quelques minutes de setups pour se connecter à la télé, on commence à coder en Mob Programming.
Et, bien entendu, pour terminer, on garde un peu de temps pour savoir comment s'est passé la session, voici les retours :
- On aurait dû faire du TCR (Test Commit Revert) ;
- On a démarré tard (il manquait de temps) ;
- Le kata était cool ;
- Le kata était très court.
Pour ceux qui sont habitués des Meetup des Software Crafters Lyon, nous avons l'habitude de mettre nos ROTI dans nos comptes rendus.
Ce "Return On Time Invested" permet d'avoir une idée de l'intérêt de la session pour s'améliorer aux prochaines, en voici les notes :
- 3 personnes à 3/5
- 2 personnes à 4/5
Déployer Strapi sur Scaleway Serverless Containers
Dans le cadre du Programme Société Numérique, Marc Gavanier nous explique ce qu'il a mis en place pour les déploiements.
Les sources sont disponibles sur GitHub.
Pour des raisons de souveraineté, Scaleway a été choisi. C'est un cloud français du groupe Iliad et son interface est plus simple que celle d'AWS.
La partie "contenu" du site est gérée par Strapi, un CMS headless open source.
Marc a choisi de séparer les applications en plusieurs repositories et de faire son infrastructure avec Terraform.
Il utilise des conteneurs Docker gérés par le service "Serverless Containers" de Scaleway pour l'application front.
En revanche, il n'existe pas d'équivalent de CloudFront chez Scaleway. Pour le CDN, il a regardé Baleen qui est souverain, mais comme il n’existe pas de moyen de se créer un compte pour voir comment il fonctionne, il n’a pas creusé. Il n'a pas non plus réussi à utiliser Cloudflare.
Pour les technologies, c'est du Next.js, et il est utilisé dans un mode où un serveur est nécessaire principalement pour des raisons de SEO, il n'est donc pas possible d'envoyer le résultat dans un équivalent de S3.
Côté back, c'est similaire au front avec en plus des configurations pour des accès à des services managés, dont :
- Serverless SQL pour la base de donnée PostgreSQL 16 ;
- Object Storage pour les images : il y a un plugin Strapi pour connecter le stockage des images avec un service S3.
Pour rendre visible les déploiements depuis l'interface de Terraform Cloud, Marc a mis en place un trigger côté GitHub Actions.
DDD Côté Front ?
Lucas s'interroge sur la pertinence d'une Architecture Hexagonale côté front suite à un essai sur une application mobile en Flutter.
Note : Il y a parfois des confusions entre DDD et Architecture Hexagonale, sans doute à cause de la compatibilité de DDD avec cette dernière.
Pour lui, à première vue, le front n'a pas de métier.
Suite à la discussion, nous remarquons plusieurs points qui font émerger des notions de métier autour des validations par exemple.
Je propose l'idée de typer chaque notion pour faire émerger naturellement ces notions.
La discussion dérive ensuite sur vertical slice et les approches stratégiques de DDD.
Un homonyme parfait, un enfer administratif
Ce sujet a déjà été présenté au camping des speakers 2022.
David Aparicio nous raconte son périple administratif avec un homonyme parfait.
En 2007, David se lance dans une conduite accompagnée, après avoir choisi son auto-école, la préfecture refuse sa demande de conduite. Il découvre alors qu'il est déjà inscrit à Toulouse au même nom, prénom et date de naissance.
En 2012, il se réinscrit à la CAF et reçoit le dossier d'inscription de son homonyme qui est considéré comme inscrit à celle de Toulouse. Son conseiller lui apprend que le dossier a été fusionné entre les homonymes et qu'il n'est pas possible de les séparer malgré un lieu de naissance différent. Le conseiller lui demande de détruire le dossier de son homonyme. C'est cet événement qui a permis à David de comprendre l'existence de son homonyme parfait.
En 2020, son homonyme fait un test PCR, ce qui empêche David de prendre un rendez-vous sur Doctolib. Par conséquent, il devient impossible pour David de se tester en situation de cas contact.
En 2022, David fait un test PCR préventif avant de rejoindre sa famille, pour les résultats, il y a confusion avec l'adresse et le numéro de téléphone de son homonyme.
En bonus, David nous raconte l'histoire d'une personne déclarée morte à tort avec pourtant un gros dossier de déclaration.
La discussion se termine sur des anecdotes sur des changements de noms de rues ou des problèmes avec des fournisseurs d'accès à internet à cause des déménagements.
Expérimentations pour rendre React réactif
Dans son expérimentation pour rendre React plus réactif, Marc Gavanier se base sur un effet de bord de Optional::pipe() (RxJS) en se basant sur son expérience avec Angular via son AsyncPipe.
Cet effet de bord permet de relancer le rendu du composant. L'idée est d'utiliser ce même principe dans React et Next.js.
Pour cela, il crée deux composants distincts, un avec des filtres et un autre avec un compteur. Il ajoute ensuite un nouveau composant <Subscribe> pour écouter les changements d'un Observable. Ensuite, il utilise ce composant comme un wrapper pour celui à mettre à jour.
À titre personnel, je trouve que cette approche masque divers problèmes comme l'écoute de plusieurs événements sur un même composant et la responsabilité du composant qui se délie de son écoute des changements.
Changer de stack/langage
Dans cette session, Adrien, développeur .NET, cherche à changer de technologies pour :
- Apprendre la syntaxe ;
- Découvrir l'écosystème d'une autre stack.
Il nous parle alors d'un exemple avec une mission en python et des imprimantes à l'aide de Celery.
Suite à cet échange, Sylvain partage son expérience de changement de stack.
Il nous parle d'un premier projet dont la stack évoquée est problématique alors que c'est plutôt la qualité du code des data scientists qui est en cause.
Suite à ça il parle d'un second projet en Java pour le comparer à ses habitudes côté .NET. Pour lui, passer de .NET à Java est globalement un non-événement. Sur les approches, ce sont les mêmes rapports à la qualité de code. L'adaptation au langage devient donc anecdotique.
Pour indiquer les quelques points plus compliqués, il évoque l'usage d'un IDE non habituel (IntelliJ IDEA) où, avec le recul, il aurait peut-être dû garder ses raccourcis plutôt que de s'y adapter.
Un autre point non lié au langage lui-même est plutôt la stack habituelle du monde Java autour d'outils comme Kafka, Maven, Spring… Il évoque en exemple la "magie" de Spring qui peut poser souci.
Il rappelle que c'est plutôt côté RH que ce rapport au langage est globalement plus compliqué à cause des annonces qui s'y orientent beaucoup, créant des silos.
Un live Twitch et une rétro
J'ai proposé un live Twitch pour conclure la dernière session de la journée, je vous invite à aller le voir : Marc commence par parler de l'événement et de son organisation, David Aparicio nous narre son histoire sur son homonyme parfait et Sylvain qui nous parle de sa session de podcast improvisée.
Suite à ce live, tout le monde se retrouve pour une rétrospective de l'événement où on revient sur les sessions, ce qui nous a plu et ce qui pourrait être amélioré.
