PHPカンファレンス2015 当日レポート［更新終了］

2015-10-03

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は、20週年を迎えます。最初は、PHPの生みの親、Rasmus Lerdorfさんのホビーなツールだったものが、世界中に広まり世界中のサーバで使われまでになりました。今回は、PHPの今とこれからについて、また「7」をテーマに発表が行われました。

PHP7は、来月リリース予定です。PHP7になることで「何がよくなるのか」「⁠何が変わっていくのか？」「⁠どんなことに気をつけなければいけないのか」ということを吸収してもらえればとのことです。

PHPという言語について次のように説明しました。

主にWebアプリケーションで使用されるスクリプト言語
1995年の誕生以来、Webと共に成長、進化

サーバサイドプログラミング言語では8割ほど使われていて、スクリプト言語としては一番のシェアを持っているそうです。CMSシェアでは、WordPressが6割ほど占めていて、言語としてだけでなくアプリでもよく使われる言語だとのこと。

使用されているPHPのバージョン分布を見るとバージョン5.3が最も使われているそうですが、昨年に比べ減少傾向のようです。現時点で、サポートが切れているバージョン5.4以下を使っているユーザは84％になります。いかに、バージョンを上げていくのが難しいか、分かります。ただし、サポート切れだからといって全く使えないというわけではなくパッチを当てることで対応することも可能です。

バージョン5.0がリリースされたのは、2004年なので11年間バージョン5の期間でした。そんな中、バージョン6.0を出す予定だったのですが、Unicodeの全面サポート計画が失敗し、バージョン6.0がキャンセルとなりました。その代わり、 6.0の機能だった「名前空間」「⁠クロージャ」「⁠Trait」などがバージョン5.4にに搭載されました。バージョン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/

今後の開発は、次の事柄にフォーカスされると話しました。

PHP7.1開発が開始
PCO（PHP Cryptography Objects）
JITコンパイラ

PHP7.1に関しては、どんな機能を入れるかという議論が進められています。ここで、コミュニティに参加し機能の提案できます。

PHPの今とこれからが、詰まった素晴らしい発表でした。

徳丸浩さん「今どきのSQLインジェクションの話題総まとめ⁠」⁠

2009年からPHPカンファレンスでトークをしている徳丸浩さんの発表です。SQLインジェクション対策漏れの責任を開発会社に問う判決の話と、PHP入門書のSQLインジェクションの話からO/RマッパやジェネレータのSQLインジェクションについて話しました。

SQLインジェクション対策もれの責任を開発会社に当判決

2009年の資料で安全なアプリケーションの発注要件の話では、脆弱性の責任は発注者か開発者かという問題を取り上げましたが、何もない場合に脆弱性があった場合に米国の弁護士さんと話したところ発注者の責任があると言うことでしたが、判例はありませんでした。

ところが昨年判例が出ました。その判例が家具インテリアECサイト侵入事件です。家具インテリアのECサイトを運営するX社がECサイトをY社に発注してそのサイトから2011年にクレジットカードの情報が漏洩。X社はY社に損害賠償を起こし、2014年1月に判決が言い渡されました。

裁判の争点は次のとおりです。

特にセキュリティに指示はしてなかった。
当初はカード情報を扱っていなかったが、X社の依頼でカード情報を保持するようになった。
カード情報は持たないほうがいいとX社が問い合わせた。
ログが他社から見れるようになっておりそのログにも個人情報が入っていた。
管理機能のID/PASSがadmin/passwordになっていた。

判断はいろいろ考えられますが、決定的な証拠はなかったけどSQLインジェクション攻撃によるものと断定さました。そして、セキュリティ対策について指示はなかったが、必要なセキュリティ対策を講じる義務を怠った責務不履行があると判断されました。また、損害賠償責任制限があった契約だとは認めるが、“⁠SQLインジェクション対策を怠ったことは重過失である⁠”と判断されました。その結果、損害賠償責任制限には該当しないとなりました。これらの判断は重要なポイントだと指摘しました。

よって、裁判所は約3000万円の損害賠償を認定しましたが、カード情報を保持しない20万の提案を却下したX社の過失相殺が考慮されて、3割減の2262万の損害賠償が確定されています。

徳丸さんの感想は、脆弱性を放置していたり管理画面のアカウントをECサイトの運営者は毎日使っていたにもかかわらず使っていたのに放置していたため、どっちもどっちだと話していました。ただし裁判所は、開発会社が専門家として当然はたすべき責務を怠っていたことを重視したということが大切です。そのため、発注者が何も言わないのでセキュリティ対策をしないというのは危ないとも述べていました。

こういった判決が出たことで、IPAの提案している「安全なウェブサイトの作り方」は最低限対策したほうがいい。また、「⁠安全なウェブサイトの作り方」が今年3月に改訂され、「⁠クリックジャッキング」が新しい脆弱性として載りました。採用見込みが薄くてもセキュリティ対策の提案は積極的したほうがあとで過失相殺にもちこめるかもしれないと述べていました。

PHP入門書のSQLインジェクション脆弱性の状況

PHP入門書のセキュリティの批判をしていると、入門書だから良いじゃないかと反論があるそうです。しかし、“⁠セキュリティのことは後回しでもいいけど、いつやるのか？⁠”と考えた場合、PHPを覚えたら忙しくなるので、できるだけ最初からやったほうが良いと話しました。特に「SQLインジェクション」はただのバグなので最初からやったほうが良いとし、入門書も最低限の対策は入れたほうがいいと言及しました。

そして、いくつかの書籍を取り上げ、そこでのセキュリティについて話しました。

* はじめてのPHPプログラミング

2008年に発行された『はじめてのPHPプログラミング』ではMySQLではなくSQLiteを使用しています。SQLiteはバインド機構を持っていないため、自前バインド関数作成しています。

