Developの最近のブログ記事

うちの Blog で利用している Movable Type は SQLite でデータ保存を行っていたのですが、どうもその SQLite データファイルが、利用しているホスティングであるさくらサーバの容量に対して到底無視できない割合（1/4）を利用しているということが判明。事実、容量の空きが非常に苦しいものとなってきていました。
その一方、さくらでは別途 MySQL も用意されており、ユーザは www 用サーバとは別に準備されたいくつかの MySQL サーバのうちの1つを選択し利用できるというサービス体系になっています。

そんな利用状況なさくらサービス、ひょっとすると使用可能なホスティングデータ量ってば、利用可能なサーバ容量の範囲とは別でないかという甘い考えが思いついたことはさておき、そもそも SQLite よりも MySQL サーバを利用するほうが保持するデータ容量は少なくなるであろうという考えの元、SQLite から MySQL へデータ移行することにしました。

その際、当方の SQLite におけるデータ構造や SQL 内容の理解がないので、1つ1つ確認しながら出来るよう、大よそを手動で事を進めていきました。今回のケースは Movable Type におけるお話ですが、他のものにもある程度流用できるのではないでしょうか。なおデータベース、および SQL についての若干ながらの知識が必要になるかもしれません。（SQL エラーが発生した場合に対応できるとか。）

0. 環境

参考までに、今回の環境は以下のとおり。
なお作業はオーソドックスにすべて CLI ベースのクライアントで進めました。

* MySQL 4.0.27
* SQLite 3.3.17
* Movable Type 4.0

1. Movable Typeのデータスキーマを MySQL 側に作成

まず MySQL 上に Movable Type のデータが格納できるよう、スキーマを作成します。
MT の設定ファイル（mt-config.cgi）内に記述されたデータベース接続設定を SQLite から MySQL のものへ変更し保存します。MT はかつて SQLite 環境で動いていたもので問題ありません。むしろこのまま MySQL へ移行しようとするので、へたに新しい MT の管理ページを作成する必要はありません。

続けて MT の管理ページへアクセスします。すると MT は MySQL 上に MT 用データが存在しないため、新規作成を行おうとしますので、これを進めていきます。MTユーザ登録などもあわせて行う流れとなりますが、内容を覚えておく必要はありません。

作成が完了した後、MySQL クライアントを使って、MT 用テーブルのデータを全て消去します。MT 用テーブルは、テーブル名の先頭すべてに「mt_」という接頭辞がついているものです。
テーブルの削除ではなく、データの削除であることに注意しましょう。データ削除コマンドは「truncate テーブル名」です。またその他のテーブルデータも消えぬことのないように…。

これで MySQL 側の受け口ができました。

2. SQLite のデータダンプ

続いて SQLite データをダンプします。

SQLite データは1つのファイルにまとめられている状態となっています。sqlite のコマンドツールはこのデータファイルを指定して実行する仕組みとなっています。またデータダンプは、sqlite の「.dump」コマンドで行います。たとえば SQLite データファイル example.db に対してのデータダンプは、CLI より以下のように実行します。

SQLite データファイルの指定、および sqlite コマンドの違いに気をつけましょう。（さくらの場合、「sqlite3」コマンドでした。）

このコマンドの実行で、sqlite.dump.sql というテキストベースの SQL データが出来ました。

3. SQL データを MySQL 向けに編集

SQLite のダンプデータは、SQL 文によるデータベースの情報や操作が記載されています。
SQL は色々なデータベースで利用されているものですが、今回ダンプした直後の内容では一部 MySQL で利用できないものが含まれているので、これを編集します。

* 一行目の「BEGIN TRANSACTION;」を削除
* 最終行の「COMMIT;」を削除
* その直前の「CREATE INDEX～」行をすべて削除

まず以上のことを行うことで、データ内は「CREATE TABLE～」と「INSERT INTO～」のみのものとなります。

本来ならば、ここから「CREATE TABLE～」のSQLもすべて削除し「INSERT INTO～」のみにすることで MySQL への投入準備が整うのですが、私の場合はここから「INSERT INTO～」文を編集する必要がありました。このままデータを INSERT してしまうと、MySQL 上では目的のデータ構造とは異なるものになろうとしていたからです。

例えば、ダンプデータ内の CREATE TABLE 文が

というものに対し、実際のこのテーブルへの INSERT 文は

