順調に進化を続けるLithiumから例外的に0.9.5がリリースされました。今回も多くの新機能がアナウンスされています。

原文

http://rad-dev.org/lithium/wiki/blog/Lithium-0-9-5-Dont-Stop-Till-You-Get-Enough

Lithium0.9.5:止まるにはまだ早い

0.9から1週間半が経ち、Lithiumチームはバージョン0.9.5をアナウンスします。本来のリリーススケジュールに予定されていませんが、今週非常に多くの事を達成したので中間のリリースを行うことにしました。これによりコミュニティの開発者は以下の優れた機能を試す事ができます。

HTTP Auth Adapter：HTTP認証を検証できるようにする`Auth`アダプタが追加されました。`Form`アダプタと同時に利用する事もできます。標準的なログインによる同一の資格情報を持ったWEBサービスへのリクエストを認証できます。（Twitterのクライアントのような例を想定してください)

再設計されたロガーAPI：我々の最初の（そしておそらく最後の）メジャーな後方互換性の無い変更です。より直感的なインターフェースを提供する為にロガーAPIを再設計しました。設定名の代わりに優先度を指定し、それぞれの優先度に対して一つのアダプタを指定します。それぞれの設定は任意の名前を付ける事ができ、priorityキーでどの優先度にアダプタが応答するかを指定します。この柔軟性により重要度の高いメッセージを複数のログに残せます。[Logger APIドキュメント]をご覧ください。

Growlロガーアダプタ：再設計されたロガーAPIともにMax OSXでポピュラーな通知システム、Growlへのアダプタもリリースされました。(オリジナルの実装者はSean Coates)。リリースされたバージョンは、最初から外部に依存関係が無いように書き直され、高速開発に大きな助けになります。

モデル初期化処理のリファクタリング：モデルクラスの初期化処理がリファクタリングされ、大幅に合理化されました。これによりモデルクラスは`lithium\data\Model`を継承したいくつかの基底クラスを継承できます。またクラスは任意のプロパティを継承します。

リードスルーキャッシュ:通常のキャッシュ処理は２つのステップで行われます。指定されたキーを元にキャッシュが存在するかを確認し、存在しない場合はキャッシュする為の処理を行い結果をキャッシュに書き込みます。リードスルーキャッシュはこのプロセスをより直感的にします。次のコードを例を考えます：

1
2
3
4

$id = $this->request->id;
$user = Cache::read("storage", "user.{$id}", array('write' => function() use ($id) {
    return array('+2 days' => serialize(User::find($id)->data()));
}));

キャッシュキーが存在しない場合は、渡された関数が呼び出され返されたデータは、キーに保存され、返す値のarrayのキーキャッシュの有効期限として使用します。このインターフェイスを使用して、キャッシュのチェックとセットを１度の処理で行えます。

ベンダライブラリのための新しいソース管理：我々は、デフォルト配布用に2つのディレクトリを追加しました：`libraries/ _source`と`app/libraries/_source`です。これらのディレクトリはあなたが外部のライブラリをコピーするかチェックアウトし、より簡単にアプリケーションと同期させる為に作られました。外部ライブラリを`_source`ディレクトリに配置した後、実際にソースコードを含むディレクトリを`libraries`ディレクトリとしてsymlinkできます。
たとえば、私はアプリケーション内でいくつかのPEARクラスを利用しています。私の現在の設定は次のようになります：

1
2
3
4
5
6

Libraries::add("PEAR", array(
    "prefix" => false,
    "includePath" => true,
    'path' => LITHIUM_LIBRARY_PATH . "/PEAR/pear/php",
    "transform" => function($class) { return str_replace("_", "/", $class) . ".php"; }
));

実際のPEARのソースコードは`PEAR/pear/php`内にネストされています。これは醜いです。その代わりに、`PEAR`ディレクトリを`app/libraries/_source`の中に移動し、`app/libraries/_source/PEAR/pear/php`から`app/libraries/PEAR`へのsymlinkを追加しました。これで設定を下記のようにシンプルに変更できます：

1
2
3
4
5

Libraries::add("PEAR", array(
    "prefix" => false,
    "includePath" => true,
    "transform" => function($class) { return str_replace("_", "/", $class) . ".php"; }
));

PHP 5.3の標準的なネーミングに従っているライブラリの場合は、その差はさらに歴然です。例えば、PEAR2の場合はシンプルに

Libraries::add('PEAR2');

とするだけでインポートできます。
この規約によって複数のバージョンのライブラリをsymlinkの切り替えだけで透過的に変更できるというメリットもあります。この規約は、Paul M. JonesのSolarPHPプロジェクトに触発されました。

MongoDB条件演算子：我々はMongoDBのネイティブなクエリ演算子を常にサポートしてきました。さらにSQLスタイルのクエリ演算子のサポートを追加しました。標準クエリの構文を使用する例：

1
2
3

Article::find('all', array('conditions' => array(
    'expires' => array('>' => time())
)));

これは自動的にネイティブなMongoDBのクエリ演算子に変換されます。これはMongoの(素晴らしい)構文を単に置き換えるものではなく、プラグインの開発者に対して様々なデータソースで動く抽象的なクエリを書く手段を提供する事と新たに非リレーショナルデータベースに興味を持つ開発者や既存のアプリケーションの移植へのバリアフリーも目的にしています。
最後に全てのチームメンバーに感謝しています。特にジョンアンダーソンに、我々のドキュメントリードは、我々は、新しいAPIドキュメントを大量に追加してAPIを100%カバーするという目標の目前にまで来ています。変更履歴、または新しいAPIドキュメントを閲覧するか、新しいリリースをダウンロードしてお楽しみください！
~Nate~

–翻訳ここまで

1週間半で大きな進展が会ったことが伺えます。特にNoSQLなデータベースを透過的に扱う技術は多くの人にとって有益ですし、キャッシュの実装をクロージャを使って簡単にする例などは示唆に富んでいますね。ログをGrowlにながすというアイデアも秀逸です！

ちょっと作業時間が取れなかったので大幅に遅れてしまいましたが、Lithiumの0.9のリリースノートの和訳です。すでに0.9.5が出ていますのでそちらも追って和訳している所です。また末尾で触れられているTekXでのセッションも見てきました。同じ内容のセッションを近日中にustreamで中継する事を相談しているので近々お目にかけられるかもしれません。

原文

http://rad-dev.org/lithium/wiki/blog/Lithium-0-9-The-Lambdas-are-awesome-Edition

Lithium0.9 ラムダは素晴らしいエディション

私はLithium0.9を迅速にリリースできた事にとても興奮しています。[今すぐダウンロード！]。0.8からの3週間で、私たちに1.0にかなり近いところまで来ました。いくつかの新機能が含まれます：

