Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

BEAR.Sunday Meetup #6 に参加・発表内容まとめ

2018/4/28(Sat)に開催されたBEAR.Sunday Meetup #6に参加してきました。

bearsunday.connpass.com

今回は、実際にproduction環境でBEAR.Sundayを採用している実例を中心とした発表でした。発表いただいた内容を個人的にまとめたものを整理したので、気になっていたけど参加できなかったといった方に少しでも雰囲気が伝わればと思います。

そもそもBEAR.Sundayとは

f:id:khigashigashi:20180429133429p:plain BEAR.Sunday

BEAR.Sunday is a framework for creating elegant, truly RESTful API centric web applications in PHP.

https://bearsunday.github.io/manuals/1.0/en/index.html

Tutorialがわかりやすいので、触ってみるのは簡単にできます。

Many web frameworks give you lots of components, modules and features. BEAR.Sunday however gives you just 3 consistent framework patterns into which you can then wire up to your favourite libraries and custom gizmos.

https://bearsunday.github.io/manuals/1.0/en/index.html

RestfulやDI・AOPなどのProgramming paradigmを書いている中でかなり意識するので、既存のMVCを当たり前のように使っている人は一度触ってみるとフレームワークの見方が変わってとてもおもしろいと思います👏

発表内容

実際に登壇された方の発表内容のメモです。 （以下、発表内容と文章の表現が異なる場合はご指摘いただけると・・・。）

Opening Session

BEAR.Sundayの作者である、@koriymさんによる発表でした。

BEARについて

評価について

  • 各人がどういう背景・視点を持っているかが重要、そこがずれると話はずれていく。
  • 分類例
    • RAD(Rapid Application Development):
      • ex, laravel / cakephp / FuelPHP ...etc
      • Downside
        • performance / maintainability
    • Enterprise:
    • Component:
      • micro ...etc
      • micro (framework):
        • エンドユーザーコードに制約を課していないのでframeworkではないという批判もある
        • micro (framework)の作者にもマーケティング用語としての「framework」を使っているという声がある

大きな泥団子

大きな泥だんご (おおきなどろだんご、英: Big ball of mud) は理解可能なアーキテクチャが欠けている ソフトウェアシステム のことを指す。 ソフトウェア工学の視点から望ましくない状態にも関わらず、このようなシステムは事業の圧力、開発者の 刷新 や コードエントロピー などの理由によって当たり前に発生している、アンチパターン の1つである。

PHPの変遷

  • ~4.4: web自体に価値、紙をwebにしただけで価値がある時代
  • 5.2: 早く簡単に（web2.0）、何がいいかわからない時代、早く世にだして受け入れられるかを検証
  • 5.3+: 創造を継続すること：変更可能・品質担保

Developerの成長について

  • OSI参照モデル等と同様にDeveloperにもレイヤーがある。
  • Developer
    • Practice
    • Skill
    • Idea
    • Mindeset
    • Health
  • 「ツールの使い方」などのPracticeよりIdeaやMindsetを重要視すべき
  • そして今回のMeetupはIdeaの話をしたい

その他

Lightning Talk

アドテクの新規事業をBEAR.Sundayで作る実例について

スタートアップを経営されている林さんという方より、新規事業をBEAR.Sundayで作る実例について話していただきました。

  • アドテクの広告効果測定
    • 膨大なデータ量になるが、BigTable等は費用面で現状使わない。しかし、今後シームレスに移行したいと思っている。
    • それもあって、各アプリケーションをPKGにして差し替え容易なアーキテクチャをBEAR.Sundayで実現したいという狙い。
    • 核となるCorePKGが各アプリケーションを呼ぶ構成
      • CorePKGではrouterを書いている、URIをみてどのアプリケーションを呼ぶかをマッピングする
      • 各アプリケーションは全てCorePKGのcompoer.jsonでバージョン管理するためCorePKGをデプロイするだけでデプロイが完了する
  • BEAR.Sundayの特徴としてMicoro Service化するには過剰だが疎結合なアーキテクチャにしたいというシーンで機能しやすい -Micoro Service化する場合はデプロイ等のコストが高いので、6人くらい専任のDevOpsの人員が必要くらいの意気込みがいる

OTOBANKでのBEAR.Sunday実例

@kalibora さんより、株式会社オトバンクにて運営されているaudiobook.jpにてBEAR.Sundayを活用した事例について話していただきました。

  • 選定理由
    • PHPでRestful APIを作る = BEAR.Sunday という社内エンジニアの雰囲気があった
    • くまが可愛い
  • 使ってよかったこと
  • AOP
    • OAUTHの認証処理で使っている
    • @OAuth2\Validate() アノテーションを作り、メソッドインジェクションする
  • swagger-php
    • 実装のために書いたアノテーションなり設定なりコードがそのままドキュメンテーションやSDKクライアントの元になる swagger.json になる
    • bodyにあるオブジェクトを配列にするinterceptorを用意する
      • bodyの興味ではないので、rendererに機能を用意してrendererをinjectするという方法が良い
      • BEAR.Sundayはリソースがrendererを持っている、MVCであればglobalはView classがもっているが
    • swaggerを普通に使うと面倒しているので、改良しちゃってる
      • ただし、メリットがちゃんと出ているかは微妙
      • phpDoc同様、使い続けることが難しい
      • 実際にswaggerが負債になってる事例が会場内で紹介された。

BEAR.Sundayに権限ライブラリを作成(?)して適用してみた

エキサイト株式会社の@poemn_caoさんより、BEAR.AclResourceを作った際の話をされました。

www.slideshare.net

@madapajaさんによる発表

GitHub - madapaja/Madapaja.TwigModule: BEAR.Sunday ModuleというBEAR.Sundayのmoduleを作られている@madapajaによる新規事業をBEAR.Sundayで作るお話でした。

  • 新規事業
    • 複数のサービス間連携を想定。
    • サービス層によってフレームワークは分けている
      • presentation層：Laravel/React
      • API: BEAR.Sunday
      • DB等
  • 構成の自由度、アプリケーションの合成という観点でBEAR.Sundayは魅力的。
  • 使った結果感じた問題

Symfony Configコンポーネント統合例の紹介

エキサイト株式会社のkuma_nanaによる「Symfony Configコンポーネント統合例の紹介」という話でした。

www.slideshare.net

The Birth of FormalBears

@iteman (Atsuhiko Kubo)さんによるこれから作るフレームワークについての話をしていただきました。

www.slideshare.net

Varnishの利用

https://spur.hpplus.jp/にてVarnishを活用する実例についてでした。

  • cacheの制御
    • ttl cache
    • cache無効化
    • rankingやrecommend・動的に異なるものをどう扱うか
  • varnishの活用
    • vmod_key
      • pageの構成要素をキーとして渡す
  • BEAR.SundayでVarnish用にxkeyヘッダを追加するモジュール

Web Page = GLUE + SPEC

@koriymさんに実装のアイデアの発表でした。

Skyの@mackstarさんによるリモートLT

Skyにいらっしゃる@mackstarさんによるリモートでの発表でした

感想

BEAR.Sundayはチュートリアルやって一度@koriymさんに教えていただいたものの、実際にアプリケーションを作ってはいなかったのですが、それでも普段MVCフレームワークを使っていて意識しにくいアーキテクチャについての実例や議論はとても勉強になりました。（と同時に、アーキテクチャレベルの議論に参加できない自分のレベルに落ち込みつつ😓） また、個人的には会場での議論の際にでた「フレームワークを作る側」の捉え方についての話がとても参考になったので、引き続きのOSS活動に活かそうと思います。