aodag’s posthaven

http://delicious.com/stacks/aodag

5エントリないとStackとして公開できないらしく、あと3カテゴリほど非公開な状態。そのうちなんとかする。

目標

• Pylons/Pyramid勉強会を4回開く
• Pyramidベースのフレームワークを作る
• Web関連ライブラリのPy3対応にコミットする
• 海外のPyConその他のカンファレンスに1回は行く
• 英語力強化（アウトプット方面）
• ブログを50エントリ書く

セカンドシステム症候群の三重苦や継続的なサポートのなさ、ブランドは傷つき、"Zope"の名を過去のものにした。

PythonコミュニティでもZopeに関連したものを使ったことがない人々に、過剰なエンジニアリングや技術者の自己満足ととらえられるようになってしまった。

オリジナルのZopeアプリケーションサーバーであるZope2の評判は、未だモノリシックでお粗末な設計に苦しんでいること以外は文句の付けようがなかった。

ブランドは許容を超えてしまった。

そしてZopeの言葉がつくものはほんの少しの尊敬と、悪いイメージを持ち始めた。

かろうじて、この評判はweb開発に関係している部分だけだった。（？PythonはWebだけではないので、それ以外の業界ではそういうイメージを持たれなかったということか？）

ブランドの崩壊はあったが、それでもPhiladelphiaの開発者は、Zopeの再構築は技術的に成功したと考えていた。

ZopeのオブジェクトデータベースであるZODBはZopeから切り離され、独立に利用できるようになった。

コンポーネントアーキテクチャは複雑な入力に対して、非常に迅速な処理を行うのに有用なことを証明した。

Zope3のインターフェイスシステムは、インスタンスベースのダックタイピングを構造化できた。そして、これはAPIドキュメントを書きやすくした。

Philadelphaの開発者にとってのZopの存在意義は、宣言的なコンテキスト依存のセキュリティシステムだった。

これは完全に混乱していた。これらは再利用はできないが、アイディアは再利用すべきであった。

オブジェクトグラフ上を"traversal"してセキュリティコンテキストを決定するというZopeのコンセプトはZope2やPlone界隈では常識であった。

そして、そのころ、それに変わるものは競合のシステムは持っていなかった。

そして、もうみんな気づいているだろう。Philadelphiaの開発者は私のことだ。そして、これらはすべて私の経験してきたことだ。

この経験を振り返ることが楽しいことだとはいえない。Zopeがこのような結果になってしまったのは、私も大きく傷ついた。

これらの経験は、私にいくつかのことを気づかせた。

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

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

モノリシックシステムによるこうした問題に対する自然な反応は、すべてを完全にプラッガブルにすることだ。だが、これは罠だ。

テストは非常に重要だ。ドキュメントはもっと重要だ。

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

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

PyramidはZopeの影響を大きく受けている。それはとても広範囲に及ぶ。派生物だ。Zopeがなければ、Pyramidはなかったとはっきり言える。

だが、同時にPyramidはZopeへの回答だ。

Pyramdiを作ったのは、Zopeの良さと偉大さを理解しているからだ。

その一方で、zopeの名前を持つパッケージをいくつか使っている。これらはZopeと関係なく十分再利用できるようになっているからだ。

PyramidはPylonsやDjangoからも大きく影響を受けている。だが、皮肉なことに、これらのシステムはそれほど良く作られていなかったため、簡単に再利用できるものはなかった。

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

宣言的なコンテキスト依存セキュリティ機能のためにコンテキストを発見する（ACL認証機構）

コンテキストベースでのビューを発見する機構。（たとえば例外ビュー）

Pyramidはzope.deprecationを、フレームワーク利用者にAPI廃止を通知するために使っている。

これは、まったく依存関係をもたず、１００行ほどのコードしかない。Zopeアプリケーションサーバーとはまったく関係のないものだ。

Pyramidを使う分には、これらのことはまったく気にする必要はない。

フレームワークの開発者はこれらのことを知っている必要があるだろう。

これらをフォークして名前を変える方法もあったし、Zope懐疑論者に知られないようにしても良かった。まったく違う名前でリリースしなおしてしまえば、もっと評判が良かったかもしれない！

