RubyKaigi 2014 2日目まとめ #rubykaigi

前日-当日

1日目のまとめに手間どって睡眠時間1時間半だったり。

入場前

初日同様、駅前のモスバーガー（会場とは逆の出口）で朝勉強しながら開場待ち。
※早めに到着して、電源のある場所で開場待ちをしたい方におすすめです。
カウンターに電源の口が4個。テーブル席の下にある電源が2箇所。
テーブル席の電源も使っていいことは、店員さんに確認しました。

入場

キーノートが9:30からということで、9:15頃に入場。
まだもらってなかったノベルティをゲット。
本日の成果物

• Idobataステッカー（永和システム様）
• ステッカー（万葉様）
• 万葉栞（万葉様）

Keynote

9:30
Matz 様

タイトル「Coming Soon...」

まだKeynoteの内容決まってないのか、って前日までツイートされてたが
実は Coming Soon がタイトルだったということでみんなしてやられて
会場に笑い声。

Heroku 入門宣伝

• 「いまだに Heroku アカウント持ってないけどね」 by Matz

各種カンファレンスと未来

過去の RubyConf 等での Ruby の未来に関する話題について。
メモが間に合わず少し情報不足だと思います

RubyConf2001

Ruby2について

• VM => 2007実現 YARV

RubyConf2002

Ruby2について

• m17n => 2007実現
• native thread => 2007実現
• Generational GC => 2013実現

RubyConf2003

• キーワード引数 => 2013実現
• 変数可視性 => 未
• メソッドコンビネーション => 2013実現
• セレクターネームスペース(Refinement) => 2013実現

2004

未来の話なし

2005

• Stabby lamdba => 2007
• 多値 => 未
• traits => 未

Stabby lamdba は文句が多かった割に、いざ導入したら好評。
周りの声を信じるな（会場笑）

2006-2009 RubyConf

2009 RubyKaigi

• 複素数リテラル 2013
• 有理数リテラル 2013
• TrueDivision 未

2010

• Mix(Trait)
• Module#prepend => 2013
• mruby => 2012

2011から2013

なし

全体で見た実現率

アイデアの実現率68%
アイデアの非実現率32%

そして2014

恒例の「サメは泳ぎ続けないと死ぬ」

※CodeIQ で出題している問題中でもネタにさせていただきました。
気になる方は明日（20日）が最終日なので挑戦してみてください。

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

昼以降ぐらいに各社ノベルティがデプロイされているテーブル近辺で
CodeIQのTシャツを来たお姉さんがチラシを配ってます。
問題に挑戦すれば、ステッカー・チョコゲット。

• 燃料投下の時期

Ruby3について！！

• Concurrency
• JIT(LLVM?)
• Static typing

Static Type について

今までは型のないスクリプト言語が多かった
Ruby含む。

最近は
Scala,Go,TypeScriptなど
型がある

• issue9999
  https://bugs.ruby-lang.org/issues/9999
  Rubyへの型導入に関する Issue
  9999というインパクトのある数字だったのも面白い
  typeアノテーション。
  こんな風にしたい

sample.rb

def connect(r -> Stream, c -> Client) ->  Fiber
def connect(Stream r, Client c) -> Fiber # quite sure this will make some reduce problems in the grammar

• Pythonの例
  • mypy
  • static type checker
  • Python の場合はコロンを利用しているけど、RubyはHashの記号と強豪するのでアローで提案。

sample.py

def fib(n: int) -> Iterator[int]:
    a, b = 0, 1
    while a < n:
        yield a
        a, b = b, a+b

• 型の利点

  • パフォーマンス(思い込み)
  • 型チェック
    • これは嬉しい。バグの抑止。リファクタリングのしやすさ。
    • しかし、柔軟性が減る。ダックタイピングと相性が悪い
  • ドキュメント
    • ドキュメントコメントよりも、コードとして記述されている分信頼できる。
    • 処理内容を読まなくても型宣言だけで判断できる

• では、なぜ今型をもっていないか？

  • ダックタイピング => 型はダックタイピングの世界を破壊する

• オプショナルの導入がもたらす予想結果
  全てに導入は無理なので部分的に導入できるようにするしかない。
  型ありから型なしを呼び出すと型落ちしていくので、あちこちで型落ちが発生。
  全体としてはあまりチェックされない。
  一部ではなく、徹底して導入すれば効果があるだろうが、それをやったら Ruby でなくなってしまう。
  Pではじまる、バージョン5と6で全く別言語になってしまった言語みたいにはしたくない。（会場笑）
  Ruby は Ruby のまま。

