Giters

dcuenot / conference-notes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Devoxx France 2022

Devoxx France 2022 - Les 10 ans !
Devoxx France 2022 - Les 10 ans !
Table of Contents

MERCREDI

Présentation du salon

Comprendre GraphQL

Abstract

GraphQL est une spécification décrivant un language de requêtes pour API sur une base d’un contrat fortement typé. En plus du contrat, GraphQL se base sur une sélection explicite des champs permettant un requêtage riche évitant soit "l’overfetching" (recevoir des données inutiles) ou la multiplications des requêtes.

GraphQL est aussi connu pour son écosystème clients (web et mobiles) ou serveur avec la possibilité d’écrire des services dans une multitude de langages. Durant cette session, nous verrons comment développer un schéma GraphQL avec différents languages (tel que typescript, kotlin voir rust). Nous aborderons entre autres: - Le système de types en GraphQL: objet, types polymorphiques, queries (lectures), mutations (écritures), subscriptions (streaming) - La gestion des erreurs - Strategies de résolutions des requêtes (avec par exemples les coroutines) - Technique plus avancées (context de requêtes, chaines d’interceptions etc).

Notes

Bare minimal query

schema {
    query {}
}

Dans une query, on ajoute un ! pour signaler qu’un champ est obligatoire, et ne doit pas être null, permet de gérer des modes dégradés.

La spécification GraphQL est la bible Github utilise GraphQL, voici la doc

L’objectif de GraphQL est de limiter la data qui transite sur le réseau, c’est le client qui défini les champs à récupérer, l’ordre d’affichage…​

Si un champs est associé à une fonction côté serveur, s’il n’est pas requêté par le client, la fonction ne sera pas appelée, ce qui permet de fortement optimiser les temps de réponse si la fonction fait une recherche en BDD par ex.

En GraphQL, il y a 3 types de requêtes différents: - Query: Requête de lecture - Mutation: Requête de mise à jour. Si plusieurs mutations sont demandées dans la même query, elles sont exécutées séquentiellement - Subscription: Streaming

En GraphQL tout est en POST, et les réponses sont en 200 ou 500. 500 quand la query n’est pas valable, et si c’est une error métier, on reçoit un 200 et dans le body de réponse le bloc error est non vide.

Apollo propose différents outils pour explorer, stitcher des graphs: Rover, Studio, explorer

🎥 Zero Trust : the new normal !

Abstract

Avec l’arrivée du COVID, les entreprises ont dû accélérer l’adoption du télétravail et ont vu l’augmentation du nombre de partenaires externes avec l’ouverture de son SI, ce qui nécessite de revoir la sécurité périmétrique des infrastructures. La démarche Zero Trust consiste à réduire la « confiance implicite » accordée aux utilisateurs et aux activités menées par le biais des équipements du SI. Pour garantir cette confiance, les entreprises ont pris le parti de se baser sur l’identité des utilisateurs pour vérifier et les authentifier sur l’ensemble des ressources accessibles. Dans cette session, nous ferons un bref rappel de ce qu’est la sécurité périmétrique (VPN, firewall, zoning réseau, …). Nous présenterons ensuite les grands principes du Zero Trust tel que le least privilege access, la microsegmentation réseau, l’authentification multi-facteur, etc. Nous comparerons aussi la sécurité périmétrique (modèle du château fort) avec celle de l’approche Zero Trust (modèle de l’aéroport) ; et nous reviendrons sur les différents modèles d’autorisation (MAC, RBAC, ABAC). Enfin, nous montrerons des exemples d’implémentation Zero Trust à travers des produits comme Boundary d’Hashicorp.

Notes

Why?

Télétravail, cloud, augmentation de la surface d’attaque. Propice aux ransomwares, et attaques. BYOD n’est pas une pratique à recommander

90% des brèches sont de mauvaises configurations Des clusters K8S de Tesla étaient mal configurés et ont permis de miner du Bitcoin https://cybermap.kaspersky.com

Trust no one, verify everything

  • Identity

  • Perimeter

  • Network

  • Application

  • Data

  • Observability

La confiance n’exclut pas le contrôle - Lénine

Architecture

  • Contrôler l’identité

    • MFA

    • Qui je suis

    • Ce que je sais

    • Ce que je possède

  • Contrôler les devices

    • MDM

    • Forcer à avoir des devices à jour

Défense périmétrique ne suffit clairement plus. The End of the Fortress Metaphor

Model d’authorisation

  • ACL (Access Control List) une personne peut agir sur un object

  • DAC (Discretionary Access Control) une personne peut agir sur un objet et peut donner cette permission à d’autres

  • MAC (Mandatory Access Control) - SELinux - une personne peut agir sur un object, et l’object peut vérifier qu’une personne peut agir sur lui

  • RBAC (Role Based Access Control) - une personne à un rôle, et par rapport à ce rôle on définit les permissions sur un object

  • ABAC (Attribute Based Access Control) - XACML - une personne peut accéder à un attribut dans un environnement (un contexte)

Modèle aéroport

Modèle de sécurité avec des zones public, privée, duty free, tarmac…​ qui est bien plus clair que le modèle chateau fort.

Principes de Zero Trust

  1. All data sources and compute services are considered resources

  2. Toutes les communications sont sécurisées, quelques soient l’endroit sur le réseau

  3. Les accès individuels sont granted par une session (avec un TTL)

  4. L’accès aux ressources est déterminé par des politiques dynamiques

  5. Monitore et mesure l’intégrité et la sécurité de tous les assets

  6. authent et authorization doivent être validée avant de donner accès à une donnée

  7. Collecte d’un maximum d’info sur le réseau, les assets, pour détecter des failles

Demo Harshicorp

