見出し画像

RubyKaigi 2024 参加レポート

MICIN公式note「MICINの邁進Days」

株式会社MICINでエンジニアをしているmasatomotyです。

2024年5月15日〜17日に「那覇文化芸術劇場 なはーと」で開催されたRubyKaigi 2024に現地参加してきました。この記事では個人的に印象や記憶に残った発表をいくつかピックアップして紹介します。


発表・セッションのサマリと感想

Embedding it into Ruby code

発表サマリ

  • 型定義を記述するため.rbと対になる.rbsファイルが必要

  • ファイル分割のメリット

    • ファイルが分割されることで.rbファイルとのコンフリクト考慮が不要

    • .rbsファイルを読むことで実装の外観が掴みやすくなる

  • ファイル分割のデメリット

    • 開発中に2つのファイルを行き来しないといけない

    • 2つのファイルになる分，更新の手間が増える

    • PRに.rbsファイルが上がってこないケースも発生する

  • 上記のデメリットを解決するためにRBS::Inlineの開発を進めている

# rbs_inline: enabled

class Person
  attr_reader :name #:: String

  attr_reader :addresses #:: Array[String]

  # @rbs name: String
  # @rbs addresses: Array[String]
  # @rbs returns void
  def initialize(name:, addresses:)
    @name = name
    @addresses = addresses
  end

  def to_s #:: String
    "Person(name = #{name}, addresses = #{addresses.join(", ")})"
  end

  # @rbs yields (String) -> void
  def each_address(&block) #:: void
    addresses.each(&block)
  end
end

  • Rubyコード内にコメントアウトでRBSを記述（上記が一例）

$ fswatch -0 lib | xargs -0 -n1 bundle exec rbs-inline --output

  • 上記のコマンドでファイル保存時に.rbsファイルを生成

  • steepを使えば自動で更新も可能

  • ただし制約も多い

    • IDEのインテグレーションがない

    • エラー検知に未対応

  • シンタックスについても試行錯誤していて，まだまだ変わる可能性がある

  • 構造体については今後も対応しない予定

感想
sorbetの導入を進めていることもあり、社内でも関心の高いセッションでした。発表内でも言及があったように「型ファイルを.rbと分けて実装するのは正直辛い」が，弊社エンジニア内でも賛成多数です。この形式での実装は個人的にもメリット・デメリットを比較しても，まだデメリットの方が大きいかなという感覚です。

一方でRBS::Inlineであれば，ファイル間のスイッチが不要で，.rbsファイル更新の手間が発生しません。Twitterでも何人か呟いていましたが，インラインでの記述はGitHub Copilotとの相性も良く，開発者体験が大幅に向上しそうな印象を受けました。

RBSのRubyコードへの埋め込みについては，Day3の「Ruby Committers and the World」セッション内でも，会場参加者による挙手投票が行われました。

1) # @sig size: Integer vs # @rbs size: Integer

2) # @rbs returns void vs # @rbs return: void
   # @rbs yields (String) -> void vs # @rbs &: (String) -> void

3) # @rbs item : Item -- The item to be added
   # @rbs size : Integer -- Size of the item
   # @rbs returns bool --
   #   Returns true if the item is successfully added

   vs

   #: (Item item, Integer size) -> void

私は以下に投票しました。会場の過半数は※
1) 右 - ※右
2) 左 - ※右
3) 下 - ※下

1)では明確に@rbsが優勢でしたが，2, 3についてはそこまではっきりとは意見が分かれてなかった印象です。3についてはcommiterの意見としてケースバイケースになりそうとのことです。このような議論からもRBS::Inlineがこれから盛り上がっていくために，シンタックスの方針決定がプロジェクトの成否を決める分岐点になりそうだなと思いました。

issueを見る限り，まだまだコメントやフィードバックが少なそうなので，今回のRubyKaigiをきっかけに議論の活性化も期待したいところです。

The state of Ruby dev tooling

