candycane development blog » 和訳

PHPプロジェクトの80-90％は巨大なクソの山であるという事実

yandod — Wed, 20 Apr 2011 03:14:09 +0000

面白いエントリを見つけたので和訳しました。PHPが使われていた歴史が古い事や開発者のコミュニティの観点から見たPHP論。読みやすいので早速どうぞ。
なお画像は「各プログラム言語からは各言語オタクがどう見えるか？」です。

原文 Why PHP Was a Ghetto

http://codefury.net/2011/04/why-php-was-a-ghetto/

なぜPHPはゲットーだったのか

ダンボ地区のかなりクールなスタートアップの創始者と私は世の中の多くのPHPの開発者でない人たちがPHPとその周囲のコミュニティを軽蔑するのかについて話す機会があった。彼はとても興味深い点に言及した事が私の印象に残った。なぜなら私はこれまで聞いた事がない指摘だったからだ。

お気づきかもしれないが、開発者がPHPに対して通常抱く不満は、だいたい以下の通りである：

醜い構文
他の言語が備えているいくつかの必要な機能の欠如は（5.3以前における名前空間、クロージャ）
一貫性のない関数の名前、使用法、およびその他の奇行
手続き型とオブジェクト指向欠如のミックス
PHPプロジェクトの80-90％は、おそらく巨大なクソの山であるという事実

しかし、彼にとってのPHPの問題は少し違っていたようだ。彼は、言語自体が悪いのではなく- 象徴となっている言語の創始者によって悪いプラクティスが推奨されているように見える言語を取り巻く文化が問題だと指摘した。PHPのコードベースには、魔術的でメンテナンス性が低くなりがちである。

言語やフレームワークを取り巻くコンセプトは作者の哲学が真実であるという事を具現化する。彼はRubyとMatzを例に挙げた。Matzは読みやすくおよび書きやすい言語、および強化されたプログラマの生産性を望んでいた。Rubyの開発者は迅速なアプリケーション開発とその言語の優雅さに共鳴しているように見えないだろうか？

その後、 DHHとRailsが登場し、 GuidoとPythonが続いた。私は考えた：ではRasmusはどうだろう？

Rasmus Lerdorfは興味深い人物だ。彼はPHPのオリジナルのバージョンを作り、貢献をし続けた事でコミュニティでは神とされPHPに関するほぼ全ての権威と見られている。彼はカンファレンスの聴講者の別の講演者から奪取し、巨大なインターネットサイトに雇用された。ほとんどの非PHP開発者がPHPを嫌悪しているという事実にも関わらず彼は敬意を集めた。

Rasmusはフレームワークを使うのでなく、テンプレート言語としてPHPを使う事を推奨しているようだ。彼にとっては、これは生のPHPの速度とスケーラビリティという事だが、他の全ての人々には、手続き型スパゲッティコードの山、メンテナンス困難なプロジェクトを作る事であるという風に理解される事になる。1995年にPHPの誕生から約10年の間、PHPのプロジェクトはこのように書かれて来た。

また別の問題にも言及した：ピザ顔の思春期の頃（5.0以前）、PHPは初心者の間で強く支持されていく。文法は素晴らしく敷居が低く誰でも*ampかwindows用のバイナリをダウンロードすれば2分で使い始める事ができる。と。またMVCパラダイムは、この時点ではWeb開発にはまだ多く見られなかった。初心者とベストプラクティスの欠如が合わさるとどうなるか？維持不可能なゴミ。そして、それが増殖する。

誤解しないで頂きたい。いくつかの素晴らしいPHP開発者は存在していた。しかし周囲は濾過されていない初心者のソースだらけだった。カウボーイPHP開発者達が何の規約も無しにプロジェクトを行えば、それはphpBBや、PHPNuke、またはPHP3のファイルの節くれだったマッシュアップのようになった。しかし、あなたはPHP開発者だけを非難することができるだろうか？いいえ! 他のWeb言語の巨人達、ASPやPerlも地獄のようなスパゲッティコードの促進に加わっていた。

なぜPHPは、いわれのない非難を受けるのだろう？それは過去の遺産によるものだ。最古のPHP開発者達はPython、Rubyに逃亡した。そしてJavaはMVCの導入以前のWEB開発で何が起きていたかを知らない。超辛口の批評家でRuby野郎のZed Shawは”PHP脳(PHP Infected Brain)の開発者”の恐怖を訴えRubyInsideでこのようなもの(訳注:上部の画像と同じもの)を発表した。

PHPはゲットーだった。

