2024-02-22

Railsガイドにきちんと目を通して新しい知識を得る - アセットパイプライン編 -

Rails

ドキュメントを読み込むのは大事、ということでRailsガイドを頭から読んでいく取り組みをしています。各章ごとに、（Railsガイドにちゃんと書いてあるのに）知らなかった機能を雑にまとめていきます。

今回は、アセットパイプラインの章です。

Sprocketsの利用法

マニフェストファイルとディレクティブ

manifest.jsのlink_directory ../stylesheets .cssで、app/assets/stylesheetsディレクトリのcssファイルを読み込みます。
実際に、この行を削除するとcssが効かなくなりました。

Railsガイドには、（ただしサブディレクトリは含めません）と記載があったのですが、手元でapp/assets/stylesheets/books/index.cssにcssファイルを書いたらCSSが反映されます。
これはどうしてだろうと思ったら、app/assets/stylesheets/application.cssに以下の記載がありました。

 *= require_tree .

これによって、ディレクトリ配下のcssファイルを読み込んでいます。
manifast.jsのlink_directoryを使うことでstylesheet_link_tagでapplication.cssが読み込めるようになり、
application.cssに*= require_tree . とすることでapplication.cssからディレクトリ内のcssが読み込まれるということだと理解しました。

なお、application.cssには以下も記載されていました。

 *= require_self