Boundary semble fonctionner comme un bastion, mais qui gère authentification + autorisation, et de plus boundary génère à la volée des clés pour accéder au VM du subnet private, fonctionne aussi pour un accès BDD PostgreSQL. Les crédentials temporaires sont stockés dans un Vault. Comme les users sont créés à la volée, il faut faire de la corrélation entre la trace dans la BDD et les logs d’accès Boundary.

Boundary est pour du Human 2 Machine. Si besoin de faire du Machine 2 Machine, il faut plutôt faire un Consul avec un Vault.

BeyondCorp Enterprise

  • N’importe quel googlers peut se connecter depuis n’importe quel réseaux sans passer par un VPN

Takeaways

  • Sécu périmétrique n’est plus une option

  • Zero trust framework basé sur device, identité, automation pour protéger les data, et bien sur le reseau

  • Des solutions existent déjà (boundary, beyondcorp)

Pourquoi vous n’attirerez et ne retiendrez pas les femmes dans vos équipes tech !

Diversité et l’inclusion des femmes en entreprise
Diversité et l’inclusion des femmes en entreprise. @AmelieBenoit33

Abstract

Les femmes sont sous-représentées dans le domaine du numérique. Elles représentent à ce jour uniquement 30% des salariés, tous métiers confondus.

Que s´est-il passé dans ce secteur professionnel pourtant dominé par la gente feminine lors de sa génèse ? Les femmes ne se sentiraient-elles plus ou pas à leurs places ?

Pourtant, les femmes communiquent. Hélas, bien souvent, on ne les écoute pas. Résultat ? Migration vers des métiers corollaires, brown-out, désincarnation dans l’équipe, démission, création de la FemTech et de safe places comme lieux d’expression communautaire.

Alors, si vous voulez favoriser la mixité et que vous avez saisi que la cause des femmes dans la tech est une brèche pour résoudre, en plus, la problématique de la diversité et de l’inclusion, venez découvrir comment améliorer vos pratiques !

Notes

Groupe majoritaire - Biais de confirmation - biais de sympathie -→ ceci induit un statu quo

Avec une logique du groupe majoritaire, il y a 2 dynamique possible: le groupe inclu, ou exclu Attitude face au changement:

  • 15% de refractaire

  • 70% de neutre

  • 15% de partants

90% des compétences pour postuler alors que les hommes estiment que 60% est suffisant Attention au titre de postes (dévelopeuse) Transparence salariale Moments conviavilatés inclusif, pas s’arrêter à la "bro culture"

Encouragez à prendre la parole, à être des roles modèles. La diversité et inclusion est un élément indispensable, augmente la productivité et la satisfaction globale

🎥 Bien maîtriser les Dev Tools de vos navigateurs

Abstract

Speaker : Romain Linsolas

Développer avec efficacité, c’est non seulement choisir les bons outils, mais surtout bien savoir les utiliser. Pour le développement web, si l’éditeur reste l’outil principal, le navigateur est lui aussi un élément primordial.

La grande majorité des développeurs et développeuses web est familière avec les fonctionnalités de base des Dev Tools intégrés aux navigateurs. Pourtant dans les faits, il s’avère que beaucoup d’entre eux n’utilisent qu’une petite partie de leurs capacités, et même ignorent bon nombre des fonctionnalités offertes par ces outils.

Dans ce Tools In Action, au travers de différentes démonstrations, nous allons voir les possibilités avancées offertes par ces outils : comment détecter et analyser les problèmes de performances, comment simuler d’autres environnements ou contextes (latences réseaux, problèmes d’accessibilité, etc.) ou encore découvrir des fonctions très intéressantes pour améliorer ses développements.

Nous nous focaliserons en grande partie sur les Dev Tools de Chrome, mais nous évoquerons aussi les différences avec ceux des principaux navigateurs concurrents.

Notes

Une fois le DevTools ouvert, tappez Cmd + Shift + P (comme dans VSCode) et les noms des tools ci-dessous:

Lighthouse

Lighthouse pour analyser les performances - LighthouseCI pour la version CICD

Performance insights (experimental tool)

affiche les infos de façon bien plus claire qu’avant

Recorder (experimental tool)

Permet de rejouer un scénario, avec une mesure des perfs -→ possibilité de l’exporter en puppeter :)

Coverage

Montre ce qui est chargé mais pas utilisé dans le JS et le CSS

CSS overview (experimental tool)

Pb de contraste, liste des fonts, les declarations unused Utile pour l’accessibilité

Rendering

Simuler un site sans couleur, flou, etc…​ pour simuler certains pb de perception.

Network condition

Simuler une déconnection, une slow 3G, etc..

Sensor

Changer notre géoloc, timezone, locale. Simulation de l’orientation de notre device

Flex ou CSS grid, on peut cliquer directement sur un petit bouton à coté de display: flex pour changer des propriétés pour tester.

Source

Enable local override permet de conserver les modifs faites dans la console.

Console
Clic sur l'oeil -> permet d'évaluer des expressions en live
Ctrl + L pour clean
$ ou $$
$_
$0 / $1 -> dernier élément inspecté
monitor(fn)
monitorEvents() --> ne marche pas avec les customEvents

Github Co-Pilot : Addictif ou Efficace ?

Abstract

Au cours de cette conversation, nous partagerons notre retour d’expérience sur l’utilisation d’un outil de pair programming intelligent (AI pair programmer) : GitHub Copilot. Nous examinerons comment l’utiliser, les avantages qu’il procure et les limites que nous avons identifiées. Nous tenterons ainsi de donner des éléments pour déterminer si ce plugin tient bien la promesse d’aider les développeurs à écrire du code plus rapidement et avec moins de travail.

Nous commencerons par une micro-session de "live-coding" en direct pour suivre les suggestions en temps réel et comparer ce qui est proposé d’un utilisateur à l’autre. Nous verrons ensuite les points forts et les questions qui se posent lors de l’utilisation de l’outil. Enfin, nous terminerons par une courte discussion sur comment GitHub Copilot fait évoluer la manière dont les développeurs documentent leur code.

Notes

Copilot aka AI pair-programmer

Pros

Copilot utilise le Model GPT-3 (fait par OpenAI) Permet de choisir entre plusieurs option, et permet de gagner du temps Force à commenter, car Copilot s’appuie sur ce contenu pour générer des suggestions

Cons

Accepte du code sur des libs anciennes / obsolètes Code pas optimal Copilot est très linéaire, et ne prend pas en compte les autres fichiers de votre projet

Démonstration assez bluffante de Copilot avec génération de 2 functions et d’une classe main pour classifier des images en Python, basé sur des réseaux neuronnes.

à tester, j’ai accès à la beta de Copilot, mais je ne sais pas si ça marche sur du code APEX / LWC Test en cours pour la rédaction de ces notes

JEUDI

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

Keynote d’ouverture
Keynote d’ouverture à #DevoxxFR! @AmelieBenoit33

Abstract

Devoxx France a été créé en 2012, après 4 années d’aventure avec le Paris JUG. C’est le moment de venir partager avec nous quelques souvenirs, de revenir sur ces 10 dernières années.

10 ans de Tech à travers le podcast Niptech

Abstract

Une keynote pour passer en revue les innovations qui ont secoué la tech depuis la naissance de Devoxx FR il y a dix ans. À travers les expériences du podcast Niptech et de sa communauté, nous partagerons des leçons apprises à la dure dans le but de nous aider à préparer ces dix prochaines années.

Notes

#Tech - #Startup - #Inspiration

Feedback sur 10 ans du podcast. Radio / webradio Podcast démarré en octobre 2004

Stack technique pour le podcast a peu évolué, et en terme de format, ils sont restés dans le format de niche malgré de nombreuses expérimentations

La tendance Quantified Self est moins hype qu’il y a 3/4 ans. Drones avec le gouvernement Suisse → interUSS

Bcp d’expérimentation, de tests pour mieux comprendre la tech, et réduire le bruit versus le signal.

3 défis de la tech pour l’avenir:

  • Données vs services (ex: collecter des data c’est cool, mais comment on l’utilise ?)

  • Bundling vs unbundling (ex: voix + quantified self)

  • Innover vs réguler (ex: drone)

Citation : "Seuls les poissons morts nagent dans le sens du courant" - /Akiva Orr

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

Abstract

Selon le GIEC, il nous reste 3 ans pour léguer un monde « vivable » à nos enfants. Sacré challenge ! Alors comment agir vite et fort dans notre univers numérique ? Une seule solution : sortir du cadre et hacker le système. C’est que propose la démarche slow.tech. En associant low et high tech, elle permet de diviser par un facteur 4 à 10 nos impacts numériques. De l’usage ingénieux d’un smartphone pour remplacer un cabinet d’ophtalmologie en passant par l’association d’un chien et d’une IA pour détecter un cancer, les écoconcepteurs de la slow.tech détournent les codes et les patterns habituels pour faire mieux avec moins. Prêt.e à emprunter cette « voie du milieu » ? Le hacker qui est en toi doit se réveiller !

Notes

Quel le point commun entre Appolo 13 et l’avenir de l’humanité?

  • CO2

  • Lowtech

  • Hackers

Trouver une solution simple, lowtech pour filtrer le CO2. Idée trouvée par des Mc Gyver, aka hackers 3 ans pour passer le pic d’émission de C02 8 ans pour diviser par 2 le CO2

Ecoconception & Slow tech Dans 30 ans, plus d’ordinateur.. doubting

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

Abstract

L’enjeu de la transition écologique de toutes les activités humaine est également appelé à se généraliser au numérique, et comme les outils informatiques sont symbole de la modernité, une exigence d’exemplarité leur sont souvent demandée, voire même imposée par le biais de rapports “RSE” (obligatoire dans certaines conditions) par exemple. Il appartient donc aujourd’hui de se doter d’outils de réflexion et de compréhension des impacts de nos activités, et une rapide présentation des forces en présence et mécanismes menant à la législation environnementale.

Dans cet exposé, les orateurs vont d’abord présenter le cadre général de consommation de ressources, définir quelles ressources et à quel moment du cycle de vie. Ensuite seront étudiées les différentes phases de consommations, l’importance des variations de mesure, de pilotage des consommation, les différentes conceptions, et les impacts provoqués par le code ou la consommation réseau.

L’objectif de la présentation est de ressortir avec un panorama clair des enjeux et impacts de la chaîne de production IT, les différents niveaux d’actions possibles en fonction de son poste, les bonnes pratiques possibles à étudier pour son or

Notes

Attention de plusieurs rapports il y a des erreurs de conversion d’unité entre bit & bytes par ex.

L’empreinte carbone des mails ? Envoyer un mail à 10 destinataires = 73g de CO2 → comment on arrive à ces chiffres ? bullshit

Quantifier - analyse du cycle du vie des produits tech

  • Fabrication

  • Run

  • End of life → exercice hyper compliqué

Run

Le plus simple à quantifier. En France, la production d’électricité génère peu de CO2 La quantité de CO2 générée par MWh est différent au fil de la journée

Datacenter peuvent "stocker" de la fraicheur avec les principes de frigorie (2 piscines eau chaude / froide) quand EDF n’est pas en tension. Donner un chiffre sans parler localisation et heure est discutable..

Consommation operateurs 2018 4 TWh Consommation nationnal 2019 473 TWh

2/3% de consommation française pour la partie Run

Eteindre une box → FBI, car le matériel de ce type est fait pour tourner. Les éteindre la nuit, use les composants.

Model 1 byte → quantité d’énergie nécessaire par byte Modèle fumeux 😚

Pas de correlation entre energie consommée et données transférées

Coût de fab > run

