PHP カンファレンス 2009・テックデイ 私的不完全議事録 【pcj09】

IT

9/5 に大田区産業プラザ PiO で開かれた「PHP カンファレンス 2009 (テックデイ)」の私的不完全議事録です。ご利用に際しては、昨日の「ビジネスデイ」議事録と同様、正確さはあまり期待せずにお願いします。



目次

基調講演 (廣川 類氏)

PHP の歩み

  • 2000/5 v4.0 PEAR
  • 2001/12 v4.1 mbstring統合/性能改善/入力セキュリティ改善
  • 2002/4 v4.2 自動グローバル変数のデフォルト無効化/mbregex/zend-multibyte
  • 2002/12 v4.3 CLI/stream
  • 2005/6 v4.4 バグ修正
  • 2008/8 v4.4.9
  • 2004/7 v5.0 エンジン・OOP 大幅強化: ZE2/XML 対応強化(SimpleXML)/Web サービス(SOAP)/DB 強化(SQLite、MySQLi)
  • 2005/11 v5.1 実行速度改善/PDO
  • 2006/12 v5.2 メモリ管理・速度改善/入力フィルタ
  • 2009/6 v5.3 名前空間/クロージャ/late static binding/GC 改善/intl/phar/fileinfo/MySQLnd
  • v6.0 Unicode 対応/レガシー機能削除
  • v5.4 DB 整理/PHP6 互換

2000 万の Web サイト、100 万台の Web サーバに利用されている。

PHP アンケート 2009

(会場に)メインで使っている PHP のバージョンは? → PHP4 の人はほとんどおらず、PHP 5.2 が 7 割くらい

PHP5 への移行

  • PHP4 のサポート終了

    • 2008/8/8 リリースの PHP 4.4.9 が最終版
    • 致命的なセキュリティ修正も実施されない
    • 大垣氏の Wiki で脆弱性公表中
  • PHP5 移行の遅れ

    • 2004 年に PHP5 が公開されたが、2007年の普及率は 50% 以下
    • その理由

      • PHP4 の完成度の高さ(PHP3 と異なり、移行の必然性がない)
      • PHP5 の非互換性、性能
      • 新機能への関心が低い

PHP の実行速度

  • PHP 5.1/5.2 ZendEngine 大幅に高速化
  • PHP 5.2/5.3 メモリ使用効率化
  • ただし、アプリケーションの性能はその他の要素で決まることが多い
  • php-src/Zend/bench.php によると、4.4が 32、5.2 は 17、五。3が 12、6.0 が 13 くらい

PHP とセキュリティ

  1. アプリケーション固有の脆弱性 (XSS 等)
  2. 設定に起因する脆弱性 (OS、Web サーバ、DB、PHP)
  3. システム固有の脆弱性 (OS、Web サーバ、Web ブラウザ、DB、PHP)

攻撃手段は日々進化する。初心者だからといって許してくれない。

  • 基本を守る
  • 最新の情報を見る (大垣氏の Wiki、gihyo.jp など)

PHP と QA

  • PHP のコード品質は高い。COverity (米国国土安全保障省)によると、100 万行当たりの欠陥数は PHP = 3、Perl = 29、Python = 4、Samba = 16 くらい
  • テストされていないコードには欠陥がある
  • testFest: テスト整備コンテストによるコードカバレッジ改善
  • 2008 年に続いて 2009 年も開催
  • コードカバレッジ率は PHP4 では 39.2%、5.2 = 59.4%、5.3 = 74.0%、6.0 = 71.7%

PHP 5.3

  • 2009/6 リリース
  • PHP6 までのつなぎ。PHP6 - Unicode + pecl/intl
  • レガシーコード整理: ZE1 互換モード廃止
  • GC 改良: 循環コレクタ
  • Late Static Binding: スタティック宣言を実行時に解決
  • Dynamic Static Call: 動的変数によりスタティックコール
  • 名前空間: PHP6 からバックポート
  • ラムダ関数/クロージャ
  • Phar アーカイブ対応: PHP アプリの配布が容易に
  • 構文改良/追加: NOWDOC、goto
  • 国際化エクステンション: pecl/intl
  • mysqlnd (MySQL Native Driver)
  • OpenSSL エクステンションに OpenID サポート追加 (Zend Framework 1.5 でサポート)
  • SPL 強化: Stack、Queue 等追加
  • PHP 6 で廃止予定の機能に警告

PHP 6.0

  • PHP6 は遅延中: 2009/5 に開発者会議開催
  • 国際化/Unicode 化

  • レガシーコード削除

  • 議論中

    • 識別子の大文字/小文字区別 PHP 6.1
    • Traits 継承の柔軟化

mbstring と文字エンコーディング変換

内部コードは Unicode に統一される。

課題: PHP6 と日本語

PHP の未来

  • PHP が成功した理由

    • コンセプト (初心者に優しく、現実的)を維持できた
    • コミュニティのサポート
    • 個人的には、他のスクリプト言語に比べて PHP が特に優れているとは思わない
  • 常に改善・改良を求めることでオープンソースの活力が維持される

    • 安定した枯れた環境は実用的なシステムも有用だが、進化は必然
  • 新たな開発者(特に若い人)に参加してもらう工夫が必要

  • 改善/機能強化の提案、貢献の方法

日本 PHP ユーザー会の紹介

  • 設立主旨……PHP ユーザ相互の情報交換およびコミュニティの健全な発展
  • メンバー……PHP ユーザ会員と思ったらメンバー。このような席で名乗りを上げてください



The days in PHP community, Taiwan
台湾 PHP コミュニティの日々 (江 明宗氏)

  • 台湾で PHP の活動を行っても、これほどの人数が集まることはない。スタッフの皆さんに感謝したい。
  • 機会があれば台湾に来てほしい。大変美味しいものもあり、民族的な活動もある。素晴らしい景色もあり、高速鉄道もある。
  • 台湾の FLOSS コミュニティ……FLOSS Community Manual
  • http://e107.tw/
  • http://www.openbw.org/

台湾 PHP コミュニティのエピソード

  • 台湾ではハードが強い。今でもそう。PC 界の王者。
  • 例: シリコンウェハース
  • ソフトウェアは? ──ローカライズ、書籍、トレーニングが主だった。
  • ビジネスモデルは、コピーを販売すること。パッケージソフトの販売。
  • 台湾のソフト業界で盛んなのはゲーム。多くは日本から来たもの。
  • 企業が PC を投入するようになり、システム開発(SI)という分野が興った。しかしとても小規模。

    • 2 バイト文字
    • 不正コピー
    • インターネットバブルの崩壊
    • 限られた市場規模──台湾の総人口は 2 千万強

私が PHP を始めた理由

  • 何と言っても若かったから。
  • コンピュータ販売の会社で、ある程度のメンテもできるという人間だった。
  • 同僚と能力面で差別化をしようと PHP の勉強を始めた
  • 最初は予算が限られていた。PhpNuke、myphpnuke や XOOPS がよく使われていた。
  • 学校の先生から提供されたリソースもあった

twpug.net 誕生について

  • TIC 100 という活動(Technology Innovation Convention)で、OSS の中文化のリソースを提供した
  • この活動を広めようと、osobiz.com を立ち上げた
  • 技術的な問題に対するソリューションを提供したり、ビジネスモデルについての話題を提供したりした
  • 技術的な話題が多く、ビジネス的な話は少ないことに気づいた
  • 当時は Palm がよく使われていたので、Palm の話題が主
  • twpug の p を Palm ではなく PHP にできないか? → twpug.net を立ち上げた
  • twpug.com と twpug.net を平行してやっていたが、.net (PHP のほう)が活発に
  • osobiz.com は続ける意味がなくなってきたので、ブログのアドレスに転用

twpug.net の成長について

  • 技術的な質問に答える
  • OSS の PHP アプリケーションを収集
  • 新しいアプリの紹介
  • PHP 関連のニュースの翻訳
  • 話題のアプリケーションを中文化
  • アプリケーションやツールの推薦

最近のトピック

より多くの PHP 開発者が必要

  • Web 2.0 関連サイトは台湾にもたくさんあるが、十分な効果を上げているとは言えない
  • コストダウンという課題。PHP はコストフリー
  • 中国本土では、PHP 開発従事者は増えているが、PHP に対する自信を彼らは持っていない。国際的な開発者として、信頼できる人間を確保したい
  • 利用可能なオープンソースソフトウェアが蓄積されている。台湾の多くの企業が、Windows ベースからウェブベースに切り替えようとしている

