#snowcamp — Public Fediverse posts

Si vous ne l'avez pas vu passer, mon article rétrospectif sur le #SnowCamp 2026 est en ligne sur LinkedIn : https://www.linkedin.com/posts/stephane-trebel_je-nai-pas-rapport%C3%A9-quun-rhume-de-grenoble-activity-7419325345952112640-3N6s

Snowcamp 2026

On ne sait pas quand les habitudes apparaissent, mais parfois on peut le reconnaître.

Et cette année, je peux l’affirmer sans trop de prétention, Snowcamp est devenu une habitude pour moi. J’y retrouve des gens, j’y ai des horaires habituels (j’arrive le mercredi matin, je repars le dimanche matin), et même si le lieu de conférence a changé cette année, ça reste un endroit sympathique pour discuter avec des gens intéressants et entendre parler de sujets fascinants.

Je n’ai d’ailleurs pas assisté à beaucoup de conférences cette année (j’étais occupé à finir celle que je présentais avec mon collègue Clément – j’en reparle plus bas), mais certaines de celles que j’ai vu m’ont bien marqué

• Guillaume Laforge et Emmanuel Bernard ont fait un 45 minutes un tour de MCP et A2A. C’était très dense, mais c’était la première fois que j’entendais parler correctement de ces sujets (c’est-à-dire en décrivant les outils, et en me laissant la charge de déterminer si c’était approprié à mon usage), donc bravo à eux.
• Arnaud Bailly a parlé de radicle, qui est un projet que je trouve de plus en plus intéressant, parce qu’il évite le problème de la recentralisation du développement, en introduisant par ailleurs des mécaniques intéressantes de builds signés (dont je me dis d’ailleurs qu’ils iraient fort bien avec Dagger, par exemple)
• Mon collègue Florian Forrestier a parlé d’utiliser n8n pour piloter la mise à jour des applications dans son système d’information domestique, et c’était une bonne introduction à cet outil
• Yannick Lecaillez a parlé de test piloté par la simulation, un concept déja entendu chez Clever Cloud (les deux utilisent FoundationDB) d’une manière différente et intéressante.

Et puis Alexandre et moi avons animé un remarquable kata d’architecture. Remarquable parce que nous ne connaissions pas le kata avant de démarrer, ce qui nous a permis de l’approcher avec nos méthodes propres. C’était intense, riche en partage et en apprentissages pour tous. Et à la fin, notre site de gestion de licornes domestiques me semblait assez correctement conçu (mais pas développé).

Et puis Clément et moi avons parler de ce qu’il se passe dans votre tête quand vous lisez du code. Je crois en avoir déja parlé sur ce blog, mais le livre de Felienne Heymans sur le sujet (The programmer’s brain) est remarquable. Et ‘jespère que nous avons pu aider les spectateurs à comprendre qu’au-delà de la méthode de production de code, et à l’heure où cette écriture ne se fait pas forcément directement, la capacité à produire un code facilement cartographiable, et qui raconte une histoire est cruciale pour la nécessaire compréhension de ce code.

Et puis il y a eu le speaker dinner … et le traditionnel repas des speakers du vendredi soir.

Et puis il y a eu l’unconference à Chamrousse, riche en discussions, et en glisse sur une neige de qualité.

Comme chaque année, je reviens de cette conférence avec des tonnes d’idées. Et j’en reviens aussi avec l’ambition forte de tout faire pour y retourner l’année prochaine !

#snowcamp

Au #SnowCamp j'ai eu le plaisir de donner une conférence avec
@emmanuelbernard sur les 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹𝗲𝘀 𝗲𝘁 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀 𝗽𝗼𝘂𝗿 𝗹𝗲𝘀 𝗮𝗴𝗲𝗻𝘁𝘀 𝗜𝗔, avec un focus sur #MCP et #A2A

Tous les liens vers les slides, les repos GitHub avec nos démos, sont disponibles ici :

https://glaforge.dev/talks/2026/01/16/on-ai-standards-and-protocols-focus-on-mcp-and-a2a/

