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
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
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. 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. 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. 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 ?
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 !
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. 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. 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à »
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
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
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
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, ...).
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. 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. JS ET LE « BON » HTML
Élément « datalist »
Autocomplete natif
47. JS ET LE « BON » HTML
Autoremplissage
Email, password, newpassword
OneTimeCode
48. JS ET LE « BON » HTML
Formater la saisie
pattern
Validation
Pseudo-classe => :valid , :invalid , :out-of-range
Spellcheck = false
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. JS ET LE « BON » HTML
Formulaires, nombreux attributs utiles
59. Kanye West, Maths and Signals ! How to
clone Shazam
Conception de langage : communiquer
avec la machine
D’AUTRES PRÉSENTATIONS INTÉRESSANTES
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
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