2007-08-01 (水)
■ PukiWiki 用プラグイン ajaxtree.inc.php Ver.1.0 を公開
ajaxtree.inc.php プラグイン をバージョンアップした。変更点は以下の通り。
- ページ名に記号が含まれていると動かない場合があったのを修正
一昨日書いたように、 PHP と JavaScript の URL エンコードの違い による問題があったので、その対処を行った。
あとは jQuery を使うように書き直そうかと思っていたが、 昨日の実験 によって、 jQuery を使わなくても自前の Ajax のコードで十分だと分かったので、 これでひとまず正式公開ということにする。
2007-08-02 (木)
■ PEAR::Pager の謎パッチ
PEAR::Pager を最新バージョンにあげようとして気がついたが、 今まで Pager_Common クラスをこんな風に書き換えて使っていた。
function _getLinksData()
{
$qs = array();
if ($this->_importQuery) {
if ($this->_httpMethod == 'POST') {
- $qs = $_POST;
+ $qs = (array)$_POST;
} elseif ($this->_httpMethod == 'GET') {
- $qs = $_GET;
+ $qs = (array)$_GET;
}
}
えーと、なぜこう書き換えてたんだ? $_POST が配列でない場合を想定しているわけだから…。 思い出した。昔の Zend_Filter_Input クラスで、
Zend_Filter_Input は、渡された配列 ($_POST) を NULL に設定し、元の値に直接アクセスできないようにします。
という処理が行われていたので、それの対策だ。
確かに、厳密にはこうしておく方がいいのかもしれない。 でも、こういう修正が必要になるケースって他にはなさそうだから、 もうこのパッチは適用しなくてもいいかな。
2007-08-04 (土)
■ PukiWiki 用プラグイン geshi.inc.php, highlighter.inc.php Ver.1.1 を公開
geshi.inc.php プラグイン と highlighter.inc.php プラグイン をバージョンアップした。変更点は以下の通り。
- タイムスタンプを変更しない編集の時もキャッシュが更新されるように改良
- プレビュー時にはキャッシュを使用しないように変更
- 行番号表示に PEAR::Text_Highlighter 0.7.0 以降の機能を用いるように変更
- PEAR::Text_Highlighter 標準のスタイルシートを同梱
「タイムスタンプを変更しない編集」の時の動作を改善できたのが目玉かな。 sonots さんから要望をいただいたのがきっかけだが、 せっかくなので、その話題のところへリンクを張っておく。
あとキャッシュ使用時に、変更がプレビューに反映されないのは変なので、 プレビューの時はキャッシュを無効にするようにしてみた。 PukiWiki Plus! の Ajax プレビューの時に負荷がものすごいことになりそうなので、
if (isset($vars['preview']) || isset($vars['realview'])) {
- $options['cache'] = false;
+ $options['language'] = '';
}
のようにして、プレビューの時は白黒の簡易表示にする、という案も考えてみたが、 とりあえず一番自然な動作になるようにしておいた。 まぁ、直すなら Ajax プレビューそのものに手を入れる方がいいだろう。 例えば、描画を最大でも3秒に1回に間引くとか。 BugTrack/126 - PukiWiki Plus! にもう少し手を加えればできないかな?
2007-08-08 (水)
■ PEAR::Pager で getLinks() を使わずに済ませる
PEAR::Pager の Tips を1つ。
$links = $pager->getLinks(); $this->view->pager = $links['all'];
みたいな書き方をよく見かけるが、 getLinks() は値を返すまでに内部でいろいろと処理を行っている。 単純にナビゲーションリンクを表示するだけなら、
$this->view->pager = $pager->links;
のように Pager クラスの $links プロパティを直接参照すればよい。 この方がシンプルで高速。
2007-08-09 (木)
■ Radeon 搭載マシンで OpenGL のアプリが起動時エラー
最近 OS を Windows 2000 から Windows XP に入れ替えてから、 いくつかのアプリが起動時にエラーを出すようになって、 動かなくなってしまっていることに気が付いた。
いろいろ試してみると、どうも OpenGL を使うプログラムがひっかかっている気がする。 さらに調べると、Administrator で実行すれば問題なく起動することも分かった。
この辺をヒントに検索してみたところ、 どうもグラフィックスボードのドライバのバグらしく、 ドライバをバージョンダウンしたら直ったという報告が見つかった。 そこで、Catalyst 7.6 から 7.4 にバージョンダウンしてみたところ、 めでたく OpenGL のアプリを起動できるようになった。
ちなみに Catalyst 7.5 も試してみたがダメ。 最新の Catalyst 7.7 は試していないが、 ReleaseNote になにも書かれていないのでたぶんダメだと思う。
2007-08-12 (日)
■ tDiary に後日談プラグインをインストール
ずっと試したかった「後日談プラグイン」を導入してみた。 tDiary のサイトから プラグイン集(最新スナップショット) をダウンロードしてきて、その中にある my-sequel.rb というのをインストールした。 どう使えばいいのか分からなかったので使い方を調べてみたところ、 Wiki スタイルを使っている場合には、
[[昨日の日記|20070811#p01]]
のような書式で過去のエントリへのリンクを張ればいいらしい。 やってみると、
つづき: 2007-08-12 (日)
のようなリンクが過去の日記のところに自動的に現れた。 おぉ、これだけでいいのか、素晴らしい!
でもタイトルでなく日付が表示されるのか。 これだと、クリックするまでその内容が分からないねぇ。 そこで my-ex.rb プラグインもインストールして、 リンクのところにツールチップが表示されるようにした。 うん、これでだいぶ良くなった。
でも、インストールした後で気が付いたが、 ブログ内での内部リンクって今まであまりしてなかったな。 これからは意識して書くようにしよう。
2007-08-16 (木)
■ PukiWiki 用プラグイン shjs.inc.php Ver.1.0 を公開
MOONGIFT さんの記事 で、 SHJS (Syntax Highlighting in JavaScript) という構文ハイライト用のライブラリがあることを知った。 同種のライブラリと比べた時の特長はこんな感じ。
- 約40種類のテーマによって好みの色合いにできる
- 対応する言語が20種類以上と比較的多い
- 元のソースコード通りにコピペできる (google-code-prettify はこれができない)
- ライセンスが GPL
結構良さそうな気がしたので、 これを利用して構文ハイライトする PukiWiki 用プラグインを作ってみた。
上のページにテーマギャラリーも作ってみた。 ジョークとしか思えないテーマもあるが、 darkblue というテーマなんかは見やすくて良いと思う。
2007-08-17 (金)
■ tDiary で SHJS (Syntax Highlighting in JavaScript) を使って構文ハイライトする
昨日 に引き続き、今度は tDiary のシンタックスハイライトに SHJS (Syntax Highlighting in JavaScript) を使ってみた。 このブログでは別のライブラリを使って構文ハイライトさせるつもりだが、 せっかくなので手順を載せておく。 なお、tDiary 2.1.3 以降の Wiki スタイルでないと動かないはず。
index.rb のあるディレクトリで SHJS のアーカイブを展開し、 shjs というディレクトリ名にリネーム。
$ unzip shjs-0.4.2.zip $ mv shjs-0.4.2 shjs
hikidoc.rb の parse_pre メソッドを以下のように書き換えるかオーバーライドする。
class HikiDoc
def parse_pre( text )
ret = text
ret.gsub!( /^#{MULTI_PRE_OPEN_RE}[ \t]*(\w*)$(.*?)^#{MULTI_PRE_CLOSE_RE}$/m ) do |str|
begin
raise if $1.empty?
html = <<HTML
<pre class="sh_#{$1.downcase}">#{restore_pre( $2 )}</pre>
<script type="text/javascript" src="shjs/lang/sh_#{$1.downcase}.min.js"></script>
HTML
store_block( html )
rescue
"\n" + store_block( "<pre>%s</pre>" % restore_pre( $2 ) ) + "\n\n"
end
end
ret.gsub!( /(?:#{PRE_RE}.*\n?)+/ ) do |str|
str.chomp!
str.gsub!( PRE_RE, '' )
"\n" + store_block( "<pre>\n%s\n</pre>" % restore_pre( str ) ) + "\n\n"
end
ret
end
end
以下のコードを shjs.rb という名前で保存し、プラグインとして追加。 スタイルシートの部分は、好みに応じて shjs/css/sh_darkblus.css などに適当に書き換える。
add_header_proc do
<<-HTML
<link rel="stylesheet" type="text/css" href="shjs/sh_style.css" />
<script type="text/javascript" src="shjs/sh_main.min.js"></script>
<script type="text/javascript"><!--
if (window.addEventListener) {
window.addEventListener('load', sh_highlightDocument, false);
} else if (window.attachEvent) {
window.attachEvent('onload', sh_highlightDocument);
} else {
window.onload = sh_highlightDocument;
}
//--></script>
HTML
end
ここまでやったら、あとは、
<<< ruby …… ソースコード …… >>>
のように書けばOK。
2007-08-22 (水)
■ PHP のタイプヒンティングとオーバーライド
PHP 5 のタイプヒンティングって、どうも違和感を感じることが多い。 例えばこんなコード。
<?php
error_reporting(E_ALL|E_STRICT);
class withTypeHinting
{
public function __construct(array $params)
{
......
}
}
class withoutTypeHinting extends withTypeHinting
{
public function __construct($params)
{
......
}
}
$string = 'string';
$class = new withTypeHinting($string);
// $class = new withoutTypeHinting($string);
これを実行すると、
Catchable fatal error: Argument 1 passed to typeHinting::__construct() must be an array, string given, ...
のように fatal error になる。 ところが withTypeHinting クラスのサブクラスの withoutTypeHinting クラスを使うと、 何のエラーも起こらずに動いてしまう。
こうやってオーバーライドすることで、 タイプヒンティングが無効化できてしまうというのはいいんだろうか? サブクラスではどんな引数でも受け付けるように拡張しました、 という風に解釈すればいいのかなぁ?
2007-08-25 (土)
■ Zend Framework 用 Piece_Flow, Piece_Right コンポーネント Ver.0.6 を公開
Zend Framework から Piece_Flow や Piece_Right を使うためのコンポーネントをバージョンアップした。 変更点は以下の通り。
- Revulo_Controller_Dispatcher_Flow (Piece_Flow を用いた Dispatcher)
- MVC でモジュールを使用した場合に動かなかったのを修正
- アクションコントローラのディレクトリを自動設定するように変更
- フローの module, controller, action の指定がない場合はデフォルト値を用いるように変更
- preDispatch() メソッドが初回に実行されていなかったのを修正
- オブジェクトをセッションから復元するための autoload 用のコードを組み込み
- フロー制御を用いない通常の場合には Piece_Flow ライブラリを読み込まないように変更
- Revulo_Validate_Right (Piece_Right を用いた Validator & Filter)
- Piece_Right 1.7.0 で追加された getFieldNames() メソッドを用いるように変更
- addMessages() しても getErrors() に反映されていなかったのを修正
今回、Piece_Flow のコンポーネントに結構手を加えたが、 autoload 用のコードを自分で書かなくて済むようにしたので、 これで少しは使いやすくなったはず。
2007-08-28 (火)
■ Zend_Loader::loadClass() のバグ
Zend_Loader の不具合を見つけた。 以下の条件が組み合わさった場合に loadClass() メソッドが正常に機能しない。
- クラス名が Piece_Flow_Continuation のようにアンダースコアを含んでいる
- 第2引数の $dirs で追加の search path を(絶対パスで?)指定している
- 読み込みたいファイルは $dirs の下には存在せず、include_path の下にある
Zend Framework の Issue Tracker を検索したところ、
としてすでに報告されていたが、 修正がないまま放置されているので、原因と対策をここに書いてみる。
…と思ったが、Zend_Loader のコードを追っているうちに、 なぜこの不具合が起こるのかよく分からなくなってしまったので、 とりあえず対策だけ書いておく。
Zend_Loader::loadClass($class, $directory);
のように書いていた箇所を、
try {
Zend_Loader::loadClass($class);
} catch (Zend_Exception $e) {
Zend_Loader::loadClass($class, $directory);
}
のように書き換えると回避できるようだ。
実は、先日リリースした Piece_Flow コンポーネント Ver.0.6 がこのバグに引っかかっていた。 ログを見ると、まだ誰もダウンロードしていなかったようなので、 アーカイブを修正版に差し替えておいた。ふぅ。
2007-08-30 (木)
■ apt-line に CDN ミラーを指定してみる
Debian をインストールする時、 今までは apt-line にこんな風に Ring Server のミラーサーバを指定していた。
deb http://ring.airnet.ne.jp/pub/linux/debian/debian/ etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free
ただ、Ring Server のサーバは、 時々ディスクがあふれたり、急に廃止になってしまったり、どうも不安要素が多い気がする。 やはり ftp.jp.debian.org を指定する方がいいのかなと考えていたところ、 cdn.debian.or.jp 試験運用開始 のお知らせがあるのに気が付いた。 あぁ、そういえば、半年くらい前にこのアナウンスを見かけたのに、すっかり忘れていた。
- 比較的高速で安定したサーバだけラウンドロビンしている らしい
- 試験運用開始されてから半年くらいたつので、さすがにもう安定しているだろう
- Debian GNU/Linux スレッドテンプレ のページでも薦めている
結構良さげなので、せっかくだから利用してみようと思い、 /etc/apt/sources.list を以下のように変更した。
deb http://cdn.debian.or.jp/debian/ etch main contrib non-free deb http://security.debian.org/ etch/updates main contrib non-free
少し試してみたが、確かに結構速くて安定している感じがする。 問題なさそうなら、玄箱とか他の Debian マシンも全てこう設定することにしよう。

# sonots [プレビューか。プレビューは全然考えてませんでしたね。そこも追随させてもらおうかなぁ]
# revulo [どうぞどうぞ、どんどん取り込んで下さい。]