AWS re:invent 2022, la grande conférence annuelle d’AWS, a commencé. Et la Keynote d’Adam Selipsky, CEO d’AWS, a eu lieu hier soir !

Comme d’habitude, cette Keynote est l’occasion de faire le tour d’un ensemble de nouveautés récentes, futures, ou rendues publiques pendant cet évenement. Voici les notes que j’ai prises pendant cette présentation de deux heures, avec un focus évident sur les domaines qui m’intéressent le plus. Et avec des liens vers les pages d’annonces et des articles quand j’en ai trouvé.

J’ai aussi pris la liberté d’insérer de nombreux liens vers des nouveautés sorties dans les jours passés, parfois entendues lors d’autres événements.

Le 13 octobre 2022, j’étais au Forum PHP à Paris, pour ma conférence « Comprenez comment PHP fonctionne, vos applications marcheront mieux ». C’était la première fois que je donnais ce nouveau talk en public 🎉

Cette conférence a été enregistrée et la vidéo est disponible sur la chaine Youtube de l’AFUP :

Cela dit, puisque tout le monde n’accroche pas avec le format vidéo et que beaucoup préfèrent du texte, voici une tentative de transcript de cette conférence.

L’architecture et le code de nos projets, quand nous pouvons faire du bon travail :

Les documentations de ces mêmes projets :

Nos documentations sont sans ambition. Nous ne faisons pas d’effort pour les structurer ni les rédiger. Elles sont très vite obsolètes et abandonnées, non maintenues et inutiles. Voire contreproductives.

Dans une salle de conférences, je vois deux types de personnes :

• celles qui sont montées sur scène auparavant et qui savent ce que ça fait ;
• et celles qui n’osent pas encore, qui tremblent à l’idée de ce que ça leur ferait ou fera.

Vous avez déjà parlé en public ? Vous êtes conférencier ou conférencière ?
Vous êtes mieux placée que qui que ce soit pour aider vos collègues !

Le 1er juillet 2022, j’étais à Sunny Tech, pour ma conférence « Préparez et donnez votre premier talk ». J’ai déjà donné cette présentation plusieurs fois en différents formats et durées et elle a été enregistrée en vidéo au moins à deux occasions :

• à Sunny Tech, justement, en format 20 minutes ;
• en meetup avec Software Crafters Lyon, où j’ai parlé pendant environ 3/4 d’heure, avec des moments d’échange avec le public entre chaque section, d’où plus de deux heures de vidéo.

Je sais que tout le monde n’accroche pas avec le format vidéo et que beaucoup préfèrent du texte, donc, ci-dessous, une tentative de transcript de cette conférence telle que je l’ai donnée à Sunny Tech – en version courte, donc.

J’ai commencé à partager des textes sur Internet pendant le lycée, en 2000 ou 2001 : j’ai écrit le tutoriel en français pour apprendre à programmer en C pour calculatrices TI-89 et TI-92+.

Quelques mois plus tôt, quand j’avais découvert cet univers, les guides étaient rares et les documentations en anglais¹. Peut-être que j’allais aider d’autres personnes à se lancer ?

Au fil des années, j’ai rencontré des dizaines de membres de cette communauté, nous avons passé plein de bons moments ensemble… Et j’ai entendu pas mal de fois « j’ai commencé avec ton tuto » ❤️

Aujourd’hui, on me demande régulièrement ce que écrire m’apporte, pourquoi je le fais.

Au-delà du fait que j’apprécie partager, que j’aime écrire, que je réfléchis en écrivant et que mettre mes pensées sur papier me force à les organiser et me donne une certaine clarté, écrire a sans aucun doute aussi eu des effets positifs sur ma carrière.

Un de mes premiers chefs répondait plus souvent et plus rapidement aux mails quand il était en congés que quand il travaillait officiellement¹.
Une réaction seulement en fin de journée ? Nous savions qu’il dépilait après son tunnel de réunions. Un retour dans les dix minutes ? Il était en vacances et n’avait pas de meetings !

Nous trouvions ça marrant, original. Peut-être triste aussi. Mais nous pouvions compter sur lui. Avec le recul, nous comptions sans doute un peu trop sur lui !

Réunion de planification Scrum, dans une PME d’une douzaine d’employés, dont 5-7 personnes dans l’équipe de devs. Elles passent en revue les stories en haut du backlog, par ordre de nombre de points descendant. Pour chaque, découpage en tâches techniques¹ et estimation grossière du nombre de jours de travail, pour déterminer ce qui devrait rentrer dans le sprint et quand arrêter d’en prendre².

Au bout d’un moment, l’équipe arrive à une story d’apparence simple : sur l’application mobile Android qu’elle maintient et édite en marque blanche pour ses clients B2B, il est demandé d’ajouter une pastille sur les contenus offerts avec l’appli, pour permettre aux utilisateurs (= les clients des clients de la PME) de mieux identifier ces cadeaux au milieu de leurs achats.

Vu de loin et sans entrer dans les détails, ça n’a pas l’air d’être une très grosse évolution et l’équipe estime qu’il y en a pour deux jours de travail.
Quelque chose comme 0,25 jour pour bien cadrer le besoin³ et déterminer quel pictogramme afficher, 0,25 jour pour monter un environnement de développement, 1 jour pour coder et tester/valider la fonctionnalité et 0,5 jour pour rebuilder les déclinaisons de l’application pour chacun des clients et les déployer sur le store Android.

Mais…

Daily, I hear developers say “my¹ user story is finished”. And, almost always, they utter this sentence when they have deployed a feature to production².

But I don’t think a User Story should be considered as “done” at that time!