となっていたとします。データベースに対して CREATE TABLE を行った後にこの INSERT を実行すると、以下のようなレコードができます。

mt_placement テーブル
---------------------
placement_id = 4
placement_blog_id = 2
placement_category_id = 2
placement_entry_id = 4
placement_is_primary = 1

一方、既に MySQL 上で準備されている mt_placement テーブルは、先ほどの CREATE TABLE のものと同じとは限りません。同じテーブル内容なものの、カラム順が異なるケースが実際にありました。（以下は一例）

この場合、同じ INSERT 文を行った mt_placement テーブルはこうなります。

mt_placement テーブル
---------------------
placement_id = 4
placement_entry_id = 2
placement_blog_id = 2
placement_category_id = 4
placement_is_primary = 1

カラム名を指定した INSERT 文ではないため、テーブル定義を行った順に INSERT が行われてしまい、結果違うレコードに仕上がってしまいます。

これを回避すべく、ダンプデータ内に記述されている CREATE TABLE 文のカラム順序どおりに、INSERT 文を編集していくのです。（説明長い！）

先ほどのこれは、

こうします。

（ついでにテーブル名のダブルクオートも排除。なお複数行でなくても一行でOK。）

全ての INSERT 文において、対応するテーブルの CREATE TABLE 文で示されているカラム順に従った形で INSERT 文を書き換えていきます。

INSERT 文のすべてを書き換え終わった後に、CREATE TABLE 文をすべて削除します。
　

4. MySQL へデータを投入

編集後のファイルを MySQL へ投入します。
例えば MySQL のデータベース「my_database」に対して投入する状況において、3. のセクションで sqlite.dump.sql ファイルを編集後 mysql.import.sql として保存したのであれば、以下のようなコマンドを実行します。

必要に応じて -u, -p などのオプションをつけて、SQL が正しく実行できるようにしましょう。
またエラーが発生した場合は原因を良く確かめて import ファイルを編集し、truncate でもう一度リセットした上で再投入しましょう。

5. Movable Type 管理へアクセス

投入後再び Web で MT 管理ページへアクセスします。SQLite 環境で稼動していたものと同じものが参照、利用できるはずです。

第3弾の今回で最後になります。今回は、ステートフルWebアプリケーションで戻るボタンを利用するための方法、および戻るボタンの利用是非について紹介していきます。

(7) ステートフルWebアプリケーションで戻るボタンを機能させる

前述したとおり、ステートフルなWebアプリケーションではブラウザ機能の戻るボタンによる再描画に対しての振る舞いを簡単に抑制することが出来ます。通常は状態の遷移を行うための指示（以下イベント）を規定していく形でフローを構築するため、結果的に戻るボタンは機能しなくなります。

この戻るボタンを機能させるにはどうすればよいか。PCブラウザの場合、戻るボタンを押すと1つ前のサーバリクエストが発生します。このことより、通常の遷移と同じように戻るボタンを押すことで発生する遷移イベントを予め想定して設定しておけば良いのです。

図7. 3画面間を遷移するサービス

図7は、再び3画面を遷移するサービス例です。このサービスのステートフルモデルによる構築で、戻るボタンを有効化するための遷移イベントを追加すると、図8のようになります。

図8. 3画面間遷移サービスに戻るボタンを有効化

図中の赤矢印部分は、全く同じリクエスト内容であることを示しています。PageCが表示されている状態で戻るボタンが押されると、1つ前のリクエスト、つまりPageBが表示されるための「toB」が実施されます。PageCからPageBへ戻るためには、この「toB」イベントをPageC自身も受け取るよう準備しておけば、正しく戻るボタンによる状態遷移が出来るようになります。
なお、図8ではPageBからPageAへ戻るためのイベントが指定されていませんが、これはPageBで戻るボタンを押すことで実行されるリクエストが、このステートフルWebアプリケーションが開始されるためのリクエスト（ステートフルモデルから見ればイベント無しにあたる）で、厳密にはリスタートのような扱いとなりますので、PageBからPageAへは自然と戻っているように動作します。

ただし、全ての状態遷移について戻るボタンを有効にする必要はありません。図9の例を見てください。

図9. 会員登録アプリケーション例

