ryz310

1 ヶ月も前になってしまいましたが、クラッソーネの <a href="https://twitter.com/yamat47">@yamat47</a> さんが拙作の <a href="https://github.com/ryz310/rubocop_challenger">rubocop_challenger</a> を使って <code>.rubocop_todo.yml</code> を解消した、というブログを書いて下さいました。

かつての自分と同じような課題を抱えていた方に自分の gem を役立てて頂けたのは本当に嬉しいです。
ブログ化までして下さった @yamat47 さん、本当にありがとうございます！

<blockquote class="twitter-tweet">今年に入ってからちょっとずつ進めてたRuboCopのTodoとの戦いをまとめて記事にしました！こんな感じの、開発者向けの改善をするのもめちゃ好きです😀<a href="https://t.co/82F6xmAKko">https://t.co/82F6xmAKko</a>&mdash; Takuya Yamaguchi (@yamat47) <a href="https://twitter.com/yamat47/status/1427785662602743811?ref_src=twsrc%5Etfw">August 18, 2021</a></blockquote>


 <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

また、gem の README では Circle CI を使った方法しか紹介してなかったのですが、<a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> Actions を使った方法についても解説して頂いており、重ね重ね感謝感激です🙏
<a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> の README からもリンク貼らせて頂きました！

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fzenn.dev%2Fyamat47%2Farticles%2F219e14ebcf31a1d13ff4" title="RuboCop ChallengerをGitHub Actionsで動かす" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://zenn.dev/yamat47/articles/219e14ebcf31a1d13ff4">zenn.dev</a></cite>

<h2>一方で、ひとつ気になったことが。。</h2>

<blockquote>自動で解消できるものがなくなって以降はRuboCop Challengerの仕組みが不要になったので、最後は削除してしまいました。

<img src="https://tech.crassone.jp/images/posts/resolve-rubocop-todos-step-by-step/good-bye-rubocop-challenger.png" alt="手動で対応した履歴" />

ありがとう、RuboCop Challenger...!!</blockquote>

待って！
Rubocop Challenger は消さないで残しておくと良いことがあります！

<h2>Rubocop Challenger は v2.0.0 から bundle update 機能も兼ね備えています</h2>

本家 RuboCop の gem をアップデートする時、新しく追加された Cop によってエラーが出てしまった、という経験は無いでしょうか？
このエラーの解消が億劫で gem のアップデートを放置してしまっている方もいるかも知れません。

Rubocop Challenger v1.0.0 のテーマは「負債の解消」だったんですが、 v2.0.0 からは「RuboCop との共生」だったりします。

誰にも話したこと無いので今始めて公表しました←

v2.0.0 以上の Rubocop Challenger では最初に RuboCop 関連の gem に対して <code>bundle update</code> を実行するようになっています。

最新の RuboCop にアップデートした状態で Rubocop Challenge を実行するので、新しく追加された Cop に違反したコードがあった場合、その場で即 <code>auto-correct</code> を実行し、<a href="https://github.com/ryz310/my_api_client/pull/616">以下のような PR</a> を作成してくれます。

<figure class="figure-image figure-image-fotolife" title="PR1"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923205915.png" alt="f:id:ryz310:20210923205915p:plain" width="949" height="388" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption><a class="keyword" href="http://d.hatena.ne.jp/keyword/RSpec">RSpec</a>/ExcessiveDocstringSpacing を修正した PR が作成されました</figcaption></figure>
<figure class="figure-image figure-image-fotolife" title="PR2"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923210041.png" alt="f:id:ryz310:20210923210041p:plain" width="1200" height="455" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>同 PR で <code>rubocop-rspec</code> が v2.4.0 から v2.5.0 にアップデートされています</figcaption></figure>

一方 dependabot も <code>rubocop-rspec</code> v2.5.0 の bundle update の PR を作成してくれていますが、こちらは CI の RuboCop チェックでエラーになっています。
RuboCop の CI チェックをパスしないと merge 出来ない設定にしている場合も多いと思いますが、これを修正するのは地味に面倒です。

<figure class="figure-image figure-image-fotolife" title="aaa"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923210548.png" alt="f:id:ryz310:20210923210548p:plain" width="936" height="364" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923210545.png" alt="f:id:ryz310:20210923210545p:plain" width="955" height="291" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>RuboCop の CI チェックでエラー</figcaption></figure>

ちなみに違反したコードが存在しない場合は <a href="https://github.com/ryz310/rubocop_challenger/pull/531">Re-generate .rubocop_todo.yml with RuboCop v1.21.0</a> のような PR が作成され、 <code>bundle update</code> を実行しただけの PR が作成されます。

この機能は地味に便利なので、CI のスケジュール実行を使って週イチくらいで動かすのがオススメの使い方です。

<h2>v2.0.0 以降の RuboCop Challenger は Gemfile に含めない事をオススメします</h2>

<code>v2.0.0</code> あたりから RuboCop Challenger を Gemfile に含めて実行すると、他の gem との互換性問題でエラーになるケースを確認しております🙏
現在では以下のように CI での実行時に <code>gem install rubocop_challenger</code> を実行する方法をオススメしております。

<pre class="code lang-yaml" data-lang="yaml" data-unlink># .circleci/config.yml
version: 2

jobs:
 rubocop_challenge:
 docker:
 - image: circleci/ruby:3.0
 working_directory: ~/repo
 steps:
 - checkout
 - run:
 name: Rubocop Challenge
 command: |
 gem install rubocop_challenger
 rubocop_challenger go \
 --email=rubocop-challenger@example.com \
 --name=&quot;Rubocop Challenger&quot;

workflows:
 version: 2

 nightly:
 triggers:
 - schedule:
 cron: &quot;30 23 * * 1,2,3&quot; # 8:30am every Tuesday, Wednsday and Thursday (JST)
 filters:
 branches:
 only:
 - master
 jobs:
 - rubocop_challenge
</pre>


こちらは完全に自分がやらかしたというか、会社で書いた以下のブログの内容が古いまま更新しなかったため、 <code>Gemfile</code> に <code>rubocop_challenger</code> を入れて使っている方が沢山 (?) いるかも知れません。
<a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> の README ですら間違っていたので、さっき慌てて修正しました。。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F12%2F05%2F140000" title="まだ .rubocop_todo.yml で消耗してるの？ - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/12/05/140000">developer.feedforce.jp</a></cite>

古い方法で使ってしまった皆さん、本当にすみません。。

<code>rubocop_challenger</code> を Gemfile に含めるのが<code>.rubocop_todo.yml</code> 解消後にアンインストールしたくなる理由の一つだと思うので、これで使い続ける人が増えてくれると嬉しいです🙏

<h2>安全な auto-correct かどうかが分かります</h2>

特にアナウンスしていなかった気がするのでついでにご紹介しておくと、最新の Rubocop Challenger では「安全な auto-correct」かどうかが分かるようになっていて、 PR の本文に以下のような記述が入るようになっています。

<figure class="figure-image figure-image-fotolife" title="安全な auto-correct "><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923215918.png" alt="f:id:ryz310:20210923215918p:plain" width="426" height="156" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>✅ 安全な auto-correct</figcaption></figure>

<figure class="figure-image figure-image-fotolife" title="安全でない auto-correct"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210923/20210923220846.png" alt="f:id:ryz310:20210923220846p:plain" width="427" height="168" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>⚠️ 安全でない auto-correct</figcaption></figure>

RuboCop 公式によると「安全な auto-correct」の場合、元の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9">ソースコード</a>が壊れる心配は無いとのことなので、 PR merge する際の判断材料にして頂ければ。

1 ヶ月も前になってしまいましたが、クラッソーネの @yamat47 さんが拙作の rubocop_challenger を使って .rubocop_todo.yml を解消した、というブログを書いて下さいました。かつての自分と同じような課題を抱えていた方に自分の gem を役立てて頂けたのは本当に嬉しいです。ブログ化までして下さった @yamat47 さん、本当にありがとうございます！今年に入ってからちょっとずつ進めてたRuboCopのTodoとの戦いをまとめて記事にしました！こんな感じの、開発者向けの改善をするのもめちゃ好きです😀https://t.co/82F6xmAKko— Takuya Yamaguchi (@yamat47) August 18, 2021 また、gem の README では Circle CI を使った方法しか紹介してなかったのですが、GitHub Actions を使った方法についても解説して頂いており、重ね重ね感謝感激です🙏GitHub の README からもリンク貼らせて頂きました！zenn.dev一方で、ひとつ気になったことが。。自動で解消できるものがなくなって以降はRuboCop Challengerの仕組みが不要になったので、最後は削除してしまいました。ありがとう、RuboCop Challenger...!!待って！Rubocop Challenger は消さないで残しておくと良いことがあります！Rubocop Challenger は v2.0.0 から bundle update 機能も兼ね備えています本家 RuboCop の gem をアップデートする時、新しく追加された Cop によってエラーが出てしまった、という経験は無いでしょうか？このエラーの解消が億劫で gem のアップデートを放置してしまっている方もいるかも知れません。Rubocop Challenger v1.0.0 のテーマは「負債の解消」だったんですが、 v2.0.0 からは「RuboCop との共生」だったりします。誰にも話したこと無いので今始めて公表しました←v2.0.0 以上の Rubocop Challenger では最初に RuboCop 関連の gem に対して bundle update を実行するようになっています。最新の RuboCop にアップデートした状態で Rubocop Challenge を実行するので、新しく追加された Cop に違反したコードがあった場合、その場で即 auto-correct を実行し、以下のような PR を作成してくれます。RSpec/ExcessiveDocstringSpacing を修正した PR が作成されました同 PR で rubocop-rspec が v2.4.0 から v2.5.0 にアップデートされています一方 dependabot も rubocop-rspec v2.5.0 の bundle update の PR を作成してくれていますが、こちらは CI の RuboCop チェックでエラーになっています。RuboCop の CI チェックをパスしないと merge 出来ない設定にしている場合も多いと思いますが、これを修正するのは地味に面倒です。RuboCop の CI チェックでエラーちなみに違反したコードが存在しない場合は Re-generate .rubocop_todo.yml with RuboCop v1.21.0 のような PR が作成され、 bundle update を実行しただけの PR が作成されます。この機能は地味に便利なので、CI のスケジュール実行を使って週イチくらいで動かすのがオススメの使い方です。v2.0.0 以降の RuboCop Challenger は Gemfile に含めない事をオススメしますv2.0.0 あたりから RuboCop Challenger を Gemfile に含めて実行すると、他の gem との互換性問題でエラーになるケースを確認しております🙏現在では以下のように CI での実行時に gem install rubocop_challenger を実行する方法をオススメしております。# .circleci/config.ymlversion: 2jobs:  rubocop_challenge:    docker:      - image: circleci/ruby:3.0    working_directory: ~/repo    steps:      - checkout      - run:          name: Rubocop Challenge          command: |            gem install rubocop_challenger            rubocop_challenger go \              --email=rubocop-challenger@example.com \              --name="Rubocop Challenger"workflows:  version: 2  nightly:    triggers:      - schedule:          cron: "30 23 * * 1,2,3" # 8:30am every Tuesday, Wednsday and Thursday (JST)          filters:            branches:              only:                - master    jobs:      - rubocop_challengeこちらは完全に自分がやらかしたというか、会社で書いた以下のブログの内容が古いまま更新しなかったため、 Gemfile に rubocop_challenger を入れて使っている方が沢山 (?) いるかも知れません。GitHub の README ですら間違っていたので、さっき慌てて修正しました。。developer.feedforce.jp古い方法で使ってしまった皆さん、本当にすみません。。rubocop_challenger を Gemfile に含めるのが.rubocop_todo.yml 解消後にアンインストールしたくなる理由の一つだと思うので、これで使い続ける人が増えてくれると嬉しいです🙏安全な auto-correct かどうかが分かります特にアナウンスしていなかった気がするのでついでにご紹介しておくと、最新の Rubocop Challenger では「安全な auto-correct」かどうかが分かるようになっていて、 PR の本文に以下のような記述が入るようになっています。✅ 安全な auto-correct⚠️ 安全でない auto-correctRuboCop 公式によると「安全な auto-correct」の場合、元のソースコードが壊れる心配は無いとのことなので、 PR merge する際の判断材料にして頂ければ。

Rubocop Challenger 作者が教えるオススメの使い方。 〜 .rubocop_todo.yml 解消後も消さないで残しておくと良いことがあります！〜

前回のブログで <a href="https://github.com/ryz310/redis-objects-daily-counter">redis-objects-daily-counter</a> という gem を作ったという話をしました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fryz310.hateblo.jp%2Fentry%2F2021%2F09%2F20%2F172054" title="Redis::Objects を使ったサービス改善と新しい gem を作ったお話 - 逃げる8回で会心の一撃" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://ryz310.hateblo.jp/entry/2021/09/20/172054">ryz310.hateblo.jp</a></cite>

今回は <code>v0.3.0</code> をリリースしたのでそちらのご紹介です。

<h2>【おさらい】redis-objects-daily-counter はどういう gem なのか</h2>

<a href="https://github.com/nateware/redis-objects">redis-objects</a> gem の拡張として作られており、日付の変更毎に新しい counter を定義してくれる <code>daily_counter</code> 機能を提供する gem です。

例えば以下のような <code>Homepage</code> という class で <code>daily_counter :pv</code> という定義をします。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class Homepage
 include Redis::Objects

 daily_counter :pv, expireat: -&gt; { Time.now + 2_678_400 } # about a month

 def id
 1
 end
end
</pre>


すると以下のように <code>#pv</code> という<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9">インスタンス</a>メソッドが使えるようになります。
これは <code>redis-objects</code> gem の <code>counter</code> の拡張であり、 <code>#increment</code> や <code>#decrement</code> というメソッドで Redis 上の値を更新することが可能です。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 2021-04-01
homepage = Homepage.new
homepage.id # 1

homepage.pv.increment
homepage.pv.increment
homepage.pv.increment
puts homepage.pv.value # 3
</pre>


<code>daily_counter</code> が <code>counter</code> とどのように違うかというと、日付が変わるとRedis 上の Key が変化するという点です。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 2021-04-02 (next day)
puts homepage.pv.value # 0
homepage.pv.increment
homepage.pv.increment
puts homepage.pv.value # 2
</pre>


これは、 <code>daily_counter</code> が以下のようなルールに則って Redis の Key にアクセスするように振る舞うためです。

<pre class="code" data-lang="" data-unlink>model_name:id:field_name:yyyy-mm-dd</pre>


なお、この時の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BF%A5%A4%A5%E0%A5%BE%A1%BC%A5%F3">タイムゾーン</a>は実行中の <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> プロセスの標準<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BF%A5%A4%A5%E0%A5%BE%A1%BC%A5%F3">タイムゾーン</a>に従いますが、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 上で実行した場合は <code>application.rb</code> で指定した<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BF%A5%A4%A5%E0%A5%BE%A1%BC%A5%F3">タイムゾーン</a>に従います。

日付が変わった後も、前日までの Key-<a class="keyword" href="http://d.hatena.ne.jp/keyword/Value">Value</a> は削除していないので、 <code>#range</code> や <code>#[]</code> や <code>#at</code> というメソッドでアクセスすることが可能です。
ちなみに <code>#range</code> や <code>#[]</code> では値が返却されますが、 <code>#at</code> では <code>Redis::Counter</code> <a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9">インスタンス</a>が返却されます。
<code>v0.2.0</code> までは <code>#[]</code> と <code>#at</code> は同じ挙動でしたが、 <code>v0.3.0</code> からそういう実装に変わりました 🙏

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 2021-04-01
homepage.pv.increment(3)

# 2021-04-02 (next day)
homepage.pv.increment(2)

# 2021-04-03 (next day)
homepage.pv.increment(5)

homepage.pv[Date.new(2021, 4, 1)] # =&gt; 3
homepage.pv[Date.new(2021, 4, 1), 3] # =&gt; [3, 2, 5]
homepage.pv[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # =&gt; [3, 2]

homepage.pv.delete_at(Date.new(2021, 4, 1))
homepage.pv.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # =&gt; [0, 2, 5]
homepage.pv.at(Date.new(2021, 4, 2)) # =&gt; #&lt;Redis::Counter key=&quot;homepage:1:pv:2021-04-02&quot;&gt;
homepage.pv.at(Date.new(2021, 4, 2)).value # 2
</pre>


<h2>v0.3.0 で追加された機能とは</h2>

<code>daily_counter</code> に加えて <code>daily_set</code> が追加されました。
こちらは <code>redis-objects</code> gem の <code>set</code>に <code>daily-</code> 機能を追加したものになります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class Homepage
 include Redis::Objects

 daily_set :dau, expireat: -&gt; { Time.now + 2_678_400 } # about a month

 def id
 1
 end
end

homepage.dau &lt;&lt; 'user1'
homepage.dau &lt;&lt; 'user2'
homepage.dau &lt;&lt; 'user1' # dup ignored
puts homepage.dau.members # ['user1', 'user2']
puts homepage.dau.length # 2
puts homepage.dau.count # alias of #length
</pre>


<code>set</code> は重複を受け付けない <code>Array</code> と考えて良いと思います。
上記の例を見てもらうと分かりますが <code>user1</code> を 2 回追加しても <code>#members</code> による取得結果には 1 つしか含まれていません。

これを使って何が実現できるかというと、 DAU (Daily Active User) の計測です。
ログインしたユーザーの ID を <code>daily_set</code> で定義した変数に追加していくことで、その日アクティブだったユーザー一覧とその数を知ることが出来ます。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 2021-04-01
homepage.dau.merge('user1', 'user2')
puts homepage.dau.members # ['user1', 'user2']

# 2021-04-02 (next day)
puts homepage.dau.members # []

homepage.dau.merge('user2', 'user3')
puts homepage.dau.members # ['user2', 'user3']

# 2021-04-03 (next day)
homepage.dau.merge('user4')

homepage.dau.at(Date.new(2021, 4, 2)) # =&gt; #&lt;Redis::Set key=&quot;homepage:1:dau:2021-04-02&quot;&gt;
homepage.dau.at(Date.new(2021, 4, 2)).members # =&gt; ['user2', 'user3']
homepage.dau.at(Date.new(2021, 4, 2)).length # =&gt; 2
</pre>


<code>#range</code> や <code>#[]</code> を使う事で指定した期間内の値を結合することも出来ます。
これによって DAU 目的で記録した値から MAU を求めることも可能です。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>homepage.dau[Date.new(2021, 4, 1)] # =&gt; ['user1', 'user2']
homepage.dau[Date.new(2021, 4, 1), 3] # =&gt; ['user1', 'user2', 'user3', 'user4']
homepage.dau[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # =&gt; ['user1', 'user2', 'user3']

homepage.dau.delete_at(Date.new(2021, 4, 1))
homepage.dau.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # =&gt; ['user2', 'user3', 'user4']
</pre>


<code>#at</code> で一日ずつ値を取得して <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> の <code>Array#uniq</code> を使っても同じ結果が得られますが、 <code>#range</code> や <code>#[]</code> の方が内部で <a href="https://redis.io/commands/sunion">Redis の <code>SUNION</code></a> を利用するため高速だと思います。

ちなみに <code>#range</code> や <code>#[]</code> の結果は <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> の Array なので、 <code>#length</code> を使って長さを求める際は実行中のマシンリソースを消費します。
一方 <code>#at</code> では <code>Redis::Set</code> を返しており、 <code>Redis::Set#length</code> は内部で <a href="https://redis.io/commands/scard">Redis の <code>SCARD</code></a> を実行するため、 <code>#length</code> は <code>#at</code> からの方が高速だと思います。
ただし一定期間の値の結合は <code>#range</code> や <code>#[]</code> を使う必要があるので、結局マシンリソースの消費は避けられないですね。。

この辺りの仕様は実装していてかなり頭を悩ませました。なので今後のアップデートで破壊的な変更が入るかも知れません。

<h2><code>monthly_set</code> なども実装してあります</h2>

前回の記事でも紹介したような <code>monthly_counter</code> に相当する <code>monthly_set</code> なども使えます。
MAU, WAU, DAU で使い分けると良いかと思います。

<ul>
<li><code>annual_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy</code></li>
<li>Redis is a highly volatile key-<a class="keyword" href="http://d.hatena.ne.jp/keyword/value">value</a> store, so I don't recommend using it.</li>
</ul>
</li>
<li><code>monthly_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm</code></li>
</ul>
</li>
<li><code>weekly_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyyWw</code></li>
</ul>
</li>
<li><code>daily_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-dd</code></li>
</ul>
</li>
<li><code>hourly_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-ddThh</code></li>
</ul>
</li>
<li><code>minutely_set</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-ddThh:mi</code></li>
</ul>
</li>
</ul>

前回のブログで redis-objects-daily-counter という gem を作ったという話をしました。ryz310.hateblo.jp今回は v0.3.0 をリリースしたのでそちらのご紹介です。【おさらい】redis-objects-daily-counter はどういう gem なのかredis-objects gem の拡張として作られており、日付の変更毎に新しい counter を定義してくれる daily_counter 機能を提供する gem です。例えば以下のような Homepage という class で daily_counter :pv という定義をします。class Homepage include Redis::Objects daily_counter :pv, expireat: -> { Time.now + 2_678_400 } # about a month def id 1 endendすると以下のように #pv というインスタンスメソッドが使えるようになります。これは redis-objects gem の counter の拡張であり、 #increment や #decrement というメソッドで Redis 上の値を更新することが可能です。# 2021-04-01homepage = Homepage.newhomepage.id # 1homepage.pv.incrementhomepage.pv.incrementhomepage.pv.incrementputs homepage.pv.value # 3daily_counter が counter とどのように違うかというと、日付が変わるとRedis 上の Key が変化するという点です。# 2021-04-02 (next day)puts homepage.pv.value # 0homepage.pv.incrementhomepage.pv.incrementputs homepage.pv.value # 2これは、 daily_counter が以下のようなルールに則って Redis の Key にアクセスするように振る舞うためです。model_name:id:field_name:yyyy-mm-ddなお、この時のタイムゾーンは実行中の Ruby プロセスの標準タイムゾーンに従いますが、 Rails 上で実行した場合は application.rb で指定したタイムゾーンに従います。日付が変わった後も、前日までの Key-Value は削除していないので、 #range や #[] や #at というメソッドでアクセスすることが可能です。ちなみに #range や #[] では値が返却されますが、 #at では Redis::Counter インスタンスが返却されます。v0.2.0 までは #[] と #at は同じ挙動でしたが、 v0.3.0 からそういう実装に変わりました 🙏# 2021-04-01homepage.pv.increment(3)# 2021-04-02 (next day)homepage.pv.increment(2)# 2021-04-03 (next day)homepage.pv.increment(5)homepage.pv[Date.new(2021, 4, 1)] # => 3homepage.pv[Date.new(2021, 4, 1), 3] # => [3, 2, 5]homepage.pv[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # => [3, 2]homepage.pv.delete_at(Date.new(2021, 4, 1))homepage.pv.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # => [0, 2, 5]homepage.pv.at(Date.new(2021, 4, 2)) # => #<Redis::Counter key="homepage:1:pv:2021-04-02">homepage.pv.at(Date.new(2021, 4, 2)).value # 2v0.3.0 で追加された機能とはdaily_counter に加えて daily_set が追加されました。こちらは redis-objects gem の setに daily- 機能を追加したものになります。class Homepage include Redis::Objects daily_set :dau, expireat: -> { Time.now + 2_678_400 } # about a month def id 1 endendhomepage.dau << 'user1'homepage.dau << 'user2'homepage.dau << 'user1' # dup ignoredputs homepage.dau.members # ['user1', 'user2']puts homepage.dau.length # 2puts homepage.dau.count # alias of #lengthset は重複を受け付けない Array と考えて良いと思います。上記の例を見てもらうと分かりますが user1 を 2 回追加しても #members による取得結果には 1 つしか含まれていません。これを使って何が実現できるかというと、 DAU (Daily Active User) の計測です。ログインしたユーザーの ID を daily_set で定義した変数に追加していくことで、その日アクティブだったユーザー一覧とその数を知ることが出来ます。# 2021-04-01homepage.dau.merge('user1', 'user2')puts homepage.dau.members # ['user1', 'user2']# 2021-04-02 (next day)puts homepage.dau.members # []homepage.dau.merge('user2', 'user3')puts homepage.dau.members # ['user2', 'user3']# 2021-04-03 (next day)homepage.dau.merge('user4')homepage.dau.at(Date.new(2021, 4, 2)) # => #<Redis::Set key="homepage:1:dau:2021-04-02">homepage.dau.at(Date.new(2021, 4, 2)).members # => ['user2', 'user3']homepage.dau.at(Date.new(2021, 4, 2)).length # => 2#range や #[] を使う事で指定した期間内の値を結合することも出来ます。これによって DAU 目的で記録した値から MAU を求めることも可能です。homepage.dau[Date.new(2021, 4, 1)] # => ['user1', 'user2']homepage.dau[Date.new(2021, 4, 1), 3] # => ['user1', 'user2', 'user3', 'user4']homepage.dau[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # => ['user1', 'user2', 'user3']homepage.dau.delete_at(Date.new(2021, 4, 1))homepage.dau.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # => ['user2', 'user3', 'user4']#at で一日ずつ値を取得して Ruby の Array#uniq を使っても同じ結果が得られますが、 #range や #[] の方が内部で Redis の SUNION を利用するため高速だと思います。ちなみに #range や #[] の結果は Ruby の Array なので、 #length を使って長さを求める際は実行中のマシンリソースを消費します。一方 #at では Redis::Set を返しており、 Redis::Set#length は内部で Redis の SCARD を実行するため、 #length は #at からの方が高速だと思います。ただし一定期間の値の結合は #range や #[] を使う必要があるので、結局マシンリソースの消費は避けられないですね。。この辺りの仕様は実装していてかなり頭を悩ませました。なので今後のアップデートで破壊的な変更が入るかも知れません。monthly_set なども実装してあります前回の記事でも紹介したような monthly_counter に相当する monthly_set なども使えます。MAU, WAU, DAU で使い分けると良いかと思います。annual_setKey format: model_name:id:field_name:yyyyRedis is a highly volatile key-value store, so I don't recommend using it.monthly_setKey format: model_name:id:field_name:yyyy-mmweekly_setKey format: model_name:id:field_name:yyyyWwdaily_setKey format: model_name:id:field_name:yyyy-mm-ddhourly_setKey format: model_name:id:field_name:yyyy-mm-ddThhminutely_setKey format: model_name:id:field_name:yyyy-mm-ddThh:mi

MAU, DAU も計測できるようになった redis-objects-daily-counter v0.3.0

半年ぶりくらいに会社の勉強会で発表しました。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/58bb74a90a8b444e8607850fc76d8eb7" title="Redis::Objects で遊んでみよう" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 560px; height: 314px;"></iframe>


Redis::Objects という gem を使って RDS にかかっていた IO 負荷を改善した、という話と、 Redis::Objects を拡張する gem を作ったという話（後述）です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fredis-objects-daily-counter" title="GitHub - ryz310/redis-objects-daily-counter: Daily counter within Redis::Objects. Works with any class or ORM." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/redis-objects-daily-counter">github.com</a></cite>

Redis を使って DB の負荷を下げる系のお話って 2010 年代にされ尽くした感があって、今更な気もするんですが、一周回って最近聞かない話だなーと思ってます。
フロントエンドエンジニアで最近サーバーサイドも触る機会が増えたような方々にウケが良かった感じがありますね。

<hr />

一方で社内のインフラエンジニアからは Redis ってメンテナンスの手間が掛かって評判悪いですね。
使うだけなら手軽で楽なんですが、<a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> のアップデートでダウンタイムが発生する時に利用者向けにアナウンスしないといけなかったり。
ダウンタイムと言っても深夜に数秒〜数分なので影響は少ないと思うんですが、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%F3%A5%BF%A1%BC%A5%D7%A5%E9%A5%A4%A5%BA">エンタープライズ</a>向けのサービスとかやってるとこの辺は厳しいですね。

<a href="https://cloud.google.com/blog/ja/products/management-tools/sre-error-budgets-and-maintenance-windows">SRE のエラーバジェットの概念</a> が日本全体に浸透すればソフトウェア開発の生産性は底上げされるんじゃないかと思うのですが、この辺は時間を掛けて少しずつ啓蒙していくしか無いですね。例えば日本の生活インフラ（電気・水道・ガスとか電車とか）ってめっちゃ高水準なので、ソフトウェアの世界でも100％稼働することが当たり前という価値観になってしまうんじゃないかな、と思うのですが、この辺の価値観は表裏一体というか、当たり前と感じているから高品質になる一方で、生産性は下がってしまうという構図だと思っています。

<a href="https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s15/s15-fujisaki.pdf">https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s15/s15-fujisaki.pdf</a>
<figure class="figure-image figure-image-fotolife" title="SREの信条 (Google)"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210920/20210920165304.png" alt="f:id:ryz310:20210920165304p:plain" width="963" height="527" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>SREの信条 (<a class="keyword" href="http://d.hatena.ne.jp/keyword/Google">Google</a>)</figcaption></figure>

一応メンテナンスの手間、という点では夏頃に <a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> から <a class="keyword" href="http://d.hatena.ne.jp/keyword/Amazon">Amazon</a> MemoryDB for Redis というフルマネージドな Redis が発表されています。
東京リージョンは未対応で、書き込み速度が遅くなっていたり、料金も若干高くなっていたりしますが、気になるサービスではありますね。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdev.classmethod.jp%2Farticles%2Faws-release-durable-redis-amazon-memorydb-for-redis%2F" title="Redisに耐久性が加わったAmazon MemoryDB for Redisが登場 | DevelopersIO" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://dev.classmethod.jp/articles/aws-release-durable-redis-amazon-memorydb-for-redis/">dev.classmethod.jp</a></cite>

<hr />

さて、この記事のメインは冒頭で触れた Redis::Objects を拡張する gem を作ったよ、という話です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fredis-objects-daily-counter" title="GitHub - ryz310/redis-objects-daily-counter: Daily counter within Redis::Objects. Works with any class or ORM." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/redis-objects-daily-counter">github.com</a></cite>

発端は Redis::Objects の <code>counter</code> を使ってサービスの効果測定（メール配信数、CV 数、ログイン数など）をしたいなーと考えたことなんですが、効果測定って一定の期間毎に集計して改善した・していないの指標にしたいやつじゃないですか？
<code>counter</code> でカウントアップしつつ、日次の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>で集計すれば良いんですが、それだとあまり気軽じゃないというか、測定対象となるサービス開発の後、測定ロジックと<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>、保存先の DB テーブル作成までセットで実装しないと実現できないですよね。

これはサクッと実装するには <code>counter</code> が自動で日次で保存先を切り替えてくれれば良さそう、ということで、 <code>redis-objects-daily-counter</code> という gem は <code>daily_counter</code> という日次で保存先を切り替えるカウンター機能を提供します。
Redis::Objects を拡張して作ってあるので、使い方はほぼ同じで、対象としたい Class に <code>include Redis::Objects</code> を追加すると使えるようになります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># Gemfile
gem 'redis-objects-daily-counter'
</pre>




<pre class="code lang-ruby" data-lang="ruby" data-unlink>class Homepage
 include Redis::Objects

 daily_counter :pv, expireat: -&gt; { Time.now + 2_678_400 } # about a month

 def id
 1
 end
end

# 2021-04-01
homepage = Homepage.new
homepage.id # 1

homepage.pv.increment
homepage.pv.increment
homepage.pv.increment
puts homepage.pv.value # 3

# 2021-04-02 (next day)
puts homepage.pv.value # 0
homepage.pv.increment
homepage.pv.increment
puts homepage.pv.value # 2

start_date = Date.new(2021, 4, 1)
end_date = Date.new(2021, 4, 2)
homepage.pv.range(start_date, end_date) # [3, 2]
</pre>


<code>#increment</code> <code>#decrement</code> は <code>counter</code> と同じ使い勝手です。ただ、日付が変わると自動的に保存先が切り替わります。
これは Redis で保存している Key 名が以下のフォーマットになっているためです。

<pre class="code" data-lang="" data-unlink>model_name:id:field_name:yyyy-mm-dd</pre>


日付が変わった後も過去のレコードは削除されていないので、以下のコードでアクセス出来ます。この使い方は同じく Redis::Objects の <code>list</code> と似たような使い勝手になっています。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 2021-04-01
homepage.pv.increment(3)

# 2021-04-02 (next day)
homepage.pv.increment(2)

# 2021-04-03 (next day)
homepage.pv.increment(5)

homepage.pv[Date.new(2021, 4, 1)] # =&gt; 3
homepage.pv[Date.new(2021, 4, 1), 3] # =&gt; [3, 2, 5]
homepage.pv[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # =&gt; [3, 2]

homepage.pv.delete(Date.new(2021, 4, 1))
homepage.pv.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # =&gt; [0, 2, 5]
homepage.pv.at(Date.new(2021, 4, 2)) # =&gt; 2
</pre>


これで測定対象となるサービスを開発した後、 <code>daily_counter</code> で測定処理を実装しておくだけで OK。
この状態でリリースすればデータは溜まっていくので、週次や月次で集計する<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>を後でゆっくり実装すれば良いです。
<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>実装前にサーバー内で <code>$ bin/rails console</code> を実行して <code>daily_counter</code> の値を確認しながら<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>の実装を考える、とかも出来ますね。
具体的なデータを見ながらの方が開発難易度は下がります。

ちなみにですが、 <code>expireat</code> オプションを指定しておくことをオススメします。
gem の仕様上、どんどん Redis 上のメモリを圧迫していくので、一定期間後に自動的に削除するようにしましょう。

<hr />

<code>daily_counter</code> があるなら週次、月次、年次カウンターがあっても良いよね、なんだったら毎時、毎分カウンターもあったって良いじゃないか、という事で <code>v0.2.0</code> ではそれらが追加されています。

毎時・毎分のカウンターは <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> rate limit 機能の実装にも良いかもしれないですね。

<ul>
<li><code>annual_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy</code></li>
<li>Redis is a highly volatile key-<a class="keyword" href="http://d.hatena.ne.jp/keyword/value">value</a> store, so I don't recommend using it.</li>
</ul>
</li>
<li><code>monthly_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm</code></li>
</ul>
</li>
<li><code>weekly_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyyWw</code></li>
</ul>
</li>
<li><code>daily_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-dd</code></li>
</ul>
</li>
<li><code>hourly_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-ddThh</code></li>
</ul>
</li>
<li><code>minutely_counter</code>

<ul>
<li>Key format: <code>model_name:id:field_name:yyyy-mm-ddThh:mi</code></li>
</ul>
</li>
</ul>


一応実装はしましたが、 <code>annual_counter</code> のように期間の長いカウンターの利用はあまりオススメしません。
Redis ってふとした拍子にデータが飛んでしまう可能性があるので、あくまでキャッシュ的な位置付けで利用するのが良いと思います。
<code>daily_counter</code> も週次・月次で RDS に集計結果を保存する運用を想定していますので。

<hr />

というわけで久々のブログ更新では新しく作った <code>redis-objects-daily-counter</code> という gem の紹介をさせて頂きました。
これから弊社プロダクトでも利用していく予定ですし、色々なサービスでも活用頂けると嬉しいです。

半年ぶりくらいに会社の勉強会で発表しました。Redis::Objects という gem を使って RDS にかかっていた IO 負荷を改善した、という話と、 Redis::Objects を拡張する gem を作ったという話（後述）です。github.comRedis を使って DB の負荷を下げる系のお話って 2010 年代にされ尽くした感があって、今更な気もするんですが、一周回って最近聞かない話だなーと思ってます。フロントエンドエンジニアで最近サーバーサイドも触る機会が増えたような方々にウケが良かった感じがありますね。一方で社内のインフラエンジニアからは Redis ってメンテナンスの手間が掛かって評判悪いですね。使うだけなら手軽で楽なんですが、AWS のアップデートでダウンタイムが発生する時に利用者向けにアナウンスしないといけなかったり。ダウンタイムと言っても深夜に数秒〜数分なので影響は少ないと思うんですが、エンタープライズ向けのサービスとかやってるとこの辺は厳しいですね。SRE のエラーバジェットの概念 が日本全体に浸透すればソフトウェア開発の生産性は底上げされるんじゃないかと思うのですが、この辺は時間を掛けて少しずつ啓蒙していくしか無いですね。例えば日本の生活インフラ（電気・水道・ガスとか電車とか）ってめっちゃ高水準なので、ソフトウェアの世界でも100％稼働することが当たり前という価値観になってしまうんじゃないかな、と思うのですが、この辺の価値観は表裏一体というか、当たり前と感じているから高品質になる一方で、生産性は下がってしまうという構図だと思っています。https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/s15/s15-fujisaki.pdfSREの信条 (Google)一応メンテナンスの手間、という点では夏頃に AWS から Amazon MemoryDB for Redis というフルマネージドな Redis が発表されています。東京リージョンは未対応で、書き込み速度が遅くなっていたり、料金も若干高くなっていたりしますが、気になるサービスではありますね。dev.classmethod.jpさて、この記事のメインは冒頭で触れた Redis::Objects を拡張する gem を作ったよ、という話です。github.com発端は Redis::Objects の counter を使ってサービスの効果測定（メール配信数、CV 数、ログイン数など）をしたいなーと考えたことなんですが、効果測定って一定の期間毎に集計して改善した・していないの指標にしたいやつじゃないですか？counter でカウントアップしつつ、日次のバッチ処理で集計すれば良いんですが、それだとあまり気軽じゃないというか、測定対象となるサービス開発の後、測定ロジックとバッチ処理、保存先の DB テーブル作成までセットで実装しないと実現できないですよね。これはサクッと実装するには counter が自動で日次で保存先を切り替えてくれれば良さそう、ということで、 redis-objects-daily-counter という gem は daily_counter という日次で保存先を切り替えるカウンター機能を提供します。Redis::Objects を拡張して作ってあるので、使い方はほぼ同じで、対象としたい Class に include Redis::Objects を追加すると使えるようになります。# Gemfilegem 'redis-objects-daily-counter'class Homepage  include Redis::Objects  daily_counter :pv, expireat: -> { Time.now + 2_678_400 } # about a month  def id    1  endend# 2021-04-01homepage = Homepage.newhomepage.id # 1homepage.pv.incrementhomepage.pv.incrementhomepage.pv.incrementputs homepage.pv.value # 3# 2021-04-02 (next day)puts homepage.pv.value # 0homepage.pv.incrementhomepage.pv.incrementputs homepage.pv.value # 2start_date = Date.new(2021, 4, 1)end_date = Date.new(2021, 4, 2)homepage.pv.range(start_date, end_date) # [3, 2]#increment #decrement は counter と同じ使い勝手です。ただ、日付が変わると自動的に保存先が切り替わります。これは Redis で保存している Key 名が以下のフォーマットになっているためです。model_name:id:field_name:yyyy-mm-dd日付が変わった後も過去のレコードは削除されていないので、以下のコードでアクセス出来ます。この使い方は同じく Redis::Objects の list と似たような使い勝手になっています。# 2021-04-01homepage.pv.increment(3)# 2021-04-02 (next day)homepage.pv.increment(2)# 2021-04-03 (next day)homepage.pv.increment(5)homepage.pv[Date.new(2021, 4, 1)] # => 3homepage.pv[Date.new(2021, 4, 1), 3] # => [3, 2, 5]homepage.pv[Date.new(2021, 4, 1)..Date.new(2021, 4, 2)] # => [3, 2]homepage.pv.delete(Date.new(2021, 4, 1))homepage.pv.range(Date.new(2021, 4, 1), Date.new(2021, 4, 3)) # => [0, 2, 5]homepage.pv.at(Date.new(2021, 4, 2)) # => 2これで測定対象となるサービスを開発した後、 daily_counter で測定処理を実装しておくだけで OK。この状態でリリースすればデータは溜まっていくので、週次や月次で集計するバッチ処理を後でゆっくり実装すれば良いです。バッチ処理実装前にサーバー内で $ bin/rails console を実行して daily_counter の値を確認しながらバッチ処理の実装を考える、とかも出来ますね。具体的なデータを見ながらの方が開発難易度は下がります。ちなみにですが、 expireat オプションを指定しておくことをオススメします。gem の仕様上、どんどん Redis 上のメモリを圧迫していくので、一定期間後に自動的に削除するようにしましょう。daily_counter があるなら週次、月次、年次カウンターがあっても良いよね、なんだったら毎時、毎分カウンターもあったって良いじゃないか、という事で v0.2.0 ではそれらが追加されています。毎時・毎分のカウンターは API rate limit 機能の実装にも良いかもしれないですね。annual_counterKey format: model_name:id:field_name:yyyyRedis is a highly volatile key-value store, so I don't recommend using it.monthly_counterKey format: model_name:id:field_name:yyyy-mmweekly_counterKey format: model_name:id:field_name:yyyyWwdaily_counterKey format: model_name:id:field_name:yyyy-mm-ddhourly_counterKey format: model_name:id:field_name:yyyy-mm-ddThhminutely_counterKey format: model_name:id:field_name:yyyy-mm-ddThh:mi一応実装はしましたが、 annual_counter のように期間の長いカウンターの利用はあまりオススメしません。Redis ってふとした拍子にデータが飛んでしまう可能性があるので、あくまでキャッシュ的な位置付けで利用するのが良いと思います。daily_counter も週次・月次で RDS に集計結果を保存する運用を想定していますので。というわけで久々のブログ更新では新しく作った redis-objects-daily-counter という gem の紹介をさせて頂きました。これから弊社プロダクトでも利用していく予定ですし、色々なサービスでも活用頂けると嬉しいです。

Redis::Objects を使ったサービス改善と新しい gem を作ったお話

<h2>自作の gem の名前を変えたい。</h2>

<code>my_api_client</code> という自作の gem がありまして、<a href="https://ryz310.hateblo.jp/search?q=my_api_clien">このブログでは何度も紹介している</a> んですが、ニッチすぎるのか宣伝が下手すぎるのか、一向に使ってみた、という噂を聞きません (´・ω・｀)

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fmy_api_client" title="ryz310/my_api_client" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/my_api_client">github.com</a></cite>

まあ弊社のプロダクトの中ではガッツリ使ってるんで別にそれは良いんですが、もう少しまともな名前にならんのかね、というコメントを頂きます。
いい機会だしちゃんと良い名前付けようと思って考えました。どうせなら自分が好きなゲームからいい名前付けたいな、と思って『Luida（<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EB%A5%A4%A1%BC%A5%C0">ルイーダ</a>）』という名前が浮かびました。<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E9%A5%AF%A5%A8">ドラクエ</a> III のあれです。

<figure class="figure-image figure-image-fotolife" title="ここはルイーダの店"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20201004/20201004001621.jpg" alt="f:id:ryz310:20201004001621j:plain:w300" title="" class="hatena-fotolife" style="width:300px" itemprop="image"><figcaption>ここは<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EB%A5%A4%A1%BC%A5%C0">ルイーダ</a>の店。旅人たちが仲間を求めてあつまる出会いと別れの酒場よ。</figcaption></figure>

<code>my_api_client</code> は <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Client を簡単に作ったりテストしたりするための gem なので、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%CB%C1%B8%B1%BC%D4">冒険者</a>を登録して一緒に旅する<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EB%A5%A4%A1%BC%A5%C0">ルイーダ</a>の店のイメージがピッタリだなーと思ったんですよね。とはいえ gem の名前を変えるのって面倒だしそのうちやろう、って思ってたら半年くらい経っちゃいましたけどね。上の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EB%A5%A4%A1%BC%A5%C0">ルイーダ</a>の店の画像ってわざわざ <a class="keyword" href="http://d.hatena.ne.jp/keyword/iPhone">iPhone</a> 版の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E9%A5%AF%A5%A8III">ドラクエIII</a> 買ってスクショ撮ったんですが、その日付が 2020/10/04 でした 😇

多分そのうちやります（フラグ）

<h2>my_<a class="keyword" href="http://d.hatena.ne.jp/keyword/api">api</a>_client v0.20.0 をリリースしました 🚀</h2>

gem の名前は変わらないけどアップデートはされていく。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fmy_api_client%2Freleases%2Ftag%2Fv0.20.0" title="Release v0.20.0 (Mar 07, 2021) · ryz310/my_api_client" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/my_api_client/releases/tag/v0.20.0">github.com</a></cite>

元々 <code>my_api_client</code> には <code>#pageable_get</code> (alias: <code>#pget</code>) というメソッドがあり、<a class="keyword" href="http://d.hatena.ne.jp/keyword/REST%20API">REST API</a> のレスポンス <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> に含まれる URL を順に辿ってリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トする <code>Enumerator</code> を取得することが出来ます。機能自体は実相してテストもしてあるものの、実際のプロダクトで使う機会がなく長いこと日の目を見なかったんですが、この度ついに弊プロダクトで利用する機会が訪れたのでチームのエンジニアに使ってもらってるんですが、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/RSpec">RSpec</a> を書く際のスタブ化が特にサポートされていなくてテストしづらい問題がありました。

今回のアップデートでは、この <code>#pageable_get</code> に対応するスタブ化をサポートしています。 <a href="https://github.com/ryz310/my_api_client/blob/master/README.jp.md#pageable-option">詳しい解説は README.jp.md にも書いた</a> んですが、せっかくなのでブログにも転記しておきます。まあ文章で説明されても実際に使ってみないとピンと来ないのはわかってますけどね。。。

<hr />

<code>#pageable_get</code> (<code>#pget</code>) を使った実装用に <code>pageable</code> というオプションが利用できます。
<code>pageable</code> に設定する値は <code>Enumerable</code> である必要があります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 MyPaginationApiClient,
 pagination: {
 pageable: [
 { page: 1 },
 { page: 2 },
 { page: 3 },
 ],
 }
)

MyPaginationApiClient.new.pagination.each do |response|
 response.page #=&gt; 1, 2, 3
end
</pre>


なお、 <code>Enumerable</code> の各値にはここまで紹介した <code>response</code>, <code>raise</code>, <code>Proc</code> など全てのオプションが利用可能です。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 MyPaginationApiClient,
 pagination: {
 pageable: [
 { response: { page: 1 } },
 { page: 2 },
 -&gt;(params) { { page: 3, user_id: params[:user_id] } },
 { raise: MyApiClient::ClientError::IamTeapot },
 ],
 }
)
</pre>


また、 <code>Enumerator</code> を使えば無限に続くページネーションを定義することもできます。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 MyPaginationApiClient,
 pagination: {
 pageable: Enumerator.new do |y|
 loop.with_index(1) do |_, i|
 y &lt;&lt; { page: i }
 end
 end,
 }
)
</pre>

