knzm/gist:1556093

## gistfile1.txt
========================================
In defense of zope libraries 翻訳
========================================

Pyramid が Zope ライブラリを使っていることについての非常に長い defence
----------------------------------------------------------------------

freenode の #pyramid IRC チャンネルで、以下のような質問に私は
うんざりするほど多くの時間を割いてきた。

::

  <誰かさん> pyramid は zopeベースだと聞いた。zope は悪だ。なぜ pyramid は
             zope ベースなのか？

Pyramid は "zope" の名前を持ったライブラリを使っている。より正確にいう
と、実際に使っているのは zope.interface と zope.deprecation の２つだ。
上に書いたような IRC の質問が出ることからも分かるように、少なくない人々
が zope は悪だと考えていて、推移的に pyramid も悪だと感じているようだ。
もしくは、 zope を消してしまうことで pyramid がより良くなるだろうと。
だが、そのように白黒付けたがるのはわかるが、実世界はもっと複雑だ。
私も物事の真実がそんなに単純であればその方がいいと思う。それなら説明す
るのも簡単だろう。だが、そうではない。そして、上記のような質問がたびたび
されるということは、明らかに何らかの答えを示す必要がある。ただし、「説明して
いるなら、すでに負けている ("if you're explaining, you're losing.")」。
だから、かわりに物語を語ることにしよう。

時は1999年、場所は Philadelphia PA, US のあるソフトウェアコンサルティング
会社で。20数名のあまり経験のない開発者たちが、地元の電力会社のイントラ
ネットアプリケーションを作成する必要にせまられていた。彼はとても未熟
(green) だった。手に余る (over his head) ことばかりだった。彼は Perl
が極めて危険だということに十分気づいていた。彼は MySQL をバックエンドに
使い、 Perl でシステムを書いていた。システム内の関数は、だいたいこんな
ものだった:

::

  sub get_domains {

      my $r = Apache::Request->new(shift);
      my %cookiejar = Apache::Cookie->new($r)->parse;
      # ... check the cookies for a user id ...
      # ... check the userid against a table in the database that
      # ... says whether the calling user is allowed to get domains
      # ... if not, redirect to login page.
      # ... if so, do some inscrutable SQL statement to get the domains
      # ... and render them into HTML.
      }

これはうまくいかなかった。金曜日の午後（mod_perl の clusterfuck of
epic propotions と判明した開発に苦しんでいる最中だった）、彼は
Slashdot で Zope 1.10 という新しいシステムを見つけた。それは Python と
いう競合する (competing) オープンソースのスクリプト言語で書かれていた。
それは自身をアプリケーションサーバーと称していた。そして、スクリーン
ショットにはすばらしい管理画面やセキュリティ機能が写っていた。彼はこれ
を試すことにした。彼は自分の Windows NT コンピュータ用のインストーラー
をダウンロードすると、ダブルクリックしてインストールした。そして、基本
的な操作方法にしたがって管理画面を Netscape Navigator 4 で開いてみた。
彼は三つのことに感動した: a) Webブラウザでコードを書けた。 b) 非常に先
進的なセキュリティモデルを持っていた。そのため、完全に信用できるわけで
はない人々にでもWebブラウザからコードを書かせることができた。そして、
c) Zope のセキュリティモデルは宣言型だった。つまり、これらのデータモデル
とセキュリティモデルを受け入れれば (buy into)、 mod_perl のアプリケー
ションで書いていた、決まりきった (boilerplate) セキュリティチェックの
コードをすべてなくしてしまうことができた。リレーショナルデータベースを
別に用意する必要すらなかった; 専用のオブジェクトデータベースを含んでい
たからだ。その UI は、データベースとコードをツリー状にグラフィカルに見
せてくれた。これは彼にとって信じられない天啓のようだった。そして、彼はこれら
の機能のもたらす優位性を生かせば、今書いているシステムをより早く簡単に
書けることを悟った。彼の技術力で、これに匹敵するほど生産的なものは他に
はなかった。