しかし、ZendとCodeIgniterのようなフレームワークの開発は大幅に正しい方向に言語発達を後押ししている。だがそれはRasmusは望んでいるのとは逆方向に向かっているである。ZendかCodeIgniterのフレームワークをチェックアウトし、ドキュメントが無く、よく書かれていないコードが一部でもあれば教えて欲しい。

ほとんどの開発者がRubyを知ったとき、彼らは同時にRailsとMVCを学んでいた。PHPは、その以前の10年間の間使われてきた。つまり(Rubyには)初心者によって凶悪なRubyが書かれていた期間は存在していない。Railsのために設立された規約があり、経験の少ない開発者を締め出すのに充分に敷居が高かった。

事実として、PHPアプリケーションは他の言語のように奇麗に記述する事が可能で、なおかつ速度の面でアドバンテージをおそらく持っている。PHPの世界でのMVCスタイルの開発の普及は、比較的最近の現象であり、それはおそらくRailsのおかげだ。

PHPが現在、備えているものはなんだろう？

規約（一般的なほとんどのプロジェクトのためのMVCテイストと少し手続き的ながらくた）
非常に低い参入障壁
速度とスケーラビリティ（おそらく最高のスクリプトベースの言語の中で）
偉大な単体テストフレームワーク
任意の言語のためのおそらく最良のドキュメント

さらにインターネットで最も影響力のあるWebサイトやツールでPHPは採用されている、FacebookやDigg、ウィキペディア、WordPress、Drupalなど、彼らは間違いなく他の多くの人々よりも確かな見識を持っている。

あなたは上記に同意しない場合は、この記事のコメント欄か、私にメールで – あなたはそうは思わない理由を聞きたいと思います。

私はPHPのおたくではない – 実際、私は非常に言語に対して懐疑論だ。私はPHPをよく書く。お分かりだろうが、それで金銭を得ている。だから、すべて、このようになる：

あなたは賢明なソフトウェア設計の決定を行う場合、PHPはWebアプリケーションを構築するために優れた選択肢です。

ちなみに、私はちょうどHPの次のWebアプリケーションを構築する為にCodeIgniterをチェックアウトしたところだ。PHPのための魔法のようで、超高速フレームワーク。CodeIgniterのことになると、私はミーハーです。

— 翻訳ここまで

確かにラスマスは各カンファレンスでフレームワークの有効性や速度に対して懐疑的な姿勢を示しています。それにしても”PHP infected brain”なんてPHP脳の恐怖といって良い言葉が英語でもあったとはねぇ。。。「ゲットー」という言葉が日本語としては象徴的な意味が薄いのでタイトルは箇条書きから抜粋しました。
ちょうどこんなつぶやきでラスマスさんも反論。アンチフレームワークというわけではなく、適切に使えという主義のようです。

Just for the record, I am not anti-frameworks just anti the indiscriminate use of frameworks and the inefficiencies that often brings. #php

2011年4月20日 12:44 PM via webReply RetweetFavorite

@rasmus

Rasmus Lerdorf

[和訳]Lithium0.9.9リリースノート

yandod — Mon, 08 Nov 2010 05:25:38 +0000

PHP Matsuri以降、実は一度ブログの更新がありましたが、自分の事が書いてあったので照れくさくて翻訳していません。そして立て続けにLithiumの新しいリリースの知らせがありましたので和訳を作成しました。文中に出てくるスタートアップにはセキュリティの権威、Chris ShiflettさんやPHPのUnicode実装に奮戦していたAndrei Zmievskiさんが在籍し、さらにはSean Coatesさんが。またTostyのCTOのMitch Pirtleさんは有名CMS Joomlaの作者です。PHP界のビッグネームがこぞってLithiumを実際に使い始めているというエキサイティングな様子が見て取れます。ではどうぞ。

原文

http://dev.lithify.me/lithium/wiki/blog/Lithium-0-9-9-99-Problems-But-a-Framework-Aint-One

Lithium 0.9.9: 99 Problems But a Framework Ain’t One

ワオ、しばらくこのブログを不在にしてました。僕の時間は何処に行ったんだろう？夏の間はしようとしていた事が全て減速していました。僕自身や他のチームメンバーは新しい仕事やスタートアップの立ち上げで多忙でした。我らがプロジェクトマネージャー、GarretはSourceForge内でプロダクトリーダーにポジションに就きました。我々もこれをとても嬉しく思います。これについては近いうちにもう少しわかると思います。