図9は、良くあるサービス利用に伴う会員登録を行うためのアプリケーションフローの例です。説明文を表示した後、入力フォーム、確認画面、登録完了画面の4画面を遷移します。それぞれの遷移に伴う位置づけとして、登録開始（start）、入力項目の確認/妥当性チェック（validate）、情報確定と登録（register）です。この例において戻るボタンを有効化する場合は、以下の図10のようにすべきです。

図10. 会員登録フローに戻るボタンを有効化

先ほどと同じように、戻るボタンに伴う再リクエストで共通化している箇所は赤矢印になっています。ここでは、確認画面から入力フォームへの戻り（つまり再入力）にあたる逆遷移は戻るボタンの有効化で可能としているのに対し、完了画面から確認画面への逆遷移は設けていません。これは登録完了後戻るボタンにより逆遷移→確認画面から再び再登録 といった二重投稿を禁止するためです。「会員登録を行う」という目的のため動作させていたフローとして無事登録が終了した以上、画面を戻す必要はありません。もし仮に確認画面で見ていた入力情報をまた見せたいのであれば、この完了画面で再び表示すればよいでしょう。

なお、当然ながら「再読み込み」ボタンによる再リクエストの二重投稿も発生しません。これはステートフルモデル内で、完了ページが regisrer を受け取って何かしらの処理をするような設定を一切行っていないからです。完了ページを表示し最終遷移まで到達した今、このステートにおいてこれ以上の遷移およびそれに伴う処理が起きることは2度とありません。ステートレスなWebアプリケーションで良くある Token などによる二重投稿チェックなどは必要なく、ステートフルWebアプリケーションの利点の1つだと言えます。

このように戻るボタンを有効化するポイントは、そのアプリケーション毎においてケースバイケースで考える必要がありそうです。おおよそ、データベースへの挿入・変更処理が伴うポイントやメール送信といった、「一度だけ実施すればそれで十分」である処理に伴う状態遷移において考えることになるでしょうが、やはり現在のところベストプラクティスは出ていません。

(8) au 端末における戻るボタンの利用

過去2回にて紹介したとおり、au 端末における戻るボタンはPCおよび他の携帯端末とは異なり、ページキャッシュの再表示を行うよう動作します。
しかし au 端末は、戻るボタンそのものの動作（ボタンを押すとどうなるか）を制御することの出来る仕様をあわせて備えています。これは他の携帯端末にはない機能で、au EZWeb のコンテンツを構成する WML を記述することでこれを実現します。この事については以前あげたエントリの通りで、私も参加しているステートフルなWebアプリケーションフレームワーク Piece Framework の HOWTO にも記載されるようになりました。

Piece Frameworkを使ったEZWeb向けWebサイトの遷移制御

Piece_Unity HOWTO
EZweb端末の強制的なブラウザキャッシュに適切に対処する

前述した (7) のように、戻るボタンによって状態遷移イベントを発生させるよう振る舞う動作を au 端末向けにも実装するには、描写ページ内で WML を記述します。例えば図8の遷移を au 端末で実現させる場合、PageCの body コンテンツ内の末尾にリスト1のようなコードを埋め込みます。

リスト1. 図8の遷移を実現するための PageC HTML ソース (抜粋)

また、図10の遷移を au 端末で動作させる場合、完了画面コンテンツ内ではリスト2のようなコードを埋め込むことで、戻るボタンを完全に機能しないようすることができます。

リスト2. 図10の完了画面を実現するための HTML ソース (抜粋)

これで au 端末向けにおいても、PC や他の携帯端末と同じ動作となるようになります。
このように挙動の異なる場合においても、ちょっとした＋αのコードを追加する形でWebアプリケーションの仕様・挙動が共通となるよう構築するよう心がけるほうが、結果的に開発者およびサポート担当者の負担は軽くなり、最終的には還元される形でユーザにも使いやすいアプリケーションとなっていくのではないでしょうか。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

前回のエントリの第2弾で、続きのお話になります。

今回はステートフルWebアプリケーションとしてシステム構築を行った場合、その基本的な動作のお話（おさらい）、戻るボタンに伴う動作、そして携帯端末におけるシステム利用と戻るボタンによる動作の違いについて、図による解説を含めて紹介します。

(4) ステートフルWebアプリケーションの基本動作

例えば以下の図1のようなサービスがあったとしましょう。

図1. 3画面間を遷移するサービス

