面白い。
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を、厳密な意味での「データモデル」として捕らえたものではない。逆の立場をとっている。（モデルとして）全くの構造を持たないテキストデータに対して、制約を加えたものという立場をとる。まさにボヘミアン。
June 27th, 2005 | Category: RelationalModeling, XML | Leave a comment
行ってきた&発表してきた。
PofEAA Chap5. Concurrency
ogijunさんのサマリをベースに。
ひがさんとkoichikさんによる（豪華な！）レクチャー風景を見物できて、こっそり満足（笑）。
見た目的に面白く感じたので、携帯のカメラで撮影してしまった。（笑）。
話題に上った分離レベルの話について、詳細に知りたければ
別の書籍にあたるのが良いと思う。分離レベル程度ならば、いくらでも良い解説は読める。
もう少し具体的なレベルで知りたいならば、RDBMS固有の振る舞いに振れた書籍にあたるのが良い。
SQL Serverの場合は、.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”がなかなかよい。
そして、Oracleの場合は、
がわかりやすいのでオススメ。（これ以外の書籍がNGというわけではサラサラ無いです。自分が所有している書籍の中では。という意味）
自分の発表： 複雑なトランザクション 1/2
自分の発表のネタは、
の第3部の複雑なトランザクションをサマリ化したもの。これの内容をベースにいろいろ議論した。
時間の関係もあり全部はプレゼン&議論できなかった。 今回扱うことができたのは・・・
- 8章. 対話型トランザクション処理の設計方法
- 対話型トランザクション処理とは
- 業務排他制御による対話型トランザクション処理の設計方法
- 楽観同時実行制御による対話型トランザクション処理の設計方法
- 9章. 複雑なトランザクション制御
- 複雑なトランザクション制御とは
- ネットワーク障害時のメッセージロスト対策
まで。
記憶している範囲で・・・
論点となったのは
- ロックの方式
- 楽観的同時実行制御における「残念！」は、ユーザーに嫌がられる可能性アリ
- 在庫引き当ての場合など厳密なモノの管理が求められるケースだと、ここで提示した方法＋αが求められるだろう。
- 楽観的同時実行制御の実現方式であるtimestamp方式は、サーバ時刻ズレなどの問題をはらむ。versionNoが一番ツブシが効く。
- 二重submit防止とロギング
- ビューに対するモデルを、永続化しておき、過去の画面（＝ビュー）を再現できることを求められたケースアリ
- (類似例として?) モデルをXML化しておいたが、予想以上にサイズが大きくなりいろいろ苦労した。
- (WebObjects屋的には) ブラウザ戻る対策が主目的であるが、pageCacheとしてメモリ上にレンダリング後の画面データを持つ仕組みが存在している
来月もやります。
残りは・・・
- 9章. 複雑なトランザクション制御
- オンライン型長時間バッチ処理
- トランザクションマネージャと連携できないリソースマネージャを含む短時間トランザクション
- キュー型トランザクション
です。
ここらへんのテーマが気になる人は、第5回PoEAAに参加するか・・・・
をボチっとやっちゃってください。イイ本ですよ。これ。
2005/06/28: 追記
「ネットワーク障害時のメッセージロスト対策」のどこが複雑なトランザクションなの？
という問いに対してイマイチな回答をしてしまったので補足。
HTTPなどのメッセージ転送機構がReliableでなく、Tx配下で動作するRM的に動作できないためです。あの本では、機能を実現する全ての構成要素がReliableでないと「複雑なトランザクション」である。という定義なんです。
あと、2相ロックに関する、私とkoichikさんのやり取りで混乱されていた方いたら、ごめんなさい。
（当然といえば当然ですが）koichikさんの主張が正しいです。
私は（直列可能性を実現するロック方法である）2相ロックと、デッドロックしないロック方法（ロックを徐々に取るのではなく、一気にとる！）をごっちゃにしてました。スンマセン。
最後にkoichikさんにお願い。
クラス正規系(?)に触れているベージュの表紙の本の名称などを教えてください！という思いをこめて「お願いトラバ」！
ん？行かないな・・・。あれれ？
June 26th, 2005 | Category: Book, Event, IT | Comments (4)
欠席しちゃいました。
すんません。
June 25th, 2005 | Category: Event, WebObjects | Leave a comment
超オススメできる。
あとで書くかも。いや、（ビジネス的な視点に興味がある人なら）買いなさい。とりあえず。
June 19th, 2005 | Category: Book, Business, Think | Comments (2)
職場のやりとりの中で、オブジェクト指向を知らない上司にオブジェクト指向を説明する羽目になった。
たとえ話で説明したのだけど、なかなかうまくいったように思う。上司にも「わかりやすい！」と感謝してもらえ、かつマイmixi限定でやりとりを公開したら結構好評で、わたくしカナリゴキゲン（←アホ）なので、ここにもやり取りを残しておくことにする。うほ。
やりとり
上司「なんで継承構造が複雑だと問題なの？」
自分「（継承を駆使した(※)）オブジェクト指向設計のメリットは2つです。1つは、実作業者をある種のカタにはめられること。もう1つは、機能を共有できることです。」
（※: テンプレートメソッド的なイメージを持っていただければ。）
自分「たとえると、ビジネスフォームみたいなものです。たとえば、契約書とかで、本文には「甲が乙に・・・の義務を負う」みたいなヤツありますよね？
甲の部分を変えれば別の契約書になりますし、逆に言えば、ソコしか変えることが出来ないので、いわゆるカタにはめる格好になります。そして肝心の契約本文は共有できるので、契約を起こすたびに文面を考える必要はありません。継承を多用したオブジェクト指向設計っていうのは、こんな感じなんです。」
上司「ふーん、いいじゃない。」
自分「ですけど、問題点もあるんです。」
上司「何？」
自分「たいていの開発の場合、契約書テンプレートを作る人と、テンプレートを埋める人は別の人なんです。そして、継続してメンテナンスしないといけない。しかも、契約書の場合と異なり、両者は常に整合性をもっていないとイケないんです。
たとえば、法律の改正があって、契約書を修正しないといけないとしましょう。契約書の場合だと、テンプレートを修正して終わりですけど、ソフトウェア開発の場合だと、そうはいきません。現実の契約書テンプレートとは異なり、契約書テンプレートを修正すると、この契約書テンプレートを元にして作った契約書も全部修正されちゃうことになるんです。去年作った契約書も全部です。」
上司「あー」
自分「しかも、この(イケてない)協力会社がつくったソースの構造は複雑で、契約書にたとえると、契約書の本文に、「～の詳細については、・・・を参照」みたに契約書の構成が複雑で全貌を容易につかめないような感じなわけです。
これを将来的にメンテナンスしていくのは大変ですよ。」
上司「なるほどねー」
てな具合。
June 19th, 2005 | Category: ObjectModeling, Think | 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
たまゆら雑記：機能テストとは何か?
力作。面白い。
たしかに「機能」という用語は、結構意味的にいろいろあるね。
June 16th, 2005 | Category: IT | Leave a comment
うーむ。
解答を計算用紙にメモしなかったのは痛恨。
メモし忘れたことに試験終了時に気づいたので、
さりげなくキーとなる数値をメモ。
大原の模範解答と照らし合わせると、数値自体はあっているので、たぶん大丈夫かと。（思います・・・・・）
にしても、ケアレスミスの多さに我ながら困ったもんだと思ってしまう。事前勉強の中で問題を説く際にやらかしたミスのオンパレード。なにも本番でもやらかさなくても・・・と自己嫌悪。
- 0と6の見誤り
- 借方/貸方 転記ミス
- 繰越分を計算に入れてしまい、貸借があわねー！と焦る。
逆に言えば、チェックを可能とする仕組みが存在しているということである。簿記すばらし。
帰りに
啓文堂書店でストレス解消。
7つの習慣がらみとあっては。
問題発見型財務会計勉強方の流れで。
そろそろ真面目に勉強しようかと。
最近、異職能、異業種の仕事のやり方に興味があります。
June 12th, 2005 | Category: Accounting, Book | Leave a comment
面白い。自分のような皮肉屋にはもってこい。
1,500円の価値があるかといわれると・・・、好き嫌いが分かれそうなので一概には言えない。
ただ、単なる皮肉だけではないので、この本のストライクゾーンは結構広いのでは？と思っている。
June 12th, 2005 | Category: Book, Business | Leave a comment
