Trois utilitaires : Delta, Dust et Watchexec

Posté par (page perso) . Édité par Xavier Teyssier, Benoît Sibaud et Davy Defaud. Modéré par Xavier Teyssier. Licence CC by-sa.
47
11
mai
2020
Ligne de commande

J’avais présenté, il y a quelque temps, trois utilitaires écrits en Rust pour remplacer grep, ls et find (à savoir ripgrep, exa et fd). Cette dépêche est l’occasion de présenter trois nouveaux utilitaires également écrits en Rust : delta, dust et watchexec.

delta

delta permet de mettre de la coloration syntaxique dans les diffs, et notamment ceux produits par Git. Il affiche avec un fond vert ce qui a été ajouté et avec un fond rouge ce qui a été supprimé, mais il met également en couleur les mots‑clés, opérateurs et structures propres à chaque langage de programmation. La coloration syntaxique provient de bat, et comme celui‑ci, il offre différents thèmes pour s’adapter aux goûts de chacun.

Capture d’écran de delta

Dust

Dust s’inspire de l’utilitaire du. Il apporte du confort quand on veut trouver quels répertoires prennent de la place, grâce à quelques astuces :

  • il fait automatiquement le tri, pas besoin de recourir à sort ;
  • il va également afficher les gros sous‑répertoires, pas seulement les répertoires de premier niveau ;
  • son affichage graphique permet de mieux voir où l’espace est pris.

Capture d’écran de Dust

watchexec

watchexec permet de lancer des commandes dès qu’un fichier est modifié. C’est pratique pour relancer des tests, une compilation ou un serveur pour un développeur. Il s’appuie sur inotify sous GNU/Linux et ses équivalents pour macOS et Windows. Voici quelques exemples d’invocation :

  • watchexec make permet de lancer la commande make dès qu’un fichier est ajouté ou modifié dans le répertoire courant ;
  • watchexec -w src -w spec rspec permet de lancer des tests avec rspec dès qu’un fichier présent dans src ou dans spec est modifié ;
  • watchexec -e py -r python server.py permet de lancer ou relancer un serveur Python dès qu’un fichier avec l’extension .py est modifié.

