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.

Hier soir … c’était le printemps ?

Parce qu’hier soir, c’était chtijug, chtijug spécial Spring, et Spring boot en particulier

Pour laquelle Brian Clozel a fait un gros boulot de livecoding.

Alors Spring Boot, qu’est-ce que c’est ?

Eh bien c’est tout ça

D’après ce que j’ai compris, c’est une façon pour les gens de Spring de simplifier la vie des développeurs en fournissant

  1. Une façon très chouette de bootstrapper une application à partir de leur site web.
  2. Un framework d’utilisation de l’ensemble des couches Spring, qui inclut évidement le code, mais aussi les bonne spratiques d’utilisation
  3. Une interface « simplifiant » l’utilisation des autres bibliothèques de Spring.

En revanche, Spring Boot n’est pas une version simplifiée de Spring (tout Spring peut être utilisé dans Boot), ni un outil à réserver aux POC.

Donc, brian nous a fait du live-coding. Et sans utiliser cette cochonnerie de thème sombre illisible. Et ça c’est bien.

On a donc pu voir en action

  • Spring-data-mongo
  • Spring-rest (je reviendrai plus bas là-dessus)
  • Spring-security

Et quelques autres.

Au passage, j’ai beaucoup apprécié la façon d’utiliser les TODO de Brian, qui lui permettait de dérouler dans un ordre sympatoche les différents éléments de sa démo.

Il a ensuite fait une rapide présentation des différentes nouveautés de Spring 4.1 (en oubliant de préciser que certaines ne fonctionnent qu’avec java 8, comme par exemple les injections de types paramétrés).

Sauf que …

Comme le dit fort bien Thibaud

Pour clarifier un peu … J’ai fait du Spring il y a maintenant 8 ans. A l’époque, on était en plein XML hell, et Spring en était le champion. Des fichiers XML partout, avec des beans à câbler dans tous les coins, c’était l’enfer. Et je me souviens en particulier à l’époque d’un aspect pénible de Spring, qui était le fait de devoir toujours passer par la doc pour obtenir des infos : rien n’était découvrable automagiquement dans l’IDE.

Aujourd’hui, le XML Hell a été remplacé par l’annotation hell. Et honnêtement, ça ne change rien au problème : on ne sait toujours pas quel bean vient de quel endroit, et qui est injecté où.

Vous serez tenté de me dire que c’est exactement pareil dans le JavaEE d’en face, et vous aurez raison. Cependant, dans le monde JavaEE, j’ai l’impression qu’il existe une distinction plus claire entre les différents types de composants : les EJBs, les beans sont plus facilement définis, et mieux isolés. Enfin, je trouve.

Spring-data a tout copié sur gaedo ?

Quoi ? Vous ne connaissez pas gaedo , La meilleure librairie de mapping objet/stockage en Java ?

Je n’ai pas pu m’empêcher d’y penser quand j’ai vu cet écran

IMG_20150203_192539

Que vous pouvez comparer avec la doc de gaedo sur les finders dynamiques… Ouaip, c’est pareil. Et ouaip, on a tous copiés sur Ruby on Rails.

Oui mais Spring boot, c’est léger ?

Comparez par exemple avec DropWizard (comme l’a fait JavaLobby), à Wisdom ou à ninja … Dans tous les cas, Spring boot apporte effectivement la légereté de ces outils en s’appuyant sur la force de Spring. Mais du coup, c’est loin d’être aussi léger que ce que vous croyez : mettre en place un stockage va impliquer l’utilisation de Spring-data-*, qui va vous tirer des tonnes de dépendances, et il en sera de même pour implémente rune API REST : vous passerez par la librairie idoine du portfolio Spring à travers une couche d’adaptation, et du coup ce ce sera encore une fois un gros paquet de dépendances, et une complexité pas forcément masquée.

Conclusion

Donc une session intérressante, sur un des frameworks majeurs du monde Java, mais qui n’en était pas pour autant exaltante. Et c’est bien normal : Spring est une solution mature, déployée à des échelles industrielles, et dans des environnements qui n’ont rien de glamour. Ils ne cherchent donc pas à épater les utilisateurs, mais plutôt à trouver une solution qui marche, et qui réponde sérieusement aux problèmes des applications d’aujourd’hui.

Français, vous me dégoûtez

J’espère que le titre est assez clair.

Après les attentats du début du mois, j’ai cherché désespérément comment écrire que, comme d’autres, je n’étais pas Charlie.

Hélas, je n’ai pas trouvé.

Mais aujourd’hui, ma colère contre cette récupération idéologique est … incandescente.

