WR blog

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

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)

いやー、内容の濃い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

参加させていただいた。

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

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

参加させていただいてきた。

時間ぎりぎりだったので、自転車を必死にこいで新宿南口から会場へ向かう。 汗びっしょり。結果5分ぐらいの遅刻。スンマセンでした。

JSF vs Struts

実際にベンダー系JSF実装(+IDE)を使用/試用されている現場の方々や、JSF実装であるmyfacesの実装と問題点について熟知されているひがさんのお話を聞けたのがとっても収穫。 ありがとうございました。

JUnit4の胎動

なんだかかわいらしいフォントだなぁ。と余計なことは置いておき。

t-wadaさんの発表。面白かったです。 アノテーションを駆使したJunit4の特徴と、プレゼンテーションの中でちらちらと披露されたt-wadaさんのテストに対する考え方や、テストをうまくやるためのノウハウ開示がとても有益でした。 中でも、テストのカテゴリ分けの必要性、TestSuite(Junit4ではなくなる可能性もあるらしい！）の必要性と、現在Greee/Redしかないテスト結果状態を細分化する必要性について興味を持った。

テストのカテゴリわけは、テスト数が膨大となると絶対的に必要でしょうね。

TestSuiteの必要性に関して、t-wadaさんはテスト時間を短縮するために必要とのこと。 テスト時間の短縮というと味気ないな・・・・現場感覚が伝わりにくい。違う。

よりAgileに、プログラミング→テスト→プログラミング→・・・なるサイクルをより円滑に進めるために、絶対的に必要なものだというニュアンスと思っている。 そういえば、t-wadaさんは、テスト対象クラス（ファイル）のタイムスタンプを元にテスト順序を決める、（何らかの手段でテストクラスに与えた）優先度を元にテスト順序を決めるアイディアなども披露してくれた。うーん、欲しいねぇ。

テスト結果状態を細分化とは、具体的には・・・・

@Ignoreアノテーションを付けたテストはYellowで表示される（これはJUnit4に実装されるようだ) (なんらかの手段で、)まだテストに通らないことが明らかであることが示されたテストがfailした場合、別の色(Orange? Blue, Red, Yellow以外の何か。第4の色)で表示される

とか。個人的には「第4の色(named by t-wada?)」が欲しい。とっても欲しい。

テストは書いたけれども、failすることが明らかであるテストがRedとなると、真のfail(failしないと思っていたのに、failしてしまった!)を見つけるのが難しくなる。

あ、あと、S2TestUnitを見ておかないとなぁ。と個人的なメモ。

2005/06/19:追記＞ t-wadaさん

「呼びかけ」にうまく反応できなくてごめんなさい。 K.Beck(?)の、「not union but intersection」の真意がよく掴めなくて・・・・。

つーか、わざわざ小難しい言い回しせんでも、「必要最小限の機能」といえばいい気がするぞ。> K.Beck

DIの本質

(ひがさんの考える)OCPとは端的に言えば、「修正をAdd-onlyで実現するもの」と理解した。 (全ての修正をadd-onlyで実現するのが望ましいという意味ではないです。)

S2 5.0?

いろいろと面白い話を聞かせていただいた。書いていいのかよくわからないので、とりあえず。

飲み会

ちょっとした用事があったのと、途中合流が難ししそうだったので、欠席させていただいた。

June 18th, 2005 | Category: Event, Java, Seasar | Leave a comment