Devoxx France 2022 - Récap du jour 2

Jeudi, jour de passage pour moi 😅

Les résumés des 3 jours de DevoxxFR 2022

Hier, j’ai fait un petit compte rendu de ma première journée de conférence et il est donc logique que je continue aujourd’hui.

J’vais pas mentir, il y avait un peu plus de pression car c’est le jour où j’avais mon talk ;-).

La Keynote de Devoxx France 2022 - 10 ans déjà

Speaker(s) :

Nicolas MARTIGNOLE
Antonio GONCALVES
Zouheir CADI

Première conférence de la journée, dans l’amphi bleu. Arrivée sur scène des orgas sur un air de rock, on est dans l’ambiance.

Forcément, cette première keynote était consacrée aux 10 ans. L’occasion de revenir sur cet événement qui est devenu iconique pour beaucoup de développeurs.

Tout commence avec la création du Paris JUG en 2008. En 2009, à JavaPolis (Belgique), la communauté FR est déjà sur place ! Comme le ParisJUG commence à grossir et que les JUG locaux sont bien présents, l’idée de copier JavaPolis (maintenant Devoxx) commence à germer.

En 2011, les orgas historiques annoncent DevoxxFR pendant l’édition belge. La première édition aura lieu au Mariott dans Paris, qui deviendra vite trop petit.

En 2015, on passe au Palais des congres. Enfin, ce qui était fait un peu à la main deviens de plus en plus pro.

Aujourd’hui, Devoxx France c’est plus de 3000 participants, mais c’est une vraie franchise avec 6 Devoxx différents et plusieurs VoxxedDays.

10 ans de Tech à travers le podcast Niptech

En invités de keynotes, il y a eu les membres du podcast Niptech, un podcast francophone suisse tech.

Le début de l’aventure date d’environ 2001 avec l’expérimentation de radios amateurs, puis la diffusion des premiers podcasts en 2004.

Aujourd’hui, les outils utilisés ont finalement . Le site est toujours hébergé sur Wordpress, les flux RSS sont toujours au coeur du système. Pas besoin de changer ce qui marche ;-)

En revanche, plus d’iTunes ni du ustream (?), maintenant les gens écoutent leurs podcasts sur Deezer (oui , c’est presque ça qu’il a dit :-p) et Twitch.

Au delà de la présentation du podcast, l’idée était surtout de présenter des tendances de ces 10 dernières années et si elles ont tenu ou pas.

On a parlé de klout (analyse des réseaux sociaux + score !), de foursquare, de drones, de crypto.

La plupart de ces tendances ont fait long feu. Les podcasters ont conclus en livrant leurs 3 défis des 10 dernières années :

Données vs servies
Bundling vs unbundling
Innover vs réguler

Le petit mot “inspirant” de la fin :

Seuls les poissons morts nagent dans le sens du courant

Speaker(s) :

Benoit CURDY
Michael MONNEY
Baptiste FREYDT

Slow.tech : il est urgent de hacker le système !

Speaker(s) :

Frédéric BORDAGE

Cette keynote sur le green IT avait pour but de nous convaincre que nous devons faire mieux.

Le problème principal du numérique réside dans la consommation de ressources liées à la construction des terminaux.

L’angle du speaker était que nous avons des systèmes de plus en plus performants mais qu’en échange on fait des sites web de plus en plus gros.

Il faut arrêter la surenchère de consommation de ressources

Pour ce faire, il faut pratiquer l’éco-conception

Amélioration du produit
Reconception du produit
Innovation des fonctions
Innovation de système

La slow tech, c’est la fusion de la “low tech” et de la “high tech”.

Le présentateur a donné l’exemple d’un site de météo WeatherForce pour les agriculteurs qui a réussi à trouver des clients en afrique en envoyant des SMS plutôt des notifications.

Dans le même sens, l’intervenant disait qu’il fallait privilégier l’utilisation de chiens pour détecter les cancers plutôt que les gros clusters d’IA/ML de Google.

Je suis d’accord sur le fond (on a un problème), mais je n’ai pas été super convaincu par la façon dont le message a été passé…

Comprendre les enjeux de consommation de ressource et d’énergie dans le secteur numérique

Du coup, pour avoir un autre avis, je suis allé voir le talk de Quentin ADAM et Pierre BEYSSAC, qui a commencé par ce disclaimer

Personne ne dit qu’il n’y a pas de problème. On a même plusieurs gros problèmes

Modification chimique de notre atmosphère
Disponibilité limitée des matières premières
Pollution environnementale localisée

Les exploitations de charbon, ça rend les landers moins bucoliques

Merci Quentin pour tes punchlines :)

