Vite, un chtijug !

Et oui, parce que hier soir, encore une fois, il y avait chtijug.

Et encore mieux, une session spécial quickies. Je dois bien avouer que j’ai pensé à un moment proposer un sujet (Wisdom ? RactiveJS ? je ne savais pas trop). Mais mon emploi du temps m’empêchant actuellement radicalement ce genre d’activité, j’ai … laissé tomber.

Heureusement, des présentateurs bien plus motivés et bien plus efficaces que moi sont venus me raconter des trucs sérieux (pendant qu’un vieux fan me glissait des trucs salaces à l’oreille, et réciproquement, si vous voyez ce que je veux dire). Bref …

Webjars

La présentation est téléchargeable sur github.com/awillemant/webjars-prez essentiellement parce qu’elle utilise des webjars pour récupérer reveal.js

Force m’est de reconnaître que le sujet ne m’était pas totallement inconnu … Pour être honnête, au moment où le speaker a expliqué qu’il était facile de demander un novueau webjar, je n’ai pas pu m’empêcher d’expliquer à mon voisin que j’avais déja fait ajouter plusieurs librairies javascript … Vanité, quand tu nous tient.

Cela dit, curieusement, mon voisin n’a pas semblé convaincu alors que, personnellement, je trouve que les webjars sont la seule façon saine de faire du front-end dans Maven (avec Wisdom, bien sûr, que JHipster ou le frontend-maven-plugin ne font qu’essayer de copier grossièrement).

Workflows Jenkins

Bon, je venais principallement pour cette présentation, pour plusieurs raisons

  1.  Je voulais voir le petit Nicolas Géraud (que j’avais connu jeune développeur chez Sogeti) faire le barbu🙂
  2. Le terme me rappelait quelque chose qui m’avait paru vraiment très intéressant
  3. J’avais assez trollé sur twitter

Et j’ai bien cru que j’allais être salement déçu.

La première partie, avec le build pipeline plugin et le parameterized trigger me rappelait des errements que j’avais connu, et qui m’avaient donné l’impression que Jenkins « scalait » assez mal sur les gros projets d’entreprise. Et j’aiv raiment eu peur que Nicolas n’en sorte pas.

Heureusement, la deuxième partie, sur le workflow plugin lui-même, a répondu à toutes mes attentes.

Parce qu’avec ce plugin, au lieu de créer un job jenkins dans un clickodrome d’une esthétique qui sera discutée plus tard, on crée son job avec … Groovy. Et, franchement, vous le savez, si il y a du Groovy, ça ne peut pas être mauvais. Et, en bonus, le job écrit en groovy peut être tiré par Jenkins d’un SCM ! C’est-à-dire que le SCM ne contient plus seulement le POM du projet à builder, mais aussi comment on peut le builder. Si on veut être fou, on peut même releaser le job d’un projet comme un des livrables de ce projet (en termes maven, ça revient à prendre le job dans un dossier sous src, genre src/build/jenkins.groovy). Bref, un outil enthousiasmant, et une présentation rondement menée, puisque Nicolas a exploité avec un certain talent chacune des 15 minutes disponibles.

Et même mon voisin n’a pas fait le grognon, alors qu’il fait du Gradle.

C’est juste dommage que sa présentation ne soit disponible nulle part sur le web🙂

Les CSS pour les moches

Dans cette présentation, Hubert (le faux jumeau officiel de Nicolas) nous donne les bases – et un peu plus – du box model CSS.
Je ne vais pas avoir l’air de négliger cette présentation, parce q’elle était chouette, bien menée, bien remplie, claire, bref, professionnelle. Mais je connais le sujet depuis … 2004, d’après mon Shaarli. Alors je n’ai aps été surpris que je l’aurais pu, mis à part lors de l’irruption inopinée d’un display: inline block;

jmh

Si vous suivez des twittos Java, vous en avez forcément entendu parler.

jmh, c’est l’outil préféré des Rémi Forax et autres fans des microbenchmarks. Pour les développeurs « entreprise », c’est un peu moins important … mis à part à la machine à café. Cela dit, la présentation de Nicolas précisait bien la raison principale de l’existence de cet outil : le fait que la JVM fasse un gros paquet de trucs dans le dos du développeur (que, curieusement, mon voisin connaissait au moins aussi bien que moi – mais je le savais depuis bien longtemps). Bref, intéressant pour les tests exploratoires aux échelles micro.

Personnellement, dans la vraie vie, j’ai tendance à lui préfer contiperf qui

  1. S’intègre dans jUnit
  2. Permet de répondre à la question « est-ce que mon code va assez vite » plutôt qu’à la question « quel code va le plus vite »

Même si jmh tient bien mieux compte des phases de démarrage de la VM.

Testez avec Sérénité

ou plutôt avec Serenity. C’est un outil de BDD qui, d’après ce que j’ai cru comprendre, est une surcouche à JBehave qui ajoute un tas de choses vraiment chouettes. Comme de la coloration syntaxique des scénarios, ou des fixtures vraiment faciles à écrire. Et c’est tant mieux parce que, quand je vois le bazar que ça peut devenir avec Fitnesse, j’ai tendance à me dire que toute autre solution ne peut être que meilleure.

L’idée présentée est donc prometteuse.

Malheureusement, je dois dire que l’effet du stress sur le speaker pendant la session de live-coding (qui lui a fait garder une main dans la poche façon Jamel Debouze, et lui a fait oublier de s’asseoir, ce qui l’aurait sans doute aidé à coder plus vite), m’a un peu agacé, puisque je sentais bien qu’il aurait pu nous en montrer bien plus, si il avait été un peu moins tendu.

J’imagine que ça n’est que partie remise.

Un classement

C’est méchant de me demander ça. Et vous me connaissez, la méchanceté … j’aime ça.

Voici donc un classement subjectif de ces présentations, de la plus frappante à la … moins frappante🙂

  1. Workflow Jenkins, parce que j’étais venu pour ça, parce que Nicolas était clair, et que j’avais plein d’idées à la fin (dont une a déja été envoyée aux bonnes personnes).
  2. Serenity, qui comble un autre vide béant, et pour laquelle je pense que Guillaume devrait, avec un peu d’expérience de ce genre d’exercice, se révéler un chouette speaker
  3. jmh, qui ne correspond pas à mes besoins, et qui n’a pas eu droit à son live-coding … Même si j’imagine très bien que ce soit un peu plus délicat à mettre en oeuvre
  4. webjars que je connaissais déja, et pour lequel le speaker a oublié de parler des différents composants côté serveur permettant de ne pas taper ce trop pénible numéro de version de javascript (de mémoire, Wisdom – évidement – Play Framework, et au moins une implémentation de Servlet spécialement conçue pour raccourcir autant que possible le chemin)
  5. css, parce que même si Hubert est un speaker rompu à l’exercice, le sujet m’a paru .. un peu … désuet ? (à un moment, je me suis même dit que j’aurais préféré revoir le fash 30 vu au bureau sur flexbox). Mais encore une fois, hubert est un chouettte speaker, et a quand même bien réussi son truc

Et encore une fois, c’est un classement totalement subjectif.

Cela dit, j’ai passé une super soirée, merci encore au chtijug.

2 réflexions sur “Vite, un chtijug !

  1. Pingback: #devoxxfr JGiven | riduidel's wordpress

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s