Shoken Startup Blog

KitchHike Founder/CTO

Ginza.rb 第35回 Trailblazer入門に参加してきた #ginzarb

勉強会 Ruby Rails

Ginza.rb 第35回 先駆者の知見拝見！Trailblazer - Ginza.rb | Doorkeeper に参加してきました。

Ginza.rbは本当に良いコミュニティ。参加すると、いつも現状で考えられる一番正しい解と最新の情報をもらっています。

Trailblazerについては、去年2015年の9月に勉強会に参加して以来。

Trailblazer勉強会に参加してきた #trbtky - Shoken Startup Blog

2回目ということで、理解はより深まったつもり。わかりやすい発表スライドのおかげです。

発表者: @y_yagi
スライド: http://y-yagi.github.io/introduction_to_trailblazer/

感想

発表後のディスカッションで@netwillnetさんが言っていた。「Trailblazerは学習コストが高い。その学習コストをPayするのは、規模の大きなプロジェクト。だが、大きなプロジェクトではいきなりTrailblazerを入れるのはリスクというジレンマがある。」

別の参加者が、Trailblazerとは別のFW、Hanamiについてだが「エンジニア8人のプロジェクトだが、入れたい。Payできると思う」と言っていた。8人クラスになると足並みをそろえるのが大変のようだ。

TrailblazerやHanamiなど、RailsのMVCとは違う思想のFWの前提にあるのは、Rails辛い問題（詳細は@y_yagiさんのスライド）。fat controllerやfat modelへの回答の一つで、背景にはDDDがある。KitchHikeはエンジニア2人で作っている小規模なプロジェクトで、FWで縛らなくてもある程度の足並みはそろっている。だからといってDDDの知識やTrailblazerの思想が役に立たないかというと、そうではない。ベストプラクティスからの学びは多いし、何よりDDDという共通知識を前提に会話できるのが良い。DDDやTrailblazerは大規模プロジェクト用かもしれないが、小規模プロジェクトの良い指針となっているなと思いました。

明日からもコード書くぞー！

スライドの抜粋メモ

Trailblazerとは

  • 通常のMVCとは異なる層を提供する
    • Operation(サービスオブジェクト)、View Model(cells)、Form等
  • 各処理を適切な層に記載する事で、view / controller / modelがfatになるのを防ぐ
  • また、各層を疎結合にする事で各層毎でのテストをしやすくする

RAILS辛い問題

  • 気付くとfat controller
    • fat controllerを避けようとした結果、今度はmodelがfatになる
  • viewにビジネスロジックが記載されている
    • viewから直接DB参照してたり
  • ビジネスロジックをどこに書けば良いのかわからない

CONTROLLER

個人的にここが一番大事だと思う。controllerを見るうちの9割はリクエストを追う時なので、ビジネスロジックは視界に入らないで欲しい。fat controllerだと、こんなのを見たいわけじゃない！という箇所が多くてリクエストを追うのが辛い。

  • HTTPのエンドポイントとしての処理のみを書く
    • リダイレクトやviewのrenderなど
  • 当然ビジネスロジックは書かない

OPERATION (Railsに無い層)

  • ビジネスロジックを定義する(service object)
  • modelを保存する処理を定義するのはOperationだけ
  • validation / callback / authorizationもOperationに含まれる

VIEWS

  • パーツ毎にcell(view model)を使い、viewはシンプルな状態のままにしておくことが推奨されている

REPRESENTER

  • RubyオブジェクトをJSONやXMLに変換する為の処理を定義する箇所

その他GEM

  • roar: Parse and render REST API documents using representers. 内部で representerを使っている
  • formular: f.selectなどを自分でカスタマイズできる。simple_formの類似。

FILE LAYOUT

Sample Project

https://github.com/apotonick/gemgem-trbrb

勉強会で仕入れた新しい情報メモ

過去のGinza.rbで@y_yagiさんが発表したHanamiのスライド

#java_ja_oss に行けなかったので資料まとめた

勉強会 OSS

10/5にjava-ja.OSSがあった。終わってから知った。行きたかった。

