BEAR.Sunday Meetup #0に参加してきました

PHP フレームワーク

　PHPのフレームワーク、BEAR.SundayのMeetUPに参加してきました。

Ray.Di Ray.Aopことはじめ

　

Bear.Sundayのコア部分の解説

  1. 「問題の解決に実装でなく設計で挑もうとしている」
  2. さまざまな思想が詰まったフレームワーク
  3. RayとBEAR.Resorceの二つの柱
  4. RayはGoogle Guiceがヒント
  5. RAY,DIはAura.Diベース
  6. とてもクリーン。全て外部から注入され、固定クラスが無い
  7. Doctrin/Common.Annotationsによるアノテーション実装
  8. Symfonyライクな書き方も可能
  9. アノテーションでインジェクションを指定する場合
    1. モジュールで設定を定義
    2. 通常のコンテナで取得
    3. インターフェースを必要とするところに一度に注入できる
  10. モジュールは特定の関心領域についての設定や構成を行う単位
  11. モジュール自身もDIによって入れ替えられる。
  12. ふるまいはAOPで変更する
  13. Ray.AOP
    1. 横断的関心指向プログラミングを実現するフレームワーク
    2. 実メソッドが呼び出される前に処理を挟み込む
    3. インターセプターは実メソッドが呼ばれているかどうか、どういう位置付けにあるかを知らない
  14. Ray.DIはオブジェクト生成のためのフレームワーク、Ray.AOPはオブジェクト利用のためのフレームワーク
    1. 生成と利用の分離
    2. 生成レベルでキャッシュできるので、コストが非常に低くなる

　ここでBEARの開発者によるオブジェクトグラフの説明。

  1. オブジェクト同士の依存関係のネットワーク
  2. Facadeとなるルートオブジェクトを取得すると玉突き式に依存するオブジェクトが取得される
  3. 早期束縛と遅延束縛をフレームワークレベルでわけて扱うことでキャッシュを効率化
  4. 現状はAPCキャッシュのみ。速度と依存関係の解決のため
  5. AOPによって横断的処理だけでなく、モックとの接続や処理の動的分岐、キャッシュの高度化などができる

僕と熊の三年間

　エキサイト(!)でBearフレームワークを全面的に採用したケースについて

  1. 最初期バージョンから全面採用
    1. はじめはエキサイトブログの携帯版
    2. 学習コストの低さから全面的に採用に
  2. 次にBEAR・Suturday
    1. Roaは強烈だった
    2. 学習コストは高くなった(といってもなんとなく動く)
    3. DIシステムでレガシーシステムとの接続を隠蔽できた
  3. 今でも全面的に使用している

リソース指向のデータ転送

  1. HTML5ではローカルにデータベースがある
  2. 連番IDを採用すると問題が生じる
  3. 課金のようなケースではどうするか？
  4. リソース指向でIDの付け替えを隠蔽
  5. 苦労した割にデータベースの同期くらいしかできないので応用方法を募集中

開発者によるBear.Sundayの開発

Frameworkとは何か?
  1. 設計思想である
  2. 設計思想とはシステムに秩序をもたらす価値観
  3. どのような価値観をもって問題を解くか？

オブジェクト指向とは何か?

  1. オブジェクト指向には二つある
    1. ひとつはアラン・ケイのOOP
      1. ダイナブック構想の人
    2. メッセージング・状態処理のローカルによる隠蔽、遅延束縛
  2. C++の作者のOOP
  3. カプセル化、継承、多態性
データ構造とオブジェクト
  1. データが外部にあるのが手続き型、内側にあるのがOOP
  2. Tell型とASK型
    1. オブジェクト指向では、オブジェクトに｢話す｣
    2. 手続き型では、対象を取得する（ASK）
  3. 手続き型とOOPはお互いに苦手なところが得意

MVC

  1. MVCについては捕らえ方が人によってばらばら
  2. パターンは価値観の表現が無意味
  3. 「MVCはアプリケーションのパターンではなく関心の分離のパターンである」
  4. 典型的なMVCはtellでなくASK
  5. ROAの条件
    1. アドレス可能性
    2. ステートレス性
    3. 接続性
    4. 統一インターフェース
BEAR Sundayの場合
  1. リクエストに対してリソースの表現が返る
    1. 関心事に応じて複雑になる
  2. これならぱtell
  3. アクセスはURIと挙動で
  4. 戻り値は常にリソースオブジェクト
  5. モデルをオブジェクトにしなければもっとわかりやすくなるのではないか?
    1. 世界最大のスケーラブルモデルであるwebの構造をまねする
  6. 状態をViewに変更するのがリソースレンダラ
  7. リソースごとにテンプレートエンジンを注入
  8. リソースは関係性を元にリンクをもち、関係性を隠蔽している
  9. リソースが関係性でつながっている(リソースグラフ)
  10. リソースがURIで表記されることで抽象度を上げ、依存性をなくす
  11. Because Everything is A Resorce

「問題の見方。物事をどう見るのかが大事」