Event « WR blog

PofEAA 8th

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

### 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 […]

PofEAA 7th

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

### 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) ・・・性の・・・について記述する。」とか。

[…]

PofEAA 6th

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

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

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

箇条書きにて。

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

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

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

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

WOMeeting2005/08

出席&発表してきた。

発表資料はこちら

* WOMeeting発表資料 * WOMeeting200508 – WOWiki

なんかやたらと眠かったので、飲み会はパスさせていただいた。行った方がよかったかな？とちょっと思ったり。

J2EE勉強会第11回

いやー、内容の濃い5時間半だった。

### EJB 3.0

いやー、ついていけませんでした。正直。ぜんぜんEJB3を追っかけてないからなぁ。

### Next Generation J2EE Deployment

気になったとこだけ。

* データアクセスレイヤ?ビジネスロジックレイヤをつなぐデータ構造（モデル）としてドメインモデルを、ビジネスロジックレイヤ?ビジネスロジックレイヤをつなぐデータ構造（モデル）としてプレゼンテーションモデルを利用する。 * 誤解を恐れずにいうと、 * ドメインモデルはデータベースのテーブル構造に比較的近い構造のJavaクラスモデルとなる。 * プレゼンテーションモデルは、データベースのビューに近い構造のJavaクラスモデルとなる。 * かなり乱暴なものいいです。 * ドメインモデルとプレゼンテーションモデルの変換は、ビジネスロジックレイヤの背後にいるDxo（ダックスオー）が実行する。 * ドメインモデルの構造として、テーブル構造に比較的近い構造を使用する理由は、Persistence APIの存在があるため * ドメインモデルはJavaクラスのデータ構造に関する。PofEAAのドメインロジックパターンと混同せぬよう。後者は、ロジックの割り当てに関する。 * EJB3 or Seasar2の選択は、開発元の文化によると思われる。 * 標準化を重視するかどうか。とか。

### テスティング話

結構盛りだくさんでした。早期の資料公開希望します（笑）。

PofEAA 5th

PofEAA第五回読書会に参加してきた。

発表に関連した議論の内容を中心に、箇条書きでメモ。

### セッションステート * レコードデータとサーバセッション * セッションステートをRDBに書き出したレコードはレコードデータではない。 * publicかつpersistentなデータがレコードデータであると理解した。 * 文中の「データベースとサーバセッションの中間の位置」とは何か？ * 中間の位置ではなく、中間の特性（？）ということみたい。 * 「位置」なる訳は、かなりグレー。 * セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。 * 具体的には・・・セッションに格納するデータ量の大小、セッションの維持時間 * セッションに格納するデータ量が多い場合→ アフィニティ? * セッションの維持時間短い場合→ アフィニティ? * （セッションアフィニティに関連して）ロードバランシングについて・・・ * 書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロードバランシングが実現できる。 * 書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。 * DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。 * Session Stateとパフォーマンス * ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？ * ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。 * PHPにはセッション情報をインメモリに持つ手段が無い。 * スクリプト起動のモデルがCGI的である故 * デフォルトで、セッション情報はファイルに格納する * RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。 * […]

WOMeeting2005/07

行ってきた。

### Practical WebObjects読書会 Chap11 : XML 毎月恒例のPractical WebObjects読書会今回のサマリは、Chapter 11. XML and WebObjects をTさんにお願いした。

内容は、XML技術の概要と、WOの持つXMLシリアライズ/デシリアライズ機能を使ったデモアプリケーションの説明。

著者の用意しているデモアプリケーションの機能・意味合いがちょっと微妙で、XMLシリアライズ/デシリアライズ機能をうまく使ったモノでないため、実際にどのような方面でシリアライズ/デシリアライズ機能を使うべきかがイメージしにくかったようにも思う。終わった後にTさんと話したのだけど、やっぱりWebサービスを絡めないとご利益が出てきにくいのかもしれない。

### Seasar 2 for WO Developer kakudaさんの発表。

