Sidekiqを利用しているときにテストで気をつけること

Testing · sidekiq/sidekiq Wiki にあるように、sidekiqをテストで利用する際には3つのモードがあります。

• fake(デフォルト)
• inline
• disable

これらを切り替えるメソッドとしてSidekiq::Testing.fake!などがあります。これらのメソッドはブロックを受け付けており、ブロックを渡すとそのブロックの中だけ一時的にモードが変わります。なので

before do 
  Sidekiq::Testing.inline!
end

after do
  Sidekiq::Testing.fake!
end

のようにするより

around do |example|
  Sidekiq::Testing.inline! do
    example.run
  end
end

のほうが良いと思ったんですが、これらの書き方は等価ではないので場合によっては前者の書き方じゃないとダメだったりします。

後者のブロックを用いた書き方ではモードが変わるのはカレントスレッドだけ、という制限があります。このため後者をsystem testで使うと、pumaのスレッドではモードが変更されないのでした。ドキュメントもよく読むと

When passing a block, the mode change only applies to the current Thread and is not process-wide.

のように書いてありますね。そうですね。

株式会社ウィルネットはプログラミングRuby 第5版の翻訳を支援します

日本語で読めるRubyの本をもっと増やしたいので、プログラミングRuby 第5版 翻訳支援の募集に応募して企業スポンサーをすることにしました。

いまどきはAIにプログラミングに関する質問ができますが、正確性や網羅性という点でまだまだ書籍の価値は高いと思っています。あと単純にもっとRubyの本が読みたい！

個人でもスポンサーにもなれるようなので、僕と同じようにRubyの本を増やしたい方はリンク先を見てみるとよさそうです。

ginza.rb 第92回を開催してアプリケーションサーバについて学んだ

Ginza.rb 第92回 - アプリケーションサーバについて学ぶぞ - connpass

第92回はRubyから使うアプリケーションサーバについて学びました。

アプリケーションサーバ2025

実は第75回や第76回でもその当時新しかったアプリケーションサーバについて学ぶというのをやっていました。しかしそこから6年経過してpitchforkなどまた状況が変わっているかな、ということで再度のアプリケーションサーバ回です。

y-yagiさんの用意してくれた資料をみながらワイワイしました。今回とりあげたサーバは以下の5つです。

• puma
• unicorn
• pitchfork
• falcon
• Itsi

pitchforkとItsiが新しい枠でpuma、unicorn、falconが既存枠。

雑感

アプリケーションサーバに求められているのは何より安定性なので、その点で新しいアプリケーションサーバがpumaの牙城を崩すのはなかなか難しいなという印象を持ちました。どれだけ速いとか機能の豊富さを売りにしているサーバがあってもお仕事の本番環境に入れるハードルはなかなか高い。

その点でpitchforkはShopifyが本番運用しているぞ、というのが安心材料として大きいと思います。reforkを有効にしたかったら仕事で利用しているライブラリでfork unsafeなものがあるかどうか調べる必要があり大変だけど、そこさえクリアすればメモリ面などでの恩恵が得られるのでトライする価値はありそう。

unicornの今後のメンテナンスがどうなるかはわからないので、いまunicornを利用しているプロジェクトであればrefork機能をオフにしたpitchforkもしくはスレッド数1にしたpumaに移行して、余裕があればreforkもしくは複数スレッドにトライするのが良いんじゃないかなと思いました。

次回

次回は10月24日(金)開催で、Kaigi on Rails 2025の振り返りをする予定です。興味のあるひとはどうぞ。

続・wkhtmltopdfの次どうするか問題

wkhtmltopdfの次どうするか問題 - おもしろwebサービス開発日記の続き。

上の記事でも書いていますが、令和の今RailsアプリケーションでPDFを生成する基本的な方針としては次の2択だと思っています。

• chromeを使ってHTMLからPDFに変換する
• Thinreports などで直接PDFを生成する

「chromeを使ってHTMLからPDFを生成する」のgemとしてはgroverが有名ですね。だけどこれはruby -> puppeteer -> chromeという構成で、間にnode製のツールであるpuppeteerが挟まっています。

ferrum はrubyから直接chromeを扱うgemなので、これを利用するとnodeが不要になるしメモリ消費量も多少下がるはずだしいいじゃん、と前記事を書いているときは思っていました。しかしferrumはあくまでchromeを操作するのが目的のツールなので「Railsが生成したHTMLからPDFを生成する」ために必要な機能は備えていません。