ソフトウェア産業

  • 産業の変化を期待している
  • ソフトウェア開発に関する教育・研修はまだまだ不十分
  • IT 関連の学校を出たと称する人間がコードを書けない。学卒比率は人口比で高いのにこの状況
  • 多くの学生が先に就職口を探し、その後勉強する。そのため就学率は高いが学力は低い
  • ソフトウェアのサプライチェーンをきちんと作って行く必要がある
  • インターネットの速度が日本に比べてだいぶ遅い
  • ビジネスモデルという点でも、パッケージからサービスへと軸足を移す必要がある
  • 競争から協業へ。台湾の市場規模は大きくないので、競争ばかりやっていてもあまり意味がない
  • 特許や著作権から標準へ軸足を移す必要あり。多くの会社が、自前の特許や著作権でビジネスをしようとしている
  • 中にはパテントゴロのような所もある

新しいソフト会社

  • GIS アプリ
  • ソーシャルネットワーキング
  • 情報セキュリティ
  • デジタルホーム──世界各地ともまだ模索段階だが、台湾はハードが強い。ハードメーカーが興味を示している
  • モバイルオフィス──台湾は人件費が非常に高い
  • E ラーニング──台湾には多くのサイトができてはいるが、アクセス率は高くない
  • ペット関連──台湾でも出生率が下がってきていて、ペットが歓迎されている
  • 遠隔医療・看護──台湾でも人口構造が老齢化
  • タレントショー (オーディションのようなサイト)
  • 各種オンデマンド
  • 共同購入
  • 予約システム

これらの分野ではすべて PHP を使うことができる

質疑応答

  • 台湾では地方における IT 産業は?

    → 台北に集中している。ほかの地域ではまだ十分ではない。ただ、ボランディアのコミュニティは存在している
  • ソフトウェアの国際化は進んでいるか?

    → 先ほど紹介したとおり、市場規模が大きくないので、台湾でサイトを作るときは英語・Traditional Chinese・Simplified Chinese の 3 言語で最初から作る
  • 市場規模が小さいとのことだが、他の言語に比べて PHP のシェアは?

    → サイトだけで見ると PHP のシェアは非常に高いが、全体的に見ると Java や C++ の比率が高い
  • 台湾において、PHP 開発でよく使われるフレームワークやツールはあるか?

    → Zend Framework、Code Igniter など。Symfony を使っている人もいる


High Performance APC
APC によるハイパフォーマンスの実現 (Brian Shire 氏)

(suno 注: このセッションは私の技術レベルをはるかに超えていたため、不正確な記述が多数含まれていると思われます。APC に詳しい方で、議事録の内容の誤りに気づかれた方は、ぜひご指摘ください。よろしくお願いします。)


自己紹介

APC エクステンション

  • ソースコード解析前にキャッシュされているかどうかを調べる
  • キャッシュにあれば、そこから実行する
  • 設定時にメモリの割り当て量(shm_memory)が重要
  • キャッシュには 2 つある

    • opcode のキャッシュ

      • apc.stat = 0 にしてファイルシステムへのアクセスを高速化する
      • その代わり、ファイルをアップデートしたら Apache の再起動が必要
      • ファイルや変数の内容をダンプすることができるが、現段階では実験的なもの
      • PHP のパフォーマンスは当初はあまりよくなかった。キャッシュのヒット率が悪いとユーザーエクスペリエンスに悪影響
      • apc_compile_file() …… プログラムの中でファイルをキャッシュに入れる関数
    • ユーザー変数キャッシュ

      • apc_store() 関数
      • サイト全体で使われるデータで使うのが理想的

パフォーマンスチューニング

  • APC は共有メモリを使っているので、セマフォ的にアクセスをロックする必要がある
  • デフォルトではファイルロッキングを使う
  • そのほかにも mutex などを使ってロックすることができる。スピンロックが最も効率的で、Facebook でも使われている。タイムアウトの問題があるので、使用には要注意
  • 遅延読み込み(Lazy Loading)──PHP のコードにパッチを当てる必要がある
  • include() などでファイルを読み込むとき、必要になった時点で読み込む。Facebook ではこれなしで成立しないほど重要な機能
  • キャッシュに膨大なデータを入れておくと、必要なデータを探すのが大変。そこで Iterator を作った