Aller plus loin

  • # Portabilité ?

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

    La semaine dernière justement j'ai regardé les différents outils de surveillance des systèmes de fichier… la plupart sont absolument importables puisqu'ils se basent sur inotify uniquement. Pourtant plein d'OS ont des fonctions équivalentes, à commencer par BeOS y a 20 ans déjà.

    Le seul que j'ai trouvé qui supporte à peu près tous les OS c'est fswatch. Enfin, il manque encore le support natif Haiku.

    J'ai rien contre Rust, au contraire, la sécurité c'est important, mais la portabilité aussi c'est important…
    Ah, visiblement watchexec supporte Win et OSX aussi, c'est déjà pas mal, mais il manque BSD… et Haiku, enfin pour l'instant.
    Et visiblement comme fswatch il a un fallback générique pour les autres plateformes, ça c'est bien, ça permet de l'utiliser quand-même !
    Du coup, avis aux BSDistes, Illumosiens… ;-)

    • [^] # Re: Portabilité ?

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

      Tu as testé watchexec sous Haiku ? A priori, il utilise le même mécanisme de polling comme fallback générique que fswatch.

      Plus généralement, la portabilité pour ce genre d'outils est compliquée. Chaque OS a une API propre, avec un mode de fonctionnement légèrement différent du voisin, mais ses différences rendent vraiment compliqué d'avoir un outil générique.

      Sous GNU/Linux, c'est inotify. On dit que l'on veut surveiller tout fichier ou répertoire et l'OS va nous envoyer des événements quand il y a des appels système qui concernent le fichier ou répertoire.

      Sous macOS, c'est fsevents : par rapport à inotify, les événements pour un même fichier sont regroupés quand ils arrivent suffisamment proches. Par exemple, on peut recevoir un événement pour un fichier avec des flags « fichier créé », « fichier modifié » et « fichier déplacé » pour un fichier temporaire.

      Sous Windows, ça s'appelle ReadDirectoryChangesW, et ça marche un peu comme inotify, mais en plus, il y a l'aspect recursif qui est pris en compte : quand on demande à surveiller un répertoire, on reçoit des événements quand un fichier dans un sous-sous-sous-répertoire est modifié (alors que pour inotify, il faut explicitement parcourir les sous-répertoires et mettre en place la surveillance de ces sous-répertoires). Par contre, dans les points négatifs, c'est plus compliqué de suivre les fichiers et répertoires déplacés.

      Sous BSD, c'est kqueue. Je n'ai pas pratiqué, mais j'ai entendu dire que c'était plus efficace comme alternative pour epoll que comme alternative à inotify.

      Pour Haiku et les autres, je ne saurais même pas dire ce qui est en place.

      • [^] # Re: Portabilité ?

        Posté par (page perso) . Évalué à 9 (+7/-0).

        Oui je sais que c'est compliqué, c'est moi qui ai écrit le support filewatcher Haiku pour le client owncloud…

        Malheureusement en effet aucune API de ce genre n'est standardisée, du coup on doit réinventer la roue (et parfois prétendre qu'on l'a trouvée en premier, comme avec le tickless :D). Sous BeOS le node_monitoring n'était pas récursif, donc sous Haiku on a fait une autre API en plus, plus flexible. De plus comme sous BeOS on peut avoir les notifications de modification des xattrs, mais bon, y a que nous qui les utilisons tfaçon les xattrs… Encore un truc pas standardisé, mais c'est une autre histoire, j'ai écrit un papier entier là dessus.

        Pas encore testé non, le seul truc que j'ai voulu tester en Rust sous Haiku c'était pas encore ça, je sais plus s'il manquait des dépendances ou si j'avais juste plus de place disque… Bon, le portage est encore jeune. Mais à priori avec un fallback sur stat() comme fswatch ça devrait marcher.

    • [^] # Re: Portabilité ?

      Posté par . Évalué à 2 (+1/-0).

      Je te conseille alors modd qui est écrit en go

      https://github.com/cortesi/modd

      Ce que j'aime est qu'il est configurable via un fichier de conf modd.conf, et tourne sous pas mal de différents OS (tous ceux supporté par Go en fait)

      • [^] # Re: Portabilité ?

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

        Oué, encore plus d'outils pour faire la même chose ;-)

        Ah, c'est un démon avec un fichier de conf… pas tout à fait le même type d'usage.

        Avec un truc comme fswatch, on lui passe le dossier courant en argument depuis un Makefile par exemple, et on lui demande d'appeler 'make', et on a une cible qui fait de l'intégration continue d'un simple 'make watch'.

  • # ncdu

    Posté par . Évalué à 10 (+14/-0).

    Je rappelle l'existence de ncdu qui permet de faire le bilan de l'espace disque utilisé. Il est mentionné sur la page de Dust, mais il permet surtout de faire la différence entre l'espace utilisé par les fichiers, et l'espace alloué par le système de fichiers. Ce qui peut être assez différent…

  • # A propos de dust

    Posté par . Évalué à 3 (+1/-0).

    Cet outil m'intéresse bien ; à mi-chemin du coup entre tree et du. Et du coup j'ai des questions.

    Quand on regarde la copie d'écran, où tu n'as tapé aucune option, on voit que le répertoire de départ apparaît en fin de liste. Je m'attendrais à l'inverse, d'autant que dans la doc, tu indiques qu'il y a une option "-r" qui met le répertoire racine en bas.

    Pour la représentation des barres, quelle est la signification des nuances de gris ?

    Et serait-il possible, pour les barres, de faire que visuellement elles soient séparées les unes des autres ? En utilisant par exemple un caractère comme le 25A0. Ca donne des trucs comme ça :

    80% ■■■■■■■■■■■■■■■■
    20% ■■■■

    Après, utiliser des caractères étendus dans la console, ça peut donner des trucs zarbs, hein. En option peut-être ?

    • [^] # Re: A propos de dust

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

      Je m'attendrais à l'inverse, d'autant que dans la doc, tu indiques qu'il y a une option "-r" qui met le répertoire racine en bas.

      Je ne suis pas l'auteur de ses outils, je ne fais que les présenter ici. L'option -r permet d'avoir le répertoire racine en haut. Je me serais également attendu à l'ordre inverse par défaut.

      Pour la représentation des barres, quelle est la signification des nuances de gris ?

      Ça permet juste de voir quels sont les sous-répertoires qui sont dans un même répertoire.

      Et serait-il possible, pour les barres, de faire que visuellement elles soient séparées les unes des autres ?

      Je ne vois pas d'option existante pour ça, mais si tu crées une issue sur github, l'auteur saura sûrement mieux te répondre que moi.

      • [^] # Re: A propos de dust

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

        Oups, désolé, j'ai cru que tu étais derrière la création de tout ça ! Evidemment, GitHub est sans doute le meilleur endroit pour lever ces points.

  • # rust

    Posté par . Évalué à -2 (+0/-4). Dernière modification le 12/05/20 à 07:34.

    J’avais présenté, il y a quelque temps, trois utilitaires écrits en Rust pour remplacer grep, ls et find (à savoir ripgrep, exa et fd). Cette dépêche est l’occasion de présenter trois nouveaux utilitaires également écrits en Rust : delta, dust et watchexec.

    Il y a une forme de fétichisme pour rust ?

    • [^] # Re: rust

      Posté par (page perso) . Évalué à 6 (+3/-0).

      Absolument pas. Je considère que Rust est un bon langage pour des choses de bas niveau où avoir un runtime important est un gros handicap. Je pense par exemple à l'écriture d'extensions pour des langages de script. Mais pour écrire un outil en ligne de commande, je préférerais d'autres langages comme Go ou Crystal. J'ai choisi les outils de cet dépêche parce que je les ai utilisés, pas spécialement parce qu'ils sont écrits en Rust.

      D'ailleurs, dans la première dépêche, j'écrivais :

      Un fait remarquable est que les trois outils présentés sont écrits en Rust. Il faut croire que ce langage convient bien pour écrire des outils en ligne de commande. C’est un domaine où le temps d’exécution est important (quand on lance une commande, c’est appréciable que le retour soit instantané ou en tout cas très rapide). Les langages de script (JavaScript, Ruby, Python) ont un temps de lancement de leur machine virtuelle qui peut casser cette impression de vitesse, je comprends donc que les développeurs d’outils en ligne de commande puissent s’en éloigner. En revanche, il est plus surprenant de ne pas retrouver d’outils en Go, en D, en OCaml ou en Haskell. Peut‐être que les lecteurs de LinuxFr.org auront une explication à cela.

      • [^] # Re: rust

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

        Je ne comprends pas trop ce que tu veux dire. Si je lance https://github.com/bdrung/startup-time avec une version actuelle (un container sous Debian 10), j’obtiens:

        Run on: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz | Debian GNU/Linux 10 (buster) | 2020-05-12
        C (gcc 8.3.0):            0.45 ms
        C++ (g++ 8.3.0):          1.58 ms
        Cython3 (cython3 0.29.2): 23.55 ms
        D (gdc 8.3.0):            5.13 ms
        Go (go go1.11.6):         1.42 ms
        Go_GCC (gccgo 8.3.0):     25.23 ms
        Haskell (ghc 8.4.4):      2.08 ms
        OCaml (ocamlc 4.05.0):    2.90 ms
        Pascal (fpc 3.0.4):       0.16 ms
        Rust (rustc 1.34.2):      1.12 ms
        Bash 5.0.3(1):            1.62 ms
        

        On voit que Rust est légèrement plus rapide (vu que c’est mon portable et qu’il y a d’autres trucs qui tournent dessus, on ne peut pas dire que c’est vraiment plus rapide mais que c’est dans le même ordre de grandeur). Donc, je ne vois pas pourquoi Rust serait un plus mauvais choix que Go pour la CLI.

        (tous les langages n’y sont pas, mais j’ai pris dès que j’avais les résultats pour Go et Rust)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: rust

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

          OK, mes explications ne devaient pas être très claires. Je vais essayer de faire mieux.

          Je considère qu'il y a deux groupes de langage pour faire un CLI : en gros, ceux qui peuvent faire un binaire rapide et facile à déployer, et ceux qui ont besoin de passer par un interpréteur qui va aller charger plusieurs modules, et va donc être à la fois plus compliqué à déployer et plus lent à charger. Et le premier groupe me paraît bien plus adapté pour des outils de type CLI.

          Go et Rust font parti de ce premier groupe. Mais, à l'intérieur de ce groupe, je suis surpris par la place que prend Rust alors que, si c'était moi avait dû choisir, je serais plutôt parti sur un langage avec un garbage collector, comme Go ou OCaml. J'ai du mal à voir quel avantage Rust a par rapport à Go ou OCaml pour un outil de type CLI. Je vois bien l'intérêt de Rust dans d'autres contextes, mais pour un CLI, je suis vraiment perplexe.

          Pourtant, j'observe que de plus en plus des outils récents de type CLI que j'utilise sont écrits en Rust, et j'imagine qu'il doit y avoir une raison derrière cela. Peut-être que c'est un effet de mode, peut-être qu'il y a une autre raison (un écosystème bien adapté ?), je ne saurais pas dire.

          • [^] # Re: rust

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

            La gestion de la mémoire pour un outil en CLI ne me semble pas particulièrement pénible en Rust (tu n'as pas vraiment le problème de plusieurs thread qui doivent accéder aux mêmes données). Donc je ne vois pas trop le problème.

            Après, pourquoi Rust plutôt que Go. Je dirais (mais c'est vraiment une estimation au doigt mouillé) qu'on est plus du côté système et donc plus proche du point fort de Rust qui "déborde".

            Pour OCaml, il semble un peu plus lent à l'exécution et culturellement moins orienté outils en CLI.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: rust

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

          D'ailleurs quelqu'un a une idée de pourquoi Free Pascal Compiler est beaucoup plus rapide que les autres ? J'ai cru à un effet de bord, mais c'est la même chose sur le site web du bench ; à tous les coups FPC est vainqueur et de loin.

          C'est con, j'ai arrêté le Pascal y'a plus de 15 ans !

          • [^] # Re: rust

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

            Il est compilé en statique comparé au C.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: rust

        Posté par . Évalué à 6 (+5/-0). Dernière modification le 12/05/20 à 12:19.

        Je ne connais pas Go, mais pour ce qui est de Rust, il existe des outils très chouettes pour faire des outils en CLI – je pense notamment à la bibliothèque Clap1, à mon sens assez géniale.

        Elle est utilisée notamment par Ripgrep, fd et watchexec.

        Peut-être que cela joue ?

      • [^] # Re: rust

        Posté par . Évalué à 3 (+1/-0).

        Il y a un glissement dans ta réflexion entre, « j'ai trouvé des outils en rust » et « rust doit être mieux que les autres pour des outils cli ».

        Si tu prendre d'autres exemples, par exemple httpie, vegeta et vtop. Ils sont écrit respectivement en python, go et js.

        Je suis d'accord qu'en principe l'absence de runtime rend le démarrage plus rapide et que ce temps de démarrage peut être désagréable. Personnellement sur PC et laptop je ressent pas le temps de démarrage de python ou go, sur rpi je trouve que python commence à se faire sentir.

        • [^] # Re: rust

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

          Je n'ai pas été clair, je ne prétends pas que Rust soit mieux que les autres langages pour faire un outil CLI. En fait, si je devais choisir un langage pour faire un tel outil, je prendrais très probablement autre chose que Rust : Go, OCaml ou Crystal.

          Je constate que les outils récents de type CLI que j'utilise sont quasiment tous écrits en Rust. Par récent, on va dire depuis 5 ans (ça correspond à peu près à la sortie de Rust 1.0). Les exemples que tu as donnés, httpie, vegeta et vtop, sont plus anciens et je ne les utilise pas (même si ça pourrait).

          Je cherche une explication à cette observation. D'un côté, je comprends que Python, Ruby et Node.js soit mal adapté pour des outils de type CLI : ils ont un temps de chargement qui peut se ressentir en ligne de commande, notamment quand ils chargent pas mal de modules, et c'est plus compliqué à installer qu'un simple binaire à télécharger. Mais de l'autre, pourquoi Rust est privilégié par rapport à Go et d'autres langages comparables, ça m'échappe. Mon choix serait au contraire de préférer l'aspect pratique d'avoir un garbage collector, avoir des goroutines et channels, etc.

          • [^] # Re: rust

            Posté par . Évalué à 9 (+8/-0).

            Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.

            Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.

            Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.

            De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
            J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
            Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
            Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.

            Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.

            A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
            ( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)

            Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
            Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.

            Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
            En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)

            Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
            C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.

            • [^] # Re: rust

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

              Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable

              J'avoue que quand j'ai commencé à m'intéresser à Rust il y a pas mal d'années, le fait que Mozilla ait abandonné pas mal de technos me faisait assez peur. J'ai l'impression qu'aujourd'hui le projet est nettement plus porté pas la communauté, ce qui est une bonne chose.

            • [^] # Re: rust

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

              Est-ce que les GC de Go/Crystal/OCaml/D… consomment forcément plus de mémoire que les pointeurs intelligents de Rust ?

              Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: rust

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

            J'imagine que pour des programmes relativement petits comme ceux présentés, même si Rust va rendre l'écriture plus difficile, cela reste de bons terrains de jeux pour essayer d'écrire une implémentation (quasi) optimale (un peu comme on s'amuserait à coder la partie critique d'un code en ASM).

            • [^] # Re: rust

              Posté par . Évalué à 1 (+2/-1).

              Je crois qu'il faut un peu démystifié cette image de complexité du Rust.

              Il y a un ticket initial de formation et un coût associé de développement un peu plus important lié à une rigueur du langage. Néanmoins, avec un peu d'habitude, tu apprends les bons paradigmes et, par la suite, tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…) ou à tenter de résoudre un obscur problème de concurrence que le caractère nazi t'empêchera de créer.

              Je suis persuadé que tu te retrouver dans des situations tout aussi compliquées d'un point de vue dév. avec du C++. Dans le cas de Rust, le compilateur t'oblige à gérer proprement la mémoire et la concurrence. Dans le cas de C++, tu créés un bug mémoire ou de concurrence et tu cherches à le débugger…

              Une petite comparaison pour la route:
              - des dév. capable d'écrire du Python exécutable, ça se trouve à tous les coins de rue ou presque ;
              - des dév. capable de me typer correctement du python, bien architecturé, qui passe les contrôles "qualité" et qui ne me fait pas un usage délibéré du duck-typing à tout va, c'est déjà plus compliqué, ça a un coût (en formation initiale et en dév.)

              En tout état de cause, quand tu commences un dév, tu choisis ton langage en prenant en compte les facteurs suivants:
              - est-ce que je connais, maîtrise et/ou désire apprendre le langage ;
              - quel son les coûts acceptables en dév. / maintenance, etc… ;
              - ai-je besoin d'une preuve de concept très rapide (Python?), la performance est-elle importante?
              - vais-je mettre le prix pour avoir un truc robuste ou puis-je me contenter d'un script "à l'arrache" sur un coin de table ?

              • [^] # Re: rust

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

                Je n'ai pas compris ce que tu cherches à démystifier. Le fait que Rust soit complexe ?

                Rust est un langage complexe (tout comme C++). C'est une complexité qui n'est pas là juste pour faire jolie, on se doute bien. Elle est là pour avoir un maximum de performances et une bonne stabilité.

                Mais, il n'y a pas que les deux extrêmes : des bidouilleurs qui font du Python et des développeurs super consciencieux qui font du Rust. Il y a un large spectre entre les deux, et on retrouve notamment Go dans cet entre-deux. Rust est bien plus complexe que Go, et je ne vois rien dans tes propos pour expliquer pourquoi Rust ne serait pas si complexe que ça pour des outils de type CLI, ou en quoi cette complexité apporte des choses.

                Tu évoques la gestion de la concurrence, mais Rust est loin d'être exemplaire dans ce domaine. Il n'interdit pas les deadlocks par exemple, contrairement à Pony et a un fonctionnement de plus bas niveau que d'autres langages, ce qui permet d'avoir des performances optimales mais a plutôt tendance à augmenter les risques de mal gérer ça. Les goroutines et channels sont plus faciles à apprivoiser que les futures et async/await. Et je ne parle même pas d'Erlang qui a, pour le coup, bien plus d'arguments à faire valoir sur ce domaine.

              • [^] # Re: rust

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

                Je crois qu'il faut un peu démystifié cette image de complexité du Rust.

                Du coup tu n'a pas démystifié sa complexité ; tu as expliqué qu'elle se justifiait à moyen et long termes. Ce avec quoi je suis tout à fait d'accord (c'était l'essence même de mon commentaire précédant).

              • [^] # Re: rust

                Posté par . Évalué à 1 (+0/-1).

                tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…)

                Pour moi ce n'est pas le langage qui permette ça. C'est plutôt le workflow de déploiement (les tests que tu fais avant déploiement, la solidité de ton déploiement, la simplicité du rollback,…).

                • [^] # Re: rust

                  Posté par . Évalué à 3 (+2/-0). Dernière modification le 13/05/20 à 23:50.

                  Ouais, enfin l'un n'empêche pas l'autre.

                  Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.

                  La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
                  La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)

                  Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).

                  • [^] # Re: rust

                    Posté par . Évalué à 3 (+2/-1).

                    Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.

                    Je ne suis pas d'accord. Ça joue sur lors du développement. Si tu laisse passer un problème de typage en prod, le problème c'est pas le langage, c'est la qualité que tu livre. L'effort pour fournir la même qualité ne sera effectivement pas la même, mais hors cas pathologique (comme ce pourquoi a était fait rust pour remplacer c++), la différence ne sera pas si grande.

                    La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.

                    Tu parle de prod, parler de prod sans parler d'opérationnel, ça n'a pas de sens. Mais surtout si la prod est le problème du développeur alors son déploiement aussi. Sinon le fait que la prod tombe le vendredi à 18h ça n'est pas son problème.

                    La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)

                    Donc c'est bien une question de qualité de ce que tu livre. Mais les prods les plus solides vivent avec le fait qu'ils casseront leur prod. Parce qu'il est humainement impossible d'avoir un niveau de test suffisant pour garantir que tu ne casse jamais. Ça ne veut pas dire que tu ne va pas tout faire pour améliorer ta qualité, mais tu sais que reproduire la charge de ta prod est impossible par exemple. C'est pour que les canary release ou l'A/B testing existent.

                    Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).

                    Il faut les twelve factors et oui on est d'accord, mais dans tout ça il n'y a pas le typage de ton langage.

                    Je vais le dire autrement…

                    Tu veux fournir de la qualité. Tu as 2 stratégies possibles. Soit tu embauche les meilleurs développeurs possibles et ils choisissent le meilleur langage existant et code un excellent logiciel. Tout repose sur la qualité de chacun des développeurs. Soit tu cherche à avoir une qualité « systémique », c'est l'organisation de l'équipe qui produit de la qualité. C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité. Cette seconde stratégie est plus fiable car elle ne repose pas sur un recrutement trop complexe et est résiliente aux faiblesse ponctuelles qu'auront les développeurs.

                    Bref tout ça pour dire que les typages dynamiques et pire encore les typages faibles, je suis pas fan du tout, mais je ne les prendrais pas comme boucs émissaires en cas de problème en prod.

                    • [^] # Re: rust

                      Posté par . Évalué à 6 (+5/-0). Dernière modification le 14/05/20 à 13:58.

                      En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.

                      1. tout le monde ne travaille pas en équipe ou si c'est le cas en inter-dépendance.
                      2. une mise en prod n’inclus pas foncièrement un déploiement complexe : à la base, on parle d'un soft en cli donc le déploiement c'est création d'un exécutable. tous les projets ne sont pas forcément orienté "software as a service".
                      3. dans une grande structure, tu as souvent une panoplies de rôles : dba, admin sys, devops, archi etc. certaines responsabilités porté par des devs dans certaines boites ne le sont pas dans d'autres
                      4. les devs ne choisissent que rarement la stack (ou l'intégralité), langage y compris.
                      5. un worflow tel que tu le décris (canary release, AB test) a un coût matériel et humain loin d'être négligeable.
                      6. c'est quoi un bon dev ? C'est tellement subjectif. Un workflow bien millimétré, ça nécessite d'embaucher des gens qualifiés (ou les former) donc on peut les classer dans la case des "bons devs".

                      Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
                      et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.

                      Tout dépend de ce que tu produits.
                      Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
                      Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
                      Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.

                      J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
                      Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
                      Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
                      mais on limite vachement les risques, c'est mathématique.
                      Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
                      J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?

                      Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.

                      La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
                      Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
                      pourquoi c'est arrivé et comment on évite à l'avenir.
                      Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
                      En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.

                      Faut avoir un outil de rollback simple mais coder comme si il était impossible.

                      [quote]
                      C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
                      [/quote]

                      Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
                      Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
                      Tout ce qui n'est pas testé n'est pas contractuel.
                      Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.

                      La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
                      Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.

                      Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
                      Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
                      Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.

                      Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
                      Limite, c'est un autre métier.
                      Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
                      Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.

                      En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
                      Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
                      Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.

                      • [^] # Re: rust

                        Posté par . Évalué à 3 (+1/-0).

                        En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.

                        C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,…) que tu es entrain de remettre en cause dans ce commentaire.

                        Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.

                        Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.

                        Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.

                        J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.

                        La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
                        Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
                        pourquoi c'est arrivé et comment on évite à l'avenir.
                        Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.

                        Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.

                        En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.

                        Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.

                        Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.

                        Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.

                        Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.

                        Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,… C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.

                        • [^] # Re: rust

                          Posté par . Évalué à 1 (+0/-0). Dernière modification le 15/05/20 à 12:08.

                          Je n'ai jamais parlé d'une prod qui casse un vendredi.
                          Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
                          Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.

                          Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
                          tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)

                          Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
                          Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
                          L'objectif est le même : prévenir plutôt que guérir.

                          Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
                          Le rollback c'est le joker au cas ou.
                          Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.

                          Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
                          T'as plein de cas ou tu ne peux pas te permettre ce luxe.
                          qlqs exemples loin d'être exhaustif :
                          - chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
                          - tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
                          - tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.

                          Le rollback, pour moi, c'est du travail dans l'urgence.
                          Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.

                          Je n'ai jamais vu ce type de bug arriver dans une prod.

                          Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
                          Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".

                          Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
                          Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
                          Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
                          Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.

                          Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
                          C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.

                          Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
                          C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).

                          Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
                          Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.

                          En client/serveur toujours, on parle de plus en plus d'isomorphisme.
                          Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.

                          Je n'ai jamais remis ça en cause.

                          Je ne fait pas que de l'antithèse.

                          • [^] # Re: rust

                            Posté par (page perso) . Évalué à 4 (+1/-0). Dernière modification le 15/05/20 à 13:40.

                            Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
                            tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)

                            J'en ai vu aussi, ce n'est pas pour ça que je design mes systèmes pour ce cas-là. Parce qu'il y a déjà trop de problème quand on est dans cette situation.

                            Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.

                            Si tu as suffisamment de test, tu n'as pas peur de la prod.

                            • chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.

                            Tu peux très bien designer ta migration pour être transparente. Soit tu duplique tes colonnes (soit via une procédure de la db, soit via l'application), et puis une fois que c'est migré, tu switch ton application. Soit tu as du schemaless et tu peux faire ton changement dans l'application. Le but c'est que ton application en version n-1 et n puisse accéder à la db, donc tu peux déployer tranquillement la nouvelle version et revenir en arrière de manière transparente.

                            • tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.

                            Ça ne dépend pas de ton application. Normalement, tu as pu tester ton webservice avant et ton application peut gérer les deux versions et au moment où le webservice change, tu changes juste la config de ton application pour utiliser le nouveau. Après, pour les webservices bien fait, tu auras les deux versions en parallèle pendant un certain temps et tu pourras switcher sur le nouveau et revenir en arrière sur l'ancien pendant cette période.

                            • tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.

                            Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.

                            Le rollback, pour moi, c'est du travail dans l'urgence.

                            Tu sais qu'il y a des systèmes qui font des rollback automatiquement ? En fonction des métriques de l'application (par exemple le nombre d'erreur 500, une baisse du nombre de requêtes…)

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: rust

                              Posté par . Évalué à 2 (+1/-0).

                              Si tu as suffisamment de test, tu n'as pas peur de la prod.

                              Entièrement dac. (c'est les tests, pas la capacité de rollback)

                              Tu peux très bien designer ta migration pour être transparente…

                              Je connais et applique tout ça.
                              Ca complexifie et l'expérience m'a montré que ça n'évite complètement les ratés.
                              Rien n'est parfait.

                              Sur des langage comme Rust, tu peux rendre l'ensemble de la base typé et amorcer des migrations ou tu peux garantir que les requètes avant et après migrations soient safe.

                              On en revient au point initial : un vrai truc typé de bout en bout t'évites d'envoyer de la merde en prod.

                              Normalement, tu as pu tester ton webservice

                              Normalement, un WS est versionné et tu peux passer de l'un à l'autre.
                              Le soucis c'est bien le "normalement" et le "bien fait". Si t'es consommateur, tu subis.

                              Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.

                              Dans l'absolu : oui. Mais la réalité fait que tu travailles sur du legacy ou tout n'est pas forcément possible aussi facilement.

                              Tu sais qu'il y a des systèmes qui font des rollback automatiquement ?

                              Alors, oui. Bon, j'appel pas ça du rollback : t'as plusieurs versions de ton app/fonctionnalité et t'as des triggers en fonction de.

                              Ça peut être un vrai serpent de mer à plusieurs têtes si tu mets ça partout.
                              Comme souvent : faut savoir utiliser la bonne stack en fonction des besoins, ressources etc.
                              Ça peut être dur de trouver le bon curseur de déclenchement. faut que les métriques ne tombent pas, qu'elles soient temps réels etc.
                              Bref : du cas par cas.

                          • [^] # Re: rust

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

                            Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
                            tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)

                            Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire. C'est juste le droit de travail. Être totalement hors des clous comme ça ce n'est même pas légal. C'est pas une question d'aimer le travail bien fait ou la passion pour ce qu'on fait. Accepter de travailler dans ces conditions et en plus considérer cela comme normal (pointer comme un quelqu'un qui ne veux pas s'engager et prendre pour soit le résultat de cet état de fait), ça dévalue ton travaille.

                            • [^] # Re: rust

                              Posté par . Évalué à 1 (+0/-0).

                              Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire.

                              Oula, tu fais des déductions rapides quand même là…

                              J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?

                              • [^] # Re: rust

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

                                Quand je dis qu'une prod avec SLA ou du moins dont les gens veulent une disponibilité 24/7, ce qui me semble être sous-entendu par « la prod tombe le vendredi soir », demande un travail en équipe, des astreintes,… Tu me répond que je suis dans ma tour d'ivoire. Tu peux me dire que non c'est une prod qui n'est pas 24/7, mais du coup tu n'a pas à t'en occuper après ta journée de travail comme tu le dis dans le premier commentaire au quel je répond.

                                J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?

                                Vouloir une prod 24/7, c'est avoir quelqu'un qui régis aussi vite que possible aux problèmes. C'est ce dont tu parle dans ton premier commentaire : je ne l'invente pas. Ça s'appelle une astreinte et tu as légalement un quota d'heure d'astreinte limite donc tu dois travailler en équipe.

                                S'il s'agit d'une prod non 24/7, c'est en effet légal. Mais faut déclarer ses heures sup' ou que ce soit dans le cadre du forfait cadre et il faut surtout éviter de responsabiliser l'employé pour des défauts de la prod. L'importance de cette prod doit venir avec des moyens équivalents. Mais ça c'est juste une remarque.

                                La logique derrière ton allégorie de « la prod qui tombe à 18h » me semble être l'une des 2. Évidement je peux me tromper et évidement en ayant la facilité d'imaginer qu'une prod était généralement 24/7, j'ai suivi un raccourcis.

                                • [^] # Re: rust

                                  Posté par . Évalué à 1 (+0/-0). Dernière modification le 15/05/20 à 20:49.

                                  Oui, on ne parle de la même chose.
                                  Quand je parlais de prod c'était très large.
                                  ça peut être fournir un exe, un intranet : dans une de mes anciennes boite, on mettais à jour des apps web dans un intranet qui était dispo h24 mais le soir et week-end, c'étais leur service info interne qui assurait les astreintes.
                                  Après, le cadre légal, c'est pas vraiment mon job…

                                  Je pense aussi que tu me réponds comme si j'étais l'auteur du tout premier commentaire qui parle de l'allégorie de la prod qui tombe à 18h.

                            • [^] # Re: rust

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

                              J'ai l'impression que vous ne parlez pas de la même chose. Pour toi, avoir une prod a l'air d'impliquer des SLA, et dans ce contexte, travailler en équipe est effectivement une obligation.

                              Mais, il existe d'autres contextes. Par exemple, flus est un service avec une seule personne derrière et ça reste parfaitement légal. Et si sa prod tombe le vendredi à 18h, je pense qu'il aura à cœur de la réparer rapidement, même s'il n'a aucune obligation.

                              • [^] # Re: rust

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

                                Je ne connaissais pas flus merci pour le lien :) et oui effectivement c'est ce que je décris un peu plus haut.

      • [^] # Re: rust

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

        Il faut croire que ce langage convient bien pour écrire des outils en ligne de commande.

        Parce qu'il n'y a pas de gtk/qt/tk/… en pur Rust ? :-)

        Incubez l'excellence sur https://linuxfr.org/board/

  • # diff, git, delta

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

    delta permet de mettre de la coloration syntaxique dans les diffs, et notamment ceux produits par Git.

    Pour info, git peut produire un tel diff en dehors de tout repo git.
    Titre de l'image

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: diff, git, delta

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

      Regarde la différence, le diff git classique donne de la couleur mais pas de la coloration syntaxique.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Envoyer un commentaire

Suivre le flux des commentaires

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