自作の gem の名前を変えたい。my_api_client という自作の gem がありまして、このブログでは何度も紹介している んですが、ニッチすぎるのか宣伝が下手すぎるのか、一向に使ってみた、という噂を聞きません (´・ω・｀)github.comまあ弊社のプロダクトの中ではガッツリ使ってるんで別にそれは良いんですが、もう少しまともな名前にならんのかね、というコメントを頂きます。いい機会だしちゃんと良い名前付けようと思って考えました。どうせなら自分が好きなゲームからいい名前付けたいな、と思って『Luida（ルイーダ）』という名前が浮かびました。ドラクエ III のあれです。ここはルイーダの店。旅人たちが仲間を求めてあつまる出会いと別れの酒場よ。my_api_client は API Client を簡単に作ったりテストしたりするための gem なので、冒険者を登録して一緒に旅するルイーダの店のイメージがピッタリだなーと思ったんですよね。とはいえ gem の名前を変えるのって面倒だしそのうちやろう、って思ってたら半年くらい経っちゃいましたけどね。上のルイーダの店の画像ってわざわざ iPhone 版のドラクエIII 買ってスクショ撮ったんですが、その日付が 2020/10/04 でした 😇多分そのうちやります（フラグ）my_api_client v0.20.0 をリリースしました 🚀gem の名前は変わらないけどアップデートはされていく。github.com元々 my_api_client には #pageable_get (alias: #pget) というメソッドがあり、REST API のレスポンス JSON に含まれる URL を順に辿ってリクエストする Enumerator を取得することが出来ます。機能自体は実相してテストもしてあるものの、実際のプロダクトで使う機会がなく長いこと日の目を見なかったんですが、この度ついに弊プロダクトで利用する機会が訪れたのでチームのエンジニアに使ってもらってるんですが、 RSpec を書く際のスタブ化が特にサポートされていなくてテストしづらい問題がありました。今回のアップデートでは、この #pageable_get に対応するスタブ化をサポートしています。 詳しい解説は README.jp.md にも書いた んですが、せっかくなのでブログにも転記しておきます。まあ文章で説明されても実際に使ってみないとピンと来ないのはわかってますけどね。。。#pageable_get (#pget) を使った実装用に pageable というオプションが利用できます。pageable に設定する値は Enumerable である必要があります。stub_api_client_all( MyPaginationApiClient, pagination: { pageable: [ { page: 1 }, { page: 2 }, { page: 3 }, ], })MyPaginationApiClient.new.pagination.each do |response| response.page #=> 1, 2, 3endなお、 Enumerable の各値にはここまで紹介した response, raise, Proc など全てのオプションが利用可能です。stub_api_client_all( MyPaginationApiClient, pagination: { pageable: [ { response: { page: 1 } }, { page: 2 }, ->(params) { { page: 3, user_id: params[:user_id] } }, { raise: MyApiClient::ClientError::IamTeapot }, ], })また、 Enumerator を使えば無限に続くページネーションを定義することもできます。stub_api_client_all( MyPaginationApiClient, pagination: { pageable: Enumerator.new do |y| loop.with_index(1) do |_, i| y << { page: i } end end, })

自作の gem の名前を考えるのは難しい

僕は知らなかったです (・∀・)

<blockquote class="twitter-tweet"><a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> で ActiveJob の retry_on が同時に発火されるの何とかしたいなーと思って調べてたら、<a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 6 からは jitter というオプションが指定できるようになってて、デフォルトでリトライ間隔を 15% ランダマイズしてくれるとの事。Rate Limit の回避とかで便利。 <a href="https://t.co/kpIx6YVFEq">https://t.co/kpIx6YVFEq</a>&mdash; サトウリョウスケ (@ryosuke_sato) <a href="https://twitter.com/ryosuke_sato/status/1365707024357466115?ref_src=twsrc%5Etfw">February 27, 2021</a></blockquote>


 <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<h2>jitter とは</h2>

<a href="https://github.com/rails/rails/blob/5aaaa1630a/activejob/CHANGELOG.md#rails-610-december-09-2020">Rails 6.1 から追加されたオプション</a> で、 <code>retry_on</code> の待ち時間に対して任意の割合でバラけさせてくれるようになります（デフォルト 15% ）。

<blockquote><a href="https://edgeapi.rubyonrails.org/classes/ActiveJob/Exceptions/ClassMethods.html#method-i-retry_on">ActiveJob::Exceptions::ClassMethods - retry_on</a>

<code>:jitter</code> - A random delay of wait time used when calculating backoff. The default is 15% (0.15) which represents the upper bound of possible wait time (expressed as a percentage)</blockquote>

<h3>実装を確認してみた</h3>

このバラけさせ方が待ち時間に対して増えるのか減るのかが気になって実装を見てみました。増える方向でバラけるようです。
例えば <code>wait: 60.seconds</code> で <code>jitter: 0.5</code> の場合だと、最大 <code>90</code> 秒の待ち時間となります。

うっかり <code>100.0</code> とか指定すると最大 10000% 待ち時間が加算されちゃいそうです。
間違えて指定しないようにご注意下さい🙏

<pre class="code rb" data-lang="rb" data-unlink>delay = seconds_or_duration_or_algorithm.to_i
delay_jitter = determine_jitter_for_delay(delay, jitter)
delay + delay_jitter</pre>


📝 jitter の計算処理は <a href="https://github.com/rails/rails/blob/35e9812dfcb030d4c986532e7672ad8f8f95286f/activejob/lib/active_job/exceptions.rb#L132-L155">このあたり</a>

<h3>どういう場面で使うの？</h3>

この機能が無かった従来だと、リトライ処理が一斉に起動してしまうという問題がありました。

例えば外部のサービスに <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トするような Job を作ったとします。<a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Rate Limit 超過の例外をハンドリングして、 <code>retry_on</code> で N 分後にリトライするように実装します。
この時、 1000 件の Job が同時に実行され 900 件が Rate Limit 超過となった場合、N 分後に 900 件の Job が一斉にリトライされてしまい、再び 800 件がエラーとなってしまう。
これが何度も繰り返される、という現象が起こってました。

<h3><a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 6.1 以前だと回避できないの？</h3>

従来の ActiveJob でも一応回避策はあって、 <code>wait</code> に <code>Proc</code> を与えてランダムな待ち時間を返すような処理を書くことで似たような動作は可能です。

<pre class="code rb" data-lang="rb" data-unlink>retry_on SomeError, wait: -&gt; { rand(60..90).seconds }</pre>


<h2><a class="keyword" href="http://d.hatena.ne.jp/keyword/iPad">iPad</a> <a class="keyword" href="http://d.hatena.ne.jp/keyword/Air">Air</a> (第4世代) 買っちゃった</h2>

<figure class="figure-image figure-image-fotolife" title="iPad Air (第4世代)"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20210302/20210302102542.jpg" alt="f:id:ryz310:20210302102542j:plain" title="" class="hatena-fotolife" itemprop="image"><figcaption><a class="keyword" href="http://d.hatena.ne.jp/keyword/iPad">iPad</a> <a class="keyword" href="http://d.hatena.ne.jp/keyword/Air">Air</a> (第4世代)</figcaption></figure>

近日中に <a class="keyword" href="http://d.hatena.ne.jp/keyword/iPad">iPad</a> Pro の新型が出るとの噂があるが、軽い <a class="keyword" href="http://d.hatena.ne.jp/keyword/Air">Air</a> がほしかったので問題 🍆 （知らなかったけどね）

🔗 <a href="https://iphone-mania.jp/news-350190/">新型iPad Pro搭載A14X/A14Zチップの処理能力はM1チップに匹敵か - iPhone Mania</a>

僕は知らなかったです (・∀・)Rails で ActiveJob の retry_on が同時に発火されるの何とかしたいなーと思って調べてたら、Rails 6 からは jitter というオプションが指定できるようになってて、デフォルトでリトライ間隔を 15% ランダマイズしてくれるとの事。Rate Limit の回避とかで便利。 https://t.co/kpIx6YVFEq— サトウリョウスケ (@ryosuke_sato) February 27, 2021 jitter とはRails 6.1 から追加されたオプション で、 retry_on の待ち時間に対して任意の割合でバラけさせてくれるようになります（デフォルト 15% ）。ActiveJob::Exceptions::ClassMethods - retry_on:jitter - A random delay of wait time used when calculating backoff. The default is 15% (0.15) which represents the upper bound of possible wait time (expressed as a percentage)実装を確認してみたこのバラけさせ方が待ち時間に対して増えるのか減るのかが気になって実装を見てみました。増える方向でバラけるようです。例えば wait: 60.seconds で jitter: 0.5 の場合だと、最大 90 秒の待ち時間となります。うっかり 100.0 とか指定すると最大 10000% 待ち時間が加算されちゃいそうです。間違えて指定しないようにご注意下さい🙏delay = seconds_or_duration_or_algorithm.to_idelay_jitter = determine_jitter_for_delay(delay, jitter)delay + delay_jitter📝 jitter の計算処理は このあたりどういう場面で使うの？この機能が無かった従来だと、リトライ処理が一斉に起動してしまうという問題がありました。例えば外部のサービスに API リクエストするような Job を作ったとします。API Rate Limit 超過の例外をハンドリングして、 retry_on で N 分後にリトライするように実装します。この時、 1000 件の Job が同時に実行され 900 件が Rate Limit 超過となった場合、N 分後に 900 件の Job が一斉にリトライされてしまい、再び 800 件がエラーとなってしまう。これが何度も繰り返される、という現象が起こってました。Rails 6.1 以前だと回避できないの？従来の ActiveJob でも一応回避策はあって、 wait に Proc を与えてランダムな待ち時間を返すような処理を書くことで似たような動作は可能です。retry_on SomeError, wait: -> { rand(60..90).seconds }iPad Air (第4世代) 買っちゃったiPad Air (第4世代)近日中に iPad Pro の新型が出るとの噂があるが、軽い Air がほしかったので問題 🍆 （知らなかったけどね）🔗 新型iPad Pro搭載A14X/A14Zチップの処理能力はM1チップに匹敵か - iPhone Mania

ActiveJob の retry_on に jitter というオプションがあるの知ってますか？

久々の更新は Rubocop Challenger の話です。

このブログでは触れたこと無かったですが、 <a href="https://github.com/ryz310/rubocop_challenger">そういう gem</a> も作ってます。
自動的に <code>.rubocop_todo.yml</code> から <code>Cop supports --auto-correct.</code> になってる Cop を拾ってきて PR 作ってくれるやつです。

ちょうど hey 社の CTO の藤村さんが同じ事をやっていてちょっとバズってたんですが、自分の gem 使ってほしかったなーと地味に思ってたりします。自分が世の中に対してアピールが足りてなさすぎましたね 😇

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.hey.jp%2Fentry%2F2020%2F10%2F23%2F111200" title="たまってしまった .rubocop_todo.yml をGitHub Actionsで継続的かつ自動的に倒す方法 - STORES Tech Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.hey.jp/entry/2020/10/23/111200">tech.hey.jp</a></cite>

何年か前に会社のブログで書いたりはしてたのでリンク貼っておく ✍

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F12%2F05%2F140000" title="まだ .rubocop_todo.yml で消耗してるの？ - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/12/05/140000">developer.feedforce.jp</a></cite>

<h2>Rubocop Challenger v2.3.0 をリリースしました 🚀</h2>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Frubocop_challenger%2Freleases%2Ftag%2Fv2.3.0" title="Release v2.3.0 · ryz310/rubocop_challenger" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/rubocop_challenger/releases/tag/v2.3.0">github.com</a></cite>

とはいえ新機能は一つだけで、 auto-correct された Cop が SafeAutocorrect かどうかを教えてくれる、というものです。

<a href="https://github.com/ryz310/rubocop_challenger/pull/465">Add description whether the challenge is created by safe autocorrect or not by ryz310 &middot; Pull Request #465 &middot; ryz310/rubocop_challenger &middot; GitHub</a>

こんな感じの PR が作成されます。（画像は動作確認で作ったものなので、実際の <code>Style/Alias</code> は常に <code>SafeAutocorrect: true</code> になります）

<img src="https://user-images.githubusercontent.com/3985540/108836759-94096800-7614-11eb-8fb9-cb311711e120.png" alt="Add description whether the challenge is created by safe autocorrect or not by ryz310 · Pull Request #465 · ryz310/rubocop_challenger" />
<img src="https://user-images.githubusercontent.com/3985540/108847589-392b3d00-7623-11eb-8c09-e5192edbbd80.png" alt="Add description whether the challenge is created by safe autocorrect or not by ryz310 · Pull Request #465 · ryz310/rubocop_challenger" />

ぜひお試し下さい 👍

<h2>つぎやりたいこと</h2>

先日 <a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> が auto-merge 機能をリリースしましたね。自分は即全部の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EA%A5%DD%A5%B8%A5%C8%A5%EA">リポジトリ</a>で有効化しました ✅

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.blog%2Fchangelog%2F2021-02-04-pull-request-auto-merge-is-now-generally-available%2F" title="Pull request auto-merge is now generally available - GitHub Changelog" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.blog/changelog/2021-02-04-pull-request-auto-merge-is-now-generally-available/">github.blog</a></cite>

次やりたい機能としては <code>SafeAutocorrect: true</code> の場合とかは auto-merge を有効化した PR を作るようにしたいんですよね。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> の GraphQL <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> でこの機能を有効化できるらしいです。

<blockquote>GraphQL APIs will be rolling out later this week. The pull request webhook event also now includes actions that indicate when auto-merge is enabled or disabled.</blockquote>

また時間ある時にでも調べます。

久々の更新は Rubocop Challenger の話です。このブログでは触れたこと無かったですが、 そういう gem も作ってます。自動的に .rubocop_todo.yml から  Cop supports --auto-correct. になってる Cop を拾ってきて PR 作ってくれるやつです。ちょうど hey 社の CTO の藤村さんが同じ事をやっていてちょっとバズってたんですが、自分の gem 使ってほしかったなーと地味に思ってたりします。自分が世の中に対してアピールが足りてなさすぎましたね 😇tech.hey.jp何年か前に会社のブログで書いたりはしてたのでリンク貼っておく ✍developer.feedforce.jpRubocop Challenger v2.3.0 をリリースしました 🚀github.comとはいえ新機能は一つだけで、 auto-correct された Cop が SafeAutocorrect かどうかを教えてくれる、というものです。Add description whether the challenge is created by safe autocorrect or not by ryz310 · Pull Request #465 · ryz310/rubocop_challenger · GitHubこんな感じの PR が作成されます。（画像は動作確認で作ったものなので、実際の Style/Alias は常に SafeAutocorrect: true になります）ぜひお試し下さい 👍つぎやりたいこと先日 GitHub が auto-merge 機能をリリースしましたね。自分は即全部のリポジトリで有効化しました ✅github.blog次やりたい機能としては SafeAutocorrect: true  の場合とかは auto-merge を有効化した PR を作るようにしたいんですよね。GitHub の GraphQL API でこの機能を有効化できるらしいです。GraphQL APIs will be rolling out later this week. The pull request webhook event also now includes actions that indicate when auto-merge is enabled or disabled.また時間ある時にでも調べます。

RuboCop で違反してるコードを自動的に修正する PR 作ってくれたら嬉しいやろ。できるでそれ。

前回のリリースから 1 週間ほどですが、今日予定していたライブが<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B3%A5%ED%A5%CA%A5%A6%A5%A4%A5%EB%A5%B9">コロナウイルス</a>の影響で中止になったので暇を持て余しました 😷

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fmy_api_client%2Freleases%2Ftag%2Fv0.16.0" title="Release v0.16.0 · ryz310/my_api_client" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/my_api_client/releases/tag/v0.16.0">github.com</a></cite>

<h2>v0.16.0 の新機能</h2>

