#bear.sunday

[phpmentors]

コネクタとしての BEAR.Resource について考えたこと

BEAR.Sunday Advent Calendar 2015 6日目の記事です。（※記事の公開が予定よりも遅れてしまいました。すみません。）

RESTfulフレームワークである BEAR.Sunday を使う機会がありました。 使ってみて考えたことを書きたいと思います。この記事では、まずコネクタとしてのリソース（BEAR.Resource）について説明します。リソースの単位を

　1. 名詞的情報にした場合と、 　2. ドメインユースケースにした場合

についてそれぞれ特徴を検討します。後者については説明用に動作するスニペットを組みました。

BEAR.Resource とは

BEAR.Sunday を構成するオブジェクトフレームワークの１つに BEAR.Resource があります。READMEには下記の記述があります。

BEAR.Resource はオブジェクトがリソースの振る舞いを持つHypermediaフレームワークです。 クライアントーサーバー、統一インターフェイス、ステートレス、相互接続したリソース表現、レイヤードコンポーネント等の RESTのWebサービスの特徴をオブジェクトに持たせる事ができます。 既存のドメインモデルやアプリケーションの持つ情報を柔軟で長期運用を可能にするために、 アプリケーションをRESTセントリックなものにしAPI駆動開発を可能にします。

リソースオブジェクトは、WebのURIと同じような page://self/index などのURIを持ち、HTTPのメソッド（GET/POST/PUT/DELETE）に準じたインターフェイスを持ちます。

コネクタとビジネスコンポーネントの関係

BEARでWebページを作る場合、「ページリソース」が「アプリケーションリソース」を呼び出す形になります。 アプリケーションリソースを使う意図について、フレームワーク作者の郡山さんに質問したところ、下記のような回答を頂きました。

Mike Amundsen(@mamund) さんの来日講演で、継続開発可能性のために、アプリケーションは情報を接続するコネクティングレイヤーとビジネスロジックのためのコンポーネントレイヤーの二層が必要だというのがありました。 BEARのリソースは前者の情報の接続のためのレイヤーです。

※コネクタ（接続レイヤー）とコンポーネントについての詳細は、資料 RESTとAPI設計のためのガイド / A Guide to REST and API Design eBook に記述があります。

アプリケーションリソースの基準は何か？

では、アプリケーションリソースの粒度、最小単位（= 再利用の単位）を何にするのか？考えてみたいと思います。

パターン１：リソースを名詞的情報とする

たとえば、公式チュートリアルの例だと下記です。

ref. bearsunday/MyVendor.Weekday

業務上意味のある名詞である情報をリソースにするパターンです。この基準を採る場合の特徴について、下記のように考えました。

メリット：BEAR.Resource の諸機能（URI、リンク、外部アプリケーションのインポート、キャッシュ等）を細粒度から使える

課題：OOP、責務駆動設計、ドメイン駆動設計と蓄積されてきたような、型制約を活かした設計を採り入れる場合の実装方法？

たとえば、下記のような問題の構造をそのまま意図としてコードに表すのがDDDのビルディングブロックの考え方でした。クラスの型、名前、振る舞い等で部品の責務を限定することでリッチな語彙を作っていきます。

エンティティをリソースに、ユースケースをリソースに、サービスは？、URI制約から型への変換が要る・・・と実装を考えたときにうまくおさまらないように私は感じました。

パターン２：リソースをドメインユースケースとする

ユースケースクラスをリソースにインジェクトするパターンです。「Domain Kata」 のサンプルアプリケーションを見て、サンプルのモデル部分をBEARアプリケーションから呼び出すスニペットを実装してみました。（Doctrine 注入については文末掲載の参考リンクを参照させて頂き、助かりました。ありがとうございます。）

kumamidori/SnippetUserRegistration

メリット：URIでユースケースの再利用が可能、モデルの意図性

課題：ユースケースから利用される側のクラスでは BEAR.Resource の諸機能がデフォルトでは使えない

２パターン挙げましたが、前者パターンで部分的にサービスをリソースにインジェクトする形もあります。 最後に、まとめ・・・としたいところですが、結論のようなものは現時点ではありません。 この記事を書くにあたって、こんな記事（奥さんに REST をどう説明したかというと…）を発見してのんびり読んだりして、楽しかったです・・・。

関連記事

ドメインモデルのための型「Domain Kata」を使ってみました

Kata #1 - サービス（SERVICES）

参考リンク

BEAR.SundayでDoctrine2のORMを使ってみた（改） — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something

BEAR.SundayでDoctrine2のORMを使ってみた - Qiita

[phpmentors]

BEAR.Sundayチュートリアル・スクリーンキャスト

