barmic 🦦 a écrit 6259 commentaires

Ok je viens de comprendre notre malentendu !

Je comprends ton point sur le fait qu'il est probablement impossible de valider une fonctionnalité (surtout UI) par des tests automatisés, mais le fait d'avoir une série de cas automatisé n'empêche pas de faire des tests manuels (c'est là que je ne t'ai pas compris puisque tu avais l'air de les placer en opposition).

La soluce, c’est de gruger. Ton core location delegate trampoline vers ta méthode à toi, qui prend un objet que tu peux instantier. Et tu gruges dans ton test, en appelant cette fonction la directement. Il va effectivement te manquer un bout dans ton test, mais au moins tu peux garantir que tout ce qui vient après le point d’entrée fonctionne comme il faut.

Ce n'est pas de la gruge, c'est segmenter ce que tu test et dans le cas présent c'est probablement ce qui distingue un test d'intégration d'un test unitaire. Ça demande souvent de faire de l'injection de dépendance (le pattern pas forcément les framework qui font tout pour toi) et c'est utile pour segmenter tes tests de manière générale. C'est assez mathématiques plus tu test des bouts simple plus la combination va être limitée et comme ça évolue de manière quadratique (il me semble) faire grandir le scope est très douloureux.

C'est pour ça que la pyramide des tests existe et je suis assez dubitatif de ce que vous faites. Beaucoup de ce qui est interface pure reste de l'algorithmique, tu réorganise les données que tu reçois, tu valide les données pour considérer qu'un formulaire est valide ou non, etc. Mais si vous en êtes content, qui suis-je pour juger ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mouaif. Je suis loin d’être convaincu. Peut être qu’on bosse comme des porcs chez moi, mais au mieux du mieux, tu va avoir peut être 80% de couverture sur des uat dans le ticket, et uniquement sur la logique métier pure. Toute la partie technique (typiquement, si ton backend se ramasse, backward compat pour appli, race conditions, etc) ne sera pas couverte par ces tests. C’est certainement une bonne base pour commencer ton test plan, mais ça gratte juste la surface.

Les tests d'acceptance ne sont pas fait pour remplacer les TU, comme les tests d'intégration ne sont pas fait pour remplacer les autres. Il tenter de s'approcher de la pyramide des tests est appréciable.

apres, je suis pas sur de suivre. Tu dit que c’est pas raisonnable de tester manuellement chaque nouvelle feature que l’équipe pond?

Non je dis que la pratique qui consiste à avoir un cahier de recette à rejouer à chaque release ça ne marche globalement pas. Il est pas à jour, il est exécuté à l'arrache, on presse les gens pour le faire au plus vite, ils ne sont pas fait assez régulièrement donc on se retrouve avec des situations du genre "c'est normal que ça ne corresponde pas",...

Pour clarifier, ma position c’est que l’automation n’est pas fiable pour valider une nouvelle feature, aussi petite soit elle.

Donc tu n'écris aucun test programmatique parce qu'ils peuvent être déjoué ?

