PHPのE_STRICTエラー

PHPのエラーレポートレベルはphp.ini設定のerror_reportingで設定されています。

PHP5から追加されたE_STRICTで「あれ」と思われるかもしれない状況があるので書いておきます。

PHP5でE_ALLをerror_reportingに設定してもE_STRICTレベルのエラーは報告されません。デフォルト設定ファイルではE_STRICTは無視されるようになっています。

と設定しないとより厳しいエラーチェックが行われません。

開発時には言語が用意しているエラーチェックを出来る限り多く使用するべきです。しかし、E_STRICTレベルのエラーレポートを行う設定を行った場合に問題が発生する場合があります。次のコードがどのように処理されるか考えると分かります。

E_STRICTで報告されるエラーには”var”宣言されたプロパティにpublic/private/protectedを使用するよう推奨するエラーがあります。このエラーはコンパイル時に発生するため、スクリプト中でerror_reporting関数を使ってエラー報告レベルと変更してもE_STRICTエラーを無視できません。E_STRICTエラーが有効な環境で、error_reporting関数で確実にE_STRICTエラーが発生しないようにするには、E_STRICTエラー出力を抑制するには最初に読み込まれるファイルのコード中にE_STRICTエラーが発生しないしerror_reporting関数を使用してエラー報告レベルを変更しなければなりません。

# E_STRICTは開発時だけ使う、という方針がお勧めです。
# PHP4用に作ったアプリの修正は手間な場合は、INSTALL
# ファイルなどにE_STRICTは無効にするよう書くだけでも
# 良いかもしれません。

備考:
E_NOTICEレベルのエラーは全て実行時に発生するエラーであるため、E_STRICTの様な問題は発生しません。念のため。

追記:
今時のPHPアプリケーションならE_STRICTエラーも発生しないようにプログラムを作成すべきす。

 

関数の戻り値と定数値(リテラル)への参照

追記:このエントリへのアクセスが多いので加筆修正しました。

Fatal error: Only variables can be passed by reference

直訳すると「致命的エラー:変数のみ参照渡しが可能です」となります。エラーメッセージの通りvariable(以外)の値は参照として渡せないのでエラーになっています。エラーメッセージが適切かどうかは微妙ですが、意訳すると「致命的エラー:ソースコード中に記述した定数値(リテラル)へのアクセスはできません」あたりが妥当と思います。当然ですがdefineで定義した定数値を返す事は可能です。PHP内部では定数は変更できない「変数」の様に実装されているからです。このエントリの「定数値」を正確に書くと「ソースコード中に記述された定数値」となります。

“関数の戻り値と定数値(リテラル)への参照” の続きを読む

QRコードを短冊に

