SPaiS

お久しぶりです。僕です。
連載：WordPress解体新書｜gihyo.jp … 技術評論社 という WordPress の運用面に関する連載を始めました。開発面に関する連載も今週開始予定です。
掘り下げる、というよりは積み上げていって WordPress を理解するような内容ですので長くなる予定です。
こういったところに連載を始めたからにはもうちんことかうんことか言っていられませんね。

名残惜しいですが一句詠みたいと思います。
玉袋に　全て隠れる　冬の朝

本当にありがとうございました。

四季報のような更新頻度になってしまいましたが、僕は元気です。

おかげさまで先日ようやく自社サイトを立ち上げました。wp.Vicuna の後継である wp.Vicuna 2.0 の開発バージョンもリリースできました。
spais.jp で個人的にリリースしてきたプラグインも、順次 spais.co.jp に管理を移譲していく予定です。

働けど働けど中々向上しない我が暮らしを少しでも向上させるため、引き続きこちらでのアウトプットは減少傾向を維持し続ける事が予測されます。
法人サイトと言っても僕一人の会社なので基本的には spais.co.jp でビジネス的視点のアウトプットを重ねて行く予定です。

こっちではどうしよう、お料理レシピとか書こうかな。俳句？詠む？詠んじゃう？

勃起せず　射精する也　三十男

お久しぶりです。
もうすっかり夏ですね。僕といえばバリ島で結婚式を挙げてきました。楽しかったです。
これのおかげで割りとハードな毎日を送っているためブログの更新などは余りできませんが、忘れないであげて下さい。

さて、著者の鈴木憲治様よりPHP逆引きレシピをご献本頂きました。ありがとうございます。

以下書評。

「直接的な関数の組み合わせでプログラムを”組み立てる”」という PHP のスタンスにおいて最も重要なのは「目的に応じた答えを知る事」であると言えます。そのような視点から見ると本書はこれ以上ないほどに”実践的”です。
目的に対する方法を引く事ができ、その方法に関連する他の方法に対してもインデクシングされているばかりか、PHP バージョンごとの差異やメジャーなレンタルサーバに依存する問題なども詳解されているため、本書とパソコンと「ウェブアプリを作りたい」という目的意識さえあれば作れてしまう程です。

それだけに留まらずセキュリティに関しての広範な対策方法や、PHP で書かれたオープンソースソフトウェアの基本的な利用法も解説されており、さらには PDF、画像、グラフなどの生成方法といった「PHP をベースとしたシステムの利用」についても言及されているため、これはもう「答えのフルコース」だと言えるでしょう。

しかしながら残念な点もいくつかあります。
@ によるエラー抑制に始まり、参照渡しを「混乱しやすいから」という乱暴な理由で推奨していなかったり === ではなく == での評価がほとんどだったりと、初心者向けだからこそ肌感覚で培って欲しい「PHP のだめなところ」に関する言及がとても少なく、本書だけで学べてしまうが故に、本書だけを参照してコーディングしていると早い段階で「あれ？なんでこうなるの？」と戸惑う場面に出くわすでしょう。
特に、セオリーとされている mb_strlen() や htmlspecialchars() に文字コードを渡す事が書かれていない点は大きな穴です。

しかし本書は数多く出版されている PHP 本の中でも「決定版」と言えるほど完成しており、PHP での開発を生業とする企業ならば新入社員用の教科書として必携の一冊であると言えるでしょう。

と、まとめるとこんな感じです。
折角なので残念なところの補足をいくつか。

@によるエラー抑制

これは大変まずい事です。自己満足的なプログラムならば良いとしても、割と実践的な事が書かれているだけにビジネス用途で作ったようなプログラムでこれを使ってはいけません。
@でエラー抑制すると遅くなるとか、そんな事はどうでもいいんです。エラー抑制する代わりにハンドリングすれば似たような負荷がかかる事が多いですから。それよりも「@でエラー抑制をしているとエラーが表示されなくなる」というところにこそ問題があります。殴られても痛くないみたいな。出さないのがいいものはエラーであってエラーメッセージではないんです。

もし@で抑制している箇所に起因するバグがあった場合、追いかけるのは結構面倒くさいです。
「いくつかあたりをつけて探してみたけどそれっぽいところはない。じゃあちょっと@消してみようか」みたいなのはバッチリ二度手間です。
そんな事するくらいなら最初から@で抑制するんじゃなくて条件式なりなんなりでエラーのハンドリングをするべきです。