C'est une évidence et je pense même que c'est mathématiquement prouvé, mais ce n'est pas le sujet à mon avis. Il n'existe pas de silver bullet, même la preuve ne fait que supprimer des pans de types d'erreur, mais il demande à n'avoir aucune erreur dans la spécification (sinon tu as juste prouvé que ton logiciel fait bien l'erreur qui est spécifiée).

La question ce n'est pas de savoir si les tests automatisés c'est bien ou s'il faut tester manuellement mais d'avoir le bon test au bon endroit. Et de mon expérience c'est un équilibre à trouver de ce qui est utile à l'équipe (au sens large).

Une stratégie de test ne peux pas s'évaluer hors de contexte. Le faire de faire des benchmark peut être crucial dans des contextes et une perte de temps ailleurs.

Mon point c'est de dire qu'avoir "une certaine" couverture avec des tests (je disais d'acceptance, mais effectivement métier est bien mieux) écris en gherkin permet d'avoir un échange plus fluide entre le product owner/business analyst/utilisateur impliqué et l’ingénieure.

Si tu peux trouver un ingénieur pour écrire le code, tu peux trouver un qa pour le tester. 1 qa pour 3 à 5 développeurs, c’est grosso modo le ratio que tu veux. Ça passe très bien à l’échelle de ce que j’en voit.

Quand tu met à jour une bibliothèque/framework, la base de données ou la version du langage, comment tu fais pour qualifier la prochaine version ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pense surtout que je n'est pas était clair. J’amende mon commentaire

1. les contributeurs aient une idée fiable de la règle qui va s'appliquer à leur travail
- 2. le travail des contributeurs ne soit détruit que dans les pires extrémités (tous les autres moyens d'établir à un consensus ont étaient consommés ou il y a des manquements graves genre respect des gens, appel à la haine, etc)
+ 2. le travail des contributeurs ne soit détruit que dans les pires extrémités (il y a des manquements graves genre respect des gens, appel à la haine, etc) ou à la suite d'un process menant à un consensus

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Est-ce que le temps passé à concevoir écrire, tester, corriger des tests se justifie par une meilleure productivité globale ou une meilleure qualité globale ?

Sans la moindre hésitation.

La question c'est quelle est la qualité de ce que tu livre ? Et du coup comment tu t'assure d'être à ce niveau de qualité ?

Tu t'appuie sur des clicher de manager, mais un manager ça ne regarde pas que la rentabilité. Il (ou elle) regarde ses objectifs. Si la boite a pour objectif de vendre des binaires pour le prix le plus faible possible alors oui les retours ça ne l'intéresse pas, mais t'augmenter aussi ne l'intéresse pas ni la satisfaction du client ou de l'utilisateur.

Mais tout le monde ne travail pas dans ces ESN qui tentent de vendre du logiciel au rabais (toutes les ESN ne sont pas comme ça, mais la réputation n'est pas démérité). Après ces entreprises existent (et prospèrent) parce que des clients ne veulent pas mettre d'argent dans leur logiciel, mais ce n'est pas le cas de tous. ST a une nécessité vital que les logiciels critiques de ses salles blanches fonctionnent parfaitement par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ton kilométrage va varier, en fonction de beaucoup de chose, mais en gros, mon opinion c’est absolument pas, pas pour tester une UX utilisateur comme OP le fait dans son naljour.

Comme je le disais dans le commentaire. Je pensais plus aux tests d'acceptance qui sont écrit dans les users stories.
Mais j'aime bien la dichotomie de El Titi et de n'utiliser des tests en gherkin que lorsque c'est métier.

bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.

Manuellement ça ne monte pas à l'échelle et c'est sujet à nombre d'erreur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En fait on ne parle pas de la même chose quand on parle de complexité, mais c'est ma faute il faudrait aussi parler de criticité.

Si tu va dans une salle blanche de fondeur de puce, le processus par le quel passe un lot peut être très complexe. Il y a un paquet de règles métier qui font qu'on ajoute ou non des étapes, qu'on rejout des étapes avec des paramètres différents qu'on scinde des lots, des fois pour les refusionner, des fois non et ils vivent leur propre vie,... le tout avec une traçabilité complète. Tu prend une puce vendu chez les client, tu peu savoir de quel lot elle faisait parti et quel a été sa vie en salle de production. Et chaque demi heure d'indisponibilité du système c'est la production qui est arrêté, des gens qui ne peuvent pas travailler.

Tu peux ricanner devant la question de tester cela correctement, mais c'est un vrai sujet à partir du moment où on est attaché à la qualité de ce qu'on délivre.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et sans plaisanter, quels sont les gains en matière de qualité et de productivité par rapport à un contrôle humain du visuel et des fonctionnalités ?

La reproductibilité et la vérification bien plus rapide sans nécessité quelqu'un qui s'y colle. C'est pas rien parce que ça peut vouloir dire que tu va faire les vérifications à chaque merge ou chaque jour et donc être beaucoup plus réactif qu'avec une recette qui est faite seulement avant la création d'une nouvelle version.

Ça n'interdit d'ailleurs pas de faire des vérifications manuelles. C'est même généralement fait jusqu'à ce que tu trouve que la vérification manuelle n'a plus d'intérêt (que tes tests soient suffisamment matures).

Il faudra aussi un troisième jeu de tests pour tester les tests.

La seule méthode que je connais c'est le mutation testing, c'est des outils qui modifient ton code aléatoirement et vérifient qu'il y a bien un test qui plante. J'en entends de plus en plus parler j'ai l'impression que c'est une méthodologie qui est entrain de gagner en maturité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je dis simplement que ça n'aide pas un junior à faire la distinction et à ne pas se lancer dans l'usage d'outils pas adaptés. Je sais pas comment l'expliquer autrement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu présente une application qui est techniquement complexe et fonctionnellement triviale. Ça n'est pas le sujet de ce genre de démarche.

C'est plutôt utile quand le fonctionnel est très complexe/subtile. Tu veux que quelqu'un du domaine puisse lire le test en étant bien sûr que c'est bien ce qu'il pratique au quotidien.

Ça demande de réduire justement le gap entre ce qu'il fait au quotidien et ce qu'il lit. Donc il est nécessaire d'utiliser le même vocabulaire que lui (ça peut passer par utiliser du français voir ne pas utiliser les mots dans le sens qu'ils ont dans le dictionnaire) et écrire les tests dans une forme qui retire autant que possible l'aspect technique est utile.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:

Ça ne change techniquement rien et tu donne le même niveau d'information. On est d'accord là dessus. Mais ça entretien une forme de confusion comme quoi ces tests pourraient ou devraient être écrit en gherkin et tu n'est pas à l'abri que quelqu'un d'un peu motivé se lance là dedans. Utiliser un vocabulaire dédié me semble contribuer à faire la distinction.

Sinon, oui Spock est un bon framework dans le même style mais le Groovy n'a plus guère le vent en poupe aujourd'hui.

Ça c'est une question de hype. Depuis qu'il est passé sous le giron de la fondation Apache, le développement est sécurisé et il a plus de popularité (les mesures du nombre de téléchargements etc). Groovy a l'avantage indéniable de pouvoir utiliser MOP pour faire des choses pas très catholiques.

Kotlin est utilisé hors d'android ? Utilisable oui bien sûr mais c'est probablement un angle mort chez moi je vois très peu de choses passer autour de son écosystème

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le triple AAA et le GWT sont en fait exactement la même chose à un niveau différents pour rendre les tests indépendants et précis.

On est d'accord, mais la proximité de GWT avec Gherkin donne plus l'impression qu'il s'agit d'un gherkin du pauvre. Dis autrement ça tend à donner l'impression qu'on ferait du gherkin si on pouvait alors que c'est pas forcément le lieu.

Parmi les autres principes du BDD on retrouve aussi la notion d'ubiquitous language inspirée du Domain Driven Development et des principes du Clean Coding qui veut qu'on retrouve le langage du domaine jusqu'au niveau du code

Et les aggregats vs les entités oui je connais, même si je trouve que les cas d'usage ou la clean architecture a vraiment du sens est plus limité que ce qui est souvent présenter. Le principe d'avoir des adapters pour tout ne rend pas les choses plus simples, elle déplace un problème vers de l'architecture et les erreur d'architecture sont plus chères que celles de codes "simples". C'est vraiment adapté quand tu as un multi usage de ton métier, quand il est très critique ou quand le logiciel est très gros avec beaucoup de gens sur la même base de code, mais sinon faut vraiment se poser la question avant de se lancer. L'ubiquitus langage et les modélisations à la méthode DDD peuvent apporter plus de bénéfices avec moins de défauts.

Dans le monde Java, pour les TU tu peux adopter aussi ce style avec Kotest par exemple :
https://kotest.io/docs/framework/testing-styles.html#behavior-spec
Ca me manque avec JUnit.

Ca me fait beaucoup penser à Spock.

J'ai pas lu tous les liens mais je n'y manquerait pas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Vraiment super intéressant, je n'étais pas allé jusque là dans ma réflexion personnelle sur la distinction test d'interface par rapport aux tests métiers (je me demande si "behavior" n'a pas aider à la confusion d'ailleurs).

J'aurais peut être un petit bémol ou une remarque au sujet du dévoiement de gherkin. Je trouve que l'utiliser même dans une forme minimale dans des tests unitaires peut aider à structurer. J'y ai même trouvé un avantage certains pour des tests asynchrones où mon bloc then est écrite avant le when (on pose des handler avant de faire l'action). Mais j'avoue qu'après ton explication j'aurais plutôt tendance à utiliser AAA pour éviter les confusions.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

celle-ci d'Einstein également intéressante pour les organisations et que je cite de mémoire : quand quelque-chose ne marche pas, faire plus de la même chose et espérer un résultat différent est le signe de la folie.

Tu as la version latine :

error humanum est perseverare diabolicum

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ils posent différents problèmes:

• ils viennent après le développement
• ils sont impératifs et non descriptif
• ils sont peut lisible, il est difficile d'en déduire l'intention même pour un développeur
• ils sont sensibles aux évolutions, si tu change le menu de ton application, tu va réenregistrer potentiellement tous tes tests

Il est possible d'utiliser selenium de manière programmatique comme une implémentation de gherkin et là ça devient la même approche que playwright ou cypress.

Je considère personnellement de loin, gherkin comme étant une approche beaucoup plus enviable pour les développeurs :

• pas de tests clique clique
• écriture de fonctions très simples fortement réutilisables pour implémenter les "phrases" gherkin
• simplification extrême de l'écriture des tests d'acceptance / e2e généralement rébarbatif (peut même être décrit par un non dev)
• développement plus orienté "contrat" et donc mieux formalisé

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il est écrit en Typescript : Il n’est donc pas facile à comprendre pour les personnes qui ne développent pas (on entend ici toute personne qui ne comprend pas du code de programmation), et c’est un peu dommage, car il est censé représenter un cas d’utilisation réel.

Et on s'en fout en fait, le test est pour vérifier que le développeur ne casse rien lors d'une PR, le test est certes sur une UI mais pour le programmeur par le programmeur pour ne rien casser pendant un développement.

C'est plus subtile que ça. Tu parle de tests unitaires qui sont des outils de développeurs pour développeur. Gherkin (cette syntaxe à base de given/when/then) est plutôt faite pour écrire des tests d'acceptantes. Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.

Bref, Typescript permet beaucoup de tests, et à ma connaissance ce n'est pas la première fois qu'on essaye des "User centric Usecases Validator" et qu'à chaque fois au bout d'un moment on revient à des trucs plus "programmeur" car une PR a cassé un truc qu'on n'avait pensé tester avec UUV blabla mais qu'en fait le test était pas assez poussé et que le UUV blabla ne permet pas de faire ce test.

Beaucoup de bibliothèques de tests se rapprochent d'une manière ou d'une autre de construction à la gherkin et des outils comme cypress ou playwright ont rendent relativement accessible ces formalismes et ces méthodologies.

Après je trouve que créer une opposition développeur utilisateur vaine et non pertinentes. Gherkin n'est qu'une syntaxe elle permet de rendre plus fin l'écart qu'il y a entre une spécification et le code. L'objectif de ces approches doivent être de créer des ponts pas des oppositions. L'objectif de gherkin c'est de faire collaborer plus étroitement les gens en augmentant la part de formalisme du côté de la spécification et en ayant une forme de test plus lisible par un non technicien.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais si ça se trouve avec un tel mode de fonctionnement avec un appel à une application stricte de règles, tu aurais été pour le verrouillage à la création.

Je n'appelle pas à une application stricte, hein ? Mais pour que :

1. les contributeurs aient une idée fiable de la règle qui va s'appliquer à leur travail
2. le travail des contributeurs ne soit détruit que dans les pires extrémités (tous les autres moyens d'établir à un consensus ont étaient consommés ou il y a des manquements graves genre respect des gens, appel à la haine, etc)

Le premier point est vraiment important pour l'acceptation des règles par ceux sur qui elles s'appliquent ou que ce soit. L'intransigeance n'est pas la seule manière d'y parvenir et le simple fait d'appliquer le point 2 amha réduit beaucoup des problèmes du premier point.

Des gens avec ce type de mentalité sont en ce moment vent debout contre la création de l'article et s'en désolidarisent.

Il faut faire descendre ce genre de pression. Si on arrêtait les couperai, on gagnerait en qualité des discussions. OSEF des pages qui ont moins de quelques semaines voir mois. La qualité du contenu de Wikipédia s'évalue à terme. Donc au lieu de s'écharper pour savoir s'il faut détruire MAINTENANT, il est possible de dire qu'aucune action sera prise avant un certain seuil (de temps, d'échange, qu'un vote ai emporté une majorité des 2/3,...). Il est aussi possible de ralentir en empêchant de commenter plus d'un certains nombre de fois par heure/jour.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a un truc qui est ptete un malentendu ici qui est aussi un peu contre intuitif : c'est pas forcément un cadeau d'avoir sa page sur wikipédia pour une personne vivante.

J'en suis parfaitement conscient et c'est pour ça que je parlait des tomates. Mon point n'est pas une question de personne ou un sujet partisan.

C'est wikipédia, en cas de doute on s'en remet à la communauté d'une manière générale. Le principe initial dit "5ème principe fondateur" est là pour maintenir une certaine marge d'interprétation pour pas avoir un cadre administratif trop rigide.

Ce qui pose problème à mon avis, c'est les flous. Ce qui fait qu'une règle est appliquée froidement ou non est arbitraire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je me demande si ça n'est pas plus malin de jouer sur la qualité de service. Si à partir d'une certaine heure internet marche moins bien, ça donne moins l'impression d'un blocage et donc l'idée de changer de liaison. Tout ce qui est filtrage ip ou mac c'est de la merde, si tu veux un truc sérieux c'est via un VPN qu'il faut passer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et comme les gens qui se collent à fermer les pages de décision d'admissibilité sont pareil, ils font ça volontairement avec souvent leur bonne volonté et juste leurs bonnes intentions ...

Je trouve que ou que ce soit quand le travail de modération est dans la suppression hors atteinte aux personnes, c'est du travail de modération bâclé avec une absence de respect pour ceux qui ont produit un contenu que ce soit sur Wikipedia ou ailleurs. Wikipedia a tout un arsenal à sa disposition avant la suppression avec verrouillage de la création. C'est une décision d'une grande violence envers les contributeurs prises avec précipitation. Pour moi il n'est pas possible d'invoquer de la bonne volonté et de la bonne intention.

Ce n'est pas une question partisane mon point de vue serait le même si on parlait d'une nouvelle variété de tomate.

Il y a exceptions pour les cas ou la personne est vraiment nommée à un poste, genre si elle était nommée vraiment ministre on peut être sur qu'elle aura une couverture médiatique qui fera durablement (pas forcément pour autant deux ans mais plusieurs mois assurément) et qu'il y aura matière à faire un article vérifiable au dela de l'actualité. Mais là elle pourrait retourner à son boulot et à un relatif anonymat avant la fin de l'été.

Elle peut très bien être nommée et partir dans quelques mois et ne plus avoir de couverture dans 10 mois en repartant à la vie civile. C'est même probable. Est-ce qu'il faut créer sa page si elle est nommée du coup ? Ou est-ce qu'il faudra la supprimer si elle ne reste pas assez longtemps ? Ou alors la règle c'est "avoir des sources médiatiques secondaires pendant 2 ans" ou que ce soit admis que c'est important (comment par qui ?) ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça ne fait aussi le buzz que lorsque ça touche des personnalités ou des sujets partisans. Comme on le voit dans ce cas particulier, les partisans et la presse sont facilement enclins à politiser une action qui n'a été que purement administrative.

C'est éminemment politique. Choisir ce qui est gardé ou pas est vraiment un choix purement politique, pas forcément partisan mais politique.

Le "comment faire des choix" est très clair : utiliser des critères de notoriété, en particulier au moins deux sources secondaires centrées et significatives séparées d'au moins deux ans.

Comment ils sont choisi ? Comment est-ce qu'on choisi de ne pas les respecter ? C'est des consensus, mais ce genre de buzz montrent qu'il n'y a pas forcément de consensus (ou qu'ils sont "mous").

Par ailleurs, la maintenabilité n'est en général pas un enjeu exprimé explicitement dans Wikipedia.

Tu ne peux pas choisir quand activer ou non des arguments au grès de ce qui t'arrange. La maintenance est un sujet ou n'en est pas un.

Si tel est le cas, il faut bien se rendre compte qu'on n'y peut pas grand chose : comment infléchit-on le comportement d'un animal sans tête ?

"On y peut rien", "c'est comme ça", "c'est pas moi qui fait les règles (mais j'ai rien contre celles qui sont choisi)",... C'est une façon de dépolitiser et de ne pas remettre en cause.

Personnellement, je trouve toute cette agitation autour de la création d'un article bien vaine [...]

Je suis d'accord, je n'ai pas particulièrement d'espoir en ce qui concerne wikipedia.

il n'y avait pas d'urgence à créer l'article, et il n'y avait pas non plus d'urgence à le supprimer. Wikipedia n'étant pas un site d'actualité, il n'aurait pas coûté grand chose d’attendre quelques semaines dans un cas comme dans l'autre.

Oui enfin si tu va avec ce genre de nihilisme il n'y a pas urgence à ce que la page sur la trigonométrie existe non plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La langue anglaise a plus de 4 fois plus de locuteurs que la la langue française. Assez logiquement, la Wikipedia anglophone a aussi plus de 4 fois plus de contributeurs que la wikipedia en français. Cette main d’œuvre gratuite l'autorise ainsi à maintenir un plus grand nombre d'articles sans épuiser ses bénévoles dans une guerre éternelle contre le vandalisme et les publicités.

Et il n'y a pas 4 fois plus de vandalisme et publicité dans la version anglaise ?

Chaque communauté linguistique de Wikipedia définit ses propres règles d'admissibilité. Celles de la communauté francophone sont plus restrictives que d'autres, ce qui fait qu'on lui reproche régulièrement d'être un repère de FAF ou d'islamo-gauchistes.

C'est une manière de présenter comme un équilibre, mais c'est un peu caduque comme argument. C'est une vision objectivement conservatrice indépendamment de si ça touche des sujets ou personnalités vu comme partisan dans une direction ou une autre.

C'est assez particulier parce que c'est profondément lié à ce que l'on cherche à ce que soit wikipedia, le fait que ce soit géré par groupe linguistique signifie que wikipedia ne veut pas forcément dire grand chose puisque les aspirations de wikipedia EN, de wikipedia DE ou de wikipedia FR ne sont pas les même. Indépendamment de la granularité de la page, le fait de présenter les pages en différentes langues tant à les présenter si ce n'est comme traductions au moins comme des équivalences. Hors il n'en est rien, ce conservatisme impact aussi les pages elles même à minima pour le choix des sources.

Je trouve bizarre l'argument de la maintenance :

• d'une part ça explique qu'il faut faire des choix et pas comment sont fait ces choix
• d'autre part l'augmentation du nombre de pages wikipedia francophone est linéaire depuis sa création nous ne sommes pas sur un fonctionnement où chaque nouvelle création devrait engendrer la suppression d'une autre par manque de "main d’œuvre"

Moi perso j'ai abandonné wikipedia. Je ne me battrais pas contre des moulins. Je ne l'utilise que très ponctuellement et ne contribue plus. Entre autre parce qu'outre les grands principes que wikipedia FR se donne, j'y vois un mépris profond pour le travail de contribution. Si je me remettais à contribuer ce serais en anglais.

Combien est-ce que cette politique¹ a fais fuir des contributeurs comme moi ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oh c'est intéressant. De ce que je comprends ils font du matériel embarqué avec support (uniquement ?) de forth.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

"réflexe" supposerait que je le fais systématiquement, tu n'en sais absolument rien.

En fait un réflexe est plutôt caractérisé par l'arc réflexe qui ne passe pas par la volonté. C'est un acte automatique sous certains stimulus (un paquet peuvent entrer en jeu) pour économiser de l'énergie, de la charge au cerveau voir pour aller plus vite.

L'un n'empêche pas l'autre. Et puisque tu parles de réflexe, donc d'une pratique généralisée, note que toutes les vidéos n'ont pas une description et un plan bien écrit. Donc ta pratique n'est pas généralisable, cela ne peut pas constituer un réflexe efficace.

On a pleins de sens qui permettent de réagir à ce qui nous entour. Par exemple toutes les vidéos ne font pas 1h20, mais tu as pris cette information en compte pour réagir. De la même manière toutes les vidéos n'ont pas description ou de plan mais il est possible de réagir à leur présence.

Mais si le contenu est intéressant, ça va prendre 1h20 alors que lire une synthèse me prendra 15 min.

Sans avoir aucune idée de la pertinence de ce qu'il t'a pondu et surtout ça enlève la totalité de l'intérêt parce que les intervention de Chapoutot je peux te les résumer en une phrase :

Le nazisme est la forme pure du capitalisme, donc le capitalisme tend vers le nazisme.

Mais ce qui est important c'est la réflexion pour en tirer une opinion comprendre comment il en arrive à cette conclusion et comment d'ailleurs cette conclusion est une exagération de ses propos. Construire une réflexion ça prend du temps, ça demande d'être prêt à écouter/lire.

Il est largement plus intéressant d'écouter les 15 premières minutes que de jouer avec une IA et d'accepter ce qu'elle te dit. D'ailleurs que l'intérêt était uniquement dans le fait d'utiliser l'IA sans véritablement s'intéresser à ce qu'elle pond puisque tu ne peux pas évaluer ce qu'elle dit sans avoir vu la vidéo.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

il peut sembler anachronique de continuer à l'utiliser en 2024

Pardon mais est-ce qu'il est utilisé ? Les exemples que tu donne et que je trouve sur internet donnent l'impression qu'il y a plus d'implémentations que de programmes pour tourner dessus. La plupart si ce n'est tous les programmes que je trouvent ont plus l'air de toy project fait pour s'amuser avec que pour répondre à un besoin autre que d'avoir une excuse pour écrire du forth.

Ce n'est pas un mal en soit, mais c'est juste mon impression quand je tente de comprendre l'écosystème.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le vrai réflexe problématique

Je ne vois pas de monde dans le quel utiliser 2 à 3 IA d'une complexité monstrueuses et d'une consommation d'énergie folle à la place de poster "Tu peux nous en dire plus sur ce lien ?" n'est pas un vrai problème sociétal, le point culminant de la consommation outrancière d'énergie en lieu et place de l'échange.

Très franchement OSEF de la note (ça aussi c'est un problème cette habitude de tous noter et tout liker synthétiser un jugement en une énumération de 3 états). Si vraiment les personnes qui se sont senti en joie d'utiliser leur algo (tout aussi privé assez questionnant sur les usages à tout le moins) voulais qu'il y ai de l'échange, c'est en créant de l'échange qu'ils auraient pu y contribuer. Ça me fait penser à cette idée que pour répondre à quelqu'un avec qui on est pas d'accord être outrancier pourrait l'amener à se joindre à nous alors que ça ne fait que le pousser à s'arcbouter dans ses idées.

Si la pratique de générer des commentaires par des IA venaient à augmenter ça deviendrait triste pour un site qui se veut communautaire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll