人生 unstable〜 challenging and exploring days 〜

コンポーネント設計書の修正内容のレビュー。 ま、こんなもんでしょ。

サブシステムの刷新に絡んで 新しい要件一覧から既存機能にない追加部分を確認。 難しく思える箇所も外部とのデータ連携が主なら それほどでもなかろう。 これから工数を見積もるのは色々仮定を置かないと無理ですな。
あれ、もしかすると、 これまで離れて分割してまた元に融合してきたDBを 再度分けるんですか。 へえ。

む、先週末の話が聞けた。
ほお、3次会のカラオケまで参加、 そこまでは自分の足で歩いてましたか。 カラオケ会場では入室直後に寝入って、 そのまま退室直前に吐くまで倒れてた、と。 そんなこんなでタクシーで会社まで戻してもらったわけですか。 1次会の途中までの記憶しかない。 2次会ではかなり言動・挙動が おかしかったらしいのでその時点で潰れてたんだな。

また perl の split の末尾空要素を除去する振る舞いにハメられた。
うーん、それ以外は別にそうすればそうなるでしょう。 得られる結果自体が不自然でも問題とも思えないけど、 好ましくないなら直します。 ただ不具合ではなく仕様修正(詳細化)と扱って欲しいですけど、 現時点ではどちらでも変わらないのかな。

ローカルPC では動作確認は難しいか。 連携システムとの接続性が確保できない。

機能設計書のレビューと同時に修正方針の確認。 使用するコンポーネントの設計書の修正は私がやりますか。。。 うーん、なるほど。 粗いプログラムコードに相当するのか。

定時後、次週から参加予定のプロジェクトのキックオフ。 既に進行しているけど、 目的やスケジュール等の認識合わせもあってのことらしい。 このボリュームをこの丁寧さで進めれば これぐらいの時間がかかわるわな。 当初予定の時間で終わるはずがない。

わけあって来週水曜日に休みを確保。 前触れもなく連絡が来たから驚いた。 \

あ、金曜日は10数年前と違って少なくとも 暴れはしませんでしたか。 それはそれとして、どうも御迷惑をおかけしました。

改修対象のコードを眺めて理解を進める。。。
背景や仕様を踏まえれば、 事前に聞かされていた改修内容も妥当と思える。 どうにか実際の修正内容がイメージできた。
押し付けられて面倒に感じている層分けも せめてもの関心領域分割として役立ってると思えなくもない。 それ以外は基本的に各 public method 本体が 丸々ベタ書されていて見通し悪すぎだわ。。。 この点、 却ってコードを追い易いと捉える向きもあって 良し悪しを断じるのは難しい。

また resume時に pvrusb2 の初期化に失敗していて 気付いたら process 数が 6000近くになっていた。
カーネル再構築完了後にも負荷の高い状況が続いていた。 しかもシステムの CPU 利用率が高く、 top で確認するとその正体は kswapd。 不審に思ったが 2.6.33 で Tiny-RCU に変更した影響かと 浅はかな素人考えをしていた。
実際 firefox を終了させた直後は負荷が軽減したが、 間も無く高負荷状態が復活。 再度 top で確認したところ一瞬 firmware という単語が目に留まり、 ようやく原因に思い至った。
pvrusb2 からUSBと電源のケーブルを引っ込ぬいたところ システムがほぼフリーズ状態に陥った。 その後 30分ほど放っておいたら、どうにか回復してくれた。 ぷう。