WR blog

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

参加させていただいた。

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

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

伝説のプログラマ、カトラー氏はなお健在だった - So what is IT? [ITmedia オルタナティブ・ブログ]

私：「私はその昔、デビット・カトラーさんにインタビューしたことがあるんです」 K氏：「へぇ、そうでしたか」 私：「13年も前の話です。カトラーさんはもうMicrosoftにはいらっしゃいませんよね？」 K氏：「とんでもない。今でも現役のプログラマとして、64bit Windowsのコアをゴリゴリと開発していますよ」

すごすぎる。まぁ、私の隣の席の人も、負けずに一生コードを書いてそうな勢いだが・・・。

July 13th, 2005 | Category: Life, Programming | Leave a comment

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

時間ぎりぎりだったので、自転車を必死にこいで新宿南口から会場へ向かう。 汗びっしょり。結果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