=== じゃなくて == を多用している

これもよくありません。基本的に == を使うべきではありません。== で評価するくらいなら型キャストしてしまって if( (int) $a === 5 ) というように書いた方がマシです。これと同じ理由で if( $a ) と言うような評価もよくありません。== を使わないよう癖つけるくらいでちょうどいいと思います。
評価する変数の型によって結果が違う評価式なんてのは気難しい人に様子を伺うようなものです。逆に == でしか評価できないような実装はそもそも設計に問題があります。

mb_strlen() や htmlspecialchars() に文字コードを渡す事

よく「PHP の mbstring の設定はこうした方がいい」なんつって mbstring.internal_encoding = utf-8 みたいな事を書いているような人がいますが、これも合理的じゃありません。そもそもプログラムごとに文字コードが違うし、リクエストに含まれる文字の文字コードだってバラバラです。それなのに PHP の設定としてサーバソフトウェア側で文字コードを制御するのは考慮しなければいけない点を増やすだけで全く持って非効率的です。そもそも文字コードを扱うレイヤーじゃないです。
大体 web アプリを作るときにはアプリで扱う文字コードを決めて、その文字コード以外の文字コードで送られてきたリクエストははじくのが前提ですから、そのアプリで解釈すべき文字コードは(原則的には)1種類です。
htmlspecialchars() のシノニムで h() を作るのも今ではセオリーで本書にも書かれていますが、第二引数だけではなく第三引数まで書かないと意味がありません。

<?php
define( 'SITE_ENCODE', 'utf-8' );
h( $var ){
  return htmlspecialchars( $var, ENT_QUOTES, SITE_ENCODE );
}
?>

みたいな。

大体 utf-8 な文字を mb_strlen() 辺りで図ろうとしても文字コード指定してるか mbstring.internal_encoding で utf-8 が指定されていないと正しい結果を返しません。mbstring.internal_encoding は前述の通り文字コードを制御するようなレイヤーにある設定ではないので、消去法的に考えるとマルチバイト系の文字列関数にはきちんと文字コードも渡してあげるのがモアベターです。

でも結局は全部 PHP の設計に起因する問題なんですよね。
これらのつかみにくい設計に関するノウハウまで求めるのは酷かもしれませんが、web デザイナーが css ハックを必要とするようにこういった情報も必要なんじゃないんでしょうか。

ここらへんの情報が無い以外は本当に素晴らしい書籍です。
僕みたいに受託で開発やってるような人間はクライアントから「社内でエンジニアを育てたい」的なお話をよく聞きますが、本書はそこらへんのニーズをバッチシ抑えてます。
逆引きリファレンスですが関数依存の構成ではなくユースケースに依存しているため、明確な目的意識が無くてもノウハウの蓄積に役立つとも思います。

以上。

僕はウェブ制作に関する技術や知識の学習をほぼ全て独自の方法で行ってきました。
それ故他人にその方法をレクチャーし実践してみろとは中々言えませんが、その中でも「大体どんな人にも役に立つであろう学習法」と言うものがありますので、今日はその方法について僭越ながら書きたいと思います。

まず僕がなんの前知識も持たず、それこそ「HTML はウェブページを構成する言語」と言う程度の知識レベルでもってウェブサービスの受託開発を始め、対価を支払ってもらえるクオリティの作品を提供できるまでになった過程において最も重要な事はもちろん「どうやって効率よく問題を解決するか」と言う能力でした。

フェーズ1

「どれだけの事を知っているか」と言う質問は、ことインターネットの世界で仕事をしている身としてはナンセンスであると言わざるを得ません。
僕が知っている必要は無いんです。答えられない疑問にぶち当たったとき「どこをどう探せば答えが見つかるか」というノウハウと「得られた答えの信憑性」を適切に評価できる最低限の知識さえあればいいんです。ググレカスってのはこの事だったわけです。

とは言え多くの初学者はまず「どこをどう探せば答えが見つかるか」と言うノウハウが無いわけですから、自分の中に答えがない時点で「分からない」となってしまいます。質問系サービスで質問している人たちですね。
実生活に関わるような事であれば短絡的に人に聞くことは間違いではないと思いますが、これが技術的な内容であった場合には話が別です。
このように技術的な内容を質問してしまうような状態をとりあえずフェーズ1とします。別に意味はないんですけどね。

