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.
Je n'ai jamais compris pourquoi ils ont implémenté Optional aussi tôt…
Parce qu’ils en avaient besoin pour gérer toute la programmation fonctionnelle à l’arrivée de Java 8, époque où les types scellés ou le pattern matching n’étaient encore qu’un rêve en Java.
Oui, tes commentaires parlent de ton ressenti personnel. De mon côté, je donne plus de crédit à des faits mesurés, étayés et sourcés. De plus, ceci :
Pour le moment, les seuls capteurs numériques capables de rivaliser avec le film argentique sont les capteurs moyen et grands formats…à prix professionnel
montre que ce point n’est pas clair dans ton discours – parce que les plus grands capteurs numériques ne sont pas les mieux résolus, cf mon message précédent. En fait, n’importe quel capteur de smartphone est beaucoup mieux défini que celui du boitier que tu as cité.
De même que ceci :
Par contre, si on parle de séparation des traits/points, le gros grain risque de faire se toucher certaines parties des traits.
Montre que la notion de pouvoir de séparation n’est pas claire dans ton propos, puisque par définition si ça touche c’est plus séparé, donc ça a un impact sur le pouvoir de séparation…
Donc tu m’excuseras, je persiste et signe : sauf rares exceptions mentionnées dans mon message ci-dessus, un capteur numérique moderne est mieux résolu qu’une pellicule argentique, ce point étant un fait solidement étayé et pas une opinion.
Quant aux objectifs, c’est moins évident – et ton Leica aura sans doute un objectif avec un pouvoir de séparation capable de surpasser de bons capteurs modernes compatibles avec lui. Mais Leica c’est quand même l’ultra haut de gamme, les progrès des objectifs (même pros) plus standard sont bien documentés et tracés dans des batteries de tests disponibles un peu partout.
[^] # 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
[^] # Re: Optional<T>
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La plus belle ligne de code. Évalué à 3.
Parce qu’ils en avaient besoin pour gérer toute la programmation fonctionnelle à l’arrivée de Java 8, époque où les types scellés ou le pattern matching n’étaient encore qu’un rêve en Java.
La connaissance libre : https://zestedesavoir.com
[^] # Re: le prix pique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Redonner vie à vos appareils argentiques : la pellicule numérique prend forme avec ce projet. Évalué à 1.
Oui, tes commentaires parlent de ton ressenti personnel. De mon côté, je donne plus de crédit à des faits mesurés, étayés et sourcés. De plus, ceci :
montre que ce point n’est pas clair dans ton discours – parce que les plus grands capteurs numériques ne sont pas les mieux résolus, cf mon message précédent. En fait, n’importe quel capteur de smartphone est beaucoup mieux défini que celui du boitier que tu as cité.
De même que ceci :
Montre que la notion de pouvoir de séparation n’est pas claire dans ton propos, puisque par définition si ça touche c’est plus séparé, donc ça a un impact sur le pouvoir de séparation…
Donc tu m’excuseras, je persiste et signe : sauf rares exceptions mentionnées dans mon message ci-dessus, un capteur numérique moderne est mieux résolu qu’une pellicule argentique, ce point étant un fait solidement étayé et pas une opinion.
Quant aux objectifs, c’est moins évident – et ton Leica aura sans doute un objectif avec un pouvoir de séparation capable de surpasser de bons capteurs modernes compatibles avec lui. Mais Leica c’est quand même l’ultra haut de gamme, les progrès des objectifs (même pros) plus standard sont bien documentés et tracés dans des batteries de tests disponibles un peu partout.
La connaissance libre : https://zestedesavoir.com
[^] # Re: le prix pique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Redonner vie à vos appareils argentiques : la pellicule numérique prend forme avec ce projet. Évalué à 3.
On est d’accord, ce qui est important c’est de comprendre les limitations, ce qu’on peut faire ou ne pas faire avec son matériel.
La connaissance libre : https://zestedesavoir.com