Kaigi on Rails 2025 に参加してきたよ
Kaigi on Rails 2025に参加してきた
まず最初に、早押しボタンの話は別のブログでちゃんと書きます。こちらは私の参加記です。
参加してきました。例年は全部の時間にセッションの予定を詰め込んで丸二日間インプットの日だったんですが、今年はブース担当になったというのもありセッション半分ブース半分くらいの比重で参加していました。昼休みもほとんどブースに居たので、友達に挨拶する時間が減ってしまったのがやや心残りでした。
Kaigi on Rails 2025のプロポーザルが不採択だったので公開します
Kaigi on Rails 2025には3本のプロポーザルを提出しましたが、全て不採用だったので公開します。誰かの参考になると嬉しいです。
PicoRuby Overflow会議 に参加してきた
大阪や！（3週間ぶり）
関西Ruby会議08の熱も冷めやらぬまま、再び大阪に来た。正確に言うと関西Ruby会議は京都だったので3週間ぶりでは無いのだが、まあ関西だし似たようなモノだろう。石を投げないでください。僕は子供の頃、大阪と京都の県境を反復横跳びできるようなところにいたことがあるので仕方ないのだ。
関西Ruby会議08に送ったCFPは全てRejectされたものの、PicoRubyを使って子供のオモチャをつくろうという方のプロポーザルはOverflow会議に再度応募して欲しいという連絡が来て、送ったらショウケースセッションとして通ったので展示してきた。行きの新幹線でポスターを必死こいてつくってたのに、駅に着いたら印刷する方法が無くてコンビニでA4印刷したモノを机に置くことになった。
関西Ruby会議08、Rubyで作る物語
京都に行ってきました。関西Ruby会議08です。
Rubyと作ろう
関西Ruby会議08のテーマは、「Rubyと作ろう」でした。これを見て、僕は普通にRubyのコードを書いたり、プロダクトを作ることだと思っていました。だけど、当日に会場に居て、一つ一つのトークを聞いて、最後に締めの挨拶を聞いたときに、なるほどRubyはこの場の全てを作ったんだとしみじみ感じました。関西Ruby会議08そのものが、RubyとRubyが好きな人たちと、Rubyのコミュニティの力で作られていました。CFPにプロポーザルを出したときは深く考えていませんでしたが、当日はRubyがこの場を作ったのだという、壮大な物語の中に居ました。
関西Ruby会議08のプロポーザル落ちたので公開します
関西Ruby会議08のプロポーザルを2本送ったのですが、力及ばず採択されなかったため公開します。
今回は2本送ったのですが、1本はもう少しブラッシュアップして、またそのうちどこか違うイベントに送って再利用しようと思います。
1本目
Title (Publicly viewable title. Ideally catchy, interesting, essence of the talk. Limited to 60 characters.)
Solid State Society
Session format (Fixed at 20 minutes.)
Abstract (A concise, engaging description for the public program. Limited to 600 characters.)
Rails 8 では、rails new をしたときにSolidQueue、SolidCache、SolidCableという3つのgemが標準で有効化されるようになりました。これらSolidの名を冠するGemは、それぞれActiveJob、ActiveSupport::Cache、ActionCableのバックエンドにデータベースを使用します。このデータベースはSSD上で動作していることが期待され、Solidという名前の由来もSSDからきています。また、Rails 8 からはProduction環境でのSQLite利用が推進されています。そしてこのSQLiteとSolid gemsのシナジーが、Railsの生産性をさらに加速させてくれます。このトークでは、SolidとSQLiteを使用することで、0->1開発の景色がどれだけ変わるかを皆さんにお伝えしたいと思います。
Details (Provide an overview, expected outcomes, target audience, and any other relevant details.)
SolidQueue、SolidCache、SolidCableだけではなく、ActiveRecord::SessionStore、ActiveStorageDBを使い完全にSolidなRailsアプリケーションを開発体験をお伝えしたいと思います。 Railsはかなり容易に0->1ができるフレームワークですが、一方でRails 7 までは本番環境の構築にはRailsが動く実行環境に加え、PosrgreSQL/MySQLとRedisがほぼ必須のミドルウェアとして要求されていました。しかし、Rails 8の登場で本番環境でのSQLiteが推奨され、さらにSolid gemsが標準化されたことで、本番環境にRailsが動く実行環境以外のミドルウェアは基本的に必要なくなりました。このトークでは、さらにSessionStoreとActiveStorageもDB化することによって、真にSQLite以外を必要としないRailsの開発体験の話をします。本番環境でのインフラ構築に悩まないことが、どれだけ開発におけるマインドシェアを奪われず開発に集中することができるかを伝えたいと思います。 また、SQLiteを使うことによって生じるデプロイの難しさや、環境の制約についてもお話しします。特にクラウド環境でSQLiteを使う場合、複数のインスタンスにDBファイルが存在することは基本的にできず、取り回しが非常に難しいです。なるべくサーバレスサービスを使わず、同じくRails 8 で標準化したデプロイツールであるkamalを使うことが現状ではベストプラクティスになるという結論です。 このトークの対象者は、まだRails 8でrails newをしたことがない人たちです。新しいプロダクトを思いついたとき、難しいインフラ構成を考慮せず最速で本番環境まで持って行ける体験の良さを、まだSolidを使ったことが無い多くの人に伝えたいです。
このトークは、次のテックブログにて書かれているRubyKaigiのスケジュールアプリ構築の話をベースとします。 https://tech.smarthr.jp/entry/2025/04/17/185354
Pitch (Explain why your proposal should be accepted and why you are the right person to speak on this topic.)
Rails 8 は、DHHが言うとおり0->1からIPOまでを全てこなせるフレームワークです。その真の実力を少しでも伝えることで、聴講者の中から起業とIPOを目指そうと思う人が出るかも知れない、つまりRubyで会社を作ろうと思ってくれるかもしれない可能性があることが、このトークを採択すべき理由です。私は実際に数百人が利用するRubyKaigiのスケジュールアプリを完全にSQLiteだけで運用した実績があり、その良さと悪さは十分に知っています。ゆえに私だからできるトークであり、私が公演するにふさわしい理由です。
Your Name (A publicly visible name or ID.)
kinoppyd
Speaker Bio (A short introduction about yourself, related to your talk. **Limited to 500 characters.**)
A Ruby programmer work at SmartHR Ltd, Inc.
2本目
Title (Publicly viewable title. Ideally catchy, interesting, essence of the talk. Limited to 60 characters.)
Rubyでつくって子供と遊ぼう
Session format (Fixed at 20 minutes.)
Abstract (A concise, engaging description for the public program. Limited to 600 characters.)
Raspberry Pi Pico と PicoRubyを使って電子工作すると、オモチャが作れるらしいんですよ。つまりそのオモチャを使って遊んでいる子供は、もはやRubyistと言っても過言ではないですよね？ 自分の子供をエリートRubyistにするために、PicoRubyでオモチャを作ってみよう。
Details (Provide an overview, expected outcomes, target audience, and any other relevant details.)
マジな話、作る予定はあるんですが今のところ全く何もできてないんですよ。たとえば光るスイッチを一杯つけたり、音を鳴らしたり、そういう子供が好きなことができるはずなんです、PicoRubyを使えば。だってほぼ同じ要件のキーボードができるんだから。 GWを利用して子供にPicoRubyでオモチャを作ってあげる実験をしようと思っています。アイディアとしては、7セグ電卓やフィンガードラムなんかは作れそうだなと思いつつ、そこにRubyらしさをどう混ぜていくかを工夫することになると思います。その成果物に関して話すことになりますが、これを書いている今のところ何の成果物もないので、当日のお楽しみになります。
Pitch (Explain why your proposal should be accepted and why you are the right person to speak on this topic.)
もしまかりまちがってこれが採択された場合、締め切り駆動開発で苦しむ私を見ることができます。
Your Name (A publicly visible name or ID.)
kinoppyd
Speaker Bio (A short introduction about yourself, related to your talk. **Limited to 500 characters.**)
A Ruby programmer work at SmartHR Ltd, Inc.
RubyKaigi2025の帰り道
今年も浴びた。RubyKaigiを。来年も浴びたい。これは帰りの飛行機を待つ空港で書いているので、完全に内容がとりとめないし、散文的だ。
前提
RubyKaigi is 最高の Event of the World.
2025
今年のRubyKaigiは、思っていたよりも特定の話題に対するフォーカスが少なかった。2024はパーサー、2023はJIT、2022はRBSみたいな、なんかその年のぼんやりと見えてくる「みんなこの話してる」ってのがあまりなく、広くいろんな物事を吸収できた年であった気がする。とはいえ、パーサーの話もJITの話もRBSの話もそこそこたくさんあったので、目立つトピックが飽和してきただけかも知れない。わりと大きな関心事であるNamespaceも、実質一人開発なので1トラックで終わってしまうし。
代わりにというほどかどうかはわからないけど、今年は音とゲームがものすごく目立っていた気がする。いろんな音が世の中にはある。それはそう。様々なゲームが世の中にはある。それもそう。だから音とゲームは我々を引きつけてやまないのだ。来年はもっと音だしてこ。
C？
今年はCレイヤーAPIの話が何となく多かった気がする。気がするだけかも知れないけど、プロファイラ文脈やC ext文脈、あとはand worldのC API 作り直したい話とか、色々あった気がする。とはいえ、RubyKaigiはCの話をするところなので、Cの話は元々多い。どちらかというと、Rubyの実行環境の世界からCに触る話が多かったという印象かもしれない。
サチュレーション？
改めて今年のセッション一覧を見渡すと、やっぱりパーサー、RBS、JIT、WASMの話が多くて、それぞれを合わせると全体の約半分ほどを占めている気がする。これは話題の中心が増えすぎてサチったのだろうか？ と思わなくもない。あとはプロファイラ、GC、JRuby、mrubyやPicoRubyの話がラインナップとしては多いような気がする。
JRuby、そういえばJRubyの話を全然聞いていなかった。一つくらい聞けば良かったと思った。いや、でもパーサーもRBSもJITもWASMも全部気になるんだよなぁ……体を三分割したい。いや、3倍に増えたい。
キーノート
キーノートは全部素晴らしかった。文字コード、だいたいまあ死んだ顔で何がつらいのかを語る人が多いけど、ima1zumiさんは楽しそうだった。すごく良い。文字とか時間とか、人間の営みとともに変化してきた伝統あるブツの話は基本的に聞いていて楽しい。Low-Level APIを使ってRubyのオブザーバビリティを高めるIvo さんの話もすごく良かった。朝イチであの圧倒的物量の英語にはちょっとビビったが、それでもわくわくする話だった。今日の朝に大街道ですれ違ったので「hi!」って言いながら手を振って挨拶した。よく考えたらDay2の感想でも伝えれば良かった気もするが、荷物が重くて元気が出なかった。Matzは手を替え品を変え毎年同じような話をしているが、4.0の話はブチ上がる。奈落からせり上がってくるMatzも最高だった。
音とゲーム
音はやはりアツいと思う。ゲームもアツい。
音、良いんですよね。MusicMixinもそうだけど、やはり音楽は人を興奮させる。Rubyで音が出るなら自分もやってみたいけど、作曲に対する造詣がないので今年はそっちを鍛えた方が良さそうな気がする。
コンソールで動くゲームもすごく良いですよね。自分が子供の頃のパソコンのゲームは既にAge of Empireとかだったので、もっとこういう文化もくらっていきたい。
心配事
嬉しいことにここ2年で子供が二人産まれたが、まだ二人とも本当に小さく、妻一人に子供二人を預けたまま四日間も家を離れることはとても心苦しい。実際に僕がいない間、妻はとても苦労している。妻に苦労を掛けていることを気にしてしまって、どこか全力で楽しめないので良くない気持ちのループになる。託児サービスを利用するのも考えたが、家には猫が居るので四日間も家を空けられない。子供がもう少し大きくなるまでは、毎年この時期はこの悩みに苛まされそうである。珍しく人生をやっている。
Rails8の認証機能と、俺たちのアイデンティティ
かかってこいよ、クリスマス。そうです、私がkinoppydです。
この記事は、SmartHR Advent Calendar 2024 Day1 のエントリーです
Rails8の認証機能
Rails8では、新たにユーザーの認証機能のジェネレーターが追加されています。これは何かというと、これまで多くのユーザーがdeviseやrodauthというGemを使って実現してきたユーザーの認証機能を、Railsの標準機能として生成できるものです。とはいっても、もちろんdeviseやrodauthのようにユーザーの認証に関わる広く高度な機能を提供するわけではありません。提供されるのはユーザー名とパスワードの組み合わせでログインセッションを作成するための一通りの機能のみです。例えば、MFAであったり、データの認可機能、テストヘルパーの提供などはありません。なんなら、ユーザーを新たにサインアップする機能すらありません。デフォルトのままでは、データベースにコンソールから直接ユーザー登録が必要です。
Kaigi on Rails 2024 の感想がようやく書ける
Kaigi on Rails 2024に参加してきました。諸々あってブログを書けるようになるまでめちゃくちゃ時間がかかってしまった。マジで何もできなくなることが世の中にはある。
Kaigi on Rails 2024 と哲学
光の道、導きの星が今年のテーマだった。気がする。それはつまりRails wayと呼ばれるモノでああり、結果として生まれてくるのが概念圧縮であったりThe One Person Frameworkと呼ばれるモノであったりする。
Railsを使っていると、誰もが迷う。0 to 1は特に迷わない。1 to IPOの時に、多くの迷いが生まれてくる。その多くの迷いに立ち向かうための話が、二つの基調講演で違う角度から語られていた。ひとつは、Railsが提供してくれるレールを尊重すること。アプリケーションを拡張したいときは、Railsの流儀を身に着け、自らのコードに応用していくということ。もうひとつは、オプションを手に入れること。常にアプリケーションをシンプルに保ち、変化に追従できるようになっておくこと。これらを光の道、導きの星として解説したのが2024のキーノートであり、深く感銘を受けたポイントだった。そしてRails自身も、メジャーバージョン8を迎えており、自らRails wayの大切さと、変化と柔軟さを体現していると言える。もちろん、ユーザーとしてそれに追従するのはまあ大変なのだけど。
Rails wayという言葉と自分がどこで出会ったのかは覚えていないが、元の本を読んでいないのでおそらく誰かから聞いた話だと思う。人には人のRails way、とまでは言わないが、俺の考えた最強のRailsが世の中にはそれなりに転がっている気がする。なんなら、Railsを書いていない人でさえも俺の考える最強のRailsを持ってインターネットに殴り込みをかけている気すらする。間違った導きの星は、人を迷わせる。だからこそ、ここ数年のRailsは様々な方法で正しい光の道が見えるように誘導しているようにも思えた。Hotwireの導入や、Omakaseの概念、Onceのコード公開、他にも色々。また、今回のセッションの中でも、モデルの育て方、データマイグレーションの標準への疑問など、様々なRails wayへの問いかけがあった。光の道、導きの星は宗教っぽいアンセムでなんか怖いなぁと思いつつも、人々が集まり哲学への問いかけを続けるZENとしてカンファレンス、それがKaigi on Railsだなと実感した。まあお前ら、Rails Guide何度も読み返せってことだ。Rails8ではRails Guideも強くなってるしな。
特に心に食らったセッションの感想
当日直接聞いたセッションと、残念ながら当日聞くことができず後日スライドを見たものがある。
Identifying User Identity
今回一番心に食らったのがこのセッションで、勇気と感動をもらった。 Userテーブルには何も情報を載せず関連テーブルで表現するというスタイル、自分もうっすらとメリットを感じていて個人開発のプロダクトではずっと続けていたのだけど、本当にそのうっすらとした感覚が正しいのかどうかの確信がいまいち持てず（なんせ個人開発なので、あまり派手な問題というモノに遭遇しない）、うまく言語化ができていなかった。そんなところにこのセッションをぶちこまれたので、ああ自分が思っていたうっすらとした感覚の正体はこれだったのかと変に感極まってしまったので一番食らったセッションになった。IdentityとIdentifyされたユーザーの情報は別で成立するんだ、というのがスッと入ってきて、なんだか嬉しい気持ちになった。スライドの中には書かれていなかったけど、Identityとユーザー情報を分割するメリットとして、ペルソナやの切り替えや認証情報の切り替えの実装が楽だというのも自分がうっすらと感じていたメリットで、その考えがさらに補強されるようで励まされた様な気持ちにもなった。 また、最後のユーザーの状態をstatus列無しでリレーションで表現できる、という考え方が凄くクールで、完全に食らってしまった。最高。ベストセッション。
Data Migration on Rails
このセッションが好きな理由は、光の道、導きの星が存在していない領域の話だったから。スキーマのマイグレーションでは無く、データのマイグレーション、もっと一般化すればワンタイムのスクリプトをどのように管理するかという手段をRailsは提供していない。もちろんDHHのお気持ち的なモノはあるみたいだけど、Railsの実装としてそれが示されておらず、Rails guideでも扱われていない。つまり、光の道、導きの星がないものを我々はどう扱えばいいのか、という話だった。実際のところ、多くの話題は光の道、導きの星が無いという話なんだけど、これだけ多くの人が同じ事をやっているにも関わらず、光の道が無いというのはなかなか奇妙な気がしたので、特に気になった。リアルワールドでは同じ目的で山のような数のGemがあり、Gemだけでは無くMakefileやShellスクリプトまで多岐にわたる様々な道しるべが用いられている。黄金律の修復が待たれる。王になれ。
Railsの仕組みを理解してモデルを上手に育てる
このセッションは当日聴いておらず、後日に資料を見て「うわっ、なんて素晴らしいんだ……」と思ったやつ。Railsをやっていると必ず迷う「複雑なフォーム」という問題に対して、光の道を示すためのガイド。Railsをやる人は、みんなこのスライドを胸に刻んでやると良いと思う。フォームオブジェクトの扱い方に関して、ここまできちんとわかりやすく言語化してまとめ上げた資料ってあまり見た覚えがないので、今後のRailsに参加する人たちは必読になると思う。本当に良いスライド。
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ
これは完全に感情の問題なんですけど、ハイトラフィックの厳しい環境で手を替え品を替え戦い抜く話、聴いててビリビリするんですよね。勇気が沸いてくる。UPDATE SKIP LOCKEDすごいね。そんなセッションでした。
推し活としてのrails new
これも当日聴いてないんですが、良いんですよスライドが。開発者としての喜びとは本当にこういうモノだな、ものづくりの楽しさってこれだな、って感じられる話本当に大好きなんですよ。自分が作ったモノが誰かに使われて喜ばれるっていう、プリミティブな感情を味わいたいんですよ！！！！ 最高！！！
まとめ
Kaigi on Rails、ホンマに良いカンファレンスやなぁ……来年こそCFP通すぞ。
大阪Ruby会議04に参加＆登壇してきました
大阪Ruby会議04
大阪で2024/08/24に開催された大阪Ruby会議04に参加してきました。
最近はCFP不採択続きだったのですが、すごく久々に採択されたのでHotwireの話をしてきました。
Day0
チーフオーガナイザーの@ydah_さんからお声がけをいただき、クラフトビールのお店でDay0を仕上げていました。
めっちゃビールが美味しかったのでバンバンおかわりを繰り返しながら、@hasumikinさんの「mruby/cの/cって何者なんだ」の話とか、@sanfrecce_osakaさんのハンドルの謎とかを聞いて楽しく過ごしていました。
先日、声優の田中敦子さんが亡くなられてしまったため、非常に悲しい気持ちで少佐の描かれたTシャツを着ていったところ、何人もの方に「それは喪に服しているんですか」と気づいてもらえたり、@joker1007さんに「つらいよね、登壇するときってメンタルの状態も大事だからね、わかる」と励ましてもらったりして、なんて温かいコミュニティだと一人噛み締めていました。
Day1
登壇しました。RubyKaigiのスケジュールアプリのフロントをHotwireで作り直したので、Hotwireがどれだけ便利で、けど気を使うところが多くて、それでいて良いものなのかというのを伝えました。セッションの詳細な解説に関しては、会社の方のブログで書こうかと思います。
今回の大阪Ruby会議04、何故か不思議なことにみんな文字列の処理の話をしていましたね。キーノートのお二人はもちろんのこと、Rubyのソースコードの文字列を短くしたり、変な形にしたり、画面に描写したり、文字列をスキャンしたり、Rustでバインディングを書いたり、ActiveRecordのコールバックがむずかったり、dRubyが良かったり。最後の方は文字列かどうかはさておき、人類は皆文字列を操作することがどれだけ難しいかということを意識していのだなとしみじみ感じました。
今回の感覚として、どのトークもかなりボリュームがあって、一日のカンファレンスとは思えないくらい頭使ったなという感想があった。結構バッキバキに心を刺激されるタイプの地域Ruby会議で、すごく満足度が高かった。一番印象に残ったのはぺん！さんの、コンソールのテキストレンダリングと3Dプログラミングの話だったかなぁ。終始「なるほどなぁ……」と思い続けた。
アフターパーティーもとても楽しくて、@makicamelさんと「小さなツールを作っていくの良いですよね！」と話していたり、@koicさんに「事前にRubocopかけたコードをMinifyした文字列にもう一回Rubocopかけたら、論理的に完全にもとに戻りますか？」とか聞いていた。理論上戻るとのこと。@hasumikinさんのキーノートで折に触れて語られていた「隙間産業」という言葉を、僕はベンチャーだと捉えましたというやや気持ちがキマった感想とかを伝えていました。
最終的に、三件目のお店でたこ焼きと焼きそばを食べながら、謎の電光掲示板の謎をみんなで解き明かしていた。楽しかった。
Day2
中之島には文化的な施設が多く、とりあえずずっと行きたかった中之島美術館と中之島香雪美術館をはしごしていた。特に中之島香雪美術館の方は、大阪Ruby会議の会場であった中之島会館の隣のフロアだったので、前日からめっちゃ気になっていたため、行けてよかった。
あとはLUUPで大阪の街を適度に観光しながら、帰路につく。りくろーおじさんのケーキというのを全く知らなかったが、頼まれていたので買って帰ったら嫁に大変喜んでもらえた。
G.O.A.T
大阪Ruby会議04は、この夏最もアツい地域Ruby会議だと最初に宣言していた通り、アツかったなと思う。そんな最高な会議を開いてくれたチーフオーガナイザーのydahさんとスタッフのみなさん、そしてkyobashi.rbとRuby関西の皆さんに心からありがとうございますの気持ちです。
大阪Ruby会議04のプロポーザルが採択されたので公開します
【重要】
これはあくまでCFPの話であり、大阪Ruby会議のブログはまた別で書きます
何
タイトルの通りですが、大阪Ruby会議のプロポーザルが採択されたので、誰かの参考になればと思い公開します。
落ちたCFPは、いつも不採択がわかった瞬間に公開するのですが、採択されたCFPは実際に登壇するまでに公開してしまうとネタバレになるので、登壇後に公開する感じでやっていきます。
CFP
タイトル
RubyKaigi公式スケジュールアプリ開発で得た、Hotwireの使い方
概要
2021年から提供しているRubyKaigi公式スケジュールアプリを、2024年に全面Hotwireで書き直しました。Hotwireを使った開発体験の良いところと、良くないところ、そして実地で得たモバイル環境でのフィードバックなどをお話しします。主なトピックはTurbo関連で、Stimulusに関しては少なめです。
詳細
RubyKaigi公式のスケジュールアプリを2021年からSmartHR社のスポンサーとして提供しており、今年はReact製だったフロントを全てHotwireで書き直しました。Hotwireで実際にどれほどのモノが作れるのかというベンチマークとして、Hotwireを触ったことがない人、少し触ったけど実際のアプリに組み込むことを躊躇している人などを対象としたトークを予定しています。
以下のURLは、実際のスケジュールアプリのリポジトリです。 https://github.com/kufu/mie
主にTurboFrames、TurboStreamsを使った、SPAライクな挙動をするHotwireアプリケーションの構築について話します。 まず、TurboFramesを用いたDialog系の操作が難しいことに触れます。TurboFramesは、画面の一部を置き換えてページ遷移を避ける技術なので、モーダルなどのDialog系の操作とは相性が良くなく、それをいかにうまく見せるかを話します。また、37SignalsのCampfireがどのようにモーダルを実装しているかにも触れ、実装を比較します。 次に、Tableタグの操作をいかにTurboで変更するかが難しい話をします。Tableは、特定のセルだけでは無く周囲の行列にも影響を及ぼす変更が多いので、単純にTurboFramesで対処することができません。そのため、TurboStreamsで書き換える方法を提案します。 最後に、Turboがいかにサーバー側のレイテンシに影響されるかを話します。実際にモバイル環境では、レイテンシが大きくなるケースが多く、その場合に単純にTuborを使っているとユーザーが操作フィードバックを受ける事ができず、混乱してしまいます。そのため、できるだけ先にHTML要素を用意してTurboを使うか、またTurboのイベントを利用して通信中だということを示すかの重要性を説明します。
前のページでトークの長さが15分と30分両方選べたので両方選んでしまいましたが、どちらでも大丈夫です。
ピッチ
Hotwireはとても良くできた技術で、特にプロトタイプのアプリケーションなどを立ち上げる際に強力なツールとなります。そのため、全てのRails開発者に手段の一つとしてHotwireを選択できるくらいHotwireの良さを伝えたいなというのがプロポーザルの主な動機です。 RubyKaigiでスケジュールアプリを実際に触ってくれた人も多いと思うので、自分が触ったモノがHotwireでできている、ちゃんと動くんだということを実感してもらう事が、このトークの説得力になると考えており、自分がこのトークをするのにふさわしい理由だと思います。