手嶋屋のブログとして書くのは久しぶりです。

前々から、手嶋屋にある蔵書を管理したいと思っていたうえに、
それを公開してしまっては？っと思い、ブクログで公開することになりました！

http://booklog.jp/users/tejimaya

ブクログ上の見た目の整理も、まだまだですし
本以外の怪しいものも混ざっていますが、ぜひ御覧ください。

日本時間の昨日（2009/12/01）、 OpenPNE3 で使っている symfony 1.2.10、 symfony 1.3.0、 symfony 1.4.0 のリリースがありました。そして今日、 なんと新しいアドベントカレンダーがはじまりました！（しかも、もう日本語でも読むことができます！）
この「アドベントカレンダー」というのは、 symfony 1.0 がリリースされた 2005 年の 12 月、そして symfony 1.2 がリリースされた 2008 年の 12 月におこなわれた、 12 月 1 日からクリスマスまでの間、チュートリアルを 1 日 1 章 symfony の公式ブログで公開していくという試みです。

さて、この新しいアドベントカレンダー、 「もっと知りたいsymfony(More with symfony)」 ですが、 1 日目の中程に僕の名前があるのに気がついた方はいらっしゃるでしょうか。

実は今回のアドベントカレンダーの翻訳では僕も参加しており、微力ながらプロジェクトに貢献をさせていただきました。
僕が翻訳を担当した章の公開はもう少し先の話になりますが、どの章をとっても symfony ユーザー垂涎ものの内容ばかりですので、毎日を楽しみにしていてください！

日本時間ではもう 12 月 1 日が終わってしまいましたが、 symfony はフランス製。まだまだ 2009 年の Symfony Day はこれからです。
というわけで、まだ symfony を触ったことがない！　という方も、 1.x の最後の LTS (長期サポートのバージョン) が出て、翻訳チームの方々の尽力により日本語のドキュメントもばっちり揃ったこの記念すべき Symfony Day をきっかけに、是非 symfony の世界に足を踏み入れてはいかがでしょうか。
（そして symfony に慣れてきたら、どうぞ OpenPNE 開発にも足を踏み入れてみてください！　お待ちしています！）

先日、 htmlspecialchars() の文字エンコーディングのチェックが甘く、これを利用して XSS に利用される危険があるということで日本人の岩本さんがパッチを提供しましたが、却下されてしまっていました。
（ただ現時点で、 id:moriyoshi さんにより Subversion 上の PHP では対応済みです。ありがとうございます）

この件について各所で議論がされていました。
大まかな流れについては、徳丸浩さんがブログでまとめておられます。
このエントリ中で、「このあたりから、一連の流れが広く知られるようになって、『もっと効果的な訴求方法があるよ』とか、海老原昂輔さんからもバグレポートが投稿されるなどの働きかけが始まっているようです。海老原さんのレポートには私のエントリも英訳されていて、本当にありがとうございます。」という風に述べられているように、僕もバグレポートの reject に対して抗議をしたり、その抗議のよりどころとして徳丸浩さんのエントリと id:t_komura のエントリを英訳し、レポートとしてまとめたりしました（お二方にはこの場を借りて厚く御礼申し上げます）（僕のひどい英語についてはとりあえず目を瞑ってください……）。

ここまで読んで、こんな疑問を思った方はいらっしゃるでしょうか。「なぜ手嶋屋というアプリ屋の人間が / OpenPNE の開発者が PHP 内部のことに口を出すのだろう」と。
僕個人はあまり PHP に愛着を持っているわけではありませんし、文字エンコーディングについて精通しているわけでもありません。ただ、僕は、ひとりの OSS 開発者としてこの問題を見過ごせなかったのです。

ちょっと長くなってしまいましたが、このエントリでは、「なぜ海老原がそんなことを」ということから「OSS を育てるには？」というところをお話ししたいと思っています。
もちろん一口に OSS といっても様々ですので、すべてのプロジェクトに当てはまるとは思っていませんが、みなさんが「自分ももっと OSS に貢献してみよう」と思うきっかけになれば幸いです。

僕は 2005 年 12 月、 17 歳の時から手嶋屋で OpenPNE プロジェクトに携わってきました。まだまだ未熟者ではありますが、 OSS 開発の素晴らしさや辛さを身をもって知り、 現在では OpenPNE の lead として毎日できるだけ多くの時間を OpenPNE を発展させるために注いでいます。

僕は日本大学芸術学部演劇学科を中退し、現職に就いています。細々と演劇をやってきた僕が最近思うのが、「ああ、 OSS と演劇ってすごく似ているな」ということです。
演劇の三大要素として「脚本」（もしくは「舞台」）、「役者」、「観客」というものがあります。 OSS でも、「ソフトウェア」、「開発者」はもちろんのこと、「ユーザ」の存在が重要だと思っています。

