CakePHPの開発者の一人であるGraham Weldonさんが公開したPHP5.4についてのスライドがまとまっていてとてもわかりやすいです。”begin your love affair with traits”(traitsと恋に落ちよう！)と題されているとおりPHP5.4といえばtraitsなわけですが簡潔なサンプルが付いているのでまだtraitsわからないよという人は必ず目を通しておきましょう。

まだまだPHPの中心は5.2といったところのようです。（CakePHP2はボリュームゾーンである5.2を対象にしているわけですね)

これがtraitsを用いたログ処理の実装の例ですね。
スライドには他にも様々な新機能についての紹介が載っています。PHPを書く機会のある方は目を通しておいて損はないと思います。

告知：大阪と福岡でCakePHP2のワークショップを開催します！

8時間耐久CakePHP2勉強会@大阪 (2/5)
http://atnd.org/events/24800

8時間耐久CakePHP2勉強会＠福岡 (2/12)
http://atnd.org/events/24868

このエントリーはSymfonyアドベントカレンダー2011に参加しています。CakePHPの人として知られている私ですがSymfonyも業務では4年以上利用し続けております。今回は22日目担当とWindows Azure + PHPの環境でSymfonyを動かしてみました。いろいろと面倒なところがありそうな予感もしますが、これまでの知識を元に公式のチュートリアルを動かす事を目標にやってみます。

SQLite拡張の有効化

ではWindws Azure PHPプロジェクトを新規に作成し、Symfony2.0.7をダウンロードしたものをソースに取込んで動かしてみます。画面のようにSQLiteの拡張が見つからないというメッセージが表示されます。Azure SDKに同梱されたPHPではSQLiteが有効になっていなかったので、php/php.ini 内のコメントを外し、SQLiteを有効にします。

これでフレームワーク部分は動作していますので、デモ用のバンドルに含まれている画面などは上記のように動作しています。

データベースの接続設定

SQLiteを有効にした事で開発用のブートストラップからダッシュボードにアクセスできます。ここからデータベースの接続設定をしていきますが、残念ながらここにはMySQLやPDO_MSSqlといった選択肢しかありません。もちろんMySQLなどをAzureで動作させればここから設定をすれば問題はありません。とはいえせっかくAzureですからAzureSQLに接続して動かしたいですよね。
AzureSQLに接続するにはmicrosoftから配布されているsqlsrv拡張を導入する必要があります。Azureプロジェクトに同梱されているバージョンに併せた拡張をプロジェクト内にコピーして、これもphp.iniから正しく読み込まれるように設定します。

extension="php_azure.dll"
extension="php_mysql.dll"
extension="php_sqlsrv_53_nts_vc9.dll"
extension="php_pdo_sqlsrv_53_nts_vc9.dll"

またデータベースへの接続設定はダッシュボードからではなく直接設定ファイルを編集して設定します。

[parameters]
    database_driver   = pdo_sqlsrv
    database_host     = YOUR-PC\SQLEXPRESS
    database_port     =
    database_name     = symfony
    database_user     = sa
    database_password = yourpassword

Doctrineの操作

ここまでの設定を行った事でDoctrine経由でのスキーマ操作等が行えます。シェルを実行した際には少しエラーが出てしまいますが、タスクの実行自体に問題はありません。ソースコードの変更を伴うようなタスクを実行した後はプロジェクトを開発ファブリックに再度反映する必要がある点には注意してください。

ここまでの動作確認は開発ファブリック上で行っています。このプロジェクトを本当にデプロイできるかどうかを試してみたいのは山々なのですが、残念ながらAzureのアカウントを持っていません。とはいえsqlsrv拡張を通じてAzure SQLにアクセスできる事は周知されているので問題ないと言って差し支えないでしょう。

PHPの動作を高速化させる技術としてはAPCが知られています。スクリプトのコンパイル結果をキャッシュする事で構文解析をスキップすることができ、また任意のデータをキャッシュする事も出来る拡張モジュールです。今回はこのAPCをWindows Azure環境で導入を試みました。

拡張モジュールの入手

理由は不明ですが、APCの拡張モジュールはWindows版PHPにバンドルされていません。AzureのPHPはWindows版のPHPですから、やはり標準では含まれていません。とはいえWindows上でPHPの拡張をビルドするというのはなかなかチャレンジングです。いろいろと調べてみたところ下記のページでWindows用のAPCのバイナリが配布されていました。