connpass.com

行きたかったぜ。

発表者が豪華

  • tagomoris: 真・OSSプロダクトとコミュニティの話 ビールを添えて
  • t_wada: OSSとしてこの先生きのこるには
  • mizzy: Serverspec の作り方と育て方（或いは Chef 社と戦争した話）
  • a_matsuda: Rails 開発者周りの話
  • mineroaoki: 初期の Ruby 開発者周りの話
  • xuwei_k: OSSコミュニティがある日突然壊れたときにどうすればいいか

豪華！

ニコ生のタイムシフトで見れるっぽい

発表資料

tagomorisさん

tagomoris.hatenablog.com

t_wadaさん

mizzyさん

a_matsudaさん

mineroaokiさん

見つからず。

xuwei_kさん

OSSコミュニティがある日突然壊れたときにどうすればいいか

togetter

togetter.com

関連エントリ

pocketberserker.hatenablog.com

OSSコミュニティについて興味深いエントリを読んだので追記

本の虫: Sarah Sharp、Linuxカーネルコミュニティの暴力性に嫌気がさして貢献をやめる

表参道.rb#5に参加してきた #omotesandorb

勉強会 Ruby

表参道.rb #5 - connpass @Sansanに参加してきた。今回はLT大会だった。最初の方のメモはとれなかったので、いくつか抜けている。

JSON-Schema

発表者: http://hokuma.net

APIの仕様と実装を近づけたい
バリデーションに使える
https://github.com/hokuma/json-schema-sample

OmniAuthのStrategy

発表者: @yimajo

Stargazerという、GithubやQiitaなどのサイトのスター数をまとめるサービスの開発で、OmniAuthを使った話

Ruby-StyleStatsの紹介

発表者: @_shiro16

RubyでStyleStatsをつくった - まっしろけっけ
スタイルシートの統計情報を出力する
http://www.stylestats.org のruby実装

index_shotgunを作った

発表者: @sue445

重複するindexを抽出するためのgem
スライド: http://sue445.github.io/omotesandorb-05/

タスクを呼び出し方がかっこ良い

rake index_shotgun:fire

すごいErlang楽しく学んだ

発表者: @kei_q

JSONサーバーのRails以外の選択肢

Erlangを選択したきっかけの一つ
時雨堂 BOT サーバー (すごいErlangをゆかいに学ぶ会)

Ruby frozen string literal

発表者: @koic

2.3.0で導入される マジックコメントでファイルごとに指定できる、もしくはコマンドラインオプションでも指定化

# -*- fronze-string-literal: true -*-

問題が無ければ3.0でデフォルトになる予定

Service WorkerとFacebookに遊ばれてました

発表者: @igrep

スライド: http://the.igreque.info/slides/2015-10-01-service-worker.html

FacebookはAndroidのChromeで通知のために使っている

Service Workerの役割

  • ブラウザ内のローカルプロキシ
  • ブラウザ版daemon的なやつ

他、発表のスライドにあった情報

Trailblazer勉強会に参加してきた #trbtky

Trailblazer::Tokyo #1@クラスメソッドに参加してきました。

connpass.com

発表者

  • @kbaba1001
  • @yuukigoodman

Trailblazerとは

A new architecture for Rails.
apotonick先生の考えた最強のRails.

github

github.com

Trailblazer は Rails に新しいアーキテクチャを提供する gem です。 Rails のメンテナンスしづらさや複雑さはビジネスロジックが MVC に混ざっていることにあります。 Trailblazer ではビジネスロジックを MVC から分離することで Rails のメンテナンス性を向上します。

引用 http://connpass.com/event/20137/

READMEが充実しているので、読むだけでも概要はつかめる。ソースコードでの例も多く、コード例を眺めるだけでもなんとなくならわかる。サンプルアプリもあるので、そのソースを使い方はわかる。