発表サマリ

  • 大半の言語で開発ツールは断片化（fragment）していて，統合されているのはGoとRustぐらい

  • RustやGoではtest, lint, lspが標準で組み込まれている

  • Rustではツールの組み合わせが1通りに対してRubyだと13,200通り

    • spec : rspec, minitest, test unit, etc

    • type : sorbet, steep, typeprof, RBS, YARD, etc

    • fmt, lint : rubocop, standard, RubyFmt, etc

    • lsp : SyntaxTreeLSP, Standard LSP, etc

  • Rust Analyzerのcontributerが816人に対して，同様のgemは6つありそれらのcontributorの合計は約603人

  • Rustはインストールがグローバルに行われてアップデートも容易，プロジェクト間の差も小さい。一方でRubyだとプロジェクトごとにgemや言語のバージョンも異なり運用が大変

  • 長い道のりになるがPrismではtype checker, linter, lsp, etcの統合を目指している

感想
個人的に今回一番印象に残った発表です。

自身でRubyのプロジェクトを立ち上げる際には，社内ですでに使われてるスタックを流用することが多く，今回ツールの組み合わせについて言及があって，ハッとなりました。

Rubyでツールに関する意思決定の頻度がRustとGoに比べて多くなるという点は，スピードと精度を求められる開発現場においては少しでも減らしたいなと感じます。特にスタートアップでのソフトウェア開発という文脈において，意思決定は一つ間違うと，その後の事業進捗やリソース配分に多大な影響をもたらします。例えば「一気にエンジニアの数を増やして開発速度を上げたい」，「超短期的に集中して開発プロジェクトに入ってもらいたい」というシーンがあったとします。迎え入れる側の開発環境がクセ強めな状態では，ローカルでの開発環境構築・プロジェクトの理解に時間がかかり，大きなロスが生じます。

Rubyは言語としての哲学やコミュニティの文化で「自由」を重んじるため，ツールの選択肢が発散する傾向は，これからも避けては通れない道ではあると思います。ただコミュニティ全体として，Rubyに関する開発環境の差異をできるだけなくし，Rubyistがどんなプロジェクト，どんな会社にいってもシームレスに活躍できる環境を整えるのは，Rubyが持続的に発展していく上で欠かせない取り組みだと感じました。

現状だとShopifyのRuby Infrastructureチームがruby-lsp，Prism，YJITといったプロジェクトを通じて多大な貢献をしてくれています。しかし，私たち一人一人のRubyistもその貢献に甘んじることなく，コミュニティ全体として標準的で，入門者にも熟練者にも優しさのある開発者体験を一緒に実現していけるといいなと思います。

Exploring Reline: Enhancing Command Line Usability