APC の将来

  • 現在の最新版は 4.0 (実験的)
  • Least Frequently Used (LFU)キャッシュ削除──キャッシュの中で最も使われていないデータを削除する

    • 設定が複雑になる
  • 共有メモリセグメントの情報を表示
  • Abstract Extension API and Dependency Interface Google Summer of Code プロジェクト wiki.php.net/gsoc/2009/api
  • No-copy shared cache (研究中)

    • キャッシュからコピーせずに、キャッシュの内容を直接実行する

(会場に)「APC を使ったことのある人は?」──会場から数十人の手が上がる


質疑応答

  • PHP 6 から本体に取り入れられるのではないかという話があったが?

    → そのとおりで、PHP 6 からは本体に取り込まれることになっている
  • APC の開発体制、雰囲気を教えてほしい

    → 主要開発者は 9 人。PHP 本体にコントリビュートしている「準レギュラー」と言うべき人が自分を含めて 3 人。APC ML がコミュニケーションにはもっともよく使われている。バグレポートでもやりとりを行っている。開発者によって興味のある分野が違う(Yahoo 社員、Facebook 社員で異なる)。問題が難しく、直す以前に理解することが難しいこともあるので、利用者には忍耐をお願いしたい
  • Apache 再起動をせずにファイルを移動する方法はないか?

    → 答えは Yes。apc_delete_file()や apc_compile_file() を利用することになる
  • PHP 5.1 や 5.2 の頃は APC のほかにも高速化拡張があったが、みな廃れてしまった。この状況を APC の開発者はどう見ているか

    → なくなったものもあるが、excache など興味深いものも出てきている。全体としてはポジティブに捉えている

(会場に)「APC の設定は難しいと思うか?」──ドキュメントが欲しいところだ、の声に「I'm sorry」(会場笑い)

Brian「具体的にこういう所がやりにくいという箇所はあるか?」

会場「導入した瞬間に体感的に速くなってしまって、それ以上何もする気にならない。初心者向けに『ここをこうやるといいよ』という箇所があれば教えてほしい」

Brian「スタックのオプション、ロッキングのオプションを変えてみるのがおすすめ。ユーザーキャッシュの設定もいじってみて」

  • APC を入れたときに非常にメリットのあるサイト、あまり意味のないサイトというものはあるか?

    → PHP を使っているすべてのサイトが効果を体感できるはず。特に大規模なコードを使っているサイト、ユーザーキャッシュを効率的に使っているサイトではより効果が感じられるだろう。Facebook のようなサイトはリアルタイム性が求められるのでキャッシュの効果が感じられるが、そうでないサイトではあまり差は出ないかもしれない
  • eAccelarator など他の高速化エクステンションから乗り換える際に気をつけるべきことは?

    → 充分にテストをするという基本的なアドバイス。予期しない結果になることもあるのでテストを入念に。
  • ボトルネックの調査をしたら DB が足を引っ張っていたということがあった。先にここを調べてから APC の導入を考えるべきというような公式見解を出してほしいという要望を述べさせていただきたい
  • Twitter の TL から代読(会場笑い)。コマンドラインインターフェイスから APC の状態を見るいい方法は?

    → 現時点では不可能。APC のステータスを取得したいということであれば、data$http を取得してくればいいのでは
  • PHP 愛好家がこれだけいるのに APC 使用者は少なかった。Facebook について興味がある人が多いのだろう。なので Facebook の雰囲気や給料がいいのかとか(会場笑い)教えてほしい

    → Facebook はすごい会社。厳しい要求もあるが、クリエイティブな職場だ。従業員 1000 人のうち、PHP エンジニアは 300 人程度。言語は C、C++、Java、その他のスクリプト言語も使われている
  • 半年ほど前に APC の導入試験をしたが、Zend Optimizer と併用したらうまく動かなかった。解決方法はあるか?

    → 解決する方法はあるようだが、ソースコードが今手元にない。新しいプロジェクトが進行中で、それを使えば Zend Optimizer と併用できるようだ


PHP を見える化する (新原 雅司氏)

自己紹介

サービス

PHP を見える化する PHP Visualization

  • 初心者〜中級者を対象
  • バージョン 5.2.10

