【戯れ言】あえてCakePHPをヨイショしてみる

prog-logo今回はCakePHP記事としてでなく、一般的なプログラミング…いや、完全個人的な戯れ言としてちょっと書いてみたいと思う。

発端は最近のはてブのエントリで、こちらこちら の記事でいろいろなフレームワークの比較が書かれているのだが、どうも直感的に各フレームワークの良さが伝わってこなかったのだ。例えば前者の方は、最終的にZendFrameworkをお勧めしているのだが、そのお勧め理由が全くよく分からないというのか、「自分が好きだから良いですよ」的な結論にどうしても見えてしまう(いえ、その主張そのものを否定はしないです)。というのは、以前まで話されていたフレームワークの比較が、現時点では通用しなくなってきているというのか、どれもバージョンアップを重ね、よりよいものになってきているからである。自分も このような記事 を書いていたりするけど、丁度良い機会なので、今自分が感じていることを以下に書いてみる。

個人的に言わせてもらえば、私のメイン使用であるCakePHPも「かなりのところでいい線いっているんじゃないか」と最近思っている。CakePHPを初めてさわってまだ1年半程度だけど、この間にとんでもないほど機能は向上し、そして安定もしたように思う。Cakeは現在メジャーバージョンは1.2で、当初はまだ1.1だった。この進化の過程で、Cakeの出来ることは格段に増えていった。

例えば、フレームワーク比較で良く目にする違いとして「symfonyは大規模向け、CakePHPは中小規模向け」というのがある。これはいったい何なのだろう? よく読むと、大抵は「symfonyはプラグイン機能があるため、大規模向け」という書き方がされている。これは本当にそうなのだろうか?

まず簡単なツッコミをさせていただくと、CakePHPは、既にプラグイン機能を装備している。symfonyとほぼ同じように、一連機能を持った仕組みを簡単に入れたり抜いたり出来る。つまり、この定義でいけば、CakePHPは十分に大規模向けだ。

でもよく考えてみて欲しい。プラグイン機能は本当に「大規模」なサイトを構築するための機能なのだろうか? いいや、私はそうは思わない。本当の大規模サイトというのは、フロントエンドは何十ものサーバがロードバランサなりラウンドロビンなりで制御され、バックエンドも同様に複数のDBがレプリケーションなりで動いているような、そんな状態のことを言うのではないのだろうか? そして、そのような機能を搭載しているフレームワークこそが「大規模向け」ではないだろうか? 安定しているかどうかは置いといて、CakePHPはこれらを支援する機能を持っているし、実際に「Firefox アドオン」サイトのような大規模なサイトもちゃんと動いている。
そしてプラグインは、私はむしろ逆の、中小規模向けのものと考える。何故なら、第三者の制作したものを、手っ取り早く自分のものに出来るというのが実質的なところであり、そういった用途のものは中小規模向けに書かれているものが多いからだ。そして、それを使う人も勿論中小規模の環境をもつ人が多い。大規模環境を持っていれば、間違いなく自前で専用にカスタマイズされたものを持たざるを得ない。

そういった意味で、最近のCakePHPは隙が全くない。大規模から小規模まで自在だし、前からPHPは4でも5でも動く(いずれ出るであろう6にもサポート表明している)。1.2になって軽量とは言えなくなってきてしまってはいるが、それはサーバスペックを上げればどうにでもなるし、そもそもキャッシュを使えば重さは感じなくなる。何より強力なアソシエーション機能は、おそらくDBをもっとも都合良く操作できるのではないだろうか?

勿論、symfonyやZendFrameworkなど他のフレームワークには、それぞれの良さがあると思うし、繰り返すけどどれもバージョンアップを重ね、機能的にはどれも大差ないように思える。まあどちらかと言えば、Cakeとsymfonyは同じグループで、ZendFrameworkはグループが違うように思う。Zendのほうは各機能が独立して機能する点は今でも継承していて、それが特徴的かつ有用な機能の一つだからだ。Adobeとかがサポートしている点も大きいと思う。symfonyの豊富なプラグイン機能は、未だ優位だと思うし(でも多少勢いの衰えた感はある)。