En plus, avec du ☕️ #java dedans, avec #micronaut, #quarkus, #langchain4j et #ADKjava.

Aucun 🐍 Python en vue !

Est-ce qu'il y a des mastonautes qui vont à #snowcamp cette semaine ? (à part @davinkevin et moi). Si oui, signalez-vous qu'on puisse se dire bonjour (c'est plus simple que de porter un mastodonte en signe de reconnaissance)

#snowcamp est une conférence vraiment géniale où vous pouvez être photographiés dans des postures toujours dignes https://www.flickr.com/photos/162459903@N02/54284726903/in/album-72177720323348522 ou https://www.flickr.com/photos/162459903@N02/54283966252/in/album-72177720323348522 (alias la brioche) ou encore https://www.flickr.com/photos/162459903@N02/54285099498/in/album-72177720323348522 (alias T-REx was here)

Le #Snowcamp #2025 fût encore une super édition!

Retrouvez les slides de ma présentation sur la #GatewayAPI, et même le code des démos ci-dessous:

* https://link.davinkevin.fr/GwAPI-snowcamp25-slides
* https://link.davinkevin.fr/GwAPI-snowcamp25-code

Merci encore d'être venus si nombreux 💖

cc @snowcampio

Très contente d'être venue au #snowcamp pour parler de la responsabilité de nos décisions dans la conception de produits et services numériques.

Comment faire pour concevoir un produit qui puisse s'insérer durablement dans l'écosystème ?

La salle était pleine, merci 🔥🫶

#designsystem #designethique

On commence dans 10 minutes 🔥

@snowcampio #snowcamp

[Snowcamp] Tester c’est tricher

Les tests sont abordés de façon très dogmatique.
Jules et Antoine vont nous montrer qu’il faut parfois sortir des dogmes, donc tricher.

Qu’est-ce qu’on teste ?

On peut faire des tests unitaires (par exemple, pour vérifier que la toile du parapluie reste étanche).

On peut faire des tests d’intégration (par exemple, pour vérifier que le mécanisme d’ouverture du parapluie tienne). On peut aussi mocker le système (par exemple, simuler le vent).

Ca peut aussi être bien de faire du test end-to-end (avec l’usage complet du parapluie).

Et puis mettre en place du canary testing (lorsqu’on invente un nouveau parapluie).

Quelle stratégie pour les tests ?

Habituellement, on parle de la pyramide des tests.
Malheureusement, il y a plusieurs interprétations de cette pyramide.

En fait, elle vient d’un livre de Mike Cohn, et elle est beaucoup plus simple que ce qu’on voit.
Et dans son livre, elle s’appelle « the test automation pyramid ».
Le livre date de 2009 et, globalement, le coût de mise en place de tests d’UI est très élevé.

Aujourd’hui, ce modèle est dépassé.

Il a été remplacé par exemple dans « designing a pragmatic testing strategy » par une espèce de ruche.

Et si on demande aux gens, on peut trouver plusieurs catégories

• Les croyants qui disent « on ne teste pas, on n’a pas le temps ». Dans state of Javascript, 21% des gens n’utilisent aucun outil de test automatisé … C’est l’ice cream model d’Alister B Scott. Evidement, c’est un anti-pattern. Et en fait, ça arrive plus souvent que ce qu’on croit (voir Development time perception bias).
• Les technophiles définissent leurs tests par l’outil qu’ils utilisent, sans penser à la stratégie. Ca amène à des dérives comme des tests de non observation (par exemple, tester que lorsqu’on va sur une page qui n’existe pas, ça retourne une 404)
• Les sceptiques cherchent la couverture de code à 100%. Evidement, la couverture ne mesure que la quantité de tests, pas la qualité.
• Les ça suffit comme ça qui ne testent que les parties du code importantes d’un point de vue métier. C’est compliqué pour les nouveaux arrivants, qui ne savent pas ce qu’ilf aut tester. Et ils se posent beaucoup de questions sur les limites et le coût de l’automatisation. C’est ce qu’explique Mike Cohn dans son livre. Et en fait, le coût des tests augmente avec leur temps, mais leur bénéfice diminue.

BOn, c’est une catégorisation faite maison.
Quelles sont les motivations des différentes catégories ?

• La stabilité du code
• L’intégrité du code
• Documenter le code
• La conformité du code
• La reproductibilité

Trucs et astuces

Pour les croyants

Dans le web, pour les tests fortement liés à l’implémentation, vitest vous aidera si vous êtes dans le web.
Pour vos tests d’interface, utilisez Playwright.
Et Playwright s’installe très facilement.
S’ensuit une démo de Playwright, qui a une api très facile à utiliser, en JS comme en Java, et qui facilite considérablement l’installation des navigateurs pilotés.
Les tests sont parfois un peu longs, mais ça peut s’optimiser.
Surtout quand dans un test d’interface on fait des appels réseau.
Et dans ce cas, il vaut mieux mocker les APIs pour pouvoir facilement mettre en scène des appels réseau qui plantent.
Et PLaywright a une api de mock !

Pour les technophiles

Essayez d’avoir des approches plus orientées métier avec du BDD ou de l’ATDD.
Ca se fait généralement avec du Gherkin.
Les speakers vous recommandent Cucumber disponible dans tout un tas de langage.
Et essayez de mettre votre base de code au même niveau de qualité que votre code applicatif.
Ca peut être bien de vérifier par exemple

• Que chaque test ait au moins un assert
• Que les tests aient des noms différents

Pour les sceptiques

Arrêtez de voir la couverture comme l’alpha et l’omega et passez au mutation testing.
Ciblez vos tests pour n’exécuter que les tests signifiants.
vitest a un flag changed qui ne va exécuter que les tests correspondant au code impacté par vos changements de code.
Dans les projets multimodules, vous pouvez ne retester que les modules impactés (disponible dans un tas de technos).

Pour les ça suffit comme ça

La stratégie de test n’est généralement pas documentée.
Vous pouvez par exemple ajouter un fichier TESTING.md qui documentera quelle est votre stratégie de test (ou utiliser un ADR).

#architecture #snowcamp #test

Lève la main si tu vas au #Snowcamp à #Grenoble aujourd'hui ou demain. Moi, je suis déja dans le train !

Qui va aller à #snowcamp pour parler de deux super sujets ? C'EST MOI (j'adore Snowcamp)

Et de quoi je vais parler ?
D'une part, d'architecture logicielle et de sécurité - c'est cool.
Et d'autre aprt (et ça, c'est gravement cool)
De la science-fiction et de sa possible implémentation positive. (inutile de dire que j'ai des idées par paquet de 100)

Ah, le CfP de #snowcamp est ouvert, cette année je me lance! :-)
Si on veut bien une petite touche d'observabilité réseau et d'ebpf
https://snowcamp.io/fr/ - #snowcampio

Things I'd like to play with after 3 days of #snowcamp conference:

## Tauri
https://tauri.app

As a replacement for PWA/Electron ways of making desktop web apps.

## OPAQUE
https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html

Zero-knowledge password-based key exchange/agreement, been using SRP in the past and looking for more modern approaches.

## Conventional comments
https://conventionalcomments.org/

To improve empathy in code reviews

Pour bien commencer mon voyage vers le #Snowcamp, rien ne vaut un peu de turbo-métal avec supplément de choucroute https://www.youtube.com/watch?v=Hf0sac4APLg

🇨🇵 Demain, c'est #snowcamp !

Je serai aux workshops sur Playwright et Hashicorp Vault, s'il y a des gens qui veulent des notes, je tenterai un live-tooting, selon la connexion.

🇬🇧 For English-speaking followers: I'll be covering Snowcamp, a french tech convention for the next three days, starting with workshops on Playwright and Vault. Might do a live coverage, assuming network coverage is suitable.

(don't hesitate to mute me for a while if you're not interested, or vote below)