kakudaさんのプレゼンテーションは、概念的なところの説明から、実際のDI動作のデモまでと、非常に準備に手がかかったすばらしいものでした。

試用レベルでも、DIを使ったことがあるのがkakudaさんと自分だけということに驚いた。WO屋さんは、やっぱり一般的なjava屋さんとは違うみたい（笑）。

皆、DIという概念を全く知らなかったのため、デモの説明を理解するのに苦労していたように思えた。やはり、最初は理解しにくいかもしれない。

ただ、私はWO屋さんにDIという概念をこの場でどうしても理解して欲しかったので、（あえて）暴論気味に、「結局はファクトリですよ。DIというのは。」的な説明をした。新しい概念を理解してもらうには、既存の似た概念を引き合いに出すのが手っ取り早い。もちろん、あくまでも「似た概念」に過ぎないので、同じところもあれば、違うところもあるのだけど、とりあえずのスタートとしては「ファクトリ」を引き合いに出して説明するのがよいと判断した。（その場では）

続けて、「ファクトリはコード内の条件分岐（かそれに類するもの）で生成する具象クラスを決定するが、DIは外だしにした設定ファイルで生成する具象クラスを決定する」という点を説明。微妙に嘘も歩けど、従来は「コード」で実現していたものを、「コンテナ＋設定ファイル」で実現しているという位置づけにしたほうがわかりやすかろうと、あえて言い切った。

また、kakudaさんのデモや、「WOにDIを適用するにはWOComponentのpageWithName()をオーバライドして、内部でS2Container#getComponent()を呼び出して云々」なる説明を通して、Seasarの特性である「インスタンスレベルのAOP」という概念も理解してもらえたようだし、よかったのではないでしょうか。うんうん。と自画自賛。

### 飲み会まだ風邪が治っていないので、飲み会はご遠慮させていただいた。

J2EE勉強会第10回

参加させていただいた。

場所は秋葉原近くの某研究所さん（名前カードや、注意書きの配布など、キッチリした事前準備に驚きました。ありがとうございました！）でした。

内容は、髪をばっさりと夏仕様にしたひがさんによるJSF(myfaces, s2jsf)のソースコードの追い方講座と、t-wadaさんによるTDDをめぐる混乱について。

* t-wadaの日記

### JSF(myfaces, s2jsf) のソースコードの追い方講座

箇条書きで。

* myfacesの実装はところどころアイタタタな面がみられる。 * 処理の起点はfacesservletである。 * jsfのアーキテクチャはWebObjects Frameworkに酷似している。 * 画面の構成要素に対して、動的にidが付与され、idがマッチする画面の構成要素に対して処理が実行される * リクエスト-レスポンス・ループに関連する状態を管理するクラスはfacescontextである。(WebObjectsの場合、WOContext) * リクエスト-レスポンス・ループ処理は、いくつかのフェーズに分割して行なわれる。 * WOとの相違点は、validationフェーズが独立して存在すること * WOの場合、処理を実装する場所はフェーズx{Application, Session, WOComponent}の掛け算分だけあるのに対し、JSFの場合はもうちょっとシンプルな構成になっているみたい。 * JSFは適用領域をWeb/HTML/HTTPに限定していないため、内部のコンポーネントに対して直接???Request, ???Responseを見せない。見せるのはfacesContextのみ。この中にRequest類が入っているようだ。

### “Test” という言葉 (TDD話導入編) by t-wada

後で書きます。

先輩の2次会終了・・・ほっとした。

大学時代の大先輩の2次会の幹事をおおせつかったので、ここ3週間はいろいろとバタバタしていた。先週末の日曜日に、その2次会が無事終了。綱渡りのような、トラブル続きの2次会だったので、無事に終えることができてカナリほっとしている。

### トラブル（の一部）

