ちょっと作業時間が取れなかったので大幅に遅れてしまいましたが、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はアスペクト指向を実装に取り入れている部分があり、従来のスタイルのフレームワークの知識を前提にして考えると分かりづらい所があります。これらの例は全体の継承関係や処理のフローを考慮することなく、断片的な修正をクロージャなどを使って実現できるという点がすごい所と言えるでしょう。

• 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


–訳ここまで

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%のトラフィックで利用しているとの事ですからコードの書き方に気をつければ安定しているのでしょう。ということでみなさん、お試しあれ！

発表の内容

このブログでもたびたび、紹介しているLithiumの特徴をデモを交えて紹介しました。
CakePHPに良く似た記述量の少ないプログラミングとPHP5.3の機能を活用している部分を感じてもらえればと思います。
おそらく今後はPHP5.3に合わせたプログラミングが一般的になっていくと思いますが、習得には実際に触れるのが一番でしょう。LithiumにはPHP5.3を実際に活用した生きたコードがあり、その優れた拡張性はきっと癖になってしまうでしょう。

ぜひぜひお試しください！

追記
思わぬ反応が得られたのでDig A Ponyのリンクも埋めておきますｗ
歌詞はググれば出てきます。

資料

参考： Dig A Pony

勉強会の内容

休日開催という事もあり、盛りだくさんな内容でした。ちょっと眠かったので記憶に残っていない部分もあったりします。CakePHPユーザーの割合が８割程度という事で利用の幅広さを感じました。またcakephperさんのMongoDBの発表はとても刺激的で、CouchDBのセットアップに挫折した自分としてはとても魅力的でした。IRCにはLithiumのJonも来ていて翻訳ソフトを使ってコミュニケーションを取っていました。
PHP勉強会もNoSQLや国際化などの新しい波が来ているのかな、と思うところがありとても楽しかったです。

最後になりましたが、ustreamの配信をしてくださったNEKOGETさん、運営のgusagiさん、発表者、参加者のみなさんおつかれさまでした！
今年もいい年になるといいですね。

今回は25分予定のところを40分も喋ってしまいました。動画とかをスキップすれば納まったかもという事でちょっと反省です。また日本時間夜の勉強会はこちらは朝になるのでテンション的にボソボソした感じになってしまったのがつらいところ。。。
発表資料もあげておきます。

slideshare

ustream

聞いてくださった皆さん、USTをして頂いたNEKOGETさん、Skypeを受けてくださったgusagiさん、ありがとうございました。

たとえば・・・

「コピペで動かすのが精一杯」
「とりあえずすいすい書ける人」
「ライブラリとかを使える人」
「ライブラリを作れる人」
「PHP自体をいじれる人」

のような感じです。PHPユーザ会が運営しているPHP勉強会なども毎月開催されていますがこのステップをどうやって登るかというのは難しい問題です。その意味でこの資料はとても役立つ内容になっていると思います。「とりあえずPHPは書けるけど、今のトレンドに合っているかわからない」なんていう方は是非ともこちらの資料を見てみるといいでしょう。なお同様のコンセプトでモダンPHP勉強会が開催されるようです。

まだ勉強会開催を控えていますが、sotarokさんお疲れ様です。

ここにも書いたOpenHackDayの話を10分ほど。
発表を手伝ってくれたakiyanさんありがとう！
OpenHackの話が気になった人は過去のエントリもご覧ください。

OpenHackNYC レポートその１
OpenHackNYCのレポート その２
OpenHackNYCのレポート その３
OpenHackNYC Hack Demoレポート
映像で振り返るYahoo Open Hack

skypeの画面共有を使ってプレゼンをしていたのは初めてですが、おおむね問題なかったようです。
一部声が割れたというのはノートPC内蔵のマイクを使ったのが良くなかったですね。
次があればいいマイクかヘッドセットを使うようにします。

発表資料を一応あげておきます。

20091107 Phpstudy

PHP以前