• DRY
  重複は悪
  型はDRYではない
  個人的にはやっぱり型を書きたくない

そこで・・・

型推論(Soft Typing)

• ダックタイピングベース
• クラスやインターフェースではなく、メソッドの集合として型を判断

• コンパイルチェックが可能。明示的な型ほど厳密ではないが、ある程度チェックできる。

  • Rubyの、柔軟性を駆使するコードはチェックできないだろう

• 型推論は言語のサブセットが対象。

  • require
  • define_method
  • method_missing などは対応できない

• 暗黙のため型宣言はない。つまりドキュメントの効果はない

• 日経Linuxの宣伝をはさみつつ
  ※今してるような話が掲載されますよ、と。

Subsetの考え方

他にも活用可能
互換性を維持しながら新たな言語へ

QA

• 型推論の導入によって今まで出せなかった警告を出せる可能性がある
• 今までの型導入失敗について。今までも型の導入については検討失敗してきたが今回との違いは？
  • 今まではサブセットの概念がなかった。

各スピーチ

Hall B : A Just in Time compiler for CRuby (CRuby言語処理系向けJITコンパイラ)

10:30
Masahiro Ide 様

趣味は車輪の再開発

CRubyのJITを作る

1 Ruby
2 JIT
3 RuJIT

・Ruby
多くの処理系がある

C言語より 10 から 100 倍遅かったり。
どうやったら高速化できる？

RubyのJIT処理イメージ

Code => AST => bytecode => compiler =>interpreter

インタープリターがボトルネック
バイトコードをより低レベルなものにして高速化

RuJIT

Trace based JITコンパイラ
頻度の高いパスをネイティブコードに変換。代表例はループ処理。

CRubyのインタープリターを Firefox の Javascript Interpreter のように

• 開発方針

  • 開発コストを下げる
  • 一人でできるように
  • 最適化の拡張をしやすいようにする

• YARVのバイトコードをRuJITでネイティブコードに変換

• 実行しながら最適化。ループ外に出せる処理を外に出したりとか。

• 評価例

  • ENV: Mac,cruby
  • だいたい、2~5倍
  • いくつかは100倍以上

• 大規模アプリケーションへの効果はまだわからない

• 複雑なケースだとパフォーマンスそのままか、やや低下

Hall A : Archeology of Ruby: Removed Features (Ruby 考古学 機能編)

11:00
Kazuhiro NISHIYAMA 様

スライド
http://www.slideshare.net/znzjp/rubykaigi2014

聞きたかったのだけど、会場Bの時間が長めになったこともあり、
会場B終了後、コーヒー1杯飲んで会場Aに入場したら
もう基本的な講演は終わっていて、QAコーナーだけだった。
A面 B面どちらかで話が時間内に収まらなかったら AB 両方を同期して進行して
もらえると嬉しかったしする。
この点は他の方もツイートしていた。

Hall A : <%= link_to "bundle", "update" %> - Make "bundle update" more fun to review

11:30
Kensuke Nagae 様

スライド
http://sssslide.com/speakerdeck.com/kyanny/percent-equals-link-to-bundle-update-percent-make-bundle-update-more-fun-to-review

1. Solution
2. Motivation
3. Implementation

Solution

• GitHub の CompareView Url
  バージョン範囲やリビジョンキーを利用したURLをもとに比較

• 自動化のチャンス
  Herokuでアップデートしてプルリク
  対応できないケースの説明がある

Motivation

• bundle updateを楽しくしたい
• 自動化

Implementation

• 実装
  • webhook
  • compare Gemfile.lock
    • GitHub APIを呼ぶ
    • RubyGems APIを呼ぶ
  • build
  • post comment

そこそこ成功

継続的改善が大事

昼休み

スポンサーからの弁当あり。
昨日同様弁当を華麗にスルーして外でぼっち飯食べました。
コミュ障でごめんなさい。

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

Hall B : RailsGirls: Not Only For Girls

13:30
Haruka Iwao 様

スライド
http://www.slideshare.net/Yuryu/rails-girls-not-only-for-girls-rubykaigi-2014

