Fiddler pour débugger à distance

Vous connaissez Fiddler ? C’est un très bon proxy de débuggage http pour Windows.

Eh bien aujourd’hui, j’ai découvert que je pouvais l’utiliser pour intercepter les requêtes entre un serveur Apache (sur une autre machine) et mon serveur web Java (lui aussi sur une autre machine). Le pire, c’est que ça n’est même pas compliqué.

Il suffit de régler le proxy pour accepter les requêtes distantes

2016-11-04-20_54_19-telerik-fiddler-options

Et de régler le proxy que fiddler utilisera pour recevoir les requêtes pour que ce soit l’autre machine

2016-11-04-20_56_38-telerik-fiddler-options

Et là, les requêtes arriveront bien d’Apache dans Fiddler pour repartir aussi sec vers le serveur.

Très cool.

 

PlantUML

Il y a des gens qui pensent qu’UML est une méthode.

Il y en a d’autres qui pensent que c’est un framework (c’est assez semblable).

Il y en a aussi qui imaginent que c’est un modèle.

Pour ma part, je n’y vois qu’un formalisme bien pratique pour dessiner des diagrammes avec des patates qui représentent la façon dont un système fonctionne. D’ailleurs, je pourrais donner pour chaque diagramme toutes les raisons qui font que, vraiment, vraiment, c’est une simplification abusive de la réalité. (mais tout ça, j’en ai déja parlé il y a bien longtemps)

Bref … C’est une façon commode de dessiner.

Hélas, la plupart des outils pensent que si je veux dessiner, j’ai besoin d’une palette, de couleurs, et de poser « au hasard de mon inspiration », des trucs sur ma feuille de dessin. PlantUML, lui, colle à ma façon de voir puisqu’il ne me propose pas de dessiner. En fait, il me propose plutôt de décrire mon dessin dans un format textuel, puis de générer le diagramme qui lui correspond. Et c’est vraiment pratique, parce que je peux me concentrer sur ce que je veux montrer, et laisser un outil bien plus performant (Graphviz en l’occurence) le dessiner pour moi. Du coup, j’aime bien PlantUML.

Surtout qu’il s’intègre facilement dans ma logithèque :

Et en plus, c’est gratuit !

Alors pourquoi je me retiendrai de l’utiliser ?

Et pourquoi vous vous retiendriez de l’utiliser ?

Franchement ? Je ne vois pas de bonne raison de ne pas vous en servir la prochaine fois que vous voudrez faire un diagramme à patates. Vous verrez, passées les 5 premières minutes de surprise, vous serez conquis.

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.

Mojo Executor

Admettons que vous deviez écrire un Mojo maven. ou, pire encore, un cycle de vie personnalisé. Vous allez sans doute faire des trucs déja implémentés par d’autres plugins maven. Et vous vous en voudrez.

Eh bien pour que vous ne vous en vouliez plus, n’éhsitez pas à appeler ces cibles directement avec Mojo-Executor.

Allez voir sur le site, c’est vraiment très très pratique dès qu’on veut reprendre un truc déja disponible dans un plugin du build. Et par vraiment, j’euphémise à mort. En fait, ça change tout.

Bon, il y a juste un truc qui me chiffone un peu, c’est qu’il faut lui passer un Plugin complet (c’est-à-dire avec une version valide). or, dans le code java, la version, on ne la connaît pas forcément, d’autant plus que le projet peut déja utiliser ce plugin et que, dans ce cas-là, sa version est déja connue des composants Maven. D’où cette petite méthode qui facilite bien la vie :

Ah, et si ça ne suffit pas, ajoutez-y ces petites méthodes qui facilitent l’ajout d’attributs (très pratique quand on fait de l’ant-exec)

Avec tout ça, votre prochain mojo sera vraiment facile à écrire.

Au passage, il semble que le même type ait écrit un maven-cli-plugin, actuellement difficile à trouver, pour éviter la perte de temps du démarrage de maven (ce qui ne m’intéresse pas professionnellement, puisque notre build prend 20 mns à s’exécuter).

Explorer des index Lucene

Petit retour de la rubrique « ça sert à presque rien ».

J’avais aujourd’hui un problème de lenteur de mon application suite à une réécriture de Gaedo. J’avais la sensation confuse, vu la nature de la lenteur, qu’elle pouvait provenir d’un problème dans les index de Lucene. Du coup, la question immédiate devenait « comment explorer l’index Lucene de Neo4j » ? Question à laquelle l’article Peeking Behind the Neo4j Lucene Index répond d’une façon très internetienne en me disant d’aller voir Luke. Pas le minable pleurnichard, hein. Un Luke beaucoup plus puissant.

