Le vendredi 6 mars 2020, je me suis rendu à la cinquième Unconférence de Lyon organisée par la communauté HackYourJob.
C’est quoi une Unconférence ?
Une Unconférence c’est une conférence dans laquelle tout le monde est à la fois participant et animateur. Dans une conférence classique, les speakers sont désignés ou choisis en amont, ce n’est pas le cas dans une Unconférence : l’ensemble des participants sont acteurs.
Ça se déroule comment ?
La journée commence par une place de marché, l’idée c’est de proposer des sujets pour une salle et une heure définie :
Le sujet peut être préparé pour le présenter mais ça peut aussi être une base pour apprendre quelque chose avec l'expérience des autres participants.
Ensuite la journée démarre. Chacun peut choisir d’assister aux sujets de son choix et même de changer de salle pendant le créneau.
J’ai proposé à cette occasion un sujet sur la fabrication d’une Pattern Library par la pratique en suivant Atomic Design, n’hésitez pas à lire l’article de blog qui en parle pour avoir plus d’informations sur le sujet.
Veille technologique avec Sylvain Coudert
Ma journée commence par le sujet de Sylvain qui voulait savoir comment faire de la veille technologique alors qu’il a tendance à travailler de plus en plus en remote depuis la campagne et à avoir du mal à prendre le temps, à la fois de suivre ce qui évolue mais aussi de mettre en pratique ce qu’il a vu dans sa veille. Il nous indique que travailler plus loin de la ville complique l’accès aux meetups ou à d’autres événements collaboratifs, ce qu’il pouvait faire plus facilement avant.
Nous avons pu relever des points sur le temps à se dégager, qui n’est pas toujours facile ni adapté à toute situation. Par exemple, j’ai l’habitude de consacrer un peu de temps chaque jour à de la veille technologique, généralement le matin mais c’est plus compliqué pour quelqu’un qui vit dans un contexte familial de trouver du temps à accorder chaque jour.
Nous somme partis sur une idée de consacrer plus de temps à des sujets qui nous passionnent, pour ma part le Design System, pour d’autres CQRS/Event Sourcing et de les restituer sous forme d’articles. L’idée de ces articles est de pouvoir explorer les sujets plus en profondeur et ainsi d’intégrer plus facilement ce que nous avons appris. Le fait de les écrire permet aussi d’ancrer le sujet, ce qui peut être utile lorsqu’on ne peut pas l’appliquer à un contexte de mission, de projet…
Suite à ce point sur les articles, la question de la légitimité revient, “Peut-on écrire un article alors qu’on est pas expert sur le sujet ?”. C’est vrai que parfois, de vieux articles peuvent paraître plus naïfs qu’en réalité et avec le recul, il n’est pas idiot de se demander s’ils ne contenaient pas beaucoup de coquilles.
Peu importe la situation, qu’on soit expert ou non sur un sujet, je pense qu’il est important de restituer ce qu’on a pu apprendre sous forme d’article. Dans la majorité des cas, cela nous aide à mieux connaître un sujet et à l’approfondir. Justement, si plus tard, avec l’expérience, on remarque que l’article diverge de ce qu’on a appris, rien n’empêche d’en faire un nouveau avec toutes les nouveautés et changements à apporter.
Nous avons retenu qu’il n’est pas forcément pertinent de réécrire l’ancien article ni le renier afin de voir l’évolution qu’il a pu nous apporter lorsqu’on en écrit un nouveau sur le sujet.
L’idée des articles a traversé la journée, elle a été abordé le soir durant une rétrospective.
J’ajouterais que, pour ma part, une grande quantité d’informations en terme de veille arrive toute seule jusqu’à moi. Ces informations me proviennent de divers canaux de communications tels que les articles de ce blog, Twitter, Slack, Discord et bien d’autres… Je pense qu’il est intéressant de trier l’informations et de recouper les sources en tenant compte des sujets qui nous semblent les plus pertinents à surveiller. Il n’est pas pertinent de vouloir suivre l’exhaustivité des sujets de l’IT.
Rendre du code testable avec Johan Martinsson
Après cette discussion sur les veilles technologiques, il est temps de changer de sujet et j’ai pu rejoindre Johan dans le salon.
Un exemple de code au tableau, non testé et non testable et c’est parti.
Je me permets un petit aparté sur mon expérience personnelle. J’entend souvent que certaines personnes échouent à tester du code existant. Lorsque je leur demande ce qui empêche de tester leur code, ils me font comprendre qu’il y a des effets de bords partout. Par conséquent leur code est difficilement testable voire pas testable du tout.
Pour revenir au code affiché, un des exemples introduit un effet de bord assez classique, la présence d’un accès à un fichier au sein d’une méthode.
public class UnicodeFileToHtmlTextConverter {
private final String fullFilenameWithPath;
public UnicodeFileToHtmlTextConverter(String fullFilenameWithPath) {
this.fullFilenameWithPath = fullFilenameWithPath;
}
public String convertToHtml() throws IOException {
try (Stream<String> stream = Files.lines(Paths.get(fullFilenameWithPath))) {
return stream.map(StringEscapeUtils::escapeHtml4).collect(Collectors.joining("<br/>"));
}
}
}
Il est courant de rencontrer ce type de code dans notre quotidien : un objet non injectable apparaît comme par magie dans l'exécution d’un code métier que nous voulons rendre testable.
La résolution est pourtant assez simple, votre IDE vous permet d’extraire toute une portion de code afin d’en créer une autre dans laquelle il suffit d’injecter l’objet via un paramètre. Ce paramètre est toujours injecté via la méthode de base, mais maintenant, la seconde méthode ne contient cet effet de bord, il va donc être plus facile d’injecter ce paramètre à travers un test unitaire.
Ça m’a rappelé ce qu’a dit Kent Beck lors de notre passage à Amsterdam pour le DDD Europe avec Colin : “Things always get worse before they get better!” (“Les choses empirent toujours avant de s’améliorer”). En effet, notre code est moins élégant, on a maintenant deux méthodes au lieu d’une seule, mais au moins, maintenant, il devient possible de tester cette seconde méthode.
Après quelques exercices plus complexes, la méthode reste globalement la même, rendre nos méthodes/fonctions le plus pure possible, c’est-à-dire en sortant les effets de bord en dehors de leur exécution.
Ce deuxième sujet permet d’explorer certaines techniques que nous voyons peu dans la plupart des katas, y compris de refactoring, je vous invite d’ailleurs à jeter un coup d’œil à ce dépôt sur GitHub pour vous entraîner à rendre testable votre code.
Gérer son activité (partielle) de formateur avec Éric Siber
De nouveau à la mezzanine, tout comme le premier sujet, mais avec Éric cette fois-ci, sur la gestion de son activité de formateur.
Eric introduit le sujet, à travers son expérience liée aux différents organismes de formation existants par lequel il est passé pour des formations qui durent parfois plusieurs mois. Rapidement, il nous explique que les organismes de formation populaires permettent, entre autres, de viser plus facilement le milieu professionnel puisqu’ils reçoivent des financement de l’OPCA.
Suite à ça il parle de l’activité de formateur au sein de ces organismes qui, bien souvent, imposent des supports existants. Pour l’illustrer, il nous parle d’un support, fait par une autre personne, qu’il a dû diffuser mais avec lequel ses opinions divergent. Les participants de la formation ont même relevé ces points de divergences comme un défaut de maîtrise du sujet présenté.
Après quelques discussions sur le sujet, nous venons à la conclusion que ce type d’organisme de formation essaie de diversifier des sujets de formations à vendre en priorité sur le contenu et la qualité des formations délivrées.
Un autre participant à la session a abordé les formations proposées avec notamment une sur les bases, une autre sur des concepts plus avancés du langage/framework … Il nous disait qu’on lui demandait de ne pas utiliser son IDE pour les formations de base afin d’aborder ce point dans une autre formation.
Nous avons ensuite conclu qu’en tant que formateur, il est intéressant d’avoir une certaine forme de liberté et de qualité pour diffuser les formations, ce qui semble en décalage avec ce que proposent les organismes. La solution serait de trouver un organisme financé lui aussi par l’OPCA pour être référencé par les entreprises qui prennent plus en considération la qualité des formations que ce qu’il se passe aujourd’hui.
Fabrique ta Pattern Library avec Anthony Rey
Je continue par un sujet sur la Pattern Library avec du live coding. Je ne vais pas détailler le sujet ici. Je vous invite à voir la conférence que j’ai donnée au MUG avec Jérémie Tisserand si vous souhaitez plus d’informations sur le sujet.
Thinking in Systems avec Romain Berthon
C’est la dernière conférence, avec Romain Berthon qui aborde la session avec pour support le livre Thinking in Systems de Donella Meadows publié en 2008.
À l’aide d’un feutre pour tableaux, Romain dessine une vision schématique de représentation d’un système avec un flux entrant, le système et son flux sortant. Il indique ensuite qu’il est possible, à travers des boucles de rétroactions à l’intérieur du système d’agir sur ces flux mais qu’il y aura systématiquement un délai pour que le changement s’applique.
Ici nous voyons qu’avec cette représentation du système de régulation de la température d’une pièce il est possible d’influer sur les entrants afin de chauffer ou non la pièce pour qu’elle soit à la température désirée.
Suite à ça, il nous indique qu’aucun système n’est parfait, qu’ils ont tous des limites et que selon les entrants par exemple, le système peut ne pas être en capacité de fonctionner correctement. Pour notre système de température, s’il fait trop froid pour réchauffer suffisamment la pièce, on arrivera à une limite du système tout comme s’il fait plus chaud que la température extérieure par exemple.
Afin de montrer que cette représentation est applicable à des domaines plus complexes, Romain nous propose l’étude de 2001 intitulée “Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement” de Nelson P. Repenning, John D.
Cette étude représente le système de travail au sein d’une entreprise. On peut voir à la page 73, sur la figure 5 le schéma qui reprend l’ensemble des schémas précédents et qui permet de déduire dans la figure 6 que dans ce système, si on travaille plus dur, notre productivité sera plus basse que si on travaille mieux.
Cette vision de la représentation d’un système m’était inconnue avant la conférence et il est assez intéressant d’appliquer ce type de représentation graphique aux différents systèmes existants. Je pense qu’il faut garder cette approche dans un coin pour avoir du recul lorsque quelqu’un propose un nouveau “système”.
Les Unconférences, est-ce que ça vaut le coup ?
Des conférences sans sélection au préalable, ça peut paraître a priori très amateur et très variable en terme de feedback. Pourtant, cette journée était très riche et je regrette de ne pas avoir pu me dédoubler pour explorer d’autres sujets.
Cette méthode permet d’avoir des sujets qui intéressent les speakers et les auditeurs au moment où se fait la conférence. C’est différent dans une conférence classique qui sélectionne ses sujets plusieurs mois avant le déroulé de l’événement. Ces mêmes sujets peuvent déjà avoir été abordés dans des meetups auparavant.
Même si les sujets sont moins peaufinés qu’en conférence traditionnelle, ils ont le mérite d’être abordés avec le recul de chacun, ce qui rend les échanges plus facile.
Pour ceux qui n’ont pas peur d’être surpris par ce qu’ils vont apprendre lors de ce type de conférence, je vous invite à venir sans hésiter. De plus, les sessions sur Lyon se font tous les trois mois et selon les conditions vous pourrez peut-être assister à la prochaine sur le thème du Mob programming en présence de Woody Zuill.
