2024年9月現在、UbuntuやDebianでapt-getを使ってインストールしたHeroku CLIは自動更新されなくなっています。具体的には、単純にsudo apt-get upgradeを走らせるだけでは、最新版になりませんでした。昔はこのコマンドで最新版に更新されたと思うのですが。

https://devcenter.heroku.com/ja/articles/heroku-cli#install-with-ubuntu-debian-apt-get には以下の記述があります。

このバージョンでは、自動更新を行いません。apt-get​を使用して手動で更新してください。

そして、自動更新をして欲しい場合には、tar 書庫によるスタンドアロンインストールを使えば良いそうです。ということで、特に事情がない分には、今後はこちらのスタンドアロンインストール版の方が便利そうです。

問題の内容

フォームヘルパーで作成したフォームの標準の挙動として、 railsは、バリデーション・エラーが起きたフォーム要素を、field_with_errorsクラスを指定したdiv要素で囲みます。 つまり、バリデーション・エラーの有無によって、HTMLの階層構造が変わってしまいます。

その一方で、BootstrapのInput groupは、input-groupクラスを指定した要素の直接の子要素としてフォーム要素があることを前提としています。 そのためバリデーション・エラー時に、input-groupを指定した要素とフォーム要素の間にfield_with_errorsクラスのdiv要素が割り込むことで、Input groupの表示を乱してしまいます。

この問題に対し、インターネット上の情報では、 display: contents;を利用する方法や config.action_view.field_error_procの設定を変更する方法が紹介されていましたが、 私が試した限りでは問題の解決に至りませんでした。

そこで以下では、Input groupの利用を諦めて、Input groupに似た表示を他のBootstrapの機能で実現する方法をご紹介します。

なお、この問題に関して別の何か良い方法をご存じの方がいらっしゃいましたら、コメントをいただけると嬉しいです。

Bootstrapにおいて、Input groupに似た表示をgridで作成する方法

例として、Input groupを利用した以下のフォームの一部分を考えます。

<div class="input-group">
  <span class="input-group-text">@</span>
  <%= f.text_field :username, class: 'form-control' %>
</div>

このフォームの一部分に近い表示を実現する例が以下のコードです。Input groupを利用した表示と比べると、「@」を囲む枠線は無くなりますが、文字やフォームの位置関係は近いものを実現できます。なお、ブラウザの画面幅をいろいろと変えた場合でも、位置関係の近さは大丈夫なはずです。

<div class="row gx-1">
  <div class="col-auto col-form-label">@</div>
  <div class="col">
    <%= f.text_field :username, class: 'form-control' %>
  </div>
</div>

このコードで利用しているBootstrapのクラスについて少し解説します。

まず横幅のバランスに関しては、以下のクラスを利用しています。

• col-auto：内容の幅、つまり、上述のコードではフォームの左にある文字列である「@」の幅に基づいたカラムの幅になります。
• col：残っている幅を均等に割り付けた幅になります。例えばcolクラスのカラムが2つあれば残りの幅が2分割されて均等に割り付けられます。上述のコードではcolクラスのカラムは1つですので、左にある「@」のカラムの幅を除いた残りの幅が全てこのtext_fieldのカラムに割り付けられます。

次に文字の位置（この例では「@」の位置）は、以下のクラスで調整しています

• col-form-label：指定することでフォームと上下位置をそろえられます。
• gx-*：ガターを調整することで「@」とフォームの間の距離を調整し左右位置を調整しています。なお、左右位置を細かく調整したい場合にはmarginで直接細かく指定しても良いかもしれません。

（参考）Input groupに似せることよりもgridのカラム幅の指定を優先する場合

グリッドにおいて要素間の左右位置をそろえたいとき等では、col-autoを使わずに、以下のコードのようにカラム幅を指定する方法もあります。 このような場合では、文字列の左右位置の調整にtext-endクラスやtext-centerクラスが役立つかもしれません。

<div class="row gx-1">
  <div class="col-2 col-form-label text-end">@</div>
  <div class="col-10">
    <%= f.text_field :username, class: 'form-control' %>
  </div>
</div>

コードの動作確認をしたgemのバージョン

• rails (7.1.3.4)
• bootstrap (5.3.3)

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

• 8.0.x - 2026/11/07
• 7.2.x - 2026/08/09
• 7.1.x - 2025/10/01
• 7.0.x - 2025/04/01

6.1.xは、以下の通りサポートが終了しています。

• 6.1.x - 2024/10/1

なお、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'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。