La Devoxx contre attaque
Et c’est parti pour une nouvelle journée de devoxx. Arrivé à 8h15, encore une fois, afin d’être dans l’amphi où auront lieu les keynotes, je pris environ 54 cafés et demi, pour me réveiller (c’est inhumain d’être debout à une heure pareille …).
Direction les 3 premières keynotes de la journée :
Accessibilité
« Accessibilité » par Valérie Haccart, créatrice de la société AlphaSens, dont le but est de sensibiliser à la déficience visuelle. Cette keynote fut extrêmement intéressante. En effet, Mme Haccart nous présenta diverses pathologies visuelles, à l’aide d’un diaporama, pour la majorité d’entre nous et de lunettes reproduisant ces pathologies pour 4 personnes choisies parmi les bénévoles Devoxx et une personne du public. Elle nous rappela, de plus, quelques règles devant être respectées lors du développement de pages html, en nous faisant entendre ce que lisait son lecteur d’écran. On notera ainsi :
- Toujours ajouter une balise alt sur une image (avec du contenu)
- Respecter l’ordre des titres (ne pas passer directement de h1 à h4, changer le css plus tôt sinon la personne lisant le code html pourrait se dire que son lecteur d’écran a sauté des lignes)
- Commencer chaque page, en précisant la langue, sinon le lecteur pourrait lire la page en anglais, ce qui rend le résultat assez incompréhensible.
Phylosophy of HumanOps
« Phylosophy of HumanOps » de David Mytton, VP, Product Engineering pour StackPath. M. Mytton a lancé la communauté HumanOps, dont le but est de produire des évènements, permettant de discuter comment gérer le côté humain dans les systèmes informatiques (stress, fatigue, …). Dans cette keynote, M. Mytton nous présenta le concept de humanOps et comment il était possible de l’intégrer dans notre monde aujourd’hui. Il commença par nous définir la manière dont était souvent perçus les Ops ou devOps, dans nos sociétés aujourd’hui … Comme des super héros. En effet, on appelle souvent ces personnes à n’importe quelle heure pour corriger un problème serveur (« Hello IT. Have you tried to turn it off and on again ? »). Cependant, ce genre d’appel affectent ses personnes sur leur vie personnelle. C’est pourquoi il est à présent nécessaire de penser à l’humanOps, en suivant plusieurs principes parmi lesquels :
- Les humains doivent dormir
- Le bien-être a un impact sur le système informatique
Il termina son propos par une phrase qui est, à mon sens, extrêmement pertinente « Pourquoi dépenser de l’argent dans de l’équipement, s’il nous est impossible d’investir autant dans les gens qui utilisent cet équipement ? »
Le refactoring le plus difficile de ma carrière
« Le refactoring le plus difficile de ma carrière » par Jérôme Petazzoni, développeur multi casquettes qui a notamment participé à la conception et à la popularisation de Docker. Cette keynote fut pour moi, l’une des plus compliquée à appréhender tant j’avais l’impression que M. Petazzoni se mettait à nu devant nous, en nous contant la dépression et le « burn out » qu’il a pu subir, dans le but de nous prévenir des risques sur la santé mentale, dans notre métier. Ainsi, il nous fit un descriptif de l’évolution de sa maladie au fur et à mesure des années, en nous décrivant les différents symptômes qu’il eut (manque de sommeil, énervement, anxiété …), ainsi que les médicaments qu’il put prendre, afin de la combattre. Il nous rappela quelques points qu’il me semble important de transmettre :
- Aujourd’hui, 1 français sur 5 souffre d’un trouble mental.
- La dépression ou le « burn out » sont des maladies. Il est donc normal et important d’en discuter, de voir un médecin et potentiellement de prendre des médicaments (après avis médical) concernant ces problématiques.
- Faire une dépression ou un « burn out » ne fait pas de nous quelqu’un de « faible ».
Voici le lien pour les slides de cette keynote qui, à mon sens, était la plus percutante de la Devoxx France 2019.
Méthode et analyse des tests de performance d’une API dans le continuous delivery
Une fois cette keynote finie et mon mortal à 0 (on ne va pas se mentir ce n’était pas la keynote la plus joyeuse de tous les temps), direction la conférence « Méthode et analyse des tests de performance d’une API dans le continuous delivery » de Sergio Lema développeur Java pour la société Ekino. M. Lema, nous posa plusieurs problématiques de test, en nous présentant un projet développé par sa société. Pour cela, il nous indiqua plusieurs questions que lui et son équipe s’étaient posées pour la réalisation de cette application et les manières dont ils mirent en place les tests correspondants. Ainsi, leur problématique principale étant la mise en place d’une application performante (de nombreuses requêtes pouvaient être appelées conjointement). Ils se demandèrent comment mesurer cette performance et réaliser les plans de tests.
La présentation était, à mon sens, inadéquate comparée au titre. En effet, plutôt que de nous indiquer les principes généraux de la mise en place de tests de performance dans un cycle d’intégration continue, M. Lema nous présenta plus ce qu’ils avaient utilisés comme technologies (JMeter, GnuPlot …) et leur cheminement de pensées pour arriver à leur résultat final. C’est pourquoi, je ne pense pas que cette conférence fut la plus intéressante de la Devoxx. Néanmoins, elle m’apporta quelques questionnements concernant la mise en place de mes propres tests de performance dans mes applications.
Projet STAMP
Bon, la dernière conférence m’avait un peu déçu, mais la suivante releva largement mon niveau d’intérêt. Mme Caroline Landry, responsable technique du projet STAMP dans l’équipe DiverSE, de la société INRIA. Elle travaille à la fois comme architecte logicielle et chef de projet (oui ça donne un peu le tournis tout ça …). Dans cette conférence, nous avons eu droit à une présentation du projet STAMP dont le but principal est l’amélioration des tests écrits par les développeurs. Comment ? Tout simplement, en analysant le code des tests écrits et en proposant au développeur des nouveaux tests, en mutant les précédents. Pourquoi ça ? Tout simplement pour éviter, dans le cas où le code était modifié, que les tests ne fonctionnent plus.
Plusieurs problèmes se posent toutefois :
- Le nombre de tests générés pouvant être important, la consommation d’exécution des tests augmente de manière drastique
- Il est compliqué au bout d’un certain moment de différencier les tests mutés des tests originaux.
Pour résoudre ces problèmes, un autre concept a été mis en place, celui de l’extrême mutation.
Mme Caroline Landry nous présenta deux autres projets « Pit » et « Descartes », permettant la mutation extrême de tests.
Vous pouvez retrouver le github de Descartes.
Et le projet STAMP.
3 techniques faciles de manipulation
Après cette conférence qui me laissa (et c’est peu de le dire, ébahi et avec des étoiles dans les yeux), direction le repas et un quickie. Pour ce petit instant de découverte et de détente, direction « 3 techniques faciles de manipulation » par Mme Marie Viley, recruteuse chez Zenika.
J’allais à ce quickie avec enthousiasme, car il faut avouer, ce n’est pas un sujet que nous abordons tous les jours dans notre métier. De fait, je ne fus pas déçu, même si je connaissais déjà les techniques de manipulations présentées :
L’engagement et la cohérence : cas d’un vendeur de voiture (par exemple), posant pleins de questions auxquelles nous répondons « oui », afin de nous faire accepter son offre par la suite.
La règle de la réciprocité : cas du donnant-donnant. Règle que l’on peut retrouver lorsqu’on nous offre un cadeau, alors que ce n’était pas prévu, cela nous engage alors à offrir quelque chose en retour.
La règle de la preuve sociale : on retrouve cette règle dans le commerce, lorsqu’on nous dit que tel produit est « élu produit de l’année », cela nous incite ainsi à l’acheter puisque « tout le monde le fait ».
Il est toutefois important de rappeler que toutes formes de manipulations n’est pas négative. En effet, une manipulation peut être utilisée pour demander de l’aide à un collègue.
Votre API web passe-t-elle les 50 points du contrôle technique ?
Une fois ce quickie terminé, direction la conférence « Votre API web passe-t-elle les 50 points du contrôle technique ? » par François-Guillaume Ribreau, architecte et chef du développement numérique chez Ouest France, fondateur et CTO de ImageCharts. Dans cette conférence, M. Ribreau nous présenta plusieurs points à valider pour pouvoir affirmer que son API est correcte, sécurisée, performante, documentée, versionnée … Parmi ces points, il nous indiqua lesquels étaient à valider :
Avant le développement :
- Etablir les objectifs clairement (Service Level Objectives – Service Level Indicators – Service Level Agreements)
- Définir les noms des services
Pendant le développement :
- Mise en place du versionning
- Vérifier si des notions telles que la pagination sont nécessaires
Après le développement (avant la production) :
- Limiter le nombre de requêtes
- Mettre en place des alertes et des métriques
- Mettre en place la documentation
Cette conférence a soulevé de nombreux points techniques qui m’ont directement amené à réfléchir sur mes API et sur le nombre de points qu’elles respectent.
Micronaut, Dragon-Slayer (SpringBoot) or just another framework
Direction ensuite : « Micronaut, Dragon-Slayer (SpringBoot) or just another framework » de Vladimir Dejanovic, Architecte logiciel et leader technique. Le but de cette conférence était de présenter Micronaut en posant la question suivante « Micronaut est-il une alternative viable à Spring ? ». Il est important de préciser que M. Dejanovic n’est pas affilié, de quelques manières que ce soit, à Spring ou à Micronaut. Ainsi la présentation qu’il a effectuée ne contenait que ses propres remarques et questionnements. Afin de comparer les deux frameworks, il créa un logiciel simple contenant web service, service, dao et compara les temps de compilation, de lancement et l’écriture du code entre les 2 frameworks. Il en conclua que les 2 frameworks étaient valables et que :
- Sur un logiciel existant il n’était pas nécessaire de passer à Micronaut
- Sur un nouveau projet il fallait envisager ce framework comme alternative à Spring
Aussi efficace à la maison qu’au bureau
Afin de changer un peu du développement, je décidais de partir pour la conférence « Aussi efficace à la maison qu’au bureau » de Jean-Laurent de Morlhon, directeur de l’ingénierie chez Docker. Le but de cette conférence était de nous présenter le télétravail et comment celui-ci pouvait être organisé. Cependant, à mon sens, cette conférence traita plutôt de comment était organisé le télétravail chez Docker et bien que quelques idées étaient intéressantes, la grande majorité de la conférence m’a fait penser à une publicité pour la société Docker. Ce fut pour moi, la conférence la plus décevante de cette Devoxx 2019.
Que se passe-t-il sous le capot ? Exploration au cœur de la JVM.
Bon après cette petite déception, je sautais sur l’occasion de refaire un peu de Java, en allant à la conférence « Que se passe-t-il sous le capot ? Exploration au cœur de la JVM. » de Sylvain Wallez, architecte, développeur et leader technique chez Elastic (oui oui la société qui produit Elastic Search …). J’étais, je dois l’admettre, quelque peu impatient. A la sortie de la conférence je sentais qu’un mal de crâne m’attendait, mais qu’à cela ne tienne !
Nous avons ainsi pu voir différents points dans cette conférence :
Identification des problèmes de mémoire possible en Java Les fuites de mémoire Trop de pression sur le garbage collector
Exemple d’un problème de mémoire récurrent causé par un comportement du jdk (boucle sur un Enum.values())
Apprentissage de la lecture du byte code
Présentation d’outils utiles : jmap et java flight recorder
Bingo, à peine la conférence finie le mal de tête a pointé le bout de son nez, mais cela valait totalement le coup !
Comment se faire hacker bien comme il faut !
Il était temps de clore cette Devoxx, par une dernière conférence et je choisis « Comment se faire hacker bien comme il faut ! » qui fut pour moi, la conférence PARFAITE pour terminer cette Devoxx. Cette conférence fut présentée par Julien Topçu, Lead Developer à la société générale.
M. Topçu nous présenta différentes failles techniques des API webs de manière humoristique, en imaginant 2 personnes « Candide » et « Pangloss » réalisant un site web de ventes de livres. Il nous présenta ainsi les failles techniques les plus communes en nous faisant participer, puis il nous expliqua, bien entendu, comment les éviter. Il nous raconta quelques histoires récentes de sites web et sociétés s’étant faits pirater en nous rappelant que personnes n’étaient à l’abri et que pour cette raison, la sécurité devait toujours être une part importante de réflexion dans nos développements. Parmi les failles présentées, nous vîmes ainsi :
- L’injection SQL
- Le Cross Site Scripting
- Les failles CSRF
- Les failles sur les XML External Entity
Ainsi se termina, pour moi, cette Devoxx 2019. Elle fût extrêmement enrichissante, tant d’un point de vue technique sur les nouvelles technologies, que sur les questionnements qu’elle me permit de me poser sur mes applications existantes. J’espère que ces 2 articles vous ont permis de vous intéresser à quelques sujets et que je vous ai convaincu de la richesse culturelle et intellectuelle de la Devoxx.
En espérant également que vous vous décidiez à aller à la Devoxx, moi en tout cas, j’y retourne l’année prochaine sans faute !
