Home Software Libraries Ruby rails Railsで複数のセッションを用いたintegration testを行う方法 @wakairo 14 Sep, 2024 07:54 +00:00 Last edited 14 Sep, 2024 08:28 +00:00 別々のブラウザから複数のユーザがログインするような状況を再現したintegration testを実装しようとするときなど、 ユーザごとにセッションが必要になるなどして、 1つのテスト内で複数のセッションが必要になることがあります。 Ruby on Railsのintegration testでは、 標準でこのような複数のセッションを用いるテストに対応しており、 公式ドキュメントの中では、ActionDispatch::IntegrationTestのAPIドキュメントに説明があります。 複数のセッションを用いたintegration testの例 公式情報は上述のAPIドキュメントをご覧いただければと思いますが、一応こちらでも簡単な例を使ってintegration testで複数のセッションを用いる方法をご紹介します。 ここではテスト内容として、ログインしているユーザが列挙されるページをテストすることを想定してテストコードを考えます。 具体的には、ユーザ1がログインするとこのページにユーザ1が現れ、 続けてユーザ2がログインすると今度はユーザ1とユーザ2の両方がページに現れることを確認します。 シンプルにopen_session()でセッションを作って用いる場合の例 複数のセッションを用いる場合に鍵となるメソッドは、open_session()です。 このメソッドはセッションのオブジェクト返しますので、必要なセッションの回数分呼び出せば、必要な数のセッションが作成出来ます。 セッションを複数作成したら、各セッションのオブジェクトのインスタンスメソッドとしてget()やassert_response()を呼び出すことで、 セッションを指定してアクションやアサーションを実行できます。 以下にサンプルコードを示します。 require "test_helper" class MultipleSessionTest < ActionDispatch::IntegrationTest test "login users page" do user1 = users(:one) user2 = users(:two) sess1 = open_session sess2 = open_session sess1.get login_path sess1.assert_response :success sess1.post login_path, params: { {email: user1.email, password: user1.password} } sess1.assert_response :found sess1.assert_redirected_to root_path sess1.follow_redirect! sess1.get login_users_path sess1.assert_response :success assert_match /@#{user1.username}/, sess1.response.body assert_no_match /@#{user2.username}/, sess1.response.body sess2.get login_path sess2.assert_response :success sess2.post login_path, params: { {email: user2.email, password: user2.password} } sess2.assert_response :found sess2.assert_redirected_to root_path sess2.follow_redirect! sess1.get login_users_path sess1.assert_response :success assert_match /@#{user1.username}/, sess1.response.body assert_match /@#{user2.username}/, sess1.response.body end end 繰り返される処理をDSLのメソッドにまとめる例 上述のシンプルな例を見てみると、ログイン処理などで、対象とするセッションは異なるものの、ほぼ同じ処理が繰り返されていることが分かります。 こういった繰り返される処理は、特定のテストで用いるセッションのDSL (Domain-Specific Language) としてまとめることが出来ます。 以下のテストコードは、テストの手順や内容は上述のシンプルな例と同じですが、今度はこのDSLを用いてコードの繰り返しを排除したものになっています。なお、テストコードの読みやすさの観点でも、こちらの例の方が良くなっているのではないでしょうか。 require "test_helper" class MultipleSessionWithDSLTest < ActionDispatch::IntegrationTest test "login users page" do user1 = users(:one) user2 = users(:two) sess1 = open_session_with_dsl sess2 = open_session_with_dsl sess1.login(user1) sess1.get_login_users assert_match /@#{user1.username}/, sess1.response.body assert_no_match /@#{user2.username}/, sess1.response.body sess2.login(user2) sess1.get_login_users assert_match /@#{user1.username}/, sess1.response.body assert_match /@#{user2.username}/, sess1.response.body end private module CustomDsl def login(user) get login_path assert_response :success post login_path, params: { {email: user.email, password: user.password} } assert_response :found assert_redirected_to root_path follow_redirect! end def get_login_users get login_users_path assert_response :success end end def open_session_with_dsl open_session do |sess| sess.extend(CustomDsl) end end end
Home Standard CSS -apple-systemは、和文フォントを少し小さく表示する TeaTea @teatea1024 09 Sep, 2024 12:01 +00:00 Last edited 09 Sep, 2024 12:04 +00:00 CSSのfont-familyに-apple-systemを入れ、Appleのデバイスを利用してこの-apple-systemが効いている状態で日本語のWebサイトを見ると、和文が少し小さいフォントサイズで表示されます。つまり、-apple-system では12ptを指定しても和文フォントは12ptで表示されません。 ということで、Figmaなどのデザインツールで決めたフォントサイズをそのまま指定すると-apple-system では少し小さく表示される点には注意が必要です。 ちなみに、-apple-systemが何故このようなことになっているかというと、一般に欧文フォントより和文フォントを少し小さく表示した方が文字サイズのバランスが良いと言われているので、欧文フォントとの文字サイズのバランスを取ったためだと思われます。
Home Web Document Ruby on Rails ガイド 新規リリースに伴うRailsガイドの更新の情報 @wakairo 22 Aug, 2024 02:25 +00:00 Rails 7.2のリリースに伴い、Railsガイドが更新されました。更新内容は、Railsガイド公式による以下の記事をご参照ください。 https://note.com/yasslab/n/nb9877f81cee3
Home Web Document Ruby on Rails ガイド 新規リリースに伴うRailsガイドの更新の情報 @wakairo 22 Aug, 2024 02:22 +00:00 Railsの公式ドキュメントであるRuby on Rails Guidesは、Rails本体の新規リリースに伴って更新されており、そのRails Guidesの日本語版であるRailsガイドもそれらに伴って更新されています。 このTopicでは、このRails本体の新規リリースに伴うRailsガイドの更新に関する情報を取り扱います。
Home Software Libraries Ruby rails Ruby on Railsのサポート終了日(各バージョンのEOL) @wakairo 13 Aug, 2024 02:38 +00:00 railsの各バージョンについて、セキュリティアップデートが行われる期限(End-of-Life)は以下の通りです。 7.2.x - Supported until August 9, 2026 7.1.x - Supported until October 1, 2025 7.0.x - Supported until April 1, 2025 6.1.x - Supported until October 1, 2024 なお、railsのサポート期間に関するより詳細な情報については本家のメンテナンス・ポリシーを参照してください。
Home Web Service ChatGPT OpenAI(ChatGPT)のAPIで、意図したJSON形式の出力を確実に得るための設定 @wakairo 09 Aug, 2024 10:04 +00:00 2024年8月に「Structured Outputs」の機能と設定がOpenAI(ChatGPT)のAPIに導入されました。 この設定を有効にすることで、スキーマで指定したJSON形式の出力を、例外的な場合を除いて、確実に得ることが出来ます。 詳細は以下の記事を参照してください。 OpenAIがJSON出力の際に100%の精度で特定のスキーマに従わせる機能をリリース - GIGAZINE OpenAI API の Structured Outputs の使い方|npaka
Home Web Document Opening the Software Toolbox 「ソフトウェアの道具箱」はUNIXの考え方の1つを簡潔に説明している SatoKen @kenicode 10 Jul, 2024 04:55 +00:00 Last edited 10 Jul, 2024 04:56 +00:00 この「ソフトウェアの道具箱」は、Linux等へも引き継がれ現在でも大いに活用できるUNIXの考え方を、簡潔に紹介してくれていると思います。 この考え方の要約をこの文書から引用すると以下のようになります。 個々のプログラムは、一つの仕事をきちんとやってのければよい。それ以上でもそれ以下でもない。 プログラムを適切な配管工事で組み合わせると、全体が部分の総和以上になる結果が生じる。 作者が想像もしなかったようなプログラムの新しい使用法が見つかることもある。 プログラムは決して余計なヘッダや追加情報を出力すべきではない。 そうしたものもパイプラインの先へ送られてしまうかもしれないからだ。 骨の折れる部分は、他の奴にやらせろ。 自分の道具箱をよく知れ! 個々のプログラムを適切に使え。適切なツールがなかったら、それを作れ。 UNIX系のOSを使うとき、特にパイプを使ってコマンドを組み立てるときに知っていると良い知識であると同時に、UNIX系のOSで動くプログラムを作るときにも、パイプを使って他のコマンド(プログラム)と連携できるようにすることが時に強力な選択肢であることは頭に入れておくと良いと思います。 何しろ短い文章ですので、初めてこの考えに触れるときや、この考えを再確認したいときに、サクッと自分で読んだり、他人に紹介できたり、便利な文章だと思います。
Home Software Libraries Ruby meta-tags meta-tags側のtruncateでは、スペース文字のところで切り詰めが行われます @wakairo 05 Jul, 2024 11:26 +00:00 Last edited 05 Jul, 2024 11:27 +00:00 meta-tagsのv2.21.0で'truncate_on_natural_separator'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。
Home Software Windows UniGetUI (formerly WingetUI) WingetUIはv3.1からUniGetUIに名称が変更されました @wakairo 03 Jul, 2024 22:36 +00:00 winget以外のパッケージ・マネジャーも多数サポートするようになってきたため、WingetUIをUniGetUIにちかぢか名称変更しますというアナウンスメントが2024/03/13に出ていました。 2024/07/03にバージョン3.1がリリースされ、リリース名が初めてUniGetUIになりましたので、名称変更が完了したものと思われます。 なお、バージョン3.0のリリースではWingetUIという名称でした。
Home Software Libraries Ruby activerecord activerecordでは、firstを使った方が実装とSQLが揃って可読性が上がる Takuma @takuma_tech 03 Jul, 2024 05:22 +00:00 こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。 一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。 したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。
Railsで複数のセッションを用いたintegration testを行う方法
別々のブラウザから複数のユーザがログインするような状況を再現したintegration testを実装しようとするときなど、 ユーザごとにセッションが必要になるなどして、 1つのテスト内で複数のセッションが必要になることがあります。
Ruby on Railsのintegration testでは、 標準でこのような複数のセッションを用いるテストに対応しており、 公式ドキュメントの中では、ActionDispatch::IntegrationTestのAPIドキュメントに説明があります。
複数のセッションを用いたintegration testの例
公式情報は上述のAPIドキュメントをご覧いただければと思いますが、一応こちらでも簡単な例を使ってintegration testで複数のセッションを用いる方法をご紹介します。
ここではテスト内容として、ログインしているユーザが列挙されるページをテストすることを想定してテストコードを考えます。 具体的には、ユーザ1がログインするとこのページにユーザ1が現れ、 続けてユーザ2がログインすると今度はユーザ1とユーザ2の両方がページに現れることを確認します。
シンプルにopen_session()でセッションを作って用いる場合の例
複数のセッションを用いる場合に鍵となるメソッドは、open_session()です。 このメソッドはセッションのオブジェクト返しますので、必要なセッションの回数分呼び出せば、必要な数のセッションが作成出来ます。 セッションを複数作成したら、各セッションのオブジェクトのインスタンスメソッドとしてget()やassert_response()を呼び出すことで、 セッションを指定してアクションやアサーションを実行できます。
以下にサンプルコードを示します。
繰り返される処理をDSLのメソッドにまとめる例
上述のシンプルな例を見てみると、ログイン処理などで、対象とするセッションは異なるものの、ほぼ同じ処理が繰り返されていることが分かります。 こういった繰り返される処理は、特定のテストで用いるセッションのDSL (Domain-Specific Language) としてまとめることが出来ます。
以下のテストコードは、テストの手順や内容は上述のシンプルな例と同じですが、今度はこのDSLを用いてコードの繰り返しを排除したものになっています。なお、テストコードの読みやすさの観点でも、こちらの例の方が良くなっているのではないでしょうか。
-apple-systemは、和文フォントを少し小さく表示する
CSSのfont-familyに-apple-systemを入れ、Appleのデバイスを利用してこの-apple-systemが効いている状態で日本語のWebサイトを見ると、和文が少し小さいフォントサイズで表示されます。つまり、-apple-system では12ptを指定しても和文フォントは12ptで表示されません。
ということで、Figmaなどのデザインツールで決めたフォントサイズをそのまま指定すると-apple-system では少し小さく表示される点には注意が必要です。
ちなみに、-apple-systemが何故このようなことになっているかというと、一般に欧文フォントより和文フォントを少し小さく表示した方が文字サイズのバランスが良いと言われているので、欧文フォントとの文字サイズのバランスを取ったためだと思われます。
新規リリースに伴うRailsガイドの更新の情報
Rails 7.2のリリースに伴い、Railsガイドが更新されました。更新内容は、Railsガイド公式による以下の記事をご参照ください。
新規リリースに伴うRailsガイドの更新の情報
Railsの公式ドキュメントであるRuby on Rails Guidesは、Rails本体の新規リリースに伴って更新されており、そのRails Guidesの日本語版であるRailsガイドもそれらに伴って更新されています。
このTopicでは、このRails本体の新規リリースに伴うRailsガイドの更新に関する情報を取り扱います。
Ruby on Railsのサポート終了日(各バージョンのEOL)
railsの各バージョンについて、セキュリティアップデートが行われる期限(End-of-Life)は以下の通りです。
なお、railsのサポート期間に関するより詳細な情報については本家のメンテナンス・ポリシーを参照してください。
OpenAI(ChatGPT)のAPIで、意図したJSON形式の出力を確実に得るための設定
2024年8月に「Structured Outputs」の機能と設定がOpenAI(ChatGPT)のAPIに導入されました。 この設定を有効にすることで、スキーマで指定したJSON形式の出力を、例外的な場合を除いて、確実に得ることが出来ます。
詳細は以下の記事を参照してください。
「ソフトウェアの道具箱」はUNIXの考え方の1つを簡潔に説明している
この「ソフトウェアの道具箱」は、Linux等へも引き継がれ現在でも大いに活用できるUNIXの考え方を、簡潔に紹介してくれていると思います。
この考え方の要約をこの文書から引用すると以下のようになります。
UNIX系のOSを使うとき、特にパイプを使ってコマンドを組み立てるときに知っていると良い知識であると同時に、UNIX系のOSで動くプログラムを作るときにも、パイプを使って他のコマンド(プログラム)と連携できるようにすることが時に強力な選択肢であることは頭に入れておくと良いと思います。
何しろ短い文章ですので、初めてこの考えに触れるときや、この考えを再確認したいときに、サクッと自分で読んだり、他人に紹介できたり、便利な文章だと思います。
meta-tags側のtruncateでは、スペース文字のところで切り詰めが行われます
meta-tagsのv2.21.0で'truncate_on_natural_separator'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。
WingetUIはv3.1からUniGetUIに名称が変更されました
winget以外のパッケージ・マネジャーも多数サポートするようになってきたため、WingetUIをUniGetUIにちかぢか名称変更しますというアナウンスメントが2024/03/13に出ていました。
2024/07/03にバージョン3.1がリリースされ、リリース名が初めてUniGetUIになりましたので、名称変更が完了したものと思われます。
なお、バージョン3.0のリリースではWingetUIという名称でした。
activerecordでは、firstを使った方が実装とSQLが揃って可読性が上がる
こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。
一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。
したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。