こんにちは、@ttskch です。

4/19 (土) に開催された Symfony勉強会 #9 に参加してきました。 会場提供は 株式会社フォトクリエイト さん。カンブリア宮殿で拝見して以来気になっている会社さんだったので個人的にこっそりテンション上がってました笑

初参加だったのですが、そうそうたるメンバーに囲まれてレベルの高い議論に触れることができ、非常に刺激的な勉強会でした。

以下、各講演・LT の内容と個人的なメモ書きをまとめます。

前半

最近の Symfony ざっくり

@hidenorigoto さん

  • Fabien の発言によると Web 全体の 1% のサイトで Symfony が使われているらしい
  • 2.4 はリリース済みだけど、2.3 が LTS なので適切に見極めを
  • Symfony のコア開発者の多くが Hack 言語 の開発にも関わっている

Symfony の Form あれこれ

@okapon_pon さん

  • エンティティと関係のない項目をフォームに付ける場合はカスタム FormFieldType で再利用性を高くする
  • twig でフォームの値を取るときは {{ form.フィールド名.vars.変数名 }}
  • 複数のエンティティからなる Form が必要な場合は、それ用のモデルを作ったりする

管理画面のロールごとのアクセスコントロールの実装例

@brtriver さん

  • 運用しやすい管理画面の条件は、パーマリンクな URL とシンプルな ACL
  • お客さんから URL だけもらえば調査できる
  • 権限チェックをコントローラ・ビューから追い出して、ルーティングでだけチェックする
  • 権限ごとにコントローラとビューを書く
  • 冗長になる代わりに、コントローラに来たときには適切な権限であることが保証される
  • 事故るリスクが低く、安心して権限周りに変更を入れられる

オレオレフレームワーク

@hidenorigoto さん

  • 今の Symfony2 を使ったイケてる環境よりも、少し昔にオレオレジェネレータでフォームや ORM の自動生成をしてた頃の方が生産性は高かった
  • Domain UseCase Framework という切り口
  • 静的な構造 (what the system “is”) => Entity
  • 動的な振舞 (what the system “does”) => Service
  • この方法だとサービスが大量になるので、JmsDiExtraBundle を使うのが吉

後半

Symfony2 + AngularJS

@77web さん

デモコードは こちら

  • カルテットの仕事で今やってもらっている内容で LT してくださいました
  • Symfony2 と AngularJS でアプリを実装するデモ
  • Symfony 側は REST で実装 (デモでは json を返すコントローラを実装)
  • デモなので省略したけど、本当は FOSRestBundle が便利
  • Angular のソースはバンドルの /Resources/public/js 配下に配置
  • Angular のリアルタイムな動作をデモ
  • twig と Angular で変数表記が同じなので、{% verbatim %}〜{% endverbatim %} で囲う
  • Symfony がフォームに付ける id を Angular 側で ng-model にセットして ラクしたり

capifony

@_nishigori さん

  • Capistrano の Symfony プロジェクト向け拡張
  • Symfony1.4~ サポートしてる
  • Symfony のコマンドとかも使えて便利
  • composer はまだ stable じゃないので、set :composer_version, '1.0.0-alpha8' とかロックしておくと安心

Vagrant と PhpStorm で Symfony 開発

@karakaram さん

  • Symfony のような巨大 FW だと synced_folder は遅すぎてきつい
  • synced_folder を NFS 化するだけでも割と早くなる
  • 開発環境では Symfony のキャッシュ・ログを RAM に出力するようにするとか
  • ただしキャッシュがないと PhpStorm の Symfony2 Plugin が使えないので rsync で定期同期するとか
  • PHPUnit on Server 便利

関連エントリ

Symfony2.5 について

@Issei_M さん

  • プロファイラが進化
  • エラーの出力がより親切に
  • FormInterface::getErrors() にオプションが追加されてより便利に
  • ただし戻り値が配列からイテレータインスタンスに変わってるので注意
  • コマンドもいくつか追加されて便利そう

Symfony のテスト周りの話

@imunew さん

  • sopra.jp をリリースしたときのお話し
  • うちのプロジェクトと状況が似てて個人的にすごく共感
  • Symfony1.4 → Symfony2 移行。学習コストが高く苦労
  • anonymous: ~ にたどり着くだけで 2 日かかった
  • 課金周りの状態遷移が複雑だったのでモックが活躍
  • Symfony2 + PHPUnit の 具体的な How To は http://imunew.github.io/blog/ 参照

Symfony の学びかた

@t_wada さん

スライドは こちら

  • Symfony はサポートが長く下位互換性を無下に壊したりしないので自社サービスで安心して使える
  • Symfony のバックグラウンドは Web, PHP, OOP の 3 つ
  • [Web] お勧め書籍：Web を支える技術
  • [PHP] お勧め書籍：パーフェクト PHP
  • [OOP] お勧め書籍：アジャイルソフトウェア開発の奥義
  • Rails は 密結合の強力さ
  • Symfony2 は 疎結合の柔軟さ
  • Symfony は MVC FW ではなく HTTP FW である (と、Fabien も言っている)
  • つまり、超マクロに言えば、リクエストとレスポンスの間のブラックボックスでしかない
  • ミクロとマクロの間のどの倍率で見るかで見え方が異なる
  • マクロから入って倍率を上げていくのが効率のよい学び方
  • joind.in などで先人の講演資料を見るのがマクロでの理解に有効
  • Form, Security は Symfony の 2 大難解コンポーネント
  • Form コンポーネントの理解には 3 Steps to Symfony2 Form Mastery がお勧め
  • Security コンポーネントの理解には Love and Loss: A Symfony Security Play がお勧め

