WR blog

（佐藤正美氏新刊出版記念）新T字形ER手法「TM」で始めるシステム分析セミナー　　～短納期・高品質・低投資時代への対応～

あるみたいです。 TM/T字形ER手法に興味がある方は是非。

October 27th, 2005 | Category: Uncategorized | Leave a comment

参加してきました。今回は発表はなしでした。

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)

October 24th, 2005 | Category: Event, Java, Programming, Ruby | Comments (5)

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メソッドを実装しているクラス群が何でもコマンドパターンというのは違うと思いますがね。 インスタンスにデータとロジックがパッキングされていることがポイント。 と思いますよー。と、気弱にまとめてみた。

September 19th, 2005 | Category: ObjectModeling, Programming | Leave a comment

PofEAA’s Wiki - PofEAA読書会第6回

行ってきた＆少しお時間をいただけたので、発表しました。

サーガ

.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”

箇条書きにて。

• 時間15分もらえた。
  • OHPは5ページ進んだ
  • 残り30(!)ページ
• サーガの定義について鋭いツッコミ
  • いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし）
  • 補償トランザクションの補償は電話（＝運用対処）
• 補償トランザクションの実現イメージ
  • 純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。
  • ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。
  • また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。
  • これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様
• バッチでキャッシュは怖い
  • よねー。やっぱり。

いろいろ

• yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。）
• 議論の参加者が増えていい感じ。
  • 整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺

感謝

あれだけの大人数なのに、一体感をもって進められたのは、絶妙な座席配置に資する部分も大きいかと。ありがとうございます。＞オージス軍団の方々。

→ GLADさんとkukutaniさんの工夫みたい。すばらしいです。ありがとうございます。

September 11th, 2005 | Category: Event, Modeling, ObjectModeling | Comments (6)