「実録！「カーセンサーnet」リニューアル奮闘記」

http://itpro.nikkeibp.co.jp/article/COLUMN/20120319/387034/
事実は小説より奇なり．
とても尾も白い記事だった．すばらしいネタをありがとう．

100回以上の性能試験と、連日深夜までの解析が続いた今回の性能検証プロジェクトは、こうして幕を閉じた。私は経験も乏しい中、性能検証を担当することとなったが、本当に濃い体験ができた。経験豊富な性能検証チームのメンバーとともに戦う中で、問題追求を最後まで諦めない姿勢も彼らから学んだ。
　すぐに原因が分からなくても「目の前で起きている事象の原因は絶対に解明できるはず」という信念を持つこと。必要があればカーネルレイヤーでもどこまでも追っていくこと。そういう姿勢が大事なのだと痛感した。

今回の教訓
◯ツールを最大限有効活用しよう
◯カーネルレイヤーを怖がるな。
◯原因は必ずあって手は届く。最後まで諦めない。

プロジェクト×的な勘当の物語．

http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/article/COLUMN/20120319/387034/

id:motchang ｽﾞｺｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ!! / "原因は必ずあって手は届く。最後まで諦めない。" ってのは良かった。

id:sionsou ヽ(・ω・)/ｽﾞｺｰ

id:hamaco その発想はなかった

id:moriyoshi 車のスピードが全然上がらないのでエンジンの特性を探ったりしたが、実はサイドブレーキを引いていたということですかね。

id:rryu 犯人はヤス並みの出オチ感。ロックとネットワーク通信のどちらのオーバヘッドが大きいのかも調べてほしかった。

id:cu39 原因＝答えに至る道は複数あって、わかった後から「もっと短いルートがあったはずだ」と思うことがあっても、過程においてそれを知ることは容易でない、という事例として覚えておく。

id:lp008962 「障害を切り分け切り分け切り分けた末に、ググったらすぐ出る既知のバグだった」という過去を思い出しました。

id:futsu-9 誤った設計をして正しくトラブルシュートはしたけど、誤った教訓を得たという感じがする

id:deep_one ちょっとしたことが原因だったが、その機構がカーネルの内部に存在したので全然分からなかったというお話…しかも、バージョンアップしたらなくなっていそう（笑）

読んでいて，自分の方がなにか間違っているかと何度も自問自答することとなった．

パフォーマンス改善をやってるのが経験の少ない若手みたいだから楽しんでられるけど，あと何年かして同じ目にあったら，こんなコードを作った奴の首を絞めたくなるだろうな．