Cela fait désormais 3 ans que je suis totalement de retour en Normandie et donc 3 ans que je peux pleinement participer à la journée de conférences de Codeurs en Seine riche en qualité de présentations et d’échanges et pleinement accessible puisque gratuite ! 

C’est donc pas moins de 930 passionnés qui se sont rassemblés en ce jeudi 21 novembre 2019 autour d’une trentaine de conférenciers et une armée de bénévoles.

Pour ma part voici comment c’est articulé cette journée :

8h45 : Plénière d’accueil

Un chouette démarrage avec ceux qu’on ne présentent plus dans l’équipe de Codeurs en Seine : Youen Chéné et Rudy Baer

9h00 : Le pouvoir du simple 

Le type de conf’ ouverte et dénonciatrice que j’adore dans ce type d’événement qui permet de prendre du recul sur des situations que nous pouvons vivre au quotidien dans nos projets.

Ici le focus était porté sur le besoin aujourd’hui de complexifier tout ce qui nous entoure : depuis les objets jusqu’au termes utilisés, technos et autres pour en valoriser potentiellement le besoin … et le coût !  

Résultat : un ensemble de buzzword pouvant permettre dans certain cas d’être gagnant au Bingo Bullshit proposé et qu’on arrive à accepter et utiliser nous-même.

Nous alimentons d’ailleurs cette image et notamment pour tout ce qui se lié à l’expert (“T’inquiètes je suis un expert“) et pourtant …

Tout en exemples, Thierry Croix nous montre que nous faisons trop souvent l’amalgame entre quelque chose de “Complexe” et “Compliqué” : ainsi beaucoup de choses complexes peuvent paraître super simples 😉

Une préconisation de retour au simple car le rôle de l’expert est d’être capable d’expliquer simplement quelque chose de complexe et non de faire quelque chose de compliqué ^^

Bref à voir mais aussi garder en tête dans nos actions de tous les jours! * 

Le talk est disponible depuis une autre conférence sous : https://www.youtube.com/watch?v=gG8UYIzsewU&feature=youtu.be)

10h00 : DockerFiles les bonnes pratiques

Même si je ne pratique pas à l’instant t, ce genre de conf permet de garder le pied à l’étrier sur le sujet 🙂

Alors pour partage, pour vos Docker composed file, voici les guidelines à suivre : 

  • One single process per container
  • Use officiel images
  • Don’t use latest tag in production
  • Use multi stage builds
  • Cleanup your layers : apt install
  • Avoid tuning as root 

et pour le reste n’hésitez pas à suivre @glours et @JeremieDrouet

11h00 : Manuel d’antisabotage

Une bonne surprise pour une conf que j’ai pu sélectionner sur le vif ayant eu porte close sur l’autre conf “Comment se faire hacker bien comme il faut”

Le but de la présentation : soulever le lien entre la CIA, le sabotage et manifest agile ?

Et à la question qui a déjà saboté une réunion, +1 à celui qui ne se lève pas :p

Effectivement on relève beaucoup de similitudes dans notre quotidien, entre les consignes du manuel de sabotage et ce qui peux se passer lors de réunions notamment : 

  • Faire des monologues, 
  • Soulever des problèmes hors sujet aussi souvent que possible,
  • Revenir sur des sujets décidés lors de la réunion précédente,
  • Soumettre tout problème à des comités
  • Jamais moins de 5 personnes dans des comités
  • Faire des réunions quand il y a du travail critique à effectuer

Une première réponse face à cela : le Manifest agile.

Étonnement Emilie Esposito nous dévoile que chacun des principes du Manifest apporte une réponse potentielle contre des consignes de sabotage : 

A cela une citation de St Exupery que je garderai : 

“La perfection est atteinte non pas lorsqu’il n’y à rien à ajouter mais lorsqu’il n’y a plus rien à retirer”

Alors en vous invitant à y regarder de plus près, voici l’autre guideline partagé pour tous les saboteurs que nous sommes :

  • C élébrez votre colère
  • I nvestiguez
  • V erbalisez
  • I nnovez ensemble
  • C ommuniquez

Cette présentation aboutit à l’introduction d’un manuel anti-sabotage en cours de rédaction par la principale concernée et disponible sur https://www.peps.coach/anti-sabotage/

Les slides et la conf sont aussi présents donc n’hésitez pas à y jeter un oeil !

12h00 : Cobol for ever

Quicky plus fun qu’instructif tout en musique 🙂

13:20 : Du sang, des larmes et des pixels

