Kaigi on Rails 2023を開催した

はじめに

いつものように、Kaigi on Railsの振り返りを年末に書くことになってしまいました。皆さん良いお年を。

というわけで

Kaigi on Rails 2023が開催されました。この記事では開催にまつわるあれやこれやを書きたいと思います。

準備の話

会場の選定

2020年にKaigi on Railsを初開催して以降、2022年までオンライン開催だったので会場について気にする必要は(良くも悪くも)ありませんでした。しかし2022年初頭の時点で「来年は物理開催ができそう」という予測があり、初めて浅草橋ヒューリックホールの下見に行ったのは2022年4月でした。かなり良い会場だったため、他の会場には特に下見に行っておらず、ほぼ即決に近い状況でした。 ポイントは駅から近いこと、人数が400人ほどとちょうどよい大きさであること、2トラックできること、ブースがそこそこ置けること、配信を手伝ってもらえることなどでした。これら全ての条件を持っている会場は意外なほど少なく、結果的にほぼ即決になったわけです。 会場は1年前からしか本予約ができなかったため、いったん仮押さえをしてもらって2022年はその年の開催に集中することとなりました。去年の感想記事

オンラインでのやり残しがないようにする

とあるのですが、まさにその勢いで過ごしていたため、2023年の準備を本格的に始めるのは2022年10月以降となりました。

2023年に入って以降の準備

初めての物理開催ということでどういうことが起こるがあまり予想が付かなかったため、以前よりもスケジュールを気にしながらの準備となりました。特に2022年との差分であるスポンサーブース(物理)や会場で必要な諸々のサイン(受付はこちら的なやつ)については2023年に入った時点で意識に入れつつ準備を進めていきました。 例年通りに基調講演について早めに固めつつ、スポンサー募集とCFP公開を順次進め、プロポーザルを選定するところまではこれまでとあまり変わらずにできたのですが、9月頃から会場とのやり取りの回数が増え、スポンサーさんとのやり取りも例年以上に頻繁になってきました。 最終的にはチームメンバーが多くの部分を拾ってくれたため、なんとか当日に間に合ったという感じです。感謝。

当日

ブース

