PHPカンファレンス関西のLTで発表したネタです。スペインやロシアからも開発者が参加するようになりさらに開発の活発さが増しているCandyCaneですが、今回はコンプガチャ機能を実装してみました。

前日の飲み会中の会話からネタとして発想し、そこから無限もやしを摘みながら4時間程度で実装したプラグインです。
現在は無制限にガチャを回せていますが、チケットを閉じる度に回せるとかペイパルで送金したらさらに回せるみたいなソリューションとして育てていける訳ないですね、、、はい。

また移行作業ではインストーラーについてもCake2で動くように改造しています。こちらも見た目で変化がわかるようにシロクマのキャラクターを背景に追加しました。やっぱり可愛いほうがヤル気が出ますからね。

発表につかったスライドは下記になります。新しいインストーラーとコンプガチャを試してみたい方はダウンロードページからα版をどうぞ。

CakePHP版Redmine CandyCane

すでにブックマークなどでご覧になった方もいるかと思いますが、表題の講演をPHPカンファレンス関西で行って来ました。サブ会場での講演でしたが40人以上の人にお越し頂けたので弾丸でしたが大阪にいってよかったと思います。既に動画などは上がっている内容であっても、参加者のニーズがあるのであれば再演するというのはいいことなのではと思いました。

なお今回のセッションの動画もすでに公開されています。


Video streaming by Ustream

今回は時間の関係で内容を大幅に削っています。継承やstaticにほとんど触れないオブジェクト指向というのもさみしい気もしますが、まずは関数ベースのコードを理解できる人がクラスを使ったコードを追うことができるのが目標でしょうか。今後もこのような中級者向けのセッションとしてPHPUnitやPHPの環境構築、セッションの取り扱いと拡張といった内容を実施していくつもりです。

お越しいただいた方々、素晴らしいカンファレンスを企画して実施していただいたスタッフの皆さんありがとうございました。

LTで発表したPHP版Redmine CandyCaneにコンプガチャを実装しましたはこちら

少し前になりますが、PHPカンファレンス北海道にてCakePHP2のワークショップを開催させて頂きました。かなり直前で無理にお願いしてワークショップの開催をお願いしたにも関わらず、快諾して頂いたnazoさんには頭が上がりません。本当にありがとうございました。

当日の資料は下記のスライドです。今回は動画などはありませんので、参加者の方で復習したい方は下北沢で開催された同ワークショップの動画を見ていただくのが良いかと思います。

3時間濃縮CakePHP2.1 in PHPカンファレンス北海道2012
View more presentations from yandod

PHPカンファレンスは最近は関西、北海道でも開催されるようになり広がっていますね。今週末も関西で開催されますのでセッションをやり参加します。

PoRTAL Shibuyaはものすごく作業がしやすかったです。表題のとおりハッカソンを開催して参加してきました。今回はお題などを設定しようとも思ったのですが、現在執筆中の書籍の作業があまりにも溜まってしまった事もありとりあえず2,3人で作業できたらいいかなと思い、ノンジャンルな感じでatndにイベントを立ててみました。しかし蓋を開けてみると総勢13人参加のにぎやかなハッカソンになりました。

最初に自己紹介タイムで作業内容を発表した後はタスクボードに予定を貼りだしてひたすら作業です。他の人がタスクを完了させているのを見ると自分もポストイットをDoneの位置に動かしたいのでがんばろうという気が起きてきます。各人の奮闘もあり翌朝にはかなりの数のタスクがDoneの位置に移動していました。

そしてハッカソンといえばやはりピザ！。かなりストイックなガチハッカソンでしたが、会場のPoRTALは椅子も座りやすくキッチンなどがあるので気分転換もしやすくてとても快適でした。全体の解散を午前中にすると体力的な負担も小さくなりそうなので、すこし改善を加えつつまた開催したいねーと参加者一同意気投合したさわやかな朝になりました。参加された皆さんはお疲れ様でした！

PoRTAL Shibuyaの作業環境を体験してみたい方や宿題が溜まってしまっている方、開発仲間が欲しい方はぜひ次回ご参加ください。作業テーマは縛りはないのできっとなんでも大丈夫です。（今回もPHP、Python、MySQL、書籍執筆、PS VITA用アプリ開発、Webサイトコーディングなどバラバラでした）また超生産性の高いPoRTALの様子が気になる方はFacebookのページをウォッチすると良いと思います！