2 つありますが、どちらも若干の Breaking Change です。
とはいえ普通に使っていたら全く影響を受けないと思います。

<h3><a href="https://github.com/ryz310/my_api_client/pull/225([@ryz310](https://github.com/ryz310">新機能 1. エラーハンドラがエラーを検出した際は常に例外を raise するようになりました</a></h3>

<code>my_api_client</code> では <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> からのレスポンス内容に応じて例外を発生させる <code>error_handling</code> というメソッドが利用できます。

以下に <code>error_handling</code> を利用した例を示します。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class ExampleApiClient &lt; ApplicationApiClient
 endpoint 'https://example.com'

 error_handling json: { '$.errors.code': 10 }

 error_handling json: { '$.errors.code': 20 }, raise: MyErrorClass

 error_handling json: { '$.errors.code': 30 }, with: :my_error_handling

 error_handling json: { '$.errors.code': 40 } do |params, logger|
 # Do something.
 end

 # GET error/:code
 def request
 get 'path/to/resouce'
 end

 private

 def my_error_handling(params, logger)
 # Do something.
 end
end
</pre>


この例の場合、 <code>ExampleApiClient#request</code> を実行すると <code>GET https://example.com/path/to/resouce</code> に対してリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トが実行され、レスポンスボディが <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> 形式だった場合、JSONPath <code>$.error.code</code> の値に応じて以下の処理を実行します。

<ul>
<li><code>10</code> だった場合 <code>MyApiClient::Error</code> を発生させる</li>
<li><code>20</code> だった場合 <code>MyErrorClass</code> を発生させる</li>
<li><code>30</code> だった場合 <code>#my_error_handling</code> を実行する （例外は発生しない）</li>
<li><code>40</code> だった場合 <code>do ~ end</code> を実行する （例外は発生しない）</li>
</ul>


<code>MyApiClient::Error</code> は <code>raise</code> オプションで例外クラスを指定しなかった場合のデフォルトの例外クラスです。

この時、従来は <code>30</code> と <code>40</code> のように <code>with</code> や <code>block</code> を利用した場合は、処理の中で明示的に <code>raise</code> を実行しない限り、例外は発生しませんでした。
エラー検出時に例外を発生させるかどうかは、 <code>my_api_client</code> の利用者に委ねられていた形になります。

しかしながら、ここに自由度を持たせるよりも、 エラー検出時には必ず <code>raise</code> させて <code>rescue</code> で異常時の処理を記述する 、という方式に統一した方が <code>my_api_client</code> の利用方法としても理解しやすく、特に困るケースも想定されなかったことから、以下のように変更することにしました。

<ul>
<li><code>10</code> だった場合 <code>MyApiClient::Error</code> を発生させる （変更なし）</li>
<li><code>20</code> だった場合 <code>MyErrorClass</code> を発生させる （変更なし）</li>
<li><code>30</code> だった場合 <code>#my_error_handling</code> を実行し、 <code>MyApiClient::Error</code> を発生させる</li>
<li><code>40</code> だった場合 <code>do ~ end</code> を実行し、 <code>MyApiClient::Error</code> を発生させる</li>
</ul>


今後はエラー検出時には常に何らかの例外が <code>raise</code> されるようになります。
上記の例では <code>MyApiClient::Error</code> が発生しますが、 <code>with</code> や <code>block</code> と同時に <code>raise</code> を指定すれば、任意の例外クラスが発生するようになります。

これにより、 <code>with</code> や <code>block</code> は例外の前処理という位置付けになります。<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%E6%A1%BC%A5%B9%A5%B1%A1%BC%A5%B9">ユースケース</a>としてはログ出力や slack への通知などが考えられます。

<h3><a href="https://github.com/ryz310/my_api_client/pull/226">新機能 2. 標準のエラーハンドラが用意されました</a></h3>

<code>my_api_client</code> では <a href="https://github.com/ryz310/my_api_client/blob/e6e4d2265fc834925d45e023c7d43590f98b7171/README.jp.md#installation">generator 機能</a> が用意されており、 <code>$ rails g api_client path/to/resource get:path/to/resource</code> を実行すると以下のファイルが作成されます。

<pre class="code" data-lang="" data-unlink>create app/api_clients/application_api_client.rb
create app/api_clients/path/to/resource_api_client.rb
invoke rspec
create spec/api_clients/path/to/resource_api_client_spec.rb` </pre>


この時、 <code>application_api_client.rb</code> に標準のエラーハンドラの例がいくつか記載されるのですが、例というより必須のエラーハンドラだよね、ということで、 <code>my_api_client</code> の内部で標準実装するようにしました。
これにより、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%C6%A1%BC%A5%BF%A5%B9%A5%B3%A1%BC%A5%C9">ステータスコード</a> 4xx と 5xx のレスポンスに対しては標準で例外が発生するようなります。また、ネットワーク系のエラーに対しても標準で <code>300 msec</code> 間隔を空けて 3 回リトライが試行されるようになります。（リトライ処理も従来は明示的な定義が必須でした）

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 従来の `application_api_client.rb` に出力されていた標準のエラーハンドラ例
error_handling status_code: 400..499, raise: MyApiClient::ClientError
error_handling status_code: 500..599, raise: MyApiClient::ServerError

# 従来の `application_api_client.rb` に出力されていた標準のリトライ処理例
retry_on MyApiClient::NetworkError, wait: 5.seconds, attempts: 3
</pre>


標準で定義されているエラーハンドラは <a href="https://github.com/ryz310/my_api_client/blob/e6e4d2265fc834925d45e023c7d43590f98b7171/lib/my_api_client/default_error_handlers.rb">my_api_client/default_error_handlers.rb</a> から参照できます。

<code>error_handling</code> は後から定義した物が優先されますので、例えば<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%C6%A1%BC%A5%BF%A5%B9%A5%B3%A1%BC%A5%C9">ステータスコード</a> <code>400</code> に対しては独自の例外クラスを発生させるようにしたい場合、継承先のクラスで <code>error_handling status_code: 400, raise: MyErrorClass</code> のように定義すれば、 <code>MyErrorClass</code> が例外として発生するようになります。

<h2>所感</h2>

社内のプロダクト用に作った gem ですが、少しずつ自分以外のエンジニアも利用してくれるようになってきました。
一方で、自由度が高過ぎると熟知していないと使えない機能が増えてしまう点を課題感として感じるようになってきました。

なるべく自由度の高い gem を意識しつつ、標準の状態でも高度な機能の恩恵を受けられる状態を目指していきたいと思います。

恐らく次の新機能は <code>async/await</code> っぽい機能、または <code>sawyer</code> gem の依存からの脱却なると思います。

前回のリリースから 1 週間ほどですが、今日予定していたライブがコロナウイルスの影響で中止になったので暇を持て余しました 😷github.comv0.16.0 の新機能2 つありますが、どちらも若干の Breaking Change です。とはいえ普通に使っていたら全く影響を受けないと思います。新機能 1. エラーハンドラがエラーを検出した際は常に例外を raise するようになりましたmy_api_client では JSON API からのレスポンス内容に応じて例外を発生させる error_handling というメソッドが利用できます。以下に error_handling を利用した例を示します。class ExampleApiClient < ApplicationApiClient endpoint 'https://example.com' error_handling json: { '$.errors.code': 10 } error_handling json: { '$.errors.code': 20 }, raise: MyErrorClass error_handling json: { '$.errors.code': 30 }, with: :my_error_handling error_handling json: { '$.errors.code': 40 } do |params, logger| # Do something. end # GET error/:code def request get 'path/to/resouce' end private def my_error_handling(params, logger) # Do something. endendこの例の場合、 ExampleApiClient#request を実行すると GET https://example.com/path/to/resouce に対してリクエストが実行され、レスポンスボディが JSON 形式だった場合、JSONPath $.error.code の値に応じて以下の処理を実行します。10 だった場合 MyApiClient::Error を発生させる20 だった場合 MyErrorClass を発生させる30 だった場合 #my_error_handling を実行する （例外は発生しない）40 だった場合 do ~ end を実行する （例外は発生しない）MyApiClient::Error は raise オプションで例外クラスを指定しなかった場合のデフォルトの例外クラスです。この時、従来は 30 と 40 のように with や block を利用した場合は、処理の中で明示的に raise を実行しない限り、例外は発生しませんでした。エラー検出時に例外を発生させるかどうかは、 my_api_client の利用者に委ねられていた形になります。しかしながら、ここに自由度を持たせるよりも、 エラー検出時には必ず raise させて rescue で異常時の処理を記述する 、という方式に統一した方が my_api_client の利用方法としても理解しやすく、特に困るケースも想定されなかったことから、以下のように変更することにしました。10 だった場合 MyApiClient::Error を発生させる （変更なし）20 だった場合 MyErrorClass を発生させる （変更なし）30 だった場合 #my_error_handling を実行し、 MyApiClient::Error を発生させる40 だった場合 do ~ end を実行し、 MyApiClient::Error を発生させる今後はエラー検出時には常に何らかの例外が raise されるようになります。上記の例では MyApiClient::Error が発生しますが、 with や block と同時に raise を指定すれば、任意の例外クラスが発生するようになります。これにより、 with や block は例外の前処理という位置付けになります。ユースケースとしてはログ出力や slack への通知などが考えられます。新機能 2. 標準のエラーハンドラが用意されましたmy_api_client では generator 機能 が用意されており、 $ rails g api_client path/to/resource get:path/to/resource を実行すると以下のファイルが作成されます。create app/api_clients/application_api_client.rbcreate app/api_clients/path/to/resource_api_client.rbinvoke rspeccreate spec/api_clients/path/to/resource_api_client_spec.rb` この時、 application_api_client.rb に標準のエラーハンドラの例がいくつか記載されるのですが、例というより必須のエラーハンドラだよね、ということで、 my_api_client の内部で標準実装するようにしました。これにより、ステータスコード 4xx と 5xx のレスポンスに対しては標準で例外が発生するようなります。また、ネットワーク系のエラーに対しても標準で 300 msec 間隔を空けて 3 回リトライが試行されるようになります。（リトライ処理も従来は明示的な定義が必須でした）# 従来の `application_api_client.rb` に出力されていた標準のエラーハンドラ例error_handling status_code: 400..499, raise: MyApiClient::ClientErrorerror_handling status_code: 500..599, raise: MyApiClient::ServerError# 従来の `application_api_client.rb` に出力されていた標準のリトライ処理例retry_on MyApiClient::NetworkError, wait: 5.seconds, attempts: 3標準で定義されているエラーハンドラは my_api_client/default_error_handlers.rb から参照できます。error_handling は後から定義した物が優先されますので、例えばステータスコード 400 に対しては独自の例外クラスを発生させるようにしたい場合、継承先のクラスで error_handling status_code: 400, raise: MyErrorClass のように定義すれば、 MyErrorClass が例外として発生するようになります。所感社内のプロダクト用に作った gem ですが、少しずつ自分以外のエンジニアも利用してくれるようになってきました。一方で、自由度が高過ぎると熟知していないと使えない機能が増えてしまう点を課題感として感じるようになってきました。なるべく自由度の高い gem を意識しつつ、標準の状態でも高度な機能の恩恵を受けられる状態を目指していきたいと思います。恐らく次の新機能は async/await っぽい機能、または sawyer gem の依存からの脱却なると思います。

my_api_client v0.16.0 をリリースしました🚀

その前に <code>v0.14.0</code> もリリースしているのですが、こちらは<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EA%A5%D5%A5%A1%A5%AF%A5%BF%A5%EA%A5%F3%A5%B0">リファクタリング</a>と Integration Test の実装だけで新機能はありませんでした。
差分が <code>+2,799 -1,246</code> もあるので中身は結構書き換わっています。

<a href="https://github.com/ryz310/my_api_client/releases/tag/v0.14.0">Release v0.14.0 &middot; ryz310/my_api_client &middot; GitHub</a>

Integration Test では <a href="https://rubyonjets.com/">Ruby on Jets</a> を使って <a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> Lambda でサーバーを建てて、CI でのテストで <code>my_api_client</code> を使って実際に HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トが成功することを確認しているので、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C7%A5%B0%A5%EC">デグレ</a>の心配が随分と緩和されました 😌

<h2>新機能: Pagination <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> のサポート</h2>

ここからは <code>v0.15.0</code> の話になります。

<a href="https://github.com/ryz310/my_api_client/releases/tag/v0.15.0">Release v0.15.0 &middot; ryz310/my_api_client &middot; GitHub</a>

<code>v0.15.0</code> のメイン機能が Pagination <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> のサポートになります。<a href="https://jsonapi.org/">JSON:API</a> というしっかりとした仕様もあるようですが、 <code>my_api_client</code> ではそこまで厳密な仕様に則っている訳ではなく、レスポンスに含まれる URL を認識して enumerable に HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トを実行する、というざっくりした機能になります。
レスポンスヘッダの <code>Link</code> などで次のページの URL を返すケースもあるようですが、そちらは現時点では未対応です 🙏

Pagination <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> という単語は <a class="keyword" href="http://d.hatena.ne.jp/keyword/Django">Django</a> REST Framework の Pagination 機能の説明で出てきます。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.django-rest-framework.org%2Fapi-guide%2Fpagination%2F" title="Pagination - Django REST framework" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.django-rest-framework.org/api-guide/pagination/">www.django-rest-framework.org</a></cite>

要するに一度のリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トで結果を全件取得させるのではなく、一定の件数を返却し、続きを取得できる Link を一緒に返却する <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> のことですね。

Request:

<pre class="code" data-lang="" data-unlink>GET https://api.example.org/accounts/?page=4</pre>


Response:

<pre class="code lang-json" data-lang="json" data-unlink>HTTP 200 OK
{
 &quot;count&quot;: 1023
 &quot;next&quot;: &quot;https://api.example.org/accounts/?page=5&quot;,
 &quot;previous&quot;: &quot;https://api.example.org/accounts/?page=3&quot;,
 &quot;results&quot;: [
 …
 ]
}
</pre>


<h3>使い方</h3>

<code>my_api_client</code> での使い方は以下のようになります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class MyPaginationApiClient &lt; ApplicationApiClient
 endpoint 'https://example.com/v1'

 # GET pagination?page=1
 def pagination
 pageable_get 'pagination', paging: '$.links.next', headers: headers, query: { page: 1 }
 end

 private

 def headers
 { 'Content-Type': 'application/json;charset=UTF-8' }
 end
end
</pre>


通常であれば <code>#get</code> を使って HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トを実行させるのですが、ここでは <code>#pageable_get</code> というメソッドを使用しています。 <code>#pageable_get</code> だと長いので <code>#pget</code> という<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%A4%A5%EA%A5%A2%A5%B9">エイリアス</a>も用意しています。
また、 <code>paging</code> というキーワード引数も新たに出てきました。 <code>paging</code> ではレスポンスのどの部分に次のページの URL が含まれるかを JSONPath expression で指定します。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgoessner.net%2Farticles%2FJsonPath%2Findex.html%23e2" title="JSONPath - XPath for JSON" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://goessner.net/articles/JsonPath/index.html#e2">goessner.net</a></cite>

以下のような <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> であれば、 <code>$.links.next</code> という JSONPath expression は <code>"https://example.com/pagination?page=3"</code> を取得します。

<pre class="code lang-json" data-lang="json" data-unlink>{
 &quot;links&quot;: {
 &quot;next&quot;: &quot;https://example.com/pagination?page=3&quot;,
 &quot;previous&quot;: &quot;https://example.com/pagination?page=1&quot;,
 },
 &quot;page&quot;: 2
}
</pre>


作成した <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Client は以下のように使用できます。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>api_clinet = MyPaginationApiClient.new
api_clinet.pagination.each do |response|
 # Do something.
end

p = api_clinet.pagination
p.next # =&gt; 1st page result
p.next # =&gt; 2nd page result
p.next # =&gt; 3rd page result
</pre>


<h3>結果は <code>Enumerator::Lazy</code> で返却される</h3>

<code>#pageable_get</code> は <code>Enumerator::Lazy</code> を返却するので、 <code>Enumerable</code> で定義されているメソッドは一通り利用可能です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.ruby-lang.org%2Fja%2Flatest%2Fclass%2FEnumerator%3D3a%3D3aLazy.html" title="class Enumerator::Lazy (Ruby 2.7.0 リファレンスマニュアル)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.ruby-lang.org/ja/latest/class/Enumerator=3a=3aLazy.html">docs.ruby-lang.org</a></cite>

<code>Enumerator</code> で返してしまうと <code>#take</code> で 100 ページ目まで結果を取得するような処理を記述したときに、

<ol>
<li>100 ページ分の HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トを実行</li>
<li>結果を <code>#each</code> で回す</li>
</ol>


という動きになり、 100 回分の HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トが完了するまで次の処理に移ることができません。

<code>Enumerator::Lazy</code> であれば、

<ol>
<li>1 ページ目の HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トを実行</li>
<li>結果を処理する</li>
<li>2ページ目の HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トを実行</li>
<li>結果を処理する</li>
<li>...</li>
</ol>


という動きになってくれます。便利ですね ✨

<code>Enumerator</code> と <code>Enumerator::Lazy</code> の違いは以下の記事が参考になると思います。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fgam0022%2Fitems%2F8acfc0c674b96060c03f" title="EnumeratorとEnumerator::Lazyの違い - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/gam0022/items/8acfc0c674b96060c03f">qiita.com</a></cite>

その前に v0.14.0 もリリースしているのですが、こちらはリファクタリングと Integration Test の実装だけで新機能はありませんでした。差分が +2,799 -1,246 もあるので中身は結構書き換わっています。Release v0.14.0 · ryz310/my_api_client · GitHubIntegration Test では Ruby on Jets を使って AWS Lambda でサーバーを建てて、CI でのテストで my_api_client を使って実際に HTTP リクエストが成功することを確認しているので、デグレの心配が随分と緩和されました 😌新機能: Pagination API のサポートここからは v0.15.0 の話になります。Release v0.15.0 · ryz310/my_api_client · GitHubv0.15.0 のメイン機能が Pagination API のサポートになります。JSON:API というしっかりとした仕様もあるようですが、 my_api_client ではそこまで厳密な仕様に則っている訳ではなく、レスポンスに含まれる URL を認識して enumerable に HTTP リクエストを実行する、というざっくりした機能になります。レスポンスヘッダの Link などで次のページの URL を返すケースもあるようですが、そちらは現時点では未対応です 🙏Pagination API という単語は Django REST Framework の Pagination 機能の説明で出てきます。www.django-rest-framework.org要するに一度のリクエストで結果を全件取得させるのではなく、一定の件数を返却し、続きを取得できる Link を一緒に返却する API のことですね。Request:GET https://api.example.org/accounts/?page=4Response:HTTP 200 OK{ "count": 1023 "next": "https://api.example.org/accounts/?page=5", "previous": "https://api.example.org/accounts/?page=3", "results": [ … ]}使い方my_api_client での使い方は以下のようになります。class MyPaginationApiClient < ApplicationApiClient endpoint 'https://example.com/v1' # GET pagination?page=1 def pagination pageable_get 'pagination', paging: '$.links.next', headers: headers, query: { page: 1 } end private def headers { 'Content-Type': 'application/json;charset=UTF-8' } endend通常であれば #get を使って HTTP リクエストを実行させるのですが、ここでは #pageable_get というメソッドを使用しています。 #pageable_get だと長いので #pget というエイリアスも用意しています。また、 paging というキーワード引数も新たに出てきました。 paging ではレスポンスのどの部分に次のページの URL が含まれるかを JSONPath expression で指定します。goessner.net以下のような JSON であれば、 $.links.next という JSONPath expression は "https://example.com/pagination?page=3" を取得します。{ "links": { "next": "https://example.com/pagination?page=3", "previous": "https://example.com/pagination?page=1", }, "page": 2}作成した API Client は以下のように使用できます。api_clinet = MyPaginationApiClient.newapi_clinet.pagination.each do |response| # Do something.endp = api_clinet.paginationp.next # => 1st page resultp.next # => 2nd page resultp.next # => 3rd page result結果は Enumerator::Lazy で返却される#pageable_get は Enumerator::Lazy を返却するので、 Enumerable で定義されているメソッドは一通り利用可能です。docs.ruby-lang.orgEnumerator で返してしまうと #take で 100 ページ目まで結果を取得するような処理を記述したときに、100 ページ分の HTTP リクエストを実行結果を #each で回すという動きになり、 100 回分の HTTP リクエストが完了するまで次の処理に移ることができません。Enumerator::Lazy であれば、1 ページ目の HTTP リクエストを実行結果を処理する2ページ目の HTTP リクエストを実行結果を処理する...という動きになってくれます。便利ですね ✨Enumerator と Enumerator::Lazy の違いは以下の記事が参考になると思います。qiita.com

my_api_client v0.15.0 をリリースしました🚀

ご存知の方も多いかと思いますが、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Chrome">Chrome</a> 80 から 3rd Party <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> の取り扱いが厳しくなり、特に指定がないと外部サイトの <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> は POST・iframe・XHR 等のリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>ト で送られなくなります。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdevelopers-jp.googleblog.com%2F2019%2F11%2Fcookie-samesitenone-secure.html" title="新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developers-jp.googleblog.com/2019/11/cookie-samesitenone-secure.html">developers-jp.googleblog.com</a></cite>

<blockquote>2 月の <a class="keyword" href="http://d.hatena.ne.jp/keyword/Chrome">Chrome</a> 80 以降、SameSite 値が宣言されていない <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。</blockquote>

とはいえ完全に無効になるわけではなく、 <code>SameSite</code> という属性が宣言されていない <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> は <code>Lax</code> という区分がデフォルトで適用されるという物なので、サーバーから返す <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> に対して明示的に <code>SameSite</code> を <code>None</code> に指定して、かつ <code>Secure</code> という属性を付与すれば、従来どおり <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> が送信されます。

去年の秋くらいにもこの <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> の対応が必要かどうか、会社で調査していたんですが、その時点では影響を受ける箇所が無くて、特に何も対応せずにスルーしていたんですが、現在開発してる新機能が<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A4%BF%A4%DE%A4%BF%A4%DE%A4%B3">たまたまこ</a>の影響を受ける機能だったため、急遽対応することになりました。

結構厳しいな、と思ったのは、これが原因で動かないことに気付くのが結構難しいんですよね。
<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B7%A5%F3%A5%B0%A5%EB%A5%B5%A5%A4%A5%F3%A5%AA%A5%F3">シングルサインオン</a>みたいな機能を作ってると<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>が異なるので 3rd Party <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> の扱いになります。
そして <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> に入っているはずの Session ID が送られてこないので、サーバー側で Session が見つからずにエラー。

自分の手元の <a class="keyword" href="http://d.hatena.ne.jp/keyword/Chrome">Chrome</a> は 79 で、まだ上記の制限が入っていなかったんですが、以前影響範囲を調査した時に <code>chrome://flags</code> から有効にするフラグを ON にしていたので、他のエンジニアの環境では動作するけど、自分だけ動かないということになり、もしかして、と思って気付いた感じです。

リリース後に気付いてたらヤバかったですね。。

で、こういう問題は <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> みたいな<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF">フレームワーク</a>で対応してくれよって気持ちになるんですが、ちゃんと対応する PR は作られていて、すでに merge もされています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Frails%2Frails%2Fpull%2F28297" title="Add SameSite to Cookies by cfabianski · Pull Request #28297 · rails/rails" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/rails/rails/pull/28297">github.com</a></cite>

ですが、 2020/2/20 現在、これを反映した <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> はまだリリースされていないみたいですね。（最新が 2019/12/19 にリリースされた <code>6.0.2.1</code> ）
また、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 5.2 に反映されるかどうかは微妙な感じになっています。

<a href="https://github.com/rails/rails/pull/28297#issuecomment-577414543">https://github.com/rails/rails/pull/28297#issuecomment-577414543</a>

<blockquote>We will backport to 6.0 as a bug fix, but I don't know this warrants a backport to a security only release like 5.2. <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 6.0 was released 6 months ago, and upgrading applications could be high, high priority if that problem is so important.

バグ修正として6.0にバックポートしますが、これが5.2のようなセキュリティのみのリリースへのバックポートを保証するかどうかわかりません。 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 6.0は6か月前にリリースされました。その問題が非常に重要な場合、アプリケーションのアップグレードは優先度が高くなる可能性があります。</blockquote>

自分の開発環境は恥ずかしながら <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 4.2 （今年中にアップデートします！）なので、当然反映されるはずもないので、自前で Rack を作成して対応しました。
参考まで以下のようなコードになります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink># config/initializers/custom_rack_middleware.rb

# NOTE: Rails 6.0.x であれば以下の処理は不要となる。
Rails.application.config.middleware.insert_before(
 ActionDispatch::Cookies,
 CustomRackMiddleware::SetSameSiteOptionOnCookie
)
</pre>




<pre class="code lang-ruby" data-lang="ruby" data-unlink># lib/custom_rack_middleware/set_same_site_option_on_cookie.rb

# TODO: Rails 6.0.x にアップデートしたら削除する
module CustomRackMiddleware
 class SetSameSiteOptionOnCookie
 def initialize(app)
 @app = app
 end

 def call(env)
 status, headers, body = @app.call(env)

 cookies = headers['Set-Cookie']
 if cookies.present?
 processed_cookies = cookies.split(&quot;\n&quot;).map do |cookie|
 &quot;#{cookie}; SameSite=None; Secure&quot;
 end
 headers['Set-Cookie'] = processed_cookies.join(&quot;\n&quot;)
 end

 [status, headers, body]
 end
 end
end
</pre>


2020/02/22 追記

ローカルの開発環境など HTTP リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トをする環境だと、 <code>SameSite=None</code> の設定を入れると <a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a> が送られなくなるようです。

ローカルでは上述の Rack を読み込ませないようにするなどの工夫が必要だと思います。

ご存知の方も多いかと思いますが、 Chrome 80 から 3rd Party Cookie の取り扱いが厳しくなり、特に指定がないと外部サイトの Cookie は POST・iframe・XHR 等のリクエスト  で送られなくなります。developers-jp.googleblog.com2 月の Chrome 80 以降、SameSite 値が宣言されていない Cookie は SameSite=Lax として扱われます。外部アクセスは、SameSite=None; Secure 設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。とはいえ完全に無効になるわけではなく、 SameSite という属性が宣言されていない Cookie は Lax という区分がデフォルトで適用されるという物なので、サーバーから返す Cookie に対して明示的に SameSite を None に指定して、かつ Secure という属性を付与すれば、従来どおり Cookie が送信されます。去年の秋くらいにもこの Cookie の対応が必要かどうか、会社で調査していたんですが、その時点では影響を受ける箇所が無くて、特に何も対応せずにスルーしていたんですが、現在開発してる新機能がたまたまこの影響を受ける機能だったため、急遽対応することになりました。結構厳しいな、と思ったのは、これが原因で動かないことに気付くのが結構難しいんですよね。シングルサインオンみたいな機能を作ってるとドメインが異なるので 3rd Party Cookie の扱いになります。そして Cookie に入っているはずの Session ID が送られてこないので、サーバー側で Session が見つからずにエラー。自分の手元の Chrome は 79 で、まだ上記の制限が入っていなかったんですが、以前影響範囲を調査した時に chrome://flags から有効にするフラグを ON にしていたので、他のエンジニアの環境では動作するけど、自分だけ動かないということになり、もしかして、と思って気付いた感じです。リリース後に気付いてたらヤバかったですね。。で、こういう問題は Rails みたいなフレームワークで対応してくれよって気持ちになるんですが、ちゃんと対応する PR は作られていて、すでに merge もされています。github.comですが、 2020/2/20 現在、これを反映した Rails はまだリリースされていないみたいですね。（最新が 2019/12/19 にリリースされた 6.0.2.1 ）また、 Rails 5.2 に反映されるかどうかは微妙な感じになっています。https://github.com/rails/rails/pull/28297#issuecomment-577414543We will backport to 6.0 as a bug fix, but I don't know this warrants a backport to a security only release like 5.2. Rails 6.0 was released 6 months ago, and upgrading applications could be high, high priority if that problem is so important.バグ修正として6.0にバックポートしますが、これが5.2のようなセキュリティのみのリリースへのバックポートを保証するかどうかわかりません。 Rails 6.0は6か月前にリリースされました。その問題が非常に重要な場合、アプリケーションのアップグレードは優先度が高くなる可能性があります。自分の開発環境は恥ずかしながら Rails 4.2 （今年中にアップデートします！）なので、当然反映されるはずもないので、自前で Rack を作成して対応しました。参考まで以下のようなコードになります。# config/initializers/custom_rack_middleware.rb# NOTE: Rails 6.0.x であれば以下の処理は不要となる。Rails.application.config.middleware.insert_before(  ActionDispatch::Cookies,  CustomRackMiddleware::SetSameSiteOptionOnCookie)# lib/custom_rack_middleware/set_same_site_option_on_cookie.rb# TODO: Rails 6.0.x にアップデートしたら削除するmodule CustomRackMiddleware  class SetSameSiteOptionOnCookie    def initialize(app)      @app = app    end    def call(env)      status, headers, body = @app.call(env)      cookies = headers['Set-Cookie']      if cookies.present?        processed_cookies = cookies.split("\n").map do |cookie|          "#{cookie}; SameSite=None; Secure"        end        headers['Set-Cookie'] = processed_cookies.join("\n")      end      [status, headers, body]    end  endend2020/02/22 追記ローカルの開発環境など HTTP リクエストをする環境だと、 SameSite=None の設定を入れると Cookie が送られなくなるようです。ローカルでは上述の Rack を読み込ませないようにするなどの工夫が必要だと思います。

駆け込みで Chrome 80 の SameSite=None; Secure の対応をやった🍪

<a href="https://ryz310.hateblo.jp/entry/2020/01/19/152826">つい先日、v0.12.0 をリリースしたばかり</a> ですが、 v0.13.0 をリリースしましたので、含まれる PR の内容について解説していきます。 より詳しい使い方は <a href="https://github.com/ryz310/my_api_client/blob/master/README.jp.md">README.jp.md</a> をご参照ください。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Fmy_api_client%2Fblob%2Fmaster%2FCHANGELOG.md%23v0130-jan-21-2020" title="ryz310/my_api_client" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/my_api_client/blob/master/CHANGELOG.md#v0130-jan-21-2020">github.com</a></cite>

<h2><a href="https://github.com/ryz310/my_api_client/pull/180">#180</a> Stub response on raising error (<a href="https://github.com/ryz310">@ryz310</a>)</h2>

今回はこの PR のみの更新です。
仕事で spec 書いてる最中に「<a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トで例外が発生した際にレスポンス内容を保存する処理のスタブ化できないじゃん」ってなって作りました。

<code>my_api_client</code> では作成した <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Client クラスを <code>stub_api_client</code> または <code>stub_api_client_all</code> というメソッドでスタブ化できます。
例えば以下のような <code>ExampleApiClient</code> というクラスを定義した時:

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class ExampleApiClient &lt; MyApiClient::Base
 endpoint 'https://example.com'

 error_handling status_code: 400..499, raise: MyApiClient::ClientError
 error_handling status_code: 500..599, raise: MyApiClient::ServerError

 # GET https://example.com/path/to/resouce
 def request
 get 'path/to/resouce'
 end
