Un commit est un diff + une référence sur son ou ses parents.
Évidemment, mais d’expérience ce point pose moins de problème qu’une branche. J’ai rarement croisé des gens qui avaient du mal à comprendre ce qu’est un commit Git ; par contre, des gens qui sont persuadés que « Une branche c’est un historique linéaire de commits » (ou quelque chose d’approchant), c’est extrêmement fréquent.
Pour le reste, à partir du moment où tu en es à « capitaliser sur ta connaissance de ZSH », tu n’est probablement pas dans la cible du billet.
Par contre, un point qui visiblement est mal compris de ce billet et qui transparait dans ce que je comprends de tes remarques : le but du billet n’est absolument pas de dire « Utilisez une GUI pour utiliser Git, c’est plus simple, quitte à rester coincé dans les limites de cette GUI ». Le but du billet, c’est de dire : « Utiliser une GUI permet de mieux comprendre fonctionnellement Git, ce qu’il fait, pourquoi, et donc de l’utiliser efficacement – même si ça demande de sortir un autre outil comme la CLI pour arriver à cette fin ». L’idée c’est de se servir d’une GUI au début de son apprentissage de Git, pour arriver à avoir une vue d’ensemble de l’outil – qui est difficile à avoir en CLI pour toutes les raisons données dans le billet – et, à partir de là, pouvoir utiliser n’importe quel outil facilement avec pour seule marche l’apprentissage de la « grammaire » de l’outil en question (et pas celle de Git). Il faudrait que j’arrive à comprendre ce qui provoque ces réactions pour corriger le billet en fonction.
Ce que tu décris est encore un autre problème : aucune procédure n’est décision-stupide-proof (pas même « ne rien faire »). Mais c’est ce que tu décris ici : des décisions stupides, pas des problématiques subies.
Attention : « en quoi » peut faire partie du problème.
Par exemple, on peut se demander si maintenir du code en Pro*C ou en Progress 4GLOpenEdge Advanced Buisness Language est toujours pertinent, quand bien même ces deux langages sont toujours officiellement supportés. Parce que ces langages répondent principalement à des problématiques qui n’ont plus lieu d’être, qu’il est difficile de trouver des personnes qui les maîtrisent, et que l’outillage (au sens large : bibliothèque, outils de développement, de CI/CD…) associé n’est pas au niveau de langages plus utilisés.
Inversement, refuser obstinément de se mettre un minimum à la page « parce que ça fonctionne en l’état », c’est prendre le risque réel de commencer à réagir quand on est déjà dans le mur. Et quand le produit ne se vends plus « parce qu’il est trop moche » et qu’on ne sait plus le redesigner en un temps raisonnable, parce qu’il utilise des techniques qui sont bloquées par défaut – à raison – par les navigateurs modernes, quand la concurrence arrive et fait mieux fonctionnellement avec 10x moins de boulot de paramétrage et 10x moins de boulot d’administration, c’est trop tard.
La vraie difficulté dans un projet à long terme – vraiment long pour de l’informatique, sur plus de 10 ans – c’est pas de « suivre la hype » ou de « rester conservateur ». C’est de bien découpler les différentes parties de son projet, d’identifier ce qu’il est pertinent de mettre à jour et de réussir à le faire, et ce en permanence, sans laisser un morceau pourrir dans un coin, et surtout sans re-créer du couplage inutile.
Une technologie moderne et qui apporte d’énormes avantages à un instant T (comme les JSP en 2000) peut devenir un boulet 20 ans plus tard (comme les JSP en 2020). De même, le code de 20 ans d’âge peut avoir été conçu selon des contraintes complètement obsolètes : toutes ces contorsions pour que le code puisse s’exécuter sur un serveur doté de 128 Mo de RAM peuvent être remplacées par quelque chose de plus rapide et plus facile à maintenir. Un LEFT OUTER JOIN sera plus lisible qu’un table1 = table2 (+). Etc.
Je ne dis pas que c’est facile à faire, au contraire : la maintenance, c’est toujours risqué (régressions…), c’est un cout difficile à justifier, ça peut être long pour un résultat pas évident à court terme, et identifier quelles technologies sont à l’agonie et par quoi les remplacer est un exercice délicat. Mais un code qu’on a laissé pourrir dans un coin « parce que c’est fonctionnel » est tout aussi mauvais qu’un code qu’on passe son temps à modifier « pour suivre la hype ».
Ce que tu décris ressemble pour moi au LightEdit mode des outils JetBrains, mais honnêtement je ne suis pas convaincu que ça soit « plus simple ». L’intérêt d’avoir un éditeur simple, c’est pas seulement une interface plus accessible, mais aussi un lancement plus rapide (si possible virtuellement instantané) et de consommer moins de ressources.
Donc, il faut être capable de démarrer seulement « une partie » du logiciel, et d’avoir un mode de bascule du mode léger vers lourd au besoin. Selon l’architecture du logiciel, ça peut être très complexe à faire sans réorganiser tout le code.
Pour moi c’est juste que dans ce cas, Gimp n’est pas l’outil adapté.
Par contre je ne sais pas quel serait « l’outil adapté » dans ce cas. Sous Windows il y a l’excellent paint.net mais c’est ni libre, ni multiplatefomes.
An exception is made for cryptography-related modules, which will necessarily change to track modern cryptographic algorithms and rotate out support for insecure algorithms. Obsolete algorithms are moved into a separate tree from the standard library and may still be manually installed to build software which depends on obsolete crypto. ↩︎
L’article d’origine date de mai 2014 (et les dernières dates mentionnées suggèrent une mise à jour en 2016). Autant dire que pour ce qui est de l’état de l’art, c’est pas terrible.
Hélas, le Covid et les différentes guerres récentes n'ont que trop montré qu'un message complètement à coté de la plaque c'est plus souvent de la stupidité que de de l'humour.
D'autre part la personne concernée peut très bien éclaircir son point de vue toute seule…
Si c'était vraiment de l'humour, j'ai trouvé aucun indice en ce sens. Personnellement la réaction trop rapide à une simple lecture du titre me semble plus plausible, à la lecture du message.
Tu peux avoir un titre complètement clickbait pour appâter le chaland (surtout les gens qui ne connaissent pas ton boulot) mais un contenu tout à fait correct derrière.
Ici ça n’est pas le cas, les contenus produits par Micode sont inutilement longs et présentés n’importe comment.
C’est un peu le problème de Micode : c’est de la vulgarisation informatique, mais dans 95 % du temps étalée sur 10x plus de temps qu’il n’en faudrait et présentée de façon faussement spectaculaire. C’est dommage.
Ben, disons que ce type m’a tellement habitué à de la repompe de lien sans aucune valeur ajoutée (sinon en général un commentaire aigri) que je ne lis plus ce qu’il raconte et vais voir directement à la source.
Dans tous les cas, si le code a autant de niveaux d’indentation – ou des milliers de lignes dans une seule méthode comme le mentionne le journal –, c’est un code qui a des problèmes bien plus graves que juste quelque chose qui se résous à coup de return early pattern. C’est un code qui a une complexité cyclomatique délirante, et c’est ce point qu’il faut corriger en premier. D’autant plus que si ce genre de méthode arrive à exister au sein du code, c’est aussi presque toujours signe qu’il n’y a aucun test digne de ce nom.
Non, c’est plus vaste que ça, ça permet en particulier d’écrire des chaines d’appels complètes sans avoir à gérer des null en plein milieu et de couper la logique fonctionnelle avec des batteries de if.
D’ailleurs, la doc dit :
API Note:
Optional is primarily intended for use as a method return type where there is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.
Note aussi que, dès aujourd’hui, tu peux aussi utiliser l’un des trop nombreux frameworks qui permettent de gérer les null avec des annotations @Nullable / @NonNull. C’est juste moins intégré au langage lui-même.
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Git Koans. Évalué à 2.
C’est bien de lire les liens quand il y en a, aussi.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Git Koans. Évalué à 4.
Évidemment, mais d’expérience ce point pose moins de problème qu’une branche. J’ai rarement croisé des gens qui avaient du mal à comprendre ce qu’est un commit Git ; par contre, des gens qui sont persuadés que « Une branche c’est un historique linéaire de commits » (ou quelque chose d’approchant), c’est extrêmement fréquent.
Pour le reste, à partir du moment où tu en es à « capitaliser sur ta connaissance de ZSH », tu n’est probablement pas dans la cible du billet.
Par contre, un point qui visiblement est mal compris de ce billet et qui transparait dans ce que je comprends de tes remarques : le but du billet n’est absolument pas de dire « Utilisez une GUI pour utiliser Git, c’est plus simple, quitte à rester coincé dans les limites de cette GUI ». Le but du billet, c’est de dire : « Utiliser une GUI permet de mieux comprendre fonctionnellement Git, ce qu’il fait, pourquoi, et donc de l’utiliser efficacement – même si ça demande de sortir un autre outil comme la CLI pour arriver à cette fin ». L’idée c’est de se servir d’une GUI au début de son apprentissage de Git, pour arriver à avoir une vue d’ensemble de l’outil – qui est difficile à avoir en CLI pour toutes les raisons données dans le billet – et, à partir de là, pouvoir utiliser n’importe quel outil facilement avec pour seule marche l’apprentissage de la « grammaire » de l’outil en question (et pas celle de Git). Il faudrait que j’arrive à comprendre ce qui provoque ces réactions pour corriger le billet en fonction.
La connaissance libre : https://zestedesavoir.com
[^] # Re: la fin du site central…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le sophisme du meilleur outil. Évalué à 3.
Ce que tu décris est encore un autre problème : aucune procédure n’est décision-stupide-proof (pas même « ne rien faire »). Mais c’est ce que tu décris ici : des décisions stupides, pas des problématiques subies.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Git Koans. Évalué à 3.
La question n'est pas tellement de cacher la misère.
Par contre, je vois assez peu de cas d'usage pour avoir Git sur un serveur, et encore moins pour aller y faire des opérations non triviales à la main.
La connaissance libre : https://zestedesavoir.com
# Et donc…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Git Koans. Évalué à 0.
Utilisez une GUI !
Et aussi retenez qu’une branche ou un tag, c’est juste une étiquette sur un commit, Git n’est pas SVN ! (rapport à « Only the Gods »).
La connaissance libre : https://zestedesavoir.com
[^] # Re: la fin du site central…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le sophisme du meilleur outil. Évalué à 2.
Attention : « en quoi » peut faire partie du problème.
Par exemple, on peut se demander si maintenir du code en Pro*C ou en
Progress 4GLOpenEdge Advanced Buisness Language est toujours pertinent, quand bien même ces deux langages sont toujours officiellement supportés. Parce que ces langages répondent principalement à des problématiques qui n’ont plus lieu d’être, qu’il est difficile de trouver des personnes qui les maîtrisent, et que l’outillage (au sens large : bibliothèque, outils de développement, de CI/CD…) associé n’est pas au niveau de langages plus utilisés.La connaissance libre : https://zestedesavoir.com
[^] # Re: la fin du site central…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le sophisme du meilleur outil. Évalué à 10. Dernière modification le 13 novembre 2023 à 12:29.
Inversement, refuser obstinément de se mettre un minimum à la page « parce que ça fonctionne en l’état », c’est prendre le risque réel de commencer à réagir quand on est déjà dans le mur. Et quand le produit ne se vends plus « parce qu’il est trop moche » et qu’on ne sait plus le redesigner en un temps raisonnable, parce qu’il utilise des techniques qui sont bloquées par défaut – à raison – par les navigateurs modernes, quand la concurrence arrive et fait mieux fonctionnellement avec 10x moins de boulot de paramétrage et 10x moins de boulot d’administration, c’est trop tard.
La vraie difficulté dans un projet à long terme – vraiment long pour de l’informatique, sur plus de 10 ans – c’est pas de « suivre la hype » ou de « rester conservateur ». C’est de bien découpler les différentes parties de son projet, d’identifier ce qu’il est pertinent de mettre à jour et de réussir à le faire, et ce en permanence, sans laisser un morceau pourrir dans un coin, et surtout sans re-créer du couplage inutile.
Une technologie moderne et qui apporte d’énormes avantages à un instant T (comme les JSP en 2000) peut devenir un boulet 20 ans plus tard (comme les JSP en 2020). De même, le code de 20 ans d’âge peut avoir été conçu selon des contraintes complètement obsolètes : toutes ces contorsions pour que le code puisse s’exécuter sur un serveur doté de 128 Mo de RAM peuvent être remplacées par quelque chose de plus rapide et plus facile à maintenir. Un
LEFT OUTER JOINsera plus lisible qu’untable1 = table2 (+). Etc.Je ne dis pas que c’est facile à faire, au contraire : la maintenance, c’est toujours risqué (régressions…), c’est un cout difficile à justifier, ça peut être long pour un résultat pas évident à court terme, et identifier quelles technologies sont à l’agonie et par quoi les remplacer est un exercice délicat. Mais un code qu’on a laissé pourrir dans un coin « parce que c’est fonctionnel » est tout aussi mauvais qu’un code qu’on passe son temps à modifier « pour suivre la hype ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: GUI alternative simple ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Is this radical redesign of GIMP possible now?. Évalué à 3. Dernière modification le 13 novembre 2023 à 11:34.
Ce que tu décris ressemble pour moi au LightEdit mode des outils JetBrains, mais honnêtement je ne suis pas convaincu que ça soit « plus simple ». L’intérêt d’avoir un éditeur simple, c’est pas seulement une interface plus accessible, mais aussi un lancement plus rapide (si possible virtuellement instantané) et de consommer moins de ressources.
Donc, il faut être capable de démarrer seulement « une partie » du logiciel, et d’avoir un mode de bascule du mode léger vers lourd au besoin. Selon l’architecture du logiciel, ça peut être très complexe à faire sans réorganiser tout le code.
La connaissance libre : https://zestedesavoir.com
[^] # Re: GUI alternative simple ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Is this radical redesign of GIMP possible now?. Évalué à 4.
Pour moi c’est juste que dans ce cas, Gimp n’est pas l’outil adapté.
Par contre je ne sais pas quel serait « l’outil adapté » dans ce cas. Sous Windows il y a l’excellent paint.net mais c’est ni libre, ni multiplatefomes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Godwin
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Hare : un langage pour les 100 ans à venir. Évalué à 7.
C’est prévu dans la note en bas de page :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas tout compris
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Collection de sites qui ont des consignes de mots de passe à la noix . Évalué à 5.
Selon l’ANSSI (https://www.ssi.gouv.fr/uploads/2021/10/anssi-guide-authentification_multifacteur_et_mots_de_passe.pdf R23 page 29) il faut forcer une diversité de caractères ; mais selon la CISA (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf page 14) il ne faut pas.
Cela dit les deux documents sont intéressants et sont cohérents entre eux sauf des détails à la marge.
La connaissance libre : https://zestedesavoir.com
# Mai 2014, mis à jour vers 2016 (?)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Culture hacker et peur du WYSIWYG. Évalué à 9.
L’article d’origine date de mai 2014 (et les dernières dates mentionnées suggèrent une mise à jour en 2016). Autant dire que pour ce qui est de l’état de l’art, c’est pas terrible.
La connaissance libre : https://zestedesavoir.com
[^] # Re: donc on doit utiliser quoi ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien .io considered harmful. Évalué à 1.
Hélas, le Covid et les différentes guerres récentes n'ont que trop montré qu'un message complètement à coté de la plaque c'est plus souvent de la stupidité que de de l'humour.
D'autre part la personne concernée peut très bien éclaircir son point de vue toute seule…
La connaissance libre : https://zestedesavoir.com
[^] # Re: donc on doit utiliser quoi ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien .io considered harmful. Évalué à 3.
Si c'était vraiment de l'humour, j'ai trouvé aucun indice en ce sens. Personnellement la réaction trop rapide à une simple lecture du titre me semble plus plausible, à la lecture du message.
La connaissance libre : https://zestedesavoir.com
[^] # Re: donc on doit utiliser quoi ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien .io considered harmful. Évalué à 2.
J’ai fait un copié/foiré, normalement le lien derrière TLD aurait dû renvoyer ici et pas derrière la page de liste des acronymes comme c’est le cas.
La connaissance libre : https://zestedesavoir.com
[^] # Re: donc on doit utiliser quoi ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien .io considered harmful. Évalué à 6.
Comme dit dans le titre et le chapeau de l’article, ça parle du TLD
.ioLa connaissance libre : https://zestedesavoir.com
[^] # Re: Bullshit
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Cet OS va vous faire courir acheter un Mac. Évalué à 4.
Tu peux avoir un titre complètement clickbait pour appâter le chaland (surtout les gens qui ne connaissent pas ton boulot) mais un contenu tout à fait correct derrière.
Ici ça n’est pas le cas, les contenus produits par Micode sont inutilement longs et présentés n’importe comment.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bullshit
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Cet OS va vous faire courir acheter un Mac. Évalué à 6.
C’est un peu le problème de Micode : c’est de la vulgarisation informatique, mais dans 95 % du temps étalée sur 10x plus de temps qu’il n’en faudrait et présentée de façon faussement spectaculaire. C’est dommage.
La connaissance libre : https://zestedesavoir.com
[^] # Re: pour toujours
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Abonnement payant sans publicité Facebook et Instagram : 10€ / mois (13€ / mois sur mobile). Évalué à 4.
Si, mais le slogan a disparu à l’automne 2019 : https://www.radiofrance.fr/franceinter/podcasts/l-edito-m/facebook-gratuit-sans-le-dire-6358243
La connaissance libre : https://zestedesavoir.com
[^] # Re: Lien direct sur le wiki LQDN
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Dérive autoritaire : attentifs ensemble (infographie La Quadrature) - sebsauvage.net. Évalué à 5.
Ben, disons que ce type m’a tellement habitué à de la repompe de lien sans aucune valeur ajoutée (sinon en général un commentaire aigri) que je ne lis plus ce qu’il raconte et vais voir directement à la source.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Lien direct sur le wiki LQDN
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Dérive autoritaire : attentifs ensemble (infographie La Quadrature) - sebsauvage.net. Évalué à 4.
Surtout que cette image date de 2015.
La connaissance libre : https://zestedesavoir.com
[^] # Re: tweets / X
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien La « polémique Benzema » vue de Suisse : "le débat français vole toujours aussi haut". Évalué à 8.
Ce Darmanin là ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: continue
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La plus belle ligne de code. Évalué à 8.
Et donc si on respecte la qualité de code des gens qui font des méthodes de milliers de lignes :
GOTO TENLa connaissance libre : https://zestedesavoir.com
[^] # Re: return early pattern
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La plus belle ligne de code. Évalué à 9. Dernière modification le 15 octobre 2023 à 02:07.
Dans tous les cas, si le code a autant de niveaux d’indentation – ou des milliers de lignes dans une seule méthode comme le mentionne le journal –, c’est un code qui a des problèmes bien plus graves que juste quelque chose qui se résous à coup de return early pattern. C’est un code qui a une complexité cyclomatique délirante, et c’est ce point qu’il faut corriger en premier. D’autant plus que si ce genre de méthode arrive à exister au sein du code, c’est aussi presque toujours signe qu’il n’y a aucun test digne de ce nom.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Optional<T>
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La plus belle ligne de code. Évalué à 2. Dernière modification le 15 octobre 2023 à 01:58.
Non, c’est plus vaste que ça, ça permet en particulier d’écrire des chaines d’appels complètes sans avoir à gérer des
nullen plein milieu et de couper la logique fonctionnelle avec des batteries deif.D’ailleurs, la doc dit :
Note aussi que, dès aujourd’hui, tu peux aussi utiliser l’un des trop nombreux frameworks qui permettent de gérer les
nullavec des annotations@Nullable/@NonNull. C’est juste moins intégré au langage lui-même.La connaissance libre : https://zestedesavoir.com