第2回CakePHP勉強会

 CakePHPの勉強会(第二回)が受付されていましたので、全力で応募しました(笑)。前々から興味があって、ようやくその機会が訪れた訳ですが…間に合って良かった。瞬殺でしたね(^^;。

 いや実は、プログラム系で勉強会やセミナーなど、参加経験が全くないんですよ(大汗)。今までは書籍やマニュアル等で独学だったんですけど、CakePHPは学ぶところが多くありそうだし、とにかく早くマスターしたい。それから、今後おつきあいが長くなるでしょうから…まあそんなわけでちょっと冒険しました。

 開催内容については後日レポートさせていただきたいと思います。
 ご参加の皆さん、是非宜しくお願いいたします。

CakePHP1.2+PostgreSQL8.3

 予告通り、PostgreSQL8.3を現状インストールされている8.2.5と入れ替え、CakePHP1.2で動かしてみました。とりあえず問題なく動いています。

 実は、動くまでに悪戦苦闘していまして…
 1.2でDBを動かすのは初めてだったのですが、1.1で問題なかったModelやControllerを持ってきても変なエラーが出ていたんです書いてあるはずのModelやControllerがないとか、pg_queryでエラーが出ているとか、云々。

 まず、ControllerやModelがない件は、redirectの仕様が若干違うらしく、1.1はパスの指定が最初から絶対値になっているため、例えば「www.foo.com/hoge」内で「'hoge/fuga'」にリダイレクトさせると「www.foo.com/hoge/fuga」となりますが、1.2は相対指定らしく、「www.foo.com/hoge/hoge/fuga」に飛んでしまうのです。なので、「'/hoge/fuga'」としたらちゃんと動くようになりました

 pg_queryの方は、結局はdatabase.php内のDATABASE_CONFIGクラス内で新しく加わったschemaプロパティの値を省略していたためにエラーが起きたようで、とりあえずpublicを入れたらすんなりと動きました(^^;。

 あと、Smartyテンプレート出力の後ろに、毎回クエリ結果が出てしまい、scaffold設定していないのに何でDB関連の表示があるのかとびっくりしたのですが、どうやら1.2からデバッグswが最初から入っているらしく、core.php内を修正したらちゃんと出なくなりました

 この辺は1.1→1.2に移行時の注意点でしょうか?
 Posgre8.3由来の不具合は、今のところ特に感じないです。まあ、まだ使い倒していないため、不具合を見つけられていないと思いますし、がりがり動かすようなアプリに入れたわけでもないため、まだパフォーマンスについては体感できていないです。

PostgreSQL8.3

 あれこれしている間に、Posgreのバージョンが上がってしまいました…

▼「PostgreSQL 8.3」が正式リリース、性能は最大30%向上
http://headlines.yahoo.co.jp/hl?a=20080205-00000007-zdn_ait-sci

 性能向上は、まあおまけ程度に考えた方が良いのかもしれませんね。ちゃんとした設定をしなければ効果が得られないと思いますから。とはいえ、非同期コミットでの性能向上とのことなので、普通に(どの程度を普通というのかはアレですが)DBを操作する場合で多少パフォーマンスが良くなるんじゃないでしょうか?

 問題は…新版を入れて問題が起きないか、これにつきますね。0.0はちょっと怖い(^^;。仕事で使っている案件には当然入れられませんけど、個人の実験用鯖には入れても良いかなとも思っていたり。CakePHPで動くかどうかの人柱にもなるでしょうし。家に帰ってからちょっとやってみましょう。

 というか…今後MySQL5.1にするか、Posgreのままでいくか、良い判断材料になりそう。MySQLはもともとレプリケーション機能が標準で備わっていて、5.1になってさらに強力になりましたが、Posgreはまだ標準でありませんので、pgpool等のアプリを別途入れないといけません。おそらく8.3.xに対応されるまではかなりの時間がかかるでしょうから、現時点でのPosgreのウィークポイントかなぁ。個人で鯖1個でやる分には全く関係ないけど、ちょっとでかいDBを持ちたい場合は困るかなぁ。Oracle入れろとか言われそうだけど、低コストでそれらしいDBを使いたい場合には、やっぱりレプリケーション機能は必要かなぁ…なんて考えています。
 個人的にはPosgreは好きです。SQLが分かりやすいし、正直InnoDBとかISAMとか訳わかんないし(汗)、制約とか(テーブル名やカラム名の文字制限とか、サブクエリとか)も少ないし。でも最近ではどちらも差がないと言われていますから、考え直すちょうど良い機会かと思います。

【追記】
性能向上についてなんですが、いろいろ調べていくうちに、実は凄いんじゃないかと思えてきました。
今回の目玉はHOT(Heap Only Tuples)という機能で、更新時の無駄が大幅に軽減されるとのこと。UPDATEすると、今までは以前のデータがVACUUMするまで経路が残ってしまうのですが、8.3からUPDATEすると即経路を付け直してゴミを破棄するため、ディスク使用量が少なくなるだけでなく、無駄な経路分重かったパフォーマンスが改善される、ということらしい。ベンチマークで倍の速度向上が得られているみたいで、これは凄い! 今後更新系のDBを構築する場合は8.3系にした方が良さそうです。
それから、レプリケーションが行えるpgpoolにIIが出ていて、こちらもなかなかの性能が出ている模様。
また、開発ツールとして「ENUM」というMySQL→PostgreSQLの移行ツールなどもリリースされるようですね。
意外とPostgreSQLは今アツいのかも

なぜ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初心者ですのでたいした情報を公開できないとは思いますが、それでもお役に立てれば幸いです。是非宜しくお願いいたします。

【オススメの参考書】

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

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

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

ECWorks Blogについて

 ご来訪いただきましてありがとうございます。

 当ブログは、基本的には私ことMASA-Pの書きたいことを適当にご紹介していきます。

 とはいえ、いままでいくつかのブログを作っては潰してきたのですが、どれも長続きしなかったんですよね。何故長続きしなかったのかいろいろ考えてみたんですが、こう、何というか…やはり日記みたいなものを書いても、自分で言うのもアレなんですけど、面白くないんですよね。最初は良いんですけど、だんだんモチベーションが下がるというのか、義務的になってきてしまって、ネタはつまらないし、辛い。暇人でもないので、更新が面倒になってしまって、結局最後はフェードアウトです(汗)。

 まあ今回もそうなりそうな気もしますが、少しでもためになるものを残そうと思い、いくつかの柱を立てました。1つは、現在最も関心事であるCakePHP」についてのドキュメントを残すこと。そして、それを用いたサイト制作の開発話なんかを紹介していくこと。あとは新しもの好きらしくインプレを書いたり、時事ニュースについてコラムを書いたりなんかしたいと思います。基本的にプライベートな内容は面白くないと思いますので無しの方向で(笑)。

 タイトルが「(仮)」となっているのは、そのうちに移転するつもりがあるからです。どこに移転するのかは、これからのこのブログの内容が指し示してくれることでしょう。つまり、CakePHPを使ってブログシステムを作るのが、当面の目標になっていたりします。
 また、タイトルにある「ECWorks」の意味についても、後々ご説明することになると思いますが、今は適当にとってつけた名前と思っていただいて無問題です。

 まあそんなわけで、出来るだけ役に立つブログにしていきたいと思っていますので、どうぞヨロシクです

 ちなみに、更新頻度はそれほど早くはないと思います(汗)。