end
</pre>


<code>stub_api_client_all</code> を実行すると <code>ExampleApiClient</code> の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9">インスタンス</a>が全てスタブ化されるようになります。
以下の例だと、 <code>#request</code> を実行した時、<a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> から <code>{ "message": "Hello world!" }</code> という <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> が返ってきた時と同じ振る舞いをするようになります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 ExampleApiClient,
 request: { response: { message: 'Hello world!' } }
)

api_client = ExampleApiClient.new
response = api_client.request
response.message # =&gt; 'Hello world!'
</pre>


で、 <code>error_handling</code> で<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%C6%A1%BC%A5%BF%A5%B9%A5%B3%A1%BC%A5%C9">ステータスコード</a>が <code>400..499</code> の時は <code>MyApiClient::ClientError</code> という例外が発生する、という定義になっているのですが、このような例外が発生した時のテストを書くために、 <code>raise</code> のスタブ化も出来るようになっています。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 ExampleApiClient,
 request: { raise: MyApiClient::ClientError }
)

begin
 api_client = ExampleApiClient.new
 response = api_client.request
rescue MyApiClient::ClientError
 puts '4xx error!'
end
</pre>


大抵の場合、これらのスタブ化ができれば問題ないのですが、例外発生時のレスポンスを見たい、というケースも無くはないかと思います。
仕様として、例外<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9">インスタンス</a>の <code>#params</code> や <code>#matadata</code> というメソッドからリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トパラメータとレスポンスパラメータを参照できるようになっています。

従来のスタブ化メソッドでも一応指定できなくはなかったんですが、結構手間だったので <code>raise</code> オプションの指定を以下のように拡張しました。
<code>raise</code> と一緒に指定した <code>response</code> が <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> のレスポンスとして返されて、それが例外として処理された、というスタブ化になります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(
 ExampleApiClient,
 request: { 
 raise: MyApiClient::ClientError,
 response: { error_code: 10 }
 }
)

begin
 api_client = ExampleApiClient.new
 response = api_client.request
rescue MyApiClient::ClientError =&gt; e
 e.params.response.data.error_code #=&gt; 10
end
</pre>


<code>my_api_client</code> は内部で <a href="https://github.com/lostisland/sawyer">Sawyer</a> を使っています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Flostisland%2Fsawyer" title="lostisland/sawyer" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/lostisland/sawyer">github.com</a></cite>

<code>e.params.response</code> が <code>Sawyer::Response</code> をそのまま返しているので、<code>Sawyer::Response#data</code> からレスポンスボディを参照できます。
<code>Sawyer::Response#data</code> では、レスポンスの <a class="keyword" href="http://d.hatena.ne.jp/keyword/JSON">JSON</a> を <a href="https://docs.ruby-lang.org/ja/latest/class/OpenStruct.html">OpenStruct)</a> のようにメソッドアクセスできるように変換してくれます。

ただし、 <code>V1.0.0</code> で <code>Sawyer</code> の依存を無くしたいと考えているので、いずれ <code>#data</code> を挟む書き方は変更になるかもしれません。
一応こういう使い方もできますよ、という新機能でした。

つい先日、v0.12.0 をリリースしたばかり ですが、 v0.13.0 をリリースしましたので、含まれる PR の内容について解説していきます。 より詳しい使い方は README.jp.md をご参照ください。github.com#180 Stub response on raising error (@ryz310)今回はこの PR のみの更新です。仕事で spec 書いてる最中に「API リクエストで例外が発生した際にレスポンス内容を保存する処理のスタブ化できないじゃん」ってなって作りました。my_api_client では作成した API Client クラスを stub_api_client または stub_api_client_all というメソッドでスタブ化できます。例えば以下のような ExampleApiClient というクラスを定義した時:class ExampleApiClient < MyApiClient::Base endpoint 'https://example.com' error_handling status_code: 400..499, raise: MyApiClient::ClientError error_handling status_code: 500..599, raise: MyApiClient::ServerError # GET https://example.com/path/to/resouce def request get 'path/to/resouce' endendstub_api_client_all を実行すると ExampleApiClient のインスタンスが全てスタブ化されるようになります。以下の例だと、 #request を実行した時、API から { "message": "Hello world!" } という JSON が返ってきた時と同じ振る舞いをするようになります。stub_api_client_all( ExampleApiClient, request: { response: { message: 'Hello world!' } })api_client = ExampleApiClient.newresponse = api_client.requestresponse.message # => 'Hello world!'で、 error_handling でステータスコードが 400..499 の時は MyApiClient::ClientError という例外が発生する、という定義になっているのですが、このような例外が発生した時のテストを書くために、 raise のスタブ化も出来るようになっています。stub_api_client_all( ExampleApiClient, request: { raise: MyApiClient::ClientError })begin api_client = ExampleApiClient.new response = api_client.requestrescue MyApiClient::ClientError puts '4xx error!'end大抵の場合、これらのスタブ化ができれば問題ないのですが、例外発生時のレスポンスを見たい、というケースも無くはないかと思います。仕様として、例外インスタンスの #params や #matadata というメソッドからリクエストパラメータとレスポンスパラメータを参照できるようになっています。従来のスタブ化メソッドでも一応指定できなくはなかったんですが、結構手間だったので raise オプションの指定を以下のように拡張しました。raise と一緒に指定した response が API のレスポンスとして返されて、それが例外として処理された、というスタブ化になります。stub_api_client_all( ExampleApiClient, request: { raise: MyApiClient::ClientError, response: { error_code: 10 } })begin api_client = ExampleApiClient.new response = api_client.requestrescue MyApiClient::ClientError => e e.params.response.data.error_code #=> 10endmy_api_client は内部で Sawyer を使っています。github.come.params.response が Sawyer::Response をそのまま返しているので、Sawyer::Response#data からレスポンスボディを参照できます。Sawyer::Response#data では、レスポンスの JSON を OpenStruct) のようにメソッドアクセスできるように変換してくれます。ただし、 V1.0.0 で Sawyer の依存を無くしたいと考えているので、いずれ #data を挟む書き方は変更になるかもしれません。一応こういう使い方もできますよ、という新機能でした。

my_api_client v0.13.0 をリリースしました🚀

<a href="https://github.com/ryz310/my_api_client">my_api_client v0.12.0</a> に含まれる PR の内容について解説していきます。
より詳しい使い方は <a href="https://github.com/ryz310/my_api_client/blob/master/README.jp.md">README.jp.md</a> をご参照ください。

<h2><a href="https://github.com/ryz310/my_api_client/pull/173">#173</a> Avoid sleep on testing</h2>

my_<a class="keyword" href="http://d.hatena.ne.jp/keyword/api">api</a>_client では以下のように書くと、任意の例外を補足して自動的に <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> リク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トをリトライしてくれます。
ネットワーク系のエラーとか、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Rate Limit に引っかかった時とかに便利なやつですね。

<a href="https://edgeapi.rubyonrails.org/classes/ActiveJob/Exceptions/ClassMethods.html#method-i-retry_on">ActiveJob の <code>retry_on</code></a> とほぼ同じ使い方になっています。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class ExampleApiClient &lt; MyApiClient::Base
 endpoint 'https://example.com'

 retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3
 error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError

 # GET https://example.com/users
 def get_users
 get 'users'
 end
end
</pre>


それは良いんですが、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/rspec">rspec</a> 上で <code>wait</code> が効いてしまっていたので、上記のコードだとリトライ3回分 wait するので、合計 3 分も待たされてしまっていました。
一応 <a class="keyword" href="http://d.hatena.ne.jp/keyword/rspec">rspec</a> で <code>sleep</code> を stub するとかやれば回避できますが、そもそもテストでは wait を無視して欲しいですよね。

my_<a class="keyword" href="http://d.hatena.ne.jp/keyword/api">api</a>_client では <code>be_handled_as_an_error</code> という <a class="keyword" href="http://d.hatena.ne.jp/keyword/rspec">rspec</a> の matcher を用意しているのですが、今回の対応で、この macher を経由してリトライが実行された場合は wait を無視するようになりました。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>RSpec.describe ExampleApiClient, type: :api_client do
 let(:api_client) { described_class.new }

 # NOTE: レスポンスで `{ &quot;errors&quot;: { &quot;code&quot;: 20 } }` を受診した際、3 回リトライが実行された後に `MyApiClient::ApiLimitError` として例外処理される。
 it do
 expect { api_request! }
 .to be_handled_as_an_error(MyApiClient::ApiLimitError)
 .after_retry(3).times
 .when_receive(body: { errors: { code: 20 } }.to_json)
 end
end
</pre>


また、 <code>ExampleApiClient</code> は <code>stub_api_client</code> や <code>stub_api_client_all</code> を使用するとスタブ化できます。
スタブ化した状態だと任意の <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> レスポンスを返すか、任意の例外を発生させる、という動作になってリトライが発生しなくなるので、上記の問題はありませんでした。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>stub_api_client_all(ExampleApiClient, get_users: { users: [{ id: 1 }, { id: 2 }, { id: 3 }] })

response = ExampleApiClient.new.get_users
response.users # =&gt; [{ id: 1 }, { id: 2 }, { id: 3 }]
</pre>


<h2><a href="https://github.com/ryz310/my_api_client/pull/175">#175</a> Verify arguments on error handling definition</h2>

<code>error_handling</code> の定義でレスポンスの<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%C6%A1%BC%A5%BF%A5%B9%A5%B3%A1%BC%A5%C9">ステータスコード</a>を指定することができるんですが、このオプション名が <code>status_code</code> なのか <code>status</code> なのかをよく間違える、という問題がありました。<code>$ rails g api_client</code> を使用するとテンプレが作成されるので、そこからエラーハンドリングの定義を行うと間違えにくいのですが、後からエラーハンドリングを追加する時とかにやらかします。作者自身もたまにやらかしてました😇

<pre class="code lang-ruby" data-lang="ruby" data-unlink># 正解
error_handling status_code: 400..499, raise: MyApiClient::ClientError

# 間違い
error_handling status: 400..499, raise: MyApiClient::ClientError
</pre>


この PR の対応で間違ったオプションを指定すると以下のような例外が発生するようになりました。

<pre class="code" data-lang="" data-unlink>RuntimeError:
 Specified an incorrect option: `status`
 You can use options that: [:response, :status_code, :json, :with, :raise, :block]</pre>


<h2><a href="https://github.com/ryz310/my_api_client/pull/176">#176</a> Provides a syntax sugar of <code>retry_on</code> on <code>error_handling</code></h2>

最初の PR でも出てきた <code>retry_on</code> ですが、 <code>error_handling raise: MyApiClient::ApiLimitError</code> でも同じ例外を指定していて DRY な感じじゃなかったり、<code>retry_on</code> と <code>error_handling</code> をそれぞれ定義してるとお互いの関連が実感しづらい、という不満がありました。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>class ExampleApiClient &lt; MyApiClient::Base
 endpoint 'https://example.com'

 retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3
 error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError

 # GET https://example.com/users
 def get_users
 get 'users'
 end
end
</pre>


この <code>PR</code> では <code>retry</code> というオプションを <code>error_handling</code> に追加しています。これにより、以下の 2 つのコードは等価になります。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3
error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError
</pre>




<pre class="code lang-ruby" data-lang="ruby" data-unlink>error_handling json: { '$.errors.code': 20 }, 
 raise: MyApiClient::ApiLimitError, 
 retry: { wait: 1.minute, attempts: 3 }
</pre>


<code>retry_on</code> にオプションを指定する必要がなければ <code>retry: true</code> と書けば OK です。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>error_handling json: { '$.errors.code': 20 }, 
 raise: MyApiClient::ApiLimitError, 
 retry: true
</pre>


ただし、 <code>retry</code> オプションを使用する際は以下の点に注意が必要です。

<ul>
<li><code>error_handling</code> に <code>raise</code> オプションの指定が必須となります。</li>
<li>Block を使った <code>error_handling</code> の定義は禁止されます。</li>
</ul>

my_api_client v0.12.0 に含まれる PR の内容について解説していきます。より詳しい使い方は README.jp.md をご参照ください。#173 Avoid sleep on testingmy_api_client では以下のように書くと、任意の例外を補足して自動的に API リクエストをリトライしてくれます。ネットワーク系のエラーとか、 API Rate Limit に引っかかった時とかに便利なやつですね。ActiveJob の retry_on とほぼ同じ使い方になっています。class ExampleApiClient < MyApiClient::Base endpoint 'https://example.com' retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3 error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError # GET https://example.com/users def get_users get 'users' endendそれは良いんですが、 rspec 上で wait が効いてしまっていたので、上記のコードだとリトライ3回分 wait するので、合計 3 分も待たされてしまっていました。一応 rspec で sleep を stub するとかやれば回避できますが、そもそもテストでは wait を無視して欲しいですよね。my_api_client では be_handled_as_an_error という rspec の matcher を用意しているのですが、今回の対応で、この macher を経由してリトライが実行された場合は wait を無視するようになりました。RSpec.describe ExampleApiClient, type: :api_client do let(:api_client) { described_class.new } # NOTE: レスポンスで `{ "errors": { "code": 20 } }` を受診した際、3 回リトライが実行された後に `MyApiClient::ApiLimitError` として例外処理される。 it do expect { api_request! } .to be_handled_as_an_error(MyApiClient::ApiLimitError) .after_retry(3).times .when_receive(body: { errors: { code: 20 } }.to_json) endendまた、 ExampleApiClient は stub_api_client や stub_api_client_all を使用するとスタブ化できます。スタブ化した状態だと任意の API レスポンスを返すか、任意の例外を発生させる、という動作になってリトライが発生しなくなるので、上記の問題はありませんでした。stub_api_client_all(ExampleApiClient, get_users: { users: [{ id: 1 }, { id: 2 }, { id: 3 }] })response = ExampleApiClient.new.get_usersresponse.users # => [{ id: 1 }, { id: 2 }, { id: 3 }]#175 Verify arguments on error handling definitionerror_handling の定義でレスポンスのステータスコードを指定することができるんですが、このオプション名が status_code なのか status なのかをよく間違える、という問題がありました。$ rails g api_client を使用するとテンプレが作成されるので、そこからエラーハンドリングの定義を行うと間違えにくいのですが、後からエラーハンドリングを追加する時とかにやらかします。作者自身もたまにやらかしてました😇# 正解error_handling status_code: 400..499, raise: MyApiClient::ClientError# 間違いerror_handling status: 400..499, raise: MyApiClient::ClientErrorこの PR の対応で間違ったオプションを指定すると以下のような例外が発生するようになりました。RuntimeError: Specified an incorrect option: `status` You can use options that: [:response, :status_code, :json, :with, :raise, :block]#176 Provides a syntax sugar of retry_on on error_handling最初の PR でも出てきた retry_on ですが、 error_handling raise: MyApiClient::ApiLimitError でも同じ例外を指定していて DRY な感じじゃなかったり、retry_on と error_handling をそれぞれ定義してるとお互いの関連が実感しづらい、という不満がありました。class ExampleApiClient < MyApiClient::Base endpoint 'https://example.com' retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3 error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError # GET https://example.com/users def get_users get 'users' endendこの PR では retry というオプションを error_handling に追加しています。これにより、以下の 2 つのコードは等価になります。retry_on MyApiClient::ApiLimitError, wait: 1.minute, attempts: 3error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitErrorerror_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError, retry: { wait: 1.minute, attempts: 3 }retry_on にオプションを指定する必要がなければ retry: true と書けば OK です。error_handling json: { '$.errors.code': 20 }, raise: MyApiClient::ApiLimitError, retry: trueただし、 retry オプションを使用する際は以下の点に注意が必要です。error_handling に raise オプションの指定が必須となります。Block を使った error_handling の定義は禁止されます。

my_api_client v0.12.0 をリリースしました🚀

どーも、サトウリョウスケです。
<a href="https://ginza-rails.connpass.com/event/155467">金曜日に登壇した勉強会</a> で <del>うっかり</del> ブログ作るって言ってしまったので 10 年ぶりくらいにブログを復活させてみました。ブログのタイトルも 10 年前のタイトルと同じです（元ネタは<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%A1%A5%DF%A5%B3%A5%F3">ファミコン</a>時代の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E9%A5%AF%A5%A8">ドラクエ</a> IV）

勉強会の感想記事は近日中に書こうと思います✍️

<h2>この記事は Feedforce Advent Calendar 2019 の 15 日目です。</h2>

さて、最初の記事からいきなり会社の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%D9%A5%F3%A5%C8%A5%AB%A5%EC%A5%F3%A5%C0%A1%BC">アドベントカレンダー</a>記事になります🙏

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fadventar.org%2Fcalendars%2F4169" title="feedforce Advent Calendar 2019 - Adventar" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://adventar.org/calendars/4169">adventar.org</a></cite>

昨日は Yutaka KAWAI さんの「コーヒーは科学である ~抽出器具による味の違い~ <a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%DA%A1%BC%A5%D1%A1%BC%A5%C9%A5%EA%A5%C3%A5%D7">ペーパードリップ</a>編」でした。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnote.com%2Futahca%2Fn%2Fn30594094e406" title="コーヒーは科学である ~抽出器具による味の違い~ ペーパードリップ編｜Yutaka KAWAI｜note" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://note.com/utahca/n/n30594094e406">note.com</a></cite>

珈琲屋さんかな？ってくらい凄い記事でしたね☕️
記事に出てきたドリッパーは全種類持ってるってヤバくないですか？？？（もちろん良い意味で）

<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%DA%A1%BC%A5%D1%A1%BC%A5%C9%A5%EA%A5%C3%A5%D7">ペーパードリップ</a>編ってことは続編もあるのかな？
この感じで記事が量産されたらそのうち書籍化されるかもしれません📚

<h2>本編</h2>

予告通り個人で gem を作る流れについて話そうと思うのですが、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%D9%A5%F3%A5%C8%A5%AB%A5%EC%A5%F3%A5%C0%A1%BC">アドベントカレンダー</a>から流れてくると非エンジニアの方もきっと読まれると思うので、あんまり技術的な話題にせずにフワッとした話でもしようかと思います。

<h3>そもそも gem ってなんだっけ？</h3>

そもそも gem っていうのは <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> でできたライブラリの事でして、例えば僕が凄く便利なプログラムを書いて、それを gem として公開すれば、世界中の人が僕のイケてるプログラムを使えるようになる、というものです。まさに <a class="keyword" href="http://d.hatena.ne.jp/keyword/Win-Win">Win-Win</a> しかない仕組み。gem は世界を救います。

一方で、プログラムってのは新機能が追加されたり、不具合が修正されたりして日々アップデートが繰り返されています。
「この機能にはバージョン 1.3 以降でないと使えません」とか「色々イケてない部分が多いからこの機能は廃止します」という変更もあるので、自分のプログラムは一体どのバージョンの gem を使っているのか、という話が物凄く重要だったりします。

gem にはどのバージョンを使っているのか（依存しているのか）という情報を管理する機能も備わっていますので、ある日突然新バージョンで挙動が変わっても「うちは一個前のバージョン使ってます！」という管理ができていれば動かなくなることはないのです。

とはいえ新バージョンでいきなりそんなトンデモ変更されたら困りますけども。

<h3>僕が初めて作った gem</h3>

自分が生まれて初めて作った gem はこの <code>rubocop_challenger</code> という gem です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Frubocop_challenger" title="ryz310/rubocop_challenger" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/rubocop_challenger">github.com</a></cite>

一般的に gem は他のプログラムと組み合わせて使う事が多いのですが、 <code>rubocop_challenger</code> は単体で動作するやつでして、実行した<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C7%A5%A3%A5%EC%A5%AF%A5%C8">ディレクト</a>リ（フォルダ）にあるプログラムの<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9">ソースコード</a>を少しずつ綺麗に（人間にとって読みやすくしたり、書き方のルールを統一したり）してくれる、という gem です。

というと物凄い神 gem ですが、RuboCop という<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9">ソースコード</a>を解析してくれる便利な gem を内部で呼び出してプルリク（プルリクが何なのかはググってください）作ってくれる、という仕組みになっているので、「人間が毎日手作業でやらないといけなかった事を自動的にやる」というのが <code>rubocop_challenger</code> の提供する価値になります 🤖

詳しくはちょうど一年くらい前に会社のブログに書いたので、ご興味ありましたら是非。古い内容なので、現在のバージョンからは少しずれてますけど。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F12%2F05%2F140000" title="まだ .rubocop_todo.yml で消耗してるの？ - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/12/05/140000">developer.feedforce.jp</a></cite>

ちなみにもうすぐ <code>v2.0.0</code> をリリースする予定です。（pre バージョンですが、現時点でもすでに使えます）

<h3>ニッチな gem</h3>

初めて作ったのは <code>rubocop_challenger</code> という「人間が毎日手作業でやらないといけなかった事を自動的にやる」 gem でした。
完全に自分の会社のプロダクト用に作った gem でしたが、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Twitter">Twitter</a> などを<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B4%A5%B5">エゴサ</a>してると、ぼちぼち使って頂けているようです。
同じような悩みを抱えている人は世の中にはいるもんですね✨

とはいえ、 gem を公開したら世界中の人たちが使ってくれる、ということには中々ならないです。
一応頑張って英語で説明を書いたりはしていますが、個人の発信力には限界もありますし、何よりニッチです。

というか、個人が作る gem なんて大抵はニッチなものになります。
「あー、こんな gem あったらめっちゃ便利やん？」という gem は大抵世界のどこかの誰かが作ってます。
なので、今までにないような新しいgem を作ろうと思ったら大抵ニッチになります。

じゃあ gem を公開しても大して使ってもらえないし、あんまり意味ないじゃん、って思うかもしれませんが、意味無くはないんですよね👍

<h3>効能 1. <a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AD%A5%EB%A5%A2%A5%C3%A5%D7">スキルアップ</a></h3>

まず、めっちゃプログラムを書く勉強になります。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> で Web 開発をしている人は大抵 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby%20on%20Rails">Ruby on Rails</a> を使って書いてると思います。ちなみに <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby%20on%20Rails">Ruby on Rails</a> も gem です。
<a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby%20on%20Rails">Ruby on Rails</a> は凄くよく出来ているので、Web 開発の難しい部分を 9 割くらいの肩代わりしてくれます。

ところが、自分で一から gem を作ろうとすると、自分の力で解決しないといけないプログラム的な課題がめっちゃあります。
Web 開発はインターネット特有の課題が多いですが、 gem の開発には Web 開発以外の知識も色々要求されたりします。

何より、自分自身で仕様を一から考えないといけないので、普段の開発以上に意思決<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C4%EA%CE%CC">定量</a>がめっちゃ多いです。
自分は <code>rubocop_challenger</code> 以外にもメンテナンスしている gem が 3 つほどありますが、これらの開発を通して日頃の Web 開発の品質も一段レベルが上がったな、と感じる事が多いです。

なので、gem の開発は自分自身の修行のためだと思ってやると良いかもしれません。誰かに使えてもらえたらラッキー、みたいな。

逆に使ってもらえる事をモチベーションにするとちょっと辛いかもしれないです。思った以上に流行らない。もっと流行れ！

<h3>効能 2. <a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%DD%A1%BC%A5%C8%A5%D5%A5%A9%A5%EA%A5%AA">ポートフォリオ</a></h3>

gem を公開してるせいか、企業からのスカウトがめっちゃ来るようになります。

自分自身、会社の採用活動に関わる機会が多いのですが、例えばスカウト候補を探す際に候補者の <a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> は必ず見るようにしています。
その経験からですが自分で gem 書いて公開しているエンジニアは世の中の 1 割もいないんじゃないかな、って思っています。

自分も gem を作るようになったのはここ 1 ~ 2 年ですし、前職にいた頃だと普段の仕事の帰りが遅かったりもしたので家に帰ってから gem を作るような余裕もありませんでした。なので、本人の熱量や環境が整わないと gem の開発は難しいかもしれません。

しかしながら、自分も採用活動していて「お。この人すごいやん」ってなるのは <a class="keyword" href="http://d.hatena.ne.jp/keyword/GitHub">GitHub</a> や Qiita とかで何かしらアウトプットのある方なんですよね。
もちろんアウトプットが無くても実際会ってみたら凄かったって人は沢山いるんですが、採用活動だとその人の仕事でのアウトプットって見えないもんですから。。

別に gem じゃなくても良いんですが、自分自身のキャリア形成を意識するためのアウトプットの一環としてとても有用だと思います。

<h3>効能 3. 魔法のアイテム</h3>

自分が今年作った gem に <code>my_api_client</code> という gem がありまして、<a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> Client を作るための<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF">フレームワーク</a>なんですが、これはプロダクトの<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9">ソースコード</a>にも使っています。

自分が携わってるサービスは <a href="https://socialplus.jp/">ソーシャルPLUS</a> というものでして、企業の Web サービスとソーシャルログインプロバイダー（ LINE とか <a class="keyword" href="http://d.hatena.ne.jp/keyword/Twitter">Twitter</a> とか）のハブになってるサービスなんですね。そのせいもあって、外部の Web <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> へリク<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%B9">エス</a>トするという処理が多く、毎回同じようなエラーハンドリングやリトライの処理を何度も書かないといけなくて大変だった訳です。

あと、エラーが発生した際に「ソーシャルPLUS」「ソーシャルPLUSを利用している企業」「ソーシャルログインプロバイダ」の誰が原因なのかを特定するための情報をログに残すとかも都度対応しないといけなくて超大変でした。

<code>my_api_client</code> はその辺の処理をすっきり簡単に書けるようにするための gem でして、すっきり簡単なもんだから、チームメイトが <code>my_api_client</code> を活用して自発的にガンガン課題を解決してくれる、という最高にホットな状況を産み出すことに一役買っております。

やっぱエンジニアも人間なので、普段の業務で忙しい中で改善活動も同時にやろうなんてモチベーションは普通は湧いてこない訳です。でも、これを使えばすっきり簡単だよ、っていう魔法のアイテムがあれば、みんなの重い腰を少しだけ軽くする事ができます。

<code>my_api_client</code> は自分の中でも割とよくできた gem なので、毎回こんな良い gem が作れる訳じゃないですけど、 gem を作ってチームの生産性が上がるってのはやっぱ魔法のアイテムだなぁって思うんです。gem は世界を救います！（２回目）

なお、 <code>my_api_client</code> については <a href="https://ginza-rails.connpass.com/event/133628/">銀座 Rails #10</a> で登壇したときの資料があるので貼っておきます。これも若干古いので、最新の仕様とは少し異なるかもしれません。
最新の仕様は <a href="https://github.com/ryz310/my_api_client/blob/master/README.jp.md">こちら</a> をご覧下さい。

<script async class="speakerdeck-embed" data-id="75d691da45b041deb3db8e6748d81638" data-ratio="1.37081659973226" src="//speakerdeck.com/assets/embed.js"></script>


<h3>効能 4. たのしい</h3>

最後はここに帰ってくるんですが、自分の gem を作るのはやっぱ楽しいのです。いきなり頭悪い文章になりました。いつから頭良い文章書いてると錯覚していた？

以前勉強会で「これまでどういうキャリアを意識してやってきましたか？」って若手のエンジニアから聞かれたのですが、自分みたいな 30 半ばのエンジニアって、エンジニアになった当初は今みたいにエンジニアが持て囃される時代でもなかったので、自分からエンジニアになろうって思った人は少なからず「ただプログラムが好きだった」っていう人が多いんじゃないですかね？わかんないですけど自分はそうでした。

自作の gem を作ってると「やっぱプログラム書くのって楽しい」ってのを思い出させてくれます。
自分は他にも趣味でバンドやったり絵を描いたりしていますが、プログラミングが子供の頃に好きだった工作に一番近いような気がしています。

中々プライベートで時間を作るのは難しいんですが、やはり楽しさが一番根底の原動力になっているのかもしれないですね。

<h2>まとまらないまとめ</h2>

会社の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A2%A5%C9%A5%D9%A5%F3%A5%C8%A5%AB%A5%EC%A5%F3%A5%C0%A1%BC">アドベントカレンダー</a>向けだし、非エンジニアにも伝わるようなフワッとした文章にしようと思って書いてたら、途中から俺のポエムを書き殴ってただけになった気がしますが、役に立つかどうかは 2 の次にして、とりあえず gem 作ってみると楽しく<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AD%A5%EB%A5%A2%A5%C3%A5%D7">スキルアップ</a>できるし、もしかしたら誰かの魔法のアイテムになってるかもしれないよ、というお話でした。

久々にゆる〜い文章書いてて自分的には楽しかったです 笑

<h2>さて、明日の Advent Calendar は？（CV. <a class="keyword" href="http://d.hatena.ne.jp/keyword/%B2%C3%C6%A3%A4%DF%A4%C9%A4%EA">加藤みどり</a>）</h2>

<a href="https://adventar.org/calendars/4169">Feedforce Advent Calendar 2019</a>、明日は上岡君が「野球についてor遠隔<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%BF%A1%BC%A5%F3">インターン</a>について」書いてくれるみたいです。

最近は<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%BF%A1%BC%A5%F3">インターン</a>も遠隔で出来るんですね。野球も遠隔<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%BF%A1%BC%A5%F3">インターン</a>も未経験のままおじさんになってしまったので自分には未知の領域です⚾️💨

乞うご期待！

