RubyKaigi 2014 1日目まとめ #rubykaigi

入場前

毎朝、会社の始業前に45分～1時間は勉強することにしているので、
船堀駅前のモスバーガーに1時間前に到着してお勉強。

早めに到着して、電源のある場所で開場待ちをしたい方におすすめです。

入場

9:30 会場。
オープニングの前にノベルティを漁る。
本日の成果物

• クリアファイル（Akatsuki様）
• クリアファイル（pixiv様）
• ステッカー（GMOペパボ様）
• ステッカー（pixiv様）
• ステッカー（食べログ様）
• ステッカー（CodeIQ様 ※要問題挑戦）
• チョコ（CodeIQ様 ※要問題挑戦）
• ボールペン（食べログ様）
• メモ帳（食べログ様） ※写真にはうつっていない
• RubyKaigi ポロシャツ
• RubyKaigi トートバック（エコバック？）
• RubyKaigi 折りたたみ傘

補足ですが、私はCodeIQの今回の問題の出題者なので
問題に挑戦せずにステッカーとチョコを貰いました。
自分の問題は挑戦できないので。

オープニング

10:15

終始素敵な笑顔で進行してくださった、 Shintaro Kakutani 様によるオープニング。
Twitterのプロフの笑顔のまま。
自分は、意識して笑顔作れない人なので尊敬します。

CRuby Committers Who's Who in 2014

10:30
Tomoyuki Chikanaga 様

今回のカンファレンスは多数の Ruby Committer が参加するということなのでスピーカーに絞って紹介。
私は Ruby のこわい・・もとい、偉い人たちについて詳しくなかったのでありがたい。

総数：84アカウント（bot込み）
前回 RubyKaigi からアクティブで動きがあるのは 50アカウント

• Tomoyuki Chikanaga 様
  Ruby trunk changes
  日々のコミットによる変更をまとめて「ruby-trunk-changes」としてブログに投稿

• Koichi Sasada 様
  Heroku
  VM
  高速化の人

• Narihiro Nakamura 様
  Ruby2.2の目玉、Symbol GC
  次の Rails は Symbol GC 対応のために Ruby2.2をターゲットに舵取り

• Matz 様
  言わずと知れた・・・ですが。
  言語デザイン。実際の開発はせず「決める」お仕事。
  前回 RubyKaigi 以降のコミットはバージョン番号を上げる1行だけ（会場笑い）

• Kazuhiro NISHIYAMA 様
  Mr.typo
  全コミットにおける fix typo 率 68%

• Hiroshi SHIBATA 様
  Rubyのコントリビュート方法をスピーチ予定

• Shota Fukumori (sora_h) 様
  最年少。
  テスト周りの並列化など。

• Kouji Takao 様
  Readline メンテナ。
  Smalruby, Ruby Programming Shounendan。
  詳しくは19日。

• Kazuki Tsujimoto 様
  VM
  Pattern Matching
  Power Assert

• Aaron Patterson 様
  yaml
  Rails Committer
  nokogiri
  いつも面白いパフォーマンスをしてくれるので20日に期待

• Keiju Ishitsuka 様
  Ruby という言語名の名付け親。
  irb

• Masatoshi SEKI 様
  dRuby
  Rinda
  ERB
  ここ1年コミットなし（コミッタ陣笑い）

• zzak 様
  ドキュメント
  gems, rake, rdoc

• Kouhei Sutou 様
  クリアコード
  rexml
  rss
  xmlrpc
  Groonga

KeyNote ： Building the Ruby interpreter -- What is easy and what is difficult?

Koichi Sasada 様

ごめんなさい、話が難しくてついていけず。
周りの方も、「難しくて分からなかった」というヒソヒソ声を多数聞いたので自分だけではなくて一安心。

昼休み

スポンサーからの弁当あり。
広いホールのテーブル席で交流しながら昼食。

自分はRubyistの知人は一人もいないし、
雰囲気に圧倒されて弁当を放棄して外でぼっち飯食べました。
コミュ障でごめんなさい。
大食漢の方、私のお昼弁当食べていいですよ。

昼食から戻ると、CodeIQの担当者さんがいらっしゃったので挨拶。

https://codeiq.jp/ace/codeiq_rubykaigi2014_tbpgr/q945
https://codeiq.jp/ace/codeiq_rubykaigi2014_tbpgr/q946

RubyKaigi向けの問題に挑戦すると、シールかチョコが貰えます。（最初の画像にあるやつ）
正解不正解は問わず。

今日、家族以外の人と話したのはこの瞬間だけだったりします。

各スピーチ

Hall B ： Controller Testing: You’re Doing It Wrong

13:30
Jonathan Mukai-Heidt 様
@johnnymukai

英語苦手だけど、テーマに興味があったので。

ツイートがリアルタイムでディスプレイに表示されていて、
英語が堪能な開発者の方がどんどん日本語で呟いてくれるため、
自分が理解できなかった英語の内容も分かって非常に助かった。

Hall Bは狭いので一番後ろでもディスプレイが見えますが、
Hall Aの場合は広いのでディスプレイを見たければ前の席に陣取る。
もちろん、ノートPCなどで直接Twitterを監視していても良いです。

従来のControllerのテストはスタブやモックばかりだったりして良くない。
コントローラーのテストはしない

時々大きなアクションと小さな詳細をもつ。

Imperative （命令型）の Controller から
Declarative（宣言型）の Controller へ

Declarative（宣言型）＝＞俗にいう、クラスマクロを用いたようなコード。 attr_accessor みたいな。

