Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Retour sur les conférences du DevFest de Nantes 2022

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 61 Publicité

Retour sur les conférences du DevFest de Nantes 2022

Télécharger pour lire hors ligne

Antonin, Jean-Loup, Quentin, Oscar, Bruno et Julien ont assisté à 2 journées de conférences et ont choisi de nous partager quelques-uns de ces sujets :
 - Choregraphy vs Orchestration in Serverless microservices
 - What about logs : comment les présenter ?
 - L'ergonomie des formulaires Web : bonnes pratiques et erreurs à éviter
 - Playwright : Tester ses webapps
 - Temporal.io : Mes workflows sont cloud ready
 - Dates et heures : Fuyez ou venez découvrir les pièges
 - JS et le bon HTML : (re)découvrir les éléments natifs
 - DockerFile : si les meilleurs étaient ce que l'on écrit pas

Antonin, Jean-Loup, Quentin, Oscar, Bruno et Julien ont assisté à 2 journées de conférences et ont choisi de nous partager quelques-uns de ces sujets :
 - Choregraphy vs Orchestration in Serverless microservices
 - What about logs : comment les présenter ?
 - L'ergonomie des formulaires Web : bonnes pratiques et erreurs à éviter
 - Playwright : Tester ses webapps
 - Temporal.io : Mes workflows sont cloud ready
 - Dates et heures : Fuyez ou venez découvrir les pièges
 - JS et le bon HTML : (re)découvrir les éléments natifs
 - DockerFile : si les meilleurs étaient ce que l'on écrit pas

Publicité
Publicité

Plus De Contenu Connexe

Similaire à Retour sur les conférences du DevFest de Nantes 2022 (20)

Publicité

Plus récents (20)