そこで彼はそのチャンスを活かすことにした。 mod_perl で書いたコードは
すべて捨ててしまった。Python の知識はまったくなかったが、 Zope のソース
や適当なメーリングリストの議論から情報を拾い上げ、 Zope を使ってどうにか
非常に基礎的なインターネットシステムを作り上げた。彼はテストの書き方を
まったく知らなかった。彼の会社にいる人たちも、誰もテストの価値を知らなかった。
だから彼もテストを書いていなかった。 web 上での (through-the-web)
コーディングモデルにもかかわらず、そしてこの仕事の以前に Python の知識
をほとんど持っていなかったにもかかわらず、完成したものは mod_parl で
書いていたらできたであろうものよりも cleaner になった。 a) Zope の宣言
的セキュリティモデルに完全に頼ることができた。 b) セキュリティやその他
の設定を変える必要があれば顧客に見せることのできる UI が存在した。 c)
システムは、彼が自分で書いたものよりも非常に精密なセキュリティモデルを
持っていた。セキュリティはコンテキスト依存だった。よって、もし誰かが
ドキュメントをイントラネットに追加した場合、そのドキュメント固有の認証
情報を問題なく持ち運ぶことができた。これを顧客に見せたところ、彼らは
喜んでお金を払ってくれた (they are happy and they pay)。すぐ後に Zope
の新しいバージョンがバージョン 2.0 としてリリースされたときは、彼はコー
ドを比較的簡単に移行させることができた。

彼はそれからいくつかの Zope の仕事をこなした。しかし、その後
Philadelphia の会社は Microsoft 製品に集中するようになったため居心地が
悪くなった (falls out of favor) 。その後、いくつかの幸運によって
Digital Creation の職を得た。 Zope 自体の開発元だ。数年のとても良い時間
をすごした。彼は Zope 2 アプリケーションをさまざまな顧客に向けて書き、
Digital Creations の（とても、とても経験豊富な）同僚やマネージャーたち
から多くの本当のソフトウェアエンジニアリングについて学んだ。

何年かがすぎると、しかし Philadelphia の開発者はソフトウェア開発業界の
いくつかのトピックが気になっていた。業界は、一時的であれば異質なものに
対して多少寛大になるが、そうする間は常に鼻をつまみ、機会があればいつで
も親しみのある領域に退却するだろう。業界は、リレーショナルでないすべて
のデータベースを疑っていた。特に、80年代後半から90年代にかけて、
Smalltalk の過剰に誇大な喧伝によって、オブジェクトデータベースは大いに
疑われていた。さらに、貧弱なドキュメンテーションを備えたものは好まれな
い、ということにも気がついていた。

Zope に関するいくつかの suboptimal なことが、彼にとって明らかになった。
明確になったのは、 Zope 自体の自動テストが必要だということだ。
さまざまなスキルレベルの人たち (彼も含めて) が十分な品質管理もなく
とんでもない勢いで疑わしい追加をしていた。結果として、自分たちの首を
絞めることになった。また、あれほど魅力的に見えた "through the web" 開発
モデルも、多くの欠陥を持っていることが明らかになった。この方法で書かれた
コードに対して自動テストを書くことは困難だった。TTW モデルはシステム
と密接にかかわっていたため、 TTW モデルのことを気にせずにコードを書くこと
が困難になっていた。TTW セキュリティモデルの存在と、管理インタフェース
に対するユーザの期待は、さらにある種の先進的なコードを書くことをやっかい
にしていた。袋小路に追いやられていた。なぜなら、新しい Zope ユーザーを
惹きつけているものが、そのシステムが最初に成功した後では、彼らを害する
(repel) 傾向にあるからだ。テストしやすいコードを書くためには、 Digital
Creations のエンジニアは TTW 開発を使うことができなかったが、 Zope で
TTW でないコードを書くのは、非常にうんざりするほど腹立たしいこと (pain
in the ass) だった。 TTW コードモデルをやめるか、もっと開発をサポートす
るツールが必要であることが明らかだった。だが、UNIX にあるような、極めて
質の高いツールチェインを作る時間は誰にもなかった。社内外で TTW プログラ
ミングモデルに対する失望が感じられていた。