どーも、サトウリョウスケです。金曜日に登壇した勉強会 で うっかり ブログ作るって言ってしまったので 10 年ぶりくらいにブログを復活させてみました。ブログのタイトルも 10 年前のタイトルと同じです（元ネタはファミコン時代のドラクエ IV）勉強会の感想記事は近日中に書こうと思います✍️この記事は Feedforce Advent Calendar 2019 の 15 日目です。さて、最初の記事からいきなり会社のアドベントカレンダー記事になります🙏adventar.org昨日は Yutaka KAWAI さんの「コーヒーは科学である ~抽出器具による味の違い~ ペーパードリップ編」でした。note.com珈琲屋さんかな？ってくらい凄い記事でしたね☕️記事に出てきたドリッパーは全種類持ってるってヤバくないですか？？？（もちろん良い意味で）ペーパードリップ編ってことは続編もあるのかな？この感じで記事が量産されたらそのうち書籍化されるかもしれません📚本編予告通り個人で gem を作る流れについて話そうと思うのですが、アドベントカレンダーから流れてくると非エンジニアの方もきっと読まれると思うので、あんまり技術的な話題にせずにフワッとした話でもしようかと思います。そもそも gem ってなんだっけ？そもそも gem っていうのは Ruby でできたライブラリの事でして、例えば僕が凄く便利なプログラムを書いて、それを gem として公開すれば、世界中の人が僕のイケてるプログラムを使えるようになる、というものです。まさに Win-Win しかない仕組み。gem は世界を救います。一方で、プログラムってのは新機能が追加されたり、不具合が修正されたりして日々アップデートが繰り返されています。「この機能にはバージョン 1.3 以降でないと使えません」とか「色々イケてない部分が多いからこの機能は廃止します」という変更もあるので、自分のプログラムは一体どのバージョンの gem を使っているのか、という話が物凄く重要だったりします。gem にはどのバージョンを使っているのか（依存しているのか）という情報を管理する機能も備わっていますので、ある日突然新バージョンで挙動が変わっても「うちは一個前のバージョン使ってます！」という管理ができていれば動かなくなることはないのです。とはいえ新バージョンでいきなりそんなトンデモ変更されたら困りますけども。僕が初めて作った gem自分が生まれて初めて作った gem はこの rubocop_challenger という gem です。github.com一般的に gem は他のプログラムと組み合わせて使う事が多いのですが、 rubocop_challenger は単体で動作するやつでして、実行したディレクトリ（フォルダ）にあるプログラムのソースコードを少しずつ綺麗に（人間にとって読みやすくしたり、書き方のルールを統一したり）してくれる、という gem です。というと物凄い神 gem ですが、RuboCop というソースコードを解析してくれる便利な gem を内部で呼び出してプルリク（プルリクが何なのかはググってください）作ってくれる、という仕組みになっているので、「人間が毎日手作業でやらないといけなかった事を自動的にやる」というのが rubocop_challenger の提供する価値になります 🤖詳しくはちょうど一年くらい前に会社のブログに書いたので、ご興味ありましたら是非。古い内容なので、現在のバージョンからは少しずれてますけど。developer.feedforce.jpちなみにもうすぐ v2.0.0 をリリースする予定です。（pre バージョンですが、現時点でもすでに使えます）ニッチな gem初めて作ったのは rubocop_challenger という「人間が毎日手作業でやらないといけなかった事を自動的にやる」 gem でした。完全に自分の会社のプロダクト用に作った gem でしたが、 Twitter などをエゴサしてると、ぼちぼち使って頂けているようです。同じような悩みを抱えている人は世の中にはいるもんですね✨とはいえ、 gem を公開したら世界中の人たちが使ってくれる、ということには中々ならないです。一応頑張って英語で説明を書いたりはしていますが、個人の発信力には限界もありますし、何よりニッチです。というか、個人が作る gem なんて大抵はニッチなものになります。「あー、こんな gem あったらめっちゃ便利やん？」という gem は大抵世界のどこかの誰かが作ってます。なので、今までにないような新しいgem を作ろうと思ったら大抵ニッチになります。じゃあ gem を公開しても大して使ってもらえないし、あんまり意味ないじゃん、って思うかもしれませんが、意味無くはないんですよね👍効能 1. スキルアップまず、めっちゃプログラムを書く勉強になります。Ruby で Web 開発をしている人は大抵 Ruby on Rails を使って書いてると思います。ちなみに Ruby on Rails も gem です。Ruby on Rails は凄くよく出来ているので、Web 開発の難しい部分を 9 割くらいの肩代わりしてくれます。ところが、自分で一から gem を作ろうとすると、自分の力で解決しないといけないプログラム的な課題がめっちゃあります。Web 開発はインターネット特有の課題が多いですが、 gem の開発には Web 開発以外の知識も色々要求されたりします。何より、自分自身で仕様を一から考えないといけないので、普段の開発以上に意思決定量がめっちゃ多いです。自分は rubocop_challenger 以外にもメンテナンスしている gem が 3 つほどありますが、これらの開発を通して日頃の Web 開発の品質も一段レベルが上がったな、と感じる事が多いです。なので、gem の開発は自分自身の修行のためだと思ってやると良いかもしれません。誰かに使えてもらえたらラッキー、みたいな。逆に使ってもらえる事をモチベーションにするとちょっと辛いかもしれないです。思った以上に流行らない。もっと流行れ！効能 2. ポートフォリオgem を公開してるせいか、企業からのスカウトがめっちゃ来るようになります。自分自身、会社の採用活動に関わる機会が多いのですが、例えばスカウト候補を探す際に候補者の GitHub は必ず見るようにしています。その経験からですが自分で gem 書いて公開しているエンジニアは世の中の 1 割もいないんじゃないかな、って思っています。自分も gem を作るようになったのはここ 1 ~ 2 年ですし、前職にいた頃だと普段の仕事の帰りが遅かったりもしたので家に帰ってから gem を作るような余裕もありませんでした。なので、本人の熱量や環境が整わないと gem の開発は難しいかもしれません。しかしながら、自分も採用活動していて「お。この人すごいやん」ってなるのは GitHub や Qiita とかで何かしらアウトプットのある方なんですよね。もちろんアウトプットが無くても実際会ってみたら凄かったって人は沢山いるんですが、採用活動だとその人の仕事でのアウトプットって見えないもんですから。。別に gem じゃなくても良いんですが、自分自身のキャリア形成を意識するためのアウトプットの一環としてとても有用だと思います。効能 3. 魔法のアイテム自分が今年作った gem に my_api_client という gem がありまして、API Client を作るためのフレームワークなんですが、これはプロダクトのソースコードにも使っています。自分が携わってるサービスは ソーシャルPLUS というものでして、企業の Web サービスとソーシャルログインプロバイダー（ LINE とか Twitter とか）のハブになってるサービスなんですね。そのせいもあって、外部の Web API へリクエストするという処理が多く、毎回同じようなエラーハンドリングやリトライの処理を何度も書かないといけなくて大変だった訳です。あと、エラーが発生した際に「ソーシャルPLUS」「ソーシャルPLUSを利用している企業」「ソーシャルログインプロバイダ」の誰が原因なのかを特定するための情報をログに残すとかも都度対応しないといけなくて超大変でした。my_api_client はその辺の処理をすっきり簡単に書けるようにするための gem でして、すっきり簡単なもんだから、チームメイトが my_api_client を活用して自発的にガンガン課題を解決してくれる、という最高にホットな状況を産み出すことに一役買っております。やっぱエンジニアも人間なので、普段の業務で忙しい中で改善活動も同時にやろうなんてモチベーションは普通は湧いてこない訳です。でも、これを使えばすっきり簡単だよ、っていう魔法のアイテムがあれば、みんなの重い腰を少しだけ軽くする事ができます。my_api_client は自分の中でも割とよくできた gem なので、毎回こんな良い gem が作れる訳じゃないですけど、 gem を作ってチームの生産性が上がるってのはやっぱ魔法のアイテムだなぁって思うんです。gem は世界を救います！（２回目）なお、 my_api_client については 銀座 Rails #10 で登壇したときの資料があるので貼っておきます。これも若干古いので、最新の仕様とは少し異なるかもしれません。最新の仕様は こちら をご覧下さい。効能 4. たのしい最後はここに帰ってくるんですが、自分の gem を作るのはやっぱ楽しいのです。いきなり頭悪い文章になりました。いつから頭良い文章書いてると錯覚していた？以前勉強会で「これまでどういうキャリアを意識してやってきましたか？」って若手のエンジニアから聞かれたのですが、自分みたいな 30 半ばのエンジニアって、エンジニアになった当初は今みたいにエンジニアが持て囃される時代でもなかったので、自分からエンジニアになろうって思った人は少なからず「ただプログラムが好きだった」っていう人が多いんじゃないですかね？わかんないですけど自分はそうでした。自作の gem を作ってると「やっぱプログラム書くのって楽しい」ってのを思い出させてくれます。自分は他にも趣味でバンドやったり絵を描いたりしていますが、プログラミングが子供の頃に好きだった工作に一番近いような気がしています。中々プライベートで時間を作るのは難しいんですが、やはり楽しさが一番根底の原動力になっているのかもしれないですね。まとまらないまとめ会社のアドベントカレンダー向けだし、非エンジニアにも伝わるようなフワッとした文章にしようと思って書いてたら、途中から俺のポエムを書き殴ってただけになった気がしますが、役に立つかどうかは 2 の次にして、とりあえず gem 作ってみると楽しくスキルアップできるし、もしかしたら誰かの魔法のアイテムになってるかもしれないよ、というお話でした。久々にゆる〜い文章書いてて自分的には楽しかったです 笑さて、明日の Advent Calendar は？（CV. 加藤みどり）Feedforce Advent Calendar 2019、明日は上岡君が「野球についてor遠隔インターンについて」書いてくれるみたいです。最近はインターンも遠隔で出来るんですね。野球も遠隔インターンも未経験のままおじさんになってしまったので自分には未知の領域です⚾️💨乞うご期待！

私と gem

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

若干釣り臭いタイトルですが、先日 <a href="https://github.com/ryz310/rubocop_challenger">RubocopChallenger</a> という gem の <code>v1.0.0</code> をリリースしたので紹介させて頂きます 🙏

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Frubocop_challenger" title="GitHub - ryz310/rubocop_challenger: Make a clean your rubocop_todo.yml with CI" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/rubocop_challenger">github.com</a></cite>

<h2>経緯</h2>

僕が所属している <a href="https://socialplus.jp/">ソーシャルPLUS</a> は 2012 年頃から開発が始まりました。Rails のプロダクトとしては古株の方だと思います。

ソーシャルPLUS に <a href="https://github.com/rubocop-hq/rubocop">RuboCop</a> が導入されたのは 2017/02 頃 <a href="#fn:1" rel="footnote">1</a> で、それまで特に RuboCop を意識したコードで開発を進めてこなかったので、巨大な .rubocop_todo.yml が出力され、それが手付かずのままになってしまっていました。ちなみに当初は 1669 行 195 種類 の違反ルールがありました。

このままでは RuboCop の恩恵が受けられないので、 RuboCop Challenge と称して (以前 <a href="https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%A4%E3%82%B9%E3%83%BB%E3%83%90%E3%82%B1%E3%83%84%E3%83%BB%E3%83%81%E3%83%A3%E3%83%AC%E3%83%B3%E3%82%B8">Ice Bucket Challenge</a> が流行っていたので) 週イチで <code>.rubocop_todo.yml</code> から違反ルールを一つ消して、 auto-correct で修正する、という事をやっていたのですが、数ヶ月（数週間だったかも）ですっかりやるのを忘れてしまいました 😇

最近また RuboCop Challenge を再開しよう、という流れになったのですが、手動でコツコツやるのも精神的にしんどくなって来たので、なんとか自動化したいな、という気持ちになり、手動でやっていた Rubocop Challenge を Ruby スクリプトで動かせるようにしました。
最初は単純な Ruby スクリプトだったのですが、せっかくなので gem 化しよう、という事になり、作成したのが RubocopChallenger です。

ところで、弊社エンジニアの <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> が circleci-bundle-update-pr という CI を利用した Bundle Update の自動更新 gem を作成しています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fmasutaka%2Fcircleci-bundle-update-pr" title="GitHub - masutaka/circleci-bundle-update-pr: Provide continues bundle update using CircleCI" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/masutaka/circleci-bundle-update-pr">github.com</a></cite>

これに感銘を受けて (？) 自分の RubocopChallenger も CI から<code>$ rubocop --auto-correct</code> を実行した結果が PR として届くような仕組みになっています。

<h2>使い方</h2>

2021-09-23 修正

<h3>1. <code>.circleci/config.yml</code> の編集</h3>

以下に設定例を紹介します。

<pre class="code lang-yaml" data-lang="yaml" data-unlink># .circleci/config.yml
version: 2

jobs:
 rubocop_challenge:
 docker:
 - image: circleci/ruby:2.5-node-browsers
 working_directory: ~/repo
 steps:
 - checkout
 - run:
 name: Rubocop Challenge
 command: |
 gem install rubocop_challenger
 bundle exec rubocop_challenger go \
 --email={RubocopChallenger が commit する際の user email} \
 --name=&quot;{RubocopChallenger が commit する際の user name}&quot;

workflows:
 version: 2

 nightly:
 triggers:
 - schedule:
 cron: &quot;30 23 * * 1,2,3&quot; # この設定の場合、火水木 の毎朝 8:30 に RubocopChallnger の PR が届きます
 filters:
 branches:
 only:
 - master
 jobs:
 - rubocop_challenge
</pre>


インストールの際、 Gemfile に <code>gem 'rubocop_challenger'</code> を追記しないようにご注意下さい。
他の gem との互換性問題により、 rubocop_challenger 実行中にエラーが発生するケースがあることを確認しております。

<h3>2. GitHub personal access token の作成</h3>

RubocopChallenger が PR を作成するために GitHub personal access token が必要になります。
<a href="https://github.com/settings/tokens">Settings</a> から <a href="https://github.com/settings/tokens/new">Generate new token</a> をクリックして access token を作成します。
Select Scopes では <code>repo</code> にチェック ✅ を入れて下さい。

<img src="https://github.com/ryz310/rubocop_challenger/raw/master/images/generate_token.png" alt="Generate new token" />

<h3>3. CircleCI で環境変数の設定</h3>

今回は <a href="https://circleci.com/">CircleCI</a> での利用例を紹介します 🙏

<a href="https://circleci.com/dashboard">ダッシュボード画面</a> に移動し、 RubocopChallenger を適用したいアプリケーションの Project Settings -> Environment Variables へと移動します。
Add Variable をクリックして <code>GITHUB_ACCESS_TOKEN</code> という Key で先程作成した GitHub personal access token を設定します。

<img src="https://github.com/ryz310/rubocop_challenger/raw/master/images/circleci_environment_variables.png" alt="Environment Variables" />

<h3>5. 作成された PR の確認</h3>

ここまでの手順を終えると、 CircleCI に指定したスケジュールで PR がされるようになると思います。
後は auto-correct の内容を確認して、 merge するだけです。

中には適用したくないルールも出てくると思いますが、その場合は <code>.rubocop.yml</code> にルールを再定義して auto-correct されないようにします。

<h2>どんな PR が作成されるのか？</h2>

ちょっと RubocopChallenger のバージョンが古い頃の物ですが、 <a href="https://github.com/ryz310/rubocop_challenger/pull/97">以下のような PR</a> が自動的に作成されます。

<a href="https://github.com/ryz310/rubocop_challenger/pull/97"><img src="https://github.com/ryz310/rubocop_challenger/raw/master/images/rubocop_challenge.png" alt="RubocopChallnge" /></a>

デフォルトの設定では、 <code>.rubocop_todo.yml</code> の中から Cop supports --auto-correct かつ Offense count が最大 のルールを消して、 auto-correct した結果が PR として作成されます。

また、 auto-correct の後で <code>$ rubocop --auto-gen-config</code> を実行して <code>.rubocop_todo.yml</code> を再作成しています。 RuboCop のバージョンが変わった時とかに <code>.rubocop_todo.yml</code> に出力される内容も若干変わっていたりするのですが、毎回最新の状態に作り直してくれるのがちょっと便利だったりします。

ちなみに PR の Description に表示されている内容は <a href="https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Layout/AlignHash">本家 RuboCop の RubyDoc</a> に記載されている内容と同じものです。これを表示するのに地味に苦労しました 😓

<h2>高度な設定</h2>

RubocopChallnger にはいくつかオプションが用意されているので、ご紹介します。

<h3><code>--mode</code></h3>

上述の通り、デフォルトでは auto-correct の対象は Cop supports --auto-correct かつ Offense count が最大 のルールが選択されますが、 <code>mode</code> に渡す値によって対象を変更することが出来ます。

<ul>
<li><code>most_occurrence</code> (デフォルト)

<ul>
<li>Offense count が最大 のルールを選択する</li>
</ul>
</li>
<li><code>least_occurrence</code>

<ul>
<li>Offense count が最小 のルールを選択する</li>
</ul>
</li>
<li><code>random</code>

<ul>
<li>全体からランダムに選択する</li>
</ul>
</li>
</ul>


<h4>使用例</h4>

<pre class="code lang-sh" data-lang="sh" data-unlink>$ bundle exec rubocop_challenger go \
 --email=rubocop-challenger@example.com \
 --name=&quot;Rubocop Challenger&quot; \
 --mode=random 
</pre>


<h3><code>--labels</code></h3>

RubocopChallnger が作成する PR に付与される label を指定します。デフォルトでは rubocop challenge というラベルが付与されます。
ソーシャルPLUS では <a href="https://waffle.io/">waffle.io</a> を利用していたりするのですが、レビュー待ち状態の label を付与するようにすると見落としがなくて便利です。

スペース区切りで複数指定することが出来ます。

<h4>使用例</h4>

<pre class="code lang-sh" data-lang="sh" data-unlink>$ bundle exec rubocop_challenger go \
 --email=rubocop-challenger@example.com \
 --name=&quot;Rubocop Challenger&quot; \
 --labels=&quot;rubocop challenge&quot; &quot;in progress&quot;
</pre>


<h3><code>--template</code></h3>

作成される PR をカスタマイズしたい場合などあるかと思います。
その場合は template に erb ファイルのパスを指定することが可能です。

デフォルトでは以下のテンプレートが使用されるので、必要に応じてカスタマイズしてご利用下さい 🙏

<a href="https://github.com/ryz310/rubocop_challenger/blob/master/lib/templates/default.md.erb">https://github.com/ryz310/rubocop_challenger/blob/master/lib/templates/default.md.erb</a>

<h4>使用例</h4>

<pre class="code lang-sh" data-lang="sh" data-unlink>$ bundle exec rubocop_challenger go \
 --email=rubocop-challenger@example.com \
 --name=&quot;Rubocop Challenger&quot; \
 --template=./path/to/template.md.erb
</pre>


<h3><code>--no-regenerate-rubocop-todo</code></h3>

上述の通り、デフォルトでは auto-correct の後で <code>$ rubocop --auto-gen-config</code> を実行して .rubocop_todo.yml を再作成しています。これが不要な場合は no-regenerate-rubocop-todo オプションを指定します。

<h4>使用例</h4>

<pre class="code lang-sh" data-lang="sh" data-unlink>$ bundle exec rubocop_challenger go \
 --email=rubocop-challenger@example.com \
 --name=&quot;Rubocop Challenger&quot; \
 --no-regenerate-rubocop-todo
</pre>


<h2>既知の不具合 (v1.2.0 で解消済み)</h2>

RuboCop のルールの中には Cop supports --auto-correct と表記されているにも関わらず、部分的にしか auto-correct してくれないものがあります。
例えば <code>Style/Semicolon</code> が auto-correct できるのは行末に <code>;</code> が存在する場合だけのようです。

<pre class="code lang-ruby" data-lang="ruby" data-unlink>puts 'hoge'; # =&gt; auto-correct される
puts 'fuga'; puts 'piyo' # =&gt; auto-correct されない
</pre>


このようなルールが auto-correct 対象に選ばれると、RubocopChallenger を実行した後も違反が解決されず、後続の <code>$ rubocop --auto-gen-config</code> で再度 <code>.rubocop_todo.yml</code> に対象ルールが出てきてしまうので、 RubocopChallenger が機能しない状態になってしまいます。
現状では <code>Style/Semicolon</code> のようなルールに遭遇した場合は、手動で <code>.rubocop.yml</code> にルールを移動させる必要があります。
<del>今のところ RubocopChallenger 側での対策を思い付いていないので、もし良いアイデアがありましたら教えて下さい 🙏</del>

2019/03/26 追記

RubocopChallenger v1.2.0 で Ignore リスト機能が追加されました。
RubocopChallenger を実行した後も違反が解決されず、後続の <code>$ rubocop --auto-gen-config</code> で再度 <code>.rubocop_todo.yml</code> に対象ルールが出てきてしまった場合、 <code>.rubocop_challenger.yml</code> というファイルが作成され、対象ルールが Ignore リストに追加されます。
Ignore リストに追加されたルールは次回以降、 RubocopChallenger の対象ルールとして選択されなくなるので、特に何もしなくとも運用を続けることが可能となります。

<h2>最後に</h2>

当初は 1669 行 195 種類 の違反ルールが .rubocop_todo.yml に存在していましたが、 RubocopChallenger を導入してから 3 ヶ月で 1187 行 132 種類 まで減らすことが出来ました。 auto-correct 可能な違反ルールはあと 62 種類残っているので、あと半分くらいまでは減らすことができそうです。

本記事では肥大化してしまった .rubocop_todo.yml を自動的に修正していく RubocopChallnger を紹介し、導入方法について解説させて頂きました。 .rubocop_todo.yml が肥大化して困っているプロジェクトで役立てて頂ければ幸いです 🙏

また、利用してみてフィードバックなどあれば <a href="https://github.com/ryz310/rubocop_challenger/issues">Issue</a> にてご連絡下さい。 GitHub では頑張って拙い英語を書くようにしていますが、日本語でも大丈夫です 🙆 PR も大歓迎です。どうぞ宜しくお願い致します 🙇
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
ちなみに導入したのは自分です<a href="#fnref:1" rev="footnote">&#8617;</a></li>
</ol>
</div>

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎若干釣り臭いタイトルですが、先日 RubocopChallenger という gem の v1.0.0 をリリースしたので紹介させて頂きます 🙏github.com経緯僕が所属している ソーシャルPLUS は 2012 年頃から開発が始まりました。Rails のプロダクトとしては古株の方だと思います。ソーシャルPLUS に RuboCop が導入されたのは 2017/02 頃 1 で、それまで特に RuboCop を意識したコードで開発を進めてこなかったので、巨大な .rubocop_todo.yml が出力され、それが手付かずのままになってしまっていました。ちなみに当初は 1669 行 195 種類 の違反ルールがありました。このままでは RuboCop の恩恵が受けられないので、 RuboCop Challenge と称して (以前 Ice Bucket Challenge が流行っていたので) 週イチで .rubocop_todo.yml から違反ルールを一つ消して、 auto-correct で修正する、という事をやっていたのですが、数ヶ月（数週間だったかも）ですっかりやるのを忘れてしまいました 😇最近また RuboCop Challenge を再開しよう、という流れになったのですが、手動でコツコツやるのも精神的にしんどくなって来たので、なんとか自動化したいな、という気持ちになり、手動でやっていた Rubocop Challenge を Ruby スクリプトで動かせるようにしました。最初は単純な Ruby スクリプトだったのですが、せっかくなので gem 化しよう、という事になり、作成したのが RubocopChallenger です。ところで、弊社エンジニアの id:masutaka26 が circleci-bundle-update-pr という CI を利用した Bundle Update の自動更新 gem を作成しています。github.comこれに感銘を受けて (？) 自分の RubocopChallenger も CI から$ rubocop --auto-correct を実行した結果が PR として届くような仕組みになっています。使い方2021-09-23 修正1. .circleci/config.yml の編集以下に設定例を紹介します。# .circleci/config.ymlversion: 2jobs:  rubocop_challenge:    docker:      - image: circleci/ruby:2.5-node-browsers    working_directory: ~/repo    steps:      - checkout      - run:          name: Rubocop Challenge          command: |            gem install rubocop_challenger            bundle exec rubocop_challenger go \              --email={RubocopChallenger が commit する際の user email} \              --name="{RubocopChallenger が commit する際の user name}"workflows:  version: 2  nightly:    triggers:      - schedule:          cron: "30 23 * * 1,2,3" # この設定の場合、火水木 の毎朝 8:30 に RubocopChallnger の PR が届きます          filters:            branches:              only:                - master    jobs:      - rubocop_challengeインストールの際、 Gemfile に gem 'rubocop_challenger' を追記しないようにご注意下さい。他の gem との互換性問題により、 rubocop_challenger 実行中にエラーが発生するケースがあることを確認しております。2. GitHub personal access token の作成RubocopChallenger が PR を作成するために GitHub personal access token が必要になります。Settings から Generate new token をクリックして access token を作成します。Select Scopes では repo にチェック ✅ を入れて下さい。3. CircleCI で環境変数の設定今回は CircleCI での利用例を紹介します 🙏ダッシュボード画面 に移動し、 RubocopChallenger を適用したいアプリケーションの Project Settings -> Environment Variables へと移動します。Add Variable をクリックして GITHUB_ACCESS_TOKEN という Key で先程作成した GitHub personal access token を設定します。5. 作成された PR の確認ここまでの手順を終えると、 CircleCI に指定したスケジュールで PR がされるようになると思います。後は auto-correct の内容を確認して、 merge するだけです。中には適用したくないルールも出てくると思いますが、その場合は .rubocop.yml にルールを再定義して auto-correct されないようにします。どんな PR が作成されるのか？ちょっと RubocopChallenger のバージョンが古い頃の物ですが、 以下のような PR が自動的に作成されます。デフォルトの設定では、 .rubocop_todo.yml の中から Cop supports --auto-correct かつ Offense count が最大 のルールを消して、 auto-correct した結果が PR として作成されます。また、 auto-correct の後で $ rubocop --auto-gen-config を実行して .rubocop_todo.yml を再作成しています。 RuboCop のバージョンが変わった時とかに .rubocop_todo.yml に出力される内容も若干変わっていたりするのですが、毎回最新の状態に作り直してくれるのがちょっと便利だったりします。ちなみに PR の Description に表示されている内容は 本家 RuboCop の RubyDoc に記載されている内容と同じものです。これを表示するのに地味に苦労しました 😓高度な設定RubocopChallnger にはいくつかオプションが用意されているので、ご紹介します。--mode上述の通り、デフォルトでは auto-correct の対象は Cop supports --auto-correct かつ Offense count が最大 のルールが選択されますが、 mode に渡す値によって対象を変更することが出来ます。most_occurrence (デフォルト)Offense count が最大 のルールを選択するleast_occurrenceOffense count が最小 のルールを選択するrandom全体からランダムに選択する使用例$ bundle exec rubocop_challenger go \    --email=rubocop-challenger@example.com \    --name="Rubocop Challenger" \    --mode=random --labelsRubocopChallnger が作成する PR に付与される label を指定します。デフォルトでは rubocop challenge というラベルが付与されます。ソーシャルPLUS では waffle.io を利用していたりするのですが、レビュー待ち状態の label を付与するようにすると見落としがなくて便利です。スペース区切りで複数指定することが出来ます。使用例$ bundle exec rubocop_challenger go \    --email=rubocop-challenger@example.com \    --name="Rubocop Challenger" \    --labels="rubocop challenge" "in progress"--template作成される PR をカスタマイズしたい場合などあるかと思います。その場合は template に erb ファイルのパスを指定することが可能です。デフォルトでは以下のテンプレートが使用されるので、必要に応じてカスタマイズしてご利用下さい 🙏https://github.com/ryz310/rubocop_challenger/blob/master/lib/templates/default.md.erb使用例$ bundle exec rubocop_challenger go \    --email=rubocop-challenger@example.com \    --name="Rubocop Challenger" \    --template=./path/to/template.md.erb--no-regenerate-rubocop-todo上述の通り、デフォルトでは auto-correct の後で $ rubocop --auto-gen-config を実行して .rubocop_todo.yml を再作成しています。これが不要な場合は no-regenerate-rubocop-todo オプションを指定します。使用例$ bundle exec rubocop_challenger go \    --email=rubocop-challenger@example.com \    --name="Rubocop Challenger" \    --no-regenerate-rubocop-todo既知の不具合 (v1.2.0 で解消済み)RuboCop のルールの中には Cop supports --auto-correct と表記されているにも関わらず、部分的にしか auto-correct してくれないものがあります。例えば Style/Semicolon が auto-correct できるのは行末に ; が存在する場合だけのようです。puts 'hoge'; # => auto-correct されるputs 'fuga'; puts 'piyo' # => auto-correct されないこのようなルールが auto-correct 対象に選ばれると、RubocopChallenger を実行した後も違反が解決されず、後続の $ rubocop --auto-gen-config で再度 .rubocop_todo.yml に対象ルールが出てきてしまうので、 RubocopChallenger が機能しない状態になってしまいます。現状では Style/Semicolon のようなルールに遭遇した場合は、手動で .rubocop.yml にルールを移動させる必要があります。今のところ RubocopChallenger 側での対策を思い付いていないので、もし良いアイデアがありましたら教えて下さい 🙏2019/03/26 追記RubocopChallenger v1.2.0 で Ignore リスト機能が追加されました。RubocopChallenger を実行した後も違反が解決されず、後続の $ rubocop --auto-gen-config で再度 .rubocop_todo.yml に対象ルールが出てきてしまった場合、 .rubocop_challenger.yml というファイルが作成され、対象ルールが Ignore リストに追加されます。Ignore リストに追加されたルールは次回以降、 RubocopChallenger の対象ルールとして選択されなくなるので、特に何もしなくとも運用を続けることが可能となります。最後に当初は 1669 行 195 種類 の違反ルールが .rubocop_todo.yml に存在していましたが、 RubocopChallenger を導入してから 3 ヶ月で 1187 行 132 種類 まで減らすことが出来ました。 auto-correct 可能な違反ルールはあと 62 種類残っているので、あと半分くらいまでは減らすことができそうです。本記事では肥大化してしまった .rubocop_todo.yml を自動的に修正していく RubocopChallnger を紹介し、導入方法について解説させて頂きました。 .rubocop_todo.yml が肥大化して困っているプロジェクトで役立てて頂ければ幸いです 🙏また、利用してみてフィードバックなどあれば Issue にてご連絡下さい。 GitHub では頑張って拙い英語を書くようにしていますが、日本語でも大丈夫です 🙆 PR も大歓迎です。どうぞ宜しくお願い致します 🙇ちなみに導入したのは自分です↩

まだ .rubocop_todo.yml で消耗してるの？

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

RubyKaigi 2018 から早 3 週間。この記事を読んでいる方でも参加された方が沢山いるのではないかと思います。
個人的な感想ですが、今年は例年以上に充実していたんじゃないかな、と大満足です✨

感想記事はこちらの記事に詳しくまとめられています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F06%2F22%2F141314" title="RubyKaigi 2018 に行ってきたので今更所感などをまとめました - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/06/22/141314">developer.feedforce.jp</a></cite>

さて、今回の RubyKaigi の発表では笹田さんから Guild の進捗についての発表がありました。

<a href="http://www.atdot.net/~ko1/activities/2018_rubykaigi2018.pdf"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20180621/20180621190557.png" alt="Guild Prototype" /></a>

この Guild の概要について社内のメンバーに解説したところ中々に好評だったので、今回の記事では Guild とはどういうものなのかを超ざっくりですがご紹介します。

<ul class="table-of-contents">
 <li><a href="#そもそも論なぜ-Guild-が必要なのか">そもそも論。なぜ Guild が必要なのか？</a></li>
 <li><a href="#Guild-と-Thread-の関係">Guild と Thread の関係</a></li>
 <li><a href="#Guild-間のデータの受け渡し">Guild 間のデータの受け渡し</a></li>
 <li><a href="#おわりに">おわりに</a></li>
</ul>

<h1 id="そもそも論なぜ-Guild-が必要なのか">そもそも論。なぜ Guild が必要なのか？</h1>

ご存知の方も多いかと思いますが、現在の Ruby のスレッド処理はマルチコアに対応していません。
最近の PC の殆どにはマルチコア CPU が搭載されていると思いますが、１つの Ruby プロセスが利用できるコアは１つだけです。つまり、並列処理と言っても複数の処理を時間分割して実行しているだけという事になります。 Guild は Ruby でマルチコアを使った並列処理を実現するために必要な機能となります。

ちなみに Guild という名称はあくまでコードネームであるため、リリース時には別の名称になると思われます。

<h1 id="Guild-と-Thread-の関係">Guild と Thread の関係</h1>

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20180621/20180621191002.png" alt="f:id:ryz310:20180621191002p:plain" title="f:id:ryz310:20180621191002p:plain" class="hatena-fotolife" itemprop="image">

上図のように Guild に Thread が内包される関係になり、プロセス全体でいうと <code>RubyVM → Guild → Thread → Fiber</code> という関係になります。
これを踏まえて、 Guild 導入の前後を図に起こすと以下のようになります（雑な図で恐縮です。。🙇）

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20180621/20180621183710.jpg" alt="f:id:ryz310:20180621183710j:plain" title="f:id:ryz310:20180621183710j:plain" class="hatena-fotolife" itemprop="image">