Retour sur les conférences du DevFest de Nantes 2022

  1. 1. DEVFEST NANTES – 02 Décembre 2022
  2. 2. PROGRAMME Choreography vs Orchestration in Serverless Microservices What about logs ? UX Formulaires web Playwright – web apps testing Temporal.io Dates et heures JS et le bon HTML BuildPack
  3. 3. CHOREOGRAPHY VS ORCHESTRATION IN SERVERLESS MICROSERVICES Guillaume Laforge, Google
  4. 4. Avantages : Facile à implémenter DIRECT SERVICE-TO-SERVICE CALLS Inconvénients : Fortement couplé Chaque service est un point de défaillance unique Chaque service a sa logique de Retry/Error/Timeout Qui assure la transaction ?
  5. 5. Avantages : Faiblement couplé Modification et scalling facile Pas de point de défaillance unique Facile à étendre avec les Evènement CHORÉGRAPHIE Inconvénients : Difficile à debugger / monitorer La logique de Retry/Error/Timeout est difficile Le workflow n’est pas explicite Qui assure la transaction ?
  6. 6. Avantages : Le workflow est explicite et versionné Monitoring facile de chaque étape Retry/Error/Timeout centralisé Services sont indépendants ORCHESTRATEUR Inconvénients : Nouvelle techno à apprendre Orchestrateur est le point de défaillance unique Qui assure la transaction ?
  7. 7. Quelle est la meilleure solution ? Direct Calls : • Une architecture simple avec peu de service qui change peu Event-Driven architecture : • Services faiblement liés • Pas de parallèle ou d’ordre Central Orchestrator : • Services fortement liés • Exécution ordonnée CHORÉGRAPHIE OU ORCHESTRATION ?
  8. 8. WHAT ABOUT LOGS ? Daniel MAHER, Scaleway
  9. 9. WHAT ABOUT LOGS ?
  10. 10. WHAT ABOUT LOGS ?
  11. 11. WHAT ABOUT LOGS ?
  12. 12. WHAT ABOUT LOGS ? Au minimum : une date/heure et le sujet du log Une structuration du log et éviter les problèmes d'interprétation Les logs et les évènements sont des choses séparées Les métadonnées ne sont pas le message, elles sont là pour aider ! La présentation est primordiale !
  13. 13. UX FORM WEB Geoffrey Crofte, Foyer Group
  14. 14. UX FORMULAIRES WEB Se poser les bonnes questions Utilisateurs différents profils Clients, experts, admin Client : Cherche l’adhésion Clarté, simplicité Experts : Connait son métier Complétude, formulaires plus complexes (besoin de voir beaucoup de choses sur un seul écran) Admin : Actions rapides Gestion simplifiée, workflows
  15. 15. UX FORMULAIRES WEB Autour du formulaire Existant ? Allez vous changer profondément les habitudes ? Pouvez-vous éviter de les changer ? Comment accompagner ce changement ? Métier Est-ce que la logique métier permet de faire cela ? Est-ce que les données existent et peuvent être stockées ? Ai-je suffisamment la connaissance métier ?
  16. 16. UX FORMULAIRES WEB Univers très normé, habitudes anciennes Ne pas inventer des nouveaux comportements Innovations basées sur des études : comportements utilisateurs « Si l’originalité de votre proposition graphique vient en altérer sa compréhension, changez là »
  17. 17. UX FORMULAIRES WEB Radios vs Checkbox
  18. 18. UX FORMULAIRES WEB Read-only
  19. 19. UX FORMULAIRES WEB Evolution de Material Design
  20. 20. UX FORMULAIRES WEB Formulaire multi-étapes Doit servir l’utilisateur Pas du design
  21. 21. UX FORMULAIRES WEB Types de champs : select
  22. 22. TESTING WEB APPLICATIONS WITH PLAYWRIGHT Debbie O'Brien Microsoft
  23. 23. QUI AIME FAIRE DES TESTS ?
  24. 24. Support des browser modernes Fonctionne sur Windows, Linux, macOS, en local ou en CI Multi Language : TypeScript, JavaScript, Python, .NET, Java. Codegen Inspector Trace Viewer – screenshot, etc. VsCode extension GitHub Actions Backer par Microsoft 🤫 KÉSAKO ET CE QU’ON NOUS PROMET
  25. 25. EXEMPLE
  26. 26. Génération du code en fonction des actions enregistrées par Playwright Pas besoin d’aller inspecter le code pour trouver les balises / id (picking selectors) CODEGEN
  27. 27. Rapport Screen shot Inspection des snapshots DOM SNAPSHOT
  28. 28. Cross browser Cross device RAPPORT DE FIN DE TESTS
  29. 29. ET LES AUTRES ? https://medium.com/tech-p7s1/why-favor-playwright-over-selenium-or-cypress-e96df84c08e1
  30. 30. VERS UNE NOUVELLE NORME ?
  31. 31. TEMPORAL.IO MES WORKFLOWS SONT CLOUD READY Alexandre Vilain, OVHCloud
  32. 32. LE PROBLÈME
  33. 33. LE PROBLÈME
  34. 34. LE PROBLÈME
  35. 35. LA SOLUTION – TEMPORAL.IO
  36. 36. LA SOLUTION – TEMPORAL.IO
  37. 37. DATES ET HEURES À L'HORIZON ? FUYEZ… OU VENEZ DÉCOUVRIR LES PIÈGES TENDUS Arnaud Pichery, Dataiku
  38. 38. DATES ET HEURES
  39. 39. DATES ET HEURES Il existe un 30 février en 1712 pour la Suède (à cause du passage calendrier julien vers calendrier grégorien, la Suède a rencontré des décalages) Le 11 mars 1917 à Paris, une annonce informe que l'horloge sera retardée de 9 minutes Nouvel an au mois de mars en Angleterre (24 mars 1708 -> 25 mars 1709) En Russie de 1937 jusqu'à la guerre passage en semaine de 6 jours
  40. 40. DATES ET HEURES
  41. 41. DATES ET HEURES
  42. 42. DATES ET HEURES Récapitulatif: Utilisation d'une librairie avec les bons types pour stocker et manipuler les dates/heures Utilisation de la norme ISO 8601 Méfiance avec les dates <2000 et danger si <1970 Bugs qui vont arriver: En 2028 les CD encodés avec la norme Joliet (extension de l'ISO 9660 pour le stockage de fichiers) la data ne pourra plus être encodée et difficilement lue (stockage de la date 1900 + 128) En 2038 gros souci sur le Unix Timestamp stocké sur des entiers sur une architecture 32bits, les systèmes sous Unix 32 bits ne fonctionneront plus correctement (caméra, four, TV, ...).
  43. 43. JS ET LE « BON » HTML Gaël Poupard, OnePoint
  44. 44. JS ET LE « BON » HTML Univers Standardisé Axiome du Web Principe du moindre pouvoir HTML > CSS > JS > … Design modulaire Tolérance à l’erreur HTML, SVG : pas JS Suivre les spécifications Ça bouge de temps en temps
  45. 45. JS ET LE « BON » HTML Javascript pousse HTML et CSS Pas mal de fonction JS deviennent du CSS, HTML Hover Smooth scroll Positionnement Support navigateur de plus en plus large
  46. 46. JS ET LE « BON » HTML Élément « datalist » Autocomplete natif
  47. 47. JS ET LE « BON » HTML Autoremplissage Email, password, newpassword OneTimeCode
  48. 48. JS ET LE « BON » HTML Formater la saisie pattern Validation Pseudo-classe => :valid , :invalid , :out-of-range Spellcheck = false
  49. 49. JS ET LE « BON » HTML Spellcheck = false Vérification orthographique Google Exfiltration de données “The company then went on to make clear that it is aware that the data may sometimes be sensitive, so text isn’t attached to any user identity and only stored and processed on Google’s servers temporarily. The company further vowed to improve its own processes to exclude passwords from being processed proactively.”
  50. 50. JS ET LE « BON » HTML Formulaires, nombreux attributs utiles
  51. 51. JS ET LE « BON » HTML Modales natives
  52. 52. JS ET LE « BON » HTML Output : accessibilité
  53. 53. JS ET LE « BON » HTML Tableau Pseud-classe : target
  54. 54. JS ET LE « BON » HTML Des « nouveautés »
  55. 55. JS ET LE « BON » HTML Et les perfs
  56. 56. ET SI LES MEILLEURS DOCKERFILE ÉTAIENT CEUX QUE L'ON N'ÉCRIT PAS Fabien Martin, VMware
  57. 57. LE PROBLÈME AVEC LES IMAGES DOCKER
  58. 58. LA SOLUTION – LES BUILDPACK
  59. 59. Kanye West, Maths and Signals ! How to clone Shazam Conception de langage : communiquer avec la machine D’AUTRES PRÉSENTATIONS INTÉRESSANTES
  60. 60. Rennes 35 Boulevard Solférino 35000 Rennes Paris 350 rue de Vaugirard 75015 Paris Nantes Whoorks Nantes Gare 17 Boulevard de Berlin 44000 Nantes + 33 2 30 96 21 60 www.spikeelabs.fr
  61. 61. Straight to the point www.spikeelabs.fr