Tout au long du talk, on a reparlé de l’absence de méthode scientifique de la part des gens qui cherchent à tout prix à calculer l’impact d’un “byte” en termes d’équivalent CO2.

Après avoir montré les chiffres ne sont pas valides (hypothèses farfelues, pas d’info sur la marge d’erreur), Pierre et Quentin nous ont montré en quoi le numérique n’est pas le problème, et que les recommandations (couper sa box la nuit par exemple) étaient contre-productives.

On peut quand même bien sûr réduire intelligemment la consommation électrique :

tesla lance la charge des teslas quand EDF lui dit de le faire (aka quand on a trop d’électricité)
les DC accumulent la chaleur / la libère avec des piscines chaudes et froides
compiler soi-même ses logiciels ;-)

Il faut optimiser la consommation là où ça a le plus d’impact. Faire de l’écoconception pour gagner l’équivalent CO2 de 2000 km de trajet voiture pour la totalité du traffic du site du Monde est ridicule.

En France, la part du numérique dans les emissions globales est très faible, par rapport aux transports, notamment.

Il faut mettre la consommation d’électricité du numérique face à ce qu’elle permet d’éviter (notamment, les gens qui télétravaillent ne prennent plus leur voiture), le numérique est utile.

Deuxièmement, la fabrication de terminaux est bien moins un problème si on utilise massivement le réemploi (réutiliser avant de recycler).

Arrêtez d’acheter des smartphones de merde qui lâche le support logiciel au bout de quelques mois

Dans les coulisses du “Cloud”

Fan d’ordinateurs plus vieux que moi

Cécile nous a présenté son métier : installation des serveurs, tirer les fibres, comment on fait pour interconnecter des racks, des serveurs, configurer les routeurs.

Elle nous a ensuite parlé des différences de certifications des datacenters, du cagibi au fond de l’openspace au dernier cri (comme celui d’Aquaray, certifié Uptime Institute Tier 4)

2 groupes électrogènes / 24H d’autonomie de diesel
des onduleurs dans 2 salles, dont le rôle est double
- nettoyer le courant des petites chutes / surtensions
- permettre de continuer à alimenter les serveurs le temps que les groupes électrogènes démarrent correctement (quelques minutes)
double adduction de fibres réseau, pour éviter la célébrissime “alerte pelleteuse”.

Ca m’a rappelé une expérience précédente, dans laquelle j’ai participé à la conception de DCs :’) #émotion #nostalgie.

Elle a enfin parlé de réseau et de comment les opérateurs et les différentes entreprises sont interconnectés au niveau mondial (une dizaine d’opérateurs de Tier 1, qui portent tout l’internet), a expliqué les principes et les limitations de BGP (IANA, RIPE NCC, peering vs transit, RPKI).

En conclusion, elle a rappelé que derrière la magie du cloud, il faut se rappeler qu’il y a surtout des humains, des serveurs et du réseau.

Equity for software engineers

J’avais prévu d’aller chercher ce talk de Damien PACAUD, mais finalement, j’ai eu une discussion passionnante avec Quentin ADAM et David LEGRAND. C’était bien aussi ;-).

Entiers, virgules flottantes ou représentations exotiques : parlons d’élégance

Speaker(s) :

Olivier PONCET
Fabien TRÉGAN

Dans ce talk, Olivier et Fabien nous ont parlé de gestion des nombres en électronique, de façon efficiente.

Difficile de résumer ce talk, aussi fun qu’éclectique, mais grosso modo on a parlé :

de nombre optimal d’états pour stocker des nombres (idéalement le nombre d’Euler)
d’ordinateurs ternaires, versus binaire (et du fait qu’on profite de la logique de Bool)
de Bibi-binaire (base16) de Boby Lapointe
de numération shadock
de représentation de flottants (sur un ensemble de bit fini)
de “demo” de hackers de jeux
de bresenham et rasterisation
de notation BCD

C’était super bien, mais j’avais pas pensé que j’allais refaire des Maths à Devoxx 😅

Ciel ! Mon Kubernetes mine des bitcoins !

C’était mon talk et j’étais bien stressé finalement ;) j’ai eu quelques retours qui m’ont un peu surpris, j’espère que globalement ça vous a plu.

Les slides sont là

Une fois le talk fait, je ne suis pas retourné directement en conf, pour souffler un peu :)

Cybersécurité et générateurs de nombres aléatoires

J’avais pas forcément prévu d’aller voir ce talk et finalement c’était une super surprise.

Mathis HAMMEL nous a parlé de la sécurité des mots de passe. On a commencé par des recommandations simples sur les mots de passes :

Mot de passes complexe et différents
Stockés dans un générateur de mot de passe
La 2FA est utile contre le (spear)phishing
Rotation des mots de passe régulière pour les comptes partagés

