Vite, un chtijug !

Je me demande si je n’ai pas déjà utilisé ce titre …

En attendant, hier soir, c’était chtijug spécial quickies.

HTTPS Everywhere avec let’s encrypt

Le HTTPS c’est mieux pour la confidentialité des utilisateurs. Let’s encrypt est une autorité de certification, dont le client essentiel est certbot.

certbot

Tourne sur n’importe quel Unix (oui oui). Il y a des plugins pour tous les serveurs web, même sur le Raspberry.

Démonstration avec un site Apache

S’ensuit une jolie démonstration avec des poneys en ascii-art. Et tant mieux, parce que certbot a une interface ncurses ! On note tout de suite les problèmes classiques liés à du https : le mixed content (images ou scripts chargés en http, …). Je note également le point « magique » de Let’s Encrypt : obtenir un certificat à la volée, c’est quand même vachement plus rapide que de le réclamer physiquement à un service de sécurité.

Validation du certificat

La partie intéressante de Let’s encrypt, c’est le mode de génération de certificat. Plutôt que d’utiliser la méthode traditionnelle avec échange de mail, ils reposent sur l’exposition d’un challenge en http sur le site pour lequel on veut un certificat. C’est assez malin, car plus facilement automatisable. Et j’imagine que certbot doit pouvoir automatiser ça

Démonstration avec nginx et webroot

Histoire de montrer les capacités de certbot, on refait la démo, mais avec une configuration manuelle, pour nginx.

Intérêt ?

Le certificat est renouvellé automatiquement tous les 90 jours ! Du coup, plus de problème d’expiration. Et ça, pour les noobs de la sécurité comme moi, c’est vraiment cool. Un point important à noter : Let’s encrypt ne fournit que des certificats de classe 1, donc avec une sécurité « moyenne ». Les classes 2 et 3 impliquent des vérifications physiques, qui sont évidement manuelles.

Point bonus : il y a une interface permettant de révoquer les certificats depuis le site de Let’s Encrypt, ce qui provoquera sans doute leur renouvellement automatique.

Ce que la revue de code m’a apporté

Julien commence par nous raconter sa vie de jeune développeur. Et, personnellement, je me reconnais mal là-dedans :

  • la fierté du code produit
  • la propriété du code (c’est le code de Julien)
  • Et enfin, il veut que son code soit beau longtemps

Du coup, ils ont mis en place chez Axa des revues de code avec des rôles identifiés pour limiter les procès en sorcellerie. Malheureusement, j’ai peur que ça ne suffise pas. Du coup, il faut apprendre plusieurs choses (qui, il me semble, font partie de l’expérience du développeur). La première étant évidement de faire preuve de bienveillance envers ses collègues, le fameux « dur avec le code, doux avec les gens ».

Axa consomme environ 5% de son temps à faire de la revue de code. C’est assez peu, vu que ça permet de détecter des bugs (en plus d’assurer une cohérence stylistique des livrables).

A priori, il faut environ 3 mois pour que les revues soient « apaisées ».

A la réflexion, il y a à mon avis quelque chose de complètement biaisé dans le fait que le développeur vienne présenter lui-même son code à un procès en sorcellerie. Il vaudrait sans doute mieux que le code soit défendu par un « avocat » sans que le développeur à l’origine du code puisse être reconnu. Parce que, comme je le dis toujours, le code qui est dans Subversion/Git n’est plus ton code, c’est celui de l’équipe. Et c’est ce qui le rend magiquement sale.

lunrjs

lunrjs est un portage de Lucene pour javascript, utilisé chez Decathlon. Et sur le site de Decathlon, actuellement, quand on change un filtre de recherche, la page est visiblement rechargée (ce qui n’est pas terrible en termes de performances). Un portage, mais un peu restreint, puisqu’on perd par exemple les recherches de termes approchants.

A noter qu’actuellement, le catalogue produits de Decathlon est hébergé en SAAS, ce qui est … osé, je trouve.