プログラミング道場生 kumamidori です。

5月31日に、Nagoya.php vol.5 に参加しました。

vol.5 のテーマは、「PHPフレームワークの１つであるBEAR.Sundayを触ってみよう」でした。 参加者全員で、BEAR.SundayワークショップWiki（チュートリアル）の内容に取り組みました。 私が見つけられた範囲だと、@kenji_sさん、@qckanemoto さんがブログにまとめられていますので、そちらをご覧頂ければと思います。記事の文末にそのリンクを貼ります。

BEAR.Sundayチュートリアル・スクリーンキャスト

この記事では、スクリーンキャストで、BEAR.Sundayチュートリアルのデモを、初心者なりの解説をまじえつつ紹介します。（見る人、誰もいないかもしれませんけれど・・・。）

スクリーンキャストNo.１：フレームワークの概要とインストール（youtubeページへのリンクです）

スクリーンキャストNo.２：リソースの作成、確認（youtubeページへのリンクです）

※今回動画を掲載することについて、フレームワーク作者に事前に許可を頂いております。

PHPカンファレンス関西について

BEAR.Sundayの作者である郡山さんは、6月28日(土)に開催されるPHPカンファレンス関西2014の基調講演をされる予定です。関西方面でご興味のある方は、懇親会の方にも申し込みされると良いかと思います。@hidenorigotoさんも遠方から来訪、参加されるそうです。

参考リンク

BEAR.Sundayに関するリンク

BEAR.Sunday

郡山さんによるRESTful Meetup vol.3におけるLT資料： HTTP IS ONE THING

PHPNW 2013(2) - Presentation « BEAR Blog

スクリーンキャスト内で引用した書籍

PHPメンターズブログにおける関連記事

PHPメンターズ -> WEB+DB PRESS PHP連載第5回「BEAR.SundayでRESTfulなシステム開発」を執筆しました

道場生ブログ -> BEAR.Sunday meetup #3 in Osaka 参加レポート

Nagoya.php vol.5 に関するリンク

Nagoya.php のFacebook

Nagoya.php vol.5 BEAR.Sunday workshopに参加しました — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something

Nagoya.php vol.5 で BEAR.Sunday のワークショップを行いました | QUARTET Engineers’ Blog

※6月29日追記：

名古屋の方から、「写真、撮っていましたよね？」とリマインドを頂いたので、貼っておきます。

[iteman]

Spout - Building a RESTful web app with Angular.js and BEAR.Sunday

Spout - Building a RESTful web app with Angular.js and BEAR.Sunday from Richard McIntyre

[phpmentors]

BEAR.Sunday meetup #3 in Osaka 参加レポート

プログラミング道場生kumamidoriです。

PHPフレームワークの１つに、「BEAR.Sunday」があるのをご存知でしょうか。

リソース指向のOSSフレームワークで、郡山さん（@koriym）によって開発されています。

去年イギリスで行われたカンファレンス、「PHPNW2013」では、BEAR.Sundayのアーキテクチャを紹介するセッションがありました。

私は以前、旧バージョンにあたる「BEAR.Saturday」の方を仕事で使っていました。新しいBEAR.Sundayついては、初学者の状態で、さわる機会もあまりなかったのですが、気になっていました。2013年7月には、BEAR.Sunday meetup #2の主催をさせて頂いたこともありました。

そのようないきさつがあり、4月7日、BEAR.Sunday meetup #3 in Osakaを開催することになりました。 郡山さんに、PHPNW2013でのセッションをアップデートした内容で再演して頂きました。

参加者を引き込む素敵なセッションをして下さり、ありがとうございました。

また、会場提供を引き受けて下さった1x1株式会社の新原さん（@shin1x1）に、お礼申し上げます。

この記事では、セッション内容の抜粋と、個人的感想を書きます。

1. セッション内容の抜粋

1-1. なぜ新しいフレームワークを作るのか

- Quality と Agility の時代

Webアプリケーションは、長期的に改善し続けていく必要のあるものである。Quality と Agility の時代と言える。 Agilityとは、「すぐに変更することが可能である」ということ。

PHP5.3以降のPHPフレームワークには、単に「動くものを速く作る」のとは、少し違った流れがあった。 多くのPHPフレームワークが揃ってDIを採用したことは、その一例と言える。

- フレームワーク、アーキテクチャ

大事なのは、あなたは何をしたいのか？ということ。 「自分たちのドメインの問題」を解決するためのフレームワークを持つことに意味がある。

