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

最も軽量で拡張性に優れたフレームワーク、Lithiumのバージョン0.5がリリースされました。1.0リリースに向けて折り返し地点と言った所ですね。リリースの速度が速すぎて翻訳する方もちょっと大変ですが、喜ばしいニュースですのでお伝えしたいと思います。

原文

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

Lithium 0.5, half way there.

Lithiumチームはバージョン0.5のリリースを喜んでお知らせします

バージョン番号から見ると、我々はLithiumの最初の安定版に向けた折り返し地点にいます。Lithiumチームは着実な3週間毎のリリースを続けます。またイテレーション・フライデーが助けになるでしょう。

このリリースにはいくつかの新機能が含まれます:

• apps/plugins/extensions を管理するライブラリコマンド
• モデル、コントローラー、テストをコード生成する為のコマンド
• 一般的な利用の為の国際化されたバリデータ
• 柔軟性とメンテナンス性向上の為のブートストラップの整理
• アダプタ化可能な認証API
• ビューエレメントのレンダリング
• 更なるドキュメント
• 更なるテスト

Lithiumは実際のところかなり安定していていくつかのエキサイティングな機能を含んでいます。MongoDBかCouchDBを使ってアプリケーションを開発する準備は出来ています。しかしあなたがORマッパを必要としているなら、Doctrine用のプラグインがあります。あるいはLithium上で実装されるリリースまで待たなければいけません。エクステンションやヘルパーの作成は本当にシンプルで他のフレームワークからの移植すらも簡単にできます。createコマンドを使ってコード生成をすれば開発を素早く立ち上げられるでしょう。

Lithiumチームは0.5と合わせてその他の更新をお知らせします

• 私たちは新居を見つけました: http://lithify.me
• lab.lithify.meのプレリリース。LaboratoryとLibraryコマンドはLithiumをプラグインを通じて拡張するという目的の一部です。 li3_lab プラグインによってサーバーから提供されるプラグイン・エクステンションを統合し、アプリケーション間でのコードの再利用と共有を容易にします。Libraryコマンドはアプリケーションやプラグインを圧縮・展開出来ます。またプロジェクトを始める為の基本となるアーカイブも添付しました。詳細は li3 help Library でご覧ください。

Lithiumワールドの動きは速く、さらに力強くなっていきます。お見逃しなく！
~gwoo

—訳ここまで

Lithiumのリリースが3週間毎であることが明言されました。これは前回紹介したイテレーション・フライデーで開発が着実に進んでいるとみてよいでしょう。RDBを利用するのであればDoctrineを利用するのが良いですが、MongoDBやCouchDBを使ってアプリケーションを開発するのであれば問題はないようです。実際に開発チームが運用しているアプリケーションはMongoDBやCouchDBばかりなので安定度が高まるのも当然と言えます。コードの圧縮展開などを実現するコマンドラインの進歩も目覚ましいですね。

次回のリリースは2/15ということで、試すのであればお早目に！

発表の内容

このブログでもたびたび、紹介している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さん、発表者、参加者のみなさんおつかれさまでした！
今年もいい年になるといいですね。

ニューヨークのPHPコミュニティが毎月開催しているNYPHPに参加してきました。
NYPHPは毎回、一人のスピーカーが1時間半ほど喋り、その後はTGI FRYDAYに行くという形式で開催されている勉強会です。
今回のスピーカーはCakePHPの元リードデベロッパーのNateによるLithiumのお話という事で、疲れ気味の体に鞭を打って参加してきました！

講演の内容のポイントを紹介します。

PHPとフレームワークの歴史

プレゼンテーションは最初にLithiumはもうCakePHPではないという事、枝分かれした存在である事について触れてからLithiumが誕生するまでのPHPの歴史を振り返ります。最初はPHP/FIから始まり、マークアップ的に処理が記述できる例などを示し、そこからPHP3、PHP4、PEAR、PHP5、CakePHP、symfony、CodeIgniter、Zend,,,という風にPHPにさまざまな技術的な進歩がもたらされた事をコメント付きで紹介していきます。ただのスクリプトでしかなかったPHPがだんだんと整理された機能になっていく事がわかります。また特にCakeやsymfonyについてNateがコメントする部分では質問が出る事もありこれだけでかなりの時間が。

これらの進歩により、機能をオブジェクトとしてデザインされたライブラリとして実装するという統一性は達成されましたが、引き換えにフレームワーク内の密結合や、拡張性が失われるといった事が起きています。また機能そのものについての論争のような事は極めて表面的なトピックに過ぎず、答えは人の数だけあり各自の判断でより生産的だと思うものを選択すればよいという事も述べていました。（例としてソースのインデントをタブにするかスペースにするかといった話など）

PHP5.3