基本──変数の見える化

  • echo
  • print_r
  • var_dump

マニア

  • debug_zval_dump

    変数の型と参照カウンタが見える

内部表現

zval [Zend/zend.h]



struct _zval_struct {

  zvalue_value value;

  zend_uint refcount;

  zend_uchar type;

  zend_uchar is_ref;

}

PHP と言えども変数に型はある。


プロファイル

Xdebug エクステンションを使う。

  • プロファイリングファイルの出力
  • 解析ツール

    • KCacheGrind
    • MacCallGrind
    • WinCacheGrind……Windows アプリケーション
    • webgrid……Web ツール
    • Carica CacheGrind

XHProf

  • Facebook で作られている Web ツール
  • 呼び出し履歴を図示できる
  • DIff Report……2 回の計測の差を比較することができる

Function Trace

  • Xdebug の一機能
  • すべての関数呼び出しの記録を取ってくれる(引数と返り値も)

(デモ中に BSoD が出て会場爆笑)

まとめ

  • プログラムは思ったとおりに動くのではなく、書いたとおりに動く
  • 見える化する手段がいくつかあるので活用する
  • (ガンダムを見習って)目指せ PHP カンファレンス 30 周年!



CakePHP ストーリー (安藤 祐介氏)

自己紹介

高速開発フレームワーク

会場アンケートで、CakePHP 使用経験者は会場の 7 割ほど。


  • フレームワークを使わないと……

    • 全てのプログラムに必要な処理を記述
    • 人によって書き方が異なる(プログラムによって構造が異なる)
  • フレームワークを使うと、ルールに沿った部品だけを作成。すべてのプログラムが同じ構造になる
  • 生産性の向上・保守性の向上……プログラム作成の作業が簡単になり、同じやり方で誰でも作成できるようになる

すべてのレベルの PHP ユーザーが対象

  • インストールが簡単。アーカイブを展開して Apache のドキュメントルートに置くだけ
  • 少ないコード量で機能を実装可能

上級者向け機能

  • コントローラーを拡張する Component
  • モデルを拡張する Behavior
  • ビューを拡張する Helper
  • アプリケーションの一部を再利用する Plugin

小さくしてまとめるのが CakePHP 流。


国内での普及状況

CakePHP で作られている有名サイト

資料

コミュニティ

  • 国内外で多くのユーザが利用
  • 活発なコミュニティがプロダクト・ユーザのレベルを高めている


CakePHP の未来

  • 現行版は 1.2
  • 次は 1.3→2→3 の予定。PHP 5 化、PHP 5.3 化を予定(4 系列サポート終了)

「CakeMatsuriTokyo」(10/30・31)を計画している。@cakematsuri をフォローしよう!

CakePHP の醍醐味

  • 素早く快適な開発
  • オープンマインドでレベルアップ

まだまだ発展する Cake ワールドを楽しんでみませんか?



PHP を「いじり」倒す 10 の方法 (moriyoshi 氏)

プロローグ

  • 例えば、Perl の言語仕様にイヤな所があっても、それを変えようとは思わない。では PHP は?
  • PHP とは何か?

自己紹介

  • PHP の開発に 2003 年頃から参加 (<?php phpcredits(); ?> で名前が出る)
  • 主に水面下で活動
  • 本業では PHP は使わず、C++ と Python を使っている

PHP の内部構造を知ろう

  • SAPI モジュール

    • Web サーバの実装とのグルーとなる部分
  • SAPI

  • ZendEngine

    • PHP のコア
    • 言語パーサのほかに設定ファイルパーサなども含む
  • Extensions

    • 新たな関数やクラスを追加する通常の extension と、ZendEngine 自体を拡張する zend extension の 2 種類がある
    • 厳密な違いはない

(以下、駆け足で関数を追加するデモ)


改造に当たっての Tips

  • --enable-debug つきで configure しよう
  • PHP のソースツリーの一番上にある .gdbinit を活用しよう

    • printzv
    • printzops
    • zbacktrace
    • など

(以下、駆け足で Boost.PHP の紹介)


Q4M と Flare を使ってスケーラブルなサービスを作る! (漢 祐介氏)

自己紹介

Q4M とは

SQL で書けるキュー

  • Q4M のメッセージは SQL で書く
  • キューの格納は INSERT、取り出しは queue_wait() 関数で、参照は SELECT で。削除は queue_end() 関数で行う