小学生の頃にMSX-BASICとN88BASICに出会う。特にMSX-BASICは中学生くらいまでリストの打ち込みや改造、アセンブラあたりまでやっていた。ちょうどMSX関連雑誌の相次ぐ休刊によりしばらくプログラミングから離れる事に。
その後、大学時代にWEBサイトを友人と作ることになりコンテンツが多かったので自動で更新する方法を模索。結論としてはperl/CGIのWEBインターフェースからCSVを読み込んでコンテンツを生成する方法に落ち着く。
perlの文法はkent-webの掲示板を改造しながら覚えた。生成したテキストファイルをssiでinclude virtualして読み込んでいた。全体までperlから生成してしまうとちょっとした修正をする時にツールを起動しなおすのが面倒なのでそういう形式にしたのだと思う。

PHPとの出会い

大学を卒業後にバイトで講師をしていたIT系のスクールで飯塚さんに出会う。なんかの時に作っていたサイトの構成の話になり「SSIでインクルードするよりPHPにした方が簡単だよ」と言われ、試してみると確かに簡単。
SSIの時と違いエラーが画面で確認できるのがとてもよかった。(裏でターミナル開いてエラーログを確認しないでいい)ということでサイトをPHP＋MySQLに作り直す。ついでにPHPの講師も始める。PHP4.2の頃で授業ではmb_stringを有効にする方法とかを教えていた。

PHPで開発案件

その後、知り合いのつてでちょっとしたツールなどを書く仕事をPHPでやっていたが、またしても飯塚さんの誘いで「PHPで大規模案件」をやっていてヘルプで入って欲しいとの誘い。初めて参加した開発案件はデスマーチだった。
ここでSmarty＋PEARで大がかりな携帯サイトの開発に関わりエラー処理やまともなモジュール設計などをPHPで初めてやることに。
でも今思い出すと顔から血が出そうなくらい恥ずかしいコードを量産していましたよ。

楽天の開発現場とコミュニティ

しばらくマイペースでやったあとに楽天の現場で働くようになり、MojaviだったりMojaviっぽい何かを使った開発をやるように。少し前にStrutsやらアプレットやらをやっていたので構成自体には戸惑いはなかった。ただオレオレフレームワークの設定ファイルの場所などをコードを読んで理解するなどの作業は最初はちょっと大変だったが、読めばわかるのが救いだった。
少ししてPHP勉強会にも参加するようになり講師時代に触る事の多かったWindowsとPHPの話で発表デビュー。その後はCakeを触るなどしているうちに本を書いたり、海外に行ったり、受賞したりで今に至る。

PHPのここが好き

自分自身が文系の出身なのでプログラミングというのは教わるものではなくいつも自分で触って体得するものでした。何の素養もない自分にとってはエラーを画面に垂れ流してくれたり、オブジェクト志向の作法を気にせずに制作することが出来たのは大きな利点でした。
実際、perlのツールをいじってたころはモジュールの意味とか分からずに書いてたし。

使う立場、教える立場の双方でPerl、、PHP、J2SE、ActionScript、JavaScriptと関わってきましたが付随するツールや環境の設定作法が多いものは未経験の方に教える時には障害になりやすかったです。その点で環境の設定やデプロイ、エラーの確認がやりやすいPHPは初期の学習コストが非常に低いのだと思います。
最近はRubyも触っていますが、RedmineとWordpressではやっぱりWordpressの方が設定が簡単であると言わざるを得ないと思います。

そういうわけで僕がPHPを好きな理由はなんとなくでも動かせる簡単さと使い勝手（デプロイ）のよさという事かなと思います。
そういう意味ではJavaScriptも全く同じような特性を持っていますね。他の言語も触る機会はありましたがPHPに出会ったからこそ今の自分があったと思うし、もしPHPが無かったらどこかで野たれ死んでいた気がするので、PHPに対する感謝の念はとても大きいです。

ダサくたっていいじゃん！みんなが簡単に使えてそれで何かを作れたならそれってハッピーじゃん！PHP最高！
ご清聴ありがとうございました。

#誤記をブックマークコメントを元に修正しました、ありがとうございます！

CodeWorks 2009 New York 1日目参加レポート
CodeWorks 2009 New York 2日目参加レポート（前編）

だいぶ長編になってきましたが、2日目のランチ以降について引き続きレポートします。

ソーシャルランチ

CodeWorksはランチがチケットに含まれていて会場内で食事が提供されます。
ちなみにチケットは2日間で$399と約４万円と聞くと高いかもしれませんが、この手のイベントとしては標準かすこし安いくらいの値段です。
昨日と違いボックスランチではなくビュッフェ形式です。

