on n'a pas les moyens de foutre à la porte les gêneurs, la tribune n'est pas une boîte de nuit
Dans mon analogie, un bannissement de tribune équivaut à mettre à la porte de la boite de nuit. Je ne comprend pas trop ce qui manque comme moyen pour cela. Mais comme je l'ai dit, je ne suis pas modérateur de cet espace et n'ai pas l'ambition de le devenir donc je imaginer qu'il y a des complications. Et je peux aussi accepter que les modérateurices peuvent avoir mieux à faire que d'expliquer cela icitte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je compatis et je suis positivement surpris que tu « tiennes » encore sur la tribune. Si on veut minimiser l'effort sans fermer l'espace je pense que des actions de modération plus agressives/strictes me semblent le plus indiqué (e.g. au lieu d'expliquer individuellement qu'on aime pas trop les images d'Hitler, bannir systématiquement l'impétrant pour N jours avec un lien vers une page explicative), au moins jusqu'à ce que la situation redevienne sous contrôle.
Cela dit, je ne suis pas modérateur de cet espace et n'ai pas l'ambition de le devenir donc je peux comprendre que ça n'est pas forcément si simple.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
De par chez moi, pour changer l'ambiance on met dehors ceux qui la plombent et on encourage la participation de ceux qui la rendent plus sympatique. Dans le cadre d'un espace de discussion sur internet, cela s'appelle des actions de modération. Bon, il y a d'autres aspects que j'ai décrit dans mon message précédent ((b) et (c)) mais au final ils sont contingent à une politique de modération appliquée correctement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
problème de la tribune qui, je pense, ne s'est pas bien adaptée à la modération
Si tu fais référence aux participants de la tribune (i.e. les moules), je suis d'accord. Mais les moules ne vont pas changer sans stimulus externe. Les stimuli possibles que je vois sont (a) des actions de modération, (b) un influx de nouvelles moules qui ont des standards/comportements plus en adéquation avec la ligne éditoriale de DLFP 2025, (c) des changements sur le format de la tribune qui encouragent une meilleure adéquation avec cette ligne éditoriale.
On est d'accord que (a) nécessite du travail de modération que personne ne semble enthousiaste de réaliser. (c) aurait besoin de discussions auxquelles je participe volontiers (dans un ticket de suivi ?) mais au final il faudra quelqu'un pour écrire le code (je peux envisager d'aider mais mon dernier patch est en attente de review depuis mars 2024). (b) me semble relativement facile à initier (suffit de rendre la tribune plus visible sur le reste du site) mais sans un minimum de (a) il y a un risque significatif d'avoir l'effet inverse.
il ne reste pas beaucoup de solution que se débarrasser du problème
Je ne suis pas forcément contre cette option. Je suis un participant régulier de la tribune et je serais un peu désolé qu'elle disparaisse/déménage. Mais force est de constater que ça n'est pas un lieu très sain. S'il n'y a pas une masse critique pour redresser la barre, peut être que cette fermeture permettra de récupérer de l'énergie moulesque dans des activités plus fructueuses.
Sinon yaka mettre gle< et adonai< comme les deux seuls modérateurs puis regarder l'implosion en accéléré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je ne suis pas d'accord. Le problème, s'il y en a un, c'est que, de facto, la tribune n'est pas modérée selon les mêmes règles que le reste du site.
Sur la tribune, il y a nombre de propos qui, s'ils étaient exprimés comme commentaire de journal, seraient immédiatement supprimés ou rédigés avec potentiellement un bannissement temporaire ou permanent de l'impétrant. Ce problème est lié au format mais aussi à la modération elle même. Le format ne permet pas aux auteurs d'éditer ou supprimer des messages. Il encourage les messages courts en « temps réel », ce qui ne favorise pas la réflexion.
Mais c'est aussi (et surtout ?) un problème propre à la modération qui, je pense, ne s'est pas bien adaptée à la tribune pour y faire respecter les règles de modération établies et appliquées sur le reste du site. Je comprend que c'est pas facile et que les ressources sont limitées mais, de mon point de vue, ça fait clairement partie du problème.
Je rejette la notion que DLFP ne doit pas être politisé. La nature du Logiciel Libre est politique et je pense qu'il est très sain de discuter de politique dans cet espace tant que ces discussions respectent certaines règles (qui me semblent mieux appliquées dans les dépêches, les journaux, les forums et les commentaires que sur la tribune).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Utiliser les services à distance d'une banque sans dépendre de Google/Apple, est-ce encore possible aujourd'hui ?
Aucune des banques que j'ai utilisées jusqu'à présent (au moins 16 dans 3 pays) impose l'utilisation d'un smartphone. De mon expérience on peut généralement obtenir un 2ème facteur d'authentification soit via un téléphone capable de recevoir des appels ou SMS soit via un appareil séparé (mais souvent il faut le payer), typiquement CrontoSign.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pour ma part, j'apprécie beaucoup de pouvoir générer une nouvelle carte virtuelle instantanément et de « (dé)geler » chaque carte à tout moment.
En pratique je ne garde qu'une seule carte virtuelle qui est toujours « gelée » sauf lorsque je fais un achat en ligne. De cette manière je n'ai pas eu de problème avec un vendeur qui a essayé de me débiter frauduleusement quelques jours après que je sois passé par lui pour un achat légitime. J'ai juste généré une nouvelle carte pour toutes mes transactions suivantes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
ING Belgique : scammy
Lloyds, TSB, Citi, NatWest, Halifax, NationWide : d'autant que je me souvienne, ça juste marche
Smile : minimaliste mais ça juste marche
Metrobank : bonnes conditions, ouverts même les jours fériés, très efficace ! tellement efficace qu'ils ont fermé mon compte sur le champs quand ils réalisé que je n'étais plus résident dans le bon pays (comparé aux autres qui m'ont vaguement signifiés qu'il faudrait sans doute un jour que je ferme le compte)
UBS : scammy
CA Nextbank : pas cher mais mal foutu
PostFinance : ça juste marche
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je pense que la formulation d'Hyrum est plus facile à comprendre pour le développeur moyen dans un contexte moderne. Ça vaut peut-être la peine de faire le lien dans l'article Wikipedia correspondant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
on ne parle pas d'une raison évoquée pour refuser un patch (par exemple, un patch qui corrigerait un détail insignifiant ou invisible sur la chaîne de caractères), mais d'une instruction préventive : "ne pas modifier cette fonction". Du coup, ça renverse quand même pas mal la logique.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
le meilleur logiciel possible
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
les coûts induits par mes choix sur les utilisateurs potentiels ne rentrent pas dans l'équation
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est un peu exagéré mais c'est l'esprit, oui. Il était (est ?) beaucoup plus facile de démontrer un « impact » (et donc d'être promu) en lançant un nouveau service qu'en faisant de la maintenance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
ne sont pas à destination d'utilisateurs finaux, mais sont à destination de professionnels
Par « utilisateurs finaux » je veux dire « utilisateurs externes ». Professionnels ou pas, ça n'a pas d'importance. Qu'ils paient ou pas non plus dans une certaine mesure. Mon exemple de service « gratuit » était juste un exemple.
Je l'avais vu décrit autrement
Je pense qu'on dit la même chose.
Je trouve que tenter de créer des méta-lois pour se torcher avec les 15 années suivantes est à minima risible.
Cette « loi » est juste une observation (d'un ingénieur) dont on peut faire ce qu'on veut. Elle me semble correcte. Je suis d'accord qu'on peut rire du management qui n'en fait pas bon usage :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux).
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est amusant de voir que cette loi porte le nom de quelqu'un qui travaille sur la maintenance de logiciels à grande échelle1, dans une entreprise qui a cimetière pour les services qu'elle a tuée.
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Plus simplement, les versions majeures et les notifications de futur abandon2 plusieurs versions en avance (parfois plusieurs années) sont utilisées pour ce genre de cas.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Ça n'est pas quand même un appel à accumuler de la dette technique?
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: le problème
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 3 (+1/-0).
Dans mon analogie, un bannissement de tribune équivaut à mettre à la porte de la boite de nuit. Je ne comprend pas trop ce qui manque comme moyen pour cela. Mais comme je l'ai dit, je ne suis pas modérateur de cet espace et n'ai pas l'ambition de le devenir donc je imaginer qu'il y a des complications. Et je peux aussi accepter que les modérateurices peuvent avoir mieux à faire que d'expliquer cela icitte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: le problème
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 3 (+1/-0).
Je compatis et je suis positivement surpris que tu « tiennes » encore sur la tribune. Si on veut minimiser l'effort sans fermer l'espace je pense que des actions de modération plus agressives/strictes me semblent le plus indiqué (e.g. au lieu d'expliquer individuellement qu'on aime pas trop les images d'Hitler, bannir systématiquement l'impétrant pour N jours avec un lien vers une page explicative), au moins jusqu'à ce que la situation redevienne sous contrôle.
Cela dit, je ne suis pas modérateur de cet espace et n'ai pas l'ambition de le devenir donc je peux comprendre que ça n'est pas forcément si simple.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: le problème
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 8 (+6/-0).
De par chez moi, pour changer l'ambiance on met dehors ceux qui la plombent et on encourage la participation de ceux qui la rendent plus sympatique. Dans le cadre d'un espace de discussion sur internet, cela s'appelle des actions de modération. Bon, il y a d'autres aspects que j'ai décrit dans mon message précédent ((b) et (c)) mais au final ils sont contingent à une politique de modération appliquée correctement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: le problème
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 4 (+2/-0).
Si tu fais référence aux participants de la tribune (i.e. les moules), je suis d'accord. Mais les moules ne vont pas changer sans stimulus externe. Les stimuli possibles que je vois sont (a) des actions de modération, (b) un influx de nouvelles moules qui ont des standards/comportements plus en adéquation avec la ligne éditoriale de DLFP 2025, (c) des changements sur le format de la tribune qui encouragent une meilleure adéquation avec cette ligne éditoriale.
On est d'accord que (a) nécessite du travail de modération que personne ne semble enthousiaste de réaliser. (c) aurait besoin de discussions auxquelles je participe volontiers (dans un ticket de suivi ?) mais au final il faudra quelqu'un pour écrire le code (je peux envisager d'aider mais mon dernier patch est en attente de review depuis mars 2024). (b) me semble relativement facile à initier (suffit de rendre la tribune plus visible sur le reste du site) mais sans un minimum de (a) il y a un risque significatif d'avoir l'effet inverse.
Je ne suis pas forcément contre cette option. Je suis un participant régulier de la tribune et je serais un peu désolé qu'elle disparaisse/déménage. Mais force est de constater que ça n'est pas un lieu très sain. S'il n'y a pas une masse critique pour redresser la barre, peut être que cette fermeture permettra de récupérer de l'énergie moulesque dans des activités plus fructueuses.
Sinon yaka mettre gle< et adonai< comme les deux seuls modérateurs puis regarder l'implosion en accéléré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Spécificité du LL
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 4 (+3/-1).
C'est faux. Mon journal sur le sujet a été noté au moins 76 fois.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# le problème
Posté par Krunch (site web personnel) . En réponse au journal Il y a quelque chose de pourri.... Évalué à 8 (+6/-0).
Je ne suis pas d'accord. Le problème, s'il y en a un, c'est que, de facto, la tribune n'est pas modérée selon les mêmes règles que le reste du site.
Sur la tribune, il y a nombre de propos qui, s'ils étaient exprimés comme commentaire de journal, seraient immédiatement supprimés ou rédigés avec potentiellement un bannissement temporaire ou permanent de l'impétrant. Ce problème est lié au format mais aussi à la modération elle même. Le format ne permet pas aux auteurs d'éditer ou supprimer des messages. Il encourage les messages courts en « temps réel », ce qui ne favorise pas la réflexion.
Mais c'est aussi (et surtout ?) un problème propre à la modération qui, je pense, ne s'est pas bien adaptée à la tribune pour y faire respecter les règles de modération établies et appliquées sur le reste du site. Je comprend que c'est pas facile et que les ressources sont limitées mais, de mon point de vue, ça fait clairement partie du problème.
Je rejette la notion que DLFP ne doit pas être politisé. La nature du Logiciel Libre est politique et je pense qu'il est très sain de discuter de politique dans cet espace tant que ces discussions respectent certaines règles (qui me semblent mieux appliquées dans les dépêches, les journaux, les forums et les commentaires que sur la tribune).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Obliger les clients à préférer la bagnole par contre…
Posté par Krunch (site web personnel) . En réponse au lien SNCF: obliger les clients à choisir entre "Monsieur" ou "Madame" lors de l'achat d'un billet n'est p. Évalué à 5 (+3/-0).
Ouais et la version SNCF est juste un cas particulie de tarif au kilomètre, juste qu'il y en a plusieurs et plein d'exceptions /s
La différence entre 0€/km et 0.01€/km est plus grande qu'entre un tarif au kilomètre et ce que la SNCF fait maintenant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Obliger les clients à préférer la bagnole par contre…
Posté par Krunch (site web personnel) . En réponse au lien SNCF: obliger les clients à choisir entre "Monsieur" ou "Madame" lors de l'achat d'un billet n'est p. Évalué à 5 (+3/-0).
La vraie simplicité c'est de ne pas faire payer à l'usage. Comme au Luxembourg par exemple. Oui, je comprend que la France n'est pas le Luxembourg.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: banque sans appli ?
Posté par Krunch (site web personnel) . En réponse au journal Où je me cherche une banque. Évalué à 3 (+1/-0).
TIL Tracfin est un service de renseignement français
Du coup je vois pas ce qu'ils feraient avec moi étant donné que je n'ai jamais vécu en France ni ai eu de relation bancaire dans ce pays.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: cartes virtuelles
Posté par Krunch (site web personnel) . En réponse au journal Où je me cherche une banque. Évalué à 2 (+0/-0).
Non. Mais si c'était le cas, une carte virtuelle dédiée me semblerait effectivement une bonne idée.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: banque sans appli ?
Posté par Krunch (site web personnel) . En réponse au journal Où je me cherche une banque. Évalué à 2 (+0/-0). Dernière modification le 24 décembre 2024 à 18:00.
Aucune des banques que j'ai utilisées jusqu'à présent (au moins 16 dans 3 pays) impose l'utilisation d'un smartphone. De mon expérience on peut généralement obtenir un 2ème facteur d'authentification soit via un téléphone capable de recevoir des appels ou SMS soit via un appareil séparé (mais souvent il faut le payer), typiquement CrontoSign.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: cartes virtuelles
Posté par Krunch (site web personnel) . En réponse au journal Où je me cherche une banque. Évalué à 5 (+3/-0).
Pour ma part, j'apprécie beaucoup de pouvoir générer une nouvelle carte virtuelle instantanément et de « (dé)geler » chaque carte à tout moment.
En pratique je ne garde qu'une seule carte virtuelle qui est toujours « gelée » sauf lorsque je fais un achat en ligne. De cette manière je n'ai pas eu de problème avec un vendeur qui a essayé de me débiter frauduleusement quelques jours après que je sois passé par lui pour un achat légitime. J'ai juste généré une nouvelle carte pour toutes mes transactions suivantes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# expériences personnelles
Posté par Krunch (site web personnel) . En réponse au journal Où je me cherche une banque. Évalué à 5 (+3/-0).
ING Belgique : scammy
Lloyds, TSB, Citi, NatWest, Halifax, NationWide : d'autant que je me souvienne, ça juste marche
Smile : minimaliste mais ça juste marche
Metrobank : bonnes conditions, ouverts même les jours fériés, très efficace ! tellement efficace qu'ils ont fermé mon compte sur le champs quand ils réalisé que je n'étais plus résident dans le bon pays (comparé aux autres qui m'ont vaguement signifiés qu'il faudrait sans doute un jour que je ferme le compte)
UBS : scammy
CA Nextbank : pas cher mais mal foutu
PostFinance : ça juste marche
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Vieillissement technologique
Posté par Krunch (site web personnel) . En réponse au lien La fondation Linux pointe les plus gros problèmes dans l’utilisation du logiciel libre. Évalué à 4.
D'ailleurs je me demande s'il existe un census équivalent pour les logiciels privateurs.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# la géographie c'est compliqué
Posté par Krunch (site web personnel) . En réponse au lien La Nasa cherche à sauver un astronaute sur la Lune et met 45 000 $ sur la table. Évalué à 3.
Je suis pas sûr que ce révisionisme fasse plaisir aux 22 pays de l'Amérique du Nord qui ne sont pas les États-Unis d'Amérique.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3.
TIL
Je pense que la formulation d'Hyrum est plus facile à comprendre pour le développeur moyen dans un contexte moderne. Ça vaut peut-être la peine de faire le lien dans l'article Wikipedia correspondant.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 5. Dernière modification le 27 novembre 2024 à 17:58.
Ça me semble être exactement la même logique. Juste qu'on annonce la couleur à l'avance. Je suis pas familier avec la philosophie de développement de ce logiciel en particulier mais j'imagine qu'à un moment il va bien falloir changer quelque chose de toute façon et c'est pas un commentaire qui va arrêter cela. J'imagine que ça freine surtout les changements intempestifs et force à considérer l'intérêt des utilisateurs que ça va casser.
Il reste à définir sur quelles métriques tu te bases pour définir le « meilleur logiciel ». Beaucoup de gens vont décider de juger ça sur le fait que le logiciel serve bien ses utilisateurs existants (i.e. que l'équipe de développement est à leur service). Tu peux s/logiciel/service/g et la logique reste la même. Je ne vois rien de douteux là dedans, même s'il peut y avoir d'autres contraintes qui déprioritisent plus ou moins cette notion de service aux utilisateurs.
Mais du coup, il y a relativement peu d'utilisateurs qui vont utiliser ton truc (« ça change tout le temps »), du coup la loi d'Hyrum est aussi moins pertinente du fait qu'il y a peu d'utilisateurs, du coup tu peux joyeusement continuer de casser la comptabilité et tout le monde s'en fout.
Je pense qu'une autre manière de voir cela c'est qu'en temps que développeur tu dois choisir l'équilibre entre te faciliter la vie, faciliter la vie de tes utilisateurs existants et faciliter la vie de tes futurs utilisateurs. Différents projets et différentes organisations vont faire de choix différents. Tant que le choix est fait de manière intentionnelle, ça ne me choque pas trop.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3.
C'est un peu exagéré mais c'est l'esprit, oui. Il était (est ?) beaucoup plus facile de démontrer un « impact » (et donc d'être promu) en lançant un nouveau service qu'en faisant de la maintenance.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3.
Par « utilisateurs finaux » je veux dire « utilisateurs externes ». Professionnels ou pas, ça n'a pas d'importance. Qu'ils paient ou pas non plus dans une certaine mesure. Mon exemple de service « gratuit » était juste un exemple.
Je pense qu'on dit la même chose.
Cette « loi » est juste une observation (d'un ingénieur) dont on peut faire ce qu'on veut. Elle me semble correcte. Je suis d'accord qu'on peut rire du management qui n'en fait pas bon usage :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3. Dernière modification le 27 novembre 2024 à 12:39.
Les utilisateurs d'un service d'infrastructure de base (I), ce sont des services de plus haut niveau (S1, S2,…). Les utilisateurs de ces services sont potentiellement les utilisateurs finaux U1 pour S2, U2 pour S2,….
Dans la situation que je décris, il y a de l'argent pour faire évoluer I et S1 mais pas S2. Pour une raison ou l'autre, pour pouvoir faire évoluer S1, il faut faire évoluer I (e.g. limites de mise à l'échelle). Les utilisateurs U2 ne sont organisationnellement pas vraiment en mesure de payer pour S2 (e.g. c'est un service « gratuit ») et son évolution.
Mais oui, au final c'est une décision du management de prioritiser un certains groupe d'utilisateurs (e.g. U1 et leur service S1 qui grandit à 3000% par an) au détriment d'un autre (e.g. U2 et leur service S2 qu'on n'a pas réussi à monétiser suffisamment). On peut aussi voir ça comme prioritiser les nouveaux services (« potentiel prometteurs ») sur les anciens (« on a essayé, c'est pas rentable »). Le management pourrait choisir ses priorités autrement mais à Google j'ai l'impression que c'était (c'est ?) souvent comme ça.
Je ne pense pas que qui que ce soit ai donné comme argument que c'était pour le bien des utilisateurs U2 de casser S2 (bon, parfois il y a un service équivalent S3 et ça peut être une manière de forcer la migration vers ce truc qui est censé être mieux pour eux). Les utilisateurs ne sont pas un groupe uniforme, surtout quand on considère tous les services/logiciels dépendants.
Dans ce contexte, la loi d'Hyrum est un juste un facteur à prendre en compte quand on prend la décision de ce qu'il est important de prioritiser.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 3.
Je vois plutôt ça comme un facteur à prendre en compte consciemment. Je suis d'accord que l'utiliser comme excuse à tort et à travers n'est pas une bonne idée.
J'ai du mal à comprendre en quoi c'est douteux. Il y a toujours des contraintes supplémentaires mais fondamentalement, si tu n'écris le logiciel pour les utilisateurs de manière à ce qu'il puisse être utilisé d'une manière raisonnable, je comprend pas trop pourquoi (pour qui ?) tu l'écris.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ironie
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 4. Dernière modification le 25 novembre 2024 à 21:29.
Disclaimer : j'ai travaillé à Google, y compris sur des projets de réduction de dette technique (y compris avec Hyrum) qui ont mené à casser des trucs pas maintenus mais rien qui ai conduit à l'arrêt d'un service disponible publiquement (que je sache).
C'est précisément parce que le travail de maintenance / gestion de dette technique est effectué de manière proactive que des projets sont abandonnés. Sinon on laisse tout pourrir, les vieux trucs continuent de fonctionner mais on fini par ne plus pouvoir rien lancer de neuf de manière efficace.
Dans le cas de Google, il y a plusieurs facteurs et je ne suis pas au courant de tout. Mais de mon expérience, historiquement il y a plein de projets qui ont été lancés, qui s'appuient sur l'infrastructure existante, sans vraiment planifier un budget de maintenance pour le projet lui même sur le long terme. Au fil du temps, l'infrastructure évolue (il y a un budget pour ça) et fini par se retrouver dans une situation où l'API doit changer mais où personne ne veut payer le coût de la mise à jour du côté client/projet.
Pour les API documentés, bien sûr. Mais il y a plein de trucs pour lesquels c'est pas si simple. C'est précisément le sujet de la loi d'Hyrum.
Par ailleurs, aux dernière nouvelles, Hyrum ne travaille plus à Google.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dette technique...
Posté par Krunch (site web personnel) . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 4.
Si tu lis la page canonique sur le sujet ainsi que le chapitre associé dans le SWE Book, tu peux voir que l'idée c'est pas d'appeler à accumuler de la dette technique de manière indiscriminée mais que, si tu as beaucoup d'utilisateurs, payer ta dette technique peut rapidement coûter cher.
Voire aussi
https://higherorderlogic.com/programming/2023/10/06/bad-code-isnt-technical-debt-its-an-unhedged-call-option.html
https://apenwarr.ca/log/?m=202306
Et tant qu'on y est https://technology.riotgames.com/news/taxonomy-tech-debt
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: On veut la suite !
Posté par Krunch (site web personnel) . En réponse au lien That’s about 700 times a second. Évalué à 4. Dernière modification le 15 novembre 2024 à 00:37.
Il n'y a pas de fin. Ce genre de problèmes arrive tout le temps. Si tu veux lire des histoires de gens qui ont eu des problèmes similaires, ont trouvé le client problématique et ont eu des discussions plus ou moins productives avec eux, il y a l'exemple de Netgear et l'université de Wisconsin–Madison ainsi que Wikimedia et une app mobile dans le lien. Wikipedia a aussi une page dédiée à cette classe de problèmes en ce qui concerne NTP.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mouai...
Posté par Krunch (site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 4.
Non, mais à partir du moment où tu acceptes une requête HEAD, tu censé y répondre correctement (sans contenu notamment). L'implémentation présentée ignore la requête et répond toujours de la même façon.
Donc, non, techniquement c'est pas « un serveur http point » ni même une tentative de l'être. Ça répond à un besoin très spécifique qui utilise une toute petite partie de la spec HTTP. Mais c'est clairement expliqué au début du post et je suis d'accord que chouiner que c'est pas conforme c'est être complètement à côté de la plaque.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.