IT « WR blog

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

後で書きます。

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

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における四つ目の制約の変換

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

一生一プログラマ。

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

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

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

会計システムのアーキテクチャ論 – 設計者の発言

制度会計ベースのアーキテクチャについて > まず、現在の主流である「制度会計に管理会計が寄生しているスタイル」というのは、「管理会計上の諸問題を仕訳に組み込んでしまう」というものだ。とりあえずすべての取引を１個ずつ仕訳して決算書を作ると同時に、仕訳データを集計して管理会計上の諸問題を管理しようとする。

管理会計ベースのアーキテクチャについて > いっぽうの「管理会計に制度会計が寄生しているスタイル」では、仕訳テーブルは単純な形をとる。このスタイルにおいて仕訳は、公告用の決算書を出力するためだけのネタなので、必要最小限度の項目さえ載っていればいいからだ。日々の活動はそれぞれの業務データ管理サブシステムによって管理されている。個々の取引毎に仕訳する必要はなく、月次でも、場合によっては四半期毎のサマリーデータからでも仕訳すればいいので、仕訳データ量もずっと少ない。期中の進捗については、仕訳データ経由ではなくそれぞれのサブシステムが保持する数字を直接集計して監視すればよい。システムは基本的に「管理会計システム」で、決算書出力機能が「オマケ」としてついているようなイメージだ。

簿記の枠組み、すなわち、汎用の枠組みに大して、業界・業種・企業に特化したデータを盛り込むようなアプローチには限界がある。そして、業界・業種・企業に特化したデータをベースに汎用のデータを生成するアプローチのほうが良いと理解した。

六の日記はここにはないぞ – 仕訳をいつ作るかなあと云う話

> 確かに仕訳中心で全てを従属させると大統一理論てな塩梅でとても愉快なんだけど、やっぱり計上→訂正→消込とかのフローに沿った部分は債務は債務、債権は債権で別管理にしておいて、仕訳は仕訳でその時々のスナップショットみたいな考えでパカパカ生成するのみにして、「どれに対する消込かって？債権側に聞けや」みたく人任せにする形が、良かったなァ、って設計した人と後から反省した。

の話にも通じるのかなっと。

Linuxは安くない。

Linux/これでいいのかLinux(仮) – 404 Not Found (FreeStyleWiki)

ふーん。納得できるかも。

XMLデータベース開発方法論

* ＠IT：XMLデータベース開発方法論（1） 1/4 * ＠IT：XMLデータベース開発方法論（1） 2/4 * ＠IT：XMLデータベース開発方法論（1） 3/4 * ＠IT：XMLデータベース開発方法論（1） 4/4

面白い。

from ＠IT：XMLデータベース開発方法論（1） 2/4 :

> RDBは「例外的な処理」との相性が悪いということである。きれいに正規化されたデータを扱っている限り、RDBは実に快適で、わずかな手間で素晴らしい成果をもたらしてくれる。しかし、そこから逸脱する例外的なデータや、例外的な処理が発生すると急に扱いにくくなる。そして、例外的なデータや例外的な処理は、多かれ少なかれ、どこかで要求に入り込んでくる。

（筆者を批判するわけでなく・・・）より正確に言えば、上記の批判（というか制約か・・・）はRDB特有のものではない。厳密な意味にでの「データモデル」を扱った場合に一般の問題といえると思う。

from ＠IT：XMLデータベース開発方法論（1） 3/4 : AWK、使い捨てデータ処理の切り札 > AWKによるデータ処理は、RDBによるデータ処理の対極に存在するといってよいだろう。RDBによるデータ処理は、専門家によって構築され、大量の定型化された情報を効率よく処理し、日常業務の中で数え切れないほど繰り返し長期にわたって使うことができる。しかし、AWKによるデータ処理は、ユーザー自身が記述し、少量の不定形の情報を効率は悪くとも必要十分な時間で処理し、使い捨てられる。

from ＠IT：XMLデータベース開発方法論（1） 4/4 : RDBとAWKの中間ポイントに位置するXML

> XMLとは、テキストでデータを記述するというAWK的テキスト処理の世界を継承しつつ、そこに要素や属性という構造を導入することで、自由を制約した言語であると見ることができる。自由の制約は、利用者がより少ない手間で成果を得られるようにするために導入される。しかし、自由の制約は最小限に抑えられ、RDBと同水準の高い秩序は要求していない。