Cela dit, je n’ai pas trouvé ça si impressionnant. Parce qu’il existe déja des tonnes d’API javascript pour exploiter le local storage « correctement ». En fait, le seul intérêt de lunrjs, c’est de compléter les recherches disponibles dans Lucene pour les déconnexions, mais je trouve le cas d’utilisation assez rare pour ne pas investir spécifiquement dessus. A mon sens, travailler sur une vraie API client/serveur dans le navigateur permettrait plus facilement d’attaquer ce type de problème. Sauf, bien sûr, si l’objectif du projet est précisément d’étendre Lucene, mais c’est plus de l’ordre du patch que de l’évolution en profondeur.

Cerberus

Donc, cerberus est un outil de test fonctionnel automatique. Des outils comme ça, il y en a … déjà … des tonnes. Alors pourquoi La Redoute s’est lancée dans cette guerre des tranchées ? Comme d’hab, l’hubris (autrement dit « il n’existait pas de solution correspondant à leur besoin »). Cerberus se place donc entre les différentes équipes, pour fournir un référentiel commun. ce qui implique également que les tests puissent être décrits par les fonctionnels ou les développeurs. Et comme un outil comme HPQC, il offre tout un tas de fonctionnalités, comme le support multi-technologies, multi-langues, multi-environnements l’exécution adaptative des tests, la génération de rapports ou l’intégration dans les outils de développement du SI (IC, bug tracker, …).
Bon, j’avoue, j’ai décroché lors de la démo. Parce que vraiment, on est face à de l’outil de test fonctionnel très haut niveau, où les étapes peuvent être effectuées manuellement ou automatiquement. Ce qui ne m’inspire qu’une chose : ces outils ne sont pas faits pour le monde d’aujourd’hui, mais pour les bonnes grosses applications traditionnelles des entreprises qui ont encore des équipes dév, fonctionnelles, test, différentes, et des processus de livraison longs et lourds. Dans ce cadre, j’imagine que ça doit marcher. Mais dans le cadre hyper-mouvant du web de 2016, je ne suis pas sûr que ça bouge assez vite.

Conclusion

Je peux paraître un peu dur avec certains des talks, mais ça n’est pas mon but. Le contenu ne m’a peut-être pas autant intéressé que les orateurs l’auraient souhaité, mais ça n’ôte rien à leur prestation. Les quatre présentations étaient en effet bien préparées, construites, bien organisées. C’est juste que chaque auditeur met ses propres filtres sur les sujets qui lui sont présentés … Bravo encore au chtijug qui arrive toujours à trouver des choses intéressantes à nous présenter (eh oui, ça n’est pas parce que ça ne m’a pas plu que ça n’était ps intéressant).

Publicités

#devoxxfr – JGiven

Bon, pour la BDD, j’ai déja vu Fitnesse, et franchement, ça fait braire tellement c’est mal fichu. J’avais aussi vu un autre outil BDD, bien plus convaincant, au chtijug, mais comme j’ai oublié son nom, ben forcément, c’est moins tentant.

Heureusement, c’est la fin de journée, et les talks raccourcissent. On est donc partis pour 1/2 heure de JGiven. Espérons que ce soit chouette !

Et donc, le BDD, ce sont les three amigos (dév, test, métier) qui écrivent ensemble les specs à partir d’exemple.

Le but de JGiven, c’est de produire un rapport facilement lisible et navigable.

Et effectivement, le rapport est beau. Bien plus beau que Cucumber … et je ne vous parle pas de l’horreur qu’est Fitnesse.

Encore mieux que le rapport, un scénario n’est pas un fichier plat, mais une classe Java (en fait un test). Et en bonus, quand on exécute le test, JGiven affiche un joli rapport d’exécution qui va contenir le scénario de façon lisible avec les succès ET les échecs.

Et attendez, c’est pareil pour injecter les valeurs des tests (plutôt que de faire des sales tables façon wikipedia) !

Bon, mais tout ça, c’était « simple ».

Quand on veut partager les informations, JGiven fournit aussi des outils pratiques.