だけど私は、Cakeの良さは、単体としての機能はとりあえず置いといて、別の点で「少なくとも日本では」優位であることを主張したいと思う。それは、特に最近、いろんな事例やTipsなど、豊富なドキュメント…とりわけ日本の有志の方が残した「日本語のドキュメント」がおそらく一番多く存在している点…これこそ、CakePHPの最大の強みではないだろうかと思う。フレームワークが高機能だったり高速だったり、そういった要素も勿論大事だと思うけど、結局は満足に使いこなせなければ意味がないわけで、それを使いこなすための手法が、ネットで検索すれば沢山手に入る。それも手に入る情報は「使えない」「改造が必要」といった後ろ向きなものでなく、前向きなものばかりだ。CakePHPのドキュメントは、本当に宝の山に思える。フォーラムも活発で、勉強会の頻度もおそらくは一番だ(Zendは少なくともPHPフォーラムであまり見たことがない)。

思えばその1年半前、さんざんに悩んだあげく、メインで使っていくフレームワークをCakePHPに絞った。もしかしたら機能的な面で言ったら、ZFやsymfonyの方が良かったかもしれない。いや、RoRだったり、Javaだったりした方が良かったかもしれない。だけど、勉強会に参加したり、ブログで情報を発信したりしてみて、Cakeに関係する皆さんがそれぞれ知り得た情報がしっかりと共有できているというか、もっといえば繋がりが非常に強く結束力のようなものがあり、皆でCakePHPを盛り上げているという実感がある。その辺が凄く楽しい! 新しい発見があるし、それが自分への刺激にもなって心地よい。自分の情報はその中でどのくらい役に立っているのかは分からないけど、それでも自分の情報が、その人にとって有効に働いてくれたら嬉しいし、それがきっかけでその人も更にCakePHPを盛り上げていってくれるのならもっと嬉しいと思う。今回CakePHP勉強会で壇上でKtai Libraryを発表することになったけど、これもそんな気持ちで現在取り組んでいる(まあもっともKtai LibraryはCake以外でも是非使って欲しいんだけど)。

何か最後は終わった後の感想みたいになっちゃったけど、まあ言いたいことは、「CakePHPはいろいろな点でなかなかイカしているぜ!」みたいな感じですかね(笑)。そして改めて、情報を公開されている方には感謝をしたいと思います。いつもありがとうございます。

なぜCakePHPなのか?

【おことわり】
本記事は2008年1月末に書かれたものです。
各フレームワークとも現在はバージョンアップを重ね、より高機能になっているため、記事内で指摘した各長所短所が現在のものと異なる場合がございます。その点を踏まえてお読みいただけますと幸いです。

CakePHPそのものにについては他でもさんざんに取り上げられているでしょうから、解説等はほどほどにしておいて、なぜCakePHPを選択したのか、そこについて語ろうと思います。CakePHPについてよく知らないようでしたら、 こちら に詳しく書かれていると思いますので、是非ご一読されてみてください。

昨年初冬あたりから、PHPフレームワークの導入に関心を持ち始めいろんなものを研究していました。その中でもとりわけ、3大フレームワークと呼ばれている「Zend Framework」「symfony」「CakePHP」の3点に絞り、実際にインストールして試用したりしてみました。

何故フレームワークかと言いますと、私は3つの問題を抱えていまして、その問題解決には導入が必要ではないかと考えていたからです。
その問題は、一方は会社で、一方は私的なサイト構築で起きていました。

まず1つめは、PHP4のサポートが昨年末で終了してしまうという問題でした。会社ではPHP4ベースの開発をずっと行ってきていましたので、今更PHP5に切り替えるというのはとても大変なことです。大きな仕様変更のためにPHP5でPHP4のプログラムを動かすことはほぼ出来ませんから、現在動いているサーバを止めてPHP5をインストールすることは出来ませんし、かといって新たなサーバを準備するにも時間がかかります。仮にサーバ準備を進めるにしても、その間にも制作中の案件がありますので、PHP4サーバで動くプログラムを開発しなければならない。しかし、今後PHP5で動かすことは目に見えていますから、その間のつなぎとして、移植性に優れたフレームワークが必要でした。