フェーズ2

このフェーズ1の人たちは言うなれば「手に漢字辞書を持ちつつ人に漢字の読みをたずねる」と言うような事をやっています。そもそも”手に漢字辞書を持っている”という認識がありません。まずは手に漢字辞書を持っている、要するに欲しい回答を手に握っていると言う前提を理解する必要があります。
これは最終的に肌感覚にまで高める必要があります。「自分の知らない事は探せる」のがほとんどの場合に適合する事実です。今の時点ではそうじゃないかもしれませんが、この感覚を常に持つ事によって次のフェーズに進む事が出来ます。

次のフェーズは「探し方が分からない」状態にある人です。「インターネットで検索すれば見つかるんだろうけど、どうやって探せばいいの？」というような感覚です。
ここまでくれば後もう少し。答えは簡単「問題を解決した気になったとき、それをアウトプットするにはどういった単語を使うか」と言う事を考えれば良いのです。
”問題の答え”が存在する前提に”問題”自体の存在が不可欠なわけですから、”問題の答え”を知りたければ”問題”自体をキーにして探せば良いのです。
つまり、今起きている問題に由来する普段見かけないエラーメッセージであるとか、状況を言葉にして検索してみましょう。

なんとなく「今起きている問題の原因」がつかめてきたのではないかと思います。つかめていない人は探り方が浅いだけだと思います。
「今自分が思いついたアイデアは既に誰かが思いついている」のと同じくらい「今自分が困っている状況は既に誰かが困っていた」のです。
その困った経験を先駆者が残していない可能性はありますが、日本語だけではなく英語圏にまで検索の手を伸ばすと大体見つかるはずです。
もしかするとフェーズ1の人が誰かに質問したページが見つかるかもしれません。諦めずにとことんまで探してみるときっと見つかるはずです。
仮に答えが見つからなかったとしても、答えをつかむための糸口は見つかるでしょう。

フェーズ3

さて、ここまでがフェーズ2なわけなのですが、ここからが本題。
「探せば答えか、答えに繋がる糸口が見つかる」と言う点について理解できたなら、今度はその検索性能を向上させましょう。
いくらインターネットで検索すれば見つかるからといって、できるならば手間を惜しみたいですし、何よりも問題の法則性から答えを探す作業自体を簡略化させないと実務的ではありません。自分が組んでいるプログラムにエラーがでたからといってそうそう1日も2日も答えを探す時間は無いはずです。
とは言え ML なんかに「教えて下さい」じゃ本来自分でハンドリングしなければならない開発時間の一部を善意の第三者に依存する事になりますので、ご自身のマネージメント自体も不安定なものとなってしまいます。これじゃ本末転倒ですね。

という事で僕がお勧めしたいのが「質問に答える側に立つ練習」です。問題とその解決手段という事象に関係しているのは”質問者”と”回答者”という単純な二者です。
「人の立場になって良く考えてみろ」とはよく言ったものですが、これがまさにそう。「質問に対して回答する立場を以って回答する力を身につける」即ち「問題を解決する能力を身に着ける」練習です。
あなたにとって ML で質問している人は自己の能力を向上させるための機会提供者です。僕自身 PHP という言語を通してウェブアプリケーションの開発や、ウェブサービスの運用をゼロから学んできました。その最初期にとった行動が「PHP-users の ML で質問に答える」と言うものです。PHP どころか所謂プログラム言語そのものにそれほど触れてこなかった人間が、いかに実務的とは言えその実務的な理解が全くない状況でウェブサービスを作らなければならないような状況においては背に腹はかえられません。とにかく「答える方が分かってる」と言う自明の理を頼りにひたすら質問に答えてました。
プログラムが動かないと言うのであれば同じ環境を作って再現して解決策を考えてみたり、モジュールが動かないという質問があれば PHP をソースからビルドしてみたり。こういったプロセスは「質問に答える」というモチベーションが根底にありますので、僕みたいに一人でやっている人間にとってはとても張りのある勉強法でもありました。

効果はてきめん。質問に対して答えを返す立場に立つ事で「問題を解決するアプローチの確立」どころか「問題を解決するために予め知っておかなければならない知識」や「問題の根本にあるインターネットの文化的、歴史的な構造と、その構造が影響するその他の問題」と言った”一つの事象に紐づく様々な要因”についての知識と、それらを関連付ける技術的なインデックスが皮膚感覚で培われていきました。
これが大体フェーズ3．次のフェーズ4が僕のいる位置なので、それ以降のフェーズはどんなもんなのかわかりませんが、とりあえずフェーズ4は「抽象的な表現や思想を技術的なアプローチで具体的にする」と言うものです。

