Software

基本的にはRailsガイドの手順に従えば良いと思います。

ガイドの手順にもありますが、ぜひbin/rails app:updateコマンドを活用しましょう。

rails 8.0への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。

bundle binstubs brakemanを用いるやり方に更新しました。

rails 7.2では、新規アプリに対してデフォルトでGitHubワークフローの設定ファイルであるci.ymlが生成されるようになりました。そこで、このci.ymlの内容について簡単に解説します。

なお、ci.ymlの最新のテンプレートはこちらでご覧になれます。

scan_ruby

bin/brakemanコマンドを実行するジョブです。 Railsの一般的なセキュリティ脆弱性がないかどうかチェックします。

scan_js

bin/importmap auditコマンドを実行するジョブです。 利用しているJavaScriptパッケージにセキュリティ上の脆弱性がないかどうかチェックします。

lint

bin/rubocopコマンドを実行するジョブです。 Rubyの静的コード解析を行い設定されているルールに準拠しているかどうかチェックします。

test

bin/rails testコマンドを実行するジョブです。なお、skip_system_testオプションが無効であれば、システムテストも実行します。

Rails 7.2においてDev Container設定を生成する機能が追加されました。 例えば既存アプリでは、以下のコマンドで既存アプリ用のDev Container設定を生成できるようになりました。

rails devcontainer

生成した設定は、Visual Studio Codeで利用でき、Dev Containerを利用した既存アプリの開発が可能となります。 必要となるソフトウェアのインストール等、Dev Containerでの開発を開始するための手順についてはDev Containerでの開発ガイドが参考になります。

なお、Visual Studio Code以外のエディタでもDev Containerで開発できるようにするべくDev Container CLIというツールの開発が進んでいますが、2024年12月現在では、ポートフォワーディングに対応していないなど、今のところはまだまだ開発途中のツールであり、実開発に投入するにはまだ早い段階である印象です。

Dev Container CLIはポートフォワーディングをサポートしていないので、Dev Containerの中で動かしたWebサーバへDev Containerの外で動いているブラウザからアクセスするようなことはDev Container CLI単体では出来ないそうです。ちなみに、ポートフォワーディングを可能にする手法やツールはいくつか提案されているようです。

公式GitHubレポジトリを見ると、2024年12月現在、以下の機能に完了のチェックマークがまだ入っていません。

• devcontainer stop - Stops containers
• devcontainer down - Stops and deletes containers

したがって、ウインドウズキーを押してから、「wt」と打って、エンターでWindows Terminalを起動可能。

その他、引数など、コマンドラインからWindows Terminalを叩く場合の詳細は以下から。

https://learn.microsoft.com/ja-jp/windows/terminal/command-line-arguments?tabs=windows

BlueStacks 5を立ち上げてしばらく経つと動かしていたアプリが勝手にシャットダウンする現象に遭遇し困っていた。 ネットで少し調べてみて、「Google Playストア」アプリの「ストレージを消去」したところ、この現象が起きなくなった。 ちなみに、ストアアプリやシャットダウンしていた方のアプリでキャッシュ削除をしたりもしたので、 このキャッシュ削除の方が有効打になった可能性もある。以上ご参考まで。

バージョン

BlueStacks App Player 5.21.600.1019 P64

参考

https://www.reddit.com/r/BlueStacks/comments/1h6lqje/bluestacks_app_interface_freezing_and_google/

Rails 7.2からRuboCopが新規アプリケーションでデフォルトで有効になりました。 このTopicでは、7.1以前で作成した既存RailsアプリにRuboCopを後から導入して、RuboCopに関して7.2の新規アプリ相当の状態にセットアップする方法をご紹介します。

RuboCop (Omakase Ruby styling for Rails) のインストール

基本的にはrubocop-rails-omakaseの公式ドキュメントのインストール手順に従います。

まず以下のように、Gemfileのgroup :development, :testのところにrubocop-rails-omakaseを追加します。

group :development, :test do

  # Omakase Ruby styling [https://github.com/rails/rubocop-rails-omakase/]
  gem "rubocop-rails-omakase", require: false

end

次にbundle installを実行して、RuboCop等をインストールします。

bundle install

さらに、必須ではありませんが、bin/rubocopでRuboCopを実行できるように、以下のコマンドを実行します。

bundle binstubs rubocop

最後に.rubocop.ymlという名前でファイルを作成し、以下の内容を記述します。

# Omakase Ruby styling for Rails
inherit_gem:
  rubocop-rails-omakase: rubocop.yml

