Retour sur le Mix-IT 2016 – Jour 1
La sixième édition du Mix-it a eu lieu le 21 et 22 avril dernier dans les locaux de l’école CPE de Lyon. Avec plus de 600 participants, des conférences autour de l’agilité, des technologies mais également des talks « aliens », c’est l’événement lyonnais à ne pas manquer ! Retour sur cette édition 2016 !
Pédagogie et Agilité
Keynote d’ouverture – Christian DEN HARTIGH
Pour cette première Keynote, M. DEN HARTIGH est venu nous parler de ses 6 dernières années en tant que professeur de français dans un collège de ZEP. Devant se confronter à de jeunes élèves, ce professeur a mis en place sa propre méthodologie : un mélange d’agilité et de biomimétisme.
Le management est la pédagogie pour adulte. La pédagogie est le management pour enfant.
Ce professeur utilise Kanban pour contrôler les flux durant son cours. Il gère ainsi l’information sur laquelle les élèves doivent se concentrer. Le programme scolaire, synthétisé comme un backlog, est affiché au mur sous forme de frise chronologique.
Le biomimétisme intervient lorsque par exemple, il organise sa salle de classe en forme de cellule : c’est à dire en cercle. Au centre du cercle se trouve le noyau de la classe : un bureau où les élèves peuvent emprunter des livres ou des documents pour travailler. Le professeur ne dispose pas de bureau attitré et se déplace parmi les élèves. Tout cela permet de favoriser les échanges et la collaboration « formateur-apprenant ».
Une des valeurs du manifeste agile est de mettre en avant l’esprit d’équipe plutôt que la réussite personnelle. C’est ainsi que beaucoup de travaux dans la classe sont réalisés en groupe. Aussi, les groupes sont mélangés tout au long de l’année et les élèves sont libres de butiner auprès des autres groupes durant ces activités.
En ce qui concerne les retours faits aux enfants, il n’y a pas de punition. Le professeur distribue des smileys pour signifier son acquiescement ou sa réprobation. L’apprentissage avec les enfants passe beaucoup par les émotions. C’est ainsi que pour gérer la colère des enfants, sont affichés au mur des « papiers de colère ». Les enfants sont libres de venir arracher le papier, le froisser et le jeter pour se calmer.
Il s’agissait de la première keynote de la journée et elle fût riche en information. On y a rencontré un professeur passionné qui possède une réelle envie d’enseigner à ses élèves . C’est vraiment impressionnant d’entendre un enseignant qui a concilié méthodologie agile et pédagogie. Une réelle bouffée d’air frais dans un milieu soit disant rigide. Je crois pouvoir dire sans me tromper qu’on aurait tous rêvé d’avoir un enseignant comme M. DEN HARTIGH durant notre scolarité.
Pour plus d’informations sur toutes ses méthodes, n’hésitez pas à consulter son blog : pedagogieagile.com.
La confiance en soi, ça ne sert à rien
Keynote d’ouverture – Laure JOUTEAU
Laure JOUTEAU est une jeune femme créatrice de l’entreprise Les Aventurières. C’est une entreprise spécialisée dans l’aide à la reconversion professionnelle. Durant cette keynote, Laure nous fait réaliser que la confiance en soi ne sert à rien ! La confiance que l’on a n’est que le fruit de projets et de réalisations du passé.
On acquiert cette confiance par ses réussites et ses échecs, mais en aucun cas il ne s’agit d’une bonne boussole pour nous guider vers de nouveaux projets. Cette dernière aide à sortir de sa zone de confort pour se lancer et réaliser ces rêves.
Ce fût une keynote vraiment très inspirante et qui m’a personnellement beaucoup fait réfléchir sur mes projets professionnels et personnels. L’auteur a écrit un article pour détailler son allocution que vous pouvez retrouver ici.
https://twitter.com/LesAventurieres/status/723048591082795008
Kotlin, Ready for production
Hadi HARIRI, développeur advocate à JetBrains est venu nous présenter Kotlin et répondre à ces questions : pourquoi Jetbrains a eu besoin de créer un nouveau langage ? Pourquoi un langage de la JVM ? Et comment fonctionne-t-il ?
Pour créer ce langage, les développeurs de Jetbrains se sont inspirés de beaucoup de langages existants : JAVA, Javascript, Grooy, C#, Clojure, etc, et ont voulu en extraire le meilleur sans les inconvénients. Ils ont eu le besoin d’un langage concis, expressif, fonctionnel et « toolable » avec un impératif : celui d’être un langage de la JVM, celui d’être interopérable. En effet, JetBrains maintient un nombre importants de projets écrit en JAVA. Par contre, ils n’ont pas pu sélectionner le langage Scala car il présentait, à l’époque, des problèmes de performance et était difficilement « toolable ».
Suite à cette brève présentation de Kotlin, M. HARIRI s’est lancé dans une démonstration présentant les points forts de Kotlin. Pour en savoir plus, je vous invite à lire cet article qui décrit l’utilisation de ce langage.
Enfin, Kotlin est un langage dont la finalité pour JetBrains n’est pas d’être vendu ni commercialisé. Il a été crée pour vraiment faciliter les développements au sein de JetBrains. Fort de ses atouts, Kotlin provoque un réel engouement et dispose d’une communauté très active. À mon sens, ils ont réussi à créer un langage qui donne vraiment envie et avec une faible courbe d’apprentissage.
Du Reactive Rx-Like pour Java 8 et plus ? V’la Reactor 2.5
La programmation réactive fût un des thèmes récurrents de cette première journée avec plusieurs conférences sur le sujet et un atelier. Mais qu’est ce que c’est ? On associe souvent la notion de réactivité à une architecture « event driven architecture ». On trouve également le Reactive Manifesto qui définit les qualités d’un système réactif : résilient, disponible, souple, orienté message, etc. De plus, c’est un mode de programmation où les traitements sont réalisés de manière asynchrone et non bloquant, à la différence de la programmation impérative.
La programmation réactive impose de modifier sa façon de penser et de concevoir le code. Elle n’est pas à appliquer dans tout les cas mais l’on peut citer par exemple les cas où elle est fortement recommandée :
- Microservices,
- Big Data,
- Développement Mobile / IoT,
- Interface UI.
Le projet Reactor se base sur Reactive Streams, une spécification pour la gestion des flux de données asynchrones et avec une gestion non bloquante de la backpressure. C’est le fait que l’observé émet plus rapidement des données alors que celui qui l’observe ne peut les consommer. Ainsi, le standard Reactive Streams permet de contrôler le flux de données en donnant la main à l’observateur pour signifier à l’observé qu’il est prêt et en indiquant également le montant de données qu’il peut consommer. On parle d’élasticité du système en opposition à la scalabilité.
Le projet Reactor est la quatrième génération d’API Reactive basé sur Reactive Streams. Il introduit deux Publishers : Flux et Mono. Flux permet l’envoi de 0 à N éléments tandis que Mono permet de simplifier l’envoi de 0 à 1 élément. Pour mieux comprendre ce que sont les types réactifs, je vous invite à consulter cet article qui les décrit dans le détail.
De plus, une nouvelle aussi excitante qu’intéressante est que Spring travaille sur l’intégration du projet Reactor pour sa version 5. Il existe le projet Spring reactive qui permet à l’équipe d’expérimenter son support. Un des exemples de conversion couramment montré est celui du Controller Spring MVC manipulant un Repository :
@RestController
public class UserController {
private BlockingRepository<User> repository;
@RequestMapping(path = "/save", method = RequestMethod.POST)
public void save(@RequesBody List<User> users) {
repository.save(users);
}
}
public interface BlockingRepository<T> {
void save(List<T> elements);
Iterable<T> findAll();
}
@RestController
public class UserController {
private ReactiveRepository<User> repository;
@RequestMapping(path = "/save", method = RequestMethod.POST)
public Mono<Void> save(@RequesBody Flux<User> users) {
return repository.save(users);
}
}
public interface ReactiveRepository<T> {
Mono<Void> save(Publisher<T> elements);
Flux<T> findAll();
}
On voit que l’ensemble des traitements est non bloquant puisque l’appel et la réponse du Controller passe par des Flux, mais aussi l’appel à la couche de persistence avec le Repository.
Pause repas
La communauté du goût nous a offert un repas succulent, équilibré et servi dans les plus brefs délais. Bravo !
Cet appétissant buffet de produits SlowFood vous sera servi par La Communauté du Goût de 12H10 à 13H10 #mixit16. pic.twitter.com/R45h4cvNxQ
— MiXiT (@mixitconf) April 21, 2016
Silver Bullet Syndrome
Hadi HARIRI
Une conférence très amusante et très dynamique sur le « hype driven development » : attitude que peuvent avoir certains développeurs a vouloir utiliser la technologie « à la mode ». Ainsi, une « silver bullet » désigne le dernier framework, la dernière librairie, la dernière architecture qui va solutionner les problèmes actuels du développeur.
I'll keep saying this … if people can't build monoliths properly, microservices won't help. #qconlondon #DesignThinking #Modularity
— Simon Brown (@simonbrown) March 4, 2015
Le speaker revient par exemple sur l’engouement que peuvent susciter les microservices aujourd’hui. Il donne aussi comme exemple l’évolution des solutions de persistance. Nos couches de persistances « maisons » se sont vues remplacées par des ORM tel que Hibernate. Ces derniers eux-même délaissés par des architectures CQRS.
Mais attention, car à toujours vouloir être à la pointe et penser que la nouvelle solution va résoudre magiquement nos soucis, les développeurs ne pensent pas aux coûts que cela va engendrer ni même au contexte d’utilisation. Sans oublier qu’une solution, aussi « hype » soit-elle, apporte également son lot de problématiques.
There is no silver bullet.
Lightning talks
Bots, Bots everywhere!
Johan POIRIER
Johan POIRIER est venu nous montrer comment l’utilisation de robots dans le chat de son équipe leur facilite la vie au quotidien. Ils utilisent des robots pour alerter sur les revues de code en cours, l’état des build dans Jenkins, pour des rappels d’événements, la surveillance des serveurs, lancer un déploiement, etc… Les possibilités sont multiples et rien n’empêche d’intégrer son propre robot !
Ligue de défense des langages délaissés : Développeurs, stoppez la maltraitance du script !
Un cri d’alerte est lancée par Angélique HENRY : « Développeurs, pourquoi accordez-vous un traitement de faveur à certains langages ?! » Angélique est venu nous rappeler qu’il faut prendre soin de tous les langages de programmations, qu’il s’agisse d’un langage de haut ou de bas niveau. On voit trop souvent des classes java documentées, commentées, fournissant des logs, testées, etc… mais trop peu de scripts shell, de dockerfile ont droit à ce genre de traitements. Ce n’est malheureusement pas dans nos habitudes de développeurs et dans un contexte où le DevOps prend de plus en plus de place, cela doit changer!
MeteorJS : end javascript fatigue !
Un lightning talk qui n’a malheureusement pas eu lieu à mon grand regret.
Robots attack
M. JEHL est professeur de SVT et un jour, il a décidé de construire son propre robot. Cela a démarré par la conception des pièces et leur l’impression 3D. Puis, pour articuler son robot, il du mettre en place des moteurs et une intelligence pour les contrôler. Il s’est notamment servi de poppy pour mener à bien cette dernière étape.
Ce professeur s’est auto-formé pour la création de son robot. Fort des ressources disponibles sur internet et des communautés prêtes à répondre à ces questions, il a mené à bien son projet. Il a énormément appris de cette expérience et a réussi à nous communiquer son sentiment de satisfaction. En ce qui me concerne, j’ai trouvé qu’il s’agissait d’un lightning talk vraiment boostant où l’auteur nous a partagé son envie et sa passion pour son projet.
Kanban : un vivier d’options
Une conférence basée sur 3 REX où le speaker est intervenu en que tant coach agile. Pour chacune de ces expériences, le point de départ était différent, mais aussi l’appropriation de la méthodologie et donc les enseignements a en tiré également.
Le premier retour était celui de 3 équipes avec un pôle de développement de plus de 200 personnes et un projet en cours depuis plus d’un an. Ces équipes ont découvert Kanban par la pratique, par des jeux et ont totalement fait peau neuve de leurs anciennes pratiques. Ce qui fût en réalité une erreur puisque Kanban n’est pas une révolution et ne remplace pas une méthode de travail existante. Par contre, ces équipes ont su gérer le flux et limiter l’encours. Elles ont par exemple contraint le travail en entrée du système. Cela a très bien marché et a permis d’éviter la rupture de charge.
Le second retour était celui d’une équipe de 10 personnes, déjà ancrée dans un contexte agile avec la méthodologie SCRUM. Cette équipe avait une réelle volonté de s’améliorer et particulièrement sur les parties engagement, planification et estimation des tâches. Ils ont notamment utilisé le CFD : Cumulative Flow Diagram ou le diagramme de flux cumulé. Il permet de visualiser l’écart entre le reste à faire, le travail en cours, et celui terminé. Cela leur a permis de se lancer dans un engagement sans estimation. Sans pour autant délaisser la planification du sprint, l’engagement sur les tâches est simplement découpé en « oui, nous allons le faire », « peut-être » et « non ». Le « peut-être » leur permet d’avoir du mou dans la constitution du sprint et par conséquent de promettre peu mais de livrer beaucoup.
Enfin, le dernier retour d’expérience a été celui d’une agence web de 50 personnes avec 200 projets. Cette dernière a découvert Kanban autour d’un Brown Bag Lunch et a voulu se lancer. Ils ont tout d’abord démarré par un atelier Value Stream Mapping pour mettre à plat leur processus de travail. Cela a révélé qu’ils avaient en réalité deux processus, deux typologies de sujets et non un comme ils le supposaient. En visualisant de cette façon leur processus, cela a engendré une meilleure collaboration dans l’entreprise puisqu’ils ont su distribuer des rôles mieux ciblés. Un gros point négatif fût la mesure de leur performance qui était uniquement basée sur la productivité individuelle. Les managers se sont rendus compte grâce au Jeu des prénoms que la rupture de charge individuelle n’est pas un mal à la performance. De ce fait, ils ont mis en place des KPI (Key Performance Indicator, ou Indicateur clef de performance) pour mesurer la performance des processus.
Pour conclure, ce fût une présentation vraiment intéressante avec un orateur qui maîtrise son sujet. Étant friand de méthodologie agile, j’ai beaucoup appris grâce à ces REX. Je trouve qu’il est important en tant que développeur, en tant qu’équipe de savoir se regarder, se mesurer et ainsi s’améliorer.
Les supports de cette présentation sont disponibles ici.
A lite Rx API for the JVM
Stephane MALDINI
Un atelier qui fait suite à la présentation de Reactor. Il s’agissait de manipuler les deux principales classes du projet Reactor : Flux, Mono. Grâce à une classe TestSubscriber permettant d’évaluer les données qui sont échangées, les différents exercices des TP consistaient à créer des flux ou des mono.
Dans l’exemple ci-dessous, un Flux est créé à partir d’une liste de chaîne de caractères. La classe TestSubscriber s’assure ensuite des données échangées en s’abonnant au flux et en requêtant ces dernières.
@Test
public void fromList() {
Flux<String> flux = fooBarFluxFromList();
TestSubscriber<String> testSubscriber = new TestSubscriber<>();
testSubscriber
.bindTo(flux)
.assertValues("foo", "bar")
.assertComplete();
}
Flux<String> fooBarFluxFromList() {
List<String> list = new ArrayList<>();
list.add("foo");
list.add("bar");
return Flux.fromIterable(list);
}
Les sources de ce TP sont disponibles à cette adresse.
Tim Urban’s Keynote on AI
Tim URBAN
La première keynote de fin fût un peu spéciale car Tim Urban s’est exprimé pour nous en direct de New-York!
Il nous a présenté sa vision de l’évolution de l’intelligence artificielle : une vision où l’intelligence des ordinateurs grandit de manière exponentielle et où elle surpassera bientôt celle de l’Homme.
Et c’est là où Tim Urban s’interroge : que va-t-il se passer lorsque les robots auront une intelligence bien supérieure à celle de l’homme et qu’ils seront devenus totalement autonome ? La question reste entière.
Si vous désirez en savoir plus, vous pouvez retrouver son article de blog ici.
Recette pour parvenir à donner une conférence sur les embryons de manchot à Mix-IT
Pour terminer cette première journée, Marie Manceau, chercheuse au Collège de France, nous a présenté comment elle a conjugué vie privée et vie professionnelle au travers d’un voyage en Antarctique. Les hasards de la vie, les rencontres, font qu’elle est parvenue à réunir son amour pour le continent Antarctique et ses recherches fondamentales sur l’implantation des plumes des manchots. Ce fût une keynote tout simplement passionnante ! On a eu droit à des explications sur qu’est ce que la recherche embryonnaire. Le tout illustré par des photographies de son voyage en Argentine et d’une vidéo du Passage de Drake pour rejoindre l’Antarctique. Marie Manceau a réussi à me donner envie de voyager jusqu’en Antarctique et d’affronter le froid polaire !
En conclusion, ce fût une première journée vraiment géniale ! C’est l’occasion de retrouver ses amis, d’apprendre énormément, de partager, d’échanger, etc … On coupe avec le train-train quotidien et l’on découvre des choses vraiment rafraîchissantes.
