No day younger than today

RubyとかRailsとか蒙古タンメンとか

gem_rbs_collection に新たなテストが追加された

5 日ほど前に以下の PR がマージされました。

github.com

これまで型定義のテストとして gems/GEMNAME/VARSION/_scripts/test を実行すると steep check と rbs validate が実行されていましたが、新たに bin/check-untyped-call.rb も実行されるようになりました。CI でも同様に実行されます。

新しいテストが何をテストしているのかというと「untyped call がないか？」です。untyped call は steep stats 実行時に出力されるもので、これが 1 以上だと警告を出力するようです。

$ steep stats
# Calculating stats:

 Target  File       Status   Typed calls  Untyped calls  All calls  Typed %
----------------------------------------------------------------------------
 test    test.rb    success            3              5          8      37%

untyped call がどういう条件で計上されるのかは Steep のコードを少し追ってもわからなかった（誰か教えてください…🙏）のですが、おそらく「untyped なレシーバーに対するメソッドコール」を計上しているのではないかと思います。

PR に記載されている例を抜粋すると

# rbs
def f: () -> untyped

# ruby
f.something # <- untyped call

みたいなコードに対して警告を出します。なぜなら f が untyped だからです。

f が untyped だと（型上は）なんでも呼び出せてしまいます。たとえば f が String だとして、以下のようなコードは明らかに間違っていますが従来のテストでは検知できません。

f.qawsedrftg

# rbs が正しく定義されていれば検知できる
def f: () -> String

# ruby
f.qawsedrftg  # <- NoMethod

ぼくも やってしまったことがあるのですが、せっかくテストコードを書いても意味がなくなってしまうため、自動で検知できるようにするため今回のテストが追加されたようです。今後はテストスクリプト実行時に untyped call が steep stats コマンドによって検知されると

5 method calls with untyped receiver detected from test.rb. Please assign the expected type to the receivers

といった警告が表示されるようになりました。

Kaigi on Rails 2022 感想記【後編】〜Organizer 編〜

こんにちは、ふーが です。

Kaigi on Rails 2022 が終了して 1 週間以上が経ち、いつの間にやら 11 月になっていました。月日が経つのは早いですねぇ、あっという間にアドベントカレンダーの時期が来て年を越して、RubyKaigi 2023 の CFP 募集も始まってしまう…！

さて、Kaigi on Rails 2022 終了直後にブログを書きました。 fuga-ch85.hatenablog.com

こちらはスピーカーとして登壇させていただいた感想をメインに書きました。今回は、Organizer として運営に携わったことについて書きたいと思います。
今年から Organizer として関わらせてもらっているため、初めてカンファレンス運営に関わってみての視点で書いていきます。

きっかけ

ぼくは フィヨルドブートキャンプ というプログラミングスクールの出身なのですが、そこの卒業生であり Kaigi on Rails Organizer でもある ちろる さんからお声がけいただいたのがきっかけです。当時、一緒に輪読会をしていてそのよしみで誘ってくださったのだと思います。

ただ当時ぼくが絶賛転職活動中だったこともありすぐにはお返事できず、転職活動が終わってから正式に参加させてもらう形で参画しました。なのでたしか今年の 2 月くらい？から正式に迎え入れていただいたと思います。

主な仕事内容

Kaigi on Rails チームでは明確な役割分担がほとんどされていません。どんな仕事があるか記憶にある限り書き出してみると

  • スポンサー企業様とのやり取り
  • Web サイトまわり
  • cfp-app まわり
  • sponsor-app まわり
  • スポンサーブースのもろもろ
  • CFP 採択
  • スピーカーへの案内、対応
  • 配信まわり
  • お金まわり
  • 託児サポート
  • Twitter 運用
  • プレイベント

などなどです。

配信やお金関係はやる人が固定化されている感はあるものの、その他はできる時にできる人がやりましょう！というスタンスでした。
Chief Organizer の大倉 さんが「カンファレンス運営は趣味でやっている」と公言（？）しているとおり、チーム全体として無理なく楽しくやっていこうぜ！という雰囲気です。

会期中のこと

上記は会期が始まるまでの準備期間にやっていた内容で、会期中は会期中で役割分担をして運営をしていました。こちらも記憶の限り書き出してみると

  • 配信
  • Twitter 巡回
  • スポンサーブース対応
  • YouTube のコメント管理
  • スピーカーの呼び込み、案内
  • トラブル対応
  • 司令塔

などなどです。

オンライン開催のため Organizer がどこかに集まって…ということはなく、それぞれ自宅から Discord のボイスチャンネルに繋いで業務連絡をしつつ、それぞれの担当をこなしていく、という感じで進めていました。

