エラーメッセージ読め読め大合唱

永遠に

今日は「エラーメッセージ読め読め大合唱」だった...
新卒にも若い先輩にも大合唱ラララー♪
まあ、ずっと言い続けるんでしょう、きっと。

実は読むんじゃなくて解読する

エラーメッセージを読んでは推測して確認してみる。
(Read error message, presume and confirm...)

違ったらまた推測しては確認してみる、の繰り返し。
(If you cannot get answer presume and confirm...loop)

わからない言葉だらけでも読んでみてヤマカンする。
(If it's many unknown words, read and guess)

答えをズバリ言い当ててくれる人なんていないから。
(Nobody teaches you just answer)

つまりエラーメッセージも答えを言うとは限らない。
(It means that error messages may not tell answer)

だから読んでわからなくて当然。
そう考えると、
「エラーメッセージを読む」という表現も間違いかな。

エラーメッセージは解読するものなんです!

Analyze error messages!

※ログも同じです

プロですから

あなたは探偵、とある事件の捜索依頼が来た。
あなたは誰々が...されたという結果しか知らない。
目撃者が何人かいる。目撃者が何か言っている。
だが、いまいち何言ってるんだかよくわからない。
気が動転してるのかあまり論理的でなかったり、
それぞれの言うことがとても断片的である。
でも犯人が誰かを探さなければならない。

目撃者の証言を無視しますか?
(Do you ignore evidence of eyewitness?)


目撃者どころじゃないかもしれない。

ダイイング・メッセージを無視しますか?
(Do you ignore dying message?)

...

いやいや、ちゃんと分析して手がかりにしますよね。
プロですから。
適当に「あいつがやった」なんて言わないですよね。
言ったらなんとも怠慢なことでしょう。

そして、その分析するのはあなたです。
誰も「この人が犯人ですよー」って教えてくれない。
というかそんなん教えてもらっても、
その論理的な裏付けが無ければ紛らわしいだけだ。
その論理的な裏付けをどうやって導くか?

僕が教えるのはそこです。
犯人が誰かなんて教えることに意味はない。
犯人はコロコロ変わるから覚えても役に立たない。

プロセスに着目します

ごめんなさいね、みなさん。
僕がフォローイングして問題が解決して、
「よっしゃ、じゃあ次の問題」と意気込むところ...
いや待て!

「そこの部分をどういう風に捉えてたの?」

「こう考えてたらわかったんじゃない?」

ってプロセスを深く掘り下げさせて頂きますが、
とってもイヤだろうね。。。(ー0ー

もちろん、急ぎ業務で先に進むべきときなら、
そこはさて置いて次へ次へって感じだけど、
DBFluteハンズオンや研修のときはね、
「プロセス」が目的だから。
頭の中の行動を振り返させて頂きます。

まあ、とってもイヤだろうね。。。(ー0ー
自分をけなせるか?弱い自分と会って話せるか?
それを一人ずっとやり続けてきたんです、僕はね。

// 答えよりも答えを導くプロセスを
http://d.hatena.ne.jp/jflute/20110530/1306729010

だからラララー♪