barmic 🦦 a écrit 5782 commentaires

  • [^] # Re: PrĂ©cisions

    Posté par  . En réponse au lien Le physicien Etienne Klein, "philosophe des sciences préféré des média", accusé de plagiat. Évalué à 7.

    […] délivrée sous forme d'image, pas très lisble !

    C'est la pratique sur X, mais il est possible de mettre un texte alternatif. A l'époque c'était pour pallier à la limite du nombre de caractère, maintenant c'est pour ne pas payer les tweets longs je crois.

    Une réponse assez minable, quoique grandiloquente

    Tu va me dire ça aussi c'est une pratique sur X

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 7.

    Le front populaire c'est environ 6 mois (si le gouvernement de Blum démissionne à l'été 1937, il n'avait déjà plus vraiment l'appuie des radicaux depuis l'automne 1936) six mois pendant les quels ils ont surtout gérés les grèves.

    Par contre ton idole, n'a pas vraiment donné le droit de vote aux femmes. Il a donné le droit de vote aux femmes lors qu'elles sont les chefs de famille c'est à dire quand l'homme n'est plus là. C'est une ordonnance de communiste du gouvernement provisoire de la RF qui institue le droit de vote aux femmes pleinement.

    A noter que cet "esprit saint" (condamné à l'indignité nationale) a intégré ça dans un projet de loi de janvier 1944 mandat qu'il avait depuis 1940, il devait être trop occupé à déporter des populations et tremper dans l'intelligence avec l’ennemi et la haute trahison pour s'en occuper plus tôt. Vraiment si c'est ça un "esprit sain et nationaliste" c'est assez pitoyable.

    Après si tu veux la liste de ce que l'on FP n'a pas fait, on peut aller plus loin :

    • pas d'abolition de peine de mort
    • pas de droit pour les homosexuels ni les LGBT
    • pas de libĂ©ration des mĂ©dia
    • pas de revenus universelle
    • pas de prise en compte des questions Ă©cologiques
    • pas de dĂ©colonisation
    • pas de plan ambitieux pour la crĂ©ation de l'ordinateur
    • pas de mise en place de l’indemnisation au chĂ´mage
    • …

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 3. Dernière modification le 06 août 2024 à 08:38.

    La plupart des fakenews sont donc admissibles mais un paquet de papiers scientifiques (que ce des articles ou des thèses par exemple).

    Ainsi, les critères de notoriété émergent essentiellement des objectifs de neutralité, de fiabilité et de synthèse, qui sont des principes fondamentaux du projet.

    Dans les faits c'est la médiatisation qui crée l'admissibilité. Je comprends l'objectif de neutralité, mais :

    • il est Ă  questionner Ă  mon avis quand il implique de maintenir des statu quo qui ne sont pas acceptables socialement
    • s'il est impossible de dĂ©finir des règles parfaites, il vaut mieux ĂŞtre souple que de ce cacher derrière

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 2. Dernière modification le 05 août 2024 à 17:57.

    Ca n'a rien à voir avec le fait que ça plaise ou ne plaise pas : c'est juste que le cas cité ne prouve rien. C'est juste un ressenti. Il doit certainement y avoir d'autres cas qui sont mieux représentatifs du problème soulevé (et je suis disposé à m'y intéresser), mais celui-là, non.

    Le problème c'est d'arriver à avoir des cas documentés (en tout cas qui a fait BEAUCOUP de bruit). Je pense que le plus récent ça doit être Michel Zecler. Mais c'est confortable de juste sélectionner/disqualifier sans donner plus de motivation que "non mais un autre".

    Laquelle ? Celle de la personne qui a rédigé l'article ?

    Celle qui se base sur rien d'autre que ton imagination.

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 8.

    Hors de toute polémique. La règle de wikipédia FR (qui n'est pas forcément celle de toutes les communautés de wikipédia ni même de toutes les encyclopédies) tend à contribuer (même passivement) à l'effet Matilda. Ça n'est pas un point de vu. Le fait de faire comme si ça n'existait pas c'est un choix politique que ce soit au moment de leur édiction ou au moment de leur application. Faire comme si les règles étaient immuables et hors de tout propos politique c'est ne pas assumer ces choix.

    C'est une position qui peut s'entendre que Wikipedia FR ne veut pas assumer une forme de contribution à rendre plus visible une population invisibilisée, mais ce n'est pas ce qui est prétendu. J'imagine que dire franchement "on ne veut pas contribuer aux mouvements féministes" doit être compliqué à soutenir publiquement quand on tente d'être neutre, mais le statu quo n'est pas neutre : comme souvent le statu quo est au profit de ceux qui sont déjà en position de force.

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 2.

    Faut arrêter avec cet argument à la noix "vous faites ou dites quelque chose qui ne me plaît pas donc vous desservez votre cause". C'est vraiment ridicule.

    Perso, je suis convaincu que si ça n'avait pas été une femme, mais un homme, ça aurait été la même chose, mais qu'on aurait pas fait tant de bruit.

    Ça apporte quoi une élucubration ?

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

  • [^] # Re: Dans les choux

    Posté par  . En réponse au lien Mon histoire d’amour avec Wikipédia est une tragédie . Évalué à 8.

    Honnêtement, combien d'entre vous avaient entendu parler de Alice Recoque avant le 9 avril ?

    En fait c'est surtout complètement con. Je ne crois pas qu'une encyclopédie ai pour objectif de répertorier les personnes déjà connu par une grande partie de la population.

    D'ailleurs basé la présence sur Wikipedia sur de la notoriété plus que sur de la vérifiabilité me semble complètement con.

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

  • [^] # Re: Tout les deux ou trois ans

    Posté par  . En réponse au lien « 5 raisons pour lesquelles Linux finira par dépasser Windows […] sur les ordinateurs de bureau ». Évalué à 2.

    coucou les trucs électron et les trucs avec des assets 12K quand ton bidule ne gère même pas le 4K etc.

    C'est une manie d'affabuler et de s'inventer ces propres modèles mentaux en informatique que ce soit parce qu'on connaît pas le domaine ou parce qu'on n'aime pas.

    La dernière fois que j'ai vu un gros potentiel de gain de place c'était en arrêtant d'avoir un tzdata qui prenait 20 ans avant et après la date du build (pour une application serveur déployée sur une seule prod et livrée une fois par semaine).

    En ce moment tu as les bibliothèques d'emoji qui commencent à grossir pas vraiment à cause des emoji eux-même mais parce qu'il y a des systèmes de mot clef pour les chercher.

    Au lieu d'inventer des bêtises qui ne servent qu'à alimenter des aigreurs, c'est vraiment intéressant de regarder ce qu'il en est et de découvrir les raisons (évidement en étant ouvert pas et tirant des conclusions hâtives sans véritablement chercher). Ça prend plus de temps que de commenter des lieux communs, mais on apprend plus de choses.

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

  • [^] # Re: PrĂ©dire le passĂ© ?

    Posté par  . En réponse au lien « 5 raisons pour lesquelles Linux finira par dépasser Windows […] sur les ordinateurs de bureau ». Évalué à 3.

    Qu'est ce que tu reproche Ă  l'OOM killer?

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

  • [^] # Re: beaucoup de possibilitĂ©....

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.

    Le chaos report a pleins d'angle morts, mais c'est intéressant que tu prenne ce rapport pour dire le contraire de sa conclusion…

    https://www.agilegenesis.com/post/agile-vs-waterfall-comparing-success-rates-in-project-management

    Les projets agiles ont un taux de succès de 42% et un taux d'échec de 11% là où les méthodes traditionnels donnent un taux de succès de 13% et 59% d'échec.

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

  • [^] # Re: Barrière d'entrĂ©e très haute pour ĂŞtre compĂ©titif

    Posté par  . En réponse au lien Changement de gouvernance pour le navigateur indépendant Ladybird . Évalué à 2.

    Dans mon organisation, on est devenu incapable de délivrer une "version 1" qui ne prenne pas 3 fois le temps qu'aurait mis un dev Cobol dans les années 80. Et le Cobol n'est pas particulièrement sensible aux fuites mémoires…

    Du coup tu compare pas la même chose. Combien de temps tu met en cobol (puisque tu parle du langage) pour fournir la même chose (les même features avec la même qualité - en correction, performance, accessibilité et sécurité -) que ce qui est dans la version 1 de ce que vous faites aujourd'hui ?

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 1.

    Dans quelle édition des JO tu as des billets pour aller voir spécifiquement la flamme olympique ? Et pas des billets pour aller au stade d'athlétisme dans le quel il se trouve qu'il y a la flamme ?

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 2.

    Ils ont toujours existaient, mais lĂ  on parle de gratuit ce qui simplifie beaucoup le processus.

    on parle dans le vent puisqu'elle n'est plus accessible.

    Ça reste intéressant d'échanger sur le sujet je trouve.

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 2.

    Je crois surtout que dans ce genre de cas, on cherche tellement à limiter les coûts que ça part en prod si de simple tests montre que ça marche et qu'il n'y a pas vraiment de réflexion sur l'architecture.

    C'est possible, mais je pense que même si ce n'était pas le cas ça aurait donné la même chose. Parce que gérer de la charge que tu ne connais pas et plus ou moins impossible. L'estimation que tu fais pour tenter de connaître ce que tu es capable de prendre en charge est totalement au doigt mouillé.

    Les JO c'est toujours l'exemple du truc qui est à la fois une charge intensive et tellement ponctuelle que tu n'a que peut de chances de gérer à moins d'oversizer "au cas où" et si tu fait de quoi tenir une grosse attaque DDOS et que tu l'a pas on te dira que tu jette l'argent par les fenêtres1.


    1. c'est le cas avec Roslyne Bachelot pour les vaccins contre le H1N1. C'était pas parfait, mais c'était ambitieux et comme ça n'a finalement pas était une pandémie elle en a pris pleins la tête. 10 ans plus tard on pleurait de ne pas avoir une politique aussi ambitieuses. ↩

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 7.

    En fait c'est typiquement le cas où tu ne fais pas de site. Tu achète les service d'une boite qui sait faire ça. Parce que tu ne sait pas quelle sera ta charge, tu n'a aucun moyen de savoir si tu va prendre 3 fois le nombre de billets que tu as ou si tu va prendre un DDOS parce que les JO, parce que ça amuse un script kiddy, parce qu'un pays veut faire chier le monde,… Ça existe, tu as des gens qui savent vendre des billets de concert pour Taylor Swift ou Beyoncé, ils n'auront aucun mal à gérer ton flux supplémentaire. Potentiellement tu peux même leur acheter une prestation très courte (genre laisser le site en ligne quelques heures/jours seulement).

    Bien coder c'est aussi savoir quand ne pas coder et utiliser une bibliothèque ou un service.

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 9.

    Je te l'ai dis je l'ai expérimenté sur une conférence de 600 personnes hors de Paris.

    J'ai passé ces 6 dernières années à voir ce que ça donne les comportements des spectateurs du football lors du coup d'envoi d'un match du PSG (j'aime pas le foot c'est pas une appréciation de l'équipe elle est simplement bien plus suivie que n'importe quelle autre en France).

    Sur un site bien codé.

    Vraiment je te laisse essayer d'avoir un jour affaire à ce genre de choses avec "un site bien codé". J'ai personnellement vu haproxy (ou plutôt le couple haproxy openssl) à genoux pour beaucoup moins que ça (avant même que du code autre soit impliqué sur du barre métal bien de chez nous avec une connexion d'opérateur bien dimensionnée).

    La charge c'est un truc qu'on prend de haut quand on s'est pas encore pété les dents dessus. Ce n'est pas un reproche ça a était mon cas et on apprend que l'on ne gère jamais la charge, mais qu'on a prévu pour gérer une charge donnée.

    Ton commentaire n'est qu'une série d'a priori. Je te souhaite un jour de mettre au défit ces a priori avec une prod un peu chargée, c'est très enrichissant.

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

  • [^] # Re: SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 2.

    Ton mail a un format facilement parssable pour trouver la date en question ou il est écrit en langage naturel et doit être lu par un humain ou une IA ?

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

  • # SoliditĂ©

    Posté par  . En réponse au journal site de la flamme olympique aux tuileries. Évalué à 3.

    Ça n'existe pas des frameworks open source de résa où toute la partie complexe (file d'attente, gestion propre des erreurs, …) est déjà faite ?

    Ça n'est pas si simple. Pour tenir ce genre d'échelle, ce n'est pas qu'une question de code. Ton déploiement doit aussi être correct et il faut que ton code et ton déploiement bénéficie l'un de l'autre.

    Par exemple à mon avis, si je voulais faire ça j’essaierais de partir sur un fonctionnement très asynchrone avec un brocker (pas en mémoire) de messages qui représentera ta requête et on t'enverrais par mail la confirmation de ta réservation. Donc potentiellement je te demanderais d'indiquer 3 ou 4 horaires qui te conviendrais et le bousin sélectionne ce qui est encore possible. En plus on doit pouvoir tenter de faire une stat sur le temps de traitement en fonction de la taille de la file dans le message et te dire qu'on va te confirmer d'ici quelques minutes.

    Pour info je connais une asso (techniquement j'ai oublié le nom) qui a tenté de ce lancer dans ce genre de service proposé un site de vente de place pour d'autres association et ça a bien foiré dès que c'est monté un peu en charge (de ce qu'on m'a dit il était impossible de corréler les factures, les paiements et les places réservées, il y avait genre x factures, y paiement et z places réservées et aucun des trois ne correspondait et bien sûr il y a eu de la sur réservation - sans qu'il s'agisse d'une attaque ni que ce soit pour un concert d'Elvis Presley).

    Après ça n'enlève pas que de ce que tu décris le site a quand même l'air de bien mal marcher

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

  • # Bug ?

    Posté par  . En réponse au lien HTMX 2.0 est sorti.. Évalué à 3.

    Ton script est buggé il me semble

    https://linuxfr.org/users/wilk/liens/htmx-2-0

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

  • [^] # Re: Tests diffĂ©rents (ou partiels)

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.

    C'est le sophisme de la solution parfaite. Ils ont eu un bug donc ils ne font pas de qualité.

    il est vrai qu'il fut un temps lointain ou à priori le matériel Apple avait un véritable avantage technologique pour les graphistes.

    Dis-moi que tu n'a jamais utilisé une architecture M1 sans me dire que tu n'en a jamais utilisé. Je n'aime pas Apple pour pleins de raisons, mais ça ne doit pas aveugler au point de ne pas voir ce qu'ils font de bien et je suis actuellement obligé d'utiliser un M1, quand il fait plus de 35 chez moi je t'avoue que ça m'arrange par rapport à ma tour que j'aime de tout mon cœur mais qui souffle un air chaud difficilement supportable.

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

  • [^] # Re: Tests diffĂ©rents (ou partiels)

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.

    J'y ai travaillé. ST a surtout besoin que les puces soient livrées sans bug, car on peut pas facilement livrer un fix sur du silicium. L'effort en tests est assez important a ce niveau dans cette industrie en général et a ST en particulier. A l'époque on avait un objectif de nombre de bugs par mm2 de surface, bon c'est toujours un peu couillon ces métriques mais ça démontre l'importance du sujet.

    Moi aussi, mais le nombre d'erreur par mm2 est un élément multifactoriel et c'est plus lié aux logiciels des ateliers eux-même qui a ce que je sache ne sont pas fait en internet. Je pensais plus à la gestion des lots parce que c'est un sujet bien plus simple.

    Si on livre le logiciel qu'une seule fois

    Je comprends ce que tu veux dire, mais la métrique ne me parait pas bonne. L'idée c'est de ne pas tester qu'à la livraison. Si tu as 6 mois de développement tu veut t'assurer que ce qui a était fais le premier jour fonctionne encore 3 mois après et éviter de t'en rendre compte le jour de l'unique livraison.

    Mais ce que je n'ai sans doute pas assez fais ressortir c'est que c'est issu d'un alignement des objectifs. Que le manager veuille de la rentabilité à tout prix ou de la qualité ou autre chose n'est pas un problème en soit c'est juste qu'il faut que les développeurs en soient conscients et s'assurer que c'est bien ce que l'on veut (qu'on est ok d'avoir potentiellement beaucoup de retours utilisateurs par exemple).

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

  • [^] # Re: Tests diffĂ©rents (ou partiels)

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.

    Ce que tu ne peux pas faire c’est dire “on a des UAT, et ils sont implémentés par l’ingénieur, donc on a pas besoin de faire une passe en profondeur manuelle”.

    C'est ce que je disais plus haut, je ne vois pas en quoi dire que les tests d'acceptances peuvent être écris par quelqu'un d'autre que celui qui code la fonctionnalité reviendrait à dire qu'il n'y a pas besoin de test manuel.

    On revérifie pas chaque feature a 100%, mais on s’assure de toucher chaque feature, et on passe un peu plus de temps sur les flows les plus importants.

    Vous avez une manière de l'évaluer ? C'est quoi une feature ? À quelle point ce processus de test dépend de l’expérience du testeur et de sa forme le jour où il fait ces tests ?

    La base données, elle est dans le backend, on parle de tests front end la. Le backend, il a ses propres tests, qui, eux, sont beauuuucoup plus simples à écrire en général.

    Tu fais transiter de la données que tu accède à ta donnée via du SQL, du REST, un protocole spécifique, une API de fichier (POSIX ou pas), ça revient au même. Il n'y a pas de différence fondamentale entre chacune de ses options. Il n'y a pas de différence profonde entre un backend qui utilise S3 et un frontend qui fait du CRUD via un REST maison.

    […] réservée à quelqu’un qui bouffe du code toute la journée (pas un qa).

    Un QA qui fait de l'automation "bouffe" au moins autant de code qu'un ingé

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

  • [^] # Re: Tests diffĂ©rents (ou partiels)

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.

    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

  • [^] # Re: Tests diffĂ©rents (ou partiels)

    Posté par  . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 3.

    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

  • [^] # Re: La restauration de Lomita semble indĂ©pendante de la DRP, finalement

    Posté par  . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à 2.

    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