Comment côter ça avec son transport ? Incapable de le faire, car il y a moult sous-traitant

Terres rares → faux pb, car on trouve des workarounds, et si qqch devient rare, il devient rentable d’explorer une nouvelle approche. Acheter du bon matos, et le mettre dans le marché secondaire.

L’économie, la mesure du C02 est devenu marché. On a ajouté le compteur de C02 sur les factures Orange ou SFR, mais on n’a pas cette métrique pour les voitures pour un trajet de vacs.

Empreinte carbone du site du Monde = 10 000km d’une voiture à essence

Question politique ?

Une mesure sans marge d’erreur, ce n’est pas une mesure Capteur: marge d’erreur, fréquence et résolution

Réductionnisme vs complexité

Un corps n’est pas simplement la somme des organes Combattre l’obsolesence / massifier les softs / compiler les softs pour utiliser les ressources CPU

Encourager le télétravail 💻

Model-Driven Design

Abstract

Speaker : Bruno Boucard

Si le Domain-Driven Design était une fleur, le Model-Driven Design en serait le nectar. Je vous propose de faire une plongée au cœur de la modélisation DDD, appelée Model-Driven Design. Afin de comprendre comment obtenir un modèle juste, expressif et frugal, nous visiterons l’essentiel des ateliers qui contribue à nourrir les modèles mentaux associés au domaine métier : - Event Storming, - Example Mapping, - CRC Cards, - Story Mapping.

Avant de rentrer dans le cœur du sujet, je rappellerai l’origine du DDD selon Eric Evans: Bounded Context et les corollaires associés. Une fois planté le décor, nous pourrons expliquer le Model-Driven Design qui se décompose en deux :

Le Supple Design : une suite de patterns au service d’un code souple et fiable.

Le Deep Model : processus de modélisation du problème métier par raffinement successif. Les plus chanceux auront peut-être un Breakthrough.

Je conclurais par le Whirlpool Process of Model Exploration proposé par Eric Evans

Après cette conférence, vous ne verrez plus le Domain-Driven Design tout à fait de la même façon.

Notes

Moralité, lire le blue book mais surtout ne pas l’appliquer by the book.

🎥 Equity for software engineers

Avantages d’un package comprenant des options ou des actions
Avantages d’un package comprenant des options ou des actions. @AmelieBenoit33

Abstract

Speaker : Damien Pacaud

De plus en plus d entreprises proposent, en complément de la rémunération, des « packages d’équity ». C’est un cercle vertueux qui démarre en Europe et il peut être utile de prendre ces éléments en compte lorsque vous cherchez votre nouvel emploi. Bien souvent, les développeurs en France considèrent peu ces éléments de rémunération et n’y prêtent pas beaucoup d’attention.

Ce talk a pour but de démystifier le monde bizarre des BSPCE, AGA, RSU, Warrants et autres Stock options.

Notes

Options

BSPCE Stock Options Warrants

Actions

AGA (attribution gratuite d’action)= RSU (restricted stock unit)

Période de vesting classique:

  • 1ère année → touche rien

  • à la date d’anniversaire, on touche 25%

Vente

  • Actions → les actions sont acquises et on peut faire ce qu’on veut

  • Options → chaque option acquise peut etre exercée

Upside / underwater (avec les actions on gagne tjs, alors qu’avec des options c’est moins sûr)

Départ de l’entreprise

  • Actions → les actions vestés sont dispo

  • Options → le droit doit être

BSPCE

  • flat tax de 30% après 3 ans

RSU

  • Tranche Marginale d’Imposition de la valeur à la date d’achat

  • Flat Tax sur la plus value de cession

Stratégie

  • Négocier de l’equity dans son package

  • Attention aux valorisations

  • Estimer votre risque

  • Series A/B → risque fort

  • Serices C / pre-ipo → moins de risques

  • côté en bourse → risque faible

Protéger son organisation des attaques par le système de build

Abstract

Speaker : Louis Jacomet

Tous les jours, les développeurs assemblent du code des dizaines de fois. Parfois de façon transparente dans l’IDE, explicitement en ligne de commande ou sur l’environnement de CI. Lors de ces actions, la notion de sécurité est souvent reléguée au second plan voire simplement ignorée.

Cette présentation illustrera les vecteurs d’attaque et expliquera comment les mitiger. L’outil de build est par définition à risque car il s’agit d’un environnement d’exécution. Certaines pratiques permettent heureusement de réduire significativement ces risques:

  • S’assurer que les dépendances sont celles attendues

  • Rejeter les dépendances vulnérables (Log4j??)

  • Avoir un build reproductible

  • Utiliser un environnement éphémère

  • Valider les contributions externes

Nous illustrerons ces points avec Gradle mais la plupart des recommandations sont valables pour Apache Maven aussi.

🎥 Vers une culture où tout le monde est responsable de l’indisponibilité

Abstract

Nous sommes des développeurs applicatifs. Mais c’est loin d’un service en prod. Et de nos jours entre le devops, l’openapi, la constitution d’un SI construit sur des APIs, on est tous responsable d’un service. Je vous propose une rétrospective de la transition chez un éditeur d’une équipe de dev produit en une équipe de service cloud faisant tourner des milliers d’instances pour d’autres, les expériences acquises et de tout ce que l’on a dû (dés)apprendre en chemin.

C’est pas tant le cœur du code qui change, plutôt la culture de l’équipe, la conception des systèmes qui entourent et supportent ce code en prod. Quel impact sur l’architecture ? Comment construire des Standard Operating Procédures ? Comment on pense un SLA ? Comment penser blast radius, voisins bruyants, SRE ? Comment penser le risque ? Etc.

Après cette présentation, vous aurez des clés pour penser la transformation de vos équipes en un modèle où tout le monde est responsable du SLO (Service Level Objective) dont l’indisponibilité fait partie.

Notes

