Developer of the Month

勝手に計算。

CakePHP 1.2
Developer of the Month

Month	Author	Lines
June 2008	AD7six	14232
May 2008	nate	121574
April 2008	DarkAngelBGE	1666
March 2008	nate	2099
February 2008	nate	3974
January 2008	nate	2637
December 2007	gwoo	4427
November 2007	phpnut	5175
October 2007	phpnut	4874
September 2007	phpnut	6246
August 2007	gwoo	3459
July 2007	phpnut	3208
June 2007	phpnut	3859
May 2007	phpnut	7421
April 2007	phpnut	4068
March 2007	nate	4530
February 2007	phpnut	5294
January 2007	nate	1623
December 2006	phpnut	8999
November 2006	phpnut	3416
October 2006	gwoo	2241
September 2006	nate	771
August 2006	nate	2465
July 2006	nate	3020
June 2006	phpnut	3501

はじめてのCakePHP本！

ただし、英語です。（笑）

Beginning CakePHP: From Novice to Professional (Beginning from Novice to Professional) (Paperback)
by David Golding
http://www.amazon.com/Beginning-CakePHP-Novice-Professional/dp/1430209771/
３５０ページで、7月２１日に発売。

作者ブログも新設したそうです。
http://www.davidgolding.net/

ちなみに、これはOfficialではありません。
Official本はこちらのほうで執筆・部分オンライン公開がはじまっています。
CakePHP in Action
http://www.manning.com/obrien/

もっというと、“本当の”Official Bookはこちらになると思います。
http://book.cakephp.org
日本語訳もぼちぼちと始めていますのでどうぞ。
http://book.cakephp.org/ja/

書籍が出版されることで、これまでと違った層にまでリーチするようになり、CakePHPの利用者が増えることは間違いないでしょう。

日本ではCakePHP本がすでに数冊発売されていますので、PHPフレームワークに関する情勢が、日本に関しては、いかに進んでいるかがわかります。

askeet by CakePHP

There was a third cakephp-study meeting at Tokyo, Japan.
Yusuke Ando's presentation was  "How to make askeet by using CakePHP. And the differences of symfony and CakePHP."

"askeet!" is a famous tutorial of PHP framework symfony.
You can check from here.
http://www.askeet.com/

He made an askeet site by using CakePHP.

You can check his talk from here.
http://www.ustream.tv/recorded/517190
http://puyo2.upper.jp/cake/files/20080627cakephpstudy_symfony.pdf

Other presentations:
http://d.hatena.ne.jp/yandod/20080627/1214589875

Google Trends (Japanese)
http://www.google.com/trends?q=CakePHP%2CRuby+on+Rails&ctab=0&geo=JP&geor=all&date=ytd&sort=0

Behaviors

今週、日本ではCakePHP勉強会第三回が開催されるそうです。どんな発表があるか、楽しみです。

MVCにそれぞれ対応した、Behavior（ビヘイビア）, Helper（ヘルパー）, Component（コンポーネント）は、CakePHP用語では“便利ライブラリ”を部品化したモジュールで、プラガブルに使うことのできる便利なものです。そして、bakery.cakephp.org には、じわじわと使えるライブラリとして情報があつまってきています。

Helper や Component はその性質からして、「後から使うかもしれないから、一応見ておこう」的な要素が強いのですが、Behaviorに関しては、モデルに直接、働きかけるだけあって、アプリの動作そのものに影響を与えるものが多く、使うことを真剣に考える機会もより多いのではないでしょうか。

Soft Deletable Behavior
By Mariano Iglesias (mariano)
http://bakery.cakephp.org/articles/view/soft-delete-behavior
このビヘイビアを入れてやると、delete() の挙動が論理削除になります。ただそれだけですが、かなり便利だと思います。
既存コードをさわらずにアプリの動作自体が変更できるのは、まさにフレームワークならではだと思います。

AliasBehavior
By Matthew Harris (kuja)
http://bakery.cakephp.org/articles/view/aliasbehavior
これもある意味、すごいビヘイビアなのではないかと。
擬似的にＤＢフィールドの別名を付けることができてしまいます。
これを使えば、WordpressでもXoopsでもOSCommerceでも、既存のDBをそのまま使ってCakePHPアプリをかぶせてしまえるのではないでしょうか。

話題変更。
jQueryで実現している下記のテーブルもなかなかすごいと思います。
decorateを1.2対応で作るなら、これを使いたい。
http://www.webplicity.net/flexigrid/
CakePHPで使う、という話題はあるだろうか、と調べたところ、こちらですでに議論されていました。ただしポルトガル語ですが。
http://groups.google.com/group/cake-php-pt/browse_thread/thread/262675845011a4bc

CakePHPって動作スピードはどうなの？

○○フレームワークのほうがスピードが速い、とかでフレームワークを選定できるでしょうか？フレームワークにはそれぞれ特徴があるので、一概にはそれだけが基準になりませんよね。

CakePHPフレームワークの正しい使い方、というのは、おそらく、

１）とりあえず動くアプリを高速で作る
２）スピードとセキュリティの最適化
３）いろいろチューニング
４）完成！

という流れだと思います。こういう作り方ができるようにフレームワーク自体がチューニングされています。最初は、とりあえずＤＢのデータをすべて取ってきて、ページデザインを考え、必要なデータを選別。その後、やはりいらないデータは最初から取ってこないようにする、DBの効率化を図る、などを作業できます。いちど、アプリを作成した後で、デザインの最適化、データベースの最適化、キャッシュの最適化とか、などなど、できることがいろいろあります。

なので、「注文された通りに作って納品する」ときには、“テスト”のフェイズを十分に取っておいたほうがよいかもしれませんね。それか、「パフォーマンスUp」を次の仕事として請け負うことも可能かもしれません。

