WR blog

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

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 | Tags: PofEAA | 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 | Tags: PofEAA | Category: Event, Java, Programming, Ruby | Comments (5)

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

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

サーガ

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

箇条書きにて。

時間15分もらえた。

OHPは5ページ進んだ 残り30(!)ページ

サーガの定義について鋭いツッコミ

いやー書籍における定義は、自分も怪しいとおもっていのたのだよねーと。（→OHP該当ページの一番下の行を見られたし） 補償トランザクションの補償は電話（＝運用対処）

補償トランザクションの実現イメージ

純粋OLTP系処理なら黒伝＋赤伝なるイメージとなる。トランザクションデータ（=取引系データ)に、通常の取引系データ（黒伝）と、打ち消し用取引系データ（赤伝）なる2種類を用意しておき、アプリ側では、赤伝が存在する場合は、黒伝がないものとして扱うようにする。など。 ただ、ただ、大量データを扱うバッチの場合は実現方法にもう一工夫必要となりそうな気がする。 また、正方向のトランザクションと、補償トランザクションの時間差も重要。Webサービスとの絡みで論じられるロングトランザクションは、純粋なトランザクションの観点では同様であるけれども、オンラインバッチの補償トランザクションとは、時間がカナリ異なる。 これらの意味で、当日の議論は若干ずれていた気がする。その場では、理解した気になっていたのですが。すまぬ。＞皆様

バッチでキャッシュは怖い

よねー。やっぱり。

いろいろ

yyamanoさんのPCの壁紙がカッコイイ。（覗き見したった。） 議論の参加者が増えていい感じ。

整理も必要かもと、ちょっとおもったが、ドメインモデルのあたりの話は複雑すぎて、参戦できず・・・。実装センスが弱いな。＞俺

感謝

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

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

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

出席&発表してきた。

発表資料はこちら

WOMeeting発表資料 WOMeeting200508 - WOWiki

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

August 27th, 2005 | Tags: WebObjects | Category: Event, WebObjects | Leave a comment

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

EJB 3.0

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

Next Generation J2EE Deployment

気になったとこだけ。

データアクセスレイヤ～ビジネスロジックレイヤをつなぐデータ構造（モデル）としてドメインモデルを、ビジネスロジックレイヤ～ビジネスロジックレイヤをつなぐデータ構造（モデル）としてプレゼンテーションモデルを利用する。

誤解を恐れずにいうと、

ドメインモデルはデータベースのテーブル構造に比較的近い構造のJavaクラスモデルとなる。 プレゼンテーションモデルは、データベースのビューに近い構造のJavaクラスモデルとなる。

かなり乱暴なものいいです。

ドメインモデルとプレゼンテーションモデルの変換は、ビジネスロジックレイヤの背後にいるDxo（ダックスオー）が実行する。 ドメインモデルの構造として、テーブル構造に比較的近い構造を使用する理由は、Persistence APIの存在があるため ドメインモデルはJavaクラスのデータ構造に関する。PofEAAのドメインロジックパターンと混同せぬよう。後者は、ロジックの割り当てに関する。 EJB3 or Seasar2の選択は、開発元の文化によると思われる。

標準化を重視するかどうか。とか。

テスティング話

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

August 21st, 2005 | Category: Event, Java | Leave a comment

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

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

セッションステート

レコードデータとサーバセッション

セッションステートをRDBに書き出したレコードはレコードデータではない。 publicかつpersistentなデータがレコードデータであると理解した。

文中の「データベースとサーバセッションの中間の位置」とは何か？

中間の位置ではなく、中間の特性（？）ということみたい。 「位置」なる訳は、かなりグレー。

セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。

具体的には・・・ セッションに格納するデータ量の大小、セッションの維持時間 セッションに格納するデータ量が多い場合→ アフィニティ? セッションの維持時間短い場合→ アフィニティ?

（セッションアフィニティに関連して）ロードバランシングについて・・・

書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロード バランシングが実現できる。 書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。

DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。

Session Stateとパフォーマンス

ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？ ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。

PHPにはセッション情報をインメモリに持つ手段が無い。

スクリプト起動のモデルがCGI的である故 デフォルトで、セッション情報はファイルに格納する RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。

Rails

セッションID?セッションステート?の保存先としてメモリ、DB、ファイルが選択可能 フレームワークレベルでのクラスタリングの考慮は特に無い。

用語「MySQLセッションステート」

PHPな人はステート情報でもなんでもMySQLに格納するに格納する様をさした言葉みたい。データの特性に応じてインメモリテーブル、ディスク上のテーブルなどを使い分ける。 上記に関連して・・・、 はてなのMySQL使用方法

検索用DBサーバ、INSERT用DBサーバが別 DBフォレスト前段にキャッシュサーバが大量に・・・

最近は、サーバアフィニティで設計するケースが多いかも。

サーバはめったに壊れないし。

AJAXならば、サーバ側で状態を保持しなくてもOK(らしい。WR：よく理解できず・・・)

ただし、システム全体をAJAXだけで構築することは一般的でないため、結局、サーバ側でもログイン情報を持つことになる。

典型的な事例：ファイルのダウンロード（サーブレットなどを用いて実装するのが一般的）

分散ストラテジー

パフォーマンス比較

別プロセス vs 別ノードで、あまり差異が無いのでは？ （ある参加者が昔測定した結果）同一プロセス：別プロセス：別ノード ＝ １：？（ききそびれ・・・）：数千、数万倍オーダー CORBAにおける、別プロセス：別ノードの比較 → 別プロセス：別ノード＝１：１０程度

考察：OSがループバック通信の最適化がしている可能性がある。 UNIXドメインを使うともっと速い（Solaris2.4 では、共有メモリで実装している。速いことが期待できる） また、Windowsの場合、同一ノード内別プロセス通信 → Local RPC で通信 ⇒速い！