PHPNW2013の来場者が興味を持っていたのは、「次のアーキテクチャは何か？」ということだった。 たとえば、Symfony1 から 2 へ、Zend1 から 2 へ、成功したフレームワークはどれも、ユーザが「バージョンアップのための、大幅な書き直し」を経験してきた。 Symfony2 から 3 で、またあれをやらなければならないのか？！という問題がある。そういった問題を、どのような技術で解決できるのかという視点、アーキテクチャの選定、という意味で、新しいものを探そうという動機から、BEARのセッションを聞きに来てくれた。

1-2. PHPNW2013「A resource orientated framework using the DI /AOP/REST Triangle」再演

（※NW2013当時の、作者ご本人のプレゼンテーション内容紹介エントリーを見て頂く方がエッセンスが伝わると思うので、そちらをご参照頂ければと思います。 私の記事では、背景、前提となる知識の部分に話題を絞ってメモします）。

BEARはアプリケーションフレームワークだけれども、ライブラリを持たない。良いライブラリは既存でたくさんあるから、再発明の必要が無い。

そもそも、フレームワークとは何か？

広義の意味：

imposes a set of design constraints on end-user code.

エンドユーザのコードに対して、設計上の全体的な制約を与える。 (by Nate Abele)

狭義の意味：

「呼ぶ」側-「呼ばれる」側の関係が逆転して、「呼ぶ」側をフレームワークが最初からお膳立てし、「呼ばれる」側だけをユーザが書く。

BEARの場合は？：呼ぶ側もユーザが書く。

BEAR.Sundayは、3つのオブジェクトフレームワークを持つ。

(1) DI Framework

前提知識となる Dependency Inversion Principle （依存関係逆転の原則、DIP）についての話があったのですが、文末の参考リンクに詳しい解説があるので、ここでは省きます。

(2) AOP

たとえばあらゆるモジュールに散在してしまうロギングのような、 横断的関心事（Cross-Cutting Concerns）を分離することで、 モジュール間を疎結合とするプログラミングパラダイムのこと。

アプリケーションロジック（ログ、キャッシュ、etc…）とドメインロジック（コアの関心事）を分離する。

(3) REST（Hypermedia Framework）

オブジェクトをWebサービスのように扱う。

RESTとは：クライアントとサーバにWebは分かれている。決まったメソッドしか使えない。リクエストは1回だけで、ステートレスである。

このアーキテクチャを、OOPアプリケーションの内部に適用している。リソースとリソースをハイパーリンクによってつなぐことができる。

情報に真の意味での価値を与えるのはそのつながりである。

実装を直接書くのではなく、まず、抽象化された意図を記述する。次に、その意図に役割を与えて動かす（実装を結合する）。

A resource oriented framework using the DI/AOP/REST triangle from Akihito Koriyama

セッション内容については以上となります。

2. 個人的感想

下記が分からなかったので、今後調べていきたいと思いました。

他の言語、たとえばRubyでは、変更の安全性（ある1箇所を直したら、あちこちに影響が出たり、予想もしないところに作用が出たり、といったことを防ぐ）を、どう担保しようとしているのか？

複雑なロジックでも、DIのランタイムとコンパイルの分離で表現できるのか？

セッションの中で出てきた、「staticコールだとAOPはうまくいかない。インターフェイスでないとうまくいかない。」という話のくだりのところが理解できなかった。自動生成の仕組みを調べておきたい。

やはり、熟練者でないと、実際に使ってみないとよくわからないので、小さなモノを作ってみるところから始めてみたいと思います。

（今回一緒に主催をしてくれた @atakig さんが直立不動の写真を載せておきます）。

関連リンク

BEAR.Sunday公式ドキュメント

kawanamiyuuさんが作られたVagrantデモ

東京で2014年4月12日に行われた別のイベント「RESTful Meetup vol.3」におけるBEAR.Sunday紹介LT（郡山さんによる）：HTTP IS ONE THING（＜このスライド、下にも進めるのですよ！）

ウェブスター株式会社によりBEAR.Sundayで開発されているPen online

過去に開催されたイベント

BEAR.Sunday meetup #0

BEAR.Sunday meetup #1

BEAR.Sunday meetup #2

参考

BEAR.Sundayの紹介記事です。

WEB+DB PRESS PHP連載第5回「BEAR.SundayでRESTfulなシステム開発」を執筆しました

Dependency Inversion Principle （依存関係逆転の原則）、DIに関するリンクです。

Robert C. Martin - Dependency Inversion Principle(PDF)

山口大輔氏による日本語訳

Pieceの中のSymfony #3: Dependency Injectionコンポーネント

[phpmentors]

BEAR.Sunday meetupに参加しました