「自分でサービスを作って立ち上げ、アクセス数が増えてきたら、それに応じてスケーラビリティを考えてゆく」という使い方もできます。

なので、そういうノウハウばかりがまとまっている文書もあったらいいなぁと思ったら、その取り組みがはじまっていました。

Optimizing Cake's Performance
http://groups.google.com/group/cake-php/web/optimizing-cakes-performance

今後、情報が増えるといいなぁというドキュメントが下記にできています。まだ書きかけのようですが、充実してほしいと思います。

何かと話題の“array”。

これはPHPの構文自体の話題

Better array syntax for PHP: Here's your chance to weigh in
http://www.debuggable.com/posts/better-array-syntax-for-php:484d6517-a700-4af3-a62f-64544834cda3

$fields = array('id', 'name', 'created');
を
$fields = ['id', 'name', 'created'];

と書けたらいいんじゃない？という提案に対する、PHP自体の開発者たちの反応とPHPを使う側の反応の違いについて説明されています。

開発者側は３分の２が反対、ユーザ側は２０人中１７人が賛成、という結果だそうです。

ちなみにこの記事は、CakePHPのリードデベロッパーによるもの。

jQuery on Rails

jQueryでRailsみたいなことをするのか、と思ったら、jQueryで Prototype/script.aculo.us を置き換えてしまおう、というプロジェクトだそうです。jQuery恐るべし。「もうscript.aculo.usはいらない」と言わせる日も近いでしょうか。今のところ、まだバージョン0.3だそうです。

jRails - jQuery on Rails
http://ennerchi.com/projects/jrails

Cakeでも使えるか、試してみよう。

CakePHP 2はどうなるか

MLでCakePHP 2の方針に関する意見求む！という話題がはじまっています。

Strict or Pretty? We're looking for a few good opinions
http://groups.google.com/group/cake-php/browse_thread/thread/c8e782d05dd268e1/

話の流れ的には、PHP5のstrictでエラーが出ないようになりそうです。

mysql_free_result()

suzukiさんの書かれた Authcomponentに関するTicket
https://trac.cakephp.org/ticket/4744
がEnhancementになったそうなので、Enhancementってどれくらいのものが登録されているのだろう、と疑問を持ち、ページを開いてみました。

https://trac.cakephp.org/report/2
ありゃーいろいろありますね。これは、「とりあえずすべての開発者に影響を与えるわけではないが、ある場合には影響がある」というものがとりあえずこちらに並べてあるように思います。すべてを扱うにはまだ人手が足りていない、ということかもしれません。

下の列には、“optimizaion”という欄があって、「こうすると速くなった〜」という情報がいろいろ書いてあります。そこで、こんなのに目がとまりました。

Ticket #4801 (new Optimization)
MySQL Highly Effective Optimization
https://trac.cakephp.org/ticket/4801

「非常に効果的なMySQLの最適化」って何をするんだろう、と思ったのですが、要は dbo_mysql.php の中で、mysql_free_result() をすると、メモリの使用が最適化されるので、スピードがかなり速くなったよ、という報告でした。そうなのかぁー。扱うデータ量が多い場合には効果があるかもしれません。関心のある方、ベンチ−マーク、お願いします。

でも、PHPマニュアルのコメント欄を見ると、
http://jp.php.net/mysql_free_result
「使ったほうがいい」「使わないほうがいい」と賛否両論です。
環境によるのかもしれませんね。

とりあえず、
https://trac.cakephp.org/report/2
はたまに見るとよさそうなページです。

1.2.0.7119!

ついに1.2のRC版リリースだそうです。
ホームページからダウンロードできます。

Release: Pure Cake Power in RC1
http://bakery.cakephp.org/articles/view/release-pure-cake-power-in-rc1

more than 800 revisions
ということで、初期の1.2からは相当変化していますが、安定版が出るのもまもなくでしょう。

Zend_Dbの作者はActiveRecordをどう考えているか

Zend_Dbの作者がActiveRecordについて語っています。これはおもしろい。

Keeping it Simple
ActiveRecord does not suck
http://karwin.blogspot.com/2008/05/activerecord-does-not-suck.html

CakePHPについては語らず、Railsについてだけですが。
要は、多くの初心者が“モデルって、DBテーブルのことだよね”と考えてしまうのはよくない、と。結果的にコントローラがふくれあがり、UnitTestで影響が出てしまう、という話になっています。

個人的な意見として、まぁ、それはそうなんですが、「絶妙に妥協」というか、通常、Webアプリで書く場合にはたいていの場合、DBがあるよね、だから、“情報”はDBテーブルに入れて、それとそのインターフェイスをモデルと考えようよ、という考え方は好きなんですよね。

Delphiの“コンポーネント”なんかは、中で何回継承していようと、完成した部品クラスはパレットの上に一列に並んでいたので、非常に直感的でした。

OOPの理想的な“Modelクラス”を使ったオープンソースをいじったりもしましたが、結局、親クラスのソースを次々と読まないと、「このクラスは何ができるの」ということが把握できなかったりするので、そういう点ではRails流のモデル定義は理想的ではないとしても“実用的”だと思っています。

ZFのプロジェクトリードは他のフレームワークをどう考えている？

個人ブログで「CakePHPをはじめました！」と書き込んだら、ZFのプロジェクトリーダからコメントが付いたみたいです。

"Point is- it’s always best to start with requirements in making technology choices."

コメントの是非は別として、通常、他のフレームワークがどうこう、という話はなかなか当事者からは聞けないと思うので、なかなか興味深いと思います。

phalkunz.com
Let’s Bake Some Cakes
http://phalkunz.com/2008/06/02/lets-bake-some-cakes/