ぼくは YouTube の映像・音声チェックやコメント管理を担当しました。

終わってみて

今回初めてカンファレンスの運営側として参加してみての感想です。

反省

一番反省というか後悔しているのは「様子見期間が長すぎてあまり力になれた実感がないこと」です。

前述のとおり明確な役割分担がないため、会期を終えた今だからこそどんな仕事内容があるのかがわかりますが、参画当初はその辺もわからなかったし自分がどんな立ち居振る舞いをすれば良いかもわからず、だいぶ長いこと様子見をしてしまっていたなぁと思います。あとは RubyKaigi や Kaigi on Rails で登壇させてもらえることになり登壇準備で余裕がなくなってしまったのも理由の一つです。「自分がいる意味あるんだろうか」という気持ちになっていました。ぼくがいなくても Kaigi on Rails は開催されるだろうし、Organizer として関わる意味を見失っていた気がします。

RubyKaigi 2022 が終わって一息ついた頃、少し余裕ができたこともあり改めて自分が Kaigi on Rails に Organizer として関わる理由ってなんだっけ、と自問してみて思ったのは「Organizer をやる意味がわからなくっているのは自分が何もしていないからでは？」と気付きました。大した努力も苦労もせずに「やる意味がわからない…」だなんて、なんておこがましいんでしょう。

そう思ってからは、できることは積極的にやっていくようにしました。気づくのが遅かったせいで具体的な行動ができたのは少ないですが、来年はもう少し能動的にいろいろできるようにしたいと思っています。

よかったこと

Kaigi on Rails 2022 が終わった後、スポンサー企業の方、スピーカーの方、参加してくださった方、たくさんの方からの「楽しかった」「良いカンファレンスだった」「勉強になった」というお声を目にしました。何よりもこういった感想がうれしいです。

また、Organizer として携わったことで自分の”軸”を再確認できたこともよかったです。
これについては後述します。

来年に向けて

反省に書いたとおり来年はもっと能動的にやっていきたいと思っています。
具体的には、ぼくはやはりコードを書いたり技術的な部分で関わっていきたい気持ちが強いので、Web サイトや cfp-app、sponsor-app あたりはメインで触っていきたいところです。

あとは配信周りにも興味があるので、その辺りの知識も蓄えていきたいお気持ちがあります。

クロージングで話があった通り、来年はオンラインとオフラインのハイブリッド開催を目指していることもあり今年以上に（作業量的にも精神的にも）大変そうではありますが、楽しんでいただけるカンファレンスになるようにがんばります。

自分の想い

「よかったこと」のところに「自分の "軸" を再確認できた」と書きました。
この "軸" というのは「Ruby や Rails のコミュニティを盛り上げることにやりがいを感じる」というものです。

完全に持論で何の数値も根拠もないことですが、ぼくは「コミュニティの熱量と技術の衰退は相関関係がある」と思っています。つまりコミュニティが盛り上がっていればその技術が廃れる可能性は低いだろうということです。

ぼくは Ruby や Rails が大好きです。今後もこの技術を使ってお仕事をしていきたいです。そのためにも Ruby や Rails に廃れて欲しくないしそのためにできることは微力でもやっていきたいという想いがあります（というような話をはじめて Kaigi on Rails チームの皆さんとお話ししたときにも伝えた気がする）。

「できること」は人それぞれだと思いますし方法もさまざまだと思いますが、ぼくにとっては Kaigi on Rails の運営に関わることはその一環です。Kaigi on Rails という場を通じてコミュニティの活性化であったり、技術的な進歩であったり、ビジネスとしての成功であったり…といったことに、直接的にも間接的にも寄与できるものと思っています。

ぼくの活動の原点はこれなので、この気持ちはこれからも忘れずに持ち続けていたいし、Kaigi on Rails がそういう場であり続けるために自分にできることをし続けていきたいです。

おわりに

そんなわけで来年もやっていきます！
改めて Kaigi on Rails に関わってくださったすべての皆様に感謝申し上げます。来年もよろしくお願いします。

Kaigi on Rails 2022 感想記【前編】〜スピーカー編〜

こんにちは、ふーが です。
10/21 - 22 で Kaigi on Rails 2022 が開催されました。楽しかったですね！

今回ぼくはスピーカーとして登壇させてもらい、オーガナイザーとして運営にも携わりました。それぞれの視点での感想を前後編にわけて書きたいと思います。

発表内容

