RubyKaigi2014 1日目。初RubyKaigiだやったー。
RubyKaigi 2014, 18-20 september
自分用のざっくりまとめ。これでもそうとう削ってるけど長い長い。 とくに英語系は本当にそう言ってたのか超不安…('A`)
Opening
Shintaro Kakutani
- RubyKaigi は Semi-international（笑）
CRuby Committers Who's Who in 2014
[JA] Tomoyuki Chikanaga
- CRubyのコミットログを一番読んでる近永さん
- コミッターたちの紳士録（Whos who）
- 以下、RubyKaigiの日程に合わせた各コミッターの紹介（15名分）
- こういうのがあるからRubyってコミュニテイに優しい感じがするんだと思う
- 発表するひとがどんな人かわかってイイ
(Sponsor - cookpad)
スポンサーの宣伝枠
- 海外レシピサービス買収とか知らんかった。へー
- @mrkn さんスペインに開発に行ってるらしい。現地から RubyKaigi ハッシュにツイートしててワロタ
- cookpad/garage
- Rails framework to add RESTful hypermedia API to your application.
- hypermedia API って後日の発表でも出てくる
- ✍ クックパッドとマイクロサービス - クックパッド開発者ブログ
- ✍ Garageについて、コード例も合わせたクックパッドさんの公式ブログ記事
- Rails framework to add RESTful hypermedia API to your application.
Keynote: Building the Ruby interpreter -- What is easy and what is difficult?
[JA] Koichi Sasada (Heroku, 笹田さん)
- 「Ruby開発において何が簡単で、何が難しいのか」
- 結婚後1年経過おめでとうございます（大江戸のときは半年おめでとうございますみたいなこと言った気がする。お幸せそうでなにより）
- 自己紹介
- 大学の先生だったんですね。なんか納得
- Ruby高速化 -> Quality を高めること
- クオリティの尺度はいろいろある
- トレードオフを認識する -> 決める -> 乗り越える、打ち克つ
(LUNCH BREAK)
- @kwappa さんのいた席に突撃（ひとこと挨拶しただけだけど）
- 他社の方と名刺交換できたー
- 若者にとっては「Rebuildの」宮川さんかーそうかー（弊社後輩くんに聞いてみた）
[B]Controller Testing: You’re Doing It Wrong
[EN] Jonathan Mukai-Heidt (Groundwork, @johnnymukai)
- いきなり英語の発表聞くもんじゃなかった…（落ち込む）
- 実際のノウハウとかより、わりと当たり前のこと言ってたような
- なんのためにテストやるの -> 安全に簡単に変更できるようにするため
- あとからTDDするのは大変だから普段からやる
- 「すべてスタブで」「すべて integration」「render_view とかの view テスト」は良くない
- テストにロジックをそのまま書くな（contextとかにってことらしい）
- Imperative/Declarative
- コントローラはロジックを持つべきじゃない
- コントローラで本当にテストすべきは Response
- shared examples は "Small" detail をカバーするもの
- サインインしてるとき・してないときを１つのshared exampleにまとめて呼び出すとか
- ✍ これはサービスによるだろうけど、この人はこうしたって話…
- サインインしてるとき・してないときを１つのshared exampleにまとめて呼び出すとか
- 命令っぽく書かない。普通の文章っぽいテストを（平叙文で）
- テストはチェックリスト
- "Skinny controller, Fat model"
- 実装の前にテストをイメージしよう
- 例外的なケースが発生した時に Fat controller にならないために
- Easier to test
- シンプルで、作りやすいように考えないといけない
- テストのために実装を簡単にする
RSpec の subject 使って、こういう書き方してたのが気になる。
subject { -> { post :create, blog_post: post, comment: params }}
[B]Continuous Delivery at GitHub
[EN] Robert Sanheim (GitHub)
- 一日にn回DeployしてるGitHubのノウハウ
- ✍ これ GitHub Kaigi で聞いた内容だ！（チャレ●ジ感）
- 継続的デリバリーの必要性と実施の話
- ✍ これまで散々聞いてきた話なので省略（自分ではメモいっぱい取ってるけど）
- "Feature Flags" を使おう
- ✍ なんだそれ？ -> アプリの一部の機能をフラグで ON/OFF できるようにしておくことらしい
- GitHub では
current_user.stuff?というフラグを用意していて、stuffにだけ使えるlive update機能をtemplateに追加したりしてるとのこと - デプロイできないからマージできない、の解消
git co master- "Long lived branches are a smell"
- Rails2 -> Rails3 アプデブランチは長かった...って話
- bootstapping でrailsバージョンを選択可能にして、バージョンでブランチを分けて開発するのをやめた
- それはそれで怖い気がするが…
- ブランチは分けた瞬間から腐りはじめるから、さっさとマージできないとダメ
- github/dat-science
- old way -> new wayの移行チェックができるlib？
- ✍ A/B testツールらしい
- Chat Ops
- ChatOps only room がある
- 新しく入ったひとでも簡単にデプロイできる
- Githubのデプロイはロックしない。キューでやってる
- デプロイ結果は常にモニタリングしている
- （使ってるのNewRelicとかだっけ？メモるの忘れてる）
- いろんな指標をグラフィカルに見れるようにしてある
- デプロイ結果をちゃんと見て、良くなっていないと意味が無い
[B]What's wrong with your app?
[EN] Keiko Oda (Heroku, @keiko713)
- 日本人女性の方がすべて英語で発表。すげー
- Herokai = Heroku employee の紹介
- Herokuで、なんかエラー返された時にあなたのappのどこが悪いんでしょうねって話
- "my app is down" って出る。Zendeskでめっちゃ検索されてる
- Heroku H12 request timeout error
- レスポンスに 30 sec 以上かかると出る
- ケース1: slow request
- 一番多い
- なんかコードが良くない？
- もしかして外部サービスに問題がでてる？
- データベースの問題？（クエリの実行に30秒以上かかってるとか？）
- 一番多い
- ケース2: traffic spike
- 突然のspikeによるdowntimeが発生したとき、あなたのアプリに備えはありますか？
- dynoをscaleしたときに、DB側が耐えられるか？（connectionが足りなくなるとか）
- 突然のspikeによるdowntimeが発生したとき、あなたのアプリに備えはありますか？
- ケース3: memory quota exceed
- ログとってる？
- ログはとても大事。いろんなことがわかる
- Logging add-onもあるよ
- ✍ Twitterで
papertrail使ってるって人がいた
- ✍ Twitterで
- Heroku自体は1500行までしかログが残らないよ
- アプリをモニタリングしましょう
- New Relicは簡単にモニタリングを始めるのにいい方法。add-onもあるよ
- 新しくなったHeroku Dashboadもよろしく
- 改めてタイムアウトの設定を見なおしてみてください
- Unicorn timeout: 15s or less
- rack-timeout: 10s or less
- Address the long-running actions and optimize the response time under 500ms
[A]Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)
[JA] Satoshi Egi (楽天技術研究所, 東大 コンピュータサイエンス修士)
Ruby Egison from Rakuten, Inc
- ”Egison”
- 自作パターンマッチ言語。の紹介
- ✍ 過去のスライドあった The Egison Programming Language
- Non-linear patterns
- 複素集合を簡単に書ける
- Ruby Gemも作りました
- サンプルもたくさん入れました
- 麻雀の上がり判定
[★][B]Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails
[JA] Toru Kawamura (SonicGarden Inc. TAP, @tkawa)
- "RailsでAPIを作るにはこれが足りない"
- くもの巣のようなAPI <-> くもの糸のようなAPI
- public <-> private(single page applicationで使うとか)
- "APIをRESTfulにするかどうかは要件次第"
- 今日はpublic（巣）の話
- 変化は避けられない。変化に適応しなければならない
- バージョンが変わる変更 <-> バージョンが変わらない変更 など
- クライアントが壊れるような変更 -> Breaking Chages
- できるだけ Non-Breaking Chageにしたい
- Breaking Changeになる状況
- 例で見る疎結合: FizzBuzzaaS
- FizzBuzz as a Service（笑）
- クライアントがパラメータを全部用意してからリクエストする -> RPC と変わらない
- ブラウザはどうやってNon-breakingでやっているか -> Workflow in HTML
- ハイパーメディアはワークフローを示す
- クローラにはもう１つヒントが
- Solution: Hypermicrodata gem
- Translate HTML into JSON on Server-side
- with Rails(example)
- Design resources
- Draw a state diagram
- クライアントが使うイメージを図にする
- 必要な処理（create,update,delete,+publish)
- 忘れがち（+next,+prev)
- さらに（+home, +notes)
- Connect names of data with corresponding URLs
- 分類を決める
- できるだけ当てはめておくと、クライアント側で処理の共通化ができる（同じ分類なら同じ処理ができるはず）
- Write HTML templates with Microdata
- ex. Uber
- link, form
- リソースの状態に応じてHTMLが変化する（publish済みならpublishフォームは出さない、次のページが無いならnextリンクを出さない）
- この設計手順の３つのメリット
- DRY
- Awareness of links, forms
- Constrains
- もしJSONだけを書くときは注意すること
- リンクやフォームを意識するために状態遷移図を書きましょう
- 疎結合のためにビューテンプレートを使いましょう（model.to_jsonは密結合になる）
- リンクとフォームを持ったJSONベースのフォーマットを使いましょう
- schema.orgのような標準名を使うとさらに良い
- Web APIはWeb Pageと同じように考える
- JSONは残念ながらデファクトスタンダードがない
- RESTの原則・制約を意識するともっとうまくいく
- ハイパーメディアはRESTの最も重要な要素
[★][B]"Gem of this Week" - building culture and making gem
[JA] Takumi Miura (DRECOM, Rails寺子屋)
- RubyKaigi2014で発表した - mitaku.log
- gemで効率化
- チームメンバーがgemを作ってメンテしていったらいいんじゃない？
- フットワークを軽くしておかないといけない
- Action1 まずはGemを作ってみる
- かぶってる処理をGemにする。プロジェクトをまたいで使える
- UserAgentの判定
- KeepAlive Monitering
- komachi_heartbeat
- かぶってる処理をGemにする。プロジェクトをまたいで使える
- Action2 アナウンスしてみる
- Communication Toolで
- Developper Meetingで（作ったとか更新したとか）
- pull requet
- Action3 Building Culture
- Gemを作る上での障壁
- 公開するの恥ずかしい
- 英語？
- 忙しい？
- スキルない…マサカリこわい…
- 心理的障壁を下げる、ミーティングでgem発表することに名前をつけた「今週のgem」
- プライベートなgemなので、公開しないし、日本語でもいい
- どうやってアップロードするの？手間、ドキュメントがめんどう
- gemのひな形をgenerateするgemを作った
- プライベートサーバにアップロードしやすくする（
rake drecom:release）
- 忙しい
- この障壁はなかなか下げられていない…
- 余力があるときにやっとくと後が楽だよねスタンス
- スキル
- Gemを作る上での障壁
- Other Factors
- GitLab
- メンバーが自由に他のプロジェクトを見れる -> 重複を発見できる、気軽にPRできる
- 社内ツール作成サークル
- 業務時間外に月１で数時間やってるサークル
- 短い時間で完成させる
- Deadline Driven Developmen
- 社内ツール Gemcom <- Gemnasium
- gemのバージョンステータスのチェックツール
- プロジェクト毎にどのgemを使ってるか見れる
- 社内で使ってるgemは公開したくないので Gemcom を作った
- gemのバージョンアップで影響のあるプロジェクトが一覧化される
- (Worst)Rankingを出している
- 競うつもりはないけど、目に見えて分かる
- 最新gem比率でランキング化
- GitLab
- INTRODUCE drecom gems
- capistrano-drecom-deploy
- チームごとにtaskが違う
- afterでいろんなことやってた
- 社内標準のtaskを提供するgem
- rails_security_patch_gem_*
- 大人の事情でRailsがアップデートできないときに、重要なパッチだけ取り込むためのgem
- drecom_ssh
- inspiration of mirakui/ec2ssh
- ordered_find
- find -> ordered_find で指定した順番を保持したまま結果を返すgem
- capistrano-drecom-deploy
- まとめ
- 障壁を取り除く
- 文化として根付かせる
- QAより
- Gemごとにリポジトリつくるの？
- yes
- 作ったGemをGitLabに突っ込んどくだけじゃなくて、(Gem in a Boxに)releaseするのはなぜ？
- gemが綺麗になる
- やっぱりうれしい
- Gemごとにリポジトリつくるの？