• Gender
• 技術カンファレンスごとの男女比
  • RubyKaigi 2013 に至っては女性スピーカー 0 名
  • PyCon はカンファレンスの中では女性比率が高い

• 技術系会社ごとの男女比
  企業ごとの円グラフ表示
  女性比率を確認。
  eBay多い。25% 程度
  平均だと 15~20% ぐらいが多い

• なぜ女性はコンピュータサイエンスより、他の分野を選ぶか
  ぐぐれば分かる
  サイエンティストの画像検索 => 男性のイメージばかり
  職業イメージとグーグルイメージの例をいくつか。

• 動画ようつべ
  http://www.youtube.com/watch?v=XjJQBjWYDTs

• 日本の採用
  履歴書に性別欄がある（JIS Resume Format）
  女性が面接を受ける際に将来の出産計画などを聞かれたり
  本当に実力だけで採用しているのか？

• RailsGirls とは？
  世界中でイベント。
  活動範囲をスライドに表示。
  ヨーロッパでの活動多い。

• カリキュラム

  • インストール
  • ビルド
  • GitHub
  • オンラインデプロイHeroku
  • Deviceによる認証

Hall B : The Twelve-factor Ruby 「Ruby を良くするための12のポイント」

14:00
Hiroshi shibata 様

スライド
http://sssslide.com/speakerdeck.com/hsbt/the-twelve-factor-ruby

• 柴田さんがやっていること

  • Committerのとりまとめ
    • Ruby コミッタはあんまり協調的ではない(会場笑)
  • スポンサーとのやりとり
    • Ruby公式や、るりまなどはスポンサーの協力で運営されている。
  • 開発環境担当

• 柴田さんの所属

  • ペパボ
  • 新しい物はRubyで作る
  • 社内全員の生産性をあげる

• どのように、Rubyを作ってる？
  コアクラスはまつもとさんの決定が必要。

• 標準ライブラリ
  メンテナの権限で変更可能

• 付属ライブラリ
  柴田さんまとめ

• ドキュメント
  zzakさん

• もっと燃料が必要
  どうやってよい燃料を与えるか？
  Redmineに、チケット起票
  GitHubでもいい。issueは無効にしているが、pull reqは可能。
  ただし、まつもとさんはRedmineにしかいない。
  大きい変更やコアへの変更はRedmine側へ

・とりあえず、出す。
利益になる。
Twitter で Ruby をディスっても仕様は変わらない。
なら、変わる可能性がある Issue なり PullRequest を投げる

一見放置されているようでも、後で確認してもらえるかも。
議論を生む。
自転車置場の議論のようなものでも、新たな知見に繋がる場合も。

以降、よりよい Issue/チケットの話

• ユースケースを出す。

  • 目的を明らかに。

• 採用されやすい報告

  • Symmetrical
    • 機能Aがあるのに、対称機能Bがないのはおかしいのでは？ => そうだね、になりやすい
  • Posix準拠
    • Posix準拠っていうと話が通りやすいそうな
  • Bug Segv
    • バグも優先度が高い

• コードをつける

  • メンテナが問題を理解するのが容易になる

• 名前
  名前重要
  名前以外の全ての条件が整っても名前が悪いと reject

• Red Ocean は避ける

• 現状の Blue Ocean

  • Win/AIX/Solaris
  • Rails trunk
  • documentation

• 日本語の報告もOK。

• 英語ならよりよい。

• 敷居を下げる

  • 英語に尻込みして報告してもらえないぐらいなら、日本語でいいので報告して欲しい

• Expectationを書く

  • 期待値を知らせる。
  • 再現

• クラッシュログをつける

• 不具合があったらTRUNKで試す。もう直ってるかも？
  TRUNKからブランチに修正を当てるので、基本TRUNKで検証

• Urgentフラグを使わない
  コミッターは優先順位見てない
  いいレポートを書く

Hall A : Scalable deployments - How we deploy Rails app to 100+ hosts in a minute

14:30
Shota Fukumori (sora_h) 様

B会場の進行遅れのせいもあり、B会場の前のコマ終了時点で既に sora_h さんの講演が
始まってしまっていた。
ちょっと疲れてたし中途半端だったので、参加を控えて休憩。

午前の話でも書いているが、両会場の時間を同期してもらえないと 2 つ見れたはずの講演が
1 つになってしまったりともったいない。

Hall B : Write Ruby code to change Ruby code

