2006-11-01 (水)
■ get_existpages() の高速化 (2)
昨日の pagename_cache.php をバージョンアップ。
- fopen に失敗したときの対策を強化
- その他コードの整理
バージョンナンバーこそ 0.2 だが、これでほぼ完成という感じ。
2006-11-02 (木)
■ get_existpages() の高速化 (3)
pagename_cache.php は昨日の段階でほぼ完成のつもりでいたが、 もう少しだけ手を加えてバージョン 0.3 にしてみた。
どうせ PukiWiki 本体の改造に手をつけたのだから、 タイムスタンプをいちいちチェックしたりしなくても、 ファイルの新規作成や削除の直後に、 キャッシュを更新してしまえば良いのだった。 この辺、プラグインという発想から抜けきれていなかったな。
これでキャッシュ読み込み時の余分なチェックが減らせたので、 前のバージョンより若干速くなった。
2006-11-03 (金)
■ get_existpages() の高速化 (4)
ここ数日ちょこちょこバージョンアップしてきた pagename_cache.php だが、 安定動作するようにファイル書き込みの処理を厳密にし、 動作確認もしたので、バージョン 1.0 として公開する。 気になっていた部分はほぼ全て直したので、ひとまずこれで完成、ということで。
あとやるとしたら、ベンチマークのデータを取ったり、 PukiWiki Plus! 用のパッチを作ってみたりするくらいかな。
2006-11-04 (土)
■ get_existpages() の高速化 (5)
pagename_cache.php で、試しにキャッシュを RAM ディスク上に置いてみたところ、 ベンチマークの結果がかなり良くなった。 こいつはいい、ということで、 その辺の設定をしやすいようにコードを整理して、 バージョン 1.1 としてリリースしておいた。
と、ここまでやった後で、大ポカをやっていたことに気が付いた。 NAS に置いたファイルに対して測定してるじゃん。 何やってんだ、俺。orz
ということでやり直し。 改めて測定してみると、 キャッシュをハードディスクに置いても RAM ディスクに置いても、 処理速度の違いはほとんど見られなかった。 逆に、NAS みたいな遅いストレージにファイルを置いている場合は、 キャッシュを別の場所に置くのが結構有効ということか。
2006-11-05 (日)
■ pagetree.inc.php プラグイン Ver.1.2 をリリース
pagetree.inc.php プラグイン をバージョンアップ。
- 親ページが存在しない場合に表示が崩れるのを修正
というか、そういう飛び地のようなページを作ることってあるのか？ と思って放置していたのだが、 ページをリネームしていたらそういう状況が発生したので、 とりあえず対応しておいた。
2006-11-06 (月)
2006-11-09 (木)
■ vmshrink コマンドで仮想ディスクを圧縮
久しぶりの VMware ネタ。 X をインストールしていない Linux の仮想マシンに対し、 ディスクの圧縮を行うにはどうすればいいか？
- VMware Command Line Tools の vmshrink コマンドを使う
- vmware-mount と vmware-vdiskmanager コマンドを使う
- Xming などの X サーバを用いて、ホストの画面に vmware-toolbox のウィンドウを表示する
恐らくこの中で一番汎用的かつお手軽なのは、vmshrink コマンドを使う方法。 仮想マシン内にインストールして実行するだけで良い。 ずっと前にダウンロードしてその存在を忘れていたが、 使ってみると非常に便利なツールだ。
なお、64 ビット版の Linux だと VMware Command Line Tools が動かないことがある。 その場合、32 ビット版の glibc を追加でインストールすれば良い。 例えば CentOS 4.4 x86_64 の場合、 以下のコマンドを実行することで動くようになる。
# yum install glibc.i686
当たり前のことかもしれないが、気付くのにちょっと時間がかかった。
(追記)
Debian amd64 の場合は、aptitude install libc6-i386 とすればよい。
2006-11-11 (土)
■ rewritemap.inc.php プラグイン Ver.1.2 をリリース
rewritemap.inc.php をバージョンアップ。
- 変換ルールをキャッシュするようにして高速化
- ファイル読み書きの処理を厳密に
- コードの整理
通常の処理では正規表現のマッチングを全く行わず、 ハッシュテーブルを参照するだけで済むようになったので、 処理にかかる時間はほぼゼロにできたはず。
2006-11-12 (日)
■ Dotdeb 版 PHP 5.2.0 (2)
Dotdeb 版の PHP5 がバージョンアップしていた。 本家のパッケージングに合わせたそうで、 今までとパッケージの内容が変わっている。
- 追加されたパッケージ
- php5-recode
- php5-sqlite
- php5-xmlrpc
- php5-xsl
- php-pear
- 削除されたパッケージ
- php5-mysqli
- php5-pdo-mysql
- php5-pdo-pgsql
- php5-pdo-sqlite
- php5-pear
PDO 関係のパッケージが消えたのがちょっと痛いが、 多分 PECL のサイトからダウンロードしてきて、 自分でビルドすればいいのだろう。
PowerPC 用 (玄箱用) のパッケージもビルドし直してみた。 今までは何ヶ所かパッチをあてなければいけなかったのが、 パッチが（ほぼ）不要になっていた。 ビルド方法の説明 もそれに合わせて書き直しておいたが、 おかげで説明はかなり短くなってしまった。 ソースパッケージの完成度が高くなってきたということだろうが、 こう簡単だと逆に面白くないかも。
2006-11-13 (月)
■ Dotdeb 版 PHP 5.2.0 (3)
昨日書いたことの訂正。 Dotdeb 版 PHP5 から、 PDO 関連のモジュールが削除されたというのは間違いだった。
PDO はまだしも mysqli 用のパッケージは欲しいなぁ、 と思いソースパッケージの中身を調べていたところ、 php5-mysql のパッケージの説明にこう書かれていた。
This package provides modules for MySQL database connections directly from PHP scripts. It includes the generic "mysql" module which can be used to connect to all versions of MySQL, an improved "mysqli" module for MySQL version 4.1 or later, and the pdo_mysql module for use with the PHP Data Object extension.
つまり、MySQL 絡みのパッケージを例にあげると、
- php5-mysql
- php5-mysqli
- php5-pdo-mysql
の３つのパッケージが php5-mysql に統合された、 と考えれば良いわけだ。
ただ、これ、本家のパッケージングとは違うんだよね。 全部まとめてインストールできるのは確かに便利なんだが、 分割しておいた方が分かりやすいんじゃないのかなぁ？
2006-11-14 (火)
■ pagetree.inc.php プラグイン Ver.1.3 をリリース
しばらくバージョンアップはしないつもりだったが、 pagetree.inc.php にバグを見つけたので修正しておいた。 見つけたきっかけは、 以下のように PHP5.2 というページを新たに作ったこと。
- PHP5
- PHP5/環境設定
- PHP5.2
これをソートすると、 アスキーコードでは / よりも . の方が先にくるので、 以下のような順番に並ぶ。
- PHP5
- PHP5.2
- PHP5/環境設定
この結果を利用してインデントつきのツリーメニューを作ると、 以下のような表示になる。
−PHP5 ＋PHP5.2 ＋環境設定
マズい。これは非常にマズい。ページの階層構造が間違って表示されてしまっている。
アスキーコード表を眺めてみると、 空白文字にハイフンにピリオドと、 スラッシュより先に来る文字は結構あるので、 ソートの際にはこの辺を考慮してやらないといけない。 ということで、こんなふうに処理することにした。
$pages = str_replace('/', "\0", $pages);
sort($pages);
$pages = str_replace("\0", '/', $pages);
つまり、ソート前にスラッシュを \x00 の null 文字に置換してやり、 ソートした後でまた元に戻してやる。 関数がバイナリセーフかどうかに注意しないといけないきわどい方法だが、 これで上手くいくはず。
2006-11-18 (土)
■ VMware Workstation 5.5.3, VMware Player 1.0.3 がリリース
されていた。
- 新たにサポートされたホストOS
- Red Hat Enterprise Linux 4.0, Update 4 (AS, ES, WS), 32-bit and 64-bit
- Red Hat Enterprise Linux 3.0, Update 8 (AS, ES, WS), 32-bit and 64-bit
- Experimental support for Red Hat Enterprise Linux 5.0, 32-bit and 64-bit
- Mandriva Corporate Server 4, 32-bit and 64-bit
- Experimental support for Mandriva Linux 2007, 32-bit and 64-bit
- Experimental support for Ubuntu Linux 6.10, 32-bit and 64-bit
- 新たにサポートされたゲストOS
- Red Hat Enterprise Linux 4.0, Update 4 (AS, ES, WS), 32-bit and 64-bit
- Red Hat Enterprise Linux 3.0, Update 8 (AS, ES, WS), 32-bit and 64-bit
- Experimental support for Red Hat Enterprise Linux 5.0, 32-bit and 64-bit
- Experimental enhanced support for Microsoft Windows Vista, 32-bit and 64-bit
- Mandriva Corporate Server 4, 32-bit and 64-bit
- Experimental support for Mandriva Linux 2007, 32-bit and 64-bit
- Experimental support for Solaris x86 10 6/06 (Update 2), 32-bit and 64-bit
- Experimental support for Ubuntu Linux 6.10, 32-bit and 64-bit
この中では Windows Vista への対応という点が注目を集めそうだが、 個人的には Ubuntu Linux 6.10 が対応されたのが嬉しい。
2006-11-26 (日)
■ PukiWiki でのページのリダイレクト
PukiWiki でページ A → ページ B に名前変更した時の作業メモ。 rewritemap.inc.php プラグイン を使って URL を A.html のようにしていたので、 .htaccess に以下のようなリダイレクトの設定を追加してみた。
Redirect permanent /A.html http://www.revulo.com/B.html
やってみたところ、 確かに目的のページにリダイレクトはしてくれたが、 リダイレクト先が以下のような変な URL になってしまった。
http://www.revulo.com/B.html?cmd=rewritemap&alias=A
なんだかよく分からないが、 mod_rewrite の設定も同時に（？）適用されてしまっている感じ。 どうも mod_rewrite を使っていると、 こうなるのを回避できないようだ。
ということで、別の案として、 プラグインを使ってリダイレクトさせる方法を試してみた。 PukiWiki 本家の自作プラグインに登録されている alias.inc.php とか redirect.inc.php でも良いが、 ここでは自作の 301redirect.inc.php というプラグインを使用した。 手順としては以下のようになる。
- ページ A の名前をページ B に変更
- 新たにページ A を作成
- ページ A に #301redirect(B) と記述
こうすれば、リダイレクト先の URL は望み通り B.html になる。 ただしこれだと、ページ A というダミーページの存在が、 ページの一覧や sitemaps.inc.php の出力に現れてしまうので、 それが嫌な場合は $non_list の設定にページ A を加えてしまえば良い。
と、ここまでやって思ったのだが、 rewritemap.inc.php にこういうリダイレクト機能を組み込んだらどうだろう？ そうすればダミーページを作らなくて済む。 ただし、仕様がゴチャゴチャになるのは嫌なので、 すっきりと組み込めるかどうか少し考えてみよう。
2006-11-27 (月)
■ PukiWiki でのページのリダイレクト (2)
昨日の件 について考えてみたが、やはり rewritemap.inc.php プラグイン にリダイレクト機能を綺麗に追加するのは難しい。 ページ A → ページ B という変換ルールが書かれていた時、 それがページ B の URL を A.html と登録しようとしているのか、 ページ A からページ B へのリダイレクトを意図しているのか、 区別のしようがないからだ。
両者の意味とか動作は似てはいるが、 301 リダイレクトするかしないかという点で明確に区別すべきなので、 やはり今の設定方法だけでは対処しきれない。 解決策としては、
- |A |B |301 のような表記方法を新たに導入する
- :config/Redirect という第２の設定ファイルを新たに用意する
- redirect.inc.php プラグインを新たに作り、rewritemap.inc.php で名前解決したページが存在しない場合はそちらに制御を移す
あたりかな。 この中では恐らく最後の案が一番まとも。 つまり、rewritemap.inc.php と同じような仕組みで、 リダイレクトする旧 URL と新 URL との対応関係を集中管理するプラグイン、 を新たに作ろうかという案。 多分、rewritemap.inc.php とは独立したプラグインとして作れると思う。
ただ、そこまでする必要があるのか？ というのが疑問。 取り掛かればすぐに作れるとは思うが、 とりあえずは保留にしておこう。
2006-11-28 (火)
■ tDiary の XSS 脆弱性
tDiaryの脆弱性に関する報告(2006-11-26) が出ている。 現在ここのブログで使っている tDiary 2.1.4 についても、 対策用のパッチが公開されていたので適用しておいた。
2006-11-30 (木)
■ Ethna 2.3.0 と symfony 1.0 beta1 がリリース
なんでこう立て続けに…。
実は、今まで Ethna を使っていたのを Zend Framework に乗り換えようとしていたが、 Ethna 2.3.0 の変更点を見てみると、 今までいい加減だった部分がマトモになったという印象を受けたので、 もう１度 Ethna を試してみようと思う。
symfony はまだ使ったことがないが、とりあえずダウンロードしておく。 Web ページにはバージョン 0.7 の古い奴がまだ置かれていたので、 以下の PEAR の方のページからダウンロードした。
http://pear.symfony-project.com/get/symfony-1.0.0beta1.tgz
他のフレームワークと比べて完成度は高そうなので、 勉強のためにチュートリアルくらいはやっておいた方がいいのかも。
