Parmi les conférences transverses françaises, MixIT fait partie de celles offrant et ouvrant un nombre de sujets allant du très technique au très ésotérique. L'édition 2017 n'a pas dérogé au format.
Petite plongée dans les points intéressants vus sur place.
L'orchestre comme modèle de gestion de groupe
Samuel Couffignal a ouvert MixIT17 en amenant plusieurs violons, violoncelles et une contrebasse avec quelques partitions. Sa démonstration - auditive - part d'un morceau joué seulement par les cordes. Le même morceau dirigé par le chef d'orhestre induit un ton différent. Le rôle du chef d'orchestre modifiant sa lecture de la partition est de favoriser le "jouer ensemble", avec un résultat dépassant les individualités.
Il prouve par là, qu'avec des musiciens professionnels, le chef d'orchestre n'est pas une nécessité : ils peuvent travailler ensemble avec un leadership interne (le premier violon). Le leadership peut aussi être externalisé pour donner une autre tendance. L'arrivée d'un membre du public, ne connaissant rien à la direction d'orchestre, construit une nouvelle sonorité. Les musiciens tentent de le suivre, et la sonorité est plus rugueuse. C'est ici la respiration qui devient un élément fondamental de la synchronisation du groupe. L'énergie et le son suivent le leader, qu'il soit dans l'équipe, ou à l'extérieur.
La conclusion est presque simple : le rôle du leader est d'aider à la mise en relation des instruments les uns avec les autres. Ce n'est pas le "je" (l'individualité) qui compte dans le jeu, mais le "nous" permettant de jouer ensemble.
The quest for the ultimate test story
Cet atelier animé par Ard Kramer est un jeu de cartes avec lequel chaque groupe doit partager des histoires réelles autour du test logiciel. Des questions réparties dans cinq catégories permettent de parler d'un cas personnel, pour construire un story telling. Le groupe vote pour deux des histoires. A la fin de l'atelier, les vainqueurs doivent représenter leur histoire. L'applaudissement est la mesure finale permettant de définir le gagnant.
Cet atelier sert à l'échange dans le groupe, ici composé de personnes venant de contextes différents. Ceci permet de partager des pratiques pour les transmettre et les diffuser, un peu à la manière d'un forum ouvert.
Type Theory 101
La théorie des types en informatique est un des domaines les plus abscons, et la base pour juguler les trolls, par exemple autour du "meilleur langage de programmation". Le rôle de la théorie des types est de sortir du jugement de valeur pour arriver à une preuve au sens mathématique, des capacités d'un langage.
En moins d'une heure, Hanneli Tavante parvient à expliquer ce qu'est la théorie des types pour permettre la lecture des équations permettant de juger des intérêts d'un langage par rapport à un autre.
A voir absolument si vous souhaitez une introduction au domaine et changer vos discussions avec vos collègues.
Apprendre à apprendre
Laurent Victorino relate son expérience personnelle d'échec scolaire, et la manière dont il a réussi à le surmonter pour devenir développeur, et aujourd'hui enseigner à des élèves qui sont assez proches de son rapport d'origine à l'école.
Le ton est plutôt acide et en même temps plein d'humour, et laisse voir que l'institution scolaire n'aide pas toujours l'élève à atteindre une position de réussite. En mettant en perspective son parcours, il prône le partage de nos connaissances avec les générations futures, avec des méthodes différentes.
La première est sans doute de prendre les élèves comme ils sont. La seconde est de les responsabiliser. L'expérimentation par la pratique (du code) plus que la théorie, sont pour lui un des vecteurs de cette responsabilisation, qui favorise la réussite.
Il reste cependant objectif : tous ne réussiront pas, et c'est pour ceux qui veulent sortir par le haut qu'il faut se battre.
Legacy Club
Bruno Boucard et Thomas Pierrain viennent reprendre leur activité autour du #LegacyClub, pour réfléchir sur ce qu'est le vieux code avec lequel tout le monde s'est sans doute débattu un jour. D'après eux, il est facile d'expliquer que le code legacy, est la faute des autres. En produisant, nous sommes probablement le code legacy de quelqu'un.
Ils prônent et montrent autour de quelques exemples en live coding que les patterns définis sont des bons points de départ pour faire évoluer et rendre du code évolutif. Les classiques de Martin Fowler, Robert C. Martin et Michael Feather sont à ce titre à lire et à reprendre régulièrement pour savoir reconnaître les "smells" et les moyens d'opérer le refactoring.
ReGen village
Marjolein Shiamatey introduit le second jour de MixIT17 avec la présentation du projet "Regen Village". Le concept, développé par le professeur Erliech, est la construction de communautés autonomes, aussi bien au niveau énergétique qu'alimentaire. L'enjeu est de construire des systèmes fermés, les villages, de 200 habitants environ, dont les déchets d'un cycle (par exemple alimentaire) permettent d'en nourrir un autre.
Ceci passe par la création d'un système d'exploitation de voisinage (NOS, Neighborhood Operating System), basé sur de l'IoT. Si le premier village est en cours de construction aux Pays-Bas, la cible est d'en créer de nombreux qui pourraient communiquer entre eux grâce au NOS.
Spécification en milieu agile
Arnaud Lemaire revient sur un des mythes de l'agilité et du second principe du manifeste agile "Un logiciel qui marche plus qu'une documentation exhaustive". D'après lui, les spécifications sont un processus plus qu'un document, et restent indispensables.
Il existe une divergence dans la conception de ce qu'est une spécification. Le domaine du problème change peu et peut être explicité. Cela peut avoir de la valeur, et elle est faible pour le développeur. A l'inverse, la solution change tout le temps, et la spécifier est souvent une gageure. Finalement, c'est la phase d'intermédiation entre problème et solution qui est intéressante, et c'est le domaine de la spécification.
Il en vient vite à expliquer que la meilleure spécification est un code de qualité, avec un Just Enough Design Up Front. Pour atteindre ce niveau de spécification, il recommande l'usage successif de trois techniques :
- L'impact mapping pour définir le contexte, et éviter de construire du logiciel là où cela n'est pas nécessaire ;
- L'Event Storming pour rentrer dans le domaine métier et comprendre la suite d'événements pouvant être affectée par un logiciel ;
- Enfin le Story Mapping pour aider à construire une feuille de route avec des plans de version.