Symfony Advent Calendar の14日目です！昨日は、@bakorerさんのPHPFog + Symfony2 でステージング環境を作る方法：Symfony Advent Calender 2011 JP – 13日目でした。
先日、東京のVoyage Groupさんで発表したLTの内容を、より詰めてまとめたいと思います。
Symfony勉強のLTでも話をしましたが、10月末よりSymfony Cookbookの翻訳を進めて、現時点では全記事が翻訳されています。クックブックと言っても、実際に役に立つ記事、これはあまり使わないだろ、という記事があると思います。そんなことをまとめて、主観的に感想とオススメ度を書いていこうと思います。主観なのでツッコミどころはあると思いますが、まぁそこは教えてくださいな。実際は、全部ここで書ききれないので、24日までに間に合えば、後のAdvent Calendarでまた出てくるかもしれないです。
では。
Symfony2 Standard Edition(http://symfony.com/download)で、without vendorをダウンロードする。
.gitignoreファイルに追加する。
/web/bundles/
/app/bootstrap*
/app/cache/*
/app/logs/*
/vendor/
/app/config/parameters.yml
/app/config/parameters.yml.distを作っておけば、チェックアウトしてきて、コピーしてカスタマイズすれば、簡単にプロジェクトを始められる。
git init
git add .
git commit -m “Initial commit”
php bin/vendors install
Symfony2では、バックではgitを使ってライブラリを管理しているが、全てdepsとdeps.lockで特定のバージョンとidを管理しており、bin/vendorsでバージョンの整合性を見た方が良い。git submoduleでもできなくはないが、deps等を一纏めにしているため、bin/vendorsコマンドを使う方が良い。
感想：
最近の開発プロジェクトでは、Gitなどの採用は必須だと思われるので、プロジェクトの始め方として紹介してあるこの記事は非常に役に立つ。Symfony2では、depsとdeps.lockを使用して、いろいろなライブラリのバージョンの整合性を保っているのも特筆する点か。
オススメ度：☆☆☆
エラーページをカスタマイズする方法は２つあり、この記事では異なるエラーページのテンプレートを編集してカスタマイズを行う。
app/Resources/TwigBundle/views/Exception/error.html.twigなどを作り、デフォルトのエラーページをオーバーライドする。デフォルトのエラーページのテンプレートは、vendor/symfony/src/SymfonyBundle/TwigBundle/views/Exception以下にあるので、これを参考にして作るのが良い。
エラーページのテンプレートが採用される順序
- １．フォーマット(html, xml, jsonなど)とステータスコード(404, 501など)の両方がマッチするテンプレートを探して、あれば使用する。
- ２．フォーマット(html, xml,jsonなど)のみにマッチするテンプレートを探して、あれば使用する。
- ３．error.html.twigを使用する。
デバッグページもexception.html.twigなどをカスタマイズすることで変更することができる。
感想：
実際のアプリケーションでは、エラーページのカスタマイズは必須なので、知っていて良い内容だ。一度読めば、だいたいやり方はわかると思われる。基本的には、デフォルトのエラーページをコピーしてカスタマイズすることになりそう。
オススメ度：☆☆☆
routing.ymlに requirementsで_schemeをhttpsと指定することでHTTPS通信を強制することが可能。
感想：
HTTPSを使用するサービスは作ったことがないので、今のところ私自身には役に立つことはないが、実際に使えば便利そうだ。なお、この記事は、ymlで指定してあるが、アノテーションで指定することもできる。その際には、以下のようにすれば良い。
* @Route("/demo/secured", requirements={"_scheme"="https"})
オススメ度：☆
ルートのrequirementsでパラメターの正規表現パターンを変更する。
デフォルトは、[^/]+ になっているので、例えば、”.+”とすれば、全ての文字を受け付けることができる。
感想：
たまにあるはまりどころであるが、そもそもルートパラメターに “/” を使わないといけない状況になることはあるのかな。逆に、数値だけとか、さらに厳しくする際にはこの正規表現を適宜変更すれば良いということがわかった。この辺はsymfony1と同じか。なお、この記事は、ymlで指定してあるが、アノテーションで指定することもできる。その際には、以下のようにすれば良い。
* @Route("/hello/{name}", requirements={"name"=".+"})
オススメ度：☆
アセット
Asseticを使用すれば、CSS、JavaScript、画像を最適化することができる。CSS, JavaScriptは元が複数のディレクトリに分散していても、１ファイルにまとめて出力することができる。
フィルター
フィルターを使用すれば、アセットファイルが出力する前にyuicompressorなどの実行結果を返すことができる。
AssetのURLを指定する
デフォルトは、Asseticが自動的にファイル名を決めるが、outputパラメターを使用して指定することも可能である。
出力のキャッシュ
プロダクション環境では、 php app/console assetic:dumpで予め静的にファイルを置いておくと良い。
感想：
Assetic素晴らしい！symfony1系では、@hidenorigotoから教えてもらったnpAssetsOptimizerPluginを使用していたが、それよりも柔軟な指定ができるのが良い。
オススメ度：☆☆☆☆☆
・YUI Compressorのjarファイルをダウンロードして適当な場所に置いておく。あとはconfg.ymlで指定してフィルターとして出力する。
・フィルタ名の前に ? を付けると、デバッグ時にフィルターを無効にすることができる。
感想：
転送量を減らすために、JavaScriptとStylesheetの圧縮は、必要な機能であるが、実際にAssetic無しでやろうと思えば面倒なので非常に助かる。ただ、前の記事を呼んでおけば、この記事は必要ないのではないか、と思う。フィルタ名の前に ? を付けるというのは一応知っていてもいいかもしれない。
オススメ度：☆☆
- jpegoptim をフィルターとして使用すれば、JPEGファイルを最適化することができる。
- jpegoptimのオプションとして、EXIFデータを削除したり、最適化クオリティを下げることが可能。
- また、twigを使用していれば、シンタックスシュガーとしてjpegoptimヘルパー関数を使用することもできる。
- キャッシュの生成ディレクトリもoutputパラメターを使用して指定することができる。
感想：
jpegoptim素晴らしい。つか、知らんかった。これがあれば、アップロードされたファイルもオリジナルはウェブから見えないところに置いておいて、キャッシュをウェブから見えるところに出力すれば良いな。同様のサイズ変更などもあれば、クライアントやサムネイルも簡単にできそう。というか、普通に考えれそうな機能であるので、既にある？
オススメ度：☆☆☆
- Asseticフィルターには、CoffeeScriptのフィルターがあり、出力直前にJavaScriptにコンパイルすることができる。
- さらに、複数のCoffeeScriptファイルを１つJavaScriptとしてコンパイルして、圧縮して出力することができる。
- CoffeeScriptファイル、JavaScriptファイルが両方が混じっているときには、拡張子に基づいて、特定のフィルターを指定することができる。そうすれば、結果、1つのJavaScriptファイルとして出力される。
感想：
CoffeeScriptを書いたことはないが、JSと混同したときなどに便利そう。あったら便利だろうが、たぶん使うことはないかな。
オススメ度：☆
この記事では一般的なファイルアップロードの例を紹介している。まず最初のステップとして、仮想的なfileフィールドを使用し、バリデーション後に実行されるuploadメソッドで、ファイルを実際のファイル保存先へ移動し、保存先をpathとしてデータベースに保存している。
しかし、エンティティ保存時の問題とファイル移動の問題の対処をアトミックにするために、ライフサイクルコールバックを使用した例を次に挙げている。
(@ORM\HasLifecycleCallbacks)を使用して、PrePersist, PreUpdate, PostPersist, PostUpdate, PostRemove などでファイル移動等の処理を書いて、レコードの保存に合わせていること。
また、同様にファイル名もidにすることができる。
感想：
この記事は、実際のアプリケーションを作る際に参考になる。特にフックの使い方とファイルアップロードをする際のプラクティスとして読んでおくことをお勧めする。
オススメ度：☆☆☆☆
Doctrineエクステンションの話で実際はそれぞれのドキュメントを参照すること。
感想：
特になし。
オススメ度：☆
サービスとしてリスナーとサブスクライバーを別クラスに指定することができる。特定のイベントのフックをそのサービスに登録させる方法を説明している。
感想：
便利と言えば、便利だが多用すると複雑になってしまいそうである。記事にあるように保存時に検索インデックスを作成するといった用途以外に思いつかない。また、実際には、サブスクライバーの話はこの記事には書いていないのでは。。。
オススメ度：☆
Doctrine DBALは、PDOの抽象レイヤーで、Doctrine ORMはDoctrine DBALのさらなる抽象レイヤーである。DBALを使うことでSQLをRDBMSに依存せずに使用することができる。
感想：
通常は、ORMを使用していればいいと思われるが、ORMにすることによってメモリが大量に消費されていたり、パフォーマンスの問題を解決する際にはDBALを直接叩いた方が速くなるので、知っていてもいい内容である。というか、アプリケーションによっては、あえてORMを使わないという選択もありかもしれない。
オススメ度：☆☆☆
・Doctrineにデータベースの内部を調べさせて、メタデータを作成することができる。次のコマンドでスキーマに書き出す。
php app/console doctrine:mapping:convert xml ./src/Acme/BlogBundle/Resources/config/doctrine/metadata/orm --from-database --force
・メタデータからエンティティクラスを作成することができる。次のコマンドでアノテーションマッピングをしたエンティティクラスを生成する
php app/console doctrine:mapping:import AcmeBlogBundle annotation
・次のコマンドでゲッターとセッターをエンティティクラスに追加する。
php app/console doctrine:generate:entities AcmeBlogBundle
感想：
最初にデータベースを作ってある場合には参考になる。データベースの設計で、ツールを使い生のSQLを吐く仕組み等に便利そう。
オススメ度:：☆☆☆
コンフィギュレーションで、doctrineのentity_managersを複数指定することができ、コントローラ等がそれぞれ呼び出すことができる。
感想：
実際はNoteにも書いてあるように、ほとんどのケースでは、複数のエンティティマネージャを使用することはないと思われる。もし使われるとすれば、既に動いているプロジェクトで使用しているデータベースを参照するときくらいか。
オススメ度:：☆
Doctrineの話でSymfony2からは直接は関係ないが、カスタムDQLをコンフィギュレーションで指定することができる。
感想：
特に無し
オススメ度:：☆
フォームレンダリングの基本
・各フィールドのラベル、エラー、ウィジェットを出力する際：
{{ form_label(form.age) }}
{{ form_errors(form.age) }}
{{ form_widget(form.age) }}
・各フィールドをまとめて出力する際：
{{ form_row(form.age) }}
・フォーム全体を出力する際：
{{ form_widget(form) }}
フォームテーマ
form_widgetなどのブロックはオーバーライドすることができる。FrameworkBundle/Resources/views/Formを参考にする。
フォームのテーマ化
・フォームと同じテンプレートの中でブロックをオーバーライドすることができる。
・もしくは、別テンプレートでブロックをオーバーライドし、同テンプレートファイルを form_themeタグを使用して適用させることができる(twigの場合)。
ベースフォームブロックを使用(twig)
・ useタグを使って、form_widgetを別名(例えば、base_form_widget)とすることで、元のform_widgetを装飾することができる。
アプリケーション全体でカスタマイズ
コンフィギュレーションでtwig:form:resourcesを変更して、アプリケーション全体のフォームのテーマを変更することができる。
感想：
この記事はフォームフィールドのデザインをスマートにする際に必須の記事である。クックブックというよりガイドブックに入っていてもおかしくない内容である。
オススメ度：☆☆☆☆☆
新規のときと編集のときに出力するフォームフィールドが異なるときにこの記事の内容が役に立つ。新規のときと編集のときで出力したり、しなかったりするフィールドをフォームイベントで動的に見て、設定する。
・具体的には、フォームクラスで直接フィールドをaddするのではなく、addEventSubscriberでサブスクライバを指定させて、フォームフィールドを出力するかどうかを判断させている。
感想：
ここもちょっと難しいが、実際に必要となることが多いと思われる。例えば、新規ではパスワードやメールアドレスを入力させるが、編集では、パスワードのフィールドやメールアドレスのフィールドは、変更できないようにする、といったことがしばしばある。フォームを２つ作ればいいという話もあるが、同じフォームフィールドを扱う可能性がある以上、この記事を参考にした方が良いと思う。
オススメ度：☆☆☆
ManyToManyのリレーションのあるテーブルを使用する際に、１つのフォームを表示で従属するテーブルのフォームを埋め込むことができる。実際に埋め込むには、フォームビルダーにaddする際に、指定するフィールドタイプにcollectionを使用する。
感想：
この記事はまだ完成はしていない。タグを新規に追加する方法や削除する方法がないので、今後の充実に期待。
オススメ度：☆☆
未執筆
感想：
執筆者求む！
dev環境、prod環境、test環境の他に異なる環境を作る方法をこの記事で説明している。この記事では、benchmark環境を実際に作成して説明している。
感想：
実際に新しく環境を作ることはあまり無いと思われるが、豆知識として知っておいてもいいと思う。symfony1では、ステージング環境を作成とかあったが、実際には個人的にあまり使わなかった。
オススメ度：☆
・Symfony は、 SYMFONY__ の接頭辞が付いたあらゆる環境変数をサービスコンテナのパラメターとしてセットすることができる。Apacheで、SetEnvするなどしておけば、特定のデータベースのパラメターを接続設定ファイルで読むことができる。
感想：
ウェブからのみの場合は確かにApacheでの指定でいいが、Symfony2を使う上で、コンソールからの指定も必要である。もちろん環境変数を指定することができるが、複数の場所（Apacheの設定とシェル環境変数）に分散されてしまい、より良い解決方法があった方がいいと思う。
オススメ度：☆☆
この記事では、バンドルを作る上で必要な情報を学ぶことができる。
- バンドル名の命名の規則
- バンドルのディレクトリ構造
- バンドルに追加するクラスやリソースの内容
感想：
この記事は、ガイドブックにあってもいい内容だ。命名規則、バンドルのディレクトリ構造や、必要なクラスやリソースをどのように配置するかを学ぶことができる。実際にアプリケーションを作ると言えば、バンドルを作るという作業になるので、この記事で書かれたことを参考にしてバンドルを作るのが良い。
オススメ度：☆☆☆☆
オープンソースで公開されているバンドルなどは、そのまま使えるものもあるが、いくつか自分用にカスタマイズしたいときなどがある。そういった際には、継承を使ってコントローラやテンプレートなどのリソースファイルをオーバーライドできる。
- 準備として、バンドルにgetParent()メソッドで継承したバンドル名を指定する。
- コントローラでは、parent:メソッド名で継承元のメソッドを実行できるし、かぶせることが可能。そのまま取り替えることも可能。
- その他リソースは、バンドル内の同じ構造の場所にファイルを置けば、特に変更する必要なく、継承できる。
感想：
確かにバンドルは独立したものであるが、継承を使うことによって再利用が可能になり、その方法を学ぶことができるので、知っておいた方がいい内容である。
オススメ度：☆☆☆☆
未執筆。
感想：
執筆者待つ。
SwiftMailerライブラリを使用してメールを送信する方法を説明してある。
- SwiftMailerを使用するには、コンフィギュレーションでtransport, username, password, host, port, encrypition, auth_mode, spool, delivery_address, disabled_delivery を指定することができる。
- 設定がうまく行っていれば、実際のメール送信は、実際に送る内容だけに注力することができる。
- メールの本文は、renderView()メソッドを使用して作成することができる。
感想：
未だ現状のSwiftMailerはデフォルトのままでは、日本語のISO-2022-JPを正しく扱うことができない。私が修正してプルリクエストを投げた内容のものもあるが、修正してフォークして、日本語圏のみで共有した方がいいかも、と思っている。
オススメ度：☆☆
特に開発環境などでは、SMTPを使用するよりもgmailを使用して行った方がメール送信が簡単になる。
コンフィギュレーションにtransportにgmailをしていして、username, passwordにそのGmailのユーザ名、パスワードを入力しておけば、このまま使うことができる。
感想：
メール送信のテストは意外に面倒なのであれば、Gmailを簡単に指定することができれば、開発も速く進むような気がする。しかもコンフィギュレーションに書くだけなので、非常に手軽。
オススメ度：☆☆☆☆
開発中は、実際の送信先のメールアドレスに送信することはしないため、次の２つの方法が用意されている。
１．メール送信を無効にする
２．特定のメールアドレスに送信する。
２の方法を使えば、実際にメールが送られるのかどうかをテストできるので、便利である。また、これもコンフィギュレーションに書くだけなので手軽。
メールの送信内容はウェブデバッグツールバーで見ることができ、config_dev.ymlでintercept_redirectsをtrueに指定すれば、リダイレクト前のメールを見ることができる。
感想：
これは、痒い所に手の届く記事。特に実際のコードに触れることなく、dev環境では、特定のメールアドレスに送ることができるようになった。また、symfony1でもウェブでバッグツールバーで送信内容を見ることができたが、その後にリダイレクトした際には、見ることができなかったが、これが改善された点も特筆すべき点か。
オススメ度：☆☆☆☆
スプールする方法もコンフィギュレーションに書くだけで、簡単に行うことができ、あとは、コンソールから次のコマンドを実行すれば良い。
php app/console swiftmailer:spool:send
感想：
スプールすることによって、メールの送信に負荷をかけなくても良くなった。実際は、メール送信に関しては、特に負荷はかかるような処理ではないと思うのだけど、携帯アドレスに送る際とかには、短時間に送りすぎると拒否されてしまうかもしれないので、オプションも見ておくと良さそうだ。
オススメ度：☆☆
HTTP認証に必要なユーザ名とパスワードを、テスト全体として、または、各リクエストごとに指定することができる。
感想：
まだリリース前の段階や、内部のみに公開の場合にベーシック認証をかけておきテストをするのが便利そうだが、あまり用途はないかもしれない。
オススメ度：☆
件名のまま。チャットシステムのような複数クライアントがおり、即時で反映されるかどうかを見るときに使うことができる。
感想：
あまり用途は思い浮かばないが、知っておいてもいいかもしれない。
オススメ度：☆
一般的なファンクショナルでは、レスポンスのみをテストするのみで良いが、本番サーバのパフォーマンス等をテストする際に、プロファイラの値を調べることもできる。
プロファイラを使えば、クエリーの数、処理時間を調べることができ、チューニングに必要なものを洗い出すことが可能となる。
感想：
実際には、これは必要ないと思う。これはテストというよりもチューニングに関することなので。しかし、プロファイラの値をコンソールから見て調べることができれば、ボトルネックとなっている場所を探すことができるだろう。
オススメ度：☆
Doctrineのリポジトリクラスをテストするには、エンティティ、エンティティマネージャ、データベース接続などを準備しておく必要がある。
Unitテスト
- DoctrineTestsをオートーローダのネームスペースで指定する
- Unitテストは、DoctrineTests内のOrmTestCaseを継承する
- Unitテスト内のsetUpでAnnotationReaderをセットアップしてエンティティをパースしたり、エンティティマネージャを取得したりする。
- QueryBuilderオブジェクトのクエリーの各パーツをテストする
ファンクショナルテスト
- セットアップでデータベース接続を取得しておく。
- コントローラでエンティティを取得するのと同じようにテストする
感想：
Unitテストは、セットアップが少々面倒くさい。もう少し楽にできるようになった方がいいと思う。個人的には、ここはUnitテストではなく、ファンクショナルテストのみでほとんどカバーできると思う。
オススメ度:：☆☆☆
コンフィギュレーションで、templatingのenginesにphpを追加することでPHPをテンプレートエンジンとして使うことができるようになる。
- Twigのときと同じように親のテンプレートを継承することができる。
- Twigのブロックと同じようにPHPでは、スロットとして親のテンプレートに子で指定したテンプレートを埋め込むことができる。
- Twigのときと同じように、別テンプレートや別コントローラを取り込むことができる。
- テンプレートヘルパもあり、テンプレートエンジンとして、基本的なことがほとんどできる。
感想：
Twigが強力なテンプレートエンジンなため、PHPを直接テンプレートエンジンに採用するメリットはあまりないと思うのだが、オプションとして知っていてもいい内容か。
オススメ度：☆
APIのキーなどをグローバルの設定値としてコンフィギュレーションとして書いておくことができる。
感想：
環境変数でSYMFONY__を指定すれば、外部パラメターをセットすることができるので、同様のことが可能だし、その方が実装が綺麗になると思う。
オススメ度：☆
Symfony2はデフォルトでMonologを使用している。
- Monologのほとんどの設定は、コンフィギュレーションでハンドラを追加することでロギングが有効になる。
- フォーマッタを変更することができる。
感想：
この記事の内容は全ては試していないが、基本的なログの取得はここに書いてある内容で可能。ログメッセージの装飾は今後調査をする。
オススメ度：☆☆
コンフィギュレーションで、指定すれば特定のアクションレベルでメールを送信することができる。500番台のエラーが起きたときなどに、管理者にメールを飛ばしてバグの調査をするときなどに役に立つ。
また、メールを飛ばし、かつ、ログに書きこむことも可能。
感想：
symfony1系でもエラーのイベントをリッスンしてメールを投げるといったことができたが、Symfony2ではコンフィギュレーションで、完結できるのが良い。
オススメ度：☆☆☆☆
Symfony2のプロファイラで得られるデータを集める方法もカスタマイズすることができる。
- Symfony\\Component\\HttpKernel\\DataCollector\\DataCollectorInterface を実装する。
- サービスにdata_collectorタグを付けて登録する。
- ウェブプロファイラテンプレートを作成する。
感想：
普通の用途では、プロファイラを拡張することはほとんどないのでは。。。
オススメ度：☆
symfony1とSymfony2は別物だが、symfony1の哲学は、Symfony2に受け継がれているものも多いため、symfony1をマスターしていれば、それほど学習コストは高くはない。
ディレクトリ構造
app/
Symfony2でのapp/ ディレクトリは、モジュールやライブラリファイルを置くところではなく、コンフィギュレーションや他のリソース（テンプレートや翻訳ファイル）を置くところになる。
src/
実際のコードを置く場所。Symfony2でのアプリケーションのコードは全てバンドルの中になり、バンドルがsrc/ 以下に置かれる。symfony1では、schema.yml、モデルファイル、フォームファイル等がプロジェクト内で共有されていたため、分散されていたが、Symfony2では、個々のバンドルとして独立されている。symfony1で、独自にplugins/ディレクトリに自分のアプリケーションを入れるなどしていれば、Symfony2のバンドルとよく似たものになる。
vendor/
symfony1のlib/vendorと概念は同じだが、入っているライブラリが異なる。
web/
フロントコントローラが置かれる。後にコンソールコマンド（php app/console assets:install web）を使って、個々のバンドル内のResources/publicディレクトリの複製orシンボリックリンクがweb/bundlesに作られる。
オートローディング
symfony1では、プロジェクト全体のPHPクラスファイルを１つの巨大な配列にキャッシュしていたので、変更があった際にキャッシュクリアが必要であったが、Symfony2では、UniversalClassLoaderを使用し、namespaceで管理しており、変更があってもキャッシュをクリアする必要がない。
コンソール
php symfonyコマンドから php app/consoleコマンドへ変更。
アプリケーション
symfony1では、frontend, backendのようにアプリケーションを分けていたが、Symfony2では別プロジェクトを作り、プロジェクト間でバンドルを共有することになる。
バンドルとプラグイン
symfony1では、config/ProjectConfiguration.class.phpでプラグインを有効にし、Symfony2では、app/AppKernel.phpでバンドルを有効にする。
ルーティングとコンフィギュレーション
symfony1では、プラグイン内のrouting.ymlとapp.ymlは自動的にロードされる。Symfony2では、routing.ymlもconfig.phpも、各バンドルの設定をインポートしてロードする。なお、symfony1のapp.ymlのような設定をするには、config.php にparametersキーで、指定すると良い。
感想：
実際は、Symfony2で遊びプロジェクトでも作ってみないといけないが、その後でこの記事を読めば、まぁ理解はできると思う。アプリケーションを分けない、というのはsymfony1系の人にとっては理解しにくいのかもしれない。あとバンドルの仕組みはプロジェクトと独立していて優れているとよくよく思う。
オススメ度：☆☆☆
まだレビューしきれていない記事は以下の通りです。サービス系は、セキュリティ系は鬼門だなぁ。
コントローラをサービスとして定義する方法
データトランスフォーマの使用
カスタムバリデーション制約の作成方法
サービスを作成するファクトリの使用方法
親サービスと共通の依存(dependency)をマネージする方法
スコープの使用方法
PdoSessionStorage を使用してデータベースにセッションを格納する方法
セマンティックコンフィギュレーションを通してバンドルを設定する方法
“Remember Me” ログイン機能の追加方法
IPアドレスのブラックリストの独自 Voter の実装方法
アクセス制御リスト(ACLs)
高度な ACL のコンセプト
異なる URL で HTTPS や HTTP を強制化させる方法
フォームログインをカスタマイズする方法
アプリケーション内でサービスやメソッドをセキュアにする方法
データベースからセキュリティユーザをロードする方法(エンティティプロバイダ)
カスタムユーザプロバイダの作成方法
カスタム認証プロバイダの作成方法
Varnish を使ってウェブサイトを高速化する方法
クラスのオートローディングの方法
ファイルの探し方
コンソール/コマンドラインツールとしてのコマンドの作成方法
デバッグするための開発環境に最適化する方
Symfony2 コントローラで SOAP ウェブサービスを作成する方法
継承無しでクラスを拡張する方法
継承無しでメソッドの挙動をカスタマイズする方法
新しいリクエストのフォーマットとマイムタイプの登録方法
今後は、これらのまだレビューしていないものを見ていくと共に、実際に手で動かしてちゃんと使えるか、翻訳された言葉がおかしくないか（実際、今回レビューしていた中でいくつかおかしい翻訳も発見している）、を見ていきます。
今回の「オススメ度」というのは、完全に主観です。ただ、☆が５つあるのは、確実に知っておいた方がいい内容です。４つもぜひ読んでおいてください。１つ２つは、暇だったりビンゴなネタであったらやってみてください。
実際のところ、私は翻訳をしながら、Symfony2自体の理解、Githubの使い方の理解を深めてきました。GitHubデビューをするのに、翻訳が一番簡単な方法じゃないかなぁ、と最近思っています。変にTOEICの勉強するくらいなら、Symfonyの翻訳をして英語も技術も身につけた方が、実際役に立ちます。いや、本当に。
明日のSymfony Advent Calendar 2011 -15日目は、@makotokagaさんです。
Shin Ohno 2003-2012