また前回触れたようにいくつかのイベントを開催したり、参加してきたのでここ数ヶ月は忙しかったです。なんにせよはっきり言うと長いリリースをしないで時間が過ぎてしまいました。こういった事はもう起こしたくないとはっきり思っています。ええ、本当に済みませんでした。
それはさておき、今日は思いがけないリリース日です。ちょうど二日前にプロジェクト公開の記念日を迎えました。（以前からアナウンスはしていましたがコードとサイトが公開されたのは11月３日でした）また今日はRemember Rememberの日です。（訳注映画Vフォーバンデッタの台詞 “Remember Remeber The 5th of November” ）
また色々な事がありましたが特に前回のリリース以降、将来的には高品質なアプリケーションの為のデファクトフレームワークになる為にがんばってきました。こんな事や、こんな事やヤクの毛狩りが無いように。

立ち上げ

この８月にMongoDBを利用したトラフィックの多いプライベートセールEコマースサイト、Tosty.comが開始しました。そしてこのサイトはLithiumで構築されています。Tosty.comのCTOによるこのケーススタディの発表のビデオを見る事もできます。
また個人的に喜ばしい事として今から2週間にBrooklyn Betaというカンファレンスに参加しました。多くの人がこれについて既に記事を書いています。ここでカンファレンスについてはまとめない事にします。このイベントはAnalogとFictive Kinのジョイントベンチャーで、彼ら一人一人を個人に敬意を持っています。なのでかれらが立ち上げたいくつかのベータ版のプロダクトMapalongとGimme Barにはわくわくしました。しかも彼らは両方ともLithiumを使っているんです！
彼らのフレームワーク上での実践と優れたアプリケーションを見るのはエキサイティングでした。そしてついに完成したわけです。これらのチームからのフィードバックは今のLithiumには不可欠でした。みなさんありがとうございました。

リリースハイライト

今回のリリースは予定したものではありませんでしたが、クオリティをさらに向上させています。約400のコミットが12人の有志によって行われました。これは過去２回のリリースの3倍以上です。また過去4回のリリースの合計に匹敵するくらいの大きさです。

全ての変更を説明しても実用的ではないでしょう。ここに変更のハイライトをリストします。特にコアアーキテクチャとのやり取りに注目してみます。

Filters::apply(): Filters クラスはLithiumでメソッドに対してレイジーにフィルタ処理を行う為の新しい機構です。この新しいメソッドはまだ読み込まれていないスタティックなクラスへフィルタを適用します。例としてPOSTモデルがあり、クエリのログを取る場合はこうなります。:

use app\models\Posts;
use lithium\analysis\Logger;
 
Posts::applyFilter("find", function($self, $params, $chain) {
Logger::info(json_encode(array("posts" => $params)));
return$chain->next($self, $params, $chain);
});

このフィルタはブートストラップ処理の中で適用されています。よってPOSTクラスはリクエスト中で使われているかどうかに関わらず常にロードされます。このフィルターをレイジーに適用すると以下のようになります。:

use lithium\analysis\Logger;
use lithium\util\collection\Filters;
 
Filters::apply('app\models\Posts', 'find', function($self, $params, $chain) {
Logger::info(json_encode(array("posts" => $params)));
return$chain->next($self, $params, $chain);
});
code>

このフィルタの効果は１つ上の例と同じです。ですが、Filtersクラスを通しているため、このフィルタはPostクラスが既に読み込まれていない場合はすぐには適用されません。この場合はPostsクラスのFindメソッドが呼びだされるまではフィルタは適用されません。

Object::_instance() と Libraries::instance(): Lithiumは当初からクラス間の依存を定義する際に$_classes属性を使う規約を持っています。これらの依存関係を個別にコンストラクタで上書きする事ができます。
しかしこのインスタンス化のプロセスは少々ぎこちないものでした。クラスの名前を$_classes配列から取得し、 new $class() としていました。現在はObjectとStaticObjectをワンライナーでそれぞれの依存のキーに設定できます。また好きなパラメータも下記のように指定できます。:

class Foo {
 
protected$_classes = array("renderer" => "app\extensions\template\Custom");
 
publicfunction render() {
$renderer = $this->_instance("renderer", array("path" => "views/"));
// ...
}
}

Libraries::instance() もよく似た動きをします。クラス型か Libraries::locate()のような名前を受け取り、見つかったクラスを指定されたパラメーターでインスタンス化します。

