ついうっかりvirtualenvせずに setup.py develop してしまったわけですが。

しかもwindowsだったので、権限でのストップがかからずそのまま大元のsite-packagesにざっくりインストールされました。

さて、setup.py developの場合、pipとは違い、eggごとのディレクトリにインストールされます。

で、これだけじゃPYTHONPATHに入ってこないわけで、site-packages内の *.pth ファイルにパスが羅列されているというのが、結構前に調べた結果。

インストールされてしまった、eggたちも、全部削除するんでなく、easy-install.pthの記述を消してしまえば、問題ないわけです。

さて、このeggたちを有効活用できないものか。

というか、そうするためにeggはディレクトリが分けられていまして、 pkg_resources.require() を使って、sys.pathに追加できます。

ポイントは、 pkg_resources.requireを使うと、そのeggが依存するeggもsys.pathに追加されるということ。

なので、今開発しているパッケージが bucho という名前で、きちんとsetup.pyに依存ライブラリを指定してあるなら、 pkg_resource.require('bucho') と書けば一発で必要なライブラリがsys.pathに追加されます。

さて、ちょっと目先を変えて、setup.pyから実行できるサブコマンドはサードパーティライブラリからも追加できます。

有名どころでは、noseのnosetestsコマンド、sphinxのbuild_sphinxコマンド。

で、先ほどの pkg_resources.requireですが、setup.pyから起動されるサブコマンドでは、setupされてるeggを内部でrequireしてあるようで、 コマンド自体のライブラリ(たとえばnose)があらかじめimport可能な状態なら、問題なく setup.py nosetestなどできます。

さらに、pkg_resources.requireはバージョン指定も可能です。また、easy_installコマンドは-m （マルチバージョン）オプションがあり、このオプションをつけると easy_install.pthに追記されずにインストールされます。このあたりの仕組みを使いこなせば、どんどん増えていくvirtualenvに悩まされることはなかったでしょう。

という、もうすぐpackaging/distutils2が出てしまう段階で、こんなTIPを調べたことに腹正しさを感じつつvirtualenvしなおしています...

Permalink | Leave a comment  »

ということで第二部で、Python3移行の話をしました。

組織的な移行じゃなくて、オープンソースコミュニティでのライブラリ対応の話です。

なんか誤解されちゃってる気がするので、補足しとく。

Python3自体は別に難しくないし面倒でもないです。

スライド中の苦しい話は、2と3と両方で動くように書くので面倒なんです。

そういうの気にしなければ、Python3使うのなんて簡単なんだからね！

Permalink | Leave a comment  »

まあ3系文法との互換性って2.6からの話なんで、2.5とかの非互換は結構あきらめていたのですが。

PasteDeployは2to3なしで、2.5から3.2をサポートしてるのですね。

except句って、2.5だと

except Exception, e:

という書き方で、2.6以降で導入された

except Exception as e:

じゃないと3で通用しないわけです。

PasteDeployが、これをどう解決してるかというと、

except Exception:
    e = sys.exc_info()[1]

な、なるほど。これなら確かにどちらのバージョンでも通用する！

が、こんな書き方するよりは、2.5を切り捨ててしまいたい。

http://www.voidspace.org.uk/python/articles/porting-mock-to-python-3.shtml

ちなみに2/24のBPStudy #54 で、こんな感じの話をしますのよ。

http://connpass.com/event/268/

まだ枠あいてるっぽいです。どうぞよろしく。

Permalink | Leave a comment  »

Permalink | Leave a comment  »

http://delicious.com/stacks/aodag

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

Permalink | Leave a comment  »

Permalink | Leave a comment  »

目標

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

Permalink | Leave a comment  »

セカンドシステム症候群の三重苦や継続的なサポートのなさ、ブランドは傷つき、"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アプリケーションを書くときまでの貸しとしてください。

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

Permalink | Leave a comment  »

何年かがすぎたが、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などよくドキュメントがありよく設計されたシステムが登場するようになり、ブランドは急速に蔑みの対象と変わってしまった。

Permalink | Leave a comment  »

