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é.

Ré-réinstaller fonz_fun_plug

Parce que j’ai rebooté mon NAS, et depuis, j’ai perdu

  • l’accès SSH
  • Lighttpd
  • minidlna

Heureusement, je peux toujours y accéder en « vrai » FTP et consulter le ffp.log qui me dit des choses aussi absconses que

* /ffp/start/uwcron.sh ...
wc: can't resolve symbol 'posix_fadvise64'

ou

* /ffp/start/sshd.sh ...

/ffp/bin/ssh-keygen: symbol '_res': can't resolve symbol

/ffp/bin/ssh-keygen: symbol '__stack_chk_guard': can't resolve symbol
tr: can't resolve symbol 'posix_fadvise64'
Starting /ffp/sbin/sshd 

/ffp/sbin/sshd: symbol '__stack_chk_guard': can't resolve symbol
* /ffp/start/rsyncd.sh inactive

Préferrant la brutalité à la subtilité, je vais donc réinstaller fonz_fun_plug 0.7. Heureusement que j’ai déja détaillé les étapes.

Donc allons-y …

(je démarre à 11H00)

Au passage, je lis dans mon article de référence

You may select to upgrade system package by packages from other repositories, but it may bring some system instability. Do it at your own risk …

Ouais, ben j’aurais dû le mettre dans une espèce de welocme message …

(et à 11H22, ffp est réinstallé, et je redémarre pour vérifier que les modifs fonctionnent – et oui, ça marche).

Par contre, dans la partie

Installer ensuite toutes les libs de minidlna, puis minidlna

Bêtement, je n’ai pas noté la liste des « libs de minidlna » … heureusement, une rapide recherche sur « kylek minidlna » me donne cette liste :

  • libjpeg-8c (system)
  • flac (kylek)
  • ogg (kylek)
  • vorbis (kylek)
  • libid3tag-0.15.1b (kylek)
  • sqlite-3.7.9 (system)
  • libexif-0.6.2 (system)

Et ça ira !

Avec ça, minidlna redémarre correctement.

J’ai en revanche un petit souçi avec lighttpd … mais je vais arranger ça rapidement …

Donc, si après le démarrage de lighttpd, je ne vois rien dans mon navigateur internet, je dois aller jeter un oeil dans /mnt/HD_b2/www/logs/error.log pour y trouver des erreurs comme par exemple

2015-01-10 18:36:22: (mod_fastcgi.c.1103) the fastcgi-backend /ffp/bin/php-cgi failed to start:
2015-01-10 18:36:22: (mod_fastcgi.c.1107) child exited with status 16 /ffp/bin/php-cgi
2015-01-10 18:36:22: (mod_fastcgi.c.1110) If you're trying to run your app as a FastCGI backend, make sure you're using the FastCGI-enabled version.
If this is PHP on Gentoo, add 'fastcgi' to the USE flags.
2015-01-10 18:36:22: (mod_fastcgi.c.1397) [ERROR]: spawning fcgi failed.

Et donc, je n’ai pas dû installer la bonne version de PHP …

Bon, en fait, c’est pas ça : quand je tape php -v, j’obtiens ça

php: can't load library 'libcurl.so.4'

Normal, puisque curl n’est pas installé.

Donc il faut installer curl avant de tenter d’utiliser du php !

J’ai donc maintenant un lighttpd+php qui marche à peu près (suffisament en tout cas pour jtartQage). En revanche, pour krissfeed ou Shaarli, j’ai toujours des erreurs

Fatal error: Call to undefined function gzinflate() in /mnt/HD_b2/www/pages/Shaarli/index.php on line 773

Qui sont liées, d’après internet à … des problèmes curieux de zlib (que j’ai pourtant installée).

Bon, en fait non, c’est juste parce qu’il ne faut pas oublier de copier le php.ini qui est sauvegardé sur GitHub !

Cinq ans d’ALM, putain !

Encore une suite à cinq ans, putain !

Oui, je mets le terme ALM à toutes les sauces, parce que c’est mon bon plaisir.

Donc, sur ce gros projet, j’ai fait ce qu’on pourrait de l’ALM. Qu’est-ce que je mets sous ce terme ?

L’ensemble des tâches qui permettent de passer du code au produit.

Ca inclut, de façon non exhaustive

  • Les outils de build
  • Les outils d’intégration continue
  • L’intégration entre ces outils et les outils de suivi de bugs.

Et évidement, je vais vous (re)parler de Tuleap.

Mais avant, je vais reprendre les étages un par un

Compiling !

Aimablement fourni par http://xkcd.com/303/ mais vous vous en doutiez, non ?

Quand on a commencé notre projet, j’avais déja touché du build maven multi-module. Maias je n’imaginais pas que j’en ferais autant, puisque notre build intègre maintenant

  • De la compilation flex avec flexmojos (raisonnablement facile)
  • De la compilation C++ … et selon la plateforme, cette compilation utilise soit Visual Studio, soit XCode … alors ne me parlez pas de maven-nar-plugin, parce qu’il est notoirement insuffisant pour nos besoins.
  • Du packaging sous d’innombrables formes (war, ear, zxp, …)

Qu’est-ce que ça m’a appris ?

It’s alive

Que la vraie force de maven n’est pas la création d’un format de dépendance universellement utilisé.

Je veux dire, c’est vrai que c’est pratique, ces dépendances, mais quand on arrive à du build « d’entreprise », c’est-à-dire moche et farci de profils, la vraie force de maven, ça n’est pas ça. Non.

