Rails on shimoju.diary

Rails 6.1のままRuby 3.2にアップデートし、YJITの恩恵を受ける

Thu, 10 Aug 2023 18:02:00 +0900

先日、携わっているサービスで一番大きいRailsアプリをRuby 3.2にアップデートし、YJITを有効化できました。方針を検討した結果、今回はRails 6.1およびPsych 3系のままRuby 3.2にアップデートする戦略をとったため、その手順をまとめます。

先週にメインのサービスをRuby 3.2にしてYJITを有効にできました！
実際に速くなったし嬉しい大YJIT記念日だ🎉 https://t.co/Wkhc6fDfj9

Kaigi on Railsでリモートワークについて発表しました

Sat, 24 Oct 2020 17:47:48 +0900

Kaigi on Railsにて「快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン」というタイトルで発表しましたshimojuです。無事燃え尽きていましたが、遅ればせながら感想ブログを書きました。

資料はこちらです。動画については順次公開中なのでそのうちアップされるはずです。

初めてのオンライン登壇ですが、特にトラブルなく終えられて一安心でした。当日の配信環境については上に書いてありますが、事前に練習会があり、Zoomの画面共有やYouTube配信側でどう見えるかのテストができたのがよかったです。これがなかったら当日かなり焦っていました。

2019年、SUZURIの怪事件

Fri, 06 Dec 2019 02:01:08 +0900

SUZURI Advent Calendar 2019の5日目の記事です。ちょっと遅れました。

SUZURIでエンジニアをしているしもじゅーです。最近はSUZURIのAndroidアプリを開発するために目下勉強中で、Android何もわからない…となっています。

今年自分が担当したのは目に見えない裏側部分や長い調査を必要としたものが多かったです。謎の不具合にも悩まされたのでそこからいくつか紹介します。ご迷惑をおかけしたものもありますが、裏側ではこんなことやっているんだ、と感じていただければ幸いです。

Herokuでzip_code_jp gemの郵便番号データを定期更新したい

Mon, 17 Sep 2018 22:50:34 +0900

日本の郵便番号データを扱うRuby gemとしてはzip_code_jpが有名です。ECサイトなどでは郵便番号から住所を補完する機能はもはや当たり前になっていますが、そのような機能を作りたいときに便利なライブラリです。

この郵便番号データはZipCodeJp.export_jsonで更新できますが、このときgemのdata/zip_codeディレクトリ内にあるJSONファイルを直接更新します。一般的なサーバ環境であればcronで回すなどすれば普通に更新できますが、Herokuの場合はローカルにファイルを書き込んでも再起動のタイミングで自動で消滅します。Heroku Schedulerなどで定期実行しても、既にパッケージされたslug内のデータは変更できないので意味がありません。 Release Phaseでいけないかな？とも思いましたが、Release Phaseはslugのビルド後に実行されるのでこれも使えません。

HerokuのRelease PhaseでDBマイグレーション忘れを防ぐ

Sun, 29 Jul 2018 21:46:04 +0900

HerokuにはRelease Phaseという機能があります。これはアプリケーションのビルドが終わってリリースする直前に任意のコマンドを実行するもので、DBのマイグレーションやキャッシュの削除といった用途に使えます。

設定方法はProcfileにrelease: commandの形式で書くだけです。例えば、Railsでmigrateとseed-fuを実行するのであれば以下のようになります。

WerckerでRailsアプリをCIしてSlack通知する

Sun, 22 Jul 2018 22:07:55 +0900

オラクルに買収されてから存在感が薄くなった(?)ような気がするWerckerですが、使う機会があったのでRailsでの設定をメモしておきます。

# wercker.yml
box:
 id: ruby:2.5.1

services:
 - id: mysql:5.7
 env:
 # rails-database-yml stepはrootユーザーを使わないのでランダムパスワードにしておく
 MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
 # 以下の3つを設定する必要がある
 MYSQL_DATABASE: rails_test
 MYSQL_USER: rails
 MYSQL_PASSWORD: password

 - id: redis:4

build:
 steps:
 # Node.jsは入っていないのでインストールする
 - script:
 name: install node.js
 code: curl -fsSL https://deb.nodesource.com/setup_8.x | bash - && apt-get install -qq nodejs
 # bundleのキャッシュもしてくれる
 # https://github.com/wercker/step-bundle-install
 - bundle-install
 # 自動的にdatabase.ymlの設定をしてくれる
 # https://github.com/wercker/step-rails-database-yml
 - rails-database-yml
 - script:
 name: copy .env
 code: cp .env.sample .env
 # Redisの接続先この方法でしか取れなかったけどもっといい方法ありそう
 - script:
 name: redis config
 code: echo REDIS_URL=redis://$REDIS_PORT_6379_TCP_ADDR:$REDIS_PORT_6379_TCP_PORT >> .env
 - script:
 name: db setup
 code: bundle exec rails db:schema:load db:seed_fu
 - script:
 name: rspec
 code: bundle exec rspec

 after-steps:
 # Slack通知
 # https://github.com/wercker/step-slack
 - slack-notifier:
 # 環境変数で設定
 url: $SLACK_WEBHOOK_URL
 channel: channel_name
 username: wercker

環境変数はWeb画面上で設定し、wercker.yml内では$変数名で参照します。「Protected」にすると設定値が見えなくなるので、秘匿情報を設定するときに便利です。

better_errorsがやたら遅いときは最新版にアップデートするとよい

Sat, 14 Jul 2018 19:18:49 +0900

better_errorsが入ったRailsプロジェクトを最近触っているのですが、エラー画面の表示がやたら遅く、コンソールが使い物にならない状態になっていました。 Puma 3系で発生しており、リクエスト・レスポンス変数内のpuma.configのサイズが非常に大きく、通信に時間がかかってしまっているからのようです。

この対策として、最新バージョンの2.4.0(2017年10月リリース)でサイズの大きいインスタンス変数をフィルタする機能が追加されていました。フィルタ設定はデフォルトで有効なので、最新版にアップデートすればいい感じになります。

# e.g. in config/initializers/better_errors.rb
# This will stop BetterErrors from trying to render larger objects, which can cause
# slow loading times and browser performance problems. Stated size is in characters and refers
# to the length of #inspect's payload for the given object. Please be aware that HTML escaping
# modifies the size of this payload so setting this limit too precisely is not recommended.
# default value: 100_000
BetterErrors.maximum_variable_inspect_size = 100_000

最近ではweb-consoleがあるのでbetter_errorsをやめることも検討したのですが、これで快適に使えるようになりました。