追記：2012/01/04

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312

========================================
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

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

訳者解説

後半で明かされますが、これはChris MacDounoghの物語です。

ここまではZopeと出会い、そしてZope自体の開発者になるまでの話ですね。

当時のWebアプリケーションプログラミングはmod_perlが常識？だったのでしょうか。JavaもすでにServletが登場していたと思いますが、まったくかかわりがなかったようですね。

Permalink | Leave a comment  »

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

Tarek started this series with these instructions:

• copy-paste the questions and answer to them in your blog
• tweet it with the #2012pythonmeme hashtag

Permalink | Leave a comment  »

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

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

以下翻訳です。

Pyramid @ Python3

最近のChrisによるWebObの作業をよくチェックしているなら、

WebObとPyramidがPython3互換になったことを知っているだろう。

このことで、Python3は、これから新しくWebプロジェクトをはじめるのにとても魅力的な対象になった。

PasteとPasteScriptはまだPython3へのポーティングが必要だが、

Pyramidチームはそれを選択しなかった。

彼らは、自分たちが使うpasterの代替を作成した。

これらは、Pyramidを使うプロジェクトを初期化したり、.iniファイルを使ってアプリケーションを起動する。

PasteScriptとプロジェクトテンプレートを使うすべてのPython3フレームワークにとって、

Pasteを使わずに代替を使うのがシンプルな方法なのかは、わからない。

加えて、普通の典型的なWebアプリケーションを作るのに必要なほとんどのライブラリやPyramidの機能が、すでにPython3をサポートしてる。

たとえば、SQLAlchemyや、MySQLにアクセスするためのPyMysql、MemcachedのためのPylibmcだ。

まだ、Python3対応してなさそうなのは以下のもの。

• gevent
• gunicorn
• python-ldap
• Cornice ― まもなく対応する予定だ。

これらに挑戦してみたいと思ったら、Python3.2の最新版を使おう。

そして、https://github.com/Pylons/pyramid/wiki/Python-3-Portingを読んで、詳細を把握しよう。

足りないライブラリがあるなら、ここに追加してくれ。

メリークリスマス。

そしてここから訳者の解説でございます。

文中のChrisというのは、repozeプロジェクトを始め、repoze.bfg(後のPyramid)を作った人です。現在のpyramidチームのリーダーですね。webobもpylonsプロジェクトに合流して、両者で協力してpython3対応を進めてきたわけです。

Paste,PasteScript,PasteDeployとWSGI創設時から長らく使い続けられているライブラリ、ツール群でしたが、いまのところPasteDeployのみがPython3対応しています。Pyramidはさまざまな議論の末、PasteとPasteScriptから必要なコードだけポーティングして、Pyramid内の独自のコマンドとして取り込むことにしました。

Webアプリケーションを実行するような汎用ツールがPyramidをインストールしないと使えないのも異論がある話だと思います。ただ、Pyramidで使いたいだけなのに、汎用ツールで公開してしまってサポートしきれないという危険を感じてるのでしょうかね。リソースは有限ですから。

Pyramidと、MySQL, Memcache, SQLAlchemyとPython3で動けば、典型的なWeb+DBアプリケーションを作るのに不自由しなさそうです。ただし、サーバーはgunicorn使いたいです。

Corniceはtarekが最近公開した、pyramidベースのサービスフレームワークです。

pyramidの拡張性をいかしたつくりで、わかりやすいAPIと、Web APIをSphinxドキュメントにおとす（Pythonのリファレンスではなく、URLやHTTP Methodでドキュメントになる。すてきすぎ）Sphinx拡張がついてます。

ということで解説終わり。

メリークリスマス

Permalink | Leave a comment  »

さて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 ですね。よろしくお願いします。

Permalink | Leave a comment  »

mercurialアドベントカレンダー２１日目です。

今回は小ネタでいきます。

pythonで開発しているときに、依存するライブラリはsetup.pyに書きますが、テストツールやドキュメンテーションツールはsetup.pyに書かないわけです。

そういうのはrequirements.txtに書いとくのです。