やはり空いている席に座る形式でどこもにぎわっています。
空席がなくてたまたま座った席はDerickやBenといったスピーカーが集まるテーブルでした！
最初は５０代以上のマダムな方が出版とテクノロジーについて自説を唱えており、全員で聞き入るという微妙な空気でさすがに割って入れない。。。
そのあと解散気味になってからDerickやBen、CodeIgniterのセッションを担当していたEdなどと話しをする事ができました。
ちなみに話のネタはPHPカンファレンスのスタッフTシャツ。

ニューヨークのチーズケーキはうまい！

PHP Oracle Web Applications: Best Practice

スポンサーでもあるOracleのセッションです。だいぶ閑散としていて１０人も居なかったのですが、講師のKuassi Mensahさんが気さくな方でインタラクティブに進める形になりました。

会場から質問が出ると「いい質問だね！」といってOracleロゴ入りのelephpantのぬいぐるみを投げて渡す！
うおお、これは断然テンションが上がります。

ということで気になっていた事などをいくつか質問しました。

「tnsname.oraを使わずにプールしたコネクションにつなげるか？」
「PDO_OCI8はいつ安定するのか」

本気なので実務的な質問をぶつけます。
回答としては、、、

「直接接続も可能だけれどtnsname.oraで制御した方がコードの改編が少ない」
「PDOのドライバの開発はコミュニティに委ねているので、メインはoci8と思ってほしい」

との事です。symfonyで今後oracleを使う場合は安定していないPDOを嫌ってORマッパを放棄する事になってしまうのでしょうか。
他にもPDOを使うことを期待しているものってある気がしますが。。。
肝心のelephpantなんですが、goodの評価はもらえず写真だけでもと撮影していたら「ほしいならあげるよ」ってもらえました！やったー！

日本に持って帰ったら写真をとってDerickに送るように言われましたが望むところです！

Webservice Design with AtomPub

PHPのコミュニティを長年支えてきたBen Ramseyさんの発表です。会場内も３０人くらいと満杯に近い状況。
内容はコードは一切なしでAtomフォーマットについてのお勉強といった形です。
RSSフォーマットとAtomでできることの違いや成り立ちなどを丁寧に解説していました。

内容がキャッチーだったのか女性の参加者が多く集まったのも印象的です。
またCakePHPのコアデベロッパーのNateがひょっこりと現れて会場におり、「のど乾いたらから水とってきた」とbenにお願いされて「Ok」と水を取りに行く場面も。
PHP本体のコミュニティとCakePHPのコミュニティの人的なつながりをこの目で見たような気がして微笑ましい出来事でした。

all the littlee pieces

Diggのフェローであり、PHP6のUTF8対応の担当でもあり日本へ与える影響も大きいAndrei Zmievskiさんのセッション。
twitterアカウントは驚異の@a。
取れるかなと試したら一発目で取れたそうです。

内容は詳細なスライドがWEBに挙がるそうです。
分散システムということでMemcacheやMogileFS、Gearmanといった技術の採用事例を基礎から解説する形です。
Memcache以外のDanga製プロダクトは日本ではなじみがありませんが、スケールアウトを効率的に行うすぐれた技術ということが証明されたようなセッションでした。

ちなみにMogileの発音は「モガイル」でした！
思ったよりもAndreiごついな~という印象でしたが、話をするタイミングが無く残念。

Debugging with XDebug

PHPのChange LogでおなじみのDerick LethanさんによるxDebugのセッション。
僕も業務で利用していますがxDebugの機能を一通り丁寧に、また作った際の動機やエピソードを交えて話してくれました。

デモの際の数値で参加者から「なんかおかしくない？」「おかしいね」「あっ」「Mystery Solved!（解決）」なんて流れが楽しい感じです。
またDerickはIDEにKomodoを使っているとの事でPDT派としては目新しく映りました。

なんにせよこれが１５回目のセッションということで疲れており、「これで終わるのがうれしい」との事でほんとにお疲れ様でしたという感じです。

懇親会

会場にブースを出していたマイクロソフトさんの提供でハッピーアワー、まぁいわゆる懇親会が開催されました。
会場ではRuby好きなニューヨーカーや、CakePHPのNate、JoomlaのMilchと話をしました。
なんでもJoomlaのイベントを来週にやるそうですが１３０人の枠が一杯になってしまったとのこと！