フェーズ4

僕がフリーランスの時代から使っていた屋号は「SPaiS」といって Spice(スパイス)をもじったものです。クライアントが持ち込む様々なアイデアやビジネスプランに対して技術的な視点で「どのように実現していくか」をスパイスとして味付けしていく事が僕が自分に課した命題でした。
おかげさまで様々なクライアントとお話をさせて頂き、様々なビジネスプランやアイデアをウェブの世界に技術的なアプローチで昇華させることができ、昨年起業しました。
まあそんなことはどうでも良いのですが、問題に対する解決策を提供する力を高める事によって、本質的には問題でない「こういうアイデアをウェブでお金にするためにはどうしたらいい？」だとか「こういうビジネスプランがあるんだけどウェブで成功させるためにはどういった手順を踏めばいい？」と言うような質問に対して独創的な発想を邪魔する事のない広い知見と”物事を調べる力”で回答できるようになります。

これが出来れば世の中にたくさんいる「あんまりお金は出せないけどウェブサービスを運用してみたい」と言う企業とお話が出来るようになります。
もしくはあなたがこっそり考えているすばらしい企画やアイデアを実現できる力にもなります。
結局のところ一人でやればウェブサービスにかかるコストはあなた一人の人件費だけです。つまりほとんどが純益になるわけです。
そう考えると「自分ひとりでウェブサービスが開発できるならばそれだけで食っていける」とは思えませんか？ググレカスを究極的に昇華していくとこうなるのだと僕は思いますし、実際に今の僕がそういう状況です。

結果を知っている必要は無いんです。道具の使い方と先駆者の知識を手にする方法さえ理解していれば、それだけであなたの力は何倍にもなります。
「探したけど無かった」のではなく、見つけるのを諦めただけです。つまり「ググレカス」はあなたにとってのチャンスなのです。

さあググレカス！

僕は昨年起業し、基本的に今までお世話になったクライアントからのご紹介を経て新たなクライアントと出会っているわけなのですが、いかんせん組織に属してウェブに関する仕事をこなしてきた訳ではないのでバックボーンが薄っぺらいのが弱点だと自分では理解しています。つまり、IT ビジネスにおけるスタンダードな論理的思考が培われてこなかった点にコンプレックスを抱えているわけです。
そんなコンプレックスを”客観視”を通じてクリアにしていこうと言う気持ちと、ビジネス的な意味でコネクションを張れたらいいなと言う浅ましい気持ちを薄っぺらなかばんに詰めて昨日は PHP 勉強会に行ってきました。

会場に着くと自己紹介が始まったばかりで、もう大分席も埋まっていました。会社名だしてやってる事を話してしまうとそれだけでライトニングトークになってしまいそうだったのでここのブログのドメインと個人で受託開発してますと軽く挨拶をしました。懇親会ではどうかわかりませんが勉強会内で参加者同士の対話が無いのに自己紹介する合理的な理由が見つかりませんでした。他の参加者の方々の自己紹介はどちらかと言うと「所属企業＋業務内容＋興味のある事柄＋個人的に出力している事柄」と言ったような内容。若干セミナーっぽい雰囲気ですね。

僕の心構えが所謂”勉強会”対するものであったがためにこの辺りから違和感を感じてしまっていたのですが、PHP 勉強会は即ち”小さなセミナー”であると同時に、勉強会そのもののベクトルも聴衆ではなく発表者に対してのものであると結論付けるとこの違和感は消えました。
「40人を超える参加者が一つにテーマに対して同じレイヤーで議論するなんてめちゃくちゃだな」と参加前には期待ageだったわけですが、良くあるカンファレンスと規模だけの差だと理解したわけです。

さて、そんな違和感を覚えたとは言え、発表する方は発表する方なりの論理的思考に基づく判断と、その判断に対して得られる結果と支払う対価が存在しており、プログラムと言うものはすべからく「コストとメリット」のトレードオフだと僕は常々感じています。
プログラムを組んだ事がある人と、組んだ事がない人において一線を画すのもこの辺りの論理的判断力に由来していると考えています。
それだけにまるっきり一人で全部やってきた僕としては、そろそろ自分の論理的判断の客観的な評価が欲しくなるわけです。汚い話ですが他の人の思考プロセスとの対比で自分を見つめなおしたいと言う浅ましい気持ちなわけです。