bon, la présentation va vraiment vite. Donc on passe vite fait aux options de présentation, qui vont permettre d’afficher une variable du test entre guillemets de façon automatique, par exemple.

Franchement, pourquoi on n’utilise pas dans nos projets ce genre d’outils intelligents, mais des horreurs comme Fitnesse ?

Je note toutefois qu’un outil comme JGiven n’est en fait qu’un support de discussion.

Et c’est vrai qu’avec un outil pareil, aller voir le métier pour discuter d’un point d’implémentation est vraiment pratique.

Question marrante : comment le métier écrit les scénarios.

La réponse est chouette : en fait, le métier n’écrit pas les scénarios – ils le font peut-être au début, mais très rapidement, il faut être développeur pour pouvoir maintenir un scénario. Du coup, le fait que ce soit en fait simplement une surcouche de JUnit n’est pas gênant sur le long terme. Ce qui s’illustre par le processus de développement : le BI arrive avec une idée, qui est élicitée par l’équipe de dév à grands coups de post-it. Puis, une fois la réunion terminée, les post-its sont traduits directement en code (parce qu’ils sont valides).

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.

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.

Infinimaven, anyone ?

Il y a quelques temps, Infinitest avait créé la sensation (j'aimerais éviter de parler de buzz, ça fait trop mot-valise d'importation) en montrant comment l'exécution de tests rapides pouvait rendre un IDE infiniment plus puissant qu'un simple outil de compilation. C'était une bonne idée, qui se heurte maintenant à deux inconvénients majeurs :
  1. Infinitest est lié à l'IDE. C'est-à-dire que si les développeurs d'Infinitest n'aiment pas votre IDE, ou ne savent pas adapter leur super produit à votre IDE, vous êtes dans la mouise (développeurs utilisant NetBeans, je compatis).
  2. Infinitest est payant. Et moi, le payant, j'aime pas ça. Enfin, quand ça commence par être payant, ça ne me dérange pas, mais un produit qui devient subitement gratuit, ça me … comment dire …)
