Keynotes
Les keynotes du matin étaient très intéressantes. Elles portaient sur le métier de développeur, son rôle dans la société d’aujourd’hui et la part qu’il a à jouer dans la révolution numérique que nous sommes en train de vivre. Des sujets tels que la place de la France dans le monde informatique, ainsi que les startups en France étaient également de la partie.
Gradle ne fait pas que remplacer Maven
Cédric Champeau (membre de l’équipe de développement de Groovy chez Pivotal) nous a fait une belle démonstration de ce que Gradle sait faire. Il a bien insisté sur le fait qu’avec Maven, on est vite obligé d’adapter la structure de son projet à l’outil, ce qui n’est pourtant pas logique. Gradle est conçu pour pouvoir prendre la main à tous les endroits du build, si bien qu’en principe il est capable de s’adapter aux spécificités des projets.
Gradle est écrit en Groovy, et c’est bien mieux qu’un énorme morceau de XML très verbeux. Il utilise un DSL pour faire du déclaratif, mais lorsqu’on a besoin, on a accès à toute l’expressivité de Groovy pour par exemple écrire son propre plugin.
Groovy a une gestion des entrées et sorties de chaque tâche très puissante et élégante, et cela lui permet de supporter efficacement et proprement le mode incrémental, ce qui est en effet assez mal géré par Maven.
Connaissant déjà Gradle, je n’ai pas appris grand chose mais cette conférence a bien relancé mes envies de me lancer vraiment à l’assaut de cet outil.
David m’a refactorer
Si j’ai bien compris le but était de montrer comment refactorer une application web s’appuyant sur je ne sais plus quel framework web en 15 minutes, en le migrant sur le serveur HTTP code-story.
Malheureusement, c’est allé bien trop vite, et pour simplifier beaucoup de code compliqué à migrer a été simplement supprimé. Bref, en 15 minutes c’était pour moi trop ambitieux. Dommage parce qu’il y avait sans doute de belles choses à apprendre avec un tel sujet.
PIT, pour savoir si vos tests vous protègent des mutants
PIT est un outil très intéressant. Il a pour but de mesurer la fiabilité de nos tests, autrement dit est-ce que nos tests couvrent correctement notre code. Cela va au delà de la couverture de code.
Prenons un exemple :
public static int sum(int a, int b) {
return a + b;
}
Si ce code est testé par un seul test qui a comme entrées 5 et 0 et qui vérifie que le résultat est bien 5, la couverture de code en terme de lignes est bien à 100%. Pour autant le test n’est pas suffisant pour s’assurer de la fiabilité de cette méthode. Il suffit par exemple de remplacer le + par un – pour changer le comportement de la méthode sans pour autant casser les tests. Dans un tel cas c’est facile de s’en rendre compte, mais quand ça se corse, ça devient plus difficile.
Cet outil est capable d’introduire des légères variations dans le code pour vérifier que cela fait échouer des tests. Le but étant de simuler ce qui pourra se passer dans l’évolution future du code, avec un développeur qui va modifier des lignes d’un code testé, ne casser aucun test et pourtant introduire un bug.
Dans le cas de la méthode sum, il se permettrait par exemple de remplacer l’addition par une soustraction. Le but c’est bien entendu que quand PIT est en train de s’exécuter, des tests échouent. Si aucun test n’échoue, il faut se poser des questions ! Il introduit une métrique complémentaire à la couverture de code qui est le nombre de tests qui ne sont pas sensibles à des changements de code.
Le concept est génial, mais cela pose quelques problèmes de temps d’exécution dans la mesure où il doit exécuter tous les tests après chaque modification. Mais il est intelligent, il se souvient des tests qui testent chaque portion de code et n’exécute que ceux qui correspondent à la partie qu’il fait muter. Il sait également lire les informations d’un système de gestion de sources pour fonctionner en mode incrémental.
C’est pour moi un outil à essayer de toute urgence, d’autant plus qu’il existe des plugins Maven, Gradle et une intégration à Sonar.
Les Applications Réactives : un nouveau paradigme pour relever les défis de l’économie numérique
Cette présentation était faite par Fabrice Croiseaux et Antoine Detante qui animent le podcast nipdev que j’écoute régulièrement. Ils montraient des exemples d’applications réactives, concept qui s’appuie notamment sur la programmation fonctionnelle et asynchrone, voire même événementielle. Ils ont montré des exemples en scala et en Javascript.
Je n’ai pas appris grand chose pour deux raisons. La première étant que j’avais écouté l’épisode de nipdev qui abordait ce sujet, la deuxième étant qu’entre Play Framework et GWT, ce sont des concepts que je manipule plus ou moins au quotidien.
42 IntelliJ IDEA tips and tricks in 45 minutes
Présentation effectuée par un évangéliste de Jetbrains. Un bon orateur qui a fait une présentation dynamique. J’y suis allé parce que j’ai adopté cet outil assez récemment. J’ai découvert un certain nombre de fonctionnalités que je ne connaissais pas. Par contre, ça va un peu vite pour pouvoir noter les raccourcis clavier qu’il utilise. D’autant plus qu’il y a de profondes différences entre les différents systèmes d’exploitation. Les raccourcis restent quand même assez compliqués et visiblement ne fonctionnent pas à chaque fois puisque même lui s’est pris à plusieurs reprises les pieds dans le tapis.
Il a insisté sur le fait qu’il fallait essayer à tout prix de se passer de sa souris, mais pour cela il faut bien maîtriser l’outil.
Chez les barbus: master chef et puppet show
Chef et puppet présentés par deux développeurs Java. Un des deux est vraiment barbu, il mérite sans problème sa place dans le monde des administrateurs systèmes. Présentation dynamique faite avec beaucoup d’humour.
Ils ont mené une présentation d’initiation à ces outils tout en montrant les similarités et les différences entre chef et puppet.
Chef est basé sur une API ruby, c’est également le cas pour puppet mais ce dernier propose un DSL qui permet de s’abstraire quasiment complètement du langage. C’est quand même plus lisible et plus accessible.
J’ai appris pas mal de choses sur le fonctionnement de ces outils, ce qu’ils savaient faire et ce qu’il ne fallait pas leur demander. J’ai compris un certain nombre de choses sur les machines que j’utilise au quotidien et qui sont administrées par l’intermédiaire de puppet.
La révolution Docker
Salle comble pour cette présentation. Elle a commencé par être perturbée par un gréviste avec son casque de chantier, son gilet orange et un drapeau « non ». Il militait contre la virtualisation. C’était simplement Nicolas de Loof qui nous a fait une entrée remarquée. La présentation portait sur le fonctionnement de Docker ainsi que les changements que ce type de technologie va pouvoir apporter.
L’idée est que les développeurs ne livrent plus un exécutable mais une image Docker qu’il suffira de lancer sur la machine de production.
Ludovic Champenois, qui travaille chez Google, a montré comment exploiter Docker sur Google Cloud Platform. Ils sont en train de travailler sur un outil qui permet de déployer une image Docker directement en production. Il a également affirmé que Google s’appuyait depuis le début d’App Engine sur la virtualisation légère, mais que c’est resté un secret pendant de nombreuses années.
Ayant déjà un peu joué au préalable avec Docker, je n’ai pas appris grand chose techniquement parlant, mais c’est toujours intéressant d’avoir la vision de gens qui sont vraiment dans le métier du cloud, chez Google et CloudBees en l’occurrence.
Soyons RESTful avec RESTX
Présentation de RESTX par son créateur. Présentation très brillante, beaucoup de live coding, assez dynamique. Comme il l’a indiqué au début, c’est un outil fait pour simplifier la vie des développeurs. On entend souvent cela au sujet des outils, mais pour une fois c’est vraiment vrai.
Ce serveur REST dispose d’une API simple et puissante. Il propose également une interface d’administration dans laquelle on peut lister tous les web services disponibles, les méthodes qu’ils acceptent, le format des entrées et des sorties, et il propose même un client REST qui permet de les tester manuellement. Mieux encore, il permet même d’enregistrer les tests manuels pour pouvoir les jouer automatiquement !
Comme tous les outils modernes, il propose un rechargement à chaud, un peu de la même façon que le fait Play Framework.
RESTX m’a vraiment séduit, il faudra que je prenne un peu de temps pour m’amuser avec. Il est pour moi un bon potentiel candidat pour rivaliser avec Play Framework qui ne me satisfait pas entièrement.
Une réflexion sur « Devoxx France 2014 – deuxième jour »