ErrorHandler：`ErrorHandler`クラスは、アプリケーション全体のPHPのエラーと例外をキャプチャして処理するための高度な設定を提供します。その革新的なデザインは、エラーを型（エラーまたは例外）を含む様々なパラメータ/例外を捕捉することができます。エラーコード、例外クラス名（継承関係を含む）、エラー発生元のクラス名メソッド名のバックトレースも含まれます。
あなたは0.9にアプリケーションを更新する場合は、今すぐ次の例を試すことができます：
アプリケーション内に新しい設定ファイルを作成します。`config/bootstrap/error.php`をブートストラップからincludeしてから以下を追加します：

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

/**
 * First, import the relevant Lithium core classes.
 */
use \lithium\core\ErrorHandler;
use \lithium\analysis\Logger;
use \lithium\template\View;
 
/**
 * Then, set up a basic logging configuration that will write to a file.
 */
Logger::config(array('error' => array('adapter' => 'File')));
 
/**
 * Configure an error page renderer function that we can use to render 404 and 500 error pages (for
 * this part to work, you need to create errors/404.html.php and errors/500.html.php in your views/
 * directory).
 */
$render = function($template, $content) {
    $view = new View(array(
        'paths' => array(
            'template' => '{:library}/views/{:controller}/{:template}.{:type}.php',
            'layout'   => '{:library}/views/layouts/{:layout}.{:type}.php',
        )
    ));
    echo $view->render('all', compact('content'), compact('template') + array(
        'controller' => 'errors',
        'layout' => 'default',
        'type' => 'html'
    ));
};
 
/**
 * Finally, wire up the error configuration. The first rule captures any exceptions where the
 * message matches one of the given regular expressions: eitheer a template or controller wasn't
 * found. In either case, render a 404.
 *
 * For all other exceptions, log them to the error log, and show the user a 500 error.
 */
ErrorHandler::config(array(
    array(
        'type' => 'Exception',
        'message' => '/(^Template not found|^Controller \w+ not found)/',
        'handler' => function($info) use ($render) {
            $render('404', $info);
        }
    ),
    array(
        'type' => 'Exception',
        'handler' => function($info) use ($render) {
            Logger::write('error', "{$info['file']} : {$info['line']} : {$info['message']}");
            $render('500', $info);
        }
    )
));
 
/**
 * Last but not least, tell the ErrorHandler to start capturing errors.
 */
ErrorHandler::run();

これで、あなたは完全にカスタマイズ可能なエラー管理ソリューションを即座に利用できます。ハンドラはエラーに対して独自に対応を行えるようにします。通常これは、それらをロギングしエラーページをレンダリングするという事になるでしょう。

永続的パラメータ：多くの拡張機能の中で永続的なパラメータを追加しルーティングします。新しいルートを設置すると、あなたはルートがマッチした際の引数のリストを指定することができ、このリクエストの間は永続的に利用され後続のリンクでも使用されます。これらの2つのルートを考えてみましょう：

1
2
3
4

Router::connect('/admin/{:controller}/{:action}', array('admin' => true), array('persist' => array(
    'admin', 'controller'
)));
Router::connect('/{:controller}/{:action}');

さて、サイトのadminセクションを参照すると、生成された全てのリンクが永続化したプロパティを継承しています：

1

<?=$this->html->link('Add post', array('controller' => 'posts', 'action' => 'add')); // links to /admin/posts/add ?>

パラメータを無効するには、単に`null`を対応するキーの値に渡す：

1
2
3

<?=$this->html->link(
    'Add post', array('controller' => 'posts', 'action' => 'add', 'admin' => null
)); // links to /posts/add ?>

ルートハンドラ：最も重要な新機能、ルートハンドラを使用すると、アプリケーションから直接のルートにコントローラロジックを実装することができます。これにより、いくつかのクールな実装や、小型で高速マイクロアプリケーションを実現できます。以前このプラグインはフレームワークの外部でしたが、この機能はコアに移動されているアプリケーションから直接利用できるようになりました。この単純な例を考えてみましょう：

1
2
3
4
5
6
7
8
9
10
11

use lithium\action\Response;
use \lithium\net\http\Router;
 
Router::connect('/hello/{:name}', array('name' => null), function($request) {
    $name = $request->name ?: 'World';
    return new Response(array('body' => "Hello {$name}!"));
});
 
Router::connect('/redirect', array('name' => null), function($request) {
    return new Response(array('location' => '/'));
});

このルーティングでまず注意する点はルートハンドラーは全てのフレームワークの処理をバイパスして直接、Responseオブジェクトを返してレンダリングする事です。またハンドラは$requestパラメータを返し、処理を通常どおり継続することもできます。最初の例では /hello にアクセスした際に誰かわからないユーザへのあいさつ、”Hello World!” を画面に書いています。または`/hello/Nate`にアクセスし `{:name}`パラメータがURLで指定されたな会いは”Hello Nate!”と表示します。
2番目の例では`/redirect`へのリクエストをキャプチャし、ハンドラはブラウザを別ページへリダイレクトするResponseオブジェクトを返しています。Responseオブジェクト（また、コントローラのプロパティとしても使用可能なオブジェクトです）では、レスポンスがブラウザに返される方法を直接コントロールします。

テンプレート変数展開：コミュニティの一部の開発者が明示のテンプレートを作成したいので、テンプレート変数をアクセスするための代替構文を実装しました。また $titleというテンプレート変数は $this['title']としてアクセスすることも出来るようになりました。
また、このテンプレート変数の展開を無効にするオプションもあります。設定に`extract`パラメータを追加することによって、我々は簡単に通常のテンプレート変数を無効にすることができます：

1
2
3
4
5
6
7
8

Media::type('html', 'text/html', array(
    'view'    => '\lithium\template\View',
    'extract' => false,
    'paths'   => array(
        'template' => '{:library}/views/{:controller}/{:template}.{:type}.php',
        'layout'   => '{:library}/views/layouts/{:layout}.{:type}.php',
    )
));

この設定を適用すると、 $this['title']は引き続き動きますが、 $titleは動かなくなります。
最後に、Joelと私は一カ月後のTEK・Xのカンファレンスで講演する予定です。我々はLithiumについての合同セッションと、それぞれコードの品質やソーシャルグラフについての講演をする予定です。今すぐ登録して、会場で会ったら声をかけてください。シカゴでお会いしましょう。

~nate~

–翻訳ここまで

機能の断片を紹介しているのでちょっとピンと来にくいかもしれません。セッションでも語られていましたが、Lithiumはアスペクト指向を実装に取り入れている部分があり、従来のスタイルのフレームワークの知識を前提にして考えると分かりづらい所があります。これらの例は全体の継承関係や処理のフローを考慮することなく、断片的な修正をクロージャなどを使って実現できるという点がすごい所と言えるでしょう。