発表サマリ

  • IRBはRubyのデフォルトREPR

  • Relineとは

    • IRBの行編集エディタ（command line editor）

    • UNIX系システムにおけるCLIでのテキスト入力のためのライブラリReadlineのRuby版

    • IRBやdebug，pry/pryにも採用されている

    • bashで使われているGNU Readlineからの代替が目標

    • GNU Readlineからスイッチするにあたり，開発者が気づかないほどシームレスな移行の実現を目指している

    • irb上でcompletion, dialog, cursor等を提供

  • command line editorが無い世界線

    • カーソル左方向ボタンが^[[Dという文字に変換される

    • このようなキーバインドを直感的な操作に変換するのがcommand line editorの役割

  • このようにGNU Readlineに実装されている機能をRelineに実装する必要がある

  • GNU Readline対比で設定できるキーバインド数の比較

    • Variables：26%

    • Editing commands：44%

  • GitHub上にアップされた6,600の.inputrcを解析して対応するコマンドの優先づけを行なった

  • Relineの実装手順についてUndoコマンドを例に実演

感想
OSSではないですが，以前に社内プロジェクトでiPad向けのキーボードUIを実装したことがあり，非常に親近感のある発表でした。
私も普段の業務や開発で，以下のようなエディタやCUIを使っています。

  • メモ書き：Sublime Text

  • Code Writing：VSCode + vim-plugin

  • シェル操作：zsh

  • データ確認：rails console

これらのエディタ・CUIを行き来していると，時々ctrl-aやctrl-eでの文頭文末への移動や，deleteボタンが上手く動作しない場面に遭遇します。私の場合は日々使っていると慣れてしまって，あまり気にしない性質なのですが，Undoコマンドのように標準的なキーバインディングが実装されてスムーズにCUI操作ができると，日々の幸福度が高まります。Relineではこんな細やかな体験を，私たちが意識することもなくスムーズに実現してくださっていて，発表を聞いていて感謝の気持ちが溢れてきました。

RubyKaigiの数ある発表の中でも，Relineは直感的な理解がしやすいプロジェクトに感じたので，タイミングを見てコードリーディングやcontributeもしていけると良いなと思います。

託児サポートの利用

今回のRubyKaigiは2歳の娘を連れていったため，STORESさんがNursery Sponsorとして提供してくださった託児サポートを利用させていただきました。

今回，沖縄には私と娘が5/14（火）に到着し，妻が5/16（木）から滞在しました。妻に娘を任せて東京でいつも通ってる保育園に預けるという選択肢もありましたが，各々の負担を考えた時に，私と娘で先に沖縄に来て，託児所を利用させていただいた方がトータルで見て楽かなということで，娘を預けさせていただきました。

保育園と実家以外で子供を預けるのは初めてだったこともあり，少々不安もあったのですが，大きな問題なく3日間過ごすことができて本当にありがたい限りでした。

  • 託児所は事前申し込み制。期限が開催日の1ヶ月半前までだったので，使いたい場合は早めのチケット購入が必須

  • 費用は無料！

  • 事前対応はフォーム入力とメールで案内が来たエクセルの記入の2回のみ

  • 5歳〜12歳はDay2に美ら海水族館のアクティビティに参加可能（私の娘は2歳なので対象外でした）

  • 預け入れはRubyKaigiのイベント開始1時間前〜終了後1時間ぐらいまで

  • 会場はイベント会場から徒歩5分ほどの場所。3日目だけ10分ほど離れた場所でした。

  • 今回は多分15人ぐらいの子供が託児所にいたはず

    • 年齢は0歳？ぐらいから小学生高学年までかなりバラバラだった印象

  • おむつや食事は準備が必須

    • 旅先で自炊してお弁当作るのは難しかったので，コンビニで子供が食べそうなものをお昼に買っていき一緒に食べました。

    • 普段は自炊や保育園が中心でコンビニで昼ごはんを済ませることがなかったので，娘が食べれそうなものを買っていくスタイルをとりました

    • 私以外にもお昼休憩のタイミングで何人か様子を見にきたり，一緒にご飯を食べてる親御さんもいました

  • 妻がDay2の午後から沖縄に来ていたので，2日目と3日目は全日利用ではなく，お昼過にお迎えするというスタイルを取らせていただきました

  • Day3に託児所に忘れ物をしていたのですが，会場までSTORESのスタッフさんが届けてくださりました。ありがとうございます

娘は慣れない環境だったこともあり，初日のお迎えのタイミングや翌日送っていったタイミングで大泣きしてしいたのですが，そのあとはすぐに泣き止み，託児所にあったおもちゃは全コンプリートするぐらい楽しく遊び，お昼寝も数時間できていたようです。

振り返り

RubyKaigiは一つ一つの発表の密度が非常に濃く，これ全部は一生消化できないのでは？と思えるぐらいのボリュームがあります。

毎日並行して3セッションの発表があったことも考えると，自分が見てないだけでも2.5~3倍のコンテンツ量があり，振り返りも一苦労です。今回この記事を書くにあたっても，自分がSlackに残していたメモだけでなく，

  • Twitter上の#rubykaigiハッシュタグでの実況

  • Helpfeel Cosense（旧Scrapebox）でのまとめ記事

  • 発表者がSpeaker Deckにアップロードしたスライド

などを参考にして内容をまとめています。

本当は以下のような発表についても本記事内で言及したかったです。

  • 今回のRubyKaigiで間違いなく一番勢いがあったパーサー関連の発表

  • Quine（奇妙なコード）

  • 圧倒的な高速化（1.8x）を実現しているYJIT

  • 引数に関する細かなパフォーマンス最適化

  • 非同期処理や並列・並行処理の機構に関する発表

  • etc

ただ，内容が深すぎて理解が及んでいなかったり，記事にまとめるのに時間がかかりすぎるため，部分的にピックアップする形にしました。（それでも記事を書くのに数時間費やしているが….）

来年は4月16日〜18日@愛媛県松山で開催とのことで，それまでには今回記事で触れられなかったような領域について一つでも理解を深めて，次回も現地参加できればと思います。

運営の皆様ありがとうございました。来年もよろしくお願いします。