Bonjour à tous les amis codeur(euse)s, j'espère que vous allez bien.
Je suis tombée sur une rediff d'un live de Lynix où un viewer disait avoir trouvé un debugger (https://www.twitch.tv/videos/1486446063?t=00h45m50s) et OUI c'était bien moi qui avait vanté ce debugger hihi. (à chaque fois que j'arrive sur la page twitch le live est off (mais mon record c'est "dernier live il y a 4 heures" (mais ne vous en faites pas un jour j'arriverai à chopper le live en live lol)))
Enfin tout ça pour dire que notre grand maitre à tous a fait une petite vidéo (https://www.youtube.com/watch?v=r9eQth4Q5jg) pour montrer quelques fonctionnalités intéressantes de ce debugger, et on voit qu'il y a quand même des trucs intéressants qu'il n'y a pas dans VS. Du coup Lynix quand vous dites que ok c'est rapide mais ça fait quasiment quedalle du reste c'est quoi le reste ? De quelles fonctionnalités on a besoin que ce debugger ne propose pas et que VS propose ?
Après je suis pas là pour vous convaincre de l'utiliser, c'est juste pour vous mettre au courant de son existence et de ses fonctionnalités, si ça peut potentiellement vous aider dans votre travail si ça vous intéresse, mais sinon moi je m'en fiche déjà il vaut 30$ c'est trop pour la radine que je suis et ensuite j'ai découvert le TDD qui permet tout simplement de se passer du debugger mais je suis encore en train d'expérimenter cette façon de coder.
Rapide ? bof, à quoi ca sert de regarder des variables changer de valeur 2500 fois par seconde ? à part se dire: "Il se passe quelque chose" ? (le but d'un debugger n'est pas d'être rapide) Gestion des threads, ok, ca peut être utile. Absence de coloration syntaxique … en 2022 … s'il y a une fonctionnalité qu'il ne fallait pas louper, c'était celle la! A mes yeux, ca fait toute la différence.
Et bon, comme Lynix l'a dit, les meilleurs outils sont ceux avec lesquels tu es confortable.
J'ai pris le temps de regarder la vidéo de Casey. Je me mets dans la perspective d'un dev qui utilise déjà MSVC et se demande ce que cet outil va lui apporter concretement
- 1 seul fichier à installer et a mettre a jour. Si je continue à utiliser MSVC, je n'ai rien de plus a installer.
- outil externe qui prend un .exe. Ca veut dire passer son temps a switch entre MSVC et cet outil.
- la mise a jour en temps réel des watches. Balek, ca va trop vite pour voir ce qu'il se passe. (A vrai dire, peut être que c'est possible de faire pareil sur MSVC, c'est juste mettre un observer sur un espace mémoire, ce que MSVC sait faire. Mais vu que je vois pas l'utilité, je n'ai jamais regardé si MSVC le fait ou pas).
- freezing threads est très intéressant. Je sais pas si MSVC sait faire ca, je n'ai jamais regardé. (Par contre, c'est un outil à manier avec parcimonie. Si une valeur est modifiée par plusieurs threads et que l'on freeze les threads, alors on loupera les problèmes d'accès concurrent et donc on loupe des bugs).
- pour la vitesse d'exécution, c'est osef pour moi (tant que c'est pas excessivement trop lent). C'est mieux, mais pas un argument pour changer.
- pour afficher des valeurs avec différents types à la volée, je sais pas si ca existe dans MSVC. Par contre, c'est un usage très restreint, c'est pas indispensable. Et c'est facile de créer une variable avec un autre type au pire.
- afficher sous forme de matrices et textes, pareil. (Et potentiellement, peut etre que ca peut être fait avec les custom visualizers)
- idem pour l'affichage de la mémoire.
- idem pour les contextes.
Au final, cet outil est utile a Casey probablement parce que c'est lié à sa façon de programmer et ce qu'il programme. C'est un outil très (trop) spécifique. (Ca me fait penser un peu, en comparaison au débogueur de NVIDIA : ça serait incorrect de dire qu'il est mieux ou moins bien que MSVC. C'est juste un outil adapté à un besoin spécifique, alors que MSVC est generaliste avant tout).
Perso, même s'il était gratuit, je pense pas que je le testerais.
JadeSalina a écrit:
le TDD qui permet tout simplement de se passer du debugger
C'est pas du tout le but du TDD. Et ça n'empêche pas d'utiliser un débogueur.
- freezing threads est très intéressant. Je sais pas si MSVC sait faire ca, je n'ai jamais regardé. (Par contre, c'est un outil à manier avec parcimonie. Si une valeur est modifiée par plusieurs threads et que l'on freeze les threads, alors on loupera les problèmes d'accès concurrent et donc on loupe des bugs).
Oui MSVC est tout à fait capable de gérer plusieurs threads (et de freeze ceux qui ne nous intéressent pas), et même plus : le débuggeur de MSVC peut s'attacher à plusieurs processus en simultané et tu peux gérer des breakpoints/freeze entre eux (chose que je fais très régulièrement à mon taff vu qu'on est sur une archi multi-processus qui interagissent entre eux).
JadeSalina a écrit:
notre grand maitre à tous
Tu te rends bien compte que tu nous le fais détester plus que tu ne nous le vends, le Casey ?
Ca me surprend pas. J'utilise principalement QtCreator sur Mac, pour ca que je connais pas très bien les IDE principaux des plateformes (MSVC, XCode, etc. je les utilisent que si je suis bloqué sur un debug qui ne passe pas dans QtCreator), mais je voyais pas trop de raison qu'ils ne puissent pas faire la même chose.
Ce qui m'embête le plus dans un débugueur externe, qu'il soit bon ou non, c'est qu'il est externe.
Ce que j'aime bien, c'est être dans mon IDE de visual studio, en train de coder, je mets mon breakpoint avec F9, et quand j'appuie sur F5 il compile, lance, et m'amène directement à mon breakpoint.
Quand je vois ce monsieur Casey coder sans IDE, j'ai cette image d'un mec avec son tournevis à main qui me dirait : "ouais ! pas besoin de visseuse, c'est pour les ***** les visseuses !"
c'est balèze de vouloir parler d'un débogueur sans jamais avoir donner son nom RemedyBG (il faut aller voir les vidéo pour enfin trouver le nom, c'est pour avoir des clics ? )
j'ai découvert le TDD qui permet tout simplement de se passer du debugger mais je suis encore en train d'expérimenter cette façon de coder.
Si seulement les choses étaient aussi simples que cela...
Allez, une petite blague pour te faire comprendre le problème:
Question: quelle est la différence entre la théorie et la pratique?
Réponse:
La théorie, c'est quand cela ne fonctionne pas et que tout le monde sait pourquoi
la pratique, c'est quand cela fonctionne et que personne ne sait pourquoi
...
La théorie rejoint la pratique quand cela ne fonctionne pas et que personne ne sait pourquoi
Hé bien, la théorie du TDD, elle est à proprement parler géniale: tu t'arranges pour que chaque ligne de code que tu écrive soit testée afin de t'assurer que ton code fasse effectivement ce que l'on s'attend à ce qu'il fasse.
Après tout, si tu peux affirmer sans le moindre doute -- et preuve à l'appui -- que ton code fait exactement ce que l'on s'attend de sa part et de la manière dont on s'y attend, ton code ne peut être que juste, n'est ce pas?
Malheureusement, cette théorie présente un biais pour le moins problématique parce qu'elle sous-entend que l'intégralité du code que tu écris doit être testée.
Et quand je parle d'intégralité, je veux bel et bien parler de 100%, pas moins! Il est totalement hors de question de se contenter d'une couverture atteignant (par miracle ?) les 98.9%, parce que si tu dois avoir un problème -- et tu peux d'ailleurs être sure que tu auras un problème -- ce sera forcément au niveau du "petit" 1.1% qui n'est pas testé.
Manque de bol, sur un projet un tant soit peu "important", tu atteint très facilement 1 000 000 de lignes de code, ce qui implique que le 1.1% de lignes de code non testées représente "la bagatelle" de ... 11 000 lignes de codes susceptibles de contenir une erreur.
Et pour te donner une idée, ces 11 000 lignes de codes, cela correspond à plus de deux fois l'intégralité du code que j'ai écrit pour mon livre!
Alors, bien sur, il y a "la bonne manière" de mettre TDD en action, et il y a "la mauvaise". Bien sur, si tu utilises la bonne manière d'appliquer TDD, tu devrais ... en théorie, atteindre une couverture de tests à 100%.
Pour notre malheur, on peut déjà estimer que cette "bonne mise en oeuvre" du TDD ne sera pour ainsi dire jamais correctement mise en pratique sur le long terme.
Et quand bien même, tu arriverais effectivement à garder une couverture de tests à 100% pendant "un certain temps" sur ton projet, tu ne serait pas sauvée pour la cause.
Car le simple fait d'avoir recours à TDD présente déjà un sérieux problème, même s'il est à relativiser du fait des bénéfices: Tu as, en plus de ton code "normal" comme source d'erreurs potentielle, tu as aussi ... le code de tes tests à prendre en compte.
En effet, si un test ne "passe pas", tu dois te dire qu'il y a deux solutions:
Soit, le code que tu as écrit pour ton programme ne fait simplement pas ce que l'on attend de lui
Soit, et c'est beaucoup plus vicieux, c'est le code des tests eux-même qui pose problème en ne testant pas forcément ce qu'ils étaient censés tester
Si bien que, si un test ne passe pas, tu dois non seulement t'assurer que ton code "effectif" sera correct, mais aussi (et surtout) que le code de tes tests est correct.
Et pour notre plus grand malheur, ce n'est pas en lisant et en relisant le code (effectif comme de tests) que tu pourras t'assurer de ce fait.
Bien sur, la (re)lecture attentive du code te permettra (souvent) de repérer les erreurs les "plus grossières" comme les fautes de frappes ou les fautes d'attention comme un if(a = b) au lieu d'un if (a == b).
Malheureusement, il y aura toujours un moment où une simple relecture attentive ne sera plus suffisante, où, pour comprendre l'origine du problème, il faut aller ... voir ce qui se passe exactement au niveau de la machine, par exemple
Pourquoi ai-je une erreur alors que ptr est bel et bien un pointeur (que je considère dans ma petite tête comme étant) valide sur la donnée que le code manipule?
Pourquoi est-ce que je passe systématiquement dans la branche "faux" du test alors que je m'attend à ce que ce test me donne un résultat "vrai"?
Ainsi que plein d'autres questions spécifiques à ton projet ou à ton code
Le problème, c'est que pour pouvoir répondre à ce genre de questions, ben, tu n'auras de toutes manière pas d'autre choix que ... d'utiliser un outil qui te permette de visualiser les données qui sont réellement manipuler
Et devines quoi? nous avons l'outil parfait pour ce genre de travail. Cela s'appelle... un débuggueur
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Et gdb n'est pas satisfaisant sur Windows? J'ai déjà installé MinGW-W64 de sourceforge sur Windows 10 et gdb fonctionne. J'ai maintenant le compilateur suivant: g++ (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. @koala01: dans 0.00001 % des cas, même le compilateur n'est pas fiable, surtout avec l'option -O3 ... Bien que je n'ai jamais eu de problème en -O3 jusqu'ici.
Le Tout est souvent plus grand que la somme de ses parties.
Ah donc pour vous c'est pas une révolution mondiale, mais c'est quand même intéressant qu'il se lance rapidement au lieu d'attendre, et le fait que tout soit dans un seul fichier au lieu d'installer VS pendant 30 minutes c'est pas bien ? Pourquoi on voudrait avoir des gros installeurs au lieu de juste lancer un petit executable ?
Lynix a écrit:
Tu te rends bien compte que tu nous le fais détester plus que tu ne nous le vends, le Casey ?
Non je me rend pas compte, pourquoi le fait que je trouve qu'il est très fort vous fait le détester ? Au contraire c'est pour vous faire voir la lumière (je dirais presque "divine" mais peut être que je m'emporte). C'est quand même dommage vous passez à côté d'un contenu très intéressant sur Handmade Hero, sur la programmation bas niveau, etc (ok c'est plus du C que C++ mais on peut quand même adapter les concepts en C++)
Et pour le TDD du coup flute je me suis faite arnaquer je croyais que c'était un nouveau truc ultime, je l'ai découvert avec les vidéos de WealCome (par exemple celle là https://www.youtube.com/watch?v=nbSaq_ykOl4) du coup j'arrête de regarder il faudrait pas que je prenne de mauvaises habitudes avec un mec qui sait pas ce qu'il fait
c'est quand même intéressant qu'il se lance rapidement au lieu d'attendre
Personne n'a dit qu'il le trouvait intéressant ou qu'il se lançait rapidement.
JadeSalina a écrit:
Non je me rend pas compte
(...)
mais peut être que je m'emporte
Tu donnes l'explication toi même : ton comportement insupportable produit une réaction de rejet chez ceux qui te lisent.
JadeSalina a écrit:
Et pour le TDD du coup flute je me suis faite arnaquer je croyais que c'était un nouveau truc ultime
Ca existe depuis 20 ans.
Et c'est un truc très bien. Je te conseille de faire du TDD.
Ce qu'on te disait, c'est juste que ca ne remplace pas le débogage.
JadeSalina a écrit:
vous passez à côté d'un contenu très intéressant sur Handmade Hero, sur la programmation bas niveau, etc (ok c'est plus du C que C++ mais on peut quand même adapter les concepts en C++)
Tu n'as toujours pas compris un point : si j'ai pris le temps de regarder une partie des vidéos que tu as donné, c'est justement parce que je suis intéressé par les idées nouvelles.
Et donc je te le dis et le répète : non, je ne trouve pas le contenu de HMH "très intéressant". Et donc non, je passe pas à côté de ce contenu.
Pour un débutant C++, je ne conseille pas de regarder ses vidéos : c'est pas du C++ et il dit pleins de conneries en C++.
Pour un dev de jeux vidéos, je ne conseille pas de regarder ses vidéos : c'est une approche très old school, où tout est refait à la main, ce qui est une perte de temps.
En termes de gestion de projets et ce conception, aucun dev pro sérieux ne bosse comme lui : sa façon de travailler est inacceptable en termes de standard de qualité.
En termes de personne, Casey est un gros con arrogant. Humainement, c'est le gens de personne a fuire comme la peste et à ne surtout pas prendre comme exemple.
Et bien sûr qu'il ne dit pas 100% de conneries dans ses vidéos. Mais vu tout ce que j'ai dit avant, c'est une perte de temps de les regarder. Il y a du contenu sur YouTube bien plus pertinent a regarder.
> Et pour le TDD du coup flute je me suis faite arnaquer je croyais que c'était un nouveau truc ultime, je l'ai découvert avec les vidéos de WealCome (par exemple celle là https://www.youtube.com/watch?v=nbSaq_ykOl4) du coup j'arrête de regarder il faudrait pas que je prenne de mauvaises habitudes avec un mec qui sait pas ce qu'il fait
En fait, ton problème, c'est d'inventer des propos que les gens n'ont jamais dits.
Il ne dit jamais qu'avec le TDD il n'y a plus besoin de débugger, il dit que concevoir les tests avant et en complétant le code de manière continue, il n'a pas besoin de passer par le débugger pour savoir ce qui se passe. Par conséquent l'utilisation du débugger est - je cite - rare. Cela s'explique très bien par le fait que les tests indiquent la valeur d'entrée et de sortie.
Alors oui, d'après lui, les gens passent 90% de leur temps à faire du débug et jouer avec le débuggeur. Je ne sais pas où il a bossé pour avoir de tels chiffres, mais probablement sur des projets qui n'avaient aucun test. Et c'est magique, avoir des tests réduit le nombre de bug et par conséquent donc le besoin du débugger.
Et pour le TDD du coup flute je me suis faite arnaquer je croyais que c'était un nouveau truc ultime, je l'ai découvert avec les vidéos de WealCome (par exemple celle là https://www.youtube.com/watch?v=nbSaq_ykOl4) du coup j'arrête de regarder il faudrait pas que je prenne de mauvaises habitudes avec un mec qui sait pas ce qu'il fait
TDD n'est absolument pas "nouveau", ca fait plus de vingt ans que la méthode existe
Et c'est, effectivement un outil au potentiel proprement faramineux. Il n'y a donc absolument aucune arnaque dans le fait de promouvoir la pratique, bien au contraire.
Il faut juste que tu arrives à te mettre en tête que cette technique particulière n'est qu'un outil et que, en tant que tel, elle est soumise à la même restriction que n'importe quel autre outil, aussi puissant soit-il. Tous les outils seront, au final, manipulés par ... un humain. Et c'est justement là qu'est tout le problème.
Car cela implique qu'il faut tenir compte du facteur humain. Or, l'humain est faillible par nature. Quoi qu'il fasse, la probabilité qu'il se plante ou qu'il fasse "une connerie" est systématiquement plus importante que celle qu'il fasse les choses "correctement".
Et le pire, c'est que c'est vrai pour absolument tout le monde: ne crois pas que je considère "faire partie de l'élite" et ne pas devoir me compter dans le lot. Bien au contraire: je suis suffisamment conscient de mes limites que pour savoir que je vais me planter, et sans doute même plus souvent que d'autres.
Et tant que tu n'intégrera pas cette probabilité d'une erreur due au facteur humain dans ton raisonnement, tant que tu te croiras dans le monde des bisounours, nous ne pourrons pas faire autrement qu'être en désaccord avec toi, car ton raisonnement t'incitera à prendre des raccourcis, à considérer que "bah, telle sécurité ne sert finalement à rien", tellement tu es sure que le risque d'erreur est nul, que nous ne pourrons rien faire d'autre que te répondre que le risque d'erreur est bel et bien présent et qu'il faut en tenir compte.
Espère le meilleur, attends toi au pire, tu ne sera jamais déçue.
Ne perds pas ton temps à te demander si telle erreur risque vraiment de survenir, car elle a déjà eu lieu avant même que tu ne te rende compte qu'elle était susceptible de survenir.
Si tu tiens à poser une question sur une erreur, demande toi plutôt quand elle aura lieu car la réponse sera toujours en ta défaveur, vu qu'elle surviendra toujours au pire moment qui soit.
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Ah donc pour vous c'est pas une révolution mondiale, mais c'est quand même intéressant qu'il se lance rapidement au lieu d'attendre, et le fait que tout soit dans un seul fichier au lieu d'installer VS pendant 30 minutes c'est pas bien ? Pourquoi on voudrait avoir des gros installeurs au lieu de juste lancer un petit executable ?
Alors en fait ... j'installe pas VS à chaque fois que je dois lancer le débugger, sinon effectivement l'intérêt serait immédiat.
Par contre, les autres, vraiment, arrêtez de lui répondre. JadeSalina est passée en mode full troll, quand on lit ça :
JadeSalina a écrit:
Au contraire c'est pour vous faire voir la lumière (je dirais presque "divine" mais peut être que je m'emporte).
Ou même ça
JadeSalina a écrit:
il faudrait pas que je prenne de mauvaises habitudes avec un mec qui sait pas ce qu'il fait
On est très clairement en face d'une personne qui, si elle ne trollait pas initialement (ce dont je commence à douter), est partie en mode full troll, parce qu'elle a bien vu qu'on n'était pas d'accord avec elle et qu'on avait pas la même opinion sur Casey, c'est acté depuis des mois. Elle n'essaie pas de nous convaincre, la dissonance cognitive n'est pas assez forte pour lui faire remettre en question son amour des gourous (parce que c'est ça qu'elle recherche, un gourou), elle cherche juste à nous faire réagir en multipliant les petites piques et en poussant plus à l'extrême son propos.
La seule réaction intelligente ici c'est d'arrêter de lui donner du crédit et de la visibilité, à défaut de pouvoir la ban du forum, arrêtons de lui répondre, ce n'est pas comme s'il restait des choses qui n'avaient pas été dites.
En ce qui me concerne en tout cas, la moindre évocation de Casey ou de Handmade Hero me fera quitter instantanément le thread, et je vous recommande de faire de même.
C'est marrant quand même, parce qu'à la base je ne connaissais que peu Casey / Handmade Hero, et quand on m'en parlait sur Twitch je disais simplement que je n'avais pas d'avis sur la question. Aujourd'hui si on me repose la question je parlerai des dérives que l'arrogance peut produire chez les personnes les plus influençables, et qu'il faut se méfier de son travail et de son culte de la personnalité.
Non je me rend pas compte, pourquoi le fait que je trouve qu'il est très fort vous fait le détester ? Au contraire c'est pour vous faire voir la lumière (je dirais presque "divine" mais peut être que je m'emporte).
Sacré culte de la personne !
S'il était au courant, ce Casey, de à quel point tu te prosternes devant lui, il profiterait surement de la situation. Surtout si tu es une fille car lui il a un peu une tête à avoir vu très peu de filles dans sa vie, hem....
ça doit être pas mal quand même d'avoir des filles qui nous prennent pour des dieux, faudrait que je monte une secte pour voir ce que ça fait. ... Enfin je crois que ma femme ne serait pas d'accord...
Moi je trouve que les réponses des experts sont quand même intéressantes, même si l'auteur reste dans son "délire", les réponses peuvent toujours servir à d'autres personnes
Moi je trouve que les réponses des experts sont quand même intéressantes, même si l'auteur reste dans son "délire", les réponses peuvent toujours servir à d'autres personnes
Le problème c'est que ça marche aussi dans l'autre sens, ça donne de la visibilité à Casey et des gens influençables peuvent tomber dans le même culte de la personnalité.
Il y a bien assez de réponses très intéressantes sur les autres sujets du forum, et si tu en as toi-même (ou quelqu'un d'autre), il ne faut pas hésiter à ouvrir un topic.
Mais Casey a rien fait de mal, c'est juste moi qui aime ce qu'il fait et sa façon de parler, quand il parle j'ai l'impression que tout le monde sont des mer*** et que l'intégralité des pratiques modernes sont complètement pété et que le C++ commitee ne savent pas coder. Et c'est pour ça que je suis venu la première fois sur ce forum, c'était pour demander (ok un peu vulgairement) si "les mecs qui font du C++ sont perdus et si ils ont entendu parler des techniques alternatives de Casey" et du coup vous avez dit que les pratiques modernes étaient bonnes et que c'est Casey qui faisait n'importe quoi, et VOUS M'AVEZ MIT LE DOUTE parce que c'est vrai que c'est un peu un 1 contre le reste du monde mais après ça veut pas non plus dire que la majorité a raison (cf Raoult)
Et j'ai déjà essayé de supprimer des messages mais on peut juste les modifier, donc si vous voulez effacer mon existence sur ce forum, vous pouvez le faire mieux que moi !
Probablement ma dernière réponse sérieuse sur le sujet de Casey, profite.
JadeSalina a écrit:
Mais Casey a rien fait de mal, c'est juste moi qui aime ce qu'il fait et sa façon de parler
C'est ton droit, et y'a pas de soucis avec ça.
Le souci il vient quand tu nous mets Casey dans la tronche en disant "Il est meilleur que vous prenez exemple", à des gens qui sont dans le métier et qui ont bien plus d'expérience que toi, et qui sont donc plus apte à juger du bien fondé (ou non) de la méthode Casey.
JadeSalina a écrit:
parce que c'est vrai que c'est un peu un 1 contre le reste du monde mais après ça veut pas non plus dire que la majorité a raison (cf Raoult)
Alors en fait Raoult aussi raconte vraiment n'importe quoi depuis le tout début de la pandémie, ça ne fait même plus débat, surtout avec le recul qu'on a aujourd'hui.
Ton problème c'est d'être attirée par l'idée qu'une personne à elle toute seule soit meilleure qu'un groupe entier, l'histoire a souvent révélé que c'était pas le cas général (Raoult et Casey ne font pas exception).
JadeSalina a écrit:
Et j'ai déjà essayé de supprimer des messages mais on peut juste les modifier, donc si vous voulez effacer mon existence sur ce forum, vous pouvez le faire mieux que moi !
Mince, si seulement tu étais dotée d'un libre arbitre et de la possibilité d'arrêter de relancer le sujet en boucle en y allant de plus en plus fort.
Ce n'est pas parce que tu ne peux pas supprimer tes anciens messages (ou ton compte) que tu es obligée de continuer, faut pas déconner.
"S'il était au courant, ce Casey, de à quel point tu te prosternes devant lui, il profiterait sûrement de la situation. Surtout si tu es une fille car lui il a un peu une tête à avoir vu très peu de filles dans sa vie, hem...."
Il faut être un gourou pour avoir des nanas ? Moi qui pensait qu'il fallait coder en assembleur ! Remboursez !
"il a un peu une tête à avoir vu très peu de filles dans sa vie, hem..." Même sans la tête , tu peux pas passer ton temps à faire 600 vidéos , faire un blog avec 100 articles et 5000 projet en même temps , si t'as une nana
Et qui dit que JadeSalina est une nana? A-t-il (ou elle) employé le féminin à son sujet?
oui, elle l'a fait... Maintenant, c'était peut être par erreur
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Et après on se demande pourquoi y'a aussi peu de représentantes de la gente féminine dans l'informatique.
Je ne pense pas que quelques petites blagues un peu potaches soient responsables de la désertion de l'informatique par les femmes, loin de là.
Le peu de collègues femmes que j'ai auraient été amusées par la petite bêtise que j'ai sorti. Je pense que c'est pour tout plein d'autres raisons que les femmes ne veulent pas aller en informatique.
Je préfère ne pas entrer dans ce genre de débat ici.
>Mais je ne comrpends pas pour le moment ou est la différence.
Mauvais panel, le "but" c'est de ne pas "ne pas choqués" celles qui ont passées le pas malgré ces remarques "à la con" , mais de ne pas rebuter celles qui sont sensibles ces remarques "misogynes".
Comme le disait Desproges : "on peut rire de tout mais pas avec n'importe qui"
- Edité par bacelar 23 mai 2022 à 10:50:52
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
ensuite j'ai découvert le TDD qui permet tout simplement de se passer du debugger mais je suis encore en train d'expérimenter cette façon de coder.
C'est déjà faux en Proof Driven Development pour une raison toute simple : les méthodes qui valident les développements au fur et à mesure le font en fonction d'une spec qui peut elle-même contenir des erreurs (dans le cas du PDD, une spec formelle, dans le cas du TDD, les tests), alors clairement pour imaginer que ce soit vrai en TDD, il faut n'avoir absolument pas réfléchis à la question.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Le Tout est souvent plus grand que la somme de ses parties.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C