全体を通して

合計１３時間ものセッションがあり大変疲れましたが、やはりコミットログやソースコードで名前を見かける人のセッションを聞くことができてとても充実していました。
こうやってレポートを書くだけでも疲れるほどのボリュームですが、３トラックなんです。
つまり全体はこれの３倍あるんです。。。。

脱帽です。
またさまざまなOSSのキーマン達が交流していたり雑談している内容などにちょっと感動を覚えますね。
redmineを使っているという人にはcandycaneの宣伝もしてみたり。。。
チケットを買うときは英語が分からないのに行っても大丈夫かとかいろいろ気になりましたが、間違いなく行って良かったです。

CakeFestの時はcakephperさんが参加されていましたが、日本から参加するユーザが言ったらこの楽しさを分かち合えるのになーと思います。
ということでこのレポートを読んで興味が出た方は来年のCodeWorksや海外のカンファレンスの予定をチェックしてみたりしてはどうでしょうか！

また日本に居ながら海外の開発者と交流ができるCakeMatsuriもよろしくお願いします。

昨日のレポートに引き続き本日のCodeWorks09についてレポートをします。
正直なところかなり疲労感がありますが、今書かないと明日からの仕事で流されそうなので気合です。
長くなりますが、最後までお付き合いくださいませ。

会場入り

今日はスムーズに会場入りする事ができました。ロビーに行くと昨日セッションをやってくれたSebastian Bergmanさんが居たのでごあいさつ。
2週間のツアーを終えてへとへとの様子でしたが、今日は観光してから帰国のスケジュールだったようです。
外観の写真を取る余裕もありました。
なお本日も３トラック構成だったのでレポートしているのは全体の3分の１です。

Extreme Scale: Thin Sever Architecture

MTVやFoodNetworkなどのサイトで利用されている有名なCMS、joomlaの作者でもある、Milch Pirteさんの発表です。
WEBサーバやDBサーバをスケールアウトするのではなく、極限までサーバーを薄くするアプローチについての講演です。
胆になるトピックはは２つ。

「MVCにおけるVの処理をサーバーでやらずにRIAに近づく」
「オブジェクトを異なるデータ構造にしてRDBに記録するのは何故」

結果としてデータをmongoDBにJSONとしてストアする最低限の処理をサーバで担当し、ブラウザ側ではすべてを組み立てるというアプローチの紹介です。
実際にアクセス数の多いFoodNetworkのサイトの例を取って「ログインユーザー名の表示」も処理ではなく、単純なデータとしてストアしているというような話をしていました。
まだ主流とは言えないアプローチですが、海外ではドキュメント型のDBが流行りつつあり十分に説得力を感じました。
またジェスチャーなどが豊かで楽しいセッションでした。

Security-Centerd Design

Essential PHP Securityの著者でセキュリティの権威ともいえるChris Shiflettさんの講演です。
セキュリティというと攻撃手法などの紹介をイメージしますが、認知心理学という単語を持ち出して人間が気づける事、注意に関するトピックを通じてセキュリティについて解説していました。

面白かったのが
「東京の地下鉄は複雑だが、路線によってチャイムが違うので乗り間違うと音で気が付く」
というJRと地下鉄を混同した話を友人の話として紹介していました。（まぁわかんないよね）
その話をする際に実際にJRのベルをiPhoneで再生したり、途中で映像を使ったりと抽象的な話を飽きずに聞かせる工夫が光っていました。
終了後も会場内は満場の拍手で、今回聞いたどのセッションよりも盛り上がりを感じることができました。

Alternative Database

セッション前におもむろにタータンチェックのスカートに履き替える魂を感じさせる男性、Scott MacVicarさんの発表です。
SQLiteのプロジェクトにも参加されているとの事でデータストアに関する深い内容でした。

ほぼ同じ内容のスライドがslideshareにあります。

おおまかな流れとしては「RDBMSはもうダメだ→memcache→tokyo cabinet→simpleDB」というような形でさまざまなデータストアの解説を行います。

日本人としてはTokyo Cabinetを知っている事がうれしくもあり、さらにTokyo Tylantの名前が出た際に「日本で作られているから日本では Tylant Tokyoって呼ぶのかもね」とかネタにしていたのでやはり名前が良かったんだろうなと思います。

長くなってきたので、次エントリに続く。。。