gusagi さんの発表

そんな風に軽くがっついた状態で始まった勉強会、トップバッターは司会進行も勤められた gusagi さん。
真面目で真摯そうな方です。技術系の集まりであるはずですが、そこそこ大きなカンファレンスの司会進行よりもずっとスムーズでした。

テーマは「XOOPS CubeにCakePHPアプリを組み込んでみた」
gusagi さんはしきりに「グダグダですいません」と申し訳なさそうにされていましたが、これはご自身のプレッシャーを聴衆に対するバイアスに変換しているだけなので余り感心しませんでした。
映画本編を見る前に「余り面白くないかもしれませんが」と前置きされると観客への映り方も違うはずです。

発表の内容は XOOPS Cube という CMS のプラグインとして CakePHP で作ったプログラムを動作させる、と言う目的に対するアプローチ解説だったわけですが・・・
そもそもからして XOOPS Cube 上で CakePHP を動作させるための合理的理由と言う前提が説明されていない状況ですので「Windows で Mac のソフトを動かすためには」と言うような解説を受けているのと感覚的に大差ありませんでした。結局のところ「CakePHP のブートストラップを XOOPS Cube に依存させるんだよ」と言うのが話の大筋でしたが、フレームワークにしろ CMS にしろブートストラップ型のプラットフォームを混在させるには当たり前の話です。
逆に「なぜ XOOPS Cube と CakePHP を混在させる上で発生する管理コストの増大を加味しても混在させるというアプローチを取るにいたったか」と言う思考プロセスから紐解いていったほうが「なぜフレームワークを選ぶのか」を合理的に理解できる糸口になって、発表者と参加者の思考を議論させる良いカンフル剤になったのでは、と思いました。

結局のところプラグインであったりモジュールであったりするものは、先駆者が作ったものを後発者が利用するのが現実です。結局のところ「車輪の再発明の仕方」なだけであって、そこにユニークな設計思想があるならば別ですが、10人いれば10人が同じアプローチを取るであろうケースにおいて「こうやります」と言うのは若干ナンセンスに感じました。

kunit さんの発表

次は kunit さんによる「Propel をあきらめるまえに」という発表。僕と同じでノウハウがぎっしり詰まったビジュアルをされている方です。
こういう人が上司にいると部下は安心して仕事が出来そう、そんな雰囲気です。
発表の内容は「symfony で採用されている OR マッパである Propel を使う事で想定される問題に対する解決アプローチ」だったわけなのですが、微妙にマッチングの難しいテーマであると感じました。こういった問題にぶちあたって”あきらめてしまう”というレイヤーに属している方にとって、Propel という OR マッパはユースケースとしては理解しにくいレベルだったのではないでしょうか。
むしろ PEAR::MDB2 (の Extended モジュール)くらいが妥当な気がしました。まあそれでは「フレームワーク」というテーマにかすりもしなくなってしまうので仕方がないといえばそうなのかもしれませんが・・・
逆に Propel の実装を理解できている人にとってはむしろ”当たり前”の思考プロセスであり「問題にぶち当たったけどまだ解決の途中」と言うような人にのみ有益な発表であったように思えます。
実務的な発表だったので自分の作業を見つめなおす良い機会にはなりましたが、この発表内容はむしろこれが出発点であり、この発表で扱われたアプローチをどれだけプログラム自体に反映させるか、つまり設計的にどう解釈すべきであるかこそが僕にとって興味のあるテーマでした。
「SQL インジェクションに自分で対応しなければならないのか」と言うテーマに対しては僕が漠然とフレームワークに感じている不安が同調しました。
つまり OR マッパに依存しないで自分でクエリを書いた場合のセキュリティかかるコストはどうする、と言うような話です。そもそも OR マッパから入っていなければ自明な論理なのですが、フレームワークを使っての開発が出発地点のような人にとってはこのような事が検討事案になってしまうんだと言う事実は、紛れも無く「フレームワークを使う弊害」だと感じました。
まあ答えとしては「データベースが提供するエスケープ機能を使う」であり平たく言うなら「プリペアドステートメントを使う」と言うことなのですが。
世の中が便利になればなるほど人間は肉体的に退化していくという進化論的な話と同じく、プログラムの原理的な部分に対する理解が薄まるほど設計も退化してしまうのではないかと考えるとおそろしくすらなります。
また、僕の被害妄想かもしれませんが「Eclipse を使ってる非 Java 開発者はスイーツ」みたいな風潮が蔓延している(ように感じられる)昨今において、Eclipse の有用性を説いて頂けた事は非常に素晴らしく感じました。