Penser service is a journey we learn from experience and not from books! Quand on gère son service, si qqch plante c’est "notre" problème.

  • Définir les limites du système

  • Définir les comportements attendus (availability, latency, error ratio, etc.)

Il est très difficile de définir les choses a priori. Apprendre à le faire tourner, mesurer les choses importantes.

Si on défini les limites, il faut les mesurer et prévenir l’utilisateur, et bloquer le service si on dépasse.

SLA is just a legal lie. SLO défini vraiment un objectif, une aspiration.

Depuis un SLO, on peut dériver:

  • de l’investissement

  • revoir une archi

  • indicateurs / alerts

SLO is function of MTBF (Mean Team Between Failure), MTTD (Mean Team To Discover) and MTTR (Mean Team To Recover). Définition des alertes, et des procédures standards de recovery

Service = Application code + config / SLO / Deployment pipeline / Pager / Tickets / Scripts…​

Si le code existe, il faut passer du temps à se poser des questions (what if…​) Blast radius → réduire l’impact, déploiement progressif ? Canary testing

D’un point vue ops

SRE = Ops avec un mentalité de Dev

Build communication and trust SLO outil de communication entre Dev & Ops/SRE

Garder les metrics TRES simples pour suivre l’état d’un service Rollback / Rollforward

Toute alerte doit avoir une Standard Operating Procedure (SOP) La procédure doit être la plus claire possible, lisible par qqun de HS à 4h du mat

  1. no alert, et on devine à partir du monitoring

  2. no metrics to anticipate, but we have SOP to get out of the mess

  3. ..

Coder pour l’Éternité, comprendre le développement sur la blockchain Ethereum

Abstract

La blockchain est de toutes les discussions, mais trop souvent on assimile blockchain et cryptomonnaies. Quel que soit l’avis que l’on peut avoir sur la question, il ne faut pas oublier que la blockchain c’est avant tout du code qui s’exécute dans un environnement très particulier. Cette présentation vise à plonger dans les profondeurs de la blockchain Ethereum en couvrant des sujets comme la machine virtuelle sous-jacente, le rôle des mineurs, les contrats intelligents et leur modèle d’exécution, les oracles. Vous sortirez de là en ayant une compréhension de la blockchain Ethereum du point de vue du code et avec un peu de chance l’envie de laisser une trace pour la postérité en déployant votre propre code sur cette blockchain.

Notes

Vitalik Buterin vision is that of a global decentralized computer. en 2014, mise en place de la fondation Ethereum, ETHDev

2000 ETH = 1 BTC, et on pouvait investir jusqu’à 500 000 BTC (1BTC = 570USD)

Crypto

Arbre de Merkle: arbre binaire, et à chaque étage, on a un hash de la concaténation des deux fils. ECC - Elliptic Curve Cryptography La clé privée est beaucoup plus petite qu’avec RSA

ECDSA - Elliptic Curve Digital Signature Algorithm Ledger ou metamask sont initialisé avec une seedphrase pour dériver des clés privées.

Blockchain

Block chain = arbre de Merkel

Ethereum

EVM = Ethereum Virtual Machine Elle peut intéragir avec la mémoire, du stockage et une stack de 1024 levels Pas de possibilité de faire des appels externes (http requests)

Les machines exécutent toutes les mêmes transactions. L’execution est déterministe, donc on peut valider le changement d’état.

Gas

Chaque instruction de la machine Ethereum est associé à un coût = le Gas L’interaction avec le stockage a un cout aussi La taille des blocs est limité par construction, car il y a une limite de gas (30 millions par block) Faut payer des gas premium fee au mineur si on veut que notre transaction soit minée plus vite

etherscan.io Premier consommateur de gas - Opensea

Actions possibles avec la BlockChain Eth:

  • Sending ETH

  • Deployer un smart contract

  • Intéragir avec un smart contract

Smart Contracts

Morceau de code qui s’exécute sur la blockchain, et qui peut être déployé. Ils ne sont pas intelligents, et ce sont pas des contrats

Le code est immuable et potentiellement immortel (sauf si SELF_DESTRUCT n’est pas implémenté) Bugs pour l’éternité :)

Langage: Solidity, Viper IDE: Truffle, Remix Blockchain: Ethereum

ABI Application Binary Interface

USD Coin year.finance Uniswap

Les bugs coutent TRES chers (3 bugs dans les 3 derniers mois à plus de 100 millions d’USD)

EVM pourrait intégré un sous-ensemble de Webassembly

🎥 S’affranchir de la Pyramide des Tests

S’affranchir de la pyramide des tests
S’affranchir de la pyramide des tests - @AmelieBenoit33

Abstract

Tester son code c’est facile à dire, mais écrire des tests utiles dans du code en entreprise, c’est pas toujours facile à faire.

En théorie les tests doivent nous aider, pourtant: - Le code ne se prête pas toujours aux tests unitaires, - On se retrouve parfois à refactorer les tests quand on refactore le code, - La pyramide des tests est souvent inversée, - Certains tests sont toujours verts, sauf quand ils sont rouges pour de mauvaises raisons, - On a beau tester le code, on a toujours des bugs, - Etc. La meilleure façon d’éviter ces problèmes est d’avoir les clefs pour choisir le bon test à écrire (ou à ne pas écrire!) en fonction du code à tester. Le but de cette présentation est de vous rendre autonome sur votre stratégie de tests, en vous présentant les tenants et aboutissants des différents types de test et du testing en général. En particulier vous verrez: - pourquoi la pyramide des tests est contre-productive - quand écrire des tests unitaires et quand ne surtout pas en écrire, - comment rédiger des tests robustes et clairs - les différentes abstractions que l’on peut tester

Notes

Doctolib s’affranchi de la pyramide de tests, c’est plutot un rectangle (1/3 E2E, 1/3 Unit, 1/3 Integration)