これは、application.css自身を読み込むタイミングを決めるものです。
例えば*= require_tree .より上に書いた場合、配下のディレクトリ内のcssと対象が重複した場合は配下のcssが適用されます。
逆に、*= require_tree .より下に書いた場合は、application.css`内のcssが適用されます。

Sprocketsにおけるindex.css

例えばapplication.cssに*= require booksと記述したとき、books/index.cssが存在しないとエラーを返します。

Sprockets::FileNotFound in Books#index

そして、そのindex.css内で *= require_tree .を記載すると、booksディレクトリ内の他のcssファイルを読み込めます。

.css.erb

.css.erbファイルを使うことで、asset_data_uriヘルパーを使ってデータURLスキームを使うこともできるようになります。

2024-02-20

Railsガイドにきちんと目を通して新しい知識を得る - Rails アプリケーションの設定項目編 -

Rails

今回は、Rails アプリケーションの設定項目の章です。

railsguides.jp

rails実行前にコードを実行する

リンクはこちら

require 'rails/all' の上に書くことで、Railsが読み込まれる前にプログラムを実行できるそうです。
あまりユースケースが思いつかないですが、いざという時はありそうなので覚えておきたいです。

Rails全般の設定

リンクはこちら

週初めの設定をconfig.beginning_of_weekで設定する

config.beginning_of_weekで週の初めを何曜日とするかを設定できます。

デフォルト設定の場合、例えばDate.today.beginning_of_weekだと、今日が属する週の月曜日の日付インスタンスを返します。
（日曜かなと思っていたのですが、月曜でした。）

これを、config.beginning_of_weekを設定することで変更できます。

# appllication.rb

config.beginning_of_week = :wednesday

Date.today.beginning_of_week
#=> Wed, 14 Feb 2024

config.colorize_loggingでログの出力に色付けをする

これも設定になっていたとは知りませんでした。
falseにしたら確かにSQLクエリログなどに色がつかなくなりました。

config.disable_sandboxでsandboxの利用をさせない

sandbox環境の制限ができるのも知りませんでした。
データベースサーバーのメモリが枯渇するのを避けるうえで有用とのことです。
一方で、プログラムが問題なく動くか、や間違って更新しても安心なようにsandbox環境を使うことは多いと思うので、なかなか判断が難しいところですね。

これをtrueにしたところ、--sandboxオプションをつけてrailsコンソールを起動するとエラーが表示されるようになりました。

$ rails c --sandbox
Error: Unable to start console in sandbox mode as sandbox mode is disabled (config.disable_sandbox is true).

config.enable_reloadingでクラス等の変更時、リクエストごとに再読み込みするかどうかを決める

開発環境でコードの修正がリロードで反映されるのはconfig.enable_reloadingがtrueになっているからでした。
デフォルト設定では、production環境ではfalseというのも覚えておくべきだなと思いました。

config.sandbox_by_defaultでデフォルトをsandbox環境にする

Rails7.1から入った機能です。
config.sandbox_by_defaultをtrueにすると、railsコンソールがデフォルトでsandbox環境になります。
本番環境での事故防止に良さそうです。

手元の環境で試そうとしたら、trueに設定してもsandbox環境にならず、調べたところ、developmentとtestではこのオプションは無視されるとのことでした。

Note that this option is ignored when rails environment is development or test.

github.com

ActiveRecordを設定する

リンクはこちら

config.active_record.partial_inserts

trueにすると、createをしたときなどに、DBデフォルト値に対してはINSERTで値が送られなくなります。

設定をtrueにして、以下のbooksテーブルで試してみました。

カラム名	型	デフォルト値
title	string	'デフォルトタイトル'
content	string	（設定なし）

Book.create
#=> INSERT INTO "books" ("created_at", "updated_at") VALUES ($1, $2) RETURNING "id"  [["created_at", "2024-02-18 ..."], ["updated_at", "2024-02-18 ..."]]

titleとcontentには確かにINSERTで値が指定されていません。
それぞれ'デフォルトタイトル'という文字列とnilが登録されていました。

こちらはRails7.0でデフォルトがfalseに変更されたそうです。
理由が気になって見てみたら、PRの方で以下の旨が挙げられていました。

ignored_columns機能が導入されたことにより、カラムを安全に削除する、より信頼性のある方法が生まれたこと
クエリサイズを減らすことの利点はそれほど大きなものではなくなった

github.com

active_record.before_committed_on_all_records

Rails7.1からのオプションです。

トランザクションに登録されているすべてのレコードに対して、before_committed!コールバックを有効にします。

上記の意味が最初よくわからなかったですが、試したらわかりました。

class Book < ApplicationRecord
  before_commit -> { p "title: #{title}" }
end

上記のように適当にbefore_commitを設定し、設定をfalseにします。

ActiveRecord::Base.transaction do
  book = Book.first
  book_2 = Book.first
  book.update(title: 'abc')
  book_2.update(title: 'def')
end

#=> "title: abc"

一方で、trueにした場合、pメソッドで出力される値は"title: def"になります。

これを見ると、falseにした場合、トランザクション内で同じレコードに対して複数回処理をした場合に、before_commitで見るのは最初に更新された方ということがわかりました。

ActionControllerを設定する

リンクはこちら

raise_on_open_redirectsでオープンリダイレクト脆弱性の対策を強化する

うっかりオープンリダイレクト脆弱性が紛れてしまった場合に、リダイレクト先が外部ホストの場合は例外を出してくれます。

例えば適当なコントローラで以下のように設定し、アクセスするとActionController::Redirecting::UnsafeRedirectErrorという例外が発生します。

allow_other_host: trueをつければ外部ホストへのリダイレクトが可能になる、というように回避策も用意されているので、基本はtrueで良さそうに思いました。

def index
  redirect_to 'http://example.com'
end

2024-02-17

Railsガイドにきちんと目を通して新しい知識を得る - Rails アプリケーションのデバッグ編 -

Rails

今回は、Rails アプリケーションのデバッグの章です。

railsguides.jp

SQLクエリコメント

リンクはこちら

ログに出力されるSQLクエリログに、どのコントローラのどのアクション起因かというのが表示されます。
SQL実行に無駄がないか（結果をキャッシュできる箇所がないか）など調査するのに便利そうですね。

config.active_record.query_log_tags_enabled = true

SELECT "books".* FROM "books" /
*action='index',application='Myapp',controller='books'*/  ← この情報が追記される

debug gemによるブレークポイント

リンクはこちら

breakで行数や実行コードを指定して処理を止める

binding.bやdebuggerで処理を止めた後、break 18やb 18で行数で処理を止められます。
また、b Book.newのようにすると、呼ばれたnewメソッドで処理が止まるようになります。

gemのソースコードを読んだりするときに今まではdebuggerで処理を止めたところからジャンプ先にまたdebuggerを設定して、、とやっていましたが、これを上手に使えば楽になりそうです。

watchでインスタンスの変化があった場合に処理を止める

watchを使うことで、オブジェクトに変化があった場合に処理を止めてくれます。
ちなみにActiveRecordのインスタンスを指定した際には、インスタンスの属性が変わっただけでは処理は止まりませんでした。

def index
  debugger # ここで止まった時に、`watch @book`とする
  @book = Book.first # nil から インスタンスが入るので処理が止まる
  @book.title = '変更'  # 属性が1つ変わるだけでは止まらない
  @book = :book # シンボル:bookに変わるので止まる
end

2024-02-16

Railsガイドにきちんと目を通して新しい知識を得る - Rails アプリケーションのエラー通知編 -

Rails

今回は、Rails アプリケーションのエラー通知の章です。

railsguides.jp

サブスクライバの設定

リンクはこちら

例えば以下のように記述をするだけで、エラーをキャッチしてログで「エラーを検知しました」と表示されるのを確認できます。
ポイントとしては、reportというメソッドを持ったクラスのインスタンスをsubscribeで登録する、というところです。

# config/initializers/error_subscriber.rb

class ErrorSubscriber
  def report(error, handled:, severity:, context:, source: nil)
    p 'エラーを検知しました'
  end
end

Rails.error.subscribe(ErrorSubscriber.new)

エラーを通知しつつ、握りつぶす

リンクはこちら

例えば上記のサブスクライバを登録した状態で、適当にエラーを発生するコードを混ぜると、reportメソッドの中身は実行されますが、処理は継続されます。

def index
  @books = Book.all
  Rails.error.handle do
    no_exist_method
  end
end

Started GET "/books"
Processing by BooksController#index as HTML
"エラーを検知しました"
...
Completed 200 OK

処理を止めたくはないけど通知はして欲しい時に使えそうですね。

2024-02-15

Railsガイドにきちんと目を通して新しい知識を得る - Rails セキュリティガイド編 -

Rails

今回は、Rails セキュリティガイドの章です。今回はセキュリティの話なので、知らなかったものと合わせて、改めて頭に入れておくべきと思った内容も含めてメモしました。

railsguides.jp

セッション固定攻撃の対策

リンクはこちら

最も効果的な対応策は、ログイン成功後に古いセッションを無効にし、新しいセッションIDを発行することです。

devisegemを見てみると、sign_in時にセッションを一度捨てる処理がされています。

# lib/devise/controllers/sign_in_out.rb
def sign_in(resource_or_scope, *args)
  # ...(略)

  expire_data_after_sign_in!

  # ...
end

private

def expire_data_after_sign_in!
  session.keys.grep(/^devise\./).each { |k| session.delete(k) }
end

ファイルのダウンロード機能の注意

リンクはこちら

ファイルダウンロードをする際に、ダウンロードパスにparamsの値を含める場合は../../xxxなどのparamsで悪さをされないように、構築されたダウンロードパスとアプリ側が想定しているパスが一致するかを検証する必要があります。

結構うっかりしてしまいそうな箇所にも思うので、知識としてしっかり頭に入れておかないといけないですね。

アカウント総当たり攻撃に対する対策

リンクはこちら

Webアプリケーションの設計でおろそかにされがちなのは、いわゆる「パスワードを忘れた場合」ページです

ついついユーザーの目先の便利さを求めて「指定されたメールアドレスは存在しません」といった内容にしてしまいそうですが、これは攻撃者にとってはヒントになるので危ないということですね。
ただ、ユーザーがtypoした場合などもあるので、そういった際に本当に困っているユーザーが自主的に気付けるようにする仕組みが必要そうです。

メールの変更にもパスワードを要求するべし

リンクはこちら

アカウントのメールアドレスを変更する攻撃を仕掛けることでパスワードをお忘れですか？からアカウントを乗っ取るということができてしまうので、メールアドレスを変更する際にもパスワードを要求するべしという内容です。

パスワード変更の際に旧パスワードを要求するのは当然必要として忘れないと思いますが、メールアドレスの方は漏れやすいようにも思いました。

正規表現

リンクはこちら

Rubyの^や$は、入力全体の冒頭と末尾ではなく「行の」冒頭と末尾にマッチしてしまうので、\Aや\zを使うべしという内容です。

これは知らないとすぐ踏んでしまうと思います。

str = "javascript:exploit_code();/*\nhttp://hi.com\n*/"

str.match?(/^https?:\/\/[^\n]+$/i)
#=> true

str.match?(/\Ahttps?:\/\/[^\n]+\z/i)
=> false

ヘッダーインジェクションの対策

リンクはこちら

ヘッダーの情報も比較的容易に操作できてしまうので、User-Agentを管理者画面でエスケープなしで表示するなどしてはいけないという内容です。
また、refererもそのまま使うと危ないので適切な対処が必要です。

DNSリバインディングの対策

リンクはこちら

DNSリバインディングをきちんと理解できていなかったので、これを機に調べました。

罠サイトはユーザーが一度アクセスした直後に別のIPアドレスを返すように変更し、「信頼された」状態となったブラウザを通じてユーザーの内部ネットワークなどにアクセスします。

Railsでは、Rails.application.config.hostsで許可するホストを制限することでDNSリバインディング対策を実施します。

deep_mungeで安全でないクエリ生成を防止

リンクはこちら

意図しないクエリを発行しないようにしているのがdeep_mungeメソッドです。

mungeはdeeplだと翻訳が出ませんでしたが、weblioだと「コードを難読化する」という意味が表示されました。

config.action_dispatch.perform_deep_munge = falseを設定してJSONで{ "person": null }のパラメータを送信した時

params  #=> {"person":[null], ...}

config.action_dispatch.perform_deep_munge = falseを設定せずにJSONで{ "person": null }のパラメータを送信した時

params  #=> {"person":[]... }

CORS

リンクはこちら

Rack CORSミドルウェアによってCORSを有効にできます。
Railsガイドの例のように設定してから以下のようにcurlでレスポンスヘッダーを確認すると、access-control-allow-originなどが設定できていることを確認できました。

$ curl -I -X OPTIONS http://localhost:3000 -H 'Origin: http://example.com'
...
access-control-allow-origin: http://example.com
access-control-allow-methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
...

2024-02-12

GitHub Actionsを使って子供が産まれてからの週数を毎日LINEで通知する

プログラミング

先日子供が産まれたのですが、予防接種の問診票等で何週目か？や何ヶ月何日か？といった情報が頻繁に必要になります。

毎回計算するのが面倒だったのでLINEで毎日通知させることにしました。
定期実行はGitHub Actionsにやってもらうことにしました。

その方法を記録していこうと思います。（ChatGPTにたくさん助けてもらいました。）

1. LINE BOTのアカウントを作成

LINEにデベロッパー登録して、BOTとなるチャンネルを作成します。
デベロッパーとしての登録などの方法は他のサイトにいくらでも書いてあるので割愛します。（自分はすでにアカウントを持っていたので忘れたというのもあります）

今回使ったのはLINEのMessaging APIです。 developers.line.biz

2. LINEのメッセージ送信の実装

難しいことは特になく、行ったこととしては、主に以下です。

line-bot-apigemを使う
- チャネルシークレットとチャネルアクセストークン（長期）を利用
broadcastメソッドを使い、友達になった全員にメッセージを送信するようにする

Messeging APIでは、ユーザーIDを指定して送信する、や友達全員に対して送信する、など色々と方法があります。

developers.line.biz

line-bot-apiではそれぞれに対応したメソッドが用意されています。

3. 日付のロジックを計算する

生まれてから何日か、何週何日かは特に考えることもなかったですが、何ヶ月何日目かは色々考えることがあって面白かったです。

月の月末までの日数の考慮
- 例: 誕生日が3/20の場合、今日が4/1場合は0ヶ月12日で、5/1の場合では1ヶ月11日ととなるように、月末が何日あるかによってズレる
誕生日の日にちを迎えているかどうかで月の計算が変わる
- 例: 今日が2/12で誕生日が1/13の場合、0ヶ月30日になるが、誕生日が1/11なら1ヶ月1日になる
誕生日を迎えているかどうかで年の計算が変わる
- 例: 今日が2024/2/12で誕生日が2023/2/11の場合、1歳だが、2023/2/13が誕生日なら0歳

実装したコード（一部）

if TODAY_MONTH >= BIRTH_MONTH
  # 例: 今が5月で誕生月が3月なら5 - 3で2ヶ月
  passed_month = TODAY_MONTH - BIRTH_MONTH
else
  # 例: 今が3月で誕生月が5月なら12 - (5 -3)で10ヶ月
  passed_month = 12 - (BIRTH_MONTH - TODAY_MONTH)
end

if TODAY_DAT_NUM >= BIRTH_DAY_NUM
  # 例: 今日が20日で誕生日が5日なら単純な引き算で15日
  passed_day = TODAY_DAT_NUM - BIRTH_DAY_NUM
else
  # 例: 今日が10日で誕生日が20日なら前月の最終日を確認しながら計算する
  prev_month_date = TODAY.prev_month
  prev_max_date = Date.new(prev_month_date.year, prev_month_date.month, -1).day
  passed_day = (previous_max_date - BIRTH_DAY_NUM) + TODAY_DAT_NUM
  # このケースだと、たとえば今が5月で誕生月が4月の場合、1月も経っていないので-1する
  passed_month -= 1
end

passed_year = TODAY_YEAR - BIRTH_YEAR
# 今年誕生日を迎えているか？を確認し、迎えていない場合は-1する
passed_year -= 1 if TODAY < Date.new(TODAY_YEAR, BIRTH_MONTH, BIRTH_DAY_NUM)
"#{passed_year}才#{passed_month}ヶ月#{passed_day}日"

4. GitHub Actionsで実行するためのYAMLファイルを作成

.github/workfrows下にYAMLファイルを作成するだけで勝手にGitHub Actionsが把握して実行してくれます。
cronで毎日朝9:00にAPIを叩きに行くようにしました。

docs.github.com

なお、動作確認のためにGitHub上から手動で実行できるworkflow_dispatchが便利でした。

docs.github.com

実装したYAML一部

on:
  schedule:
    - cron: '0 0 * * *' # 日本時間でAM9:00
  workflow_dispatch:

環境変数（LINEのアクセストークン等）の設定は、リポジトリの設定から可能です。

ハマりかけたポイント

1. cronで設定しても実行されない？

動作確認でcronで2分後くらいに設定してpushしたのですがその時間になってもワークフローが実行されませんでした。

設定が悪いのかな？と思ったのですが、実際には実行開始が遅れているだけのようでした。
GItHubの公式ドキュメントにそれっぽいことが書いてありました。

Note: The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs

実際に、朝9:00に実行するようにスケジュールしたんですが、実行されたのは9:33でした。

2. 環境変数が反映されない？

実装の途中で環境変数を1つ追加したのですが、GitHubのSecrets and variablesに設定しているのに環境変数がruby スクリプトから取得できませんでした。

なんでだ？と思って色々見ていたら、単純にYAMLファイルでXXX_KEY: ${{ secrets.XXX_KEY }}を書くのを忘れていただけでした。。。

まとめ

特に難しいことはしていないですが、ちょっと面倒だったことを解決できると嬉しいですね。
LINE APIは以前使ったことがありましたが、GitHub Actionsのcronは初めて自分で設定して使ったので勉強になりました。

今回実装したリポジトリ

github.com

2024-02-10

Railsガイドにきちんと目を通して新しい知識を得る - Rails 国際化（I18n）API編 -

Rails

今回は、Rails 国際化（I18n）APIの章です。

railsguides.jp

パラメータでロケールを管理する際の工夫されたURL設計

リンクはこちら

ルーティングを以下のように書くことで、https://xxx.com/yyy?locale=jaなどではなく、https://xxx.com/en/yyyにアクセスした際にparamsでlocaleを受け取ることができます。
※あくまでparamsのlocaleで値を受け取れるだけで、ロケールが変更されるというわけではないです。

# routes.rb
scope "/:locale" do
  resources :books
end

Railsガイド中の、以下の記載もなるほどなーと思いました。

アプリケーションの設計面から見れば、ロケールはアプリケーションドメインの他の部分よりも構造上の上位に位置するのだから、ロケール情報もURLの上位に置くべきという考え方もあります。

アプリによっては、基本は日本が対象であれば、Railsガイドにも紹介されている以下のように省略（デフォルト）できるようにするのが良さそうです。
さらに以下では言語も絞っていて、enかja以外だとRoutingErrorになります。

# routes.rb
scope "(:locale)", locale: /en|ja/ do
  resources :books
end

セッションやcookieにロケール情報を含めるのはNG

リンクはこちら

ロケールはURLの一部にするべきであるということが書いてあります。
URLを共有した相手が同じページを見れる「RESTful」であることを守るためということです。

YAMLでエスケープが必要なキー

リンクはこちら

つい先日会社の勉強会でも話題になったのですが、YAMLのクセについてです。
いくつか特定のキーはエスケープしないと訳文が見つからないエラーになってしまいます。

trueとかfalseとかはなんとなくわかりますが、yes, no, on, offあたりもエスケープしないといけないのは個人的に驚きがある仕様です。
知らないと地味にハマりポイントになりそうです。

# YAML
sample:
  on: 'Sample On!'
dummy:
  'on': 'Dummy On!'

I18n.t('sample.on') #=> Translation missing
I18n.t('dummy.on') #=> Dummy On!

`index.en.html.erb`でテンプレートファイルごと区別する

リンクはこちら

たとえば3つ上のところで設定したようなルーティング（英語と日本語のロケールがあるもの）のとき、index.en.html.erbなどとすることでロケールによってテンプレートファイルを分けることができます。
1つのファイルで表現するのは難しいとか、内容が大きく異なるときなどはこちらを使うのが良さそうです。

ただ、試したところ、たとえばデフォルトロケールが日本語の状態で、index.ja.html.erbとindex.html.erbだけ用意して英語のロケールでアクセスすると、index.ja.html.erbが使われました。
なんとなくindex.html.erbが使われるのかな？と思っていたのでこの優先度は意外でした。

translateメソッドの参照

リンクはこちら

scope

# YAML
sample:
    parent:
      child1:
        child2: 'Child2!'

上記は以下で呼び出せます。文字列の形で.で繋ぐ方法しか使ってこなかったので知りませんでした。

I18n.t(:child2, scope: [:sample, :parent, :child1])
#=> 'Child2!'

default

訳文が見つけられなかったときに表示するものを指定できます。

# YAML
dummy: '見つけられなかったらこれ'

I18n.t('no_exist', default: :dummy)
#=> "見つけられなかったらこれ"
I18n.t('no_exist', default: [:no_exist1, :no_exist2, :dummy])
=> "見つけられなかったらこれ"

ハッシュで複数取得

# YAML
parent:
    child1: 1つ目
    child2: 2つ目
    child3: 3つ目

配列で複数取得したり、親要素を指定してハッシュで取得したりもできます。

I18n.t(['parent.child1', 'parent.child2'])
#=> ["1つ目", "2つ目"]
I18n.t('parent')
#=> {:child1=>"1つ目", :child2=>"2つ目", :child3=>"3つ目"}

deep_interpolation: trueで変数を使う

まとめて取得する際に変数に値を入れたい場合はdeep_interpolation: trueを使う必要があります。

# YAML
parent:
    child1: 1つ目
    child2: 2つ目 %{foo}

I18n.t('parent', deep_interpolation: true, foo: 'フー')
#=> {:child1=>"1つ目", :child2=>"2つ目 フー"}

ロケール固有のルール

i18n.plural.ruleで固有の複数形化のルールを設定できるというものです。
I18n::Backend::Simple.include(I18n::Backend::Pluralization)を使うことで柔軟な複数形の対応ができるようになります。

# YAML
apples:
    one: 0もしくは1
    other: 1より大きい

I18n.t :apples, count: 0, locale: :ja
#=> "1より大きい"

I18n::Backend::Simple.include(I18n::Backend::Pluralization)
I18n.backend.store_translations :ja, i18n: { plural: { rule: lambda { |n| [0, 1].include?(n) ? :one : :other } } }

I18n.t :apples, count: 0, locale: :ja
#=> "0もしくは1"

バックエンドを切り替える

リンクはこちら

I18n.backend=でバックエンドを切り替えることができます。
Redisを読みに行くようにするなどをすることがあるみたいですね。

たとえば以下のように適当にバックエンドを指定してあげると、.ymlファイルでは翻訳ができなくなりました。

# YAML
hello: こんにちは

# application.rb

config.i18n.backend = I18n::Backend::KeyValue.new(String.new)

I18n.t('hello')
#=> 'Translation missing'

訳文が見つからなかった時に例外を発生させる

リンクはこちら

config.i18n.raise_on_missing_translations = trueにすることで訳文が見つからなかった場合に例外が発生します。
viewでtranslateメソッドを使った場合には訳文が見つからないとkey名をそのまま返すため、訳文の実装を忘れていても意外と気づきにくいです。
Railsガイドで書いてあるようにtest環境（もしかしたらdevelopment環境も？）をtrueにするのはアリだなと思いました。

Sprocketsの利用法

マニフェストファイルとディレクティブ

Sprocketsにおけるindex.css

.css.erb

rails実行前にコードを実行する

Rails全般の設定

週初めの設定をconfig.beginning_of_weekで設定する

config.colorize_loggingでログの出力に色付けをする

config.disable_sandboxでsandboxの利用をさせない

config.enable_reloadingでクラス等の変更時、リクエストごとに再読み込みするかどうかを決める

config.sandbox_by_defaultでデフォルトをsandbox環境にする

ActiveRecordを設定する

config.active_record.partial_inserts

active_record.before_committed_on_all_records

ActionControllerを設定する

raise_on_open_redirectsでオープンリダイレクト脆弱性の対策を強化する

SQLクエリコメント

debug gemによるブレークポイント

breakで行数や実行コードを指定して処理を止める

watchでインスタンスの変化があった場合に処理を止める

サブスクライバの設定

エラーを通知しつつ、握りつぶす

セッション固定攻撃の対策

ファイルのダウンロード機能の注意

アカウント総当たり攻撃に対する対策

メールの変更にもパスワードを要求するべし

ヘッダーインジェクションの対策

DNSリバインディングの対策

deep_mungeで安全でないクエリ生成を防止

CORS

1. LINE BOTのアカウントを作成

2. LINEのメッセージ送信の実装

3. 日付のロジックを計算する

4. GitHub Actionsで実行するためのYAMLファイルを作成

ハマりかけたポイント

1. cronで設定しても実行されない？

2. 環境変数が反映されない？

まとめ

パラメータでロケールを管理する際の工夫されたURL設計

セッションやcookieにロケール情報を含めるのはNG

YAMLでエスケープが必要なキー

index.en.html.erbでテンプレートファイルごと区別する

translateメソッドの参照

scope

default

ハッシュで複数取得

deep_interpolation: trueで変数を使う

ロケール固有のルール

バックエンドを切り替える

訳文が見つからなかった時に例外を発生させる

`index.en.html.erb`でテンプレートファイルごと区別する