PHPが動くPaaSの中でも知名度の高いheroku phpfog orchestraのそれぞれ実際のところどの程度のパフォーマンスが出るのか気になったので調べてみました。結論から言うとどのプラットフォームもAmazon EC2内のネットワークがボトルネックになっておりパフォーマンスの差はほとんどありませんでした。

テストは下記の簡単なスクリプトに対してabで並列数１でリクエストを投げるという形で行いました。下記のグラフは１秒間あたりに処理したリクエスト数です。

<?php
echo json_encode(getdate());

結果が頭打ちになってしまっている原因はおそらくネットワークです。今回のテストは日本から行なっているので海を越えて東海岸のEC2に到達するまでの部分がボトルネックになっていると思われます。３プラットフォームに対してtracerouteを取ってみましたがどれもAmazonのネットワークに入った後に追跡ができなくなっています。どのプラットフォームも連続的に接続を行うと接続がリセットされてしまう現象が起こるのですが、とくにphpfogはその頻度が高くテスト自体が難しい状況でした。

traceroute to argon-stack-1879049447.us-east-1.elb.amazonaws.com (107.20.154.48), 64 hops max, 72 byte packets
 1  1.1.1.1 (#######)  2.618 ms  0.738 ms  0.699 ms
 2  hoge.nttpc.ne.jp (######)  2.966 ms  3.323 ms  3.011 ms
 3  210.153.249.209 (210.153.249.209)  3.511 ms  3.650 ms  3.476 ms
 4  210.153.249.161 (210.153.249.161)  4.049 ms  5.707 ms  4.542 ms
 5  210.165.252.145 (210.165.252.145)  3.617 ms  4.084 ms  4.376 ms
 6  xg5-0-n-otemachi-core6.sphere.ad.jp (202.239.114.173)  3.881 ms  3.082 ms  3.075 ms
 7  xe-7-1-3.a20.tokyjp01.jp.ra.gin.ntt.net (203.105.72.161)  3.596 ms  3.251 ms  2.967 ms
 8  ae-6.r25.tokyjp01.jp.bb.gin.ntt.net (61.213.162.169)  2.919 ms
    ae-6.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.162.161)  3.240 ms  3.238 ms
 9  ae-1.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.2.20)  5.840 ms  9.010 ms
    ae-9.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.2.92)  3.462 ms
10  as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189)  108.546 ms  101.626 ms  101.496 ms
11  ae-0.r21.sttlwa01.us.bb.gin.ntt.net (129.250.2.54)  96.991 ms  100.001 ms  100.137 ms
12  ae-5.r21.asbnva02.us.bb.gin.ntt.net (129.250.4.181)  175.298 ms  202.796 ms  167.169 ms
13  ae-2.r00.asbnva02.us.bb.gin.ntt.net (129.250.3.114)  163.586 ms
    ae-2.r04.asbnva02.us.bb.gin.ntt.net (129.250.4.207)  169.794 ms  173.062 ms
14  ae-1.amazon.asbnva02.us.bb.gin.ntt.net (168.143.191.26)  164.108 ms  168.722 ms
    ae-2.amazon.asbnva02.us.bb.gin.ntt.net (168.143.228.38)  184.965 ms
15  205.251.245.1 (205.251.245.1)  184.698 ms
    72.21.220.45 (72.21.220.45)  179.675 ms  169.800 ms
16  72.21.222.149 (72.21.222.149)  169.540 ms  170.406 ms
    205.251.245.47 (205.251.245.47)  175.874 ms
17  216.182.224.203 (216.182.224.203)  164.258 ms  176.473 ms  167.645 ms
18  * * *

参考までにさくらのレンタルサーバー（スタンダード）とロリポップも一緒に同じテストをしてみると圧倒的なパフォーマンスを見せたのはロリポップでした。特にロリポップは秒間20リクエスト以上、並列数を増やしていくと80リクエストを処理する事もあり想像以上のパフォーマンスでした。

パフォーマンスが高い時もある一方で不調時の落ち込みも大きく、結果のばらつきでいえばさくらインターネットの方が安定した数値が出ています。

東海岸のAmazon以外で稼働するPaaSがあれば良いのですが、現状ではパフォーマンス面でPaaSには差がつかない状況です。一方で無料で作れるアプリの数やツールの充実度、拡張などではherokuが群を抜いています。パフォーマンスをさらに引き出すようなノウハウをご存知の方がいたら是非教えて下さい。