発表者の@kbaba1001さんいわく、Trailblazerは、開発者であるapotonick先生が業務で多くのレガシーコードと向き合う中で見つけた解決策の集大成なのだとか。思想が先にあって、それをRailsに落とし込んだものではない。なので、机上の理想論ではなく、実現性の高い現実解となっているのがステキなところ。自分で苦労しながら導きだした一つの現実解を汎用的に再構築し、Githubで公開してメンテナンスしている開発者のapotonick先生はエラい。

apotonick先生は充実したREADMEだけではなく、Trailblazerに関する本も執筆している。

leanpub.com

プロジェクトに導入する際には、この教科書が唯一指針となる。英語で200ページ以上。学習コストとしては低くはないが、指針があるのでメンバー間のブレが出にくいのは大きい。

以下は勉強会中にとったメモです。

Trailblazer の紹介 (@kbaba1001)

Trailblazerが解決する課題

Railsは規模が大きくなるとメンテナンスしづらい

  • ビジネスロジックのあるController、再利用しづらい
  • partialがたくさんあって、変更による影響が追いにくい
  • default_scopeを付けている時、外す時が大変。リレーション側からのアクセスだとunscopeで外せない
  • accepts_nested_attributes_for。いっしょに関連するモデルを作る機能。モデルとモデルが密接な結合になってしまってメンテナンスがしづらくなる。
  • validationをifオプションで切り替えをすると、メンテナンスしづらくなる。例: Amazonの買い物かごのウィザード。テストで再現が難しい。後でAPIで登録する場合は書き直しになる。
  • Rails Engineを使うgemの拡張。DeviceやRails adminでcontrollerを上書きすると後々のメンテナンスが大変。gemごとに上書き方法が違う。
  • fat model, fat controller
  • 遅いテスト

課題に対するフォース

apotonick先生の考えた最強のRails

Trailblazerとは、A new architecture for Rails.
cells, reformなどapotonick先生が開発したgemを多く取り入れている。

具体的には、app/conceptsというディレクトリを作って、その配下に機能ごとにディレクトリ作成する。

  • ビジネスロジックをMVCから分離してconcepts以下にまとめる
  • MVCを疎結合にしてメンテナンス性の向上
  • Model: associationとscopeだけを書く
  • View: concepts毎にViewModelとして分割
  • Controller: オペレーションに対するHTTPエンドポイントのみを提供。Strong Params、Modelをfindしない。

ビジネスロジック

  • CRUD
  • validation/callback
  • Viewのためのロジック
  • Worker

一言でいうとMVC + Operation + Cell

サンプルアプリ
https://github.com/apotonick/gemgem-trbrb

Operationとは

Modelのラップ

ビジネスロジックを書く、CRUD, validation, callback

Controllerからのrunメソッドで、processメソッドが呼ばれる

Cellとは

ViewModel

メソッドとassetsのあるpartial

concepts/{機能ディレクトリ}/以下のcell.rbに定義されているメソッドを呼べる

テスト

Operation, cellのテストを行うことで、featureテストやrequestテストを減らすことができる。

partialだけのテストは書かないが、cellのテストができる。細かい単位でテストができるメリット。

Trailblazerと自動テスト (@yuukigoodman)

  • なぜTrailblazerか
  • 電子書籍について
  • とりあえずやってみた前後のdiff
  • Tarilblazerの情報源とか

情報源

DDDの知識は必須では無いが、fat modelに苦しんだ経験から良い設計を勉強する過程で勉強することになるだろう。

以下が揃ったプロジェクトなら、導入できるかも。

  • メンバーがfat modelに苦しんだ経験、良い設計への興味
  • テスト重視
  • Version 2.0が計画されていること。長期メンテナンスが予定されていること。

apotonic先生の教科書が唯一指針になっているので、学習コストは多いが指針はぶれなさそう。

Trailblazer を業務で使ってみた話 (@kbaba1001)

iOSのバックエンドAPI開発でTrailblazer(reform)を使ってみた

解決したかったこと

  • APIリクエストの妥当性検証
  • モデルとリクエストパラメータの疎結合化

Grapeは未使用

コントローラ、モデルでをやりたくなかったので、フォームオブジェクトを作った

reform

