元号が令和になりました。GW楽しんでいますでしょうか？ さて、10日以上過ぎてしまいましたが、4月18日～20日に福岡で開催されたRubyKaigi2019に参加してきましたのでそのことについて書こうと思います。
弊社からは私を含む3名が参加しまして、岡山から車で移動しました。道中は仕事のこととか話しつつ、大体6時間くらいで到着しました。
0日目
前日入りしたのですが、その日はLINE 福岡さん主催のLINE Developer Meetupに参加しました。
LINEさんのオフィスに行ってみたかったというのが主なところでしたが、監視に関する発表を聞き、懇親会ではElasticの大谷さん（@johtani）にご挨拶することができたのでよかったです。担当プロジェクトでElasticsearchを使っているのですが、困っているときにたくさんのアドバイスを頂いて助かっています😃ElasticStackを使った監視にも、かなり興味が湧いたので、個人のプロジェクトとかでやってみたいと考えています。
LINEさんの懇親会では寿司とピザが出てきて、イケてる会社の勉強会って感じでした。LINEの中の方とも多少お話することができまして、LINEはRubyはほとんど使ってなくて、バックエンドはJavaとKotlinと伺いました。なので、「あー、RubyKaigiあるんだなぁ」くらいの感じでした。
1日目
博多駅周辺にホテルを取っていたので、移動は3日間ともSmartHRさんがスポンサーをされていたシャトルバスで移動しました。これはとてもありがたかったです🙏
Ruby3について
Rubyの3x3に向けての取組について、Keynoteと途中経過レポートで聞くことができました。Matzは型を書きたくないので、型アノテーションのような仕組みは使いたくないとのことで、型プロファイルを行って型ファイル（拡張子はrbi）を自動生成するようにしたいとのことでした。2.6でMJITが入ってRubyの性能は上がったけれどRailsで遅くなったりと、なかなか高速化の道は難しそうです。あとは並行性を良くするための取組についてもありましたが、GuildやAutoFiberなど、既にありそうな名前と競合していて、名前付けも難しい…。
社内報告会をしたときに、「sorbetみたいに型アノテーションを書くことで、処理を手堅くしたいところだけでも使えたらすごくいいのにな」という意見もありました。
OpenAPI3について
OpenAPIはあまり詳しくなかったのですが、APIの話なので聞きに行ってみました。OpenAPI3はAPI Schemaファーストで開発をするための仕組みで、OpenAPI3でスキーマを定義すると、サーバサイド、クライアントサイドでの開発が捗るという話でした。
- OpenAPI3はRESTの拡張のため、既存の資産を生かせる。RailsはRESTベースなので導入しやすい。
- 実装にスキーマ定義を守らせるための仕組み(gem committee)を導入し、実装が乖離しないようにすることができる。
- openapi_parserを使って定義ファイルからRubyObjectに変換できる。
今ちょうどGraphQLを使ったAPI実装をしている最中なのですが、これを知っていたらOpenAPI3でもよかったかなという気持ちになりました。ただ、不要なフィールドを渡さないような仕組みがRESTだとないような気がしているので、やはり自分の利用にはGraphQLのほうが合ってたかなとは思います。
RMagickについて
Rubyistならほぼ誰しもがお世話になっていると思われるRMagickのお話でした。RMagickはRubyKaigi2019現在、最新は3.1.0となっていて、不具合をかなり潰したので最新のRMagickと最新のImageMagickを使ってほしいとのこと。今回は2系から3系に上げるときに行ったことについての発表でした。
とのことでした。MacでRMagickを入れようとすると、結構な頻度でエラーが起きていたのですが、homebrewで入れたImageMagickを検知してエラーを起きにくくしたということでした。Windowsも似たような感じだったかと思います。メモリの不具合に関しては、メモリリークが発生していたパターンの紹介や、ImageMagick自体のメモリリークの不具合を報告したりなどをされていたということでした。そのissueもcloseされて新バージョンがリリースされていたので、6系の最新のImageMagickを使うのがやはりよいそうです。
7系への対応は今年いっぱいくらいかかりそうで、6系と7系の対応をどうするかでメンテナで意見が分かれているけれど、1つのバージョンで6系、7系両対応のほうが優勢らしいです。
これもまた社内勉強会では、「メンテナが大変になるし、バージョン分けてもいいんじゃないか？」という意見がありました。
GraphQLについて
決済サービスのSQUAREでGraphQLを使ったという話だったのですが、メインどころの話はGraphQLの型定義が膨大な数に及ぶのでメタプログラミングした、という話のように思えました。方針としてはわからなくはなかったのですが、そこでメタプログラミングするとGraphQLの型ファイルドキュメントを作りにくいから微妙だなと感じました。せめて型定義ジェネレータを作るほうが筋がいいのでは？🤔
オフィシャルパーティー
オフィシャルパーティーは川端商店街を貸し切っての、400mの懇親会場で商店街を練り歩きながら好きなところでご飯や飲み物をもらって好きなテーブルで話をするという感じでとてもダイナミックなイベントでした。しかしこれがめちゃくちゃ良くて、普通の広い一間の懇親会よりも交流がしやすかったですし、外国人の方々は商店街でお土産を買うことができるし、オフィシャルパーティー終了後に近くの飲み屋に移動することも簡単なのでその付近にたくさんのお金が落ちるという仕組みで最高じゃないかと思います（運営の皆さんはそのぶん大変だとは思いますが！）
ふだんから人見知りの私ですが、いつもよりオープンな会場だったので、フォロワーの方とお話できたり、そのつてで大阪・京都界隈の方たちともお話できたり、以前に自分のgemにPRをしてくださった、はてなの@onkさんとお話できたのでよかったです。
2日目
2日目と3日目は会場で朝食が食べられるように、Medleyさんが朝食スポンサーをされていました。今回は朝食を会場でいただくことができて助かりました。明太子がおいしかった！
#rubykaigia 朝食頂きます！ pic.twitter.com/56ldEJO8H4
— パトラッシュ@RubyKaigi参加してました (@patorash) 2019年4月18日
Rubyの安定版のメンテナンス
Rubyの安定版のメンテナをされている@nagachikaさんのKeynoteでした。安定版のメンテナを募集とのことと、メンテナとして気を付けていることや失敗談などを共有してくださいました。こういう方々に支えられているのだなと、感謝しきりでした。
CrystalBall
テスターの方の発表でした。プロジェクトが大きくなってくると、テスト対象のファイルも膨大になり、テストにかかる時間も長くなります。それを、gitの変更点からテスト対象を絞り込んで該当しそうなテストのみを実行するという仕組みとしてCrystalBallを作ったということでした。
これはテスト戦略としてはとても素晴らしいと共感しました！変更点だけになれば相当なテスト時間を削減できます。ただ、全体テストが不要になるわけではないので、ローカルでテストを実行する場合はCrystalBallでテストを行い、CIに全体テストを任せる、ということなのかなと思いました。入れてみてもいいなと考えています。
フロントエンドフレームワーク Ovto
OvtoはhyperappをRubyで書けるJSトランスパイラーのOpalで移植したフレームワークです。発表者のyharaさんがDIYをするために作成されたとのことで、今回の発表はOvtoの2人目のユーザーを作るためとのことでした。「ちょっと最高のフレームワークができたので共有したくて」という感じで和やかに始まりましたが、私もOvto使ってみたいなぁ～と思いました。
フロントエンドをRubyで書く意味って？と言われそうですが、Rubyで書けたら面白いじゃん！と思うので、個人プロジェクトとかで試してみようかなと思います。 なお、Ovtoについては、るびまに記事が上がっています。
TruffleRubyでChrome DevToolsを使ったデバッグ
Chrome Devtools Protocolというプロトコルがあり、それを使うとChrome Devtoolsのデバッガを使ってどんな言語でもデバッグできるらしいです。私の解釈ですが、GraalVMで動作する言語であれば、Chrome Devtools Protocolを使うことができるのでデバッグが容易になった、ということだと思いました。RubyのオブジェクトがChrome Devtools上で見られるようにJSのオブジェクトにうまくマッピングされていてすごい！と感じました。
LT
LTはどれも面白かったのですが、印象に残っているのは、Unicodeと元号ライブラリの令和対応のやつでした。あとmrubyを搭載した人工衛星が飛ぶという話。
PRTimes Drinkupに参加
2日目はPRTimesさんが主催のドリンクアップに参加してきました。LT枠で申し込んでいたため、LTしましたが、プロジェクタの後ろのほうで話すことになったり、会場がガヤガヤしていてあんまり聞こえてなかったみたいでした😭しかし、それキッカケで話すことができた方もいましたし、やってよかったなと思います。いろんな方と話すことができて楽しかったです！PRTimesさん、ありがとうございました！
実のところ、LTするから緊張しすぎてあんまりご飯が喉を通らなかったため、終わってからとんこつラーメンを食べに行ってきました。やはり博多、めっちゃうまかったです。
あまりの旨さに替え玉してしまった。後悔はない。 pic.twitter.com/HrQR5FwY6l
— パトラッシュ@RubyKaigi参加してました (@patorash) 2019年4月19日
3日目
Committers VS the World
事前に集めた質問にRuby Committerさん達が答えてくれるという恒例のセッションでしたが、Rubyの進歩についてとか、記法どうする？とかの話題で面白かったです。マルチバイト文字（絵文字）で遊ぶやつ、いいですね～。
🍣 = Sushi.new
そして、大きなニュースとしては、Rubyのリポジトリがsvnからgitになるとのことでした。RubyKaigi後のやりとりを見ているとgitになってからのほうが大変そうでしたが、慣れるまでの時間だと…いいな…。
Numbered Parametersに関しては、私はGroovyやKotlinと同じくitがいいのですが、itはRSpecで使っているからという意見もあって、難しそう…。
(1..10).map { @1 * 10 } # 現在の候補は@1の模様 (1..10).map { it * 10 } # 個人的にはこれがいい
巨大なアプリケーションのコードのクリーンアップ
Cookpadの中の人による、成長したアプリケーションのコードの削除についてのお話でした。CookpadはRailsになって10年が経ち、削除した機能などがあるのだけれど、コードベースでは残ってしまっているものが多数あるとのこと。それを削除するための取組についてでした。
面白かったのが、使われていないコードをあぶりだすため、処理が実行されたらログを出すようにするのにRubyコミッターにRuby自身のコードに処理を仕込んでもらった、というところでした。これぞ、コミッターを会社で雇っている実践的な活用法ですごい！と思いました。自分的には「その発想はなかった！」と唸りました。
あとはoneshot_coverageという行単位で実行されたらログを出すやつも紹介されていて、よさそうでした。SimpleCov形式で実行結果がみられるのが便利そう。 これらの取組によって、CookpadのRailsアプリの起動が1.5秒改善されたとのことで、地道な改善は大事だなと思わされました。
WebAPIクライアント開発のベストプラクティス
今回のRubyKaigiで個人的に一番よかったのは@sue445さんの、この発表でした。
WebAPI Clientを作るための知見がめっちゃ詰まっていてとてもよかったです！👌WebAPI Clientの責務やどこまで面倒を見るか等は、ついついやりすぎてしまう場合がありそうなので、参考になりました！私もこれから担当製品のWebAPIとそのClientを作っていかなければなーと思っていたところだったので気を付けたいと思います。faradayを使ったことが多分なかったと思うので、今後はfaradayを使っていくようにしようと思いました。
dRubyワークショップ
なんとなく気になっていたdRubyのワークショップに参加。Rubyのオブジェクトを異なるプロセス間で受け渡して処理が実行できるという不思議さ…。うーん、本当に不思議。
「dRubyの本を読んでもわからないところがあったら、もう一冊買ってください」って言っててウケました😂
The send-pop optimization
@shyouheiさんのRubyの最適化のお話でした。Rubyは処理毎に必ず返り値があるのだけれど、必ずしもそれを利用することがないため、Ruby側で返り値を利用していない場合は返り値を返す処理を実行しないようにすれば速くなるのではないか？という仮定で取り組んだとのことでした。
ベンチマークの結果、遅くなる処理もあったけれど突出して速くなる箇所もあったとのことで、採用されたそうです（たしか）。しかし、Railsの起動には0.3秒程度遅くなったとのこと。返り値を使っているかの検証処理が挟まれたため、仕方がないのかもしれませんが、動き出したらトータルでは速くなるのかな～？と思います。
Keynote
データベース用のライブラリであるSequelの作者の方のキーノートでしたが、最適化の鬼という感じで「これはもうRubyである必要があるのか？？？」と思いながらも楽しく（？）見ていました。出てくるコードがすべてハチャメチャでした。
閉会
あっという間の3日間でしたが、とても楽しく、とても刺激的でした。次回は長野県の松本市とのことだったので、来年どうやって行こう？🤔と今から悩んでいます！運営の皆様、お疲れ様でした＆ありがとうございました！
全体を通して
我々はRubyというプログラミング言語と通して知り合い、そしてRubyKaigiで一同に集まり、ここで直接ご本人に会って感謝を伝えることができたりする貴重な機会でもあるので、人見知りだからといって恥ずかしがっているのはほんまに勿体ないなーとヒシヒシと感じました。今回は結構頑張ってお世話になっている様々な方にご挨拶できましたし、アフターパーティーにあぶれた人たちで集まって飲み屋さんに行って交流できたりもしたので、充実したRubyKaigiとなりました。
昼食の屋台や、コーヒーを頂いたり、スポンサーブースで色々お話できたことなど、本当にたくさん楽しませていただきました。新たな試みが多くて思わず人に話したくなるカンファレンスでした！
