アルファギーク・ジュニア

最近ふと思うのですが、2年か3年前ぐらいまでは学生だったとか、あるいは学生になりたてだった、という人たちが、社会人になるなり研究室に入るなりで経験を積んでか、Web 2.0的なアプリケーションを作ってアウトプットしたり、そういう考え方を blog に書き残していたりとか、そういうのが目立つようになってきたような感じがあります。

こういう世代の人は、新しい技術の吸収のスピードとかが明らかに少し上の世代と違うような、そんな感じがなんとなくしています。ほんと、なんとなく、という感覚的な話なので申し訳ないですが。

ということで、彼らをジャニーズ・ジュニアにちなんでアルファギーク・ジュニアと呼ぶことにします。(おい)

Perl::Critic / UNIVERSAL::require

このところ社内の技術勉強会で取り上げているテーマの Perl::Critic。このモジュールは、Damian Conway の Perl Best Pracitice に書かれているスタンダードな Perl のコーディングスタイルをチェックするためのものです。Perl::Critic をインストールすると perlcritic というコマンドがインストールされ、それを使うことで自分が書いた Perl のソースをチェックしたりできるという。

いろんなコーディングスタイルのルールとかは、Perl::Critic::Policy のサブクラスに記述されていて、pod で全部読めます。

この Perl::Critic なポリシーの中に Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval というのがあります。これは eval には文字列じゃなくてブロックでコードを与えよ、というルール。

eval "print $foo";        #not ok
eval {print $foo};        #ok

理由は pod を参照していただくとして、eval を lazy な use や require のために使うときはどちらにしろ文字列で eval を使わないといけない。(コメントにありますが、モジュールファイル名で require したときのみなんとかなる) そこで、eval で use とか require するのが嫌! ってときには UNIVERSAL::require を使うという手があるかなと思いました。

これを使うと、

eval "require $module"

が、

$module->require;

と書け、OO厨*1にはたまらない感じ。

ただ、今 id:hideoki と話しててわかったのですが、UNIVERSAL::require も中では文字列で eval をしてるので、"The string form of eval is recompiled every time it is executed, whereas the block form is only compiled once. " という点においては一緒のようなんですけど。

ちなみに、UNIVERSAL::require は Catalyst で使われてるのをみて知りました。

*1:PofEAA読書会でみんなが連呼していた言葉。厨という言葉がついているが必ずしも揶揄というわけではないらしい。

PofEAA読書会振り返り

さて、昨日もちょっと触れましたが PofEAA 読書会に行ってきました。Patterns of Enterprise Application Architecture (邦訳: エンタープライズ アプリケーションアーキテクチャパターン) の読書会で、昨日は第10章の Data Source Architectural Patterns でした。Ruby on Rails の O/R マッパであるところの ActiveRecord の元になってるパターン、Active Record パターン (ややこしいな) が含まれる章で、みなさん曰く書籍の中でも特に面白い章だとのことでした。

• Table Data Gateway
• Row Data Gateway
• Active Record
• Data Mapper

の 4 つのパターンがありました。

この書籍、こんな感じでいろんなエンタープライズアプリケーションの中から共通してみられるパターンを抽出してカタログ化してみましたというものです。で、DHH がこの書籍を大いに参考にして Rails を作ったとかで非常に大事っぽいことが書いてあるのですが、和訳がちょっと微妙なのと、内容そのものが結構難しいのでなかなか理解するのが難しい! というか僕は正直かなり読むのがしんどいです。そんなわけで一人で読むのは辛いので読書会に参加してきました。

もとい、10章の内容は SQL どこに書くの? 的なパターンでした。

Table Data Gateway は J2EE の DAO に代表されるパターンで、ひとつのインスタンスがテーブルの全部のレコードを扱うというもの。SQL を一箇所に集めることで保守性を上げましょうね、というもの。