だが、zopeが悪だと単純な二元論を持つ人たちのために名前を変えるだけのためにフォークするのは、何百人という貢献者のたちへの冒涜だ。

彼らはZopeブランドの悲劇にかかわらず、賞賛と尊敬に値する人たちだ。

彼らは私がしてきたよりも（そして将来にわたってもきっと）PythonのWeb開発に多くの貢献をしてきている。きっとこれを読んでいる読者たちよりも。

zopeは悪、pyramidはzope、だからpyramidは悪だという議論をしている人たちには、もっと勇敢になってもらいたい。

Within your first ten minutes of evaluation, considering the stuff I've written above, please try to momentarily entertain the notion that the history of Pyramid's Zope dependencies isn't written entirely by hapless dunces. 

PyramidがZopeに依存している理由が不運な劣等生について書かれたものではない（訳注：フレームワーク上の欠陥ではないという意味？）ことを書いてきた。

If you need a concrete positive replacement, try to think of something like this: 

Mac OS X today ships with zope.interface out of the box and that sort of deployment effects more users than you and me put together plus all of our friends (and maybe even all of their friends) will likely ever influence. 

Consider that the common wisdom you've gained from Reddit or that guy who used Zope-the-application-server for one day in 2002 may be irrelevant. 

訳注：このあたり、ぜんぜん意味わかんない

批評は、あなたがたが最初にPyramidアプリケーションを書くときまでの貸しとしてください。

それでもまだ信じられないのであれば、そのような批評を歓迎します。

何年かがすぎたが、Philadelphiaの開発者はソフトウェア工学のいくつかのトピックを気にかけていた。

He notices that if it behooves the industry temporarily, it will tolerate things that are slightly different, but it always holds its nose while doing so and will always retreat back to the familiar at first opportunity. 

業界では、すべてのデータベースがリレーショナルでないことに気づいていた。

特に、80年代後半から90年代に掛けて、Smalltalkの喧伝によって、オブジェクトデータベースの可能性が示されていた。

たいしたドキュメントもなかったと記憶している。

Zopeに関するいくつかのことがらが、彼にとっては自明だった。

明確にされたのは、Zope自体の自動テストが必要だということだ。

さまざまなスキルレベルの人たちが十分な品質管理もなく疑問のある追加をしていた。

結果として、自分たちの首を絞めることになった。

あれほど魅力的に見えたweb上での開発モデルも、多くの欠陥を持っていることが明らかになった。

この方法では、自動テストを書くことは困難だった。

TTW(Through-the-web) モデルは、システムと密接にかかわっていたため、webモデルとかかわりのないコードを書くことが困難になっていた。

TTWセキュリティモデルの存在と、管理インターフェイスへの期待は、さらに先進的なコードを書くことをやっかいにしていた。

袋小路に追いやられていた。

なぜなら、新しいZopeユーザーをひきつけているものが、最初にそのシステムで成功した後に、撃退すべきものととらえられてしまっているからだ。

テストしやすいコードを書くためには、Digital Creationsのエンジニアは、Web上での開発やめなくてはならなかった。しかし、Zopeのためのコードをオフラインで書くのは、非常に腹立たしいことだった。

TTWコードモデルは死すべきか、もっと開発をサポートするツールが必要であることが明らかだった。

だが、UNIXで動くような、よりよいツールチェインを作る時間を誰も持っていなかった。

TTWプログラミングモデルは、社内外で幻想だったと感じられていた。

だが、それでも2001年はZopeは非常に成功した。

2001年のSoftware Development MagazineのJolt Product Excellence Awardを勝ち取り、雑誌の表紙をかざった

(この賞をもらったときは、この製品は、とても重要で、企業サイトを作る難しい仕事を速く、早く、さらに効果的にすると書かれていた：訳注よくわかんないけどものすごく賞賛されたようだ)

大きなメディア企業がこのプラットフォーム上にサイトを立ち上げた。

彼らにとって十分なできだった。

Digtal Creationもコンサルティングの成功を十分に受け入れていた。

