PHPカンファレンス2012 参加メモ(その1)

PHPの今とこれから 2012(日本PHPユーザ会 廣川類氏)

開発のソーシャルコーディング対応

PHP5.4

  • 高速化
  • Trait:単一継承の言語でコードを再利用する仕組み
  • 日本語の扱いが便利に:Zendエンジンマルチバイト対応標準化
  • コールバック関数による置換(5.4.1〜):正規表現置換eオプション

PHP5.5

  • リリース時期未定(2013/3 ?)
  • 目玉機能は、(今のところ)Generator
  • finallyキーワード
  • パスワード用ハッシュ


いまだからできる、ふつうのはなし(グリー株式会社 上村宏紀氏)

大規模とは

テーブル分割

  • 最初から大きくなることが分かってるテーブルを分割して別々のサーバに置く

→ あとから分割するのはとても難しい

  • ユーザidでmodをとって100分割
  • 分割したテーブルをサーバにマッピング

よくやる解決方法

  • スレーブ増やす
    • 参照クエリの数が増えた時
  • スケールアップ
    • メモリ増やす
    • Fusion-io使う
  • クエリのチューニング
    • covering index
    • index full scan(特殊なケース)

→ IO Waitを減らす

  • GREEではDB切換えをオンサービスで行っている
    • auto_incrementを上げる(duplication entry対策)
    • 更新を新セットに向ける
    • レプリケーションを切断、撤去

クエリのチューニング

  • バッチの処理が遅くなっている
    • レプリケーション遅延が頻発
    • 4000/secのupdate文が飛んでいた
    • in句で50件ずつまとめて更新するようにした

→ 処理速度が向上

  • レビュー
    • github:enterpriseを活用した開発スタイル
  • デプロイ
    • 1サイクルを短くする


徳丸本に学ぶ安全なPHPアプリ開発の鉄則2012(徳丸浩氏)

  • 鉄則1: PHP自体の脆弱性対処をしよう
  • 鉄則2: Ajax脆弱性対処をしよう
  • 鉄則3: 競合条件の脆弱性対処をしよう
  • 鉄則4: htmlspecialcharsの使い方2012
  • 鉄則5: escapashellcmdは使わないこと
  • 鉄則6: SQLインジェクションの対処
  • 鉄則7: クロスサイト・スクリプティングの対処
  • 鉄則8: クロスサイト・リクエスト・フォージェリの対処
  • 鉄則9: パスワードの保存はソルトつきハッシュ、できればストレッチングも
  • 鉄則10: 他にもたくさんある脆弱性の対処

鉄則1:PHP自体の脆弱性対処をしよう

  • PHPの高危険度脆弱性は多いが、影響を受ける場面が限られているものが多い
  • アプリケーションが、当該脆弱性の影響を受けるか、外部からは判断しにくい
  • アプリケーションやフレームワーク脆弱性の原因となった場合、外部からの攻撃が容易となる

脆弱性対処のアプローチ

  • 正当的な方法
    • 脆弱性情報が出る毎に影響を評価し、対処方法を決める
    • 影響が大きく、回避策がある場合は、まず回避策を適用する
    • パッチ、PHP新バージョンのアプリケーションに対する影響をテストする
    • 本番環境にパッチ適用、バージョンアップ
  • Linuxディストリビューションのパッチに任せる

鉄則2: Ajax脆弱性対処をしよう

  • evalインジェクション
  • JSONハイジャック
    • Androidの標準ブラウザでハイジャック成功(Android2.3.4。4.0.3では直ってる)

鉄則3: 競合条件の脆弱性対処をしよう


PHPではじめるオブジェクト指向(VOYAGE GROUP 田中康一氏)

原則・法則・格言

  • デメテルの法則
    • メソッドに渡されたオブジェクトとメンバオブジェクトのみにメッセージを送る
    • 1行に->は1つまで
  • 単一責任の原則(SRP)
    • クラスを変更する理由は1つ以上存在してはいけない
  • リスコフの置換原則(LSP)
    • 派生型はその基本型と置換可能でなければならない
    • 基本クラスのメソッドを使えなくする、派生クラスから例外を投げる、はやっちゃダメ
  • 開放閉鎖の法則
    • ソフトウェアの構成要素は拡張に対して開いていて、修正に対して閉じていなければならない
  • 依存関係逆転の法則
    • 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。
    • 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。
  • インターフェース分離の原則
  • Tell, Don't Ask.