PageA, PageB, PageC という3画面があり、PageAからPageB、そしてPageBからPageCという画面遷移を行うサービスであるとします。
ステートフルなシステムとして構築する場合は、PageAをスタート地点として、PageAからPageBへ行きたいという「toB」指示が出るとPageBへ遷移、同じくPageBにいる状態で「toC」指示が出るとPageCへ遷移するという意味になります。ステートフルですので、必ずPageAから始まることを限定しています。またPageAにいる状態で「toC」と言われても遷移することもありません。
このサービスを実際に実行した例が図2になります。

図2. 3画面遷移を実行した例

緑色のマークはこのサービスを利用するユーザ（クライアント）です。PageAから始まり、「toB」指示と共にPageB、その後「toC」指示と共にPageCへ遷移していることを示しています。PageA〜PageCまでを閲覧しているページ、緑色マークは現在閲覧中の場所の目印、黄色のふきだしはGET/POSTリクエストで、赤矢印はそれに伴う画面描写の切り替え（リフレッシュ）と観るとさらに分かりやすいかもしれません。

(5) 戻るボタン使用による状態の非遷移

上記図1の3画面遷移サービスに対しブラウザの「戻る」ボタンを使用するとどうなるでしょうか。

前述したように、あるページを表示している状態において想定していない遷移指示が出たとしても勝手に遷移するようなことはありません。通常は「意味のない指示」と判断し、その場の状態に留まろうとします。（ステートフルなWebアプリケーションを実現するためのライブラリおよびフレームワークの仕様に基づきます。）

例えば PageC まで遷移済みの状態から戻るボタンを押下した場合、ユーザは PageC の1つ前のページ、つまり PageB に戻ると想像することでしょうが、図3のように画面リフレッシュが行われたにも関わらずPageCが再描画されるという動きになります。

図3. 戻るボタンを押しても現ページが再描画される

(6) 携帯キャリア毎における戻るボタン押下と画面〜システム状態の認識ずれ

さて、この3画面遷移サービスを携帯端末で利用するとします。キャリア毎に携帯端末の仕様がありますが、基本的なWebアクセスのための通信機構はPCのものと何ら変わらない仕組みになっているため、PCと変わらないサービス内容を利用することができます。これは、戻るボタンに関する事柄も全く同じです。

前回にも紹介しましたが、Docomo, Softbank 端末の場合戻るボタンを押下すると1つ前に行ったサーバリクエストを改めて実施します。これはPCと同じ仕様のため、図3と全く同じ動きになります。
PCによる画面表示の情報量に比べ携帯端末は若干少ないため、「あれ、ひょっとすると画面が戻っていない？」と認識するまでに時間を要する可能性があるかもしれません。今まで当たり前のように利用していた戻るボタンがまさか効かないと考えることが出来ず、行動に対する応答内容のズレに混乱をきたす利用者も出るかもしれません。

au の場合はさらに悲惨なことになっています。前回のエントリの通り、auの戻るボタンはページキャッシュの再表示です。容赦なく前回ページをそのまま再表示しますので、図4のように完全に画面〜システム間の状態相違が発生します。

図4. auにおける画面〜システム間の状態相違

ユーザは戻るボタンでPageBに戻っているつもりですが、システムでは PageC にいることになっています。仮にこの遷移サービスが図5であったとしましょう。PageB からは PageC だけでなく、「toD」指示で PageD へ行ける遷移になっているとします。このようなサービスにおいて、au 端末で戻るボタンを駆使して画面遷移を行おうとすると、図6 のようになってしまいます。

図5. 画面間遷移するサービス その2

図6. ユーザにとって思いがけない画面遷移

PageC から戻るボタンで PageB に戻り、PageD へ行こうとします。画面上では PageB に戻ったことになっていますし、PageD へ遷移するための「toD」に相当するようなページリンクもあるでしょう。しかしPageB は「戻ったつもり」の扱いとなっており、PageD へ行こうとしても実際は PageC にいるわけですから、「PageC を再描画する」という動きとなります。ユーザにとっては「どうして！？」という動きに違いないでしょう。

このように、携帯キャリア毎にシステムそのものの挙動が異なることになっています。これらは統一した挙動となるよう、調整をかける必要があるでしょう。
またこれとは別に、戻るボタンそのものについてその取り扱いを考える必要があるでしょう。システムとして不具合が発生せぬよう制限を設けることは重要ですが、だからといってユーザビリティを損なうようなサービスにしてしまってはいけないということです。ということでもう少しだけ続きます。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

