00:01
第22回のtanaken on Rails始めます。
今日はですね、カフェで収録しているので、ずいぶん騒がしいんじゃないかなと思います。
でもまあ、いいかな、そういう日があっても。
今日はですね、今週のThis Week in Railsから、お知らせ1件とプレリクエストを3つ紹介します。
お知らせの1件目、RailsWorld 2024に関するお知らせですね。
スピーカーが公開されたということで、
今6月2日ですけども、6月4日ぐらいまで追加のチケットがあるみたいなことが書いてあったかな。
そんなに日本からたくさん行かれるっていう感じではないかもしれないんですけど、もし興味があれば調べてみてください。
スピーカーリストを眺めていると、このThis Week in Railsを読み始めて、
またこの人プレリクエスト出してるなとか、
このThis Week in Rails自体の執筆をされている方とかでアイコンをよく見かけている方がスピーカーの中にいたんで、
なんだかこれまでよりも親しみが湧くなという風な感想を持ちましたね。
そんな感じです。RailsWorld 2024のお知らせでした。
ここに持ってプレリクエストですね。
1つ目、Change Asset Pipeline Default to Prop Shaft in Rails 8というプレリクエストです。
Rails 8からアセットパイプラインのデフォルトライブラリーがプロップシャフトになるよというお知らせ。
お知らせというか変更ですね。
プロップシャフト自体はRails 7系から選べるようになったのかな、多分。
確かそう、Rails 7.0からだったんじゃないかな。
7系、7.0とか7.1とかだと思うんだけど。
プロップシャフトはRailsのアセットパイプライン用のライブラリーで、
GitHubリポジトリ、Rails、SDA、プロップシャフトに詳しく書いてあります。
ReadMeに色々書いてあるんですけど、それを日本語訳した記事。
テックラッチョさんで、プロップシャフトジェムリードミー翻訳というタイトルのページもあるので、
03:02
そちらを見てみるといいかなと思うんですけど。
プロップシャフトはSprocketsのような今までのライブラリと比べて、
かなり機能の数を絞ることでシンプルでかつ高速なアセットパイプラインを実現すると。
主者選択して必要な機能だけに絞ったという背景とかについてもReadMeに書いてあります。
Sprocketsからプロップシャフトに移行する場合、
今回はRails 8からデフォルトになるよという話のプリリックなんですけど、
なのでRails 8以降でRails Newするときにはプロップシャフトがデフォルトだよというだけの話なんですけど、
それ以前のアプリケーションでSprocketsを使っているなどの場合、
プロップシャフトに移行するときにはアップグレードガイドを見てくださいねということになっております。
機能をプロップシャフトでだいぶ絞っているので、
移行するときにはSprocketsで機能としてやっていたことを変わらずにそのまま移行するということになるので、
作業量はもしかしたら大きいかもしれませんということがReadMeに書いてありましたね。
移行の場合はこのアップグレードガイドに従って着実に進めていけるといいんじゃないかなと思います。
続いてプリリクエスト2つ目。
Add Rails Guide Called Tuning Performance for Deploymentというタイトルのプリリクエストですね。
Rails GuideにTuning Performance for Deploymentというページが追加されていますという話ですね。
RailsGuide.rubyonrails.orgにはまだ反映されていないんですけど、
EdgeGuys.rubyonrails.orgには反映されていますね。
そっちを読んでもらえるといいんですけど、
このガイドのページではCRubyとして知られているRubyの標準実装でアプリケーションを実行していることを前提としていて、
他のRuby、例えばJRubyとかTruffleRubyとかそういうののRuby実装を使っている場合はこのガイドは参考にできないので、
注意してくださいねという注意書きがあったりします。
このガイド自体はRailsのデフォルトのアプリケーションサーバーであるPumaのチューニング方法を主眼として紹介しています。
06:01
Pumaの重要なパフォーマンスに関する設定だったり、
パフォーマンステストの実施する方法について解説しているということですね。
ガイドが充実して嬉しいなというところですね。
最後3つ目のプレリクエストは、
Add ActiveRecord コロンコロン リレーション シャープ リードオンリー はてな
というタイトルのプレリクエストです。
こちらはアクティブレコードに関する変更です。
アクティブレコードのコアにはリードオンリー はてなというメソッドがあります。
これはリードオンリーのレコードの場合にトゥルーを返すというメソッドですね。
例えば、ユーザーズという変数にユーザー.リードオンリー.フェア アクティブ トゥルー
ユーザーのアクティブカラムがトゥルーなレコードをリードオンリーで取ってくると。
それをユーザーズという変数に入れましたよと。
ユーザーイコールユーザーズ.ファースト
ユーザーズからレコード1個取ってきて、 ユーザー.リードオンリーはてなという形で
ユーザーがリードオンリーなのかそうじゃないか。
トゥルーフォルスが返ってくると。
今回の場合はリードオンリーをつけてユーザーのスコープみたいな感じで
スコープというかこれ多分クラスメソッドなのかな。
ユーザー.リードオンリー.フェアという形で取ってきているので
その中の1つのレコードをユーザーを取ってきても
ユーザー.リードオンリーはトゥルーリードオンリーですよという状態になるよと。
そんなメソッドがもともとあるんですよね。
今回のプレリクエストでは何をやっているかというと
今まではレコード1つ1つに対してリードオンリーというメソッドはあったんだけど
リレーションに対してのメソッドがなかったと。
なのでアクティブレコードリレーションに対してリードオンリーメソッドを追加したよと。
そんなプレリクエストになっています。
なのでさっきの例でいうと
ユーザー.リードオンリー.フェアという形で取ってきて
ユーザーズという変数に入れてますと。
ユーザーズ.リードオンリーという風にやると
トゥルーが返ってくるよというそういうメソッドを増やしたよと。
今まではこのメソッドがなかったんですね。
なのでユーザーズに対してレコード1個取ってきてリードオンリー確認するというのができたんだけど
ユーザーズ自体がリードオンリーかどうかというのを見る方法がなかったので
そういうメソッドを提供しているよということです。
09:00
そんなところで今週はお知らせ1件とプレリクエスト3件紹介しました。
ではまた来週。バイバイ。