* ネタがかぶった・・・ * バンド連中のネタは事前に把握していたのだけど、新郎職場の素人さんのネタがなかなか決まらず把握し切れなかった。そうしたら・・・・ネタがかぶった。orz. これだから素人はイヤなのよ。 * →後輩の機転で、演出を変更し、ことなきを得た。 * 時間押しまくり・・・ * 出演時間を守らないバンド大杉！お前ら、15分って言ってあったらだろ？！幹事を泣かせるなと。 * →時間的にスケーラブルにしてあったので、軽めの出し物を1つ削って対処 * 引き出物が違う！ * 会場の担当者から受け取ったダンボールの中身が、会場のロゴが入ったグラス。これが引き出物のはずはないし、そもそも、グラスをそのまま渡すなんてありえない！ * → 会場の不手際でダンボール間違い。置き場から正しいダンボールを発掘した・・・が、その引き出物は仕込が必要なモノだったので人海戦術で対処、対処。つめつめ。仕込が必要ならその旨言ってくれないと・・・。 * ギタートラブル！ * ただでさえ押しているのに、ギタートラブルでさらに押し・・・・orz. * → 片づけを超マッハでやることで対応 * ビデオケーブルがない！ * ビデオ出力が受けられると聞いたのでアップスキャンコンバータを後輩に手配してもらい、準備万端・・・のはずが、会場には1mのビデオケーブルしかなく、PA卓から客席まで届かない！我々がビデオ出力を使用するということは、前に伝えてあった筈。狭いPA卓に我々が入れない以上、それなりの長さのビデオケーブルがあってしかるべき。 * → ビデオケーブル購入で対応 * PAが遅刻 * 論外！約束の時間からかなり遅刻しやがってきた。ムカムカ。おかげでせっかく前倒しして入場したことによるゲインが相殺されてしまった。 * ワイヤレスマイク受信機の出力が受けられず * 出演者にキャノンでしか受けられないと念押ししていたのにかかわらず、出演者が持ってきたワイヤレス受信機はフォーン出し・・・orz. * → 変換ケーブルを買ってくるように依頼・・・したけど最終的な対処方法は不明。なんとかなったらしい。（つーか、会場にキャノン←→フォーンの変換ケーブルが無いのが大問題なわけだが）

### ありがと。

コレだけのトラブルに対処できた理由は、あらかじめ計画を立てて、役割を委譲していたため。 […]

PoEAA 4th

* PofEAA’s Wiki – PofEAA読書会第4回

行ってきた&発表してきた。

### PofEAA Chap5. Concurrency ogijunさんのサマリをベースに。

ひがさんとkoichikさんによる（豪華な！）レクチャー風景を見物できて、こっそり満足（笑）。見た目的に面白く感じたので、携帯のカメラで撮影してしまった。（笑）。

話題に上った分離レベルの話について、詳細に知りたければ別の書籍にあたるのが良いと思う。分離レベル程度ならば、いくらでも良い解説は読める。もう少し具体的なレベルで知りたいならば、RDBMS固有の振る舞いに振れた書籍にあたるのが良い。

SQL Serverの場合は、.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”がなかなかよい。

そして、Oracleの場合は、

がわかりやすいのでオススメ。（これ以外の書籍がNGというわけではサラサラ無いです。自分が所有している書籍の中では。という意味）

### 自分の発表：複雑なトランザクション 1/2

自分の発表のネタは、

の第3部の複雑なトランザクションをサマリ化したもの。これの内容をベースにいろいろ議論した。

時間の関係もあり全部はプレゼン&議論できなかった。今回扱うことができたのは・・・

* 8章. 対話型トランザクション処理の設計方法 * 対話型トランザクション処理とは * 業務排他制御による対話型トランザクション処理の設計方法 * 楽観同時実行制御による対話型トランザクション処理の設計方法 * 9章. 複雑なトランザクション制御 * 複雑なトランザクション制御とは * ネットワーク障害時のメッセージロスト対策

まで。

### 記憶している範囲で・・・論点となったのは

* ロックの方式 […]

WR blog

Recent Posts

Archives