だが、それでも 2001 年に Zope は非常に成功した。 2001 年の Software
Development Magazine において Zope は Jolt Product Excellence Award を
獲得し、雑誌の表紙を飾った (この賞のテキストによると「この賞に輝いた製品
は、その重要性で業界を震撼 ("jolted") させ、企業ソフトウェアを作成する
困難なタスクをより速く、より簡単で、より効率的にした」)。いくつかの大き
なメディア企業がこのプラットフォーム上にサイトを立ち上げた。彼らにとっ
て最適な選択だった。 Digtal Creation も大量のコンサルティングを成功させており、
さらなる利益も十分に得られていた。主要な Zope メーリングリストは1日あたり
100メッセージが流れていた。メーリングリストのメール受信を重要なサービス
のイベントトリガーにしても良いんじゃないかとジョークで言っていた。
まるで時報のように新しいメッセージが昼夜問わず飛んできていたからね。
Zope ベースの新しいシステムがどんどん作られていた。 Content Management
Framework (Plone のベースとなっている) もその１つだ。

そんな感じで時は過ぎ、 Philadelphia の開発者は Zope の次のバージョンが
始まるのを見ていた。 Zope 3 だ。Zope 3 は古い Zope 2 とは完全に互換性が
なくなることになった。何らかの互換性レイヤーはのちに作成されることになっ
ていたが、 Zope は完全に再設計、再構築されていた。すべてが書き直された。
この作業には Digital Creations 内で多くの労力が注がれた。Zope 2 を
最初に書いたメンバーがほぼフルタイムで作業した。さらに彼は会社の "A チーム"
の開発者たちの手助けを受けることもできた。 Zope 3 は「コンポーネント
アーキテクチャ」に基づいていた。これは独立に開発しテストしたコンポーネント
を入れ替え可能にするものだった。開発者が必要なものを何でも組み込むこと
ができ、必要に応じてサードパーティの既製コンポーネントを入れ替えること
ができるというもので、 Zope 2 のもろさと柔軟性のなさとは対照的だった。
サブクラスよりもコンポジションが好まれるようになった。 ZCMLという XML
ベースのコンフィグレーション言語すら作り出した。 Zope 2 のような巨大で
モノリシックなシステムの代わりに、相互運用 (interoperate) する小さな
部品で構成されるようになった。 Philadelphia の開発者は、これはすごい
ものになると確信していた。彼が尊敬する賢い人たちが、これらの作業をして
いたからだ。

Philadelphia の開発者は、 Zope 3 の何百、何千行というコードが書かれるのを
眺めていた。開発チームは、よいテストの書き方を学んでいた (だが、よい
ドキュメントの書き方は学ばなかった)。 Digital Creations の最高の
エンジニアたちが Zope 3 の設計を行った。少しずつだが、美しい核を
持つ複雑なシステムになっていった。それでも、Zope 2 とは違っていた。
Web 開発の世界で、他のどれとも大きく違っていた。1年か、もしかすると2年
かかると思われた。結局、最初の非ベータリリースまでに4年ほどが経っていた。
Zope 2 はこのときまでポピュラーな状態だったが、Zope 3 の先行きが不明な
ことから多くの人々は Zope 2 の未来に不安を抱いていた。

Zope 3 が最初にリリースされたときには、 Philadelphia の開発者は非常に落
胆していた（彼の Digital Creations での主な仕事は Zope 2 を使ったコンサ
ルティングだった）。難しすぎる。全体像がつかめない。貧弱なドキュメント。
多くの人たちがいらだちを感じ、 Zope の完全な代替手段を探し始めた。
非常にシンプルな要求を持つ人々は、より適した代替手段を素早く見つけていた。

この間に Digital Creations は Zope Corporation と名前を変えた。そして、
少しずつベンチャーキャピタルにフォーカスしたビジネスモデルを拡大し始めた。
直接的なコンサルティング料 ($) よりも販売のために製品を作る ($$$$$$$$$$)
ようになった。結局、会社はエンジニアリングへの投資を減らしていった
(そして営業に注力していくようになっていった)。そして、とうとう Zope 3 の
屋台骨が揺らいでしまった (eventually the bottom drops out) 。収入を生み出す
プロジェクトのすべてがいまだ古い Zope 2 技術を使用している状況で、会社
は新しい Zope を作成する資金を出し続けることをまったく正当化できなくなった
からだ。 Zope 2 と Zope 3 両方のプロジェクトの創始者であり主要な支援者が、
売るための製品を作ることに注意を払わないといけなくなって、プロジェクトに
対してあまり支援をしなくなった。サードパーティから Zope 3 へのオープン
ソースの貢献は重要だったが、 Zope Corpolation の後ろ盾がなければ、
その穴埋めができるようには見えなかった。