さらなる利益も十分に得られていた。

主要なZopeメーリングリストは1日あたり100メッセージが流れていた。

メーリングリストのメールを受信を重要なサービスのイベントトリガーにしてもよいんじゃないかとジョークで言っていた。まるで時報のように新しいメッセージが昼夜問わず飛んできていたからね。

Zopeベースの新しいシステムがどんどん作られていた。CMF(Ploneのベースとなっている。)もその１つだ。

そんな感じでときはすぎ、Philadelphiaの開発者は、Zopeの次のバージョンが始まるのを見ていた。Zope3だ。

Zope3は、Zope2と互換性がなくなるようだった。互換性レイヤーはのちに作成されることとなっていた。だが、Zopeは完全に再設計、再構築されたていた。

すべてが書き直され、この作業はDigital Creationsのなかで多くの労力が注がれた。

Zope2を作った主要メンバーはフルタイムで作業した。さらに彼はチームの開発者たちの手助けもした。

Zope3はコンポーネントアーキテクチャをもとにしていた。これは開発してテストしたコンポーネントを入れ替え可能にするものだった。開発者が必要なもの、提供できるものサードパーティから提供されるものを必要に応じて入れ替えることができ、Zope2の柔軟性のなさとは対照的だった。

サブクラスよりも集約が好まれるようになった。ZCMLという、XMLベースのコンフィグレーション言語ですら作り出した。Zope2のような大きく1枚岩なシステムの代わりに、小さな部品の相互作用で構成されるようになった。

Philadelphiaの開発者は、これはすごいものになると核心していた。尊敬する賢い人たちが、これらの作業をしていたからだ。

Philadelphiaの開発者は、Zope3の何百、何千というコードを眺めていた。