15:30
Richard Huang 様

スライド
https://speakerdeck.com/flyerhzm/write-ruby-code-to-change-ruby-code

• RSpecの、新文法どう？

  • 1回目 => いいね
  • 2回目 => ...。
  • 3回目 => もういや。
  • ※雰囲気で訳してます

• 開発者はアップグレードとリファクタリングが好き。

• アップグレード対応大変。

• 自動化

• テキストベース
  一括置換するRuby code
  Rails2形式を3形式に

思ったことはだいたいできるが厳密ではない。
コメントも置換しちゃったりとか。
下記を使えば厳密にできる。

• ASTを使う
  • どうやって使う？
    • ripper
    • ruby_parser
    • parser

しかし、とっつきにくい。そこで・・・

• 上記でも良いのだが、より使い勝手の良いツールを作った

  • synvert gem https://github.com/xinminlabs/synvert
  • ASTを扱いやすくしたようなもの。

• 以降変換の実現

• TL上は「これすごいんじゃね、ざわざわ・・ざわ・・」的なリアクション

Hall B : 7 years of Ruby & Rails with the same web site

15:30
Zev Blut 様, Kevin Griffin 様

• iKnow, Cerego などを作ってる
• Rails
• コードの共有難しい(sharing code is difficult)
• submodule
• rails engine
• 共通化してみたものの異なるシステムが同じcoreに依存
  • cherry-pickつらい
• カスタムソリューション
• 進撃のカスタム（会場笑)
• 担当者が変わった
• 退社
• ナレッジの消失
• 意味を失ったテスト

• 何をできるか？

  • デッドコードを消す
  • すべてを書き換える
  • 575行追加して
  • 333万行のデッドコードを消す（会場、おおーーーーっと拍手）

• 消した結果メンテしやすくなったよ、と。

• アップデートし続ける

• Developer Bootstrap

  • vagrant + chef
  • 新規メンバ参入時の導入コストを下げる

• QA

  • テストファーストしてるよ

Hall B : Power Assert in Ruby

16:30
Kazuki Tsujimoto 様

スライド
https://speakerdeck.com/k_tsj/power-assert-in-ruby

• Concept
  対応してるのは、unit系。
  spec系は未対応。
  ただ、spec系の場合に、実装できないというわけでもない。
  貢献お待ちしてますよ、と。

• 豊富なマッチャーの使い分け

  • 覚えるのが大変だけど、分かりやすいレポート