Request::accepts()によるコンテンツ認証 : Request オブジェクトはコンテンツ認証をサポートしました。認証にはHTTP Acceptedパラメーターを使います。アプリケーションの中で使われるコンテンツのタイプをMedia クラスで設定された設定をもとに返します。.
Model::update() と Model::remove(): Model クラスに２つのメソッドが追加されました。これは複数のドキュメントやレコードを一度に操作できます。
MongoDBスキーマサポート: このリリースではMongoDBのスキーマサポートが改良されました。Mongoオブジェクトを簡単に記録するだけではなく、 $_schema プロパティを使ってLithiumに期待するフィールドの情報を伝えることできます。MongoIDを文字列で渡す事で自動的にMongoIDオブジェクトを生成し問い合わせや更新に使います。
APIドキュメンテーション: その他の機能の為にこのリリースには多くのAPIドキュメントがf組まれます。これらは間もなく docs pageで公開されます。(訳注、反映済み)さらにドキュメントは新しいli3_docsで提供されます。
HTTPメタデータによるルーティング: これまではルーティングはURL内のパターンでのみマッチしていました。現在は全てのRequestオブジェクトのプロパティに拡大されました。これはおなじみのRouter APIで指定します:

// Only allow POST requests to FooController::create():
Router::connect("/create", array("Foo::create", "http:method" => "POST"));
 
// Allow POST or PUT::
Router::connect("/update", array("Foo::update", "http:method" => array("POST", "PUT")));
 
// Only match if on the dev server:
Router::connect("/secret", array("Secret::index", "http:host" => "dev.application.com"));
 
// Only match if request is over HTTPS:
Router::connect("/admin", array("Foo::index", "env:https" => true));

次のリリースのいくつかの変更もハイライトしようと思います。UUIDジェネレーターを再実装したDenis de Bernardy,に感謝します。これにより複雑なコードを明らかに減らす事ができました。これによりパスワードのセキュリティに使われるコアの暗号化を改良できます。また透過的なCSRF対策もフレームワーク上に間もなく実装されます。
さらに彼と何人かの才能ある日本の開発者がそれぞれPostgreSQLのサポートを実装しました。これも次回のリリースでデビューします。
最期に TextMate pluginに小さな改良がありました。アプリケーションで使いテストを実行した後、エラーが発生した場所にTextMate上でジャンプできます。Macユーザなら試してみてください。

API changes

大きなリリースなのでいくつかの後方互換性の無い変更があります。幸いにも小さな変更なので簡単に修正できます。

$this->render(‘foo’) の呼び出しはコントローラー内で動かなくなります。代わりにこの呼び出しは$this->render(array(‘template’ => ‘foo’))に変更してください。
Inflector::camelize() は “_” と “-” を置換します。 (以前は “_”　だけを置換していました).
データベース設定にカスタムポートを使う場合、 “port” キーはサポートしなくなります。その代わりに “host” キーのフォーマットを “host:port”としてください。
Model::_connection() をバックエンドを直接呼び出すのに使っている場合、このメソッドが廃止予定である事に注意してください。かわりに新しい実装である Model::connection()を利用できます。
LithiumのG11n機構を使っている場合、CatalogAPIの２つの変更に注意してください。: read() と write() メソッドの最初のパラメータは反映したい設定の名前です。 read() の場合、 true をいつでも指定できます。こうすれば以前の実装と同じです。

簡単に移行する場合は全ての read() の呼び出しをCatalog::read(…) から Catalog::read(true, …)としてください。
write() を置き換える場合は動揺ですがやや自動的ではありません。以前の呼び出しが: Catalog::write(‘message’, ‘en’, $data, array(‘name’ => ‘runtime’)), の場合、現在は:Catalog::write(‘runtime’, ‘message’, ‘en’, $data)となります。

What’s next?

このリリースが表に出ると、チームは次のリリースに向けて動く事に興奮しています。僕らはあと２つの大きな機能を安定版のリリース前に実装します。またいくつかの優れたプラグインがリリースの準備ができています。メーリングリストやフォーラムで沢山の質問を受けているのが、Lithiumの全てが集まっている所を探すことの難しさです。ブログやポッドキャスト、ビデオにプレゼンテーションです。僕らはちゃんと聞いています。来週のアナウンスを楽しみにしてください。
それじゃ、”remember, remember the 5th of November!” (訳注：台詞です。)
~ nate ~

リリースのダウンロード
 全ての変更履歴

-訳ここまで

久々のリリースという事で情報量が多く、３時間強も掛かってしまいました。十分に集中していたとは言えないのですが。個人的にはNateの持っている交友関係の広さや彼がPHPのコミュニティでアクティブな様子が伺えます。また彼のポストには洋楽や洋画の引用がよくありますので、理解を深めるにはこういったものも嗜むと良さそうですね。近日中の次のアナウンスを楽しみにしましょう。

Lithium0.9.5リリースノート(和訳)

yandod — Sun, 23 May 2010 01:17:23 +0000

