アカウント名:
パスワード:
結局、情報を隠せば隠すだけユーザーも作り手も損をするんだよな。
ログ出すかどうかは、アプリしだいですからねぇ。
SAMBAとかみたいにログレベル指定できるアプリあるじゃないですか。
再現性の高いバグばかりならいいんですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
うぅむ (スコア:1)
バグ報告できるアプリの開発ってことになりますんかねぇ。
# 効率的なバグ?って思ったのは、俺だけ?
Re:うぅむ (スコア:2)
私も初めに戸惑いました。
元ネタの「てにおは」(っての?) はおかしいですよね。
この内容なら「効率的に 不具合を報告する方法」とかなるハズ。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
オフトピ(was Re:うぅむ) (スコア:1)
こういうのは英語の表現では良くあるので、直訳するとそういう日本語になってしまいがちです。
今回も直訳したからかな?と思いましたが、原題が "How to Report Bugs Effectively" なので、そういう事でもなさそうです。
ということでこれらの方が原題に近いし日本語的で良いと思います。
「効率的に不具合を報告する方法」by kamuy
「効果的にバグを報告するには」by 件の和訳者
#ちなみに助詞を意味するのは「てにおは」ではなく「てにをは」です。
Re:オフトピ(was Re:うぅむ) (スコア:2, 参考になる)
「バグ報告をする効率的な方法」
「不具合を効率的に報告する方法」
「バグを効果的に報告するには」
Re:うぅむ (スコア:1, 参考になる)
どっちかというと、暗に、「アプリはログを出すように作っておいたほうが良いぞ」と
言いたいのではないか?という気もします。
ヘタにユーザーフレンドリーとかいうお題目のもと、こういう内部(?)情報を
「隠蔽」しまくっているアプリだと、いざトラブルになると、原因調査のきっかけに
なりそうな情報を得る手段が無くて、ユーザーも作り手も往生してしまいそう。
てゆーか(笑)、往生します。
ログとりのための仕組みで、便利な奴が有ると、色々嬉しいですよね。
DebugWriteを「コンパイルオプションレベルでオフにしてmakeしなおして出荷する」
のではなくて、
「設定ファイルとかデーモンとかをちょっといじるだけで動的にいつでもDebugWriteを取り出せる体制になる」
ようになってないと、色々しんどいっす。はい。
結局、情報を隠せば隠すだけユーザーも作り手も損をするんだよな。
そういう所はOpenSourceそのものとも通じるものを感じます。
Re:うぅむ (スコア:1)
めったに再現しないバグが出るのを恐れて、いつでもログを吐くようにしてあると、ログを出力する方法によっては使いにくかったり目障りだったりします。 Unix の syslog というのは普通に動いている限り不要な情報を出力してもほとんど邪魔にならない点で優れていると思いますが、それでも何でもかんでも吐きまくることはできないし、別にファイルを自分で作って吐くようにすると、普段必要のないログを書いたファイルができるのは使いやすくない、ということで、やっぱり になってしまうと思います。
まあ、どの程度普段からログを出力するか、というのは、明文化されていないけれど感覚的な基準があるように思うので、それに従うべきということでしょう。
// Windows のイベントログって、どう使うことが想定されているのだろう?
鵜呑みにしてみる?
Re:うぅむ (スコア:1)
「方法によっては」なのですか?
じゃあ、その方法ってやつを洗練することを、考えましょうよ。
よだん:
これだけ保存媒体が安くなったんだから、それこそ方法しだいでは色々と、
人に負担を感じさせないログ取りをやりやすいご時世なんじゃないかなあ?
おふとぴ (スコア:1)
ありゃあ、まったくもって意味不明ですな。
作った会社では、仕様なんだろうけどね。
Re:うぅむ (スコア:1)
SAMBAとかみたいにログレベル指定できるアプリあるじゃないですか。
それで良いのじゃない?
Re:うぅむ (スコア:1)
ログレベルが可変なのは重要です。特に、 #99940 [srad.jp] で G7 さんが書かれているように、 configure, make 時のパラメタではなく実行時のパラメタとして指定できると、報告者にとって便利です(報告者にとって便利であれば、もちろん開発者にとっても有利です)。
なぜログレベルが可変だといいかというと、
再現性の高いバグばかりならいいんですけどね。
鵜呑みにしてみる?
Re:うぅむ (スコア:1)
……などと書いていたら、危うく「バグがないのが一番いい」ということを忘れてしまうところでした。
鵜呑みにしてみる?
Re:うぅむ (スコア:1)
というわけなので、当然、
みたいな用途を想定したものだと思ったのですが。
まあ、個別のアプリの話してもしようがないですけど、そういうソフトも結構あるよ、ということで。
Re:うぅむ (スコア:1)
でも、例えば今何か新しくソフトウェアを書いていて、ログレベルを可変にしようと決めたとします。このとき、開発者はどの情報が重要かという判断をしなければならないわけですが、この判断はノウハウがないと(あるいは実際にソフトウェアをリリースしてみないと)難しいだろうな、と思ったわけです。
鵜呑みにしてみる?
Sambaのlog levelは動的に変更可能 (スコア:1)
smbd(8)のシグナルを参照のこと。 [samba.org]
Re:Sambaのlog levelは動的に変更可能 (スコア:1)
ショックなのは、 Samba を使っているのにこの機能を知らなかったこと……あわわ。何か起きてから慌てないよう、普段からちゃんと勉強しないといけませんね。
鵜呑みにしてみる?