WR blog

Joel on Software

業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。

この本、本当にいい本です。

第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。

超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。

December 16th, 2005 | Category: Book, Programming | Leave a comment

そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。 いかんですね。

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の実行順序を工夫するあたりで、中村さん（？）が言っていた内容がよく聞こえなかったのですが、誰か教えてもらえません？ 次回で無事終わることができる・・・かもしれない。

December 6th, 2005 | Category: Event, IT, Programming | Comments (4)

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

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