レガシーアプリケーション，だと...

O/R マッパーについて，改めて調べようと，"Hibernate in Action" (Bauer, 2005)¹ を拾い読みしていて，行き当たった記述です．

Java アプリケーションが他のレガシーアプリケーションとデータベースのアクセスを共有するケースは多い．この場合，トランザクションスコープキャッシュを超えるどんな種類のキャッシュも利用すべきでない．なぜなら，キャッシュシステムにはレガシーアプリケーションがいつ共有されたデータを更新したかについて検知する方法がないからだ．

(Bauer, 2005, p.222)

ここでいう，「レガシーアプリケーション」とは， Hibernate を使用しない，あらゆるアプリケーションであり， Hibernate を利用できない，あらゆる開発言語のことですよね．

FORTRAN， COBOL はもちろん， C/C++ も含むと．さらに， Perl, Python, Ruby, PHP であるとか， Haskell, Eralng といった，開発言語も含まれているわけです．

Java と ．NET に限定される，と言った方が早いですね．

NHibernate for .NET

この NHibernate とやらは， Java の Hibernate とキャッシュの同期をやるのですかね． .NET CLR 上で動作するとすると， Java VM とは別プロセスで動くはずで，そうすると，キャッシュの同期をやるには，プロセス間通信（クラスタリング）が必要になるはず．

2005 年に発行された本の内容ですので，今は違うのかもしれませんけど．でも，データベース側の変更を検知して，キャッシュのコントロールをしている，となると，それはそれで，アプリに無駄な複雑さを持ち込んでいる感じはあります．

キャッシュはデータベースへのアクセスを避けるために，次のような場合に試みられる．

● アプリケーションが識別子（主キー）によるルックアップを実行する．

● 永続化レイヤが関連を遅延して解決する．

クエリの結果をキャッシュすることも可能である．しかし，７章で論じるようにクエリ結果のキャッシュがパフォーマンスに与える影響はほとんどの場合わずかである．したがって，この機能の利用頻度は低いものである．

(Bauer, 2005, p.218)

O/R マッパーの発行する SQL のパフォーマンスが低いから，それを緩和するために，メモリへのキャッシュが必要，といっているようにしか読めませんね．

駄目な技術を何とか使えるように，あれこれと手立てを講じているように思えるのは気のせいか？

何か， RAID (Redundant Array of Inexpensive Disks) のパリティ方式，RAID2 -> RAID3 -> RAID4 -> RAID5 -> RAID6 を彷彿させますね．

---

1. Christian Bauer, Gavin King. "Hibernate in Action". Manning Publications, 2005. 倉橋 央, 勝嶌 和彦. "Hibernate イン アクション". ソフトバンク クリエイティブ， 2006.

the N+1 Schema Problem

Lambda the Ultimate の以下の記事より．

Why Normalization Failed to Become the Ultimate Guide for Database Designers? , Lambda the Ultimate

以下，引用．日本語は拙訳．

In my experience, nothing seems to effect lines of code in an enterprise system more than schema design, both in the data layer and logic layer, and often an inverse relationship exists between the two; hence the use of object-relational mapping layers to consolidate inevitable problems where there will be The Many Forms of a Single Fact (Kent, 1988).

私の経験上，データベース・スキーマ設計以上に，企業システムのコード量を左右するものはないと思える．これは，データ層，ロジック層の両方についていえる．また，しばしば両者の関係は逆転する．そして，object-relational マッピング層（ O/R マッピング）の使用は， 単一事実の多くの形態の存在 (Kent, 1988) という，避けようのない問題を，確実にもたらすことになるだろう．

Mapping stabilizes the problem domain by labeling correspondances between all the possible unique structures.

O/R マッピングは，可能でありユニークな，あらゆるデータ構造群の関係，とされる問題領域を保ち続ける．¹

I refer to this among friends and coworkers as the N+1 Schema Problem, as there is generally 1 schema thought to be canonical, either extensionally or intensionally, and N other versions of that schema.