物理ブースの存在は2023年における最大の変化かもしれません。これまでも2021年と2022年にオンラインブースはあったのですが、人の流れと会話の量という点で物理ブースには勝てないということが明らかになっていました。そこで物理開催における重要ポイントの一つはブースということになります。 ブースの設置数は会場との兼ね合いなのですが、今回の会場のサイズ的に10社くらいが限度そうでした。そのため、厳正なる抽選(Array#sample)を行い、多くのスポンサーさんに対してお断りをしなくてはなりませんでした。誰も得しないのでできればお断りしたくはないのですが、こればかりは大きな会場を確保できない限り起こるような気がします… 当日のブースはとても賑わっていて、物理開催の良さが一つ表れているなと感じました。各社ともかなり力が入っていて(ありがとうございます!)、個人的にも楽しませてもらいました。

懇親会

懇親会も2023年で大きく変わったものの一つです。物理で開催するということはもちろんなのですが、これまでのオンライン懇親会ではすでに仲良くなった人たちしか来ず、新規参入者が少ない、という印象があったため、それを変えたいと思いました。 そのため、懇親会のチケットを別売りにすることはせず、本編のチケットにバンドルすることにしました。さらに懇親会の会場を本編と同じ場所にすることにより、できるだけ離脱を減らすようにしました。 その結果、目測ではありますが本編参加者の8割近い数の参加者がありました。多くの方に楽しんでいただけてよかったと思いますし、今後もこの形式でやっていくのが良いという手応えもありました。

フリースペースやハックスペースなど

今回は物理開催ならではということと、会場にちょうどいい大きさの部屋が複数あったということで、今回は各部屋を様々に活用してみました。 まずはサテライト会場です。これはROOM Bが少々手狭であるということから、大勢の人がROOM Bに来た場合に参加者がROOM Bの動画を見れる部屋を別に用意するというものです。一定の需要があったらしく、常に参加者がいる状態だったようです。 ハックスペースもありました。フリースペースとは違ってこちらの部屋には電源があったのですが、あまり積極的に周知しなかったこともあってそれほど利用されていなかったようです。これは課題といえば課題なのですが、そもそも次回の会場に電源を供給できる部屋があるのかもわからないのでなんとも言えません。 そしてフリースペースです。この部屋はかなり広く座席数も多い部屋なのですが、積極的に活用するというよりはむしろ解放しておいて自由に使ってもらうようにしました。机と椅子に関しては会議室的な正面向きの配置ではなく、互いに向き合うように配置して会話しやすいようにしました。これは前日準備で運営メンバーから出てきたアイデアで、実際やってみると非常にうまくいきました。「廊下」的な機能性なのですが、物理的な廊下が狭い会場では廊下部屋を作るのが有効であるという知見を得ました。来年以降も実装を検討したいですね。 フリースペースには水道などの設備があったため、なんとねこのやのogijunさんをお呼びしてコーヒーを淹れていただきました。ogijunさんはKaigi on Railsの名付け親ということもあり、また私がコーヒー好きのため、個人的にもぜひやりたいということで実施の運びとなりました。こちらは満員と行列を避けるために意図的に周知していなかったのですが、それでもかなりの杯数が出たようです。やはりカンファレンス会場で飲む深煎りコーヒーはいいですよね… コーヒーについては元々RubyKaigi 2019で同様のことが行われていた(ただし部屋の外で提供して部屋の中で飲むスタイルだった)のですが、その時と比べると部屋の中でコーヒーを提供する関係でogijunさん周辺に人だかりが出来ていたのが今回の変化でしょうか。もくもくとコーヒーを淹れるというよりはにぎやかな感じで楽しそうでした。島田浩二さんがコーヒースタッフ業(?)をやってらっしゃったのが印象的です。

コンテンツ

今年は初めての2トラックということでした。初めましての登壇者あり、久しぶりの登壇者あり、3人での登壇あり、3年連続の登壇者ありとバラエティに富んだ方々によるトークの総数は基調講演を含め36と過去最多となりました。どのトークも興味深かったのですが、分身の術を得ていないため全て見ることはできませんでした。先日YouTubeに動画が全て公開されましたので、今順次見ているところです。ここでは基調講演の個人的な感想を書きたいと思います。

zzak

zzakは実は日本語で基調講演をしてくれるのでは、と期待していた部分もあるのですが、最終的には英語でのトークとなりました。といっても内容が日本語でスライドに書き込まれていたため、内容を理解するのに支障はなかったと思います。 zzakは昔から活動している人ですが、まとまったストーリーを聞くのは初めてだったのでなるほどと思いながら聞いていました。しばらく触っていなかったRailsをまた触るにあたってissueを全部読むなど、Railsにかける想いが伝わってくる話でした。将来への展望も聞けたので今後も楽しみですね。

byroot

byrootは遠方に住んでいるため動画でトークとなりました。RubyKaigiの会場で直接会って打ち合わせをして最終的に承諾をもらったのですが、実はbyrootは過去の登壇がほとんどなく(探しても見つからない)、非常に貴重なトークになりました。 内容は過去のバグ修正についてですが、特に2つ目のバグはActive Recordのdupの挙動とMarshalの挙動とObject Shapeのobject too complexの挙動とが全て合わさって起こるバグであり、説明を一度聞いただけでは理解できないようなバグでした。byrootはRailsコアチームのメンバーでありかつRubyコミッターでもあり、またObject Shapeの開発にも関わっていたということでバグを直すことができたとのことですが、さすがと言うしかない。

データで見れないKaigi on Rails 2023

見出しは出オチですが、実際、物理開催では例えば参加者の性別のようなデータを正確に取ることは困難です。アンケートに記入する欄はあるのですが、アンケートの回答率はそこまで高くはないので(回答してくださった方ありがとうございます!)、やはり全体像をつかむまではできません。 それでも語れるいくつかのデータとして、例えば実参加人数を見てみましょう。約380人の会場参加登録がありましたが、チェックインは約370人となっています。つまり10人くらいの人は参加費を払ってはいるが実際には来なかったということになります。全体から見ると3%ほどということになりますね。これはいわゆるオーバーブッキングを行っても問題が起こらない可能性を示唆しています。15000円の参加費でもこれくらいの人数が来ないのであれば、もっと安ければさらに来ない人は増えるでしょうから、キャパに対して5%ほど上乗せした人数を入れることは可能そうです。 YouTubeでの視聴に関してはしっかりとしたデータが取れています。それによると、Day2のROOM Aはユニークな視聴者が約600人います。これは興味深いことにオンライン視聴チケットの数を超えています。おそらくTLなどから流入した方がいるのでしょう。平均視聴時間は約20分と非常に短く、見たいトークを1つだけ見るという使い方になっていると思われます。 こうしてみると、カンファレンス参加の形というのは非常に多様なのだなと感じます。物理参加の人たちは2日間ずっと会場の近くにいて人と話したりトークを聞いたりする一方、1つのトークを動画で見るだけの人もかなりの数いるということです。Kaigi on Railsはカンファレンスの敷居を下げることを当初より意図して設計されており、今回の結果もまたその方向性を後押しするものとなるでしょう。

さいごに

さて、ここまで2023年のKaigi on Railsについて書いてきました。2024年についての情報はもう少しお待ちいただくとして、最後に告知があります。 2024年2月15日16日にベルサール羽田空港で開催されるDevelopers Summit 2024にて、オフラインカンファレンス復活!イベント現地参加の魅力を語りつくすリレーセッションに登壇することになりました。私はKaigi on Railsからの参加ということで、「初学者から上級者まで」という部分にフォーカスしたトークをする予定です。現地でお会いできることを楽しみにしています!

おまけ

画像を置いておきますね。

Kaigi on Rails 2023のYouTube用画像です

RubyConfTw2023の感想記事

はじめに

この記事はフィヨルドブートキャンプ Part 2 Advent Calendar 2023の24日目の記事です。23日目の記事はかわかみさんの空手とフィヨブーと私:なにが「たのしい」のか?でした。

お詫び

まだ色々書けていない記事があるのですが、年内には書くので許して…

カンファレンスについて

https://2023.rubyconf.tw/

今年が10回目のRubyConfTwに登壇者として参加してきました。参加者としての参加も含めて今回が初参加です。今年は日本から多くの登壇者がいました。 最初に言い訳をしておくと、自分のトークが2日目だったのと、来るときに飛行機が3時間近く遅延したりして若干疲労していたのもあり、初日はあまりトークを聞けていません。そしてなんと自分以外の日本人登壇者が全員初日だったため、結果として多くを聞けていません。 ランチドリンクがタピオカミルクティーだったりと台湾らしい要素もあり、中国語のトークGoogle Meet経由の同時通訳で聞いたりと興味深い試みもあり(運営が機材を用意する必要がないのがよい)、楽しく過ごせました。

自分のトークについて

speakerdeck.com

今回は"Writing Minitest clone in 30 minutes"というタイトルでライブコーディングを含むトークをしました。タイトル通りにMinitestっぽい機能、特にautorunを中心に約30分で実際にそれっぽく動作するものを作るという内容です。

今回のトーク、実はEuruko2023からの続きになっています。そちらでは「RSpec」を「読む」がテーマだったため、今回は「Minitest」を「書く」と内容を反転させてみました。時間も同じ40分で、やっぱりライブラリの深い部分というか実装に近いところについてのトークをしようと思ったら最低でも30分、できれば40分はほしいですね。

ライブコーディングというと難しそうですが、実際には準備をキッチリとしていれば意外となんとかなります。時間に余裕を持たせて、多少エディタの操作でミスをしても間に合うように調整すれば大丈夫です。実際、今回も変数名をtypoしていたのを聴衆に助けてもらったのですが、そういう事態を事前に織り込んでおけばよいのです。あとはエディタやターミナルの操作に熟達すること。これは日々の仕事にも効いてくるのでなんにせよやっておくと良いです。

Minitestはライブラリのテストに使っており、Minitestについて紹介するというのもこのトークの一つの目的でした。MinitestはRailsアプリに対して使われることこそ(何故か)少ないものの、シンプルで高速なテストが書けるのでもっと使われてもいいと思っています。

余談:登壇ネタを思いつくことについて

今回のネタは前述のようにEuruko2023のネタを反転させただけなので、そこまで思いつくのが大変ということはありませんでした。ではEuruko2023のネタはどうしたのかというと、サイトにRSpecのテーマが人気だと書いてあったのです。それを見た私はRSpecに関する何かで登壇することに決め、結果的にコードリーディングになりました。元々RSpecが好きで記事を書いていたこともあったのですが、それ以上にRSpecについて話したい動機が私にはありました。 それは勉強です。こういうと変な言い方ですが、プログラマとして10年近く仕事をしていると、大抵のことはなんとかなってしまいます。私は怠惰なので、こうなると勉強をサボります。そこで「登壇駆動勉強」として、定期的に良く知らないテーマについて話をするようにしています。実際、RSpecのコードを読んだことがあるから登壇したのではなく、RSpecのコードを読む理由がほしかったから登壇したというのが本当のところです。今回も、Minitestっぽいものは割と書けそうだし書いてみたいという気持ちが元々あった部分があります。

台湾観光について

今書いています…もうちょっと待ってね…

プロポーザルについて2023 - 作文術とか

はじめに

Kaigi on Railsの運営メンバーであるunasukeがプロポーザルに関するいい記事を書いてくれていました。

https://blog.unasuke.com/2023/kaigionrails-proposal-writing-guide/

この記事の最後に

通過するproposalを書くための作文術(どのように書くか)ではなく

とあるので、この記事ではそれを受けてプロポーザルがより通りやすくなるようなコツについて書いてみようかなと思います。

前提:プロポーザルを出すということについて

しかし、プロポーザルを通す前にはまずプロポーザルを提出しなくてはなりません。これをハードルに感じる人もいるかと思います。そこで、プロポーザルを出すハードルを下げるようなことをいくつか書こうと思います。

プロポーザルを書くことで自分の知識や知見が整理される

個人的に重要視していることとして、プロポーザルという形式はアウトプットをする最も良い方法の一つだと思っています。書いたプロポーザルは公開されない場合も多いので、あまり読み手のことを気にせずに書くことができます(もちろん読み手がいる以上は考えるのですが、例えばよく知らない人からのマサカリとかは来ないわけです)。また、プロポーザルは字数に制限があることも多く、結果として自分が話したいことを「端的に」表現することになります。

これらの結果として、プロポーザルは自分が言いたいことに関するノイズがそぎ落とされた表現となります。プロポーザルを書く過程で「なるほど、自分が考えていたのはこういうことだったのか」となることもよくあります。ここで得られたものはプロポーザルの当落に関わらず今後の糧となります。

ですので、「落ちたらどうしよう」と考えすぎるよりはとりあえず出してみるとよいでしょう。実際、落ちても何も起こりませんし(私も数え切れないプロポーザルをrejectされています)。

カンファレンスで話すと注目される

これは人によってはメリットにならないかもしれませんが、カンファレンスの登壇者は一般参加者に比べて注目されやすくなります。これは特にフリーランスのように自身の知名度を商売道具にするケースでは非常に強力です。

また、副次的な効果として「懇親会でのコミュニケーションが楽になる」というのがあります。登壇者は質問をされることも多く、自分から話しかけに行く必要があまりありません。自分のトークというネタがあるため会話にも困りません。結果として知り合いが増えることで今後のカンファレンスに行った際の助けにもなります。

ちなみにこのこと自体はイベントの規模にかかわらず発生するので、最初は地域Rubyコミュニティなどで発表してみるのもオススメです。

プロポーザルに何を書くか

プロポーザルを書くに当たって考慮すべきことは三つあります。内容と構成とテクニックです。このうち、構成については冒頭のunasukeの記事で書かれているため、ここからは内容面とテクニックについて書きます。

実際に手を動かしたことを書く

「自分が実際に行ったことについて書く」のは重要です。「その人にしか話せない」ようなプロポーザルであれば通る確率はかなり高くなります。そして、自分にしか話せないことを書こうとすると多くの場合自分が実際に行ったことについて書くことになります。

手を動かした内容が日々の業務の中であっても全く問題ありません。各社が業務内で行ったことは公開されにくく、しかし実際に共有されると多くの人の役に立つという性質を持っています。Kaigi on Railsは特に「明日からの仕事に役立て」るということがコンセプトの一つになっているため、業務に直結した内容は比較的通りやすい傾向があります。

ここでの「手を動かす」はコードに関することでも良いですし、それ以外のこと(例えばマネジメント的なこと)でも構いません。また、OSSに関することでも良いですが、自作OSSの自慢的な話は(少なくともRubyKaigiと比べると)通りにくいです。これは単に方針の違いであり、自作OSSの自慢が良いとか悪いとかいうことではありません。

カンファレンスの傾向を把握する

今まさに説明した「方針の違い」というのは非常に重要です。方針に反するプロポーザルは原則として通りません。これらの方針は明記されている場合とそうでない場合があります。Kaigi on RailsではCFPページがありそこに具体例が挙げられています。もし不安がある場合は過去のトークを見てみるとよいでしょう。

Kaigi on Railsの場合、CFPページに「Rubyに特化した話題については、優先度が下がるかもしれません」と明記されています。こういった方針に関しては事前に把握してプロポーザルを出すことが求められています。

プロポーザルを通すテクニック

ここでは私が考える、プロポーザルを通すためのテクニックについて書きます。

アピールするポイントを明確にする

プロポーザルには必ずアピールとなるポイントがあります。例えばそれは新規性であったり網羅性であったりします。それを絞ることで採択する側がどこに注目すべきが明確になります。例えば非常に重要なトピックについては網羅性に重点を置いたプロポーザルは評価が高くなるかもしれません。あるいは新しいテーマや切り口であれば「これまでどこでも議論されていない」ことを強調してもよいかもしれません。

明確なアピールポイントが存在するプロポーザルは採択する側の目に留まりやすくなります。プロポーザルはかなりの数に目を通すため、目立つことは予想以上のアドバンテージとなります。

聴衆を明確化する

もう一つ明確にすべきポイントは聴衆です。例えば入門的なトークをする場合、すでにそのトピックについて詳しい人は得るものが少なくなりがちです。そこで事前にプロポーザルに「詳しくない人がターゲットです」と書いてしまいます。この方法のメリットはいわゆる「枠」に収まりやすくなるという点です。多くのカンファレンスはバランス良くトークを配置しようとする傾向があり、それはある程度意識的に「初心者枠」のようなものを考えながら採択をするということにつながります。ターゲットが明記されていることで枠に入りやすくなります。

これは実際に資料を作る過程でも有効です。聴衆が明確にされていることが入れるべき内容と落とすべき内容がハッキリとしてきます。

分量を書く

冒頭のunasukeの記事にもありましたが、分量はないよりあったほうが絶対に有利です。採択する側も人間なので、がんばってたくさん書いてくれたものは通したくなりますし、逆に手抜きに見えるものは通したくなくなります。それを抜きにしても、実際に登壇する際のイメージが湧くと安心して採択できるので、そういう意味でもたくさん書くのはオススメです。

さいごに:まずは出してみること

残念なことに、提出された全てのプロポーザルに対して主催側がフィードバックをすることは各種の制約により不可能です。ですが、個別にフィードバックを求められた場合は応じるケースもあります(Kaigi on Railsでは可能な限り応えたいと思っています)。もしいいプロポーザルを書けたはずなのに落ちてしまったなら、主催者にコンタクトを取ってみてもよいかもしれません。プロポーザルの提出に使われているアプリケーションによってはその中でやりとりをすることも可能ですが、他の手段もあります。

プロポーザルは出してみないとコツがつかめないと思います。私もキャリアの初期に出したプロポーザルはあまり良いものではなかったはずです。しかし、プロポーザルを出すことを続けるうちに内容や書き方が洗練されていきます。

そもそもプロポーザルは落ちるほうが普通の世界です。倍率はイベントにもよりますが、直近のRails Worldでは6倍になったそうです。通る確率は約15%ということになりますが、ここまで極端でなくても3倍程度の倍率は珍しくありません。プロポーザルの当落にはある種の運も絡んできます。

ですので、「落ちたらどうしよう」と考えるのはあまり有意義とは言えません。むしろ落ちて当然と思いつつ、しかし最善を尽くして書くのがよいでしょう。

皆さんの渾身のプロポーザルをお待ちしています!

RubyKaigi 2023の感想

TL;DR

最高でしたね。LTができたのと多くの人と話せたのが特に良かったですが、トークやパーティーなど、これぞRubyKaigiという感覚が非常に強くて感動しました。

はじめに

この記事はRubyKaigi 2023の感想記事です。基本的にはRubyKaigiについて知っている人を対象としています。基本的な情報は記載しません。

一言でいうと

最高でした! いや、なんでしょう、RubyKaigiは2016年から基本毎年参加していて(2018年のみ不参加)、全部楽しかったのですが、今年は自分にとって今までで一番楽しかったです。

この記事の構成について

この記事は主に3つのパートで構成されています。

まず最初は私が聞いた各トークの感想です。なお、トークのメモは一切取っていない(忘れたというよりは、気力が持たなかった)ため、うろ覚えでの記述になっていることをご承知おきください。

次のパートは私がLTで行ったトークについてです。プロポーザルを提出するまでのこと、採択されてからの準備、実際に行ってみての感想などを書きます。

最後は今回のRubyKaigiの楽しさの理由について振り返ってみます。主に3つの理由が思いつくのでそれらをそれぞれ考察していきます。

トーク感想(Day1)

Matz Keynote

いつものMatz節が炸裂する場面もありましたが、今回は過去の話がメインだったこともありいつもとは少し毛色が違った気がします。Rubyの開発にはやはり色々な苦労があったのだなあと思いつつも、「なんだかんだで楽しんでいるんだなあ」と感じました。

MatzにDrinkupにて「英語をどうやって勉強しましたか?」と聞いたところ「勉強していません」と返されたのですが、自然体でRubyの開発(や英語)をできてしまう(ように見える)のがすごいですね。

Matzが引退したあとのRubyはどんな感じになるのか現時点では想像できませんが、いずれそういう日は来るのだよな、ということに思いを馳せたりもしました。

The future vision of Ruby Parser

実はこのトークはほとんど見れず、というのも昼食に思ったより時間がかかってしまい間に合わなかったのでした…

あとでLramaがコアにマージされたことを知り、金子さんの腕力に驚いた次第です。Bisonを置き換えるのすごい…

"Ractor" reconsidered

やはり並列処理は難しいのだなあ、というのが最初の感想です。GCが絡んだときの難しさについても語られていて、そこまで理解はできていないのですが難しいことはわかりました。

以前Ractorを試したときはたしかにパフォーマンスの劣化を経験したので、そこがどうにかなると実用するモチベーションが湧くのは完全にその通りだと思います。

自作のライブラリをRactor Friendlyにできればいいなと思っているのですが、その方法などについてドキュメントが整備されてくるとエコシステムの発展も進みそうだなと思いました。誰かやってくれ…

Power up your REPL with types

「型のキラーアプリ」ことIRB。型情報があると補完がリッチになるというのは型を導入する大きな理由になりますね。

ぺんさんはTRICKの人という印象が強いですが、IRBのissueを見るとぺんさんが作ったものが多く、たくさんのバグを見つけているのだなあと気づきました。

IRBには色々と独自の仕組みが導入されていると思うのですが、そこをShopify勢が作っているものと合わせていけたりすると面白そうと思いました。

LT

Building Ruby Native Extention using Ruby

トップバッターはかつよしさん、「これ終わるのか」と思うまもなく「これは終わらないな…」と思ったら案の定終わらないという綺麗な展開でした。内容的には興味深かったのでもったいない…

RBS meets LLMs - Type inference using LLM

最近流行のLLM(よく知らない)を型推論に使うというお話。個人的に今年に入ってから「Copilotでここまで補完が効くなら型はいらないのでは?」みたいなことを考えていたのでまさにドンピシャな内容。5分ジャストで終わったのもすごい。

Customize your Vim/Neovim directly with Ruby

私のLTです。詳細は後ほど。

mruby VM

MatzによるLT。基調講演とは変わって技術的な内容だったようです。「ようです」というのは、このとき会場内で迷子になっており、着席できたときにはもう終わりかけだったのでした。

Natsukantou the XML translator

Rackっぽいミドルウェアパターンを適用して翻訳精度を高めたgemの紹介でした。YARDのコメントを書く必要があるのが面白いですね。

BINGO!

Shugoさんが社長として抱える「ミッションクリティカルな」タスク、ビンゴゲームの実装についてのお話。WASMの実用例としてとても興味深いと思います。Fiberの制約を乗り越えるために事前にコードをERBを用いて展開しておく、というアイデアには脱帽です(この理解で合っているのかな?)。

Adding custom rule for Rubocop in the 2 month of employment

前回のRubyKaigiのMusic Mixinで転職に成功したゆらさんのお話。そして転職するとコードを理解するためにリファクタリングすることになり、そのためのCopを作ったというお話でもありました。Rubyコミュニティいいよね…

Unexplored Region - parse.y -

再びの金子さんが今度は爆速でparse.yの解説をしました。「初級編」から「上級編」まであるうちの「中級編」で時間が来てしまったのですが、一体「上級編」には何が書かれていたのだろう…と思って読んでみたのですが全然わからなかった…パーサーの道は険しい…

Ultra-fast test-driven development

RSpecを高速化するrsepc-daemonの紹介でした。確かに効果的なアプローチだと思うのですが、なぜ今までなかったのだろう…今回の全トークの中でも一番業務に取り入れやすいテーマだったような気がします。

Optimizing Ruby’s Memory Layout: Variable Width Allocation

Rubyのメモリ効率を改善するVariable Width Allocationの解説、というか導入でした。これはちゃんと話すと30分でも足りないみたいなやつだと思うので、5分だと導入だけになるのはやむなしかなと思います。余談ですが、舞台袖でLTの進行についての解説があったのですが、Peterはだいたいわかっていたようです。

Dividing and Managing: The Cops Squad of RuboCop RSpec Dept

rubocop-rspecからgemを切り出しているお話。FactoryBotについてのCopは独立していたほうが使いやすくなるので嬉しいですね。切り出しはこの発表の直前に行われていたということで、ここでも登壇駆動開発の姿が。登壇者のydahさんはここ最近活発に活動していてすごいです。

Serverless IdP for small team

RubyKaigiのオーガナイザーでもあるsorahさんのトークは認証周りのお話。Googleのような巨大な認証の仕組みはRubyKaigiチームのような比較的小規模なチームにとっては大きすぎるということで独自の認証基盤を作ったとのことでした。特にRubyKaigiのようなチームでは各メンバーがすでに認証基盤上にアイデンティティを持っているのでそれをOmniauth経由で使えるようにするという仕組みのようです。

トーク感想(Day2)

Implementing "++" operator, stepping into parse.y

何を隠そう私が関わったトークでした(スライドの英語レビューをした)。超満員で立ち見になりましたが、会場の沸き方はさすがしおいさん。内容的にもパーサーを丁寧に解説しており、今年っぽいトークでした。

Yet Another Ruby Parser

実装というよりはモチベーションなどにフォーカスしたトークでした。問題意識としてはすごくわかる(パーサー乱立しすぎ…)し、それを手書きでゴリっとやるというのもすごいなと思いました。もっと実装のことについて語られるとなお良かったかな…

これは金子さんのLramaとバトルになるんですかねえ…決めるの大変そう…

Revisiting TypeProf - IDE support as a primary feature

エディタが好きなのでこのトークは気になっていたのですが、TypeProfを書き直しているということでまずそれ自体がとても大変そうだなと感じました。結果として応答速度が大幅に向上し、エディタでの利用に耐えるようになったというのはさすがまめさん。

TypeProfで得た情報を他のツールから使えると夢があるなあと思っているのですが、そのへんはどうなんでしょうかね…

Ruby Implementation of QUIC: Progress and Challenges

Kaigi on Railsでも獅子奮迅のうなすけのトーク。まず驚いたのは英語がうまい!忙しいのにいつ勉強しているんだ、という気持ちです。

内容はPythonRubyのギャップ的な話が多く、Pythonがわからない私は「そーなのかー」となっていました。うなすけの苦労が偲ばれますが、今後もまだやることがあるっぽいのでうなすけ先生の次回作に期待です。

Tips and Tricks for working in the MRI codebase

MRI(いわゆるCRuby)の開発に関するTips集的なトーク。Asakusa.rbなどによく行っているせいか、既知の内容も多かったのですが復習的な意味で楽しく聞けました。特にデバッガについては知らない情報が多かったです。

デバッガといえば、たまたま近くにいたima1zumiさんと話したところ、macOSではgdbのインストールが難しくてlldbを使うしかないそうです。なんだと…

Optimizing YJIT's Performance, from Inception to Production

YJITを生んだMaximeのトーク。基調講演ということもあり丁寧なトークであり、それにもまして丁寧に開発をしているのがとても印象的でした。私はコンピュータサイエンスを学んでいないのですが、「これがコンピュータサイエンス…!」となりました。そして実際にRailsアプリを高速化できているのもものすごい成果ですね。

学術的な成果がRubyに持ち込まれている、という点には感銘を受けつつ、その学術の世界と縁がない私はどうやってYJITと向き合えばよいのだろう、とも思います。勉強することは多いですね…

トーク感想(Day3)

Ruby Committers and The World

今回は初の英語メインということもあり、Shopify勢が元気な印象でした。あとはEregonが正規表現について語りまくっているのがとても印象的でしたね。

1時間では全然足りないなあとも思うし(一言も発していない人も多かった)、これはいっそ3時間くらいやってもらってその間に他のルームでもセッションを進めてしまうとよいのだろうか?

Code indexing: How language servers understand our code

エディタで使えるようなコード情報を集めるお話。エディタ好きとしては気になるところであり、実際なかなか興味深いことを話していました。このインデックス関連のツールはgemとしてリリース予定とのことであり、ruby-lspと合わせて期待が持てます。

なお、登壇者のvinistockから別に聞いた話では、ruby-lspにプラグインシステムを持たせてRailsなどへの対応はそこでするということも進行中とのことでした。こちらも期待ですね。

Ruby JIT Hacking Guide

RJITの紹介トークでした。とにかく私達にJITを作ってほしい、ということに力点が置かれており、k0kubunさんのJITにかける想いが伝わってきます。

私はアセンブラが苦手というかよくわかっていないのですが、調べてみるモチベーションは非常に高まりました(なにか作るかはまあ、余裕があれば…)。

Parsing RBS

soutaroさんの基調講演はまたもパーサーの話。型定義は瞬間瞬間を見ると壊れていることが多い、というのはなるほどなあと思いました。

RBSのパーサーがgemになっていると、外部ツールから型情報を読み取れて便利なのでそれも期待してよいのでしょうか…?

"Customize your Vim/Neovim directly with Ruby"について

発表のきっかけ

私はもともとRubyKaigiにプロポーザルを出していて、今回も出したかったのですがネタがなくて断念しました。最近作っているものである程度まとまったものといえばAlbaくらいしかなく、Albaでは過去にプロポーザルを通せなかったためです。

ですがあるタイミングで"rspec-current.vim"ならばLTくらいならできるのではと思い始めました。その時点ではまだLTがあるという情報はなかったのですが、気持ちの上ではLTにプロポーザルを出すつもりでいました(準備していたとは言っていない)。

そしてLTのCFPが公開されてから割とすぐにプロポーザルを提出しました。以下はその内容です。

Abstract

My editor of choice is Neovim. Do you know what advantage Vim/Neovim have for us Rubyists? Yes, we can write plugins with Ruby!
This facility made it possible to develop rspec-current.vim, a Vim/Neovim plugin to tell you what subject and context are in your cursor position. It's useful with deeply nested RSpec file.
As I mentioned, we can use Ruby as a plugin development language. This means we can even use RubyVM::AbstractSyntaxTree in our plugin. In this talk I'll talk about the implementation detail of the plugin and encourage you to do the same!

Details

I think this type of editor plugin will be still useful in the future.
Although recently lots of developers use Language Server Protocol (LSP) to build editor plugins, there are some benefits not using LSP.
First, it's much simpler. I created only one Vim script file and that was enough. In contrast, if I adopt LSP I need to consider if I create my own Language Server or send a PR to other existing implementations.
Second, it should be faster. There's no overhead of JSON RPC. If we want to display the result from plugins, it's important.
So I think I can introduce something useful, at least for Vimmers.
But most importantly, this talk is about encouraging. Creating small but useful things in Ruby makes our lives a little easier, and it is fun!

Pitch

I've wondered why do we want to use other languages to improve one language. I really appreciate efforts that improve Ruby with Ruby such as RJIT or Typeprof.
But what about editors? VSCode is a great editor but we must use TypeScript to develop any kind of plugin. I'm not a big fan of this.
This talk is a concrete example of using Ruby to improve Ruby experience. As I know more about Ruby I can develop it even better. And I'm working on it!
Btw, I know TextBringer but I have not used it so I cannot talk about it at all :)

