WR blog

一生一プログラマ。

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

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

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

先輩の2次会終了・・・ほっとした。

大学時代の大先輩の2次会の幹事をおおせつかったので、ここ3週間はいろいろとバタバタしていた。
先週末の日曜日に、その2次会が無事終了。綱渡りのような、トラブル続きの2次会だったので、無事に終えることができてカナリほっとしている。

### トラブル（の一部）

* ネタがかぶった・・・
* バンド連中のネタは事前に把握していたのだけど、新郎職場の素人さんのネタがなかなか決まらず把握し切れなかった。そうしたら・・・・ネタがかぶった。orz. これだから素人はイヤなのよ。
* →後輩の機転で、演出を変更し、ことなきを得た。
* 時間押しまくり・・・
* 出演時間を守らないバンド大杉！お前ら、15分って言ってあったらだろ？！幹事を泣かせるなと。
* →時間的にスケーラブルにしてあったので、軽めの出し物を1つ削って対処
* 引き出物が違う！
* 会場の担当者から受け取ったダンボールの中身が、会場のロゴが入ったグラス。これが引き出物のはずはないし、そもそも、グラスをそのまま渡すなんてありえない！
* → 会場の不手際でダンボール間違い。置き場から正しいダンボールを発掘した・・・が、その引き出物は仕込が必要なモノだったので人海戦術で対処、対処。つめつめ。仕込が必要ならその旨言ってくれないと・・・。
* ギタートラブル！
* ただでさえ押しているのに、ギタートラブルでさらに押し・・・・orz.
* → 片づけを超マッハでやることで対応
* ビデオケーブルがない！
* ビデオ出力が受けられると聞いたのでアップスキャンコンバータを後輩に手配してもらい、準備万端・・・のはずが、会場には1mのビデオケーブルしかなく、PA卓から客席まで届かない！我々がビデオ出力を使用するということは、前に伝えてあった筈。狭いPA卓に我々が入れない以上、それなりの長さのビデオケーブルがあってしかるべき。
* → ビデオケーブル購入で対応
* PAが遅刻
* 論外！約束の時間からかなり遅刻しやがってきた。ムカムカ。おかげでせっかく前倒しして入場したことによるゲインが相殺されてしまった。
* ワイヤレスマイク受信機の出力が受けられず
* 出演者にキャノンでしか受けられないと念押ししていたのにかかわらず、出演者が持ってきたワイヤレス受信機はフォーン出し・・・orz.
* → 変換ケーブルを買ってくるように依頼・・・したけど最終的な対処方法は不明。なんとかなったらしい。（つーか、会場にキャノン←→フォーンの変換ケーブルが無いのが大問題なわけだが）

### ありがと。

コレだけのトラブルに対処できた理由は、あらかじめ計画を立てて、役割を委譲していたため。
ビデオ担当、オープニング・エンディング担当、司会などもろもろ。

ただ、もちろん、役割を担当してくれた先輩・後輩連中の助けが無くては、うまく行かなかったことは明らか。心から感謝します。ありがと。

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

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

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

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

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

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

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

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章. 複雑なトランザクション制御
* 複雑なトランザクション制御とは
* ネットワーク障害時のメッセージロスト対策

まで。

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

* ロックの方式
* 楽観的同時実行制御における「残念！」は、ユーザーに嫌がられる可能性アリ
* 在庫引き当ての場合など厳密なモノの管理が求められるケースだと、ここで提示した方法＋αが求められるだろう。
* 会員限定とか、在庫をクラス分けするとかもあり。
* 楽観的同時実行制御の実現方式であるtimestamp方式は、サーバ時刻ズレなどの問題をはらむ。versionNoが一番ツブシが効く。
* 二重submit防止とロギング
* ビューに対するモデルを、永続化しておき、過去の画面（＝ビュー）を再現できることを求められたケースアリ
* (類似例として?) モデルをXML化しておいたが、予想以上にサイズが大きくなりいろいろ苦労した。
* (WebObjects屋的には) ブラウザ戻る対策が主目的であるが、pageCacheとしてメモリ上にレンダリング後の画面データを持つ仕組みが存在している

### 来月もやります。

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

残りは・・・

* 9章. 複雑なトランザクション制御
* オンライン型長時間バッチ処理
* トランザクションマネージャと連携できないリソースマネージャを含む短時間トランザクション
* キュー型トランザクション

です。

ここらへんのテーマが気になる人は、第5回PoEAAに参加するか・・・・

をボチっとやっちゃってください。イイ本ですよ。これ。

### 2005/06/28: 追記
> 「ネットワーク障害時のメッセージロスト対策」のどこが複雑なトランザクションなの？

という問いに対してイマイチな回答をしてしまったので補足。
HTTPなどのメッセージ転送機構がReliableでなく、Tx配下で動作するRM的に動作できないためです。あの本では、機能を実現する全ての構成要素がReliableでないと「複雑なトランザクション」である。という定義なんです。

あと、2相ロックに関する、私とkoichikさんのやり取りで混乱されていた方いたら、ごめんなさい。
（当然といえば当然ですが）koichikさんの主張が正しいです。
私は（直列可能性を実現するロック方法である）2相ロックと、デッドロックしないロック方法（ロックを徐々に取るのではなく、一気にとる！）をごっちゃにしてました。スンマセン。

最後にkoichikさんにお願い。
クラス正規系(?)に触れている*ベージュの表紙の本*の名称などを教えてください！という思いをこめて「お願いトラバ」！

—-

ん？行かないな・・・。あれれ？

WOMeeting欠席

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

WebObjectsのやたらと詳しい解説

WebObjects – Wikipedia, the free encyclopedia

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

30歳からの成長戦略

超オススメできる。

あとで書くかも。いや、（ビジネス的な視点に興味がある人なら）買いなさい。とりあえず。

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

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

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

### やりとり

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

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

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

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

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

上司「何？」

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

上司「あー」

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

上司「なるほどねー」

てな具合。