筆者の立場は、XMLを、厳密な意味での「データモデル」として捕らえたものではない。逆の立場をとっている。（モデルとして）全くの構造を持たないテキストデータに対して、制約を加えたものという立場をとる。まさにボヘミアン。

PoEAA 4th

* PofEAA’s Wiki – PofEAA読書会第4回

行ってきた&発表してきた。

### PofEAA Chap5. Concurrency ogijunさんのサマリをベースに。

ひがさんとkoichikさんによる（豪華な！）レクチャー風景を見物できて、こっそり満足（笑）。見た目的に面白く感じたので、携帯のカメラで撮影してしまった。（笑）。

話題に上った分離レベルの話について、詳細に知りたければ別の書籍にあたるのが良いと思う。分離レベル程度ならば、いくらでも良い解説は読める。もう少し具体的なレベルで知りたいならば、RDBMS固有の振る舞いに振れた書籍にあたるのが良い。

SQL Serverの場合は、.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”がなかなかよい。

そして、Oracleの場合は、

がわかりやすいのでオススメ。（これ以外の書籍がNGというわけではサラサラ無いです。自分が所有している書籍の中では。という意味）

### 自分の発表：複雑なトランザクション 1/2

自分の発表のネタは、

の第3部の複雑なトランザクションをサマリ化したもの。これの内容をベースにいろいろ議論した。

時間の関係もあり全部はプレゼン&議論できなかった。今回扱うことができたのは・・・

* 8章. 対話型トランザクション処理の設計方法 * 対話型トランザクション処理とは * 業務排他制御による対話型トランザクション処理の設計方法 * 楽観同時実行制御による対話型トランザクション処理の設計方法 * 9章. 複雑なトランザクション制御 * 複雑なトランザクション制御とは * ネットワーク障害時のメッセージロスト対策

まで。

### 記憶している範囲で・・・論点となったのは

* ロックの方式 […]

WOMeeting欠席

欠席しちゃいました。すんません。

WebObjectsのやたらと詳しい解説

WebObjects – Wikipedia, the free encyclopedia

エライ頑張って書いてあるな・・・。

オブジェクト指向設計の説明

職場のやりとりの中で、オブジェクト指向を知らない上司にオブジェクト指向を説明する羽目になった。

たとえ話で説明したのだけど、なかなかうまくいったように思う。上司にも「わかりやすい！」と感謝してもらえ、かつマイmixi限定でやりとりを公開したら結構好評で、わたくしカナリゴキゲン（←アホ）なので、ここにもやり取りを残しておくことにする。うほ。

### やりとり

上司「なんで継承構造が複雑だと問題なの？」

自分「（継承を駆使した(※)）オブジェクト指向設計のメリットは2つです。1つは、実作業者をある種のカタにはめられること。もう1つは、機能を共有できることです。」（※: テンプレートメソッド的なイメージを持っていただければ。）

自分「たとえると、ビジネスフォームみたいなものです。たとえば、契約書とかで、本文には「甲が乙に・・・の義務を負う」みたいなヤツありますよね？甲の部分を変えれば別の契約書になりますし、逆に言えば、ソコしか変えることが出来ないので、いわゆるカタにはめる格好になります。そして肝心の契約本文は共有できるので、契約を起こすたびに文面を考える必要はありません。継承を多用したオブジェクト指向設計っていうのは、こんな感じなんです。」

上司「ふーん、いいじゃない。」

自分「ですけど、問題点もあるんです。」

上司「何？」

自分「たいていの開発の場合、契約書テンプレートを作る人と、テンプレートを埋める人は別の人なんです。そして、継続してメンテナンスしないといけない。しかも、契約書の場合と異なり、両者は常に整合性をもっていないとイケないんです。たとえば、法律の改正があって、契約書を修正しないといけないとしましょう。契約書の場合だと、テンプレートを修正して終わりですけど、ソフトウェア開発の場合だと、そうはいきません。現実の契約書テンプレートとは異なり、契約書テンプレートを修正すると、この契約書テンプレートを元にして作った契約書も全部修正されちゃうことになるんです。去年作った契約書も全部です。」

上司「あー」

自分「しかも、この(イケてない)協力会社がつくったソースの構造は複雑で、契約書にたとえると、契約書の本文に、「?の詳細については、・・・を参照」みたに契約書の構成が複雑で全貌を容易につかめないような感じなわけです。これを将来的にメンテナンスしていくのは大変ですよ。」

上司「なるほどねー」

てな具合。

WR blog

Recent Posts

Archives