Notes de l'éditeur

  • Avantages :
    Facile à implémenter



    Inconvénients :
    Fortement couplé
    Chaque service est un point de défaillance unique
    Chaque service a sa logique de Retry/Error/Timeout
    Qui assure la transaction ?
  • Avantages :
    Faiblement couplé
    Modification et scalling facile
    Pas de point de défaillance unique
    Facile à étendre avec les Evènement

    Inconvénients :
    Difficile a debugger / monitorer
    La logique de Retry/Error/Timeout est difficile
    Le workflow n’est pas explicite
    Qui assure la transaction ?



  • Avantages :
    Le workflow est explicite et versionné
    Monitoring facile de chaque étape
    Retry/Error/Timeout centralisé
    Services sont indépendants

    Inconvénients :
    Nouvelle techno à apprendre
    Orchestrateur est point de défaillance unique
    Qui assure la transaction ?

  • Quelle est la meilleur solution ? It depends !

    On est pas obliger de choisir, on peux faire un mix de ses solutions.

  • En anglais
  • Culture -> testing culture
  • Multiple everything. Test scenarios that span multiple tabs, multiple origins and multiple users.
    Browser contexts. Playwright creates a browser context for each test
  • On peut vérifier si on est sur un desktop ou un téléphone
  • Fait partie de la vague « OpenSource by Microsoft »

  • Dans système de workflow on a les diffèrent étape métier (bleu)

    Pour chacune de ces étape on a donc un micro service associé.
  • Et pour chacun de ces µs il y a possiblement un workflow a exécuter, avec des sous étape.
  • C’est la que les problèmes commence
    Quand il faut que chaque µs gère
    les erreurs
    les retry
    Les timeout,
    les tous les mécanismes asynchrones

    On se retrouve avec de la duplication de code partout et des gestion des erreurs non homogène
  • Temporal est un Framework de Workflow.

    On déploie un cluster Temporal.io et une base de donnée
    Et on y connecte ses micro service
  • Chaque µS s’enregistre au près de Temporal en décrivant les tache qu’il est capable d’exécuter.

    Le client demande à temporal l’exécution d’un workflow. Et temporal orchestre l’exécution du workflow

    La gestion de l’asynco est faite par Temporal

    Et la gestion des erreurs, retry ,timeout et des rejeux est standardisé par Temporal
  • Vous avez 200 images docker en production. Une vulnérabilité est découverte dans l’image de base.

    L’ops qui normalement doit agir dans ce cas, se retrouve a attendre que les programmer fix chacune des images avant de pouvoir redeployer.
    Et les développeur doivent mtn mettre a jours à chaque vulnerabilité.

  • Les buildpack ont été  inventé par Heroku, et est maintenant Soutenue par la Cloud native computing Fundation
    Les buildpack permettent de construire une images docker à partir des sources et rien d’autre.
    Chaque buildpack détecte la présence de déclencheur dans le code source:

    Fichier .py buildpach install python
    Fichier pyproject.toml install poetry


    On obtiens donc une images docker sans avoir a la décrire.
    Cela permet au Ops de régénérer une images docker sans changer le code.
    Et au développeur de ne pas s’occuper des images docker et de leur vulnérabilité.
  • Shazam : comment ça fonctionne / transformée de fournier

    Un mec qui fait son compilateur

×