TMD45'β'LOG!!!

Life is Beta-ful.

くがつじゅうはちにち

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)
    • CRuby SVN 84 accounts(bot含む)
      • 2013/6/1 50名が活動(bot含む)
      • 2014 15名が活動(うち3人がKeynoteスピーカー)
  • 以下、RubyKaigiの日程に合わせた各コミッターの紹介(15名分)
    • こういうのがあるからRubyってコミュニテイに優しい感じがするんだと思う
    • 発表するひとがどんな人かわかってイイ

(Sponsor - cookpad)

スポンサーの宣伝枠

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 をカバーするもの
    • サインインしてるとき・してないときを1つの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が足りなくなるとか)
    • ケース3: memory quota exceed
      • アプリがめっちゃ遅いからもっとメモリを使いたい?
        • 一時的な対応として、appを再起動(メモリ解放)
        • Ruby 2.1からメモリ使用量が増えたんだよ...
        • Your Unicorn worker # is appropriate?
        • それでもメモリリークするなら、ツールとか使ってどのあたりにメモリが使われてるかモニタリングしましょう
  • ログとってる?
    • ログはとても大事。いろんなことがわかる
    • Logging add-onもあるよ
      • Twitterpapertrail 使ってるって人がいた
    • 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 (楽天技術研究所, 東大 コンピュータサイエンス修士)

  • ”Egison”
  • Non-linear patterns
    • 複素集合を簡単に書ける
  • Ruby Gemも作りました
    • サンプルもたくさん入れました
  • 麻雀の上がり判定
    • コード少なく書ける(という例をあげてくれてた)
    • ✍ たしかにめっちゃ綺麗に書ける。Egisonのルールがわかったら、複数メソッド渡り歩くような複雑で純粋なパターンマッチを読むより簡単そうな気はする

[★][B]Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails

[JA] Toru Kawamura (SonicGarden Inc. TAP, @tkawa)

  • "RailsAPIを作るにはこれが足りない"
  • くもの巣のようなAPI <-> くもの糸のようなAPI
    • public <-> private(single page applicationで使うとか)
    • "APIをRESTfulにするかどうかは要件次第"
    • 今日はpublic(巣)の話
  • 変化は避けられない。変化に適応しなければならない
    • バージョンが変わる変更 <-> バージョンが変わらない変更 など
    • クライアントが壊れるような変更 -> Breaking Chages
      • できるだけ Non-Breaking Chageにしたい
  • Breaking Changeになる状況
    • 人間が読めるdocから作られるクライアントがたくさん
    • 機械が読めるdocから作られるクライアントもある
      • jsonでリクエスト形式を返してくるからコードで読んで返すとか
      • 機械に読ませるdocを変更したら結局いっしょ
    • 密結合のせい
      • APIの変更がクライアントに通知されるべき
      • 各レスポンスにAPIの説明を分解して埋め込む
      • 疎結合にする
  • 例で見る疎結合: FizzBuzzaaS
    • FizzBuzz as a Service(笑)
      • クライアントサイドを疎結合にできる -> ようなAPIを作る
      • コード中にURLやパラメータを含めない
    • クライアントがパラメータを全部用意してからリクエストする -> RPC と変わらない
      • ハイパーメディアはそれと違う
      • レスポンスに埋め込まれた次のリクエストを実行していくと、全ての結果が得られる
        • responseのnext param(URLとか)があり、それを辿っていく
        • Facebookっぽいなぁ
    • ブラウザはどうやってNon-breakingでやっているか -> Workflow in HTML
      • ハイパーメディアはワークフローを示す
    • クローラにはもう1つヒントが
      • リンクをたどってページを取得する
      • クローラはHTMLの中のデータと意味を理解している。どうやって?
        • Microdata -> HTMLに構造化データを埋め込むしくみ
        • URLに結びつけることで大まかな「データの意味」も表す
        • HTMLの構造を変えても持たせた「データの意味」は変わらない
      • つまりHTMLでWeb APIを作ることもできる
      • まぁでもやっぱりJSON Web APIが欲しいよね
        • じゃあ足りないものをJSONに補えばいい
        • JSONの拡張はいろいろある
  • Solution: Hypermicrodata gem
    • Translate HTML into JSON on Server-side
    • with Rails(example)
      1. Design resources
      2. Draw a state diagram
        • クライアントが使うイメージを図にする
        • 必要な処理(create,update,delete,+publish)
        • 忘れがち(+next,+prev)
        • さらに(+home, +notes)
      3. Connect names of data with corresponding URLs
        • 分類を決める
        • できるだけ当てはめておくと、クライアント側で処理の共通化ができる(同じ分類なら同じ処理ができるはず)
      4. Write HTML templates with Microdata
        • ex. Uber
        • link, form
          • リソースの状態に応じてHTMLが変化する(publish済みならpublishフォームは出さない、次のページが無いならnextリンクを出さない)
    • この設計手順の3つのメリット
      • 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
  • Action2 アナウンスしてみる
    • Communication Toolで
    • Developper Meetingで(作ったとか更新したとか)
    • pull requet
  • Action3 Building Culture
    • Gemを作る上での障壁
      • 公開するの恥ずかしい
      • 英語?
      • 忙しい?
      • スキルない…マサカリこわい…
    • 心理的障壁を下げる、ミーティングでgem発表することに名前をつけた「今週のgem」
    • プライベートなgemなので、公開しないし、日本語でもいい
    • どうやってアップロードするの?手間、ドキュメントがめんどう
      • gemのひな形をgenerateするgemを作った
      • プライベートサーバにアップロードしやすくする(rake drecom:release
    • 忙しい
      • この障壁はなかなか下げられていない…
      • 余力があるときにやっとくと後が楽だよねスタンス
    • スキル
      • すごいRubyできて忙しい人たちが急いで書いたRubyを、そうでもない余裕のあるルビーチョットデキル人たちがgem化する
      • 新人さんにやってもらったりしてgem増えた
  • Other Factors
    • GitLab
      • メンバーが自由に他のプロジェクトを見れる -> 重複を発見できる、気軽にPRできる
    • 社内ツール作成サークル
      • 業務時間外に月1で数時間やってるサークル
      • 短い時間で完成させる
        • Deadline Driven Developmen
    • 社内ツール Gemcom <- Gemnasium
      • gemのバージョンステータスのチェックツール
      • プロジェクト毎にどのgemを使ってるか見れる
      • 社内で使ってるgemは公開したくないので Gemcom を作った
        • gemのバージョンアップで影響のあるプロジェクトが一覧化される
      • (Worst)Rankingを出している
        • 競うつもりはないけど、目に見えて分かる
        • 最新gem比率でランキング化
  • INTRODUCE drecom gems
    1. capistrano-drecom-deploy
      • チームごとにtaskが違う
      • afterでいろんなことやってた
      • 社内標準のtaskを提供するgem
    2. rails_security_patch_gem_*
      • 大人の事情でRailsがアップデートできないときに、重要なパッチだけ取り込むためのgem
    3. drecom_ssh
      • inspiration of mirakui/ec2ssh
    4. ordered_find
      • find -> ordered_find で指定した順番を保持したまま結果を返すgem
  • まとめ
    • 障壁を取り除く
    • 文化として根付かせる
  • QAより
    • Gemごとにリポジトリつくるの?
      • yes
    • 作ったGemをGitLabに突っ込んどくだけじゃなくて、(Gem in a Boxに)releaseするのはなぜ?
      • gemが綺麗になる
      • やっぱりうれしい

▲ ページトップへ移動