同一 Guild 内の Thread は従来どおりシングルコアで動作します。しかし、 Guild を複数定義することで、それぞれの Guild に所属する Thread は並列に動作するようになります。
Guild が実装されていない現在の Ruby は <code>RubyVM → Thread → Fiber</code> という関係になりますが、言い換えればこれは単一の Guild で作られた Ruby プログラムとみなせると思います。
このことから、Guild が実装されても後方互換性は保たれるのではないか予想されます。

<h1 id="Guild-間のデータの受け渡し">Guild 間のデータの受け渡し</h1>

Guild 間でのデータ受け渡しについて、 Shareable Object と Non-Shareable Object という概念が出てきます。
詳細は <a href="http://www.atdot.net/~ko1/activities/2018_rubykaigi2018.pdf">発表スライド</a> を見てもらうとして、大雑把に両者の違いを説明すると以下のようになります。

<ul>
<li>Shareable Object

<ul>
<li>Guild 間でデータ共有が可能なオブジェクト</li>
<li>基本的に値が変化しない Immutable なデータがこれに該当する

<ul>
<li>Const や Freeze したデータのこと</li>
<li>ただし Array や Hash は Freeze しても内側のデータまで Freeze されないので、 Shareable とはならないので注意

<ul>
<li>これについては Deep Freeze を実装するかも、とのこと。</li>
</ul>
</li>
</ul>
</li>
<li>他にも Isolated Proc という、ブロックの外側の変数へのアクセスを禁止した Proc もこれに該当しますが、詳細は割愛</li>
</ul>
</li>
<li>Non-Shareable Object

<ul>
<li>Guild 間でデータ共有が禁止されているオブジェクト

<ul>
<li>データの受け渡しができない訳ではない（詳しくは後述）</li>
</ul>
</li>
<li>主に一般的な変数のこと</li>
<li>単一の Guild にのみ所属する</li>
</ul>
</li>
</ul>


Shareable Object は Immutable (値が変化しない)オブジェクトなので、並列処理中にデータを共有しても問題ないことはイメージしやすいかと思います。
重要なのは Non-Shareable Object の受け渡しで、以下に示す 2 つの方法があります。

<ul>
<li>COPY

<ul>
<li>データを Guild 間で共有するのではなく、別の Guild にコピーして渡す</li>
</ul>
</li>
<li>MOVE

<ul>
<li>別の Guild にデータを渡すと、元の Guild からは見えなくなる</li>
</ul>
</li>
</ul>


COPY は参照渡しではなく実体渡しなので、１つのデータに対して同時アクセスすることにはならず、 Thread-Safe なやりとりになります。
一方の MOVE は、データを別の Guild に渡すと元の Guild からはアクセスできなくなる、カットアンドペーストのような振る舞いになります。
こちらも同時アクセスが発生しないため、 Thread-Safe なやりとりになります。

ちなみに MOVE より COPY が利用されるケースが多いだろうとのことでした。

<h1 id="おわりに">おわりに</h1>

RubyKaigi 2018 で発表された Guild について超ざっくりと説明してみました。間違ってるところがあればご指摘頂けますと幸いです🙏
なお、開発中の仕様なので実装までにいくつかの変更があるかもしれません。

想像ですが、 Sidekiq とか Puma のような Thread ベースのサービスは Guild が導入されたら劇的にパフォーンスが良くなるかもしれませんね。
これからの Ruby の可能性に期待が高まります✨

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎RubyKaigi 2018 から早 3 週間。この記事を読んでいる方でも参加された方が沢山いるのではないかと思います。個人的な感想ですが、今年は例年以上に充実していたんじゃないかな、と大満足です✨感想記事はこちらの記事に詳しくまとめられています。developer.feedforce.jpさて、今回の RubyKaigi の発表では笹田さんから Guild の進捗についての発表がありました。この Guild の概要について社内のメンバーに解説したところ中々に好評だったので、今回の記事では Guild とはどういうものなのかを超ざっくりですがご紹介します。そもそも論。なぜ Guild が必要なのか？Guild と Thread の関係Guild 間のデータの受け渡しおわりにそもそも論。なぜ Guild が必要なのか？ご存知の方も多いかと思いますが、現在の Ruby のスレッド処理はマルチコアに対応していません。最近の PC の殆どにはマルチコア CPU が搭載されていると思いますが、１つの Ruby プロセスが利用できるコアは１つだけです。つまり、並列処理と言っても複数の処理を時間分割して実行しているだけという事になります。 Guild は Ruby でマルチコアを使った並列処理を実現するために必要な機能となります。ちなみに Guild という名称はあくまでコードネームであるため、リリース時には別の名称になると思われます。Guild と Thread の関係上図のように Guild に Thread が内包される関係になり、プロセス全体でいうと RubyVM → Guild → Thread → Fiber という関係になります。これを踏まえて、 Guild 導入の前後を図に起こすと以下のようになります（雑な図で恐縮です。。🙇）同一 Guild 内の Thread は従来どおりシングルコアで動作します。しかし、 Guild を複数定義することで、それぞれの Guild に所属する Thread は並列に動作するようになります。Guild が実装されていない現在の Ruby は RubyVM → Thread → Fiber という関係になりますが、言い換えればこれは単一の Guild で作られた Ruby プログラムとみなせると思います。このことから、Guild が実装されても後方互換性は保たれるのではないか予想されます。Guild 間のデータの受け渡しGuild 間でのデータ受け渡しについて、 Shareable Object と Non-Shareable Object という概念が出てきます。詳細は 発表スライド を見てもらうとして、大雑把に両者の違いを説明すると以下のようになります。Shareable ObjectGuild 間でデータ共有が可能なオブジェクト基本的に値が変化しない Immutable なデータがこれに該当するConst や Freeze したデータのことただし Array や Hash は Freeze しても内側のデータまで Freeze されないので、 Shareable とはならないので注意これについては Deep Freeze を実装するかも、とのこと。他にも Isolated Proc という、ブロックの外側の変数へのアクセスを禁止した Proc もこれに該当しますが、詳細は割愛Non-Shareable ObjectGuild 間でデータ共有が禁止されているオブジェクトデータの受け渡しができない訳ではない（詳しくは後述）主に一般的な変数のこと単一の Guild にのみ所属するShareable Object は Immutable (値が変化しない)オブジェクトなので、並列処理中にデータを共有しても問題ないことはイメージしやすいかと思います。重要なのは Non-Shareable Object の受け渡しで、以下に示す 2 つの方法があります。COPYデータを Guild 間で共有するのではなく、別の Guild にコピーして渡すMOVE別の Guild にデータを渡すと、元の Guild からは見えなくなるCOPY は参照渡しではなく実体渡しなので、１つのデータに対して同時アクセスすることにはならず、 Thread-Safe なやりとりになります。一方の MOVE は、データを別の Guild に渡すと元の Guild からはアクセスできなくなる、カットアンドペーストのような振る舞いになります。こちらも同時アクセスが発生しないため、 Thread-Safe なやりとりになります。ちなみに MOVE より COPY が利用されるケースが多いだろうとのことでした。おわりにRubyKaigi 2018 で発表された Guild について超ざっくりと説明してみました。間違ってるところがあればご指摘頂けますと幸いです🙏なお、開発中の仕様なので実装までにいくつかの変更があるかもしれません。想像ですが、 Sidekiq とか Puma のような Thread ベースのサービスは Guild が導入されたら劇的にパフォーンスが良くなるかもしれませんね。これからの Ruby の可能性に期待が高まります✨

10 分でわかる Ruby Guild

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

前回の記事では Docker を使って Rails 5.2 の環境構築をしました。
現在も引き続き Docker についてのお話をします。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F02%2F11%2F140012" title="Rails 5.2 開発環境を Docker で構築する - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://developer.feedforce.jp/entry/2018/02/11/140012">developer.feedforce.jp</a></cite>

その後も幾つか手を加え続けておりまして、現在この記事を書いている時点で <code>v1.3.0</code> になりました 🎉
明らかに初回のナンバリングを間違えていた感がありますが、少しずつインクリメントさせていく楽しみを実感できて良いです 笑

<h2>前回からの変更点について</h2>

さて、前回の記事は <code>v1.0.0</code> 時点のものでしたが、ここで <code>v1.3.0</code> になった現在の <code>Dockerfile</code> を見てみましょう。

<pre class="code" data-lang="" data-unlink># Dockerfile
FROM ryz310/rails-on-docker</pre>


なんと！たったの１行ぽっちです！＼＼\٩( 'ω' )و //／／

何言ってんだコイツと思われそうですが、これはどういう事かというと、大部分を <code>base/Dockerfile</code> に移動したためです。

<pre class="code" data-lang="" data-unlink># base/Dockerfile
FROM ruby:2.5
MAINTAINER ryz310@gmail.com

RUN apt-get update -qq &amp;&amp; apt-get install -y build-essential libpq-dev nodejs

WORKDIR /myapp
ENV BUNDLE_JOBS=32

ONBUILD ADD Gemfile /myapp/Gemfile
ONBUILD ADD Gemfile.lock /myapp/Gemfile.lock
ONBUILD RUN bundle install
ONBUILD ADD . /myapp</pre>


この <code>base/Dockerfile</code> のイメージは <a href="https://hub.docker.com/r/ryz310/rails-on-docker/">僕のDocker Hub</a> に置いてあります。

<code>ONBUILD</code> が付いたコマンドはこのイメージを継承したイメージで実行されるため、先ほどの <code>Dockerfile</code> には <code>FROM</code> しかありませんが、ビルドの際には以下の 4 つのコマンドが実行される事になります。

<pre class="code" data-lang="" data-unlink>ADD Gemfile /myapp/Gemfile
ADD Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
ADD . /myapp</pre>


感覚としては、 <code>base/Dockerfile</code> で Rails の起動に必要なサーバー環境を構築して、 <code>Dockerfile</code> で Rails そのものを構築していくような感じです。
Rails の構築には RDS イメージなども必須となってきますので、それについては <code>docker-compose.yml</code> と組み合わせて構築していきます。

<pre class="code" data-lang="" data-unlink># docker-compose.yml
version: &#39;3&#39;
services:
 db:
 image: mysql:5.7
 volumes:
 - mysql_data:/var/lib/mysql
 environment:
 MYSQL_ALLOW_EMPTY_PASSWORD: &#39;yes&#39;
 ports:
 - &#34;3306:3306&#34;
 web:
 build: .
 image: web_image
 command: bundle exec rails s -p 3000 -b &#39;0.0.0.0&#39;
 volumes:
 - .:/myapp
 - bundle:/usr/local/bundle
 ports:
 - &#34;3000:3000&#34;
 depends_on:
 - db
 environment:
 DB_HOST: db
 spring:
 image: web_image
 command: bundle exec spring server
 volumes:
 - .:/myapp
 - bundle:/usr/local/bundle
 tty: false
 stdin_open: false
 environment:
 DB_HOST: db
volumes:
 mysql_data:
 bundle:</pre>


ここも <code>v1.0.0</code> の頃からいくつか変更がありまして、例えば <code>web</code> と <code>spring</code> で同じ内容になるように <code>v1.0.0</code> では YAML のエイリアスを使っていたのですが、 docker image で共有する方法に変えました。この定義の記述について少し補足します。

<code>web</code> の定義で <code>build: .</code> と <code>image: web_image</code> と言う記述がありますが、これは Dockerfile をビルドして <code>web_image</code> というタグをつける、と言う振る舞いになります。一方、 <code>spring</code> の定義の <code>image: web_image</code> では <code>web_image</code> というタグが付いたイメージを使用する、という振る舞いになります。この辺はなんだかややこしいですね 😓

また、 <code>bundle:/usr/local/bundle</code> を volume に指定する事で、<code>bundle install</code> の内容を永続化するようにしてあります。これにより、<code>$ docker-compose run --rm web bundle install</code> というコマンドが有効になってくるので、Gemfile を更新した際に一から Build する必要がなくなります。
同様に、 MySQL も <code>mysql_data:/var/lib/mysql</code> を volume に指定する事で、テーブルの内容を永続化するようにしています。

<h2>まとめ</h2>

<code>ONBUILD</code> を使用する事で、他の Rails アプリでも同じイメージを転用できるようになったのが一番の改善点ではないかと思います。

ただ、Rails アプリ側の事情で何か <code>$ apt-get install</code> を加えたくなった場合にどうするのか、という課題感があります。<code>base/Dockerfile</code> は汎用的な環境構築を意識しているので、あまり一般的でないインストールは行いたくありません。理想としては「子イメージ」で <code>$ apt-get install</code> させて、「孫イメージ」で今回のように Rails の構築をする構成が実現できれば良いのではないかと思いますが、 <code>ONBUILD</code> を「子イメージ」でスキップさせるとか出来るんでしょうか？

次回はこの辺について少し調べていければ、と思っています。

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎前回の記事では Docker を使って Rails 5.2 の環境構築をしました。現在も引き続き Docker についてのお話をします。developer.feedforce.jpその後も幾つか手を加え続けておりまして、現在この記事を書いている時点で v1.3.0 になりました 🎉明らかに初回のナンバリングを間違えていた感がありますが、少しずつインクリメントさせていく楽しみを実感できて良いです 笑前回からの変更点についてさて、前回の記事は v1.0.0 時点のものでしたが、ここで v1.3.0 になった現在の Dockerfile を見てみましょう。# DockerfileFROM ryz310/rails-on-dockerなんと！たったの１行ぽっちです！＼＼\٩( 'ω' )و //／／何言ってんだコイツと思われそうですが、これはどういう事かというと、大部分を base/Dockerfile に移動したためです。# base/DockerfileFROM ruby:2.5MAINTAINER ryz310@gmail.comRUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejsWORKDIR /myappENV BUNDLE_JOBS=32ONBUILD ADD Gemfile /myapp/GemfileONBUILD ADD Gemfile.lock /myapp/Gemfile.lockONBUILD RUN bundle installONBUILD ADD . /myappこの base/Dockerfile のイメージは 僕のDocker Hub に置いてあります。ONBUILD が付いたコマンドはこのイメージを継承したイメージで実行されるため、先ほどの Dockerfile には FROM しかありませんが、ビルドの際には以下の 4 つのコマンドが実行される事になります。ADD Gemfile /myapp/GemfileADD Gemfile.lock /myapp/Gemfile.lockRUN bundle installADD . /myapp感覚としては、 base/Dockerfile で Rails の起動に必要なサーバー環境を構築して、 Dockerfile で Rails そのものを構築していくような感じです。Rails の構築には RDS イメージなども必須となってきますので、それについては docker-compose.yml と組み合わせて構築していきます。# docker-compose.ymlversion: '3'services:  db:    image: mysql:5.7    volumes:      - mysql_data:/var/lib/mysql    environment:      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'    ports:      - "3306:3306"  web:    build: .    image: web_image    command: bundle exec rails s -p 3000 -b '0.0.0.0'    volumes:      - .:/myapp      - bundle:/usr/local/bundle    ports:      - "3000:3000"    depends_on:      - db    environment:      DB_HOST: db  spring:    image: web_image    command: bundle exec spring server    volumes:      - .:/myapp      - bundle:/usr/local/bundle    tty: false    stdin_open: false    environment:      DB_HOST: dbvolumes:  mysql_data:  bundle:ここも v1.0.0 の頃からいくつか変更がありまして、例えば web と spring で同じ内容になるように v1.0.0 では YAML のエイリアスを使っていたのですが、 docker image で共有する方法に変えました。この定義の記述について少し補足します。web の定義で build: . と image: web_image と言う記述がありますが、これは Dockerfile をビルドして web_image というタグをつける、と言う振る舞いになります。一方、 spring の定義の image: web_image では web_image というタグが付いたイメージを使用する、という振る舞いになります。この辺はなんだかややこしいですね 😓また、 bundle:/usr/local/bundle を volume に指定する事で、bundle install の内容を永続化するようにしてあります。これにより、$ docker-compose run --rm web bundle install というコマンドが有効になってくるので、Gemfile を更新した際に一から Build する必要がなくなります。同様に、 MySQL も mysql_data:/var/lib/mysql を volume に指定する事で、テーブルの内容を永続化するようにしています。まとめONBUILD を使用する事で、他の Rails アプリでも同じイメージを転用できるようになったのが一番の改善点ではないかと思います。ただ、Rails アプリ側の事情で何か $ apt-get install を加えたくなった場合にどうするのか、という課題感があります。base/Dockerfile は汎用的な環境構築を意識しているので、あまり一般的でないインストールは行いたくありません。理想としては「子イメージ」で $ apt-get install させて、「孫イメージ」で今回のように Rails の構築をする構成が実現できれば良いのではないかと思いますが、 ONBUILD を「子イメージ」でスキップさせるとか出来るんでしょうか？次回はこの辺について少し調べていければ、と思っています。

続・Rails 5.2 開発環境を Docker で構築する

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

僕が所属している <a href="https://socialplus.jp/">ソーシャルPLUS</a> チームでは Rails の開発環境を Docker で構築しています。
自分も日々お世話になっている Docker ですが、イチから Dockerfile 書いた事が無かったので、やってみました。

こちらのチュートリアルを参考にしています。

<a href="http://docs.docker.jp/compose/rails.html">&#x30AF;&#x30A4;&#x30C3;&#x30AF;&#x30B9;&#x30BF;&#x30FC;&#x30C8;&#x30FB;&#x30AC;&#x30A4;&#x30C9;&#xFF1A;Docker Compose &#x3068; Rails &mdash; Docker-docs-ja 17.06.Beta &#x30C9;&#x30AD;&#x30E5;&#x30E1;&#x30F3;&#x30C8;</a>

<h1>やってみた✨</h1>

早速ですがこちらが完成品の GitHub リポジトリになります。
<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fryz310%2Frails-on-docker%2Ftree%2Fv1.0.0" title="ryz310/rails-on-docker" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/ryz310/rails-on-docker/tree/v1.0.0">github.com</a></cite>

この記事は <code>v1.0.0</code> 時点で書いていますが、リポジトリは今後も更新されていく可能性があります。

<h2>環境</h2>

<ul>
<li>Debian Stretch</li>
<li>Ruby 2.5.0</li>
<li>Rails 5.2.0.rc1</li>
<li>MySQL 5.7</li>
</ul>


<h2>つかいかた</h2>

Rails 5.2 で環境構築したと言いましたが、リポジトリには Rails のソースコードが一切含まれていません。
これは <code>rails new</code> から Docker でやっていくためです。
以下に手順を示しますので、興味ある方はぜひ記事を読みながら一緒にやってみて下さい 🙏

<h3>0. リポジトリをローカルにクローンする</h3>

<pre class="code" data-lang="" data-unlink>$ git clone https://github.com/ryz310/rails-on-docker.git</pre>


<h3>1. 以下のコマンドを実行する</h3>

<pre class="code" data-lang="" data-unlink>$ docker-compose run web rails new . --force --database=mysql --skip-bundle --skip-git</pre>


<code>rails new</code> によって必要なファイルがインストールされます。同時に Gemfile も Rails 用に更新されます。
残念ながらアプリ名は指定できないので、必要に応じて変更して下さい。

なお、後述の MySQL データの永続化のため MySQL のデータファイルを含めないようにリポジトリの方で <code>.gitignore</code> を用意しています。
そのため <code>--skip-git</code> を付けて Rails に <code>.gitignore</code> ファイルを作成させないようにしていますが、永続化が不用な場合はオプションを外して下さい。

<h3>2. 更新された <code>Gemfile</code> で以下のコメントアウトを外す</h3>

<pre class="code" data-lang="" data-unlink># gem &#39;mini_racer&#39;, platforms: :ruby</pre>


以前であれば <code>therubyracer</code> だったのですが、いつの間にか <code>mini_racer</code> に変わっていたのですね。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftechracho.bpsinc.jp%2Fhachi8833%2F2017_06_09%2F41039" title="週刊Railsウォッチ（20170609）ついにtherubyracerからmini_racerへ、注意しないとハマるgem、5.1でのVue.jsとTurbolinksの共存ほか" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://techracho.bpsinc.jp/hachi8833/2017_06_09/41039">techracho.bpsinc.jp</a></cite>

TechRacho さんの週刊Railsウォッチにはいつもお世話になっております 🙏

<h3>3. <code>$ docker-compose build</code> を実行する</h3>

Gemfile を変更したので再読イメージを作り直します。

<h3>4. <code>config/database.yml</code> を以下のように変更する</h3>