2つめの問題点は、社内開発スタッフ間での技術共有が思ったように出来ていなくて、現状異なるスタッフがプログラムを修正することが困難になっていました。
基本的に、今まで開発してきた案件は新規制作が多く、それほど大きな規模ではなかったため、個々が今まで作ってきたサイトをベースにして、改変する形で作ったものが多いのですが、先日たまたま1人では納期的に間に合わない案件が出まして、共同作業がどうしても必要になりました。その際に、私の作っていたフレームワークもどき(笑)をベースにしたのですが、それを理解してもらうのにかなりの時間を要したものですから、これではいけないなと危機感を感じました。
私がフレームワーク制作にかかりきりになれるのなら、社内標準のフレームワークとして共有することが出来るのですが、残念なことに私もサイト制作はしなければなりませんから、2足のわらじを履くことは出来ません。実際にそのようなことをやってみていたのですが、案の定フレームワークのメンテナンスが出来なくなったため、もうこれは止めようと思っていました。PHP4で書かれているので移植が必要なのですが、そんな時間もないため、ちょうど良い機会とも考えていました。
そのためには、豊富なドキュメント量のあるオープンソースフレームワークが必要と考えました。ドキュメントさえしっかりあれば、自分が教える必要がないからです。

3つめの問題は、私的なサイトを現在制作中なのですが、何せ手伝ってくれる人もいませんので、開発コストのかからない方法としてフレームワークがどうしても必要でした。出来れば、開発の力を中身の部分だけに特化して、基本的動作に関しては不具合が少なく手のかからない簡単なものが良いと思いました。専用サーバこそ用意しましたが、環境にもコストをかけられないため、軽量で動くことも大切でした。

以上の問題点を踏まえつつ、先に説明した3つのフレームワークを試用しました。

まずZend Frameworkですが、バージョン1が出たばかりということもあり、導入事例があまりないのが最大の欠点でした。オフィシャルが用意しているリファレンスは大変にしっかりしたものなのですが、残念なことに、一番肝心の「構築方法」が具体的に書かれているものが無く、現時点で最も開発に時間がかかりそうだと結論しました。
ただし、Zend Frameworkはどちらかというとライブラリに近く、機能単位で分割されているため、それを個別で利用することが出来るという利点があります。つまり、symfonyやCakePHP内でも、Zend Frameworkの機能の一部分を使うことが出来るのです。なので、これは余裕が出てきたら再度研究する価値はあるかなとも思いました。

次に、一番悩んでいたのがsymfonyです。
実は、会社ではCakePHPで、私的サイトではsymfonyで行くつもりでいました。会社ではPHP4を併用しなければならない点があり、その時点でCakePHP以外に方法はないため、これを上回る優れた点がない限りは会社でsymfonyを使うつもりはありませんでした。私的サイトの方はPHP5でOKなため、単純に機能の善し悪しで決めることが出来ました。
もちろん、異なる技術を同時に覚えていかなければならないため、効率が悪いのは確かです。ですが、会社で作成した技術を転用していると思われるのも癪(しゃく)なので、この辺に関してはむしろ良いかなとも思っていました。
実際に、symfonyは「symfonyコマンドによる作業の自動化」と「yamlやxmlによるコーディングの自動化」「adminジェネレータ」が大変に優れていて、特にデータベースに関係のある操作を行うのに最も使いやすいフレームワークです。
例えば、開発中にテーブルのカラムをどうしても増やさなければならない場合、プログラムを修正したあと、データをコンバートするのがどうしても手間でした。場合によっては、今まで開発に使っていたデータを捨て、新しく入れ直すこともありました。symfonyでは、yamlもしくはxmlに記述したモデル情報を修正し、symfonyコマンドで2つの操作を行うだけで、データは元のまま、カラムだけが増えているという大変に嬉しい状態になります。CakePHPでは、こうはいかないのです。

しかし、symfonyには2つの欠点があり、最終的にそれが導入の妨げになりました。

1つ目は、JOINを含む、複数の関連性のあるカラムをモデルで受け取る場合にsymfonyはどうやったら良いのか理解ができなかったことです。MVCの概念からいくと、データ操作はモデル内で完結した方が美しいのですが、モデルAのなかでテーブルAのみを操作するのは問題ありませんが、テーブルBをJOINした場合のモデルBの関連性をどのように表現して良いか、全く分かりませんでした。CakePHPは、モデルAを主としてモデルBをJOINしても、問題なくアクセスできるし、さらにCakePHPは、「アソシエーション」機能で、モデルAに関連したモデルBを一括取得できるというメリットもありました。

