Mockrunner

Bon, j’imagine que vous connaissez toutes les librairies de mock, mais ça n’est pas de ça que je veux vous parler.

Non.

Supposons que vous développiez une application JavaEE ou équivalent Spring.

Dans cette application, vous allez utiliser des services typiques de JavaEE : du JDBC, du JMS (peut-être), des Servlets. Et dans certains tests, vous allez vouloir mocker ces différents composants pour différentes raisons. Et comme ce sont des choses qui se font assez souvent, et que les APIs sont franchement complexes, l’idée de les recréer avec EasyMock/Mockito/… ne vous emballe pas.

Heureusement, vous pouvez utiliser Mockrunner !

Avec mockrunner, c’est très simple de créer le composant dont vous avez besoin, que ce soit dans du code ou dans des fichiers de configuration Spring. Et ça fait gagner un temps fou.

J’ai bien failli lâcher krissfeed, vous savez …

En ce moment, chaque semaine, je ne sais ni pourquoi ni comment, le fichier data.php se corrompt assez facilement. Et du coup, krissfeed ne marche plus.

Du coup, ça m’a donné une excuse pour faire mon voyage traditionnel dans le monde des lecteurs RSS en ligne. En ligne, parce que je lis mes flux depuis mon portable de bureau, le portable de ma femme, mon ordinateur fixe, et même mon téléphone portable, enfin pas avec krissfeed, puisque les réglages sont partagés entre tous les appareils.

Bref …

J’ai donc jeté un oeil à quelques concurrents

  • commafeed a un look assez sympa, mais certains flux ne se mettaient jamais à jour
  • readerself a l’air chouette, sauf que le paquet de redirections empêche de l’utiliser avec lighttpd (sauf à connaître la syntaxe des redirections dans ce langage, ce qui n’est pas mon cas)

Et puis je suis revenu à krissfeed, qui est juste suffisant pour mon besoin …

Bref, une non-histoire :-)

Un peu d’auto-congratulation

Cet article est exceptionnellement en anglais, mais vous comprendrez vite pourquoi …

Thanks for your article, Rick.

I must confess I’ve not done any support on that library over the last few years …

I must also confess I didn’t wrote that lib for the reason you mention, but rather because using standard commons-VFS webDAV implementation with the webdav servlet I use was … painfully slow.

Anyway, reading such an article is an unbeliveable ego boost. So thanks a lot for your article.

Ce soir, c’est service workers, mais sans moi

Hélas, je ne suis pas au chtijug ce soir, et c’est bien dommage, parce que les service workers, ça m’a l’air bien intéressant. J’essayerai de chopper la présentation d’Hubert demain …

Et pourquoi je n’y suis pas ? Parce que je ferai demain une démo d’une application développée avec Wisdom, JCR, requirejs, Ractivejs, jQuery et Bootstrap. Tout ça a l’air d’une hypitude révoltante, c’est vrai, mais en fait c’est beaucoup plus simple  manipuler que ce qu’on croit. Si je voulais faire un rapide bon/pas bon, je dirais (même si vous le savez déja)

Bons côtés

  • Grosse productivité du live-reload de Wisdom incluant évidement les modifications du Javascript, du HTML, et même du POM
  • RequireJS est toujours aussi pratique pour ajouter des librairies Javascript sans se poser la question de la page dans laquelle ce Javascript est inclus … ou pas.
  • RactiveJS permet vraiment de faire facilement des interfaces modernes (surtout quand les templates Mustache sont chargés séparément via RequireJS).

Mauvais côtés

  • L’implémentation de wisdom-JCR interdit le live-reload. Et même si je suis en contact avec les développeurs de cette extension, c’est vraiment moche.
  • Dans le même ordre idée, avec wisdom, il ne fut jamais mettre un objet Java en cache, parce que quand on le charge après un reload, ce n’est plus le même objet Class, et du coup ça fait tout planter.
  • J’ai eu besoin de générer des images à partir de ppt/pttx. Eh bien curieusement, il n’y a aucune librairie qui ait vraiment le niveau pour faire ça de façon professionnelle.

Les mauvais côtés ont quand même bien failli tuer ce projet. Heureusement, ils ne l’ont pas encore tué … On verra demain soir.

Pas le temps

Pas le temps, pas le temps, je cours tout le temps.

En fait, j’aimerais bien bloguer un peu plus, mais en ce moment, je dois avouer que c’est un peu la course à l’échalotte permanente. Parce que, vous savez, j’ai changé de boulot.

Et le changement n’a pas été que facile.

Parce que le travail de consultant, et plus particulièrement d’architecte, est bien plus complexe que ce que je (et ce que les développeurs en général) croyait. D’ailleurs, il suffit de se demander ce que fait un architecte logiciel … C’est vrai, ça fait quoi ?

En vérité, je n’en sais pas grand chose. La seule réponse que je puisse donner est

Un architecte, ça fait … tout ce que vous imaginez qu’il puisse faire

C’est flou ?

Ca fait de moi le factotum de chaque projet auquel je peux participer ?

C’est vrai, mais c’est aussi tout l’intérêt du poste : se poser des questions inattendues, avoir la possibilité de créer des liens entre différents concepts pour en tirer des applications intéressantes.

Du coup, ça rend un peu d’intérêt au poste, non ?