ぼくは今年の 3 月に異業種からエンジニアに転職して、エンジニア歴としては 8 ヶ月くらいのいわゆる "newbie" です。
そんなぼくが入社 2 〜 3 ヶ月目くらいの時期からプロジェクト（稼働 7 年長の Rails アプリケーション）に型の導入をし始めました。当時は「型があることによる開発体験を Ruby でも感じたい」「興味があるのでどんな感じなのか試してみたい」という気持ちで始めたのですが、進めていると "newbie 目線" でさまざまなメリットがあることがわかってきました。
プロジェクトに参画したとき、newbie には newbie なりの苦悩があるのですが、型の導入はそれらを解消する一助となるものだったのです。

同じように苦悩している newbie がいるならばぜひ型導入をやってみてもらいたいと同時に、newbie の独断で型を導入することができないと思うので実際の運用面も含めたチームへの提案方法の一例を紹介したりしました。登壇資料は以下です。

speakerdeck.com

ご視聴くださった皆さん、採択してくださった運営メンバーの皆さん、レビューしてくださった同僚の皆さんありがとうございます。

登壇裏話

発表の冒頭でぼくがプロジェクトに型を導入することになったきっかけとして「EM である @koic さんに背中を押してもらって導入を進めることになった」というお話をしました。
実はこのとき、同時に「導入する過程などを Kaigi on Rails で話せるといいよね。newbie が導入を進めた、という話は今のふーがさんにしかできないので。」ということも言っていただいていました。これぼくにとってすごく大きくて、興味のある分野に挑戦させてもらった上でその成果を Kaigi on Rails という大舞台で発表できたらそれほどうれしいことはないなとすごく胸が高鳴ったのを覚えています。

そんなわけで CFP 募集が始まる前からぼくの発表したい内容はおおむね決まっていて、まさにこのとき話したような「今のぼくだからできる発表」ができたのではないかと自負しています。来年もまた "最新の自分" で自分にしかできない発表をできるように 1 年がんばっていこうと思います。

さらに裏話

今回の登壇資料のスライドに以下のようなスライドがあったのに気づいたでしょうか。

このスライドはぼくが所属している永和システムマネジメントの伝統芸（？）で、@kakutani さんがオリジナルを作り、それを @koic さんが受け継いで使われていたとお聞きしました。前日にあった会社のオンライン飲み会でこのスライドの話になり「"提供" スライドを使ってみたい人生だった」と発言したところ、@koic さんが素材をくださったのでさっそく今回の登壇資料で使わせてもらったのでした。
特に使うのに資格が必要とかいうわけではないと思うのですが、なんとなく永和の一員として認めてもらえた気がしてうれしかったです（きもちの問題）。

懇親会とか

今回は休憩時間に SpatialChat で用意されたスポンサーブースで Ask the speakers area が用意されていたのですが、登壇後にそこで同じく型の導入のお話をされた しゅん さんとお互いの導入の状況だったり困りポイントだったりをお話しできてうれしかったです。
After Party ではフィヨルドブートキャンプの卒業生とお話しできたり、刺激を受けたセッションのスピーカーに直接感想を伝えられたりしたのも楽しかったです。
あとはご本人と「やんちゃクラブ」を一緒に視聴するという貴重な経験もできました。
心残りは Asakusa.rb のパブリックビューイングに参加したかったなぁ…というところですが、スタッフ業もあったためまたの機会を楽しみにしておきます。

そんな感じで自身の発表も含め 2 日間楽しく過ごしつつたくさん刺激をもらったカンファレンスでした！運営の皆さん素敵なカンファレンスをありがとうございます。

gem_rbs_collectionでジェネレーターが推奨されなくなった

こんばんは、ふーがです。

gem_rbs_collection は gem の型定義が集約されているリポジトリですが、まだまだ型定義されている gem が少ないこともあり「型やっていくぞ！」という人々が一生懸命パッチを送っていたりします。
その際、rbs prototype などのコマンドで Ruby コードから型定義を自動生成することができるのですが、これが推奨されなくなりました。正確に言うとジェネレーターによる型生成を推奨しないことが主題ではなく、「必要な API の型定義に注力することを推奨するようになった」という感じです。

詳細は以下の Pull Request で確認できます。

github.com

要約すると、

ジェネレータは便利ですが、生成された型定義は使い物にならないことがあります。自動生成するよりも、主要な機能について RBS を手書きする方がより価値のある型定義になるのではないか。

というようなことが書かれています。

実際、僕も何度かジェネレーターで生成した型定義のパッチを送ったことがありますが、一気に自動で生成できて便利な反面、よく知らない（自分が使っていない）API の型定義の正当性がわからない、テストが書けない、などは感じていたところであります。

「ジェネレーターを使わないで、ということではない」とも書かれているのでまったくの非推奨というわけではなさそうです。
が、書かれている理由は確かにその通りだなあと思ったので、今後はジェネレーターを使わず自分が必要となる API について丁寧に型とテストを書く方がよさそうだなと個人的には思っています。