7/27(土)に開催されたBEAR.Sunday meetup #2に参加しました。PHPNW 13向けのBEAR.Sunday講演のプレビューがメインだったとは思いますが、それ以外でもさまざまな刺激を受け、また視野の拡がる素晴らしいmeetupでした。まとまりのない感じになってしまいますが、参加した感想を書いておきたいと思います。

自己紹介LT - 「型」

meetupの最初に参加者全員が自己紹介LTをやることになっていました。3分の持ち時間で十分に内容を伝えるのはなかなか難しいことですが、その中で私は黒田鉄山先生の著書「気剣体一致の武術的身体を創る」を紹介する形で、武術における型と、プログラミング技術における型とはと問いかけるようなLTをしてみました。

主張したかったことは、別途ブログ記事にしていきたいと思いますが、この型の話がわずかながらでも郡山さんのお話につながった部分があったのでよかったと思っています。

BEAR.Sundayとは何か？

郡山さんのPHPNW13向けプレビューセッションでは、BEAR.Sundayの特徴を現在の郡山さんの言葉であらためてお聞きすることができました。まとめると次の3つが特徴であるという内容でした。

Resource Oriented Framework

Connecting Framework

"Zen" Framework

もしかするとこれまでにもこの言葉を郡山さんからお聞きしたことがあったかもしれませんが、今回Connecting Frameworkという言葉が私の腑に落ちました。DIによるオブジェクト間の接続、AOPによるレイヤー横断の接続、RESTによる情報間の接続、この3つに注力したフレームワークでありそれ以上でも以下でもない、ということです。そして3つ目の"Zen" Frameworkという言葉ですが、単にフレームワークがシンプルなもので構成されているという単純な話ではないと私は受け取っています。郡山さんの持つ技術や思想が詰め込まれているにも関わらず利用者はとてもシンプルにそれらを利用でき、また、それらを利用していくことがある種の型稽古となってよいアプリケーションを作るための技術者の力を磨いていく、そんなフレームワークであると言いたかったのではないかと勝手ながら解釈しています。

NateさんのLithium&AngularJSのお話

日本にいらしていたLithiumリードデベロッパーのNateさんもmeetupに参加され、彼からAngularJSとLithiumについてお話がありました。WebアプリケーションのフロントエンドをAngularJSで作る一方、バックエンドのPHPアプリケーションをLithiumで開発するのにRESTリソースを扱いやすくするために作られているのが、Lithiumのプラグインli3-resourceというお話でした。Richardさんからも同様な世界的なトレンドのお話があり当然の流れなのでしょうが、APIを中心に据えて開発するという郡山さんの考えと一致していて、やはりそこへ行くんだというプラスの意味での驚きを感じました。

実装の部分では思想の違いがあるでしょうけれど、郡山さんとNateさんそれぞれがフレームワーク開発者として世界のトレンドを受けて、見えている世界に共通のものがあるということが分かり興味深かったです。

最後に

今回のような素晴らしいmeetupが継続的に開催されて欲しいと思います。次回また参加させていただきたいと思っています。会場となったHUB Tokyoさん、スポンサー頂いたWebsterさん、準備や運営にあたられたスタッフのみなさん、ありがとうございました。

[iteman]

[phpmentors]

WEB+DB PRESS PHP連載第5回「BEAR.SundayでRESTfulなシステム開発」を執筆しました

技術評論社WEB+DB PRESSのPHP連載「巨人の肩からPHP - 先人たちに学ぶモダンプログラミング」の連載第5回「BEAR.SundayでRESTfulなシステム開発」を収録したvol.73が発売されました。

WEB+DB PRESS Vol.73｜gihyo.jp … 技術評論社

第5回ではRESTアーキテクチャスタイルを取り上げています。アーキテクチャスタイルとは何かという点、RESTをアーキテクチャスタイルとして採用することの意義なども解説しており、実際にRESTアーキテクチャスタイルでアプリケーションを開発していく流れをBEAR.Sundayフレームワークを使って解説しています。

bearsunday - A resource oriented framework for PHP5.4 - Google Project Hosting

koriym/BEAR.Sunday - GitHub

BEAR.Sunday - twitter

WEB+DB PRESS Vol.73 - BEAR Blog

なお、見出しアイコンにベア吉が採用されています。

[iteman]

BEAR.Sundayではその特性を利用してオブジェクト生成の再利用を行っています。莫大なオブジェクトグラフコンストラクションコストは再利用され運用ではほぼ０になります。10万を超えるファンクションコールは1/100の1000程度になります。これは抽象化レイヤーが最少のFWとほぼ同等です。 この設計パターンはパフォーマンスの寄与と、より少ないコード実行を可能にしています。

BEAR Blog