以上でRuboCop (Omakase Ruby styling for Rails) のセットアップが出来ました。

ローカル環境でのbin/rubocopの実行とその結果に対する対応の進め方

以下のコマンドでbin/rubocopを実行でき、omakaseのチェックを行えます。

bin/rubocop

このチェックでの指摘事項が多かった場合、以下のオプションを付けて実行することで、 無視設定を記述した.rubocop_todo.ymlというファイルが作成され、 .rubocop.ymlにもこの無視ファイルを参照する設定が追加されますので、 とりあえず全ての指摘事項を無視するように設定が出来ます。

bin/rubocop --auto-gen-config

設定が出来たら、bin/rubocopを実行して、とりあえず指摘事項の数が0となることを確認します。

1つずつ指摘事項へ対応

ここから先は、以下の手順を繰り返します。

• .rubocop_todo.ymlから1項目を削除
• bin/rubocopを実行して指摘内容を確認して対応
  • bin/rubocop -aもしくはbin/rubocop -Aを実行して自動修正できるものは自動修正し、その修正内容で問題ないことを確認
    • -aは安全なもののみ、-Aは安全で無いものも含めて自動修正を行います。
  • 自動修正できなかったものは手作業で修正・確認
  • 特定のファイルのみチェックを回避する場合は、.rubocop.ymlにてExclude:を用いて設定
  • ソースコードの特定の箇所（行）のみチェックを回避する場合は、ソースファイルのコメントに# rubocop:disable等を用いて設定
  • 指摘内容に対応する規則を完全に採用しない場合には、.rubocop.ymlにてEnabled: falseの記述を用いて規則を無効にする

1項目ずつ対応を進め、.rubocop_todo.ymlの中身が無くなったら、.rubocop_todo.ymlを削除すると共に、.rubocop.yml内で.rubocop_todo.ymlを参照している設定を削除します。ここまで終わればRuboCopの諸規則への対応は完了となります。お疲れ様でした。

GitHubワークフロー（CI）でのrubocopの実行

.github/workflows/ci.ymlに相当するファイルがなければ作成します。 この.ymlファイルを編集して、以下のようにjobsの下にlintジョブを追加します。

注意点

• timeout-minutes:の設定は、実行時間に対して十分余裕を持たせて下さい。
• ruby-version: .ruby-versionという設定は、プロジェクトルートにある.ruby-versionという名前のファイルで指定されているrubyのバージョンという意味になります。この設定について詳しくはこちらのTopicをご覧下さい。
• -f githubオプションは、出力フォーマットをGitHub Actionsに適したものにするオプションです。

jobs:
  lint:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: .ruby-version
          bundler-cache: true

      - name: Lint code for consistent style
        run: bin/rubocop -f github

公式情報

• RuboCopのその他の詳細についてはRuboCop公式ドキュメントをご覧ください。
• Omakase Ruby styling for RailsのRuboCop設定の最新の内容はGitHubで確認出来ます。なお、最新ではなくインストールしたバージョンのRuboCop設定内容をご覧になりたい場合は、GitHubの操作でTagsから当該バージョンを選択するようにして下さい。

概要

Rubyでは、以下のようにshareable_constant_value: literalというマジックコメントを記入することで、 以下の例のように、定数に代入したArrayやHashのリテラルを深く（deeply）freezeすることが出来ます。

# shareable_constant_value: literal

X = [{foo: []}]
X.frozen? # => true
X[0].frozen? # => true
X[0][:foo].frozen? # => true

少し詳しい話

shareable_constant_valueマジックコメントはRuby 3.0で導入されました。

注意点

このマジックコメントのliteralモードでfreezeされるのは定数が対象であるため、 以下のように、代入先が変数である場合にはfreezeされません。

# shareable_constant_value: literal

z = []
z.frozen? # => false

また、このマジックコメントのliteralモードを指定したファイル内では、以下のように、 「freezeされていないオブジェクト」や「freezeされていないものを含むオブジェクト」を定数に代入しようとするとエラーが発生します。

# shareable_constant_value: literal

Y = [{}, Object.new] # => エラー発生

裏を返せば、以下のように、freezeすればエラーが回避できます。 また、freezeする定数とfreezeしない定数でファイルを分けるという自然なアプローチでもエラーを回避できます。

# shareable_constant_value: literal

Y = [{}, Object.new.freeze]

参考文献

• Ruby公式のshareable_constant_valueのドキュメント