wozozo の発表

日ごろ #team-one でくだらない事や性的な事しか話しておらず、たまにちょこっと技術的な会話が、本当にたまにある程度だったのでどのような感性を持った人間なのか判断しかねてはいましたが・・・
テーマは「rhaco2 について」
最新情報的なニュアンスの発表でしたが、PHP 勉強会近辺のクラスタに属していないと全く理解できない所謂”身内ネタ”だったので割愛します。
ただ、rhaco2 の実装が面白そうに感じたのでちょっとソースを読もうという気にはなりました。
プレゼンに大きく顔文字だけ表示して「これが」「はーい」「こうで」「はーい」という発表スタイルはエンタの神様を見ているような不思議な感覚でした。

BoBpp さんの発表

ある意味一番論理的な発表だったと思います。
Perl の携帯端末向けサービス開発に特化したフレームワーク「MobaSiF」についてです。
MobaSiF の設計思想に始まり、規模の大きな企業やサービス内での実際の開発・運用スタイルについての言及。
唯一とも言える「高速」と言う設計思想は極めて実務的であり合理的です。その高速という思想をサービスの運用だけではなく、開発スピードにまで持っていく辺りに”成功したウェブサービスを維持し続ける事の大変さ”が滲んでいるとも感じました。
現実問題フレームワークを基準とすることに限界を感じるであろうタイミングは「開発スピードに起因する」と僕自身漠然と感じていました。開発スピードに起因するとは、ウェブサービスが違うという事は文化が違う事であり、文化が違うという事はその空間の制御速度が違う、と言う点に帰結します。日本とインドでは「時間が違う」と感じる事に近い話です。
その制御速度を以ってして開発に当たるわけですから、それぞれのウェブサービスに対して同じフレームワークを採用しているのにフレームワークの実装そのものがウェブサービスごとに固有の物となっていくのは、自然言語における方言に近いものなのかもしれません。
そう考えると「方言を使う事のメリットやデメリット」という視点そのものがナンセンスであるとも考えられます。
ウェブサービスの性質や文化を反映した結果、そのウェブサービスを形作るフレームワークが変化していくと言う思想は、技術者にとっては客観的に不自然な事かも知れませんが、その現場に生きる主観的な立場からすると「そうなる事が自然」である事の反映なのでしょうから「そのウェブサービスに特化し続けた結果」であるとも言えるはずです。
いつかは飯食って糞するだけで金が入ってくるような生活を送ってみたいと考えるに僕にとってかなり勉強になる発表でした。

sotarok さんの発表

GREE 発の国産フレームワーク Ethna の特色や開発スタイルについての発表です。
「Ethna のここが凄い」と言うアプローチでいくつかの特色が解説されましたが、若干分かりにくかったです。
僕の理解力に起因する事なので決して sotarok さんの発表が分かりにくかったのではない、とは思いますが、いかんせん思考プロセスに準じていないフラットな解説だったので、状況を頭に浮かべながら解説の通りに状況をトレースしていきましたがイマイチ強さを伝えきれていないように感じました。
アクションをいくつかのレイヤーに分けることで再利用性を高めるというアプローチは凄く良く思えましたが、そこをフレームワークが担当する合理的理由が明示されなかったのが残念でした。
解説自体もフレームワークを利用するプログラムの設計でフォロー出来そうなケースを用いてだったので、実感として有用性がそこまで感じられなかったのは僕が天邪鬼だったからという点に大きく依存しますが、やはり kunit さんの発表のように「問題ありき」で有用性を実証していない、即ち「この機能以外では解決できないと言う問題ではなかった」と言う点に起因すると感じました。
開発スタイルはとても参考になりました。歴史のある配布物ならではの苦労や”だからこその恩恵”、若干自嘲的にフレームワークごとの利用統計を発表して頂いたのもとても有益でした。

flyfront さんの発表