観客がいない芝居は存在しないのと同じです。観客を意識してこそ受け入れられる芝居作りができます。演劇は「今、ここに」の芸術で、何度同じ題目の芝居をやってもまったく同じ作品になるということはなく、その上演の観客のリアクションや会場の雰囲気、役者やスタッフのモチベーションや脚本への理解度など様々な要素によって大きく変化していきます。
これを OSS に置き換えて読んでみてください。なんとなく似ているなという気がしません？

OSS を支えるもっとも大きな力となっているのは開発者ではありません。ユーザです。
たとえば、 OpenPNE3 からは国際化対応が可能になったものの、実際はそれを希求するユーザが少なかったために優先度が下がっていました。ところが先ほど、台湾の Finjon Kiang さんから質問を受けチャットでお話しさせていただいたことをきっかけに、海老原が重い腰を上げて まずは第一歩として日曜日までに英語のドキュメントを揃える約束をしました。また、彼からフィードバックを受け、非日本語圏ユーザの対応を進める考えを持っています。彼から相談を受けなければ僕は現時点で行動することはなかったでしょう。ユーザの力というのはそれほど重要のものなのです。

ただ、 Finjon さんにはお会いしたことがあったり、たまたま僕の仕事が一段落したところで親切に対応する余裕があった、ということで前述の件はあくまでうまくいった例に過ぎません。実際はそんなに簡単に行かないこともあると思います。今回の htmlspecialchars() の件のように。

OSS 開発者も一人の人間ですから、認識が甘かったり視野が狭かったり思い込みが激しかったり体調が悪かったりなどあると思います。たとえば僕にはアラビア語のように右から左に読む言語についての知識が皆無ですし、アラビア語圏の人々に関する理解もまったくありません。そんななかで「OpenPNE をアラビア語に対応してくれ」と言われても渋ってしまうでしょう。しかし、たとえば、「アラビア語に対応するにはこんなビューの設計じゃダメだ、こうしなくては」と提案をもらったり、「エジプトでは SNS のようなコミュニティサイトが強く求められているのだ」というような要望をもらい続ければ、やはり人間ですから、「ああ、なんとかしなくてはな」と動き出すに違いありません。たとえそうならなかったとしても、公開の場で「この海老原というリードデベロッパーは頭の固い奴でアラビア語の一つもロクに対応してくれない卑劣な人間だ。なんとかしてくれ」と他の開発者やユーザに泣きつけば、僕がひどいバッシングを受けてしぶしぶ対応するか、もしくは他の意欲的な人が対応を進めてくれるかもしれません。
ただ、最初の要望の段階で「ああやっぱりアラビア語なんかには対応してくれないのか」と諦めてしまっては、そこで終わりです。たぶん僕も「ああその程度の熱意だったのね」と感じで別のバグや要望に取りかかって忘れ去ってしまうことでしょう。これは、ソフトウェアを使いたいユーザにとっても、ソフトウェアを使ってもらいたい開発者にとっても、お互いに損でしかありません。

僕は今回、htmlspecialchars() の問題を遠巻きに見ていましたが、今回パッチを提供された岩本隆史さんが諦めそうになっていたことを秋元さんのエントリで知り、とても辛い気持ちになりました。同じく OSS にかかわる人間として、 jani さんの対応はひどいなと思うのと同時に、 reject した彼の気持ちもわかるのです。 PHP のバグレポートの量やバグの複雑さといったら、とても OpenPNE の比ではないでしょう。そんななか PHP を進化させるためにバグレポートをトリアージしていく労力といったら、察するにあまりあるほどです。そこで一つのチケットを誤ってぞんざいに処理してしまったとしたら、それは非難されて当然とはいえ仕方がないことだともいえます。
一方で、岩本さんの辛さもわかるのです。僕もいくつかのプロジェクトにユーザとして英語でバグレポートを書いたりパッチを提供したりしていますが、そのうちのいくつかは通りいくつかは reject されました。せっかく慣れない英語で時間をかけてレポートを書き上げたのに理不尽な理由で reject されたときや、「もう 1 ヶ月前にその問題は自分が見つけたから待っててよ」などと言われた日には、ついふて腐れて反論する気も失せてしまいますよね。

ただ、ここまできてこの問題がそのままになってしまうのは、先ほども申し上げたとおり両者にとってデメリットです。僕は OSS にユーザと開発者の両方の立場で携わるものとして、一つのコントリビュートが死んでしまうのを見るのは耐えられなかったのです。そして、なんとかこの問題をあらゆる人が納得のいく結末まで持って行きたい、というその一心で、下手でめちゃくちゃな英語ですが ML に抗議をし、参考になる日本語のエントリを超訳で英訳するという行動を起こすに至ったのです。

