Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Oui mais un clic sur le bouton +1 c'est mieux qu'un message avec +1000 hein!!Envoyé par souviron34
je dirai meme non voulu, car quand le non prevu devient voulu le bug passe de son status de bug a celui de fonctionnalite.Il faut fournir les preuves que le programme est juste au sens métier.
D'où la question, qu'est ce qu'un bug ? Un événement non prévu ...
<TROLL>Je vais dans l'extrême, mais quand il s'agit de saboter une projet, un bug imperceptible pour les uns peut devenir une fonctionnalité pour quelqu'un<TROLL>.
je sais pas pourquoi mais depuis quelque temps chez moi ça ne marche plusOui mais un clic sur le bouton +1 c'est mieux qu'un message avec +1000 hein!!
"Erreur sur la page"...
(IE 8.0.6)
Je me suis pris un vote négatif. Bon, pour être plus clair, j'ai eu le cas d'une fiche qui faisait l'héritage d'une autre fiche, cependant quelqu'un avait supprimé la référence de l'objet (un bouton) dans la fiche héritée, du coup le code ne pouvait pas être executé. Parfois la pratique n'est pas conforme à la théorie, donc il faut repartir de la théorie pour retrouver le cas pratique en l'implémentant convenablement.
+1, mais celà suppose que l'ancienne application soit fiable, et que les données soient comparables. Et que la hiérarchie comprenne ce que ça veut dire. Y'en a qui m'ont donné 5 semaines pour concocter un comparateur - qui a très bien marché, et a même trouvé les erreurs de l'ancienne appli. Et y'en a pour qui, à partir du moment ou les données ont le bon format, y'a pas besoin de tester plus, ça coute cher...
C'est une vraie connerie ces pouces, mais en tous cas, c'est le plus court chemin vers l'anémie des débats. Tout le monde est content,cool et d'accord.
Peut importe l'ivresse tant qu'il y a un flacon
La possibilité d'être jugé par des gens qui ne comprennent pas le sujet où le texte où simplement sont subjectifs, c'est la dictature de la masse.
Moi je n'en donne pas, et je ne regarde pas. Je ne vais pas travestir mes avis pour quelques personnes me reconnaissent en mettant des petits pouces verts.
Pardonnez moi ce HS, mais je trouve ce système inutile.
Bof rien n'empêche n'importe quel branque de poster "+1", ça revient au même à part que c'est plus synthétique et plus rapide.
L'ancienne application n'était justement pas fiable, mais sur les différences, je pouvais comprendre pourquoi, en tout cas, j'avais des pistes. Si j'ai utilisé cette technique de comparaison, c'est qu'on avait pas droit à l'erreur sur les chiffres, le passé appartenant au passé.
@B.AF: je ne préfère pas penser à un vote électronique pour les prochaines présidentielles.
It is not a bug, it is a feature !
Je ne sais plus de qui est cette phrase.
Je ne vais pas vraiment faire avancer le débat, mais on va dire que je vais étaler ma petite expérience sémantique. Là où je travaille, on distingue deux choses :
- Une réaction imprévue du programme (du genre un message bloquant pour une opération qui normalement passe sans problème et qui devrait passer sans problème après avoir testé la chose dans tous les sens) : c'est un bug.
- Un mauvais traitement de l'information (erreur de calcul par exemple) : c'est un defect.
Bon, d'accord, la frontière est parfois très mince et l'un peu provoquer l'autre...
Et je profite de ce message pour effectivement plus qu'approuver les tests de non-régression qui révèlent énormément de choses. Bien sûr, cela suppose qu'il y avait déjà une version antérieure considérée comme fonctionnant correctement.
Hé bien voilà, ça se serait un bon débat pour la rubrique "best of" !
Ah non mince, tout le monde est d'accord, le vote électronique c'est de la merde
Raté !
Un référundum, please, mais avant d'avoir le vote électroniqueHé bien voilà, ça se serait un bon débat pour la rubrique "best of" !
Ah non mince, tout le monde est d'accord, le vote électronique c'est de la merde
Raté !
J'ai eu un cas, où j'avais besoin à la fois du débogueur et du "printf", parce qu'un objet était instancié deux fois au lieu d'une.
parfois je me dit que les vote negatifs sont arbitraire sinon donnes par des gus constipe et frustres, je comprend pas le vote negatif que vient d'avoir chaplin sur son intervention, mise a part le hors sujet. tiens!j'ai surment repondu a ma question.
tu peux expliquer ton histoire de double instantiation ou il faut debuger pour trouver ,car je sais pas en quelle language c'est mais je crois que normalement ca bug pas ca fait plutot erreur a la compilation.
C'était en Delphi, un objet était instancié dans deux procédures, qui étaient executées l'une après l'autre. D'abord, j'ai déroulé le code dans le débugueur en mode pas à pas, ne trouvant rien, j'ai mis du code dans l'événement de création de l'objet que je soupçonnais.
Le plus dure, c'est de se poser les bonnes questions pour avoir les bonnes réponses, parce que les utilisateurs disent juste "il y a rien qui s'affiche dans la fenêtre".
J'ai eu un cas encore plus fou, entre deux applications développées dans des langages différents, et c'est au final un problème de version d'un navigateur qui provoquait une situation invraisemblable.
Qui dit mieux
J'ai eu le cas de la même appli, fonctionnant parfaitement sur plusieurs OS et une centaine de machines.. Puis vient un jour où elle crashe sur une machine...
Après................. 2 mois de debug ....... à s'arracher les cheveux... Finalement pour s'apercevoir que sur la machine qui crashait un patch d'une librairie système n'avait pas été appliqué...
Ben là je peux vous assurer que tout y est passé : debugger, printf, mise en commentaire de code, quasiment reprendre l'appli avec 1 fonction puis 2 puis... (il y avait 700 000 lignes de code !!!)
C'est ça de faire des applications portables
Je suis surpris (euphémisme) par tous ceux qui disent qu'ils utilisent le print pour debugger lorsqu'ils font du concurrentiels.
J'espère que vous maîtrisez parfaitement le fonctionnement de votre print, parce que dans pas mal dans langages, ils sont asynchrones, sans compter l'influence du système d'exploitation sur lequel vous codez/debuggez...
Faux...
Si tu te sers de la sortie "erreur" (stderr en C)..
Dans ce cas c'est synchrone...
Super, je parle de généralités et toi tu cites un cas précis, merci de ta participation...
Faux...
Si tu te sers de la sortie "erreur" (stderr en C)..
Dans ce cas c'est synchrone...
De plus, étant donné que tu passes par l'OS (et accessoirement le matériel), je ne pense pas que tu puisses affirmer à 100% que sur toutes les plateformes ce soit synchrone pour le stderr du C...
Il est vrai que C, C++, Java, Python, Perl, Php, pour ne citer que les plus courants, ne représentent qu'une infîme portion de ce qui est utilisé
à 100%, non..
Cependant, la taille du tampon système est usuellement tellement faible que la synchroniciité des sorties d'erreur est assurée pour 99.999% des cas...
Or ton intervention semblait viser que systématiquement ce n'est quasi-jamais synchrone... et donc aberrant de ce servir de ça...
Je dis juste "non, ton argument est faux dans l'écrasante majorité des cas"..
Ou pas, puisque je parlais bien d'un environnement concurrentiel... Donc à moins que pour tous ces langages tu es certain de n'utiliser que des threads légers pour lesquels le runtime à la mainmise complète sur les I/O (et encore, si elles sont bufferisées), tu ne peux garantir l'aspect synchrone.
Il est vrai que C, C++, Java, Python, Perl, Php, pour ne citer que les plus courants, ne représentent qu'une infîme portion de ce qui est utilisé
à 100%, non..
Cependant, la taille du tampon système est usuellement tellement faible que la synchroniciité des sorties d'erreur est assurée pour 99.999% des cas...
Or ton intervention semblait viser que systématiquement ce n'est quasi-jamais synchrone... et donc aberrant de ce servir de ça...
Je dis juste "non, ton argument est faux dans l'écrasante majorité des cas"..
Répondre avec citation
Partager