Tout ça nous a servi d’introduction pour parler de l’anatomie d’une CVE sur Kaspersky Password Manager.

Il s’agit d’un password manager vendu par Kaspersky, mais qui dispose de plusieurs problèmes de sécurité, certains très graves :

Tirage pas uniforme pour essayer de combattre des attaques par Modèle de Markov
- Mais c’est contre-productif, car c’est facile de choisir un Modèle de Markow spécialement entraîné pour !
Kaspersky utilise Mersenne Twister, qui n’est pas un Cryptographically Secured Pseudo Random Number Generator
Kaspersky utilise en seed un timestamp (!!!)

La conséquence, c’est que :

2 personnes qui génèrent un mot de passe à la même seconde récupèrent le même
31 millions de mdp possibles sur une année, c’est crackable en quelques secondes

Bref, ya rien qui va !

Après la censure, l’auto censure… mais là c’est drôle, éducatif et avec de l’IA

Speaker(s) :

Pierre MORVAN
Louis TOURNAYRE

Pierre et Louis ont profité du confinement pour tester le machine learning alors que ce n’est pas du tout leur métier.

Pour s’entraîner à des confs et arrêter leurs tics de langage (les “euh”) ils ont décidé d’entraîner un modèle pour détecter le “euh”.

Ils nous ont expliqués ce qu’est un reseau de neurone, comment l’entraîner (back propagation). Il faut créer de la donnée pour générer plusieurs données d’entraînement.

Pour reconnaître les “euh”, on récupère le son du navigateur, fait une transformée de fournier pour le transformer en image “facilement” exploitable, puis on analyse le flux et on compte le nombre de “euh”.

Ca a fini par une démo avec “Teachable machine”.

Les sources du code github.com/ryarnyah/devoxx-euhh

REX: TDD avec TestContainers

Julien DURILLON a fait un REX d’un test qu’ils ont fait de sur TDD avec TestContainers.

Lors de la refonte de leur système de facturation (système critique s’il en est ;-p), ils ont voulu le faire en mode TDD.

La plupart des fonctions ne peuvent pas être testées unitairement, la couverture faible était très faible. Et lancer des TI lors de la préparation de la PR, c’est parfois un peu tard.

Julien nous a montré le code et effectivement ça a l’air très simple d’utilisation, surtout quand on connaît déjà JUnit.

Meet and Greet

La journée a fini (encore une fois) en apothéose avec une soirée Meet and Greet, payée par les sponsors.

B***EL il y avait du monde. Faut pas être agoraphobe.

J’ai pu revoir et discuter avec mes anciens collègues de Lectra, revue des connaissances de l’école d’ingé (!!) et rencontré (enfin en vrai !) DamyR et Louhdetech.

Mais au fait DevRel c’est vraiment qu’un lanceur de paillettes ?

Speaker(s) :

Stéphane PHILIPPART
Fanny KLAUK
Aurélie VACHE
Horacio GONZALEZ
Sebastien BLANC
Olivier LEPLUS
Philippe CHARRIERE

La dernière session que j’ai eu le courage de faire aujourd’hui était pour parler du métier de DevRel. Métier qui, en tant que blogger (passionné) et speaker (passionné tout autant) n’intrigue forcément.

Au final, je ne vais pas mentir, je ne suis pas ressorti avec une impression beaucoup plus claire de ce qu’était le métier de DevRel. Mais c’était tout de même très utile d’avoir les retours des différents DevRels autour de la table.

Globalement, ce que j’en retiens, c’est qu’il y a autant de façon de faire DevRel que de DevRel.

Le DevRel peut être celui qui passe tout son temps en conférence (certains parlaient de “seulement 30% du temps” alors que ça me parait déjà important).

DevRel ce n’est pas forcément un métier à temps plein selon Horacio, qui se voit plus comme un facilitateur pour des DevRels à temps partiel en interne (des gens qui aiment partager mais dont ce n’est pas le métier normalement).

Il n’y a pas de consensus pour déterminer si un DevRel c’est juste une autre façon de faire du marketing (moins direct, plus à destination des dev plutôt que du management côté client) ou pas.

On a reparlé du très bon article de Wassim Chegham, qui parle notamment (mais pas que) de la différence entre un “dev evangelist” et un “dev advocate”.

Le point le plus intéressant a été le moment où l’un des panélistes a demandé aux membres présents ce qui les motivait dans leur rôle de DevRel.

La plupart ont répondu “aider les autres” (avec des variations sur comment y arriver), certains ont répondu “discuter avec les gens”.

Autant je me retrouve dans la première partie, autant je me dis que je suis encore très loin d’être capable de faire la seconde.