Row Data Gateway はそれを一歩進めて、1レコードを1インスタンスで管理するというパターン。ただ、Row Data Gateway ではレコードに相当するインスタンスはドメインロジック(ビジネスロジック)を持たない。ドメインロジックをインスタンスが持ってるのが Active Record パターン。

Active Record パターンはクラスの設計とテーブルの構造がほぼ一致、つまり1クラスが1テーブルに対応していて、そのクラスにはドメインロジックも含まれている。(書籍では明示的に触れられてないけど、Row Data Gateway もテーブルとクラスの構造が一致してないといけないってことになるのかな。)

テーブルの構造とクラスの設計に乖離がある場合、その乖離を埋めるためのマッピングを用意してやる必要がある、これが Data Mapper パターン。Java の Hibernate とかが Data Mapper による O/R マッピング実装。

という風に理解しました。合ってるかな。

んで、実際に Perl での実装を見た場合、Ruby on Rails の ActiveRecord にクリソツだといわれる Class::DBI は、やはり Active Record パターンということになりそうです。1クラスが1テーブルに対応していて、その各クラスが同時にドメインモデル(ビジネスロジックが実装されるモデル)でもあります。

ただ、この Class::DBI は Ima::DBI をベースにしていて、Ima::DBI が何をしているかというと、ひとつはクロージャを使ってコネクションやステートメントハンドラをキャッシュするという仕事ですが、もうひとつは DBI と連携して SQL に名前をつけて管理するということもしています。

Ima::DBI を継承したクラスで、

Foo->set_sql('get_all_foo', 'select * from foo', 'somedb');

としておくと、

my $sth = $foo->sql_get_all_foo;

という感じで、set_sql で登録してある SQL を sql_* なメソッドとして呼び出せるという。なので、Ima::DBI を使うときは Ima::DBI を継承したクラスに SQL を書いていくことになるので、Ima::DBI が Table Data Gateway みたいな役割を果たすことになります。

一方で、Ima::DBI はインタフェースが OO っぽくないし使いづらいので、これを OO インタフェースでラッピングしたのが Class::DBI ということになるでしょう。なので、Class::DBI は Active Record パターンな実装ですが、内部では Table Data Gateway も使われているという感じです。

高橋メソッドのRubyの高橋さんが隣にいたので Rails の ActiveRecord についていろいろ教えてもらいましたが、Class::DBI と似てるけど実装がだいぶ違うみたいで、面白かったです。

ActiveRecord は DHH が Rails のために実装したものだそうで、その中では Ruby の DBI も利用しておらず、データベース接続から Active Record パターンによるインタフェースの実装まで、ほぼスクラッチから書かれているらしい。(各 DB 実装へのバインディングは、他の人による実装だそうです。) DBI/Ima::DBI その他 CPAN モジュールをベースに作られている Class::DBI とはその辺りが対照的。

何かと Rails と比較されることが多い Catalyst ですが、miyagawa さんが以前に

Ben のエントリにもあるように Rails と Catalyst にはマーケティングのよしあしという決定的な違いがあるにせよ、Catalyst は「CPAN にあるモジュールを徹底的に使いこなして、それをコンテナ的につなげる触媒(Catalyst) 的な動きをする」というのが一番のメリットだなあという風に僕は理解しています。

と「Catalyst は CPAN モジュールの触媒」と書いてましたが ActiveRecord と Class::DBI の作られ方を比較しても似たような印象を受けますね。(Class::DBI が触媒、ということじゃなくて) そもそも CPAN をベースに考えられているという点で。

ところでこの読書会、はてなダイアラーの人がいっぱいいました。特に(高橋さんと反対側の隣に座っていた) id:koichik さんにはいろいろ教えてもらって勉強になりました。アルファギークジュニアな感じの人も何人かいたなあ。あと、この手のコミュニティに共通して見られる傾向ですが、笑いのつぼがとても浅いです。「OO厨」とか厨の付く言葉がでるたびに笑いがおこってました。