基本は大きいiPhone

基本的な設定や操作は全くと言っていいほどiPhoneと同じです。すでにiPhoneを使っている人なら違和感なく使えるでしょう。ただ画面が大きいことでキーボードのうちやすさや画面のみやすさがストレスなく使い続けられるレベルに向上しています。SafariでのネットサーフィンはiPhoneではけして快適ではなかったですが、iPadでは部屋にパソコンがあってもネットサーフィンをする為にパソコンを開く事が無くなるレベルです。電子書籍リーダー？ 僕は洋書を読まないので全然ピンとこないです。

アプリはiPad用じゃないとほぼ意味なし

まだ発売直後なのでアプリは多くはないです、Facebookのアプリ等を試しましたが、拡大表示は悲しい感じです。そもそもウェブサービス系のアプリは画面の狭さをカバーするものが多かったと思いますが、画面が大きくなったいまはSafariで開けば十分な使い勝手です。Flashは見れないですが。。。

画面を縦にするとネットサーフィンが快適

個人的には驚いたのが縦画面で見るウェブの快適さです。通常のノートPCは画面が横長であることが前提です。ですが、大抵のウェブコンテンツは縦に長いので、考えて見るとページをスクロールすることに日夜かなりの労力を割いて来ました。iPhoneでも縦は縦ですが、致命的に画面が狭いので通常のネットサーフィンには耐えませんでした。縦画面でみると楽天の長大な商品ページや、はてなブックマーク、まとめサイトの閲覧がとてもスムーズです。

不満点

あたりまえですが、タッチしまくるので指紋がつきます。柔らかい布で拭けば綺麗になりますが。大きさと重さ的に満員電車で使うのは厳しい気がします。アプリが少ない点も気になりますが、すぐに解決しそうです。電子書籍については日本ではKindleも一応使えるというレベルでしかないので、日本語のコンテンツが出れば一気に普及するかもしれません。

以上つらつらと書きましたが、基本的にいい買い物でした。迷っている人は買ってみて後悔はしないんじゃないかなと思います。自分も実家の両親に追加購入しようか検討中です。

日本でもさまざまな形態で技術系のカンファレンスが開催されていますが、その上を行くカンファレンスを知ったので紹介します。
「会場はバスです、さらにいうとバス２台です」

知ったきっかけ

iPadの発売にあわせてLithiumのデベロッパのNateとJoelとお茶をしたのですがそこで「面白い会場を使うカンファレンスがある」とJoelが教えてくれました。ググっても以外とヒットしにくいのですが会場が「バス」という異常に個性的なWEB系カンファレンスがfunconfです。

概要

サイトから読み取れる特徴をざっと並べてみます。flickrなどを検索しましたが、残念ながら写真などは発見できませんでした。

• 会場は35人乗り、12輪バス
  参加者はバス２台に分譲して参加します。途中、換気とバスの乗り換えの為に止まりますが、基本的にはダブリンを出発して走行しながらの講演。バーやトイレのついたリムジンバスのようです。
• 朝９時開始、終了午前２時
  スケジュールを見ると午前２時まで予定が組んであります。しかもまだ夜は早いって・・・・。海外のイベントはハードだなぁ。OpenMicはフリートークの事でしょうか？
• スピーカーは豪華
  DiggのリードアーキテクトだったJoe Stump、Gravatarを作り、現在はgithubのTom Preston Wanner、FirebugやFacebookのiPhone AppのJoe Hewittと名前は初めて聞きましたがすごい業績の方々のお話が聞けたようです。

日本でもバスツアーできるかな

日本ではLL温泉という温泉で行う合宿がありますが、観光バスをチャーターしてやればこういうスタイルができるかもという気がします。まぁバスの中だと車酔いするので、PCとかを使わずにできるように工夫する必要はありますが。東京で集合しバスで温泉、その後はハッカソン・・・・なんてどうですかね。

安定版のリリースに向けて着実に歩を進めているLithiumのバージョン0.8がリリースされました。
Nateから出ているリリースノートを訳してみました。

原文

http://rad-dev.org/lithium/wiki/blog/Lithium-0-8-And-then-there-were-2

Lithium 0.8 – And then there were 2

我々は最終的な安定版APIのLithiumフレームワークまで残すところ2つのリリースという所に差し掛かりました。まもなく、企業が開発に自信を持って利用できる固定されたAPIが提供されます。
しかし、我々はすでに非常に高度なアーリーアダプターを見て興奮している。リチウムの最初の（未発表の）プロジェクトを開発している由緒ある[アナログ]がそうだ。我々は彼らのインプットと専門知識の受益者であることを誇りに思う。
このリリースには多くの新機能が含まれます：

