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 。=>疎結合に。
- FizzBuzzaas
-
MicroData
- Googleの検索で説明。そのデータが何を表すものか、情報をタグの属性に含める
- itemtype, itemprop
- https://schema.org/
- https://github.com/termi/Microdata-JS
- JSON にも MicroData を含める
- JSON-LD
- Googleの検索で説明。そのデータが何を表すものか、情報をタグの属性に含める
-
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 に公開。
Gem を作る文化を根付かせる努力
-
Communication Tool で作った Gem を周知。
-
Gem 公開の障壁
- マサカリ
- 難しそう
- 時間がない
- 英語必須
-
Gem公開の障壁をなくす努力
- 内部公開できるように
- 内部公開なら敷居が下がる
- 外部からのマサカリがこない
- 英語じゃなくてもいい
- 内部公開なら敷居が下がる
- GitLab
- 気軽にGemを作って push できる
- 他のプロジェクト、他のチームの gem も見れる
- 難しそう、への対応
- gem の作成を支援する gem を作成
- Gemcom
- gemnasium にインスパイア
- ランキングで盛り上げたり、利用状況を把握したり
- 内部公開できるように
Hall A : Ruby committers vs the World
Ruby Committerへの質疑応答
詳しくは Togetter