Zope 3 は決して大きな注目を浴びることはなかった。コンポーネントアーキテ
クチャのようないくつかのテクノロジーは Zope 2 へと逆移植された。だが、
これは、ただでさえ複雑だった Zope 2 をさらに複雑にしただけだった。
Bluebream や Grok のようなプロジェクトは Zope3 をベースとしたハイレベル
なフレームワークだが、これらもそれほど注目されなかった。5年におよぶ
brand-muddying (ブランドが傷つくこと) によって、人々は Zope が何なのか
わからなくなってしまった。「Zopeとは何か? Zope 2 か? Zope 3 のことか?
Zope Corporation か? PyPI にあるパッケージのことなのか? パッケージの集
まりか?」それぞれすべて真実である。その結果、ブランド名は大きな意味を持
たなくなった。すべてを表すと同時になにも表していない。恐るべきことに、
Django のような良いドキュメントがありよく設計されたシステムが登場するよ
うになり、ブランドは急速に蔑みの対象と変わってしまった。セカンドシステム
症候群による失敗、大きな後援者の継続的なサポートの欠如、そしてブランドが
傷ついたことの三重苦により、 Python コミュニティの間では、 Zope に関連
したものを使ったことがない人々でさえ、"Zope" の名は「過剰なエンジニア
リング」や「技術者の自己満足」の代名詞として使われるようになってしまった。
オリジナルの Zope アプリケーションサーバーである Zope 2 についても、
いまだ比較的モノリシックで複雑 (crufty) であること以外は大部分は非の打
ち所がないにもかかわらず、その評判に深刻な被害を受けた。ブランドはその
信頼をほとんど失った。そしてタイトルに Zope という単語が入っているもの
は何でも疑いを持って扱われるようになり、 web 開発にほとんど関係していな
い部分でさえ、敬意をまったく払われなくなった。

ブランドの崩壊はあったが、それでも Philadelphia の開発者は Zope の再構築
のいくつかは技術的にとても成功したと考えていた。Zope のオブジェクトデータ
ベースである ZODB は Zope から切り離され、独立に利用できるようになった。
「コンポーネントアーキテクチャ」 (それは事実上大げさな名前を持つ
高機能なスーパー辞書だ) は、複雑な入力に対して非常に迅速な検索を
行うのに有用なことが証明された。 Zope 3 のインターフェイスシステムは、
(クラスベースではなく) インスタンスベースの構造化されたダックタイピング
を可能にした。そして、これは APIドキュメントを書きやすくした。
Philadelpha の開発者にとって元々 Zope の存在意義は宣言的なコンテキスト
依存のセキュリティシステムだったが、これは完全に混乱していた (muddled) 。
これらは再利用はできないが、アイディアには価値があった。オブジェクト
グラフ上を "traversal" してセキュリティコンテキストを決定するという
Zope のコンセプトは Zope 2 や Plone 界隈では常識になっていた。
そして、そのころ、競合のシステムはそれに代わるものは持っていなかった。

そして、もうみんな気づいているだろう。 Philadelphia の開発者とは私のこ
とだ。そして、これらはすべて私の経験してきたことだ。この経験を振り返る
のは楽しいことばかりとは言えない。 Zope がこのような結果になってしまった
のを見るのは、私にも辛いことだった。だが、これらの経験は、私にいくつか
のことを気づかせた:

- 多くの開発者はとてもとてもリスクを嫌う。彼らは小さなステップを好む。
  またはまったく変化したくない。彼らに馴染みのある技術を使い続けることを
  認めないといけないし、妨げとなる方法を彼らが使わないことも認めなけれ
  ばならない。

- 事実上他の開発テクニックや技術と一緒に使えないような、統合されたモノ
  リシックシステムの魅力は徐々に消えていく。そして、魅力が消えていくと、
  忌むべきものに変わる。