ところでなぜ僕がこの記事を書いたかというと、先月に開催された RubyKaigi 2022 で gem_rbs_collection へのコントリビュート方法について発表し、発表の中でジェネレーターを使ったコントリビュート方法を紹介していたからです。

speakerdeck.com

この方法でコントリビュートできなくなったわけではないのですが、状況が変わったということは記しておいた方がいいかと思い書いた次第です。

RubyKaigi 2022 に参加 & 登壇した

9/8 - 10 に三重県津市で開催された RubyKaigi 2022 に現地参加し、登壇してきました。
記憶の新しいうちにいろいろ思ったことや感じたことなど書こうという感じです。

登壇について

なんとありがたいことにプロポーザルを採択していただき、登壇させてもらいました。
プロポーザルの概要は以下から見れます。

rubykaigi.org

話したこと

ざっくり言うと「Ruby の型を導入しているプロジェクトはまだ少なそうですよね。多分 gem の型定義が少ないというのも導入しづらい要因の1つだと思うので、gem_rbs_collection にコントリビュートしませんか？コントリビュートまでのステップをお話するので！」的な感じです。
発表資料はこちらです。

speakerdeck.com

@_risacan_ さんがグラレコしてくださいました。
めっちゃきれいでみやすい！ありがとうございます！！
他のセッションについてもまとめていらしてとてもわかりやすかったので、ぜひ見てみてください。

また、Wantedly さんが RubyKaigiまとめブログ。初日KeynoteからRuboCop, Mega Driveの話まで | Wantedly Engineer Blog を公開されており、こちらで僕のセッションについての記事も掲載していただいています。
とても詳しく書いてくださってありがとうございます！

www.wantedly.com

感想

月並みですが本っ当に楽しかったです。自分の好きな分野について 30 分も人前で語れる機会なんてそうそうないですし。
圧倒されるくらい多くの方が来てくださったこと自体うれしかったですし、皆さん型への興味をお持ちだということがわかったのもうれしかったです。

また、Steep や gem_rbs_collection のメンテナの方々も見てくださっていたようで、あとでチャット欄を見たら僕の話を先読みしていて（ネタバレともいうw）さすがでした（ありがとうございます！）。

うれしいことづくめで本当に登壇できてよかった！
見てくださった皆さん、応援してくださった皆さんありがとうございました。

RubyKaigi に初参加した

オフラインの RubyKaigi は今回がはじめての参加でした。
昨年はオンラインでの視聴だったのですが、オフラインの良さを知ってしまったので来年も間違いなくオフライン参加します。

セッションを間近で見れた

大きなスクリーンと立派な演題で話す話者を前にセッションを見れたのがよかったです。
時には笑いが起こったり、拍手が起こったり、一体感がよかったなあ。

前の方の席で見るの、おすすめです。特に Trick。

Ruby Friends がたくさんできた

やはりセッションの合間に Rubyist の皆さんと交流できるのが本当に楽しかった。
オンラインだとどうしてもセッションだけを楽しむ形になってしまいます。オフラインだと少し歩けばフィヨルドブートキャンプの関係者、コミュニティでご一緒した方、憧れのコミッターの方、Matz さんとエンカウントしてお話ししたり写真を撮ったりできます。
この体験が最高すぎて、会期中に退屈することは 1 分たりともなかったです。

ほかにも僕のセッションを聞いてくれた方が話しかけてくれて感想を言ってもらえたり、豪華なお弁当が用意されていたり、たくさんのノベルティをゲットできたりと「これが RubyKaigi か…！」と感じられることがたくさんありました。

今回は様々なご事情で現地参加できなかった方もいらっしゃると思うのですが、来年はぜひ現地でお会いできたらうれしいなと思います。

俺の Kaigi Effect

たくさんの刺激を受けたのですが、強く感じるのは「やっていくぞ！」というモチベーションがめちゃくちゃ上がったことです。
具体的にはまず RBS や Steep の内部構造を知っていきたい。その上で機能追加、改善などをできるようになりたい、という気持ちが大きいです。今の僕には大きすぎる目標かもしれないけれど、今のこの気持ちが "Kaigi Effect" なら大事にしたいですね。

その上でまた来年の RubyKaigi でもプロポーザルは出したい。プロポーザルを出す近道は手を動かしていくことだと思ったので、手を動かしていくぞ！

おわりに

まだ余韻が抜けきっていませんが、たくさん良い刺激を受けてもっと Ruby を楽しんでいきたいと思えた 3 日間でした。
また松本でお会いしましょう〜