Rails Luminary Awardsの受付開始
はい、こんにちは。第31回のtanaken on Railsです。
今週は、お知らせ1件とプレリクエストを4件紹介します。
まず、お知らせです。
Rails Luminary Awardsの推薦の受付が始まりました。
Rails Luminary Awardsは、Railsのエコシステムとコミュニティに貢献した人を称える表彰です。
昨年、2023年より、Rails Foundationによって開始されました。
応募フォームのURLを希少ノートに貼っておくので、そちらからご応募いただけます。
続いて、プレリクエストの紹介に移ります。
1つ目、Implement New Maintenance Policy、Railsのメンテナンスポリシーに関する変更です。
プレリクエストの説明文に記載されていた変更点は、次の3つです。
1つ目、メンテナンスの期間が明示されました。
機能のバグ修正については、マイナーバージョンのリリースから1年間。
セキュリティ修正に関しては、マイナーバージョンのリリースから2年間という形になったようです。
これまでは明記されていなかったかなと思いますね、期間に関しては。
どのバージョンは、現在サポート中ですというような表記はありましたけれども、
これは何年間なんですよというのは記載されていなかったので、期間が明確になったよというのが1個目ですね。
2個目の変更点が、重大なセキュリティ問題と通常のセキュリティ問題の区別がなくなりました。
今までは重大なものと通常のものを分けて記載されていたんですけれども、
関係なくセキュリティ問題という1つの区切りになったよというところですね。
3つ目、Railsが提供するnpmパッケージのバージョン番号の表記が変わりました。
これまではGemのバージョンにパッチより細かいバージョン、
これ何だろうな、ビルドバージョンとかっていうのかな、一般には。
っていうのがあるときには、ハイフンを使って表記していました。
例えば、Gemのバージョンが7.0.1.4のとき、npmパッケージのバージョンは7.0.1-4という表記になっていたと。
これはnpmパッケージがビルドバージョンというか4桁目のバージョンを
ドットつなぎのバージョンを表記できないという制約があるのかな、みたいですね。
たぶん、ちゃんと調べてないけどそんなことは書いてありました。
なので、仕方なくというか、ハイフンつなぎで書いていたというところなんですけども。
調べてみると、セマンティックバージョニングの文脈では、
ハイフンを使うとその後に記載されているバージョン番号は、
プレリリースバージョンという意味になる。
例えばレールズだと、ベータとか、7.0.2-ベータ何たらとか、ベータ1、ベータ2とかってあると思うんですけど、
そういうまだプレリリースのバージョンだよというときに、
ハイフンつなぎで書くみたいなのがセマンティックバージョニングの記法みたいなんですよ。
そのセマンティックバージョニングのシンタックス的には、ハイフン使うとそういう意味合いになるので、
多分それを避けた方がいいんじゃないかというところなんじゃないかなと予想してますが、
今後はどうなったかというと、ゼロ埋めで表記をしていくということになったみたいです。
具体的に何かというと、
ジムのバージョンが7.0.1.4のときに、
npmパッケージのバージョンは7.0.104という間にゼロで埋めて104というような表記になったということみたいですね。
7.0.1.100とかだった場合はどうなるんだろうなって、
2桁最後の自分のバージョンの4つ目が3桁だった場合はどうなるんだろうなとか、
レール図のバージョン管理の方法として、
4桁目の数字が3桁って伝わりにくいですね。
ドットつなぎの4個目のバージョンの番号が3桁になると、
4桁目の数字が3桁になると、
4桁目の数字が3桁って伝わりにくいですね。
ドットつなぎの4個目の数字、バージョンの番号が3桁になるってことはないよっていう前提なのかな。
分からんけど。
2桁までだからゼロ埋めでいいでしょうみたいなことなんですかね。
ちゃんと調べてないが、そういうことみたいですね。
という3点が要求されていました。
そういうメンテナンスポリシーの変更がありましたよということですね。
メンテナンスポリシーの変更点でプレリクエストには明記されてなかったんですけど、
差分としてあったのが、レール図チームは6ヶ月ごとにバージョンの変更をやっていくぞ、
バージョンの変更というか機能の追加をやっていくぜ、
意気込みみたいなのが書かれておりやして、それはへえと思いましたね。
そうなんだというところでございました。
1年以上変更がなかった場合はうんぬんかんぬんみたいな記載もあって、
半年ごとにいろいろやっていくぜみたいな意気込みをこのメンテナンスポリシーにも書かれていたのは、
そうなんだという気づきがあって面白かったですね。
続いてプレリクエストの2つ目。
Add Default Password Reset Token to Hash Secure Password。
こちらはアクティブモデルに関する変更です。
モデルにハズセキュアパスワードを使うと、パスワードリセット用のトークンを利用できるようになりました。
前提としてハズセキュアパスワードって何ですかというところのおさらいを念のためしておきます。
ハズセキュアパスワードはレールズのアクティブレコード、アクティブモデルによって提供されるモジュールの機能ですね。
パスワードのハッシュ化と認証を簡単に行うための機能です。
パスワードダイジェストというカラムを持つ、例えばユーザーモデルというのがあったとしましょう。
普通にハズセキュアパスワードを記載してあげると、ユーザーモデルにはパスワードというアトリビュートとパスワードコンファメーションというアトリビュートが勝手に追加されるようになっています。
勝手にというかハズセキュアパスワードという機能によって追加されるようになっています。
このパスワード属性は入力必須なので、値を指定しない、あるいは空文字列で保存するとバリデーションエラーになるようになっていて、
加えてパスワード属性とパスワードコンファメーションの属性、パスワード確認、よくありますよね。
パスワード登録するときにあなたのパスワードと同じパスワードをもう一回入力してくださいみたいな。
この二つのパスワードの入力値が一致してたら登録できるみたいな。よくありますよね。
そういう前提になっていて、このパスワード属性とパスワードコンファメーション属性の値が不一致の場合もバリデーションエラーになるという仕組みがあります。
これを使っている方も結構いるんじゃないかなと思いますね。
今回のプルリクエストでは、このハズセキュアパスワードの機能を使ったときにパスワードリセット用のトークンも利用できるようになりました。
パスワードリセットトークン
例えばさっきの例で、ユーザーモデルを入して、名前とパスワードを入れて、そのユーザーをセーブしますと。
ユーザーのインスタンスに対してパスワードリセットトークンというメソッドを呼び出すことができるようになったと。
このパスワードリセットトークンというインスタンスメソッドを呼び出すと、15分間だけ有効なトークンが発行されるようになります。
このトークンを使って、ユーザー.FindByPasswordResetTokenというクラスメソッドを使って引数にトークンを渡すと、
先ほど発行したトークンと一致するユーザーを見つけることができると。
15分の間だけそのトークンと一致するユーザーをファインドしてくることができるようになります。
逆に15分過ぎてしまうと、このFindByPasswordResetTokenというメソッドを使って呼び出すと、ニルが返ってくるようになるということですね。
このFindByPasswordResetTokenにはビックリマークがついたメソッドもあって、
こいつを呼び出すと例外が発生すると。
16分以上経っちゃってたら例外が発生すると。
例外はアクティブサポートメッセージバリファイヤーインバリットシグネチャー
Since the token is expiredと書いてある。
インバリットシグネチャーというエラーが出るというような感じになっているみたいですね。
パスワード忘れた方はこちらとメールアドレスを入力して、パスワード再発行のメールが飛んできて、
そこにURLにトークンがついていて、そこにアクセスして新しいパスワードを発行するという流れがあると思うんですけど、
そういう時に使えるようなトークンを生成して、そのトークンが15分以内であればユーザーを見つけることができると。
そんな仕組みになっているよということですね。
では最後でございます。
最後はプレリクエストを2つ紹介するんですけど、両方ともルーティングに関する変更なのでまとめて紹介します。
ルーティング変更
1つ目がデプリケートハッシュキーパスマッピング。
2つ目がデプリケートマルチプルパスルートマッピング。
これらは両方ともルーティング、アクションパックに関する変更です。
まず1つ目がハッシュキーを使った矢印みたいな表記。
これハッシュキーパスっていうのか。
その矢印を使った表記。
例えばgetUsers="右矢印みたいな組み合わせで作るやつ。
例えばgetUsersがusersindexにルーティングするよみたいな。
そういうときに右この矢印記号で書くという記法があったんですけど、
この記法は非推奨になります。
具体的にはgetUsers="2usersindex".
矢印じゃなくて2でルーティングパスを指定するみたいな。
これは既にもちろん使える表記の記法なんで、
使っている方もたくさんいると思うんですけど、
この右矢印記法はやめて2とか使ってくださいねと。
あとマウントのときも右矢印使えたんですけど、
そうじゃなくてatコロンで指定してくださいねというような記法ですね。
続いて複数のパスを含むルーティングも非推奨になったということで、
何かというと例えばgetUsers,otherPath,2usersindex
例えばsraUsersというパスとsraOtherPathというパスを
両方ともusersコントローラーのインデックスアクションに
ルーティングするよみたいなことで
複数のパスをgetの横にカンマ区切りで渡すことができたんですよね。
それも非推奨になって行を分けてね
getUsers,2usersindexとかgetOtherPath,2usersindexとかっていう風に
それぞれ分けて書いてくださいねというのが推奨になりました。
で、なんでこんな非推奨の書き方を指定というか
今回ちゃんと非推奨な書き方として出すようにしたかというと
この非推奨な使い方をしていると
使わない場合に比べて1.25倍から1.5倍ぐらい遅いと
パフォーマンスがあんま良くないと
なのでこのプレリクエストの著者によって
実験結果が示されているんですけど
この非推奨の使い方をやめると1.25倍から1.5倍早くなった
という結果が示されていたりするんで
非推奨にしましょうというところで
逆にそんなルーティング何回も何回も必要なシーンってあるんかいな
みたいなのもあるんですけど
テストを実行するときなのかなとかかな
あるいはなんだろう
ルーティングって別にそんなに何度も何度も
本番環境でやるようなもんじゃないような気もしてるんですけど
遅いより早い方がいいよねというのと
toとかatとか記載してあげた方が
意味が明確にはなる気もするんで
右矢印記号とかを使うよりもね
っていうところはあると思うんで
分かりやすくもなるなとは個人的には思っているし
あと複数パスの場合も
框枠切りでやると1行に収まるという
分かりやすさもあるんですけど
複数文に分かれてるとね
片方のパスだけ変更したときに
Gitの差分として
変更した方の部分だけの差分として
Gitのコミットローグが残ると思うんで
その方が分かりやすいっていうのは
あったりするかなという気はしますね
とかとかということで
非推奨な書き方が
明示されるようになったよということでございます
はい 以上です
今回はお知らせ1件とプレリクエスト4件
3つ目と4つ目は実質一緒でしたけど
プレリクエスト4件とお知らせ1件を紹介しましたと
こんなところで今週の田中山本レビューは以上とします
それではまた来週バイバイ
