こんにちは、 
tomoasleep です。
2018年5月31、6月1日、2日の3日間に渡って開催されたRubyKaigiに参加してきた様子をレポートします。
※写真はMatzことRubyの生みの親・まつもとゆきひろ氏と一緒に参加した@minakawa-daiki
RubyKaigiって？
RubyKaigi
（ルビーかいぎ）とは、日本で開催されているRubyコミュニティ主催のオブジェクト指向プログラミング言語Rubyに関する年次イベントである。名称は過去何度か変遷しており、2013年からは通称であったRubyKaigiが正式名称として用いられている。
引用: Wikipedia
最近QiitaでもMatzさんの別の講演内容が1000いいね以上獲得していてトレンド入りしていました。
1000いいね！ | 【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略に行ってきたので私的メモ by @arakawa_gios https://t.co/HiBJjDIlyJ
— Qiita (キータ) 公式 (@Qiita) July 5, 2018
5/31
Keynote
1日目の初日はMatzのKeynoteからでした。
ことわざに絡めてRuby2.5で導入された yield_self を自ら then に改名した話、「Ruby is Dead」と言われることもあるが、これからも進化し続けるという宣言などが飛び出しました。
Ruby3.0に向けた話として、最近トレンドの静的型付けについても触れられましたが、有用性は認めつつも型注釈を文法に入れるつもりはなく、
型検査も外部のツールとして用意するというスタンスのようでした。
Lunch
牛タン入った弁当 
A practical type system for Ruby at Stripe. – RubyKaigi 2018
A practical type system for Ruby at Stripe. – RubyKaigi 2018
昼のセッションでは、Stripeで内部的に作っているType Checkerの紹介がありました。
StringのProductivity Teamの方からの発表のようで、StripeでのRubyの使われ方についての説明(Railsは使っていないというのと、monorepoにしているのが特徴的でした)がありながら内製のType CheckerであるSorbetが紹介されました。
紹介早々、完成度が高いオンラインデモ ( https://sorbet.run )が紹介され、自分も発表を聞きながら色々デモを試していました。
社内で使うということもあって、実用性を追求している印象で、できるだけシンプルに、簡単に導入できるようにし、なおかつスケールするようにというのを原則として置いているようでした。
非到達コードの検出を行ったり、nil のチェック漏れや起きやすい例外処理中のtypoなど、遭遇しやすいエラーやテストでチェック漏れしやすいエラーを検出でき、社内の利用でもそれらを検出できているそうです。
ちなみに、型注釈は Contracts.ruby に似たDSLで書くようです。
(黒魔術的なところもあるので、個人的にはコメントとして書けるといいな〜と思ったりするのです 
)
外部のライブラリはデモなどを見た感じでは signature ファイルを用意する感じでしょうか？
(デモには .rbi ファイルなるものが確認されました 
)
実装は C++ ベースで実行速度も高速とのことでした。
現在は社内で利用されているのですが、将来的にOSSにする計画だそうです。非常に公開が楽しみなプロジェクトです。
Hijacking Ruby Syntax in Ruby – RubyKaigi 2018 も気になる…
All About RuboCop – RubyKaigi 2018
All About RuboCop – RubyKaigi 2018
RuboCopの作者である、bbatsovさんがRuboCopの歴史と 1.0 に向けた話をしてくれました。
初期はRubyコードのパースに正規表現を使っていたり(!?)の話や、その後利用するパーサーをripperからparser gemに移行した話がとても興味深かったです。
1.0 に向けてもRails用のCopなどを分離したりとこれからの計画についても語ってくれました。
余談ですが、弊社のエンジニアでもある yujinakayama の名前がRuboCopの開発メンバーとしてスライドに出てきた時は、社内のSlackで歓声が上がりましたｗ
Afternoon Break
Afternoon Breakとして少し長めの休憩があったのですが、その間はスポンサーブースを回ってみていました。
RubyKaigi初参加なのですが、様々な企業がプレゼントを用意したり、スタンプラリー企画などがあったり、趣向を凝らしていてとても面白かったです。
RubyGems 3 & 4 – RubyKaigi 2018
RubyGems 3 & 4 – RubyKaigi 2018
RubyGemsのメンテナの人の話。
標準ライブラリというのもあって、いろんなケース(Ruby 1.8サポートとか 
)に対応したり、Compatibilityを配慮したり、標準ライブラリともなるとかなり慎重に出していかないといけないという大変さが伝わります…。
RubyGems 3や4ではわかりやすくDeprecationが出るようにしながら、DeprecatedなMethodをいくつか取り除き、色々な新機能を入れていくようです。
開発のために、rubygems.org のローカルコピー作ってコードの全文検索するツール(akr/gem-codesearch)や、様々なバージョンのRubyで動作確認をするツール (akr/all-ruby) など普段想像もしないツールなどが作られていて、非常に興味深かったです。
A parser based syntax highlighter – RubyKaigi 2018
A parser based syntax highlighter – RubyKaigi 2018
Rubyのシンタックスハイライター（https://github.com/pocke/iro）を書いた pocke さんの話でした。
背景として、各種エディタのシンタックスハイライターが使っている独自のパーサーには色々な問題点があり、正規表現などで書かれているので実装がわかりにくい、新文法への追従が必要、複雑なコードをうまくパースできないなどの問題があるとのことでした。
それらの問題への対応として、Ruby標準のParserである ripper を利用した、 iro を開発したそうです。
バックエンドとしてのRuby製の iro とフロントエンドとしてのvimプラグインの二層構成になっているようです。
今後は、他のエディタへの対応や、高速化、HTML中などのコード埋め込みへの対応や、Slim、Markdownなどへの対応も行いたいとのことで今後が楽しみなプロジェクトだと感じました。
クライアントとして Vim プラグインを書いているところで LSP (Language Server Protocol) は利用できないのか気になって質問したのですが、LSP はシンタックスハイライト用のプロトコルがまだ用意されていないらしく、現在は独自のプロトコルを利用して、エディタプラグインと通信を行っているそうです (そのへん整備されていくといいですね)
LT – RubyKaigi 2018
様々なテーマで5分間のLTが行われました。
コアの改善の話や、静的解析の話、5分間でTODOアプリのライブコーディングに挑戦する話や、Matzのトークに絡めて、「Rubyが毎年死んでいる話」(バージョンブランチのライフサイクルの話)など様々なテーマの話がありました。
中でも rib という Yet Another irb の発表があったのですが、非常に完成度が高く、もうちょっと長く聞きたかったです。
Party
初日のセッションも終わり、会場内のパーティに参加しました！
ぼくは会場に来ていた知り合いの方や、SNSで知り合った方などとの交流をしました。
Rubyistの祭典ということもあり、他の参加者とはRubyの話で熱く盛り上がりました(個人的な開発の話や、型注釈や開発環境の改善など…話したいこと色々あったのでとても盛り上がりました)
熱くなりすぎてめちゃくちゃ疲れたので、この日は終わったあと即ホテルに戻り風呂に入って即就寝しました 
6/1
6/1はこんな感じのスケジュールでした。
My way with Ruby – RubyKaigi 2018
My way with Ruby – RubyKaigi 2018
2日目の話は須藤さんのKeynoteで、須藤さんがこれまでRubyを使って色々なことをHackしてきた話でした。
いろいろな自動化をコツコツ作ったりとか、作業の効率化をやってきたりとかの話なのですが、やってきた改善が非常に多彩で、本来の意味のHackerという感じですごいです…。
Improve Ruby coding style rules and Lint
Improve Ruby coding style rules and Lint – RubyKaigi 2018
RubocopのカスタムCopを書いたりそのCopをRubocopメンテしていく話。
OSSを使っている分、自分たちのつらいところをみんなのつらいとこと捉えてOSSに還元する、などの話があって、実際にトップレベルでのinclude禁止するCop書いたら、他のユーザーからCopがバグ発見に役立ったなどSNS経由で感謝された話があったり、OSSならではの良さがありますね…。
Rubocopは実はプレリリースという概念がないらしく、どういう運用しているかと言うと、リリースした後false negativeの報告飛んでくるのでそれを全力で次のリリースで直す、らしいです。
結構ロックですね…。
Scaling Teams using Tests for Productivity and Education
Scaling Teams using Tests for Productivity and Education – RubyKaigi 2018
プロジェクト内の規約とかをテストでチェックしようという話でした。
実際にユニットテストのファイル名と実装のファイル名が対応しているかなどや、入れないことにしているGemが入っていないかなどのチェックをしているらしいです。。
Linter的ではなくテストとして書いているのは、手続き的に書けるからなのでしょうか？
現実的にプロジェクトの規約をSpecとして落としていくのは非常に面白かったです。
「新しいエンジニアがプロジェクトに入るとき、学習できるような情報をエラーメッセージで与えるようにする」ことをJIT Educationと呼んでそれに取り組んでいる話もありました。初学者がハマりやすい、gem install 時のC拡張のコンパイル時のエラーもわかりやすくするために、 jules2689/extended_bundler-errors を開発したそうです。
今回の発表の様子が、Youtubeにアップロードされています。僕も復習のため見る予定です。
Ruby Programming with Type Checking – RubyKaigi 2018
Ruby Programming with Type Checking – RubyKaigi 2018
Steepの発表でした。デモシーンでは会場が湧いていて、みんなStatic Type Checkerを心待ちにしている様子です。
StripeのSorbetとも早速比較されていて、こちらは純Ruby製なので遅いのが課題だけど。
SorbetのNominarl Typing(名称あってるか？)よりもSteepのStructual TypingがRubyの文化としてはあっているかなと思いました。
個人的には型注釈は同一ファイルに書きたい派なので、別ファイルに書くのはどうなんだろうと思うところもあるのですが…。
とはいえ、現実的なStatic Type Checkerが出てきているとRubyでもついにGradual Typing出来る時代が…と感じてワクワクします。
RNode with code positions – RubyKaigi 2018
RNode with code positions – RubyKaigi 2018
RubyのRNodeに位置情報(列情報)に追加した話でした。途中のtokenizerやast、bytecodeあたりを全部拡張したらしいのでかなり大変そうですね…。
この変更でエラー時に行数しか出していなかったのをより詳細な情報を出せるそうです。
(例えば some_object.message.message のようなコードだと "NoMethodError: undefined methodmessage’ for nil:NilClass”と出てもどのmessage` が原因かわからなくて困るのですが、列情報が分かればより親切なエラーが出せるので便利そうですね。)
他の拡張のアイデアとして、単にnodeの最初と最後の位置を取るだけでなく、 method (arg1, arg2) などの途中の括弧の位置なども取れるようにしているそうで、 parser gem にもある機能ですが、色々な用途があるので実現すると便利そうです…。
あと、内部で使っていたASTモジュール (RubyVM::AST) というのを、直前にリリースされた Ruby 2.6.0-preview2 で使えるようになったのと告知がありました。公式のASTモジュールは最新のサポートが得られやすいなど便利そうなので使ってみたいです！
Type Profiler: An analysis to guess type signatures – RubyKaigi 2018
Type Profiler: An analysis to guess type signatures – RubyKaigi 2018
RubyでType Checkするための既存のアプローチ(plum-umd/rdlなど)を振り返りつつ、既存のコードから型を推測するためにいろいろ試している話。
TypeDB構想など、去年のJetBrainsの方の発表(Automated Type Contracts Generation for Ruby – RubyKaigi 2017)を彷彿とさせる構想など、興味深い話がいくつかありました。
Party 
初日とは違い、様々な企業が主催しているパーティが各地で開かれていました。
自分はRubyKaigiで刺激を受けてめっちゃコードが書きたい状態だったので、RubyKaigi 2018 コード懇親会に参加しました。
色々なテーマごとに分かれて(Language Serverにしたら1人 
)交流したりしながら開発を進める感じでした。
隣の人が、Opalを使ってRubyで書ける、Hyperappに近いクライアントサイドフレームワークの作者でその話で盛り上がったりしました 
※写真はRubyKaigi Chief Organizer/Ruby committer のAkira Matsuda氏と一緒に参加した@minakawa-daiki
6/2
The Method JIT Compiler for Ruby 2.6 – RubyKaigi 2018
The Method JIT Compiler for Ruby 2.6 – RubyKaigi 2018
k0kubunさんからのRuby 2.6に導入予定のMJIT(MRI JIT)の話。
MJITが生成するのはCのコードで、そのコンパイル自体はCコンパイラに行わせるという設計のようです。
Railsへ適用すると遅くなる問題を調査するために、プロファイリングを取ったり、取り組みが見える感じで非常に興味深い発表でした。
C実装のコードからRuby実装のブロックを呼び出したときに遅いので、C実装をRuby実装に置き換えると高速化したという話もとてもおもしろかったです。
“C Language is Dead”というパワーワードが飛び出したりしましたが
ちなみに、当時はRailsに適用すると逆に遅くなる問題ですが、その対策を行ったようです。Stable Releaseが楽しみですね！
RubyのJITに生成コードのメモリ局所性対策を入れた話 – k0kubun’s blog
TRICK 2018 (FINAL) – RubyKaigi 2018
TRICK 2018 (FINAL) – RubyKaigi 2018
超絶技巧プログラミングと呼ばれている(?)ジャンルのコンテストをRubyKaigiで開いて、応募があったプログラムや受賞したプログラムの紹介がありました。
Qunieとかのプログラムは目にしたことがあったのですが、まさに超絶といった感じのプログラムのオンパレードですごかったです。
予約語だけで作られたプログラム、pngをアスキーアート化するプログラム(プログラム自体もPNG VIEWERというアスキーアートになっています！)、単なるfizzbuzzのプログラムに見えて、実は見た目とは全く違う挙動をするプログラム(でもやっていることはfizzbuzz)みたいなプログラム…などおもしろプログラムがガンガン登場するのでぜひ動画見てみてください 
詳しくはYoutubeから。
Closing
コードを書いた話だけ、ソフトを書いた本人からの発表だけをアクセプトしたらしく、それ以外はリジェクトしたらしいです。
(Railsまったくなかったというようなことは言っていましたが、故意にRailsまわりrejectしたかまではわからなかったです。)
After Party
参加しました。RubyKaigi 2018 After Party
終わりに
Closingでも話がありましたが、RubyKaigiではコードを書いた本人からの話に絞られているというのもあって、
コードの意図や試行錯誤を感じる発表が多いのが非常に面白く、この3日間、パーサーが絡む話が非常に多かったのもなかなかない体験でした！
色々な人とRuby話ができたというのもあって、非常に楽しかったです！来年は福岡開催だそうです。来年も楽しみですね！
Rubyに関する投稿 on @Qiita は こちら
Incrementsでは、一緒にQiitaとQiita Teamを改善したいエンジニアを募集しています！
まずは気軽に、一緒にランチを食べませんか。
興味のある方は こちら 💁
Increments
Incrementsは、「エンジニアを最高に幸せにする」をミッションにしているスタートアップです。エンジニアの方々が幸せに開発できるために、エンジニアの方々が嬉しいと思ってくれるために、私たちはソフトウェアの開発に取り組んでいきます。
Qiita
Qiitaは、知見を共有しスキルを高めることができる、プログラミングに特化したオープンな情報共有コミュニティです。
Qiita Team
Qiita Teamは、チームの生産性を高めるために開発された社内向け情報共有ツールです。チームメンバーが簡単、気軽に情報を書き込んで、それが適切なメンバーと共有され、共有された内容について活発にコミュニケーションを取ることができるサービスです。
Qiita Jobs
Qiita Jobsは、エンジニアに特化した転職支援サービスです。会社ではなくチームを探す。採用担当ではなくチームメンバーと話す。人事ではなく自分が配属チームを決める。Qiita Jobsはあなたに最適なチームで最高の仕事をするきっかけを提供します。