プロポーザルが通った!

幸いにしてLTのプロポーザルは通りました。上の文章をよんでいただければお分かりの通り、5分の発表時間に対してかなり長文のプロポーザルを書いており、熱意をうまくアピールできたのが良かったのかもしれません(だから発表中に語られなかったことも大量に書いてある…)。

プロポーザルが採択されたのは4月25日のことで、本番までは2週間くらいしかありません。そこで実装を「手直し」しようとしたのですが思わぬ展開が。

動かない!!!

すでに完成していると思って油断していたのですが、なぜか試してみると全く動作していない。理由は調べられなかったのですが、デモをすることは発表の流れ的に必須である以上、これは重大な問題でした。

そこで割と直前までひたすら修正をしていました。あるあるですが、一度修正を始めると色々なところが目に付き、ついつい細かな修正を繰り返してしまっており、結局発表自体に手を付けたのは5月の7日ごろ…

発表準備

今回の発表をVim(正確にはNeovim)で行うことは当初から決めていました。主な目的はネタですが、デモ用のNeovimと発表資料の行き来がしやすいという隠れたメリットもありました(同じiTermを使っているため、キーボードショートカットでウィンドウの切り替えができる)。

ただそこにも問題があり、iTermは端末アプリケーションなのでフォントサイズはアプリケーション内で固定です。そのため、髙橋メソッド向けにフォントサイズを上げすぎるとデモの際にコードが読めなくなってしまいます。今回はウィンドウを2つ使い、それぞれで異なるプロフィールを利用することで回避しました。

