Ginza.rb 第35回 Trailblazer入門に参加してきた #ginzarb
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
その他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
勉強会で仕入れた新しい情報メモ
- Rubyで作られてDDD指向のWebFW Hanami http://hanamirb.org/guides/
- AWS専用線アクセス体験ラボ http://dev.classmethod.jp/cloud/aws/direct-connect-handson-160511/
- 認可処理用のgem pundit
- View Modelのgem cells
- featureテスト（capybaraなど）を減らせる。featureテストはコストが高い。
- HAL, JSON APIというJSONの標準化フォーマットの2強
- Roda is a routing tree web toolkit, designed for building fast and maintainable web applications in ruby. https://github.com/jeremyevans/roda
過去のGinza.rbで@y_yagiさんが発表したHanamiのスライド
#java_ja_oss に行けなかったので資料まとめた
10/5にjava-ja.OSSがあった。終わってから知った。行きたかった。
java-ja、怖そうなイメージだったけど、思ってたより１０倍くらい怖いイベントだった #java_ja_oss
— yancya (@yancya) 2015, 10月 5行きたかったぜ。
発表者が豪華
- tagomoris: 真・OSSプロダクトとコミュニティの話 ビールを添えて
- t_wada: OSSとしてこの先生きのこるには
- mizzy: Serverspec の作り方と育て方（或いは Chef 社と戦争した話）
- a_matsuda: Rails 開発者周りの話
- mineroaoki: 初期の Ruby 開発者周りの話
- xuwei_k: OSSコミュニティがある日突然壊れたときにどうすればいいか
豪華！
ニコ生のタイムシフトで見れるっぽい
１ http://t.co/kAUYZFsbS0
２ http://t.co/vj9DcVk813
#java_ja_oss
— ﾊﾔｸﾈﾅｻｲ(:3[＿] (@glasses_king) 2015, 10月 5発表資料
tagomorisさん
t_wadaさん
OSS についてあれこれ from Takuto Wada
mizzyさん
発表したスライドは公開しません #java_ja_oss
— Gosuke Miyashita (@gosukenator) 2015, 10月 6a_matsudaさん
mineroaokiさん
見つからず。
xuwei_kさん
togetter
関連エントリ
pocketberserker.hatenablog.com
OSSコミュニティについて興味深いエントリを読んだので追記
表参道.rb#5に参加してきた #omotesandorb
表参道.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
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的なやつ
他、発表のスライドにあった情報
- 日本語テストメソッドについてどう思います http://www.slideshare.net/kenjikumaie/ss-25876730
- gem command_line_reporter コマンドライン出力を色をつけたり変更できる
Ginza.rb 第25回 RailsConf2015の資料をみんなで読もうに参加してきた
7/21にRubyの勉強会、Ginza.rbに行ってきました。ブログ書こう書こうとしていてずっと書いてなくて、ついに第26回Ginza.rbが明日になったので書きます。
やったこと
- RailsConf2015の資料や動画を見た
- Rails Weeklyで直近のコミット内容を追った
- Rails5での新機能、主にAction Cableについて
RailsConf2015の資料や動画
公式サイトにアップされているDHH氏の基調講演や、各発表のスライドを流し読み。
Slide decks from RailsConf 2015 | Eventifier
Rails Weekly
RailsConfの資料を見終わると、話題はRails Weeklyに上がってくる直近の動きへ。実際にコミットしている方も主催者側として勉強会に参加されていて詳しい説明を聞くことができた。
ちなみにGinza.rbの主催者/参加者には、パーフェクト Ruby on Railsの共著者である@willnet氏と@joker1007氏がいる。さらに@a_matsuda氏もフラッと参加するなどハイレベル。Ginza.rbほんとすごい。
Rails5の新機能
3つ大きな変更が予定されている。
ここの勉強会がきっかけで、次の週に行った開発合宿でAction Cableを使うことになった。Ginza.rbほんとすごい。
[Rails5]Action Cableのサンプルを読み解いてみる - Qiita
Turbolinks 3こそRailsの未来 - Qiita
(翻訳) Ruby 2.2 のシンボル GC | FIVETEESIXONE
次回の勉強会
次回（といっても明日だけど）は@kyannyさんがBackbone, Chaplin, Marionette そして React - Quipper における Single Page Application 開発の変遷 - YAPC::Asia Tokyo 2015をベースにJavaScriptフレームワークに関する発表をされる予定。
イベントページ Ginza.rb 第26回 シングルページアプリケーションのためのRailsとJavaScript フレームワーク - Ginza.rb | Doorkeeper
Doorkeeperからメール来てすぐに予約したつもりだったけど、キャンセル7人待ちだったorz。Ginza.rbほんとすごい。
CROSS 2015でデザイナーパネルディスカッションやってきました #cross2015
技術評論社のサイト gihyo.jp にレポートが掲載されました
企画したきっかけ
スタートアップを立ち上げて自分たちのWebサービスをスクラッチから作ってきたのですが、最近はデザイナーさんとのやり取りが多くなってきました。前職はSIerだったためデザイナーさんと仕事で関わることは無く、最初はどうやって進めていったら良いのか悩んでいました。幸いにも周りの人たちの協力で少しずつデザイナーさんとの共同作業に慣れてきましたが、ずっとエンジニアとデザイナーの関係についてのベストプラクティスについて考えていました。そこで、友人や紹介していただいたデザイナーさんに参加してもらって、デザイナーさんの視点からエンジニアとのコミュニケーションや仕事の進め方について語ってもらおうという俺得企画です。
パネリスト
- 株式会社nanapi 木村 真理さん
- 株式会社FULLER 櫻井 裕基さん
- 株式会社サイバーエージェント 新妻 里夏さん
- 株式会社LIG 堀口 誠人さん
概要
デザイナーの作業領域がコーディングよりになっていっている背景をもとに、エンジニアはデザインついてどこまで踏み込めば良いのか、そしてエンジニアとデザイナーの理想の関係を考えるというテーマでディスカッションを行いました。
パネリスト紹介
株式会社nanapi 木村 真理さん
株式会社FULLER 櫻井 裕基さん
株式会社サイバーエージェント 新妻 里夏さん
株式会社LIG 堀口 誠人さん
toggetter
CROSS 2015 デザイナーからのラブレター #cross2015 - Togetter
感想
ディスカッションの中での話題で、この2つが心に残りました。
- エンジニアもデザイナーもお互いの作業領域に踏み込んでいくことが大切
- コミュニケーション、共通認識が大事。（例: エンジニアとデザイナーで共用Pinterestアカウントを作り、良いと思ったデザインサイトをピンしていく）
- 仕様変更を前提とした修正しやすいデザインを作っている人がいる
特に3番目は、拡張しやすいコードが正義なエンジニアにとってとてもわかりやすいことでした。拡張しやすいデザイン、再利用しやすいデザインがデザイナーさんたちの間でも広がっていってるんだなと知りました。
最後になりましたが、参加者とCROSS2015運営スタッフの皆さんに感謝いたします！
