PHPカンファレンス2015 スペシャルレポート
PHPカンファレンス2015 当日レポート［随時更新］
10月3日，大田区産業プラザPiOにて，PHPカンファレンス2015が開催されています。本稿では，イベントの模様を随時レポートしていきます。
イベント開始前の最終確認するスタッフの皆さん。この後、受付が開始されました。受付は1Fです。
本日のイベントの模様は、中継されています。
オープニング
実行委員長の前島有貴さんより，オープニングの挨拶がありました。今年は、PHP誕生から20周年ということで、会場を貸し切って2,000以上の参加者を見込むそうです。
その後、いくつか案内がありました。昨年好評だった，スポンサーブースを回るスタンプラリ―があるとのこと。全部回ると、景品がもらえるそうです。
お昼には、数に限りはありますが、お弁当とオムライスの販売もあるそうです。書籍ブースでは、サイン会が行われます。
- 12:00～12:30：『Laravelエキスパート養成読本』
- 12:30～13:00『PHPはどのように動くのか』
- 15:10～15:40『実践ドメイン駆動設計』
なお、懇親会チケットは、書籍ブースの前で販売されるとのことです。
廣川類さん「PHPの今とこれから2015」
オープニングの挨拶の直後、セッションが始まりました。
記念すべき第一回目のセッションということで、会場にも緊張感があったように思えます。
今年でPHPは、２０週年を迎えます。
最初は、PHPの生みの親、Rasmus Lerdorfさんのホビーなツールだったものが、世界中に広まり世界中のサーバで使われまでになりました。
PHPの今とこれからどうなっていくのか？ということと「７」をテーマにセッションがスタートしました。
PHP7は、来月リリース予定です。
PHP7になることで
・何がよくなるのか？
・ 何が変わっていくのか？
・どんなことに気をつけなければいけないのか？
ということを吸収してもらえればとのことです。
PHPとは？ということで、PHPの言語説明が始まりました。
・主にWebアプリケーションで使用されるスクリプト言語
・1995年の誕生以来、Webと共に成長、進化
サーバサイドプログラミング言語では、8割ほど使われていてスクリプト言語では一番のシェアを持っているそうです。
CMSシェアでは、WordPressが6割ほど占めていて、言語としてだけでなくアプリでもよく使われる言語です。
使用されているPHPバージョン分布によるとバージョン5.3が最も使われているそうですが、去年に比べ減少傾向のようです。
現時点で、サポートが切れているバージョン5.4以下を使っているユーザは、84%になります。
いかに、バージョンを上げていくのが難しいか、分かります。
ただし、サポート切れだからといって全く使えないというわけではなくパッチを当てるということも可能です。
バージョン5.0がリリースされたのは、2004年なので11年間バージョン5でした。
そんな中、バージョン6.0を出す予定だったのですが、Unicodeを全面サポート計画が失敗し、バージョン6.0がキャンセルとなりました。
その代わり、バージョン5.4に6.0の機能を搭載 「名前空間」「クロージャ」「Trait」など。
バージョン5.4から非常に完成度が高まりました。
バージョン5.5で「キャッシュ」バージョン5.6で「デバッガ」を搭載し性能を向上してきたのが、ここまでの流れです。
PHPリリース情報に「CVE-XXXX」のようなものが、出てきた時に今お使いのバージョンを確認してください。
セキュリティに脆弱性があったという意味なので、すみやかにパッチを当てる必要があります。
そして、メジャーバジョンアップとなる7.0が、来月リリース予定です。
・大幅高速化
・致命的エラーを例外補足可能
・古いSAPI、エクステンションの削除
・ヌル合体演算子(??)
・結合比較演算子(<=>)
・戻り値型宣言
・スカラー型宣言
・匿名クラス
といった機能が搭載されます。
一番大きなポイントは、高速化になります。
ベンチマークによるとPHP5.6と7.0では、劇的に実行処理時間が違います。
ただし、それでもわずかにHHVMの方が早いです。
それから、スカラー型宣言と戻り型宣言ができるようになりました。
型宣言は、今までのPHPの思想に反するのではないかということで、議論が続けられてきたのですが時代の流れとともに取り入れることになりました。
ただし、型宣言はstrictモードを明示的に指定しないと有効にならないので、今までどおりの型宣言無しでも扱うことができます。
それから、致命的エラーを例外補足可能になります。
今まで、致命的エラーを例外処理できませんでしたが、例外機構の見直しが入り例外処理できるようになります。
PHP7の互換性に関する変更は、次のようなものになります。
・エクステンション削除: ereg, mysql, msspl
・SAPI削除: 22種類 から 7種類
・ASP(<%...%>), Script(<script language="php"></script>)の廃止
・newオブジェクトの参照代入廃止
・PHP4形式のコンストラクタ: E_DEPRECATED
・エクステンションは要変更: http://gophp7.org/gophp7-ext/
PHPこれからどうなっていくのかというと
・PHP7.1開発が開始
・PCO (PHP Cryptography Objects)
・JITコンパイラ
PHP7.1に関しては、どんな機能を入れるかという議論が進められています。
ここで、コミュニティに参加し機能の提案をすることができます。
PHPの今とこれからが、詰まった素晴らしいセッションでした。
徳丸浩さん「今どきのSQLインジェクションの話題総まとめ」
岸田健一郎さん「Composerではじめるアプリケーション開発」
はじめにアンケートがありましたが、初心者向けセッションに変わる模様です。
詳しくはブログにも記載していただけるとのことです。
現在phpで開発するときに外部ライブラリをインストールするには基本的にComposerで行う方法が一般的です。
Composerは２０１２年３月１日に誕生1.0.0がアルファ版と言いながらほぼ完成した物が出来上がっていたものです。
では今から3年前より前はどうなっていたかというと・・・
Pearがありました！
が、この枠組は誰でも登録して公開出来るわけではなく、厳しいレビューに晒されてから公開する形でした。みんな辛い状況でした。
2008年に登場したOpenpearは、その辺りが改善されてSubcersionにより誰でも公開出来る形になりました。
非常に素晴らしい仕組みです。たが、それからGithubが大きく発展したので、Composerが作られました。
流行りだけではなく、決定的に世の中がComposerに移行するきっかけになった事件がありました。
それは、多くの人が使っているphpunitが、プロジェクトをPearからComposerへ移行するという出来事です。
phpunitはComposerの対応のインストールが非常に簡単になりました。
Pearで数十行怪しげなコードを入れてphpunitをインストールしていましたが、「composer install」とたった1行入れるだけになりました。
PHP the right wayという本を読むと・・・（今PHP開発をする上で幸せになる為の本。おすすめらしいです。）
この本のpsr-4のautoloadingについての説明が記載されていますが、requireやrequire_onceをたくさん書くべきではなく__autoloadを書こう！となっています。
この__autoloadですが、実はなにも考えずともComposerが勝手にやってくれます。
どうやってコンポーザーをインストールするかというと・・・
https://getcomposer.org/doc/00-intro.md
に記載されています。
curl -sS https://getcomposer.org/installer | php
でインストールできます。
composer.jsonにオートロードするphp等を記載することでrequireやrequire_onceを記載する必要はなくなります。
尚、composerについて何か知りたいという場合は
composer help
では出ません！
composer list
で出ます。
開発時のチップスとしては
バージョンを固定する、*などを使わない
update時にパッケージ名を指定する
などが紹介されました。
もしもコンフリクトしたら・・・のテクニックは
composer.lockを削除し
composer installを再実行
git add / git commit
したほうが良いとのことです。大抵、ツールでのコンフリクト解除は出来ないので、良い方法のようです。
ここまでで時間が来てしまいましたが、Composerについての理解の深まる、素晴らしいお話でした。
柏岡秀男さん「PHP初心者セッション」
有限会社アリウープの柏岡秀男さんによるセッションです。
2000年の頃から、ほぼ毎年参加してセッションされているそうです。
終始、場を和ませる冗談が入り混じり楽しいセッションでした！！
OS+Web Server+Database+Scriptの組み合わせでは、以下のものが多く使われています。
・LAMP Linux Apache MySQL PHP
・LAPP Linux Apache PostgreSQL PHP
・LEMP Linux Nginx MySQL PHP
では、どんな環境で始めたらよいか、次のようなものがあります。
・ホスティング
・レンタルサーバ
・AWS
・Microsoft Azure
・Google App Engine
・VMware
・VirtualBox
などがあります。
手軽にはじめるのであれば「XAMPP」「MAMP」といったものがあります。
実際にMAMPを利用したデモが行われました。
Apacheの立ち上げ方やphpMyAdminの紹介など。
PHPとHTMLを組み合わせて、どのように出力するかについて説明がはじまります。
PHPでHTMLを出力することもできるので、PHPを扱っているのかHTMLを扱っているのか意識する必要があります。
数回のデモと解説のイテレーションを繰り返しながら、進行されていたので初心者でも分かりやすかったのではないでしょうか？
「文法」「サーバサイドスクリプト」「PHP関数」「php.netのマニュアルの見方」「htmlspecialchars」といったことを解説されていました。
PHP初心者がこれから学ぶ際に注意すべきまとめとして「PHPのマニュアルを活用すること」「入力値や出力値に注意すること」「入門書はよく選びましょう」「怖がっていてはいけません」ということを話されていました。
とくに「とにかく書いてみる！」ということが大事ということで、セッションが終了しました。
PHP初心者が、このセッションを受講していればステップアップに繋がる素晴らしいセッションだったと思います。
畠山大有さん＠クラウドから地上まで。Azureがどうやって動いているのか、掘ってみよう」
中村けん牛さん「超高速WordPress?PHP7 vs HHVM vs PHP5.6」
概要
・WordPress とサーバをチューニングしてどこまで高速化できるのか？というテーマ
・高速化の技術と考え方を PHP7, HHVM, PHP5.6 のベンチマーク付きで解説されていました。
登壇者はプライム・ストラテジー株式会社 代表取締役の中村さん。
個人では詳解WordPressなどの本を執筆，WordPressのプラグインを開発，Webメディアで連載記事を執筆するなど，活動は多岐に渡ります。
プライム・ストラテジーさんでは1億PV/月超えのメディアサイトなどの構築，サーバ運用をしており，他にもWordPress仮想マシンイメージ kusanagi を開発しています。
kusanagi のページ http://kusanagi.tokyo にアクセスすると，ページ右上に Run time 0.005s と表示されます。これはサーバでWordPressを実行している時間です。
ページキャッシュを使わずにこの実行時間を実現しており，現状500〜1,000msが普通ですが，kusanagiは100倍の速度をたたき出しています。
なぜ高速化が必要なのか？
第一に，PHP + MySQL の動的なシステムなので，静的なHTMLページに比べると動作速度の点で不利になります。
第二に，CPUの開発ロードマップは動作クロック（周波数）よりもコア数を重視しています。
同時処理能力は向上していますが，ほとんどの処理が直列実行であり，直列の限界が周波数の値になるため頭打ちになります。そのため，ハードの進化による処理速度向上を期待しづらくなります。
最後に，オウンドメディアやサービスサイトでは
・PV獲得の機会を失わない
・UXを向上
・検索エンジンを最適化
・Webサイトの信頼性，安定性を向上
以上の観点から高速化が必要になります。
WordPressの高速化はサーバサイド(サーバ，WordPress)での高速化とフロントエンド(HTML, CSS, JS)での高速化に分けられますが，今回はサーバサイド側の話になります。
サーバサイドの高速化とは？
HTMLページのロード時間を短くして，1秒あたりのリクエスト（アクセス）数を増やすことです。 ここで言うHTMLページのロード時間は，HTTPリクエスト送信，WordPress実行，それとHTTPレスポンス受信までの時間の合計になります。これを短くすることを目指します。 なお，ロード時間は Firefox の Firebug のネットタブで確認できます。
ページロード時間と1秒あたりのリクエスト数の関係
1コアでページロード時間が500ms だった場合，1秒あたりのリクエスト数は2 100ms にチューニングできたときは10 2コアにスケールアップすると20 さらに4コアにスケールアップするとページロード時間は変わらず100msになります。
リクエスト送信と受信には通信時間，WordPress はPHPの実行，MySQLの実行，翻訳処理の時間が含まれます。 翻訳に時間がかかるため，日本語と英語版のWordPress でも倍くらい時間が違います。
ページキャッシュを使わずにWordPressを高速化する
まず，LAMP （PHP5.4）にWordPress4.3日本語版をいれた環境を用意します。 この時点でロード時間は246ms，リクエスト数は4.9リクエスト/秒です。
APC（PHP アクセラレータ）を導入すると，246msから133msと約1.85倍早くなります。
このAPCは簡単に導入できます。CentOS6の場合，root権限で以下のコマンドを実行します。
yum install -y php-pecl-apc
service httpd restart
PHPアクセラレータはPHP5.5以降はOPcacheを使います。 PHP5.6とOPcacheの組み合わせで，246msから110msと約2.2倍の速度になります。
この状態でさらにMySQLのクエリキャッシュを導入すると，110msから102msと約1.1倍の速度に。 MySQLのクエリキャッシュはデフォルトのWordPressで導入されているので，基本，設定は不要です。 設定する際は以下の通りに行います。
query_cache_size = 64M を my.cnf の mysqld セクションに記述
MySQLサーバをrestart
さらに翻訳キャッシュを導入することで，102msから72msと約1.4倍の速度になります。 そして，PHP7RC4とOPcacheの組み合わせで約2倍になり，72msから36msになります。 最後にHHVM3.9導入で30msまで高速化することができました。
ここで時間切れとなってしまいました。
WordPressの高速化について，実例を挙げながらとてもわかりやすい説明をされていて，勉強になるセッションでした。
寺田渉さん「PHPの基本クイズ ? この動き、あなたは知っていますか？」
プログラム & 翻訳が趣味だという寺田渉さんのセッションは、PHPでハマりそうなポイントをクイズ形式で紹介されました。
PHPの他の言語にはない仕様を題材に、クイズが展開されていきます。
一部紹介します。
・== ではなく === の必要性
・switchも==で比較していること
・number_format関数は、引数にfloatを受け取るので、大きい値を引数に渡すと丸められてしまうこと
・empty関数に文字列の '0' を渡すとtrueを返すこと
・if ($var) と if (!empty($var))の動作の違いについて、前者の書き方だと$varが未定義時にNoticeがでてしまうこと
・PHPのみのファイルで、?>の後ろに空白があるとhttpヘッダは出力済になるためリダイレクト等はできず、代わりに真っ白の画面が表示されてしまうこと
・配列の + と array_merge()の違い
var_export($a + $b);
var_export(array_merge($a, $b)); ・foreach で 書き換え たら異変
$array1 = [1,2];
foreach ($array1 as &$val) {
$val = 0; //0で書き換え
}
$array2 = [3,4];
foreach ($array2 as $val) {
//何か
}
var_export($array1); // [0, 4] なぜ 4 ここに！？
var_export($array2); // [3, 4]
書き換えならarray_walkを使いましょう
など、面白い問題を20問出題されていました。
Rasmus Lerdorfさん「基調講演」
PHPの開発者Rasmusさんの基調講演、満員御礼で始まりました。
20周年は「すごい」ではなく、「ただただ、歳を取ったな」というだけの感覚
スライドに１９９５年のインターネットを物語るPHP ANOUNCEMENT JUNE 8,1995があります。
この文章は当時の問題のリストアップをしているタイムカプセルのようで、当時のPHPは現実の問題解決にフォーカスしていました。
元々は、C言語を使ってロジックを書いていきTypoをした時にエラーを出すという事
基本はスタックベースでプッシュしてゆく仕様でした。
当時すごく良く出来ていると思ったものは今から見ると失敗に終わりました。
今はPHP7で色々なものを織り込んだものを出せるようになりました。
PHP7はセカンダリーのOpCacheを持てるようにしています。
ファイルベースでコンパイルされたものは4倍、メモリ上のキャッシュでは１０倍の速度が出るようになりました。
いままで、CLI（コマンドラインインターフェイス）のPHPではキャッシュが使えなかったけれど、７では使えるようになりました。
これにより、コンポーザーの動作は２倍の速度が出るようになっています。
つまり、もともとのPHPのスピード改善が２倍くらいあるのでPHP５でコンポーザーを動かすのとくらべて４倍の速度改善がされているともいえます。
他にも新機能は色々あります。
- スタティックアナライザの書き方
- returnTypeで特定のタイプが返せるように成りました。
- stritタイプを準備しているので、型に問題があればエラーを返せるようになりました。
- クロージャーも１回限りしか使えないような書き方が出来るようにもなりました。
- NullCoalesceOperatorが実装されました。
- SpaceshipOperatorが実装されました。
スターウォーズのX1のようなオペレーターが実装されました。
”<==>”これです。
- FatalになっていたエラーもExceptionとしてキャッチできるようになりました。
- クロージャーコールを追加されました。
- 特定メソッドの上でクロージャーをコール出来るようになりました。
- PHP4の非推奨なメソッドを多く削除しました。
ereg等です。
- 新しい予約語も追加されているので注意。
- uniform variable syntax
PHP7はすべて左から右に解釈するようになっていますが、PHP5の順序で解釈させるようにする方法も準備しています。
- preg_replaceをpreg_replace_callbackで実装する方法がスライドで説明されました。
- どうやって２倍の速度が出せるようになったのでしょうか
Wordpressでの１リクエストで調査しているが２倍の高速化を果たしたことを証明するグラフが表示されました。
２０年前からアップデートしている言語にも関わらずどうやって２倍になったのか
インストラクションの半分を削除し、今までと同じように動くことを求められるため、大変だった。
例えば、メモリの消費を大幅に抑えました。CPUキャッシュからコンパイラから諸々見ました。
- JIT?
JITはまだPHP7には無いんですが、かえってエキサイティングな情報でしょう？JITを使わずにこれだけのパフォーマンス改善が行えているのですから！
これからJITを導入するオプションが残っているので、更なるパフォーマンス改善が望める。
- 一連の数字を挙げましたが、みんなでベンチマークしてみてください！
プレゼンの中で出した数字の出し方については詳細に情報を提供しています。
続いて様々なアプリケーションでの比較をしていきます。
- Drupal8
レイテンシーは半分に下がっている。hhvm3.7よりも早い！
- Woedpress4.1.1
PHPは5.6の時代から見ると3倍くらいの性能に。hhvm3.7の速度に近づいている・・・でもhhvmに勝てなかったので・・・gccの機能、FDOを用いバイナリの最適化を図り、ほぼほぼ同じ速度になりました！
- phpBB3.1.3
hhvm3.7よりも早い！
- MediaWiki1.24.1
hhvm3.7の速度に近づいている。mediaWikiについてもhhvmは最適化を図っています。特に最適化を測っていない言語については、PHP7の方が早い
- Opencart2.0.2.0
あまり速度向上が認められませんでした。このアプリケーションのほとんどの時間がDBのアクセスであるためです。
- WardrobeCMS 1.2.0
PHP5と比較して2倍の性能向上が見られる。 LaravelやSymfonyのようなフレームワークを用いている人はこの2倍の効果を感じることが出来るはず。レイテンシーが半分は体験としてわかるはず。クリックすればわかるレベル。
- Geeklog2.1.0
他と同じような結果
- Magento1.9.1.1
そもそもリクエストできる数が少ない数十程度である（数百から千さばける）
- Traq3.5.2
2倍くらいの差が出た。
- PHP5からPHP7への移行を数々のアプリケーションで試した結果
Avalonというアプリで修正が必要だったが、他ではそのまま何もせずにPHP7を採用できた。
- Cachat、Moodle-2.9-dev（hhvmでは動かず）、ZenCart1.5.4
みんなテストしてください！もうすぐリリースされますので。問題があれば教えて下さい。
リリースして大量の問題が報告されると、開発チームは不機嫌になりますが、リリースする前なら、ニコニコ修正します。
Vagrantのスクリプトも準備しています。
この仮想マシンはDHCPで接続も可能です。
開発環境のコピーも提供します。Vagrantのコンパイルで、とても簡単にPHP7とPHP5にスイッチできます。
バイナリーをmakeすることも可能です。
マニュアルでのインストール方法もあります。
PHPのバグを見つけて下さい！
バグが無いということであればバグフックスを修正する側に回ってくれても構いません。
このサイトです。
このバグを報告するサイトではランダムでバグを表示する機能があります。
バグではないという見極めも大事です。むしろほとんどがそうです。
- 質疑応答で・・・
Q:仕事で7に移行するときに気をつけることは？
すぐに使ってね！（笑
本当はphp7.0をプロダクションで用いる事は無いと思うが7.1までは待たなくても良い位の信頼度があるのでそれくらいで使えます。
Q:mb系のFunctionが通常のFunctionと一緒になることはあるか？
A:mb系のfunctionが融合する可能性は今のところ無い。いつかするかもしれない。
いまでも例えばユーザースペースを使う等で実施できる。
7.0は今までどおりのmbは別で実装されている。
Q:パフォーマンス向上の項目を教えて下さい
A:すべてパフォーマンスに関する要素を書き出す事は出来ない。
言語自体もでも早くする仕組みを改善している。あまりにも多い。
ファイルベースでのキャッシュによるリスタートの速さが挙げられる。
Q：PHPでは、推奨するフレームワークがあるの？
A：それって結局はどのフレームワークがいいの？って質問でしょう？（笑
私にフレームワークを聞くのは間違っている。PHPの開発者ではない。Cの開発者だから。
私のフレームワークに関する知識は「なんでこんなに遅いんだろう」と汗を掻く位しかない。
しいて言えば、モジュラー構成になっていて、必要なものを選べるようなフレームワークがいいと思う
Q：PHPのPはパーソナルだーという話があるが実際はどうか？
PHPはPHPでPは・・・という話はしない！（笑
背後になんの意味もないの？という話をする人の為に話す事はあるけど。
PHPはPHPです。
Q：古いエクステンションに合わせて後方互換を保ったものを準備するつもりはありますか？（Pecl等で作られているので
C言語で書かれたモジュールを準備するつもりはない。
ただし、後方互換を実装した数百という例があるので、やるべきことはパターンを見て、自分で、PHP5のコアに入っている物もあるので、それをPHP7に実装していく事。
yoku0825さん「MySQL 5.7にやられないために知っておいてほしいこと」
MySQL 5.7 とは？
・2年半ぶりにメジャーバージョンアップしました。次はMySQL5.8になるようです。
・新しい機能がたくさんあるので，アップグレードしたいバージョンではありますが，たくさんの罠がひそんでいるようです。
これまでの MySQL
・2008/11 MySQL5.1
・2010/12 MySQL5.5
・2013/02 MySQL5.6
・2015/xx MySQL5.7
2015年8月に5.7.8-rc2がリリースされました。rcとはリリース候補版を意味します。
5.6の一般公開版の時点で，Oracleは18〜24ヶ月で次のメジャーバージョンをリリースする予定と言っており，リリースがずれこんでいるようです。
MySQL5.7の新機能について
MySQL5.7で新しくなった機能等について4つのカテゴリにわけて解説されました。
一部ご紹介します。
＜最低限これは知って欲しい＞
・16桁ハッシュのパスワード廃止
・default_password_lifetime
・sql_modeのデフォルト値変更
＜一応知っておいてほしい＞
・mysql.user.passwordカラムの廃止
・認証周りの構文の変更
・secure_file_priv
＜これは知っているとちょっと得する＞
・sysスキーマ
・GTIDのオンライン有効化がサポート
・MySQLネイティブの全文検索が日本語対応
＜知っておいても損はない＞
・innodb_buffer_pool_sizeのオンライン変更がサポート
・sync_binlogのデフォルト変更
・マルチソースレプリケーション
まとめ
新機能等の発見報告は，
・日本MySQLユーザ会メーリングリスト
・MySQL Casual Slack
・Qiita，ブログその他自身の情報発信場所
などでされています。
楽しいPHP7+MySQL5.7ライフを！
30分のセッションでスライドが172枚ととてもボリュームがあり，MySQL5.7について満遍なく知ることができるセッションでした。
大谷祐司さん「Hack言語に賭けたチームの話」
秋山顕治さん「Electronからクロスプラットフォーム・アプリケーションの歴史を考える」
久保達彦さん「フリマアプリ「メルカリ」の急成長を支えるエンジニアリング」
メルカリのインフラについて
インフラはさくらとAWSのハイブリッド構成になっています。
専用サーバはコスパが高く性能が高いので，サーバの台数を100台程度で抑えることが可能に。
クラウドは突発的な負荷の対応や，試験用，使い捨て用にサーバを確保しやすいなど，柔軟性が高いものになっています。
PHPで高速なAPIサーバを実現
各所で細かくチューニングしていて，機能を絞ったものでも対応できるため，軽量なフレームワークであるdietcakeを使っているそうです。
他にも，高速なサーバを実現するために以下のようなことを行ったそうです。
・キャッシュを使ってなるべくサーバに仕事をさせない
・New Relic によるモニタリングをし，速度を監視し問題があれば修正
・php-Parallel-Prefork というライブラリで非同期処理を行う
・2015年7月にPHP5.6にアップグレードし，レスポンスが改善
nginx によるハイパフォーマンスネットワーキング
メルカリのアプリから，HTTPSもしくはSPDYでnginxに接続し，そこからHTTPでApacheとmod_phpで構成されるAPIサーバに接続しに行きます。
メルカリはnginxを多用しています。
スケーラビリティが高く，数万もの同時接続を軽快に捌くことができます。
また，高速なHTTPS通信を提供しています。
今はSPDY/3.1を使用していますが，iOS9 の普及率を見てHTTP2に変更する予定だそうです。
検索結果のキャッシュ
検索処理はキャッシュを使わないとかなりサーバに負荷をかけてしまうので，なるべくキャッシュできるように努力しているそうです。
続きは公開している資料を参照してくださいとのことでした。
Slack で ChatOps
デプロイや勤怠管理，アラート通知，CIの手動実行など，様々なことをSlackでできるようにしています。
いろんなサーバからSlackに通知する際，
・各サーバ上のクライアントがIncomming Webhooks の URL を知っておく必要がある
・各クライアントで利用している言語がバラバラ
・通知処理を書くのが面倒
といった問題があり，プロキシを立ててそれと通信するクライアントを各サーバに配置することにしました。
そこで作ったのがslackboardというライブラリです。
slackboardとは久保さんが作成したライブラリで，slackboard，slackboard-cli，slackboard-logで構成されます。
slackboard-cliを使うとechoの後に記述した内容をSlackへ通知することができます。
$ echo mercari | slackboard-cli -c tech-test -s slackboard-server:29800~
slackboard-logを使うとコマンドが失敗したときにそのログをSlackへ通知することができます。
$ slackboard-log | -c tech-test -s slackboard-server:29800 -- ls hoge~
ゼロダウンタイムデプロイ
以前のデプロイではrsyncを複数回使っていたそうですが，たくさんの500エラーがでてしまっていたそうです。
これを解決するために，ngx_dynamic_upstreamというライブラリを使いました。
プッシュ通知基盤
基本的に外部のサーバと通信するのでとても重かったそうです。
そこで，Gaurunを作ってそれを使ってサーバ構成を見直し，nginxにまとめる形に直して対処したそうです。
ログ分析基盤
ログ容量は1日200GBあり，各サーバからfluentdに転送するまえにDataTrackというライブラリを使っています。
Norikraからfluentdを経由して，データの種類によってMackerelとSlackに振り分けています。
しかし，ログが分析に適していなくて職人芸が必要だったので，ログを設計し直しました。
Pureeを使うとアプリからfluentdにログを取得でき，OpenRestyを使うと高速なWebアプリケーションを作ることができます。
PascalはOpenRestyのおかげで，ログのフォーマットを分析に適した形にすることができました。
アプリ内アクションやA/Bテスト分析など，適用できる範囲を広げていくそうです。
まとめ
いろいろ工夫して高速なAPIサーバを実現しました。来年は7対応をするかも？
メルカリではエンジニアを募集中です。
席は満席になり常にシャッター音が鳴り響いていて，注目の高さが伺えるセッションとなりました。
富所亮さん「Behat Driven Development」
富所さんは、現場に自動テストを導入した話をされました。
まず、ご自身の経験から自動テストにまつわる悲しい過去を語られました。
・何度も同じ箇所でデグレ。
・でも、自動テストを追加する工数が取れないと言われる。
・でも、自動テストのやり方がわからないと言われる。
・RspecとかCapybaraはRubyのツールだから分からないと 言われる。
・バグが起きた時の再発防止策で「頑張る」とか言われる。
自動テストがない状況なので、作業が積み重なり自動テストを導入できればなと思っていたそうです。
そこで、２年前に出会ったのがBehatです。
欲していたものが全てBehatにあったそうです。
Behat自体は、BDDのツールですが、BDDとして使っていないそうです。
単純に、自動テストツールとして使っているそうです。
TDDやBDDを導入するのは、生半可では回らないので、ひとまず自動テストを導入してみたそうです。
自動テストの利点
・デグレがよく起こる箇所の事前検査
・ビジネス的に重要な箇所の事前検査
・テスト手順が煩雑な箇所の検査
・放置状態の機能の死活監視
富所さん自身が、個人的に感じる利点
・リリースに自信がでる。(よく聞く)
・リファクタリングに勇気がでる。(よく聞く)
・面接の時言える。
・自動テストは、意識高そう。
ただし、現場に自動テストを導入しようとするとこういったことがよく起こるそうです。
「テスティングツールの学習コスト」「テストに対するコストが高いと非エンジニアに対して理解を得にくい」「テストを書いたことがないエンジニアの精神的な障壁」
こういったことに、当てはまる人たちへのケアができていないと、そもそも自動テストというものが受け入れられないそうです。
次に、自動テストの失敗談についてお話されました。
ケース1) テスト作れない
テストが作れないという問題があり、原因としては 「テスト自体をやったことがない」「テストについて教育や学習の時間が取れない」というところらしいです。
そもそもテストを作れない理由は、「教育工数が取れない組織自体に問題」「自動テストへの心理的ハードルの高さ」「効率のいい運用ができなくて、時間がなくなっていく負のスパイラル」ということがあげられるそうです。
ケース2) 自動テストの遺跡
CIがないとテスト自体が、遺跡になります。
プロジェクト開始当初は、頑張ってテストを書いても、意識が高い人はテストを書くがプロジェクトが佳境になったり緊急対応時にきちんとテストを書かない人が出てくる。
また、特定個人の環境でしか動かないテストも存在し、遺跡になってしまうとのことです。
CIが不在ということが、問題。
誰の環境にも依存しないところできちんとテストができる環境がないと特定の個人に依存してしまうから、自動テストが回らないそうです。
ケース3) テストの放置
Jenkinsにテスト実行ログやグラフは出ているが、ただテストを実行しているだけになっている場合。
成功・失敗といった結果がMLに飛んで来ているが、誰も反応しなくなります。
最悪、テストが失敗状態でリリースが重ねられると自動テストされる意味がなくなってしまいます。
リリースツールは、テスト失敗時にリリースできない状態を作ってあげないと、自動テストがリリースに影響を与えられないとのことです。
通知が、MLだと他人事になってしまいます。例えば、sys-xxx@のような人を特定できないメールアドレスだとそうなってしまいます。
自動テスト導入後の運用も含めてトータルに考えないと、あっという間に廃れてしまうそうです。
富所さんの体験談だそうですが、自動テストを押し付けても現場に浸透しなかったそうです。
現場における平均レベルのエンジニアが自然と実行できるレベルにまで噛み砕かれている状態でないとうまく浸透しないとのことです。
ここから、Behatの話になります。
Behatって何?
・BDDテストフレームワーク
・Cucumberにinspireされた
・テストシナリオはGherkin形式
・PHP製 (ココ大事)
Behatで出来ること
・デフォルト状態では何もない
・テスト(feature), アサーション(step)は自分で作る
・一般的にはextensionを導入して使う
ここから、実際のBehatテストコードをもとに解説が始まりました。
Gherkin形式で書かれたfeature(テストシナリオ)にはPHPコードが一切出てきません。
step(テストコード)にfeatureで書いたものが、割り当てられていきます。
Behatはバランスが良いため、Behat と現場の相性がよいそうです。
自動テストの成功を阻む要因としてこのようなものがあります。
1. テストツールの教育不足
2. 個人依存のテスト実行環境
3. 導入後の通知や運用ルールの不備
Behatであれば、これらの要因に対して効果をもたらすそうです。
1. テストツールの教育
・PHP製という強み
・Qiitaや、後述の参考資料の内容を1時間程度やれば、十分把握可能
・E2Eテスト前提であれば、Mink拡張を利用するだけなので、 PHPのコードは一行も書かない
2. 個人非依存のテスト実行環境
・Composerでinstall可能
・近代的なCIツールなら簡単に構築可能(前述)
3. 導入後の通知や運用ルール整備
・最近のCIツールは通知拡張を備えている(slack とか)
・テスト失敗時にdeploy出来ないフローにする
・PR開発によるコードレビューは相性が良い
近代で自動テストを回すために必要な構成要素は、次のとおりです。
・VCS
・Bitbucket
・GitHub
・CI
・wercker
・Jenkins
・Travis CI
・Notification
・slack
・HipChat
・idobata
これらを正しく扱うことで、テストが実行されてかつテストがOKだった場合のみデプロイが走り通知がいくということができ、自動テストが運用できるとのことです。
ご自身の自動テストへの取り組み体験をもとに非常に参考になるセッションだったのではないでしょうか？
新原雅司さん「いまどきのPHP開発現場 -2015年秋-」
新原雅司さんは、いまどきのPHPを取り巻くツールの紹介と何故、そのツールが使われているのか？どういった考えでつかうのか？といった観点で、お話されました。
まずは、PhpStormの紹介からです。
・JetBrains社のIDE（有償）
・動作が軽快、静的解析、オールインワン
・Vimmerも納得のIdeaVIM
vimと比較した時に、プラグインをインストールする必要がなく、最初から必要な機能がそろっていて統一したUIで操作できるというのは、大きい利点だそうです。
実際に、PhpStormを使ったDemoを行い、補完機能についてご紹介されました。
PhpStormの前後のコンテキストを理解した補完や構文解析は、vimなどのエディッタにはできないリッチな機能です。
Phpstormには、Gitクライアントが入っています。
コミット時にPSR-2といった規約に合わせて、自動で整形を行ったうえでコミットを行うということができます。
次にVagrantの紹介です。
・プロジェクト毎に独立した環境
・自動構築
・チームで同じ環境を利用
・運用環境と同じ環境
導入ポイント
・PHP コードと一緒に管理
・とことん自動化（vagrant upで完了）
・プロビジョニングは VM の中で実行
・Shell Script -> Ansible が楽
Ansible以外にもプロビジョニングツールがありますが、Ansibleが比較的簡単なのでオススメだそうです。
次にフレームワークの紹介です。
・コンポーネント指向が主流
・Symfony / Zend Framework / Aura
CakePHP 3 / Laravel / BEAR.Sunday
・コンポーネントを分離して利用できる
・他のフレームワークのコンポーネントを利用
最近のフレームワークはコンポーネント単位で、切り出して別のフレームワークで使えるようになっているのが、今の主流だそうです。
フレームワークの付き合い方として、フレームワークのためにアプリケーションがあるのではなく、アプリケーションを作りやすくするためにフレームワークを部品として使っていることを見誤らないことが大事だとおっしゃっていました。
次にTravis CIの紹介です。
・GitHub と連携
・git push / PR を検知して実行
・ .travis.yml に実行内容を指定
・sudo が実行できる（何でもできる）
GitHubとしか連携できないので、GitHubを使わない場合は、その他のCIツールを使うことになります。
次にScrutinizerの紹介です。
・コードフォーマットや静的解析のSaaS
・指摘表示
・有償ならテスト実行も可
・Travis CI などと組み合わせる
コードレビューをしてくれるサービスと考えられるとのことです。
次にHerokuの紹介です。
・PHP 5.5 / 5.6 / 7(RC4) / HHVM
・PHP 拡張や httpd サーバ、設定が可能
・無料枠あり（検証環境にも便利）
・アドオンが豊富
無償枠があるので、すぐに使えるところがいいところだそうです。
最後にまとめです。
「ツールやサービスに任せる やるべきことに集中」
「ツールに導かれる」
ツールを使い続けることで、今まで知らなかったことをノウハウとして学ぶことができるという言葉で締められました。
これから、ツールとの向き合い方を考えさせられる素晴らしいセッションだったと思います。
arimoさん「DMMのハイパーメディアオタサーの姫arimoが語るPhalcon」
前田雅央さん「営業・運用を支える 気付ける 管理画面」
今回紹介するのは、スマホ向けの広告配信で、より効果の良い媒体に出すアドネットワークの為のアプリのZucksの管理画面のお話です。
アドネットワークとは、広告主からお金を集め、様々な配信調整を行い広告主様に報告するというサービスです。
管理画面を作る上での工夫は・・・
- ・コミュニケーションの工夫
- ・運用を楽にするため工夫
- ・機能開発のデプロイの工夫
- ・データの変化に気づくための工夫
管理画面って・・・
ユーザー権限管理、データのCRUD処理 レポーティング機能 データ出力（CSV）
がある。
あるある事案として、長期運用されてくると、
- 使われているかわからない機能画面がある
- 使いづらい画面でも利用者が使いこなしてしまう
- 何度か作り直したくなる病が発症するが、諦める。
- 裏機能がいつの間にか出来る
今日は限定的な管理画面についての話をします。
コミュニケーションの工夫
「何故必要なのですか？を聞く」
とは言え答えてくれない心の声があります。
「本当は・・・」
というもの。エンジニアには聞こえないので・・・観察力が必要です。
例えば「最初に絞り込むのは」何ですか？みたいな質問が必要になります。
でも、その質問どうやって思いついたらいいのでしょう？
日々観察から思いつけるようにしましょう。GoogleAnalyticsも、期間は右上に表示されています。これは、期間が表示要素として重要だからです。
つまり観察力が必要なのです。
例えば、ページャーっていつもあるけど、直接Xページに行くというのはほぼない。必要なのは最初、前へ、次へ、最後でいいはずなのに・・・
Xページというのが出てくるときは何かあると気づくことが出来ます。
フォームは最低限実装に。何も困ってない。を旗印に開発すると良い
- 「運用を楽にするための工夫」
共有できるURL URLを伝えれば同じ画面が見られない
/use/articles/listというURLだとアクセスしても見れない。
/user/brtriver/articles/list
なら見える。URLはとても大事です。
- 「更新履歴をシンプルに表示」
営業：案件の単価がいつの間にか３０円になってるんだけど？
開発者：え？いつのまにか？
営業：変更してないはず
開発者：調べてみますね。
（営業さん悪くないんです。人間は忘れるものなんです。）
なので、履歴を保存して見られるようにしましょう。
Entityを配列に変換したものをひたすら保存しましょう。
表示は
priceとかその辺は何もいじらずなんとなくわかるならいいのです。
ユーザーIDとかもそう。IDのままでもいいのです。
array_diffがあるので、これでいい。
- 「嫌な情報を事前に把握する」
タイムアウトで５００エラーとか。
問題が置きてから気づくのは当たり前なので、その前に気が付きたいものです。
Symfonyだとルーティング定義名で何がどう遅くなってるかと出てくるのですが、ロジックとしては、なんらかのしきい値を超えたらWarningのログを残すようにしましょう。
Slackで通知するとまた見やすく便利です。
monolog便利。fingers_crossedで詳細なログを残すようにしてます。
そういうのが判れば・・・
「Aさん、レポートの取得期間が長すぎて時間がかかりすぎているようなので、期間を短くして試してもらえますか？」
と聞くことが出来るようになります。
エンジニアからコミュニケーションを取れるようになります。
- 「機能開発のデプロイの工夫」
導線を用意せずページを増やして確認
- /report
- /report2
という形で本番のデータでテストします。もちろんこれは、ある程度大きい物であることが前提です。
既存のコードに修正せずに対応することが出来るようになります。
- 「データの変化に気がつく仕組み」
管理画面からの通知をメールとSlackに連絡すると、そこでやり取りが発生するようになります。
とはいえ、クリティカルな通知はダメです。
Slackが時々失敗するからです。クリティカルな通知なのに「Slackへの通知が失敗しました！」という通知が来てしまったら困ります。
気づける管理画面はサービスの質を向上させます。
竹澤有貴さん「PHPデプロイツールの世界」
このセッションでは，デプロイツールの使い方ではなくアプローチの仕方の違い等について説明がなされました。
FTPを使い手動で行う，rsyncでアップロードするなど，デプロイする方法はたくさん存在します。
また，PEARからComposerに，ライブラリなどはプロジェクトごとで管理する方針に変化しています。
GruntやGulpなど，フロントエンドもまた進化し続けています。
デプロイツールの主なタスク
・ライブラリのインストール
・フロントエンドタスク実行
・複数のリモートサーバ（Vagrant, dockerなど）へ接続
・ローカルタスクの実行 (rsyncなど)
これらをPHPに統一したい，他の言語でやろうとするとむずかしいのでそんなときにPHPデプロイツールを使いましょう。
3つのツール
ここからは，3つのツールを比較する形で説明が進みました。
第一にEnvoy。
リモートサーバタスクツールでデプロイツールは実装されていません。
Laravel の公式に載っていますが，Laravelと親和性はありません。
第二にDeployer。
完成度が高いリモートサーバタスクツールです。
第三にRocketeer。
Capostranoスタイルで作られており，デプロイタスクツールになります。
高機能多機能ですが，サービスロケータを多用していてソースコードを読むのは難しいです。
タスク実行のアプローチ
3つのツールをタスク実行のアプローチという観点で見てみます。
まずEnvoy。
Envoy.blade.php に実行するタスクを書き，コンパイルして通常のPHPコードに変換します。
symfony/processによる接続を行い，タスクごとにリモートサーバに接続します。
次にDeployer。
deploy.phpに実行するタスクを書き，それを読み込みます。
phpseclib/phpseclibという使い勝手が良いライブラリを使い接続します。
最後にRocketeer。
サービスを全てコンテナに入れてからタスクを実行します。
Task Queueは実際は配列になっているなど，とても複雑になっています。
並列のアプローチ
今度は，各ツールを並列のアプローチで見てみます。
まずEnvoy。
それぞれのプロセスがタスクを実行し，リモートサーバ上にプロセスが立ち上がります。
シンプルな並列処理です。
次にDeployer。
ReactPHPを利用した非同期処理です。
proc_openを利用し，各プロセスがタスクを実行します。
最後にRocketeer。
pcntl_forkによるプロセスのフォークを行います。
各プロセスがタスクを実行します。
タスクのアプローチ
最後に，各ツールをタスクのアプローチで見てみます。
Envoyは記述したタスクのみ実行し，タスクの前後に処理を行うなどの仕組みはありません。また，ローカルタスクはタスクごとに記述します。
Deployer，Rocketeerはタスクの前後の処理は簡単に記述でき，ローカルタスクについてはDeployerはリモートタスク内で，Rocketeerはタスクごとに実行可能です。
まとめ
同じコンポーネントを使っているがアプローチはそれぞれ異なります。
人気度で選ぶのではなく，使ってみてツールの違いやアプローチの違いを知っておくとトラブルに対応しやすいです。
各ツールの仕組みを理解しながらPHPのデプロイツールについて知ることができたセッションでした。
蒋池東龍さん「PHPあるあるパフォーマンス対決」
蒋池さんは2年前の「PHPコアから読み解く定石の嘘ホント」の続編として似たようなスクリプトで、どっちの方がパフォーマンスが高いのかを論理と数値から確かめた話をクイズ形式で発表してくれました。
数値に関してはfor分で回してmicrotimeで純粋な実行時間を計測、論理はPHPの最小単位の命令のスクリプトのオペコードで見ていきます。
セッションの目的
・数値は大切だけど数値だけでわかったことにならない、だけど論理だけで頭でっかちにならない
・数値と論理からパフォーマンスを考えてもらってPHPの楽しさ奥深さを考えてもらいたい
メソッドチェーン
メソッドチェーン vs 非メソッドチェーン(10万回計測)
結果としては非メソッドチェーンの方が早いです。
オペコードを見てみると、メソッドチェーンの方は変数を多用しているため無駄が多くなり遅くなっているおり、非メソッドチェーンは1つの変数を使い回しているため無駄がないという結果になっています。
異次元配列の書き込み
高次元 vs 低次元(100x100x100回計測)
結果は低次元の方が早いです。
オペコードを見てみると、低次元の方が処理を分散して値を入れているため速くなっています。
関数の引数
スカラー vs 配列(10万回計測)
結果は配列の方が早いです。
オペコードを見てみると、関数の引数を送受信するのにコストがかかるのでスカラーのほうが遅く配列のほうが早くなっています。
オペコードの量は関数の引数を送受信するのにコストがかかる上に変更に弱いコードなので引数が多ければ配列で渡したほうがいいです。
まとめ
パフォーマンスが高いスクリプトを書くことは大事です。
それと同じようにどうしてそうなのか、深い理解することも大事です。
自分でも考えてみることも大事です。
おわりに…
最後に、「PHPはどのように動くのか~PHPコアから読み解く仕組みと定石~」会場では売り切れてしまったけど技術評論社さんから発売中です。
Skyscanner Japanはエンジニアを募集しています
河野匡貴さん「10年続いているwebサービスの画像サーバをノーメンテでftpサーバからS3互換のストレージサーバに移行している話」
カラーミーショップというWEBサービスは１０週年。ネットショップを作りたい人向けのサービスで内部はPHPで独自フレームワークです。
公開しているAPIはRailsやCoffeeScriptで書かれています。
顧客はPCのからAPPサーバーにアップすると内部でFTPサーバーにアクセスする仕組みです。
顧客からの参照はCDNを通じてアクセスされる形です。
S3互換のストレージサーバーとは、APIがS3互換で裏側がMogileFS。ひとまずS3と同じと考えてくれればOKです。
- １：FTPサーバーとやり取りしているロジックを１箇所に集約する
- ２：ロジックを変更してS3互換サーバーに更新が掛かるように
まずファイルアクセスを抽象化してくれるライブラリを探しました。
FTPからS3互換サーバに移行するときに便利になるように。
Flysystemというライブラリが便利な事がわかりましたが、このライブラリは5.4から対応なので、5.3で運用していたカラーミーショップでは使えないことがわかりました。
全体をPHP5.4にバージョンアップする時間は裂けないので・・・Flysystemをフォークし、自分で動くように5.3対応のものを作りました。
- PHP5.3でテストを動かす
- テストコードをPHP5.3対応
- テストを実行
- ひたすら直す 具体的には[]→Array()とかtraitをよしなに変更とかです。
- Travisで一応5.3-5.6のテストは通っている
- Flysystemを使いつつ、画像サーバ特有の処理を共有化したものを作る
コピペコードにならないように社内用のComposerライブラリに追加し、テストも書きました。
ここまでで4ヶ月くらい掛かった。
- ノーメンテで画像データを移行する方法
APPサーバからFTPサーバとS3互換サーバの両方に更新がされるように修正。両方にアップロードする仕様です。
FTPから一時ファイル置き場にrsyncし、s3cmdを使ってファイルをputします。
この最中（FTPから一時ファイル置き場にrsync）に削除されると、S3互換サーバに必要の無い情報が入ってしまうので、削除するスクリプトを仕上げに通します。
最後にAPPサーバからFTPサーバに更新がされる処理を削除
１８台もあったので３ヶ月くらい掛かりました。
画像サーバーを移行しようという話が出たのが今年の１月で、すべて終わったのが９月で長かったという感想です。
大きな障害がなく無事移行が完了出来たのが一番良かったです。
仲裕介さん「WebRTC開発者向けプラットフォーム「SkyWay」の裏側」
ライトニングトーク
恒例のライトニングトークが行われました。
深澤ひかりさん「PHPer女子が語る2015 こんなコードを書くヒトはモテない～コラボ編～」
スタジオ・アルカナの深澤ひかりさんによる発表です。女子エンジニアの票が一番集まった答えが正解となる選択式問題「こんなコードを書く人はモテない」を，今年はCoidIQとコラボして出題しました。
岸田健一郎さん「ランダムデータをPHPで作る」
永和システムマネジメントの岸田健一郎さんは、ランダムデータの作成が手軽にできる「generatedata.com」、自身が作ったテストデータ作成のためのFabricateを紹介しました。また、FabricateのO/Rマッパー用のアダプタ実装について協力を呼びかけていました。
マスクドPHPさん「PHPでRubyを攻略する」
マスクドPHPさんは、Rubyで戦うRPG「RubyWarrior」をPHPに移植した「php-waarrior」を紹介しました。RubyWarriorはRubyだから全力が出せないとし、PHPに移植して攻略したとのこと。ロシアで人気になったので、ロシア語に対応したそうです。
村上俊介さん「良心的にまじめに開発するための心構え」
アライドアーキテクツの村上俊介さんの発表です。上司から「まじめに考えればこのくらい分かるよね。良心を持ってコードを書いてね」と言われないようにするために、気をつけたいことを「しくじりポイント」として参加者に共有しました。
大橋勇希さん「PHPでDIをする」
VOYAGE GROUPの大橋勇希さんは、DIについて初学者向けの解説を行いました。DIの基本構造、実現するための方法を紹介しました。変更に強くなるためにもDIしようと述べていました。
石川将行さん「サンタクロースを支えるIT技術」
GREEの石川将行さんは、自身が参加している「サンタクロースボランティア」について紹介した後、そのボランティア活動で使っているWebサイトや管理ツールを改善してきたことを報告しました。ボランティアで自由にエンジニアリングをする楽しみを伝えていました。
竹澤有貴さん「phpと夫婦生活」
竹澤有貴さんは、PHPを使って夫婦生活を改善できないかと思い、家計簿サービス、健康管理サービスなどを奥さんとともに要件定義を考えて実装しました。しかし、様々な事情で上手くいかなかったそうです。ただ、会話が増えたり、自宅での開発でトラブル自宅での開発への理解が深まったり、メリットもあったと紹介しました。
赤瀬剛さん「（あなたにもできるかもしれない）ローカルPHPカンファレンスの作り方」
赤瀬剛さんは、今年6月に開催した「PHPカンファレンス福岡2015」がとあるツイートがきっかけで開催されたことを発表しました。そして、「PHPカンファレンス＋地名」でツイートするだけで、公式アカウントができたり、登壇者やスタッフなどが集まったり、イベントが形作られることを紹介しました。
小川雄太さん「THE NEW "PERFECT PHP" WILL BE COMING SOON」
小川雄太さんは、5年ぶりの改訂版となる『パーフェクトPHP』を刊行するために動き出していること、そしてそのために自身へのプレッシャーをかけるために発表しました。今回、著者の一人として、PHPエクステンションのスペシャリストである関山隆介さんが執筆に加わることも紹介しました。
筑城裕介さん「小説執筆の現場で活躍するPHP」
コードライフの筑城裕介さんは、趣味で執筆している小説をどのように効率化して進めているかについて発表しました。時間泥棒サイトへの対策、簡易校正、進捗の可視化、バックアップのためのツールをそれぞれ作成したとのことです。
青木啓剛さん「蚊に刺されないためのPHP」
青木啓剛さんの会社では休日に入口のドアが閉まっているため、開錠のカードを忘れた時、中の人に開けてもらうまで待っている間に蚊に刺されてしまうことがあるそうです。それを解決するために、開閉のスイッチを動かすための機械を作り、Slackごしにつかえるようにしたことを紹介しました。
後藤健さん「ISUCON2015 PHPで予選を戦って俺の力量不足で惨敗してきた」
サイバードの後藤健さんは、課題のWebサイトの高速化を競う大会「ISUCON」の予選に出場しました。後藤さんが選んだ言語はもちろんPHPで、バージョンは7を使いました。そして、当日はよくある手法を使って高速化したそうですが、予選突破ラインにおしくも届かなかったとのこと。ただ今回、バージョン7を利用することでかなり早くなったことを挙げ、配列操作周りで効果的であったことを推察しました。最後に、本戦に出場する人はぜひPHPでがんばってほしいと話しかけ、自信も来年がんばりたいと述べていました。
クロージング
実行委員長の前島有貴さんから閉会の挨拶がありました。今回の参加者数はこれまでにない規模だったため、いろいろと気になっていたけれども無事終わることができたとし、参加者の方に感謝しました。また、各セッションの感想をjoind.inのページで受け付けていることを案内しました。
そして来年のPHPカンファレンスも開催すること（日程は調整中）を告知しました。
ブース
スポンサーブースは1Fです。次はお昼時の様子ですが、とても賑わっています。
ジュンク堂書店出張所＆サイン会
今回も、ジュンク堂書店が出張所ができています。
書籍のサイン会が行われていました。
『Laravelエキスパート養成読本』にサインする著者陣。
『PHPはどのように動くのか』にサインする蒋池東龍氏。
懇親会
同会場4Fにて、懇親会が行われました。Rasmusさんの乾杯挨拶のほか、ライトニングトークやプレゼントが当たるジャンケン大会等も行われ、皆さん、歓談を楽しんでいました。
（随時、更新予定です）