今日、TechCrunchに"iPadがAmazonのKindleを叩き潰す10の理由"という記事が投稿されました。
確かに、iPad、特に$489のモデルは、Kindleに対抗しえるものをいくつか持っています。しかし、たたきつぶせるのか？というと、私はそうは思えません。私が考える、iPadがKindleを倒せない10の理由を列挙します。
1) 価格: 比較対象となる値段は、$269のKindleと、$499のiPadです。$269のKindleは、本を読むという目的では非常に良くできています。もしもAmazonがKindleの値段を$199に落としてきたら・・・勝ち目はありません。
2) 電子インク: 読む楽しみを与えてくれます。これ以上言う必要はありませんよね？
3) グレア: iPadにはバックライトがあるので、長時間読書をする場合、目にやさしくありません。それに加えて、Kindleは直射日光下での読書もまったく問題ありません。ぜひiPadでもやってみてください。
4) 3G接続: Kindleには3G機能が内蔵されていて無料で使えます。月々の支払はずっと 無料です！しかも世界中で、です。まず、iPadの3Gオプションを選択すると、$130のコストが余計にかかります。さらに、その3Gを使用する場合には、AT&Tに毎月$30(あるいは$15)のお金を支払い続ける必要があります。iPadにはさらに３つのネガティブな要素、申し込みの苦労、コスト、AT&Tの接続性の悪さもかかってきます。
5) Amazon対iTunes: Amazonから多くの本をダウンロードすることができます。それはApple/iTunesという監獄につながれるということは永遠にありません。Appleはなんでもコントロールしたがります。そして、しばらくはその姿勢は変わらないでしょう。
6) サイズ: KindleはiPadよりも小さく、携帯性にすぐれています。ちょうど本を持ち運ぶような感覚で、簡単に持ち運びできます。iPadはポータブルではありますが、タブレットかラップトップを持ち運んでいる感覚でしょう。
7) 重さ: Kindleの0.6ポンド(292g)と比べて、iPadは1.5ポンド(680g)です。大抵、これに持ち運びやすさのための重さが追加されます(訳注：ケースとかのこと？)。そのため、Kindleは片手で疲れずに長時間持ち続けることができます。ぜひiPadで挑戦してみてください。
8) バッテリーの持続時間: Kindleは一回充電すると、軽々と2週間は使い続けることができます。これがKindleを長時間の飛行機の移動や、旅行などで本を読むには完璧なデバイスにしています。iPadのバッテリーは10時間持つとしていますが・・・ご存知の通り、実際のバッテリーはその半分ぐらいしか持たないでしょう。
9) タッチ: iPadはタッチデバイスです。そのため、読書をして、ページをめくる度に付く指の脂を常に掃除しなければならないでしょう。そのような問題はKindleにはありません。
10) 耐久性: 最後にになりますが、私は落としてスクリーンが壊れるような心配をすることなく、Kindleを5歳と10歳の子供に与えることができました。iPadの高価でもろいパネルではそうはいかないでしょう。実際、Kindleは、子どもたちが毎日持ち運ばなければならないような、重い教科書の代わりを完璧に努めてくれるでしょう。
どのように思われましたか？コメントとフィードバックをお待ちしています。
]]>クラウドコンピューティングは、エンタープライズのITの経済性を大幅に向上させるチャンスです。私たちは、より少ない投資で、本当に数多くのことができるようになります。
私は、エンタープライズITというのは、競争を勝ち抜くための武器であり、すべての業界において、業界のリーダーとなる企業は情報処理に対して、さらなる投資を行い続けるでしょう。それぞれの市場セグメントの中で一番となる会社は、その投 資のおかげで情報処理のエキスパートとなり、顧客についても良く理解して、サプライヤーの選択をするときにも適切な相手を選ぶことができるようになり、深い知識をもってサプライチェーンをコントロールできるようになり、驚くほど効率的な配送システムを構築するでしょう。情報処理への投資のおかげで、すべての仕事の質と効率が高められます。これらは、小売企業、金融系企業、油田開発企業、製薬業、スポーツチーム、ロジスティックスの企業などの未来の現実です。これらの現実から逃れられるセグメントはないでしょう。また、多くのセグメントは、もう現実となっています。競争相手以上のITへの投資というものが、唯一、顧客と株主へ報いる手段となっています。
私には、情報技術への投資こそが、すべての成功を収めた企業の未来につながる道であることは明らかです。また、現在もほぼそのような状態になっています。これに関して、朗報があります。コストをより低減し、効率的にして、環境への影響も少ない方法です。それはクラウドコンピューティングを利用することです。私たちは、より少ない投資で、本当に数多くのことができるようになります。
クラウドコンピューティングに関する議論は業界レベルでは承認を獲得することができています。しかし、何人かの企業とアナリストはエンタープライズのITインフラの経済性を向上させる方法として、プライベートクラウドというものにこだわっています。私の感覚では、歩き出す方向性としては正しいと思うのですが、規模の経済によって受ける恩恵は、リアルはクラウドコンピューティングよりも効果が低いと考えています。違いはなんでしょうか？スケールの面で、理想スを共有する枠組みの範囲内であれば、よりよいサービスを少ないコストで使うことができるようになります。高性能なリソースも使用ができます。コストと、リソースの利用の利点については、後ほど詳細に見て行きます。
大規模なスケールにおいては、配電、機械システムのエキスパートのチームを持つことが、手頃な値段と性能を獲得するための手段となります。主要なクラウドコンピューティングのプロバイダーは、これらのチームを持ち、コストを下げたり効率を上げたりして、より環境に良いと言えるように、新しい技術に投資をしています。10数メガワット未満では、スケールさせてもコスト・効率を良くして行くのは難しいです。同じような議論を他のドメインにも広げると、クラウドコンピューチングのプロバイダーは、サーバおよび記憶装置に特化したチームを持っているでしょう。彼らはネットーワークに関するハードとソフトウェアに深く投資をしています。これらはすべて、プライベートクラウドの範囲のスケールでは正当化しにくいものです。
クラウドコンピューティングのプロバイダーには、24時間、年中無休でサービスをモニターしたり、顧客の問題に対応するスタッフを抱えています。サービスのモニターを行うというのは、極めて難しいことです。数メガワット以下の規模で、それらをうまく行っている例を私はまだ見たことがありません。
クラウドコンピューティングのプロバイダーには、世界で最も優秀な、分散システムの専門家が何人も所属しています。オープンソースに関するエキスパートもいて、オープンソースと、内部で作成したソフトウェアの両方に対して、深く依存しています。このようにしている理由には２つあります: 1) 高度にスケールすると、今まで全く考えていなかった、ワクワクするような理由でシステムが失敗しますが、その際にうまく扱えるかどうかは、ハードウェアとソフトウェアの両方に関する深い知識があるかどうかにかかっていて、 2) 効率のために高度にスケール場合には、ほとんどのクラウドサービスのすばらしい経済性を達成するには、ソフトウェアのライセンスのコストとは両立しないからです。
リソースの活用というのは、未だに、高度にスケールした共有のインフラ上のクラウドに移行が行われるだろう、ということに対しての、強い論拠になっています。スケールにおいては、顧客の多様性が高ければ、クラウドの素晴らしい特性である、「相互に関連のないピーク」が現れます。会社ごとに、ピークの負荷に耐え切れる能力を供給しなければなりませんが、共有されたクラウドで実行されていれば、負荷のピークと底の間で、スムーズに実行が行えます。11月の販売のピーク、4月の税金のピーク、4半期の終わりごとの金融ビジネスのピークなど、これらの多くの負荷はそれぞれ毎日、週ごと、年ごとなどのサイクルを持っていて、それらを重ねあわせになります。例えば、マイケル・ジャクソン死去のニュースは、いくつかの領域で重い負荷を与えることになりましたが、ほとんどなかった領域もあるでしょう。東海岸の巨大な嵐のニュースは、いくつかのビジネスでは大規模なピークを与えることになりますが、ほとんどなかったという企業もあるでしょう。大量の多様な負荷をまとめて考えると、少ししかスケールできない場合よりも、利用レベルが平均的に高いレベルになるという傾向があります。プライベートクラウドでは、共有クラウドで達成されているような、高い利用レベルは達成することができません。
先週、Alistair Croll氏はInformationWeekに素晴らしい記事を書きました。
正しいクラウドの利用者には必ずコスト面でのアドバンテージがあります。なぜな ら、クラウドの利用者全員がいつも注目しているのはコストだからです。また、彼 らは消費者により近い位置にいます。というのも、どこにでもプログラム運用計画 (POP)があり、コンテンツ配信システムとパートナーシップを結んでいるからで す。消費者とパートナーを結びつけるということは、エンタープライズのIT戦略に おいて、ますます不可欠な部分になっていくでしょう。プライベートなクラウドを見ると、固定化していて、未来はありません。
プライベートクラウドへの投資は、一時的な対処法で最終目的地である、共有クラウドにたどり着くのを遅くする以上の価値はありません。プライベートクラウドで行くという決定は、利用レベルを低く使用という決定であり、多くのパワーを無駄に消費します。環境面での効果も低下し、高いコストがかかります。
]]>訳注: -compiler attributeは、プログラミングErlangに準拠して、「モジュール属性」と しています。termはそのままtermとしています。
EEP: 8 Title: 型と関数の仕様定義 Version: $Revision: 52 $ Last-Modified: $Date: 2008-10-30 15:20:25 +0100 (Thu, 30 Oct 2008) $ Author: Tobias Lindahl [tobias(dot)lindahl(at)it(dot)uu(dot)se], Kostis Sagonas [kostis(at)it(dot)uu(dot)se] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2-Dec-2007 Erlang-Version: R12B Post-History:
このEEPは、ある型や、効率的にすべてのErlangの語彙(term)のサブタイプを 宣言するためのErlang言語拡張について説明します。これらの型は、レコードの フィールドや、関数の引数、返り値で使用することができます。
型情報を利用することで、関数のインタフェースを説明したり、 Dialyzerなどのバグ検出ツールに対してより詳しい状況説明を提供したり、 Edocなどのさまざまな形式でプログラムのドキュメントを生成することができる、 ドキュメンテーションツールが詳しい情報を取得できるようになります。 このドキュメントで説明している型システムに期待されることは、Edocで使用されている、 @typeや@specなどのコメントベースの説明よりも使われるようになって、置き換わることです。
型はErlangのtermのセットに対して説明します。型は、既定の型の集合で構成され、 組み立てられます。既定の型というのは、integer(), atom(), pid()などになります。これについては、後ほど説明します。 既定の型は、これらの型に属す、Erlangのtermの集合によって表現されます。 たとえば、atom()はアトムの集合を意味します。
数値とアトムのシングルトン型としては、数値の-1, 42、あるいはアトム の'foo', 'bar'が該当します。
他のすべての型は、既定の型、もしくはシングルトン型の集合を使って組み立てていきます。 もし、あるタイプと、そのサブタイプの両方を構成要素とする型があったとすると、 サブタイプは吸収されてなくなり、そのサブタイプは、 集合の要素として最初から定義されていなかったかのように扱われます。 例えば以下のような集合があったとします。
atom() | 'bar' | integer() | 42
これは以下のtermのセットで定義された型集合と同じ意味になります。
atom() | integer()
型同士の間にあるサブタイプの関係により、 すべてのErlangのtermを含む最上位要素のany()から、 termの空集合を表す最下層の要素の``none()``との間で、 すべての型はラティス構造を形成します。(訳注：完全な木構造にはならない、という意味だと思われる)
以下に示されているが、既定の型の集合です。また、 型に関するシンタックスについても示します。
Type :: any() %% トップの型。すべてのErlangのtermを含む
| none() %% 最下層の方。termを含まない
| pid()
| port()
| ref()
| [] %% nil
| Atom
| Binary
| float()
| Fun
| Integer
| List
| Tuple
| Union
| UserDefined %% ユーザ定義型の項で説明する
Union :: Type1 | Type2
Atom :: atom()
| Erlang_Atom %% 'foo', 'bar', ...
Binary :: binary() %% <<_:_ * 8>>
| <<>>
| <<_:Erlang_Integer>> %% 基数(Base size)
| <<_:_*Erlang_Integer>> %% 単位サイズ(Unit size)
| <<_:Erlang_Integer, _:_*Erlang_Integer>>
Fun :: fun() %% あらゆる関数
| fun((...) -> Type) %% あらゆる引数と返り値のタイプ
| fun(() -> Type)
| fun((TList) -> Type)
Integer :: integer()
| Erlang_Integer %% ..., -1, 0, 1, ... 42 ...
| Erlang_Integer..Erlang_Integer %% 整数の範囲を示したもの
List :: list(Type) %% Proper list ([]-終端)
| improper_list(Type1, Type2) %% Type1=中身, Type2=終端
| maybe_improper_list(Type1, Type2) %% Type1とType2は↑と同様
Tuple :: tuple() %% あらゆるサイズのタプルに適合
| {}
| {TList}
TList :: Type
| Type, TList
リストは一般的によく使用されるため、リストには短縮型表記法がいくつか設定されています。 list(T) は短縮して、 [T] と書くことができます。 [T,...] という短縮形はT型の要素を持つ、空でないリストを表します。 [T]と[T,...]の唯一の違いは、 [T]は空のリストになる可能性があるが、 [T,...]は空になることはないという点だけです。
注意して欲しいのは、 list() の短縮形、 つまり未知の型を要素に持つリストの短縮形は [_](あるいは[any()])になります。[]ではありません。 []という表記は、空のリストに対するシングルトン型を表します。
表記を便利にするために、以下のような型も組み込みで定義されています。 表の中の型の集合に対する、定義済みの別名として、見ることができます。 いくつかの型の集合は、これからの説明の中で頻繁に使います。
| 組み込み型 | 同値の定義 |
|---|---|
| term() | any() |
| bool() | 'false' | 'true' |
| byte() | 0..255 |
| char() | 0..16#10ffff |
| non_neg_integer() | 0.. |
| pos_integer() | 1.. |
| neg_integer() | ..-1 |
| number() | integer() | float() |
| list() | [any()] |
| maybe_improper_list() | maybe_improper_list(any(), any()) |
| maybe_improper_list(T) | maybe_improper_list(T, any()) |
| string() | [char()] |
| nonempty_string() | [char(),...] |
| iolist() | maybe_improper_list( char() | binary() | iolist(), binary() | []) |
| module() | atom() |
| mfa() | {atom(), atom(), byte()} |
| node() | atom() |
| timeout() | 'infinity' | non_neg_integer() |
| no_return() | none() |
既定の型、および、組み込み型と同じ名前の型をユーザが定義することはできません。 これはコンパイラによってチェックされ、問題があれば、 コンパイルエラーとして結果が通知されます。 最初に説明した目的のために、もし組み込み型に対して同様のことを行った場合には、 警告が発生します。
また、便利に使うために、レコード記法も使用できるようになっています。 レコードは対応するタプルを短く書く記法になります。NOTE: 以下のような組み込みのリスト型も存在しますが、 ほとんど使われないことを想定しています。そのために長い名前がついています。
nonempty_maybe_improper_list(Type) :: nonempty_maybe_improper_list(Type, any()) nonempty_maybe_improper_list() :: nonempty_maybe_improper_list(any())以下の二つのは型は期待されるErlangのtermのセットを定義するのに使用されます(訳不安)。
nonempty_improper_list(Type1, Type2) nonempty_maybe_improper_list(Type1, Type2)
Record :: #Erlang_Atom{}
| #Erlang_Atom{Fields}
レコードは型情報も入れることができるように拡張されました。これについての詳 細はレコード宣言の中の型情報にて説明していきます。
今までに見てきたように、型の基本的なシンタックスは丸括弧が後ろについたアトムになります。 'type'コンパイラ属性を利用して新しい型を宣言する方法は以下のようになります。
-type my_type() :: Type.
型名は、後ろに丸括弧のついたアトム(この例では 'my_type')になります。 Typeは今までのセクションで説明してきたような型です。現在の制限としては、 Typeに指定できるのは、既定の型、もしくはそれまでに出てきたユーザ定義型 のみになります。この制限に引っかかると、コンパイルエラーとして通知されます。 同様の制限がレコードに関しても存在します。
この制約があるために、現在では、再帰的な型の定義を一般的に行うことはできません。 この制約をどのようにはずしていくか、ということに関しては今後の課題になります。
型宣言では、型変数を丸括弧の中に含めることによりパラメータ化することもできます。 型変数を使うための文法は、Erlangの変数と同じで、最初の文字を大文字から開始します。 当然、これらの変数は、宣言の右側に書くことができますし、書かなければなりません。 具体的なサンプルを以下に示します。
-type orddict(Key, Val) :: [{Key, Val}].
レコードに含まれる、フィールドの型についても、レコード宣言の中で定義するこ とができます。
-record(rec, {field1 :: Type1, field2, field3 :: Type3}).
型の指定がないフィールドは、デフォルトではany()の型であるという扱いになります。上記のサンプルは以下の書き方を省略したのと同じになります。
-record(rec, {field1 :: Type1, field2 :: any(), field3 :: Type3}).
フィールドの初期値がある場合には、以下のように初期化が終わった後に型宣言を 置く必要があります。
-record(rec, {field1 = [] :: Type1, field2, field3 = 42 :: Type3}).
当然のことながら、フィールドの初期値は、指定された型(複数選択肢がある場合はそのひとつに) に準拠した値である必要があります。これはコンパイラによってチェックされ、 問題があれば、コンパイルエラーになります。初期値が存在しないフィールドについては、 'undefined'というシングルトン型がすべての型宣言に対して追加されます。 実際の例で説明すると、次に説明する２つのレコードは、処理系の中では、 まったく同じものとして扱われます。
-record(rec, {f1 = 42 :: integer(),
f2 :: float(),
f3 :: 'a' | 'b').
-record(rec, {f1 = 42 :: integer(),
f2 :: 'undefined' | float(),
f3 :: 'undefined' | 'a' | 'b').
これらの理由から、可能な場合には常に、レコードの初期化を行うことをお勧めします。
あらゆるレコードは、型情報を持つか持たないか、のどちらかになります。一度定義すると、 下記のようなシンプルなシンタックスで型を使用することができます。
#rec{}
さらに、レコードのフィールドは使用時にも仕様を設定することができます。 レコード型を使用するときに、以下のようにフィールドに関する型情報 を足すことで、指定することができます。
#rec{some_field :: Type}
この場合、型情報が設定されなかったフィールドに関しては、オリジナルの レコード宣言の情報が設定されているものとして実行します。
新しいモジュール属性の ``'spec'`` を使用することで、関数の契約(あるいは仕様) を記述することができます。基本的な書き方のルールは以下のようになります。
-spec Module:Function(ArgType1, ..., ArgTypeN) -> ReturnType.
関数の引数の数は、実際の関数と、使用の宣言で一致している必要があります。 もし一致しない場合には、コンパイラエラーになります。
この形式の書き方はヘッダファイル(.hrl)の中で、エクスポートされた関数の型情報 を宣言するのにも使用することができます。これらの情報が書かれたヘッダファイル をインクルードすると、これらの関数がインポートされて(場合によっては暗黙的に インポートされる場合もあります)使用できるようになります。
モジュール内部だけで使用する場合には、ほとんどの場合は下記のような、モジュール名を 省略した短縮系で使用されます。
-spec Function(ArgType1, ..., ArgTypeN) -> ReturnType.
また、ドキュメント化する目的で、引数に名前を設定することもできます。
-spec Function(ArgName1 :: Type1, ..., ArgNameN :: TypeN) -> RT.
関数定義は、オーバーロードさせて、複数のタイプを持たせることができます。 その場合は、セミコロン(;)を使用して、それぞれのパターンを区切って指定します。
-spec foo(T1, T2) -> T3
; (T4, T5) -> T6.
現在の制限としては、引数の型がオーバーラップしていると、コンパイラが 警告を発します。エラーにはなりません。例えば、以下のような仕様定義を すると警告が発生します。
-spec foo(pos_integer()) -> pos_integer()
; (integer()) -> integer().
型の変数を使って、関数の入出力の引数関係の定義を行うことができます。 以下のサンプルでは、ポリモーフィックな識別を行う関数の定義を行っています。
-spec id(X) -> X.
しかし、上記の定義では入力と出力の型について制約を与えることはできません。 ガードのように、特定の型のサブタイプであるという制約をかけるやり方を使用することができます。
-spec id(X) -> X when is_subtype(X, tuple()).
数量の境界に関しても、制約をかけることができます。現在は、 is_subtype/2ガードは、'spec'属性中でのみ使用することができます。
is_subtype/2制約のスコープは、それが適用された後の (...) -> RetType定義までになります。混乱を避けるために、 以下のような引数のオーバーロードがある場合には、それぞれの制約の定義では、 それぞれ別の変数を使用することをおすすめします。
-spec foo({X, integer()}) -> X when is_subtype(X, atom())
; ([Y]) -> Y when is_subtype(Y, number()).
Erlangの関数の中には値を返さない物もあります。サーバを定義するものであったり、 以下のように例外を投げるのに使用される関数であったり、というのが主要なケースです。
my_error(Err) -> erlang:throw({error, Err}).
このような関数においては、no_return()という特殊な返り値を返すものとして、定義することをおすすめします。
-spec my_error(term()) -> no_return().
現在の使用の一番大きな制約は、再帰を用いた型の定義ができないことです。
このドキュメントはパブリックドメインです。
]]>原著者：Copyright 2004-2009 Mikael Remond, Richard Carlsson
原文：http://erlang.org/doc/apps/eunit/
原文更新：2009
EUnitはErlang用のユニットテストフレームワークです。とてもパワフルで柔軟かつ、使用するのが簡単であり、構文上のオーバーヘッド(書かなければいけないもの)が少ないのが特徴です。
EUnitは、ケント・ベックと、エリック・ガンマが作成したJUnit(と、ケント・ベックがそれ以前に作成した、Smalltalk用のSUnit)を起源とする、オブジェクト指向言語用のユニットテストフレームワーク群から来たアイディアを元に開発されています。しかし、EUnitは、より関数型プログラミングと、並列プログラミングに適応するような技術が使用されています。また、関連するフレームワーク群よりも、言葉数が少なくて済むことが多いです。
EUnitは多くのプリプロセッサマクロを使用しますが、利用者にできるだけ負担をかけないように設計されています。また、既存のコードと衝突を起こさないように設計されています。モジュールにEUnitのテストを追加する際には、通常は既存のコードに変更を加える必要がありません。これに加え、モジュールのエクスポートされた関数をテストするだけであれば、いつでも、完全に分割したモジュールにテストをおくことができます。何らかの衝突が起きることはありません。
ユニットテストは、お互いに分離されている「ユニット」という単位で個別にテストを行う方法です。ユニットは特定のサイズにしなければならない、ということはありません。ユニットが一つの関数であることもあるし、モジュールを示すこともあります。またプロセスはアプリケーション全体を一つのユニットと呼ぶこともあります。が、多くのケースにおいては、テストを行うユニットは、複数の関数、もしくはモジュールであることが多いです。ユニットをテストするためには、個別のテストをいくつか用意したり、これらのテストを実行するのに必要な最小限の環境を作るためのセットアップ(通常、設定が必要でないケースがほとんどですが)を行ったり、テストを実行して結果を収集したり、後でテストを再実行するために最後に必要となる片付けを行ったりします。ユニットテストのフレームワークを使用することで、これらのプロセスのそれぞれの段階の作業を軽減することができて、テストを書くのがラクになります。そしてテストを実行するのも簡単になり、どのテストが失敗したかが簡単に確認できるようになり、バグを修正することができるようになります。
ほとんどのプログラムは、作成されてから破棄されるまでの間に変更されるでしょう。バグがあれば修正され、機能が追加され、必要になれば最適化が行われ、また、リファクタリングやコードの整理が必要となれば、同じ機能を達成するやり方の別の方法に修正されます。しかし、動作しているプログラムに対して、これらの変更を加えることは、新しいバグや、既に修正済みのバグを再び入れ込んでしまうリスクを常に孕んでいます。少ない手間ですぐに実行できるユニットテスト群があれば、簡単にコードが期待通りに動作するかどうかを知ることができます。このようなテストをリグレッションテストあるいは、回帰テスト(用語集を参照)と呼ばれます。これは、コードの変更や、リファクタリングをする抵抗を減らすのに役に立ちます。
テストをパスするコードを開発するのにフォーカスするため、プログラマはより生産的になります。仕様以上に作り込んでしまうこともなくなりますし、不必要な最適化をしてしまうことも防げます。最初から正しいコードを作成することができるようになります。これはテスト駆動開発と呼ばれます(用語集を参照)。
テストを書いている時に、テストの実行とは関係のない、そこにあるべきではない依存関係があるのを見つけるかもしれません。よりクリーンな設計をするためにこのような依存関係は取り除く必要があります。早めにこのような依存関係を切っていくことで、コード中に悪い依存関係が広がっていくのを未然に防ぐことができます。
ボトムアップでテストをしていくことで、小さいプログラムのユニットから開発を開始することができ、期待通りに動作するという信頼性も生まれます。これにより、テスト済みのユニットを組み合わせて作る、上位のレベルの部品が仕様通りに動作するかのテストも簡単になります。これは統合テスト(用語集参照)と呼ばれます。
テストはドキュメントとしても読むことができます。テストを見れば、正しい使用法と、正しくない使用方法、そして期待される結果が分かります。
プログラムユニットが、仕様に従って、期待通りに動作するかどうかのテストになります。ユニットテストは、リグレッションテストを書く場合にも重要な構成要素となります。リグレッションテストというのは、何らかの理由でコードが変更された場合に、仕様通りの動作を保っているかどうかをチェックするものになります。
プログラムに変更を加えたあとにテストを実行し、以前と同じようにプログラムが動作するかどうかチェックすることです。もちろん、意図して変更した振る舞いは除きます。ユニットテストはリグレッションテストとして重要ですが、リグレッションテストは単にユニットテストの範疇に収まるものではありません。バグや互換性など、テストの振る舞いは通常の仕様とは異なるものです。
個別に開発されたプログラムのユニット(それぞれのユニットは個別にユニットテストされているものとします)を統合したときに、期待通りに動作するかどうかをテストすることを指します。システムの開発された方法により、統合テストは単に「階層の違うユニットテスト」と同等の場合もありますが、他の種類のテストも含みます。システムテストとの違いを確認してください。
すべてのユニットを組み合わせた完全なシステムが、仕様通りに動作するかどうか検証します。具体的には、システムテストでは実装の詳細の知識が要求されるようなものであってはいけません。システムテストには、基本的な機能性とは別に、様々な異なる側面から見たシステムの振る舞いに関するテストを含みます。例えば、パフォーマンスや、ユーザビリティ、信頼性などになります。
テストを実装コードよりも先に書いて、その後にテストをパスする最小の実装を行うことによりソフトウェアを開発していくという、プログラム開発テクニックです。この方法を使うと、正しい問題を解決することにのみフォーカスします。そして、ユニットテストによって、そのプログラムが完了した後の姿を決定することで、必要以上に実装が複雑になることを防ぎます。もしテストをパスして仕様を満足したあとは、それ以上機能を追加する必要はないのですから。
他のユニットB(引数として渡されるか、参照される)と何らかの連携を行う必要のある、ユニットA(例えば関数)をテストする必要があり、なおかつユニットBの実装が完了していない、というケースが時々あります。この場合に、ユニットAをテストするために、本物のBと同じような振る舞いをするニセ者を代わりに利用することがあります。これを「モックオブジェクト」と呼びます。もちろん、これは本物のユニットBを実装する方が、モックオブジェクトを作るよりも大変である場合にのみ役立ちます。
明確に定義され、識別可能なテストの最小単位です。実行されると、テストケースはパスするか、失敗するかのどちらかになります。テストのレポートでは、どのテストケースが失敗したか明確に区別されなければなりません。
テストケースを集めたものになります。一般的には、とある関数や、モジュール、サブシステムなど、共通のターゲットに対するテストを集めたものになります。テストスイートは、他の小さなテストスイートを含んだ、再帰的な構造として作成することもできます。
EUnitをErlangのモジュールで使用する、一番簡単な方法は、モジュールの先頭(-module宣言の直後で、他の関数宣言の前)に以下の行を追加するやり方になります。
-include_lib("eunit/include/eunit.hrl").
この行を追加すると以下のような効果が現れます。
Note: -include_lib(...)が実行可能になるためには、Erlangのモジュールサーチパスにはeunit/ebinで終わる名前を持つディレクトリ(EUnitインストールディレクトリのebinサブディレクトリ)が含まれる必要があります。もし EUnitが lib/eunitのような、Erlang/OTPのシステムディレクトリにインストールされている場合には、ebinサブディレクトリはErlangの起動時に自動的にサーチパスに追加されます。そうでない場合には、erlコマンド、もしくはerlcコマンドに-paフラグを渡して、サーチパスにきちんと追加する必要があります。例えば、.erlファイルをコンパイルするアクションがMakeファイルに書かれていたとすると、以下のように書きます。
erlc -pa "path/to/eunit/ebin" $(ERL_COMPILE_FLAGS) -o$(EBIN) $<
あるいは、Erlangをインタラクティブに実行する場合に、常にEUnitを有効にしたい時には、$HOME/.erlangファイルに以下の行を追加します。
code:add_path("/path/to/eunit/ebin").
EUnitフレームワークはErlangでユニットテストを書くのをとても簡単にしてくれます。テストを書く方法は何通りかありますが、まずは一番簡単なやり方から開始します。
EUnitは、名前の最後が_test()で終わる、引数のない関数をシンプルなテスト関数であると認識します。任意の値(EUnitが破棄してしまいますが)を返すとテストは成功とみなされます。また、なんらかの例外を投げる(ただし中断しない)場合には失敗したとみなされます。実行が中断すると、テストの実行自体が途中終了します。
以下のコードが、シンプルなテスト関数の例になります。
reverse_test() -> lists:reverse([1,2,3]).
このテストは、[1, 2, 3]というリストに対して、lists:reverse(List)を実行するとクラッシュはしない、というテストになります。これはすばらしいテストとは言えませんが、多くの人がこのようなシンプルな関数を書き、自分のコードの基本的な機能性をテストしています。これらのテストはコードを変更しなくても、名前がマッチすればEUnitから直接使用されます。
失敗を表すためには例外を使用します。そうすることで、より詳しいテストを書くことができます。もし期待していない結果が得られた場合には、クラッシュさせて例外を投げる必要があります。一番簡単な方法は = を使ったパターンマッチを使用する方法です。
reverse_nil_test() -> [] = lists:reverse([]). reverse_one_test() -> [1] = lists:reverse([1]). reverse_two_test() -> [2,1] = lists:reverse([1,2]).
もし lists:reverse/1 に何かバグがあり、[1, 2]という入力に対して、 [2, 1]以外の結果を返した場合には、上記の最後のテストはbadmatch errorを投げます。最初の二つ(badmatchが得られなかったとすると)はそれぞれ単純に [] と [1] を返し、成功したことになります。EUnitは魔法使いではないので、比較値を書かない場合には、値を返すテストを書いて、もしそれが間違った値だったとしても、EUnitは成功したとみなします。もし返り値が仕様通りでない値を返した場合にはクラッシュするようなテストを書く必要があります。
assertマクロの使用: もしBoolean演算をテストで使用したい場合には、assertマクロを使うのが手軽です(詳しくはEUnitマクロを参照)。
length_test() -> ?assert(length([1,2,3]) =:= 3).
?assert(Expression) というマクロは式を評価します。そして評価した結果がtrueでない場合には、例外を投げます。そうでない場合にはokを返します。上記の例では、 lengthを呼び出した結果が3を返さなかった場合に失敗します。
もし前の説明に書いたように -include_lib("eunit/include/eunit.hrl") 宣言をモジュールに付けた時には、モジュールをコンパイルするだけで大丈夫です。自動的にエクスポートされた test() 関数を実行します。例えば、m という名前のモジュールを作ったとしたら、 m:test() がEUnitを実行し、モジュールの中で定義されたすべてのテストを実行します。テストの関数に対して、 -export 宣言を付ける必要はありません。魔法によって、これらはすべて自動的に行われます。
eunit:test/1関数を使用することで、各々のテストを実行することもできます。例えば、より進んだテストデスクリプタ( EUnitテスト表現を参照)を使用したい場合などです。例えば、eunit:test(m) を実行するのは、自動生成された m:test()を実行するとの同等です。また、 eunit:test({inparallel, m}) を実行すると、同じテストケースを実行しますが、それぞれのテストは並列で実行されます。
通常のコードと、エクスポートされた関数に対するテストコードを分けたいとします。このような場合には、もしモジュールの名前がmであったとすると、テスト関数をm_tests(m_testではなく複数形)というモジュールの中に書くことができます。EUnitにモジュールmをテストするように指示した場合、m_testsというモジュールを探しにいって、この中に定義されたテストが実行されるようになります。モジュール名に関してはプリミティブというところで詳しく説明します。
もしテストコードが標準出力に何かを書き出したとすると、テストが実行されたときにコンソールに何もテキストが表示されないのを見て驚くでしょう。これはEUnitがテスト関数から出力される、すべての標準出力の結果をキャプチャーしているからです。これにはセットアップ、クリーンナップの関数も含まれますが、ジェネレータ関数は含まれません。そして、この結果は、エラーが発生した場合に、テストレポートの中に出力されます。テストの実行中にEUnitを迂回して、テキストを直接コンソールに書き出したい場合には、io:format(user, "~w", [Term])というユーザ出力ストリームを利用することができます。推奨される方法としては、EUnitのデバッグマクロを使用することで、シンプルに書くことができます。
シンプルなテストを書く際に障害となるのは、テストケースごとに別々の名前を持った、個別の関数を書く必要があるということです。テストを書くためのコンパクトで、より柔軟な方法は、テストそのものを書くのではなく、テストを返す関数を書くことです。
EUnitは、_test_()(最後のアンダースコアが大切)という名前で終了する関数を、テストジェネレータ関数として扱います。テストジェネレータは、EUnitで実行することができるテスト群のの表現を返します。
基本的なテスト表現は、テストは引数のない１つのfun式で表されます。例えば、以下のようなテストジェネレータを作成することができます。
basic_test_() ->
fun () -> ?assert(1 + 1 =:= 2) end.
このジェネレータは、以下のようなシンプルなテストと同じ結果になります。
simple_test() ->
?assert(1 + 1 =:= 2).
実際には、EUnitは内部ではすべてのシンプルなテストをfun式として扱います。これらの式をリストの中に格納して、一つずつ実行します。
テストをよりコンパクトで読みやすく書くためには_testマクロ(先頭のアンダースコアを忘れずに)を使用することができます。このマクロは、テストが書かれているソースコード内の行番号の情報を自動的に付加し、タイプ数を節約できます。
basic_test_() ->
?_test(?assert(1 + 1 =:= 2)).
_testマクロは引数としてあらゆる式(テスト本体)を受け取り、それを追加の情報とともにfun式の内部に格納した状態で展開されます。本体は、シンプルなテスト内に書くように、テストを表す式なら何でも指定することができます。
上記の例はもっと短くすることができます。マクロ名の前にアンダースコアがついたassertマクロ群などのほとんどのテストのためのマクロは、自動的に?_test(...)ラッパーを付加します。上記の例はもっとシンプルに以下のように書くことができます。
basic_test_() ->
?_assert(1 + 1 =:= 2).
_assertマクロを、assertマクロの代わりに使用することで、まったく同じ文となります。最初にアンダースコアがついたマクロはテストオブジェクトを表す記号として見ても差し支えありません。
１つのサンプルは百聞にしかず。以下の小さなErlangモジュールはEUnitを実践の中でどのように使用できるのかということを示しています。
-module(fib).
-export([fib/1]).
-include_lib("eunit/include/eunit.hrl").
fib(0) -> 1;
fib(1) -> 1;
fib(N) when N > 1 -> fib(N-1) + fib(N-2).
fib_test_() ->
[?_assert(fib(0) =:= 1),
?_assert(fib(1) =:= 1),
?_assert(fib(2) =:= 2),
?_assert(fib(3) =:= 3),
?_assert(fib(4) =:= 5),
?_assert(fib(5) =:= 8),
?_assertException(error, function_clause, fib(-1)),
?_assert(fib(31) =:= 2178309)
].
著者のメモ: 初めてこのサンプルを書いた際に、fib関数の中の+演算子の代わりに、間違って*演算子を書いてしまいました。もちろん、テストを実行したらすぐに間違ったことが分かりました。
EUnitでテストを定義するすべての方法を表したリストを見るためには、EUnitテスト表現を見てください。
コンパイル時にNOTESTマクロを定義することでテストを除外することができます。erlcのオプションとして指定するには以下のように書きます。
erlc -DNOTEST my_module.erl
コード中に書く際は、EUnitヘッダファイルをインクルードするよりも前に、以下のマクロ定義を書きます。
-define(NOTEST, 1).
定義する値は重要ではありませんが、1かtrueを良く使用します。EUNIT_NOAUTOマクロが定義されない場合には、明示的にエクスポートされているものを除いて、すべてのテスト関数を自動的に削除し、テストを無効にします。
実際にEUnitをアプリケーションの中に実際に使用するが、デフォルトではテスト機能をオフにしたい場合には以下のようにヘッダファイルに書きます。
-define(NOTEST, true).
-include_lib("eunit/include/eunit.hrl").
このヘッダファイルがすべてのモジュールにインクルードされているものとします。一カ所だけを修正することで、テストのデフォルト設定を変更することができるようになります。また、NOTESTの定義はコードを修正しなくても上書きできるようになっています。一時的にテストを有効にするためには、TESTをコンパイラオプションとして定義します。
erlc -DTEST my_module.erl
これらのマクロの詳細については、コンパイル制御マクロを参照してください。
もし、自分で作ったソースコードを配布して、他のユーザが自分のアプリケーションに組み込み、コンパイルして実行しようとしているとしたら、EUnitが手に入らなかったとしてもコードがコンパイルできるようにしたいと思いますよね？前の方のセクションで出てきたサンプルを参考に、共通ヘッダファイルに以下のようなコードを書くことができます。
-ifdef(TEST).
-include_lib("eunit/include/eunit.hrl").
-endif.
もちろん、EUnitのマクロを使用する、すべてのテストコードは、-ifdef(TEST)、あるいは、-ifdef(EUNIT) セクションの中に書くようにします。
EUnitのすべての機能はプリプロセッサマクロを使用しなくても使用できますが、EUnitのヘッダファイルには、ユニットテストを書くのを簡単にするためのマクロが数多く定義されています。これを使用すると、詳細まで書かなくても、可能な限り短いコードになります。
明確に定義されているものを除いて、EUnitのマクロを使用しても、EUnitのライブラリコードへの実行時の依存関係は発生しません。これは、コンパイル時にテストが有効になっているか、無効になっているか、というのには依存しません。
式をテストオブジェクトに変換します。テストオブジェクトはfun式でラップされ、ソースファイルの行番号が付加されます。技術的には、{?LINE, fun () -> (Expr) end}と書くのと同一です。
このマクロはコンパイル時にEUnitが有効な時にはいつでも定義されています。このマクロは、以下のようにテストコードを条件コンパイル内に置くときに使用します。
-ifdef(EUNIT).
% ここにテストコードを書く
...
-endif.
例えばテストが無効になっているときには、EUnitヘッダファイルをインクルードしないでコンパイルされることもあります。TEST, NOTESTの項目も参照してください。
このマクロが定義されると、自動的にテスト関数をエクスポートする機能が無効になります。
このマクロは、コンパイル時にEUnitが有効になっている場合にはいつも定義されます。ユーザが自分で別の値を定義した場合を除いて、trueとして定義されます。このマクロはテストコードを条件コンパイルする際に使用することができます。NOTEST, EUNITの項目も参照してください。
EUnitに依存しているテストコードについて条件コンパイルする場合には、EUNITマクロを使用する方が望ましいです。TESTマクロはもっと一般的なテスト条件に使用されます。この場合はTESTマクロの方が望ましいでしょう。
TESTマクロは、TOTESTマクロを上書きすることができます。NOTESTが定義されていたとしても、EUnitヘッダファイルがインクルードされる前にTESTが定義されていれば、EUnitは有効な状態でコンパイルされます。
このマクロは、EUnitがコンパイル時に無効になっている場合にはいつも定義されます。ユーザが自分で別の値を定義した場合を除き、trueとして定義されます。TESTマクロと比較してみてください。
このマクロは条件コンパイルにも使用することができますが、一般的にはテストを無効化用途に使用します。EUnitヘッダファイルをインクルードする前にNOTESTが定義されていて、なおかつTESTが定義されていない場合には、EUnitが無効の状態でコンパイルされます。テストの無効化も参照してください。
このマクロは、テストが無効になっていて、assertマクロを使用しても無効になる場合に定義されます。テストが有効な場合には、このマクロは常に自動的に有効になります。無効化することはできません。assertマクロの項も参照してください。
もしこのマクロが定義されていると、NOASSERTマクロを上書きします。他の設定によらず、常にassertマクロを有効にすることができます。
もしマクロが定義されていれば、デバッグマクロが動作しなくなります。詳しくはデバッグマクロの説明を見てください。NODEBUGを定義するとテストが定義されていたとしても、NOASSERTが定義されます。
もしこのマクロが定義されると、NODEBUGマクロの動作が上書きされます。デバッグ用のマクロを強制的に使用可能にします。
テストをより短く、読みやすくすることができます。
ローカルな、Expr内で、Var = Argというローカルな束縛を作成することができます。 (fun(Var)->(Expr)end)(Arg)と定義するのと同じです。この束縛はExprの外にはエクスポートされません。このVarに対する束縛は、使用されるスコープの他の束縛を邪魔することはありません。
もしCond式がtrueの場合にはTrueCaseが評価されます。そうでない場合はFalseCaseが評価されます。これは (case (Cond) of true->(TrueCase); false->(FalseCase) end).と同等です。Condはブーリアンの値でない場合にはエラーになります。
?_assert(BoolExpr)のような、"_"アンダースコアの文字から始まる名前のマクロも存在します。この形式のマクロは、テストを実行するだけでなく、"テストオブジェクト"も作成します。これは?_test(assert(BoolExpr))のように書くのと同じ動作をします。
もし、EUnitヘッダファイルがインクルードされる前にNOASSERTマクロが定義されると、テストも無効化されている時に、これらのマクロも空の実装に取り替えられます。詳細については、コンパイル制御マクロを参照してください。
テストが有効になっている場合に、BoolExpr式の評価を行います。結果がtrueでなければ、それを知らせる例外が生成されます。例外発生しなかった場合には、マクロ式の評価結果は、okというアトムになります。BoolExprの値は返されません。もしテストが無効な場合には、okアトムを返すコード以外は生成されません。BoolExprも評価されなくなります。
一番使用される方法は以下のようになります。
?assert(f(X, Y) =:= [])
このassertマクロは、ユニットテストの中だけでなく、どこでも使用することができます。以下のように、DbCで行う、事前条件/事後条件/不変条件のチェックにも使用することができます。
some_recursive_function(X, Y, Z) ->
?assert(X + Y > Z),
...
assert(not (BoolExpr))と同等です。
テストが有効になっている時に、Exprを評価し、結果がGuardedPatternに対して、マッチするかどうか検証します。もしパターンにマッチしなかった場合には、それを知らせる例外を生成します。このあたりの詳細はassertマクロの説明を見てください。GuardedPatternはcase構文の -> シンボルの左側に書くことができるものであれば、なんでも書くことができます。ただし、カンマで区切られたガードテストを含むものを除きます。
シンプルなマッチのテストでも、= ではなくて、assertMatchを使用すると、より詳細なエラーメッセージを生成することができます。
サンプル:
?assertMatch({found, {fred, _}}, lookup(bloggs, Table))
?assertMatch([X|_] when X > 0, binary_to_list(B))
テストが有効な場合に、ExpectとExprの両方の式を評価して、結果が等しいかどうか比較します。もし等しくなかった場合には、情報を伝える例外を生成します。詳しくはassertマクロの説明を見てください。
assertEqualは、左側の期待値がパターンではなくて、計算後の値である場合には、assertMatchよりも良いでしょう。また、?assert(Expect =:= Expr)よりも、詳しい説明が得られます。
サンプル:
?assertEqual("b" ++ "a", lists:reverse("ab"))
?assertEqual(foo(X), bar(Y))
Exprを評価して、その中で発生した例外をキャッチし、それが期待されたClassPattern, TermPatternと一致しているか検証します。マッチしないか、Exprを評価した中で例外が発生しなかった場合には、情報を伝える例外を生成します。詳しくはassertマクロの説明を参照してください。assertError, assertExit, assertThrowは、ClassPatternとしてerror, exit, throwを設定してassertExceptionを使用した場合と、それぞれ同一です。
サンプル:
?assertError(badarith, X/0)
?assertExit(normal, exit(normal))
?assertException(throw, {not_found,_}, throw({not_found,42}))
外部コマンドはOSに強く依存します。これらのマクロ以外にも、現在のOSに依存したテストを作成するために、標準ライブラリのos:type()をテストジェネレータ関数の中で使用することもできます。
注: これらのマクロはテストが有効な状態でコンパイルされると、EUnitのライブラリコードへの実行時の依存が発生します。
テストが有効な場合に、CommandStringを外部コマンドとして実行します。もし外部プログラムの返値がゼロでなかった場合には、それを通知する例外が生成されます。例外が発生しなかった場合には、マクロの式の結果は、okアトムになります。もしテストが無効化されている場合には、okアトムを返す以外のコードは生成されず、外部コマンドも実行されます。
一般的な使用法:
?assertCmd("mkdir foo")
assertCmd(CommandString)マクロと同様ですが、もしステータス値としてN以外の値が返されると例外を生成します。
テストが有効な時に、CommandStringを外部コマンドとして実行します。コマンドが出力したものが、指定した文字列のTextと一致しなかった場合には、違いの情報を伝える例外を出力します。どのようなプラットフォームでも、改行コードはLFに正規化されます。もし例外が発生しなかった場合には、このマクロはokアトムを返します。
CommandStringを外部文字列として実行します。返り値が0(成功を意味します)でなかった場合には、情報を伝える例外が生成されます。成功した場合には、このマクロは、コマンドが出力した物をフラットな文字列として返します。どのようなプラットフォームでも、改行コードはLFに正規化されます。
このマクロは、エラーが発生しても、テストをきちんと実行するために、ファイルの作成と削除、OS特有のタスクの実行などを、フィックスチャのセットアップ、片付けのセクションで使用するのが便利です。
UNIX環境で動作するサンプル:
{setup,
fun () -> ?cmd("mktemp") end,
fun (FileName) -> ?cmd("rm " ++ FileName) end,
...}
EUnitではいくつかのデバッグを補助するマクロを定義しています。これらを使うと、標準出力ではなく、直接コンソールにメッセージをひょうじすることができます。これらのマクロは同じ基本フォーマットを使用して出力されます。これにはデバッグマクロが実行されたファイル名、行番号が含まれ、開発環境(Emacsのバッファ内でErlangを実行している場合など)によっては、出力メッセージから、ソースコードの該当する行に直接ジャンプすることができます。
EUnitヘッダファイルがインクルードされる前にNODEBUGマクロが定義されると、これらのマクロは何もしなくなります。詳しくはコンパイル制御マクロの項目を見てください。
コンソールに現在のファイルと行番号を表すマーカーを表示するだけのマクロです。このマクロは引数を取りません。結果は常にokとなります。
Textをメッセージとして出力します。Textはプレーンな文字列、IOリスト、アトムが使用可能です。実行結果は常にokとなります。
このマクロは、テキストをio:format(FmtString, Args)と同様にテキストをフォーマットして、debugMsgと同じように出力します。結果は常にokとなります。
Exprに対するソースコードと、現在の値の両方を出力します。例えば、?debugVal(f(X))は"f(X) = 42"と表示されます。(ほとんどの単語は切り詰めて表示されます)。評価結果はExprの値となります。そのため、デバッグ機能を有効にしてコンパイルされている時には、このマクロで式(式が使える所はどこでも)をラップして、コードがコンパイルされた時の値を表示するという使い方ができます。
Exprを評価したときの時間とテキストを表示します。評価結果はExprの値となります。そのため、デバッグ機能を有効にしてコンパイルされている時には、このマクロで式(式が使える所はどこでも)をラップして使用することができます。例えば、List1 = ?debugTime("sorting", lists:sort(List))を実行すると、"sorting: 0.015 s"と表示されます。
EUnitでテストやテストセットをデータとして表現する方法は柔軟でパワフルで、簡潔です。このセクションでは、詳細の表現について説明していきます。
シンプルテストオブジェクトは以下の表現のうちの１つになります。
fun() -> ... end fun some_function/0 fun some_module:some_function/0
まとめると、シンプルテストオブジェクトは、引数をもたない関数を一つだけ持ちます。また、行番号などの追加のメタデータをいくつか持ちます。テストの評価は、この関数が成功するか、失敗するかで行われます。成功した場合には何かの値を返します。ただし、この値は無視されます。例外が投げられると失敗と判定されます。
テストオブジェクト群をリストに入れるだけでテストセットを作成することができます。T_1, ..., T_Nというのが個別のテストオブジェクトだったとすると、[T_1, ..., T_N]はこれらのオブジェクトで構成されるテストということになります。順番もこの通りに扱われます。
同様の方法でテストセットをつなげることができます。S_1, ..., S_Kがテストセットだったとすると、[S_1, ..., S_K]もまたテストセットになります。テストの順番は、S_iに含まれるテストは、S_(i+1)のテストの前となるようにテストセットごとに配置されます。
よく使用されるテストセット表現は深いリストになります。シンプルなテストオブジェクトは、一つだけのテストを含んでいるテストセットとして見えます。Tと[T]に違いはありません。
モジュールもテストセットの表現として利用されます。プリミティブのModuleNameの項目も参照してください。
すべてのテストとテストセットにはタイトルを注釈でつけることができます。テストもしくはテストセットをTとすると、注釈を付けるには{タイトル、T}というペアのタプルを作ります。タイトルは文字列です。あらゆるテストは通常タプルを使用して、タイトル文字列を最初の要素として、{"タイトル", ...}という形式で作成するだけで表現できます。さらに{"タイトル", {...}}というような、余計なタプルを付ける必要はありません。
以下の要素がプリミティブになります。他のテストセットを引数に含むことはできません。
モジュール名を表す単独のアトム。これは{モジュール, モジュール名}と同等です。これはeunit:test(モジュール)という形式でコールされたときに良く使用されます。
これは与えられた名前のモジュール内の、エクスポートされたテスト関数からなるテストセットで構成されます。これらの関数は、引数がゼロで、名前の末尾が_testもしくは_test_で終わるものになります。..._test()という関数は、シンプルなテストで、..._test_()という関数はジェネレータになります。
これに加えて、EUnitは、ModuleNameというモジュールに_testsという末尾の文字列の追加された別のモジュールも探しに行きます。もし見つかれば、このモジュールに含まれるテストもすべて追加されます。ただし、ModuleNameにすでに_testsという文字が後ろについている場合は探しに行きません。 {module, mymodule}という仕様は、mymoduleと、mymodule_testsというモジュールに含まれる、すべてのテストを実行することになります。通常、_testsモジュールは、メインのモジュールの公開インタフェースに対するテストケースのみを含み、他のコードは含まないようにすべきです。
これは、.appファイルの中で見られる、通常のErlang/OTPアプリケーションのディスクプリタになります。結果となるテストセットはInfoに含まれるモジュールの中のエントリーの中のモジュールから構成されます。
これは、特定のアプリケーションに含まれるすべてのモジュールにあるテストセットを作成します。アプリケーションの.appファイル({file, FileName}参照)を調査するか、もしくは存在しない場合には、アプリケーションのebinディレクトリ({dir, Path}を参照)に含まれるすべてのオブジェクトファイルを調べます。もしそれでも見つけられない場兄は、code:lib_dir(AppName)ディレクトリが使用されます。
ファイルやパスを表す文字列です。これは{file, Path}もしくは{dir, Path}と同等になります。このPathは、それぞれファイルシステムの中で参照されます。
もし、FileNameの末尾が、オブジェクトファイル(.beam)を表す拡張子がついている場合には、EUnitはそのファイルをリロードして、テストしようとします。そうでない場合には、ファイルを、テスト仕様を含むテキストファイルとみなして、標準ライブラリ関数のfile:path_consult/2を使用して読み込みます。
ファイル名が絶対パスでない場合には、まず現在のディレクトリからの相対パスとして検索します。その後は通常のサーチパス(code:get_path())を利用します。これにより、よく使う"app"ファイル名はパスを指定しなくても直接指定することが可能になります。例えば、"mnesia.app"のように書くことができます。
これは、指定されたディレクトリの中のすべてのオブジェクトファイルをテストします。{file, FileName}を使用してすべてのファイルを個別に指定するのと同じように動作します。
ジェネレータ関数であるGenFunがコールされ、テストセットが生成されます。
テストセットを生成するのに、ModuleName:FunctionName()が呼ばれます。
Xの値を、リストに含まれている単体の関数に適用し、それぞれを引数のないテスト関数に変換します。AbstractTestFunは通常のテスト用のfunとほぼ同じですが、引数をゼロ個ではなく、一つだけ受け取ります。パラメータを受け取る前の、正式なテスト関数になる前のテストは、いくつかの情報が足りない状態になります。実際、 {with, X, [F_1, ..., F_N]}は、[fun () -> F_1(X) end, ..., fun () -> F_N(X) end].と同等になります。これは特に、抽象的なテスト関数がすでにきちんとした関数として定義されている場合に便利です。{with, FD, [fun filetest_a/1, fun filetest_b/1, fun filetest_c/1]}は、[fun () -> filetest_a(FD) end, fun () -> filetest_b(FD) end, fun () -> filetest_c(FD) end]と一緒ですが、よりコードが短くなります。フィックスチャの項目もご覧ください。
これから説明していく表現を使うと、どこでどのようにテストが実行されるかを制御することができます。
それぞれのテストをサブプロセスに分けてテストを行います。現在のテストプロセスはそれぞれのテストが終了するのを待ちます。これはプロセスの状態を独立した、新規のプロセスとしてテストを実行するのに役立ちます。EUnitは常に少なくとも一つのサブプロセスを自動でスタートさせます。呼び出しもとのプロセスでテストが実行されることはありません。
{spawn, Tests}とほぼ同一ですが、テストを、指定されたErlangのノードで実行します。
{timeout, Time::number(), Tests}指定されたタイムアウト時間の中でテストを実行します。Timeは秒で設定します。60を指定すると1分に、0.1を指定すると1/10秒になります。もしタイムアウトすると、終了していないテストは強制的に中断されます。設定されたタイムアウトの時間は、セットアップと片付けも含んだ、フィックスチャ全体の時間になります。もしタイムアウトが起動すると、片付けのコードが実行されないで、突然強制終了されることになります。
指定されたテストを、厳格な順序で実行します。{inparallel, Tests}.も参照してください。デフォルトでは、テストはinorderもinparallelも指定されていません。テストのフレームワークまかせの方法で実行されます。
可能であれば、指定されたテストを並列で実行します。{inorder, Tests}も参照してください。
{inparallel, Tests}と同様ですが、平行実行の数をN以下に設定します。
フィックスチャは、あるテストセットを実行するのに必要な状態を表します。EUnitはテストセットのためのローカルの状態を簡単に設定しやすいような機能を提供しています。また、テストの結果(success, failures, timeoutsなど)に関わらず、テストセットが終了したときに自動的にクリーンアップを行うこともできます。
説明を簡単にするために、まず最初に定義をリストアップします。詳細は後半で説明します。
Setup() -> (R::any()) SetupX(X::any()) -> (R::any()) Cleanup(R::any()) -> any() CleanupX(X::any(), R::any()) -> any() Instantiator((R::any()) -> Tests) | {with, [AbstractTestFun::((any()) -> any())]} Wherelocal | spawn | {spawn, Node::atom()}
以下の表現は、テストセットを操作するためのフィックスチャを定義します。
foreachはフィックスチャのセットアップと追加の片付けを、指定されたテストセットの中の一つ一つのテストに対して繰り返し行う際に使用されます。
foreachxはforeachとほぼ同じですが、テストセットではなくて、追加の引数Xと、追加のインスタンス作成関数のペアのリストに対して行われます。
Setup関数は、指定された何かテストが実行される前に実行されます。また、Cleanup関数は、指定されたテストが(理由に関わらず)もうなくなった時点で実行されます。セットアップ関数は引数を取りません。セットアップ関数の返値はそのままCleanup関数に渡されます。Cleanup関数は必要なことを行い、okアトムなどの任意の値を返す関数でなければなりません。SetupX, CleanupXもほぼ同様ですが、追加の引数X(コンテキストに依存します)を受け取ります。もしCleanup引数が設定されなかった場合には、何もしないダミーの関数が設定されます。
Instantiator関数はCleanup関数と同様に、いくつかの値(Setup関数が返した値)を受け取ります。Instantiator関数はジェネレータ(プリミティブを参照してください)と同様に。指定された値でインスタンス化されたテストを持つテストセットを返さなければなりません。特別なケースとしては、{with, [AbstractTestFun]}というシンタックスは引数を一つ取る関数のリストの一つ一つに対して値を渡すインスタンス作成関数を表します(この行自信ないです)。詳しくは、プリミティブの{with, X, [...]}の項目を参照してください。
これらの用語は指定されたテストがどのように実行されるかを定義します。デフォルトではspawnが設定されていて、現在のプロセスでセットアップと片付けが行われ、テスト自体はサブプロセスで実行されます。{spawn, Node}もspawnと近いのですが、サブプロセスは指定されたノード上で実行されます。localを指定すると、セットアップ、片付けと、テストの実行のすべてを現在のプロセスで実行します。この場合、テストがタイムアウトしてプロセスが終了したときに、クリーンアップ処理が実行されないという問題があります。そのため、ファイル操作など、永続化に関するフィックスチャについては避けるようにしてください。以下のような場合にのみ、'local'を指定するようにしてください。
テストが開始するまでは、テスト記述のセット全体を生成するのではなく、徐々に生成できたら便利なこともあります。例えば、かなり大量のテストを生成したいが、かなりのすべてを一度に生成するにはメモリをかなり消費していまう場合などです。
呼ばれるたびに、完了していたら空のリストを作り、そうでなければテストケースと残りのテストを生成する新しいジェネレータを含むリストを返すという、ジェネレータを作成するのが簡単です。以下のコードが基本パターンでのデモコードになります。
lazy_test_() ->
lazy_gen(10000).
lazy_gen(N) ->
{generator,
fun () ->
if N > 0 ->
[?_test(...)
| lazy_gen(N-1)];
true ->
[]
end
end}.
EUnitが、テストを実行しようとこのテスト表現をトラバースしようとしたときに、新しいジェネレータは、前のテストが実行されるまでは次のテストを生成しません。
上記のlazy_gen/1など、補助関数を使ってこの主の再帰的なジェネレータを作成することは簡単です。名前空間を汚染するのがいやで、この種のコードを書くのが好きであれば、再帰的なfunを使っても書くことができます。
eunit 2.1.2
Copyright 2004-2009 Mikael Remond, Richard Carlsson
]]>Erlang Factory Bay Area 2009で発表された、Erlangのテスティングフレームワーク、EUnitのチュートリアルです。
～Python最適化計画～
注意: 引用している論文はすべて、 "RelevantPapers"のページからリンクを張っている。中国語版もある
このプロジェクトではPythonを速くしたいと思っている。また、大きくて安定しているアプリケーションをこのプロジェクト"Unladen Swallow"に切り替えて使用してもらえるようにするのもゴールの一つである。
パフォーマンスと互換性という、二つのゴールを同時に達成するために、我々はスクラッチから作るのではなく、CPythonを改修していくという方法を取ることを決めた。具体的には、CPython 2.6.1に対して作業を始めることにした。Python 2.6が、2.4/2.5(ほとんどのアプリケーションが使用している)と、3.x(最終的に到達する未来)の、間のちょうどいい位置にあるからである。CPythonのリリースコードから開始したおかげで、我々は組み込みの関数やオブジェクト、標準ライブラリモジュールなどの重要な部品を再実装しなくて済んでいる。また、頻繁に用いられているCPythonのC言語による拡張のAPIもそのまま使用することができるのである。2.XのCPythonからスタートしているため、既存のアプリケーションからは簡単に移行することができる。もし、3.Xから始めていたら、大きなアプリケーションのメンテナンスをしている人たちにアプリケーションの移植からお願いする必要があり、私達が対象としているユーザにうまくスタートしてもらうのを難しいと思っていただろう。
多くの時間をPythonコードの実行速度の方にフォーカスして行う仕事がメインとなる。Pythonのランタイムライブラリに使用する時間は少なくなるだろう。我々が長期間かけて提案したいのは、LLVM上に構築された、Python用のJIT機能付きのカスタムの仮想マシンを補完することである。それ以外のPythonランタイムに関してはほとんどCPythonのままになる予定である。我々が今までに行ってきた調査によると、Pythonのアプリケーションはメインのevalループの中で多くの時間を消費しているということが分かっている。特に、opコードのディスパッチといった、VMの構成部品に比較的小さい変更を加えるだけで、Pythonアプリケーションのパフォーマンスには著しい効果がある。我々は、LLVMのJITエンジンを通じて、Pythonをマシンコードにコンパイルすと、極めて大きなパフォーマンスの向上が得られると信じている。
いくつか明確になっているメリット:
マシンコードを生成するインフラを、Pythonをコンパイルする機能に加えると、現在のバイトコード表現で行えることよりももっと多くの効果的な実装が行えるようになる。例えば以下のようなコードがあったとすると：
for i in range(3): foo(i)
現在は以下のように変換される
$x = range(3)
while True:
try:
$y = $x.next()
except StopIteration:
break
i = $y
foo(i)
もしrange()というのが組み込み関数のrange()のことであるというのを知ることができれば、我々は以下のように変換することもできるだろう。
for (i = 0; i < 3; i++) foo(i)
C言語では、数値計算のためのアンボックス型を使用することもできる。また、以下のようにループを展開することもできるだろう。
foo(0) foo(1) foo(2)
我々は、Unladen Swallowの内部構造を、マルチコアが使用できることになることを想定した構造にしようと考えている。サーバにおいては、コア数は増える一方であり、より多くのタスクを並列でこなすために、性能を引き出せるようにしたいと考えている。例えば、他のコアで仕事をしつつ、より時間がかかるが性能の良い最適化を平行して行う並列コードオプティマイザを入れたいと考えている。また、並列ガーベジコレクションも導入して、負荷のかかっていない、あまっているコアを利用できるようにしたいと考えている。今日では、ほとんどのサーバの製品は、4個から32個のコアを載せて出荷されているので、私達はこの方向性での最適化が有利であると考えている。しかし、高度に並列化されたアプリケーションの需要については敏感に察知していかねば、と考えている。盲目的にコアを消費すればいいとは考えていない。
なお、我々が取り組もうとしている領域の多くの部分では、他の動的言語の実装がいくつも計画されていたり、開発されていたりする。例えば、MacRuby, JRuby, , Parrotや、他のPython実装である、Jython, PyPy, IronPythonなどである。我々はデバッグ情報に関するアイディアや、正規表現のパフォーマンスに関するアイディア、動的言語で一般的に使用されているパフォーマンスのためのアイディアというのを知るために、これらの他の実装を参考にさせてもらっている。これらは、すでに先人により踏み固められてきた部分であるため、一から車輪の再発明をすることは、できれば避けたいと考えている。
Unladen Swallowは三ヶ月ごとにリリースを行う。また、それとは別に必要に応じてその間にバグフィックスのためのリリースを行う。
Q1では、既存のCPythonの実装に対して、比較的小さな改修だけを行う。Q1で狙っているのは、標準の状態から25%から35%の高速化である。Q1の目標はできるだけ早く、既存のアプリケーションに対して、実際にパフォーマンスアップの恩恵を受けてもらうという、保守的なものである。プロジェクトの完了まで待ってもらうのは我々の望むところではない。
目標を達せするためのアイディア:
2009Q1リリースはrelease-2009Q1-maintというブランチで管理する。リリースとCPython 2.6.1とを比較して我々のパフォーマンスを見て欲しい。
Q2でフォーカスするのは、LLVMの作法に従って実装した、機能的に同等のPython VMに置き換えることである。我々はいくつかのパフォーマンス向上をanticipateしているが、2009Q2リリースではそこには軸足を置くことはしない。Q2ではあくまでも、LLVM上で動作する実装を手に入れるということに注力する。subsecuent半期後には、これによって多くの速度改善が得られる見込みである。
目標：
Q3以降(onward)の計画は単純に論文に従ってイテレーションをこなしていくだけである。我々は独自の作業は行わないつもりであるが、過去30年にわたる研究成果を取り込むつもりである。 完全なリストではないが、RelevantPapersのページにはその一部が含まれる。これらの論文の研究成果を引用して実装していくことを考えている。
我々は正規表現エンジンや、他のボトルネックが見つかった拡張モジュールのパフォーマンス改善についても計画をしている。しかし、正規表現はすでに、我々が改良を行っていくターゲットとしてふさわしいことは既に分かっているため、まず最初に最適化を行っていく。
それに加えて、我々が取り組もうと思っているは、GILの削除と、Pythonのマルチスレッドの状況の改善である。これは、IBMのRecycler(Bacon etal, 2001)のような、より"sophisticated "なガベージコレクションのシステムを実装することで可能になると信じている。
われわれの長期の目標は、パフォーマンス上重要なクラスと関数をCのバックエンドからPythonに持ってくることができるぐらい、Pythonを高速にすることである。
2009第三四半期のパフォーマンスの目標は第二四半期の終わりに決定する。
すぐにできる改良を行って、何人かの人に我々のPythonが適用できると確信してもらったら、LLVMへの切り替え作業に入る予定である。おそらく、最初はブランチを切って作業を開始するだろう。これによって数多くの作業が行えるようになる。
8番目以降の項目は、2009の第二四半期の終わりに向けて、平行で作業を行っていく。
正規表現は伝統的なパフォーマンス上のホットスポットではないが、ほとんどの正規表現のユーザは、もっと早くなることを期待しているということが分かっている。また、結果として予想外のパフォーマンス劣化が発生することもある(訳不安)。このため、CPythonの正規表現エンジンの速度アップに対しても、リソースを投入するつもりである。
CPythonの現在の正規表現エンジンは、スタックベースのバイトコードインタプリタである。CPythonの正規表現エンジンには、命令コードのディスパッチのパフォーマンスを向上させるような、現代的な技術(Bell 1973; Ertl & Gregg, 2003; Berndl et al, 2005)の要素は取り込まれていない。その他の面では、伝統的で率直な実装のバーチャルマシンとなっている。我々は、Pythonそのものパフォーマンスの速度アップに使用される多くの技術は、同じように正規表現のパフォーマンス向上に対しても適用できると信じている。方法としては、まずはJITコンパイルされた正規表現をマシンコードに落とすことにより、命令コードのディスパッチの性能を向上させるところから始めるだろう。
JavaScriptのコミュニティが最近行っていることを見れば、我々が信じていたものは間違っていないということが分かる。GoogleのV8エンジンにはIrregexpというものが組み込まれている。これはJIT正規表現コンパイラである。また、SquirrelFish Extremeには同様の原理を基にした、新規の正規表現エンジンが含まれている。JITのコンパイル時間と、実行時間のトレードをするものである。これらは両方とも、さまざまなJavaScriptのベンチマークの正規表現の項目において、驚くほどの改善を見せている。我々が行いたいのは、これらの成果を、CPython上でも実現することである。
我々は、これとは別にシンプルな正規表現についてはRuss Coxが主張している、Thompson NFAを使用しようと考えている。これは、パターンによって最速の実装を選択できるような、複数エンジンの正規表現システムを作成するということである。V8チームも、Irregexpのワーキングではこのようなハイブリッドシステムを考えていたが、採用はされなかったという話を聞いた。以下のように述べている。
現在我々が取り掛かろうとしている問題は後方参照と、後方追跡の文脈で使用される|や*といった基本演算子である。正しい振る舞いにするためには、通常の正規表現のように、後方追跡が必要となる。Webで使用されている正規表現のデータをもとに、我々が考えている最適化が十分であるかどうか検証してみたが、この方法をとったサブセットによる利益はあまりにも小さいということがわかった。
CPythonの正規表現エンジンに対して仕事に取り掛かる前に解決しなければならない問題のひとつは、Pythonには正規表現のベンチマーク集が存在しないというという問題である。我々はV8ベンチマークのregexp.jsコンポーネントを再利用できないか、ということを考えているが、まず最初に、これらのベンチーマークがPythonのプログラムで書かれる正規表現の種類を網羅しているかどうかの検証をしなければならない。Pythonプログラムの中で使用されている正規表現が、JavaScriptやRuby, Perlなどで使用されるものと大きく違うと信じる理由は特にないが、確認が必要なことには変わりはない。
数多くのPythonのヘビーユーザと話をすると、Pythonの起動時間の改善に興味を持つ人は多い。これは、サーバーの再起動の時間を早くしたいと思っているような巨大なウェブサイトでもそうであるし、起動時間が減れば作業時間もそのまま減るようなコマンドラインツールの作者からも言われる。
特にBazaarのようなアプリケーションの場合、現在は起動時間はほとんどimportにかかった時間である。Pythonは、インポートを実行時まで遅延させたり、インポートがどのように動作するかをカスタマイズできるようなフックをたくさん提供したり、モジュールを読み込む場所を変更できたり、数多くの柔軟性を提供している。この柔軟性の代償としてimportが遅くなっているのである。
多くのユーザにとっては、特定のサーバで利用されるような柔軟性のメリットはあまりない。起動ごとにimportの動作が変える必要はないのである。そのため、我々はより厳格で動作の速いimport文の選択肢を提供しようと考えている。アイディアのひとつは、必要となるすべてのモジュールを、ひとつにまとめて自己完結したバイナリを格納するという方法である。これは、a)ファイル操作のシステムコールがimportするたびに発生するのを避ける、b)Pythonのレベルでの、リンク時の最適化が行えるようになるというメリットがある。結果として、内部モジュールのインライン化や同様の最適化が行えて、速いコードが手に入るのである。自己完結イメージは特に、サーバアプリケーションの実装をする多くのPythonユーザにとって魅力的である。ビルドとデプロイが効率的に行えるからである。
内部構造の変更が少ない高速化としては、Pythonのmarshalモジュールの最適化が考えられる。marshalモジュールは.pycや.pyoといったファイルの生成で使用されている。Unladen Swallowの作業の成果であるcPickleの高速化の技術を基にすることで、少ない手間でmarshalモジュールの高速化を行うことができる。
いくつかの設定の違いごとの、起動時間を追跡するベンチマークは手元にある。現在のCPythonの起動時間の大きな部分をimportが占めているので、このベンチマークにimportにフォーカスした小さいなベンチマークを追加しようと考えている。
Unladen Swallowのtestsディレクトリの中には、いくつかの面白いパフォーマンステストのディレクトリがある。pref.pyというファイルが我々が開発に利用するベンチマークの主要なインタフェースである。このファイルが、各種ベンチマークの起動の橋渡しをしたり、*.py[co]ファイルの掃除をしたり、実行結果の統計を取ったりするのである。
Unladen Swallowのベンチマーク集は、主要なPythonアプリケーション、特にウェブアプリケーションのホットスポットにフォーカスしている。我々が調査した主要なウェブアプリケーションでは、主にテンプレートシステムがボトルネックであると分かった。そのため、我々の初期のベンチマーク集は以下の項目に注目した。
これとは別に、マイクロベンチマークも用意している。例えば、Nクイーン問題を解くプログラムや、覆面算を解くプログラムや、起動時間のベンチマークなどである。
これらとは別に、Richards, PyStone, PyBenchといったベンチマークもいくつか含んでいる。これらは、Pythonの実装の完全さを確認したり、他のPython実装と比較する目的で入れているだけである。Unladen Swallowでは、これらのベンチマークは実際のアプリケーションや、Pythonの実装方法のパフォーマンスを代表したベンチマークであるとは考えていない。そのため、デフォルトでは、これらのテストは実行されないし、この結果を持って方法を決めることもないのである。
プロジェクトの、長期のパフォーマンスの傾向をグラフ化するために、Unladen SwallowではGoogleの社内標準のパフォーマンス測定フレームワークを利用している。プロジェクトメンバーは定期的に、これを使用したパフォーマンスの最新情報をメーリングリストに投稿するだろう。しかし、個々の変化のテストに使用するのは、Benchmarksのページで説明されている、perf.pyで十分である。
Unladen Swallowでは、実装の正確さを確認するために、Pythonの標準のテストスイートと、Python2.6上でよく知られているいくつかのサードパーティ製のライブラリの両方を使用する。特に、サードパーティ製のC拡張モジュールは、気づかないようなC言語レベルの変化で、すぐに動作しなくなるため、テストに使用している。
JITの実装が前進するにつれて、我々はファジングテストを通常のテスト実行に組み込む予定である。我々が計画しているのは、Victor Stinner氏のFusilというPythonのファジングツールである。これはa)既に存在しており、b)Python上の本当のバグを発見するデモンストレーションを行ったことがある、というのが理由である。
Unladen Swallowでは--jitオプションを設定することで、JIT実行時の動作を制御することができる。例えば、--jit=neverを指定すると、JITは完全に動作停止をする。--jit=alwaysを設定すると、初回のウォームアップのインタプリタの実行をスキップし、直接ネイティブコード生成を行うようになる。--jit=onceを設定すると、再コンパイルしなくなる。これらのオプションは、状況に応じてさまざまな実行方法をテストするのに使用される予定である。我々の目標は、例えば最適化が十分に行われて初めて発生するようなバグのある機能があったとして、そのような決して出会うことのないようなJITバグを見つけることである。これはJVMで提供されているinterpreted modeと同様のものである。
Unladen Swallowでは上記のようなテストをコミットごとに毎回実行するために、BuildBotインスタンスを整備している。
CPythonの美徳のひとつはシンプルさである。CPythonのVMとコンパイラを変更するのも比較的シンプルで簡単であった。LLVMを組み込む作業は、必然的にCPython実装を複雑にしてしまうものである。この追加実装からくる生産的なトレードオフを測定するために、Unladen Swallowチームは定期的にpython-devとpython-ideasというメーリングリストからアイディアをもらい、実装している。もしそのアイディアを実装するのがCPythonに適用させるのよりも難しければ、それをマージする前に何かを修正しなければならないということが分かるのである。チームメンバー以外のメンバーにやってもらいたいのは、バイアスが少ない視点で実装してもらうことである。
Unladen Swallowに関するすべてのコミュニケーションは、Unladen Swallowのメーリングリスト上で行われるべきである。このメーリングリストでは、設計に関する議論が行われ、ビルド結果、パフォーマンスの数値、コードレビューの結果が定期的に報告され、その他のオープンソースプロジェクトに関するすべての詳細な話も行われる。もしこのページ(Unladen Swallowのwiki)にコメントを付けたとしても、見落とすことがあるかもしれないため、申し訳ないが、メーリングリストの方にメールを出してもらいたい。
]]>Python作者のGuidoのブログの翻訳です。一日にちょっとずつ翻訳をしていたのですが、長くて一ヶ月もかかってしまいました。読むのも大変だとは思いますがどうぞ。capabilityという言葉があったんですね。権限を与えていく方式のことをcapabilityというらしいです。最後にGoogle App Engineのこともちょろっと触れられていますよ。
訳がこなれていない部分もあったり、リンク先の資料とかも目は通してなかったりするので、読みにくかったり勘違いしている部分もあるかもしれません。
私はMark Miller氏からemailを受け取った。Zooko氏のcap-talkメーリングリスト(私は参加していない)のポストを引用したものである。Markは私に対して、capability(訳注：チケットを用いたオブジェクトの保護システム)に対する見解を明らかにして欲しいと質問をしてきた(おそらくPythonに対して) 。他のメーリングリストへの参加が必要ということもあるので、自分の意見をここに書くことにした。検索エンジンの魔法によりこの記事は関係する場所に届くことが期待される (訳注：GuidoはGoogleで働いているため検索エンジンに触れているのかも) 。
彼がポストした内容によると、Zooko氏は、私がcapabilityについてのアイディアを敵視をしていて、Amoeba(Pythonは、もともとは、Amoeba向けに開発された)におけるパスワードを使ったcapabilityと、私の想定される態度や経験とを結び付けようとしているようである。これはいくつかの理由で奇妙だと言わざるを得ない。最初に、私が覚えている範囲内では、Amoebaのcapabilityはパスワードを利用しているわけではなく、不可逆(一方向)の関数と乱数を基にしている。それと、安全な壁に埋め込まれたイーサネットのソケット(これはおそらく流行らなかった:)も。二番目にAmoebaにおけるcapabilityの私の経験から、何年もかけて、プログラミング言語のEのようなモダンな言語から、Pythonへcapabilityを組み込む提案の中に効果のあるものがあったとは思えないことである。最初の提案は確か、Ka-Ping Yee氏とBenLaurie氏のものであった。この内容はというと、足し算的なアプローチよりも、引き算的なアプローチであったが、実質的にはユーザを制限するPythonサブセットのことである。
今回の件でもっとも驚いたことは、人々が私のひとつひとつの言葉を細かく読んでいるということである。私は宗教的な権威であるローマ法王でもなんでもないのに！私は、設計上の問題について独り言を言うのが好きなハッカーでしかないのである。その独り言も、正しいとは決して言えないのである。もし、私がつぶやいた意見に同意できず、何か質問をしたいというときは、私が投稿しているフォーラム(python-dev, python-ideas, もしくはこのブログ)に反応を返していただきたいと思う。私が読んでいないところに転送して、あれやこれや、推測をするのはやめていただきたい。
とりあえずこの件は置いて、ついでにこの記事はすべて独り言である、と表明したうえで、capabilityとPythonについての、現在の私の考えについていくつか表明したいと思う。
まず、これから説明するのはPythonに限定したいと思う。Capabilityに注力して設計された言語は既に存在して、ある程度の成功は収めているだろうし(例えばE)、その一方で、それらの言語が人気を獲得して、他の魅力的な機能が芽吹くまでには困難な時間を要すると思われるからである。ほとんどの開発者はセキュリティ＝必要悪とみなしている。
こういった姿勢こそが、新しい言語を開発しないで、既存の言語にセキュリティ機能を追加しようという考え方になる理由である。これは、「薄汚れた(訳注：おそらくセキュリティ対策を考えていない、という意味)人々」を、彼らが既に知っている言語の少しだけ異なるバージョンにスイッチするほうが、完全に新しい言語を(一人で採用して)試行するのに比べてはるかに簡単である。もちろんこの説明は、熱狂的なセキュリティ狂信者の行動について否定をするものではない。同様のことは、一般的な「言語のマーケティング」という大きな世界でもいえる。C++はC言語と互換性を持たせる方針で設計され、これから外れるものは却下されている(訳注：実際は型チェックなどはより厳格な方向に変更されている)し、Javaは受け入れやすさを狙ってC/C++と類似するように設計されている。また、良く知られていることでいえば、Larry WallはPerlを設計するにあたり、初期のターゲットユーザがすでにsedとshを使っているという前提のもと、「ねじれた構文」を採用している。
私もPythonの設計においてこのような点から完全に自由であったとは言えないということは認める。私の場合は人気を取るためにそういうことわけではないが。私が他の言語からアイディアを借りてくるときには、そのアイディアがすばらしいものであると認めたときであって、現在のプラクティスに何かを追加するのを目的としていたわけではない。マーケットシェアについて心配はしていなかった。もし心配していたのであれば、グループを表現するためにインデントを使用することはしなかった。
とにかく、このような考えのメリットがあるにもかかわらず、何度も非互換な拡張の要求はやってきては、去り、というのをつづけている。一番最近転生してきたのは、Mark Seaborn氏によるCapPythonである。Wikiページをざっと読んでみると、このページの半分以上を「問題点」と書かれたセクションがあることから、Mark氏はセキュリティ機能追加による制約については良く気づいているように思える。もっとも最近の議論(Zooko氏のポストのトリガーとなった、と私が思っているもの)は、Tav氏が自分のブログに書いた内容から始まった。これには、CPythonの既存の制限実行モードへの、いくつかの謙虚な提案(これは私にとって励みになります!) と、この制限実行モードへのアタックのチャレンジが書かれていた。返信を見るとTav氏はこの分野の歴史に関して明るく、私が自分自身で提供するのよりも良いものを提供できそうに思える。
しかし、私はこの手法に関しては極めて疑わしいと思い続けている。Tav氏のスーパーバイザーコードに対するさまざまな攻撃によって、堅牢なスーパーバイザーを書くのがいかに信じられないほど微妙であるかということを物語っている。CPythonの制限実行モデルはサンドボックスの中の(信頼のない)コードが、スーパーバイザーの中へ、コールしにいくというモデルになっている。スーパーバイザーのPythonコードは完全な権限を持って実行されている。Tav氏のバージョンでは、スーパーバイザーがサンドボックス内にいくつかの関数オブジェクトを提供している。サンドボックスは、それらの関数を通じてのみ、スーパーバイザーへのアクセスが行えるというものである。Tav氏の目的としている変更により、いくつかのインスペクション(訳注：内省。Java用語のリフレクション＝反省とほぼ同一)のための属性が関数から取り除かれる。また、スーパーバイザーがサンドボックス内から隠そうとしているデータや関数へのアクセスを提供するようなその他のクラスオブジェクトも取り除くとしている。この基本的な考え方はうまくいくだろうし、まだサンドボックスを直接突破する方法を見つけた人はいない。そのため、今のところサンドボックを堅牢に保つために、これ以上取り除く必要のある属性は存在しないように見える。
しかし、Tav氏のスーパーバイザーコードの中の脆弱性をたたく、いくつかの攻撃方法(不確かであるが)があきらかになっている。サンドボックス内のコードによって作成された、一見したところ安全なビルトイン関数(引数が設定される)の呼び出しにより、セキュリティを突破するのは難しそうに見えるが簡単である。この方法は、何年も前にSamuele Pedroni氏がPython 2.2以降の制限実行環境が危険ではないか、という疑念を明確にするのに使用された。
Samuele氏のアプローチは、(C)Pythonの二つの性質を結びつけるものである。ひとつはスーパーバイザーに使用されたビルトイン関数が、スーパーバイザーの権限で実行されてしまうということである。もうひとつは、Pythonの中では多くの場所、特にオブジェクトに渡される名前付きの属性で暗黙の変換が行われるということである。このような特性により、サンドボックスの抜け穴があると、ビルトイン関数にセットされるような「魔法の属性」を持つクラスを定義することができるようになり、スーパーバイザー権限でビルトイン関数が呼ばれるようになる。これは、いくつかの面白い引数をビルトイン関数に渡し結果を受け取ることができる知恵を持っている。詳しくはTav氏のブログに書いてある。
私がこのアプローチに対して心配しているのは、スーパーバイザーが提供しているそれなりに大きなPythonのサブセットがかなり複雑なことをしなければならないということである。例えば、モジュールのインポートの安全な仕組みの提供などである。複雑になればなるほど、私がスーパーバイザーのセキュリティに対して感じる信頼度は指数関数的に下がる。言い換えれば、Tav氏が"safelite.py"というスクリプトに書かれたおもちゃのスーパーバイザーコードに対し、クラックを試して、問題があればパッチを当てるという作業を何度か繰り返して進化させて、強固な防護壁を持つ完全な機能のスーパーバイザーを完成させるには、現実的な時間の枠内(10年単位)には収まるようには思えないのである。
それでは、他のもっと一般的な、堅牢なPythonのサブセットの話題に移ろうと思う。これらは、標準ライブラリに含まれる制限実行機能、あるいは属性参照に制限を加えたもの(例えばCapPythonや、ZopeのRestrictedPython)のことである。Pythonが褒められる場合、標準ライブラリが褒められることが多い。Pythonの開発スキルが上達することで、組み込みのリストと辞書だけを使って、効率の良いアルゴリズムを実装するのがどれぐらい良くなるか、ということは計測されていない。多くの場合、実装がどれぐらい効率的に行えるかどうかというのは標準ライブラリをどのぐらいマスターしているのか、ということに依存している。Pythonの標準ライブラリは多くの他の言語よりも大きい。唯一Javaは「いつでもそこにある」ということをやろうと思っているらしく、Pythonよりも多くのライブラリを持っている(ただし特定の組み込み環境を除く)。
"堅牢な"バージョンのPythonの成功のためには、ほとんど標準ライブラリのAPIのサポートが必要になると思われる。私はここでは、実装とAPIを区別している。理由としては、多くの標準ライブラリモジュールは、堅牢なサブセットによって使用できないようになっている言語機能を使用している可能性があるからである。これ は、堅牢なサブセットでのみ使用される別の実装が提供されるのであれば、大きな問題とはならない。
残念ながら、これらの要因が組み合わさると、堅牢なPythonサブセットにマッチした、十分な大きさの標準ライブラリを提供するということはとても実用的ではないと思う。ひとつの問題はPython自身にある。Pythonは高級な動的な言語であり、Cpythonにおけるバイトコードへのアクセスなど、実装固有の部分を含む、あらゆるレベルでのインスペクションをサポートしている(バイトコードアクセスはJythonやIronPythonや他の実装ではこれに相当する機能はない)。もちろん、言語の動的な機能やインスペクションの機能があるからといって、ほとんどの場合はモジュールAPIと、実装の間に直接の影響があるとは限らない。これは時々Pythonユーザのフラストレーションの原因となるが(例えば、最近のpython-devにおけるasyncoreについての議論)、ほとんどのケースでうまくいっており、いくつかの動的な機能を利用することでAPIをシンプルにできることも多い。例えば、動的なアトリビュート検索を利用して、APIを拡張する方法がいくつかある自動デリゲーションは、まさにその動的な機能の一般的な使用例の一つと言える。また、コマンドのディスパッチも有名である。堅牢なバージョンのPythonが十分な数のユーザをひきつけるほど完璧になるのは難しい。もちろん、この考えが間違っていると証明されて欲しいと思っているが、人々は追加的なセキュリティにより、手っ取り早く成功する方法を提供して欲しいという考えに惹かれているように思える。しかし、残念ながら、私には、この追加的なアプローチはショートカットになるとは思えないのである。
ここで、私がいくつかの経験をしているGoogle App Engine(現在私の時間のほとんどはこれの貢献に使用している)についても触れる必要があるだろう。Google App Engineでは標準ライブラリのサブセットをサポートした、"堅牢"に改良されたPythonを提供している。今、"堅牢"と、引用符でくくって書いたのには理由がある。App Engineのセキュリティのニーズはcapabilityのコミュニティいつも目的としているようなニーズとは多少異なる。Pythonアプリケーション全体が、ひとつの堅牢なドメインの中にあり、セキュリティはC/Pythonの境界やユーザ/カーネルの境界、仮想マシンの境界で強固に守ることで堅牢な環境が手に入れられる。信頼されていないプロセスとの堅牢な通信は提供されていない。スーパーバイザーのコードはC++で実装され、重要な部分は異なるプロセスとして活動している。
App Engineの場合、Pythonの言語としての方言はCPythonとして実装されたものと完全に同じである。唯一の違いはライブラリのレベルにある。App Engineのユーザはファイルシステムにデータを書き出すことは出来ない。また、ソケットやパイプ、スレッドやプロセスも作成することはできない。また、裏口となるようないくつかのビルトインモジュールも使用できなくなっている。モジュールに関しては、いくつかのケースでモジュールの堅牢性を崩すようなAPIのみが使用できなくなり、それ以外の安全だと思われる便利なAPIは残された。これらはすべてApp Engineの目標を達成するためには、極めて合理的な制約と言える。そして、ほとんどの場合で、この中のひとつの制約だけが、App Engineのユーザに苦痛をもたらしている。
App Engineのセキュリティの向上には、内部リソースをかなり使用しているが、まだ結果は大きく制限されている。App Engineのセキュリティモデルが、capability信者が好むものよりも、かなりシンプルであることを考えて欲しい。これは乱暴な開発者からの攻撃からGoogleを守るためのオール・オア・ナッシングのモデルである。一方で、開発者がお互いを攻撃しあうのを防ぐ効果もある。推測するに、capabilityをベースとしたPythonの場合は、セキュリティを守るためにもっと多くの努力が必要になったと思うし、開発者にはもっともっと多くの制限が課せられていたと思う。Google App Engineは開発者が使いたいと思うような、とても「魅力的な機能」を持たなければならないと思っている。
]]>またまたGuidoのブログの翻訳です。GuidoがScalaを語ってる！と思ったら、なんか色々不満なご様子。Scala用語はイマイチ分からぬことも手伝って、相変わらず適当翻訳ですがどうぞ。
私は、Scala eBookの無料コピーをMartin Odersky氏, Lex Spoon氏, Bill Venners氏の三名からいただいた。私は、CalTrain(訳注：アメリカのカリフォルニア州を走る通勤電車)で通勤中に読もうと挑戦してみたが、ざっと内容をつかむことしかできなかった。700ページ以上ある大作の本である。私はもちろん、この書籍のターゲットの読者ではない。この本のターゲットは二つあり、一方はより良い言語に挑戦しようとするJavaプログラマーへの誘惑、もう一方はScalaを使うとどのようなことが起きるのか、という紹介である。その二つの間を行き来している感じである。私は最終的にはScalaのウェブサイト(チュートリアルや概要、言語リファレンスなどをダウンロードした)を訪れることになった。
これを言わなければならないのは残念ですが、私はとてもがっかりしています(あ、言語にです。eBookのほうは、言語使用と同じぐらい大きいということを除けば、言うことは何もありません)。私が最初にScalaについて聞いたのは、昨年の5月のGoogle I/Oで、Steve Yegge氏との会話の中で触れられていたときのことである。SteveはScalaを「静的な型システムの逆襲」 (そのセクションのビデオを見つけるのが面倒なので、てきとーに言い換えています)。Steveは信じられないほどフクザツな型システムをからかい始めた。例えば、型システムには、型の消去、分散アノテーション(variance annotation) 、実存(existential)型、ポリモーフィックメソッド型など、難解なコンセプトがたくさん含まれているのである。もしより知りたければ、言語リファレンスのToCという項目を調べて見ると良い。
私はSteveに同意せざるを得ない。もしこれがコンパイル時の言語内の型セーフを維持するためのものであるならば、私はいつでも動的な型システムを選択するだろう。より良いやりかたがあるはずである。おそらくHaskell？Haskellは純粋な関数型言語で、関数型言語のI/Oの問題をうまい具合に解決した、動作の速い実装が存在する。Haskellのモナドは本当に深く、実装はかなり大変であるが、これを使うのは極めて簡単であるように思える。
私がScalaを見て、もっともがっかりした点が、簡単そうに見えるコードを書くことを可能にするような、無数のルールがあるということである。これらのルールはすべて、無数の例外のように見えた。これらの例外により、これらを知らないときにはシンプルなコードを書くのがとても難しくなる。例えば、Scala本では、for構文の中ではif修飾詞をいくつも使用できると説明されている。しかし、パーサに推測して欲しいという位置にセミコロンを挿入してやる必要がある。さらに不可思議なのは、丸カッコの代わりにもし波カッコ({})を使用したときに、セミコロンが省略できるのである。説明も無く、このようなことが堂々と現れるのである。私は、リファレンスマニュアルの内のほとんど関係がないように思えるルールを結び付けて説明を理解した。まずはforステートメント(技術的にはfor内包表記(comprehension)と呼ばれる)であるが、これは波カッコや丸カッコを同じセマンティクスで使用することができる。しかし、セミコロンの推測は、波カッコと丸カッコで異なるのである。えぇっ！:-)
]]>クラウドをとても好きな人がいる。ここでいうクラウドというのは、Google AppEngineやAmazon EC2, MicrosoftのAzureのようなクラウドコンピューティングのことである。一方、クラウドが嫌いな人もいる。これを嫌うような人は、ロックインや、APIの独占なども嫌う傾向がある。(両方の姿勢の例を提示したいと考えているが、ちょうど今は時間がないので勘弁してほしい。情報を集めるのは簡単だから:-)
新しい分野かどうかはさておき、これらの意見の相違が、持ち家に対する意見の相違と同じではないか、と心配になる。「借りる」ということを嫌う家族がいたり、家主との係争を引き合いに出したり、近所の人がうるさかったり、終わることのないメンテナンス(屋根、フェンス、暖炉、バスルーム、キッチンなどきりがない)があったり。私自身は中間であるが、過去には良い家主に会うことが出来たり、最近の自分自身の家のメンテナンスの努力・コストがいやになりつつも、独立していることを楽しんでもいる。
明らかに、クラウドコンピューティングはこの借家に近い。伝統的なデーターセンターの所有権が家の所有権となっているのである(建造するコストを無視して、所有することなしに利益を上げることを考えてみてください:-) アナロジーを使い、大家ができるビジネスの方法として、クラウドサービスのスタイルの違いの比較を行う人もいるだろう。例えば、Google App Engineはカーペットも家具もサービスの一部として含まれるが、食事の配達はオプションである。Amazon EC2はやりたいことが自由にできるコンクリートがむき出しの部屋を貸し出すのに近い。どちらにも市場はある。
このクラウドの課題に関して、好き/嫌いという論争は止むことがないと考えるべきである。クラウドを嫌っている人を好きになるようにと説得することはない。しかし、自分のサーバを所有したくないと考えている家主に対するビジネスはたくさんあるのである。我々はクラウド嫌いの人と一緒に仕事してがっかりするのはやめて、そのような人たちに喜んでもらうことをしたほうが良いだろう。
]]>Pythonの著者のGuidoのブログが引っ越しをしたようです。そこに載っていた記事を一本翻訳してみました。今マイブームはオペラ座の怪人で、楽譜を買ったり、小説を買ったりして読んでいるんですが、小説の日本語がやたら直訳で堅いんです。柔らかい翻訳に触れたくて、衝動的に翻訳してみた次第です。動機とPythonは何の関係もないですが。
誰かからジョーク交じりに、100万個の32ビットの数値を2メガバイトのメモリでソートできるか？と聞かれたことがある。私はこれに挑戦してみたが、この中でI/Oのバッファリングについていくつか学ぶことができた。
明らかにこの問題はジョークである。バイナリエンコーディングだと仮定してもデータだけで4メガバイトになってしまうのである！しかし、これを可能にする実装方法がある。32ビットの数値が100万個納められているファイルがあるとして、どのようにすればメモリの使用量を最小にしてソートをすることができるだろうか？これは一種のマージソートになるはずである。メモリ内でソートされた小さいチャンク(かたまり)を一時ファイルに保存し、その後この一時ファイルをマージして最終的な出力エリアに出力する。
これは私の考えた解決策である。手短に(1分で)説明しよう。
NOTE: すべてのサンプルはPython3.0を使用して書いた。主な違いはバイナリストリームにアクセスするのにfile.bufferを使用している箇所である。
#!/usr/bin/env python3.0
import sys, array, tempfile, heapq
assert array.array('i').itemsize == 4
def intsfromfile(f):
while True:
a = array.array('i')
a.fromstring(f.read(4000))
if not a:
break
for x in a:
yield x
iters = []
while True:
a = array.array('i')
a.fromstring(sys.stdin.buffer.read(40000))
if not a:
break
f = tempfile.TemporaryFile()
array.array('i', sorted(a)).tofile(f)
f.seek(0)
iters.append(intsfromfile(f))
a = array.array('i')
for x in heapq.merge(*iters):
a.append(x)
if len(a) >= 1000:
a.tofile(sys.stdout.buffer)
del a[:]
if a:
a.tofile(sys.stdout.buffer)
私のGoogleのデスクトップ(Guideは現在Googleで働いている)では、実行に5.4秒かかった。3年前の古いPCでGoogle謹製のLinuxが稼動しており、Python3.0のpystoneのベンチマーク結果は34000である。また、入力には正確に100万個のランダムな32ビットの数値の入ったファイルを使用した。この結果はそんなに悪くない。同じ入力を使用して、すべてメモリ上でソートするという、直球な実装では2秒かかった。
#!/usr/bin/env python3.0
import sys, array
a = array.array('i', sys.stdin.buffer.read())
a = list(a)
a.sort()
a = array.array('i', a)
a.tofile(sys.stdout.buffer)
それではマージソートの方(ファイルを使用する方)に説明を戻そう。最初の３行は以下のようになっている。
#!/usr/bin/env python3.0
import sys, array, tempfile, heapq
assert array.array('i').itemsize == 4
最初の行はPython 3.0を使用するということを言っている。二行目では必要なモジュールをインポートしている。三行目はタイプコードの'i'が32ビットの数値をあらわさない、64ビットのシステムを除外するためのものである。私は特にこのコードをいろいろな環境で動く汎用的なものにしようとは思っていない。
次に、小さなヘルパーを作る。これはジェネレータであり、ファイルから数値を読み込み、一度に1つずつ返すものである。
※訳注：ジェネレータというのは状態を保持する特殊な関数で、yield(擬似return)が呼ばれるたびに処理を中断する。再度実行されると前回yieldが呼ばれたところから処理が続行し、returnか、関数の終わりに達すると処理が終わる。通常、ループと一緒に使用する。
def intsfromfile(f):
while True:
a = array.array('i')
a.fromstring(f.read(4000))
if not a:
break
for x in a:
yield x
ここの部分のパフォーマンスをチューニングする。このコードは一度に1000個の整数を読み込む。そして、その結果を分割して1つずつyieldで返す。最初に実装したコードはこのバッファリングを使用していないため、一度に4バイトずつファイルから読み込んで、整数に変換して、結果を返していた。しかし、これでは4倍も遅くなってしまうのである！(通常、細かいファイルアクセスは、一度にまとめて読むのに比べて時間がかかる) a.fromfile(f, 1000)というメソッドは使えないということは覚えておいて欲しい。このfromfile()メソッドは、ファイル上に十分な数のデータがそろっていないときには文句を言ってくるからである。私は、ファイル上にある整数の個数が何個であれ、自動で動作してくれるようにしたかったので使用しなかったのである。
次に来るのが入力のループである。ここでは繰り返し1万個の整数値が含まれるチャンクを入力ファイルから読み込み、メモリ上でソートし、一時ファイルに書き込んでいる。その後、上記のinsfromfile()関数を使用して作成した、一時ファイルを参照するイテレータを作成する。そして、この次のマージを行うフェーズで使用する、イテレータのリストに追加する。
iters = []
while True:
a = array.array('i')
a.fromstring(sys.stdin.buffer.read(40000))
if not a:
break
f = tempfile.TemporaryFile()
array.array('i', sorted(a)).tofile(f)
f.seek(0)
iters.append(intsfromfile(f))
100万個のデータが含まれるデータを使用すると、それぞれ1万個のデータを含む、100個の一時ファイルが作成される。
最後に、これらのソート済みの一時ファイルを一緒にマージする。heapqモジュールを使用すると、簡単にこの目的を達成できる。heapq.merge(iter1, iter2, ...)は、順番どおりの入力値をyieldで返すイテレータを作成する。この関数は、今回の場合のように、入力されたそれぞれイテレータは、ソート済みであるということが前提となる。
a = array.array('i')
for x in heapq.merge(*iters):
a.append(x)
if len(a) >= 1000:
a.tofile(sys.stdout.buffer)
del a[:]
if a:
a.tofile(sys.stdout.buffer)
ここも、I/Oのバッファリングを利用して、効率的にチューニングできるもう一つのポイントである。ソートされた値を得られる端から一つずつファイルに追加していくと、だいたい２倍遅くなる。これらを総合すると、ファイルの読み込みと書き出しの両方にバッファを設けただけで、10倍のスピードアップが得られたことになります！
以上が今回のストーリーの金言である。
もう一つのheapqモジュールがすばらしいということも、今回の学びである。このモジュールは出力のフェーズで必要となった、イテレータをマージする機能を持っていた。そして、バイナリデータを管理するのにarrayモジュールを使用したことも忘れないで欲しい。
最後に、このサンプルを見て、Python3.0とPython2.5がそんなに大きな違いがないということがご理解いただけたと思う！
]]>Python作者のGuidoのブログの記事を軽く翻訳してみました。単語を適当に抜かしたりしていますが、だいたいはそのままです。Guideらしいというか、Pythonらしいコメントですね。もちろん、この方針はPython以外にも使えます。
私がこの機会を利用して、ここを見ている方々に本当に伝えたいのは、Python3000にモジュールを移植するときにAPIを変更してはいけないということです。ここを見ている方は以下の話は聞いたことがあるでしょう。Python3.0はAPIが変更になり、後方互換性がなくなる、と。しかし、開発者の方々(特に他のユーザから使用されているライブラリの)はAPIを変更してはいけません。もし変更する予定があるならば、3.0に移植する前に行ってください。あるいは、3.0に変更なしで移植したあとに行って下さい。
なぜそうしなければならないのか？それはユーザのためです。Ima Lumberjackは彼の製作所の管理のためのweb 2.0アプリケーションを実装していました。Imaはあなたの作ったすばらしいweb 2.0フレームワークのユーザです。ImaはアプリケーションをPython3000に移植しようとしています。彼はあなたの作ったフレームワークがPython3000に対応するのを待ち作業を開始しました。彼は書籍に書いてある移植の方法をすべて正確に行いました。2to3のツールを使用し、テストを行いました。そこでテストが失敗してしまったらImaがどんなにがっかりするか、想像できますよね？失敗した原因がAPIの変更にあるのか、アプリケーションの移植が不十分だったのか判別できません。
もしあなたの作ったフレームワークにAPIの変更がなければ、Imaの仕事はもっと焦点のはっきりしたものになります。2to3ツールを実行したあとに残っているバグはImaのコード側のバグです。彼はその部分の修正方法ははっきり理解しています。
あなたのライブラリが他のライブラリから使用されていたとすると、さらにこの問題は重みを持ってきます。トラブルの広がりは加速度的に大きくなります。もし、仮に、これらのモジュールの中にPython3000への移植を諦めたものが出てきてしまうと、多くの他のライブラリやアプリケーションの移植の妨げになっていしまいます。
もういちど強く言っておきます。Python3000への移植と同時にAPIを変更してはいけません。
P.S. 3.0finalリリースは現在2008年の9/3に予定されています。詳しくはPEP361を見て下さい。
]]>