別々のブラウザから複数のユーザがログインするような状況を再現した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

CSSのfont-familyに-apple-systemを入れ、Appleのデバイスを利用してこの-apple-systemが効いている状態で日本語のWebサイトを見ると、和文が少し小さいフォントサイズで表示されます。つまり、-apple-system では12ptを指定しても和文フォントは12ptで表示されません。
ということで、Figmaなどのデザインツールで決めたフォントサイズをそのまま指定すると-apple-system では少し小さく表示される点には注意が必要です。

ちなみに、-apple-systemが何故このようなことになっているかというと、一般に欧文フォントより和文フォントを少し小さく表示した方が文字サイズのバランスが良いと言われているので、欧文フォントとの文字サイズのバランスを取ったためだと思われます。

Rails 7.2のリリースに伴い、Railsガイドが更新されました。更新内容は、Railsガイド公式による以下の記事をご参照ください。

• https://note.com/yasslab/n/nb9877f81cee3

Railsの公式ドキュメントであるRuby on Rails Guidesは、Rails本体の新規リリースに伴って更新されており、そのRails Guidesの日本語版であるRailsガイドもそれらに伴って更新されています。

このTopicでは、このRails本体の新規リリースに伴うRailsガイドの更新に関する情報を取り扱います。

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のサポート期間に関するより詳細な情報については本家のメンテナンス・ポリシーを参照してください。

2024年8月に「Structured Outputs」の機能と設定がOpenAI（ChatGPT）のAPIに導入されました。 この設定を有効にすることで、スキーマで指定したJSON形式の出力を、例外的な場合を除いて、確実に得ることが出来ます。

詳細は以下の記事を参照してください。

• OpenAIがJSON出力の際に100％の精度で特定のスキーマに従わせる機能をリリース - GIGAZINE
• OpenAI API の Structured Outputs の使い方｜npaka

この「ソフトウェアの道具箱」は、Linux等へも引き継がれ現在でも大いに活用できるUNIXの考え方を、簡潔に紹介してくれていると思います。

この考え方の要約をこの文書から引用すると以下のようになります。

1. 個々のプログラムは、一つの仕事をきちんとやってのければよい。それ以上でもそれ以下でもない。
2. プログラムを適切な配管工事で組み合わせると、全体が部分の総和以上になる結果が生じる。 作者が想像もしなかったようなプログラムの新しい使用法が見つかることもある。
3. プログラムは決して余計なヘッダや追加情報を出力すべきではない。 そうしたものもパイプラインの先へ送られてしまうかもしれないからだ。
4. 骨の折れる部分は、他の奴にやらせろ。
5. 自分の道具箱をよく知れ！ 個々のプログラムを適切に使え。適切なツールがなかったら、それを作れ。

UNIX系のOSを使うとき、特にパイプを使ってコマンドを組み立てるときに知っていると良い知識であると同時に、UNIX系のOSで動くプログラムを作るときにも、パイプを使って他のコマンド（プログラム）と連携できるようにすることが時に強力な選択肢であることは頭に入れておくと良いと思います。

何しろ短い文章ですので、初めてこの考えに触れるときや、この考えを再確認したいときに、サクッと自分で読んだり、他人に紹介できたり、便利な文章だと思います。

meta-tagsのv2.21.0で'truncate_on_natural_separator'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。

winget以外のパッケージ・マネジャーも多数サポートするようになってきたため、WingetUIをUniGetUIにちかぢか名称変更しますというアナウンスメントが2024/03/13に出ていました。

2024/07/03にバージョン3.1がリリースされ、リリース名が初めてUniGetUIになりましたので、名称変更が完了したものと思われます。

なお、バージョン3.0のリリースではWingetUIという名称でした。

こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。

一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。

したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。