導入が楽

  • MySQL 5.1 さえあればどうにゅできる
  • 言語を問わず利用できる
  • API のドキュメントは未整備

Flare とは


Web アプリケーションにおける高負荷になりやすい(であろう)ポイントと解決方法

  • データベースに対しての read/write が多い系

    • 従来はスケールアップで切り抜けて来た
    • よくある解決方法: Master/Slave 構成にする
    • 問題: ロックなどが発生して、DB からのレスポンスが遅くなると、クライアントへのレスポンスも遅くなる
    • これからは Q4M も使いましょう
    • クライアントにはさっさとレスポンスを返してしまう。多分、ユーザが何かしらの操作を行っている間に write は終わっている
  • Web サーバが頑張っちゃう系 (.xls ファイルや .pdf ファイルを作るなど)

    • 従来は 5 分ごとに cron で読み込んで、データがあれば処理を行わせていた。cron 実行のタイミングが難しい
    • これからは Q4M を使いましょう
  • 重い SQL を頑張っちゃう系 (集計処理をさせるなど)

Web アプリケーションにおけるスケールアウトしにくい(であろう)ポイントと解決方法

  • スケールアウトしにくいポイントの代表例はセッション

    • よくある解決方法: DB に格納する
    • master/slave 構成は同期問題があるためになかなか難しく、そのために 1 台になりやすい
    • これからは Flare を使う

symfony での実装方法

少し凝った Q4M と Flare の使い途

  • Q4M では priority を使い、ジョブを分離する
  • Q4M では multi queue を使い、色々な Queue を一元化する
  • Q4M では queue をバラまく。大きくなったら細かくして分散する
  • Cron の代わりに Q4M を使う
  • Q4M では timeout を最大でも 60 秒にする

  • 小さくて教諭するデータは flare に

まとめ

  • Q4M を使うことで、DB へのアプローチに幅が出てきた
  • Flare はセッションストレージの大本命。セッション以外にも使えそう




Symfony, a web framework for professional websites (Fabien Potencier 氏)

(冒頭で日本語による挨拶)

自己紹介

Twitter のアカウントは @fabpot。

symfony

豊富なドキュメント

  • オープンソースのドキュメント

    • Practical symfony (400 ページ)
    • symfony リファレンスガイド (200 ページ)
    • Form book
    • The book (450 ページ)
  • 日本語の書籍も 2 冊。また、『実践 symfony』『symfony リファレンス』も刊行予定

とても活発なコミュニティ

symfony 1.0──2007 年 1 月

symfony 1.2──2008 年 11 月

  • 分離化膿だがまとまりのあるコンポーネント: symfony プラットフォーム

    • FOrms、Routing、Cache、YAML、ORMs……
  • コントローラはまだ Mojavi ベース

    • View、Filter チェーン……

ロードマップ

  • 1.0──2007 年 1 月
  • 1.1──2008 年 6 月
  • 1.2──2008 年 11 月
  • 1.3──2009 年 11 月
  • 1.4──1.x 系最終バージョン(2009 末)。1.4 = 1.3 - deprecated features (廃止予定の機能)


《エンタープライズ》バージョン

  • Version 1.0 LTS: 3 年間メンテナンス
  • Version 1.1、1.2、1.3: 1 年間メンテナンス
  • Version 1.4 LTS: 3 年間メンテナンス
  • 通常リリース

    • バグ・セキュリティ修正、PHP 新バージョンへの互換性
    • (小さな物でも)機能追加なし
    • アップグレードは簡単で安全
  • なぜこれらを「エンタープライズ・バージョン」と呼ぶか?

商用サポート

symfony だけのカンファレンス

世界各地でのイベント

  • symfony camp (各国)
  • symfony day (ドイツ)
  • 来年日本で Symfony Live をするなら参加したいですか? (大勢挙手)「OK, done.」(会場笑い)

たくさんのアプリケーション

プロフェッショナルのためのフレームワーク

  • セキュリティ
  • 実行環境切り替え
  • ユニット/関数テスト
  • 設定と拡張のしやすさ
  • Admin ジェネレータ
  • 開発用ツール
  • キャッシュ機構
  • きれいな URL
  • 国際化機構
  • 進んだ form サポート
  • ORM

