アカウント名:
パスワード:
エラーが出た。動かない。……それじゃ分からんというの。
「どの画面でどんな操作をしたら、何が起きた。」とか、「エラーメッセージの○○が表示された。」とかなら、まだ調べようがある。何が起きていて、何をしたいのか明確に説明して欲しいものです。
Windowsの場合、必要なデータを可能な限りバックアップして、Windowsをクリーンインストールしなおせなんて回答がよくあって、もめる原因になる。でも、コンポーネントストアや、ユーザープロファイル、システムプロファイルあたりが死んでいると、システムの修復ができないことも多い。
> 何が起きていて、何をしたいのか明確に説明して欲しいものです。
それができないから、それを因数分解する人がフロントSEといわれる人なわけです。はい。ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、ソフト自体には興味ないので、そのソフトの挙動についていろいろと求めるには限界がある。
>ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、
もしそうだったとしても・実務上期待される動作(今まで動いていた動作のあらまし)・実際に起こった挙動を報告するのは出来ると思うんだよね
出来たら苦労しないのよ。老若男女問わず、情シス経験者でもない限り問い合わせ1回目ではまずその情報は出てこない。出てきたら感動して1日は他人のことなのに自慢するレベル。
ソフトの挙動について求めてはいないんだ。あなたの挙動について求めたいんだ。
Bit別冊の「GNU Emacsマニュアル」の障害報告の節を読んだときに目から鱗がポロポロ落ちた記憶があります。
日本語訳はあちこちにありますが、例えば↓https://flex.phys.tohoku.ac.jp/texi/emacs-jp/emacs-jp_238.html#SEC263 [tohoku.ac.jp]
Emacsは最新版の和訳文書があるので、それを紹介してくれhttps://ayatakesi.github.io/emacs/27.1/html/Bugs.html [github.io]
52 バグの報告
Emacsでバグを見つけたと思ったときは、それを報告してください。それをfixすることは約束できませんし、それがバグであると常に認める訳ではありませんが、もちろんそれについて知りたいのです。追加したいと考える機能についても、同じことが言えます。以下のセクションは、有効なバグレポートを作成する助けとなるでしょう。
Known Problems 既知の問題とバグについて読む方法。
Criteria 本当にバグを見つけたのか?
Understanding Bug Reporting バグを報告する効果的な方法。
Checklist 良いバグレポートのために従うべきステップ。
Sending Patches GNU Emacsにパッチを送る方法。
52.3 バグレポートの理解
バグがあると判断したときは、それを報告すること、そして有用な方法で報告することが重要です。もっとも有用なのは、Emacsを起動するシェルコマンドから、問題が発生するまでに、何のコマンドをタイプしたかの正確な記述です。
バグレポートのもっとも重要な原理は、事実を報告することです。仮定や口頭の説明は、詳細な生データの代替にはなりません。事実の報告は簡単ですが、多くの人は事実のかわりに仮定の説明をしようと懸命に努め、それを報告するのです。その説明がEmacsが実装されている方法にたいする仮定にもとづく場合、それらは使い道がありません。その一方で事実の欠落により、わたしたちはバグについての実際の情報を得られないでしょう。実際に問題をデバッグして、推定を超える説明を報告したい場合、それは有用です— しかし、どうか生の事実も同様に含めてください。
たとえば、C-x C-f /glorp/baz.ughRETとタイプして、ファイルをvisitしたとき、そのファイルが偶然大きい(とあなたは知っている)ファイルで、Emacsが‘Ifeel prettytoday’と表示したとします。バグレポートにはすべての情報が必要になります。あなたは問題がファイルのサイズにあると仮定して、“大きなファイルをvisitしたら、Emacsが‘Ifeel pretty today’と表示します”、などと報告すべきではありません。これはわたしたちが“推測説明(guessingexplanations)”と呼ぶものです。ファイル名に‘z’があるという事実が、問題の原因かもしれません。もしそうなら、あなたの報告を受け取ったとき、わたしたちは大きなファイルで問題の再現を試み、それらのファイル名にはおそらく‘z’が含まれておらず、問題を確認できないでしょう。名前に‘z’が含まれるファイルをvisitしてみるべきだと、推測できる方法はありません。
C-xC-fのではなく、“ファイルをvisit”とさえ言うべきではありません。同様にテキストを入力する方法では、“その行に3文字あるとき”ではなく、“RETA B C RET C-pとタイプした後”と書いてください。
可能なら、すぐにバグを再現するためにemacs -Q(Emacsは初期のカスタマイズなしで開始されます。Initial Optionsを参照してください)でEmacsを呼び出して、バグを発生させるステップを繰り返してみてください。この方法でバグを再現できたら、あなたの個人的なカスタマイズをバグから除外できます。バグレポートは、Emacsをemacs-Qで開始したことから始まり、バグを再現させる正確な一連のステップを続けるべきです。可能ならバグを再現するのに必要な、正確なファイル内容を報告してください。
emacs-Qでは再現できないバグもいくつかあります。結局は再現するのが難しいバグもあります。そのような場合、何を行なったかを報告すべきです —が、前述したように、どうか最初にバグを発生させた生の事実を固持してください。
報告したい複数の問題がある場合は、どうかそれらを個別のバグとしてそれぞれ報告してください。
52.4 バグレポートのためのチェックリストには、レポートに含めるべき事項と、不要な事項がリスト形式でまとめられている。https://ayatakesi.github.io/emacs/27.1/html/Checklist.html [github.io]
情報ありがとうございます。現在まで和訳され続けているとは知りませんでした。ご教示と、そして翻訳をされている方々に感謝します。
バグ発生前の操作を完全に覚えてるわけないんだから、推測説明以外では報告のしようがない。正確な操作ログが欲しいんだったらEmacsで勝手に保存しとけよ。
バグを修正できない言い訳を並べてるようにしか見えんわ。
そしてEmacsにキーロガーが仕込まれていたと祭りになるのですね。
このコメントはただ茶々を入れてるだけなんだが、
IMEをオフにすることは含めなくてよいのだろーか
近年はそうとも言えんのですよ
マジもんで「何もしていないのに壊れた」が発生しますので
ええ、原因は強制自動アップーデートでございます
# アップグレードしますか はい/後で なんてちゃちなもんじゃねぇ
コメントアウトにコメントするのはなんだけど、出勤したら画面が黒いままでうんともすんとも言わないって連絡が来るんだよね。「ずっとくるくるがまわってる」ってのもある。
元サポートとしては、「そういうやり取り面倒だから情報収集ツール送ってくれ たらすぐ取るよ」と思ってしまう。基本的にエンドユーザは当然ながら、SEの言うことですら頭から信じてしまうと 調査は迷走する。表面に出てくる現象は氷山の一角でしかなく、信じられるのはlogのみ!なので情報収集ツールの実行をお願いされたら、めんどくさがらずに素直に従っ てくだしあ。
Microsoft「だからテレメトリーデータを取らせてね。フィードバックHUBで再現データを送れるようにするしね。」
そして再現しようとすると出ないのはお約束#Windowsに限らんけどあるあるネタ
よくあるのが「エラーが出た。自分は何もしていない」ってやつだな。何もしてないわけ無いだろ、と。
何もしてないこともありますよ。例えば https://hardware.srad.jp/story/17/02/23/0636215/ [hardware.srad.jp] とか。対策済みだと言うならごめんなさい。
「エラーが発生しました」としかメッセージを出さないソフトウェアもあるからなぁ。そうじゃなくてエラーメッセージを書けよって言うからスクリーンショット送ってやったら黙ったわ。
経験的にはネットワークやファイルI/Oまわりは、エラーメッセージが雑になりがちな印象がある。
「ネットワークの接続に失敗しました」→ 実際には接続は成功していて、その後の処理でエラー「ファイルが見つかりません」→ 実際には存在していて、読み込み権限はあるが書き込み権限がない
後者は一見「ファイルが存在するのに見つからないと表示される」というエラーハンドリングの問題に簡単に行き着くように思えるが、「(ユーザが)別のディレクトリを見ている」という典型的な失敗例が先行してミスリードを起こす。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
的確な状況説明が行われていない。 (スコア:0)
エラーが出た。動かない。……それじゃ分からんというの。
「どの画面でどんな操作をしたら、何が起きた。」とか、
「エラーメッセージの○○が表示された。」とかなら、まだ調べようがある。
何が起きていて、何をしたいのか明確に説明して欲しいものです。
Windowsの場合、必要なデータを可能な限りバックアップして、Windowsをクリーンインストールしなおせなんて回答がよくあって、もめる原因になる。でも、コンポーネントストアや、ユーザープロファイル、システムプロファイルあたりが死んでいると、システムの修復ができないことも多い。
Re:的確な状況説明が行われていない。 (スコア:2, すばらしい洞察)
> 何が起きていて、何をしたいのか明確に説明して欲しいものです。
それができないから、それを因数分解する人がフロントSEといわれる人なわけです。はい。
ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、
ソフト自体には興味ないので、そのソフトの挙動についていろいろと求めるには限界がある。
Re: (スコア:0)
>ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、
もしそうだったとしても
・実務上期待される動作(今まで動いていた動作のあらまし)
・実際に起こった挙動
を報告するのは出来ると思うんだよね
Re: (スコア:0)
出来たら苦労しないのよ。
老若男女問わず、情シス経験者でもない限り問い合わせ1回目ではまずその情報は出てこない。
出てきたら感動して1日は他人のことなのに自慢するレベル。
Re: (スコア:0)
ソフトの挙動について求めてはいないんだ。
あなたの挙動について求めたいんだ。
Re:的確な状況説明が行われていない。 (スコア:2)
Bit別冊の「GNU Emacsマニュアル」の障害報告の節を読んだときに目から鱗がポロポロ落ちた記憶があります。
日本語訳はあちこちにありますが、例えば↓
https://flex.phys.tohoku.ac.jp/texi/emacs-jp/emacs-jp_238.html#SEC263 [tohoku.ac.jp]
Re:的確な状況説明が行われていない。 (スコア:2)
Emacsは最新版の和訳文書があるので、それを紹介してくれ
https://ayatakesi.github.io/emacs/27.1/html/Bugs.html [github.io]
52 バグの報告
Emacsでバグを見つけたと思ったときは、それを報告してください。それをfixすることは約束できませんし、それがバグであると常に認める訳ではありませんが、もちろんそれについて知りたいのです。追加したいと考える機能についても、同じことが言えます。以下のセクションは、有効なバグレポートを作成する助けとなるでしょう。
Known Problems 既知の問題とバグについて読む方法。
Criteria 本当にバグを見つけたのか?
Understanding Bug Reporting バグを報告する効果的な方法。
Checklist 良いバグレポートのために従うべきステップ。
Sending Patches GNU Emacsにパッチを送る方法。
52.3 バグレポートの理解
バグがあると判断したときは、それを報告すること、そして有用な方法で報告することが重要です。もっとも有用なのは、Emacsを起動するシェルコマンドから、問題が発生するまでに、何のコマンドをタイプしたかの正確な記述です。
バグレポートのもっとも重要な原理は、事実を報告することです。仮定や口頭の説明は、詳細な生データの代替にはなりません。事実の報告は簡単ですが、多くの人は事実のかわりに仮定の説明をしようと懸命に努め、それを報告するのです。その説明がEmacsが実装されている方法にたいする仮定にもとづく場合、それらは使い道がありません。その一方で事実の欠落により、わたしたちはバグについての実際の情報を得られないでしょう。実際に問題をデバッグして、推定を超える説明を報告したい場合、それは有用です
— しかし、どうか生の事実も同様に含めてください。
たとえば、C-x C-f /glorp/baz.ugh
RETとタイプして、ファイルをvisitしたとき、そのファイルが偶然大きい(とあなたは知っている)ファイルで、Emacsが‘I
feel pretty
today’と表示したとします。バグレポートにはすべての情報が必要になります。あなたは問題がファイルのサイズにあると仮定して、“大きなファイルをvisitしたら、Emacsが‘I
feel pretty today’と表示します”、などと報告すべきではありません。これはわたしたちが“推測説明(guessing
explanations)”と呼ぶものです。ファイル名に‘z’があるという事実が、問題の原因かもしれません。もしそうなら、あなたの報告を受け取ったとき、わたしたちは大きなファイルで問題の再現を試み、それらのファイル名にはおそらく‘z’が含まれておらず、問題を確認できないでしょう。名前に‘z’が含まれるファイルをvisitしてみるべきだと、推測できる方法はありません。
C-x
C-fのではなく、“ファイルをvisit”とさえ言うべきではありません。同様にテキストを入力する方法では、“その行に3文字あるとき”ではなく、“RET
A B C RET C-pとタイプした後”と書いてください。
可能なら、すぐにバグを再現するためにemacs -Q(Emacsは初期のカスタマイズなしで開始されます。Initial Optionsを参照してください)でEmacsを呼び出して、バグを発生させるステップを繰り返してみてください。この方法でバグを再現できたら、あなたの個人的なカスタマイズをバグから除外できます。バグレポートは、Emacsをemacs
-Qで開始したことから始まり、バグを再現させる正確な一連のステップを続けるべきです。可能ならバグを再現するのに必要な、正確なファイル内容を報告してください。
emacs
-Qでは再現できないバグもいくつかあります。結局は再現するのが難しいバグもあります。そのような場合、何を行なったかを報告すべきです —
が、前述したように、どうか最初にバグを発生させた生の事実を固持してください。
報告したい複数の問題がある場合は、どうかそれらを個別のバグとしてそれぞれ報告してください。
52.4 バグレポートのためのチェックリストには、レポートに含めるべき事項と、不要な事項がリスト形式でまとめられている。
https://ayatakesi.github.io/emacs/27.1/html/Checklist.html [github.io]
Re:的確な状況説明が行われていない。 (スコア:1)
Emacsは最新版の和訳文書があるので、それを紹介してくれ
https://ayatakesi.github.io/emacs/27.1/html/Bugs.html [github.io]
情報ありがとうございます。現在まで和訳され続けているとは知りませんでした。ご教示と、そして翻訳をされている方々に感謝します。
Re: (スコア:0)
バグ発生前の操作を完全に覚えてるわけないんだから、推測説明以外では報告のしようがない。
正確な操作ログが欲しいんだったらEmacsで勝手に保存しとけよ。
バグを修正できない言い訳を並べてるようにしか見えんわ。
Re: (スコア:0)
そしてEmacsにキーロガーが仕込まれていたと祭りになるのですね。
Re: (スコア:0)
このコメントはただ茶々を入れてるだけなんだが、
IMEをオフにすることは含めなくてよいのだろーか
Re:的確な状況説明が行われていない。 (スコア:1)
エラーが出た。動かない。……それじゃ分からんというの。
近年はそうとも言えんのですよ
マジもんで
「何もしていないのに壊れた」
が発生しますので
ええ、原因は強制自動アップーデートでございます
# アップグレードしますか はい/後で なんてちゃちなもんじゃねぇ
Re: (スコア:0)
# アップグレードしますか はい/後で なんてちゃちなもんじゃねぇ
コメントアウトにコメントするのはなんだけど、出勤したら画面が黒いままでうんともすんとも言わないって連絡が来るんだよね。
「ずっとくるくるがまわってる」ってのもある。
Re:的確な状況説明が行われていない。 (スコア:1)
元サポートとしては、「そういうやり取り面倒だから情報収集ツール送ってくれ たらすぐ取るよ」と思ってしまう。
基本的にエンドユーザは当然ながら、SEの言うことですら頭から信じてしまうと 調査は迷走する。
表面に出てくる現象は氷山の一角でしかなく、信じられるのはlogのみ!
なので情報収集ツールの実行をお願いされたら、めんどくさがらずに素直に従っ てくだしあ。
Re: (スコア:0)
Microsoft「だからテレメトリーデータを取らせてね。フィードバックHUBで再現データを送れるようにするしね。」
Re: (スコア:0)
そして再現しようとすると出ないのはお約束
#Windowsに限らんけどあるあるネタ
Re: (スコア:0)
よくあるのが「エラーが出た。自分は何もしていない」ってやつだな。
何もしてないわけ無いだろ、と。
Re: (スコア:0)
何もしてないこともありますよ。
例えば https://hardware.srad.jp/story/17/02/23/0636215/ [hardware.srad.jp] とか。
対策済みだと言うならごめんなさい。
Re: (スコア:0)
「エラーが発生しました」としかメッセージを出さないソフトウェアもあるからなぁ。
そうじゃなくてエラーメッセージを書けよって言うからスクリーンショット送ってやったら黙ったわ。
Re: (スコア:0)
経験的にはネットワークやファイルI/Oまわりは、エラーメッセージが雑になりがちな印象がある。
「ネットワークの接続に失敗しました」→ 実際には接続は成功していて、その後の処理でエラー
「ファイルが見つかりません」→ 実際には存在していて、読み込み権限はあるが書き込み権限がない
後者は一見「ファイルが存在するのに見つからないと表示される」というエラーハンドリングの問題に簡単に行き着くように思えるが、
「(ユーザが)別のディレクトリを見ている」という典型的な失敗例が先行してミスリードを起こす。