EJB1.4とWebサービス

コーディングレスでWebサービス化可能

発刊時点ではEJB1.4は存在しない。

CORBAにも類似の仕組み(IIOP over HTTP)が存在するが、Webサービスというわけではない。over HTTPなだけ。 XML Webサービスのパフォーマンス

RPCに比べると2,3桁違う Apache XML-RPCと比較してもWebサービスは1,2桁遅い やっぱりRMIは圧倒的に速い

理由のひとつ：ソケットのキープアライブをする。 これだけでも5倍ぐらい差が出るはず。

DTO:ローカルとリモートの2つあることに注意！

ファウラーは、リモートDTOのみをDTOと読んでいるかも。（狭義の/J2EEパターンの文脈におけるDTO？）

オンライン型バッチ処理

書籍所有者は2名だけ。orz. ま、しょうがないか。 30分弱で10スライド進んだ。

あと33スライド(笑)

APPサーバ～DBサーバ間NWラウンドトリップ回数削減のtips

SQLステートメントのセミコロンつなぎ JDBC batchUpdate (ひがさんのコメントの内容を忘れた・・・）

一旦リストアしてリラン pattern

いったんリストアしてリランなんて、60’sのテクニックだぜ！ 単にリランしても無駄なケースが多いのでは？

バッチ失敗の原因はデータ不備。よって、投入データorマスタデータの修正後にリランするのが常套手段と思われる。

とすると、夜間張り付いている人が必要だよね？

バッチリランのため、外部からログイン可能/状態チェック可能な経路/手段を設けておいたケースあり

ミニバッチ pattern

読み取り一貫性問題： みんなあまりピンと来てないみたいなので、次回もうすこしブレークダウンして・・・ ミニバッチの並列実行： 並列実行を想定して物理設計しないと（Oracleパーティション&ディスク構成とか？）。無闇に並列化してもNG

そもそも、オンライン型バッチの必要性って？

システムの全サービスをインサービス状態のままでバッチを実行するのではなく、バッチ実行が影響する特定のサービスをアウトオブサービス状態とするのが一般的では？

システム要件的に許されるならば、それが（コスト的に）一番かも。

「エンタープライズシステムはバッチでしょう！」ということなので、次回も地味に頑張ります。

その他

この人数になってしまうと、さすがにハンドル名と顔を一致させるのはムリ。

名札の導入に期待！

懇親会は1hほどで退散 ⇒ 友人のLive@三宿へ。

July 31st, 2005 | Category: Event, Programming | Leave a comment

行ってきた。

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」という概念も理解してもらえたようだし、よかったのではないでしょうか。うんうん。と自画自賛。

飲み会

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

July 30th, 2005 | Tags: WebObjects | Category: Event, WebObjects | Leave a comment

参加させていただいた。

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

内容は、髪をばっさりと夏仕様にしたひがさんによる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

後で書きます。

July 23rd, 2005 | Category: Event, Java, Programming | Comments (2)

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

トラブル（の一部）

ネタがかぶった・・・

バンド連中のネタは事前に把握していたのだけど、新郎職場の素人さんのネタがなかなか決まらず把握し切れなかった。そうしたら・・・・ネタがかぶった。orz. これだから素人はイヤなのよ。 →後輩の機転で、演出を変更し、ことなきを得た。

時間押しまくり・・・

出演時間を守らないバンド大杉！お前ら、15分って言ってあったらだろ？！ 幹事を泣かせるなと。 →時間的にスケーラブルにしてあったので、軽めの出し物を1つ削って対処

引き出物が違う！

会場の担当者から受け取ったダンボールの中身が、会場のロゴが入ったグラス。これが引き出物のはずはないし、そもそも、グラスをそのまま渡すなんてありえない！ → 会場の不手際でダンボール間違い。置き場から正しいダンボールを発掘した・・・が、その引き出物は仕込が必要なモノだったので人海戦術で対処、対処。つめつめ。仕込が必要ならその旨言ってくれないと・・・。

ギタートラブル！

ただでさえ押しているのに、ギタートラブルでさらに押し・・・・orz. → 片づけを超マッハでやることで対応

ビデオケーブルがない！

ビデオ出力が受けられると聞いたのでアップスキャンコンバータを後輩に手配してもらい、準備万端・・・のはずが、会場には1mのビデオケーブルしかなく、PA卓から客席まで届かない！我々がビデオ出力を使用するということは、前に伝えてあった筈。狭いPA卓に我々が入れない以上、それなりの長さのビデオケーブルがあってしかるべき。 → ビデオケーブル購入で対応

PAが遅刻

論外！約束の時間からかなり遅刻しやがってきた。ムカムカ。おかげでせっかく前倒しして入場したことによるゲインが相殺されてしまった。

ワイヤレスマイク受信機の出力が受けられず

出演者にキャノンでしか受けられないと念押ししていたのにかかわらず、出演者が持ってきたワイヤレス受信機はフォーン出し・・・orz. → 変換ケーブルを買ってくるように依頼・・・したけど最終的な対処方法は不明。なんとかなったらしい。 （つーか、会場にキャノン←→フォーンの変換ケーブルが無いのが大問題なわけだが）

ありがと。

コレだけのトラブルに対処できた理由は、あらかじめ計画を立てて、役割を委譲していたため。 ビデオ担当、オープニング・エンディング担当、司会などもろもろ。

ただ、もちろん、役割を担当してくれた先輩・後輩連中の助けが無くては、うまく行かなかったことは明らか。心から感謝します。ありがと。

July 10th, 2005 | Category: Event, Music | Comments (2)