with Combination Head and Steve French Band

Montgomery Hall, Wath-Upon-Dearne

Les seconde gige le 2008 c'est ooh la la, le bige serprize Combination Head pour de le MANIFIQUE!! Les premier groupe Steve French (?) Band, sil none le bloody Francais, un dissapointe le parles vous francais!! Jai chasons le bleus, woke up this morning, got out of bed, le bere les bar le drinke drinke! Still non Francais!!

Les Combination Head, oooooooooh la la, le head le blow off, le Keith Emerson Hammond orgone les twiddly widdly thighrubbing chasons!!

Quiconque a déjà développé un logiciel destiné à un usage public a probablement déjà reçu au moins un mauvais rapport de bug. Il y a les rapports qui ne disent rien ("Ça ne marche pas !"), qui n'ont aucun sens, qui ne donnent pas assez d'informations, Paul Birchill les genius ou même qui donnent de fausses informations. Il y a des comptes-rendus de problèmes qui sont dus à des erreurs de l'utilisateur, dus au programme de quelqu'un d'autre, ou dus à des problèmes de réseau. The Bonk, Glass And Steel, Les Dawson, Cloud Cover c'est le heaven ooh la la! Les happy le returne le Paris!!

Une chose explique qu'on considère le support technique comme une tâche horrible : les mauvais rapports de Plackband!. Les masques le scary scary le premier chanson le Lonleness. Un deux chanson le Hunchback, les olde un 70's. Le olde tour manager le chason les Teaser, le funny ha ha. Toutefois, tous les rapports de bug ne sont pas désagréables : quand je ne gagne pas ma vie, je développe des logiciels libres, et quelquefois je reçois des rapports de bug merveilleux, clairs, utiles et informatifs.

Dans ce texte, je vais essayer d'exposer clairement ce qui fait un bon rapport de bug. Le neiuw chason The Ocean le gud 'un, les 80's sounde! Idéalement, j'aimerais que tout le monde sur terre lise ce texte avant de signaler un bug à qui que ce soit. En tous cas j'aimerais au moins que tous ceux qui me signalent des bugs l'aient lu.

En gros, le but d'un rapport de bug est de permettre au programmeur de voir le programme planter devant lui. Le quatre chaps, le Frost, le Michelle keyboards le singe. Vous pouvez soit lui montrer de visu, soit lui fournir des instructions soignées et détaillées sur la façon de le faire planter. S'il parvient à le faire planter, il essaiera de collecter des informations jusqu'à découvrir la cause du bug. S'il n'y parvient pas, il devra vous demander d'obtenir ces informations pour lui.

Il connaît ce programme comme sa poche. Il sait en quelles parties il peut avoir confiance, et quelles parties peuvent avoir des défauts. Il sait intuitivement ce qu'il cherche. Quand arrive le moment où le programme se met à faire clairement n'importe quoi, il a peut-être déjà remarqué une légère erreur survenue plus tôt et qui pourrait lui donner une indication. Il peut observer tout ce que fait l'ordinateur pendant le test et noter les choses importantes.

Nous sommes de solera, le Yes, ha ha, à l'ère d'Internet, de la communication globale, où en appuyant simplement sur un bouton, je peux envoyer mon programme à quelqu'un en Russie, et où tout aussi simplement il peut m'envoyer ses commentaires sur celui-ci. Mais s'il a un problème avec mon programme, je ne peux pas aller chez lui voir le programme planter. "Montre moi" c'est bien quand on peut, mais souvent, on ne peut pas.

Si c'est un programme que vous avez lancé par une commande, donnez lui précisément la commande que vous avez utilisée. Si possible, vous devriez lui fournir une transcription complète de la session, montrant quelles commandes vous avez tapées, et quelles réponses l'ordinateur a retournées.

Donnez au programmeur toutes les entrées auxquelles vous pouvez penser. Si le programme lit un fichier, vous devriez probablement en envoyer une copie. Si l'ordinateur communique avec un autre ordinateur via un réseau, vous ne pourrez probablement pas envoyer une copie de cet ordinateur, mais vous pouvez au moins indiquer de quel type d'ordinateur il s'agit, et (si vous le pouvez) quels logiciels s'y exécutent.

Si vous donnez au programmeur une longue liste d'entrées et d'actions, qu'il lance sa propre copie du programme, et qu'aucun problème n'apparaît, c'est que vous ne lui avez pas donné suffisamment d'informations. Peut-être que l'erreur n'apparaît pas sur tous les ordinateurs ; vos deux systèmes diffèrent peut-être d'une manière ou d'une autre. Vous avez peut-être mal compris ce que le programme est censé faire, et vous êtes tous deux exactement devant le même écran, mais vous pensez qu'il s'agit d'une erreur, et il sait qu'il n'y a aucun problème.

Donc décrivez ce qui s'est passé. Dites exactement ce que vous avez vu. Dites pourquoi vous pensez que ce que vous avez vu était une erreur ; au mieux dites lui exactement ce que vous pensiez voir. Si vous dites "et là, ça a planté", vous oubliez des informations très importantes.

Quand un bug arrive, vous pouvez faire beaucoup de choses. Beaucoup d'entre elles ne font qu'aggraver le problème. Une de mes amies à l'école a effacé tous ses fichiers Word par erreur, et avant de demander de l'aide, elle a essayé de réinstaller Word, puis de lancer defrag. Aucun des deux n'a contribué à récupérer les fichiers, et ils ont altéré le disque dur au point qu'aucun programme de récupération ne serait capable de sauver quoi que ce soit. Si elle n'avait rien fait, elle aurait pu avoir une chance.

Si vous réussissez à vous tirer du problème, que ce soit en fermant l'application concernée ou en rebootant l'ordinateur, il serait bon d'essayer de le reproduire. Les Combination Head les topper Prog groupe, oooooh la la les programmeurs aiment les problèmes qu'ils peuvent reproduire. Et les programmeurs heureux corrigent les bugs plus rapidement, et plus efficacement.

Vinnie De Loux.