社員マスタという不思議なエンティティ（第２回）
面白いです。
|
|||||
|
* XMLとスキーマ * PPL Summer School 2004 via 読書記録ChangeLog なんだか楽しそうなことが書いてありそうなんだけど、よくわからない・・・orz. とりあえず気になるところを引用しておく。 > スキーマと意味？ > スキーマは、文書の意味を規定しない > XML文書全体の集合の部分集合を規定しているだけ > DTDに適合する文書を扱うスタイルシート、ソフトウェア、人間の総体が意味を規定する スキーマは、世界中にあまたあるXML文書を、 * スキーマに合致したXML文書 * スキーマに合致しないXML文書 の2つに分類するだけ。 > 別の見解 > スキーマは，integerすら持たないXML文書を、型情報を備えたオブジェクトへと昇華させる > 効率は負ける > 誤ったレイヤリングである 「誤ったレイヤリング」の「こころ」はなんだろう？？？？ > スキーマの理論 よくわからない・・・が、楽しそう。キーワードだけ並べておく。 * 正規木文法 * 木オートマトン * 正規文法 * 文脈自由（列）文法 * Chomsky Hierarchy * 局所文法(local grammar) > 課題1: スキーマの汎用化と特殊化 > […] メインフレームとかは真面目に勉強しといたほうが良いかも via 読書記録ChageLog WOMeetingでのkawasakiさんのお話などを聴くと、 UNIX, Windows, IAアーキテクチャといった現状のIT基盤はイマイチ信用にかけると思わざるを得ない。IT基盤の究極の姿はメインフレーム的な機能・特性を持つものになるのかなと。 ちょっと勉強したい・・・が、どうやって？何のために？ ま、自身の技術的な興味はさておき、ユーザーのニーズにこたえるIT屋の立場にたって考えると、 キチンとしたIT基盤の上で仕事がしたい。とか思いませんか？ IT基盤がある程度の予見性をもった、信頼に足る基盤であるためには、メインフレーム的な基盤が必要であるように思える（素人なので話半分で・・・）。 とすると、いつかはメインフレーム的な基盤を使用することが一般的になるはず。 が、ここらへんの技術がコモディティ化してくるのは、一体いつになるんですかね・・・。 ユーザーがメインフレーム的な特性が実現できるよう、IT技術サプライヤに強く求めていくような構図ができないと、歩みはゆっくりにならざるを得ないでしょうね。 > 素人目で見ても仮想OSでは長い歴史のあるメインフレームOSの > 仮想OS機能を知るのが第一歩だと思いますが。 > もちろん一番気の毒なのは、UNIX系だけがOSだと思いこんでいる > 人たちによるOSの授業や、研究指導を受ける学生さんたち。 うーん、メインフレームと大学って、なんで相性が悪いんでしょうか・・・ 確かに大学（某旧帝大）時代のコンピュータ系の研究室って2パターンに分かれていたような気がします。 * *BSDマンセー * プロセッサアーキテクチャ(?) メインフレームはあまり扱ってなかったような気がします。なぜかUNIXが主流。 なんつーか、UNIXって一種のカウンターカルチャー的な部分を持つからそれが大学のカルチャーにマッチしたのかな？ PofEAA第五回読書会に参加してきた。 発表に関連した議論の内容を中心に、箇条書きでメモ。 ### セッションステート * レコードデータとサーバセッション * セッションステートをRDBに書き出したレコードはレコードデータではない。 * publicかつpersistentなデータがレコードデータであると理解した。 * 文中の「データベースとサーバセッションの中間の位置」とは何か？ * 中間の位置ではなく、中間の特性（？）ということみたい。 * 「位置」なる訳は、かなりグレー。 * セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。 * 具体的には・・・ セッションに格納するデータ量の大小、セッションの維持時間 * セッションに格納するデータ量が多い場合→ アフィニティ? * セッションの維持時間短い場合→ アフィニティ? * （セッションアフィニティに関連して）ロードバランシングについて・・・ * 書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロード バランシングが実現できる。 * 書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。 * DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。 * Session Stateとパフォーマンス * ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？ * ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。 * PHPにはセッション情報をインメモリに持つ手段が無い。 * スクリプト起動のモデルがCGI的である故 * デフォルトで、セッション情報はファイルに格納する * RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。 * […] 行ってきた。 ### 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の使い方を学習する事からはじめます（笑） をを！頑張ってください！ 参加させていただいた。 場所は秋葉原近くの某研究所さん（名前カードや、注意書きの配布など、キッチリした事前準備に驚きました。ありがとうございました！）でした。 内容は、髪をばっさりと夏仕様にしたひがさんによる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 後で書きます。 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 ビュローテープディスペンサー 正確にはIBMのサポートということになるんでしょうけど。 CtrlキーにSwapしているCapsLockキーの調子が悪くなってしまった。 キーカスタマイズツールでEmacsキーバインドにしている関係上、 Ctrlキーがキチンと押せないとカーソル移動すらままならず非常にストレスがたまる。 というわけで、IBMサポートにTELしてキーボードの取り寄せを依頼した。4営業日以内に到着するとのコトだ。送付先は都内だし、たぶん土曜日あたりに到着するんじゃないかな。 修理のためにPCを送付しなくて済む点は、本当にありがたい。 特に自分の場合、このX31に仕事とプライベートの両面でフル活用しているため、 X31がないと生活全般に支障をきたしてしまう。 やっぱりThinkPadですよ！ということで、当分浮気できそうにないな。やっぱり安心。 |
|||||
|
Copyright © 2026 WR blog - All Rights Reserved Powered by WordPress & Atahualpa |
|||||