また、Vimでプレゼンする際に邪魔になる色々なもの、例えばタブの表示などは全て非表示にする必要があるのですが、それはコマンドで行いました。以下がそのコマンドです。

command! StartPresentation :tabdo :windo :set laststatus=0 | :set showtabline=0 | :set nonumber | :execute "sign define piet text=>> texthl=Search" | sign place 2 line=23 name=piet

髙橋メソッドで表示する内容についてはテキストファイルとして作成し、それをスクリプトから起動してgtでタブを移動することでページ切り替えをする方法をとりました。この方法のメリットは上のコマンドと合わせてマシンの再起動などに強いことです(簡単なコマンドでプレゼン環境を復元できる)。実際、接続確認をしたら画面が表示されなかったのでマシンを再起動したのが発表の直前だったのですが、ストレスを感じることはなかったです。

内容面について触れると、基本ネタ重視だがしっかりと実用面をアピールするという方針で作りました。途中、Shugoさんと金子さんに触れているのは偶然ではなく、発表内容の相互関連感を演出する目的がありました。本当はMatzにも触れたかったけど無理でした…

発表

発表は英語で行いました。これは言うまでもなくRubyKaigiが国際カンファレンスであるということと、台本がない状態で同時通訳の方が正しく訳してくれることはおそらく期待できないであろうと思ったためです。英語がそれほど得意でなくても聞き取れるよう、平易な英文を心がけました(難しい英語が使えないともいう)。

