RubyKaigi 2014 1日目まとめ #rubykaigi

# RubyKaigi 2014 1日目まとめ #rubykaigi
## 入場前
毎朝、会社の始業前に45分～1時間は勉強することにしているので、
船堀駅前のモスバーガーに1時間前に到着してお勉強。

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

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

![20140918.jpg](https://qiita-image-store.s3.amazonaws.com/0/43480/b411ccfd-2567-e81e-001d-b492067be8a7.jpeg)

* クリアファイル（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](http://qiita.com/egisatoshi/items/38f7f8aef32ac67ccd4b)
[続編 -RubyにHaskellよりも強力なパターンマッチを実装した - Qiita](http://qiita.com/egisatoshi/items/dfa13e45edbc71430048)

### 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](https://github.com/geminabox/geminabox)

#### Gem を作る文化を根付かせる努力
* Communication Tool で作った Gem を周知。
* Gem 公開の障壁
    * マサカリ
    * 難しそう
    * 時間がない
    * 英語必須

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

## Hall A ： Ruby committers vs the World
Ruby Committerへの質疑応答
詳しくは Togetter

## 参照
[Togetter まとめ1日目](http://togetter.com/li/720658)