Historique de la pyramide

Première apparition en 2009 dans un book Tests E2E lents, pénibles à écrire et peuvent casser facilement

UT better?

UT Benefices: rapides, faciles à trouver dans le code, faciles à débug UT Costs: ? Vraiment difficile à évaluer, mais c’est pas gratuit

Les tests figent les interfaces de votre code.

Intéressant d’écrire des UT sur les interfaces pour lesquelles ont s’engagent (aka stable) Figé les contrats c’est compliqués pour les évolutions futures

E2E fragiles ?

On peut encapsuler les détails d’implémentation comme du code classique, et donc le rendre robuste et stable.

E2E lents ?

40 000 tests dont 1/3 en E2E, et à chaque commit lancent tous les tests sur un ensemble de machines Approche qui a tenu 9 années, et maintenant l’idée est de lancer certains tests à certains moments

Comment améliorer les tests?

Pourquoi on teste? pour éviter de casser des choses.

  • User use case

  • Attacker use case (sensitive data not leaked)

  • developpers use case (logs)

  • Data use cases (usage metrics)

L’important est de définir pourquoi on teste, et après si la forme est une pyramide, un rectangle, une montgolfière, on s’en moque :)

Git, back to the future

Abstract

Speakers : Antoine Ceol

Tout le monde utilise Git (où presque) et tout le monde s’est déjà retrouvé dans un état WTF 😱🤬🤯.

On va prendre ensemble un peu moins de 30 minutes pour apprendre à se dépatouiller quand on veut revenir en arrière, améliorer, et pourquoi pas, effacer son historique. Ça peut-être dangereux, mais, connaissant les avantages et anticipant les risques, ca en vaut la peine. L’approche se fera par l’exemple en ligne de commande ⌨️, un (git) bash suffit, pas besoin de DeLorean

Notes

Demo Magic - tooling pour faire des démos de script shell

git commit --allow-empty -m "message"
git log --walk-reflogs --pretty=oneline --abbrev-commit

Permet de retrouver les commits qui ont amender.

git show HEAD~0 -→ pointer un "vrai" commit git show HEAD@{1} -→ pointer un commit dans le reflog

git commit --fixup <commitId>
git rebase -i main --autosquash

git push --force-with-lease

Gitmoji 🥰

Jouer à Minecraft avec une IA générée par GPT-3

Abstract

Il y a des joueurs qui jouent à Minecraft pour le plaisir de jouer, d’autres pour développer leur créativité. Mais il y a une autre façon de jouer à Minecraft, c’est en utilisant une intelligence artificielle générée par GPT-3.

Dans cette présentation, nous allons parler un peu d’IA et de ML, de GPT-3 et de Codex, mais surtout, nous allons nous amuser à générer du code pour contrôler un bot dans Minecraft, le tout dans la bonne humeur ! Ca vous tente ?

Notes

La demo a été montré dans une vidéo avec Micode. Comme toutes les démos avec AI, ça ne marche pas à tous les coups, pas hyper stable

L’abstract plus haut a été écrit pas GPT-3, mais chuut.

Le joueur écrit "jump" dans le chat du jeu. Le bot récupère le chat et ajoute du contexte, et l’envoie à GPT-3. Playground openAI - Codex

Repo de code sur Github: minecraft-openai (sera opensourced plus tard)

VENDREDI

Keynote: On a parlé futur
Keynote: On a parlé futur, inclusion et gouvernance ce matin. @AmelieBenoit33

Futurospective digitale : le futur est-il encore ce qu’il était ?

Abstract

Speaker : Ludovic Cinquin

Les technologies digitales ont été un puissant moteur de transformation de notre civilisation, à tel point qu’elles se sont immiscées dans tous les recoins de nos vies et de notre planète.

Les 10 dernières années ont été ébouriffantes. Qu’en sera-t-il des 10 prochaines ?

Même si la prévision est un art difficile - surtout en ce qui concerne l’avenir -, nous pouvons identifier quelques macro-tendances qui structureront le futur de notre industrie. Le reste sera à écrire. Avec des lignes de code ?

Notes

Keynote Accenture / Octo - Technology vision, comme à l’époque.

3 scénarios pour le futur:

  • World tech companies

  • Digital Cold War

  • …​

Doubt par rapport aux chiffres annoncés concernant la consommation en CO2 d’un bitcoin.

LesBonsclics, une plateforme pédagogique au service du 1er réseau européen d’aidants numériques.

Abstract

Wetechcare est une association active en France et en Belgique dont la mission est de faire du numérique une opportunité pour tous. L’association est à l’origine d’un projet de plateforme digitale, Lesbonsclics, à destination de tout citoyen qui souhaite aider une personne en fragilité numérique sur l’acquisition des compétences numériques de base.

Elle regroupe notamment des contenus pédagogiques et des éléments méthodologiques pour permettre un accompagnement ludique et efficace. Les utilisateurs bénéficient d’un programme d’animation en ligne permettant de développer ses compétences en fonction de leurs sujets d’intérêt et de leur temps disponible. En 2021, la plateforme a permis l’accompagnement de plus de 500000 personnes.

Lesbonsclics connaît un succès permanent depuis sa création, chaque mois elle intègre plus de 2000 nouveaux aidants. L’association s’appuie notamment sur du mécénat de compétences de développeurs pour le développement de sa solution.

Notes

WetechCare - La gouvernance collaborative du web Utiliser la tech pour résoudre l’équation sociale

Objectif: réduire la fracture numérique. Permettre à chacun d’accompagner à son échelle des publics en difficulté.

La quête d’une gouvernance collaborative du web

Abstract

Le web est de plus en plus attaqué par des campagnes de désinformation, qui emploient des usines de trolls pour manipuler l’opinion publique, noyer les informations compromettantes et amplifier la haine. Cette guerre de l’information est devenue un enjeu de sécurité nationale.

