バグの影響を伝播させないアプローチ - Michael T. Nygard / Release It!

なんとか It! シリーズのひとつ「Release It! 」を読みました。


航空券予約システムをダウンさせたバグの経験から始まります。

極論を言うと、この種のバグがひとつ残らず消滅するなんて夢物語にすぎない。 バグは発生する。消えてくれないなら共存するしかない。 [...] この例で最悪だったのは、ひとつのシステムのバグが全システムに伝播して影響したことだ。答えるべき問いは、「ひとつのシステムのバグが他に影響するのをどうやって防ぐか?」である。 (p.21)

バグの影響を伝播させないシステムの作り方、というのが、この本の「本番用システム」のあるべき姿です。その中からいくつかピックアップ。

本番と同じサイズのデータセットでないと、クエリで数百万行が返っ てきて、それをオブジェクトに変換するときに何か起きるか確かめることかできない。本番と同じサイズのテストデータを使えば、パフォーマンステストでより良い情報が得られるという副次的な効果もある。 (p.93)

ダミーでいいから量をある程度用意するのはよいことだと思う。いまやっているプロジェクトでは、想定ユーザ数と平均的なユーザの典型的な行動パターン（つまり各URLのアクセス頻度）のシナリオを用意してもらえた。まだ調整中なのだけれど、どこがボトルネックになっているのか分かるし、優先順位も明らかになっている。

待たせた結果がエラーメッセージであってはならないし、相手のタイムアウトまで待たせてもいけない。それでは、こちらの問題を呼び出し側に転嫁するだけだ。 (p.116)

フェイルファストっていうのは、なんか努力せずに諦めたみたいな感じがするんだけど、応答が遅い状態が長く続くくらいなら、さっさとフェイルして、アラートメールを出したほうがいい。どうせアラートメール出すハメになるのだから。

開発プロジェクトか大忙しのときに、こうした設計についてのトピックを意識するのは難しいかもしれない。[...] そんなあなたにいいニュースかある。これらの問題を開発中に取り上げるのは断念してもいい。ただし、これは悪いニュースでもある。開発中に収り上げないなら、 本番で取り組むことになるだろう。 (p.235)

開発開始段階ですべての機能/非機能要件が決定されていない（つまりほとんどの）場合、最適な設計も最初に決定できないということになる。少し設計して、作って、また設計して、の繰り返しになるので、設計コストは増加する。そのかわり不適切な設計のままつっぱしって、システムがダウンするリスクを避けられる。

今やっている案件でできていることは続けたいし、できていないことは今後やっていきたいものです。

データではなくメソッドを学ぶ - 森博嗣「科学的とはどういう意味か」

「信仰は科学です( ｰ`дｰ´)ｷﾘｯ」みたいなことを普段言っている割には、かなりな勢いで直感でものを考えているふるかわです、こんばんは。

駅の本屋さんでふと目に止まって、森博嗣の「科学的とはどういう意味か」を買いました。

人間にとって「気持ち」の影響力は大きい。けれど、いくら感動しても、いくら泣いても、飢えている人を救うことはできない。いくら一時の笑顔があっても、それは「解決」ではない。 (p.12)

当たり前のことですが、つい忘れてしまいますね。

こんなに大げさな話ではなくても、問題の解決にまったく寄与しないことが、自明であるにも関わらずやってしまうことってあります。目下の課題とまったく関係のない質問、誰にも聞かれていないし、役にもたたない発言など。そういうことに自覚的でありたいと思います。

学科で教わることには、以上のように2種類ある。きっちりと分かれてるものではないけれど、大別すると、「データ（情報）」と「メソッド（方法）」だ。[...] これに対して、後者は、それらの材料を用いて加工する「方法」を憶えることになる。算数や数学というのは、一言でいえば「方法」なのである。 (p.35)

 「大学の研究室でやった研究で仕事してる奴なんか、ほとんどおらんで。ここは方法論を教えるところやから」と言ったのは、私が所属した研究室の先生の言葉でした。私は物覚えが悪いので、テストは常にひどかったですし、いまでもひどいです。


仕方なく方法論を身につけようと思いました。なので、何か新しいことを知ったら、とくにそれが方法論であったり、解釈の仕方であったりすると、「この方法を違う問題に当てはめられないか」と考えます。いつも、ではないですが、そういうふうに考える傾向があります。


それがどのくらい有効なのかよく分かりませんが、少なくとも私には役に立つ考え方であり、アプローチです。


と、まあ、当たり前なことを、ドヤ顔で書いてみました。「こんなこと役に立つのかよ」って思い悩む、高校時代のときから余裕でプログラミングとかできている学生の役に立てば、と思いました。

大阪国際トライアスロン 2011

大阪市此花区の埋立地であるところの舞洲（まいしま）で開催された、大阪国際トライアスロン舞洲大会に出ました。別にワールドカップとかではないです。

てめー、この仕事の立て込んでるときに、と、言われそうではあるのですが、トライアスロンしなければ、きっと飲んだくれてるだけでしたので、まだ、マシであったと思っていただければ。スイム750m、バイク23km、ラン5km の短い距離でもありますし。

スイムは大阪湾を泳ぎます。東京湾を泳いだこともあるし、汚いといっても知れているだろう、そう思っていた時期が私にもありました。ビニール袋が打ち上げられていると思ったら、鯛の屍骸でした。往復750mのコースを、岸と並行に泳ぐコースです。

バイクは4周回で、23km。大井埠頭みたいなもんだろうから、大したことないだろう、そう思っていた頃が（以下略）。夢舞大橋という橋を往復するのですが、これがまあ坂です。しかも可動橋なので道路のつなぎ目が大きい段差になっていて、バランスをくずしやすいのです。バイクが下手な私は、下りのスビードをあげられませんでした。橋以外はコーナーが続き、こちらもスピード出しにくいです。アウターギアつかってない。

埋立地のランなんてフラットだから楽勝だろう、そう思っていた頃(ry 。岸に沿った歩道を走るのですが、津波対策なのか、そういう景観狙いなのか、埋めたての土砂が余っていたのか、結構アップダウンがあります。ただ、変則片道2.5km のコースには、給水ポイントがわりとあります。500m ごとは言い過ぎかもですが、1kmよりは短い間隔で給水があります。ただし、水だけ。全体的を通して、日を遮る箇所がほとんどなく、かなり暑いです。

JTU 公認のエリート部門もあるので、スタッフはたくさんいます。大阪の都市部でのレースの手軽さを求めるならよいかも。ちなみに電車は通っていません。オリンピック誘致できてたら、通ってたかもですね。

そんなレースでした。