順調に進化を続ける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`を継承したいくつかの基底クラスを継承できます。またクラスは任意のプロパティを継承します。

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

$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クラスを利用しています。私の現在の設定は次のようになります：

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を追加しました。これで設定を下記のようにシンプルに変更できます：

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にながすというアイデアも秀逸です！

Lithium0.9リリースノート（和訳）

yandod — Sat, 22 May 2010 20:24:11 +0000

ちょっと作業時間が取れなかったので大幅に遅れてしまいましたが、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してから以下を追加します：

/**
 * 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つのルートを考えてみましょう：

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

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

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`パラメータを追加することによって、我々は簡単に通常のテンプレート変数を無効にすることができます：

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

安定版まであと２つ Lithium0.8リリース(和訳)

yandod — Thu, 01 Apr 2010 06:08:55 +0000

安定版のリリースに向けて着実に歩を進めている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

–訳ここまで

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

Lithium0.7がリリースされました(和訳)

yandod — Wed, 10 Mar 2010 03:22:27 +0000

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

Li3 ocphp

View more presentations from G W.

原文

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などの近代的なフレームワークではプラグインなどを利用した拡張が提供されていますが、なかなか共通部分をプラグインに切り出せないという問題にはまりがちです。その点を考慮してか次世代のフレームワークでは実装そのものとプラグインの境界線が薄くなる方向へと進んでいます。アプリケーション自体をプラグインとして実装するとイメージすると近いかもしれません。

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

HipHopのビルドとインストール方法(和訳)

yandod — Sun, 21 Feb 2010 04:18:54 +0000

ソースコードがついに公開されたHipHop for PHPのビルドとインストール方法のドキュメントの和訳を作成しました。CentOSかFedoraの環境をお持ちの方は早速ビルドに挑戦してみてはいかがでしょうか。利用法のドキュメントの和訳は引き続きアップします。

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

–訳ここまで

Lithium0.6リリースノート和訳

yandod — Wed, 17 Feb 2010 05:23:55 +0000

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

[プロファイリング]（http://pastium.org/view/cc7b5d11ced0c4e2ad8cf25227b0bd96用） [xhprof]（http://pecl.php.net/package/xhprof）を使用する。

コンテンツの配信（http://pastium.org/view/e6d0c0cc88010822cb58a7fc4b7a6014）（画像、スタイルシートなど）のプラグインからなど。

上記のような基本的な変更がありましたが、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に関する過去の記事

PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開

yandod — Wed, 03 Feb 2010 03:19:26 +0000

アメリカ時間の昼ごろに僕のTwitter上が一つのニュースで埋め尽くされました。
PHPをC++に変換して高速化する技術をFacebookが公開したというものです。世界中のPHPハッカーが注目する興味深いリリースという事でちょっと長いですが、リリースノートの和訳を行いました。

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つの主な手順が含まれます：

収集した情報から何が宣言され、何に依存しているかの静的分析
C++の特定のタイプを、スカラー、文字列、配列、クラス、オブジェクト、およびバリアント型から選ぶ型推定
ほとんどの部分の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%のトラフィックで利用しているとの事ですからコードの書き方に気をつければ安定しているのでしょう。ということでみなさん、お試しあれ！

Lithium0.5がリリースされました！(和訳)

yandod — Mon, 01 Feb 2010 02:48:14 +0000

最も軽量で拡張性に優れたフレームワーク、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ということで、試すのであればお早目に！

candycane development blog » 和訳

PHPプロジェクトの80-90％は巨大なクソの山であるという事実

原文 Why PHP Was a Ghetto

なぜPHPはゲットーだったのか

PHPはゲットーだった。

[和訳]Lithium0.9.9リリースノート

原文

Lithium 0.9.9: 99 Problems But a Framework Ain’t One

立ち上げ

リリースハイライト

API changes

What’s next?

Lithium0.9.5リリースノート(和訳)

原文

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

Lithium0.9リリースノート（和訳）

原文

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

安定版まであと２つ Lithium0.8リリース(和訳)

原文

Lithium 0.8 – And then there were 2

Lithium0.7がリリースされました(和訳)

原文

Lithium0.7 Luck-of-the-irish

HipHopのビルドとインストール方法(和訳)

原文

ビルドとインストール

前提条件

必要なパッケージ

カスタムパッケージ

バンドルパッケージ

ビルド

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

ビルド

Lithium0.6リリースノート 和訳

原文

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

PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開

原文

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

HipHopの誕生

HipHopの動作

今夜のお楽しみ

Lithium0.5がリリースされました！(和訳)

原文

Lithium 0.5, half way there.

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

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

Lithium0.6リリースノート和訳