Trois outils pour développeur : MailHog, Tokei et Pandoc

Posté par (page perso) . Édité par Davy Defaud, Nils Ratusznik et patrick_g. Modéré par patrick_g. Licence CC by-sa
51
9
avr.
2018
Ligne de commande

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.

L’interface Web de MailHog avec trois courriels capturés

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 dans tmp/cache et 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, \LaTeX, 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 \LaTeX. Ça m’a également servi, par le passé, pour convertir un wiki d’un format à un autre.

  • # Pandoc

    Posté par (page perso) . Évalué à 7 (+6/-1).

    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 . Évalué à 7 (+6/-0).

      Dans les points qui me chagrinent un peu dans ce logiciel, c'est […] surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !) […]

      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 :

      • moins d'une soixantaine si on veut le binaire pandoc
      • une dizaine de plus si on ajoute le binaire trypandoc

      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 pandoc pour compiler Pandoc comme dans le courriel de Matthias Kilian ; il est temps de rafraichir les workflows et de passer à cabal new-build pandoc et consorts.

      • [^] # Re: Pandoc

        Posté par (page perso) . Évalué à 3 (+2/-0). Dernière modification le 10/04/18 à 10:45.

        C'est bien de le défendre, mais pandoc est réellement un cauchemard de dépendences…. et c'est peu dire.

        moins d'une soixantaine si on veut le binaire pandoc

        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

        nix-store -q --graph /nix/store/6cq9d87vapf15rj7n5xjkr70sggx8dkf-pandoc-1.19.2.4.drv |wc
           6682   45656 1051320
        

        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 . Évalué à 2 (+1/-0).

          C'est un cauchemar de dépendences digne des pire paquets d'Haskell […] un petit nix-store -q --graph sur pandoc me donne […] un graph de + de 6500 dependances.

          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 (page perso) . Évalué à 3 (+2/-0).

            Parmi les 6500 dépendances, y aurait-il la glibc ou équivalent

            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

            nix-store -q --graph /nix/store/xb31y9cb9kh45xgqsjizkkc3ybspmjd1-doxygen-1.8.11.drv | wc
               1541   11527  232923
            
            
            
      • [^] # Re: Pandoc

        Posté par (page perso) . Évalué à 4 (+2/-0).

        nombre de dépendances directes

        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.

        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.

        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 (page perso) . Évalué à 6 (+5/-0).

    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 . Évalué à 2 (+2/-0).

    Merci, cela faisait longtemps que je cherchais un outil comme celui-ci. Et très performant qui plus est.

    • [^] # Re: Tokai

      Posté par (page perso) . Évalué à 4 (+2/-0).

      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

  • # Merci pour MailHog!

    Posté par (page perso) . Évalué à 5 (+4/-0).

    ç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 (page perso) . Évalué à 2 (+2/-0).

    Merci pour ce partage, mais…

    cloc utilise des expressions rationnelles, alors que Tokei a de vrais analyseurs

    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 ;).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.