Bon, alors, évidement, vous me direz que l’interface est d’une laideur rarement vue. Et que le thème Swing utilisé n’arrange absolument rien. C’est vrai. Mais quand même, cet outil m’a permis de trouver que mon bug ne venait pas de Lucene (ça m’aurait étonné, mais je devais vérifier quand même, non ?), mais plutôt d’une désoptimisation introduite par l’usage massif des indexes.

Otros Log Viewer

Admettons que vous ayez des logs à analyser. Et par log, je veux dire des messages produits par log4j, slf4j ou JUL.

Vous pouvez utiliser grep. OU PAS.

Vous pouvez utiliser vi. OU PAS.

Vous pouvez utiliser Apache Chainsaw … mais c’est un peu galère … Surtout parce que le projet a l’air plutôt abandonné, ce qui est bien dommage.

En guise d’alternative un peu améliorée à Chainsaw, vous pouvez enfin utiliser Otrols Log Viewer, qui fait tout ce que fait Chainsaw, et y ajoute des gadgets supplémentaires (comme la lecture de logs à travers tous les systèmes de fichiers supportés par Commons VFSje vous avais dit que c’était bien).

Une fois que vous l’aurez lancé sur vos logs Glassfish, vous verrez votre tail -f d’un autre oeil …

Tempus Fugit

Pour aller avec Contiperf, ou plutôt pour en compléter certains articles, Tempus Fugit est elle aussi une librairie intégrable dans JUnit (mais pas que) qui permet de faire un truc typiquement galère dans un test unitaire : du multithread.

Vous savez, tous ces trucs hyper galère comme par exemple tester si un deadlock se produit … Oui, neo4j, je regarde tes histoires de supernodes pour gaedo, et j’ai les boules.

Contiperf

Vous connaissez, j’en sui sûr, cette phrase de Jeff Atwood

Performance is a Feature

Quand j’ai lu cet article (ou peu de temps après, je me souviens plus), je me suis dit – bien aidé par l’article –  si la performance est une feature, alors comme toutes les autres elle doit être testée. Donc il me faut des outils de tests.

Si je faisais seuklement du web qui fait papa-maman, je pourrais me contenter d’un test de performances web : combien de temps pour afficher cette page, etc, …

Mais je ne fais pas ce genre de développement (plutôt un truc … compliqué techniquement, mais simple fonctionnellement). Et pour ce truc, réaliser des tests de performances intégrés à maven peut s’avérer délicat. Heureuesement, j’ai découvert le superbe Contiperf qui permet de réaliser facilement des tests de performance dans JUnit, tout en générant de très beaux rapports de performance. D’ailleurs, je vais m’en servir dans gaedo.

Commons-VFS

Admettons que vous soyez un développeur Java, qui veut utiliser des fichiers de différents systèmes de stockage (du ZIP, du FTP, du HTTP(S), voire même du WebDAV). Bon, ben c’est pas compliqué, ne vous fatiguez pas à chercher … Allez voir tout de suite Commons VFS 2. C’est franchment très très pratique.

Pour copier un fichier d’un endroit à un autre (du moment qu’il existe un support pour le système de fichier), ou pour lire le contenu du fichier (éventuellement à l’aide de commons-io), voire même encore pour … en fait tout le reste, Commons VFS sera toujours là pour vous filer un coup de main.

Par contre, si à un moment vous voulez vous connecter à un serveur WebDAV, évitez l’implémentation par défaut, qui fait du bête parsing DTD, et écrivez votre FileProvider reposant (par exemple) sur Sardine (dont le seul aspect ridicule est le nom) qui utilise la DTD de WebDAV compilée avec JAXB pour offrir une implémentation qui déchire son macareux.

Lanterna

Admettons qu’on vous demande de faire une application pour terminal à peu près jolie, et qui fassent des trucs comme Ant ou Mavend e façon interactive. Vous feriez quoi ?

Vous seriez dans le caca, inutile de vous le cacher.

Eh bien si ça vous arrive, sachez que vous pouvez faire un truc à peu près sympa avec Lanterna.

Avec ça, vous pourrez peut-être pas copier les fichiers, ou exécuter du code, mais au moins ce sera joli … De toute façon, pour faire des trucs pratiques, les librairies Apache Commons sont bien pratiques (en particulier commons-io, commons-exec ou commons-vfs dans ces cas-là).

Et si vous vous demandez pourquoi je parle de tout ça, c’est à la fois pour donner un peu de vie à ce blog, mais aussi (et surtout) parce qu’il faut bien comprendre ce que veut dire « écosystème riche ». Et que la meilleure façon de le montrer, c’estd e lister toutes ces librairies que j’ai dans mon pom et qui servent à « presque » rien (sans même parler de ces plugins maven, hein)