Hackathon当日メモとYakiBiki TODO メモ
有休取ってようやく復活する程度に普通以下の体力のid:msakamoto-sfです。ということで今日買ったばかりのNOSTRADAMUS(JUDAS PRIEST)聴きながら記憶をまとめ直してます。ところでNOSTRADAMUS、エエですね。暫くRhapsodyもBlind Guardianも新譜出してなかったので、正直メロディアス/シンフォニックメタルにマジで飢えてました。
Hackathonですが・・・結局、id:msakamoto-sfは23時には寝てしまいました。(爆)
えーっと、背もたれがないと姿勢を保っていられない程度に筋肉が無い貧弱な肉体で、やっぱ無理でしたね。またPHPのコードに触るのが実に2-3週間ぶりで、片づけようと思っていた自分のコードを理解してどう手を加えるのか考えるので精一杯という感じで。YakiBikiのDAOレイヤーをgrainベースに入れ替えようと思っていたんですが、find系のメソッドの構造が結構関数キャッシュとかcallbackが入り組んでて、どう解体してどう再構築しようかで悩んで終わってしまいました・・・。
結局、十分寝たせいか、そして会場の椅子が背もたれつきでしかも大会場にずっと居たのですが空調が効いていたせいか、PHPカンファレンスでの最前列に座っていた時の方がめちゃくちゃコーディングが快適だった始末。Hackathonでは悩むだけで終わりましたが、翌日のPHPカンファレンス中のコーディングで何とかDAOのBaseクラスをgrainベースのコードにreplaceすることができました。但し、E-Mobileユーザーがバリバリに接続しまくってたらしくSVNのコミットが異常に遅くなったため、さらに明けて今日、コミットした次第です。この影響で、現在のYakiBikiのtrunkは正常に動作しなくなっています。Baseが変更された為、全DAOおよび全TXレイヤーが動かなくなっているためです。
後はHackathonとか翌日中に思いついたり気づいた事。
- 作ったは良いけど結局使ってないインデックスがあった。
- G2Aインデックス
- U2Aインデックス
- ここら辺はACLキャッシュで使う予定だったけど、結局全く使わずに実装できちゃったんだよな。
- モデレート機能:変更があっても、バージョンを変えないように出来れば良い?
- スレッドは只の名前空間に。権限とかは外す。っつーかWikiの命名規約があればほぼ無用じゃない?
- →どちらかというと、「スレッド」自身が名前空間であり「テンプレート」だよなぁ。
- →「スレッド」じゃなくて「デフォルトセット」というべきかな?概念を表す上手な言葉が見つからない。
- カテゴリの作成やスレッドの作成権限→ROLEに押しつけていいんじゃね?
- 開発した本人ですら訳分かんなくなりそうな微妙な権限ポリシー、やめよう。カテゴリとかスレッド周りの。
- SmartyのHTMLエスケープ機能の組込:default_modifierというのを調整すれば良いらしい。
- 機能と見た目をシンプルにする。開発者本人が、特に権限周りの機能に振り回されかけてる。
忘れかけてた自分のメモにリンク。
http://d.hatena.ne.jp/msakamoto-sf/20080608/1212931311
あと、id:kunitさんに隙を見て気になっていた点を確認できた。これだけでも収穫。
- APL2のライセンスにLGPLのコードは混ぜられるか?
- → 難しい。やらない方が良い。LGPLの方が感染力が強い。
- privateメソッドのxUnitはどう実装しているのか?
- 派閥がある。
- リフレクション使って無理矢理呼び出したり、
- privateじゃなくてアクセス修飾無し(=packageスコープ)にして同じパッケージにxUnitを入れたり、
- そもそもprivateになりそうだったら、委譲する、とか。
- ネットワークやDBなど、外部世界との境界線上の異常系のテストの自動化の話題は上がっているのか?
- まだその辺りの話は出てきていない。ニーズが有れば出てくるのでは?
privateメソッドのテストについては、実は自分的には private を呼ぶだけのpublicなラッパを実装したクラスを用意してそれ経由で・・・とか思ってたんだけどそう人は居なかったみたい。また境界線上の異常系なのだけれど、雑誌記事やBlogで見る限りでは非常に理想型のロジック部分だけしか取り上げて居らず、
- 例えばトランザクション処理中にDBが突然ダウンした時、一定時間のT.O.後にX回リトライするとか、
- SYNパケット受信後、X秒間何もパケットが届かなかった時の異常系とか、
- TCP/UDPソケットでread()/write()中に突然LANケーブルが外れたりとか、
そうした滅茶苦茶ボーダーマージナルな部分の異常系の取り扱いロジックのテスト自動化については、まだそうした話は出てきてないみたい。
実際の所、今自分が出ているところがそうした通信系で非常にシビアな部分までもテスト(しようと)する文化で、この辺りまでクリアできないと上の人達にテスト自動化のメリットを納得させるのが難しいと考えていたりいなかったり。でもこのレベルになるとカーネルレベルの挙動をHOOKINGできないといけなかったりで、KernelHacker級の技量が無いとそもそも無理な世界だよな。プラットフォームの縛りも入るだろうし。