PoEAA 3rd
PoEAA読書会 第3回に参加した。まとまりなく書いてみる。
発表資料はこちら
駆け込みで前夜に資料作成
前夜1:00am-6:00amぐらいで3章のサマリをPPTで作成し、持参&発表。 直前に駆け込みで作ったこともあり、内容はイマイチだったけど、議論のベースとして機能したので結果オーライ。ということにする。んで、質は量に転化する。ということにする。（これまでも、これからも）
あ、資料作成の際には昔WOMeetingで使った資料を流用したりした。継承の実装方式の図や、RDBMSのイメージとかEnterpriseObject(笑)とか。ちょっと手を抜けた。
進め方など
当初、15～25分程度でさくっと進めるつもりだったのだけど、実際始めてみると、 発表しつつ、議論しつつな感じで進めたほうがよさそうな印象を受けたので、そうすることにした。 自分が2部以降をキチンと読み込んでいなかったため、議論についていけなかったり、議論の整理がうまくなかったりした部分があったのは反省点。でも、読み込む時間がないのよねー。あと、情報を体系化して、脳みそへ定着するための時間が。
議論に参加してくれた方、感謝。いろいろ話して、楽しくやりましょう。 特に、ひがさんには感謝！感謝！有益なネタ振りをたくさんしてくれた。しかも、カナリ読み込んでるし！ つーか、発表者のくせしてあまり読み込んでなくてごめんなさい。たたき台として存在する意味があると自分に言い聞かせる。
UnitOfWork
EOEditingContext! EOF最強！ 楽○○○○○○御が実質的に機能しない点を除いては！（苦笑）
外部キー制約、参照整合性
外部キー制約付けない派が大多数。なるほど。確かに実務上は付けないほうがよさそうではあるのだけど。 ちょっと意外ではあった。
依存
依存概念をCASCADE ON XXX制約でカバーできるかどうか？については良くわからない。 EOFの場合、(確か) 親Objectと子Objectのリレーションシップを切断すると、子Objectが削除されたはず。 というわけで、Objectの世界で依存概念の意味をどこまで規定するかに依存すると思われる。 ただ、たいていの場合、CASCADE ON XXX制約で十分な気がしている。
一瞬、ER図にも依存概念を導入したほうが良いかなと妄想した。うーん、IDEF1xとかだと入ってそうだな。でも、あれを理解する気にはなれない・・・。ま、いいや。
EOF/WebObjects
発表が終わって、ogijunさんとボソボソ。 やっぱ、EOFはいけてるねーとか。
O/Rマッパーに必要な概念のほとんどを実装しているからねぇ。 Apple買収後も、XML対応とかいろいろ適切な方向に進化してくれたら面白かったのに！とか思う。
あと、Webフレームワークがステートフルな方向に行くのなら、WebObjectsフレームワークも・・・って、完全に脱線だなコリャ。
ちょっとWebobjectsに興味をもたれたかたは、ここらへんとか、suzukiさんの有益な資料(spice-of-life.net - WebObjects)などをごらんくださいまし。
概念をビジュアル化することの効能
余談だけど、概念を脳みそへ定着させるために発表スライドをつくるというのは結構有益。 ソフトウェアをビジュアル化する作業は、モデリング技術の延長上にある。複雑なもの・見えないものをある側面に着目して、表現することに相当する。短期的・長期的に有益。 というわけで、誰か、次回のサマリ担当に立候補してくれないかなーと。
ポジションペーパ
リンク集発見!
ありがとうございます。koicさん。
Day by day(2005-05-23)
