【Ltech＃0】 RubyKaigi2018報告会
Download as PPTX, PDF0 likes154 views
2018/06/05（火）開催 Ltech#0 RubyKaigi2018報告会講演スライド 登壇者：吉田 希 Ruby2.6に関する情報と参加した講演で気になったところについて
【Ltech＃0】 RubyKaigi2018報告会
- 2. アジェンダ • 自己紹介 • RubyKaigi2018概要 • Ruby2.6にまつわる内容 • 聴講した講演からいくつか • RubyGems • Rubocop • Guild • TypeDB, TypeProfiler • 総括と所感
- 3. 自己紹介 • zom@Qiita • LIFULL入社10年目 • 好きな言語：Ruby • 書ける言語 • Ruby • PHP • js • 趣味：自炊 • anovaで低温調理
- 4. RubyKaigi2018概要 • 5/31(木) - 6/2(土) • 国際センター＠仙台 • 参加者1017名 • この規模は過去最大 • 外国の方も多く体感値3割くらい • スポンサー71社 • LIFULLもプラチナスポンサーとして参加 • Ruby2.6の最新情報が目玉（？）
- 5. Ruby2.6にまつわる内容 • Ruby2.6.0-preview2がRubyKaigiの初日である5/31に公開 • JITコンパイラ • Endless range • Proc#callの高速化 • block.callの高速化 • yield_selfの別名thenの追加 • RubyGems3の導入 • preview3は9月を予定 • 多段backtrace機能を追加予定 • Ruby2.6.0は12月25日にリリース予定
- 6. Ruby2.6にまつわる内容 • JITコンパイラ • Cのコードとしてファイルに書き出しCコンパイラでネイティブコード に変換 • CとGCCコンパイラ環境が必要(VisualC++, IntelC++Compilerでは動かない) • OSもFreeBSDでは動かないなどいくつかの制約がある • 現段階ではプロダクションで使うと確実に動かない • OptCarrorではRuby2.0に比べると2倍速くなった • Railsでは遅くなった • 一定の条件下でオーバーヘッドが発生する（修正予定） • Ruby→C→（ここ）→Rubyが遅いらしい https://speakerd.s3.amazonaws.com /presentations/fc4bc2035f8a497a8fd3dc801aa7a168/rubykaigi2018_k0kubun.pdf
- 9. Ruby2.6にまつわる内容 • Proc#callの高速化 • block.callの高速化 • yield_selfの別名thenの追加 • https://bugs.ruby-lang.org/projects/ruby- trunk/repository/revisions/63525 • Matz自身が5年ぶりにコミットしたことで湧いた
- 11. 聴講した講演からいくつか
- 12. RubyGems • 今までの話 • 現行の最新は2.7.7 • もう2.5と2.6はセキュリティメンテナンスしかされない • Ruby1.8対応 • Object#respond_toでメソッドの有無を確認してifで分岐して対応… • これからの話 • Ruby2.6.0-preview2には3.0.0beta1がバンドル • 3.0はRuby2.2以上を対象 • 上記のようなif分岐を削除 • 今後deprecateになるものにwarningを出す
- 13. RubyGems • Ruby2.7か3.0までに4.0をリリース予定 • 4.0ではすでにインストールされているgemはインストールしな いようにしてエコにする • --user-installのデフォルト化 • gem installするとシステム領域にインストールしようとして permission deniedになる • これは初見ユーザ殺しでRubyを嫌いになってしまう一因と考えている ため
- 14. Rubocop • 今までの話 • 最初は正規表現で頑張ってた • 次にripperを使うようになった • これでかなり改善された • しかしripperはMRIでしか動かない＆ドキュメントがほぼない • クロスプラットフォームで動かしたいので脱ripperしたい • parser(gem)を使うことで実現、ゴリゴリ修正 • ここまでで2012年5月から2013年7月までの流れ • 並列チェックやキャッシュなど様々な機能追加をしてlintツールとして の地位を確立 • 拡張機能も充実（189個） • rubocop-spec, guard-rubocop, rubocop-sequel, rubocop-caskなど
- 15. Rubocop • これからの話（Rubocop1.0について） • コア機能からRails用のCopを削除 • Rubocop拡張をしやすいようにAPIの提供 • mryでスムーズな移行を推奨 • https://github.com/pocke/mry • それでもRubyのサポートするバージョンや設定値の変更などい くつかの機能の変更はある
- 16. Guild • Ruby3.0より導入予定のThreadに代わる並列プログラミングモ デル • 複数のThreadによってGuildが構成され、Guild間で並列実行さ れる • Actorモデルという並行計算モデルを元にしている模様 • 残念ながら知らない領域… • Guild間で共有可能なオブジェクト、そうではないオブジェク トなど実例を交えて提示
- 17. Guild • 各種ベンチマークではコア数に応じて高速に処理できるケース とできないケースがある • 40コアでn個のフィボナッチ数を10万回求める • これはnの数によって異なる • 特定のディレクトリ以下のファイルの単語数を計算して一番単語数の 多いファイルを特定する • Guildを使ったほうが遅い • GCやオブジェクトの割当の際にGVLが発生するため • とはいえ実例を見る限りすごく簡単に並列処理ができそう
- 18. TypeDB, TypeProfiler • Rubyに型を入れないことを明言＠Matz • 将来的にコンパイラが進化して型を推測するような未来になり、型を 意識せずに済むのでは • その未来では自分たちで型を書いている現在のコードは陳腐化する • Matzが最終的なGoサインを握っているのでコアコミッタは Matzの要求を引き出す作業をしている • 様々な型チェックの仕組み(gem)が作られている
- 19. TypeDB, TypeProfiler • Steep • https://github.com/soutaro/steep • 設定ファイルに書いてチェックさせる方式なので言語仕様に影響しな い • Matz好みの方向性とのこと • Sorbet • 今回のRubyKaigiで発表された？ • 結構よくできているらしい • RDL • アカデミック界隈で重宝されている • Sorbetがなければ世界一では by @mametter
- 20. TypeDB, TypeProfiler • Steepが方向性としては良いが手動で作るのは大変 • 将来的には自動生成されるとよい • その生成するための型情報を貯めるためのTypeDB • そしてそのDBへ入れる型情報を生成するためのTypeProfiler • RubyCode→TypeProfiler→TypeDB • 機械学習のようなイメージと個人的に解釈
- 21. TypeDB, TypeProfiler • RubyCode→TypeProfilerにするための手段 • 静的解析1 • 動的に生成されるメソッドなどは間違った推定をしがち • 静的解析2（TypeDBのプロトタイプを使用） • （まだデータが十分じゃないから？）間違った推定をしがち • 動的解析（メソッドのin/outをTracePointで解析） • 遅い • void型を推定できない • やりたいことに対してTracePointのAPIが足りない • まだ道半ば
- 22. 総括と所感 • とにかく使いやすいように、楽しく書けるように、という想い や工夫が伝わってきた • Guildで手軽に並列プログラミング • RubyGemsの--user-intall • TypeDBで自動型推定 • RubocopでLint • Ruby is deadと毎年言われているがこの信念があれば死なない と思う
- 23. 総括と所感 • 日本人でも英語で発表する • 英語マジで大事 • 普通にC言語やメモリの話がされる • 基礎マジで大事 • アセンブリの話をされたときはさすがにぽかーんとした • エンジニアとして刺激をもらえる
- 24. おわり