ベンチマークの結果は下記に公開しておきます。
PaaS bench

追記
サンフランシスコに出張中の元同僚に同じコマンドを投げてもらったところ、2倍近く性能が向上していました。

Concurrency Level: 1
Time taken for tests: 6.670 seconds
Complete requests: 30
Failed requests: 0
Write errors: 0
Total transferred: 9780 bytes
HTML transferred: 4140 bytes
Requests per second: 4.50 [#/sec] (mean)
Time per request: 222.325 [ms] (mean)
Time per request: 222.325 [ms] (mean, across all concurrent requests)
Transfer rate: 1.43 [Kbytes/sec] received
 
Connection Times (ms)
 
 
 
min mean[+/-sd] median max
Connect: 180 215 23.6 210 267
Processing: 1 8 5.6 5 24
Waiting: 1 7 5.5 5 23
Total: 186 222 25.0 217 274
 
Percentage of the requests served within a certain time (ms)
50% 217
66% 228
75% 240
80% 251
90% 261
95% 270
98% 274
99% 274
100% 274 (longest request)

そろそろgithubと並んで使った事が無いなら危機感を感じるレベルなPaaSですが、PHPの場合は何を使っていますか？PHP FogやOrchestra.ioといったPHPに最適化されたプラットフォームもありますが、PaaSの王道とも言えるHerokuでもPHPは非公式にサポートされています。

しかもこれが非公式サポートであるにも関わらず、facebookの開発者コンソールからクリックだけでデプロイできるので密かにメジャーなプラットフォームになっているという不思議な状況です。Ruby界隈では常識かと思われるHerokuがPHP界隈で流行っていない原因に「mbstringがサポートされていない」というのがあります。しかし今回ちょっとやってみたらmbstringをHeroku上にセットアップする事が出来ました。

ひとまずコチラが実際の環境です。
phpinfo() on Heroku

mbstringをherokuで動かした方法

参考にしたのは下記に紹介されていたmongo.soをセットアップする方法です。同じ方法で作成した拡張を読みこまさせてみたら動きました。heroku run bashを使えばどんな拡張でもビルドできそうですね。

linux – PHP Multibyte String on Heroku – Stack Overflow

作成したPHP拡張モジュールをgithubに公開しています。この拡張をアプリのリポジトリにいれた上で、プロジェクトフォルダ内のphp.iniから読み込ませれば動作しているようです。具体的な例はこのサンプルアプリのリポジトリをご覧ください。

yandod/phpinfo-heroku

やっている事はHeroku上でビルドしたmbstring.soをプロジェクト内に配置して、php.iniを下記のように記載してこれもプロジェクト内に配置します。

extension=/app/www/mbstring.so

拡張モジュールについては今後はここに集まるかもしれませんね。使いたい拡張があった人はビルドした後にプルリクエストを送るとよさそうですね。

Herokuってパフォーマンスどうなの？

PHPに最適化されているその他の環境ではなくHerokuを使う利点はやはりプラットフォームが大きい事による安定性やパフォーマンスだと思われます。下北沢オープンソースカフェのマスター河村さんが計測してみた所によると、herokuはpagodaboxやphpfogよりもパフォーマンスが良かったようです。

PHPerもHerokuを始めよう

というわけでまだherokuデビューをしていないPHPerはherokuをやってみるといいと思います。アカウントを取得したらやることはそんなに多くありません。

• Heroku Toolbeltのインストール
• heroku create –stack cedar
• git push heroku master

本当に簡単なので是非試してみてくださいー。

参考：
heroku で PHP を使う – A Day in Serenity @ Kenji

下北沢オープンソースカフェでPHPのオブジェクト指向入門講座を開催しました。
公開したスライドにかなりブックマークをした貰ったので既に資料をご覧になった方もいるかもしれません。
現場での参加者は4名でWordPressのテーマ作成などはしているけれど、classが出てくるとコードが追えなくなるという話を以前、プリンス西川さんが言っていたのでそれに応える形で話をしました。
実際のところfunctionとグローバル変数の組み合わせでも頑張れば何でも作れるわけですが、肥大化する引数やグローバルな変数や関数の乱立は他のプラグインの導入の際のリスクになりえます。そこから脱する為に必要な文法の知識を取り扱っていました。

また何度かにわけてやると集まるのが大変なので8時間耐久フォーマットで一気に実施しています。（今回は6時間くらいで終われました）

PHPでオブジェクト指向というと下岡さんの書かれた本などもありますね。
書籍「PHPによるデザインパターン入門」の原稿テキストを公開します – Do You PHP はてな

今回の資料はfunctionベースの開発をしている人がclassの文法を学ぶ事が目的なのでデザインパターンや設計の話は一切していません。サンプルコード程度のものであればクラスにせずとも頑張ればメンテナンスもできるでしょう。
とはいえ複雑な関数を分割したり、グローバル以外の使いやすいスコープを得る為にクラスにしてメンバ変数を使うという方法はやはり知らないよりは知っている方がいい知識なのではと思います。

スライドの他にオープンソースカフェの河村さんのおかげでUstreamの動画が6時間分ほどあります。質問をしたり、スライドにはないコードをデモしたりもしているのでスライドを見て気になった所を動画で見なおしたりと学習に役立ててもらえればと思います。

次の展開としてはさらに初級レベルに行くか、がっつりユニットテストをするかと行った所を予定はしています。まぁ要望次第ですね。

動画

Ustream.tv: ユーザー cognitom: 8時間耐久「クラスのクラス」 – 1/5, 2012/3/21(水) by Yusuke Ando. その他
Ustream.tv: ユーザー cognitom: 8時間耐久「クラスのクラス」- 2/5, 2012/3/21(水) by Yusuke Ando. その他
Ustream.tv: ユーザー cognitom: 8時間耐久「クラスのクラス」 – 3/5, 下北沢オープンソースCafe. その他
Ustream.tv: ユーザー cognitom: 8時間耐久「クラスのクラス」 – 4/5, 下北沢オープンソースCafe. その他
Ustream.tv: ユーザー cognitom: 8時間耐久「クラスのクラス」5/5, 2012/3/21(水) by Yusuke Ando. その他

CakePHP2.1.0が日本時間の3/5にリリースされました。熱心なCake職人の方にとっては規定の事実でしたが、まだそんなに齧ってないという人向けに今回のリリースのトピックを簡単にまとめます。

ウェブサイトがリニューアルされた

長い間利用されてきたサイトのデザインがリニューアルされて2｡0仕様に。それに伴ってマニュアルのページもスタイルが変更されています。またサイトのキャッチコピーも「CakePHPはウェブアプリケーションを素早くシンプルに少ないコードで作れます」というコピーに変わりました。

プラグインの検索ができるようになった

さまざまなプラグインの情報を登録して検索できるサービスが開始されました。もともとはCake Packagesというサイトでしたが作者の方がコアチームに参加して統合された形のようです。

PHP5.2.8以降に対応

PHPのバグに対応して必須の環境が5.2.8になりました。もちろん5.3系や5.4系でも動作します。最新のPHPの機能への実装はいずれ行わますが、CakePHP2.0の時点でnamespaceなどを見越した設計をしているので移行はスムーズに進むのではと思います。

PEARチャンネル経由のインストールができるようになった

なぜかPEARからのインストールを今更サポート

既存の機能のリファクタリング

既存の機能の応用的な部分の整理が進んでいます。通常のアプリケーション開発に関する部分は代わっていませんが、思い当たる機能を使っている場合は念のため確認です。

• Content Type Views
  JSONやXMLのビューを簡単に返せるように。
• Extending views
  Viewの継承を利用した画面レイアウトをサポート
• Plugin.view
  プラグイン内のビューをプラグイン名.ビュー名で指定できるように。
• エラーの改善
  debug()関数の表示がより読みやすく。
• 汎用イベントシステム
  コールバックやディスパッチの処理がイベントエンジンで置き換えられ拡張が容易に。
• テスト
  データソースからのフィクスチャの生成が可能に。新しいテストシェルはテスト対象のファイル名を指定すればよい。

  Console/cake test app/Model/Post.php
  Console/cake test app/Controller/PostsController.php

• コールバック優先度
  コールバックの優先度を設定するパラメータが追加。
• ThemeViewの廃止
  普通のViewで同じ事ができるように
• HTTPキャッシュの改善
• コアヘルパーのいくつかがライブラリに移行
  TextHelperやNumberHelperがどこでも使えるように。
• Deep saving
  関連データをどこまで保存するかを指定するパラメータが追加。
• 新しいACLエンジン
  ACLの設定をデータベースではなくファイルで行う仕組みが追加
• HtmlHelper::media()

  HTML5のタグが生成できるように

CakePHPはコアの開発チームが何度か入れ替わっていますが、安定して開発が続いていますね。開発チームを離れた人でもイベントには参加していたりコミュニティの安定感がやはり特徴です。反面、最新の機能のサポートは遅いですが、使い勝手を維持しながら着実なリファクタリングが続いています。
これまで使っていた人もこれから使う人にとっても安心度の高いフレームワークなのではないでしょうか。

誰でも参加できるコードレビュー、CodeReview.cafeの第2回は3/6に開催します。
参加希望の方はfacebookをご覧ください。

CodeReview.cafe #1

チーム開発をしていると何らかの形でのコードレビューの機会は多くあると思います。一方で個人で作業をするフリーランサーなどの場合はレビューの機会を持つことが出来ないのではないかと考え、コワーキングスペースに集まっている人でコードレビューをやってみるという集まりを下北沢オープンソースカフェで開催しました。

今回は5人のレビュイーが各自のコードやサイトを説明し、それに対して参加者がアドバイスをしたり意見を言うというような形式で行いました。

レビューの対象になったのは・・・

• @yando のCandyCaneのバグ修正
• @nakachon のWordPressのプラグインのコード
• @shinichiN のころぐのコード
• @yasulab のポートフォリオサイトのデザイン(Skypeでリモート参加)
• @cognitom のJavaScriptテンプレートエンジン、YinYang

どのレビューでもいろいろな気づきやアドバイスがあり、実際にコードのリファクタリングをしてみたりというような成果がありました。

Keep: 良かったこと

異なったレベルからのフィードバックが得られる
その時に集まった参加者によりますが、本人がまだ知らない観点からの改善案や関数を教えてもらえるというのがうまくいっていました。WordPressのテーマやプラグインからプログラミングに入った場合、グローバルな関数を多用したりインデントがおかしかったりというような点について長期的な改善案がその場でコーディングされたりしていたのは特にうまくいった例だと思います。またデザインなどについてのレビューもやはり色々な人に見せると類似したサイトを教えてもらえたり、ちょっとした画像サイズの乱れなどが指摘されたりしていました。

レビューを受ける側がアウトプットを出す
「○○についての勉強会」というフォーマットは教える側がコンテンツを用意しなければいけないですが、レビューという体裁の場合はフィードバックをもらう側がコンテンツを用意するので労力の負担がスケールしやすいように感じました。またレビューの日時が決まっていると、そこにあわせてアウトプットを用意しなければならないという作業の動機づけになるという感想もありました。

レビューの機会が無い人がレビューを体験できた
今回の参加者はほとんどがチームでのコードレビューをしたことが無いという方々でした。理由は人それぞれだとは思いますが、レビューを受ける機会を得る事ができるというのは大きな成果だったと思います。

Problem: 悪かったこと

共有できるレビューの指針が無い
通常、コードレビューをチームで行う場合はコードがチームの方針に適合しているかどうかをチェックすると思いますが、ランダムな個人が集まっているのでそういった観点からのチェックポイントが持ちにくいというのは工夫が必要そうです。一般的なコーディングスタンダードなどを考慮したり、簡単な記述揺れなどはそれでもチェックはできそうです。

成果物をうまく見せる方法の模索
今回はモニターに自分のPCをつなぐ方法や、オンラインでのコード共有、githubでの差分表示などでコードの解説を行いました。各自の作業環境がバラバラなので成果物をうまく見せる方法については工夫が必要そうです。

レビュー時間のコントロール
こみいった内容になってくるとどうしてもレビュー時間が長くなってきます。会社などではなく、カフェで気ままにやっているので構わないといえば構わないですが効率的にレビューを行う為の工夫はいずれ必要になってきそうです。

Try: 次やってみること

レビュイー向けのチェックリスト
レビューを受ける人がコードを見せる方法や説明のポイント、コーディングスタンダードの有無などについて事前にチェックする項目はあったほうがよさそうなので次回の開催の際にはフォーマット化しようと思います。

時間配分
今回は時計もあまり見ていなかったので、時間の計測などを試してみます。

と、いうわけでとりあえずやってみたわけですが大失敗というわけでも無かったので2週間後くらいにまた開催してみようと思います。参加者の皆さん、おつかれさまでした。またコードレビューに興味がある方は参加をお待ちしております。