考察

「問題なく出来るよね」と思われがちだが

　　そうではなく

　　　　「本来の目的を達成できるよね」と

　　　レビューするものである。

　　　　イレギュラーが発生した場合にも

　　　　　　どう対応するかということをチェックし

　　　　作業の見直しを行う。

　　そうそう、誰が何を認識できるということまでチェック！

作業を時系列に並べ

　　色分けをしてみる。


　　まずレッドゾーンを塗ってみれば

　　　　色々な創造力が働くかもしれない。

バグでシステムダウン

　　障害解析中に見えることは


　　　　　開発者のスタンス

まあ、予定通りとも言いましょうが

　　　じゃじゃ馬的なスマートフォン　android 4.0.1に

　　　　　機種変更した訳ですが

　今更ながら分かることと言えば

　　　android 2.3系とandroid 4.0系では

　　　　　ハードウェア的な違いが戸惑いを与えると言うことでしょうか？


　　　　nexsus one だと戸惑わないのに　？

大きいストライドよりも

　　身丈のあったストライドを見つけると

　　　　効果的に動けるものだ


　　このストライドを調整するのがステップバイステップか？

sh のスクリプトで2重起動判定を行うのだが

if [ $(pidof -x $0 | wc -w) > 1 ]; then
   echo '二重起動'
fi

で返す値は実際には単独で2正常動作せず？ ubuntuだから？

if [ $(pgrep -fo $0) -ne $$ ]; then
   echo '二重起動'
fi

の方が汎用的かも？

都市伝説化した技術は検証されることなく
　　　そのまま信じられてしまうのでしょうか？

　　　わずか1つのバグでシステムを停止してしまうのに

たくさんの検証コードを書けばいいのだろうが

　　　それでは効率が悪い

　　　思考実験を脳内で

　脳内だけでは現実性が乏しいので

　　　　検証コードを


　はて？どうすれば無限ループに陥らないのか


　　　マップを書こう？

本当に起こり得るのかというコードを書くまでは。

　あら、本当に起きちゃった（笑）


　他にも脆弱性がちらほらと見つかってましたが？

バウンダリと例外処理のスコープかもしれない

道に迷いそうになったので交番で尋ねてみました。

　某有名ホテルまでの地図を見せて

　　　　どう行けばいいんですか？

　　　　　なぜか困惑？

「いついつまでにください」とは言わない

　　　「何時頃頂けますか」と言う

　　　　　クライアントの罪悪感を煽るように

朝から発生していました。

　問題は速やかに有効な施策が打てるかどうか。

正常系と想定するエラー系だけを実装しているが

　有り得ないだろうと思われるAPIには何のチェックも省いてしまうものだ。

　　　ついでにエラーメッセージさえも。

　　障害時にはそのエラーが発生しているかもしれない。

はるか昔

　　頼まれて製作したイフェクターを思い出した

　　　　きっかけはイフェクターの製作の本

　　　ほう、配管用のボックスか？

　　　　　多少乱暴にスイッチを踏んでも壊れまい

仕様変更に基づいて試験すると

　何が仕様変更したかが分からないので

　　仕様変更も故障のひとつだし

数式が知りたいのだが読本になっている

同じ方法は同じ間違いを犯すものだ

障害時のソースコードとログを丹念に調べるのは？

　設定書は間違っているかもしれないし
　　　設定していないかもしれない

　　設定していないつもりでも
　　　　設定しているかもしれない


ソースコードのコンパイルも同様。

再現待ちの間にもこのように解析は続く。

昨晩未明から朝方まで

　システムトラブルメールが飛んでおりました。


　出社早々分析開始で誰も寄ってきません（汗）