例えば「RailsでrenderしたHTMLをchromeに食わせてPDFに変換する」部分は自分で書く必要があるし、「HTML中の相対パスで書かれているリンクを絶対パスに変換する」というのも必要になってきます。

なのでferrumだけだといろいろ自分たちで頑張らないといけない部分が多かったのですが、この面倒な部分をやってくれるgem ferrum_pdfが去年くらいからリリースされています。まだ個人的には使えてないですが、@takeyuwebさんは導入したことがあるようです。

なのでgroverを使うようなケースであればferrum_pdfを試してみるのがいいかと思っています。

でも本当にこれでいいのかな？

ferrum_pdfを使うにしても結局「chromeを使ってHTMLからPDFに変換する」形式なのでアプリケーションサーバのメモリが心配になるケースがありそうです。その場合は別インスタンスに「HTMLをPDFに変換する専用アプリケーションサーバ」を立ててPaaSSaaSのように運用するのがいいんじゃないかな〜とぼんやり考えています。そうするとメモリ消費量が心配になったときにHTML->PDFの部分だけスケールアウトできるので…。

この手のPaaSSaaS自体は探すといくつかヒットしますが、HTMLを外部サービスに投げたくない場合がほとんどなはず。

ｶｯとなったら作るかもしれませんが直近ではその予定がないので、もし興味のあるひとがいたら作ってもらえると嬉しいです。

gon v6.5.0をリリースした

gonのメンテナになった - おもしろwebサービス開発日記 の続き。

新しいRubyで出るwarningやエラーなど一通り対応できたかな、という状況になったので作者からrubygems.orgにpushする権限をもらってv6.5.0をリリースしました。使ってみてなにかおかしいところあったら教えて下さい。

テストコードが微妙な箇所がまだかなりあるので、今後気が向いたときにほそぼそと直していきます。

gonのメンテナになった

gazay/gon: Your Rails variables in your JS

お手伝い先で使っているので見てみたら最終コミットが4年前でIssueやPRが積み重なっており、CIはTravisCIという状況。メンテされないgemとどう向き合うか。“普通のOSS開発者” willnetさんの取り組み で書いたようにCIをGitHub Actionsに移行するPRを出して作者にメンションするも音沙汰なし、というところで気合を入れて作者にメールをしたところメンテナ(collaborator)にしてもらえました。

seed-doと同様に、新しいRubyやRailsで動かないのをなんとかするくらいのモチベはあるのでできる範囲で頑張っていこうと思います。

ginza.rb 第91回を開催してGumroadについて学んだ

Ginza.rb 第91回 - Gumroadのソースコードを読むぞ - connpass 第91回はOSSになったGumroadのコードを読みました。

Gumroad

実際にお金を稼いでいるアプリケーションのコードをOSSにして、外部コントリビュータのPRをうけつつその上で開発を進めるというのは世界的に見てもなかなかユニークな形式なのではないでしょうか。

流石にコード公開前の履歴まではみれないですが、それ以外は特にコードの公開用に体裁を整えた形式が見えないのが潔いなと思いました。コードを眺めるとapp/helpersにビューヘルパーではないヘルパー用モジュールが含まれているのとか、app/modulesがなんでもモジュール置き場になっているのとかにとてもリアルさを感じます。このような負債は多かれ少なかれ歴史のあるアプリケーションには必ず見られるものですが、今後これとどのように付き合っていくのかを外部から見守っていけるのはありがたいところです。

Gemfileをみると数多くのgemが使われているのがわかります。かなり古くメンテナンスが滞っているgemもありますが、恐らく「この便利gemは知らなかった…」というものが1つや2つは見つかるはず。

AIの活用という点でも学べる点は多いです。まずコードを書く方面でLLMを活用しています。.cursorrulesが定義されていたり、devinがPRを作っていたりします。レビューにはCodeRabbit、Diamond、Cursor – BugBotを利用しているようです。

あとはコード中でもLLMを活用しています。koicさんも書いていますが、自然言語で書いた返金ポリシーをLLMに解釈させていい感じにユーザに応じた返金までの期間を算出するのが面白かったです。現状ふつうのプログラミングでは算出が難しいロジックの一部をLLMにまかせて運用工数を短縮する面白い実例なのではないでしょうか。

10年以上の歴史を持つコードであり分量も多いですが、読む価値はあると思います。

次回

次回は8月8日(金)開催で「アプリケーションサーバ」というお題で実施する予定です。この分野だとpumaやunicornが有名ですが、それ以外にも数多くの選択肢があるぞというのを掘り下げていく予定です。

興味のある人は予定を開けておいてください。