http://downloads.php.net/pierre/

Azureに添付されているPHPに適合するのはVC9でビルドされたNon Thread Safeなバイナリですので該当するものをダウンロードして php/ext 以下にコピーし、php.iniからモジュールを読み込みます。

動作確認

さてphp.iniに設定を書きこんだのでphpinfo()にて読み込まれていることを確認してみます。

動作しているようです。がしかし、何度かリロードを繰り返すと、、、

クラッシュしてしまいました。このレベルでクラッシュしてしまうと前述した方法ではログが取れません。気になるのがAzureのローカルファイルに書き込めないという制限に対してAPCのWindows版についている注釈。

注意: Windows 版の APC では、temp パスが存在し、 Web サーバから書き込み可能になっていることが必要です。 APC は環境変数 TMP、TEMP、USERPROFILE の内容をこの順に調べ、 どれも設定されていない場合は WINDOWS ディレクトリを使用します。

該当の環境変数が指しているディレクトリを見てみると下記のような状態。

いくつかファイルは出来ていますがサイズが0です。どうにかしてこの状況を打開したい所ですがログが見れないという問題がある為、そこから考え直す必要がありそうです。現在の予想としてはファイルシステムがらみ（ロックとか）の問題が起きているかAPCとPHPの相性、スレッドセーフなどを疑っていますが果たして。。

前回はとりあえずエラーの情報を画面に表示する設定をしてみましたが、今回はエラーの情報を記録できるように設定してみます。インスタンスの再起動の際にディスクの内容が初期化されるAzureではログの情報はAzure Storageに記録する事になります。

Azure 運用時の考慮点 | Tech Fielders コラム

Windows Azure のインスタンスにはローカルディスクが用意されていますが、ここに保存されたデータは再起動時にクリアされてしまいます。つまり、永続的なデータについては Azure ストレージの使用を検討し、コンピューティングに関してはあくまで計算やサービスの提供窓口としての機能しか持たせないようにすることをお勧めします。

Azure StorageにアクセスするAPIを使ってログを書く事もできますが、Azure StorageはRESTでアクセスするサービスになっているのでログを一行出力する度にAPIをコールするというような使い方は現実的ではありません。そこでAzureではログなどの情報をトラッキングする為のDiagnostics(診断)という機能を持っています。この機能を有効にする事で任意のログをローカル側で貯めながら随時同期するという仕組みを実現できます。このログの仕組みそのものについてはwaritohutsuさんのブログの記事が詳しいです。

Windows Azure ログ講座第一弾 ～Windows Azure logs～

上記の記事はC#での実装方法になっていますが、同様の挙動をPHPで試してみます。

Diagnosticsの設定と動作確認

Diagnosticsの設定を行うには新規にプロジェクトを作る際のウィザードの中で設定をするのが最も手軽です。ウィザードで設定した内容を元に各種設定が記述されています。既存のプロジェクトに設定を行う場合は、設定ファイルに該当の記述を追加する事でDiagnosticsを有効にすることができます。

まずはServiceDefinition.csdefのImport設定からDiagnosticsを読み込みます。何もImportしていない場合は開始タグと終了タグが存在していないので該当部分を置き換えてください。

    <Imports>
      <Import moduleName="Diagnostics"/>
    </Imports>

次にServiceConfiguration.cscfg(関係する部分だけ抜粋しています)にログの転送設定などを記述します。今回は開発用ストレージを対象にした設定を記述していますが、クラウド環境のストレージを利用する場合は適切なアカウント情報などに置き換えてください。ログの転送頻度を表すScheduledTransferPeriodInSecondsに有効な値が設定されていないと記録されたログがストレージに転送されなくなるので特に注意が必要です。

    <ConfigurationSettings>
      <Setting name="StorageAccountName" value="devstoreaccount1"/>
      <Setting name="StorageAccountKey" value="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="/>
      <Setting name="UseDevelopmentStorage" value="true"/>
      <Setting name="LogLevel" value="Error"/>
      <Setting name="ScheduledTransferPeriodInSeconds" value="10"/>
      <Setting name="WindowsAzureStorageConnectionString" value="UseDevelopmentStorage=true"/>
      <Setting
        name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true"/>
    </ConfigurationSettings>

設定に文法エラーが無ければプロジェクトをパッケージして開発ファブリックにデプロイできるはずです。

PHPのエラーをDiagnosticsへ流し込む

