Featured image of post Devoxx France 2022 - Récap du jour 2

Devoxx France 2022 - Récap du jour 2

Ecrit par ~ zwindler ~

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.

Demain c’est loin (ou pas)

Fiouf, quelle journ√©e… “Quelle vie, mes amis !”

Direction le dernier jour, demain !!


Vous aimez ce blog ou cet article ? Partagez-le avec vos amis !   Twitter Linkedin email Facebook

Vous pouvez également vous abonner à la mailing liste des articles ici

Généré avec Hugo
Thème Stack conçu par Jimmy