あと、setup.pyには細かいバージョン指定をせずに、これまたrequirements.txtに書くことが多いのですが、開発しているうちにrequirements.txtを更新するのを忘れてしまうわけです。

まあ、こんなのpip freezeしてあげればいいのですが、そんなの機械がやってくれよ！

ということでprecommit hookでrequirements.txtが古くなっていないか確認します。

あと、virtualenvで作業してるのになぜかプロジェクトに関係ないライブラリが入ってしまってないかの確認にもなります。

[hooks]

precommit.freeze = pip freeze | sed "/-e .*$/d" | diff - requirements.txt

Permalink | Leave a comment  »

Permalink | Leave a comment  »

はろーえぶりわん

pypyをはじめようとしてそのまま日がたち、アドベントカレンダーで一念発起してpypyをいじっているaodagです。

さて、アドベントカレンダーが回ってきましたが、ほかのみんなのようなpypyで処理系を！ということはあんまり考えてないわけです。

pypyがcpythonよりも速いと聞いてきました！

さてpypyはpyramidですでに公式サポートしているので、まあpypy使えますよねというところですが、ZODBが動かないわけです。

動かないので、動かすためにあがいてみました。（まだちゃんと動かせていません。）

まずはこちらのmlポストを見て欲しい

https://mail.zope.org/pipermail/zodb-dev/2011-September/014364.html

手順が書いてあります。

ということでそのままやってみます。

>>>> storage = FileStorage('data1.fs')
>>>> from ZODB.DB import DB
>>>> db = DB(storage)
>>>> conn = db.open()
>>>> root = conn.root()
>>>> root
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/aodag/Envs/pypypy/lib-python/modified-2.7/UserDict.py", line 15, in __repr__
    def __repr__(self): return repr(self.data)
  File "/home/aodag/Envs/pypypy/site-packages/persistent/mapping.py", line 30, in __get__
    return self.func(inst)
  File "/home/aodag/Envs/pypypy/site-packages/persistent/mapping.py", line 99, in data
    data = self.__dict__.pop('_container')
KeyError: '_container'

だめでした(´・ω・｀)

でもこれってpypyだからだめなの？

ひょっとして、このブランチがだめなんじゃないの？

ということで、このブランチをcpythonで試してみました。

まずはパッチなしの場合。

python2.6では動きます。

python2.7でも動きました。

さて、パッチ適用後です。

python2.7で動きました。

pypyのバージョンが関係しているかもしれませんが、このあたりで心折れたので（日付変わっちゃってるし(´・ω・｀) ）ZODB動かす夢はまた情報が入ったら試すことにします。

残念な結果になりましたが、ひとまずアデュー。

Permalink | Leave a comment  »

Pyramidとは

PyramidはWebアプリケーションフレームワークです。

2011年に1.0, 1.1, 1.2 とハイスピードで開発が進み、現在の最新バージョンは1.2.3です。

Pyramidの特徴

Pyramidは、ミニマリズムを原則としています。

そのため、ある設定をするだけでいきなりなにかが動き出したり、ちょっと呼ぶだけで自動でいろいろなものが設定されたりすることはほとんどありません。書いたまま動きます。

Pyramidの利点は拡張性です。

ありとあらゆる場所にフック可能で、リクエストオブジェクトやセッション、DB接続など、あらゆるフレームワークの動きを変更可能です。

また、こうしたフックは自分のアプリケーションでも利用可能で、拡張性の高いアプリケーション作成に非常に役立つものと思います。

小さなアプリケーションは小さく書けることを目標においています。

実際、helloworldのようアプリケーションはWebサーバーの起動まで含めて１ファイルに収めることも可能です。

目的に合わせてできることを制限したフレームワークは非常に便利です。その目的に合わせたアプリケーションを書く限りは....。

フレームワークの制限に泣いたことのある人、昔ながらのCMS的なWeb+DBサイトのフレームワークを使うことに限界を感じている人。

また、単に新しいフレームワークを知って知見を広めたい人。

Pyramidをぜひ触ってみてください。

インストール

今後説明する環境はubuntuに限定します。

