00:08
はい、こんにちは、tanakenです。 tanaken on Railsと題して、Railsに関して
喋る番組をちょっとやってみようかなと思います。今年、2024年ですね。今、1月の6日でございます。
2024年の一つのテーマとして、自分の庭を広げていこうというのを掲げておりまして、
自分の得意とする分野の一つとして、Ruby on Railsがあるんですけども、
得意と言ってはいるものの、最近のRailsがどういうふうに変化していってるのかというのを、
あんまり実は追いかけていってないよねと。お仕事でやる分には、最新情報を追いかけなくてもできちゃったりする部分はあったりするんですけども、
とはいえね、今後お仕事をする中でもRailsのバージョンとかね、上げていったりする中で新しい機能を使ったりとか、
これから新しくアプリケーションを作るというときに、Railsアプリケーションをゼロから作るってことももちろん今後たくさんあると思うので、
そういったときにね、最近のRailsがどうなってるのかっていうのをね、知っていると良いのではないかなと思って、
そんな思いでRailsについてしゃべる番組をやってみようと思い立ったという経緯でございます。
で、何をしていくかというと、
This Week in Railsというね、ウェブサイト、ウェブサービスサイトがありまして、そこで毎週金曜日にね、
えー、まあRailsのこの1週間での差分がどんなものだったのかというのはね、記事として発行されておりまして、
まあ日本時間で言うと、土曜日のね、朝8時ぐらいかなに更新される、というか第1回はそうでした。
で、ちょっと分かんないんですけど、第1回というか、えっと2024年の1発目はそうだったんですけど、
えーと、多分この運営されているのがhey.comさんなので、
向こうの現地時間で言うところの、えーと、金曜日の23時頃かな、多分に更新されたのかなと予想しているんですけども、
まあまあそんな感じで、このページが毎週1記事ずつ生成されていくので、
じゃあ自分としてはそれを翌日の土曜日に読んで、えー気になったことをしゃべるみたいなのを毎週土曜日にやるといいんじゃないかと。
はい、まあコンテンツはRailsさんが提供してくれるから、それをただ読んで感想を読むみたいな、感想を述べるみたいな感じでやっていったら楽なんじゃないかという、
03:08
まあ継続性もね考えた上での、はい、そんな感じでちょっとやってみようかなと思ってやってみております。
はい、さてさて、じゃあ、えー、第1月の1発目ですね、はい、えー1月5日として配信された記事でいくつかあるんですけども、
その中で気になったのが3つ、まあ3つのプレリクエストが気になったんで、それをちょっと見ていこうと思います。
はい、1つ目、えー、Default to creating GitHub CI filesというプレリクエストですね、はい、えーこれは何かというと、えー、まあRails入手したときのデフォルトの設定ファイル、デフォルトで生成される設定ファイルが増えましたと。
で、えー、GitHub ActionsでCIを回すための、えー、まあ.GitHubすら、えー、Workflowsすら、えー、CI.yamlですね、このCI.yamlファイルが作られるようになりましたよというやつですね。
で、まあ、えー、これもDHHさんが、えー、出してるプレリクなんですけども、まあ実質ね、GitHub ActionsでのCIを実行するっていうのが、まあみんなが第一の選択肢として取る、えー、なんだろうな、CIのまあ仕組みというかになってるよね、まあデファクトスタンダードになってるよねっていう話だというふうに思ってます。
もちろんね、CIをやってくれるサービス、サークルCIとか、まあいろいろあると思うんですけど他にも、まあ小さなアプリケーションを作り始めてGitHubでコード、ソースコードを管理するってなったら、まあGitHub ActionsでCIを回すっていうのが一番最初に取る選択肢になるよなと、まあ現在、2024年現在であれば、まあそうなるんだろうなというのは僕も理解ができるんで。
なのでまあそういうファイルがデフォルトで生成されるようになったよというので、はい、そうなんですね、という感じですね。
で、スキップCIというオプションをつけると、この設定ファイル、CI.yamlの生成をスキップすることができるようになっているよということでした。
はい、続いて2個目。
2個目は、Add Rate Limiting to Action Controller via the kredis limiter typeというプリクエストですね。
何を言っているかというと、アクションコントローラにレートリミットを追加できるようになったよと。
06:01
で、何を使っているかというと、kredisというものを使って、limiter typeという、kredisという仕組みのlimiter typeというのを使ってコントローラにレートリミットを設定できるようになりましたというプリクエストですね。
で、これ何かというと、kredisという、読み方がkredisで合っているのかはちょっと分からないんですが、kredisというGEMをDHAさんが作っておりまして、このGEMがRAILSに追加されたと。
はい、で、kredisはkeyedredis、キー、鍵、キーですね、keyedredis、redisはキャッシュ、キーバリューストアのredisですね。
で、keyedredisの略だというふうにリポジトリに書いてありました。
で、keyedredis何かというと、高レベルの型とデータ構造をカプセル化してくれる仕組みですね。
で、これredisにkeyedvalueで値を保存するredisを使われている方多いと思うんですけども、redisで扱えるデータ構造自体には限りがあって、
文字列とか、あといろいろハッシュとかも渡せるのかな、ハッシュというか何だろう、Rubyのハッシュオブジェクトという表現じゃなくて、
これwikipediaに見たんですけど、いくつかデータ構造扱えるものがあるはあるんですよ。
とはいえちょっと限りはあって、今ちょっと先走って言ったように、Rubyのオブジェクトをそのまま扱うことっていうのはできないんですよね。
で、例えばRubyのオブジェクト様々ありますけど、例えばデイトオブジェクトとか、
ストリングオブジェクトって言うとあれだけど、Rubyプログラミングとしてのオブジェクト様々、全部オブジェクトなんで様々あると思うんですけど、
それを直接そのまま扱うことは本来はできないと。
なので、それを何らかの方法で変換して、プログラム上は吉名に組んでいる、実装されているっていう状況、どんな環境においても多分そうだと思うんですけど、
そういった状況に対して一つの手段としてK-Redisっていうものを提供してくれていると。
で、このK-Redisっていうのを使うと、その辺の変換をすごく上手にやってくれて、
Rubyのオブジェクトをそのまま扱えるっていうふうな、そういったジェムになっているというふうに田中けんは認識をしました。
で、例えば何かっていうと、サンプルコードがK-RedisのGitHubに、 GitHub.com//rails//k-redisっていうリポジトリにあるんですけども、
09:10
K-Redis.hogehogehという形で、そこにいろんなRubyのオブジェクトとして扱いたいもの、型を指定するみたいな感じになってるんですけど、
例えばだと、k-redis.decimalみたいな感じで、.decimalっていうメソッドがあって、
その引数にレディスに保存するときのキー、キーとなる文字列を入れます。
で、k-redis.decimal、例えばマイデシマルみたいなキーで、これから値を保存するぞというので、
で、そのk-redis.decimal、マイデシマルみたいな、そこで作ったオブジェクトに対して.valueというメソッドを呼んで、.value="というメソッドで何か値を、
大きなデシマル、ビッグデシマルの値を例えば入れると。
で、その値自体はvalue="メソッドを呼んだ時点で、レディスにセット、レディスのセットメソッドっていうのがこれ、セットを呼び出して、
マイデシマルというキーで、例えばビッグデシマルで計算した値を突っ込むみたいなことをまずやってると。
ここでレディスとの疎通があるわけなんですよね、多分ね。
で、さっき初期化したk-redis.decimal、マイデシマルっていうメソッドで作ったk-redisのオブジェクトに.value="というメソッドを呼び出すと、
レディスに保存されている値をゲットしてきて、その値をビッグデシマルに変換したもの、ビッグデシマルのオブジェクトとして取り扱うことが、すぐに取り扱うことができると。
で、本来だったらレディスに保存されている値は多分文字列としてレディスに保存されちゃってるので、
その文字列をビッグデシマルに変換するみたいなことをアプリケーションコードで実装しなきゃいけないんですけど、
そういったことをやらずに、Rubyのビッグデシマルオブジェクトとして取り扱うことができるみたいな、そんな感じの便利なGemになっておると。
めっちゃしゃべっちゃった。
12:02
ここまでがk-redisというGemの、僕が理解した説明ですね。
このk-redisというGemを使って、Controllerのコントローラーファイルでレートリミットを実装できるようにしたよというのがこのプルリクでございます。
k-redisにはLimiterというタイプみたいなものがあって、
Limiterは引数にまずはKeyの、レディスに突っ込むときのKeyとなる文字列が第一引数にあって、
その後キーワード引数でLimitというものとExpiresInみたいなものを指定できるようになっていると。
他にもいくつかキーワード引数で指定できるものがあるんですけど、
シンプルに言うとLimitとExpiresIn、執行するまでの時間みたいなのとLimitは回数っていうのがあって、
そのLimiterというタイプでは、Limitキーワード引数に指定した回数だけ呼び出せて、
それを超えるとExpiresIn、超過している、Limitを超過しているよというメソッドがExceededというメソッドがあるんですけど、
そのメソッドがフォルスを返すような、そんな感じの仕組みになっていて、
このLimiterというタイプを活用することで、コントローラーのRateLimitも簡単に実装できるよと、
そんな感じのプリリックになってます。
Rails側の実装としては、コントローラーファイル、コントローラークラスの中にRate Underscore Limitというメソッドを書いて、
ここに何回許可するのかとか、何分何秒以内のリクエストを許可するのかとか、
どのアクション、例えばCreate ActionだけRate Limitを指定するのかとかっていうのを引数として設定できるような感じになっていたりしますというところですね。
はい、何だろうな、現職今の僕が携わっているアプリケーションでもRate Limitの実装ってあって、
それはコードちゃんと読んでないんで思い出さなきゃですけど、
確かラックミドルウェアで何かやっていたはず、Rate Limitの実装とかは。
15:09
その辺りをコントローラーで書けるので、わかりやすくなるかな。
コントローラーに書いてある、コントローラーでこの特定のアクションだけRate Limitを書けるとかが、
そのコントローラーを見ればわかるようになるので、まあまあ活用できそうな感じはしますね。
これもRails 8以降とかで使えるようになるのかな。
多分わかんないですけど、というような気がしてて楽しみだなと思ってます。
はい、最後3つ目。
3つ目はBump the required Ruby version to 3.1.0というプレリクエストです。
これ何かというと、やってることとしては、
Rubyのバージョン、リクワイヤードなRubyバージョンを3.1.0というふうにしますよというプレリクエストです。
そうなんだぐらいに読めるんですけど、そのプレリクエストの説明を読むと、
読んで面白かったんでピックアップしたんですけど、
これまでのRailsとRubyというのは当然、
話せないものというか、
必ず持ちつもたれつみたいなところがあると思うんですけど、
Railsのバージョンアップ、Railsのメジャーバージョンアップの時に、
Rubyのバージョンの古いもの、EOLになったRubyのバージョンの互換性を削除するというふうにこれまで運用していたらしいです。
そういうポリシーで運用されていたらしいんですよね。
このポリシーに関してもっと変えたほうがいいんじゃないかというのは提案をしていました。
何かというと、例えばRails6からRails7、最新今7系ですよね。
Rails7になったときに、Rails7の最初の7.0.0かな、が出るというタイミングで、
RubyのEOLになったバージョンの互換性を保つ、古いバージョンでも動くようにするための実装というのを、
メジャーバージョンアップの時だけ、例えばRails6からRails7になった時だけ、
例えばRuby2.6はもう古いよねって言って、2.6の互換性、2.6に気を使った処理というのを消していたという感じの運用をしていたと。
そういう運用をしていると、どういうデメリットがあるかみたいなのがあって、
まず一つは、EOLになったRubyのバージョンとの互換性をすごく長い期間維持しなければならない、
18:07
そういう場合があるよねというふうに指摘されています。
例えば今の例だと、Rails6からRails7になった時に、
多分もうRuby2.6はEOLだったと思うので、これちょっと調べてないですけど、
多分僕の感覚だとそうだった気がするんですけど、
だからRails6から7に上がった時に初めて2.6の対応が消せるってなると、
Rails6の最新、Rails6系の細かい開発、バグ修正とかやってる時もずっとRuby2.6のことを気にしなきゃいけない。
でも、Rails6の最新のバージョンをやってる頃には、
もうRuby2.6はEOLだったかもしれないのに、
もうEOLなのになんでこんなに気にして実装しなきゃいけないんだ、
みたいなことが多分あったんだろうというふうに予想します。
そういうことを指摘されている。
なので、古いバージョンを意識して長期間メンテナンスしなきゃいけないっていうのは、
精査性が下がるんじゃないかみたいな感じの多分指摘なんですよね。
2点目として、Railsのメジャーバージョンアップの際に、
複数のRubyのバージョンがEOLになってた場合ですね、
を一気に削除しなきゃいけなくなる、そういう場合もあると。
ということですね。
これは分かんないですけど、RailsバージョンNみたいなものが仮にあったとして、
バージョンNプラ1に上げますと、
その時にRubyのバージョンが複数EOLになっていたと、
その2つのRailsNからRailsNプラ1に上がるまでの間に、
複数のバージョンがEOLになってた場合に、一気に対応バージョンが減るっていう風になって、
その時の対応項数というか対応の手数とか増えるし、
リスクもあるみたいなことだと思うんですよね。
ちょっと細かいことはあまり書かれてなかったですけど、
複数のバージョンの互換性を一気に消さなきゃいけないよねというので、
そういうのってあんまり対応するサイクルとしてあんまり良くないんじゃないか、
みたいなことが言われていたということです。
はあそうなんだということで、
このプレディックでは何をやったかというと、
このプレディックのbeforeプレディックを出す前の状況だと、
Ruby2.7をサポートしているRailsのメインブランチで、
21:00
Ruby2.7をサポートしている状態だったんですけど、
もう2.7はEOLになっているので、
2.7よりも上げましょうというのがまず大前提としてあるし、
Rubyの3.0も2024年の3月末をもってEOLになるので、
もうRuby3.0に関しても対応しないサポート切っちゃおうぜと、
そういう対応しましょうぜというプルリクエストになっています。
なのでRuby3.1というのを最新のRailsではサポートで3.1以上というふうにしましょうと。
Ruby3.0は3月にEOLになるし、
Rails今7.1系が最新なんですけど、
Rails7.2系というのは3月中にリリースする、
2月、3月、この1,2,3月の間にリリースするという予定はないので、
早くても4月以降になるはずなので、
このRails7.2がリリースされる頃にはもう絶対Ruby3.0はEOLになっているから、
だったらもう3.1以上というのをRailsの必要なバージョン、
RailsでRubyの必要なバージョンというふうに指定してしまっていいよねということで、
そういった対応をしているということですね。
はい。
はい、という形で、
RailsバージョンアップとRubyとの関係性、
Rubyの互換性削除のポリシーとかを僕は全然知らなかったので、
ああそういうもんだんだと、今までそうだったんだというのと、
それに対する提案、こうした方がいいんじゃないかみたいなのを考えて、
プレリクエストを出されている方がいるんだなということで、
勉強になったなという感じでございました。
はい、以上3つでございました。
もう1回振り返ると、1個目がデフォルトでGitHub ActionsのCIを回す設定というのが
追加されるようになりましたというのと、
コントローラーでレイトリミットの実装が簡単にできるようになりました。
そのためにk-redisというgemを使うようになりましたという話と、
3つ目がRailsにおけるRubyの必要なバージョンを3.1以上というふうにしましたよと、
経緯はこれこれ、バージョンアップポリシー、メンテナンスポリシーがこういうふうに変えていったらいいんじゃないかみたいな、
そういう提案も含めて変わりましたよと、
なんかそんな感じのお話になっております。
はい、よっしゃ。
24:00
はい、という感じで毎週1本ね、Railsについて喋るというのをやってみようと思います。
はい、ちょっとねソースコードの部分はね、口で喋るのはかなり難しいので、
どうしようかなという感じではあるんですけど、
はい、まあなんか自分のためにやってるところがね、かなり98%ぐらいあるんで、
残りの2%ぐらいで皆さんが楽しんでいただければみたいな、何かの役に立てばぐらいで思っております。
はい、よし、じゃあこんなところで、第1回のたなけんonRails終わりにしたいと思います。
はい、では皆さんまた来週。バイバイ。