秋元さんはかなりヘビーなところまで要求されていましたが、幸運にも本件はすぐに多くの人々から注目を浴び、多くの人が行動を起こし、ついに Subversion にコミットされるに至りました。
しかしこれはあくまでたまたまこれが注目を浴びたからであって、運が悪ければ、場合によっては秋元さんが挙げておられるような手段をいくらでも用いて、熱意を持って根気強く、対応されるまで努力し続ける必要があったとしてもおかしくありません。

OSS は言うなれば、「ユーザ参加型ソフトウェア」です。
ユーザは質のいいアプリケーションをほとんど自由に使うことができるようになると同時に、「品質向上のためには自分もユーザとして行動しなければならない」という責務を負います（もちろん質に満足していればその必要はないです）。
本当にソフトウェアをよくしたいのであれば、たとえ開発者がダメな人間ばかりであったとしても、行動するべきです。今回岩本さんをはじめとする多くの人々がそうしたように。

ということで、みなさん、普段使っている OSS に対して不満はありませんか？　もしあれば、解決するために行動してみませんか？　みなさんは既にユーザとしてソフトウェアをよくする切符を持っているわけで、それを使わないのはもったいないと思います。気が向いたときにでも是非やってみてください。 OSS の成長に貢献するのは、きっと想像以上に面白いはずですよ。
（もし不満のある OSS がないという方は、まだ発展途上の OpenPNE3 のユーザになってみてください。きっとやりがいがあるんじゃないかと思います）

OpenPNE プロジェクトで必要になったので、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書いてみました。
gist にコードをあげたので、是非ご自分の clone の .git/hooks/commit-msg 向けに変更して使ってみてください。
（僕はあまりシェルスクリプトを書き慣れてはいないので、指摘などもお待ちしています）

これを使うことで、たとえばコミットメッセージを含まないメッセージを記述した場合、エラーとなってコミットできないようになります。

また、 curl が実行可能な場合、 http://redmine.openpne.jp/ から Issue のタイトルを取得して表示させます。もし間違えた Issue を指定した場合でも、 git commit –amend ですぐにコミットを訂正することができます。

OpenPNE プロジェクトや手嶋屋での開発のように、チケットや Issue に強く依った開発をしている場合、コミット毎に Issue ID を強制することはかなり有効に働くはずです。是非活用してみてください。

本日、 Symfony Components に Symfony Templating が追加されました。

Symfony Components というのは Symfony 2 の構成要素となるライブラリ群のことですが、これらのライブラリは Symfony 2 とは関係なく独立して使用することができます。公開当初からドキュメントが完全に揃っていたり、ユニットテストのカバレッジが 100 % と謳われているなど、 symfony 以外で利用する場合でも魅力的なのではないでしょうか。

個人的にこのコンポーネントには Symfony2 に関するプレゼンテーション が公開されたときから注目していました。

Symfony Templating はいくつかの機能を備えています。ヘルパーはもちろん、テンプレートの継承や、ファイルだけでなくデータベース、メモリからのテンプレートの読み込みを可能にする機構（デフォルトはファイルのみ）、Smarty などの複数のパーサの利用を可能にする機構（デフォルトは PHP のみ）などです。
※かなりおおざっぱに紹介しているので、詳細は ドキュメント を参考にしてください。

管理画面からテンプレートの設定などをおこなう OpenPNE のようなソフトウェアにとって、複数のあるストレージやパーサを利用できるというのは非常に魅力的です。

ということでさっそく symfony 1.3 で Symfony Templating を使ってみたので紹介してみます。

※symfony ユーザとして世界ではじめて Symfony Templating を使う、というのを目指してみましたが、実のところどうだったんでしょう……

試してみたときのコード

試してみたときのコードを GitHub で公開しています。
http://github.com/ebihara/examine-template/tree/master

たいしたものではないですが clone や fork や pull リクエストはご自由にどうぞ！

symfony で使う手順

プロジェクトなどの生成

プロジェクト、アプリケーション、モジュールを生成してください。

Symfony Templating の追加

lib/vendor 以下に Symfony Templating を追加してください。

$ svn co http://svn.symfony-project.com/components/templating/trunk/lib/ lib/vendor/SymfonyTemplating

sfTemplatingComponentView.class.php の追加

lib/view 以下に拙作の sfTemplatingComponentView.class.php を追加してください

