- 2009-08-10 (月) 18:02
- PHP
お久しぶりです。
もうすっかり夏ですね。僕といえばバリ島で結婚式を挙げてきました。楽しかったです。
これのおかげで割りとハードな毎日を送っているためブログの更新などは余りできませんが、忘れないであげて下さい。
さて、著者の鈴木憲治様よりPHP逆引きレシピをご献本頂きました。ありがとうございます。
以下書評。
「直接的な関数の組み合わせでプログラムを”組み立てる”」という PHP のスタンスにおいて最も重要なのは「目的に応じた答えを知る事」であると言えます。そのような視点から見ると本書はこれ以上ないほどに”実践的”です。
目的に対する方法を引く事ができ、その方法に関連する他の方法に対してもインデクシングされているばかりか、PHP バージョンごとの差異やメジャーなレンタルサーバに依存する問題なども詳解されているため、本書とパソコンと「ウェブアプリを作りたい」という目的意識さえあれば作れてしまう程です。
それだけに留まらずセキュリティに関しての広範な対策方法や、PHP で書かれたオープンソースソフトウェアの基本的な利用法も解説されており、さらには PDF、画像、グラフなどの生成方法といった「PHP をベースとしたシステムの利用」についても言及されているため、これはもう「答えのフルコース」だと言えるでしょう。
しかしながら残念な点もいくつかあります。
@ によるエラー抑制に始まり、参照渡しを「混乱しやすいから」という乱暴な理由で推奨していなかったり === ではなく == での評価がほとんどだったりと、初心者向けだからこそ肌感覚で培って欲しい「PHP のだめなところ」に関する言及がとても少なく、本書だけで学べてしまうが故に、本書だけを参照してコーディングしていると早い段階で「あれ?なんでこうなるの?」と戸惑う場面に出くわすでしょう。
特に、セオリーとされている mb_strlen() や htmlspecialchars() に文字コードを渡す事が書かれていない点は大きな穴です。
しかし本書は数多く出版されている PHP 本の中でも「決定版」と言えるほど完成しており、PHP での開発を生業とする企業ならば新入社員用の教科書として必携の一冊であると言えるでしょう。
と、まとめるとこんな感じです。
折角なので残念なところの補足をいくつか。
@によるエラー抑制
これは大変まずい事です。自己満足的なプログラムならば良いとしても、割と実践的な事が書かれているだけにビジネス用途で作ったようなプログラムでこれを使ってはいけません。
@でエラー抑制すると遅くなるとか、そんな事はどうでもいいんです。エラー抑制する代わりにハンドリングすれば似たような負荷がかかる事が多いですから。それよりも「@でエラー抑制をしているとエラーが表示されなくなる」というところにこそ問題があります。殴られても痛くないみたいな。出さないのがいいものはエラーであってエラーメッセージではないんです。
もし@で抑制している箇所に起因するバグがあった場合、追いかけるのは結構面倒くさいです。
「いくつかあたりをつけて探してみたけどそれっぽいところはない。じゃあちょっと@消してみようか」みたいなのはバッチリ二度手間です。
そんな事するくらいなら最初から@で抑制するんじゃなくて条件式なりなんなりでエラーのハンドリングをするべきです。
=== じゃなくて == を多用している
これもよくありません。基本的に == を使うべきではありません。== で評価するくらいなら型キャストしてしまって if( (int) $a === 5 ) というように書いた方がマシです。これと同じ理由で if( $a ) と言うような評価もよくありません。== を使わないよう癖つけるくらいでちょうどいいと思います。
評価する変数の型によって結果が違う評価式なんてのは気難しい人に様子を伺うようなものです。逆に == でしか評価できないような実装はそもそも設計に問題があります。
mb_strlen() や htmlspecialchars() に文字コードを渡す事
よく「PHP の mbstring の設定はこうした方がいい」なんつって mbstring.internal_encoding = utf-8 みたいな事を書いているような人がいますが、これも合理的じゃありません。そもそもプログラムごとに文字コードが違うし、リクエストに含まれる文字の文字コードだってバラバラです。それなのに PHP の設定としてサーバソフトウェア側で文字コードを制御するのは考慮しなければいけない点を増やすだけで全く持って非効率的です。そもそも文字コードを扱うレイヤーじゃないです。
大体 web アプリを作るときにはアプリで扱う文字コードを決めて、その文字コード以外の文字コードで送られてきたリクエストははじくのが前提ですから、そのアプリで解釈すべき文字コードは(原則的には)1種類です。
htmlspecialchars() のシノニムで h() を作るのも今ではセオリーで本書にも書かれていますが、第二引数だけではなく第三引数まで書かないと意味がありません。
define( 'SITE_ENCODE', 'utf-8' ); h( $var ){ return htmlspecialchars( $var, ENT_QUOTES, SITE_ENCODE ); }
みたいな。
大体 utf-8 な文字を mb_strlen() 辺りで図ろうとしても文字コード指定してるか mbstring.internal_encoding で utf-8 が指定されていないと正しい結果を返しません。mbstring.internal_encoding は前述の通り文字コードを制御するようなレイヤーにある設定ではないので、消去法的に考えるとマルチバイト系の文字列関数にはきちんと文字コードも渡してあげるのがモアベターです。
でも結局は全部 PHP の設計に起因する問題なんですよね。
これらのつかみにくい設計に関するノウハウまで求めるのは酷かもしれませんが、web デザイナーが css ハックを必要とするようにこういった情報も必要なんじゃないんでしょうか。
ここらへんの情報が無い以外は本当に素晴らしい書籍です。
僕みたいに受託で開発やってるような人間はクライアントから「社内でエンジニアを育てたい」的なお話をよく聞きますが、本書はそこらへんのニーズをバッチシ抑えてます。
逆引きリファレンスですが関数依存の構成ではなくユースケースに依存しているため、明確な目的意識が無くてもノウハウの蓄積に役立つとも思います。
以上。
- Older: ググレカス勉強法
Comments:0
Trackbacks:0
- Trackback URL for this entry
- http://spais.jp/php/%e6%9b%b8%e8%a9%95%e3%80%8cphp%e9%80%86%e5%bc%95%e3%81%8d%e3%83%ac%e3%82%b7%e3%83%94%e3%80%8d/2009-08-10/trackback
- Listed below are links to weblogs that reference
- 書評「PHP逆引きレシピ」 from SPaiS