開発チームは、よいテストの書き方を学んでいた。(だが、よいドキュメントの書き方には気づいていなかった）

Digital CreationsのすばらしいエンジニアたちはZope3の糞な部分も設計した。

少しずつだが、美しい核を持つ複雑なシステムになっていった。それでも、Zope2とは違っていた。Web開発のその他のものとも、大きく違っていた。

1，2年が経過した。最初のノンベータリリースまでに4年ほどが経っていた。

Zope2はこのときまで、ポピュラーな状態だった、だが、多くの人々はその未来やZope3に不安を抱いていた。

Zope3が最初にリリースされたときには、Philadelphiaの開発者は非常に落胆していた。（彼のDigital Creationsでの仕事は、Zope2を使ったコンサルティングだった）

難しすぎる。全体像がつかめない。貧弱なドキュメント。多くの人たちがいらだちを感じた。

さらに、Zopeを置き換えるようなものも増えていたし、人々はもっと単純に早く適切な代替手段を探し始めていた。

この間に、Digital CreationsはZope Corporationと名前を変えた。そして、少しずつベンチャーキャピタルにフォーカスしたビジネスモデルを欲しがるようになった。コンサルティング料よりも製品で稼ぐことを試みるようになった。

結局、会社はエンジニアリングへの投資を減らしていった（そして営業に注力していくようになっていった）

そして、Zope3の基盤が崩れてしまった。Zope2が使われているプロジェクトがある状態で、新しいZopeを作るための資金が出なくなったからだ。

Zope２とZope３の両方のプロジェクトを開始した主要な支援者は、売れる製品を作ることに注意をはらわないといけなくなった。

サードパーティからZope3へのオープンソースによる支援は重要だったが、Zope Corpolationの後ろ盾はなかった。そしてそれらの影響もあまり見られなかった。

Zope3は決して大きな注目を浴びることはなかった。

コンポーネントアーキテクチャのようないくつかのテクノロジーは、Zope2へと逆移植された。だが、この方法は、ただでさえ複雑だったZope2をさらに複雑にした。

BluebreamやGrokのようなプロジェクトでは、Zope3をベースとしたハイレベルなフレームワークだ。だが、これらもそれほど注目されなかった。

5年におよぶブランド汚しによって、人々はZopeが何なのかわからなくなってしまった。

Zopeとは何か？Zope2か？Zope３のことか？Zope Corporationka？PyPIにあるパッケージのことなのか？パッケージの集まりか？

それぞれすべて真実である。

ブランドネームというのは結局、大きな意味を持たなくなる。すべてを表すと同時になにも表していない。

恐ろしいことに、Djangoなどよくドキュメントがありよく設計されたシステムが登場するようになり、ブランドは急速に蔑みの対象と変わってしまった。

追記：2012/01/04

@knzm2011 が全訳してくれました。

http://plope.com/Members/chrism/in_defense_of_zope_libraries の翻訳

1/3くらいまでです。

PyramidがZopeライブラリを使っていることについて

IRCチャンネルで訊かれた以下のような質問について、多くの時間を割いた。

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

Pyramidはzopeの名前を持ったライブラリを使っている。

より正確にいうと、実際に使っているのは、 zope.interfaceとzope.deprecationの２つだ。

上に書いたようなIRC質問でるのは、少なくない人たちが、 zopeは悪だと考えている証拠だろう。

そして、推移的に、pyramidも悪だと感じるようだ。

もしくは、zopeを消してしまうことで、pyramidがより良くなるだろうと。

だが、そのように白黒付けたがるのはわかるが、実世界はもっと複雑だ。

物事の真実がそんなに単純であれば説明するのも簡単だろう。その方がいい。

だが、そうではない。そして、明確な答えを示す必要があるくらいに、上のようにたびたび質問される。

ただし、説明するとなにかが失われる

だから、かわりに物語として語ることにしよう。

時は1999年、場所はPhiladelphia PA, USのあるソフトウェアコンサルティングの会社で。

20数名のあまり経験のない開発者たちが、地元企業のイントラネットアプリケーションを作成する必要にせまられた。

彼はとても世間知らずだった。手に余ることばかりだった。

彼は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をチューニングするという壮絶な苦しみの最中だった）、

彼は、Slashdotで Zope 1.10という新しいシステムを見つけた。

それはPythonというオープンソースのスクリプト言語で書かれていた。

それは自身をアプリケーションサーバーと称していた。

そして、すばらしい管理画面やセキュリティ機能のスクリーンショットを掲載していた。

彼はこれを試すことにした。

彼は自分のWindows NT用のインストーラーをダウンロードすると、ダブルクリックしてインストールした。

そして、基本的な操作方法にしたがって、管理画面をNetscape Navigator4で開いてみた。

彼は三つのことに感動した。

a) Webブラウザでコードを書ける

b) 非常に先進的なセキュリティモデルを持っていた。

そのため、完全に信用できるわけではない人々にでもWebブラウザからコードを書かせることができた。

そして、Zopeのセキュリティモデルは宣言型だった。

つまり、これらのデータモデルとセキュリティモデルを受け入れてしまえば、mod_perlのアプリケーションで書いていた、決まりきったセキュリティチェックのコードをすべてなくしてしまえた。

リレーショナルデータベースを用意する必要もなかった。専用のオブジェクトデータベースまで含んでいたからだ。

UIは、データベースとコードをツリーとしてグラフィカルに見せてくれた。

これは彼に信じられない天啓のようだった。

そして、彼はこれらの機能によって、今書いているシステムをより早く簡単に作れることを悟った。

彼の技術力の中で、これほどの生産性を持つものはなかった。チャンスだった。

mod_perlで書いたコードはすべて捨ててしまった。

Pythonの知識はまったくなかったが、Zopeのソースや適当なメーリングリストの議論から情報を広い上げ、Zopeを使ってどうにかシステムを作り上げた。

彼は、テストの書き方をまったく知らなかった。

彼の会社にいる人たちも、誰もテストの価値を知らなかった。

だから彼もテストを書いていなかった。

web上でのコーディングあるにもかかわらず、そしてこの仕事の以前にもPythonの知識もほとんどなくかったが、mocl_parlで書いたものよりもよいものになった。

a) Zopeの宣言的セキュリティモデルに完全に頼るようにした。

b) セキュリティの設定を変えるために必要なUIを顧客に見せた。

