こんにちは どうも、ぷりんたいです。さいきん、 Mastodon がTwitter廃人たちの間で大ブームですね。 今日はそんな Mastodon の話……ではなく、 Mastodon でも採用されている Ruby 製のバックグラウンドジョブフレームワーク Sidekiq を軸に非同期処理の話をします。 ターゲット読者は、 Sidekiq で非同期処理をはじめたばかりの入門レベル程度の方を想定しています。 アンチパターン アンチパターンとは、一言でいえば「よくないやり方」のことです。 みなさんの現場でも当座をしのぐことだけを目的として、エイヤ設計やソイヤ実装をしてしまうこともあるかもしれません。しかし、それらはしばしの眠りの後に技術的負債、または技術的致命傷としてプロダクトに跳ね返ってきます。 そういった、現場で起こりがちな問題の早期発見や予防をするために、誤った設計や実装の例を集め分類され

技術部のフルタイムRubyコミッタの遠藤（@mametter）です。昨日の Hackarade #04 の開催報告に続き、2日連続で記事を投稿します。 今回は、ある条件下でのRubyの実行速度を高速化した話を紹介します。この改善はすでにMRIの先端にコミットされていて*1、年末リリース予定のRuby 2.6に含まれる予定です。 ひとことで言うと、「簡潔ビットベクトルを索引に使うことで、プログラムカウンタから行番号を計算するアルゴリズムをO(log N)からO(1)に改善した。これにより、TracePoint有効時やコードカバレッジ測定下で、長さ N のメソッドの実行が O(N log N) から O(N) に高速化される」ということです。順に説明します。 背景：Rubyのバイトコードの構造 この最適化を理解するにはまず、Rubyのバイトコードのある特徴を知る必要があります。 たとえば x

最近プルリクを作ったり見るときに考えてること。 前提 プルリクはマージされてシップするまで顧客に対して価値を産んでいない 1秒でも早くマージしてシップすることが何より大切 もちろん質をおろそかにしていいわけではない この2つをレビュアーとレビュイーが共有する必要がある どうやったら早くマージできるか これは単純で プルリクの意図/価値を共有しておく やり取りの回数を減らす 指摘→修正→指摘→修正みたいなのはさける 読むべき量を減らす だけでOK レビュイーとして プルリクの意図を必ず書く 「なぜ」これが必要なのか 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高) 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい 余計な変更は入れない コードスタイルの変更などは読むときのノイズになる 伝わりづらい/自分でもわかりづらいと思