あーく・りなっくす

プログラミングとかガジェットとかの雑記

PHP Conference 2016 に行ってきた

PHP イベント

ざっくりとした感想とか要点とかを書きます。

資料や Togetter は PHPカンファレンス2016 講演資料まとめ - Qiita にまとまっているのでそちらを。

セミナー

Composer プラグインを作ってみよう

資料：Composerプラグインを作ってみよう /phpcon2016 // Speaker Deck

  • Composer とは何か
    • PHP 5.3 以降で使えるライブラリの依存関係解決ツール
      • それ以外だと auotloader とか作ってくれる
    • すべてローカルに保存
      • ./vendor/ 以下に
  • Conposer プラグイン
    • 導入方法
      • ライブラリと同じで Composer で
    • イベントフック
      • Composer の実行を検知して何かをする
      • 例
        • 本体のダウンロードに割り込んで並列でダウンロードする
        • npm で JavaScript のライブラリを入れる
    • サブコマンド
      • Composer のサブコマンドとして実装する
      • 例
        • qaプラグイン
          • ./vendor/bin/xxx をサブコマンド経由で呼べるようになる
    • なぜプラグインを実装するのか
      • Composer で導入できるので、移植性が高く配布が楽
      • かつては scripts というライブラリで拡張していた
        • 導入するのに、 composr.json のコピペが必要だった
  • Composer とは何かというところに戻る
    • Composer でできること
    • 実はパッケージを作るフレームワークと言える
      • 「PHPで何かを作る」≒「Compser パッケージを作る」
    • Composer はなんでも知っている
      • パッケージがどういうものなのか
      • ライブラリの依存関係
      • プログラムの起動方法

Cygames を支える PHP と、その高速化の取り組み

資料：？

  • 開発スタイル／マインドセット
    • 面白くなければ意味がない
      • 面白さにゴールはない
      • 面白くなけれなバッサリ捨てることも
    • トライアンドエラーを繰り返す
      • 素早くリリース
      • 微調整とか
  • CS 最優先
    • 面白いかはユーザが決める
    • 即対応できるようなログの設計
      • リアルタイムでログを確認できるように設計している
    • 本番環境のデータを複製して、同じ環境で試せるように
  • 当たり前のことを当たり前にやる
    • 小さな差がピーク時に大きな差に
      • 不要な処理とか
    • 適切なリファクタリング大事
    • 運用や拡張がしやすい実装
  • 負荷分散
    • 分散・スケールアウトできるように
    • できるだけキャッシュに
  • 高速化
    • 「推測するな、計測せよ」
    • New Relic で解析
      • 重いクエリなどを地道に対応
      • DB 関連がボトルネック
      • データがもりもり増える
        • 必要がなくなったデータは順次パージ
      • イベント単位でテーブルを作成し、終わったらパージ
    • デカイのをサクッと drop しちゃうとレスポンス劣化しちゃう
      • IO がやれられる
      • 数秒とは言えほぼ舞にやるので問題
      • 緩やかな削除で対応
  • リリース時の取り組み
    • 職種やチーム問わずにレビューしてもらう
      • 全スタッフ≒ゲームユーザ
    • リリース前には実際に運用テスト
      • 数日間実施
      • 通常運用リハーサル
      • 緊急デプロイなどのフローも確認
        • 不具合が起きた想定で実施
  • 今／これからの取り組み
    • PHP 7 (7.1) 対応
    • 品質と生産性の向上、仕組みづくり
      • ゲーム特有の問題を検知できる仕組み
        • ○○はこんなセリフ言わないとか
      • ユニットテストや E2E 以外の何か
    • Zephir による高速化／共通化
  • Zephir やってみた
    • クエリや処理の最適化以外でのレスポンスの高速化
  • Zephir とは
  • メリット
    • 高速化できる
      • 主にループを多用するところ
    • PJ やフレームワークに関係なく利用可能
    • 特定箇所のみに適用可能
    • PHP に戻すことも可能
  • デメリット
    • デプロイフローが増える
    • 修正がしにくい
      • 修正の頻度が低いところなら採用できる

安全なPHPアプリケーションの作り方2016

資料：安全なPHPアプリケーションの作り方2016

  • Joomla! 権限昇格脆弱性
    • デモを交えて解説
    • 同じことをするメソッドが 2 つあった
    • 不要なコードは削除しましょうという話
  • それ以前の Joomla! にあった脆弱性
    • 正規のメソッドを使った問題
      • わざとバリデーションでエラーを発生させるなどなどで同じことができる
    • セッション汚染脆弱性
      • セッション変数を外部から変更できる脆弱性
    • デモ
      • オブジェクト・インジェクションで任意の関数を実行
  • OS コマンド・インジェクション
    • ケータイキット（MT）
    • 回避方法について
      • OS コマンド呼び出しを使わない
      • シェル呼び出しをしない
        • PHP では無理
      • 入力させたものを渡さない
      • エスケープする
    • もっといい方法があった
  • 正規表現インジェクション
    • phpMyAdmin
    • これもエスケープに関する問題
    • preg_replace() を避ける形で修正された
  • Zend Framework の SQL インジェクション
    • サポート終了した Zend Framework 1 の話
    • order()での問題
      • もともとアプリケーション側で対応すべきものをフレームワーク側でやっちゃったっていう話
  • XSS
    • js の文字列リテラルのエスケープは難しい
    • 回避方法
      • 過剰エスケープ
        • 読みにくい
      • HTMLノードを書いてそれをjsから参照
        • data-*のやつ
      • Inline JSONP
        • jsonにしておく
    • 結論としては HTML ノード経由か Inline JSONP かが楽
      • js のエスケープは人智を超えているのでやめよう
  • 安全なアプリケーションを作るときの原則
    • わかりやすく書こう
      • うますぎるプログラムはいけない
      • こなれた機能を使ってシンプルに
    • 「ややこしいことは起きがちな」機能は避ける
    • 局所的に脆弱性を解消する
      • 想定したものかのチェックとか
    • 防御的にプログラミング
    • コード、命令に対して、外部からの値を持ち込まない

LT

印象に残ったものだけ

家庭用ブロードバンドルータ上でWPを動かそう

  • ルータ上で PHP を動かす
    • OpenWrt

5.7の次のMySQL

  • PHP と同じで 5.8 ではないという

やさしいPHPコーディング規約の導入

  • php_cs でとりあえず引っかかったものを例外に追加
  • 徐々に対応していく
    • 無理に一気にやらない