Humans come first, machines second. The most simple and straightforward heuristic for whether a particular output stream (stdout or stderr) is being read by a human is whether or not it’s a TTY.
Je hais tous ces scripts qui mettent une tonne de couleur, de bannières, d'emojis, de symboles. Si seulement ces gens savaient que parfois ça finit dans des fichiers ou dans un | grep. Je vise personne
Make it easy to see the current state of the system. If your program does a lot of complex state changes and it is not immediately visible in the filesystem, make sure you make this easy to view.
Je suis étonné qu'ils choisissent git status comme example, le format de sortie est beaucoup trop verbeux comparé à un hg status ou son équivalent avec l'antédiluvien svn.
Use symbols and emoji where it makes things clearer.
Au secours, voir au dessus.
Use a pager (e.g. less) if you are outputting a lot of text.
Bah non. Je t'ai pas demandé de lancer un pager pour moi. Tu vas imprimer la documentation par défaut aussi ?
En partant de la fin, voici mes bémols et amendements qui n’engagent que moi.
Ça honnêtement, c'est pas ton problème. Tu utilises le gestionnaire de paquet ou des solutions existantes pour les autres systèmes.
Vous n’êtes pas en contradiction. Si un programme est bien empaqueté pour ta distribution, alors il est facile de l’installer et de « Make it easy to uninstall. » À l’inverse, quand un programme s’installe par un « curl … | bash » et en fout partout dans l’arborescence sans même prévoir un « uninstall » (pour rester dans l’esprit fenêtré) ; ou quand bien qu’utilisant le gestionnaire de paquets fait des opérations post-installatoires mais ne prévoit pas de nettoyer son merdier quand on désinstalle ; etc, c’est vraiment problématique et c’est ce qui est pointé.
Bah non. Je t'ai pas demandé de lancer un pager pour moi. Tu vas imprimer la documentation par défaut aussi ?
Si tu lis bien, on est dans le contexte « interactif » et dans lequel des gens peuvent être sur de vrais terminaux (ce n’est pas parce-que toi tu simules un dans une fenêtre avec des ascenseurs que c’est le cas de tout le monde.) Un exemple tout con : quand avec mailx je lis un message qui est trop long, j’apprécie que le truc ne soit pas balancé à la gueule et qu’il ne me reste que la fin dans la tronche, avoir le temps de lire chaque écran puis d’appuyer sur la barre d’espacement pour passer à l’écran suivant est appréciable. La même chose s’applique quand je fais un git log ou un git diff par exemple.
Encore une fois, il faut tenir compte du contexte : on est en mode interactif, et quand je « pipe » les mêmes commandes (ou quand il n’y a pas de terminal interactif connecté —cas dans ta CI/CD par exemple) bah ce n’est pas paginé. Et ça rejoint ce qui est dit au début de savoir mettre les usagers au centre. Il est aussi dit plus loin qu’il faut prévoir de pouvoir désactiver la chose ou mieux de pouvoir configurer la sortie non interactive (json/table/etc.)
Cela rejoint le premier point : « The most simple and straightforward heuristic for whether a particular output stream (stdout or stderr) is being read by a human is whether or not it’s a TTY. » Il est clairement dit qu’il faut distinguer quand on est en usage interactif ou non.
Je hais tous ces scripts qui mettent une tonne de couleur, de bannières, d'emojis, de symboles. Si seulement ces gens savaient que parfois ça finit dans des fichiers ou dans un | grep. Je vise personne
Si npmjs respectait ces préconisations, alors certains trucs juste visuels seraient désactivé quand on est dans une exécution sans affichage ou dès qu’il y a >… ou |… par exemple. GNU GREP fait exactement cela, et si la détection n’est pas bonne ou si tu forcer un autre comportement tu as l’option --color et c’est là le propos de l’article.
Concernant les couleurs et les émojis, il n’est pas dit d’en mettre des tonnes mais que ces éléments peuvent aider …si bien utilisés (donc avec parcimonie et ce doit être configurable et débrayable/embrayable quand c’est présent) ça aide bien beaucoup de gens (les autres encore une fois devraient pouvoir désactiver : qui peut le plus doit pouvoir le moins, c’est à cela que l’on reconnait un bon programme.) La capture d’écran suivante est pour moi un des cas où c’est bien fait : on n’a que quatre couleurs et dans le flot on sait repérer rapidement les « failed » du fait de leur couleur ; et ces couleurs ne finissent pas dans ton fichier quand tu log la chose.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Moui
Posté par David Demelier (site web personnel) . Évalué à 6 (+5/-1).
Je hais tous ces scripts qui mettent une tonne de couleur, de bannières, d'emojis, de symboles. Si seulement ces gens savaient que parfois ça finit dans des fichiers ou dans un
| grep. Je vise personneJe suis étonné qu'ils choisissent
git statuscomme example, le format de sortie est beaucoup trop verbeux comparé à unhg statusou son équivalent avec l'antédiluviensvn.Au secours, voir au dessus.
Bah non. Je t'ai pas demandé de lancer un pager pour moi. Tu vas imprimer la documentation par défaut aussi ?
Bonne chance, mais je soutiens l'idée.
Ça honnêtement, c'est pas ton problème. Tu utilises le gestionnaire de paquet ou des solutions existantes pour les autres systèmes.
Il y a du bon et du pas bon dans cet article mais il est trop subjectif.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Moui
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 9 (+7/-0).
En partant de la fin, voici mes bémols et amendements qui n’engagent que moi.
Vous n’êtes pas en contradiction. Si un programme est bien empaqueté pour ta distribution, alors il est facile de l’installer et de « Make it easy to uninstall. » À l’inverse, quand un programme s’installe par un «
curl … | bash» et en fout partout dans l’arborescence sans même prévoir un « uninstall » (pour rester dans l’esprit fenêtré) ; ou quand bien qu’utilisant le gestionnaire de paquets fait des opérations post-installatoires mais ne prévoit pas de nettoyer son merdier quand on désinstalle ; etc, c’est vraiment problématique et c’est ce qui est pointé.Si tu lis bien, on est dans le contexte « interactif » et dans lequel des gens peuvent être sur de vrais terminaux (ce n’est pas parce-que toi tu simules un dans une fenêtre avec des ascenseurs que c’est le cas de tout le monde.) Un exemple tout con : quand avec
mailxje lis un message qui est trop long, j’apprécie que le truc ne soit pas balancé à la gueule et qu’il ne me reste que la fin dans la tronche, avoir le temps de lire chaque écran puis d’appuyer sur la barre d’espacement pour passer à l’écran suivant est appréciable. La même chose s’applique quand je fais ungit logou ungit diffpar exemple.Encore une fois, il faut tenir compte du contexte : on est en mode interactif, et quand je « pipe » les mêmes commandes (ou quand il n’y a pas de terminal interactif connecté —cas dans ta CI/CD par exemple) bah ce n’est pas paginé. Et ça rejoint ce qui est dit au début de savoir mettre les usagers au centre. Il est aussi dit plus loin qu’il faut prévoir de pouvoir désactiver la chose ou mieux de pouvoir configurer la sortie non interactive (json/table/etc.)
Cela rejoint le premier point : « The most simple and straightforward heuristic for whether a particular output stream (stdout or stderr) is being read by a human is whether or not it’s a TTY. » Il est clairement dit qu’il faut distinguer quand on est en usage interactif ou non.
Si npmjs respectait ces préconisations, alors certains trucs juste visuels seraient désactivé quand on est dans une exécution sans affichage ou dès qu’il y a
>…ou|…par exemple. GNU GREP fait exactement cela, et si la détection n’est pas bonne ou si tu forcer un autre comportement tu as l’option--coloret c’est là le propos de l’article.Concernant les couleurs et les émojis, il n’est pas dit d’en mettre des tonnes mais que ces éléments peuvent aider …si bien utilisés (donc avec parcimonie et ce doit être configurable et débrayable/embrayable quand c’est présent) ça aide bien beaucoup de gens (les autres encore une fois devraient pouvoir désactiver : qui peut le plus doit pouvoir le moins, c’est à cela que l’on reconnait un bon programme.) La capture d’écran suivante est pour moi un des cas où c’est bien fait : on n’a que quatre couleurs et dans le flot on sait repérer rapidement les « failed » du fait de leur couleur ; et ces couleurs ne finissent pas dans ton fichier quand tu log la chose.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.