「TCPDFでお手軽PDF生成」というテーマでした。要するに配布されているライブラリの使い方ですね。
大変申し訳ないのですが普段”聞くだけ”と言うスタイルに慣れていないせいか、この辺りから猛烈な眠気に襲われて余り覚えていません。
OSS で尚且つ日本語が扱える PDF 生成ライブラリは数少なく、あったとしても動かすのは大変なんですよ、という話だったと記憶しています。
ユースケースではないので漠然と操作方法的な話が続いていたのが印象的でした。たぶん自分で使ってみればトレースできる内容だったと思います。
PDF という極めて実務的な表現方法に対して漠然とした操作説明だけを発表されるのは逆に難しいんじゃないかとも思いましたが、どちらにしても主体性のない内容だったので flyfront さん自身の思想が反映されているとは感じられず、それがひいては「内容のなさ」に感じられてしまいました。

k-kishida さんの発表

前日行われた CakePHP 開発合宿の模様を発表されていました。
アラフォーだとか湯けむり事件簿だとか、わりとバズワードが好きな方なんだなと感じました。
僕は解釈のショートカットが余り好きではないのでこの辺りの表現には食傷気味でしたが、内容はわりと面白そうでした。
「面白そうでした」となってしまっているのは発表のほとんどが「合宿楽しかったよ！みんなも行こうよ！」と言う感想で占められてしまっていたため、合宿に行くことでこれだけの成果が得られたと言う客観的な事実に基づいていなかったためです。僕の想像における話ですが、CandyCane が凄い興味深かったので早くソースを読んでみたいと思いました。

すずきさんの発表

最後は勉強会の会場を用意して下さったすずきさんです。
k-kishida さんと同じく先日の合宿に関する報告でしたが、が、その模様を撮影した写真をスライドショーで流しつつ、それぞれの写真にあわせて一言話されていただけでした。
要するに人力 flickr ですね。
「ブログで感想を書くまでが勉強会だ」と仰られていたのが印象的でした。

総評

総評とか書くと上から目線に見えますね。良くも悪くもとても勉強になりました。
やはり勉強会はおでこがくっつくくらいの少人数が限界なんだろうなと強く感じました。人数が多ければ多いほど一つの思想はマイノリティになっていくわけで、距離感が遠くなればなるほど議論の旨みも出しにくいものであり、僕が勉強会に期待するのはその旨みなわけです。
それぞれの方の発表を聞く前には「どんな事を話してくれるんだろう、どんな事を質問しよう」とかなり期待していましたが、操作方法などでは質問も糸瓜もなく「今回の発表にいたった経緯を教えて下さい」とか「今回のアプローチを選んだ論理的根拠はなんですか」なんて事を聞ける空気ではない(と感じた)ため大人しくしていました。
今回参加させていただいた PHP 勉強会はむしろ”小さいカンファレンス”であり、”小さなセミナー”であると感じました。
僕はあくまでも勉強会は対流が基本だと感じている人間なので、今回のように「発表者から聴衆へ」と言う一方向の流れに対して論理的根拠に乏しい発表が含まれていると「大味だな」と感じてしまいます。それが正しいのかどうかはさておき。

4月18日に参加させてもらった CMS 勉強会は、IT に関する知識で言えば明らかに今回よりも劣っていると言わざるを得ませんでしたが、参加者がそれぞれに抱える問題や、その問題に対する解決アプローチを議論しあう事で素晴らしい意見や知識の共有が果たせたと感じられるとても意義のある勉強会でした。
勉強会のフィールドが言語に向けられているため、発表者ごとに大きな差が生まれるのは仕方がないと思いましたが、発表する内容がないのであればテーマに対する解決アプローチを議論する方がよっぽど効果的なのではないでしょうか。

「発表する側と聞く側」の物理的なコスト差があるのは事実ですが、僕みたいにワイフから「月に100万は献上」などとシビアなハードルが課せられている人間からすると「死ぬ気で作った空き時間に知らない人が笑ってる写真集見せてもらった」と言うところに価値を見出す事は難しかったです。
これは明らかに僕の認識不足だったのでむしろ僕が申し訳ないと謝るべき事ですね。すいません。

批判的な内容ばかりですが、発表して下さった、またこのような勉強会に参加させて頂いたという事に対する僕なりのお礼です。
僕は基本的に S ですが褒められて得られる性的な興奮に比べ、批判される事で得られる新たな知見の方が万倍有益であると考えたための感想です。

どうもありがとうございました。