Parce qu’il n’a pas suffit de commémorer la liberté d’insulter … pardon, d’expression, en invitant un ramassis d’amis de cette liberté (du moment que les opinions leur plaisent, évidement).

Il n’a pas suffit non plus de commémorer cette même liberté de haïr … pardon, d’exprimer la franchouillardise, en remettant des militaires dans la rue. Au passage, je ne résiste pas à deux appartés à ce sujet.

Vous savez que les militaires disposent d’armes incomparablement plus dangereuses que les flics ou les gendarmes ? Mais est-ce que vous connaissez les différentes règles d’engagement ? Pour ce que j’en sais, ça me terrifie. Parce qu’un militaire peut ouvrir le feu bien plus facilement qu’un policier. Et qu’un FAMAS a une portée incroyablement plus grande qu’un pistolet, fût-il automatique.

En bonus, je sais pas vous, mais moi, personnellement, voir un plan de défense relevé après l’attaque, ça me paraît aussi utile qu’une capote enfilée après l’éjaculation …

Bref, revenons à notre sujet pas joyeux.

La liberté d’expression a donc été défendue en invitant ses pires détracteurs, en mettant en place une politique visible d’intimidation des citoyens. Et c’est tout ?

Non. C’est encore pire.

La liberté d’expression a été défendue en punissant pénalement des enfants qui s’expriment.

Lisez donc ces deux articles

Et maintenant, essayez de vous regarder dans un miroir. Personnellement, j’ai beaucoup de mal à croire vivre dans un pays qui respecte la liberté quand je lis ça.

Et plus encore quand je vois les hommes politiques de mon pays se satisfaire de marquer des enfants à vie.

Quand je vois ça, je pleure.

Et c’est encore pire quand je compare la réaction française (raciste, hypocrite, mesquine) aux réactions d’autres pays, où la fraternité avait du sens.

Honnêtement, j’ai rarement eu autant envie de quitter ce pays qui sent le rance qu’en ce moment. Et ce qui provoque ce dégoût, ce ne sont pas quelques terroriste imbéciles, mais tous les carriéristes amateurs de dictature beige. Et oui, c’est peut-être, de ma part, une réaction allergique à la réaction allergique de notre pays que mentionne Maître Eolas.

Une étincelle au chtijug

Et c’est reparti pour un tour, cette fois-ci sur du Big Data, je crois …

J’avais entendu parler de Spark dans l’interview de Sam Bessalah chez les castcodeurs, et Duy Hai Doan est venu préciser les idées.

Et Duy Hai a été sympa pour rendre les slides disponibles sur le web

Ainsi que sa présentation pour Spark avec Cassandra

En nous expliquant d’abord que Spark est bien plus concis que Hadoop (en partie parce qu’en Scala), et bien plus rapide (parce que stockant ses données en mémoire, plutôt que sur disque, comme Hadoop). En bonus, Spark traite les données en graphe (d’ailleurs, de façon amusante, Blueprints n’est pas listée dans les API de graphe Big Data), en SQL, ou via des flux.

Cool, non ?
Petit détour par les RDD, qui reprennent, conceptuellement, ce que toute personne ayant implémenté un processeur de requête comprendra : il n’interprète les requêtes qu’au dernier moment. Par exemple, un filter suivi par un groupBy ne sera évalué que si, à la fin, l’utilisateur du RDD tente de récupérer, d’une façon ou d’une autre, les données sur son poste. D’une façon intéressante, certaines opérations vont redistribuer les données sur le réseau (typiquement, un groupBy) à cause de notions compliquées de « hashcode » de données. D’ailleurs, curieusement, on ne distingue pas les opérateurs impliquant un brassage (groupBy) des autres, ni d’ailleurs des actions démarrant le processus. Et personnellement, je trouve ça moche pour une raison bien simple : le développeur peut (et va) écrire du code inefficace, simplement parce qu’il ne saura pas comment distinguer le code efficace du code inefficace.
On passe ensuite aux API.

Spark supporte le SQL, le streaming, et le mapping d’objets. Pas mal … Sauf bien sûr qu’il y a toujours ces histoires de redistributions de données temporaires, que je vois come le vrai défaut de Spark. Je m’explique …

Comme les opérations brassant les données peuvent les envoyer n’importe où, si on en écrit « par accident », on risque de passer d’un code très rapide (parce qu’en mémoire) par un code très lent (parce que sur le réseau). Et Spark ne fournit aucun moyen de distinguer les deux, malheureusement.

Et ça empire si on utilise Cassandra comme couche de stockage, à cause de la nature multi-datacenter de l’outil, qui va certes permettre de survivre à des accidents nucléaires, au prix de coûts de transferts de données.

Pour troller, Spark, c’est bien, pour faire du SQL distribué.