En réaction à cela, les géants du web ont pris des décisions radicales et unilatérales, comme le bannissement de Donald Trump ou l’autorisation des appels au meurtre de Poutine et des soldats russes.

Dans cette présentation, après avoir insisté sur l’ampleur du problème, je présenterai la plateforme Tournesol, qui propose une gouvernance collaborative et sécurisée de la recommandation de l’information.

J’essaierai de convaincre le public que la recherche et le développement de telles solutions sont critiques pour le futur de l’humanité.

Notes

Tournesol - La plateforme de gouvernance collaborative du web Plateforme de recommandation de l’information. Exemple on nous présente 2 vidéos, et il faut élire laquelle on recommenderait le plus.

Ajouter de la donnée dans la BDD d’entrainement d’un algo (comme GPT-3) c’est comme un "vote". Renforcement fort de biais, et risque fort sur les algo de recommandations

Chaque année FB retire 7 milliard de faux compte

🎥 Développ(eur|euse) Senior avec 6 ans d’expérience, et après ?

Abstract

Speakers : Hugo Lassiege et Dimitri BAELI

Le sujet récurrent dans l’IT : si on est senior avec 6 ans d’expérience, quelle est l’étape d’après ? Faut-il devenir manager pour progresser ? Dans cette session nous vous proposons de découvrir les rôles de Staff Engineer, Principal Engineer, Fellow, Distinguished et la notion d’impact qui accompagne ces rôles. Nous espérons vous faire réfléchir également à la notion de leadership dans vos métiers, vos équipes, vos produits et l’entreprise.

Notes

Carreer de Contributeur Individuel. Senior, Staff engineer, Principal Engineer, Fellow/Distinguished Engineer, CTO -→ Leadership path

Other path: Manager path. But you cannot do both at the same time. The Engineer, Manager, and the Pendulum

Impact

Avez-vous eu de l’impact dans votre entreprise ? Etes-vous capable de le mesurer ? Quel est le retour business?

  • Junior Software engineer: impact is individual

  • Software engineer : team squad

  • Senior: chapter guild

  • Staff: product line

  • Principal: impact on company - anticipation

  • Fellow: impact on the industry

Quatre axes pour le developpement perso

  1. Expertise tech

  2. Capacité à produire des choses - Efficience - getting things done

  3. Business

  4. People - Leadership

Comment déveloper Leadership - Business

Identifier soit même les sujets. Leadership is another side of management.

Pour passer de senior à staff, faut faire de la communication.

Créer de l’impact ? Objectives (problem to solve) Discovery: Value, usability, feasability, viability Delivery: Reliability, scalability, security, performance

C’est bien d’identifier les problèmes, mais il faut contribuer pour les résoudre, et ne pas être le raleur de service.

Culture du feedback FR & EN

À la découverte des Docker Dev Environments

Abstract

Speakers : Guillaume Lours et Djordje Lukic

Imaginez-vous en plein travail sur une nouvelle fonctionnalité et vous devez absolument faire une revue de code d’un de vos collègues. Vous allez encore une fois mettre de côté votre code en cours, récupérer celui de votre collègue et qui sait peut-être modifier votre environnement local pour tester ses changements ? Et si nous vous proposions une nouvelle expérience de développement ? Comment ? Et pourquoi pas par un simple Copier/Coller de l’url de votre repository GIT dans Docker Desktop ?

Les Dev Environments sont une manière d’isoler votre code, vos dépendances et processus en cours, vous permettant ainsi d’avoir plusieurs versions d’un même projet en test sur votre machine. Et bien plus encore, partagez simplement votre code avec les autres membres de votre équipe, interagissez via Docker Compose avec une stack applicative complexe …​

Notes

Feature déjà présente sur Docker Desktop depuis plusieurs mois. Permet de shiper un environnement de dev, avec les fichiers non commité, les dépendances…​

Pour comprendre, le plus simple est de faire les 2 exemples proposés dans Docker Desktop > Dev Environment.

Réception d’image satellite 🛰️ avec un Raspberry

Abstract

Speakers : Guillaume Membré

Vous avez tous déjà vu les images météo satellites diffusées pendant la météo, mais est-ce que vous saviez que vous pouvez les capter directement du satellite ? Et en plus avec du matériel que vous avez peut être déjà ! Dans cette présentation, nous verrons comment réaliser une station de capture de flux radio émis par les satellites 🛰️ NOAA, en utilisant du matériel grand public comme un Raspberry, un tuner USB et pas mal de DIY 🛠️. Ce type de projet complétera sans problème une station météo à base de sondes de températures et d’Arduino.

Notes

Satellite NOAA - programme des années 60 qui continuent à graviter autour de la Terre - reste 3. Protocole: Automatic Picture Transmission