以前 Piece Framework で作る EZWeb 向けサイトの画面遷移のお話をあげましたがその結果「極めて一部な人達にのみ好評」だったため、その補足および、より詳細な情報・アプローチを含めたお話です。久々に技術的なお話をあげたと思えばこういう極めてニッチな事柄であるのが hatotech::kumatch です。

なお既にタイトルに 1 とつけているだけあって、少しだけ連続したエントリになります。

(1) 挙動の異なる「戻る」ボタン

現在日本国内では複数のキャリアがそれぞれの携帯端末仕様を展開し、それらに準ずる端末が発売されています。
ご存知のとおり各携帯端末にはWebサイトを閲覧する機能が備わっており、各キャリア向けの仕様に基づくサイトを閲覧できる専用のブラウザが組み込まれています。
携帯端末ブラウザはPCで利用するようなブラウザと同じようにページコンテンツを表示したり「ブックマーク」「再読込み」といった機能が準備されていますが、そのうちの前画面に戻るために利用される「戻る」ボタンの挙動がキャリアによって異なることになっています。以下にそのパターンを紹介します。
なお、今回の話に Willcom や eMobile の端末は含めないものとします。現在のところこの2キャリアについては携帯キャリア端末としての動作とは異なり PC となんら変わらず振舞うことができると考えることができるからです。

● 再リクエスト形式
Docomo、Softbank の2キャリアは「戻る」ボタンを押下すると、1つ前に行ったサーバへのリクエストそのものを改めて行います。このとき画面に表示される内容はこのリクエストに伴う結果によるもので、これは PC におけるブラウザ仕様と同じであると言えます。

● ページキャッシュ形式
au の端末で「戻る」ボタンを押下した場合、1つ前の画面で表示していた内容をそのまま再表示します。通常は事前にキャッシュしていた内容を表示し、サーバへのリクエストは行いません。

(2) ステートフルWebアプリケーション

Webアプリケーションはステートレスと呼ばれるバラバラな処理と描写を連続して実行することで目的を達成しています。そもそもWebアプリケーション自体、HTTP という「リクエスト−レスポンス」のセット間同士に一切の関連性がない細切れな通信プロトコルを利用して動作しているわけですが、そのWebアプリケーションはある程度決められたやり取りをもって動作していることがよくあります。例えばユーザ情報を入力した内容を使用して会員登録を行ったり、商品をカートに入れて決済を行い購入確定とするショップサイトなどとといった具合です。
これら一連の流れ（フロー）をもって1つの処理内容（アプリケーション）と捉え実装する方法を、ステートレスWebアプリケーションに対し「ステートフル」なWebアプリケーションと呼びます。

ステートフルなWebアプリケーション開発は、既存のステートレス指向なWebアプリケーション開発で常に頭を悩ませる以下の問題に対し、驚くべき単純な解を与えてくれます。

●セキュリティ対策
一連の流れをもって1つのアプリケーションと考えており、いきなり最後の処理 (例えばデータベース書き込み) だけを実施するようなリクエストは排除

●戻るボタン対策
画面遷移の内容（ルート）を完全に制御するため、ブラウザの戻るボタンを押されたとき（及びそれに相当する操作）の挙動まで管理可能

●マルチウィンドウ対策
各ウィンドウごとに状態を保持することが可能であり、セッション情報の混合が起きず管理が容易

ステートフルなWebアプリケーション開発を支援するいくつかのライブラリ、およびフレームワークが登場しています。しかしそれを利用する上で開発を行っていく設計基準、手法にベストプラクティスがないのが現状です。

(3) ステートフルな携帯サイト

ステートフルなアプローチで構築するWebサイトでは、(2)で記載したとおりの恩恵を受けることができます。しかしながら構築するものが携帯端末向けのサイトである場合、以下のような理由でステートフルなWebアプリケーション開発による旨みが減少するだけでなく、「余計なこと」を考える必要があります。

●シングルウィンドウ固定
現在のところ、携帯端末で利用されているブラウザ内で複数のウィンドウを開くような概念は一般的ではありません。一部端末ではマルチウィンドウに対応していたりもするようですが、フルブラウザ (PCサイト閲覧向け) であったりということで今回のような話とは別件になります。したがってマルチウィンドウ対策を考える必要は特にないでしょう。