では次にPHPからDiagnosticsに対してログ情報を送ってみます。PHPからAzure Logを記録するにはphp_azure.dllが提供するazure_log関数を使います。

azure_log(AZURE_LOG_CRITICAL,"This is error log.");

実行後にしばらく待つとログがWADLogsTableに記録されます。ログの情報の確認はAzure Storage Explorerが便利です。

次にこの関数を使ってPHPのエラーログをAzure Logに記録してみたいと思います。この為にはPHPのエラーハンドリング機構を使って自作したエラーハンドラーからazure_log関数を呼び出す形になります。これによりPHPから発せられた警告や任意にトリガーしたエラーを記録できるようになります。

function azure_log_handler($errno, $errstr, $errfile, $errline){
	$string = sprintf("%s %s %s %s", $errno, $errstr, $errfile, $errline);
	azure_log(AZURE_LOG_CRITICAL, $string);
	return false;
}
set_error_handler("azure_log_handler",E_ALL);
trigger_error("PHP ERROR");

ログのフォーマットはのちに検索する事なども考慮して使いやすそうなフォーマットにするとよいでしょう。

現存するライブラリについて

上記の方法では自前の実装でDiagnosticsを使っていますが、Azure向けの関数を活用するライブラリとしてWindows Azure SDK for PHPがあり、このライブラリにもDiagnosticsのクライアントが含まれています。このクライアントを使う事でパフォーマンスログなどをBlobオブジェクトで記録できます。このライブラリの活用方法については別の機会に紹介しようと思います。

Diagnosticsは設定を行ってもそれだけでは何も記録しません。ウィザードからとりあえず設定をしてみても何も起きていないので機能の存在に気がついていないケースもあるような気がします。なんらかの形でログを記録する処理を実装する必要があるとう点を留意する必要があります。

異色のマーケティングで注目を集めているWindows AzureですがPHPの動作環境として真面目に取り組んでみています。今回は開発時に必ず必要になるログの確認方法を見てみようと思います。

Azure上のPHPの正体はFastCGIで動作するWindows上のPHPですが、FATALエラーなどが発生した場合は下記のようなエラー画面が表示されます。

詳細なエラー情報が無い為、エラーへの対処が難しいです。この場合、通常の環境であればログファイルを確認する事になります。ですがAzureの場合は永続化されるファイルストレージは通常では存在しないのでエラーログを出力しないように設定されています。この問題への根本的な対処は別にするとして、ひとまず画面へのエラー表示を行うように設定を変えます。

エラーを詳細に表示するにはWEBロールのプロジェクト内にあるWeb.configの<system.webServer>の中に下記のノードを追加します。(ペースト時にダブルクオートが全角に化けないように注意してください)

<httpErrors errorMode="Detailed"/>

この設定を行えば下記のようにFATALエラーの内容が画面に表示されます。

開発時はこの状態でよいですが、本番環境にこの設定をデプロイしないように注意してください。ログを記録する方法については別途記事にします。

元ネタは英語の記事から引用しました。
Launching My PHP Application On Azure: Take One

Windows Azure上でPHPを動かしてみています。SDKからそのまま作ったプロジェクトの場合、PHPのバージョンは5.3.4になっており、これをアップデートする方法を調べたのでメモ。

Windows Azure PHPの正体

Windows Azure PHPプロジェクトとしてプロジェクトを作った場合、プロジェクト内のphpというディレクトリの配下にWindows版のPHPのバイナリとおぼしきファイル群が自動的にコピーされる。このPHPはAzure SDKに同梱されていると思われるPHPかシステムにインストール済みのPHPのいずれかから選択してコピーする。またビルド日時から見て、通常配布されているWindows版PHPと同一とみなしてよさそうだ。
プロジェクトに同梱されたPHPはそのままデプロイ用のcspkg形式のパッケージに同梱されてAzure環境上にデプロイされる。

このPHPの導入は単純なコピーだけではなく、Azure Storageなどへのアクセスを実現するためのphp_azure.dll の導入も合わせて行っている。これに伴って php/php.ini には下記の記述が挿入されている。

extension="php_azure.dll"

phpinfo()の出力内容をみるとこのPHPはWindows版の非スレッドセーフ版PHPをVC9でビルドしたものであることが分かる。xDebugのようなExtensionなどを導入する際にはこれを前提として取り扱えばよさそうだ。