3年も前の本で、内容としては最近の流行とはすこし離れてきているそうなのですが、書籍からも読書会からも勉強になることはすごくたくさんあったし面白かったので、次回も参加してみたいと思います。

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

Inside Flickr's Backend

phpspot開発日誌 で Flickr のシステム構成に関するプレゼン資料のサマリが載っていて、その PDF を見たところプログラマ1人デザイナー1人で作ってるとか PHP で Smarty を多用してるとか、MySQL InnoDB でほげほげとかあって面白かったわけですが、この PDF、一年くらい前のもののようでした。

ただ、Yahoo! に買収されるもっと前のものとはいえ、参考になるポイントはとても多く有益な資料であることはまちがいないですね。個人的には、プログラマ一人、というところに納得。逆に一人あるいは数人じゃなかったらどうしてあれだけのものが作れたか、不思議に思ってたところだと思います。

なお、このタイトルは Inside LiveJournal's Backend (PDF) をもじったものです。こういうケーススタディ的な資料が無料で見れるというのはすばらしい時代だなと思います。

田中良和が本を書いた

ただ、そんな時頭に浮かぶのは、誰もやったことがないことは、やる前に考えたところでうまくいくかどうかなんて、そもそも分かるはずがないという当たり前の事だった。実行してみなければ分からないのだ。

田中良和という人に初めて会ったのは2年ほど前だったと思います。インターネットで面白いことをやってる同世代の人たちが何人かで集まってご飯を食べるという集まりの中でした。当時彼は楽天広場の中の人。そして今はグリー株式会社の代表取締役社長。

その集まりには彼以外にも面白い人がたくさん集まっていて、特別なバックグラウンドも持っていない僕はただただ周囲に圧倒されるばかりだったのを今でも覚えていますが、そんな中でも一際目立っていたのが田中さんでした。僕とは年齢がほとんど変わらないのに、物事に関する洞察力、ビジネスの知識の幅、意思決定の速さ、積んできている経験は遥かに上をいっていて、そして現場で開発もしている。何か特別なものを持っている、この人にはかなわないな、と思いました。

田中さんからは、ネットに関する考え方、ビジネスのこと、転職に関すること、ライフスタイル、いろんなことを教えてもらった。おそらく僕が影響を受けた人の中でも、特に影響が大きかったのが彼だと思います。

そんな田中さんが本を書いた、というので早速で買って、帰り途中にスタバによって読んでみました。

「俺の中に神が舞い降りた」なんてグリーを開発し始めたときに不適な笑みを浮かべながら語ったりする人なんで、僕は彼は特別だとばかり思い込んでいたのですが、どうやらその認識は間違っていたようです。

自分が何をしたいかが分からなかった学生のころの話、インターネットに初めて出会ったころに受けた衝撃、SCN や楽天での仕事を通じて出会ったたくさんの人から学んだ方法論、文系あがりでプログラミングなんてできないと劣等感を感じていたときのこと、そして挫折とそれを乗り越えることで培ってきた、自分自身を動かすための彼なりの考え方。そんなことが書いてあり、今の彼があるのはそんなひとつひとつの、小さな努力の積み重ねだったんだなというのが良くわかりました。

最初から最後まで、共通して伝わってくるのが「行動を起こすしかない」という彼の一貫した姿勢です。批評家になってはいけない、何かを実現する人間にならなければいけない、という信念。僕が初対面のときに受けた彼のアグレッシブな印象は、そんなところから来ていたのだなと改めて思います。

最初は、「よっしーが本書いたっていうんだし、読んでやるか」ぐらいの気持ちで買って帰ったのですが、読み終えた後に「下手な自己啓発本より100倍は面白かった」と、本人にメールしておきました。

ネットに限らず、自分の人生に後悔したくないすべての人におすすめできる良い本だと思います。

僕が六本木に会社をつくるまで