WindowsやMacの方は、VirtualBoxやVMWarePlayerで環境を用意してください。

build-essentialとpython-devが入ってることを確認しておきましょう。

$ wget http://python-distribute.org/distribute_setup.py

$ python distribute_setup.py

$ easy_install virtualenv --user

$ easy_install virtualenvwarpper --user

$ cat >> ~/.bashrc
export WORKON_HOME "$HOME/.envs"
mkdir -p "$WORKON_HOME"
export VIRTUALENV_USE_DISTRIBUTE=1
source ~/.local/virtualenvwrapper.sh
^D
$ source ~/.bashrc

とりあえず動かす

実際に環境を作ってpyramidを動かしてみます。

$ mkvirtualenv --no-site-packages pyramid
(pyramid)$ pip install pyramid
(pyramid)$ paster create -t pyramid_starter mypyramid
(pyramid)$ cd mypyramid
(pyramid)$ pip install -e .
(pyramid)$ paster serve development.ini

http://locahost:6543 にアクセスすると、Pyramidのデフォルトページを見れるはずです。

１日目からいきなり遅れてしまいましたが、２日目以降はPyramidのいろいろな話題を12/25まで取り上げていく予定です。

Permalink | Leave a comment  »

やるぜ！

https://connpass.com/event/142/

Permalink | Leave a comment  »

githubのリポジトリから直接インストールします。

pip install git://github.com/Pylons/pyramid.git#egg=pyramid

インストール後のパッケージ状況

Chameleon==2.5.2
Mako==0.5.0
MarkupSafe==0.15
PasteDeploy==1.5.0
WebOb==1.2b2
distribute==0.6.19
-e git://github.com/Pylons/pyramid.git@b75e577383936454d8b3e912f4f5478bf9af01e6#egg=pyramid-dev
repoze.lru==0.4
translationstring==0.4
venusian==1.0a2
wsgiref==0.1.2
zope.deprecation==3.5.0
zope.interface==3.8.0

main.py

from pyramid.config import Configurator
from wsgiref.simple_server import make_server

def index(request):
    request.response.text = "hello, world"
    return request.response

config = Configurator()
config.add_view(index)
app = config.make_wsgi_app()

httpd = make_server('0.0.0.0', 8080, app)
httpd.serve_forever()

ひとまず簡単なアプリケーションは動きました。

Permalink | Leave a comment  »

(´　　＞　ω　＜　)Pyramid1.2リリースだよーーーー！

インストールするには

pip install pyramid==1.2

easy_install pyramid==1.2

変更点の細かいところは、公式を見てもらうとして、大きな変更点を紹介するよ！

debug toolbar

*あの* Django の debug toolbar を移植したもの。

SQLAlchemyのクエリデバッグにも対応してます。

これまでブラウザ上で対話的なデバッグに使われていた WebError はここで引退？ということになるのか。

WebErrorのデバッグ機能はdebug toolbarに、メール通知などはpyramid_exclogに分割されました。

PasteScriptで生成するプロジェクトテンプレートも、 debug toolbar を使うように変更されてます。

route_prefix

PyramidはConfigurator.includeで別アプリケーションをインクルードできるようになっていたのですが、URLのルーティングは完全にグローバルな状態でした。

今回、includeメソッドでroute_prefixを追加することで、サブアプリケーションがあるURL以下にマッピングされるようになります。

たとえば、 include('admin', route_prefix='/admin') とすることで、 adminアプリケーションの、 'login' などは、 '/admin/login' とマッピングされるようになります。

tween

tweenはWSGIミドルウェアのPyramid版といったもので、 Viewを包み込んでリクエストの処理を行えます。

WSGIミドルウェアとの違いは、リクエストオブジェクトやレンダラーのようなPyramid機能を使えるというところ。

CSRF処理の追加や、リクエストオブジェクトへの情報付加など、いろんなことができますね。

route_prefixとtweenで、アプリケーションの拡張性や再利用性がぐんとあがったように思います。

そろそろ仕事で使ってもいいかもね。

https://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html

Permalink | Leave a comment  »