• assert大量、覚えられる？(笑。

  • ディスプレイには大量のマッチャ一覧が表示されてる

• power assertはassertメソッドしか使わない。

• assertを使い分けなくても分かりやすいレポートが。

• power-assert gem

  • cruby2以上が必要。
  • test-unit3からは標準組み込み
  • Rubyに標準組み込み予定

• 使い方の一例
  powerp
  pメソッドの拡張

• Imple

  • tracepoint の話がメイン。
  • tracepoint は凄いってことを知らせたい
  • 経験者挙手(数名)。

• イベントの取得

• 戻り値と例外

• そのままだと、情報が取れすぎる

• みんな大好き黒魔術(会場笑)。

  • binding#eval
  • スタックの深さを使用すると、必要な情報だけもらえる

• == による非字画の結果がでないことが。

• バイトコードの確認方法
  RubyVM::InstructionSequence.disasm

def say
  "I love ruby"
end

puts RubyVM::InstructionSequence.disasm(method(:say))

__END__
output 
== disasm: <RubyVM::InstructionSequence:say@/path/to/home/test.rb>==========
0000 trace            8                                               (   1)
0002 trace            1                                               (   2)
0004 putstring        "I love ruby"
0006 trace            16                                              (   3)
0008 leave                                                            (   2)

• 最適化が原因。無効化すると対応できる

LT

17:30
10名
http://rubykaigi.org/2014/LT

Practical factory_girl

Kenichi TAKAHASHI 様

• メンテブルなFactory

• traitを使う

• 継承、ネスト、trait

• 複合条件が出た場合

• trait

• 状態は親子関係じゃない

• describe

  • もの、こと

• context

  • 状況

Native Library Gems

英語スピーチ＋スライドの文字が小さかったのもあって内容把握出来ず。

ofruby - Ruby running on the iPhone

ongaeshi 様
アイフォンで動く開発環境 ofruby。
iPhone内で完結する。

• ライセンス無料

• 構成

  • mruby
  • openFrameworks

• なぜ作った？
  子供がプログラムをかける環境の提供。
  昨今スマホのシェアが増え、PCが絶滅の危機。
  子供が親の目を盗んでPCをさわるための機会が減少。
  つまり人類の危機。
  人類の危機を救う！
  (パソコンをいじる機会が減る)。
  会場笑

• ソースコードが公開されてるので動作可能。

• デモ
  ボールが落ちるデモなど、数種類のデモで会場を盛り上げる。

Keepfreedom Ruby

万葉
Yasuko Ohba 様

• 自由が好き。
• Rubyは自由。

• 気持ちのままかける

• チームのコード。

• 時間の経過。

• 一貫性の問題。

• 一貫性と自由。

• Rubyが与えたものをプログラマが制限しない。

• 短期的に初心者に制限を与えるのは良いのかもしれないが、地獄への入り口。

• 試すことは良い。

• チャレンジ、変更への障壁を上げない。

• よく知られたメソッドに妙な制限を加えない。

• やるならオプショナル。

10th anniversary るびま

Rubyist Magazine editors

• LT落選した人→るびまで記事書いて。

• メリット。あとに残る。

• るりまの歴史

  • 48号今日出た => http://magazine.rubyist.net/?0048
  • 10周年記念記事
    • 通常発行数：48
    • 特別発行数：5
    • 記事数通常記事：643

• 目玉記事

  • 多言語探訪
    • 書籍化ボツる
  • Hotlink

• 印象的記事

  • ぱるま、エイプリルフール

lets try mruby

cの話のみ
INOUE Yasuyuki 様

• mrubyに貢献すべき
  • 簡単に問題を発見できる
  • 困難に挑戦する必要が無い
  • まだまだ。簡単な課題がたくさんある

Probabilistic model for inspirations and significance of programming

Ippei Obayashi 様

Rubyとは関係ない話
アイデア、閃きなどについて

• 成否はまちまち。
• 利益もまちまち。
• アイデアは確率。
• アイデアは期待値。
• 成功率低い。
• アイデアの価値は低い。
• 期待値は加法性がある
• 足せる。
• そのままではだめ。
• 試行が必要。
• コードをかけ。
• プログラミング力が必要。
• :
• :
• でも加法性の前提はあやしい
• 2つのアイデア。
• 同時じゃない。
• 条件付き期待値。
• 相関すると、期待値は小さくなる。
• 似たアイデアは片方がうまくいかないともう片方もダメ。
• 相関を減らす。
• 多種多様なアイデアを試す。
• 多種多様なプログラミングが必要。
• 要修行。
• :
• 総括、アイデアとかの話になったらこんな感じでけむにまけ

R/W splitting in Rails

Kohei Suzuki 様

• railsで複数データベース
• 読み書きの使い分けがデフォルトではできない。(マスターとスレーブ)。
• acts_as_readonlyable 多機能だけど移行困難。コードベースでかい。
• switch_pointを作った。
  • モンキーパッチを避ける
  • プロキシを挟む
• Railsに依存しない実装

invitation for v1.0.0

tagomoris 様
バージョニングの話

• v1 でプロダクションでの利用、APIの安定をアピール。
• v0 ということはその逆。

• 互換性を破壊しないバージョン1をリリースすること。

• バージョニングにはロマンがある(by twada)

• fluentdはバージョン0 (ここで会場笑い)

rspec3へのアップグレード

Yuji Nakayama 様

• RSpec3 6月2日リリース。

• 互換性なし。アップグレードが必要。

• Rspecチームはアップグレードをサポート。

• rspec2.99

  • 2系互換と、3の機能
  • アップグレードチェックList

• Transpect

  • 文法を変換してくれる
  • ASTと、実行時情報を使ってる

• Upgrade Workflow

  • 2.99のアップ
  • Transpec実行
  • 必要なら手作業

• ほかの作業にも流用したい

• 何故今回のやり方はうまく行った

  • 実行可能であること
  • テスト可能
  • モチベーション

• 妥協の余地あり。

• RSpec以外の分野に適用する場合、変換精度を落として楽をする。

• APIを破壊する代わりにアップグレードサポートをする

参照

Togetter まとめ2日目
Togetter まとめ2日目A
Togetter まとめ2日目B