- モノリシックシステムによるこうした問題に対する自然な反応は、なんでもかんでも
  プラッガブルにすることだが、これは完全な負け戦 (a net lose) だ。

- テストは非常に重要だ。

- ドキュメントはもっと重要だ。

- 複雑なシステムを置き替えるなら、もっとシンプルにしていかなければなら
  ない。複雑さを追加してはいけない。

- ブランドは重要だ。「○○とはなにか？」という質問には１つの答えだけを
  持つべきだ。微妙なものとブランディングを混ぜてはいけない。混乱をもた
  らすだけだ。

Pyramid は Zope の影響を大きく受けている。それはとても広範囲に及ぶ。
間違いなく派生物だ。 Zope がなければ Pyramid はなかったとはっきり言える。
だが、同時に Pyramid は Zope への回答だ。 Pyramid を作ったのは、 Zope
の良くないところと素晴らしいところを理解しているからであって、理解していない
からではない。その一方で、私たちは偶然 zope の名前を持つパッケージ
をいくつか使っている。これらは Zope と関係なく十分再利用できるようになっ
ているからだ。 Pyramid は Pylons や Django からも大きく影響を受けている。
だが、皮肉なことにこれらのシステムはそれほど良く作られていなかったため、
簡単に再利用できるものはなかった。

Pyramid は zope.interface を以下のことに利用している:

- 宣言的なコンテキスト依存セキュリティ機能のためのコンテキストの検索機構
  （ACL認証機構）。

- コンテキストベースのビュー検索機構。（たとえば例外ビュー）。

Pyramid は フレームワーク利用者に API の廃止を通知するために
zope.deprecation を使っている。これは依存関係を持たず、Zope アプリ
ケーションサーバーとはまったく関係のない100行ほどのコードしかない。

Pyramid を使う分には、これらのことはまったく気にする必要はない。
フレームワークの開発者はこれらのことを知っている必要があるだろう。
これらをフォークして名前を変えることもできたし、そうしても Zope 懐疑論者
にはきっと分からないだろう。まったく違う名前でリリースしなおしてしまえ
ば、もっと評判が良かったかもしれない！ だが、 zope が悪だという単純な
二元論を持つ人たちのために名前を変えるというだけの理由でフォークするの
は、何百人という貢献者たちへのとんでもない冒涜だ。彼らは Zope ブランド
の悲劇にかかわらず、賞賛と尊敬に値する人たちだ。彼らは私がしてきたより
も（そして将来にわたってもきっと）Python の Web 世界に多くの貢献をして
きている。きっとこれを読んでいる読者たちよりも。

zope は悪、 pyramid は zope 、だから pyramid は悪だという議論をしたい人
たちには、もっと勇気を持ってもらいたい。評価を始めて最初の 10 分の間、
これまで書いてきたことを思い出して、 Pyramid の Zope 依存性の歴史全体が、
哀れなのろま (hapless dunces) によって書かれたわけではないという観念を
つかの間受け入れてほしい。具体的な positive replacement を必要としている場合は、
このようなものについて考えてるみること: 今日の Mac OS X は zope.interface
を出荷時から含んでおり、そうしたデプロイは、あなたと私にその友人を加え
た人々 (そしておそらくそのまた友人を加えた人々) が与えたであろう影響よ
り多くのユーザに影響を及ぼしている。 Reddit から得た常識がどういうもの
かを考えてみるといい。すなわち、2002年に Zope アプリケーションサーバを一日
使っただけの奴の言うことなんか関係ない。あなたが最初に nontrivial な Pyramid
アプリケーションを書くときまで、この疑いの保留は私たちの貸しにしてほしい。
そのあとで、個別の批判については歓迎する。


補足説明
--------

- "if you're explaining, you're losing." はアメリカの政治家 J. C. Watts の言葉。
  Lessig の講演 http://randomfoo.net/oscon/2002/lessig/ でも引用されている。

- Jolt Product Excellence Award に関するくだり "products that win ..." は、
  zope に対する評価ではなく Award 自体の説明文。 http://bit.ly/zoWnll