La vraie force de maven, c’est de définir un cycle de vie universel. Parce que ce cycle de vie permet, quelquesoit le type de projet, le langage utilisé, ou quelque concept que ce soit, de positionner les différentes opérations dans un tout cohérent. Ca n’a l’air de rien, comme ça, mais c’est réellement indispensable pour les gens qui s’occupent de faire un packaging réaliste. Parce que je sais, quand j’en arrive à la phase « packaging », que tout mon code est compilé, testé, que les ressources ont été traité.

Franchement, quand je regarde les alternatives à maven, je me dis qu’ils n’ont rien compris : ne pas reprendre ce cycle de vie, c’est juste irresponsable maintenant.

Groovy, baby

Alors évidement, vous me direz qu’écrire un plugin maven pour les cas non standard, c’est l’enfer. Et c’est vrai.

Heureusement, j’ai également découvert une gradation dans la personnalisation que j’applique de façon systématique (vous savez, pour tous ces trucs foireux – comme par exemple construire un fiochier de config requirejs à partir de dépendances Javascript) :

  1. Je trouve un plugin maven qui convient ? C’est la fête
  2. Je trouve un ensemble de tâche ANT qui colle ? Cool
  3. Je peux écrire un script groovy avec gmaven ? Bien (dans ce cas-là, n’écrivez pas le script dans le build, mais mettez-le dans un dossier clairement séparé, par exemple src/build/gmaven)
  4. Aucun des trois n’est suffisant ? Alors il est temps d’écrire un plugin maven.

Avec ça, rien n’est impossible dans un build.

Et notez que je ne suis passé du point 3 au point 4 que dans deux cas. Et dans les deux cas, c’est parce que je devais en fait écrire un plugin avec cycle de vie complet. Dans tous les autres cas, groovy a été suffisant, et je dirais même fun.

Non mais tout ce XML, quand même …

Tout ce XML de maven ? A priori, on le regardait sous tes les angles dans m2e quand on ajoutait un nouveau type de build, et après, il n’y avait plus vraiment besoin d’intervenir dessus. Alors dire que c’est pénible, faut pas déconner. Le pire, en fait,a vec maven, c’est qu’Eclipse ne différencie pas les scopes des dépendances. Heureusement pour nous, Jenkins compilait en-dehors de tout IDE.

Make me a sandwich

Et encore, on n’a pas besoin de sudoer Jenkins

Ben oui, Jenkins, le gagnant de la grande guerre du fork.

Lui aussi, on l’a bien tanné.

Justement à cause de notre build natif multi-plateforme. Parce que si on compile une partie de notre application selon la plateforme, on fait comment pour avoir les artefacts dans un build commun ?

Eh bien on se fait un profil spécial Jenkins, dans lequel le build maven est découpé en parties multi-plateformes et dépendant de la palteforme, et on joue du build matrix plugin pour que tout compile et se package sans problème.

Et ça marche, mpême si c’est pas très facile.

Ca chauffe !

A vrai dire, le plus grand échec a été l’implication de l’équipe : même avec un bon radiateur, personne (sauf la testeuse en chef – que toujours elle marche sur un chemin de roses fraîchement coupées) ne s’y est jamais vraiment intéressé. Et ça, c’est triste.

Parce que ça veut dire que cette histoire d’intégration continue n’a été qu’une lubie de ma part, et que je n’ai pas réussi à en communiquer la valeur pour l’équipe, le projet, le produit.

Là-dessus, je peux dire que je retiens la leçon, et que je ferais en sorte que les builds en échec ne puissent plus être ignorés.

Tester c’est douter

Cela dit, tout n’est pas si sombre, puisque le projet a quand même une bonne partie de son code testé, et que TDD a été utilisé dans la plupart des acceptations du terme. La meilleure, et la plus efficace étant qu’aucun bug ne devait être marqué corrigé sans qu’un test ait été ajouté spécifiquement. Parce que

ce qui a foiré foirera

Ca a l’air con dit comme ça, mais ça c’est vérifié à chaque fois : les parties de code ayant connu un bug en ont toujours connu plus, et plus encore.

Heureusement qu’il n’y avait pas d’exploitation statistique des liens entre code et bugs pour vérifier ça, sinon c’aurait été l’enfer.

Et mylyn ? Et Tuleap ?

Là, par contre, l’échec est patent.

Plus encore quand je regarde ce que j’ai pu faire avec gaedo où, là, chaque bug est corrigé à travers un commentaire de commit.

Imaginez que le seul lien dont on ait pu dispoiser était, éventuellement, un lien HTTP dans un commentaire de commit référençant un bug. Comme ça, par exemple :

http://mantis/bugs/view.php?id=7137
the error was stupid : I did not add children to parents when they were needed

ca, c’est moi qui l’ait écrit aujourd’hui.

Ce qui est bizarre, c’est que j’avais parlé de mylyn, de Tuleap, et qu’un autre collègue avait parlé de svn commit hooks … mais aucune de ces tentatives n’a pris. Et pour des raisons diverses … La pire étant celle qui nous a empêché d’utiliser Tuleap : « j’ai pas vraiment eu le temps de regarder ». je dois dire que ça, ça m’a tué.

Alors, content ?

En fait, la plupart des choses installées vont continuer à fonctionner … jusqu’à ce qu’on les arrête.

En revanche, je reste convaincu de l’intérêt de ces outils, et je n’hésiterai pas à pousser leur adoption la prochaine fois.