PHP Version 5.3.4
Build Date  Dec 9 2010 22:17:30
Compiler  MSVC9 (Visual C++ 2008)
Architecture  x86
Configure Command  cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--disable-isapi" "--disable-nsapi" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8-11g=D:\php-sdk\oracle\instantclient11\sdk,shared" "--with-enchant=shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet" "--with-mcrypt=static"
Server API  CGI/FastCGI
Virtual Directory Support  disabled
Configuration File (php.ini) Path  C:\Windows
Scan this dir for additional .ini files  (none)
Additional .ini files parsed  (none)
PHP API  20090626
PHP Extension  20090626
Zend Extension  220090626
Zend Extension Build  API220090626,NTS,VC9
PHP Extension Build  API20090626,NTS,VC9
Debug Build  no
Thread Safety  disabled
Zend Memory Manager  enabled
Zend Multibyte Support  disabled
IPv6 Support  enabled
Registered PHP Streams  php, file, glob, data, http, ftp, zip, compress.zlib, phar
Registered Stream Socket Transports  tcp, udp
Registered Stream Filters  convert.iconv.*, mcrypt.*, mdecrypt.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*

プロジェクトに同梱されたPHPのアップデート

PHPのバージョンを上げる場合、該当のバイナリファイルを上書きする事でアップデートを行える。まずは利用したいバージョンの非スレッドセーフ版Windows版PHPをダウンロードしてくる。ダウンロードする際はインストーラー版ではなくZIPアーカイブをダウンロードしてファイルを展開する。次に展開したファイルをプロジェクト内のphpディレクトリに上書きしていく。この際にphpディレクトリごと上書きしてしまうとphp.iniが書き変わってしまう為、下記のファイルを個別に差し替える。

php/php-cgi.exe
php/php5.dll
php/php.exe (ユニットテストなどで使っているなら)
ext/ (APIの互換が保たれているバージョンであれば更新しなくても大丈夫)

開発ファブリックで動作確認してみたところ、最新のPHPが動作している事が確認できた。同様の手順でパッチを当ててビルドしたPHPのバイナリを動作させることもできるかもしれない。

※Windows版PHPにあまり詳しくないので正しい知識をお持ちの方がいればお知らせください。

前々回のエントリはお陰様でホットエントリに入る事ができました。PHPをdisるともれなくアクセスが伸びるという現象が過去にもさまざまなブログで観測されていますが、その現象を再確認する事が出来ました。なお上記の画像を見ると分かりますがこのアクセス数増加の効果は３日で無くなりました。アクセス数を伸ばしたいブロガーの方は3日おきにPHPをdisってみるといいのかもしれません。
そんなネタエントリの何倍も頑張っているcandycaneのエントリは全くアクセスが伸びていないのが残念です。

それはさておき今回はWordPress用のJetpackプラグインが提供するアクセス解析の機能がとても便利に感じました。スクリーンショットにもあるようなわかりやすいアクセス解析グラフがほぼリアルタイムでダッシュボードに表示されます。似たようなアクセス解析ではGoogleAnalyticsがありますが、結果の反映が素早かったのでもうこれからはGoogle Analyticsを見る頻度が少なくなっていきそうです。

最近のアップデートで自分のブログにログインする表示されるツールバーの中にもアクセス数のグラフが分かりやすく表示されます。（これで何事かが起きているのに気づいたらダッシュボードで詳細が見れるという事ですね）

ダッシュボード内ではリファラ解析や、エントリ中のリンクの何処がクリックされたのかというった情報がこれもほぼリアルタイムで閲覧できます。

Jetpackには他にもURLをツイッターやFacebookで共有するボタンを表示する機能とか色々な機能が入っていますが、WordPressを使っている方はインストールしてみて損は無いプラグインではないかと。っていうかアクセス数がリアルタイムで見れるのは気持ちが盛り上がるので楽しかったです。ありがとうJetpack。

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

原文 Why PHP Was a Ghetto

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

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

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

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

1. 醜い構文
2. 他の言語が備えているいくつかの必要な機能の欠如は（5.3以前における名​​前空間、クロージャ）
3. 一貫性のない関数の名前、使用法、およびその他の奇行
4. 手続き型とオブジェクト指向欠如のミックス
5. 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が現在、備えているものはなんだろう？

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

さらにインターネットで最も影響力のある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 webReplyRetweetFavorite

@rasmus

Rasmus Lerdorf

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


–訳ここまで