2008-01-07 [長年日記]
_ XML_HTMLSax3 が stable になったと同時にメンテナ不在に
PEAR :: Package :: XML_HTMLSax3
タイトルですべて。
この package は well-formed な XML じゃなくても解釈できる、なかなかの優れもの。well-formed な XML, XHTML しか相手にしないなら SAX 関数とかでもいいんだけど、これがあれば結構 HTML 相手でも頑張って解釈してくれる。
RC1 をずっと使ってたんだけど、stable だよーやったよーと思っていたらこんなことに。うーむ。
まぁね。PHP 5 + well-formed X(HT)?ML しか相手にしないならこんなの要らないしね。
2008-01-08 [長年日記]
_ pear の channel server 周りで悩む
独自 PEAR channel server の立ち上げに利用するパッケージって、あちこち
で触れられている通り
これですよね。
$ pear search -c pear.chiaraquartet.net pear Retrieving data...0%...MATCHED PACKAGES, CHANNEL PEAR.CHIARAQUARTET.NET: ================================================= PACKAGE STABLE/(LATEST) LOCAL Chiara_PEAR_Server 0.18.7 (alpha) PEAR Channel Server
相変わらず alpha なんですけど、もしかして pear.php.net 自体もずっとこれで運用してるってことなのかな？ alpha なままってどうなんだろうというのと、マニュアルにも
堂々と
Incomplete documentation
って出たまんま。うーん。すげーな。これ早めに片付けた方が mirror の整備とか進むと思うんだけど。
あと Nabble - Php Japan - phpug-admin - 日本におけるPEAR Channelサーバの構築について なんてやり取りを見つけて、
にアクセスして見ると、機能してるんだかどうだかよく分からない状態。せっかくあるのに 日本 PHP ユーザ会 (Japan PHP Users Group) :: メイン を見ても使ってるんだか使ってないんだかよく分からない。
まぁ結局のところ PHP 版の CPAN はやっぱり存在しないっつーことで FA かな？
package の作成は以前試したように楽になってるんだけど、これだけだと出来上がったパッケージを pear upgrade で更新できない。channel server を立てれば解決するんだけどなーんか微妙に踏ん切りがつかない状態ですな、これ。
内輪向け的にはパッケージングしないで include_path 通して svn update の方が簡単なのかなぁ？ でもすべての環境で include_path をいじらなきゃいけなくなるし、svn バイナリも用意しなきゃいけない。
update がそんなに頻繁でなければ pear package の形になっている方が portable で嬉しいよね。*1それは間違いないと思う。うーぬぬぬ。
*1 しつこいようだけど「update を考えなければ」できあがった package を HTTP でアクセスできる場所に置くだけで簡単にインストールできるようになるし。
2008-01-16 [長年日記]
_ MacBook Air ほんとに出た
Twitter が死に死に*1なのでこっちへ。（それもどうだ。）
Macworld 2008 - Apple、重量1.36kgの「MacBook Air」発表 | パソコン | マイコミジャーナル
チラッと Twitter を見ていた限りでは、発表前買う気だった人たちも様子見モードに移行した感じ。まぁ日本の geek では順当な反応かと。Apple 製品が日本の geek にジャストフィットなんかしないっすよ。
個人的にも Air って名前があまりにまんまで拍子抜けしたのと、デザインがなんとなく Muramasa を想起させてなんだかなぁって感じ。あとやっぱり日本の製品なら同じ重さで同じ値段でフルスペックの2スピンドルを出せるよねって思っちゃう。それに Apple 製品らしく制限が多い。
同じ1スピンドルで似たような重さなら ThinkPad X60 シリーズでいんじゃね？という印象。Remote Disk とか Time Capsule とかも面白いんだけどやたら周辺機器を買わせよう感が強くてちょっとげんなり。
ただ、なんとなくそれなりに売れそうな気はする。金が余っててスタイリッシュに仕事した人向けというか(笑) あるいは初めてのパソコンで張り切っててかっこいいのが欲しい人とか(笑) それなりの軽さなのは当然として、トラックパッドの操作性は今までにないもの*2だし、素人向けにはインパクトは結構あるような気がする。というか普通のマスメディアですごく説明しやすい要素が揃ってると思うのね。だからこう、mono 方面とか iPod から、みたいな人たちには結構売れるんじゃないかなって思う。当然、数が少なくて要求がシビアな geek に受けるよりそっちの方が商売的にはずっと大事なわけだし、正しい判断だと思う。
まぁでもあんまりワクワクしない機械なのは間違いないかな。MacBook が出たときにも思ったことだけど。つか単純に開けにくそう。
2008-01-18 [長年日記]
_ URI ベース pear パッケージの操作
インストール
pear install URI
アップグレード
pear upgrade URI
ダウングレード
pear upgrade --force URI
アンインストール
pear uninstall __uri/PACKAGE
インストール状況の確認
pear list -a (全channel) pear list -c __uri (URIベースのパッケージのみ)
インストール済みファイル群の確認
pear list-files __uri/PACKAGE
cf.
2008-01-24 [長年日記]
_ PHP の設定って PHP で書いた方がよくない？
PHP の各種設定を行える場所
基本的に3つあると思う。
- php.ini
- .htaccess
- 設定用関数を利用
で、普通 PHP の入門記事とかで触れられるのは 1 か 2 のはず。でも、実はこれ間違ってたんじゃないかって思い始めた。
まぁ確かにすべての項目を 3 の方法で設定できるわけじゃないんだけど、ほとんど困らないような気がする。
今までの方法は全部ダメ
php.ini は忘れた方がいいというか単なるデフォルト
まず php.ini , これは virtual host で複数サイトを展開する際、すべて設定が同じになってしまう。今からまっさらの状態で新しく始めるならこの設定にしておくべきというのがまずだいだい決まっているので、それに従って設定してしまうというのは確かにアリ。
でもちょっとでも歴史があった場合これだけじゃ絶対うまくいかない。sjis のサイト、euc-jp のサイト、utf-8 のサイトが入り乱れていること請け合い。あるいはオープンソース開発者でいろんなコード触ってるとかいう場合なんかも一つの php.ini でまかなえるはずがない。
だからもうこの際「インストールして php.ini を編集する」っていう流れは忘れちゃっていいと思うんだ。
.htaccess はサイトごとの設定を保持できるけどそれだけじゃダメ
.htaccess じゃなくて apache の conf の方がいいとかそんなことを言うつもりなし。
問題は CLI でスクリプトを起こしたときに .htaccess は役に立たないってこと。だからいちばんいいのは、
.htaccess などに
php_value auto_prepend_file CONFIG_FILE
と書いておいて設定は PHP で書く方法なんじゃないか、というのがこの記事の趣旨。
だいたい、.htaccess で設定を書くと PHP 独自定義の bool値も定数も存在しないので読みにくくなってしまう。
php_value error_reporting 2047
とか書かれててもすぐに意味が分からないし、php_flag なのか php_value なのかも気にしなきゃいけない。面倒くさいし、この部分、マニュアルもそんなに丁寧に書かれていない。
やってみよう
php.ini だと
mbstring.language = Japanese mbstring.internal_encoding = utf-8 mbstring.http_input = pass mbstring.http_output = utf-8 mbstring.detect_order = auto
これを .htaccess で書くと
php_value mbstring.language Japanese php_value mbstring.internal_encoding utf-8 php_value mbstring.http_input pass php_value mbstring.http_output utf-8 php_value mbstring.detect_order auto
これを PHP で書くと
<?php // mb_http_input(); // 違う機能です mb_language( 'Japanese' ); // ※ mbstring.language と同じ意味ではありません！ mb_internal_encoding( 'utf-8' ); // 自動変換の機能に対しては有効ではありません mb_http_output( 'utf-8' ); mb_detect_order( 'auto' );
ただし上に書いたように注意事項もある。
- PHP の中ですべての設定を書けるわけではない
- PHP の中で行った設定が期待通りに働かない場合もある
特に 2 の方は一見うまく動いているように見えるので注意が必要。例えば
mbstring.internal_encoding()
を PHP の中で設定するときは
mbstring.encoding_translation off
とセットでないといけない。encoding_translation は PHP のコードを読み込む前に動く（でないと透過的な変換として機能しない）ので、php.ini あるいは .htaccess の段階で internal_encoding が決まっていないと正しく動作しない。逆に、この機能を使いたい場合は
mbstring.encoding_translation mbstring.internal_encoding
は PHP の外でセットしておかないとダメ。最近では UTF-8 をそのまま使うことが多くなっているはずで、その際は自動変換の機能はなくても問題ないけど、そうでない場合は注意が必要。
PHP で設定を書かなくてもいいのは実はメリットじゃなかったのかも
今回なんでこんなことを思ったかっていうと、さっきも書いたけど
CLI で起動したとき .htaccess は生きてこない
ということに今さら気づいたから。しかし上の auto_prepend_file なら CLI でも以下の方法で設定を読み込むことができる。
php -d auto_prepend_file=CONFIG_FILE
CLI を活かせると、例えば大量の PHP のファイルの動作チェックの自動化とかできちゃう。もっとも、イマドキのアプリなら普通はフレームワーク使ってるし、フレームワークのテストに従ってるかもしれないし、ユニットテストがバッチリ動いててチェックも楽ちんなので全然関係ないかもしれない。
でもそうじゃない環境もある。絶対にある。そのとき、せめてこの方法が使えれば人の目と手でチェックするだけよりも確実に効率は上がる。上がるんだよ。
上の方法で
error_reporting( E_ALL ); ini_set( 'log_errors', true ); ini_set( 'error_log', '/path/to/error.log' );
とかしておいて
for i in `find /path/to/app -name '*.php'`; do cd dirname $i; php -d auto_prepend_file=CONFIG_FILE $i; done
とか回すとドバーっとエラーがログに吐かれる。いちいちブラウザで開いて回らなくてもよい。
まぁ CLI の場合は当然 HTTP 周りのパラメータがセットされないわけだけど、それも CLI での検証時だけ適当に補完するように CONFIG_FILE を書いてやればとりあえず騙せるのではなかろうか。
PHP スクリプトで変更できない設定を CLI 環境下で反映する
PHP のマニュアルで変更の可否が PHP_INI_SYSTEM と PHP_INI_PERDIR になっているものは php のスクリプトからは変更できない。ini_set() とか使ってもダメ。.htaccess を使えない CLI の場合はこうなると php.ini をいじるしかないけど、システム全体に影響する php.ini をいじりたくない場合は
php -c PATH
でそのときだけの php.ini を指定することができる。
というわけで
また一つ PHP ならではの機能がメリットでなくなったことを感じたのでした。（代わりに auto_prepend_file という PHP ならではの機能を使ってるんだけど。）
というかやっぱさ。今さらだけど php.ini や .htaccess でしかいじれない設定があるのってすっげーおかしくね？ CLI だと
php -c PATH
で ini ファイルを都度指定できるけど、mod_php とかだと ini を切り替える方法ないよね？ なんでこんな変な方針なんだろう。譲って言語の外で設定できることはよしとしよう。それが便利な場合もあるさ、というか実際便利だと思っていたこともある。でも言語の中で変更できないっておかしいよなぁ。
2008-01-31 [長年日記]
_ まずダメなところを認めることから始まる
あんまり真面目に追っかけてなかったけど、Matz はその後さらに燃料を投下してたのか。なんてサービス精神旺盛なんだ。
Attacking PHP - Matzにっき(2008-01-26)
もうね。本人すら最初に何を話題にしたのか忘れてるんだけど、本当の問題は引用した部分、リンク先の部分だけなんだよね。ここまでにしておきなさい。初心者に向いているかどうかとか、Webアプリの構築に向いているかどうかなんてことはもっとじっくり材料を整理して日記なんかよりももっと向いたメディアで展開すべきであって、手近な材料をきっかけに話を膨らますもんじゃない。（それが楽しいってのは否定しないけどさ。）
※ 一部に建設的な手法を議論されている方がいらっしゃることは承知しております。それを否定する気はまったくありません。
ありがたいことに元ネタについてはときどきの雑記帖 i戦士篇 2008年1月(下旬)にもう少し広い範囲をカバーした対訳があるのでそっちを見てください。
※ register_globals が on かどうかなどは判別できます。マニュアルの ini_get() を穴が開くほど嫁。
でだ。この挙げられた中で否定的な意見はざっくり構文的な設計の部分、肯定的な意見は機能の（特にキャッチーさと多さの）部分なんだよね。そもそもが全然噛み合ってないし、たぶんどっちも正解というか自分はどっちにも賛成します。全然矛盾しないし。
ということはすなわち片方の意見を以て PHP 全体が良いとか悪いとかはまったく言えないし、初心者に向いているかいないかも言えないし、Webアプリに向いているかいないかも言えないんです。言えないんです。それでいいんです。
ただね、気になるんだけどみんなちゃんとこの元ネタの肯定、否定意見読んだ？と問いたい。そのうえでこれらの意見にまったく同調できないんだとしたらそれは申し訳ないけど、明らかに不勉強か不感症です。そしてこれがいちばん言いたいことなんだけど
使うんだったらダメな部分はちゃんと理解して認めたうえで使え。スルーするな。
いいところについてはプログラムを書く人間はただ享受すればいいだけだけど、ダメなところは弱点なんだから、書く人間がそれを引き受けなきゃいけない。つまり「ダメだ」「イケてない」という意見こそ真面目に聞いたうえで使わなきゃダメ。初心者だからよく分からない？ だったらなおさらだ。言い直すと
勉強しない人の存在こそが「だから PHP は」「だから PHPer は」って言われるスキを与えるわけ。
分かったらくだらないケンカ売ったり買ったりしてねーで勉強しろ。他人の日記読んで頭に血のぼらせたりニヤニヤしてても絶対にいいコードは書けるようにならないから。Matz 叩きたいだけなら止めないけど、それはお前にとってどんなメリットがあるって言うんだ。
あと。
PHPer もずいぶん二極化というか局地化してるよね。完全に我が道行っちゃってて外野の声に反応がほとんどないのもちと寂しいですよ > 誰ともなく