Retour en toute transparence d’un entrepreneur entre ses heures de gloire et de difficultés. Très intéressant également.

14:10 : “Full remote comment réussi à travailler en équipe”

Nouvelle porte close sur le premier quicky ciblé “Les 10 incohérences dans les langages informatiques”, donc place à “Full remote comment réussi à travailler en équipe”

Dès le départ, Lise Quesnel pose les bases du cliché du télétravail et met en avant les principaux risques que j’avais également subi (les 2 premiers en tout cas) en tant qu’autant entrepreneur notamment : 

  • Risque de solitude
  • Equilibre perso et pro
  • Perception

Sa réponse : la confiance et la communication

Parmi les usages partagés sur son full remote chez Zenika, ce que j’aurai à relever et à tester : 

  • un hello Slack : où comment saluer tout le monde à son début de journée comme on le fait communément au bureau. De la même façon un petit mot en fin de journée avec un emoticon à l’image du sentiment de comment s’est passé cette journée
  • en complément des outils déjà utilisés pour ma part (Slack, Bitbucket, Jira), différents outils type tableau blanc ou espace de travail collaboratif pour les visio conférences : à tester ! 
    • Miro 
    • Whimsical
    • Mural

14h30 : Introduction à JHipster

Ayant déjà participé à une telle présentation pour une version antérieure de JHispter, il s’agissait pour moi d’un petit refresh de ce projet open source qui reste assez fort de par sa communauté et évolution du produit; bref un bon point de départ pour un projet from scratch d’après moi

15h40 : Comment j’ai arrêté les boucles for

Finalement le talk qui m’a le plus intéressé et envie d’approfondir pour la suite côté dev! 

Ou comment même un dev 100% java peut nous faire entendre y gagner en faisant le choix de s’orienter vers la programmation fonctionnelle.

Le gros avantage présenté ici est l’utilisation conjointe de Kotlin (tout de même défini ici comme “du Java aux amphétamines avec du fonctionnelle dedans“) et Arrow une librairie permettant d’intégrer facilement les concepts mathématiques liés à la programmation fonctionnelle

Par un exemple concret et code source à l’appui, Ghislain Mahieux nous partage progressivement ce qui pourrait nous laisser abandonner les boucles for donc et l’usage de lamdba Java …

Et pour reprendre le bilan de son expérience, tous les signaux semblent au vert : 

  • Lisibilité : code plus concis via les Extensions functions
  • Fiabilité : plus de NPE, – de code donc – de bugs
  • Maintenabilité : sealed class / extensions functions
  • Progressivité 

et l’équation idéale :

Meilleure gestion des effets de bords + Meilleure maintenabilité + Meilleure lisibilité = + de confiance dans le code

Cela mérite donc de potentiellement essayer pour un besoin pouvant y prétendre 😉

Le support de la présentation est partagé ici .

16h40 : N’ayez pas peur de refactorer vos APIS

Une autre conf intéressante vis-à-vis de l’utilisation de Pactflow qui pour moi se glisse dans la pyramide de tests entre les tests d’intégration et tests automatisés.

Le but recherché ? S’assurer immédiatement des impacts de montée de version d’une API, connaître à l’instant t les versions utilisées et potentiellement se débarrasser des versions obsolètes ! 

17h30 : Carte blanche à Frédéric Leguédois

J’attendais pas mal de cette fin de journée avec cette carte blanche après avoir déjà pu assister à une des célèbres présentations de Frédéric Leguédois  : “Cessons les estimations”.

On aime ou pas le personnage mais effectivement ça balance !

Alors parmi les fausses idées dénoncées et sans tout vous dévoiler : 

  • Cessons de croire que d’accroître les ressources permettent de gagner en rapidité de livraison car : “9 femmes ne peuvent pas faire un bébé en 1 mois“. En augmentant les ressources on peut obtenir plus de fonctionnalités mais pas plus de rapidité

mais encore et surtout

  • Tout ce que l’on fait souvent avant la mise en production est spéculation” ou comment via une autre expérience partagée, Fréderic Leguédois nous vante les mérites et besoins de livraisons itératives et rapides en production – mais ça c’est bien la cible vers où on veut tous aller non? ^^

Et c’est ainsi la tête bien remplie et totalement épanouie de cette journée que j’ai pu finalement clôturer cette journée Codeurs en Seine 2019  sans compter un premier debrief à la volée autour d’un verre bien mérité 😉

A l’année prochaine ! Merci encore @CodeursEnSeine

Leave a Reply

Your email address will not be published. Required fields are marked *