Dans cette dépêche, je vais vous présenter trois outils que j’utilise de temps en temps et qui pourraient servir à d’autres développeurs :
- MailHog permet d’attraper des courriels pour les examiner ;
- Tokei compte les lignes de code d’un projet ;
- Pandoc est un couteau suisse pour manipuler des fichiers et les transformer d’un langage de balisage à un autre.
MailHog
MailHog (sous licence MIT) permet d’attraper des courriels envoyés par une plate‐forme de développement et de les afficher dans une interface Web. Pour cela, il fournit un serveur SMTP et un remplaçant au binaire sendmail, libre à vous de choisir le moyen qui vous convient le mieux. Il offre également, en option, la possibilité de transférer vers un vrai serveur SMTP les courriels et un outil de type chaos-monkey pour tester les cas d’erreurs d’envoi de courriels.
Je m’en sers quand je développe sur la partie serveur de Cozy Cloud. Cela permet de tester des fonctionnalités qui nécessitent l’envoi de courriels sans avoir à se compliquer la vie à configurer un vrai serveur d’envoi de courriels. En bonus, on évite de prendre le risque d’envoyer des courriels vers de vrais comptes d’autres personnes et on ne perd pas de temps à attendre que le courriel arrive, en attente d’un traitement anti‐pourriel.
Tokei
Pour estimer la taille d’un projet, le nombre de lignes de code peut être une métrique intéressante. Il existe plusieurs projets pour faire ça, celui que je trouve le plus pratique est Tokei (sous licence Apache ou MIT). Voici ce qu’il affiche pour le dépôt principal de code de LinuxFr.org :
-------------------------------------------------------------------------------
Language Files Lines Code Comments Blanks
-------------------------------------------------------------------------------
CoffeeScript 10 770 642 31 97
Dockerfile 1 70 49 4 17
HTML 24 2660 2161 4 495
JavaScript 11 2686 2025 394 267
Markdown 1 187 187 0 0
Rakefile 2 33 24 3 6
Ruby 262 11593 8338 1500 1755
Ruby HTML 1 47 46 0 1
Sass 47 27317 23467 1583 2267
Shell 4 68 50 4 14
SVG 41 10886 10865 17 4
TeX 1 53 43 0 10
Plain Text 44 531 531 0 0
XML 1 11 11 0 0
YAML 4 173 160 4 9
-------------------------------------------------------------------------------
Total 454 57085 48599 3544 4942
-------------------------------------------------------------------------------Par rapport à cloc, Tokei a plusieurs avantages :
- il est beaucoup plus rapide (0,03 seconde pour Tokei contre 3,2 secondes pour cloc sur le dépôt principal de LinuxFr.org) ;
- il est plus précis : cloc utilise des expressions rationnelles, alors que Tokei a de vrais analyseurs (en particulier, un début de commentaire dans une chaîne de caractères comme
printf("/*")peut bien induire en erreur cloc) ; - il ignore par défaut les fichiers listés dans
.gitignore(par exemple, quand j’ai lancé cloc sur l’exemple ci‐dessus, il a compté les fichiers danstmp/cacheet j’ai dû le relancer avec des options pour qu’il fasse ce que j’en attendais).
Pandoc
Il existe de nombreux langages de balisage : HTML, Markdown, reStructuredText, textile, DocBook, 
, MediaWiki markup, OrgMode, EPUB, etc. Et ces langages ont parfois plusieurs variantes (exemple : CommonMark et GitHub Flavored Markdown pour le Markdown). Bref, ce n’est pas toujours facile de connaître les différents langages et de passer de l’un à l’autre. Pandoc (sous licence GPL v2 ou plus) permet de convertir un texte de la plupart de ces langages vers un autre langage, ou d’autres choses comme du PDF ou de l’OpenDocument.
Je m’en sers, par exemple, pour écrire des présentations en Markdown et en générer une version PDF via la classe Beamer pour . Ça m’a également servi, par le passé, pour convertir un wiki d’un format à un autre.
# Pandoc
Posté par anaseto . Évalué à 7.
Pandoc est en effet devenu assez impressionnant avec le temps et extrêmement complet pour transformer entre langages de balisage légers et de là vers d'autres formats. L'auteur du logiciel est d'ailleurs, me semble-t-il, la personne la plus impliquée dans l'effort de standardisation de Common Mark (même si pandoc offre par défaut beaucoup d'extensions sur celui-ci, plus que toute autre implémentation du langage).
La lecture de formats plus complexes comme LaTeX n'est pas contre pas très fiable (même si ça s'améliore avec le temps j'imagine), ni bien définie : il faut vérifier le résultat à la main et ajuster le LaTeX pour rester dans le sous-ensemble géré — ce qui n'est pas évident, car ce n'est pas quelque chose de bien défini (définir de façon concise un sous-ensemble de LaTeX, c'est peine perdue) et qui pourra difficilement devenir complet, vu que le langage utilisé en interne est (et doit être) beaucoup plus pauvre que LaTeX.
Dans les points qui me chagrinent un peu dans ce logiciel, c'est qu'il est assez lent (pas gênant pour de petits documents ou si on va exécuter LaTeX de toutes façons après), et surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !), qui fait que je ne me risquerais pas à dépendre de ce logiciel pour un truc important que je voudrais pérenne.
[^] # Re: Pandoc
Posté par gipoisson . Évalué à 7.
Factuellement, les courriels de Matthias Kilian et d'Ingo Schwarze ne sont pas corrects quant au nombre de dépendances directes de Pandoc car celui-ci n'atteint pas la centaine :
Néanmoins, l'histoire est tout autre si l'on ajoute les dépendances transitives ; mais dans ce cas, on arrivera à bout du compte à reprocher à Pandoc de dépendre de la glibc et équivalents :)
Au-delà de cette banale comptabilité, la vraie question consiste dans le pourquoi de toutes ces dépendances et la réponse est donnée dans l'aide du logiciel : “Pandoc includes a Haskell library and a standalone command-line program. The library includes separate modules for each input and output format, so adding a new input or output format just requires adding a new module.” que je traduis de la sorte :
« Le projet Pandoc englobe une bibliothèque et un binaire à lancer sur la ligne de commandes. La bibliothèque se sert d'un module dédié afin de traiter chaque format d'entrée (respectivement de sortie) […] »
Généralement, les modules Haskell suffisamment distincts les uns des autres se retrouvent dans des paquets différents. Vu la quantité de formats que supporte Pandoc et sans parler des extensions (à la fois celles mentionnées dans la dépêche et celles-ci), il n'est pas étonnant d'avoir des dizaines de paquets comme dépendances.
Cela dit, étant donné à qui je répond, je n'ai pas de doute que ma logorrhée supra est superflue, la personne en question étant sans doute déjà au courant de tout ça. Peut-être que la partie citée au début de ce commentaire était sarcastique. Plus important, en 2018, on ne devrait plus utiliser
cabal install pandocpour compiler Pandoc comme dans le courriel de Matthias Kilian ; il est temps de rafraichir les workflows et de passer àcabal new-build pandocet consorts.[^] # Re: Pandoc
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 10 avril 2018 à 10:45.
C'est bien de le défendre, mais pandoc est réellement un cauchemard de dépendences…. et c'est peu dire.
Binaire oui peut être… mais compiler pandoc est une autre histoire.
C'est un cauchemar de dépendences digne des pire paquets d'Haskell, à tel point que j'ai des configuration spécifique pour le désactiver à la demande dans la stack que je déploie….. Car la simple compilation de pandoc et de toutes ses deps prends un peu prêt 2h from scratch.
un petit nix-store -q --graph sur pandoc me donne
Soit un graph de + de 6500 dependances.
A titre de comparaison, un serveur web complet comme nginx retourne environ ~2000. Incluant même perl, les autotools et GCC nécessaire à le compiler…
Ceci dit ça n’enlève rien au fait que ça soit un excellent tool.
Et qu'au passage, l'explosion des dépendance semble être une spécificité de beaucoup de documentation generator, Sphinx n'étant pas beaucoup mieux.
[^] # Re: Pandoc
Posté par gipoisson . Évalué à 2.
Il y a tout sauf de l'hyperbole dans cette citation :) Parmi les 6500 dépendances, y aurait-il la glibc ou équivalent ?
Plus sérieusement, ma réponse initiale concernait les propos d'anaseto et Ingo Schwarze qui parlaient de façon on ne peut plus claire de dépendances directes. Matthias Kilian a même dû s'assurer de désinstaller toute autre chose différente de GHC & cabal pour être sûr de ne tirer que le strict minimum Haskell requis à la compilation de Pandoc.
[^] # Re: Pandoc
Posté par Firwen (site web personnel) . Évalué à 3.
Nix retourne toujours toutes les dépendences jusqu'a la libc, donc oui.
A titre de comparaison voilà celui de doxygen, incluant aussi jusqu'a la libc
[^] # Re: Pandoc
Posté par anaseto . Évalué à 4.
Je pense que personne ne voulait faire référence aux dépendances directes, mais bien aux dépendances vers des paquets Haskell (directes ou indirectes, sans compter les paquets standard qui viennent avec GHC), qui sont au moins au nombre de cent.
Mais c'est plus une observation qu'une critique en ce qui me concerne, au sens, si un jour Haskell devient très populaire et tous les OS disposent de suffisamment de main d'œuvre pour assurer un support de base fiable de tous ces paquets, ça deviendra raisonnable pour plus de monde, comme pour d'autres logiciels connus en C/C++/Python/… tout sauf minimalistes et avec beaucoup de dépendances. En attendant, il faut juste être conscient que dépendre de pandoc est un choix personnel, dans le sens où ça ne me surprendrait pas que sur un OS ou distrib donnée, des difficultés empêchent occasionnellement d'utiliser le logiciel pendant plusieurs semaines/mois/années — si j'ai fui pandoc il y a déjà quelques années, c'était en partie parce que je me suis justement retrouvé à ne pas réussir à le compiler sous OpenBSD à un moment donné et que je n'ai pas suffisamment l'âme d'un packageur pour y passer des heures et des heures.
En effet, ce n'est pas étonnant, il s'agit plutôt d'un choix, typique pour des logiciels dans des langages comme Haskell/Python/Perl/Javascript : priorité à intégrer un maximum de fonctionnalités en réutilisant ce qui est fait ailleurs (même de tous petits paquets), même si ça explose le nombre de dépendances. Ça a du bon comme du mauvais.
# Merci pour MailHog
Posté par vaceletm (site web personnel) . Évalué à 6.
Je ne connaissais pas MailHog, c'est top et super facile à déployer sur une stack de dev déjà basée sur Docker.
Exemple en sur la base de code de Tuleap entre 2 meeting du lundi matin.
# Tokai
Posté par Thooams . Évalué à 2.
Merci, cela faisait longtemps que je cherchais un outil comme celui-ci. Et très performant qui plus est.
[^] # Re: Tokai
Posté par Ontologia (site web personnel) . Évalué à 4.
Il y a sloccount aussi, qui calcul le cout de développement de son code. Assez marrant
A quoi correspond le code de type Sass dans le code linuxfr ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tokai
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Sass est le préprocesseur pour les feuilles de styles (CSS).
# Merci pour MailHog!
Posté par toctoc1 . Évalué à 5.
ça tombe à pic, je cherchais un truc pour tester la fonction de mail de Kanboard, sur des machines non pourvues de serveur mail.
En plus, y'a des binaires pour win32 et win64. TOP.
# préciser la comparaison.
Posté par Selso (site web personnel) . Évalué à 2.
Merci pour ce partage, mais…
une expression rationnelle reste une méthode d'analyse après tout.
A préciser donc : "… lexicaux et syntaxiques" ?
Cela serait intéressant que tu explicites ce que tu sais ;).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.