function dbescape($sql, array $params)
{
    foreach ($params as $param) {
          switch (getup($param)) {
               case “inteher”:
               case “double”:
                    $replasemment = $param;
                    break;

               case “string”:
                    // 文字列の場合はエスケープ処理を行う
                    $replasemment = sprintf(“‘%s’”, sqlite_escape_string($param));
                    break;
               default:
                    die(“パラメータの方が正しくありません");
          }

          // SQLを置換し、パラメータを埋め込む
          $sql = substr_replace($sql, $replasemment, strpos($sql, “?”), 1);
     }

     return $sql;
}

しかしこの場合、バインド値に?があると誤動作すると指摘。

SELECT * FROM foo WHERE bar = ? AND base = ?
                                                         ↑’?’に置き換え

SELECT * FROM foo WHERE bar = ’?’ AND base = ?
                                                           ↑ ‘AAA’に置き換え

SELECT * FROM foo WHERE bar = ’‘AAA’’ AND base = ?
               AAAがリテラル外にはみ出す↑

SQLインジェクション攻撃は次のようになると示しました。

SELECT * FROM foo WHERE bar = ? AND base = ?
                                                         ↑’?’ぶ置き換え

SELECT * FROM foo WHERE bar = ’?’ AND base = ?
                                                           ↑ ‘or 1 = 1--’に置き換え

SELECT * FROM foo WHERE bar = ’‘or 1 = 1--’’ AND base = ?
         or 1 = 1--がリテラル外にはみ出す↑

ここから得られる教訓はプレースホルダの仕組みを安易に自作すると徳丸さんに怒られることです。十分に考慮して作りましょう。

* よくわかるPHPの教科書

『よくわかるPHPの教科書』も古い書籍ですが一時期ベストセラーになっていた本です。セキュリティには一定の配慮がされています。この本ではSELECT文ではmysql_real_escape_stringでエスケープ処理を行いsprintfの%dを使っていますが、DELETE文はmysql_real_escape_stringでエスケープ処理を行っているだけです。

ここでSQLインジェクションを実演してDELETE文で意図しない書き込みの削除ができるところを示しました。エスケープは難しいところがあるため、ケースバイケースできちんとやることが大事だと述べていました。

また、SQLインジェクションがあれば個人情報はたいてい漏れてしまいます。エラーメッセージを使った個人情報漏洩のデモを示しました。ここでは、マイナーなextractvalue関数を使いDELETE文からメールアドレを取得していました。

他にも、ブラインドSQLインジェクションというもので1回の呼び出しで1bitの情報が得られそれを積み重ねることで情報が取得できるとのこと。こちらもデモを示しました。

* 気がつけばプロ並みPHP

『気がつけばプロ並みPHP』では、SQL呼び出しはPDOのプレースホルダを使っていてSQLインジェクションについては特に重大な脆弱性はないと話しました。ただ、htmlspecialcharsを使ったものをSQLに使っていたり文字セットを使ってはいけないと言われているSET NAMESを使っていたりしているそうです。

* その他の本はどうなの？

最近はPDOのプレースホルダを使うのが主流になっているため、SQLインジェクションはないみたいですが、細かい問題はあるようです。ここ5年くらいはPHP入門書にSQLインジェクションの脆弱性がないことが当たり前になったと語りました。

また、XSSに関する脆弱性についてはたいてい説明されているが、次のような抜けもあると指摘しました。

SQLインジェクション対策はPDOのプレースホルダで静的と動的があり静的を使うほうが安全。
文字エンコーディングの指定はPDOの5.3.6以降で接続文字列に文字エンコーディングが指定できるようになったので、これを使う。SET NAMES outfitはやめる。
PDOの癖としてPDO::PRAM_INTを指定しても文字列として扱われるため、int型にキャストしたほうがいい。

O/RマッパやSQLジェネレータのSQLインジェクション

次に、O/RマッパやSQLジェネレータのSQLインジェクションについて取り上げました。PDOのプレースホルダを使うとだいたいSQLインジェクションはおきませんが、O/RマッパやSQLジェネレータではどうなのかについて話がありました。

* Rails SQL Injection Examples

Rails SQL Injection Examplesというサイトで脆弱性について言及されています。Railsの話なので言語はRubyになりますが、PHPでも参考になります。

例題の実演をして、UNION SELECTで別のテーブルの情報が抜き取れるところを示しました。この例題の脆弱性はプレイホルダで対策できるのでプレースホルダを使いましょうということでした。

また、Railsのorderメソッドは次のような式が書けます。

SELECT * FROM 成績 ORDER BY (算数+国語)

複雑なものも書けるそうで、これを応用するとSQLインジェクションができると説明しました。

エラーメッセージから情報を取得できますが、本番環境ではエラーメッセージは出ないという意見のある方のために、ブラインドSQLインジェクションを紹介し、実演で1回1bitの情報からIDとパスワードが漏洩するところを示しました。このように、SQLインジェクションはどこにどんな形であっても致命的になります。

orderメソッドでUNION SELECTから情報漏洩はできるのか。

ORDER BYのあとでUNIONは使えない
複文ではmissing attributeとエラーが出る

といった条件を考慮して列名に別名をつけると、IDとパスワードとメールアドレスが表示されることを示しました。この対策はアプリケーション側でバリテーションすることです。

* Zend FrameworkのSQLインジェクション

Zend FrameworkのSQLインジェクションの説明では、Zend_Dbで次のようにクエリを書けると紹介。

$select = $db->select()
                      ->from(products)
                      ->order(’name’); //列 nameでソート

orderメソッドで式を書くとそこで式も指定できます。これはまずいのでは？と思い、どのように識別子と式を区別しているのかと調べたところ、次のように処理されていました。

if (pre_match(‘/\(.*\)/‘, $val)) {   // (と)があれば
     #val = new Zend_Db_Expr($val);    // 式とみなす
}

その時の徳丸さんは、(; ´Д`)という気持ちだったとのこと。

CVE-2014-4914 (Zend Framework 1.12.6以前)は、次のようなになっていました。

orderの引数文字列に(と)がありさえすれば式とみなされエスケープ対象となる。
1;攻撃文字列 ?() とかでもOK。
公表されたPoCは次のとおり。

order(‘MDS(1); drop table products --')
↓生成されるSQL文
SELECT `products`.* FROM `products` ORDER BY MD5(1);  drop table products --

Zend Framework 1.12.7での修正されましたが、どのように直ったかと調べたところ、

//1.12.7
if (pre_match(‘/^[\w]*\(.*\)$/‘, $val)) {
     #val = new Zend_Db_Expr($val);
}
// 英数字0文字以上に続けて(があり、末尾に)があれば式とみなす

という形になっていました。その時の徳丸さんは、またも(; ´Д`)という気持ちになったとのこと。

Zend Framework 1.12.7に対する攻撃は、従来のPoCでは次のようになり、

order(‘MDS(1); drop table products --')
↓生成されるSQL文
SELECT `products`.* FROM `products` ORDER BY 'MDS(1);  drop table products ?' ASC
// order by以降が’で囲まれて識別子となる

新しいPoCでは次のようになります。

order(‘MDS(1); drop table products ?)')
↓生成されるSQL文
SELECT `products`.* FROM `products` ORDER BY MDS(1);  drop table products ?) ASC
// 式とみなされる条件を満たし、「そのまま」SQL文に

そして、Zend Framework 1.12.8での修正で、式の判定が次のように修正されました。

//1.12.8
if (pre_match(‘/^[\w]*\([^\]*\)$/‘, $val)) {
     #val = new Zend_Db_Expr($val);
}
// 英数字0文字以上に続けて(があり、途中は)以外が続き、
// 末尾に)があれば式とみなす

なんとなく攻撃は難しくなっているけど、徳丸さんの気持ちは変わらず(; ´Д`)な感じだそうです。仕様が良くないとし、下手に自動で切り替えずメソッド名を変えたほうが良いと話します。対策は「最新の Zend Frameworkを使用すること、かつorderメソッドの引数をバリテーションすること」だと述べていました（Zend Framework 2にはこの問題はありません⁠）⁠。

* JSON SQLインジェクション

SQL::makerというクエリビルダーがあります。プレースホルダを作ってバインド値も作ってくれて値をリストで渡すとIN演算子に勝手にしてくれたり便利なものですが、ハッシュ値に>=を渡してあげると演算子が変更できてしまいます。このハッシュ値にKEYなど意図していないもの渡すと、演算子のところにKEYと入ってしまいSQLとして意図していないものができあがってしまいます。

もし演算子の部分がいじれてしまうと、SQLインジェクションができてしまいます。Perlの最近の流行りでJSONを受け取るAPIの場合に問題があるそうです。

SQL::makerをPHP版に移植した人がいたので、このあたりを調べてみたそうです。

変数の値がyamadaの場合は次のようになります。

SQL文: SELECT * FROM `users` WHERE (`name` = ?)

また、変数の値がarray(‘⁠KEY⁠’⁠ => ‘⁠yamada')の場合は次のようになります。

SQL文: SELECT * FROM `users` WHERE (`name` KEY ?)

PHPはGET/POSTのパラメータに連想配列が渡せます。$user_name = $GET[‘⁠user_name⁠’];としている場合は、

http://example.jp/query.php?user_name[key]=value

となり、$user_nameにはarray(‘⁠key⁠’⁠ => ‘⁠value⁠’)が入ってしまい、keyの場所に攻撃文字列を入れると簡単にSQLインジェクション攻撃ができてしまうと説明しました。

PerlよりPHPのほうが簡単に攻撃ができてしまうので注意が必要です。対策としてはSQL::maker側はstaticモードを追加して、値としてハッシュや配列を渡せなくすること、アプリケーション側の対応は渡すパラメータにバリテーションを設けることだとしました。

* Drupageddon (CVE-2014-3704)

Drupageddon (CVE-2014-3704) は、JSON SQLインジェクションと類似の問題になります。

Drupalは3大CMSの一つで、WordPress、Joomlaの次にシェアがありますが、Drupageddon(CVE-201403704)はDrupal ver 7.31以前に存在するSQLインジェクションです。Drupal ver 6には存在せず、7系統にあるDrupal coreのSQLジェネレータの脆弱性です。アルマゲドンをもじってドゥルパゲドンと命名されたようです。

この脆弱性は10月15日に発表された直後に攻撃が開始され10月15日午後11時 (日本時間16日午前8時）までにアップデートまたはパッチの適用していない限り、破られたと想定して対処しなければならないとのこと。技術的にもめずらしいものなのだそうです。

通常の要求は次のような形です。

name=admin&pass=xxxxxx

これは、SQL文で次のようになります。

SELECT * FROM users WHERE name = ‘admin’ AND status = 1

このnameを配列で指定しています。

name[]=user1&name[]=user2&pass=xxxxxx
SELECT * FROM users WHERE name = ‘user1’, ‘user2' AND status = 1

この時点で問題があります。JSON SQLインジェクションにもあったように、IN句生成できると便利な呼びだしかたですが、キー名をつけてみる（id1, id2）と、

name[id1]=user1&name[id2]=user2

となり、プレースホルダに名前がついてしまいます。

SELECT * FROM users WHERE name = :name_id1, :name_id2 AND status = 1

そして、キー名前に空白をつけてみると、

name[1 xxxx]==user1&name[2]=user2

となります。プレースホルダに空白が含まれてしまい、xxxxのところは次のSQL文の一部になってしまいます。

SELECT * FROM users WHERE name = :name_1 xxxx, :name_2 AND status = 1

すでにSQLインジェクションは起こっていますが、この状態だとSQL文のエラーになります。エラーにならないようにバインド変数を設定すると、次のような形になります。

name[2 xxxx]=&name[2]=user2

SELECT * FROM users WHERE name = :name_2 xxxx, :name_2 AND status = 1

プレースホルダは:name_2しかないので正しくSQL文として実行できてしまいます。ここまでくると、SQLインジェクションの攻撃ができてしまいます。

このことを脆弱性のあるバージョンで実演しました。実演したのは次のような10秒待つSQLインジェクションです。

name[2 ;SELECT sleep(10) ? ]=&name[2]=user2

さらに、管理者権限を奪うところを示しました。

* 問題点まとめ

一連の問題点をまとめると、次のように言えます。

Zend Frameworkは、orderメソッドの仕様が明確でなかった。
SQL::Makerは、キーを外部から入力される想定をしていなかった。
Drupalでは、配列は想定していたが、連想配列は想定していなかった（7.36で配列を弾くようにバリテーションをするようになった⁠）⁠。

まとめ

最後に徳丸さんは、次のように発表の内容をまとめました。

SQLインジェクション対策もれの責任を開発会社に当判決が出た。
PHP入門書のSQLインジェクションは解消されつつありますが、まだまだ他の脆弱性がある。
SQLジェネレータの実装に起因するSQLジェネレータ脆弱性は仕様の考慮漏れやバリテーション不足。
SQLジェネレータ利用者側の注意ライブラリのマニュアルをよく読みバリテーションは普通にやっておこう。

岸田健一郎さん「Composerではじめるアプリケーション開発」

岸田健一郎さんは、Composerを使ったアプリケーション開発について発表しました。はじめにアンケートがあり、その結果を踏まえて、初心者向けの話とすることになりました。今回の内容について、詳しくは岸田さんのブログにも説明がありますので参照してください。

現在PHPで開発するときに外部ライブラリをインストールするには基本的にComposerで行う方法が一般的です。Composerは2012年3月1日に誕生。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が勝手に行います。

Composerのインストール方法は、ドキュメントに記載されているとおり、次の形でインストールできると示しました。

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がどうやって動いているのか、掘ってみよう⁠」⁠

もともとの発表予定者だった畠山さんに替わり、Microsoftのテクニカルエバンジェリストの高添さんがAzureについて発表しました。

はじめに

AzureはMicrosoftが運用しているクラウドサービスで、PaaSやIaaS、BaaSなど様々な形態のサービスを持っていることを紹介しました。9月30日に7個、10月2日に11個というハイペースで新機能をリリースしていて勢いがあるそうです。

PHPやりたいけどPHP以外でハマることって実は多い

今回の話は、PHPをとりあえず使うならAzureのPaaSを使うのが便利！という内容でした。PHPを使う場合はApacheやNginxなど、いろいろな設定をする必要があります。こういった設定はどこまでユーザーは必要と感じているかというと、本当に業務で使う人以外は必要としない場合も多いと指摘。Microsoft WebMatrixというAzureのPaaSならそういった面倒な設定をする必要もなくPHPを起動することができると話しました。実際にインスタンスを立ち上げ、phpinfoが表示されるまでのデモを行っていましたが、かなりスピード感がありました。

AzureのPHPなら…?

WebMatrixでは**PHPのバージョンの動的変更が可能**で、PHP5.4から5.6に動的に環境を変更する仕組みについて紹介しました。また、スケールアウトの仕組みも設計されています。負荷がかかると自動的にスケールしてくれる仕組みで使用者はアプリケーション開発に専念できます。スケールに際して気になるリージョンは全世界にあり、日本でも東西にひとつずつデータセンターがあります。1リージョン当たり60万台の物理サーバーを置いていて、日本国内で1年間に購入される物理サーバーの数50万強をゆうに超えるとのことです。

タイトルにあったクラウドから地上までとは？

そして、タイトルの「クラウドから地上まで」という意味について取り上げました。クラウドはそのままの意味ですが、地上というのはオンプレミス環境のことを指すとのこと。パグリックなクラウドだけではなくオンプレミスとしてもAzureを利用することが可能になっていて、パグリックなクラウド側と同じインターフェイスでプライベートPaaSとして利用可能になっていると話しました。この仕組みを実現する構成としては、リクエストをハンドリングするフロントサーバーが存在し、バックエンドに実際に処理を行うサーバーが待機しているという状態になるようです。フロントのハンドリングでオンプレミス環境に切り替えるといったことも容易にできると述べていました。

まとめ

発表では、Azureの手軽さや機能性を主に説明していましたが、「⁠何かを学ぶためには、自分で体験する以上にいい方法はない」という言葉で締め、実際に使ってみると早い述べる高添さん。みなさんも実際に使ってみてはいかがでしょうか。

中村けん牛さん「超高速WordPress ～PHP7 vs HHVM vs PHP5.6」

プライム・ストラテジー株式会社代表取締役の中村けん牛さんは、WordPress高速化の技術と考え方をPHP7, HHVM, PHP5.6のベンチマーク付きで解説しました。

中村さんは『詳解WordPress』などの本の執筆やWordPressプラグインの開発、Webメディアで連載記事を執筆するなど、活動は多岐に渡ります。また、プライム・ストラテジーでは1億PV/月超えのメディアサイトなどの構築、サーバ運用をしており、他にもWordPress仮想マシンイメージKUSANAGIを開発しています。

最初にKUSANAGIのサイトを取り上げ、ページ右上に記載されている「Run time 0.005s」とはサーバでWordPressを実行している時間であると言及。ページキャッシュを使わずにこの実行時間を実現していて、現状50～01,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の他の言語にはない仕様を題材にしたもので、20の問題が出題されていきました。その一部の内容を紹介します。

==ではなく===の必要性。
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で書き換えたら異変が起こること。書き換えならarray_walkを使おうと説明。

$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]

Rasmus Lerdorfさん「基調講演」

PHPの開発者Rasmus Lerdorfさんの基調講演は、満員御礼で始まりました。

20周年は「すごい」ではなく、「⁠ただただ、歳を取ったな」というだけの感覚だと話します。そしてスライドで、1995年のインターネットを物語る「PHP ANOUNCEMENT JUNE 8,1995」を示しました。

この文章は当時の問題のリストアップをしているタイムカプセルのようで、当時のPHPは現実の問題解決にフォーカスしていたと説明。元々は、C言語を使ってロジックを書いていきTypoをした時にエラーを出すということ、基本はスタックベースでプッシュしていく仕様でした。ただ、当時すごく良くできていると思ったものは、今から見ると失敗に終わっていると言います。

今はPHP7でいろいろなものを織り込んだものを出せるようになりました。PHP7はセカンダリーのOpCacheを持てるようにしています。その結果、ファイルベースでコンパイルされたものは4倍、メモリ上のキャッシュでは10倍の速度が出るようになりました。また、いままで、CLI（コマンドラインインターフェイス）のPHPではキャッシュが使えなかったけれど、7では使えるようになりました。これにより、コンポーザーの動作は2倍の速度が出るようになっています。つまり、もともとのPHPのスピード改善が2倍くらいあるのでPHP5でコンポーザーを動かすのとくらべて4倍の速度改善がされていると紹介しました。

他にも新機能はいろいろあります。

スタティックアナライザの書き方。
returnTypeで特定のタイプが返せるようになった。
stritタイプを準備しているので、型に問題があればエラーを返せるようになった。
クロージャーも1回限りしか使えないような書き方ができるようにもなった。
NullCoalesceOperatorが実装された。
SpaceshipOperatorが実装された。
スターウォーズのX1のようなオペレータ<==>が実装された。
FatalになっていたエラーもExceptionとしてキャッチできるようになった。
クロージャーコールを追加された。
特定メソッドの上でクロージャーをコールできるようになった。
ereg等のPHP4の非推奨なメソッドを多く削除した。
新しい予約語も追加されているので注意。
Uniform Variable Syntax。
PHP7はすべて左から右に解釈するようになっているが、PHP5の順序で解釈させるようにする方法も準備している。
preg_replaceをpreg_replace_callbackで実装する方法。

どのように2倍の速度が出せるようになったのか？については、Wordpressでの1リクエストで調査し、2倍の高速化を果たしたことを証明するグラフを表示して説明しました。また、20年前からアップデートしている言語にも関わらず2倍になったことについて、インストラクションの半分を削除し、今までと同じように動くことを求められるため、大変だったと言います。例えば、メモリの消費を大幅に抑えたり、CPUキャッシュからコンパイラから諸々見直したりしたとのこと。そしてJITについて、まだPHP7にありませんが、JITを使わずにこれだけのパフォーマンス改善が行えているとし、これからJITを導入するオプションが残っているため、更なるパフォーマンス改善が望めるはずだと述べました。

なお、発表中に出した一連の数字については詳細に情報を提供しているとし、皆さんもベンチマークしてほしいと呼びかけていました。

次に、様々なアプリケーションでの比較を示しました。

Drupal8は、レイテンシは半分に下がっている。HHVM3.7よりも早い。
WordPress4.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は、あまり速度向上が認められなかった。これは、ほとんどの時間がデータベースへのアクセスであるため。
WardrobeCMS 1.2.0は、PHP5と比較して2倍の性能向上が見られる。LaravelやSymfonyのようなフレームワークを用いている人はこの2倍の効果を感じることができるはず。クリックすればわかるレベル。
Geeklog2.1.0は、他と同じような結果。
Magento1.9.1.1は、そもそもリクエストできる数が少なく数十程度である。
Traq3.5.2は、2倍くらいの差が出た。

また、PHP5からPHP7への移行を数々のアプリケーションで試した結果、Avalonというアプリで修正が必要だったが、他ではそのまま何もせずにPHP7を採用できたと話しました。

Rasmusさんは、「⁠もうすぐPHP7がリリースされますので、みんなテストしてください。そして問題があれば教えてください。リリースして大量の問題が報告されると、開発チームは不機嫌になりますが、リリースする前なら、ニコニコ修正します」と述べていました。

Vagrantのスクリプトも準備していると言います。この仮想マシンはDHCPで接続も可能です。開発環境のコピーも提供します。Vagrantのコンパイルで、とても簡単にPHP7とPHP5にスイッチできるとのこと。

また、PHPのバグを見つけてほしいと言います。バグが無ければバグフックスを修正する側に回ってくれても構わないとし、バグを報告するサイトではランダムでバグを表示する機能を紹介しました。また、バグではないという見極めも大事、むしろほとんどがそうだとも注意しました。

質疑応答も活発に行われました。

仕事で7に移行するときに気をつけることは？
- すぐに使ってください（笑⁠）⁠ 本当はPHP7.0をプロダクションで用いることは無いと思うが、7.1までは待たなくても良いくらいの信頼度があるのでそれくらいで使える。
mb系のFunctionが通常のFunctionと一緒になることはあるか？
- mb系のFunctionが融合する可能性は今のところ無い。いつかするかもしれない。いまでも例えばユーザースペースを使う等で実施できる。7.0は今までどおりのmbは別で実装されている。
パフォーマンス向上の項目を教えてください。
- すべてパフォーマンスに関する要素を書き出すことはできない。言語自体もでも早くする仕組みを改善している。あまりにも多い。ファイルベースでのキャッシュによるリスタートの速さが挙げられる。
PHPでは、推奨するフレームワークがあるの？
- それは結局はどのフレームワークがいいのかという質問でしょう？（笑⁠）⁠ 私にフレームワークを聞くのは間違っている。PHPの開発者ではなく、Cの開発者だから。私のフレームワークに関する知識は「なんでこんなに遅いんだろう」と汗を掻くくらいしかない。しいて言えば、モジュラー構成になっていて、必要なものを選べるようなフレームワークがいいと思う。
PHPのPはパーソナルだという話があるが実際はどうか？
- PHPはPHPでPは……という話はしない（笑⁠）⁠ 背後になんの意味もないのか？という話をする人のために話すことはあるけど。PHPはPHPです。
古いエクステンションに合わせて後方互換を保ったものを準備するつもりはあるか？（PECL等で作られているので⁠）⁠
- C言語で書かれたモジュールを準備するつもりはない。ただし、後方互換を実装した数百という例があるので、やるべきことはパターンを見て、自分で、PHP5のコアに入っているものもあるので、それをPHP7に実装していくこと。

yoku0825さん「MySQL 5.7にやられないために知っておいてほしいこと」

yoku0825さんは、MySQL5.7について発表しました。

MySQL 5.7 とは？

MySQLはバージョンが5.7となり、2年半ぶりにメジャーバージョンアップしました。次はMySQL5.8になるようです。yoku0825さんは「5.7は新しい機能がたくさんあるので、アップグレードしたいバージョンではありますが、たくさんの罠がひそんでいる」と言います。

これまでのMySQL

2015年8月に5.7.8-rc2がリリースされました。rcとはリリース候補版を意味します。5.6をリリースした際に、Oracleは18～24ヶ月で次のメジャーバージョンをリリースする予定と言っていましたが、リリースがずれこんでいるようです。

2010/12: MySQL5.5
2013/02: MySQL5.6
2015/xx: MySQL5.7

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言語に賭けたチームの話⁠」⁠

大谷祐司さんは、7月にリリースした転職サイトで、社内ではじめてHackを採用したそうです。それを通したHackの知見について発表しました。

Hackとは？

HackはFacebookによって開発された言語です。PHPと互換性を持っていて、HHVMという仮想マシン上で動作します。Facebook本体のコードはほとんどHackに移行済みです。PHP5.5をベースに仕様追加と削除が行われていて、途中から5.6ベースになっています。

Hackの特徴は、バグのないコードを迅速にかけるようにすること、エンジニアがコーディング体験を楽しめること、高速な動作や大規模開発向きの仕様が実装しやすいこと、これらの目的を持った言語であると紹介しました。

ただ最近は、Hackについて次のよう良く言われていると指摘しました。

Hackは昨年話題になったけど、とっくに下火で進化も止まっているのでは？
Hackは単純に「パフォーマンスの高いPHP」だよね？
PHPフレームワークやライブラリが使えず開発にコストがかかるだけでは？

大谷さんが某CTOに相談しに行った時には、Hackを本番環境で使うなんてクレイジーだぜ！と言われたそうです。

しかし結論はすべて誤解だったと話しました。

バージョンアップは早くて8週間に1回、バージョンが0.1づつ上がっていて、大谷さんが作り始めた時が3.4で、今は3.9とのこと。来週には3.10になります。バージョンごとに機能追加がとても多く、エキサイティングな言語だと言及しました。

なお、サポートは3バージョンに1つがLTSということで、約1年間サポートすることを約束されています。

最近のリリースにおける進化

最近のHackでは並列処理のために、型チェッカーの機能拡張、トランスレーション・キャッシュのメモリ改善、処理の高速化が行われています。「⁠Hackがとっくに下火で進化も止まっている」というのは間違いで、今もすごいスピードで進化を続けていると述べました。

例えば、Hackが使われたことにより、Wikipediaは編集する際の速度が2倍に、boxはwebレスポンスが1/3に短縮し、wpengineはレスポンスのパフォーマンスが5.6倍になったことを挙げました。このように、Hack/HHVMはとても優れたパフォーマンスを発揮しています。

また、Facebookによる仕様追加が多く、「⁠大規模サービス開発」向けの言語に仕上げている印象だと説明しました。

追加されている機能

Hackに追加されている機能として、次の事柄を挙げました。

引数・戻り値の型指定できる。型の前に?をつけるとnullを許容するというサインになる。
Genericsの実装。
Hack独自の配列を実装していて、厳密な型やタイプを指定できる。そのため、格納する値に型の指定が可能だったり、Getメソッドを利用することでissetなしで値を取り出せる。
Enumの仕様が追加。
async、awaitという関数で並列処理ができる。
hh_clientを使うとコンパイラーエラーや戻り値のチェックなどの構文チェックが実行前に行える。

Hackは単純に「パフォーマンスの高いPHP」であるというのは間違いで、大規模開発に耐えられるように、多くの拡張がなされていると述べました。

なお、Hackではand、or、endforeach、goto、globals、break Nなどが非推奨の構文です。また、PHPソース中にHTMLを書くことはできません。

Hackを使ってサービスをリリースするまで

今回のサービスで採用している技術・構成は次のとおりだと紹介しました。

OS: CentOS7
Webサーバ: nginx1.9
DB: MariaDB10.0
インフラ管理: Ansible
web開発言語: Hack (hhvm3.7)
フレームワーク: FuelPHP1.7
バッチ開発言語: Go言語

なぜHackを使用したかについては、チームにPHPの経験者が多かったことと、そのノウハウを活かしながら新しいものがやりたかったことを挙げました。また、今は問題ないけど、将来大規模になった時にもパフォーマンスが良いほうがいいということや、サイズが大きくなったりソースが多くなってきたりした時に可読性がよく、スピーディーな改修ができるとともHackを使う要因として挙げました。ただ、開発が1年遅れていたらPHP7にしていた可能性があると述べていました。

Hackの採用は次のような覚悟を持って採用したそうです。

最悪ダメだったらPHPに戻す
前例がないからチャレンジしてみよう
英語ネイティブのメンバーがいるから大丈夫
PHP7ではなくHACKが流行る未来を妄想

Hackの学習は、チュートリアルを進めることで仕様や使い方を学ぶことができたとのこと。

しかし、次のような問題点があったと指摘しました。

HHVMが落ることがある。なぜか落ちるので監視して自動再起動をしている。
peclが利用できないため、golangでextension記述している。
HackにはHack自体を拡張する機能を持っているが、スピード重視で今回は使用していない。
CentOS6サポートを急に停止したのでCentOS7へ急遽移行した。
コードフォーマッターがきちんとは使えないため、改造して使っている。
Hackと検索してもゲームの.hackが出てきてしまい、情報になかなかたどりつけない。情報もまだ少ない。

HHVMで動作するPHPのフレームワークの情報は公開されていて、主要なフレームワークは対応しています（現在27種類が100%対応済み⁠）⁠。今回はFuelPHPを採用したと言います。その理由は、社内での採用実績が豊富だったのが一番大きいとし、標準ライブラリが充実していてpeclが使えない部分を結構おぎなっていると説明しました。PHP5.3以上が推奨でHHVMと相性が良さそうでもあると述べていました。

FuelPHPを採用して、次のような形で使っていると紹介しました。

DBアクセス部分に若干のコード追加をおこなっている。
テンプレートエンジンはSmartyを使用した。問題はおきていない。
index.php → index.hhに名前を変更した。FuelPHPは.phpで動いているがプロジェクトで使っているものは.hhを使っている。
プロジェクトで使用しているものは<?hhで開始するようにしている。
FuelPHPのソースを全部Hackに書きなおさないといけないと思っていたが、そんなことはなくFuelPHPのPHPの部分とプロジェクトのHackの部分はうまく共存して、いい感じで安定している。

また、開発の際には次のようなルールを設けて、記述の統一化、可読性のアップを実現しているそうです。

定数はenumで作成。
ArrayではなくVector/Mapの積極的な利用。
タイプヒンティングは必ずつける。
hh_clientでコミット前の構文チェック実行。

hh_clientがあるおかげで、実行しなくても潜在的な不具合など見つけてくれるので助かっていると述べていました。

セキュリティについては、Dell Secure Works社に依頼して、監査してもらった結果Hack/hhmvに起因するリスクはゼロだったのこと。

今回Hackを採用して良かったこととして、次の事柄を上げました。

PHP経験のあるメンバーが早期習得でき、学習コストは掛からなかった。
「新しいチャレンジ」しているのでメンバーは活き活きとしてコードを書いている。
PHPだけを書いていたメンバーはいろいろな書き方を知ることでスキルの幅が広がり、PHP以外の言語への興味が出てきた。

「PHPフレームワークやライブラリが使えず開発にコストがかかる」ということはなく、PHPで培った資産を活かしながら、様々なメリットを活用して開発ができると、まとめました。

まとめ

最後に、Hackはとてもホットな言語なので皆さんも是非試してみてほしいとし、「⁠Hack言語に出会って、PHPの今後に大きな可能性を感じました。PHP7のリリースも控えており、PHPのこれからがとても楽しみです」と述べていました。

秋山顕治さん「Electronからクロスプラットフォーム・アプリケーションの歴史を考える」

Electronといえば、Node.jsとChromiumをベースにしたクロスプラットフォームアプリケーション開発プラットフォームとして有名です（旧 Atom-shell⁠）⁠。AtomやSlack, kobitoなどのプロダクトのクライアントアプリケーションはElectronが使われています。

秋山顕治さんの発表では、Electronの登場背景からこれまでのデスクトップアプリケーション開発事情とクロスプラットフォームアプリケーション開発の歴史を振り返りました。

ElectronのWebエンジニアにとっての利点とは

Electornの利点は、やはりWebの技術でデスクトップアプリケーションが開発できることが大きいと言います。簡単なアプリケーションならすぐに作れるので、実際に秋山さんが作ったタイマーアプリのデモを示しました。

なぜ今までデスクトップアプリケーションを作ったことがなかったのか？と思い返す

今まではデスクトップアプリケーション開発といえば、Windowsなら.NET系の開発、MacならCocoa系の開発をする必要があり、割と低レイヤーな言語で開発し、それぞれのプラットフォームに対応する必要がありました。このことに付随して次の項目が敷居を上げていたと指摘しました。

新たな言語を学習するコストが高い。
開発環境を用意するコストが高い。
デベロッパー登録をしないとインストールできない。
あるプラットフォームむけに構築されたソフトウェアは他のプラットフォーム上で動かない。

これが実際に秋山さんのモチベーションにどう関わってきたのかを振り返ります。ちなみに、本発表でのクロスプラットフォームの定義は同じ言語で複数デバイス対応することを指します。

* 古代からの流れを一気に

これまで次のような時代の変遷がありました。

OS登場以前（1950年頃）: いろいろな実装が乱立していた。
OSの確率: ある程度戦争に終止符が打たれ、OSという概念が生まれてくる。
ハードウェアおよびOSの乱立: HWやOSが乱立。
2000年代: OSがいっぱいあってもしかたないと、収束してきた。

そして、プラットフォームがある程度の数に収束して、Windows、Mac、Linuxあたりに対応するアプリケーションを作れば良い、という流れができてきました。ただ、収束してきたと言えども、2つや3つのOS向けに開発者を行うのはツライという印象です。

開発者の願いは、"一度書いたら、すべてのプラットフォームで動いて欲しい"

この流れから生まれてきたのがJavaです。またはQtや.NETも生まれてきました。これらは、一度プログラムを書けば複数のOS上で動作するような設計がされてきました。ただ、個人開発を行うには辛く、業務として企業が取り組んでいる印象が強かったと秋山さんは話します。

Web技術の採用の流れ

その後、個人開発でも簡単に作ることができるWeb技術を使ってクロスプラットフォーム開発を行う流れが出始めました。Flash（adobe AIR）やMicrosoft Silverlightはそういった流れから生まれたのでしょう。ただ、Flashに関してはAppleがiPhoneにFlashを採用しなかったことから下火になり、SilverLightもIE上で動作という制約があり、まだまだオープンな形で使えるものがありませんでした。

この頃からのブラウザアプリの流れ

その後2010年に、次の特徴を伴うGoogle Chromeアプリが登場します。

Webアプリケーションがオフラインで利用できる
ブラウザを開かなくても利用できる
様々なブラウザの機能を利用できる

これらの特徴には魅力的に感じつつも、まだまだChromeという環境に依存することや、専用のランチャーをインストールする必要性、CHrome自体のシェアを考えるとまだ手を出せない印象でした。一方で、既にクロスプラットフォームを前提に構築されているWebブラウザであるChromeにどっかりのっかった点は良い面であったと秋山さんは言います。この時点までいろいろなものが出てきたけれど、「⁠俺を動かす情熱には足りない…」とのことでした（笑）

* ここまでの秋山さんの要望

秋山さんの要望をまとめると、次のとおりです。

なるべく多くの環境で動作
ライトな言語で開発したい
持っている技術の流用か、後に仕事に流用できなそうな技術を採用したい
ランタイムのインストールとかしたくない（させたくない）

そこで登場したのがElectron

そして登場したElectronは、次の特徴を持っていました。

HTML+CSSでUI構築
Javascriptで動作を記述
クロスプラットフォームのWebブラウザをランタイムとして同梱

AirやSilverlightはあらかじめランタイムをインストールする必要があったけれども、Electronはランタイム同梱なので、使う側がランタイムインストールなど手間が無く使えます。結果、すべて要望に合致したのがElectronでした。

* Electronはなぜ最初から登場しなかったのか?

Electronはなぜ最初から登場しなかったのか？と述べる秋山さん。Electron登場の条件は以下があったと指摘しました。

オープンソースのクロスプラットフォームWebブラウザの登場（chromium）
JSのサーバーサイド（実質的にはブラウザ外）実装の登場（Node v8）

Webの技術が拡張されていった結果、Electronが登場したと述べました。

* 秋山さんの要望以上の利点

Electronのメリットとして、次の事柄を挙げました。

Node.jsの機能利用（19万以上のnpm⁠）⁠。
実質Web開発なのに対象環境をElectronおよびNode.jsのみに絞ることができる。
ブラウザの種類についてもバージョンについても気を使う必要がない（ランタイム同梱だから、開発者はほかのを意識する必要が全くない⁠）⁠。
JSで開発できること。多くのWeb開発者はJSを触っている。
Polymerなどはブラウザ互換が肝になっていたけれど、ElectronはChromimに対応していればいいのでクロスブラウザは考えなくても良い。

また、PHPのエキスパートはJavaScriptのエキスパートでもあるよね？と指摘し、ここでやっとPHPconということを思い出したかのような発言が出ていました（笑）

* Electronの欠点

デメリットととして、ランタイム同梱なのがメリットである反面、そのせいでバイナリサイズが大きい（数百MB）というところを挙げました。とはいえ最近のパソコンはそれくらいのサイズならば問題なく使えるものが多く、そこまでデメリットでも無いかもしれないとも述べていました。

具体的にどういったシーンで使えるのか?

そして、Electronは次のようなシーンで使えると紹介しました。

"最強のTwitterクライアントを作る"といった流れがあるので、オレオレツールとかいいかも
社内向けのクローズドなアプリケーション
クロスプラットフォームなアプリケーション作り（Macしか持ってないけどWindows向けアプリケーション作るなど）

まとめ

本発表は、クロスプラットフォームアプリケーションを取り巻く歴史を振り返り、なぜElectronが登場して、今注目されているのかを考えるものでした。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のツールだから分からないと言われる。
バグが起きた時の再発防止策で「がんばる」とか言われる。

このように自動テストがない状況だったため、作業が積み重なり自動テストを導入したいと考えていたそうです。

そこで、2年前に出会ったのがBehatだと言います。必要なものがすべてBehatにあったそうです。Behat自体はBDDのツールですが、BDDとしては使わずに、単純に自動テストツールとして使っていると紹介しました。TDDやBDDの導入は生半可では回らないので、ひとまず自動テストを導入してみたかったと述べていました。

自動テストには、次のような利点があります。

デグレがよく起こる箇所の事前検査
ビジネス的に重要な箇所の事前検査
テスト手順が煩雑な箇所の検査
放置状態の機能の死活監視

富所さん自身が、個人的に感じる利点としては次の事柄を挙げました。

リリースに自信がでる（よく聞く）
リファクタリングに勇気がでる（よく聞く）
面接の時言える。
自動テストは、意識高そう。

ただし、現場に自動テストを導入しようとすると、「⁠テスティングツールの学習コスト」「⁠テストに対するコストが高いと非エンジニアに対して理解を得にくい」「⁠テストを書いたことがないエンジニアの精神的な障壁」などの話がよく取りざたされるそうです。このようなことを言う人たちへのケアができていないと、そもそも自動テストというものが受け入れられないと語りました。

次に、自動テストの失敗談について紹介しました。

* ケース1) テスト作れない

テストが作れないという問題。原因としては「⁠テスト自体をやったことがない」「⁠テストについて教育や学習の時間が取れない」など。そもそもテストを作れない理由は、「⁠教育工数が取れない組織自体に問題」「⁠自動テストへの心理的ハードルの高さ」「⁠効率のいい運用ができなくて、時間がなくなっていく負のスパイラル」が挙げられる。

* ケース2) 自動テストの遺跡

CIがないとテスト自体が、遺跡になる。プロジェクト開始当初は全員テストを書いても、プロジェクトが佳境になったり緊急対応時にきちんとテストを書かない人が出てくる。

また、特定個人の環境でしか動かないテストも存在し、遺跡になってしまう。これはCIが不在ということが問題。誰の環境にも依存しないところできちんとテストができる環境がないと特定の個人に依存してしまうから、自動テストが回らない。

* ケース3) テストの放置

Jenkinsにテスト実行ログやグラフは出ているが、ただテストを実行しているだけになっている場合。成功・失敗といった結果がメーリングリストに飛んで来くるが、誰も反応しなくなる。最悪、テストが失敗状態でリリースが重ねられると、自動テストされる意味がなくなってしまう。

リリースツールは、テスト失敗時にリリースできない状態を作ってあげないと、自動テストがリリースに影響を与えられない。また、通知がメーリングリストだと他人事になってしまう。例えば、sys-xxx@のような人を特定できないメールアドレスだとそうなる。つまり、自動テスト導入後の運用も含めてトータルに考えないと、あっという間に廃れてしまう。

以上は富所さんの体験談だそうですが、自動テストを押しつけても現場に浸透しなかったと言います。現場における平均レベルのエンジニアが自然と実行できるレベルにまで噛み砕かれている状態でないとうまく浸透しないと話していました。

BDDテストフレームワーク「Behat」

次に、Behatを紹介しました。BehatはBDDテストフレームワークで、Cucumberにインスパイアされています。テストシナリオはGherkin形式で、PHP製とのこと。

Behatは次のような形で使うことができると説明しました。

デフォルト状態では何もない。
テスト（feature）, アサーション（step）は自分で作る。
一般的にはextensionを導入して使う。

そして、テストコードをもとにBehatの使い方を解説しました。Gherkin形式で書かれたfeature（テストシナリオ）にはPHPコードが一切出てきません。step（テストコード）にfeatureで書いたものが割り当てられていきます。

自動テストの成功を阻む要因として次のような事柄が挙げられます。

1. テストツールの教育不足
2. 個人依存のテスト実行環境
3. 導入後の通知や運用ルールの不備

しかし、Behatはバランスが良いため、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を使ったデモを行い、補完機能について紹介しました。PhpStormの前後のコンテキストを理解した補完や構文解析は、vimなどのエディッタにはできないリッチな機能であること。また、Gitクライアントが入っていて、コミット時にPSR-2といった規約にあわせて、自動で整形を行ったうえでコミットを行えることを話しました。

次にVagrantの紹介しました。特徴は次のとおりです。

プロジェクト毎に独立した環境
自動構築
チームで同じ環境を利用
運用環境と同じ環境

Vagrantの導入ポイントは次の点にあると指摘しました。

PHP コードと一緒に管理
とことん自動化（vagrant upで完了）
プロビジョニングはVMの中で実行
Shell Script -> 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」

PhalconはPHPフレームワークの中で最速と呼ばれるフレームワークです。内部実装でC言語を採用し、処理速度の向上を図っています。arimoさんは、DMMの実案件でPhalconを使ってみた事例を発表しました。

arimoさんの自己紹介に30分中の10分を費やすという時間の使い方に冒頭で会場がざわつきつつのスタートです（自らのスライドで"早く始めろよ"とツッコミをいれてましたが。笑⁠）⁠。

Phalconを使おうと思ったきかっけ

DMMの案件では仕様変更が頻繁に起こるらしく、それまでは急務ではなかった大量アクセス／速度が仕様変更によって求められた時があったとのことです。そこでFuelPHPで途中まで実装していたものを突然Phalconに全書き換えをすることになったそうです。

「案件でやったことがある人いたのでまぁいけた」と語るarimoさんでしたが、Phalconは名前が台頭してから歴史が浅く、執筆者の感覚的にPhalconを実案件で使ったことがある人は中々いないイメージだったため地味に驚きました。

FuelPHPからPhalconに書き換えた感想は、ドキュメントが少なすぎるとのことで、やはりまだまだ人口の少なさが伺えます。

Phalconはどんなフレームワークか

公式サイトのベンチマーク見てみると、秒間に捌けるリクエスト数（rps）はZend Freamworkは354, Laravelで489, FuelPHPで568, Codeigniterで1059という並びに対して、Phalconは2,535という数字で、PHPフレームワークの中ではダントツの数字を誇っています。また、Laravelなどでも採用されているDIコンテナが便利という点がオススメポイントと述べていました。

バージョンはどうなっているのか

バージョンによって内部実装が変わっているので中々互換性などは厳しい部分もあるとし、1.x系はC言語で実装してあるのに対して2.x系はZephierという言語を採用していると説明しました。そのため、現行ではZephirでいろいろなカスタマイズができるようになっています。Zephirとはビルド時にC言語にコンパイルされるプリプロセッサ的な役割の言語で、CのPHPエクステンションをほぼPHPな記法で書くことができます。Zepherを使うと拡張は描きやすいですが、エラーが出ると追えなくて大変とのことでした。

Phalconの闇

Phalconの闇として次の事柄を挙げていました。

ドキュメント英語問題: 公式マニュアルも中途半端日本語化されているという罠。
ORMの使い勝手があまりよくない問題: いろいろと使えなく、結局素のSQLを書くことも。
メール機能事件: ここも使えなく、結局PHP側に依存。
Configのマージ事件: 設定項目がうまく反映されなく、環境変数を使う。
DIコンテナが一生変わらない問題: 書き方によってはそういうケースも。
テーブルの中身消える事件: id指定をしてdeleteしているハズなのに全てのデータが消える事件が。

まとめ

Phalconのいいところは速さです。ドキュメントがまだまだ整備されていないし、情報が少ないというところが大変だけど、新しいフレームワークや言語はみんなこういう状況なハズです。新しいチャレンジするのは良いことだと思うので、ぜひ皆さんもチャレンジしてみてください。

前田雅央さん「営業・運用を支える気付ける管理画面⁠」⁠

前田雅央さんは、スマホ向けの広告配信で、より効果の良い媒体に出すアドネットワークのためのアプリZucksの管理画面について発表しました。

アドネットワークとは、広告主からお金を集めて様々な配信調整を行い、その結果を広告主に報告するというサービスです。

アドネットワークの管理画面を作る上で、次の工夫が必要だと言います。

コミュニケーションの工夫
運用を楽にするため工夫
機能開発のデプロイの工夫
データの変化に気づくための工夫

また、管理画面ではユーザー権限管理、データのCRUD処理、レポーティング機能、データ出力（CSV）があります。

このような管理画面を長期運用していくと、次のような事案が起こると話します。

使われているかわからない機能画面がある。
使いづらい画面でも利用者が使いこなしてしまう。
何度か作り直したくなる病が発症するが、諦める。
裏機能がいつの間にかできる。

本発表では、限定的な管理画面についての話をするとし、最初に、コミュニケーションの工夫について語りました。「⁠なぜ必要なのですか？を聞く」とはいえ、「⁠本当は……」という答えてくれない心の声はエンジニアに聞こえないため、観察力が必要だと言います。例えば「最初に絞り込むのは」何ですか？といった質問が必要になると述べていました。でも、その質問はどのように思いついたらいいのでしょうか。前田さんは、日々観察から思いつけるようにしようと言います。GoogleAnalyticsも「期間」は右上に表示されていますが、これは期間が表示要素として重要だからだと指摘しました。

このよう観察力があれば、例えば、ページャはいつもありますが、直接Xページに行くというのはほぼないため、必要なのは最初、前へ、次へ、最後でいいはず。また、Xページというのが表示されるときは何かあるときと気づくことができると話します。そうして、フォームは最低限の実装、「⁠何も困ってない」を旗印に開発すると良いと述べていました。

運用を楽にするための工夫については、共有できるURLが大事だと説明しました。

更新履歴をシンプルに表示することについては、

営業：案件の単価がいつの間にか30円になってるんだけど？
開発者：え？いつのまにか？
営業：変更してないはず。
開発者：調べてみますね。

と言ったやり取りを防ぐためにも、履歴を保存して見られるようにしようと話します（なお、この場合は営業さんは悪くなく、人間は忘れるものだとも言及していました⁠）⁠。そのためには、Entityを配列に変換したものをひたすら保存することだと言います。価格の表示やユーザーIDなど、調整しなくてもarray_diffを使えば分かると述べていました。

また、タイムアウトで500エラーなど、嫌な情報を事前に把握したいとし、問題が置きてから気づくのは当たり前なので、その前に気がつきたいと話しました。Symfonyだとルーティング定義名で何がどう遅くなってるかが表示されますが、ロジックとしてはなんらかのしきい値を超えたらWarningのログを残すようにしたいと述べました。

Slackで通知するとまた見やすく便利です。そのために使うmonologが便利だとし、fingers_crossedで詳細なログを残すようにしているそうです。そういうことが分かれば、「⁠Aさん、レポートの取得期間が長すぎて時間がかかりすぎているようなので、期間を短くして試してもらえますか？」と聞くことができるようになると指摘し、エンジニアからコミュニケーションを取れるようになると述べました。

機能開発のデプロイの工夫については、導線を用意せずページを増やして確認することを挙げました。例えば、ある程度大きいものを「/report」「⁠/report2」という形で本番のデータでテストすることで、既存のコードを修正せずに対応できるようになると話しました。

管理画面からの通知をメールとSlackに連絡すると、そこでやり取りが発生するようになると言います。そして、気づける管理画面はサービスの質を向上させるとのことです。しかし、Slackが時々失敗するため、クリティカルな通知はダメだと注意しました。クリティカルな通知なのに、「⁠Slackへの通知が失敗しました」という通知が届いたら困ってしまうと述べていました。

竹澤有貴さん「PHPデプロイツールの世界⁠」⁠

竹澤有貴さんは、デプロイツールについて、使い方ではなくアプローチの仕方の違い等について発表しました。

デプロイする方法は、FTPを使い手動で行う、rsyncでアップロードするなど、たくさん存在します。また、PEARからComposerに、ライブラリなどはプロジェクトごとで管理する方針に変化しています。GruntやGulpなど、フロントエンドもまた進化し続けています。

デプロイツールの主なタスクと、そのための3つのツール

竹澤さんは、デプロイツールの主なタスクとして次の事柄を挙げました。

ライブラリのインストール
フロントエンドタスク実行
複数のリモートサーバ（Vagrant, dockerなど）へ接続
ローカルタスクの実行（rsyncなど）

これらをPHPに統一したい、また、他の言語で行おうとすると難しいときには、PHPのデプロイツールを使おうと述べ、次の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サービスであるカラーミーショップが10週年を迎えます。河野匡貴さんは、今回このサービスをS3互換のストレージサーバに移行したことを発表しました。

カラーミーショップはPHPで、独自フレームワークを使っていて、公開しているAPIはRailsやCoffeeScriptで書かれていると紹介しました。顧客はPCのからAPPサーバにアップすると内部でFTPサーバにアクセスする仕組みです。参照はCDNを通じてアクセスされます。

今回移行しようとしているS3互換のストレージサーバとは、APIがS3互換で、裏側がMogileFSであり、S3と同じと考えてくれれば問題ないと話しました。

最初に、次の事柄について検討したと話します。

1. FTPサーバとやり取りしているロジックを1箇所に集約する。
2. ロジックを変更してS3互換サーバーに更新がかかるように。

そこで、FTPからS3互換サーバに移行するときに便利になるように、ファイルアクセスを抽象化してくれるライブラリを探したとのこと。結果、Flysystemというライブラリが便利なことがわかりましたが、このライブラリは5.4から対応だったため、5.3で運用していたカラーミーショップでは使えないことが分かったそうです。全体を5.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サーバに更新がされる処理を削除したとのこと。ただ、18台もあったので3ヶ月くらい掛かったと振り返りました。

河野さんは、移行の感想として「画像サーバを移行しようという話が出たのが今年1月で、すべて終わったのが9月で長かった。大きな障害がなく無事移行が完了出来たのが一番良かった」と述べていました。

仲裕介さん「WebRTC開発者向けプラットフォーム「SkyWay」の裏側⁠」⁠

NTTコミュニケーションズの仲裕介さんは、SkyWayの開発体制の推移や裏話（開発の歴史）を発表しました。冒頭、「⁠全くPHP関係ない発表に来ていただき、ありがとうございます」と前説していました。

本発表では、SkyWayの裏側（開発の歴史）と、大企業でのスタートアップ的なことも悪くないということを伝えたいと話しました。

WebRTCとは何か

最初に、WebRTCについて、ブラウザだけで（プラグインなどのインストールなしで）動作するリアルタイム通信の技術であると説明しました。音声、映像データのやり取りが可能で、ブラウザに限らず動くことも合わせて示しました。

SkyWayとは

SkyWayは、WebRTC技術を用いたP2Pのビデオチャットなどが簡単に扱えるライブラリ／サービス／プラットフォームです。SkyWayにはJavaScriptだけではなく、iOSやAndroid向けのSDKもあることや、ファイヤーウォールやNATを越えるときに必要なサーバ機能などがあることを紹介しました。

WebRTCはネットワークからアプリケーションレイヤまで幅広い技術が必要となります。ネットワーク側はアプリケーションレイヤの人にはかなり難しく、そのあたりを肩代わりすることで、アプリエンジニアが実装に集中できる環境を提供していると説明しました。

SkyWayの裏側: 開発の歴史

仲さんのチームはR&D的な側面も持っていて、NTTコミュニケーションズとしてはネットワーク分野に強い会社なので、その強みや色を出そうということからSkyWayのプロジェクトが発足したそうです。

次のような進行で開発が行われたと紹介しました。

ステップ1
- サーバーは自社クラウドCloudn
- 開発言語はErlang
- JS SDKは peerjsをフォークしてつくった
- Webサイトはgh-pagesで公開.ioのドメインでやったらかっこいいという理由(笑)
ステップ2
- インフラ構築自動化
- モダン感が出てきた
- 管理画面側のバックエンドはFuelaPHP
- 同じくフロントエンドはSPAな構成に
- FuelでのサーバーサイドレンダリングとSAP側の住み分けを行った
ステップ3、4
- 自動化をさらに加速
- TRUNサーバーを追加
- iOS/AndroidSDKの公開
ステップ5
- システム冗長化
- Log収集と解析機能
- Golangの導入

最初はなかなかモダンな開発にできなかった開発体制も、時を経るにつれてモダン環境に進化していったと振り返っていました。

まとめ

WebRTCはかなり難しい技術が折り重なっていますが、これをユーザが使いやすい形に落とし込んでいるSkyWayにはいろいろなバックグラウンドがあると感じました。PHPユーザの皆さんもぜひ一度試してみてはいかがでしょうか。

ライトニングトーク

恒例のライトニングトークが行われました。

深澤ひかりさん「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さんの乾杯挨拶のほか、ライトニングトークやプレゼントが当たるジャンケン大会等も行われ、皆さん、歓談を楽しんでいました。

本イベントのレポートは以上になります。