人生 unstable〜 challenging and exploring days 〜

あ、やはりこちらにもあちらのテストのヘルプ要請が来ましたか。 合流できるのは再来週ぐらいですかね。

「見たら分かる」から「昨日の作業は残さず、1からやり直す」か。 早いけど粗雑な真骨頂を垣間見た気がする。 見たら分かるレベルのものならわざわざ今まとめなくていいんだよ。 頭使ってくれ…

え、今この時期にコード長が変わる、仕様変更ですか。 このプロジェクトのぐだぐだ感も極まれり。

imagemagick 導入。。。 imagemagick を野良ビルドするとなると 開発パッケージが導入されていない libpng と libjpeg も 野良ビルドが必要になるよな。。。 んん? libgif は要らんのかね。 gif と bmp のサポートは外部ライブラリではなく組込なのかな。 面倒。
configure オプションの調整までもが こちらの責任なら make install もさせてくださいよ。 義務・責任と権限がちぐはぐでやりにくすぎる。
止め、方針転換。 うむ、distroのrpm版で問題なかろう。 運用チームに丸投げ。

んん、結合テストのケース作成を依頼されていたが、 対象機能に関する概要記述から意図が読み取れない。 明日か来週にでも説明してもらおう。 しかし、他の人が作成したケースから推測できる分からすると それほど大変ではなさそう、な気がする。

ふむ、来週中に現担当部分の実装・テストに一旦けりをつけられるか。 しかし休みが取れないな。

追加で実装した部分を追加でテストしてもらう。 うん、仕様の理解とケース出し、実施でほぼ1日かかるか。

開発環境整備。 svn から export し zip で固め、開発環境へコピー、展開。 その他の手作業はディレクトリや symlink の作成、構成ファイルの調整等。 同時に作業の内容を手順書としてまとめておく。
あれ、apache2 と php が入っているから安心しちゃっていたけど、 postgresqlクライアントと imagemagick が入ってない。 これじゃまともに動かんですよ。 運用チームに(再)導入依頼が必要になりますか。 またしばらく待つことになりそうですねえ。。。

あちらのメール送信モジュールのインタフェースが 期待したほどすんなり使えそうにない気配。 思っていたより手間がかかりそうな。

歩数計は、 液晶文字が薄くなってきていたので電気が切れ気味だったのは確かだけど、 不意にリセットがかかるのは電気の接触不良の可能性が高そう。 電池の入れ替え作業中にそんな印象を受けた。 実際、入れ替えたばかりなのにさっそくリセットかかってるしなー

親から電話。 三回忌の日程を調整。 有休2日取らないといけないけど、その日でまあ大丈夫でしょ。

あれ、エラーメールの取り扱い云々はこちらでしたか。 件のメールが今回プログラミングもやっているプロパーから出ていたので てっきり担当もそちらだと思ってしまいましたわ。 そうそうエラーメールのヘッダ From: なんて良くて mailer daemon ですよ。 言われないと気付かないもんですかね。そうかもしれませんね。 でも、だから、サンプルとして実物を確認しておくべきだったんだろうな。

テスト(ケース)漏れがあったので仕様を説明し追加テストを実施してもらう。 うーん、説明しながら思ったけど、けっこう面倒臭いな。

後回しにしていた仕様変更対応。 リファクタリングとして まず先行実装した箇所を共通クラスに移し、 呼出インタフェースを調整・汎用化。 そして今回分のコードを追加。 うん、綺麗に収まった。
うーん、行内に見出しが2つある: <tr><th>見出しA</th><td>データA</td><th>見出しB</th><td>データB</td></tr> 見出しA と見出しB は1行に収める必然性があるほど関連は強くなく、 レンダリング結果の見た目の分かりやすさはともかく、 html ソースレベルでは編集しにくい。 tbody の style を float にして <tbody><tr><th>見出しA</th><td>データA</td></tr></tbody> <tbody><tr><th>見出しB</th><td>データB</td></tr></tbody> にすれば、なんかそれっぽく見える。。。 あかん、 <thead><tr><th>見出し</th><th>データ</th></tr></thead> が破綻する。 うーん、table 自体を分割するのが素直なのか。 しかも大工事になる。今回は手間をかける時間がないので、保留。

ナイス・クロスレビュー。
管理画面側で予定している追加実装の参考にするため、 某バッチの設計書に目を通す。。。 あれ、この条件だと処理対象レコードが 2件に分かれて取得されるけど、 問題ない? あ、問題大ありですか。
今回の処理対象レコードは管理画面で操作する。 このレコードが2件に分かれること自体わりと最近、 ここ1週間ぐらいの中で判明・決まった仕様だから バッチ側の影響が見切れてなかった。 突貫工事の勢いで仕様が決まり実装が追加されていくから サブシステム間の整合性に問題があるかもしれない。 だからこそサブシステム間の結合テストが予定されているわけだけど、 偶々気付けた今回の件は結合テスト時に検出できたか怪しい。 うーん、結合テストのケース出しの観点を再確認しておこう。。。

続テスト。 今日もまたテストケース追加。 null値のケースが増えたので ざっくり (1)新規null値 (2)更新null値→non-null値 (3)更新non-null値→null値 のパターンを追加。 2項目が変わったので6ケース増えた。 実のところファイルアップロード絡みなので (1)更新non-exist→exist(non-null) (2)更新exist→overwrite(non-null) (3)更新exist→no-op(null) も追加。 当然 x2。 これであり得る操作パターンを網羅できているわけではないが、まあ十分。

今週末に予定されている説明会の前に 軽く新制度・体制について説明を受けた。 ふーん、 これまでのデタラメから (多少なりとも?)マトモに変わろうとしてる、のかな。

定時上がり。 なんだかんだでどうにか今月中のタスクはほぼ消化できた。 残はなくはないが他チームの進捗に影響を受けてる部分なので。

あれ、また歩数計の時計が狂ってる。 これは時計が狂うというより 電池が切れかかって 瞬停が起こってるのかな。 CR2032 は備蓄してないな。