手を動かした内容が日々の業務の中であっても全く問題ありません。各社が業務内で行ったことは公開されにくく、しかし実際に共有されると多くの人の役に立つという性質を持っています。Kaigi on Railsは特に「明日からの仕事に役立て」るということがコンセプトの一つになっているため、業務に直結した内容は比較的通りやすい傾向があります。
今まさに説明した「方針の違い」というのは非常に重要です。方針に反するプロポーザルは原則として通りません。これらの方針は明記されている場合とそうでない場合があります。Kaigi on RailsではCFPページがありそこに具体例が挙げられています。もし不安がある場合は過去のトークを見てみるとよいでしょう。
Kaigi on Railsの場合、CFPページに「Rubyに特化した話題については、優先度が下がるかもしれません」と明記されています。こういった方針に関しては事前に把握してプロポーザルを出すことが求められています。
残念なことに、提出された全てのプロポーザルに対して主催側がフィードバックをすることは各種の制約により不可能です。ですが、個別にフィードバックを求められた場合は応じるケースもあります（Kaigi on Railsでは可能な限り応えたいと思っています）。もしいいプロポーザルを書けたはずなのに落ちてしまったなら、主催者にコンタクトを取ってみてもよいかもしれません。プロポーザルの提出に使われているアプリケーションによってはその中でやりとりをすることも可能ですが、他の手段もあります。
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 improveRuby 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 improveRuby 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 :)
Music Mixinも今年初めて参加してみましたが、20時から2時までずっと会場にいて色々な人と話せてとても楽しかったです。最終日なので次の日のことをあまり気にする必要がなかったので、そのままラーメンから居酒屋をはしごし、最後には川に到達してそのまま明るくなるまで飲んでいました。こういう体験はRubyKaigiならではだなと思うのですが、それが楽しいという感覚に大きく寄与しているのは間違いありません。
Hi Rubyist, I now have another #kaigieffect, I started to listen to English podcasts! I found myself not very good at listening, so this is my attempt to improve myself for next Kaigi (or maybe, conferences outside of Japan?)
そこで2022年は「オンラインでのやり残しがないようにする」ということが個人的な気持ちとしてありました。一方では「オンラインでやるには相対的にコストがかかりすぎる、あるいは効果が低すぎる」ものもあります。例えばワークショップ的なものはやりたかったのですが、オンラインで行なうと理想的な体験にならない可能性が高いこともあり、企画としては自然消滅しました。最終的には、2021年の方向性を踏襲しつつ、運営に負担のかかり過ぎない形での実現を目指すことになりました。というのは、オンラインカンファレンスとしてのKaigi on Rails 2021はすでに結構がんばっていたからです。
Kaigi on Rails 2021は10月の後半にあったのですが、そこから今まで2ヶ月でも結構色々なことがありました。
各種登壇
まず、Kaigi on Railsの準備期間中に密かにRubyConf 2021での発表のために動画を収録していました。この動画でもってRubyConf初登壇をすることができました。今年のRubyConfはハイブリッド開催であったこともあり、自分の発表がどれくらい反響があったのかはよくわかりませんが（多分あまりなかった）、英語で30分話すのは良い経験になりました。録画の際にConfreaksの人が手伝ってくれるというのがなかなか面白かったです。