●戻るボタンの挙動の違い
前述した(1)で示したとおり、携帯キャリアにより戻るボタンの動作が異なります。Docomo、Softbank に関しては PC と同じように考えることができますが、au は完全にページキャッシュによる再描画を行うことが可能であるため、これに対する対策を別途考える必要があります。

●戻るボタンそのものの考え方の違い
私自身あまり携帯端末をヘビィに使うユーザではありませんが（加えて Willcom 端末利用のため PC と同等のように扱う）、携帯端末を利用する場合中央四方キーの左もしくは左側ソフトキーなどを使ってページを戻る（来た道を戻る）ような利用方法がPCブラウザ以上にあるのではないでしょうか。
これはPCブラウザの場合、マウスによるポインタ機能が備わっているため、メニューなどのページ内リンクによる画面遷移が比較的容易であるのに対し、画面内に描写できる量が限られる携帯サイトでは「メニューから項目を選択」→「詳細表示」といった画面遷移が取られていることが多く、結果他項目へ移る際に1つ前のメニューへ戻るために戻るボタンが利用されるというという流れです。

携帯端末における戻るボタン殺してしまうと、PCブラウザ以上に操作感を損なうことなるだけでなく、場合によっては混乱を招く恐れもあるのではないかと推測しています。このあたりのより詳細なお話を予告として、次回に続きます。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

【PHP】フレームワークについて語るスレ5【総合】
http://pc10.2ch.net/test/read.cgi/php/1159579507/

833 名前：nobodyさん 投稿日：2007/01/29(月) 16:37 ID:???
おまいら CSRF 対策どうしてる?
やっぱりワンタイムチケット使ってるのかな?

フレームワークってGETでページ遷移、POSTで内容を取得みたいなことが多いけど
よくあるCSRF対策だとPOSTでページ遷移しろって書いてあるし

実装面倒だからWAF使おうかなと思ってたりするけど他の人はどうしている?
フレームワークにワンタイムチケットのクラスとかつっこんで使うのが主流なのだろうか

841 名前：nobodyさん 投稿日：2007/01/29(月) 19:44 ID:???
>>839
> まず、アプリケーションの作りとして、リクエスト1はGETよりもPOSTを用いる方が好ましい。
またそんな馬鹿なこと言ってると高木のおっさんに怒られるぞ？

842 名前：nobodyさん 投稿日：2007/01/29(月) 20:41 ID:???
そもそも高木のおっさんはPHPの利用はやめろと言っている

843 名前：nobodyさん 投稿日：2007/01/29(月) 21:03 ID:???
>>842
> そもそも高木のおっさんはPHPの利用はやめろと言っている
ワロタ

言ってるのか高木先生。
特定のPHP書籍を指して「脆弱本」と言いきったのはあるけれど。

CSRF 対策についてはやはりこちら。
http://takagi-hiromitsu.jp/diary/20060409.html
「ワンタイムトークン方式では全ては解決しない」解説が図解入りでされていると共に対策例、あと「hiddenパラメタは漏れやすいのか？」という解説が成されています。高木先生すごいや。

844 名前：nobodyさん 投稿日：2007/01/29(月) 21:04 ID:???
>>833
Pieceフレームワークを使えばすべて解決

845 名前：nobodyさん 投稿日：2007/01/29(月) 21:07 ID:???
>>844
お前頭良いな

タイミング良過ぎワロタ。

そんな Piece ですが、近々 View 関連のアップデートが行われた Piece_Unity 0.11.0 がリリースされることでしょう。わたくしの出した原案を元に Iteman がキレイに実装しとります。

今、Mason で動いている中規模レベルなサイトを PHP にリフレッシュしようとしてるんですけどね。

　必要な機能を trac ticket にあげて、
　コード読んで trac wiki にまとめて、
　PHP の Test Case 書いて、
　それが動くようなコードを書いて commit して、
　ticket を close する。

という作業をひたすら繰り返している行為がですね、もうめちゃくちゃ気持ちいいわけですよ。変態ですね。そろそろ頭がおかしくなってきたのかもしれませんが、自ら進んで、かつ好んでやっていますのでそっとしておいてください。

いっつも忘れるので書置き。

「%」が正規表現に関する Prefix なのかと思えば、実はそうじゃないという現実がアレだ。 (% u とかで upcase が走る。)