<pre class="code" data-lang="" data-unlink>default: &amp;default
 adapter: mysql2
 encoding: utf8
 pool: &lt;%= ENV.fetch(&#34;RAILS_MAX_THREADS&#34;) { 5 } %&gt;
 username: root
 password: xxxxxx # &lt;- ここを変更
 host: db # &lt;- ここを変更</pre>


あくまでローカルの開発環境構築なのでパスワードを隠したりとかはしません。本番運用とかでやっちゃダメですよ！
MySQL の Root ユーザーのパスワードは <code>docker-compose.yml</code> で指定しています。必要に応じて書き換えて下さい。

<pre class="code" data-lang="" data-unlink> db:
 image: mysql:5.7
 volumes:
 - .mysql_data:/var/lib/mysql
 environment:
 MYSQL_ROOT_PASSWORD: xxxxxx # &lt;- ここ！</pre>


<h3>5. <code>$ docker-compose up</code> を実行する</h3>

コンテナを起動させます。

<h3>6. <code>$ docker-compose exec spring spring rake db:create</code> を実行する</h3>

コンテナは起動していますが、Rails で使用する DB テーブルはまだ作成されていないので作成します。
何気に <code>spring</code> を使っている点に注目です。

<h3>7. <a href="http://localhost:3000/">http://localhost:3000/</a> にアクセスして Rails が動いていることを確認</h3>

ここまでの操作で Rails が正しく動作しているはずです。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20180211/20180211110115.png" alt="f:id:ryz310:20180211110115p:plain" title="f:id:ryz310:20180211110115p:plain" class="hatena-fotolife" itemprop="image"><figcaption>Yay! You’re on Rails!</figcaption></figure>

<h1>ポイント</h1>

<h2><code>bundle install</code> が毎回走らないように工夫している</h2>

Dockerfile で WORKDIR に <code>/tmp</code> ディレクトリを指定しているところがポイントです。
これをせずに <code>WORKDIR /myapp</code> からの <code>ADD . /myapp</code> をやってしまうと、 Rails のコードに変更がある度に <code>bundle install</code> が最初から実行されてしまいます。
Gemfile と Gemfile.lock を <code>/tmp</code> に格納することで、これらのファイルに変更がない限り <code>bundle install</code> が実行されないようになっています。

<pre class="code" data-lang="" data-unlink>WORKDIR /tmp
ADD Gemfile Gemfile
ADD Gemfile.lock Gemfile.lock
RUN bundle install
WORKDIR /myapp
ADD . /myapp</pre>


参考: <a href="https://easyramble.com/rails-development-on-docker.html#crayon-5a7fa9761d5ba051809395">Docker&#x3067;Rails + MySQL&#x306E;&#x958B;&#x767A;&#x74B0;&#x5883;&#x3092;&#x69CB;&#x7BC9; | EasyRamble</a>

<h2><code>spring</code> に対応</h2>

Rails で開発する上で欠かせない <code>spring</code> も利用できるようにしてあります。
前述の <code>rake db:create</code> の時にも出てきましたが、<code>$ docker-compose exec spring spring rails console</code> のようにして使います。
<code>spring</code> が 2 回出てくるところがポイントです。一つ目はコンテナのサービス名です。

毎回書くのはだるいので僕は alias にしています。fish shell 用なので良いように読み替えて下さい 🙏

<pre class="code" data-lang="" data-unlink># ~/.config/fish/config.fish

# docker-compose aliases
function fig
 docker-compose $argv
end

function figspring
 docker-compose exec spring spring $argv
end</pre>




<pre class="code" data-lang="" data-unlink># USAGE
$ figspring rails c</pre>


参考: <a href="https://qiita.com/kawasin73/items/2253523be18e5afd994f">&#x9AD8;&#x901F;&#x306B;&#x958B;&#x767A;&#x3067;&#x304D;&#x308B; Docker + Rails&#x958B;&#x767A;&#x74B0;&#x5883;&#x306E;&#x30C6;&#x30F3;&#x30D7;&#x30EC;&#x30FC;&#x30C8;&#x3092;&#x4F5C;&#x3063;&#x305F; - Qiita</a>

<h2>MySQL データの永続化</h2>

イメージを作り直した時に MySQL のデータが失われてしまうのは辛いものがあります。
毎回テスト用のデータを一から作り直したくないので、 <code>docker-compose.yml</code> で以下のように指定してMySQL のデータを永続化させています。

<pre class="code" data-lang="" data-unlink> db:
 image: mysql:5.7
 volumes:
 - .mysql_data:/var/lib/mysql # &lt;- これ！
 environment:
 MYSQL_ROOT_PASSWORD: xxxxxx</pre>


<code>.mysql_data</code> ディレクトリ以下に MySQL のデータが格納されています。リポジトリの <code>.gitignore</code> で無視させています。
試していませんが、参考にさせて頂いた記事によると Docker for Mac 以外の環境では問題が発生するようですのでご注意下さい。
対応方法も記事内で紹介されています 🙏

参考: <a href="https://blog.leko.jp/post/how-to-mount-data-volume-to-local-with-docker-compose/">docker compose&#x3067;MySQL&#x306E;&#x30C7;&#x30FC;&#x30BF;&#x9818;&#x57DF;&#x3092;&#x30ED;&#x30FC;&#x30AB;&#x30EB;&#x306B;&#x30DE;&#x30A6;&#x30F3;&#x30C8;&#x3059;&#x308B; | WEB EGG</a>

<h1>まとめ</h1>

週末に何かアプリでも書こうかと思った時に、ついでに Docker で環境構築もやっちゃうか、と思い立って書きました。
そうこうしてるうちに週末の半分くらいが過ぎ去っていますが、きっと今後は捗るはず。。 😇
何度も確認していますが、もし間違っている点、不便な点などありましたらそっと教えて頂けますと幸いです 🙏
Fork も大歓迎ですし、誰かに使ってもらえると嬉しいです 😁

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎僕が所属している ソーシャルPLUS チームでは Rails の開発環境を Docker で構築しています。自分も日々お世話になっている Docker ですが、イチから Dockerfile 書いた事が無かったので、やってみました。こちらのチュートリアルを参考にしています。クイックスタート・ガイド：Docker Compose と Rails — Docker-docs-ja 17.06.Beta ドキュメントやってみた✨早速ですがこちらが完成品の GitHub リポジトリになります。github.comこの記事は v1.0.0 時点で書いていますが、リポジトリは今後も更新されていく可能性があります。環境Debian StretchRuby 2.5.0Rails 5.2.0.rc1MySQL 5.7つかいかたRails 5.2 で環境構築したと言いましたが、リポジトリには Rails のソースコードが一切含まれていません。これは rails new から Docker でやっていくためです。以下に手順を示しますので、興味ある方はぜひ記事を読みながら一緒にやってみて下さい 🙏0. リポジトリをローカルにクローンする$ git clone https://github.com/ryz310/rails-on-docker.git1. 以下のコマンドを実行する$ docker-compose run web rails new . --force --database=mysql --skip-bundle --skip-gitrails new によって必要なファイルがインストールされます。同時に Gemfile も Rails 用に更新されます。残念ながらアプリ名は指定できないので、必要に応じて変更して下さい。なお、後述の MySQL データの永続化のため MySQL のデータファイルを含めないようにリポジトリの方で .gitignore を用意しています。そのため --skip-git を付けて Rails に .gitignore ファイルを作成させないようにしていますが、永続化が不用な場合はオプションを外して下さい。2. 更新された Gemfile で以下のコメントアウトを外す# gem 'mini_racer', platforms: :ruby以前であれば therubyracer だったのですが、いつの間にか mini_racer に変わっていたのですね。techracho.bpsinc.jpTechRacho さんの週刊Railsウォッチにはいつもお世話になっております 🙏3. $ docker-compose build を実行するGemfile を変更したので再読イメージを作り直します。4. config/database.yml を以下のように変更するdefault: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: xxxxxx # <- ここを変更 host: db # <- ここを変更あくまでローカルの開発環境構築なのでパスワードを隠したりとかはしません。本番運用とかでやっちゃダメですよ！MySQL の Root ユーザーのパスワードは docker-compose.yml で指定しています。必要に応じて書き換えて下さい。 db: image: mysql:5.7 volumes: - .mysql_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: xxxxxx # <- ここ！5. $ docker-compose up を実行するコンテナを起動させます。6. $ docker-compose exec spring spring rake db:create を実行するコンテナは起動していますが、Rails で使用する DB テーブルはまだ作成されていないので作成します。何気に spring を使っている点に注目です。7. http://localhost:3000/ にアクセスして Rails が動いていることを確認ここまでの操作で Rails が正しく動作しているはずです。Yay! You’re on Rails!ポイントbundle install が毎回走らないように工夫しているDockerfile で WORKDIR に /tmp ディレクトリを指定しているところがポイントです。これをせずに WORKDIR /myapp からの ADD . /myapp をやってしまうと、 Rails のコードに変更がある度に bundle install が最初から実行されてしまいます。Gemfile と Gemfile.lock を /tmp に格納することで、これらのファイルに変更がない限り bundle install が実行されないようになっています。WORKDIR /tmpADD Gemfile GemfileADD Gemfile.lock Gemfile.lockRUN bundle installWORKDIR /myappADD . /myapp参考: DockerでRails + MySQLの開発環境を構築 | EasyRamblespring に対応Rails で開発する上で欠かせない spring も利用できるようにしてあります。前述の rake db:create の時にも出てきましたが、$ docker-compose exec spring spring rails console のようにして使います。spring が 2 回出てくるところがポイントです。一つ目はコンテナのサービス名です。毎回書くのはだるいので僕は alias にしています。fish shell 用なので良いように読み替えて下さい 🙏# ~/.config/fish/config.fish# docker-compose aliasesfunction fig docker-compose $argvendfunction figspring docker-compose exec spring spring $argvend# USAGE$ figspring rails c参考: 高速に開発できる Docker + Rails開発環境のテンプレートを作った - QiitaMySQL データの永続化イメージを作り直した時に MySQL のデータが失われてしまうのは辛いものがあります。毎回テスト用のデータを一から作り直したくないので、 docker-compose.yml で以下のように指定してMySQL のデータを永続化させています。 db: image: mysql:5.7 volumes: - .mysql_data:/var/lib/mysql # <- これ！ environment: MYSQL_ROOT_PASSWORD: xxxxxx.mysql_data ディレクトリ以下に MySQL のデータが格納されています。リポジトリの .gitignore で無視させています。試していませんが、参考にさせて頂いた記事によると Docker for Mac 以外の環境では問題が発生するようですのでご注意下さい。対応方法も記事内で紹介されています 🙏参考: docker composeでMySQLのデータ領域をローカルにマウントする | WEB EGGまとめ週末に何かアプリでも書こうかと思った時に、ついでに Docker で環境構築もやっちゃうか、と思い立って書きました。そうこうしてるうちに週末の半分くらいが過ぎ去っていますが、きっと今後は捗るはず。。 😇何度も確認していますが、もし間違っている点、不便な点などありましたらそっと教えて頂けますと幸いです 🙏Fork も大歓迎ですし、誰かに使ってもらえると嬉しいです 😁

Rails 5.2 開発環境を Docker で構築する

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

突然ですがワテクシ、 Rails アプリはそこそこ書ける方なんですが、インフラはからきしだったりします。 <a href="https://dic.pixiv.net/a/%E3%82%AD%E3%83%A2%E3%83%BC%E3%82%A4%E3%82%AC%E3%83%BC%E3%83%AB%E3%82%BA">フルスタックじゃないエンジニアが許されるのは小学生までだよねー</a>、というちょっと懐かしみのある煽りが社内のからも聞こえてきそうなので、最近インフラを少しずつ触るようにしています。触ってみるとインフラも色々楽しいですね ✌︎('ω')✌︎

とはいえ、インフラエンジニアレベル 1 の自分があれこれやっても障害に繋がるだけなので、まずはお手軽な雑用タスクから始めることにしました。

さて、少し話は変わって、最近、弊社サービスで Sidekiq プロセスのファイルディスクリプタが急騰してサーバーがダウンする、という障害が何度か発生しました。
現象としては Sidekiq プロセスのファイルディスクリプタが上限値 (初期値は <code>1024</code> ) に達すると、サーバーの CPU 使用率が 100 % 付近まで達してしまう、というものだったので、ファイルディスクリプタの上限を <code>65536</code> まで上げる、というワークアラウンドな対応で凌いでいました。

現在は解決済み（この原因については、別途記事にします）ですが、当時はなぜファイルディスクリプタの数が上昇し続けてしまうのか原因が全くわからず、チームのエンジニアは安眠できない日々が続いていました。とりあえず Sidekiq のプロセスをリスタートすればファイルディスクリプタの数は一旦リセットされるので、監視してやばくなったらアラートを飛ばして再起動させる、という方法で一旦は凌ます。また、継続して監視することで、原因の解明にも繋がるかもしれません。

弊社のサービスでは監視に <a href="https://mackerel.io/">mackerel</a> を利用しているので、カスタムメトリックを使ってお手軽に監視させよう、ということになりました。
mackerel のカスタムメトリックの投稿方法は <a href="https://mackerel.io/ja/docs/entry/advanced/custom-metrics">こちらの記事</a> にまとまっています。
要点だけ抜粋しますと、 <a href="https://mackerel.io/ja/docs/entry/spec/agent#config-file">mackerel-agent の設定ファイル</a> に 以下の書式で標準出力を実行するコマンドを記述 すれば OK です。

<blockquote>設定ファイルで指定するコマンドは、標準出力の各行に以下のフォーマットの出力をすることが期待されます（<code>\t</code> はタブ文字です）:</blockquote>

<pre class="code" data-lang="" data-unlink>{metric name}\t{metric value}\t{epoch seconds}</pre>


そして以下がファイルディスクリプタを監視するための設定です（完成品がレンジから出てくるパティーン）

<pre class="code" data-lang="" data-unlink>[plugin.metrics.file_descriptor_count]
command = &#39;&#39;&#39;
 echo -e &#34;file_descriptor.sidekiq\\t$(sudo ls /proc/$(pgrep -f -u {user_name} sidekiq | head -1)/fd/ | wc -l)\\t$(date -u +%s)&#34;
&#39;&#39;&#39;</pre>


標準出力されれば OK なので、 <code>echo</code> で任意の文字列を出力するような方法でも実現可能です。内部で <code>pgrep -f -u {user_name} sidekiq</code> と書いて、プロセス ID を取得していますが、 <code>-u</code> でプロセスを実行しているユーザーを指定しないと、 <code>pgrep</code> のプロセス ID を取得してしまうケースがあるので注意が必要です。(mackerel-agent は <code>root</code> で実行される)
同じ要領で、他にも以下のように書けば <code>puma</code> のファイルディスクリプタも取ることができます。

<pre class="code" data-lang="" data-unlink>[plugin.metrics.file_descriptor_count]
command = &#39;&#39;&#39;
 echo -e &#34;file_descriptor.puma\\t$(sudo ls /proc/$(pgrep -f -u {user_name} puma.sock | head -1)/fd/ | wc -l)\\t$(date -u +%s)&#34;
 echo -e &#34;file_descriptor.puma_cluster_worker\\t$(sudo ls /proc/$(pgrep -f -u {user_name} &#39;puma: cluster worker&#39; | head -1)/fd/ | wc -l)\\t$(date -u +%s)&#34;
&#39;&#39;&#39;</pre>


ちなみにこの記事を書くときに、もしやと思って調べてみたら、 <code>mackerel-agent-plugins</code> の中に <a href="https://github.com/mackerelio/mackerel-agent-plugins/tree/master/mackerel-plugin-proc-fd">任意のプロセスのファイルディスクリプタを監視する奴</a> がありました 😓
試していませんが、こっちを使った方が良いと思います 😇

そんな感じで監視できたグラフが以下になります。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/r/ryz310/20171231/20171231142049.png" alt="f:id:ryz310:20171231142049p:plain" title="f:id:ryz310:20171231142049p:plain" class="hatena-fotolife" itemprop="image">

ファイルディスクリプタ数がファイナルファンタジーの HP みたいになってますね。。。
とりあえず <code>10,000</code> を超えたらアラートを飛ばすように設定しましたが、デプロイする度にリセットされるので、結局アラートが飛ぶことも障害が発生することもなく、問題は解決しました。

本稿では <code>echo</code> を使ったワンライナーでカスタムメトリックを投稿する方法を紹介しました。
<code>mackerel-agent-plugins</code> に載っていないけどワークアラウンドでとりあえず監視させたい、という時は便利だと思うので、どこかでご活用ください 🙏

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎突然ですがワテクシ、 Rails アプリはそこそこ書ける方なんですが、インフラはからきしだったりします。 フルスタックじゃないエンジニアが許されるのは小学生までだよねー、というちょっと懐かしみのある煽りが社内のからも聞こえてきそうなので、最近インフラを少しずつ触るようにしています。触ってみるとインフラも色々楽しいですね ✌︎('ω')✌︎とはいえ、インフラエンジニアレベル 1 の自分があれこれやっても障害に繋がるだけなので、まずはお手軽な雑用タスクから始めることにしました。さて、少し話は変わって、最近、弊社サービスで Sidekiq プロセスのファイルディスクリプタが急騰してサーバーがダウンする、という障害が何度か発生しました。現象としては Sidekiq プロセスのファイルディスクリプタが上限値 (初期値は 1024 ) に達すると、サーバーの CPU 使用率が 100 % 付近まで達してしまう、というものだったので、ファイルディスクリプタの上限を 65536 まで上げる、というワークアラウンドな対応で凌いでいました。現在は解決済み（この原因については、別途記事にします）ですが、当時はなぜファイルディスクリプタの数が上昇し続けてしまうのか原因が全くわからず、チームのエンジニアは安眠できない日々が続いていました。とりあえず Sidekiq のプロセスをリスタートすればファイルディスクリプタの数は一旦リセットされるので、監視してやばくなったらアラートを飛ばして再起動させる、という方法で一旦は凌ます。また、継続して監視することで、原因の解明にも繋がるかもしれません。弊社のサービスでは監視に mackerel を利用しているので、カスタムメトリックを使ってお手軽に監視させよう、ということになりました。mackerel のカスタムメトリックの投稿方法は こちらの記事 にまとまっています。要点だけ抜粋しますと、 mackerel-agent の設定ファイル に 以下の書式で標準出力を実行するコマンドを記述 すれば OK です。設定ファイルで指定するコマンドは、標準出力の各行に以下のフォーマットの出力をすることが期待されます（\t はタブ文字です）:{metric name}\t{metric value}\t{epoch seconds}そして以下がファイルディスクリプタを監視するための設定です（完成品がレンジから出てくるパティーン）[plugin.metrics.file_descriptor_count]command = '''  echo -e "file_descriptor.sidekiq\\t$(sudo ls /proc/$(pgrep -f -u {user_name} sidekiq | head -1)/fd/ | wc -l)\\t$(date -u +%s)"'''標準出力されれば OK なので、 echo で任意の文字列を出力するような方法でも実現可能です。内部で pgrep -f -u {user_name} sidekiq と書いて、プロセス ID を取得していますが、 -u でプロセスを実行しているユーザーを指定しないと、 pgrep のプロセス ID を取得してしまうケースがあるので注意が必要です。(mackerel-agent は root で実行される)同じ要領で、他にも以下のように書けば puma のファイルディスクリプタも取ることができます。[plugin.metrics.file_descriptor_count]command = '''  echo -e "file_descriptor.puma\\t$(sudo ls /proc/$(pgrep -f -u {user_name} puma.sock | head -1)/fd/ | wc -l)\\t$(date -u +%s)"  echo -e "file_descriptor.puma_cluster_worker\\t$(sudo ls /proc/$(pgrep -f -u {user_name} 'puma: cluster worker' | head -1)/fd/ | wc -l)\\t$(date -u +%s)"'''ちなみにこの記事を書くときに、もしやと思って調べてみたら、 mackerel-agent-plugins の中に 任意のプロセスのファイルディスクリプタを監視する奴 がありました 😓試していませんが、こっちを使った方が良いと思います 😇そんな感じで監視できたグラフが以下になります。ファイルディスクリプタ数がファイナルファンタジーの HP みたいになってますね。。。とりあえず 10,000 を超えたらアラートを飛ばすように設定しましたが、デプロイする度にリセットされるので、結局アラートが飛ぶことも障害が発生することもなく、問題は解決しました。本稿では echo を使ったワンライナーでカスタムメトリックを投稿する方法を紹介しました。mackerel-agent-plugins に載っていないけどワークアラウンドでとりあえず監視させたい、という時は便利だと思うので、どこかでご活用ください 🙏

mackerel のカスタムメトリックを echo でワンライナーしたった

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

<a href="http://developer.feedforce.jp/entry/2017/11/04/235323">前回</a>に引き続き、 Dynamoid 第3弾です ✌︎('ω')✌︎

Rails で DynamoDB を利用する際の ORM として <code>dynamoid</code> があります。
今回は <code>dynamoid</code> から Global Secondary Index (GSI) を利用する方法について紹介します。

<ul class="table-of-contents">
 <li><a href="#Global-Secondary-Index-GSI-ってなんぞ">Global Secondary Index (GSI) ってなんぞ</a><ul>
 <li><a href="#今回も名称の整理をしておきます">今回も名称の整理をしておきます</a></li>
 <li><a href="#GSI-は検索のためのインデックス">GSI は検索のためのインデックス</a></li>
 <li><a href="#Local-Secondary-Index-LSI-もあるやで">Local Secondary Index (LSI) もあるやで</a></li>
 <li><a href="#どういう用途で便利なのか">どういう用途で便利なのか</a></li>
 </ul>
 </li>
 <li><a href="#Dynamoid-での利用方法">Dynamoid での利用方法</a><ul>
 <li><a href="#テーブル定義">テーブル定義</a><ul>
 <li><a href="#where-を使えば-GSI-を使って自動的にクエリで検索してくれる">#where を使えば GSI を使って自動的にクエリで検索してくれる</a></li>
 <li><a href="#昇順降順を入れ替えたい場合">昇順・降順を入れ替えたい場合</a></li>
 </ul>
 </li>
 </ul>
 </li>
 <li><a href="#まとめ">まとめ</a></li>
</ul>

<code>dynamoid</code> の導入方法については以前書いたこちらの記事を参考にしてみて下さい。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Ftech.feedforce.jp%2Fdynamodb-setup-on-rails.html" title="DynamoDB を Rails で使えるようにするためのあれこれ | feedforce Engineers&#39; blog" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://tech.feedforce.jp/dynamodb-setup-on-rails.html">tech.feedforce.jp</a></cite>

<h1 id="Global-Secondary-Index-GSI-ってなんぞ">Global Secondary Index (GSI) ってなんぞ</h1>

<h2 id="今回も名称の整理をしておきます">今回も名称の整理をしておきます</h2>

文中に Hash Key やら Range Key という名称が出てきますが、現在は名称が異なります。
しかし、 <code>dyanmoid</code> では相変わらず旧名称のまま (<code>hash_key</code>, <code>range_key</code>) でパラメータを指定するので、今回も最初に対応表を記載しておきます。

<table>
<thead>
<tr>
<th style="text-align:center;"> 旧名称 </th>
<th style="text-align:center;"> 現名称 </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center;"> Hash Key </td>
<td style="text-align:center;"> Partition Key </td>
</tr>
<tr>
<td style="text-align:center;"> Range Key </td>
<td style="text-align:center;"> Sort Key </td>
</tr>
</tbody>
</table>


<h2 id="GSI-は検索のためのインデックス">GSI は検索のためのインデックス</h2>

DynamoDB にはプライマリキーの指定方法として、単一の Partition Key を使用する方法と、Partition Key と Sort Key を組み合わせて使用する方法があります。
これについては前回の【range 編】の記事でも触れました。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2017%2F11%2F04%2F235323" title="Dynamoid の使い方【range 編】 - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://developer.feedforce.jp/entry/2017/11/04/235323">developer.feedforce.jp</a></cite>

プライマリキーに指定されたカラムに対してであれば、レコードの抽出や範囲検索などが実行可能となる訳ですが、プライマリキーに指定されていないカラムに対しては検索が実行できず、テーブルのフルスキャンを実行することになってしまい非効率です。そこで、別のカラムに対しても検索を行いたい場合は GSI を設定して、フルスキャンすることなく効率的にデータを抽出できるようにします。

<iframe src="//www.slideshare.net/slideshow/embed_code/key/gHjtA6AS8rk0sB?startSlide=47" width="595" height="485" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"> </iframe>


GSI もプライマリキーの指定と同様に、単一の Partition Key のみで指定することも、 Partition Key と Sort Key の組み合わせで指定することも可能です。
ただし、 プライマリキーにはユニーク制約が設定されますが、 GSI にはユニーク制約が存在しない ので、その点には注意が必要です。

<h2 id="Local-Secondary-Index-LSI-もあるやで">Local Secondary Index (LSI) もあるやで</h2>

LSI の Partition Key はプライマリキーと共通です。Sort Key の部分だけ別に設定したい場合に使用します。その点を除けば GSI とよく似ていますが、こちらはテーブルの作成時にしか定義することができないようです。

<iframe src="//www.slideshare.net/slideshow/embed_code/key/gHjtA6AS8rk0sB?startSlide=46" width="595" height="485" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"> </iframe>


なお、LSI も<code>dynamoid</code> から指定することは可能 (<code>local_secondary_index</code> を使用する) ですが、本稿では触れません。

<h2 id="どういう用途で便利なのか">どういう用途で便利なのか</h2>

あまり複雑なテーブル設計が推奨されない DynamoDB ですが、簡単なテーブル間の関連付けを行いたいシーンが出てきます。親テーブルの ID を結合キーとして子テーブルに設定したい場合などに GSI は便利です。
以下に User Table と User Comment Table の例を示します。User Comment Table には親テーブルである User Table の ID が GSI の Partition Key として設定してあります。また、コメントの投稿日時 (Posted at) を GSI の Sort Key として設定しています。これで User 毎に投稿日時順にソートしたコメントを取得することができるようになります。

User Table

<table>
<thead>
<tr>
<th style="text-align:center;"> ID </th>
<th> name </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center;"> 1 </td>
<td> John </td>
</tr>
<tr>
<td style="text-align:center;"> 2 </td>
<td> Marry </td>
</tr>
<tr>
<td style="text-align:center;"> 3 </td>
<td> Taro </td>
</tr>
</tbody>
</table>


User Comment Table

<table>
<thead>
<tr>
<th style="text-align:center;"> ID (Primary Partition Key) </th>
<th style="text-align:center;"> User ID (GSI Partition Key) </th>
<th> Posted at (GSI Sort Key) </th>
<th style="text-align:center;"> Comment </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center;"> 1 </td>
<td style="text-align:center;"> 1 </td>
<td> 1509529916 </td>
<td style="text-align:center;"> Hello </td>
</tr>
<tr>
<td style="text-align:center;"> 2 </td>
<td style="text-align:center;"> 1 </td>
<td> 1509530052 </td>
<td style="text-align:center;"> I am John </td>
</tr>
<tr>
<td style="text-align:center;"> 3 </td>
<td style="text-align:center;"> 1 </td>
<td> 1509530085 </td>
<td style="text-align:center;"> How do you do? </td>
</tr>
<tr>
<td style="text-align:center;"> 4 </td>
<td style="text-align:center;"> 2 </td>
<td> 1509523925 </td>
<td style="text-align:center;"> Thanks a lot! </td>
</tr>
<tr>
<td style="text-align:center;"> 5 </td>
<td style="text-align:center;"> 3 </td>
<td> 1509527628 </td>
<td style="text-align:center;"> こんにちは </td>
</tr>
<tr>
<td style="text-align:center;"> 6 </td>
<td style="text-align:center;"> 3 </td>
<td> 1509527101 </td>
<td style="text-align:center;"> どうも </td>
</tr>
</tbody>
</table>


ちなみに、プライマリキーと GSI を逆に設定してもほぼ成立するのですが、前述したように GSI にはユニーク制約が存在しないので、User Comment Table では ID をプライマリキーとして、重複が生じないように設定してあります。

<h1 id="Dynamoid-での利用方法">Dynamoid での利用方法</h1>

<h2 id="テーブル定義">テーブル定義</h2>

ここからは前述の User Table と User Comment Table を <code>dynamoid</code> から利用する例を示していきます。

<pre class="code" data-lang="" data-unlink>class User
 include Dynamoid::Document

 table name: :users, key: :id

 field :name, :string

 # 現在のユーザーに紐付くコメントを作成する
 def create_comment!(attributes = {})
 attributes[:user_id] = id
 UserComment.new(attributes).tap(&amp;:save!)
 end

 # 現在のユーザーのコメント一覧を取得する
 def comments
 UserComment.where(user_id: id)
 end

 # 現在のユーザーの最終コメントを取得する
 def latest_comment
 comments.scan_index_forward(false).scan_limit(1).all.first
 end
end</pre>




<pre class="code" data-lang="" data-unlink>class UserComment
 include Dynamoid::Document

 table name: :user_comments, key: :id

 field :user_id, :string
 field :posted_at, :datetime

 global_secondary_index hash_key: :user_id, 
 range_key: :posted_at, 
 projected_attributes: :all
end</pre>


※ ちなみに <code>dynamoid</code> には <code>has_many</code> を利用して関連テーブルを実現する方法があるのですが、結合キーを親テーブルに持つ設計になるのがあまり好ましくなかったので、自前で実装しています。

いくつか注意する点があって、 <code>global_secondary_index</code> で使用する <code>hash_key</code> と <code>range_key</code> は <code>field</code> で定義されている必要があります。
また、 <code>projected_attributes: :all</code> というオプションをつけないと後述の <code>#where</code> でインデックスを利用した検索が行われません。一旦これが無い状態でリリースとしてしまうと、射影される属性が限定された GSI が作成されてしまい、実行時にエラーになります。その場合は AWS マネジメントコンソールから直接 GSI を作り直す羽目になりますのでご注意ください 🙏

<pre class="code" data-lang="" data-unlink>One or more parameter values were invalid: Select type ALL_ATTRIBUTES is not supported for global secondary index</pre>


<h3 id="where-を使えば-GSI-を使って自動的にクエリで検索してくれる"><code>#where</code> を使えば GSI を使って自動的にクエリで検索してくれる</h3>

<code>#comments</code> というメソッドの中で <code>#where</code> を使用した検索が登場しますが、 GSI が設定されていれば特別な記述がなくとも自動的にクエリ検索が行われます。

<pre class="code" data-lang="" data-unlink>UserComment.where(user_id: id)
# =&gt; [#&lt;UserComment:0x00007f44c86183e8&gt;, ...]</pre>


前述の通り <code>projected_attributes: :all</code> が指定されていないとフルスキャンされてしまうのでご注意ください。

<h3 id="昇順降順を入れ替えたい場合">昇順・降順を入れ替えたい場合</h3>

<code>#latest_comment</code> というメソッド内で使用していますが、 <code>#scan_index_forward(false)</code> と指定すると降順でソートされた状態で結果が返ってきます。未指定の場合は昇順でソートされます。
また、 <code>#scan_limit(n)</code> と指定することで、先頭から <code>n</code> 件の結果に限定して取得が可能です。<code>#latest_comment</code> ではこれらを組み合わせて最終のコメントを取得しています。

<h1 id="まとめ">まとめ</h1>

本稿では GSI と LSI とプライマリキーの違い、具体的な利用用途を紹介しました。<a href="http://developer.feedforce.jp/entry/2017/11/04/235323">前回の記事</a>でも触れましたが、 <code>dynamoid</code> は初回実行時にテーブルや GSI が存在していないと作成する、という挙動になるため、後で設計を変えたくなった場合に GSI や最悪テーブルを作り直す羽目になります。特に初めて利用する場合は設計の勘所を掴むのが難しいので、リリース前に入念に設計を見直すことをお勧めします。その点では RDS 以上に慎重な設計が求められるように感じています。
色々と気を付けなければならない点も多いですが、並列動作性は非常に高いので、利用したくなるシーンが必ず出てくると思います。その際に本稿が少しでもお役に立てば幸いです 🙏

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎前回に引き続き、 Dynamoid 第3弾です ✌︎('ω')✌︎Rails で DynamoDB を利用する際の ORM として dynamoid があります。今回は dynamoid から Global Secondary Index (GSI) を利用する方法について紹介します。Global Secondary Index (GSI) ってなんぞ今回も名称の整理をしておきますGSI は検索のためのインデックスLocal Secondary Index (LSI) もあるやでどういう用途で便利なのかDynamoid での利用方法テーブル定義#where を使えば GSI を使って自動的にクエリで検索してくれる昇順・降順を入れ替えたい場合まとめdynamoid の導入方法については以前書いたこちらの記事を参考にしてみて下さい。tech.feedforce.jpGlobal Secondary Index (GSI) ってなんぞ今回も名称の整理をしておきます文中に Hash Key やら Range Key という名称が出てきますが、現在は名称が異なります。しかし、 dyanmoid では相変わらず旧名称のまま (hash_key, range_key) でパラメータを指定するので、今回も最初に対応表を記載しておきます。 旧名称 現名称 Hash Key Partition Key Range Key Sort Key GSI は検索のためのインデックスDynamoDB にはプライマリキーの指定方法として、単一の Partition Key を使用する方法と、Partition Key と Sort Key を組み合わせて使用する方法があります。これについては前回の【range 編】の記事でも触れました。developer.feedforce.jpプライマリキーに指定されたカラムに対してであれば、レコードの抽出や範囲検索などが実行可能となる訳ですが、プライマリキーに指定されていないカラムに対しては検索が実行できず、テーブルのフルスキャンを実行することになってしまい非効率です。そこで、別のカラムに対しても検索を行いたい場合は GSI を設定して、フルスキャンすることなく効率的にデータを抽出できるようにします。 GSI もプライマリキーの指定と同様に、単一の Partition Key のみで指定することも、 Partition Key と Sort Key の組み合わせで指定することも可能です。ただし、 プライマリキーにはユニーク制約が設定されますが、 GSI にはユニーク制約が存在しない ので、その点には注意が必要です。Local Secondary Index (LSI) もあるやでLSI の Partition Key はプライマリキーと共通です。Sort Key の部分だけ別に設定したい場合に使用します。その点を除けば GSI とよく似ていますが、こちらはテーブルの作成時にしか定義することができないようです。 なお、LSI もdynamoid から指定することは可能 (local_secondary_index を使用する) ですが、本稿では触れません。どういう用途で便利なのかあまり複雑なテーブル設計が推奨されない DynamoDB ですが、簡単なテーブル間の関連付けを行いたいシーンが出てきます。親テーブルの ID を結合キーとして子テーブルに設定したい場合などに GSI は便利です。以下に User Table と User Comment Table の例を示します。User Comment Table には親テーブルである User Table の ID が GSI の Partition Key として設定してあります。また、コメントの投稿日時 (Posted at) を GSI の Sort Key として設定しています。これで User 毎に投稿日時順にソートしたコメントを取得することができるようになります。User Table ID name 1 John 2 Marry 3 Taro User Comment Table ID (Primary Partition Key) User ID (GSI Partition Key) Posted at (GSI Sort Key) Comment 1 1 1509529916 Hello 2 1 1509530052 I am John 3 1 1509530085 How do you do? 4 2 1509523925 Thanks a lot! 5 3 1509527628 こんにちは 6 3 1509527101 どうも ちなみに、プライマリキーと GSI を逆に設定してもほぼ成立するのですが、前述したように GSI にはユニーク制約が存在しないので、User Comment Table では ID をプライマリキーとして、重複が生じないように設定してあります。Dynamoid での利用方法テーブル定義ここからは前述の User Table と User Comment Table を dynamoid から利用する例を示していきます。class User include Dynamoid::Document table name: :users, key: :id field :name, :string # 現在のユーザーに紐付くコメントを作成する def create_comment!(attributes = {}) attributes[:user_id] = id UserComment.new(attributes).tap(&:save!) end # 現在のユーザーのコメント一覧を取得する def comments UserComment.where(user_id: id) end # 現在のユーザーの最終コメントを取得する def latest_comment comments.scan_index_forward(false).scan_limit(1).all.first endendclass UserComment include Dynamoid::Document table name: :user_comments, key: :id field :user_id, :string field :posted_at, :datetime global_secondary_index hash_key: :user_id, range_key: :posted_at, projected_attributes: :allend※ ちなみに dynamoid には has_many を利用して関連テーブルを実現する方法があるのですが、結合キーを親テーブルに持つ設計になるのがあまり好ましくなかったので、自前で実装しています。いくつか注意する点があって、 global_secondary_index で使用する hash_key と range_key は field で定義されている必要があります。また、 projected_attributes: :all というオプションをつけないと後述の #where でインデックスを利用した検索が行われません。一旦これが無い状態でリリースとしてしまうと、射影される属性が限定された GSI が作成されてしまい、実行時にエラーになります。その場合は AWS マネジメントコンソールから直接 GSI を作り直す羽目になりますのでご注意ください 🙏One or more parameter values were invalid: Select type ALL_ATTRIBUTES is not supported for global secondary index#where を使えば GSI を使って自動的にクエリで検索してくれる#comments というメソッドの中で #where を使用した検索が登場しますが、 GSI が設定されていれば特別な記述がなくとも自動的にクエリ検索が行われます。UserComment.where(user_id: id)# => [#<UserComment:0x00007f44c86183e8>, ...]前述の通り projected_attributes: :all が指定されていないとフルスキャンされてしまうのでご注意ください。昇順・降順を入れ替えたい場合#latest_comment というメソッド内で使用していますが、 #scan_index_forward(false) と指定すると降順でソートされた状態で結果が返ってきます。未指定の場合は昇順でソートされます。また、 #scan_limit(n) と指定することで、先頭から n 件の結果に限定して取得が可能です。#latest_comment ではこれらを組み合わせて最終のコメントを取得しています。まとめ本稿では GSI と LSI とプライマリキーの違い、具体的な利用用途を紹介しました。前回の記事でも触れましたが、 dynamoid は初回実行時にテーブルや GSI が存在していないと作成する、という挙動になるため、後で設計を変えたくなった場合に GSI や最悪テーブルを作り直す羽目になります。特に初めて利用する場合は設計の勘所を掴むのが難しいので、リリース前に入念に設計を見直すことをお勧めします。その点では RDS 以上に慎重な設計が求められるように感じています。色々と気を付けなければならない点も多いですが、並列動作性は非常に高いので、利用したくなるシーンが必ず出てくると思います。その際に本稿が少しでもお役に立てば幸いです 🙏

Dynamoid の使い方【global_secondary_index 編】

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

先日のおとうふ先生の記事にもあったように、<a href="http://tokyo.serverlessconf.io/">Serverlessconf Tokyo 2017</a> というイベントが都内で開催されておりました。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2017%2F11%2F02%2F221452" title="Serverlessconf Tokyo 2017 で IBM Cloud Functions のアツい話を聞いてきた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://developer.feedforce.jp/entry/2017/11/02/221452">developer.feedforce.jp</a></cite>

11/3(金) のメインカンファレンスには弊社からも5名ほど参加しており、みんな大学生の頃の100倍くらい意識高く勉強して参りました ✌︎('ω')✌︎
お昼ご飯に弁当出たのが嬉しかったです ✌︎('ω')✌︎
あと、馴染みあるメンツでカンファレンス行くと、終わってから飲みに行けるのも良いですね ✌︎('ω')✌︎

さて、今回の記事では当日の発表内容についていくつかダイジェストと感想を書いていきたいと思います。

スライドはこちらのサイトでまとめられているようで大変助かります 🙏

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fwww.n-novice.com%2Fentry%2F2017%2F11%2F03%2F240000" title="Serverlessconf Tokyo 2017 公開資料 - にわかエンジニア好きなことを書く備忘録" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://www.n-novice.com/entry/2017/11/03/240000">www.n-novice.com</a></cite>

<h1>サーバレスアーキテクチャによる時系列データベースの構築と監視</h1>

<script async class="speakerdeck-embed" data-id="c1e5e041140945188ca5b0de4ee32f34" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>


<ul>
<li>Mackerel という監視サービスをどのように監視・管理しているのか、というお話</li>
<li>時系列データベースの構成

<ul>
<li>Kinesis Streams へ保存</li>
<li>Lambda で Redis へ保存</li>
<li>Redis に一定件数溜まったら DynamoDB へ保存

<ul>
<li>一度 Redis を挟んでいるのは書き込みコストを抑えるため</li>
</ul>
</li>
<li>DyanmoDB の TTL を超えるデータは S3 へ保存</li>
</ul>
</li>
<li>データの参照性に合わせて書き込み先を変更しているのはナルホド</li>
<li>監視についてまとめ

<ul>
<li>メトリックを可視化して眺めよう</li>
<li>監視の基礎は平常状態を知ること</li>
<li>系全体の可用性を監視しよう</li>
</ul>
</li>
</ul>


Serverless を使った具体的な設計例として、とても参考になります。
時系列データベースの実装として、複数のストレージを上手く組み合わせて設計されているのは色々なシーンで応用できる設計例ではないでしょうか。

<h1>Java チームが選択したTypeScript による AWS Lambda 開発</h1>

<a href="http://riotz.works/slides/?2017-serverless-conf">Slides | Riotz Works</a>

<ul>
<li>固定 IP を実現するには VPC lambda が必要

<ul>
<li>VPC の lambda はすごく遅い</li>
<li>固定 IP に対する需要は現在も一定数あるようなので。。。（日本では特に）</li>
</ul>
</li>
<li>マイクロ化が過剰で複雑になった

<ul>
<li>どの程度の粒度でサービスを切り分けていくか、というのは相変わらずセンスが問われるな、という印象</li>
</ul>
</li>
<li>言語毎に実行速度がずいぶん違う

<ul>
<li>一度 Java で実装して、スピードが出ずに TypeScript で実装し直した

<ul>
<li>Java は初回実行時はオーバーヘッドが大きい</li>
<li>バッチ処理のように計算量が多い処理であれば Java の方が速いようです</li>
<li>AWS Lambdaの処理性能を言語毎に測ってみた

<ul>
<li><a href="http://acro-engineer.hatenablog.com/entry/2016/08/02/120000">http://acro-engineer.hatenablog.com/entry/2016/08/02/120000</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>


<h1>Serverlessの世界に特別なことなんて何もなかった</h1>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fslideship.com%2Fusers%2F%40marcy-terui%2Fpresentations%2F2017%2F11%2F5vUYExsSUrPbyjyjKA7J99%2F" title="The mind of Serverless as a Software - Serverlessの世界に特別なことなんて何もなかった -" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://slideship.com/users/@marcy-terui/presentations/2017/11/5vUYExsSUrPbyjyjKA7J99/">slideship.com</a></cite>

<ul>
<li>Serverless でよくある課題と解決

<ul>
<li>Functionの適切な分割・統合</li>
<li>Functionやサービス間のデータの受け渡し</li>
<li>外部サービスの呼び出しとエラーハンドリング</li>
<li>テスト</li>
</ul>
</li>
<li>スライドに色々な Tips が詳しく書かれているので一読すると吉

<ul>
<li>ただ、紹介されている方法だと Lambda Function の粒度がかなり細かくなるので、その辺の管理は大丈夫なのか気になりました</li>
<li>マイクロ化しすぎ問題とかは大丈夫でしょうか？</li>
</ul>
</li>
<li>どういうサービスが Serverless に向いているのか、という話も出てくるので参考になります

<ul>
<li>個人的には特性を押さえた上で、従来の Rails のようなアプリケーションと Serverless をハイブリッドに組み合わせて使うのが良いと考えています</li>
</ul>
</li>
</ul>


<h1>Serverlessとか言う前に知ってほしいDBのこと</h1>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fslideship.com%2Fusers%2F%40marcy-terui%2Fpresentations%2F2017%2F11%2FNV8cP63mxs1tLw4qkct7Xd%2F" title="Serverlessとか言う前に知ってほしいDBのこと" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://slideship.com/users/@marcy-terui/presentations/2017/11/NV8cP63mxs1tLw4qkct7Xd/">slideship.com</a></cite>

<ul>
<li>一個前のと同じ登壇者の方

<ul>
<li>こちらは DB についての tips</li>
<li>いい感じに煽られていたので、来週弊社で開催される <a href="http://developer.feedforce.jp/entry/2017/11/02/190000">LT大会</a> でもこんな感じのノリを期待しています ✌︎('ω')✌︎

<ul>
<li><a href="http://developer.feedforce.jp/entry/2017/11/02/190000">&#x793E;&#x5185;LT&#x5927;&#x4F1A;&#x6E96;&#x5099;&#x4E2D; - Feedforce Developer Blog</a></li>
</ul>
</li>
</ul>
</li>
<li>非同期で並列数を制限すれば RDS を Lambda から利用しても問題ない

<ul>
<li>同時接続数が爆発しないように調整して使えば OK

<ul>
<li>Lambda から RDS を使ってはいけない、というのがセオリーだったので、使えると言い切る人がいたのはインパクトあった</li>
<li>まあ確かに。例えば AWS Aurora の db.r3.large だと 最大接続数が 1,000 ある

<ul>
<li><a href="http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Managing.html#Aurora.Managing.MaxConnections">http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Managing.html#Aurora.Managing.MaxConnections</a></li>
</ul>
</li>
<li>同時に 1,000 を超える Lambda が実行されなければ理屈の上では大丈夫なはず</li>
<li>用法用量を守って正しくお使いください、というやつか。。</li>
</ul>
</li>
</ul>
</li>
<li>DynamoDB でフルスキャンしたら負け

<ul>
<li>この辺は最近自分でも勉強していたので再確認しながら聞いていました（宣伝）</li>
</ul>
</li>
</ul>


<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2017%2F11%2F04%2F235323" title="Dynamoid の使い方【range 編】 - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://developer.feedforce.jp/entry/2017/11/04/235323">developer.feedforce.jp</a></cite>

<h1>真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用</h1>

<script async class="speakerdeck-embed" data-id="100ed8972466451a8fab9450e51bb0c6" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>


他の発表と被ってしまったので、当日の講演は見られなかったのですが、ブログの方を見たらとても興味深い内容だったのでご紹介しておきます🙏

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fgs2.hatenablog.com%2Fentry%2F2017%2F11%2F04%2F013215" title="Serverlessconf Tokyo 2017 に登壇しました。そのほか雑感 - GS2 Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://gs2.hatenablog.com/entry/2017/11/04/013215">gs2.hatenablog.com</a></cite>

<blockquote>実は、私もSaaSはサーバレスなのか？という事に対しては、ちょっと思うところがあります。
私はフルマネージドサービスはサーバレスだと思いますが、マネージドサービスはサーバレスではない。と思っているためです。
また、別の言い方をすると、スケールに限界があるモノはサーバレスではない。と思っています。
つまり、使用方法さえ間違えなければ《勝手に》《無限に》スケールするフルマネージドサービスこそがサーバレス。と言えるのではないか。と思っています。</blockquote>

SaaS の運用・開発してる人だと結構重要なテーマなのではないか、と思います。
SaaS なんだからリクエストどんだけ送っても向こう側で良きに計らってくれるやろ。そう思ってた時期が俺にもありました 😇
とは言え、SaaS 利用者からそう見えるようなサービスにしたい、という思いはあります。SaaS 利用者としても SaaS の裏側のことは一切考えずに利用したいと思うので。。
弊社の <a href="https://socialplus.jp/">ソーシャル PLUS</a> も SaaS ですが、利用して頂いているサイトがイベントなどでアクセスが急騰するケースがありますので、開発・運用ではそういう点に気を遣っています。

<ul>
<li>コールドスタート対策

<ul>
<li>コールドスタートとは

<ul>
<li>Lambda は初回呼び出し時やしばらく呼ばれなかった後に呼ばれたときは response time が長くなる</li>
</ul>
</li>
<li>1 つの Lambda Function に全ロジックを入れる

<ul>
<li>API Gateway のエンドポイント毎にどのロジックを実行するかパラメータで渡している</li>
<li>コール比率の低いエンドポイントでもコールドスタートを回避できる</li>
</ul>
</li>
<li>パラメータで動作が変わる

<ul>
<li>Rails の Routing のようなものと佐藤は解釈しました</li>
</ul>
</li>
<li>一定間隔で Lambda を起こすように Invoke させる方法もあるが、個人的には Routing やらせる方式の方が良いのではないか、という気がする

<ul>
<li>Lambda Function が大量に作られてしまう（マイクロ化しすぎ問題）と管理が難しくなるのではないか、という思いもあって</li>
<li>この方法は実際に試してみたいです</li>
</ul>
</li>
</ul>
</li>
</ul>


<h1>所感</h1>

Serverless に限ったことではありませんが、近年登場する新技術はトレードオフな側面が強いように感じています。
一昔前は今までは解の無かった技術的課題を解決する形で新しい技術が登場する、というケースが多かったのではないでしょうか？
対して今は、既存の技術でもできなくはないけど、特定のケースで困るから、それを解決する新しい技術が登場する、というケースが多いような。
そして、その特定のケースを解決するために、一部のことは許容しなければならない、という印象です。
（まあ単純に僕も歳をとって、保守的な考え方が強くなってきただけなのかもしれません。。）

今回のカンファレンスは実際の開発者からどういうトレードオフがあるか、という話が出てきたことで、自分の中で改めて Serverless と向き合う覚悟というか、モチベーションが出てきたように思います。

とはいえ、個人的には、従来の Rails アプリと Serverless をハイブリッドに使った設計に取り組んでいくのが現時点での最適解ではないかと感じています。
もちろん、設計を考えた上で Full-Serverless が最適となれば、そういうアプリを作って行くつもりですが、それなりに複雑なロジックを考えるにはまだ Full-Serverless は早いのではないかな、と思います。
やはり並列性の高さが Serverless の魅力なので、アプリケーションの基本的な部分は従来通り Rails で作成して、アクセス数が急にスパイクするような場所を局所的に Serverless にするような設計をこれから色々試していこうと考えています。

ただ、Serverless のコンセプトとしては、ソフトウェア開発の生産性そのものを向上させることが目的とのことだったので、将来的にはハイブリッドよりも Serverless に振り切った設計がベストになっていくかもしれません。今後の発展に期待しています。

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎先日のおとうふ先生の記事にもあったように、Serverlessconf Tokyo 2017 というイベントが都内で開催されておりました。developer.feedforce.jp11/3(金) のメインカンファレンスには弊社からも5名ほど参加しており、みんな大学生の頃の100倍くらい意識高く勉強して参りました ✌︎('ω')✌︎お昼ご飯に弁当出たのが嬉しかったです ✌︎('ω')✌︎あと、馴染みあるメンツでカンファレンス行くと、終わってから飲みに行けるのも良いですね ✌︎('ω')✌︎さて、今回の記事では当日の発表内容についていくつかダイジェストと感想を書いていきたいと思います。スライドはこちらのサイトでまとめられているようで大変助かります 🙏www.n-novice.comサーバレスアーキテクチャによる時系列データベースの構築と監視Mackerel という監視サービスをどのように監視・管理しているのか、というお話時系列データベースの構成Kinesis Streams へ保存Lambda で Redis へ保存Redis に一定件数溜まったら DynamoDB へ保存一度 Redis を挟んでいるのは書き込みコストを抑えるためDyanmoDB の TTL を超えるデータは S3 へ保存データの参照性に合わせて書き込み先を変更しているのはナルホド監視についてまとめメトリックを可視化して眺めよう監視の基礎は平常状態を知ること系全体の可用性を監視しようServerless を使った具体的な設計例として、とても参考になります。時系列データベースの実装として、複数のストレージを上手く組み合わせて設計されているのは色々なシーンで応用できる設計例ではないでしょうか。Java チームが選択したTypeScript による AWS Lambda 開発Slides | Riotz Works固定 IP を実現するには VPC lambda が必要VPC の lambda はすごく遅い固定 IP に対する需要は現在も一定数あるようなので。。。（日本では特に）マイクロ化が過剰で複雑になったどの程度の粒度でサービスを切り分けていくか、というのは相変わらずセンスが問われるな、という印象言語毎に実行速度がずいぶん違う一度 Java で実装して、スピードが出ずに TypeScript で実装し直したJava は初回実行時はオーバーヘッドが大きいバッチ処理のように計算量が多い処理であれば Java の方が速いようですAWS Lambdaの処理性能を言語毎に測ってみたhttp://acro-engineer.hatenablog.com/entry/2016/08/02/120000Serverlessの世界に特別なことなんて何もなかったslideship.comServerless でよくある課題と解決Functionの適切な分割・統合Functionやサービス間のデータの受け渡し外部サービスの呼び出しとエラーハンドリングテストスライドに色々な Tips が詳しく書かれているので一読すると吉ただ、紹介されている方法だと Lambda Function の粒度がかなり細かくなるので、その辺の管理は大丈夫なのか気になりましたマイクロ化しすぎ問題とかは大丈夫でしょうか？どういうサービスが Serverless に向いているのか、という話も出てくるので参考になります個人的には特性を押さえた上で、従来の Rails のようなアプリケーションと Serverless をハイブリッドに組み合わせて使うのが良いと考えていますServerlessとか言う前に知ってほしいDBのことslideship.com一個前のと同じ登壇者の方こちらは DB についての tipsいい感じに煽られていたので、来週弊社で開催される LT大会 でもこんな感じのノリを期待しています ✌︎('ω')✌︎社内LT大会準備中 - Feedforce Developer Blog非同期で並列数を制限すれば RDS を Lambda から利用しても問題ない同時接続数が爆発しないように調整して使えば OKLambda から RDS を使ってはいけない、というのがセオリーだったので、使えると言い切る人がいたのはインパクトあったまあ確かに。例えば AWS Aurora の db.r3.large だと 最大接続数が 1,000 あるhttp://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Managing.html#Aurora.Managing.MaxConnections同時に 1,000 を超える Lambda が実行されなければ理屈の上では大丈夫なはず用法用量を守って正しくお使いください、というやつか。。DynamoDB でフルスキャンしたら負けこの辺は最近自分でも勉強していたので再確認しながら聞いていました（宣伝）developer.feedforce.jp真のサーバレスアーキテクトとサーバレス時代のゲーム開発・運用他の発表と被ってしまったので、当日の講演は見られなかったのですが、ブログの方を見たらとても興味深い内容だったのでご紹介しておきます🙏gs2.hatenablog.com実は、私もSaaSはサーバレスなのか？という事に対しては、ちょっと思うところがあります。私はフルマネージドサービスはサーバレスだと思いますが、マネージドサービスはサーバレスではない。と思っているためです。また、別の言い方をすると、スケールに限界があるモノはサーバレスではない。と思っています。つまり、使用方法さえ間違えなければ《勝手に》《無限に》スケールするフルマネージドサービスこそがサーバレス。と言えるのではないか。と思っています。SaaS の運用・開発してる人だと結構重要なテーマなのではないか、と思います。SaaS なんだからリクエストどんだけ送っても向こう側で良きに計らってくれるやろ。そう思ってた時期が俺にもありました 😇とは言え、SaaS 利用者からそう見えるようなサービスにしたい、という思いはあります。SaaS 利用者としても SaaS の裏側のことは一切考えずに利用したいと思うので。。弊社の ソーシャル PLUS も SaaS ですが、利用して頂いているサイトがイベントなどでアクセスが急騰するケースがありますので、開発・運用ではそういう点に気を遣っています。コールドスタート対策コールドスタートとはLambda は初回呼び出し時やしばらく呼ばれなかった後に呼ばれたときは response time が長くなる1 つの Lambda Function に全ロジックを入れるAPI Gateway のエンドポイント毎にどのロジックを実行するかパラメータで渡しているコール比率の低いエンドポイントでもコールドスタートを回避できるパラメータで動作が変わるRails の Routing のようなものと佐藤は解釈しました一定間隔で Lambda を起こすように Invoke させる方法もあるが、個人的には Routing やらせる方式の方が良いのではないか、という気がするLambda Function が大量に作られてしまう（マイクロ化しすぎ問題）と管理が難しくなるのではないか、という思いもあってこの方法は実際に試してみたいです所感Serverless に限ったことではありませんが、近年登場する新技術はトレードオフな側面が強いように感じています。一昔前は今までは解の無かった技術的課題を解決する形で新しい技術が登場する、というケースが多かったのではないでしょうか？対して今は、既存の技術でもできなくはないけど、特定のケースで困るから、それを解決する新しい技術が登場する、というケースが多いような。そして、その特定のケースを解決するために、一部のことは許容しなければならない、という印象です。（まあ単純に僕も歳をとって、保守的な考え方が強くなってきただけなのかもしれません。。）今回のカンファレンスは実際の開発者からどういうトレードオフがあるか、という話が出てきたことで、自分の中で改めて Serverless と向き合う覚悟というか、モチベーションが出てきたように思います。とはいえ、個人的には、従来の Rails アプリと Serverless をハイブリッドに使った設計に取り組んでいくのが現時点での最適解ではないかと感じています。もちろん、設計を考えた上で Full-Serverless が最適となれば、そういうアプリを作って行くつもりですが、それなりに複雑なロジックを考えるにはまだ Full-Serverless は早いのではないかな、と思います。やはり並列性の高さが Serverless の魅力なので、アプリケーションの基本的な部分は従来通り Rails で作成して、アクセス数が急にスパイクするような場所を局所的に Serverless にするような設計をこれから色々試していこうと考えています。ただ、Serverless のコンセプトとしては、ソフトウェア開発の生産性そのものを向上させることが目的とのことだったので、将来的にはハイブリッドよりも Serverless に振り切った設計がベストになっていくかもしれません。今後の発展に期待しています。

Serverlessconf Tokyo 2017 に参加してきました

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎

最近こうして <a href="http://developer.feedforce.jp/entry/2017/10/12/100000">弊社の tech ブログが移転した</a> 訳ですが、自社で管理してるブログだと投稿フローがめんどくさいと僕がボヤいたのが移転理由の一端だったりします 😎
でも移転作業したのは僕じゃなくて、球だけ投げてどっか行きました 😎
移転ありがとうございます 🙇

移転して一発目の投稿なので張り切って参ります 💪

さて、Rails で DynamoDB を利用する際の ORM として <code>dynamoid</code> があります。
今回は <code>dynamoid</code> から Hash-Range Table (Partition Key と Sort Key の複合) を利用する方法について紹介します。

<code>dynamoid</code> の導入方法については以前書いたこちらの記事を参考にしてみて下さい。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Ftech.feedforce.jp%2Fdynamodb-setup-on-rails.html" title="DynamoDB を Rails で使えるようにするためのあれこれ | feedforce Engineers&#39; blog" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://tech.feedforce.jp/dynamodb-setup-on-rails.html">tech.feedforce.jp</a></cite>

<h1>Hash-Range Table ってなんぞ</h1>

<h2>その前に名称の整理をしておきます</h2>

タイトルに 【range 編】と書いているのですが、これは Sort Key の事を指します。
どうやら DynamoDB は初期の頃と現在で一部の名称が変化したようです。
しかし、 <code>Dyanmoid</code> では相変わらず旧名称のまま (<code>hash_key</code>, <code>range_key</code>) でパラメータを指定するので、対応表を記載しておきます。

<table>
<thead>
<tr>
<th style="text-align:center;"> 旧名称 </th>
<th style="text-align:center;"> 現名称 </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center;"> Hash Key </td>
<td style="text-align:center;"> Partition Key </td>
</tr>
<tr>
<td style="text-align:center;"> Range Key </td>
<td style="text-align:center;"> Sort Key </td>
</tr>
</tbody>
</table>


<h2>DyanmoDB には 2 種類のプライマリキーがある</h2>

こちらのスライドが分かりやすいのですが、 DynamoDB のテーブル定義として Hash Table と Hash-Range Table というものがあります。

<iframe src="//www.slideshare.net/slideshow/embed_code/key/gHjtA6AS8rk0sB?startSlide=24" width="595" height="485" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"> </iframe>




<iframe src="//www.slideshare.net/slideshow/embed_code/key/gHjtA6AS8rk0sB?startSlide=26" width="595" height="485" style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"> </iframe>


<ul>
<li>Hash Table

<ul>
<li>Hash Key (Partition Key) という一つのカラムの値でプライマリキーを表現するテーブル</li>
<li>この構成だと Hash Key は 重複させることができない</li>
</ul>
</li>
<li>Hash-Range Table

<ul>
<li>Hash Key と Range Key (Partition Key, Sort Key) の二つの値でプライマリキーを表現する</li>
<li>Range Key が異なっていれば、同一の Hash Key を持つレコードが複数存在しても良い</li>
<li>スキャンより高速なクエリ <a href="#fn:1" rel="footnote">1</a> で複数のレコードを取得することが可能

<ul>
<li>スキャンだと物凄くコストが高いので、基本的にクエリだけでデータ取得できるように設計すべき</li>
</ul>
</li>
<li>Range Key での昇順・降順でのソートが可能</li>
<li>Range Key に対しての <a href="http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Query.html#Query.KeyConditionExpressions">範囲検索</a> も可能</li>
</ul>
</li>
</ul>


<h1><code>dynamoid</code> での利用方法</h1>

<h2>テーブル定義</h2>

<pre class="code" data-lang="" data-unlink>class User
 include Dynamoid::Document

 table name: :users, key: :hash_key
 range :range_key, :string # &lt;= これ
end</pre>


<code>range :(フィールド名), :(データ型)</code> で Range Key の定義が可能です。
ちょっと試せていないのですが、AWS コンソールからだとテーブル作成時にしか Range Key (ソートキー) を定義できないので、既に存在しているテーブルに途中で <code>range</code> の定義を加えても動作しないと思います。

<h2>使い方</h2>

Dynamoid にも ActiveRecord と同じように <code>#where</code> というメソッドが実装されています。
ドキュメントでは内部でどのような動きをするのかが見当たらなかったので、実装から確認したのですが、検索条件に Hash Key や Range Key が含まれているかどうかを判断して、クエリが使える場合はクエリで検索してくれるようです。

<pre class="code" data-lang="" data-unlink>User.where(hash_key: &#39;hash_key&#39;) # クエリで検索される
User.where(hash_key: &#39;hash_key&#39;, range_key: &#39;range_key&#39;) # クエリで検索される
User.where(name: &#39;name&#39;) # Hash Key が無いのでスキャンが実行される</pre>


ただし、引数の指定方法や定義の仕方が少しでも間違っていると <code>#where</code> でスキャンが実行されてしまっているケースがあります。本当にクエリ検索されているか、念のため Rails のログ出力を確認し、スキャンが実行されていないかどうか確認するようにして下さい ⚠️

<code>#where</code> の使い方は ActiveRecord とほぼ同じです。

<pre class="code" data-lang="" data-unlink>User.where(hash_key: &#39;hash_key&#39;).all # =&gt; [#&lt;User:0x000000076ed848&gt;, #&lt;User:0x0000000779abb0&gt;, ...]
User.where(hash_key: &#39;hash_key&#39;).each do |user|
 user # =&gt; #&lt;User:0x000000076ed848&gt;
end
User.where(hash_key: &#39;hash_key&#39;).first # =&gt; #&lt;User:0x000000048cb050&gt;
User.where(hash_key: &#39;hash_key&#39;).last # =&gt; #&lt;User:0x000000048cb050&gt;</pre>


そして、 <code>range_key</code> に対して <code>gt</code>, <code>lt</code>, <code>gte</code>, <code>lte</code>, <code>begins_with</code>, <code>between</code> の演算子が使用できます。

<pre class="code" data-lang="" data-unlink>User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.gt&#39;: 123)
User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.lt&#39;: 123)
User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.gte&#39;: 123)
User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.lte&#39;: 123)
User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.begins_with&#39;: &#39;range_&#39;)
User.where(hash_key: &#39;hash_key&#39;, &#39;range_key.between&#39;: [100, 200])</pre>


<h2>ハマりポイント</h2>

ここからは Range Key を <code>dyanmoid</code> を使っていてハマった点をいくつか紹介したいと思います。

<h3><code>range</code> を定義していると <code>#find_by_id</code> の動作が変わる</h3>

<pre class="code" data-lang="" data-unlink># Hash Table として利用
class User
 include Dynamoid::Document

 table name: :users, key: :hash_key
end

# OK!
User.find_by_id(&#39;hash_key&#39;)
# =&gt; #&lt;User:0x000000048cb050&gt;</pre>




<pre class="code" data-lang="" data-unlink># Hash-Range Table として利用
class User
 include Dynamoid::Document

 table name: :users, key: :hash_key
 range :range_key, :string
end

# Error!
User.find_by_id(&#39;hash_key&#39;)
# =&gt; Aws::DynamoDB::Errors::ValidationException: The provided key element does not match the schema</pre>


んん？？ってなったのですが、こういう事らしいです。

<ul>
<li><code>#find_by_id</code> は内部的には <code>Aws::DynamoDB::Client#get_item</code> を呼び出している</li>
<li><code>#get_item</code> は結果が一意に定まる検索条件を指定しないとエラーになる

<ul>
<li>つまり <code>range_key (primary sort key)</code> を定義している場合は引数一つだとエラー</li>
<li>引数に <code>range_key</code> を指定すれば OK</li>
</ul>
</li>
</ul>


<pre class="code" data-lang="" data-unlink>Line::User.find_by_id(&#39;hash_key&#39;, range_key: &#39;range_key&#39;)
# =&gt; #&lt;User:0x000000048cb050&gt;
# OK!</pre>


<h3><code>has_many</code> は Hash-Range Table に対応していない</h3>

<code>dynamoid</code> では ActiveRecord のような <code>has_many</code> <code>has_one</code> <code>belongs_to</code> が定義されているのですが、 Hash-Range Table だと上手く動作しません。
内部の実装を見てみましたが、 Hash Table の状態で利用することが前提となっているようでした。

Hash Table であればこんな感じで利用することができます。

<pre class="code" data-lang="" data-unlink>class User
 include Dynamoid::Document

 table name: :users, key: :hash_key
 has_many :talks, class: Talk
end

class Talk
 include Dynamoid::Document

 table name: :talks, key: :hash_key
 belongs_to :user, class: User
end

user = User.create(name: &#39;Taro&#39;)
user.talks.create(content: &#39;Hello world&#39;)</pre>


<h1>まとめ</h1>

Hash Table と Hash-Range Table の違いから、 Dynamoid における実装方法についてを紹介しました。
Dynamoid を利用した場合は migration を明示的に実行する訳ではないため、Rails のソースコードと DyanmoDB のテーブルの実態が必ずしも一致していないケースがある点がハマりどころのような気がします。
本稿で紹介した Hash-Range Table が DynamoDB と Dynamoid 両方で正しく設定されているかをリリース前に入念にチェックした方が良いでしょう。
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<a href="http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/QueryAndScanGuidelines.html">クエリとスキャンのベストプラクティクス</a><a href="#fnref:1" rev="footnote">&#8617;</a></li>
</ol>
</div>

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎最近こうして 弊社の tech ブログが移転した 訳ですが、自社で管理してるブログだと投稿フローがめんどくさいと僕がボヤいたのが移転理由の一端だったりします 😎でも移転作業したのは僕じゃなくて、球だけ投げてどっか行きました 😎移転ありがとうございます 🙇移転して一発目の投稿なので張り切って参ります 💪さて、Rails で DynamoDB を利用する際の ORM として dynamoid があります。今回は dynamoid から Hash-Range Table (Partition Key と Sort Key の複合) を利用する方法について紹介します。dynamoid の導入方法については以前書いたこちらの記事を参考にしてみて下さい。tech.feedforce.jpHash-Range Table ってなんぞその前に名称の整理をしておきますタイトルに 【range 編】と書いているのですが、これは Sort Key の事を指します。どうやら DynamoDB は初期の頃と現在で一部の名称が変化したようです。しかし、 Dyanmoid では相変わらず旧名称のまま (hash_key, range_key) でパラメータを指定するので、対応表を記載しておきます。 旧名称 現名称 Hash Key Partition Key Range Key Sort Key DyanmoDB には 2 種類のプライマリキーがあるこちらのスライドが分かりやすいのですが、 DynamoDB のテーブル定義として Hash Table と Hash-Range Table というものがあります。 Hash TableHash Key (Partition Key) という一つのカラムの値でプライマリキーを表現するテーブルこの構成だと Hash Key は 重複させることができないHash-Range TableHash Key と Range Key (Partition Key, Sort Key) の二つの値でプライマリキーを表現するRange Key が異なっていれば、同一の Hash Key を持つレコードが複数存在しても良いスキャンより高速なクエリ 1 で複数のレコードを取得することが可能スキャンだと物凄くコストが高いので、基本的にクエリだけでデータ取得できるように設計すべきRange Key での昇順・降順でのソートが可能Range Key に対しての 範囲検索 も可能dynamoid での利用方法テーブル定義class User include Dynamoid::Document table name: :users, key: :hash_key range :range_key, :string # <= これendrange :(フィールド名), :(データ型) で Range Key の定義が可能です。ちょっと試せていないのですが、AWS コンソールからだとテーブル作成時にしか Range Key (ソートキー) を定義できないので、既に存在しているテーブルに途中で range の定義を加えても動作しないと思います。使い方Dynamoid にも ActiveRecord と同じように #where というメソッドが実装されています。ドキュメントでは内部でどのような動きをするのかが見当たらなかったので、実装から確認したのですが、検索条件に Hash Key や Range Key が含まれているかどうかを判断して、クエリが使える場合はクエリで検索してくれるようです。User.where(hash_key: 'hash_key') # クエリで検索されるUser.where(hash_key: 'hash_key', range_key: 'range_key') # クエリで検索されるUser.where(name: 'name') # Hash Key が無いのでスキャンが実行されるただし、引数の指定方法や定義の仕方が少しでも間違っていると #where でスキャンが実行されてしまっているケースがあります。本当にクエリ検索されているか、念のため Rails のログ出力を確認し、スキャンが実行されていないかどうか確認するようにして下さい ⚠️#where の使い方は ActiveRecord とほぼ同じです。User.where(hash_key: 'hash_key').all # => [#<User:0x000000076ed848>, #<User:0x0000000779abb0>, ...]User.where(hash_key: 'hash_key').each do |user| user # => #<User:0x000000076ed848>endUser.where(hash_key: 'hash_key').first # => #<User:0x000000048cb050>User.where(hash_key: 'hash_key').last # => #<User:0x000000048cb050>そして、 range_key に対して gt, lt, gte, lte, begins_with, between の演算子が使用できます。User.where(hash_key: 'hash_key', 'range_key.gt': 123)User.where(hash_key: 'hash_key', 'range_key.lt': 123)User.where(hash_key: 'hash_key', 'range_key.gte': 123)User.where(hash_key: 'hash_key', 'range_key.lte': 123)User.where(hash_key: 'hash_key', 'range_key.begins_with': 'range_')User.where(hash_key: 'hash_key', 'range_key.between': [100, 200])ハマりポイントここからは Range Key を dyanmoid を使っていてハマった点をいくつか紹介したいと思います。range を定義していると #find_by_id の動作が変わる# Hash Table として利用class User include Dynamoid::Document table name: :users, key: :hash_keyend# OK!User.find_by_id('hash_key')# => #<User:0x000000048cb050># Hash-Range Table として利用class User include Dynamoid::Document table name: :users, key: :hash_key range :range_key, :stringend# Error!User.find_by_id('hash_key')# => Aws::DynamoDB::Errors::ValidationException: The provided key element does not match the schemaんん？？ってなったのですが、こういう事らしいです。#find_by_id は内部的には Aws::DynamoDB::Client#get_item を呼び出している#get_item は結果が一意に定まる検索条件を指定しないとエラーになるつまり range_key (primary sort key) を定義している場合は引数一つだとエラー引数に range_key を指定すれば OKLine::User.find_by_id('hash_key', range_key: 'range_key')# => #<User:0x000000048cb050># OK!has_many は Hash-Range Table に対応していないdynamoid では ActiveRecord のような has_many has_one belongs_to が定義されているのですが、 Hash-Range Table だと上手く動作しません。内部の実装を見てみましたが、 Hash Table の状態で利用することが前提となっているようでした。Hash Table であればこんな感じで利用することができます。class User include Dynamoid::Document table name: :users, key: :hash_key has_many :talks, class: Talkendclass Talk include Dynamoid::Document table name: :talks, key: :hash_key belongs_to :user, class: Userenduser = User.create(name: 'Taro')user.talks.create(content: 'Hello world')まとめHash Table と Hash-Range Table の違いから、 Dynamoid における実装方法についてを紹介しました。Dynamoid を利用した場合は migration を明示的に実行する訳ではないため、Rails のソースコードと DyanmoDB のテーブルの実態が必ずしも一致していないケースがある点がハマりどころのような気がします。本稿で紹介した Hash-Range Table が DynamoDB と Dynamoid 両方で正しく設定されているかをリリース前に入念にチェックした方が良いでしょう。クエリとスキャンのベストプラクティクス↩