（なんと前回のエントリから3年近く間が空いてしまいました・・・） Oracle Database のアーキテクチャについて説明した書籍「プロとしてのOracleアーキテクチャ入門」を 執筆するお話をソフトバンククリエイティブ社様よりいただき、 同じ職場のOracle暦10年のベテランエンジニアの方と共同で執筆作業をすすめ、 2008/8/22に（なんとか）無事出版できました。
ソフトバンククリエイティブの本:プロとしてのOracleアーキテクチャ入門
Amazonのレビューでも好意的なコメントをいただけており、ほっと一安心といったところです。
Joel on Software
業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。
この本、本当にいい本です。
第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。
超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。
そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。 いかんですね。
Unit Of Work : まさゆきさん
Hibernate との比較で語られていたので、わかりやすかったように思う。 ちなみに、EOF/WebObjects関連の資料は、WebObjects基礎研究室 とか、WebObjects関連プレゼン資料 にあります。
ちょいとHibernateに対する疑問
1 Request = 1 Sessionなる考え方にどうもなじめないなぁと。EOF/WebObjectsの1 HTTP Session = 1 Unit of Workの方がシンプルな気がするのです。なぜなら、複数画面に渡る編集機能を実現することを考えた場合を考えると、いちいちdetachしてattachするのが面倒に思えるので。（と某mixi日記に書いたのですが、獄長から「Hibernateでも1 HTTP Session = 1 Unit of Workでつかえるよん」とツッコミが。1 Request = 1 Sessionと1 HTTP Session = 1 Unit of Workを使い分けるというのがよい？） なんであんなにListenerが必要なのだろうか？実行の順序性に意味がありそうな一連のオペレーションを、Event, Listenerモデルで構築する意味がわからない・・・
Identify Map
Fawlerの語りの意味を読み解く作業は不毛感ありまくりな気がするなぁ。 FawlerはIdentify Mapをキャッシュと密接な関連を持つものと位置づけているようだ。
Lazy Load
t-wada さん、相変わらずすばらしい発表ですね・・・。構成がイイ！なんというか、つかみがうまいんですよねー 具体的な事例、コードを見る視点と、抽象的なレベルでのアーキテクチャの捉え方の視点をいったりきたりする感じがとてもイイ！です。
WRサーガ：非TM対応RM, キュー形トランザクション
ちょっと仕込みが足りなかった感じ。反省
べき等のあたりの説明って、理解できました？ ＞ 皆様
あれ？ 困ったときのkoichikさん頼り ができないじゃん！・・・と思ったらafukuiさんがいらしていたので・・・よかった！助かった！ 【お願い】TM未対応RMの実行順序を工夫するあたりで、中村さん（？）が言っていた内容がよく聞こえなかったのですが、誰か教えてもらえません？ 次回で無事終わることができる・・・かもしれない。
（佐藤正美氏新刊出版記念）新T字形ER手法「TM」で始めるシステム分析セミナー ～短納期・高品質・低投資時代への対応～
あるみたいです。 TM/T字形ER手法に興味がある方は是非。
参加してきました。今回は発表はなしでした。
TableDataGateway (わたなべさん)
読書会の議論でも発言させていただきましたが、TableDataGatewayは（非常に荒いレベルの）オブジェクトの設計方針について、わかりやすい指針を示しているものに過ぎないと考えます。
具体的な対象と照らし合わせた上での、責務の範囲 : 具体的には・・・RDBの構成要素（テーブル、カラム、複数テーブルなど）を相手にするGateway一般の中で、TableDataGatewayは、テーブル（もしくはテーブル類似のビューなど）を相手にする。責務の範囲をテーブルとする クライアントから見た場合のインスタンス関係。もっと言えば、アイデンティティ。：具体的には・・・TableDataGatewayは1テーブルにつき1個。（テーブルの数は簡単に数えられる（苦笑）ので、インスタンスのアイデンティティも容易に理解できる）
RowDataGateway (和田さん)
あとで書きます。
ActiveRecord(inoueさん)
Railsのデモが中心。やっぱRailsすげー！
ちょっと気になったのは、Railsの実行モデル。あれだけ評価・処理実行・自動生成が走るとなると、CGIでは・・・きついよね。多分。
議論を聞いて。
ビジネスロジックの割り当て、データアクセスの議論が混在している印象。 ここは分けて話さないとまずいっす。
せっかくファウラーたんが、整理してくれているのだから。（わかりにくいけど）
角谷さんの意見に同意
わからない部分を曖昧に、抽象的に触れて流すよりも、わからない部分を明確に提示し、自分が理解できている（と思っている）部分を具体的に示すほうが良いと思う。ここはそれが許される「場」であると思います。
言い方を変えれば、せっかくなんだから燃料を投下しましょうよ。 どんなに炎上しても誰かが整理してくれるし。となるかも。
資料（半）公開希望。
再度資料を見て、記憶を呼び戻したいので。 懇親会で酔っ払ったので、良く思い出せないというは秘密。
戦果
ogijun氏が蔵書の一部を販売していたので、以下の2冊を購入。
ユースケース実践ガイド 1500yen : 最近、プロセス屋さんの世界で next ユースケースが熱いらしいので、あらためて基礎を抑えておこうかと。 ソフトウェアエンジニアリング基礎知識体系 600yen : なんか、書き物書くときに便利そうじゃない？たとえば・・・「IEEE xxx では、～における特性として、a) ・・・性、b) ・・・性、c) ・・・性、が求められている。本ドキュメントでは、a) ・・・性の・・・について記述する。」とか。
懇親会
獄長！獄長！獄長！ry)
PofEAA 読書会で話題になったので。
シンタックス的に利用する機構（＝多態性）が同じこの2つのパターン。 思うところをつれづれと書いてみたりする。
コマンドパターン
マクロでみた意味的には、そのインスタンスにコマンド実行（処理実行）に必要なデータと、ロジックを詰め込むようなイメージ。
必要なデータとロジックがインスタンスにパッキングされているがゆえに、1番目の処理Aと2番目の処理Bと3番目の処理Aを実行したい場合は、処理Aに対応したインスタンス＋処理Bに対応したインスタンス+処理Aに対応したインスタンスをキューなどに並べておき、順次実行すればよいこととなる。 コマンド実行のトリガを与えるクライアントが、コマンドのインスタンス以外に気を使わなくて良い点がポイント。コマンドクラスが、そのコマンド実行に必要なデータ、ロジックをカプセル化して保持しているから。 さらに、コマンド実行を取り消す（アンドゥ）ために必要なデータと、ロジックも詰め込むようにすることで、アンドゥ処理が可能となる。
OOPの意味的な観点でいうと、コマンドパターンは「インスタンス」に意味がある。
具体的には、同じMoveCommand(dx, dy)でも、new MoveCommand(5,10)と new MoveCommand(-10,20)は、処理内容が異なる。
多態性は、クライアントが異なるコマンド種別を統一的に実行できるために活用される。
Command cmd = queue.getCommand(); cmd.execute()
ストラテジパターン
マクロで見た意味的には、ロジックをプラガブルにしたようなイメージ。インスタンスレベルで保持するデータにはあまり重きを置かれていない。
クラスとか、インスタンスとかが本質的な意味でポイントにはならず、プラガブルな構成要素的な観点を持つものであればよい。
OOPの意味的な観点でいうと、ストラテジパターンは「インスタンス」にあまり意味がない。
プラガブルな機構を実現できれば、ストラテジが提供するメソッドはクラスメソッドでもかまわない。（暴論気味・・・）
多態性は、クライアントの統一的な利用というよりは、プラグ差し替えを実現するための機構として利用される。本質は利用形態の一元化ではなく、差し替え可能性にある。
最近のコマンドパターン
StrutsのActionFormをコマンドパターンとか言う人もいて、 ちょっと違和感を感じていたりもするけど、まぁいいかも。という気もする。
HTTPリクエストの内容を、1つのインスタンスにパックしており、かつ、ビジネスレイヤの呼び出しというロジックも（一応）実装しているから。上記に話とも一応対応している。
が、キューに格納されるでもなく、アンドゥ機構を提供するでもない点がちょっと引っかかるかな。コマンドパターンのご利益を活用しているわけではないということ。
executeメソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。
PofEAA’s Wiki - PofEAA読書会第6回
行ってきた＆少しお時間をいただけたので、発表しました。
サーガ
.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”
箇条書きにて。
時間15分もらえた。
OHPは5ページ進んだ 残り30(!)ページ
サーガの定義について鋭いツッコミ
いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし） 補償トランザクションの補償は電話（＝運用対処）
補償トランザクションの実現イメージ
純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。 ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。 また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。 これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様
バッチでキャッシュは怖い
よねー。やっぱり。
いろいろ
yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。） 議論の参加者が増えていい感じ。
整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺
感謝
あれだけの大人数なのに、一体感をもって進められたのは、絶妙な座席配置に資する部分も大きいかと。ありがとうございます。＞オージス軍団の方々。
→ GLADさんとkukutaniさんの工夫みたい。すばらしいです。ありがとうございます。
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル
公開されたようです。
▼ 早稲田大学エクステンションセンター 秋講座 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 早稲田大学エクステンションセンター（社会人向けの公開講座）の講師を、秋もやることになりました。 秋の講座は、９月30から12月９日まで、毎週金曜日の19:00から20:30までの10回の連続講座です（10月21日、休校）。
費用が非常に安価なので、個人的にT字形ERに興味があるが、会社からお金を出してもらうのはちょっと・・・という方にオススメできます。
毎回の講座後の飲み会も楽しい。
出席&発表してきた。
発表資料はこちら
WOMeeting発表資料 WOMeeting200508 - WOWiki
なんかやたらと眠かったので、飲み会はパスさせていただいた。 行った方がよかったかな？とちょっと思ったり。