私と友人，同僚との間では，この問題を， the N+1 Schema Problem として言及している．すなわち，一般的に，数学的公理に則った（ canonical ）と考えられる， 1 つのスキーマがあるとき， - それが外延的であるか内包的であるかを問わず - 別にそのスキーマの N 個のバージョンが存在する．

・・・

O/R マッピングというのは，クラスのフィールドに対して，テーブル，およびクエリ結果のカラム（ relation の attribute ）を対応させるのが一般的だと思います．

O/R マッピングがこのように行なわれるとしますと，アプリケーション側からデータベースをみたとき，データベースは，クエリによって，新しいデータタイプを実行時に生み出していることになるわけでして．極端な話， SELECT 文のカラムリストが一つ違うだけで，異なるデータタイプが生み出されることになるんですよね．

マッピングがコンパイル時に行なわれるのだとすると，データベース・スキーマが持っている， relation データタイプの情報を，コンパイル前に，アプリケーション側のプログラミング言語にコピーすることになります．そして，そのコピーは大抵，改変を伴って行なわれます．つまり，アプリケーションごとに，データベース・データタイプの別バージョンコピーを持つことになります．

これが， object-relational 間のギャップがもたらす，より大きな，そして深刻な問題ではないかと考えます．

---

1. データベースの用語では，データ統合 data integration の問題．プログラミングの用語では， DRY (Don't repeat yourself )原則の問題かと思う．

詳細設計書の入力先は人間

Educators, generals, dieticians, psychologists, and parents program. Armies, students, and some societies are programmed.

Harold Abelson, Gerald Jay Sussman, Julie Sussman, "Structure and Interpretation of Computer Programs" Second Edition, (MIT Press, 1996)

詳細設計書の読み手は，あくまで人間であって，機械ではないわけですから，当然，曖昧さはあるでしょう．また，曖昧さがなければ意味がないとも言えます．

ひとまず詳細設計書には意味を与えるべきです。機械的実行が可能な表記法を定義し、それに則って記述するべきです。なんなら「詳細設計書を読み込んで実行するプログラム」があれば良いでしょう。

古き悪しき詳細設計書 - SiroKuro Page

事前条件，事後条件（，不変条件）を列挙して，機械に実行させる，というのは，宣言型プログラミング言語が目指すところであるわけでして．形式仕様記述言語¹というのは，そうしたものでしょう． そうした仕様記述から，機械で実行可能なプログラムを作り出すのであれば，詳細設計書を読んでコードを書く人間は不要になりますね．²

詳細設計書に擬似コードを載せる，ということにも，意味はあると思います．そのとおりに実装しろという指示ではなく，あくまで，仕様を理解するための一例とするなら．例えば，コード例がひとつも載っていない，言語仕様， API 仕様， アルゴリズム仕様を読んで理解できるのか，という話です．この場合，コード例が COBOL をベースにした擬似コードでも構わないと思います．

もちろん，仕様が正しいことを，設計者・プログラマの双方が確認できるように，事前条件，事後条件，不変条件を列挙したり，テストケース，テストデータといったものを用意する必要はあるでしょう．

詳細設計書の問題として語られているのは，実は詳細設計書の書き方の問題ではなく，工程が分断されていて，コミュニケーションが一方通行になってしまっている，という問題ではないでしょうか．

詳細設計書というものは，プログラマを「プログラムする」ためのドキュメントと考えます．そうしますと，詳細設計書を入力されたプログラマが，「コンパイル・エラー」をだす可能性は当然あるわけです．この場合，設計書を書いた人間にエラーを知らせて，設計書を修正させなければなりません．

詳細設計書をレビューするのに，最も適した人間は，それを読んでコードを書くプログラマです．プログラマがレビューし，設計書を書いた人間にフィードバックできないのであれば，その設計書の品質は，かなり低いものとならざるを得ないでしょうし，場合によっては無用の長物となるでしょう．

---

1. 例えば，VDM．　形式仕様記述から，C++ ，Java のコードを自動的に生成する機能がある．

2. SQL ，Prolog がそうであるように，宣言型プログラミング言語は，パフォーマンスの問題を無視できるには至っていない．従って，プログラマを「人間コンパイラ/オプティマイザ」として位置付けるのは，それはそれで一定の意味はある． RISC プロセッサと， C コンパイラが成し遂げたように，機械が自動生成するコードが，人間の書くコードにパフォーマンスで勝る，ということが，この抽象度のレベルで有り得るのかが問題．

日本の IT 産業はオープンになれなかった

かなり以前のことだが、日本のあるITコンサルティング会社の経営トップにこう聞かれた。私が答えに窮していると、その経営トップはズバリ言った。「ユーザー企業のレベルが低いからです」

なぜ、日本のIT産業は世界で勝てないのか？ - 記者の眼：ITpro

ユーザ企業のせいにするのは、八つ当たりというものだと思うわけですけど。

オープンシステムで、米国企業が圧倒的な優位に立ち、一方、日本企業がそうなれなかった理由というのは、一言でいえば、文化の違いじゃないですかね。

例えば、こんな話はどうでしょう。

．．．

日本の大手ハードウエア・メーカーから、 PC サーバ機を購入すると、”簡単セットアップ CD” みたいなやつと、日本語で懇切丁寧に書かれたマニュアルが付いてきます。

米国メーカーから購入すると、英語・中国語・日本語兼用の、ペラ一枚の ”Quick Start Guide" だけが付いてきます。

日本メーカーの PC サーバ機のカタログは、写真つき・色つきの豪華なもので、見た目が華やかです。今ですと、「仮想化対応」を高らかに謳っていたりします。が、サーバ筐体の中に、どのデバイス・メーカーのどの製品が使われているか、といった情報はどこにもありません。

米国メーカーのカタログは、白黒で非常にそっけなく、まんまスペック・シートであったりします。そのため、見た目は地味ですが、サーバ筐体の中に、どんなデバイス・メーカーのどの製品、どのチップ・セットが使われているか、事細かに書かれていたりします。

日本メーカーの PC サーバ機には、もちろん、有名海外メーカーのデバイス/チップセットが使われています。 しかし、デバイスのベンダー ID 、デバイス ID を、自社工場で書き換えていたりします。

米国メーカーの PC サーバ機は、供給元のデバイス・メーカーのベンダー ID 、デバイス ID 、そのままになっています。

．．．

こうしたことに気付いたのは、大手日本メーカー製の PC サーバに、自分で Linux OS をインストールしようとしたときでした。 型落ちの PC サーバ機があったので、開発用に使おうとしたのですけどね。で、見事にハマリましたとさ。

思うに、大手日本メーカーは、 PC サーバ機でも、顧客囲いこみで売る戦略なんですよね。メインフレームの売り方で PC サーバを売っているような感じです。

もちろん、これは日本のユーザ企業がそれを求めているからこそ、そうしているのだと思うわけですけど。日本のユーザ企業が、メーカーの「手厚いサポート」を求めているのも確かなわけで。米国メーカーみたいに、売った後は自分でなんとかしてくれ、みたいなのは、あまり好まれないように思います。

とはいえ、オープンシステムの文化というのは、まさに米国メーカーのそれ、 Do it yourself なんですよね。

オブジェクト指向分析設計は万能薬なのか

業務システムにオブジェクト指向は要らん発言とか。

企業の業務システム、といっても色々あるわけですけど、一般にその言葉が指していると思われる、販売管理、在庫管理、会計、といったシステムについて考えるとして。オブジェクト指向というのは、本当にそうした分野にフィットするものなのか、と思うのですよね。

こうした業務システムというのは、もともと企業の中を流通しているデータを扱っているわけで。そうしたデータというのは、それ自体が動作を持つものじゃなく、あくまで人間が解釈して情報として使うためにあるものだと思うわけです。例えば、「商品」、「売上」、「在庫」といったものを、オブジェクト指向のオブジェクトととらえても、それ自体に直感的に動作が付随してこない感じで、今ひとつだと思うわけです。

もともと、オブジェクト指向という概念が、シミュレーション・システムのプログラムに直感的な表現方法を与えるためのものだと考えますと。やはり、フィットする分野とフィットしない分野があるのではないですかね。

例えば、電子回路の設計、およびシミュレーションに使われている、 VHDL みたいなのは、オブジェクト指向に物凄くフィットしそう。電子回路を構成する素子というのは、それ自体が、状態と動作を持ちますから、オブジェクト指向で、直感的に表現できるものだと思うのです。

どんな技術にも、向き不向きというのはある、と思うのですよ。

以下、余談。

オブジェクト指向プログラミング言語については、一定の意味はあると思います。一番大きいのは、変数のスコープを、言語ユーザ自身で定義できるイディオムを手に入れたことじゃないですかね。

Lisp でいうところの、クロージャのような役割ですが、 クロージャと異なるのは、有限回しかスコープをネストできないこと。クロージャは再帰によって無限回ネストできますから。

この有限回しかスコープをネストさせない、というのが、オブジェクト指向プログラミング言語の本質に関わる部分なんじゃないかな。そう考えると、 Java にクロージャを持ち込むことに、 Java 言語のデザイナが頑強に反対している理由がわかるような。

PHP = SSI + Shell

仕事で PHP を使うことになってしまいました。使ってみた感想がタイトルです。

「SSI とは?」, Apache チュートリアル: Server Side Includes 入門

SSI の中で使える、 Shell スクリプトってところですね。

PHP という言語は色々言われているみたいですが、つまるところ、

過度な期待はしないでください

ということではないかと思います。

本の読み方を知らない新人さん

新人：「パラメータはコンフィグファイルに記述って仕様に書いてありました」

わたし：「それがどうしてレジストリにつながるの？」

新人：「コンフィグファイルを検索してたらレジストリというのが出てきて、それを理解できないとコンフィグファイルの操作方法が分からないのかと思って...」

プログラマで、生きている: ググるな危険

この話に出てくる「コンフィグファイル」というのは、 おそらく、 .NET Framework での 拡張子 .config のファイルのことなのだろうと推測します。 Windows アプリケーションの場合は app.config 、 Web アプリケーションの場合は web.config というファイルを使うことになっています。 Microsoft の用語では、 「構成ファイル」 になっていますね。

.NET Framework の構成ファイル スキーマ ( MSDN )

.NET には、バインディングと呼ばれる仕組みがありまして、 Visual Studio のデザイナでフォーム上に配置したコントロールのプロパティと、構成ファイルの XML 要素をマッピングしておくと、自動的にプロパティを読み書きしてくれる、という機能があるんですよね。 これは、フォームのコントロールに限らず、任意のオブジェクトのプロパティで使えます。

上の話は、新人さんに、 .NET の入門書と仕様書を渡して、作業を指示した、という話なのではないですかね。入門書には、 app.config 、 web.config の説明ぐらいはあったのではないかと思うのです。つまり、この新人さんは、読むようにと渡された、入門書を読んでいない、ということになりますね。渡された本を読まずに Google で検索していると。¹

入門書が読めない人に、プログラミングの仕事を教える、というのは、かなり厳しいと言わざるをえないですねえ。 Google がどうとか、受身だとか、そういうレベルじゃないと思います。 OJT で読書のやり方から教えるというのは、不可能でしょう。

学生時代、 1 冊も本を読まずに済ませてきたのだとすると、それはそれですごいですね。

---

1. .NET について調べるなら、 Google じゃなくて、 MSDN でしょうね。入門書を読めないレベルですと、 MSDN の資料を読むのは無理でしょうけど。

RDBMS の制約の使い方

制約というのは、一意性制約、参照整合性制約、チェック制約などのことです。

個人的には、 RDBMS の制約の典型的な使い方は、 トランザクションの並行実行によって発生する、競合状態 ( race condition ) の検出に使う、というものだと考えてまして。アプリケーション側で、レコード・ロックだの、テーブル・ロックだのやるくらいなら、 RDBMS に任せてしまうが良い、と考えています。

簡単なので、一意性制約の例を挙げますと。単に、テーブルに、値が重複してはならないフィールドの集まりがあるわけですな。

そうすると、2つ以上のトランザクションが、この制約を満たすために、テーブルに既に値があるかどうかを、 SELECT で確認して、それからレコードを INSERT するなり、 UPDATE するなりする、という状況が起きる。 いわゆる、 check-then-act な競合状態が起きるわけです。

ここで、アプリケーション側で RDBMS のロック機能を使って atomic にするというのは、あまりよろしくない。 RDBMS にこんな地雷を埋め込んでいると、新しくリリースされたアプリケーションが、同じ RDBMS を使って、デッド・ロック起こしたり、パフォーマンス障害を起こすのは時間の問題と考えて良いでしょう。

ですので、素直にテーブルのフィールドに一意性制約をつけて、 RDBMS に重複を検出させるのがよろしかろうと思います。 もちろん、アプリケーションのデータ・チェックで、重複回避のために値の存在確認はさせるべきです。RDBMS の制約は、あくまで競合状態の検出にのみ使います。

当然のことながら、 制約を安易に多用しますと、RDBMS 内でロックを多発させることになって、パフォーマンス劣化を引き起こします。 RDBMS の制約は、並行処理の設計の問題であって、単なる RDBMS の便利機能ではありません。アプリケーションのデータ・チェックの代用にはなりませんので、悪しからず。

制約違反が大量発生して RDBMS がとてつもなく遅くて困るって？

アプリケーションが、データ・チェックをさぼってないか、確認してください。本当にそれらの制約が必要なのか、もう一度よく検討してください。

もしそれが、競合状態の多発を意味しているのであれば、根本的にシステムの設計がまずい可能性があります。非同期にして直列処理することを考慮しましょう。ハードウエアのキャパシティ不足であるなら、ハードウエアの増強を検討しましょう。

ソフトウエアの「消費コスト」

というのか、何かそんな概念について。

「ソフトウェア工場はうまくいかないんですね。なぜなら部品の組み立てに相当するものが、アップロードとかDVDに焼くといった工程ぐらいしか存在せず、効率化しようないからです」。

「ソフトウェアは工業製品ではない」 Rubyのまつもと氏が講演 ＠IT

確かに、計算機プログラムの「製造」工程というのは、ソース・コードのビルドであり、サーバへのアップ・ロードであり、 CD/DVD への書き込みであったりして、製造コストは限りなくゼロに近い − 少なくとも「設計」にかかるコストに比べれば − とは思うのですが。

しかし、計算機プログラムには、「設計」以外にも大きなコストが存在すると思うのですよね。

例えば、計算機プログラムを音楽 CD のようなものと比較した場合、大きな違いがあって、それはユーザの「消費コスト」というのか、「使用コスト」のようなものの存在だと思います。つまり、計算機プログラムの入った CD を買ってきて、 PC の CD-ROM ドライブにセットして、「再生」ボタンを押せば、即座に「消費」可能 − ユーザがその製品の付加価値を得ることが出来る − かといえば、否なんですよね。

ユーザが計算機プログラムを入手してから、ユーザがそのソフトウエアの付加価値を享受するまでには、通常、長い道程があるわけです。何百ページだか何千ページだかあるマニュアルと格闘しつつ、ソフトウエアをインストールし、ソフトウエアの使い方を学び、様々な設定をほどこし、データを入力し、そして、ちょっとしたプログラムを書く必要があったりするわけです。

かくして、この大きな労力を必要とする仕事を、ユーザの代わりに行い、ユーザがソフトウエアを使えるような状態にまで持っていく（ターン・キー）、というビジネスが生まれたわけでして。いわゆる SIer と呼ばれる産業です。

こうした、ソフトウエア・ベンダー、ハードウエア・ベンダーから、ユーザまでの「ラスト・ワン・マイル」 − 現状はワン・マイルどころではなさそうに思いますが − を担当する仕事というのが、それなりに大きな産業として存在しているわけです。

そこで感じたのは、現場の科学者が「明日にでも計算したい問題を抱えている」ということは、観念として理解されることはあっても、実感としてはわかってもらえないらしいということであった。彼の答えは、逆に、私の専用機を作るという火に油を注ぐことになった。やはり、自分でやるしかないのである。

杉本大一郎, 『手作りコンピュータへの挑戦 テラ・フロップス・マシンをめざして』, 講談社 ブルーバックス B-956, 1993

上に引用したのは、かの GRAPE 計算機の開発話ですが。著者が、計算機メーカー、計算機科学者への愚痴（？）のようなものを書いています。それは、計算機メーカーや計算機科学者は、「汎用」の問題を解くことにばかり熱心で、科学者の抱えている個別の問題には関心を持ってくれない、といったことです。

これは、計算機ビジネスの構造的要因から来ていると思うのですよね。つまり、ソフトウエアにしろ、ハードウエアにしろ、ベンダーは可能な限り多くのユーザを獲得しなければならないわけでして（業界では「ユーザ・ベース」とかいってますね）。そうすると、システムは可能な限り「汎用」に作る必要が出てきます。特定の問題にフォーカスしても、それこそ、特定の少数のユーザしか得られませんからね。

しかし、「汎用」なシステムを、ユーザが自分の問題解決に使おうとすると、あれこれと自分で作業をする必要が出てくるわけです。このジレンマが解消する日が、いつかは来るのでしょうかね？

基本設計と見積もり

基本設計というのは、費用・工期を見積もることができるレベルの設計といいます。 が、なぜか IT システムの世界では、基本設計の前に顧客に見積もりが提出され、「一括請負契約」が締結される、という不可思議なことが行なわれていたりします。「一括請負契約」が締結された後で、基本設計作業に入ることになるんですよね。

プラント・エンジニアリング業の方が書いた、プロジェクト・マネジメントの本を読むと、基本設計作業と並行して契約交渉が行なわれ、基本設計完了後、競争入札等で、契約が締結される、などと書かれています。基本設計の費用は、全部ベンダーの営業経費になるのかしら、と少し疑問に思っていたのですが、以下の話を読む限り、基本的にはそういうことみたいですね。

見積が無償なのは、むろん日本だけのことではない。しかし、私は海外で、ある欧米系石油メジャーに対する見積業務に従事していたときの経験を覚えている。案件は競争入札だった。大型プラントの見積作業は、それ自体が億の単位の費用を要する。ところで、その顧客は、応札者に対して、「入札要求仕様書（基本設計書）のベリフィケーション費用」という名目で、かなりの金額を支払う約束をした。

それだけではない。経済状況の乱変動に伴って、見積期間中に顧客の要求事項もあれこれと変化して、ついていくのがひどく大変な状況になった。すると、入札締切の直前に、顧客はベリフィケーション費用を50% 増額する、と宣言し、そのとおり実行したのだ。この時以来、見積はいつでも無料であるべしという感覚が、自分の中から抜け落ちてしまった。

お見積りは無料です (タイム・コンサルタントの日誌から)

IT システム業界の場合、売り手と買い手の同床異夢になっているように思います。

買い手は、「見積もりは無料」だと思っているし、売り手もそう思わせている。しかし、基本設計どころか、要求定義もろくにおこなってないわけですから、その見積もりは、極めて粗悪な代物です。

売り手としては、買い手から早く現金を引き出したいものですから、粗悪な見積もりでも、とにかく契約を結んでしまおうとするわけです。工期は短ければ、短いほど良い。今期の売上ノルマに追加できますからね。

買い手からみた場合は、おそらく、早くベンダーに責任を「丸投げ」してしまいたい、というのがあるのでしょう。見積もりが粗悪であろうがなんであろうが、「一括請負契約」である以上、ベンダーは「最後まで」責任を負うはず、ほぼ無限責任に近い責任が生じるはずだ、というところですかね。

これは、実のところ、買い手の幻想にすぎず、「請負」の対象が明確に定まらなければ、つまり、基本設計が完了していなければ、請負契約は法的に成立しないわけでして。契約を結んだと思っていても、法的には契約は成立していない、という奇妙な状態となります。

このような不安定な関係で、仕事が曲りなりにも成り立つのは、売り手と買い手との間に、一定の信頼関係がある場合だけなのでしょう。結局、長期の取引関係を前提に、ということになります。実際、「一見さん」との取引は、 9 割くらいの確率でトラブルに発展しているような感がありますね。