symfony は、まとまりがあるがバラバラにも使えるクラス群だ

環境切り替え

  • 開発者……開発環境
  • 顧客……テスト環境
  • エンドユーザ……実運用環境

現在、本番環境で開発している開発者がいたら、今すぐやめたほうがいい(会場爆笑)。

環境ごとに異なった設定が必要。例えば開発環境ではキャッシュや統計情報は不要だが、実運用環境ではデバッグ情報は不要。この主の環境設定を symfony では非常に簡単に行える。

開発者用ツール

  • エラーページ

    • PHP の生エラーメッセージはブラウザに表示されたくない。機密情報が漏れることがある
    • symfony ではこの種のエラーメッセージは絶対に表示されない
    • しかし開発環境では、より多くのエラー情報を生成させたい
    • デバッグに必要なありとあらゆる情報が得られるようになっている。特に設定しなくてもデフォルトでそうなっている。安全な環境構築
  • Web デバッグツールバー

セキュリティ

  • XSS、CSRF、SQL インジェクション対策も設定ファイルで (csrf_secret / escaping_strategy など)

テスト

  • テストは重要。しかし多くの場合、テストを手作業でやっている。効率の面でよくない
  • ウェブサイトに新たな機能を追加したら、またこの手作業を繰り返さないといけない
  • たいていは 1 つか 2 つをテストするだけで、残りの部分はおざなりに
  • symfony にはブラウザシミュレータがあり、手作業でやっていたことを自動化できる
  • 緑のバーが出ればテストは OK。何か上手く動作しなければ赤いバーが出る
  • 副作用があるような機能を追加したときなどに非常に有効

多フォーマットのネイティブサポート

  • リクエストは(デフォルトでは HTML)フォーマットを持つ

  • コントローラとモデルは同じ
  • 異なるテンプレート

REST アーキテクチャ

  • GET、POST、PUT、DELETE、HEAD のサポート
  • PUT と DELETE はブラウザでシミュレート
  • REST リソースも Routing でサポート

「symfony ミートアップ東京」9/6 (日)夜に開催 → bit.ly/sf-tokyo

質疑応答

  • ドキュメントに要望。Forms in action (suno 注: 聞き間違いかも)はいつ完成するか?

    → ドキュメントはだいぶあるにはあるが、カバーしていない部分があるのも認識している。今年の末までには揃う。もちろん、あなたのほうでコントリビューションしてくれてもいい
  • 普段使っている 1.2 ではキャッシングに APC を推奨しているが、実際に使ってみると相性が悪い。今後の方針は?

    → キャッシュのルーティングに symfony 1.2 は問題がある。キャッシュの設定を変更すると直る(suno 注: 具体的にどう変えるのかは聞き取れなかった)。間違いなくパフォーマンスは著しく向上する。直感に反する設定だが、symfony 1.2 ではこれでよい。1.3 以降はこの部分も修正される予定
  • 日本で会社として symfony を使った開発をしている。2.0 へのマイグレーションはサポートされるか?

    →symfony 2.0 は 1.x 系列とは違ったものになる。とは言ってもコンポーネントは同じものを使う。コントロールまわりは 1 から書き直すことになる。1.x → 2.0 に簡単にはアップグレードできない。アップグレードツールが提供できるかどうかは不明。ただ、1.x で「ベストプラクティス」に従って作られたものであれば、比較的容易に移行できるはず
  • symfony 1.0 のメンテナンスが間もなく終わるが、1.3 には deprecated feature が多いようだ。1.0 から 1.3 への移行はフルスクラッチで書き直した方がよいか?

    → 私たちは 1.0 から 1.3 へのマイグレーションテストを行っているが、最も難しいのは 1.0→1.1 への移行だ。それに比べれば、1.3 への移行は比較的たやすい。deprecated の機能を削って行けば、1.4 への移行も可能になる。多くのユーザーが RedHat エンタープライズ Linux を symfony のプラットフォームに使っているが、この OS は PHP 5.1 までしかサポートしていない。このバージョンの PHP で動くのは symfony 1.0 しかない。だからこそ、この 6 月まで symfony 1.0 のサポートがある。ただ、現時点で 1.0 からの移行は考えるべきだ。1.0 からのアップグレードで問題があったら、メーリングリストを活用してほしい