$ curl http://github.com/ebihara/examine-template/raw/master/lib/view/sfTemplatingComponentView.class.php > lib/view/sfTemplatingComponentView.class.php

オートローダーの設定

Symfony Templating 内のクラスがオートロードされるようにします。

config/ProjectConfiguration.class.php を以下のように変更してください。
http://github.com/ebihara/examine-template/commit/a2bf730058cd1fc58c1058b3f676b3e4b8422eba

View で Symfony Templating を使うように変更する

http://github.com/ebihara/examine-template/commit/62ce58a3a653ae390374e2f1b882c1e06f1ff992 の通りにやれば OK だと思います。以下にかみ砕いて説明します。

まず、ビュークラスとして拙作の sfTemplatingComponentView を使用するようにモジュールの module.yml に設定を記述します。

default:
  view_class: sfTemplatingComponent

また、アプリケーションの layout.php を、 Symfony Templating 向けに書き換えます。
layout.php で $sf_content を出力しているところを、 $this->get(‘content’) の返り値を出力するように変更します。

<?php echo $this->get('content') ?>

テンプレートでは、先ほどの layout.php を継承するために記述を加えます。

<?php $this->extend('layout.php') ?>

これで晴れて Symfony Templating が使えるようになるはずです！

sfTemplatingComponentView でいろいろやっているので、アクションからアサインされた変数を使用したり、ヘルパー関数を呼んだり、ということもいままで通りできます。

それからどうするの？

ここまででとりあえず Symfony Templating が手軽に使えるようになったと思います。

Symfony Templating の使用方法については ドキュメント に詳細な解説があるのでそちらを参考にしてください。

また時間があるときに、 Symfony Templating 自体の具体的な活用方法について紹介していければと思います！

まだまだ、改善の余地がありますが（特に認可画面）、
興味のある方は是非ともいろいろ実験してみてください。

今日、社内勉強会で、『symfony 開発見学ツアー+symfony 1.3 ってなんなんだー』というタイトルで発表したので、その資料を公開します。

弊社開発部はプログラマでないスタッフも多いので、前半はそういったスタッフ向けに、後半はバリバリに symfony 1.2 で開発をしているスタッフ向けにという二部構成で発表をおこないました。

OpenPNE 開発の中心となっている身として、 symfony の開発体制などから学ぶところはとても大きいです。他のスタッフもそういった視点でも symfony を見るきっかけになったようで、 発表者としてはとても嬉しい結果となりました。

開発者としてはやはり symfony 1.3 の痒いところに手が届く機能改善はかなり魅力的で、早くも symfony 1.3 使いたい病にかかってしまったスタッフが現れて、これも発表者としては嬉しい限りです。これからも引き続き symfony 1.3 に注目していきたいと思います。

みなさんも是非 symfony 1.3 の動向を見守ってみませんか？

今日、社内勉強会で、『OAuthで気持ちのいいアクセス制御を』というタイトルで発表したので、その資料を公開します。

発表中に出てくる、「うべったー（http://co3k.org/twitter/）」のソースコードは gist 上で公開しているので（突貫すぎてクオリティは高くありませんが）ご興味のある方はご覧いただけると嬉しいです。

手嶋屋の開発部では、週2回、社内MTGルームで勉強会をおこなっています。
今日、『PHP5.3ってなんなんだー』というタイトルで発表したので、その資料を公開します。

ちなみに、今回主に参考にしたのが PHP 5.3 upgrading notes です。こちらもあわせてご覧ください。

PHP5.3、もう楽しみで仕方がないです！　さっそくRC版で Phar アーカイブの作成など試してみようと思います。

5/15 (金) に開催されたsymfony勉強会/懇親会にて、
『ルーティングを使ってシンプルなアプリケーション開発を』
という発表をしてきました。

発表資料は以下になりますので、興味のある方は是非ご覧ください！

symfony 1.2 が出たばかりの頃ならともかく、いまこのネタをやるにはちょっと鮮度が落ちすぎているのではないか……と心配だったのですが、
聞いてみると意外に好評だったようで、これはこれでよかったのかな、と思います。
自分としてはもっと突っ込んだ話をしていきたかったので
それなりに悔いは残っていますが、また発表の機会があればそこで挽回したいです。

ともあれ、会場提供してくださった株式会社ディノ様、進行をしてくださった月宮さん、
つたないプレゼンを最後までお聴きいただいた参加者のみなさん、本当にありがとうございました！

※懇親会にも参加したのでそのときの様子もお伝えしたいのですが、
同行していた國忠さんがカメラでなにやら色々撮っていた気がするので、
その写真を入手して改めてエントリを書きたいと思います。もしくは國忠さんが書いてくれると思います。