Windows Azure + PHPな環境で動いているバイナリは普通のと同じ
11月 16, 2011 by yandod · 2 Comments
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日間&WPのアクセス解析はJetpack
4月 25, 2011 by yandod · Leave a Comment
前々回のエントリはお陰様でホットエントリに入る事ができました。PHPをdisるともれなくアクセスが伸びるという現象が過去にもさまざまなブログで観測されていますが、その現象を再確認する事が出来ました。なお上記の画像を見ると分かりますがこのアクセス数増加の効果は３日で無くなりました。アクセス数を伸ばしたいブロガーの方は3日おきにPHPをdisってみるといいのかもしれません。
そんなネタエントリの何倍も頑張っているcandycaneのエントリは全くアクセスが伸びていないのが残念です。
それはさておき今回はWordPress用のJetpackプラグインが提供するアクセス解析の機能がとても便利に感じました。スクリーンショットにもあるようなわかりやすいアクセス解析グラフがほぼリアルタイムでダッシュボードに表示されます。似たようなアクセス解析ではGoogleAnalyticsがありますが、結果の反映が素早かったのでもうこれからはGoogle Analyticsを見る頻度が少なくなっていきそうです。
最近のアップデートで自分のブログにログインする表示されるツールバーの中にもアクセス数のグラフが分かりやすく表示されます。（これで何事かが起きているのに気づいたらダッシュボードで詳細が見れるという事ですね）
ダッシュボード内ではリファラ解析や、エントリ中のリンクの何処がクリックされたのかというった情報がこれもほぼリアルタイムで閲覧できます。
Jetpackには他にもURLをツイッターやFacebookで共有するボタンを表示する機能とか色々な機能が入っていますが、WordPressを使っている方はインストールしてみて損は無いプラグインではないかと。っていうかアクセス数がリアルタイムで見れるのは気持ちが盛り上がるので楽しかったです。ありがとうJetpack。
PHPプロジェクトの80-90％は巨大なクソの山であるという事実
4月 20, 2011 by yandod · Leave a Comment
面白いエントリを見つけたので和訳しました。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脳の恐怖といって良い言葉が英語でもあったとはねぇ。。。「ゲットー」という言葉が日本語としては象徴的な意味が薄いのでタイトルは箇条書きから抜粋しました。
ちょうどこんなつぶやきでラスマスさんも反論。アンチフレームワークというわけではなく、適切に使えという主義のようです。
Lithium0.9リリースノート（和訳）
5月 23, 2010 by yandod · Leave a Comment
ちょっと作業時間が取れなかったので大幅に遅れてしまいましたが、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はアスペクト指向を実装に取り入れている部分があり、従来のスタイルのフレームワークの知識を前提にして考えると分かりづらい所があります。これらの例は全体の継承関係や処理のフローを考慮することなく、断片的な修正をクロージャなどを使って実現できるという点がすごい所と言えるでしょう。
HipHopを実行するには(和訳)
こちらはHipHopの利用法のドキュメントの和訳です。
- 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が公開
2月 3, 2010 by yandod · 7 Comments
アメリカ時間の昼ごろに僕の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%のトラフィックで利用しているとの事ですからコードの書き方に気をつければ安定しているのでしょう。ということでみなさん、お試しあれ！
第49回PHP勉強会で「Lithiumラボ #1」を発表した
1月 31, 2010 by yandod · 2 Comments
第49回PHP勉強会にリモートから参加しました。
ニューヨークからは時差があるので金曜日の深夜１時頃からの発表になりました。
Skypeでの発表をケアしてくれたgusagiさん、cakephperさんのお陰でひとまず無事に終える事ができました。ありがとうございました。
発表の内容
このブログでもたびたび、紹介している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さん、発表者、参加者のみなさんおつかれさまでした！
今年もいい年になるといいですね。
第48回PHP勉強会でWordCampのレポートをした
12月 9, 2009 by yandod · Leave a Comment
今月のPHP勉強会にもリモートから発表をしました。
これで通算3回目ですが、まぁ慣れてきたような気がします。時差がある海外からでも発表できるくらいなので、東京以外からの発表とかもやればできそうですね。
今回は25分予定のところを40分も喋ってしまいました。動画とかをスキップすれば納まったかもという事でちょっと反省です。また日本時間夜の勉強会はこちらは朝になるのでテンション的にボソボソした感じになってしまったのがつらいところ。。。
発表資料もあげておきます。
slideshare
ustream
聞いてくださった皆さん、USTをして頂いたNEKOGETさん、Skypeを受けてくださったgusagiさん、ありがとうございました。
「モダンPHPプログラミング」の資料が大変素晴らしい件
12月 9, 2009 by yandod · Leave a Comment
プリンとOpenPearで有名と思われるsotarokさんが公開した「Modern PHP Programming」の資料がとても良いです。PHPは敷居が低い為、非常に多くのユーザーがいます。
しかしユーザーが多い一方でレベル差が大きくなっている面もあります。
たとえば・・・
「コピペで動かすのが精一杯」
「とりあえずすいすい書ける人」
「ライブラリとかを使える人」
「ライブラリを作れる人」
「PHP自体をいじれる人」
のような感じです。PHPユーザ会が運営しているPHP勉強会なども毎月開催されていますがこのステップをどうやって登るかというのは難しい問題です。その意味でこの資料はとても役立つ内容になっていると思います。「とりあえずPHPは書けるけど、今のトレンドに合っているかわからない」なんていう方は是非ともこちらの資料を見てみるといいでしょう。なお同様のコンセプトでモダンPHP勉強会が開催されるようです。
まだ勉強会開催を控えていますが、sotarokさんお疲れ様です。
第47回PHP勉強会にリモート参加した
11月 7, 2009 by yandod · Leave a Comment
ここにも書いたOpenHackDayの話を10分ほど。
発表を手伝ってくれたakiyanさんありがとう！
OpenHackの話が気になった人は過去のエントリもご覧ください。
OpenHackNYC レポートその１
OpenHackNYCのレポート その２
OpenHackNYCのレポート その３
OpenHackNYC Hack Demoレポート
映像で振り返るYahoo Open Hack
skypeの画面共有を使ってプレゼンをしていたのは初めてですが、おおむね問題なかったようです。
一部声が割れたというのはノートPC内蔵のマイクを使ったのが良くなかったですね。
次があればいいマイクかヘッドセットを使うようにします。
発表資料を一応あげておきます。
