このエントリは SmartHR Advent Calendar 2023の21日目の記事です。 Railsのバージョンを上げる作業は、単に新しいバージョンのgemをインストールするだけでは終わりません。Railsの新しいバージョンに沿った設定項目を確認し、適宜適用していく必要があります。もちろん必ずしもすべての設定を最新にしなければならないわけではありませんが、Railsの新しい設定というのは基本的にそうすることにメリットがあるから作られているわけで、特別な理由がなければ最新の状態にしておきたいものです。 みなさんのRailsアプリケーションのconfig/application.rb には次のような設定があるはずです。 config.load_defaults 6.1 このコードサンプルは引数が6.1なので、Rails6.1デフォルトの設定を適用していることを示しています。これを7.0に

Kaigi on Rails初のオフライン開催であるKaigi on Rails 2023で登壇する機会をいただけました。 例外は遅い 資料と動画は こちら から辿れます。 ちょっと間が空いてしまいましたが、以下登壇に関連してつらつら思いついたことを書いています。 なんでこの題材で話をしたんですか これまでのKaigi on Railsの発表内容から 明日の業務から使えるRailsの知見 Railsアプリケーション開発の実例 に関連したキャッチーなテーマが採択されやすんだろうな〜、とあたりをつけていました。僕は前者のネタはたくさんストックがある*1ので、その中で みんな興味がありそう 既存の書籍や記事ではあまり取り上げられていない題材 として、例外がよさそうだとなったのでした。発表でも言及した destroyじゃなくてdestroy!を使いましょう rescue_fromだけでエラーハンド

先日、仕事でRails(Active Record)の難しい仕様に遭遇したので共有するためにエントリをしたためました。似たようなケースに遭遇した人の手助けになれば幸いです(\( ⁰⊖⁰)/) 対応Railsバージョンと設定 Rails6.1以上 config.active_record.has_many_inversing = true(Rails6.1のデフォルト設定)である 問題1 まず次のコードを読んでみてください。 class User < ApplicationRecord has_many :posts end class Post < ApplicationRecord belongs_to :user, inverse_of: :posts # (1) before_update { puts 'before_update' } end user = User.new po

wkhtmltopdfというライブラリは、HTMLからPDFを生成してくれるライブラリです。Rubyからだとwicked_pdfや pdfkit 経由で使われることが多いです。 さてそんなwkhtmltopdfですが、GitHubリポジトリ を見るとわかるようにアーカイブされてしまっています。公式ページ に経緯が書いてありますが、要約するとwkhtmltopdfが依存しているQtWebkitのメンテが止まったのが原因でメンテが続けられなくなったということのようです。 wkhtmltopdfが参照しているQtWebkitはかなり古いものなので、モダンなブラウザでの描画と差分が出たり、脆弱性を付かれたりする可能性がありそう。なのでなにか別のやり方に乗り換えたい。 選択肢を考えてみる 乗り換え先は具体的に何がいいの、というと僕も自信を持ってこれだ！という解を持っていないのですが、headless

表題の通りのことができるgem、CiLoggerが便利ですよという話です。 私達は大量のテストをCI上で実行しています。テスト結果を見れば失敗理由が自明なものもありますが、E2Eテストなどでよく起きる「たまに失敗するテスト」の調査はログやスクリーンショットなど、可能な限りの情報を集めないと根本原因がつかめないことが多いです。 そんなときに、特に考えずRailsデフォルトの設定(config.log_level #=> :debug)のままにしておくと、膨大なログの中から該当するテストに関連する行を探し当てる作業が必要になります。これは事前の準備なしではほぼ不可能です。 事前の準備として簡単に思いつく方法は、テスト前後で「どのテストが開始/終了したか」をログに出力することです。 config.around do |example| Rails.logger.debug("start exam

この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に

以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。 上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか？」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1。 あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。 想定読者 良いエンジニアを採用したい偉いひと、もしくは人事のひとです。 前提: 良いエンジニアとは このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニ