2008-12-14 :-|
_ 朝ッ
1000起床
_ 風邪 未だ治らず
以前は一晩寝れば治ってたんだがなあ。チャリ通勤しなくなってあからさまに体力が落ちたか
_ デザインパターンを切る
4分冊
- 第一章 概論〜第二章 事例:ドキュメントエディタの設計
- 第三章 生成に関するパターン
- 第四章 構造に関するパターン
- 第五章 振る舞いに関するパターン〜最後まで
4冊目が厚くなった
そういや仕事場でこの本が捨てられていたな
_ 九州Ruby会議01の Ustream を見始めた
ust やってるらしいのだけど 九州Ruby会議01 - Regional RubyKaigi を見ても ust の URI が書いておらずグーグル検索しても見当たらないので ust は諦めていつものように trance なラジオを聴いていたのだが hsbt さんとこ に URI が書かれたので 九州Ruby会議01の ust を見始めた。九州Ruby会議01 - Regional RubyKaigi のページに書いてないということは公式じゃなくて野良 ust なのか？
_ [インターフェイス指向設計]インターフェイス指向設計
オブジェクト倶楽部に顔を出していながら私の脳はさっぱりオブジェクト脳ではないので「インターフェースを実装すると何がうれしいの？」という日々を送っていたのだけど
インターフェイスを意識することで、設計が「疎結合」になります。(p. ix)
ああなるほど。
あと arton さんが言うように コードのスタイルが気持ち悪い。
4873113660
_ いろんな脳が足りない
日記を読んでても id:hoso-kawa が何を言ってるのか分からないし( たぶん Seasar 方面によく登場する言葉だろう ) だいぶ前に koic が言っていた SRP とか LSP とか 何のことか分からないし( ref.Principles of Object-Oriented Design - SlideShare ) NetBSD の nvi で話題になってる Unicode 云々なんてのも「ふーん」「へー」くらいにしか読めないし何ていうかいろいろヤバいなオレ修行するぞ修行するぞ。
で、あのチャットでの「よっこいしょういち」につながるわけか。
m_pixyさん：<br>あー。そうです。<br>wassrのrubyチャネルなどをウォッチしていれば Ustream の話題があったかもしれぬよのう。
やれるかどうか直前まで自信なかったからアナウンスしてなかったみたいです。アナウンスすればよかったのにね
正規の手続きでリリース時期遅らせられれば<br>死人はでないかも。<br>僕の感覚ではウォーターフォールといっても<br>契約(条件)次第ってとこ。<br>(どうとでもなる回答だな)
かくたにさん：<br>ヤマカンで http://www.ustream.tv/channel/rubykyushu などを覗こうとしたのだけど辿りつけませんでした orz<br>自分の情報収集能力にガッカリした。
坊T＠さん：<br>文字通りの「デッドライン」が決まっているプロジェクトを再計画する、なんてことをやってのけているひとが居たら事例を聞きたいですの。いやけっこう切実なんだけどね。そういうのも交渉スキルになるのか。<br><br>うー。<br>胃が痛い
僕はパッケージ製品適用ばかりだから事例が難しい。<br>公共は法改正日が決まってるからデッドラインは<br>決まってるけどなんとかかんとか(開発元で死人が<br>でてるのかなぁ。。。)<br>可能な限りの段階リリースにして分散させるしかないかも。<br>仕様がぼろぼろならもうお手上げ。
坊T＠さん：<br>仕様が決まってない場合はすごいことになりそうっすねえ...。「この日までにこの製品を納入する。納期を遅らせることや機能を削減することは許されない」という場合には....がんばるしかないんだろうなあ。なんだよがんばるって。<br>そのような場合はプロジェクト開始時に見積りを誤ると大変なことになるんすよね。<br>ガチガチのウォーターフォールならば、見積り時には作業量が見えてるはずだから見積もりを誤ることはない、ってか？ううむ
僕もインターフェイス指向設計のあのスタイル苦手です＞＜ <br>最初はカーネルスタイルっぽいので書いてたんだけどな...
youichiさん：<br>うん、いや、あれはあれでたぶんアリなんだと思うんだ