楽しい作業ログ
13:50
まずは保存からだなぁ。
SCP開いたりなんだりで準備に10分くらい時間かかる。
13:55
相変わらず仕様書がよくわからない。
なんでこんなにわかんないのかようやくわかった。
設計している人にとって当然の処理が省かれていて、気になるところだけ"設計"してあるんだよこれ。
つまり、自分が作る事を前提とした設計書。
俺が読む時は、設計者にとって当然の事とは何なのかを想像する事から始まるからだ。
まあ、代理店やデザイナーが作るイメージ先行で実際に完成形が自分でもよくわかってない自称要件定義書よりはマシなんだけど、あっちは予算も大きいから俺が設計することがそもそも前提だしねぇ。
こっちはほぼ完ぺきに完成系をイメージ済みなんだけど・・・。
13:57
ベトナム人来るので音楽モード終了
更新よくわかんねーから新規からやろう。
14:15
とかなんとか言ってたらホーチミンからCOMの解放方法がわかったよという連絡を受けてそっち処理先行。理由はいまだによくわからんのだけど、関数内でGC.Collectしても駄目だったから、別関数（例えばインポート用ダイアログのOnClosedとか）でGC.Collectすると無事終わる。
なんかnullにし損ねててローカル変数の解放漏れしてんのかなぁと思うんだけど、わっかんねーなぁ。シート名とかも全部nullにせなあかんのだっけか。
しかしどうでもいいけどEXCELインポート処理一つとっても読み込みスレッドと画面反映スレッド別々に分けてキューでメッセージやり取りしてんだけど、ベトナム人低級PGに任せるの無理じゃねこれ？
中断したのでついでにベトナム人側作業を先に手伝う事に。これはJAVAのやつだ。大して難しくないんだけどSMS連携があるからね。
14:40
ようやくJAVA側が終わった。どうもSMS側で特定の電話番号を設定漏れしてるくさい。500VNDのやつはいくんだけどね。
腰折られたし、一服してくるか。Silverlight一歩も進んでねー。Excel進んだだけだぜおい。
14:54
再開。えーと、新規での保存処理だったな。
15:02
うーん、どうすんだこれ。モデル側かなぁ・・。
でも何十個も一括で保存するのにモデル側に実装すると遅くなんねーかこれ？
まあ、いいか。速度はともかくモデルのbeforeSaveが妥当なはず。
15:25
ようやくModelにコード書き終わった。次はControllerだけど、インターフェースどうするかな。削除の場合・・、うーんわからん。とりあえず追加でいこうか。
15:30
なんかViewのコードが皆同じだな。Viewファイルが存在しなければこのView使えとかやりたい。
15:43
なんか謎のテストコードを発見。なんだこれ？もしかしてこのコードを通せということか？
せっかくだから使ってみよう・・ってNullReferenceだよ！
15:48
ちょっと直したら結構動くな。
俺が書いたんじゃないよねこれ？覚えがないし・・。
16:00
ほぅ・・。beforeSave内でidを設定しても上書きモードにならんとな。
あかんわこら。$exists = $this->exists(); がsave関数の一番最初に書かれているから、たとえビヘイビア使ったとしてもまったく意味がない。
うーん、しょうがないからIDセットだけ別関数にせざるを得ないな。
でIDセットだけ切り分けようと思っても基本的に重い処理だから駄目で、うえーん、全部別関数にせざるを得ないや。
16:15
てことで別関数にしてトランザクションも自前になるからatomicもfalseにして・・と。
これで出来たはずだが・・
16:30
うお・・この場合はどうすんだ。
セーブ前に入力値内のだぶりを全部チェックしてマージするっきゃないんでないの？
なんだそれ。ありえないだろ。複数入力弾いた方がいいんでないの？違うのか？自動マージを使う事期待して複数作る事なんてありえんよ。
16:37
とはいえ完全同一ならはじけるがあれが違うとはじけないよな。
まあ、これはいいのか。
16:51
ベトナム人帰った。同時にようやくサーバ側の保存テスト通った。
地味にこれではまった。
やりたいこと）
$a = $b - $c;
やらかしたこと）
$a = $b = $c;
この人為ミスだけはなかなかな。
さて、削除どうすんだ。
16:56
入力値増やしてやり始めたら気づく。削除の時も元在庫数の再計算必要じゃねぇか・・。
今度こそモデルだ。えーと、deleteAllはbeforeDelete呼ばんからつかえんのか。じゃあこれは無しにして、、えーと、foreach -> delete かよ。遅そうだなこの処理・・。
17:04
ふぅ、出来た。サーバ側だけで何時間かかってんだ。さて、Silverlight側に実装だけど、削除対象の算出がめんどくせぇなぁ。
idは使えないだろうから三つのキーで合わせてみるとして、、うへぇ。
めんどくせぇ！なんだこの仕事。死ねばいいのに。
なんていってないで作ろうか。
17:29
一切テストせずに全部書いたぞ。Silverlightはビルドが遅いから一気書きが多くなる気がする。
こっからテストなんだけど、何が嫌だって、テスト用の商品コードとかを俺が全然わかんねーから時間かかんのなんのって。
17:32
なんか怖すぎるのでDBバックアップ先に・・。
17:42
まさかの検索側問題で動かず。
17:47
どうも動いているっぽい。一回コミットする。
ただコードからIDひっぱらないと駄目っぽいね？この辺りが「仕様書には書いてないけどそういうのを作らないと動かない仕様」ってやつで、おぞましいんだよね。設計者が当然だと思っている部分なんだけど、これWebだと普通にAjax処理になって重いですから。
やるけどさぁ。
17:59
一服終了。さて仕上げるか。予想通りこれだけでつぶれてんな。明日も出るしかないか・・。ふぅ。
18:16
前作ったコードが結構使える。てかC#3 + Silverlightって、慣れてくるとラムダだらけにならんか？これ読めんのかなぁ・・。
18:19
うお・・っ、なんだそれ。テーブルのキーを持っておきながら違うのか？どういうことだ？ってかこれもセットしないといけないのか？
まてまてまて、なんだこれは。該当する値ってなんだ。なんだなんだ。モデルから修正なのか？なんだ？
18:24
やる気なくなった。
18:26
AまたはBが変わったタイミングでCの値は更新される可能性があるが、CはBとDで取得可能。CをとるべきかどうかはEが必要。EをとるにはCをとらないといけない。
Aが変わったタイミングでDの情報を取得する必要がある。
てことはつまりBの時にDがある場合か、Aの時にDの取得に成功しかつBがある時にEは気にせんでCを取得して、C取得後Eを更新して、とる必要のないデータだったら捨てて、必要のあるデータだったらCを更新すればいいのか。
きんもー。
18:56
一通りやってようやく保存テスト出来るようになった。
保存できてねーじゃん。あれ・・。
19:03
なんかバグ修正中に別のバグが見つかってそのバグ対応に追われるという。
おかしい。Cakeは私は完璧に保存したと威張っているし、Silverlightも完璧に処理しましたと威張っているのに・・。
しかしキャッシュうぜーな。Cake側ではbeforeFilter段階でdisableCacheしてんのに。
ユニークIDつけるしかなさげとかおいおい。
http://social.msdn.microsoft.com/Forums/ja-JP/silvelightdotnetja/thread/92a959d7-b916-4fe5-804b-32a7f2fd8258
19:23
どーも日付書式が合ってないのが悪さしてるくさいんだが。CakeもCakeでsaveAllの戻り値でEmpty返してんじゃねーよなぁ。
19:45
なんか調べたけど、結局コンバータかかないといけねーんじゃねーのこれ？だるっ！
19:50
とりあえずコンバータ書いてやったけどおいおいこんな時間じゃねーか。客先IDが保存できてねーなぁ。てか客先IDも仕様に記載のないバックグラウンド処理で持ってこねぇといけねーんじゃねーかよ。いい加減にしやがれっきしょー。
一度帰ろ。続きは家でやろ。今帰らんと飯も食えねぇからな。明日確定コースだし、今週も髪切れなそうだなぁおい。だるっ！
21:07
家帰ってからやって結局この時間に終わった。途中ベトナム側での実装にトンチンカンなモデルの修正処理とか入ってて直してたら時間くっちったよ。
今日出来たのは保存だけだから、その他が大量にある。明日だな・・。
ふぅ。