そしてPHPに訪れた大きな変化として、Late Static Binding, Namespace, Clousureの話へと進みます。Late Static Bindingによりstaticなメソッドやプロパティを持ったクラスの派生クラスをようやく書くことができるようになりました。（正確には書くことはできるが、継承元のクラスから派生クラスのメソッドをコールバックするような形にできない）またNamespaceによりこれまでは各ライブラリやフレームワークが独自の工夫で解決していたクラスとファイル名をマッピングする為のルールのベースが言語としてようやくサポートされました。そしてClousureはメソッドの呼出しなどのバリエーションをさらに柔軟にする事ができるようにしてくれます。

このあたりからちょっとしたコードを書いて説明したりするようになりめちゃくちゃ面白くなってきます！

Lithiumのデモ

PHP5.3の機能の紹介からLithiumのデモへとセッションは進みます。CakeFestの時にも言っていましたが、Lithiumはブートストラップが非常に薄くなっており、処理は2行しかありません。その後の初期化処理としてはLibrariesクラスを利用してライブラリを登録する処理が行われます。ここでポイントとなるのはLithium内でつかわれるクラス群もこのLibrariesを介して操作するという事です。つまり、このLibrariesクラスを介してZendのライブラリなどを登録した場合、フレームワーク内では特に区別されず、コアクラス自体を差し替える事もできるのです。
通常、多くのフレームワークは内部で特定のクラスをハードコードして呼び合う部分がかなりの部分あり、そこが拡張しづらいポイントとなり制約となります。(symfonyもfactories.ymlである程度制御できますが、ハードコードされている部分もかなりありますね)それをPHP5.3の機能を生かして拡張可能な形を実現したのが大きなアイデアです。

またクロージャを生かして、オブジェクトへの設定などをより柔軟に与える事ができるようになった例をいくつか。たとえばRouterに対するルーティングの設定としてModelからFindした結果をマッピングして渡す、など。PHP5.3以前でやるとすれば、データを取得したのちに配列へ格納し、ループしながら設定するなどの工夫が必要になるところですが、クロージャを利用することで一行で記述できました。

そして最後にLithiumのフィルタ機能についてのデモに入ります。フィルタ機能は任意のクラスの任意の処理の前後に処理を設定する事が出来る機能です。たとえばデータベースのログを取得したければ、Databaseクラスのexecuteにフィルタを設定するといった形です。通常ならこのように処理の前後に介入するならばコールバックを設けるか、派生クラスを作りラッパーメソッドを書くところでしょう。これをシンプルな記述だけで実現する事ができます。
応用の例としてLithiumのコードカバレッジの取得がこのフィルタ機能を使っている事が明かされました。（xDebugのダンプだとデータが大きすぎる）

まとめ

Lithiumの思想についてはこれまでのたびたび、和訳で紹介してきました。しかしながら実際のデモやその他のフレームワークなどに言及しつつNateの話を聞くことでよりはっきりとその思想を理解する事ができました。通常、フレームワークというとどんな機能があるとか何が出来るといったポイントで評価しがちですがこれはNateの言葉を借りるなら「表面的で、人の数だけ答えがある」という話なのだと思います。
LithiumがCakePHPだけでなくさらに多くのフレームワークや技術の反省点を生かした上で「拡張性・軽量性」を追求しているという事がよくわかりました。

Lithiumの拡張性は高く、ORマッパにDoctrineを組み込む実装などが簡単に行えます。機能に気に入らない部分があれば作りかえるなり、他から借りてくればよい。ただしその設定や拡張に複雑な実装が必要ないように。ということですね。
一見難しいフレームワークという印象だったのですが、CakePHPの機能は引き継がれており拡張などをする場合はCakePHPよりもシンプルに記述する事ができます。

いやー、これは面白かったです。

おまけ

懇親会はTGI FRIDAYS。最初にハイネケンを頼んだ後に、バーガーを頼んだら「セットにできるよ」と言われてそれに。最初のビールに付け足してくれるのかと思いきやビールももう一杯きてちょっと大変でした・・・。

原文

http://rad-dev.org/lithium/wiki/blog/iteration-friday

Iteration Friday

ここLithiumプロジェクトではJames Martinによって提唱されたRAD(Rapid Application Development)という手法を用いています。Rapid Developmentから発生し、進化した実践としてアジャイル、スクラム、XPがあります。

Union of RADが用いている手法も進化しています。我々は強力なコラボレーション、コミュニケーションの動機、活発なユニットテストと短いイテレーションを重視しています。最後に上げた「短いイテレーション」がこの記事の目的です。

明日、(2010/1/8)は最初のイテレーション・フライデーになります。しかし、これまでやってこなかったということではなく、初めてこの名前で呼ばれる明日という事です。ジーンズを履きハワイアンシャツやファンキーな帽子でも身に着けて、このイテレーションでマージし、利用可能になった変更をアナウンスしてください。

イテレーション・フライデーの目的継続的なリリースの為の自然なスケジュールを推進です。我々は短いイテレーションこそがコードの品質と開発速度を押し上げると信じています。イテレーションの内容は重要ではありません。たった１つの機能であれ、1000の機能であろうがそれは重要ではありません。規則的なスケジュールで変更がマージされる事がチームとコミュニティの為になり、またRapid Developmentの成功の鍵なのです。