En fait, ça lui en donne beaucoup, même si ça vide un peu la tête : il n’est pas rare que, le soir, en rentrant chez moi, je ne puisse rien faire de plus intelligent que casser du tank.

Tout ça fait que j’ai un peu moins de temps pour ce blog. Mais, ne vous inquiétez pas, j’y pense encore.

Uploader un fichier en ajax sur un serveur Wisdom

Je pose ça là pour bien être sûr que j’ai bien tout essayé.

Donc, j’ai un scénario assez basique : dans une popup, écrite avec du Ractivejs/Bootstrap, j’ai un formulaire avec lequel je veux pouvoir uploader un fichier sur mon serveur écrit en Wisdom. Facile, non ?

Sauf que pour l’instant, ça ne marche pas.

Tout le code est dans ce gist (que WordPress ne semble vouloir inclure via ses smartcodes)

Le formulaire HTML semble correct. Et le javascript a l’air tout aussi normal.

En bonus, quand je passe en mode debug, j’arrive bien dans la bonne méthode de Wisdom.

Du coup, je jette un oeil à l’onglet network de Chrome, qui me donne ces infos

2015-05-24 10_41_46-p

Et là, si je ne me trompe pas, ça semble vouloir dire (en particulier, par exemple, Content-Length:44) que le fichier que je veux envoyer n’est pas là.

OK, donc c’est un problème côté client …

Et en fait, c’est une sale histoire entre jQuery et FormData. Ca me soulage : j’ai eu peur que Wisdom soit de la partie. Il me reste maintenant à corriger ce problème de Javascript … Qui se corrige en remplissant le Formdata avec le contenu de fileInputChooser.

Comme ça :

var file = $('#fileInputChooser')[0]
var formData = new FormData();
// Seems like auto-loading a FormData from a form do not work that well ... crap !
formData.append("fileInputChooser", file.files[0])

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.

Ionic framework ?

Eh mais la semaine dernière, il y avait …

Et je n’en ai pas encore parlé ? C’est MOCHE.

Donc, ionic framework …

pour lequel Loïc fournit les slides :

Comme ça, je n’aurais pas à vous résumer le truc, mais juste à donner mon avis.

Ionic est donc une surcouche d’Apache Cordova pour y faciliter l’intégration d’AngluarJS et d’autres trucs. Ca permet de faire facilement des applis hybrides pour mobiles.

Les applis hybrides étant, pour ceux qui ne le sauraient pas, des applications web packagées pour ressembler aux applications système.

Au passage, un petit tacle à ceux qui croient que c’est moche : les jeux de chez Wargaming utilisent ce type d’application pour les garages de World of Tank/Warplanes/Battleships. Et pourtant, ça ressemble assez peu à un site web, il me semble. Donc dire que l’hybride est forcément une mauvaise solution me paraît un peu abusif.

Bref. On retrouve donc avec Ionic la possibilité de construire une appli mobile en web. Et, malheureusement, avec Angular. je dis malheureusement, parce que franchement, angular me sort autant par les yeux que JSF, et c’est pas peu dire.

Cela dit, la présentation était sympa.

J’ai même été particulièrement bluffé par l’intégration de Firebase. Je savais que cette base de données « as a service » existait. Mais je ne savais pas que c’était aussi chouette. Tellement que ça a éclipsé dans mon esprit toutes les idées du genre « mais pourquoi ne pas remplacer angular par Ractive ? »

Donc, une présentation réussie, mais pas pour son sujet principal.

Droit à l’oubli du code

Vous n’y avez sans doute pas échappé, Google Code a fermé ses portes. Dommage, j’aimais bien, quand il a démarré, ce service. Et j’y avais quelques projets …

J’aurais pu, pourtant, exporter ses projets pour les mettre dans un quelconque git. Mais je ne l’ai pas fait.

Parce que même si certains de ces projets étaient intéressants (majick-properties, en particulier), je crois qu’il faut savoir certaines choses disparaître dans un oubli relatif (puisque de toute façon, the internet wayback machine se souvient de tout).

Les wikis ont changé, et c’est bien !

Depuis des années, dans les projets auxquels je participais, on utilise des wikis « simples », comme typiquement mediawiki. C’était pratique, mais dès qu’on sortait des pages de texte, on était embêté.
Il fallait alors installer, si on en avait le courage, un logiciel de forum, ou de blog interne, ou tant d’autres choses.Honnêtement, c’était assez peu pratique. Suffisamment, d’ailleurs, pour donner aux utilisateurs peu intéressés comme moi l’impression d’un monde déjà fermé.Et puis j’ai du jeter un oeil, pour différentes raisons, à XWiki (la plus importante étant sans doute l’interview donnée par les patrons de l’entreprise éponyme aux castcodeurs). Et là, le choc :

  • Joli
  • Avec un éditeur WYSIWYG
  • Extensible par une multitude d’applications (forum, gestionnaire de tâches, outil de microblogging, …)
  • Scriptable en Velocity et en Groovy !
  • Installable facilement dans tous les environnements

Bref, une révolution.

Il y a certes deux ou trois choses gênantes, comme le manque de certains imports/exports, mais rien de dramatique à mon sens.

Du coup, forcément, je vais tester plus de choses avec cet outil aussi puissant que bien fichu.