20241109

bundler はグローバルにインストールしていい bundle add rails するだけでグローバルにインストールしてもいい時代やったんや。手癖で –path vendor/bundle しがちだったけど、グローバルにインストールしたほうが vendor ディレクトリを git ignore する必要すらなくなるしよい。付けない派に転向する。 https://qiita.com/jnchito/items/99b1dbea1767a5095d85 .local/share/mise/installs との組み合わせがわからんけど… rbenv exec bundle exec とかしなくていいようになっているっぽいから結果良ければそれでよい。 ➜ gem environment (... snip ...) ➜ fd 'rails$' -t x /Users/kyagi/.local/share/mise/installs/ruby/ --exec ls -l -rwxr-xr-x@ 1 kyagi staff 549 Nov 9 15:09 /Users/kyagi/.local/share/mise/installs/ruby/3.3.4/bin/rails -rwxr-xr-x@ 1 kyagi staff 234 Sep 29 18:08 /Users/kyagi/.local/share/mise/installs/ruby/3.3.4/lib/ruby/gems/3.3.0/gems/railties-7.1.3.4/exe/rails -rwxr-xr-x@ 1 kyagi staff 234 Nov 9 15:09 /Users/kyagi/.local/share/mise/installs/ruby/3.3.4/lib/ruby/gems/3.3.0/gems/railties-8.0.0/exe/rails

20241108

rails 8 GA https://github.com/rails/rails/releases/tag/v8.0.0 solid queue を使う予定はないけれど、db を sqlite3 にしたい気持ちはある。 ➜ bin/rails -T | grep solid bin/rails solid_cable:install # Copy over the schema and set cable adapter for Solid Cable bin/rails solid_cache:install # Copy over the migration, and set cache bin/rails solid_queue:install # Install Solid Queue bin/rails solid_queue:start # start solid_queue supervisor to dispatch and process jobs

20241029

Rails 8 は 10 月中にリリースされるか 1 ヶ月前 beta1 が、2 週間前に rc1 が出たからそろそろか。Rails 8 がリリースされたら個人開発の開発環境も追随して、かつ　PostgreSQL も 1 ヶ月前 に出た 17 にしよう。 https://github.com/rails/rails/milestone/87 年内やクリスマスを意識すると世界的に秋にリリースが固まる傾向があるのかもしれない。

20240825

少し幹から離れると情報が過疎になる fly.io にデプロイしていている個人開発アプリの staging 環境が整ってきた。 以下の要素をうまく同期できているのがよい。 AWS Organizations + IAM Identity Center のベストプラクティスに則ったメンバーアカウント(SDLC/awesomeapp-stg) rails の config/ENVIRONMENT.rb rails の credentials/ENVIRONMENT.key fly.io の fly secrets set RAILS_MASTER_KEY=$(cat config/credentials/.key) fly launch が生成した Dockerfile デフォルトだと production 環境をデプロイしようとするので、調整が必要だったが、こういうニッチな情報はネットにないので自分で試行錯誤する必要があった。 これはこれでどこかでブログにまとめておこう。

20240727

PostgreSQL のダンプデータからテーブル名を別名にしてリストアする 既存の Rails アプリをいちから作り直しているうちに、だいぶ形になってきた。 すでにデータは既存のアプリにあるので、そちらからテーブル名を別名にしてリストアする方法を探していたが、以下に落ち着いた。 既存のテーブル名を sources 新規のテーブル名を destinations とする場合、一度別名でテーブルのコピーを作成する。 その後ダンプしてリストア時に別名にしたテーブルを指定すればよい。 > CREATE TABLE destinations AS SELECT * FROM sources; ➜ pg_dump -f db/development.dump.bin.postgres ${db} -Fc ➜ pg_restore -c -U rails -W -d [PROJECT_NAME]_development -t destinations development.dump.bin.postgres

20240725

さようなら dotenv, こんにちは Encrypted credentials The Complete Guide to Ruby on Rails Encrypted Credentials を読んで 認証情報の保存場所を .env から config/credentials/development.yml.enc に切り替えた。 Rails における認証情報の取り扱いの新標準だと思う。 この変更により rails アプリから認証情報を参照する方法も変わることになる。 screenshot of diff 同時にマスターキーも config/credentials/development.key になる。 これにより既存の config/credentials.yml.enc と config/master.key は不要になるので削除してしまってよい。環境ごとの認証情報と鍵は以下のコマンドで生成できる。 ➜ EDITOR="vi" rails credentials:edit --environment=development これで dotenv とさよならできるかと思ったが、AWS SDK にホームディレクトリ配下 .aws/{config,credentials} の認証情報を読みにいかせないための AWS_SDK_CONFIG_OPT_OUT だけは必要になる。これだけなら認証情報でもなんでもない。いままでは .gitignore でコミットしないとはいえ .env に平文で書かれていた認証情報が気になったが今後はそういう こともなくなるので精神衛生上もよい。 ➜ cat .env AWS_SDK_CONFIG_OPT_OUT=true 新旧を比較すると以下のようになる。development.yml.enc と development.key は環境ごとに staging や production と読み替えることが可能。 いままで これから 提供元 rubygem: dotenv rails 標準機能 認証情報の格納ファイル .

20240721

AWS Cognito Hosted UI 個人開発しているアプリの認証基盤に AWS Cognito を使用するため、土日に弄んでいた。 最初は SDK 経由での実装を試みていたが、ネット上にあまり例が見つからないのと、手順が煩雑な印象を受けていて諦めそうになっていたところ、 YouTube の動画で Hosted UI の機能を知った。 フォーム自体を AWS が生成してくれるのでアプリが acc/pass を全く触ることなく認証を完了できるのがよい。 Hosted UI でコールバックされた後にどうすればいいのかが不明だったが AWS 公式ブログのこの記事の Authorization code grant の通りにやってみたら 無事にユーザープールにアクセスすることができた。Rails アプリとしては UUID で管理されているユーザー ID を Users テーブルに格納するだけでよい。 個人開発者にとって 認証基盤など個人では手に負えない分野は巨大テックの企業努力を利用させてもらう のが正しいアプローチだと思う。 4. After Amazon Cognito verifies the user pool credentials or provider tokens it receives, the user is redirected to the URL that was specified in the original redirect_uri query parameter.