コントローラーからロジックをなくす
テストも宣言的にする。
不要な部分を削ぎ落したシンプルなテストに。
＝＞認証、リソース、レスポンス形式などに的を絞ってテスト

＜感想＞
確かに、Controllerのテストは結合レベルになりがちで、無理やり単体にしようとすると
モックだらけになってやる意味がなくなりがち。

これは、HubotのScriptなどにも共通の話題かな、と思ったり。
HubotのScriptはシステム間をつなぐような物が多いため、
単体レベルではモックだけ、ということになりがち。

後日深堀りしたい。

Hall B ： Continuous Delivery at GitHub

14:00
Robert Sanheim 様

GitHub 社の開発手法が聞けるということで立ち見が出るほどの大盛況。

• Continuous Delivery とは？
  いつでも、デプロイ可能。

• なぜ Continuous Delivery ？
  変化に対応
  Shipping は楽しい
  リリースサイクルを早める

• 従来
  スローペース＝リリース、フィードバックのサイクルが一年がかり
  遅すぎてビジネスの変化についていけない

• どのように Continuous Delivery を実現する？

  • 自動化
  • PullRequest
  • フィーチャーフラッグ
  • Long lived branches are a smell => 長寿ブランチは Smell
  • science https://github.com/github/dat-science
  • ChatOps
    • Hubot
    • チャットでデプロイ

＜補足＞
具体的にキーワードは出てきませんでしたが、 GitHub Flow の話を含んでますよね。
http://qiita.com/tbpgr/items/4ff76ef35c4ff0ec8314

フィーチャーフラッグの話題の参考試料は以下。
http://martinfowler.com/bliki/FeatureToggle.html

Hall B ： What's wrong with your app?

14:30
Keiko Oda 様

Herokuテクニカルサポートエンジニア

• Heroku Matz チームの紹介
• 本題へ
• サポートへ寄せられる連絡

"my app is down" ばっかり

• サポートへ寄せられる最も多い問い合わせ

H12
タイムアウト

• タイムアウトの原因
  遅いリクエスト
  トラフィック
  外部サービスの問題
  メモリ超過

• タイムアウトへの対応
  メモリ超過については
  短期的にはとりあえず再起動
  長期的にはリークの原因調査

ログ大事。
herokuの1500行がデフォなのでアドオンを使う

New Relicで監視
Webサーバーの選択

Hall A ： Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)

15:30
Satoshi Egi 様

スライド
http://www.slideshare.net/rakutentech/ruby-egison

Egison言語。
Egison言語を作った。宣伝のために Ruby の gem 版を作った

• パターンマッチについて
• パターンマッチの具体例
  • 双子素数、三つ子素数のパターン例
  • 人物の属性と、肩書別挨拶のパターン例
  • などなど
• Egison言語の将来
• 拡張子は .egi 「私の名前（江木さん）」

＜関連＞
https://github.com/egison/egison-ruby
RubyにHaskellよりも強力なパターンマッチを実装した - Qiita
続編 -RubyにHaskellよりも強力なパターンマッチを実装した - Qiita

Hall B ： Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails

16:00
Toru Kawamura 様

スライド
http://www.slideshare.net/tkawa1/rubykaigi2014-hypermedia-the-missing-element

会場、 Twitter のタイムラインともに絶賛の声。
目からうろこのプレゼン内容、分かりやすい構成、分かりやすい説明、通る声。

REST APIの作り方。

• 変化には二種類
  • Breaking Change
  • Non Breaking Change

前者は互換破壊。
密結合だめ。
疎結合にすれば Non Breaking Change に。

• 具体例

  • FizzBuzzaas
    • FizzBuzz As a Service (会場笑い)
    • URLをハードコードせず、 first, next 。＝＞疎結合に。

• MicroData

  • Googleの検索で説明。そのデータが何を表すものか、情報をタグの属性に含める
    • itemtype, itemprop
  • https://schema.org/
  • https://github.com/termi/Microdata-JS
  • JSON にも MicroData を含める
    • JSON-LD

• hypermicrodata gem
  https://github.com/tkawa/hypermicrodata

• REST API を作るには状態遷移図が重要

Hall B ： "Gem of this Week" - building culture and making gem

16:30
Takumi Miura 様

スライド
http://mitaku.github.io/blog/2014/09/22/rubykaigi-2014-speech/

理想の開発って？
共通化
gem

コンテキストはゲーム開発。

ビジネスの競争に勝つための Ruby , Rails

しかし、乱立するプロジェクトで重複がちらほら。
cherry-pick で対応するがよろしくない。

コンポーネント、ビジネスロジック どちらも gem 化しよう。
コンポーネント、外部公開できるなら外部公開の gem。
ビジネスロジック、大抵公開できないので内部の gem Server に公開。

geminabox

Gem を作る文化を根付かせる努力

• Communication Tool で作った Gem を周知。

• Gem 公開の障壁

  • マサカリ
  • 難しそう
  • 時間がない
  • 英語必須

• Gem公開の障壁をなくす努力

  • 内部公開できるように
    • 内部公開なら敷居が下がる
      • 外部からのマサカリがこない
      • 英語じゃなくてもいい
  • GitLab
  • 気軽にGemを作って push できる
  • 他のプロジェクト、他のチームの gem も見れる
  • 難しそう、への対応
    • gem の作成を支援する gem を作成
  • Gemcom
    • gemnasium にインスパイア
    • ランキングで盛り上げたり、利用状況を把握したり

Hall A ： Ruby committers vs the World

Ruby Committerへの質疑応答
詳しくは Togetter

参照

Togetter まとめ1日目