Source code of my website
🚧 : add touraine-tech article draft
+95
-5
+95
-5
content/posts/2026/2026-02-17-touraine-tech/index.md
+95
-5
content/posts/2026/2026-02-17-touraine-tech/index.md
···
46
46
47
47
[20260212_093554.webp](20260212_093554.webp)
48
48
49
-
## L'architecture hexagonale au pays des irréductibles développeurs - par Nathan Castelein et Ambre Person
49
+
### L'architecture hexagonale au pays des irréductibles développeurs - par Nathan Castelein et Ambre Person
50
50
51
51
Ordralfabétix (Ambre avec ses couettes et muni de son poisson pas frais) et Cétautomatix (Nathan avec son tablier et son marteau), présentent chacun leur vision de l'architecture hexagonale, pour implémenter Jarvix, l'Intelligence Armoricaine.
52
52
···
64
64
65
65
> PS : Ce talk m'a donné envie d'intégrer une section sur l'architecture hexagonale dans Factorio. Ça traînait dans ma tête depuis un moment, mais ça s'est débloqué en voyant le village illustré, donc ça m'aura bien servi.
66
66
67
-
## Le hasard fait bien les tests - par David Pilato
67
+
### Le hasard fait bien les tests - par David Pilato
68
68
69
-
Les tests un peu _flakky_, on connait. Parfois, certains éléments aléatoires et difficiles à reproduire font échouer des tests.
69
+
Les tests un peu _flaky_, on connait. Parfois, certains éléments aléatoires et difficiles à reproduire font échouer des tests.
70
70
71
71
David présente l'utilisation de [_Randomized Testing_](https://labs.carrotsearch.com/randomizedtesting.html), une librairie de tests Java développée par Carrot Search, qui s'intègre avec JUnit.
72
72
···
78
78
79
79
Un seul point négatif : la librairie est conçue pour être utilisée avec JUnit 4.
80
80
81
+
### Metal-As-A-Service : Gérer votre bare-metal en MaaS, comme si c'était une machine virtuelle ! - par Julien Briault
82
+
83
+
On ne présente plus Julien, bénévole aux Restos du Coeur, et porteur de l'initiative _Le Cloud du Coeur_. Cette fois-ci, il nous présente le challenges associée à la gestion de serveurs en bare-metal.
84
+
85
+
L'utilisation de serveurs en bare-metal offre des performances brutes, et des latences très basses, ce qui permet d'absorber des pics de traffic lié aux évènements annuels des restos, comme le concert des Enfoirés.
86
+
87
+
Après avoir expliqué les challenges de la gestion du bare-metal, pour démarrer les machines installées dans un rack, pouvoir y installer un OS et exécuter du post-provisionning avec des scrips Cloud-Init, Julien a présenté l'utilisation de MaaS de Canonical, qui permet d'installer n'importe quel OS (Linux ou Windows) sur n'importe quel Hardware (en fonction des marques, HPE, DELL, etc.), l'intégration à leur CLI, ainsi que la surcouche maison OpenBareMetal qui permet de faire de l'auto-scaling de bare-metal, et donc aller économiser des coûts énergétiques.
88
+
89
+
C'est bluffant.
90
+
91
+
### Fatigués de la POO ? Passez à la DOP ! - Par Jérôme Tama
92
+
93
+
Un talk qui parcours les évolutions de Java depuis la version 8 jusqu'aux versions récentes.
94
+
L'approche est de proposer en live un refactoring de code sous la forme d'un Kata.
95
+
96
+
L'approche est pédagogique, et les features des Java apparaissent naturellement petit à petit. Bref, c'est bien amené.
97
+
98
+
> Je demanderai probablement à Jérôme l'autorisation de réutiliser son Kata pour mes cours, car il est très clair, et présente les nouveautés une-à-une. L'intérêt de chaque feature transparaît immédiatement dans le code.
99
+
100
+
### Un voyage dans le temps sur le passé, le présent et l'avenir de la protection de la mémoire - par Laurent Grangeau
101
+
102
+
Laurent liste l'ensemble des mécanismes de protection de la mémoire, les failles et les évolutions depuis les premières années de l'informatique, jusqu'aux approches actuelles (souvent sur GPU). La plus grande partie des mécanismes sont hardware (implémenté par le CPU), et d'autres sont logicielles (comme le sandboxing).
103
+
104
+
On re-découvre les concepts de pagination, de mémoire virtuelle, de segmentation.
105
+
Le talk est très dense, et beaucoup de mécanismes sont présentés, c'est exhaustif.
106
+
107
+
### Keynote du Jeudi soir : Speechless - par Jean-François Garreau
108
+
109
+
Un exercice d'improvisation, animé par Jean-François, avec quatre speakers de légende : Estelle Landry, Aurélie Vache, Mickael Alves, et Sébastien Ferrer. Deux membres du jury : Marjorie Aubert et Thierry Chantier.
110
+
Un bel exercice, très drôle, pendant lequel le public participe au choix des sujets.
111
+
On a eu le droit à quatre belles impros, parfois sur des thèmes glissants. Une bonne rigolade pour finir la journée.
112
+
81
113
## Les talks du vendredi
82
114
83
-
Le vendredi matin, j'étais très fatigué (j'ai passé une mauvaise nuit). J'ai donc passé la matinée à peaufiner mon talk (j'ai ajouté une partie sur l'architecture hexagonale) et à discuter avec les speakers dans notre salle réservée.
115
+
Le vendredi matin, j'étais très fatigué (j'ai passé une mauvaise nuit). Après la keynote, j'ai donc passé la matinée à peaufiner mon talk (j'ai ajouté une partie sur l'architecture hexagonale) et à discuter avec les speakers dans notre salle réservée.
84
116
85
117
J'ai profité du regain d'énergie de l'heure du midi pour aller voir quelques talks _Lightning_ de 15 minutes.
86
118
119
+
### Gray Hat, Black Hat, Users : comment protéger une plateforme de 85M d'utilisateurs face à des menaces hybrides - Par Mikael Robert et Yohan Boyer
87
120
121
+
Mikael et Yohan sont co-fondateurs du réseau social Yubo, réseau social Français 🇫🇷, avec pour cible des utilisateurs de la Gen Z.
88
122
89
-
## Une belle démarche de transparence
123
+
Ils nous présentent les challenges de développer et opérer un réseau social, dont les utilisateurs peuvent parfois essayer de détourner les usages du réseau.
124
+
Les hackers sont donc des ados, qui apprennent à "hacker" sur Youtube et Tiktok.
125
+
Les usages détournés peuvent potentiellement être du scam, du doxing, de la sextorsion, ou plus légèrement exploiter une race-condition ou un process mal optimisé pour accéder à des fonctionnalités normalement payantes gratuitement.
126
+
127
+
Parmi les tentatives d'exploitation dont ils ont dû se prémunir, plusieurs cas sont rigolos, comme celui d'une tentative d'infiltration _via_ le recrutement, avec des CVs visiblement faux, conçus pour appâter les recruteurs, et visant probablement à se faire embaucher pour aller exploiter les données de l'entreprise de l'intérieur.
128
+
129
+
Ce sont des challenges auxquels on est pas forcément habitués, donc c'est toujours intéressants de découvrir ce monde du hacking des réseaux sociaux.
130
+
131
+
### Mieux écrire, mieux trouver : Diátaxis comme guide de documentation - par Alexis "Horgix" Chotar
132
+
133
+
Alexis présente rapidement le concept de Diataxis, framework d'organisation de documentation.
134
+
Ce framework propose d'organiser la doc selon 2 axes, en 4 parties : les tutoriels et how-tos visant à documenter des actions, et les explications et la références plus portées sur la connaissance.
135
+
136
+
Quelques tips intéressants, en particulier ne pas hésiter à lier les articles de documentation, ainsi qu'être le plus spécifique possible.
137
+
138
+
### Déchaînez le Chaos : Tester la résilience de votre application avec Chaos Monkey - par Erwan Le Tutour
139
+
140
+
Erwan présente les approches de Chaos Monkey, qui ont été popularisées par Netflix, avec la Simian Army.
141
+
142
+
Il nous présente ici très concrètement comment mettre en place un Chaos Monkey dans une application Spring Boot en utilisant le starter `chaos-monkey-spring-boot` développé par CodeCentric, qui développe aussi Spring Boot Admin.
143
+
144
+
La démo est intéressante, Erwan nous montre comment activer le Chaos Monkey, sur les différentes couches de notre application, pour y introduire des latences ou des erreurs. À tester couplé avec des tirs de charge pour observer comment les applications se comportent et améliorer leur résilience.
145
+
146
+
### Tricher pour mieux apprendre : 30 minutes par jour pour rester curieux dans nos métiers de la tech - par Yann Schepens
147
+
148
+
Yann nous parle de veille techno, et nous propose de prendre 30 minutes chaque jour, sur notre temps de travail pour faire de la veille.
149
+
Il nous invite à pratiquer, lancer des projets persos, partager la veille.*
150
+
151
+
L'idée la plus pertinente à mon sens : faire sa veille 30 minutes avant le daily. Cela permet de bien gérer le temps, de ne pas déborder.
152
+
30 minutes par jour, ça représente une dizaine d'heures par mois, donc cette "triche" permet quand même de cumuler pas mal de temps, c'est une bonne astuce si on a pas encore de temps consacré à la veille.
153
+
154
+
### Au secours, mes images pourrissent mes perfs - par Antoine Caron et Mathieu Mure
155
+
156
+
Un talk en déguisement, et sur le thème du jeu Hadès. La mise en scène est chouette.
157
+
158
+
Antoine et Mathieu nous présentent l'histoire de l'utilisation des images sur le web, depuis la photo des Cernettes, en passant par les différents formats, des BMP, GIF, en passant par les JPG et PNG, jusqu'aux formats modernes AVIF ET WEBP.
159
+
160
+
Ils nous listent avec humour les piliers de l'enfer : des JPG non-transparents, aux images qui ne chargent pas, à l'image de 20 pixels affichée en grand donc floue, à l'image de 4000 pixels affichée en tout petit.
161
+
162
+
Mais au delà de cet aspect humoristique, ils nous listent des axes d'amélioration très concrets : l'utilisation des formats modernes qui sont très léges, le redimensionnement des images et la mise à disposition au browser d'un srcset pour lui permettre de choisir parmi les formats, les lazy loading et fetchpriority pour aller chercher des images au bon moment.
163
+
164
+
Une architecture est aussi proposée pour redimensionner les images à la volée et les conserver en cache, plutôt que de faire ces redimensionnements au build (pas comme sur ce blog donc), à base de Strapi, imgproxy, d'un bucket et d'une BDD pour le stockage, et d'un Varnish ou d'un CDN pour le cache.
165
+
C'est plutôt intéressant pour des sites publics, je testerai probablement une ou deux de ces astuces dans les prochains mois.
166
+
167
+
### Local-first et sync-engines, l'architecture du futur ? - par Benjamin Legrand
168
+
169
+
Benjamin présente les problèmes liés aux architectures classiques _n-tiers_, avec le Frontend qui communique à un Backend, avec des requêtes HTTP par exemple. Ces communications sont sources d'attente côté utilisateur en cas de latence réseau, et on met en place des mécanismes pour y palier : loaders et spinners. La gestion d'erreur est également un problème en soi, ainsi que la disponibilité du Backend qui doit être maximale, sous peine de rendre le Frontend inutilisable.
170
+
171
+
Il présente ensuite les approches _local-first_, qui consistent à avoir une base de données locale au Frontend (type indexedDB ou sqLite), couplée à un moteur de synchronisation.
172
+
173
+
Les avantages sont nombreux : plus besoin de spinner, l'accès réseau devient optionnel car l'application peut fonctionné en mode déconnecté, les données peuvent être plus facilement sécurisées et privées si besoin, le Frontend devient alors aussi plus tolérant aux pannes du Backend.
174
+
175
+
Côté Frontend, l'utilisation de live-queries permet d'implémenter le lien entre les écrans et la base de données facilement (ainsi que le refresh pour les données synchronisées entrantes). Côté moteur de synchronisatin, la plupart des moteurs du marché proposent l'utilisation d'un CRDT (pour _Conflict-free Replicated Data Type_), une espèce d'API de Documents à la MongoDb, pour implémenter la synchronisation facilement.
176
+
177
+
localfirst.fm fournit une vision complète de l'ensemble des libraries ou frameworks qui suivent ces principes.
178
+
179
+
## Keynote de fin : Une belle démarche de transparence
90
180
91
181
La keynote de cloture du vendredi soir (juste après ma game de Factorio), a été l'occasion pour les orgas de remercier tout le monde : sponsors, speakeuses et speakers, et le public présent.
92
182