modelを継承して、propertyとvalidationを書ける。modelとformを分離するためのgem。

ActiveRecordは入れ子のパラメーターが扱いにくい。reformで解決する。

  • バリデーション、massassignment対策
  • 入れ子パラメータが使える
  • 項目が任意に増えるフォームで、配列を受け取ることができる
  • 複数モデルにパラメータを分配できる
  • モデルに定義されていないカラムをpropertyに書いてvirtual: trueで書ける
  • モデルに書かれていたvalidationのifを無くすことができる。コンテキストによる混乱が無くなる。

コントローラのテストはしにくい。model.saveをコントローラでやっているが、saveメソッドを上書きすることで対応。request specに書かれていたものがservice specに移る。

service層でmodel層をラップしているイメージ

  • ビジネスロジックをサービス層に封じ込めた
  • サービス層でテストするので速い。serviceでcreateして、saveするテストを書けば良い。

Trailblazerが提供するもの => Operation層

  • RailsにもMVC以外の層を作ってもよい
  • Trailblazerのgemは小さい
  • 小さなgemを組み合わせる導入の柔軟さ
  • テストしやすさを重視

apotonick先生が仕事の過程で見つけた現実解。思想が先にあってそれをRailsに合わせたわけでは無いので、現実的である。

勉強会で仕入れた新しい情報メモ

YAPC::Asia 2015のスライド #yapcasia

公式サイトのリンクまとめページ

トークリスト: しばらく経てばここに資料へのリンクが張られるはず。
Talks - YAPC::Asia Tokyo 2015

発表者や参加者のブログエントリまとめ。発表者のブログに行くとスライドと発表の補足があったりする。
【随時更新中】YAPC::Asia Tokyo 2015 感想エントリまとめ | YAPC::Asia Tokyo 2015

外部サイト

SSSSLIDE
「yapc」タグの付いたスライド - SSSSLIDE

Togetterまとめ
YAPC::Asia Tokyo 2015 #yapcasia 全セッション総まとめ - Togetterまとめ

gihyo.jpのレポート 発表内容がレポートされている。このレポートを読むと発表の概要がつかめる。
YAPC::Asia Tokyo 2015 スペシャルレポート：レポート｜gihyo.jp … 技術評論社

読んだスライド

我々にできるOSSとそのコミュニティの育てかた

OSS開発とコミュニティに関する興味深いテーマ。@t_wadaさんの関連エントリと合わせて読むべし。

@tagomoris

@t_wadaさんの関連エントリ
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

どうしてこうなった？ Node.jsとio.jsの分裂と統合の行方。これからどう進化していくのか？

Node.jsの開発がスタートした2009年から、Ryan -> Isaac -> TJへとリーダーの移り変わり、BDFLモデルからの脱却、io.jsのforkが時系列にまとめられている。

@Yosuke Furukawa

Docker３兄弟

先週、Docker速習会で触ったばかりなので理解を深めることができた。

@toritori0318

発表者のエントリ
YAPC::Asia 2015で「Docker３兄弟」というお話をしました＋QA補足 #yapcasia - アルパカDiary

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術

YAPC 2015のベストトーク賞！

@hitode909

発表者のエントリ
YAPCでベストトーク賞いただきました #yapcasia - hitode909の日記

Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN

2008年からYAPC::Asiaに関わっている@yusukebe氏の発表。エンジニアがコンテンツを発信するための1例として、Podcastを使った配信の具体的な話。

@yusukebe

発表者のエントリ
ありがとう！ #yapcasia - ゆーすけべー日記

Perlでゼロから作るコンテナ

@nukamu, @maokt
Perlでゼロから作るコンテナ - YAPC::Asia Tokyo 2015

この発表の資料をどうしても見たかったので図々しくも@nukamuさんに連絡したところ、公開予定があるそうです。
Togetterはこちら
Dockerの振る舞いを知るためにPerlを使ってゼロからコンテナシステムを作ってみよう！Linux基礎講座付き #yapcasia #yapcasiaC - Togetterまとめ

他に公開されているスライド