c)出来上がったシステムは、これまで彼が書いていたものよりも、非常に精密なセキュリティモデルを持っていた。

― セキュリティはコンテキストに依存する。よって、もし誰かがドキュメントをイントラネットに追加したい場合、問題なくそのドキュメント固有の認証情報を持っていなくてはならない。

これを顧客にみせたところ、彼らは非常に気に入ってくれた。

Zopeの新しいバージョンは、バージョン2.0として、すぐにリリースされた。彼は、コードを比較的簡単に移行させることができた。

彼はそれからいくつかのZopeの仕事をこなした。しかし、彼はその後Philadelphiaの会社をやめた。Microsoft製品を取り扱うようになったからだ。

彼は、その後、いくつかの幸運によって、Digital Creationの職を得た。Zopeそのものの開発者となった。

数年のとても良い時間をすごした。

彼はZope 2アプリケーションをさまざまな顧客に向けて書いた。

また、Digital Creationsの同僚やマネージャーたちから多くの（とても、とても良い経験だった）本当のソフトウェアエンジニアリングについて学んだ。

Read more »

1. What is the coolest Python application, framework, or library you have discovered in 2011?

I like Pyramid, webob and repoze components.These are the base of modern python web application.

2. What new programming technique did you learn in 2011?

MVVM pattern.That is used in WPF/Silverlight appplications.I wanna use the architecture like that on pyramid application.On that, the important point is loose coupling.

3. What’s the name of the open source project you contributed the most in 2011? What did you do?

Pyramid.I contributed some patches for that.

4. What was the Python blog or website you read the most in 2011?
   • Reddit Python Section
   • The history of Python
   • Python insider
   • Fethez le Python
5. What are the three top things you want to learn in 2012?
   • python3 and pysetup3
   • html5 and new js apis
   • Windows Phone7
6. What are the top software, app, or lib you wish someone would write in 2012?

   I wish some libraries support py3.

   They are:

   • repoze.who
   • PasteScript
   • ZODB3

Read more »

このエントリはPythonアドベントカレンダー2011の２５日目として、書いてもらった Pyramid@Python3の翻訳です。

tarekはエキスパートPythonの著者であり、PyconJP2011でもPython3のパッケージングについて基調講演をしていただきました。

以下翻訳です。

Read more »

さてpypyアドベントカレンダー 22日目ですよ。

このブログのエントリは半分くらいがアドベントカレンダー参加のために書かれています。

pypyはc以外にもjython, CLIのバックエンドがあると聞いて！

ということで、WindowsやらUbuntuやらでがんばってみました。

タイトルどおりまあ、完敗だったわけですが。

まずWindows

とりあえずWindows SDK 6.1で挑戦。

うっかり入っていたMonoを検出されてしまい時間をとられる。

基本的に.NET SDK使おうとしてるようだけど、MonoがあるとアセンブラだけMonoのilasm2使おうとするらしい。でもそんなファイルないですから！

しょうがないので該当部分をちょこっと変えてMonoのことは忘れてもらいました。

そして、ビルド開始。

pypy translate.py -Ojit --backend=cli

として待つこと１０分くらい？

どのくらい進んだかなーと画面を確認したらエラーで止まってました。(´・ω・｀)

UnicodeBuilderReprのll_getlengthがないのが原因のようで。

というかないのは問題ではなく、ないものを使おうとしてるのが問題？

このあたり良くわからないので、他の組み合わせでもやってみました。

ubuntu 64bitで挑戦。

結果として、64bitは long == longlong であるために、 型の区別がつかない -> bad overridingエラーという、もう根本的にだめじゃね？というエラーでストップ。

ということで32bit ubuntuで挑戦

エラーです。StringReprのconvertルールが見つからないというエラー。

心折すぎる。

結局どのプラットフォームでもpypy cli のバイナリ生成すらできませんでした。

cliならクロスプラットフォームなので、公式なバイナリが出てくれればいいのですが。

ということで、１周目、２周目と負け続きのエントリでした。

来年はもっとpypyを勉強して言語作成とかの話したい。

次は、@chlere ですね。よろしくお願いします。