我々はイテレーション・フライデーへの皆さんの参加を待っています。あなたのプロジェクトを同じスケジュールで進め、一緒に楽しんでしまいましょう！ iteration-friday.net のウェブサイトを見て、あなたのプロジェクトのイテレーションの準備が出来たらツイートしてください。

~ gwoo ~

–訳ここまで

オープンソースのソフトウェアを開発する際に開発の速度が安定しないというのは誰もが悩んだ事のある問題でしょう。それを解決する一つの実践がこのイテレーション・フライデーです。この記事ではよく知られているアジャイルやスクラムといったものを包括する概念としてRAD開発に言及しています。アジャイルの定義とはイテレーションであると最近、僕は考えています。頻繁なリリースを実行し、イテレーションを自然に実践する事が出来るイテレーション・フライデーに参加してみませんか？
どんな開発速度であってもかまいません、毎週金曜日に変更をマージし、リリースし #iFrydayのハッシュタグをつけてアナウンスをすればOKです！
大事なのは頻繁に規則的にサイクルが回る事です。

あけましておめでとうございます。
まだ正月ボケが冷めやらずといった時期ですが、Lithium0.4のリリースの知らせがnateから飛び込んできました。前回のリリースが12/9なので1か月たたずのリリースということで開発の活発さが伝わってきます。Lithiumの特徴である究極の拡張性を推し進める為の変更が行われているようです。という事で内容の方を見てみましょう。

原文

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

Happy New Release (of Lithium 0.4):

ホリデーシーズン中は少し静かでしたが、Lithium0.4が利用可能になった事をご案内します。前回のリリースから100以上の変更が行われ、バージョン1.0に向けた執拗な前進は全速力で続いています。リリースのハイライトは以下の通りです。

• キャッシュレイヤーの著しい改善:
  さらにXCacheとRadis用の新しいアダプタの追加。アトミックなインクリメントとデクリメントのサポートと複数キーの読み書きの基礎の追加。
• アダプタ設定を扱うベースクラスのリファクタリング:
  合理的で一貫性のあるAPIを提供する為の努力によりいくつかのフレームワークの設定を扱う core/Adaptable クラスがリファクタリングされました。また data/Connections がこれを継承して書き直され、LithiumのコアAPIがより統一されています。
• コンソールコマンド:
  li3 build コンソールでアプリケーションとライブラリの配布に便利な .phar アーカイブのビルドと展開ができるように。また li3 build test を起動することでモックを生成できます。有効なオプションについてはAPIドキュメントをご覧ください。
• さらなる拡張性の為のリファクタリング:
  僕らは開発者がカスタムクラスで殆どの依存要素を置き換えられる極めて拡張性の高い柔軟なコアを自負してきました。先週、このコアがどれだけ拡張性に富んでいるかをテストする事を決めました。そのためにフレームワーク内の静的結合を計測する為の小さなツールを書きました。このツールにより僕らはより動的にする事が可能な静的な結合を認識できるようになりました。
  
  
  この変更の後の分析結果はcoreとutilの二つのパッケージ(フレームワークの基礎を構成するパッケージ)を除いてとても満足いくものでした。たった２つのパッケージだけが内部のパッケージに静的に依存しているのです。これが意味するのはフレームワークのほぼすべてのパッケージを展開し、自分自身のクラスを使う事が出来ると言う事です。それだけではなく、coreとutilのパッケージ小さなアプリケーションやミニフレームワークの基礎やユーティリティとして利用できるフレームワークのマイクロカーネルとして振舞う事に気が付きました。

別のニュースとして、Joëlがli3_queueプラグインの作業を開始しBeanstalkをサポートしようとしています。またMariano IglesiasがDoctrineORマッパをLithiumと共に使うチュートリアルを執筆しました。
という事で、リリースが冷めないうちに試してみる事をお忘れなく。0.5でもこれ以上の変更を予定していますので。

最後にLithiumプロジェクトに集まってくれたり、コードや助言、激励などを頂いた皆さんに感謝を述べたいと思います。これがLithiumコミュニティの始まりならば、僕はとてもとても大きな希望をこのプロジェクトに抱いています。

2010年を大きな年に
~ Nate ~

–翻訳ここまで

Nate達、開発チームが究極の拡張性を追求しているライブ感が伝わってきますね。またその拡張性の高さ故に一部分を他のプロダクトで差し替えたり、また逆にLithiumの一部分だけを再利用する事も容易になっています。そろそろフィルター機能などを実例を交えて説明できればと思っています。また日本でもおなじみのJoelが作業をしているBeanstalkも興味深いですね。（初めて聞く名前でした）
とはいえ、まずはフレームワークが発展していくこのライブ感を楽しみたいところですね。