• 完全にリファクタリングされたテストスイート。テストスイートは、より柔軟な自動化ツールのサポートを改善しています。
• `Adaptable` ストラテジの完全な再実装`。ストラテジのシステムは非常に強力であり、すべての入力およびアプリケーションの出力などを広範囲に制御できます。
• 新たな戦略システムによってデータの最も安全なストレージメカニズムHMACのセッションとクッキーのデータ格納をサポートします。
• `Form`ヘルパーのHTML5のフォーム要素のサポート。
• 他の多くの小規模な機能とパフォーマンスの最適化。

API の変更

• `lithium\storage\cache::write()`のパラメータのリストは変更されました。詳細については、APIをご参照ください。
• より良い内部APIの整合性、`lithium\data\model::__init()`はパラメータを受け付けなくなります。同じ挙動をさせるには `config()`を使用するようにコードを変更してください。

現在、我々は開発者が強力なツールセットについてみることに興味を持っています。私たちは、APIを現在から1.0の間で変更しないと約束することはできませんが、我々は自信を持っているAPIのコアのほとんどは現在かなり安定して利用の準備ができています。以前のポイントリリースでは、全ての互換性の無い変更と関連するすべての移行手順と同様に完全にリリースノートに記載されます。
wikiの完全な変更のリストをチェックしたら、次にそれをダウンロードして試してみてください！

~nate

–訳ここまで

大きな変更が少なくなり、安定版のリリースが近付いている事が感じられます。またデバッグを容易にするためのツールなどの機能の実装が行われるとのことで挙動が分かりやすくなりさらに利用しやすい形になっていきそうです。今後も注目ですね。

PHP5.3専用のもっとも革新的なフレームワークLithiumの最新版である0.7が2010年3月8日にリリースされました。今回はMySQLサポートの正式対応が追加され従来型のアプリケーションの開発が飛躍的に向上しました。またコードの再利用を進める為の内部の最適化も引き続き行われています。詳細はいつものようにリリースノートの和訳を作りましたのでそちらをご覧ください。
またGwooがOrange Countyで行ったプレゼンテーションの資料と音声も公開されているので要チェックです。

原文

http://rad-dev.org/lithium/wiki/blog/Lithium-0-7-luck-of-the-irish

Lithium0.7 Luck-of-the-irish

私たちは近づいてきたセントパトリックデーのお祝いに夢中になる前に、最新版のLithiumのリリースを準備できました。Lithium0.7は170のコミットを6人の開発者から受け取り、私たちはまた一歩の安定版のリリースに近づきました。
当初よりLithiumはドキュメント指向のデータベースをサポートし、高い比重を置いていました。私たちは依然として高速にパフォーマンスに配慮し、かつ柔軟なアプリケーションの構築と柔軟なアプリケーションの開発にはデータストレージに新しいアプローチを使用する事が大きな利益になると考えています。しかし、我々はまだ従来のリレーショナルデータベースが多くのアプリケーションに有益な事もわかっています。この目的のために、これらの機能を統合しリレーショナルデータベースを使用するために必要な大規模なサブセットをLithium0.7に実装しました。現時点ではMySQLがテストに合格した唯一のデータベース（`SourceTest`）ですが、基盤部分はSQLite3、PostgreSQLなどのその他のデータベースにも適用できます。すでにMSSQLの作業は進行中で、[li3_mssqlプラグインとして進行中]（http://rad-dev.org/li3_mssql/wiki）、もちろんこのデータベースや他のデータベース実装へのコントリビューションは大歓迎です。
また、SQLをサポートする為に`Adaptable`クラスに計画的な実装をLithium0.7で追加しました。計画はどのようにデータが転送され、アダプタに適用される変更を抽象化して提供します。たとえば、あなたが`Cache::write()`を使用してデータを保存し、`Cache::read()`てデータを取り出したいとします。この機能は、コアに含まれている`Serializer`という計画を通じて簡単に実現できます。`Cache`アダプタに対するインターフェイスは`Base64`、`Json`、`Serializer`が実装済みです。また`Adaptable`のそのほかのサブクラスに対するストラテジーは実装中です。
ChangeLogを見てもらえれば（http://rad-dev.org/lithium/wiki/releases/0_7）、g11nのいくつかの大きな改善とテストのカバレッジの向上がした事がわかるでしょう。
いくつかの名前空間とブートストラップのプロセスは、アプリケーションのコア機能を委任しやすいように改良されました。いくつかの変更は、以前のリリースとの互換性がありません：

• Dispatcher::run() `Request`オブジェクトが最初のパラメータとして必要になりました。`webroot/index.php`を見てください。
• プラグインをすぐに他のライブラリと同じようにできます。app/libraries内の”plugins”ディレクトリが削除されています。現在はプラグインの追加はライブラリの追加と同じように行います。例 `Libraries::add(’li3=docs’);`
• 新しいBootstrapファイルと`bootstrap/action.php`の代替の`switchboard.php`の除去。
• bootstrap/libraries.php内の `Libraries::Add(’app’, array(’default’ => true));` はあなたのアプリケーションを ‘default’ ライブラリとして提供します。
• `Connections` はconnections.phpを読み込まなくなりました。有効にするには`config/bootstrap.php`で設定してください。
• `Connections::add()の`は現在2つのパラメータを受け取ります。`config/bootstrap/connections.php`を参照してください。

PHP 5.3およびLithiumに関する2時間のプレゼンテーションをここで読めます。（音声あり）：http://lithify.me/presents
我々は、高速開発のスケジュールをイテレーションフライデーと共に進めてきました。私たちは減速するつもりはありません。予定どおり安定版は2010の初夏にリリースできるでしょう。
うまくいけば、このプロジェクトの成功はプロジェクトに関わる全ての人にとってエキサイティングなニュースになるでしょう。いつものように、われわれはどんな形のコントリビューションも大歓迎で待っています。
〜gwoo

–翻訳ここまで

MySQLなどの従来型のデータベースがサポートされましたが、ドキュメント指向データベースこそが高速で柔軟なアプリケーション開発をもたらすという強い意志が伝わってきます。かつてCakePHPなどが流行り始めた際はDRYなフレームワークこそが高速開発を実現する事を世の中に示したと言えますが、時代は次のステップに向かっていますね。Lithiumは単なる新しいフレームワークではなく、こういったパラダイムシフトを提唱しようとしている事が特に大事な点だと個人的には考えています。
またCakeやsymfonyなどの近代的なフレームワークではプラグインなどを利用した拡張が提供されていますが、なかなか共通部分をプラグインに切り出せないという問題にはまりがちです。その点を考慮してか次世代のフレームワークでは実装そのものとプラグインの境界線が薄くなる方向へと進んでいます。アプリケーション自体をプラグインとして実装するとイメージすると近いかもしれません。

なんにせよこのパラダイムを体感するには実際に試してみるのが一番でしょう！

• PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開
• HipHopのビルドとインストール方法(和訳)
• HipHopを実行するには(和訳)

原文

http://wiki.github.com/facebook/hiphop-php/running-hiphop

HipHopを実行するには

注：これらのコード例では、HipHopコンパイラが完全に組み込まれていると仮定します。

環境設定

まず最初に、2つの環境変数の設定が必要です。

cd .. # into the root of the hphp checkout
export HPHP_HOME=`pwd`
export HPHP_LIB=`pwd`/bin

HipHopを実行するモードの選択

HipHopは5つの異なるモードで実行することができます。これらはHello Worldの例をそれぞれ示しています。すべてのコマンドはこれらの例では、src /ディレクトリから実行されます。

まず、test.phpをと呼ばれるファイルを作成します。テキストを下記のように流し込むなら、”echo Hello World!> test.php”のような感じです。次に、以下のようにモードを選択します：

モード1：HipHopでコンパイルし、直接実行する。

hphp/hphp test.php

モード2：HipHopで一時ディレクトリにコンパイルし、コマンドラインからコンパイルしたプログラムを実行する。

hphp/hphp test.php --keep-tempdir=1 --log=3
/tmp/hphp_p6vSsP/program (use your own temporary directory name from output)

--keep-tempdir=1も-k 1で指定することができます。ハイフン一つとkのあとにスペースが空いている事に注意してください。これは、boostのコマンドラインオプションでの作業を監視するものです。

--log=3いくつかの冗長な情報の出力。どの一時ディレクトリが作成されたかを見つけることができる。--output-dir=mypathまたは-o mypathで独自の出力ディレクトリを指定することができます。

モード3：HipHopで一時ディレクトリにコンパイルし、Webサーバーとしてコンパイルしたプログラムを実行する。

hphp/hphp test.php --keep-tempdir=1 --log=3
sudo /tmp/hphp_p6vSsP/program -m server

その後、別のウィンドウから実行：

curl localhost/test.php

sudoを使用しない場合は、ポート8080上でHipHopを実行することができます。

hphp/hphp test.php --keep-tempdir=1 --log=3
/tmp/hphp_p6vSsP/program -m server -p 8080
GET http://localhost:8080/test.php

あなたのサーバーを管理するにはこのコマンドを実行：

GET http://localhost:8088

また、デーモンとしてサーバを実行することができます：

sudo /tmp/hphp_p6vSsP/program -m daemon

モード4：HipHopインタプリタで直接実行する。

hphpi/hphpi -f test.php (note the "-f" flag)

モード5：HipHopインタプリタを逐次変換Webサーバかデーモンとして起動する。

sudo hphpi/hphpi -m server (or daemon)
curl localhost/test.php
curl localhost:8088

大きなコードベースのコンパイル

まずコンパイラの様々なスイッチを理解しましょう：

hphp/hphp --help

いくつかのフラグを指定する方法が３つあります。 （1）HDF形式の設定ファイル。hdf形式の詳細については doc/hdf をお読みください。次に、--configで、使用する設定ファイルを指定します。（2）HDFファイル内のほぼすべてのオプションは、直接ドット表記形式で列挙することができます。たとえば-v "node.subnode=value" のように。（3）我々は、最も頻繁に使用されるものをいくつかのショートカットを作成しました。このようになります--force 。

最も重要なフラグはインクルードまたは除外するファイルやディレクトリを指定するものです。これらはきれいに設計されていないので、今後改善する必要があると感じています。疑問がある場合は、単にファイル名のリストを別のファイルに準備して--input-listのスイッチを使用します。

オンデマンド解析モード使用する（オプション）

コマンドラインから指定されていないファイルは、コンパイラがそれらを見つける事が出来る場合のみ 、インクルードされます。あなたの書いたinclude文下記のように扱われる事になります：

• 単純なリテラルの結合、コンパイラはコンパイル時にそれを計算することができます。
• "include_once $MY_ROOT.'/path/file.php';"のような単純な形式で記述
  注：ここでいう、$ MY_ROOTはこのような内容の設定ファイルを作成する事でコンパイラに指示することができます：

IncludeRoots {
* {
root = $MY_ROOT
path = lib/my_code
}
* {
root = $ANOTHER_ROOT
path = anotherlib
}
}

この設定ファイルを含むように--configを使用する 。コンパイラは、上記のinclude文を”lib / my_code/path/file.php”として解決します。

注：オンデマンドモードを設定することが困難な場合、すべてのコンパイルしたいPHPファイル含めるように--input-listを使用してください。

distccの使用

大規模なコンパイルについては、我々はdistccのセットアップをお勧めします。

例：PHPUnitのコンパイル

1. PHPUnitの PHPファイルをチェックアウトする：

git clone git://github.com/sebastianbergmann/phpunit.git
cd phpunit
git checkout -b 3.4 origin/3.4

2.確実かつ安全な方法として入力ファイルを指定します。

find . -name "*.php" > files.list

これはコンパイルしたいすべてPHPファイルのリストです。

3.プロジェクトをコンパイルする準備が整いました。

$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 \
--include-path="." --force=1 --cluster-count=50 \
-v "AllDynamic=true" -v "AllVolatile=true"

-k 1または--keep-tempdir=1で、新しい一時的なディレクトリが毎回作成されます。この方法はコンパイルを試している時に便利です。

PHPUnitはPHPUnitのルートディレクトリから相対的にインクルードを行っているので、--include-pathが必要です。このオプションを指定しない場合、すべてのこのような形式 “include ’somepath/file.php’;” はそれを含むファイルからの相対パスとして扱われます。

HipHopがコードに発見した警告やエラーを無視するには--force=1が必要です。このオプションがなければ、コンパイラはエラーがあれば画面上にダンプして停止します。--force=1を使った場合、これらのエラーのほとんどは実行時エラーでしょう。この場合もあなたはまだ出力ディレクトリの下に生成された CodeError.js でそれらを確認できます。

--cluster-count=50distcc無しでのコンパイルに役立ちます。このフラグがなければ、それぞれのPHPファイルに対してcppファイルが1つ生成されます。PHPファイルの数が多い場合、cppファイルのコンパイルがToo Manyで終わる可能性があります。clusteringを使えばPHPファイルの数は重要ではありません。HipHopは指定された数の.cppファイルを生成し、より簡単にdistccに少ない回数でこれを渡す事ができます。クラスタの数はdistccのワーカー数より少し少ないくらいにすべきです。例えば20台のマシンで8つずつのdistccワーカーを動かしている場合はクラスタ数は100がよいでしょう。しかし、ある種の最適値を見つけるにはコンパイル時間を比較しながらにクラスタ数を上げたり下げたりしてください。

-v "AllDynamic=true"このオプションにより 、動的な関数や、動的メソッド呼び出しを問題なくサポートすることができます。コーディング中に動的関数呼び出しや動的メソッド呼び出しをしている場合はオンを推奨します。少しパフォーマンスが犠牲になりますが、それが安全です。

-v "AllVolatile=true"このオプションにより、関数やクラスの動的な宣言を問題なくサポートすることができます。function_exists()やclass_exits()を宣言の前後で実行したり、その順序に意味があるような異常なテストを実行しない限りはオンにすることを推奨します。PHPUnitは、いくつかのクラスファイルをロードした後、新しいクラスを見つけるためその戻り値を比較する為にget_declared_classes()を呼び出すことがあります。したがって、PHPUnitにはこのスイッチを追加する必要があります。ほとんどの場合は、オンにする必要はありません。これは、パフォーマンスが場合によって犠牲になります。

4.これでコンパイルされたPHPUnitのバイナリができたはずです。もしここまで到達することはできない場合は、私たちに報告してください。バイナリを実行するには、

php phpunit.php (in PHP)
/tmp/hphp_po33pK/program -f phpunit.php (in HipHop, note the -f flag) php phpunit.php PHPUnit/Tests/Framework/SuiteTest.php
/tmp/hphp_po33pK/program -v "Server.SourceRoot=`pwd`" \
-f phpunit.php PHPUnit/Tests/Framework/SuiteTest.php

コンパイルされたバイナリの”プログラム”は、通常phpunit.phpと同じディレクトリから実行するよう注意してください。PHPUnitは、ローカルディスクから.phpファイルを探す際にfile_exists()を使っているからです。より高度な設定をし静的ファイルキャッシュを構築することで、ディスク上の場所の依存関係を削除する事もできます。

注意-v "Server.SourceRoot=`pwd`"は、通常は必要ありません。しかし、PHPUnitのかなりの数のファイル操作はいくつかのファイルの場所に基づく、ローカルディスク上にへのrealpath()を呼び出しています。だから我々はテストを実行する場合にこれを追加する必要がありました。

5.いくつかの役に立つヒント：

（1）--keep-tempdir=1でバイナリを作ったが、その名前を忘れてしまった場合は、単純なコマンドは、通常それを見つけることができます。

ls -altrd /tmp/hphp_* | tail -1

（2）多くの一時的なディレクトリがディスク容量を使い切る事があります。全てのHipHopの一時ファイルはこのよう削除できます。

rm -fR /tmp/hphp_*

例：HPHPiの下でPHPUnitの実行

$HPHP_HOME/src/hphpi/hphpi -f phpunit.php
$HPHP_HOME/src/hphpi/hphpi -f phpunit.php PHPUnit/Tests/Framework/SuiteTest.php

海平：私たちは、すべてのSuiteTest.php渡すことができますが、我々は、我々はまだ完全に、PHPUnitのいくつかのローカルディスク上の推定といくつかのマイナーなバグをのために、PHPUnit/Tests/Frameworkの下で完全にパスすることはできていません。全ての問題を修正する為に今もデバッグ中です。

例：WordPressのコンパイル

1.WordPressのコピーを取得します。注意、私たちはHipHopでWordPressをコンパイルする前に修正する必要がある2つ、3つの問題を見つけました。これらは、WordpressのSVNのトランクにも反映されていますがバックポートはされていません。

wget http://wordpress.org/latest.tar.gz
tar zxvf wordpress-2.9.1.tar.gz
cd wordpress
[patch to fix some PHP coding problems that will cause compilation errors]

2.config.sample.phpをコピーするなどしてconfig.phpを作成し、データベース情報を設定します。このファイルは、 コンパイル前に準備しなければならないので、最終的なバイナリにされます。このファイルの変更がある場合はパッケージ全体の再コンパイルが必要です。

3.すべてのコンパイルしたいPHPファイルのリストを作成：

find . -name "*.php" > files.list

4.プロジェクトをコンパイルする準備が整いました。

$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 \
--force=1 --cluster-count=50

WordPressはPHPUnitほど動的なコーディングを持っていないためPHPUnitよりも簡単です。

5.コンパイル済みのバイナリが出来たはずです。それを実行するには

sudo /tmp/hphp_xpl7hT/program -m server -v "Server.SourceRoot=`pwd`" \
-v "Server.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf

sudo WordPressがそのポートのみで動作するのでポート80にListenする為に必要です。

-m server サーバーモードでプログラムを実行します-m daemonとしても大丈夫です。

-v "Server.SourceRoot=`pwd`" 画像やcssファイルを見つけるには、依然として必要です。

-v "Server.DefaultDocument=index.php" http://server/ として動作する為に必要。

-c $HPHP_HOME/bin/mime.hdf静的なコンテンツのファイル拡張子に応じて異なる MIMEヘッダを提供する必要とするサーバーではロードする必要がある。

冗長なログを参照するには、

-v "Log.Level=Verbose"これはエラー、警告、情報よりも多く出力します。
-v "Log.NoSilencer=on"は、WordPressのコードで多く使用される@演算子でエラーを出力します 。
-v "Log.Header=on"ログの各行のヘッダに出力されます 。ほとんどのヘッダは16進数による長い文字列です。これは16進エンコードされたスタックトレースです。これを読めるように変換するには以下のコマンドを実行します。

/tmp/hphp_xpl7hT/program -m translate the-long-hex-string-without-brackets


–訳ここまで

• PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開
• HipHopのビルドとインストール方法(和訳)
• HipHopを実行するには(和訳)

原文

http://wiki.github.com/facebook/hiphop-php/building-and-installing

ビルドとインストール

HipHopはCentOSとFedora向けに開発されており、他のオペレーティングシステム上でのビルドは現在のところ機能しません。他のオペレーティングシステム向けのサポートは準備ができ次第追加されます。

前提条件

HipHopの前提条件はすべてをを静的にビルドする事です。ほとんどのパッケージは直接あなたのディストリビューションのパッケージ管理システムからインストールすることができます。

必要なパッケージ

• cmakeの2.6以上のバージョン
• g++ / gccの4.1以上のバージョン
• Boost 1.37以上のバージョン
• flex
• bison
• {re2cの{0}0.13.0以上のバージョン
• libmysql
• libxml2
• libmcrypt
• libicu 4.2以上のバージョン
• openssl
• binutils 及び binutils-dev
• libcap
• gd
• zlib
• tbb インテルのスレッドビルディングブロック
• libmbfl： git clone git：/ /github.com/scottmac/libmbfl.git
• Oniguruma
• libpcre3
• libexpat

カスタムパッケージ

以下のパッケージは若干の変更が加えられており、最新のソースのコピーに対して提供されているパッチを当てる必要があります。

• libcurl src/ third_party/libcurl.fb-changes.diff
• libevent 1.4 src/third_party/libevent.fb-changes.diff

パッチを適用するにはあなたのビルド環境は：
curl-7.20.0 hiphop-php libevent-1.4.13-stable

次のコマンドを入力します：
cd libevent-1.4.13-stable
cp ../hiphop-php/src/third_party/libevent.fb-changes.diff .
patch < libevent.fb-changes.diff
cd ..
cd curl-7.20.0
cp ../hiphop-php/src/third_party/libcurl.fb-changes.diff .
patch -p0 < libcurl.fb-changes.diff

パッチ処理中にエラーが表示される場合は -p0 を入力しないでください。

バンドルパッケージ

• src/third_party
  • libafdt
  • libmbfl
  • sqlite3
  • timelib

ビルド

ソースからIntel TBBを使用する

ソースからTBBの構築した場合や、、手動でバイナリをインストールした場合はいくつかの変数をバージョンと場所のヒントを与えるためにエクスポートする必要があります。

export TBB_INSTALL_DIR="/home/user/tbb22_012oss"
export TBB_ARCH_PLATFORM="intel64/cc4.1.2_libc2.5_kernel2.6.20"

目的はls $TBB_INSTALL_DIR/$TBB_ARCH_PLATFORM　に対してリンクするファイルが表示される事です。

ビルド

CMakeは、現在の選択されているビルドツールです。

あなたのカスタムのlibcurl、libeventや、必要に応じてインストールした他のライブラリの場所をCMakeに指し示す必要があります。CMAKE_PREFIX_PATH変数は場所のヒントを与えるために使用されます。

export CMAKE_PREFIX_PATH=/home/user

HipHopのビルドは下記のように行います。

cd /home/user/hiphop
git clone git://github.com/facebook/hiphop-php.git
cd hiphop-php
git submodule init
git submodule update
export HPHP_HOME=`pwd`
export HPHP_LIB=`pwd`/bin
cmake .

これが終わるとビルドに必要なファイルが生成されシェルに処理が戻ります。最後にmakeを実行します。エラーが発生した場合は、チェックアウトしたディレクトリ内のCMakeCache.txtの削除が必要です。

make

–訳ここまで

PHP5.3以降専用の先進的フレームワーク、Lithiumの0.6がリリースされました。(Lithiumの基本情報はこちらの記事をどうぞ)
良好な開発体制に支えられて安定版のリリースに向けて着実にプロジェクトが進行しているようです。

いつものようにリリースノートを和訳しました。
今回は2009年10月に来日したJoelがリリースノートを記述していますね。

原文

http://rad-dev.org/lithium/wiki/blog/Lithium_0_6_Big_Improvements_A_Brewin

Lithium0.6：大きな改良の醸造

過去3週間のタイムラインをご覧になっていたのであれば、安定版にむけたLithiumの活動が押し寄せている事にお気付きでしょう。
Lithium-0.6 では後方互換性のないいくつかの変更があります。：

• 新しい最上位レベルの名前空間、`\lithium\net` が作成され、`\lithium\util\Socket`、`\lithium\util\Socket\*`、`\lithium\http` がこの新しい名前空間の下に移動しました。
• アプリケーションレベルのブートストラップ設定ディレクトリを `\app\ config\bootstrap` に作成。これはあなたにあなたのブートストラップシーケンスをより小さく、論理的な塊に分割することができます。そしてこれらはすべて、自動的にロードされます。
• すべてのプラットフォーム用のコンソール出力にカラー表示をサポート。POSIX互換性のあるエスケープ文字をサポートします。
• ほとんどの`li3`コマンド（`test` コマンドも含まれ、、テスト結果を緑赤で表現）で重要な情報をハイライトされカラーで出力されます。
• テンプレート層の完全な見直しを行いました。カスタムストリームクラスは今後はレンダリングに使用されません。APCとうまく動作するテンプレート層の為です。ビューテンプレートはコンパイルされて `app/resources/tmp/cache/templates/`に格納されるようになりました。古いバージョンからアップデートを行う場合は、このフォルダパスが存在している事を確認してください。
• マイナーなキャッシュの愛をLibrariesを `app/config/bootstrap\cache.php`。(ロスのないフィルタとして)
• 適切なロケールをアクション、コンソールへのリクエストから検出する機能の追加
• G11nの環境設定を一元的および世界的に有効なロケールの切り替えの導入。
• g11nのいくつかの名前とメソッドのシグネチャを、より合理的なAPIに変更しました。
• `Cache`アダプタのほとんどのAPIの変更：
  • MemcaceとAPCキャッシュアダプタでのマルチキーのサポート(どのメソッドがこの機能をサポートするかはドキュメントを見てください)。
  • `Cache::write()`からのキー生成時の不要な’\_expires’キーの削除。今後はキャッシュキーを汚染しません。
• 改善されたドキュメントとテストなど。

Lithiumのハッキングから離れて、我々はいくつかの非常に有用なフィルタシステムのユースケースを管理しました：

上記のような基本的な変更がありましたが、Lithiumのコア部分は確かな状態です。さらに新たな機能は毎日のように追加されています。われわれはフィニッシュライン中間地点より先を通過し、勢いはさらに増しています。
*[変更履歴]（http://rad-dev.org/lithium/wiki/releases/0_6）
*[ダウンロード 0.6]（http://rad-dev.org/lithium/versions）
最新の開発状況は[Rad-Dev]（http://rad-dev.org/lithium）をご覧ください。[APIドキュメント]（http://lithify.me/docs）、IRCチャンネルは`irc.freenode.net`上の`＃li3`と`＃li3-core`です。

〜jperras

—訳ここまで

国際化対応やビュー、コンソールのカラー表示など出力系の変更が多く入っているようですね。ビュー層の変更がどのようにＡＰＣを考慮しているかなどは実際に動かしてみながらみるのがよいでしょうか。次回のリリース(3/8)ではMySQLやキュー、初期画面などが追加・改良されるようです。ますます楽しみですね。

Lithiumに関する過去の記事

2/21追記:
マニュアルなどの和訳も行いました。

• PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開
• HipHopのビルドとインストール方法(和訳)
• HipHopを実行するには(和訳)

原文

http://developers.facebook.com/news.php?blog=1&story=358

Facebookにおいて重要なことのひとつが開発スピードが早いことです。過去6年間にわたって、PHPが提供する高速な開発ペースによって多くを成し遂げてきました。プログラミング言語としてみると、PHPはシンプルです。簡単に習得し、簡単に書き、簡単に読み、簡単にデバッグする事ができます。我々は他の言語よりも早くエンジニアを獲得し、それによってより早いイノベーションをすることができます。

今日、私は2年に渡って作業してきた素晴らし小さなチームのプロジェクトを共有することに興奮しています。
HipHop for PHP。HipHopにより私たちはページによっては、Webサーバー上で約50パーセントのCPU使用量を削減できました。CPUの使用量の少なさは、サーバー台数の削減につながり、それはより少ないオーバーヘッドを意味します。このプロジェクトは、Facebook上で多大な影響を及ぼしました。私たちはHipHopがウェブに大きな利益をもたらすと感じ、今晩オープンソースとしてリリースしPHPによる大規模WEBサイトのスケーリングに新たな方向性が提示されると期待します。いまだ完全ではないHipHopでも信じれれないような結果を残しており、ベータ版であっても心地よいものであるでしょう。

HipHop for PHPは技術的にはコンパイラではありません。むしろ、ソースコードの変換機です。HipHopはあなたのPHPのソースコードをC++に最適化された形に機械的に変換します。そしてg++でコンパイルされます。HipHopは意味的に同等の方法でソースコードを実行しますが、いくつかのまれに使われる機能(eval など)を犠牲としてパフォーマンスを向上させます。HipHopコード変換機は、PHPランタイムの再実装であり、また多くのパフォーマンス向上の為のPHPエクステンションを書き直したものです。

スクリプト言語としてのスケーリングPHP

PHPのルーツは、PerlやPython、Rubyのようなスクリプト言語で、すべてのプログラマの生産性の面で大きな利点があり、迅速かつ継続的な開発を可能にします。これはC++やような伝統的なコンパイル言語やJavaのような中間言語と比較した場合です 。一方、スクリプト言語は一般的にCPUおよびメモリの使用に関して効率的でないことが知られています。このため、月間4000億以上のページビューでPHPをベースにしたFacebookをスケールするという事は挑戦的な事でした。

これらの非効率性に対処する1つの一般的な解決法はPHPアプリケーションの複雑な部分をPHPエクステンションとしてC++で書き直す事です。これによりPHPはフロントエンドのHTMLとC++のロジックをつなぎ合わせる糊のような言語に大きく変化します。技術的な観点はうまくいきますが、アプリケーションに携わる事ができるエンジニアの数を劇的に減らしてしまう事になります。C++を学ぶ事はPHPエクステンションを書くための最初の一歩にすぎません。次にZend APIを理解しなければいけません。我々のエンジニアリングチームは100万ユーザ当たり1人と比較的小さいものですが、私たちのコードベースの一部を他のものよりアクセシブルにするわけにはいかないと考えました。

ほとんどのページがログインしたユーザによってカスタマイズされるFacebookのスケーリングはとりわけ挑戦的です。あなたのホームページを表示する際はすべてのあなたの友人のルックアップする必要があり、関連する更新を検索し、（マルチフィードと呼ばれているカスタムサービス）、お客様のプライバシー設定に基づいてフィルタリングし、コメントや写真などの豊富なデータを補います。そのような豊富なデータが、人々がFacebookの愛している部分です。これらすべてが１秒以下で行われます。HipHopによって最終的にPHPとして組み立てられるロジックを、迅速かつ継続的に書く事ができます。またこのロジックはC++やErlangやJava、Pythonで書かれたバックエンドサービス、ニュースフィード、検索、チャットサービスおよび他のコア部分などと連携しています。

2007年には、これらの問題を解決するための、いくつかの異なる方法を考案しそのうちいくつかの実装を試みました。共通の改善案はFacebookを別の言語で書き換える事でした。ですが、サイト開発の複雑さと速度を達成するためにいくらかの時間がかかると思われました。我々はPHP内部のZendエンジンも書き換えそれらのパッチを寄付しましたが、最終的に必要としてパフォーマンス向上には至りませんでした。HipHopの利益は我々の開発スピードがほとんど変わらない事です

HipHopの誕生

数年前のhackathonでの一夜に（プライムタイムのハック）、PHPをC++に変換するコードを書き始めました。かなりの構文の似ているC++は、CPUとメモリ使用量に関してはPHPを大きく凌いでいます。PHP自体もCで書かれています。我々はこれほどの量のコードを書き直すのが不可能な事はわかっていましたが、もしプログラム的にこれを行うシステムを構築したらどうなるだろうと思いました。

PHPのパフォーマンスを改善するための新しい方法を見つける事は新しいコンセプトではありません。実行時には、Zend EngineはあなたのPHPソースをオペコードに変換し、その後、Zendの仮想マシンを介して実行されます。APCとeAcceleratorのは、この出力をキャッシュしPHPで提供される大多数のウェブサイトで使用されます。またZend Serverは、オペコードの最適化とキャッシュを介してPHPを高速化する商用製品です。その代わりに、我々はPHPのソースコードを直接C++に変換した後にネイティブのマシンコードに変換することを考えました。PHPをコンパイルする事も新しいアイデアではありません。RoadsendとphcはPHPをCにコンパイルし、 QuercusはPHPをJavaにコンパイルし、 Phalanger はPHPを.Netにコンパイルします。

言うまでもなく、一度のhackathonだけでは終わりませんでした。8ヵ月後、私は速くコンパイルされたコードを実行することが可能であることを示すのに十分なコードを得ました。我々はプロジェクトのスピードアップにイアン・プロクターとミンハイ・ヤンをプロジェクトのスピードアップの為にメンバーに加えました。我々は、続く10カ月をすべてのコーディングに、次の6ヶ月を本番サーバー上でのテストに費やしました。我々はリリースから6か月の時点で、Webトラフィックの90％以上のHipHopを使用して提供していると事を誇りに思っています。

HipHopの動作

プロジェクトの主な課題は、PHPとC++の間のギャップを埋めることでした。PHPは動的な弱い型付けを持つスクリプト言語です。C++は静的型付けのコンパイルされた言語です。一方、PHPは魔法のように動的な機能を記述することができ、ほとんどのPHPは比較的簡単です。if(…){…} else {..}はfunction foo($x) { include $x; } よりも好ましいです。これは、我々がパフォーマンスを稼いでいるところです。私たちの生成したコードは変数や関数の静的バインディングをいつでも使用可能です。また、変数のほとんどに型推定を用いてメモリを節約します。

変換プロセスは3つの主な手順が含まれます：

1. 収集した情報から何が宣言され、何に依存しているかの静的分析
2. C++の特定のタイプを、スカラー、文字列、配列、クラス、オブジェクト、およびバリアント型から選ぶ型推定
3. ほとんどの部分のPHPのステートメントと式をC++のステートメントと式に直接対応されたコード生成

また我々はHPHPi も実験的なインタプリタとして設計し開発しました。HPHPiを使用すれば、PHPのソースコードを実行前にコンパイルする必要はありません。これは私達がヒップホップ自体のバグをキャッチする事と、技術者がコードを書く方法を変更せずにPHPコードを書けるようにします。

全体的にはHipHopはC++のパフォーマンス上のメリットを活用しつつ、PHPの良い面を維持することができます。合計では我々30万行のコードとと5000以上のユニットテストを書きました。今夜GitHub上で、全てがPHPライセンスの下でリリースされます。

今夜のお楽しみ

今夜、我々はHipHopの深部へ飛び込む開発者の小さな集まりをストリーミングします。ご覧になりたい場合は太平洋時間19:30に再度こちらのページをご覧ください。

今夜、多くの質問があると思いますが、HipHop wikiを見てください。（リンクを後ほど公開するつもりです）あるいは、 HipHopの開発者メーリングリストに参加してください。また今後数ヶ月、FOSDEM 、 SCALE 、PHP UK、 ConFoo、TEX　X、OSCONなどのイベントで、でHipHop for PHPについて講演をします。我々は非常に盛んなオープンソースプロジェクトに皆さんと一緒にHip Hopが進化することに興奮しています。

海平趙、シニアエンジニア、Facebookがプログラマの楽園と悟っています。

—訳ここまで

長文という事と、タッチが慣れないという事があって誤訳があるかもしれません。自分なりに咀嚼して書いてみたつもりですがご意見などあればTwitterなどで頂ければと思います。次はだれが最初に試すか、本番に投入するかという勝負ですね。とはいえFacebookでは90%のトラフィックで利用しているとの事ですからコードの書き方に気をつければ安定しているのでしょう。ということでみなさん、お試しあれ！