breaking changesの可能性があるプルリク・コミット #53058（Deprecate built-in sidekiq adapter）★ 634f90b（Remove deprecated internal SuckerPunch adapter）★ f9e51b7（Remove support to set ActiveJob::Base.enqueue_after_transaction_commit to :never, :always, and :default）★ #55583（Optimize Active Job argument serialization by ~5x）★ 個別のプルリクにも目印として★を追加しています。 🔗 Deprecate built-in sidekiq adapter by fatkodima · Pull Request #5
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Use Sidekiq Directly, Not Through Active Job - Andy Croll 原文公開日: 2021/10/04 著者: Andy Croll 参考: 週刊Railsウォッチ20211018: SidekiqをActive Job経由ではなく直接使う 参考: Active Job の基礎 - Railsガイド Webアプリケーションを構築する場合は、ユーザーごとのレスポンスに要する時間を最小限に留めるべきです。Webサイトが速ければ速いほど、その分ユーザーも幸せになれます。 そのための方法の1つは、重くなる可能性のある処理（実行に長時間かかる、パラレル化可能な処理）を、イミディエイトなWebリクエストの外で非同期実行することです。メール送信、計画的なクリーンアップ、長時間かかる計算、外部API
皆さん、こんにちは。プルリクで間違った指摘をして大反省中 の osada です。 プルリクで間違った指摘をして大反省中です。 下記のコードで、何を指摘したか、お分かりになるでしょうか？ class NotificationJob < ActiveJob::Base queue_as :default def perform(notifiable, user) notifiable.notify(user) end end こんなことを言ってしまったのです。 オブジェクトを丸ごとシリアライズすると、redis の容量を圧迫し、 シリアライズ・デシリアライズにも時間が掛かるので、 クラス名とidを渡して、job の中で取り出して使って下さい。 この発言には2つ、間違いがありました。 1つ目は、オブジェクトが丸ごとシリアライズされると思っていたこと。 2つ目は、ActiveJob は クラス名と
こんにちは どうも、ぷりんたいです。さいきん、 Mastodon がTwitter廃人たちの間で大ブームですね。 今日はそんな Mastodon の話……ではなく、 Mastodon でも採用されている Ruby 製のバックグラウンドジョブフレームワーク Sidekiq を軸に非同期処理の話をします。 ターゲット読者は、 Sidekiq で非同期処理をはじめたばかりの入門レベル程度の方を想定しています。 アンチパターン アンチパターンとは、一言でいえば「よくないやり方」のことです。 みなさんの現場でも当座をしのぐことだけを目的として、エイヤ設計やソイヤ実装をしてしまうこともあるかもしれません。しかし、それらはしばしの眠りの後に技術的負債、または技術的致命傷としてプロダクトに跳ね返ってきます。 そういった、現場で起こりがちな問題の早期発見や予防をするために、誤った設計や実装の例を集め分類され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く