あれほどの人数を前にして話すのは初めてでしたが、不思議と全く緊張しませんでした。照明の関係で会場にいる人々の顔があまり見えないのがその理由かなと思います。

実際に発表してみると、聴衆から笑いが起きなかったのは残念ですが及第点の発表はできたと思います。笑いについては画像が使えないという制約があったのが大きかった気がしますが、Vimでこの制約を乗り越えるのは大変…

なお、このLTにはセルフ解説があります。英語トークの登壇者が日本語で解説記事を書くのは比較的珍しいと思いますが、ご笑納ください。

楽しさの理由とは

前述の通り、今年のRubyKaigiは今までで一番楽しかったのですが、なぜ自分が今回ここまでエンジョイできたのか、3つの理由について考えてみました。

交流の機会が増えた

一番大きかったのは交流の機会が増えたことだと思います。今年はオフィシャルパーティーやアフターパーティーに加え各社のDrinkupも復活し、Rubyistと話す時間がものすごく長くなりました。元々話すのが大好きな自分としてはこれはとても嬉しい。

Music Mixinも今年初めて参加してみましたが、20時から2時までずっと会場にいて色々な人と話せてとても楽しかったです。最終日なので次の日のことをあまり気にする必要がなかったので、そのままラーメンから居酒屋をはしごし、最後には川に到達してそのまま明るくなるまで飲んでいました。こういう体験はRubyKaigiならではだなと思うのですが、それが楽しいという感覚に大きく寄与しているのは間違いありません。

交流の機会という意味でいうと、今年はヘルパーではなく一般参加だったのですが、結果としてブースをめぐってスポンサーの方々と会話する機会が増えるなど交流には良い影響があったように思います。一方でヘルパー同士の交流は当然ながらできなかったため、一長一短ではあります。

Rubyists on Railsのような交流企画があったのもとても良かったですね。あれはぜひ毎年何らかの形式でやってほしいなと思いますが、企画が大変なのもとてもよくわかる…(沖縄だとRubyists on Jetsになるのかな?)

トークがわかるようになった

今年自分でもビックリしたのが「トークが…わかるぞ…?」という感覚でした。これは去年のRubyKaigiまではあまり得られなかったものです。

初めてRubyKaigiに参加した2016年当時、私は今ほどRubyについて詳しくなかったですし、プログラマとしての実力もまだまだだったと思います。あれから7年が経ち、私はRubyプログラマとしてはかなり成長できました。特に2020年からAlbaを作り始めたのが私の転機の一つであり、ライブラリ的な観点からコードを見ることができるようになりました。

また、個人的に考えていることとして、RubyKaigiは参加するたびに理解度が5%ずつ上がっていくという仮説があります。7年で6回RubyKaigiに参加し(2018年のみ不参加)、理解度が毎年上がっていく感覚は確実にあります。