2つ目は、symfonyには強力なプラグイン機能があり、PEARアーカイブで簡単にインストールができるという利点があるのですが、残念なことに同じプラグイン機能を複数持つことが出来ないのです。
symfonyは、プロジェクト内に複数のアプリケーションを持つことが出来るため、例えば一般向けのフロントエンドと管理者向けのバックエンドを1プロジェクトで管理できます。例えば、フロントエンドに会員向けのログイン機能、バックエンドに管理用ログイン機能を用意するとして、認証ログインのプラグインであるsfGuardPluginを用いたくても、同じデータテーブルを使わなければならないのです。一般データ内に管理者データを混ぜることは大変に危険ですから、このやり方はNGです。
また、sfSimpleBlogPluginというブログ機能もプラグインで提供されているため、簡単に導入することが出来るのですが、これも複数ブログをプロジェクト内で持つことは出来ないのと、sfGuardPluginが強制的に組み込まれていて、既に使っている場合に重複してしまうなど、いろいろな問題点に遭遇しました。

提供されているプラグインを手っ取り早く入れて単一のサービスを手軽に始めるには大変に良いかもしれませんが、複数の機能を組み合わせるような場合には、symfonyは向いていない気がしました。
もっと言えば、枠の中で動くようなシステムはsymfonyは最短で作ることが出来ますが、ちょっとでも枠から外れたものを作らなければならない場合はsymfonyでは難易度が高く、逆に妨げになると感じました。

CakePHPは、symfonyと比べて構造が簡単でそれほど大きくなく、システムが大変に理解しやすいです。フレームワーク内の動きがソースで追えますので、何か不具合があった場合に安心感があります。symfonyはPEARで簡単にインストールすることが出来ますが、パッケージがlibディレクトリに隠れてしまうため、扱いにくいかもしれません。その上、symfony以外で要求する(PEAR)アプリケーションが多く、テストサーバと本番サーバのように、他のサーバに同じ環境をつくらなければならない場合、整合性がとれなくなる可能性もあります。CakePHPはバージョンアップしにくい欠点はありますが、逆に言うと異なるバージョンを併用することも出来、これはこれで便利かもしれません。

いろいろと細かい点を書いたかもしれませんが、symfonyは「サイトオーナー向け」、CakePHPは「サイトデベロッパー向け」と書いた方が分かりやすいのかもしれません。symfonyは有りものを使うのに便利で、少ない手順でサイトが作れるものに対し、CakePHPは作り込みが前提で、作り込むための基本的なものが準備されている点に違いがあると思います。どちらも優秀なシステムだと思います。ただ、私の用途からいくと、CakePHPの方が理想的であるため、導入を決めました。

ただ、ビューテンプレートについては若干使いにくく、出来ればテンプレート内にPHPコードを埋め込みたくないため、Smartyを使うことにしました。ビュープログラムをSmarty用に改良したものが紹介されているのですが、若干不具合があるため、それを参考に最新版のソースコードから作り直したものを作成しました(そのうちに紹介しようと思います)。これにTinyMCEを組み込み、携帯対応コンポーネントと自前で作成した認証コンポーネントを組み込んだものを「フレームワークのフレームワーク」として使っていく予定です。

そんなわけで、作成途中で見つけたTips等を今後紹介していこうと思います。CakePHP初心者ですのでたいした情報を公開できないとは思いますが、それでもお役に立てれば幸いです。是非宜しくお願いいたします。

【オススメの参考書】

アマゾンのサーバでエラーが起こっているかもしれません。一度ページを再読み込みしてみてください。

CakePHP徹底入門

CakePHP徹底入門 [書籍]

著者イージーゲート

出版社翔泳社

出版日2008-08-29 (金)

商品カテゴリー大型本

ページ数384

ISBN479811717X

Supported by amazon Product Advertising API

CakePHP ポケットリファレンス (Pocket Reference)

CakePHP ポケットリファレンス (Pocket Reference) [書籍]

著者株式会社ブルーオーシャン 岡田 佳典

出版社技術評論社

出版日2008-06-18 (水)

商品カテゴリー単行本(ソフトカバー)

ページ数448

ISBN4774135038

Supported by amazon Product Advertising API