7 posts
先日、携わっているサービスで一番大きい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にて「快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン」というタイトルで発表しましたshimojuです。無事燃え尽きていましたが、遅ればせながら感想ブログを書きました。 資料はこちらです。動画については順次公開中なのでそのうちアップされるはずです。 快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン 当日の配信環境について Kaigi on Rails 発表動画 初めてのオンライン登壇ですが、特にトラブルなく終えられて一安心でした。当日の配信環境については上に書いてありますが、事前に練習会があり、Zoomの画面共有やYouTube配信側でどう見えるかのテストができたのがよかったです。これがなかったら当日かなり焦っていました。
SUZURI Advent Calendar 2019の5日目の記事です。ちょっと遅れました。 SUZURIでエンジニアをしているしもじゅーです。最近はSUZURIのAndroidアプリを開発するために目下勉強中で、Android何もわからない…となっています。 今年自分が担当したのは目に見えない裏側部分や長い調査を必要としたものが多かったです。謎の不具合にも悩まされたのでそこからいくつか紹介します。 ご迷惑をおかけしたものもありますが、裏側ではこんなことやっているんだ、と感じていただければ幸いです。
日本の郵便番号データを扱う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のマイグレーションやキャッシュの削除といった用途に使えます。 設定方法はProcfileにrelease: commandの形式で書くだけです。例えば、Railsでmigrateとseed-fuを実行するのであれば以下のようになります。 Procfile release: bin/rails db:migrate db:seed_fu web: bundle exec puma -C config/puma.rb DBマイグレーションを忘れて500エラーはあるあるな話ですが、これで防ぐことができます。 コマンドが失敗したとき(0以外のステータスで終了したとき)はもちろんデプロイは行われません。
オラクルに買収されてから存在感が薄くなった(?)ような気がするWerckerですが、使う機会があったのでRailsでの設定をメモしておきます。 wercker.yml 1box: 2 id: ruby:2.5.1 3 4services: 5 - id: mysql:5.7 6 env: 7 # rails-database-yml stepはrootユーザーを使わないのでランダムパスワードにしておく 8 MYSQL_RANDOM_ROOT_PASSWORD: 'yes' 9 # 以下の3つを設定する必要がある 10 MYSQL_DATABASE: rails_test 11 MYSQL_USER: rails 12 MYSQL_PASSWORD: password 13 14 - id: redis:4 15 16build: 17 steps: 18 # Node.jsは入っていないのでインストールする 19 - script: 20 name: install node.js 21 code: curl -fsSL https://deb.nodesource.com/setup_8.x | bash - && apt-get install -qq nodejs 22 # bundleのキャッシュもしてくれる 23 # https://github.com/wercker/step-bundle-install 24 - bundle-install 25 # 自動的にdatabase.ymlの設定をしてくれる 26 # https://github.com/wercker/step-rails-database-yml 27 - rails-database-yml 28 - script: 29 name: copy .env 30 code: cp .env.sample .env 31 # Redisの接続先この方法でしか取れなかったけどもっといい方法ありそう 32 - script: 33 name: redis config 34 code: echo REDIS_URL=redis://$REDIS_PORT_6379_TCP_ADDR:$REDIS_PORT_6379_TCP_PORT >> .env 35 - script: 36 name: db setup 37 code: bundle exec rails db:schema:load db:seed_fu 38 - script: 39 name: rspec 40 code: bundle exec rspec 41 42 after-steps: 43 # Slack通知 44 # https://github.com/wercker/step-slack 45 - slack-notifier: 46 # 環境変数で設定 47 url: $SLACK_WEBHOOK_URL 48 channel: channel_name 49 username: wercker 環境変数はWeb画面上で設定し、wercker.yml内では$変数名で参照します。「Protected」にすると設定値が見えなくなるので、秘匿情報を設定するときに便利です。
better_errorsが入ったRailsプロジェクトを最近触っているのですが、エラー画面の表示がやたら遅く、コンソールが使い物にならない状態になっていました。 Puma 3系で発生しており、リクエスト・レスポンス変数内のpuma.configのサイズが非常に大きく、通信に時間がかかってしまっているからのようです。 この対策として、最新バージョンの2.4.0(2017年10月リリース)でサイズの大きいインスタンス変数をフィルタする機能が追加されていました。フィルタ設定はデフォルトで有効なので、最新版にアップデートすればいい感じになります。 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をやめることも検討したのですが、これで快適に使えるようになりました。