しかし、それらを考慮しても今年は急に視界が開けたようなところがありました。これは一体何なのだろうかと思うと、一つ考えられるのは問題意識です。RubyKaigiはRubyのエコシステムを改善している人たちのトークが多く、その背後にはRubyの現状に対する様々な課題感があります。今年のRubyKaigiでは開発生産性(いわゆるDX)に関連した話が多かった印象があるのですが、そこに対する課題感は私も強く持っており、実際、kaigieffectとして直後にNiwaという新しいドキュメントツールのプロジェクトを立ち上げました。これまでここまで直接的なkaigieffectを受けたことはなかったので、やはり問題意識がRubyKaigiの楽しみ方に影響を与えているのは間違いないと思います。

これを読んでいる方にもRubyのコア開発やその周辺の話題についてアンテナを張ることをオススメします、RubyKaigiをもっと楽しめること間違いなしです。

松本がとても良い

最後の理由として、松本の町の良さを挙げたいと思います。松本の町には市電やバスの姿がなく、基本的に人々は歩いて移動しているようでした。実際、松本駅松本城まつもと市民芸術館の3点の内部は十分に徒歩圏であり、その内部で諸々が完結する印象を受けました(ただスーパーマーケットはなかった気がするので住民はどこで買い物をしているのだろう)。

町にある最も大きな道路も威圧感はそこまでではなく、結果として町が分断されることなく一体感を保っていたように感じます(甲州街道で分断されている町に住んでいたことがあるので余計にそう思う)。そこが松田さんの言う"Nice"というところに繋がっていくのかなと思いました。

町の一角に蔵が集まっているエリアがあったり、謎に水が湧き出ていたり、小さな川が流れていたり、そういったところも町の雰囲気に一役買っていたような気がします。今回はお昼休みが2時間あったため町に滞在する時間も長く(0日目と4日目を含めるともっと長い)、町を堪能できたのはとても良かったです。

おまけ1:松本で何を食べたのか

例によって写真はほとんどないので、文章でメモ程度に残しておきます。

Day0

  • そば処かまくらや
    • 葉わさび蕎麦というのを食べた、ピリッと辛い葉わさびと蕎麦の相性が良い
  • かうひいや3番地
    • いわゆる古民家カフェで雰囲気がとても良い、コーヒーはやや深煎りだったけどもっと深いやつを頼んでもよかったかも

Day1

  • 蕎麦倶楽部佐々木
    • セットのみだった、蕎麦も美味しかったけど出てくるもの全部美味しくてとても良い
  • オフィシャルパーティー
    • ベジタリアン用のフードが置かれている場所の近くにいたので野菜ばかり食べていた

Day2

  • 珈琲美学アベ
    • このときは普通のコーヒーを頼んでしまった、モーニングはシナモントーストとジャムを選択
  • 女鳥羽そば
    • 三段重ねの蕎麦が名物らしいので頼んだ、味が段ごとに違っていて美味しく食べ進められた。アスパラの天ぷらも美味
  • アルプスコーヒーラボ
    • 浸漬コーヒーが名物らしく、自分はラムコーヒーを注文。浅煎りなのとほのかなラムの香りとでなかなか良い
  • RIZAP Drinkup at RubyKaigi 2023
    • 馬肉のお店で肉を食べまくった。大量のタンパク質を摂取

Day3

  • そば処吉邦
    • ボリュームが多いお店だとしらずに大盛の天蕎麦を注文、かなり満腹になった
  • アフターパーティー
    • 奥の方にあった牛タンがめちゃくちゃうまかった。たこ焼きや刺身も食べた

Day4

  • 珈琲美学アベ
    • 今度はモカクリームオーレを注文することに成功
  • ホップ・フロッグ・カフェ
    • 店主がかなりコーヒーマニアな感じでずっとコーヒーの話をしていた、4種類の飲み比べセットを注文(コーヒーで飲み比べセットは珍しい)
  • そば処種村
    • 2種類の食べ比べセットを注文、そばつゆも2種類あって計4種類の味を堪能

おまけ2:関連イベント

今年のRubyKaigiの一つの特徴はプレイベントやアフターイベントが多いことなのではないかと思います。今回私は参加できる限り全てのイベントに行くようにはしていたので、ここでは関連イベントの感想についても書こうと思います。

RubyKaigi 2023 予習イベント ~推しトーク紹介~

須藤さんメインの予習イベントでした。登壇者のしおいさんも参加し、主にお二人の推しのトークについて紹介する内容でした。オンラインでかつ昼間の開催だったのが特徴的です。

Shibuya.rb RubyKaigi 2023 前夜祭 @GMO Yours・フクラス

最近オフライン開催が復活したShibuya.rbの名前を冠したオフラインでの予習イベントでした。100人近くが集まり非常に賑やかなイベントで、いわゆるReject Talks的なものもあり内容的にも非常に充実していました。

RubyKaigi 2023 を楽しむ予習会

オンラインでの予習会ですが参加人数がとても多く、結果的に全てのトークについてコメントをしていくという内容でした。チーフオーガナイザーの松田さんも参加しており、伝統的な「タイムテーブル徹底解説」的なイベントとなりました。

Ruby-dev office hour RubyKaigi 2023 直前スペシャル

毎週月曜日にまったりとやっているdev office hourの直前号といったイベントでした。他の予習イベントに比べてもRubyコミッターや登壇者の比率が高かったような気がします。dev office hourの性質上ウェビナーモードではないZoomでの開催であり、飛び入りで会話に参加しやすいのが良かったです。

Asakusa.rb Welcome Drinkup for RubyKaigi 2023

オフラインでのAsakusa.rbの拡大版的な内容で、Shopifyの人々も大勢来てとても賑やかかつ国際的な雰囲気でした。登壇者の一言コメントなどもあり直前で大いに盛り上がりましたね。私はShopify勢に積極的に話しかけに行くことができて満足。

ふりかえりRubyKaigi 2023

STORES主催のオンラインの振り返りイベントで、トークをいくつかピックアップして感想を話していく会でした。直後なのでみんな記憶がフレッシュだったので色々濃い話ができていたと思います。登壇者の方々が入れ替わり立ち替わりしゃべっていたのも良かったですね。2時間では時間が足りないのはご愛敬…

RubyKaigi2023 スポンサー振り返り会!エンジニアが語る運営秘話

Wantedlyのオフィスで行われた、スポンサー目線での振り返りイベントでした。私はKaigi on Rails運営の立場からスポンサーについて学ぶために参加しましたが、やはりブースには各社が力を入れているということを感じました。まだお話したことのない方が多く参加していた印象。

After RubyKaigi 2023〜メドピア、ZOZO、Findy〜

タイトルにある3社合同のアフターイベントで、3社から1名ずつとsue445さんとうなすけさんが登壇するイベントでした。sueさんのトークが来年プロポーザルを出したいと思っている私にはとても参考になりました。うなすけのトークは私もちょこっと関わっていました。裏でCookpadのイベントもあったのですが、そちらと比較して若い参加者が多かった印象で、彼らにRubyRailsの話を色々としていました。

【Money Forward x Shippio】 BaySide Tech Nite

英語メインのイベントで、kaigieffectで英語やらなきゃとなっている人が多い中タイムリーなイベントでした。私はLTをして、英語を学ばないということについてお話しました。詳細は資料を参照してください。

speakerdeck.com

さいごに

というわけで最高のKaigiだったのですが、来年は沖縄ということでまたしても期待が高まりますね!

そして10月にあるKaigi on Railsへの熱量も非常に高まりました。最高のKaigiにしていきたいと思いますのでそちらもご期待ください!

さいごに写真とツイートをどうぞ。

松本城

RubyKaigi2023のメインホールを舞台から見る

Matzとツーショット

#rubyfriends

Nice Team!

kaigieffect その1