Matériel utilisé.

  • Clé USB TNT++ avec un chipset modifié pour écouter la bande de fréquence.

  • Antenne custom pour capter le signal satellite.

  • Raspberry Pi 2

  • Logiciel: rtl_fm | sox > .wav | wxtoimg`

Pi alimenté via Ethernet PoE. Mais avec 30m de câble, il faut compter 1.5V de perte. Donc il faut envoyer 12V pour recevoir 10V, puis passer dans un régulateur de tension.

🎥 Mob programming, la véritable approche du développement en équipe

Mob programming
Mob programming @AmelieBenoit33

Abstract

Speakers : Maxime Odye et Mathieu Pousse

Shérif, le manager, est en colère. Il vient de surprendre toute l’équipe de développement autour d’une même machine. Rendez-vous compte ! Après des comparaisons douteuses avec la DDE, il les a bien sermonnés et leur a ordonné de retourner à leur poste de travail immédiatement, un peu de sérieux ! Avec Shérif, la bamboche, c’est terminé ! Malheureusement, des Shérif, il en existe encore beaucoup dans les open-spaces de nos DSI. Partager un ordinateur entre plusieurs développeurs, mais pourquoi donc ?

Le MOB programming est une pratique s’appuyant sur le Lean et sur Extreme Programming qui consiste à réaliser une tâche, qu’elle soit technique ou non, à plusieurs. Les groomings, planifications et autres réunions de conception, ne serait-ce pas déjà des MOBs ? De mythe à réalité, nous vous proposons de faire un retour d’expérience du MOB programming dans une équipe produit chez Ouest-France. Nous vous offrirons deux points de vue, celui du lead, présent depuis le début du projet (5 ans) et celui d’un développeur qui a rejoint l’équipe début 2021.

Notes

Réunir la team sur le même sujet, au même moment, et au même endroit (un peu comme le principe des urgences hospitalières) Objectif du mob, lisser par le haut.

1 Driver, N navigateurs, et toutes les x min, on change de rôle. Navigateur énonce les idées / concepts, mais ce n’est pas une dictée.

Full / Swap stacks -→ agnostic de la stack techno.

Pros

Partage des pratiques, outils, historique du projet, réflexion/solution, moments d’équipe, front/back/ops Montée en compétences & onboarding simplifiés Pas de code review, moins de standup, plus de développement

Cons

Equipe injoignable Débats philosophiques. MOB mal préparé, trop exploratoire, trop ambitieux.

Règles

MOB le mercredi après-midi only Pas de sujet = pas de MOB Pour chaque sujet, il faut un "leader" pour le préparer, poser le contexte, dimensionner Pas de sujet de conception pure Rester focus sur l’objectif (comme dans un dev classique)

IDE partagé, et configuré de la même façon. Ne cacher les numéros de ligne

Sujets

Définir la liste des sujets en amont comme étant elligible à un MOB. Loi des 2 pieds

Difficultés

Rythme: quand ça manque de rythme, les gens décrochent vite. Trop soutenu, c’est pas mieux. Pas de saisie en parallèle, car impossible à suivre. Fatigue intellectuelle forte.

Productivité?

Bénéfices: Team building, bienveillance, soft skills, entretien de la sécurité psychologique Montée en compétence: technique, fonctionnelle, organisationnelle, tips & tricks

L’exercice de MOB est intéressant car il y a eu bcp d’échec ⇒ boucle de feedback courte, pratique agile - improvement

CI/CD, le divorce serait-il prononcé ?

Abstract

Speakers : Nicolas GIRAUD et Yann Schepens

A l’heure des digital factories, des transformations numériques, et autres mutations DevOps de nos organisations, les concepts du CI/CD sont poussés toujours plus loin…​

A un moment où tout devient pipeline, où chaque action est automatisée, enchaînée et intégrée dans des scénarios, ne faisons-nous pas exploser la complexité de nos déploiements ? Comment faire pour maintenir cet écosystème qui doit nous aider à rester concentrés sur la valeur de nos produits ?

Et si, alors que nous tendons vers les "Everything As Code", des solutions se trouvaient déjà au cour de nos applications ? Et si nous, développeuses et développeurs logiciel, avions une partie de la réponse entre nos mains ?

A la lumière de leurs expériences et surtout enrichi par de nombreux échanges, Nicolas et Yann se proposent de démontrer en quoi certaines pratiques du développement moderne peuvent nous aider à limiter les risques. Pour que maintenir vos pipelines reste un jeu d’enfant…​

Notes

CI: Contexte du dévelopeur - Build & Tests CD: CDelivery du livrable aux utilisateurs. CDeployment sur un env. CDevelopment déployer aux users finaux.

pipeline = workflow = graphset

Dis, comment on fait un pipeline ?

  1. Définir les objectifs et contraintes

  2. Analyser le process de dev/déploiement existant

  3. Déterminer les étapes clés ou cas particuliers

  4. Définir les feedbacks aux différentes étapes (notif, board de management)

  5. Définir les déclenchements automatisés

  6. Choisir les outils

  7. Faire un premier pipeline

DRY: Faire des librairies de pipelines. Factoriser c’est bien, mais attention au blast radius SOLID: Les mêmes principes qu’en dev peuvent être appliqués dans le développement de CI/CD

3 pipelines différents

Build Deliver Deploy

Et définir les étapes clés, posées des questions, …​ Pouvoir débrayer si besoin.

La vie de couple CI/CD est parfois difficile. Pour faire la thérapie de couple, arrive un 3e laron: DevOps Pas compris la conclusion du talk.

Créer un jeu cross plateforme…​ en Rust! 🦀

Abstract

Speaker : François Mockers

Avez vous déjà codé la lumière ? Le plus difficile, c’est les ombres ! L’écosystème du jeu vidéo en Rust est en plein boom ! Après avoir conquis les amateurs et indépendants, même les grands studios s’y mettent. Après un tour de quelque projets Rust dans le monde du jeu vidéo (Amethyst, Macroquad, rg3d, Nannou, …​), nous nous concentrerons sur le moteur de jeu Bevy et ce qu’il propose :

un ECS (Entity Component System) s’appuyant sur le système de type Rust un moteur de rendu moderne modulable grâce à un graph de rendu un support cross plateforme grâce à webgpu Sur ces bases et une super communauté, en un an et demi d’existence Bevy est rentré dans le top 5 des moteurs de jeu open source sur GitHub. Venez explorer les idées de Pipeline Rendering, shaders, ECS, Global Illumination, Ray Tracing, Clustered Forward Rendering et tant d’autres!

Et comment, grâce à un moteur de jeu qui vous semblera rapidement naturel, vous pourrez enfin faire ce jeu auquel vous rêvez depuis tout petit…​.

Notes

Ca manquait un peu de Rust dans cette conférence 😁

ECS: Entity Component System Modèle de composition plutôt qu’héritage

About