Cela dit, je l'avais testé et trouvé vraiment pratique. Et avant-hier, pendant que je travaillais sur mon projet "secret", je me suis dit que ce serait bien pratique de faire du test continu sur mon code Groovy … Donc j'ai farfouillé un peu. Et je me suis dit que, puisque je lançai déjà mes tests unitaires avec maven, pourquoi ne pas lui demander de devenir un Infinitest en ligne de commande ?
Après tout, l'outil de build de Scala fait déjà ça, non ?
Et sans doute que d'autres en font autant …
Alors pourquoi ça n'existe pas pour maven ?
A mon avis, il y a plusieurs raisons à ça
  • la longueur typique des builds Java. Il n'y a qu'à écouter le dernier épisode des castcodeurs pour se rendre compte que ça ne dérange apparemment pas grand monde de mettre 20 minutes à builder une librairie. Cela dit, tout le monde ne semble pas apprécier cet apparent consensus.
  • Le temps de démarrage rédhibitoire de maven (forcément, comme à chaque fois il rebâtit le monde depuis Object, c'est un peu longuet à se lancer).
  • L'absence pendant longtemps d'un moyen de le charger et de le garder en mémoire (mis à part évidement maven-cli-plugin, que je n'ai bien sûr jamais utilisé, essentiellement parce que je lançais maven avec M2Eclipse, à ce propos, j'ai découvert tout récemment qu'une console maven existait déjà en maven 1).
Heureusement, maven 3 est censé être plus rapide (je l'ai téléchargé, mais pas encore installé, ce que je vais d'ailleurs faire cet après-midi), et il existe à nouveau une console "officielle". Ce qui résoud à peu prés deux des problèmes. Cependant, il manque encore un moyen de faire de la triggered execution. Comment faire ? Est-ce qu'un plugin pourrait faire ça ? Est-ce qu'un plugin fait déjà ça mais que personne ne le connaît ? (à ce sujet, je trouve incroyable qu'il n'existe aucun équivalent de l'Eclipse plugin central : un site central recensant tous les plugins existant – ou les plus connus au moins – pour maven. Je crois vraiment que ça rendrait service à plus d'un développeur, non ?)
voilà donc l'état de mon questionnement.
Notez bien qu'à mon avis, écrire un plugin simpliste qui ferait ça ne me paraît pas, vu de loin, outrageusement complexe … surtout si, par exemple, le shell maven est extensible (ce qu'il ne peut qu'être, connaissant la maven way). Cela dit, c'est comme tout, il faut un peu de la matière la plus précieuse dans cet univers : du temps. Et ça, j'en ai vraiment trop peu pour mes projets en cours sans en rajouter d'autres … Dommage, c'aurait été marrant à coder. Cela dit, si quelqu'un a la moindre idée d'un début de piste, je suis archi-preneur.

Flex, c’est quand même moins bien

Pour mon nouveau boulot, je suis amené à faire du Flex. Je ne le prends pas trop mal, dans la mesure où ça me permet (en théorie) d’implémenter un point essentiel des méthodes pour rester un développeur « on the edge ».
Là où c’est moins bien, c’est que tant qu’à faire, j’aurais préféré travailler sur un langage qui ne fasse pas semblant.
Prenez l’IDE, par exemple. La toute dernière version de Flash Builder est en fait un packaging d’Eclipse dédié aux développeurs Flash (comme peut l’être, je ne sais pas moi, Eclipse for C, Pulsar, …). En un sens, c’est très bien, parce qu’en tant que développeur Java, je ne suis pas vraiment surpris. Sauf quand ils décident de me livrer sans mon consentement une version française. Ou que le seul refactoring disponible soit le renommage de fichiers (alors que faire des refactorings dans un langage dynamique, même si c’est plus difficile, c‘est possible). Ou que les erreurs de compilation me font revenir quinze ans en arrière, avec des codes abscons suivis de messages encore moins clairs (pour l’anecdote, il m’a fallu hier à peu prés l’après-midi pour trouver qu’un test ne fonctionnait pas à cause d’un simple problème de déclaration de constructeur). Ou qu’une application mxml contenant les tests doive se trouver dans le dossier src (ce qui est super pratique pour séparer les tests et le code source de ma bibliothèque, tiens, imaginez comme maven est content).
Et si l’IDE infâme ne vous suffit pas, prenez les bibliothèques de test unitaire. En Java, je connais bien jUnit, et un peu TestNG. Elles sont plutôt documentées et facilement intégrées dans l’IDE. Bon, en Flex, il y a quoi ? flexunit ? funit ? asUnit bon, eh bien je vous mets au défi de trouver une doc claire et complète pour ces différentes bibliothèques. Attention, je ne parle pas d’un tutorial écrit pour faire comme tout le monde et présentant un exemple bidon même pas intégré à l’IDE, mais bien de l’exemple complet qui me permet à la fin de lancer mes tests dans l’IDE. Cherchez pas, vous ne trouverez rien. Parce que ces trucs sont codés à la va-vite et que leurs auteurs ne semblent pas se soucier de l’industrialisation de ces tests unitaires.
Et pour finir avec l’industrialisation, parlons un peu des flexmojos. C’est une super-idée de vouloir intégrer la compilation Flex à maven pour montrer comme l’outil est extensible. Mais c’est aussi une terriblement moins bonne idée que de fournir une dépendance flexmojos-unittest-support qui contienne les trois bibliothèques sus-mentionnées (dont les classes de bases de test unitaire s’appellent toutes … TestCase … merci pour les problèmes d’import) sans jamais expliquer comment éviter cette dépendance (mis à part, quand on connait maven, en allant faire un tour dans le pom de cette dépendance pour trouver les dépendances initiales et leurs versions respectives).
Bref, Flex, c’est quand même vachement moins bien que Java. Et c’est là que je comprend les éternels regrets des vrais développeurs Java, qui voient Sun lancer des idées du bout du petit doigt et ne pas les soutenir (au hasard, JavaFX) alors qu’avec un bon soutien, cette techno a les moyens de botter cent fois les fesses à ce Flex, qui n’est rien d’autre qu’un javascript vaguement rhabillé.

préconditions en Java

Quand on développe en Java et qu’on écrit des méthodes, on a souvent le cas de paramètres ayant des valeurs incorrectes (genre un paramètre nul).

Ce qu’on fait d’habitude, c’est une vérification simple :

if(toto==null) {
    toto = "toto";
}

C’est laid, hein ?

Et en plus, ça pollue le code.

En me baladant sur internet à la recherche de la solution à un problème compliqué de collection basée sur le hash contenant des éléments mutables, je suis tombé sur cet article : mutable entries in a collection qui m’a mené à celui-ci (beaucoup plus intéressant) : RuntimeExceptions and Gurus failing to meditate bon, j’aime bien la GuruFailedToMeditateException, mais ce que j’aime surtout beaucoup, c’est les vérifications de préconditions avec la classe Preconditions. J’aime même tellement ça que je me demande comment je pourrais inclure ça dans mon projet à grands coups d’annotations (pour que ça marche bien et que ça puisse aussi générer de la doc).

Du coup, j’ai commencé à re-jeter un coup d’oeil aux frameworks de programmation par contrat en Java.

Bref, c’est un sujet assez intéressant, sur lequel je vais essayer de creuser un peu.

Tester l’utilisation de la mémoire

Dans majick-properties, je suspecte le code que j'ai écrit d'être potentiellement à l'origine de fuites de mémoire. Et ça, c'est plus qu'embêtant quand on fait une bibliothèque dont le but est de faciliter la vie.

Surtout que, traditionnellement, la chasse aux fuites mémoires en Java est compliquée : il faut un profiler (en Java, le meilleur rapport qualité/prix est obtenu avec le profiler de NetBeans), trouver le truc qui foire, le corriger, et espérer que ça tienne 

360

Heureusement, la communauté Java dispose maintenant de méthodes permettant de vérifier que ces fuites de mémoire ne reviennent pas. La première que j'ai trouvé utilise une librairie dont le nom seul est un hommage au bont goût : insane. Et la deuxième utilise jUnit pour parvenir au même résultat, ce qui fait que je vais pouvoir utiliser les concepts dans mes tests. Je me demande quand même s'il ne va pas falloir que je regarde insane de prés pour améliorer ça, parce qu'en fait, cette deuxième solution ne semble pratique que quand on sait précisément ce qu'on cherche, alors que la première est plus efficace en terme d'exploration.

Tiens, au fait puisqu'on parle de mémoire en Java, il semble que cet article : understanding weak references, soit une mine d'infos sur les distinctions subtiles entre weak, soft et phantom references.

sacrénom d’un bug !

C’est le genre de trucs qui m’énervent, ça.

J’ai voulu être sérieux, j’ai fait une tonne de tests unitaires, et sans même avoir de rapports de couverture de test dans maven, je suis déjà certain d’avoir au moins 75 % du code testé.

Enfin, testé … dans Eclipse.

Parce que dans Maven, c’est une autre histoire. J’ai une espèce de sale foutu bug qui fait que mon premier test unitaire Swing (qui utilise bien sûr FEST-Swing) ne s’arrête pas.

Ah, si mon fan était là ! Il me dirait bien sûr que c’est un sale problème d’utilisation de l’EDT. Ouais, enfin bon, quand je regarde le code de mon test, il n’y a pas grand chose qui me choque.

Et encore moins quand j’utilise les méthodes de FEST-Swing pour m’assurer que je fais tout dans l’EDT.

Bref, je vais être bon pour fouiller.

Ce que ça a de particulièrement agaçant, c’est que comme le test ne se termine pas, je n’arrive pas à faire de

mvn deploy

Et ça, ça m’agace avec une force !

Bah ! Je trouverai la solution demain.