kaigieffect その2

次はKaigi on Railsだ!

福岡Rubyist会議03に参加してきた

概要

去る2月18日(土)に福岡Rubyist会議03に参加してきました。とても良い地域Ruby会議だったので、ここではその様子をレポートしていきたいと思います。

全般

今回の福岡Rubyist会議03は基調講演2名、一般講演6名の計8名による講演がメインの技術カンファレンスでした。講演の他には会場の後方に八女茶が提供されていたのが特徴でした(めちゃくちゃ美味しかった…)。

参加者はスタッフの方などを合わせて総勢100人前後、参加登録ページによると一般参加はほぼ満員でした。会場では東京から来た方も多く、賑やかな雰囲気となっておりました。

コンテンツ

ここでは各講演について概要などを書いていきます。今回、個人的に初の試みとしてメモを取っていたので、その内容からの復元となります。

yasulab: RubyistによるRubyistのためのカンタン動画制作

安川さんのお話は動画を撮ることについてで、独自の機材でYouTubeへのライブ配信を行うなどとても意欲的なものでした。「音は丁寧に、画は程々に」というフレーズが印象的で、実際に配信をする際には参考になりそうです。StreamYardやScreenFlowなどの便利ソフトウェアも紹介されていて、今後動画配信をする人にとっては助けになる内容だったと思います。

speakerdeck.com

hsbt: Ruby のリリースを爆速にするための方法

しばたさんのお話はRubyのリリースについてで、かなり自動化できている部分もあるが手動の部分もまだあるということでした。Rubyのような複雑なソフトウェアをリリースするのはとても大変なのだと想像は付くのですが、こうして実際に発表になるといやそれは本当に大変そう。

「セキュリティリリースの際はパッチを公開できない」という話があり、なるほどと思いました(リリースより前にパッチを公開してしまうと問題を認識されて悪用されるから公開できないが、そのために動作確認が大変、という理解です)。

speakerdeck.com

sorah

そらさんの基調講演はRubyKaigiの運営がテーマでした。「大変だけど楽しんでやっている」「Rubyコミュニティには恩がある」という話が印象的でした。特に圧巻だったのはtakeout-appについてで、かなり多機能なアプリをAWSを駆使しつつ数週間で作ってしまうのはさすがの一言。

Wi-Fiの話も色々な苦労を偲ばせておりました(技術的なことはよくわからなかった…)、いつもありがとうございます。

(資料は非公開です)

Y_uuu: mruby on IoT devices.

岡嵜さんはmrubyのお話で、mruby-esp32というライブラリをIoTで使う際に直面したたくさんの課題を解決する話でした。課題の一つは最新バージョンへの追随で、地道にエラーを倒していきます(詳細は発表資料を参照)。MQTTというプロトコルのクライアントがない課題はmgemを作ることでクリアして、エンジニアリングをやっている…!という感想です。mrubyはまだまだ潜在的な応用事例が色々あると思うので、今後に期待ですね。

speakerdeck.com

hachi: Factorybot 改善ツール作成失敗と学び

hachiさんのお話はFactoryBotの改善ツールを作ったこととその「失敗」についてです。「失敗」となってはいますが、実際には「全部思った通りにはいかなかった」くらいの内容に見えました。Railsのメソッドをオーバーライドし、test-profに入っているbefore_allに置き換えたりすることで高速化を図るのですが、CIに入れるくらいの精度を目指そうとすると偽陰性偽陽性が多くなってしまうとのこと。

「レコードの作成には意図があって、それはレコードが作成されたという事実からはわからない」というのがポイントということで、なるほどたしかにと思いました。アプローチとしては面白いと思うし、テストの高速化はみんなの夢なのですが、なかなか難しいですね。

speakerdeck.com

pocke: ⁠外部コマンド実行入門

pockeさんのお話のテーマは「外部コマンド実行」でした。コマンドインジェクションのリスクがあるため、そもそも外部コマンドを使わないか引数を複数にわけて渡すことでシェルの起動を防ぐべき、という指針は非常に実践的。外部コマンドを実行するメソッドもいくつか紹介されましたが、だいたいOpen3で事足りてしまうという…

drive.google.com

znz: Rubyist Magazine Reboot

西山さんはるびまのお話でした。現状更新が止まっているるびまをどうするかについて、関わる人数を増やさなくてはいけないこと、現状のシステムの紹介などが取り上げられました。質疑応答タイムが各自の想いを語る場になっていて良かったですね。

slide.rabbit-shocker.org

tompng: メンテできないコードをメンテする技術

ぺんさんの基調講演はTRICKに出てくるようなコードをどうメンテするのかという内容でした。「本当にメンテできないのなら、提出まで至らない」という話が個人的に印象に残っていて、TRICKのコードでもメンテナンス性が重要であるというのは発見でした。非常に高度な内容が次々と出てきて圧倒されましたが、「時にはメンテ不能になることもある」という話を聞いて少し安心しました。

TRICKのようなコードはIRBの秘孔を突くことがあるらしく、IRBのバグ修正にも一役買っているということで、すごい話だなあという感想です。

皆さんの反応は該当の時間のハッシュタグ検索結果から見られます。

drive.google.com

福岡

福岡に行ったのはこれが二度目でした。滞在時間が長かったので割とあちこちに行けましたが、せっかく行った太宰府天満宮が工事中で残念でした。美味しいコーヒーをたくさん飲んで、福岡のコーヒー文化の豊かさに触れることができて良かったです。

次回行く機会があれば門司港に行ったりしてみたいですね。

最後に

今回はトークがとても面白くて非常に充実した時間を過ごせました。現地の方と交流もできましたし、久々の地域Ruby会議を満喫することができました。オーガナイザーの方々、スタッフの方々、スポンサーの方々、ありがとうございました!

【宣伝】この記事はFukuoka.rb#296にて執筆されました。

2023年の抱負

今年はちゃんと一年の最初に抱負を書けました。えらい。

ご挨拶

みなさま、あけましておめでとうございます。今年もどうぞよろしくお願いいたします。

2023年のキーワード

今年のキーワードは「可能性」です。

可能性

これまでも割と自分の可能性に対して意識的に広げるようなことをしてはきましたが、今年はさらに自分の可能性を押し広げていきたいなと思っています。

言っていることは「挑戦」に近いのですが、もっと自分と向き合えたらいいなということでこちらにしました。

やっていることで続けたいこと

実は2022年の途中から習慣をいくつか作ることに成功していて、それは2023年も継続したいと思っているのでここに書きます。

GitHubに草を生やす

2022年の6月くらいから毎日GitHubに草を生やすようにしています。現時点では2日の欠落以外は毎日継続できています。これは言うほど難しくなくて、なぜならdotfilesや個人サイト、さらにはdependabotのマージも含まれるからです。

これの動機づけとしては、https://logmi.jp/tech/articles/326542RubyのパパであるMatzが毎日草を生やしている旨を言っていて、ならばもっと暇がある自分もできるはずだと思って始めました。

Duolingoで中国語の勉強をする

これは4月くらいから、Duolingoを使って中国語を勉強しています。これもほぼ毎日、一日平均10分くらい継続できています。中途半端に負けず嫌いが発動したのでダイヤモンドリーグに残留しています。

「なんで中国語を勉強しているの?」ときかれると「トリリンガルに憧れがあるから」くらいのフワッとした理由しかないのですが、語学は普通に楽しいので続いているのだと思います。

ちなみに、上記二つの習慣はRubyKaigiとKaigi on Railsの間もがんばって続けられたので自信になりました。

新しくやりたいこと

これはおととしも書いているのですが、瞑想とかマインドフルネスは習慣化したいですね。これには笑い話があって、とあるマインドフルネスアプリをサブスクリプション購入して、使わないからトライアル期間中にキャンセルしようとしたらもうトライアル期間が終わって課金されていたんですね。なのでせっかくだからちゃんとやろうということです。