メモ。QRコードに関するblog。本文もQRコードならコメントもQRコードです(気付くのが遅すぎ?

とろこでトップページの「QRコード読み取りのコツ」に

■QRコードの真正面から撮影

とありますが、真正面から読まないとQRコードが読み取れないリーダ(携帯)があるのですね。と、書いている自分も正面から読み取るようにしていますが、QRコードは印刷面が平たければ、ななめから読み取っても読み取れる設計になっています。QRコードの仕様を知らない方も多いと思うので簡単な説明を付けておきます。隅の大きめの■が斜めからも読み取れるようにするための役割を持っています。全ての隅に大きめの■が無いのは読み取り開始位置を判別できるようにするためです。カメラの解像度やQRコードが写されている領域の影響もあるので正面から撮らないと読み取りに失敗する確立は高くはなると思います。エラー補正情報をQRコード内にたくさん入れていれば読み取りに成功する確立は高くなりますが、QRコードが大きくなります。微妙ですね。

allow_url_fopen

追記:
現在のPHPではリモートファイル読み込みを制御するphp.ini設定としてallow_url_fopen(URL等のファイルとして読み込むフラグ)とallow_url_include(URLなどをPHPスクリプトとして読み込むフラグ)があります。php://input(標準入力用のURL。Webアプリの場合、POSTリクエストなどが読み込める)もallow_url_include=Offでは利用できません。このためallow_url_include=Offの場合、リモートスクリプトからの読み込みを防止できます。

基本的には

  • allow_url_includeは常に無効(JSONなどでなくPHPスクリプトとしてリモートデータを読む、などの場合は局所的に有効化)
  • allow_url_fopenは全く必要ないなら無効

とすると良いでしょう。

PHPを使っている方はHTTP/FTP/SSH等のプロトコルでリモートサーバ上のファイルをローカルファイルの様に読み書きできる事をご存知と思います。この機能はphp.ini設定のallow_url_fopenディレクティブで有効/無効を設定できるようになっています。PHP 4.3.4より前のPHPではこの機能のスクリプト中からも無効/有効に設定を変更する事ができました。(INI_ALLの設定項目であった)

驚いたことにPHP 4.3.4からphp.iniからしかこの設定を変更できなくなってしまいました。(INI_SYSTEMの設定項目になった)誰かがセキュリティ強化を目的として変更したのだとは思いますが、セキュリティも強化できず、有用なリモートファイルアクセス機能も使えなくする非常に拙い変更です。

例えば、phpBB(BBSアプリケーション)ではinclude/require文に不適切に処理されたユーザ入力が利用されている為、リモートスクリプトを読み込み実行できてしまう非常に深刻なセキュリティ上の問題がまた最近見つかりました。phpBBはallow_url_fopen機能が無効であっても動作するので

allow_url_fopen = Off

と設定するか必ず読み込まれる設定ファイルで

ini_set(‘allow_url_fopen’, 0);

とすると、phpBBのようなアプリケーションでも比較的安全に運用することができました。

しかし、allow_url_fopenがINI_SYSTEMの設定項目になった為、前者の方法を取ると他のアプリケーションで、場合によっては非常に有用な、allow_url_fopen機能を使えなくなってしまいました。後者の方法は、特定のアプリケーションのみの設定を変更するのに有効ですが、INI_SYSTEM設定項目であるため実際には無効に設定できなくなってしまいました。

セキュリティ上の意味は容易に理解できるであろうと、internals@list.php.net にallow_url_fopenの設定を

デフォルトOFF
INI_ALLへ変更

するように提案して見たところ議論が結構荒れています…
この設定が安全かつ不必要な機能制限が無く、最も良い設定と思うのですが…

# allow_url_fopen_includeのようにinclude/require文用の設定
# を追加するのも良いですが、デフォルトOFF、INI_ALLであるべき
# と思います。

php-rast

Rastとはネットワーク応用通信研究所が開発している全文検索システムです。

本ソフトウェアは,あらかじめ対象となる文書群から検索に必要な情報を格納するデータベースを作成しておき,それに対して検索を行う全文検索システムです.

検索方式は N-gram 方式や分かち書き方式から選べます.また,必要に応じて文字列処理モジュールを差し替えることができます.

なお,本ソフトウェアは IPA の平成16年度オープンソフトウェア活用基盤整備事業の委託を受けて開発を行っています.

このRast用のPHPモジュールを冨田冨田隆三さんが公開されています。

名古屋市立大学の冨田です

以前、全文検索エンジンRast のモジュールを公開したところ、ここでライセンス違反の可能性を指摘されて公開を止めていましたが、Rast-0.2.0 で BSD ライクな緩いライセンスに変更されたようなのでまた公開してみます。

ダウンロードはこちらからどうぞ。
http://a157.debian.co.jp/php_rast/

冨田

サンプルの動作は良い感じです。サンプルコードもざっと見てみましたが使いやすそうです。

_php_stream_passthru

php-usersのMLに投稿した内容の補足です。コードはPHP 4.4の開発ブランチのソースです。

main/stream.cに_php_stream_passthru関数が定義されています。reafile関数(ファイルの中身を全て出力)、fpassthru関数(ファイルリソースの中身を全て出力)に利用されています。

注目すべきは以下です。

PHPWRITEマクロは最終的に出力バッファに書き出します。PHPからの出力は最終的にWebサーバにバッファされる場合があります。つまり、一度に大量のデータを出力するとメモリを大量に必要とする可能性があります。

Momoery Mapped I/Oの利点がバッファ無しでデータを読める事は分りますが、大きなファイルを送信するには不適切な事は明らかです。データを適切なチャンクサイズに区切ってPHPWRITEに書き込むよう変更しなければならないですね…

DokuWiki

久しぶりにmadwifiの設定をしようとmadwifiのページを見てみると見慣れないWikiを使っていたのでどんなWikiかさらっと見てみました。インストールやソースを読んでいないので見てみた感想です。

基本的なWiki機能はそろっているようです。ページの場所 “top>a page>another page”の様に表示されるのも便利です。ログインユーザ登録もサポートしているようで、Eメールアドレスを登録してから編集を許可する、という運用ができるのはSPAM対策やセキュリティ対策に役立つと思います。

次のような機能を持っているようです。

DokuWiki Features here

* works on plain text files, no database needed
* simple syntax and easy editing with quickbuttons and accesskeys
* Section Editing allows you to edit small parts of a page
* automatic generation of content tables
* unlimited page revisions
* colored side by side diff support
* support for read only pages
* syndication of recent changes as RSS Feed
* namespaces
* Interwiki Links
* uploading and embedding images
* image caching and resizing
* easy navigation through breadcrumbs
* Customizing with templates and plugins
* Multilanguage Support
* Spam blacklist
* custom text replacements
* pagecaching
* locking to avoid edit conflicts
* full UTF-8 support
* and more

Wiki機能の比較は見るだけでも興味深いと思います。

Tipsのページを見てみると色々な機能が追加できる事が分かります。SVGをPNGやGIFに変換、ページをPostscriptに変換、HTMLからDokuWiki形式への変換方法が記載されています。

面白かったのはNanoWebをサポートするWebサーバとして記載されている所です。NanoWebはPHPで記述されたWebサーバで

Nanoweb’s main features are :

– HTTP/1.1 compliance
– Powerful and easy configuration
– Modular architecture
– FastCGI, CGI and Server side includes support
– Name and port based virtual hosts
– Access control lists
– htpasswd, MySQL, PostgreSQL and LDAP authentication support
– Themes for server generated content
– Apache compatible log format, MySQL logging
– Directory browsing
– inetd support and SSL via external helpers
– Denial of Service protection
– Proxy Server extension
– Filters and gzip support
– RBL support (mail-abuse.org)
– Extension Protocols (request methods) support
– … and a lot more

と色々盛り沢山です。

コマンドラインのPHPさえインストールされていれば自分でWebサーバを立てる事ができます。NanoWebのソースは以前に読んだ事があるので多少は分かります。pluginの作成は簡単そうでした。速度的にも普通(?)のリクエスト数であれば十分処理できるパフォーマンスでした。(思ったより速くて驚いたと思います)

PHP4でpublic

PHP本家の開発ML internals@lists.php.net ではPHP4でpublic宣言を行えるようにするかどうかで盛り上がっています。

PHP5を使っている方はご存知の通り、PHP5からオブジェクトのプロパティはpublic, protected, privateにアクセスレベルを限定できるようになりました。それと同時に古いプロパティ宣言であるvar宣言は使わないよう推奨されています。

初めの頃のPHP5のリリースではPHP5で追加されたE_STRICTエラーを表示する為の記述に間違いがありました。E_ALLではE_STRICTエラーでは表示されず、E_ALL | E_STRICTにしなければなりません。E_STRICTエラーにはvar宣言についてもvarではなくpublic, private, protectedを使用する旨のエラーが発生します。E_STRICTエラーを表示する設定方法に間違いがあったため、E_STRICTエラーには気が付きづらかったと思います。E_STRICTレベルエラーを有効にしてエラーの数に驚いた方も多いかも知れません。

しかし、var宣言エラーの問題さえクリアすればほとんどE_STRICTレベルのエラーを回避し、PHP4とPHP5の両方で実行できるコードを書くことも可能になります。現状ではPHP4ではクラス定義の際、プロパティは必ずvar宣言しなければならないのでクラスを使えばE_STRICTエラーは必ず発生します。

class foo {
public $var;
}

をPHP4でも使えるようにするメリットはあります。PHP4用のコードと言いつつPHP4.4より古いPHP4では実行できなくなるのも困るというのも分かります。

私はPHP4の文法は拡張せず最初に読み込むアプリケーションの設定ファイルなどで


error_reporting(E_ALL);

を実行する方がよいのではないかと思っています。
この方法には最初に読み込まれるファイルが在ること、そのファイルにクラス定義が含まれないと前提条件もありますがこれでも十分ではないかと思います。

# 最悪、auto_prependでerror_reporing設定を変える方法も使えます。

S2PHP5

S2PHP5は名前の通りPHP5専用のフレームワークだそうです。

説明

Java版のSeasar2を、PHP5に移植します。

 マイルストーン
M1: Java版Seasar2をPHP化する (バージョン 0.9x)
パッケージ構成やインタフェースを統一し、Javaのソースをできるだけ変更することなくPHP5に書き換えます。
M2: PHPらしくリファクタリング (beta バージョン)
リリース1.0 に向けて、移植もれ、移植ミス、動作不具合への対応。
また、実装方法、命名規則、名前空間、クラス定義の読込み方法や設定ファイルの在り方等々、ユーザ様からの声を検討、反映し、「 易しく・優しく・PHPらしく 」 を目標にリファクタリングします。
ご意見・要望など Seasar-User ML までお願いします。

最初のリリース(0.92)は5/29のようです。現在は0.93(6/9)が最新リリースのようです。

面白そうなので近いうちに時間を作って試して見たいです。

# 私のアンテナあまり広くないので、面白そうな情報があった
# ら是非教えてください :) 

Rails

Rubyを使っている方やMLを覘いている方(私はこちらです)はWebフレームワークのRuby on Railsをご存知と思います。Ruby使いではないのでMLをさらっと横目で見ている程度なので詳しくは知らなかったのですが

http://www.rubyonrails.org/

QuickTimeの紹介ムービーがあったので見てみました。10分ほどのムービーですが簡単にWebアプリケーションが作れる事が分かります。

Rails、面白そうですね。MLで盛り上がる訳ですね 🙂

Serendipity – PHP Blog System

Blogツールの選択肢は多すぎてどれを選べば良いか迷う程ですがSerendipityというPHPで記述されたBlogシステムを知りました。

WYSIWYG HTMLエディタも利用できたり、全てのRSSとATOMに対応、イメージのリサイズサポート等、割と良くできていると思います。PHP5ならSQLiteをデータベースとして利用できるのでDBサーバ無しでも利用できる点が良いと思います。

Developer Team
Jannis Hermanns
Sterling Hughes
George Schlossnagle
Wez Furlong
Sebastian Bergmann
Garvin Hicking
Tom Sommer
Joyce Park
Christian Mühlhaeuser
Joseph Tate

開発者の名前を見るとPHPプロジェクトのコミッターが多いですね。
# 私が知らないだけで、全員コミッターかも知れませんが。

b2evolutionから乗り換えるには、統計情報、SPAM排除機能等が必要ですね。これらの機能はまだないようです。

PHP 5.1でgoto!?

なんだかPHP 4.4ブランチが出来たりして??と思っていたところ「goto文をPHP 5.1で!」と言う事でinternals@lists.php.netが盛り上がっています。

goto文が無くて困ることは無いのですが、あって困る事は沢山あります。自分だけがコードを書くわけではありませんしgoto文の乱用は簡単です。しかし、今まで無くて困らなかったのに何故今頃、という感じです。

万が一goto文がサポートされても使わないようにしましょう(笑

PHPとICU

http://www.gravitonic.com/downloads/talks/intlphpcon2005/php_unicode.pdf

メモ。PHPのI18Nの話。
前半はUnicode等の説明。

G5 PowerMac, MacMiniでサウンド

YellodogLinuxからG5 PowerMac, MacMiniでサウンドをサポートしました、とアナウンスがありました。

We are pleased to announce support for the latest Apple Power Mac G5s (towers), Power Mac G5 sound support, internal Mac Mini sound support, and dual head support for new Apple Aluminum Cinema Displays.

サイボーズがMySQLを選択した理由

サイボーズは独自システムからオープンソースシステムを活用する方向に移行をするようですね。

Berkeley DBも候補に挙がっていた、とこの事ですからトランザクションが必要ないことは明らかですね。現時点で選定したらSQLiteという選択肢もあったのかも知れませんね。

決定した時点での状況、Windowsサポート等を考えるとMySQLと言う選択も株主としても納得できる選択と思います。

新しいフレームワークではアプリケーションをPHPで記述しています。これもMySQLの採用と同じくらい大きな選択で、この部分をJavaにするかでも悩みました。

この選択もDBの選択と同様に微妙ですが、コードの一部を公開してカスタマイズを可能にするにはPHPの方が有利だと思います。新しく作るならPHP5が良いかと思いますが、もう作ってあるようですね。

このブログ、サイボーズの方もご覧になっているようなので営業を一つ。
セキュリティの監査など必要でしたら是非どうぞ。
# 本当に引合がきたりして(笑

PHPに足りないもの

よく「中規模以上のプロジェクトにPHPは向かない」と聞きますがJavaに比べると確かにその通りです。Beanなんて考え方は無いですし「JCPで作られた数々の標準に対応するような物がない」と言われても仕方ない状況です。言語仕様についても結構アバウトで微妙な仕様が突然変わったりします。
# 最近では5.0.3でコンストラクタをprivateで宣言できなくなった件があ
# ります。これは次の5.0.5で修正されますが。
# PHP4->PHP5ではオブジェクトを配列にキャストするとPHP5ではおかしな
# 動作をするなどがあります。

(特に現在は)PHPでJavaのような環境を前提としたしシステム開発には無理があります。Javaのようにいたれりつくせりの環境、アプリケーションサーバの付加分散等までフレームワークでやってしまえるような環境であるJavaと比べれば、明らかにPHPは中規模・大規模に向かないと言えます。

PHPでの開発は、どちらかと言うと、C言語での開発に近いのではと思います。いたれりつくせりの標準フレームワークは無い事、詳細は異なりますがアバウトなデータ型管理、などC言語での開発に似ている点はいくつかあると思います。C言語がJavaのような標準フレームワークを持っていないくても色々な分野で利用されています。最近ではC言語での大規模開発は相対的に少なくなって来ているとは思いますが、C言語で中規模以上の開発は向かない、と言う方はいないと思います。

ここでプロジェクトの規模について簡単に整理してみます。プロジェクトの規模には大きく分けて2種類あると考えています。1つは開発時の開発体制の規模、もう1つは運用時のシステムの規模です。

「開発体制規模が大きなシステム=運用時のシステム規模が大きなシステム」は成り立ちません。PHPが向かないと言われているシステムは「開発体制規模が大きなプロジェクト」であり、「運用時のシステム規模が大きなプロジェクト」ではありません。作るアプリケーションによりますがPHPで大規模システム(後者)を構築すると非常に開発効率が良い場合もあります。開発者が20名を超える中規模(会社によっては100名以下は小規模という会社もいくつもあると思いますが)システムの場合、プロジェクト管理により高度な技術的な知識が必要となり、プロジェクトを進行しづらい状況もあるとは思います。反対に安直にJavaで作ってしまい、スケーラビリティに欠けるWebシステムになってしまった、と言う話もよく聞きます。
# スケーラビリティに欠けるシステムはPHPでも簡単につくれますが、
# Javaのフレームワークを過信する間違いはよく聞きます。

PHPに足りない物は開発者の分業を可能とするフレームワークです。PHP5になって、PHP4との互換性を考えなければ、フレームワークを構築する開発者は随分やりやすくなってきています。PHP5になりフレームワークをルールに則り利用する事を強制する事も可能なりました。DIを実装しているMapleなどのフレームワークが充実してくるとこの状況も徐々に改善してくる事と思います。特に日本製フレームワーク、MapleEnthaに期待したいと思います。

「OSSの性能・信頼性評価/障害解析ツール開発」の成果を公開

OSCでもこの手の発表が聞けると思えますが、聞けなくて残念。

開発基盤ワーキンググループに関するドキュメントで、一般公開可能なドキュメントをダウンロードすることができます。
他のワーキンググループや日本OSS推進フォーラム全体に関するドキュメントは、左のメニューから選択してダウンロードしてください。
ダウンロードは下記ドキュメントのタイトルをクリックしてください。

「OSSの性能・信頼性評価/障害解析ツール開発」の成果を公開しました

http://www.ipa.go.jp/software/open/forum/DevInfraWG.html

AJAX – ダイナミックWebコンテンツ

JavaScript/DOMを使ったメニュー生成やフォーム選択状況に応じて適切なメッセージを表示するダイナミックコンテンツは多くありましたが、よりインタラクティブなHTMLコンテンツがどんどん増えそうです。

AJAX = Asynchronous JavaScript + XML

XMLHttpRequestを使った方法ですが、非常に新しいと言うことではないのですが最近急に注目されはじめました。

はやりgoogleのせい?

ここここが参考になります。

まるごとPostgreSQL! Vol. 1

「まるごとPHP! Vol.1」もエキスパートセクションのセキュリティ関連トピックで執筆させて頂きましたが同シリーズの「まるごとPostgreSQL! Vol.1」も執筆させて頂きました。私も編集者の方からのメールで今日知りましたが、以下の様な内容になるそうです。

■書名:まるごとPostgreSQL! Vol.1
 (売れたらVol.2を作りたい、という希望を込めてのVol.1です)
■ISBN:4-8443-2035-X
■価格:1800円+税
■体裁:232ページ、B5判、1色刷
■発売日:2004年12月8日
■目次:
特集1●PostgreSQLによる高可用性の実現
  pgpoolでPostgreSQLを大幅にパワーアップ!……石井 達夫
  PostgresForestのすべて……谷越 桂太
  ESM for PostgreSQL……安永 尚稔
  Slony-I first impressions!……谷田 豊盛
特集2●PostgreSQLとOracleによるデータベース相互移行マニュアル……奥畑 裕樹
特集3●PostgreSQLによる大規模運用……大垣 靖男
特集4●新バージョンPostgreSQL 8.0先行レビュー 〜使えるRDBMSをめざして
  PostgreSQLのあゆみ、そして8.0へと続く道……谷田 豊盛
  Point In Time Recoveryのしくみ……坂田 哲夫
特集5●PostgreSQLで.NET
  開発者が語るPgsqlの歴史と今後……Francisco Figueiredo Jr.
  Pgsqlのインストールとその機能……さいとう ひろし
  VB.NET+PostgreSQLでWebアプリを作ろう……白井 伸昌
  C#でPostgreSQLを操作しよう……林 重行
  5分でできる。Npgsqlを使ったExcelへのデータ取り込み……多度 純一
●一般記事
  PostgreSQLチューニング実践テクニック……石井 達夫
  PostgreSQL技術者認定制度(PostgreSQL CE)を受けに行こう!……稲葉 香里