WR blog

メインフレームとかは真面目に勉強しといたほうが良いかも

via 読書記録ChageLog

WOMeetingでのkawasakiさんのお話などを聴くと、
UNIX, Windows, IAアーキテクチャといった現状のIT基盤はイマイチ信用にかけると思わざるを得ない。IT基盤の究極の姿はメインフレーム的な機能・特性を持つものになるのかなと。

ちょっと勉強したい・・・が、どうやって？何のために？

ま、自身の技術的な興味はさておき、ユーザーのニーズにこたえるIT屋の立場にたって考えると、
キチンとしたIT基盤の上で仕事がしたい。とか思いませんか？

IT基盤がある程度の予見性をもった、信頼に足る基盤であるためには、メインフレーム的な基盤が必要であるように思える（素人なので話半分で・・・）。
とすると、いつかはメインフレーム的な基盤を使用することが一般的になるはず。
が、ここらへんの技術がコモディティ化してくるのは、一体いつになるんですかね・・・。
ユーザーがメインフレーム的な特性が実現できるよう、IT技術サプライヤに強く求めていくような構図ができないと、歩みはゆっくりにならざるを得ないでしょうね。

> 素人目で見ても仮想OSでは長い歴史のあるメインフレームOSの
> 仮想OS機能を知るのが第一歩だと思いますが。
> もちろん一番気の毒なのは、UNIX系だけがOSだと思いこんでいる
> 人たちによるOSの授業や、研究指導を受ける学生さんたち。

うーん、メインフレームと大学って、なんで相性が悪いんでしょうか・・・
確かに大学（某旧帝大）時代のコンピュータ系の研究室って2パターンに分かれていたような気がします。

* *BSDマンセー
* プロセッサアーキテクチャ(?)

メインフレームはあまり扱ってなかったような気がします。なぜかUNIXが主流。
なんつーか、UNIXって一種のカウンターカルチャー的な部分を持つからそれが大学のカルチャーにマッチしたのかな？

PofEAA 5th

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@三宿へ。

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

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

印刷屋のdeveloper日記 – お手伝いさせていただきます

> S2Cayenneの開発をお手伝いする事になりました。
> さしあたりSVNの使い方を学習する事からはじめます（笑）

をを！頑張ってください！

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

後で書きます。

NOKIA/Vodafone 702NK

702NKに機種変更したので、あわせてこの本も購入した。

なんだかんだあって、ほとんど使い込めていないのだけど以下のようなことができるらしい。

* Outlookとの同期
* Web閲覧
* POP/IMAPメールアクセス
* Bluetoothアクセス
* PC用モデムとして

うむ、PCカードかCFカード型のBluetoothカードがあれば、コードレスでOutlook同期/携帯経由のインターネットアクセスができるのはいいかも。欲しいなぁ。と。

物欲スパーク。

ボーナスも出たし、先輩の二次会も先週で片付いたので、満を持してスパークさせてみた。

* NOKIAのスマートフォン： Vodafone 702NK
* Logitec 耐衝撃ボディ採用バスパワー対応ポータブルタイプ USB 2.0 外付型HDユニット – 40G/シルバー
* BUFFALO USB2.0/USB1.1対応ハードディスク – 250GB
* Delfonics 革製キーホルダー
* Delfonics ビュロークリップケース
* Delfonics A4 6ポケットファイル
* Delfonics ビュローテープディスペンサー

やっぱりThinkPadのサポートはイイ！？

正確にはIBMのサポートということになるんでしょうけど。

CtrlキーにSwapしているCapsLockキーの調子が悪くなってしまった。
キーカスタマイズツールでEmacsキーバインドにしている関係上、
Ctrlキーがキチンと押せないとカーソル移動すらままならず非常にストレスがたまる。

というわけで、IBMサポートにTELしてキーボードの取り寄せを依頼した。4営業日以内に到着するとのコトだ。送付先は都内だし、たぶん土曜日あたりに到着するんじゃないかな。

修理のためにPCを送付しなくて済む点は、本当にありがたい。
特に自分の場合、このX31に仕事とプライベートの両面でフル活用しているため、
X31がないと生活全般に支障をきたしてしまう。

やっぱりThinkPadですよ！ということで、当分浮気できそうにないな。やっぱり安心。

オブジェクト指向システム分析到着・・・

koichikさんのコメント : Csus4.net – Just example. ≫ Blog Archive ≫ PoEAA 4th
により書名を教えてたいただき、早速購入したのですが・・・・・

む、むずいっす・・・・。
付録AのOSAの形式的定義の構成を抜粋します・・・。

* A.1 ORMから第一階述語と規則への写像
* A.1.1 述語
* A.1.2 規則
* A.2 第一階言語から数学的モデルへの写像
* A.3 OSAメタモデル
* A.3.1 図A.4における最初の制約の変換
* A.3.2 図A.4における二つ目の制約の変換
* A.3.3 図A.4における三つ目の制約の変換
* A.3.4 図A.4における四つ目の制約の変換

なかなか手ごわそうです・・・オブジェクト指向システム開発―分析・設計・プログラミングへの実践的アプローチ

簿記3級

家に着いたらポストに封筒が・・・
6月に受けた日商簿記3級の合格通知でした！わーい。

とすると、次は2級か？どうしようかなぁ。

渡辺幸三さんのblog、
設計者の発言: 失業・転職は「簿記」習得の大チャンスによると・・・
> ただし、資格の取得については慎重に考えたほうがいい。簿記学校のコースはたいてい資格取得を目指しているが、日商簿記ならば２級までを取る必要はないと筆者は考える。３級は試験としては難しくないので受けたらいいと思うが、２級になると科目が「商業簿記」と「工業簿記」とに分かれて量も多く内容も高度になる。これに合格するには、本来の勉強の他に独特な「合格するためのテクニック」を磨く必要があって、いたずらに時間がかかる。そういうことに時間をかけるくらいなら、ソフト技術者としてはそれこそ「最近話題の実装技術」や「次のプログラミング言語」を学ぶほうがよほど実際的だと思う。

とあり、2級向けの講座を受講すること・勉強することは有意義だけど、2級に向けた試験勉強をすることはちょっと・・・ということみたいである。ただ、締め切り的なモノがないと、やらないからなぁ・・・。悩みますね。どーしようか。