Kaigi on Rails 2022を開催したのでその感想を(やっと)書く

はじめに

遅くなってごめんなさい。この記事はKaigi on Rails 2022の開催をした振り返りです。

頻繁に参照される去年の振り返りはこちら

最後のオンライン開催

最初に誤解のないように書いておくと、2023年以降もオンラインでの配信は行う予定です。ですが、オンライン単独での開催は2022年が最後となると思われます。

そこで2022年は「オンラインでのやり残しがないようにする」ということが個人的な気持ちとしてありました。一方では「オンラインでやるには相対的にコストがかかりすぎる、あるいは効果が低すぎる」ものもあります。例えばワークショップ的なものはやりたかったのですが、オンラインで行なうと理想的な体験にならない可能性が高いこともあり、企画としては自然消滅しました。最終的には、2021年の方向性を踏襲しつつ、運営に負担のかかり過ぎない形での実現を目指すことになりました。というのは、オンラインカンファレンスとしてのKaigi on Rails 2021はすでに結構がんばっていたからです。

去年実現できずに今年実現したかったアイデアとしては例えば「コミュニティスペース」というものがあって、これはオンラインで各地域Rubyコミュニティの方々にブースっぽい感じで集まってもらうイメージだったのですが、やはりオンラインだと関係者のモチベーションも上がりにくて結果的に満足度も高くならないということであまり話題になりませんでした。これは物理でやるといい感じにできるかもしれないので来年以降に期待かもしれません。

「がんばりすぎない」

先日Kaigi on Railsの運営ポリシーを決めたのですが、そこでも強調されているのががんばりすぎないことです。今年はここには結構気を遣っていました。というのは、去年のオンラインブースは結果として

全体レイアウトを確定させ、すでに設営済みだったブースをお引っ越しして、設営会の波を突破して、前日にはリハーサルもしたのですが、この時点でおそらく40時間近くブース関連に費やしていたと思います。これは持続可能性に乏しいので、来年以降は改善したいですね。

という状況になっていたからです。今年もブースをやることは決まっていたのですが、どうすれば運営の負担を減らしつつ総合的な満足度を高い状態にできるかに着目しながらやっていくことになりました。

ブース

そんなわけでブースです。今年は11社のスポンサー様にブースを出展していただきました。ブースのためのプラットフォームとして今年はSpatialChatを使いました。理由としては会場の同時編集が可能であることと、

みんなテーブルに着席しない!!

という去年発生した問題を回避するためです。

参加者人数は正確には把握できなかったのですが、最大時で100人ほどの参加者がブースに参加していたようです。盛り上がってはいたのですが、顔ぶれを見ると新しい方が少なく、やはりオンラインではすでになじんでいる人ばかりになりがちという傾向は乗り越えられませんでした。

コンテンツ

肝心のメインコンテンツですが、トークの内容としては過去一番だったと思います。これは過去2回の内容が悪かったということでは決してないのですが、Kaigi on Railsという場に求められているトークを登壇者の方々が徐々に掴みつつあるということなのかもしれません。

yahondaさんの基調講演

yahondaさんは今年の4月頃にRailsのコミッターになったということで、キーノートスピーカーとしてはタイミング的には最高でした。内容については最初「OSSのやり方」的なテーマでお願いしようかと考えていましたが、最終的に「あなたとRails」というタイトルになりました。OSSにコントリビュートしたいけどとっかかりがない方は多数いると思うので、そういった方々のヒントになる内容だったのではないかと思います。

Nateさんの基調講演

もう一人のキーノートスピーカーのNateはSpeedshopというRailsのパフォーマンス専門のコンサルタントをやっている方で、専門的な話を期待してキーノートをお願いしました。提出された動画が私個人の期待を上回るマニアックで高度な内容だったため、字幕作成の過程で内容的に難しくて固まってしまう場面もあったのですが、日本のRailsコミュニティにあの動画を共有できてとても良かったです。

女性登壇者について

去年の振り返りの中で、

女性の登壇者と参加者が少なかったので、それを増やすことは重要な目標になるでしょう

と言及されている女性の登壇者ですが、今年は3名の方に登壇していただきました。プロポーザルの数自体も増えていたので、全体的に目標は達成できたと思います。理由はハッキリとはしませんが、地道な広報活動をしたのが良かったのかもしれません。来年以降も登壇者の男女比のバランスが取れるように活動していきたいです。

当日のトーク

プレイリストを置いておきますね。

当日

今年の当日運営はかなりゆとりがありました。オンラインでの運営も3年目となり、特に初期からいるメンバーは慣れてきているというのもあります。また、後述するように新しい運営メンバーも増えているため、単純に当日の配置という意味でもやや余裕はあったように思います。私個人としては半分視聴者というと言い過ぎですが、かなりじっくりと発表を見れました。

去年の振り返りを見るとだいぶ忙しそうにしているので、さきほどの「がんばりすぎない」という点は当日もある程度実現したのかもしれません。とはいえ、ブースに行ったり司会をしたりとやることは結構多いのですが。

懇親会

懇親会は、今年は参加者がなぜか去年より減るという現象に見舞われました。これは解釈が難しいのですが、一つの仮説として「コロナ禍が収まりつつあり、土曜日は別の用事で出かけるため参加できない人が増えた」というものがあります。これは後述するデータでも裏付けられていて、2日目(土曜日)の参加者は本編の時点で少な目でした。

データで見るKaigi on Rails 2022

データです。

Day1

トータルの総視聴数は3,215、ユニークな視聴者数は1,437人でした。去年と比較すると15%程度の増加であり、去年よりさらに広範囲にリーチしたことがわかります。

同時視聴者数はデータが取れませんでしたが、当日の記憶では400人近くだったと思います。こちらは去年とさほど変わらなかったかもしれません。

参加者のうちの女性の割合は12.2%であり、こちらは去年に比べて3%ほど上昇しています。

Day2

トータルの総視聴数は1,632、ユニークな視聴者数は719人でした。2日目も去年と比較すると15%程度の増加ですが、やはり1日目と比べると大幅に少ない結果となっています。

同時視聴者数はこちらもデータが取れていませんが、200人前後の時間帯が多かったように記憶しています。

参加者のうちの女性の割合は14.4%であり、こちらも去年に比べて3%ほど上昇し、登壇者の男女比(3:19)と同程度となっています。

感想

やはり2日目、土曜日の数字は1日目と比較してかなり低調です。この事実は1日目のみを視聴している人が一定数いることを示しています。来年のオフライン開催についてこのことは大きな意味を持っています。というのは、来年はチケットの販売数を会場のキャパシティに合わせて制限しなければならず、両日参加のチケットのみを販売すると2日目の会場がガラガラになってしまうこともあり得るからです。もちろん、オンラインとオフラインで参加者の行動が大きく変わる可能性はあるわけですが。

運営体制

今年は新しい運営メンバーを3名迎えての出発となりました。今年の運営チームは例年にも増して自発的に行動してくれるメンバーが多く、多いに助けられつつ運営を行うことができました。特に当日の託児サポートやMiroの準備などは私はほとんど何もしておらず、主体的に発言し動いてくれたメンバーがいてこそ成り立ったものでした。

運営メンバーといえば、今年はunasukem_yamashiifu-gaの3名が運営の感想を書いてくれていますね。そちらも併せて読んでいただくとよく多角的に伝わってくるのではないかと思います。

来年の話

これを書いている時点で2023年まであと2時間を切っているのですが、来年は運営メンバーも大幅に増え、オフラインでの開催を行うことが決まっています。これまで得てきた経験値が部分的にリセットされてしまう面はあるのですが、それ以上にオフラインでのカンファレンスはとても楽しいのでわくわくしながらやっていきたいなと思っています。来年もよろしくお願いします。

それでは、良いお年を!

おまけ

バーチャル背景を置いておきますね。

Kaigi on Rails 2022 バーチャル背景