大質疑応答タイム

チーム開発のプラクティスについて

  • gitflow を使っている人多い
  • 開発者によって当然能力のバラつきはあるので、最初から「きれいに書くこと」は強制せず、まずは正しく動作するものを「知っているやり方で」作らせる
  • その後、レビュー、テスト追加、リファクタリング、で昇華させていく
  • マージはコミッター以外が行う、は徹底
  • トピックブランチを育てない → 小さい単位でどんどん master にマージしてリリースする

Symfony のバージョンアップについて

  • Symfony はサポートが親切なので、比較的カジュアルにバージョンアップしやすい (「ダメだったら戻せばいいや」)
  • LTS → LTS の移行ならさらに安心

yml とアノテーションの使い分けについて

  • Symfony2 ではだいたい yml, xml, アノテーションの 3 パターン
  • でも xml はあまり使われてない
  • ORM はアノテーションが多数派な印象
  • routing は yml とアノテーションが半々ぐらいの印象
  • service は yml が多数派な印象
  • ググったときの情報量に差があるので、多数派に乗っかるのは合理的
  • 設定はアノテーションに書くべきではない (設定変更でリビルドが必要なのはおかしい)
  • 設定は yml にまとまってる方が参照しやすい
  • メソッドのメタデータはアノテーションに書いてある方が参照しやすい
  • そういう合理性を考えた結果、多数派が (偏りが) 生まれているはず
  • ちなみに ORM Designer という便利なツールがあったり
  • doctrine:mapping:import という Cake の bake みたいなコマンドもあったり

懇親会 LT

はじめてのフレームワークとしての Symfony 導入

@kseta19 さん

  • フォトクリエイトさんでお仕事を通じて成長できたお話し
  • 文系出身エンジニアさん
  • 入社 1 年目は Excel でテスト項目書いたりしてた
  • スキルアップのため、レガシーコードの Symfony2 移行にチャレンジ

@kseta19 さんは今回の勉強会の発起人だそうです。 運営、進行、色々とありがとうございました！

Future Oriented Programming

@koriym さん

スライドは こちら LT へのフィードバックは こちら

  • 意思決定プロセスのお話し
  • 過去志向、現在志向、未来志向、どれが良い悪いではない
  • Web 業界には現在志向の人が多い印象
  • 現在志向：学習コスト、開発コスト、みんな使ってるのか、ググって解決できるか、クールなのか
  • 現在志向 ≒ 流行志向 ＝ 自分中心
  • 未来のことは分からない、ただ一つ分かっていることは「変わり続けること」
  • ニュートンの世界観とアインシュタインの世界観
  • アインシュタインの世界は不確実性の世界
  • 一度公開した I/F を取り上げない、I/F の意味を変えない、新しい機能はオプションとして追加
  • バージョニングしない
  • セマンティックバージョニングを守っていないライブラリを使うとサポート超大変
  • Guzzle では 3.* を壊さないために 4.0 で名前空間を変えるという解決策
  • HTTP はリソースをバージョニングしないことで繁栄したとも考えられる
  • 未来志向的な OOP では protected はアンチパターン
  • 公開するなら「一生変えない」つもりで public にする、アクセサはダメ
  • connection レイヤーが component レイヤーをラップして I/F を永続的に保証
  • connection は component が持つ「動詞」を仲介するのみ
  • component は DI で差し替え可能
  • OOP: “tell, don’t ask.”
  • 手続き型 «< OOP と言っているわけではない
  • システムの中でどこが変更されやすい hotspot なのかによって設計判断
  • 「データ」と「情報」は違う
  • データは無加工の生データ、情報は人が扱える粒度に加工されたもの
  • エンジニアは情報を設計し、企業は情報を知識に変える

その他

@yutatone さんによる飛び入り LT

  • エンジニアが楽しく仕事できることは会社にとって価値がある
  • 技術者が楽しく働けるベンチャー企業はいい
  • 海外でのリモートワークは、時差を克服できなくて難しい

@t_wada さんによるテストの方法論や考え方についてのお話し

  • ユニットテストを書くのが面倒 → プロダクトコードが複雑すぎる可能性を疑う
  • デバッガは再現性がないので証明には使えない
  • テスト文化を浸透させる一つの方法：デバッガ使用禁止、echo 禁止、var_dump 禁止
  • REST + JS 構成ではエラーが JS 側で起こるので別途エラー収集が必要 (泥臭い)
  • バックエンドで API が変わってるのに JS が更新されてない問題 (プッシュで「更新してね」を教える必要あり)
  • AngularJS と twig の記法が似ているので脆弱性に注意
  • テストコードとプロダクトコードが互いをテストする
  • JS 側のテストで、レンダリング結果をピクセル単位で diff するツールとかもある
  • PHPUnit の @group は実質的には「タグ」なので、リリース後の不具合修正のために追加したテストにそういうタグを付けておくと、後から自分の弱点が見えたりして有用

まとめ

総じてレベルの高い勉強会で、本当に勉強になりました。 特に私はまだまだ Symfony 初心者なので、@t_wada さんの「Symfonyの学びかた」は大いに参考にさせていただけそうです。

懇親会では大御所のみなさんの議論が白熱しすぎてあやうく日付をまたぐ勢いでしたが、おかげさまで貴重なお話をたっぷり聞かせていただき感無量でした。次回は私も何か発表できるネタが用意できたらなと思います。

当日の様子は Togetter にもまとまってます ので、ぜひご覧ください。

Note: 本エントリ公開後もしばらく #symfony_ja を追いかけて、追加情報があれば適当にアップデートします。