初めまして。流通事業部UXU開発2Gの吉田です。普段はLIFULL HOME'Sの中古物件領域の開発を担当しています。 前の記事のナガサキさんと同じく私もRubyKaigi2018に三日間とも参加してきましたのでレポートを上げます。
ただ、三日間の講演をすべて書くとなると非常にボリュームが多く読む方も疲れてしまうと思うので各講演を三行にまとめてみる、という試みで書きます。
Day1
Keynote by @yukihiro_matz
[JA][Keynote] Keynote / Yukihiro "Matz" Matsumoto @yukihiro_matz
このことわざを元にしたKeynoteはボリュームが多いので各セクションごとに三行とさせてください…。
- 名は体を表す
- クラス名やメソッド名、変数名といった概念に適切な名前をつけることで使い勝手を良くする必要がある
- プロジェクト名は求心力、旗印となるので大事
- Googleが検索の覇権を握っている今日ではググラビリティを考慮した名前付けをする必要がある
- Time is Money
- お金と言っているが実際には価値
- いかに短い時間で価値提供ができるか、それを実現するために各コミュニティやツールがある
- 動作速度も重要で、そのためにJITコンパイラや並列実行機能の強化をしていく
- 塞翁が馬
- Rubyは死んだとよく言われているが波があるので気にしない
- Python2→3もRuby1.8→1.9も破壊的な変更のせいでユーザがついてこれずコミュニティが分断してしまった過去がある
- Ruby2→3にするときは同じ轍を踏まないように進める
Analyzing and Reducing Ruby Memory Usage by @tenderlove
https://speakerdeck.com/tenderlove/reducing-memory-usage-in-ruby
- メモリの使用量を下げたい場合、まずはコードを読むかmalloc stack traceをしてどこでメモリを使用しているかを確認すること
- Ruby2.6ではrequire済みのファイルの探査方法においてRubyのハッシュを作成するのではなくCの文字列を直接参照するようにしたため省メモリになる
- Ruby2.6ではDirect ISeq Marking（直接命令シーケンスマーキング）という技術を導入することでGCのための配列が巨大化せずに済むので省メモリになる
Hijacking Ruby Syntax in Ruby by @joker1007 & @tagomoris
- Binding、TracePoint、Refinements、Ripperと様々なクラスを使ってfinal, abstract,overrideなどJavaLikeな継承とかを強制させるgemを書いた@joker1007さん
- 同じくTracePointを用いてリソースの切断を確実に、コード上はスマートに実行できるwith_resourcesとGoのdefer機能をRubyのgemとして実装した@tagomorisさん（ただしいずれもプロダクションには適用しないほうがいいとのこと）
- これらのクラスを使った黒魔術はくっそ楽しいけどデバッグが大変なので覚悟が必要
All About RuboCop by @bbatsov
https://speakerdeck.com/bbatsov/all-about-rubocop-rubykaigi-2018
- .rubocop.ymlの作成には--auto-gen-configを使うのもよいしgryを使うのも良い
- Rubocop1.0はRails用のAPIをコアから取り除いたら。近い内にリリース予定
- スムーズな移行のためにmryの利用を推奨
RubyGems 3 & 4 by @hsbt
- RubyGems2.7だけが安定版で2.5, 2.6はセキュリティメンテナンスしかされないのでもう使わないで
- RubyGems3.0はRuby2.2以降を対象としたものでdeprecateとなっている機能の削除、新しくdeprecateになるやつのwarningを出すなどRubyGems4.0に向けた移行バージョン
- RubyGems4.0はRuby2.7か3.0に合わせてリリース予定でコンサバティブオプションの導入や--user-installをデフォルト扱いにする意向
A parser based syntax highlighter by @p_ck_
https://speakerdeck.com/pocke/a-parser-based-syntax-highlighter
- 既存のシンタックスハイライターは正規表現で書かれていてバグりやすい＆読めなくて辛いのでRipperを使ってIroというRuby*Vim向けシンタックスハイライターを自作した
- 対象としてyamlもpythonもサポートしており、今後はslimとMarkdownもサポートしたい
- オンラインで試せる https://ruby-highlight.herokuapp.com/
Day2
My way with Ruby by @ktou
https://slide.rabbit-shocker.org/authors/kou/rubykaigi-2018/
- フリーのソフトウェアを使ってRubyでできることを増やす活動をしていた
- バリデーション機能付きのRSS/Atomパーサが欲しくて自作した→その流れで内部的にRSSパーサを使っていたREXMLのメンテナーになっていた、というような感じ
- 一人でやるには限界があるので一緒にやってくれる人を募集している
Faster Apps, No Memory Thrash: Get Your Memory Config Right by @codefolio
https://docs.google.com/presentation/d/1-WrYwz-QnSI9yeRZfCCgUno-KOMuggiGHlmOETXZy9c/edit#slide=id.p
- 高速なアプリケーションを作るためには不要なコードは消す、環境変数のチューニング、jemallocを使う、最新版のRubyを使う
- GCは遅いので無駄な処理を入れないことでGCを走らせない、いくつかの小さいオブジェクトをいくつも持つよりも大きなオブジェクトを1つ持つほうがメモリ効率が良いときもあるなどそういったリファクタリングも必要
- GC.statやGC::Profilerを使ってメモリの状態を見よう
Guild Protype by @ko1
http://www.atdot.net/~ko1/activities/2018_rubykaigi2018.pdf
- GuildとはThreadsに置き換わる新しい並行プログラミングのための機構でRuby3に導入予定
- 分散するほどでもない処理量のものに関してはGuildを使わないほうが高速になる場面もあるが、適切に使えればvCPUの数に応じてWorker数を増やせば効果を発揮する
- GCのタイミングでcriticalエラーが発生するなどまだ課題がある
Type Profiler: An analysis to guess type signatures by @mametter
- 型解決のシステムとしてはSteep、RDL、Sorbet(by Stripe)の3つが有名所として挙げられるがMatzの意向としては外部ファイルに設定を書くSteepが合っている
- しかし自分で型を書くのはしんどいので、コードを解析して自動で型ファイルが生成されるようになればよいというところでRubyのコードをTypeProfilerという中間ファイルのようなものに変換しTypeDBに問い合わせて「この使い方であればこの型である」といった構想に行き着く
- 3パターンほどプロトタイプを作ってみたが課題もあり、道半ば
Day3
The Method JIT Compiler for Ruby 2.6 by @k0kubun
https://speakerdeck.com/k0kubun/the-method-jit-compiler
- Ruby2.6-preview2に入っているけどバグってるからプロダクションでは絶対に使わないで
- 検証コードではRuby2.0より5倍ほど、OptCarrot（Ruby製NESエミュレータ）では2〜3倍高速化できたが、Railsでは遅くなってしまった
- 検証したところRuby→C→RubyというCからRubyの呼び出しの過程で遅くなっていることが判明したのでRuby→Rubyに変えたら高速化できた
- C is dead
How happy they became with H2O/mruby, and the future of HTTP by @i110 & @kazuho
[JA] How happy they became with H2O/mruby, and the future of HTTP / @i110, Kazuho Oku @kazuho
- mrubyを使ってimgのリサイズリクエストを捌くようにした話
- nginxのconfに記述してリクエストを捌くやり方はテスタビリティも低く（設定を変えるたびにreloadしてcurl？）、デバッグもしづらい
- mrubyを使うことでputsで環境変数も確認できるしmruby-mtestというGemを使うことでテストも書けるので運用効率が上がった
- goreplayというアクセスログからリクエストを再現できるツールを使い計測したところ高速化も確認、本番導入もしたが全体的には高速化につながった（一部リクエストは若干の遅延）
- EarlyDataヘッダとhttp status 425を標準化したときの話
- バグの多いクライアントが存在するために新しいプロトコルを導入しようと思った時点でダミーの拡張でもいいから先に流しておいて、今後クライアントにエンバグさせないという工夫が必要
- httpは高速化のために103 ealry hintsなどの設定が複雑化していっているのでmrubyやrackを用いてシンプル＆プログラマブルな書き方をしていく必要がある
- つまりC is dead（Cで書かれているapacheやnginxで頑張るな、というジョーク）
終わりに
一部書けていない講演もありますし、三行に収めるために内容を削ぎ落としているため多少語弊を招く箇所もあるかも知れません。 詳細は記載の資料を読んでいただくなりしていただければと思います。
また、先日LTechという自社イベントの第0回という形でRubyKaigi2018の参加報告をさせていただきました。いくつかの講演に関してはもう少し細かく報告しております。
次回のLTechは記念すべき第1回として機械学習で開催予定です。ありがたいことに既に参加応募をたくさん頂いており予定人数を超えてしまっていますが補欠枠は引き続き募集しておりますのでご興味があれば登録の程をお願いいたします。 また第二回以降も鋭意企画中ですので興味をお持ちの方は是非connpassのLIFULLページからメンバー登録をお願いいたします。 lifull.connpass.com
またLIFULLではRuby好きなエンジニアや、カンファレンス好きなエンジニアの方を採用も募集しています。こちらのご応募もお待ちしております。 hrmos.co
