Home Software Libraries Ruby omniauth OmniAuthを利用したログインのボタンやリンクではTurboをオフにした方が無難 @wakairo 21 Dec, 2025 05:24 +00:00 Last edited 21 Dec, 2025 05:24 +00:00 OmniAuthを利用すると外部サービスの認証情報を用いたログインが可能となりますが、 そのログインのボタンやリンクでは、以下のようにdata: {turbo: false}を付けてTurboをオフにしないと、ログインが機能しない場合があります。 <%= button_to "Login with GitHub", "/auth/github", data: {turbo: false} %> なお、公式のREADMEにあるRails向けサンプルでもdata: {turbo: false}が用いられています。 また、Rails 7からは、Turboがデフォルト構成に組み込まれ有効になっているため、OmniAuthを利用する際は本件への注意が必要です。
Home Software Others setup-ruby setup-rubyにおける.ruby-versionを用いたバージョン指定 @wakairo 19 Dec, 2025 05:37 +00:00 ruby-version:が無いときのデフォルト動作では、まず.ruby-versionを読みに行くのですね。知りませんでした。 ちなみに少し調べてみたら、2020年のv1.3.0のときから既にそういう仕様のようですね。 それから、railsの新規アプリのGitHub Actionsの設定も現在はruby-version:を省略するようになっていますね。
Home Software Others setup-ruby setup-rubyにおける.ruby-versionを用いたバージョン指定 Takuma @takuma_tech 18 Dec, 2025 11:14 +00:00 setup-rubyのREADMEに以下の記述がありますので、 ruby-version:を設定ファイルにあえて書かないことで、.ruby-versionに設定することも可能です。 If the ruby-version input is not specified, .ruby-version is tried first, followed by .tool-versions, followed by mise.toml 設定ファイルをできるだけ簡潔にしたいなら書かない選択もありですし、逆に分かりやすさを重視するなら明示的に書くのも一案です。どちらを取るかは悩ましいところですね。
Home Software Others Podman Podmanのreplaceオプションを使ってワンコマンドでPodを作り直す @wakairo 17 Dec, 2025 05:53 +00:00 Last edited 17 Dec, 2025 08:01 +00:00 以下のコマンドの実行などで、Podに対応するKubernetes YAMLファイルを一度用意しておけば、 podman generate kube mypod -f=mypod.yaml replaceオプションを利用した以下のコマンドで1つで、PodとそのContainerの停止から削除、再生成までを一度に行えます。 podman play kube mypod.yaml --replace Imageの更新について Kubernetes YAMLファイル内でimagePullPolicy:を指定していないlatestタグのImageは、 replaceを利用した前述のコマンドの実行により、Imageの更新(pull)も併せて行われます。 latest以外のタグのImageが更新された形でPodを再生成したい場合は、 以下のコマンドでImageを更新してから、replaceを利用した前述のコマンドを実行します。 podman pull example/image:tag 参考情報 https://docs.podman.io/en/latest/markdown/podman-kube-play.1.html#replace https://github.com/containers/podman/issues/4880 https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting
Home Software Libraries Ruby actionview `yield :foo`と`content_for :foo`の使い分け @wakairo 17 May, 2025 03:26 +00:00 動機 Rails 8.0.2でrails newをして生成されたapp/views/layouts/application.html.erbでは、 以下のようにyield :fooとcontent_for :fooが混在していました。 <html> <head> <title><%= content_for(:title) || "Sample" %></title> (中略) <%= yield :head %> content_forのAPIドキュメントによれば yield :fooとcontent_for :fooの働きが等価となる場合もあるのですが、 このapplication.html.erbの例のように、片方に統一されず両方を利用しているケースがあったので、 yield :fooとcontent_for :fooの使い分けについて調べる事にしました。 結論 基本的には、yield :fooを使う。ただし、以下の2つのケースではcontent_for :fooを使う。 ケース1:ヘルパーメソッドの中では、yieldは利用できないので、content_for :fooを使う。 ケース2:ビュー側で設定されているかどうかに応じて挙動を切り替えるコードを短く書くときにはcontent_for :fooを使う。 詳細yieldはヘルパーメソッドの中では利用できない content_forのAPIドキュメントに書かれている通り、 content_forは以下の例のようにヘルパーメソッド内で利用可能ですが、yieldは利用できません。 module StorageHelper def stored_content content_for(:storage) || "Your storage is empty" end end yieldとcontent_forでは、設定されていないときの戻り値が異なる ビュー側で以下のように:fooに対して設定が行われていた場合、 <% content_for :foo do %> Foo <% end %> yield :fooとcontent_for :fooの戻り値は、この例ではどちらも" Foo\n"であり、同じになります。 しかし、ビュー側で前述のような記述がなく:fooに対して設定が行われていなかった場合、 yield :fooの戻り値が空文字列("")であるのに対し、content_for :fooの戻り値はnilであり、 戻り値が異なります。 設定されていない場合にcontent_for :fooがnilを戻す性質を利用することで、<title><%= content_for(:title) || "Sample" %></title>のような設定されているかどうかに応じて挙動を切り替えるコードを短く書くことができます。
Home Software Libraries Ruby bootstrap-rubygem Rais8でPropshaftを使う環境ではapplication.jsでbootstrapをimportする @wakairo 07 Apr, 2025 01:42 +00:00 Rais8から標準となったPropshaftを使っている場合でのbootstrap-rubygemのインストールについてです。 結論としましては、公式GitHubレポジトリのインストール方法にある「Sprockets」のところより前はPropshaftでも同様に作業を進め、その後はPropshaftの場合は以下の2行をapp/javascript/application.jsに追加すればインストール完了です。 import "@popperjs/core" import "bootstrap" なお、Propshaftの場合のインストール作業全体の例は、こちらのページで紹介されています。ご参考まで。
Home Software Libraries Ruby actionpack params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要 @wakairo 25 Feb, 2025 06:59 +00:00 Last edited 25 Feb, 2025 07:00 +00:00 ちなみに、RuboCopにrequireとpermitの組み合わせからexpectへの書き換えを自動でやってもらうことは可能ですが、配列パラメータの許可に関してはRuboCopが自動書き換えに失敗する場合があります。 その理由は以下の記述は、配列のパラメータも配列でないパラメータも許可してしまうため、RuboCopとしては配列なのかそうでないのかの判定が機械的に行えないためであると考えられます。 permit(user: [:name]) より詳しくは、前述の記事のこちらの箇所を参照ください。
Home Software Libraries Ruby actionpack params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要 @wakairo 25 Feb, 2025 06:43 +00:00 Rails8では、requireとpermitに代わるより安全な新しいメソッドとして、strong parametersへexpectが導入されました。 expectでは、安全面への配慮から、配列のパラメータを指定する方法がpermitに比べ厳格化されています。 具体的には、配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要となりました。 配列のパラメータを許可する具体的な方法(引用元: expectのAPIドキュメント)は以下の通りです。 params = ActionController::Parameters.new(comments: [{ text: "hello" }, { text: "world" }]) params.expect(comments: [[:text]]) # => [#<ActionController::Parameters { "text" => "hello" } permitted: true>, # #<ActionController::Parameters { "text" => "world" } permitted: true>] なお、安全のためにexpectがこの二重の括弧の記法を採用した背景については、Rails 8: strong parametersの新しいparams.expectの使い方(翻訳)を参照ください。
Home Software Libraries Ruby solid_queue Solid Queueとアプリで同じDBを使う時の注意点と設定 @wakairo 30 Jan, 2025 02:52 +00:00 Last edited 26 Mar, 2025 02:13 +00:00 公式READMEでは、Solid Queueとアプリで同じデータベースを利用することは可能だがいくつか注意点があると記されており、問題をさけるための設定として以下が紹介されています。 なお一般的には、class ApplicationJobはapp/jobs/application_job.rbで定義されています。 class ApplicationJob < ActiveJob::Base self.enqueue_after_transaction_commit = true end また、インストールにおいても単一データベース用にいくつか作業が必要になります。 なお、本件に関する日本語情報としては、Rails Guidesの日本語版に概要の記述があります。
Home Software Unix Unix commands env 一時的な環境変数設定はenvコマンドでも出来る Linx使い @linux 16 Jan, 2025 12:27 +00:00 あるコマンドの実行のためだけに一時的に環境変数を設定するには、 bashやzshでは実行したいコマンドの直前で環境変数設定をすればOKです。 具体的には、下例のように、タイムゾーンに対応する環境変数を設定(TZ=UTC)して、dateコマンドを実行することが出来ます。 $ date Thu Jan 16 21:08:10 JST 2025 $ TZ=UTC date Thu Jan 16 12:08:13 UTC 2025 ところが、この機能は一部の古いシェルや軽量シェルには備わっていないらしいです。 そのようなシェルでは、シェルに依存しないenvコマンドを以下のように利用して同じことが可能、という小ネタでした。 $ env TZ=UTC date Thu Jan 16 12:08:35 UTC 2025
OmniAuthを利用したログインのボタンやリンクではTurboをオフにした方が無難
OmniAuthを利用すると外部サービスの認証情報を用いたログインが可能となりますが、 そのログインのボタンやリンクでは、以下のように
data: {turbo: false}を付けてTurboをオフにしないと、ログインが機能しない場合があります。なお、公式のREADMEにあるRails向けサンプルでも
data: {turbo: false}が用いられています。また、Rails 7からは、Turboがデフォルト構成に組み込まれ有効になっているため、OmniAuthを利用する際は本件への注意が必要です。
setup-rubyにおける.ruby-versionを用いたバージョン指定
ruby-version:が無いときのデフォルト動作では、まず.ruby-versionを読みに行くのですね。知りませんでした。ちなみに少し調べてみたら、2020年のv1.3.0のときから既にそういう仕様のようですね。
それから、railsの新規アプリのGitHub Actionsの設定も現在は
ruby-version:を省略するようになっていますね。setup-rubyにおける.ruby-versionを用いたバージョン指定
setup-rubyのREADMEに以下の記述がありますので、
ruby-version:を設定ファイルにあえて書かないことで、.ruby-versionに設定することも可能です。設定ファイルをできるだけ簡潔にしたいなら書かない選択もありですし、逆に分かりやすさを重視するなら明示的に書くのも一案です。どちらを取るかは悩ましいところですね。
Podmanのreplaceオプションを使ってワンコマンドでPodを作り直す
以下のコマンドの実行などで、Podに対応するKubernetes YAMLファイルを一度用意しておけば、
replaceオプションを利用した以下のコマンドで1つで、PodとそのContainerの停止から削除、再生成までを一度に行えます。Imageの更新について
Kubernetes YAMLファイル内で
imagePullPolicy:を指定していないlatestタグのImageは、replaceを利用した前述のコマンドの実行により、Imageの更新(pull)も併せて行われます。latest以外のタグのImageが更新された形でPodを再生成したい場合は、 以下のコマンドでImageを更新してから、
replaceを利用した前述のコマンドを実行します。参考情報
`yield :foo`と`content_for :foo`の使い分け
動機
Rails 8.0.2でrails newをして生成されたapp/views/layouts/application.html.erbでは、 以下のように
yield :fooとcontent_for :fooが混在していました。content_forのAPIドキュメントによれば
yield :fooとcontent_for :fooの働きが等価となる場合もあるのですが、 このapplication.html.erbの例のように、片方に統一されず両方を利用しているケースがあったので、yield :fooとcontent_for :fooの使い分けについて調べる事にしました。結論
yield :fooを使う。ただし、以下の2つのケースではcontent_for :fooを使う。content_for :fooを使う。content_for :fooを使う。詳細
yieldはヘルパーメソッドの中では利用できない
content_forのAPIドキュメントに書かれている通り、 content_forは以下の例のようにヘルパーメソッド内で利用可能ですが、yieldは利用できません。
yieldとcontent_forでは、設定されていないときの戻り値が異なる
ビュー側で以下のように:fooに対して設定が行われていた場合、
yield :fooとcontent_for :fooの戻り値は、この例ではどちらも" Foo\n"であり、同じになります。しかし、ビュー側で前述のような記述がなく:fooに対して設定が行われていなかった場合、
yield :fooの戻り値が空文字列("")であるのに対し、content_for :fooの戻り値はnilであり、 戻り値が異なります。設定されていない場合に
content_for :fooがnilを戻す性質を利用することで、<title><%= content_for(:title) || "Sample" %></title>のような設定されているかどうかに応じて挙動を切り替えるコードを短く書くことができます。Rais8でPropshaftを使う環境ではapplication.jsでbootstrapをimportする
Rais8から標準となったPropshaftを使っている場合でのbootstrap-rubygemのインストールについてです。
結論としましては、公式GitHubレポジトリのインストール方法にある「Sprockets」のところより前はPropshaftでも同様に作業を進め、その後はPropshaftの場合は以下の2行をapp/javascript/application.jsに追加すればインストール完了です。
なお、Propshaftの場合のインストール作業全体の例は、こちらのページで紹介されています。ご参考まで。
params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要
ちなみに、RuboCopに
requireとpermitの組み合わせからexpectへの書き換えを自動でやってもらうことは可能ですが、配列パラメータの許可に関してはRuboCopが自動書き換えに失敗する場合があります。その理由は以下の記述は、配列のパラメータも配列でないパラメータも許可してしまうため、RuboCopとしては配列なのかそうでないのかの判定が機械的に行えないためであると考えられます。
より詳しくは、前述の記事のこちらの箇所を参照ください。
params.expectで配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要
Rails8では、
requireとpermitに代わるより安全な新しいメソッドとして、strong parametersへexpectが導入されました。expectでは、安全面への配慮から、配列のパラメータを指定する方法がpermitに比べ厳格化されています。 具体的には、配列のパラメータを許可するには明示的に二重の角括弧([[ :属性名 ]])が必要となりました。配列のパラメータを許可する具体的な方法(引用元:
expectのAPIドキュメント)は以下の通りです。なお、安全のためにexpectがこの二重の括弧の記法を採用した背景については、Rails 8: strong parametersの新しいparams.expectの使い方(翻訳)を参照ください。
Solid Queueとアプリで同じDBを使う時の注意点と設定
公式READMEでは、Solid Queueとアプリで同じデータベースを利用することは可能だがいくつか注意点があると記されており、問題をさけるための設定として以下が紹介されています。 なお一般的には、
class ApplicationJobはapp/jobs/application_job.rbで定義されています。また、インストールにおいても単一データベース用にいくつか作業が必要になります。
なお、本件に関する日本語情報としては、Rails Guidesの日本語版に概要の記述があります。
一時的な環境変数設定はenvコマンドでも出来る
あるコマンドの実行のためだけに一時的に環境変数を設定するには、 bashやzshでは実行したいコマンドの直前で環境変数設定をすればOKです。
具体的には、下例のように、タイムゾーンに対応する環境変数を設定(
TZ=UTC)して、dateコマンドを実行することが出来ます。ところが、この機能は一部の古いシェルや軽量シェルには備わっていないらしいです。 そのようなシェルでは、シェルに依存しない
envコマンドを以下のように利用して同じことが可能、という小ネタでした。