いやー、内容の濃い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
via 読書記録ChangeLog
なんだか楽しそうなことが書いてありそうなんだけど、よくわからない・・・orz.
とりあえず気になるところを引用しておく。
スキーマと意味？
- スキーマは、文書の意味を規定しない
> - XML文書全体の集合の部分集合を規定しているだけ
> - DTDに適合する文書を扱うスタイルシート、ソフトウェア、人間の総体が意味を規定する
スキーマは、世界中にあまたあるXML文書を、
- スキーマに合致したXML文書
- スキーマに合致しないXML文書
の2つに分類するだけ。
別の見解
- スキーマは，integerすら持たないXML文書を、型情報を備えたオブジェクトへと昇華させる
>
「誤ったレイヤリング」の「こころ」はなんだろう？？？？
スキーマの理論
よくわからない・・・が、楽しそう。キーワードだけ並べておく。
- 正規木文法
- 木オートマトン
- 正規文法
- 文脈自由（列）文法
- Chomsky Hierarchy
- 局所文法(local grammar)
課題1: スキーマの汎用化と特殊化
- 広い範囲の人が合意するスキーマは複雑すぎて作れない
>
狭い範囲の人が合意するスキーマは広範囲の情報交換には使えない
- UN/CEFACTやOASISで制定された人名（国際化）されたもの）とどう折り合いをつければいいのか？
双方向変換？
「広い範囲の人が合意するスキーマは複雑すぎて作れない」 うーむ・・・。
も読んでみる（否、眺めてみる）ことにする・・・とおもったら、403であくせすできんじゃんか！！！ばーかばーか ＞ 京都大
ケチ。
August 6th, 2005 | Category: XML | Leave a comment
メインフレームとかは真面目に勉強しといたほうが良いかも
via 読書記録ChageLog
WOMeetingでのkawasakiさんのお話などを聴くと、
UNIX, Windows, IAアーキテクチャといった現状のIT基盤はイマイチ信用にかけると思わざるを得ない。IT基盤の究極の姿はメインフレーム的な機能・特性を持つものになるのかなと。
ちょっと勉強したい・・・が、どうやって？何のために？
ま、自身の技術的な興味はさておき、ユーザーのニーズにこたえるIT屋の立場にたって考えると、
キチンとしたIT基盤の上で仕事がしたい。とか思いませんか？
IT基盤がある程度の予見性をもった、信頼に足る基盤であるためには、メインフレーム的な基盤が必要であるように思える（素人なので話半分で・・・）。
とすると、いつかはメインフレーム的な基盤を使用することが一般的になるはず。
が、ここらへんの技術がコモディティ化してくるのは、一体いつになるんですかね・・・。
ユーザーがメインフレーム的な特性が実現できるよう、IT技術サプライヤに強く求めていくような構図ができないと、歩みはゆっくりにならざるを得ないでしょうね。
素人目で見ても仮想OSでは長い歴史のあるメインフレームOSの
仮想OS機能を知るのが第一歩だと思いますが。
もちろん一番気の毒なのは、UNIX系だけがOSだと思いこんでいる
人たちによるOSの授業や、研究指導を受ける学生さんたち。
うーん、メインフレームと大学って、なんで相性が悪いんでしょうか・・・
確かに大学（某旧帝大）時代のコンピュータ系の研究室って2パターンに分かれていたような気がします。
メインフレームはあまり扱ってなかったような気がします。なぜかUNIXが主流。
なんつーか、UNIXって一種のカウンターカルチャー的な部分を持つからそれが大学のカルチャーにマッチしたのかな？
August 6th, 2005 | Category: Infrastructure | 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サービス
- 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スライド進んだ。
- 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
印刷屋のdeveloper日記 - お手伝いさせていただきます
S2Cayenneの開発をお手伝いする事になりました。
さしあたりSVNの使い方を学習する事からはじめます（笑）
をを！頑張ってください！
July 29th, 2005 | Category: Seasar | Leave a comment
参加させていただいた。
場所は秋葉原近くの某研究所さん（名前カードや、注意書きの配布など、キッチリした事前準備に驚きました。ありがとうございました！）でした。
内容は、髪をばっさりと夏仕様にしたひがさんによるJSF(myfaces, s2jsf)のソースコードの追い方講座と、t-wadaさんによるTDDをめぐる混乱について。
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)
702NKに機種変更したので、あわせてこの本も購入した。
なんだかんだあって、ほとんど使い込めていないのだけど以下のようなことができるらしい。
- Outlookとの同期
- Web閲覧
- POP/IMAPメールアクセス
- Bluetoothアクセス
- PC用モデムとして
うむ、PCカードかCFカード型のBluetoothカードがあれば、コードレスでOutlook同期/携帯経由のインターネットアクセスができるのはいいかも。欲しいなぁ。と。
July 18th, 2005 | Category: Uncategorized | Leave a comment
ボーナスも出たし、先輩の二次会も先週で片付いたので、満を持してスパークさせてみた。
July 17th, 2005 | Category: Uncategorized | Leave a comment
