こんにちは、山口拓弥（@yamat47）です。

最近、いまさらながら Netflix の梨泰院クラス にハマっています。
勧善懲悪なストーリーはわかりやすく面白いし、見れば見るほどチャミスルが飲みたくなりますね 🍻

https://twitter.com/yamat47/status/1586206595842646016

さて本日は、最近業務で書いた ActiveRecord の scope の実装の話をします。
危うく重大な不具合を含んだままアプリをリリースしそうになったので... 自戒も込めて記事にします...！

不具合を含んでいたコードを早速紹介します
サンプルで扱うモデルの説明
業務のコードをそのまま公開するのは文脈を伝えづらく難しかったので、この記事ではシンプルなまったく別の状況を扱います。
大まかな説明ですが、こんな感じの状況を想定してください：

不特定多数とオンライン対戦ができるような SNS アプリ。
 ユーザーはギルドに所属することができ、このギルド同士で対戦をする。
ユーザーは年齢を登録する必要がある。
 また 18 歳未満のユーザーは保護者による同意を必要とする。

登場するモデル同士の関連付けはこうなっています：

guild has many users.
user has many parentalconsentlogs.

意図しない挙動の自動テストでの再現を含めて、サンプルコードは公開してあります。
参考にしてください：

https://github.com/yamat47/activerecord-or-merge-sample

問題を含んでいたスコープの実装
アプリを利用できるユーザーのリスト、すなわち「年齢が 18 歳以上」もしくは「保護者が同意済み」なユーザーのリストを取得したいとします。
いろいろなところで再利用しそうだったため、モデルに scope として実装しました。

class User puts User.adultorparentalconsented.tosql
SELECT "users".* FROM "users" LEFT OUTER JOIN "parentalconsentlogs" ON "parentalconsentlogs"."userid" = "users"."id" WHERE ("users"."age" >= 18 OR "parentalconsent_logs"."id" IS NOT NULL)
=> nil

他の条件を組み合わせると、その順番によっては意図しない挙動になる
例えば「あるギルドに所属しているユーザーのうちでアプリを利用できる人のリスト」を取得したいとします。
ID が 1 のギルドに所属しているという条件を追加してみるとこのようになります：

irb(main):006:0> puts User.where(guild: 1).adultorparentalconsented.tosql
SELECT "users".* FROM "users" LEFT OUTER JOIN "parentalconsentlogs" ON "parentalconsentlogs"."userid" = "users"."id" WHERE ("users"."guildid" = 1 AND "users"."age" >= 18 OR "parentalconsentlogs"."id" IS NOT NULL)
=> nil

わかりやすくするために WHERE 句だけを取り出したのがこちらです：

WHERE ("users"."guildid" = 1 AND "users"."age" >= 18 OR "parentalconsent_logs"."id" IS NOT NULL)

これは「ギルドの ID が 1 で年齢が 18 歳以上」もしくは「保護者が同意済み」のいずれかの条件を満たすレコードに絞り込みます。
ギルドによる絞り込みが全体に効いてほしかったにも関わらず、最初の条件にしか効きませんでした。

: 正確には RDBMS の実装に依存しますが、このような挙動になるものばかりです。（参考：MySQL の演算子の優先順位、SQLite の演算子の優先順位）

すなわち、保護者が同意済みな他ギルドのユーザーも絞り込んだ結果に含まれてしまいます。
これはまったく意図していない挙動でした...。

ではどうすれば解決できる？
解決策 ① .merge で囲う
記事のタイトル通りですが、スコープの中身全体を .merge で囲うことで解決します。
条件が長くなりすぎないように微調整しつつ、具体的にはこんな感じにします：

: 参考: ActiveRecordのorクエリをscope化する - Qiita

class User puts User.where(guild: 1).adultorparentalconsented.tosql
SELECT "users".* FROM "users" LEFT OUTER JOIN "parentalconsentlogs" ON "parentalconsentlogs"."userid" = "users"."id" WHERE "users"."guildid" = 1 AND ("users"."age" >= 18 OR "parentalconsentlogs"."id" IS NOT NULL)
=> nil

WHERE 句だけを取り出したのがこちら：

WHERE "users"."guildid" = 1 AND ("users"."age" >= 18 OR "parentalconsent_logs"."id" IS NOT NULL)

いい感じに絞り込みの条件を組み立てることができました！

解決策 ② unscoped な条件を渡すのをやめる
ParentalConsentLog.where.not(id: nil) という条件は、それまでに渡された他の条件と切り離された unscoped な条件です。
これをそのまま .or に渡していたことで、ActiveRecord がその条件をうまく解釈できず素朴に連結をしていました。

今回のケースであれば、scoped な状態をもとに組み立てた条件を渡すようにすることでも解決ができます。
具体的にはこちらです：

class User < ApplicationRecord
 scope :adultorparental_consented, lambda {
 leftjoins(:parentalconsent_logs)
 .where(age: 18..)
 .or(where(parentalconsentlogs: { id: nil }))
 }
end

（Rails console の結果などは ① と一緒なので省略します）

まとめ
以上、ActiveRecord のスコープを作るときにハマった課題とその解決策でした。

「他条件と組み合わせたときの挙動」はなかなか単体テストでは検証しづらく、動作確認をしていたときにたまたま気付けた不具合でした。
こういうケースに実装中に気付くにはどうしたらよかったか...
「こんなの試しています」などあれば、Twitter などで気軽に教えていただけると嬉しいです！

クラッソーネでは失敗を周囲にシェアして知見にしてもらうのが好きなエンジニアを大募集しています。
興味ある方はぜひ採用サイトをご覧ください！

https://www.crassone.co.jp/recruit/engineer/

.orを使ってActiveRecordのスコープを定義するときは.mergeで囲わないと意図しない挙動になるかも？

こんにちは、プロダクトマネージャーの山口拓弥（@yamat47）です。

しばらく記事を書かないうちに Rails エンジニアから役割が変わっていました。
この辺りのことは誕生日に書いた記事に書いているので、よければお読みください：

https://blog.yamat47.me/entry/2022/06/02/002443

さて、この記事では Ruby 3 から本格的に導入された型解析の仕組みについて書いてみます。
ただ 遠藤さんのまとめ記事 をはじめとして型解析自体について解説されたものはすでにありますので、実際に試してみた体験談をまとめてみます。

Ruby での型解析って？
Ruby は実行するまで型が決まらない、いわゆる動的型付け言語です。
しかし TypeScript の流行や Python での型注釈記法の導入をはじめとして、動的型付け言語であっても型検査の仕組みを導入するような動きが活発です。
そして Ruby においても、2020 年 12 月にリリースされた Ruby 3.0 にて静的型解析を行う仕組みが導入されました。

Ruby の型解析には RBS Typeprof Steep Sorbet というツールが登場します。
遠藤さんのまとめ記事からの引用ですが、それぞれの役割はこういったものです：

> * RBS: Ruby 3 の型情報を扱う言語を始めとする基盤。Ruby 3 にバンドルされる。
> * TypeProf: 型注釈のない Ruby コードを型解析するツール。Ruby 3 にバンドルされる。現状の主機能は Ruby コードからの RBS スタブ生成。
> * Steep/Sorbet: Ruby の静的型検査器。型注釈を書く必要はあるが、Ruby で静的型の便利なプログラミング体験ができる。IDE での補完やドキュメント表示も。
>
> source: Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ

今回、自作の Gem について Steep を使った型検査の仕組みを導入してみました。
「Ruby の型検査って聞いたことあるけど使ったことないな」という方に参考にしていただけると嬉しいです。

自作の Gem に静的型検査の仕組みを導入してみた
試してみたライブラリの紹介
今回型解析を導入してみたのは yamat47/japaneseaddressparser という Gem です。
以前このブログでもご紹介したことがある、Ruby で日本の住所を解析するためのライブラリです：

https://tech.crassone.jp/posts/introduction-for-japanese-address-parser-gem

このライブラリは JapaneseAddressParser という Module を提供していて、その大まかな使い方はこんな感じです：

.call というインターフェースを持ちます。
address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')

.call の返り値は JapaneseAddressParser::Models::Address というクラスです。
都道府県・市区町村・町域の情報を持っています。
address.class #=> JapaneseAddressParser::Models::Address

JapaneseAddressParser::Models::Address#address は住所のふりがなを表す文字列を返します。
address.furigana #=> "トウキョウトミナトクシバコウエン 4"

とりあえず .rbs ファイルを自動で生成してみる
Steep を使って型解析をするためには、型の情報がまとめられた .rbs ファイルが必要です。
これは Typeprof を使って自動で生成することができます。

bundle exec typeprof lib//.rb spec//spec.rb -o sig/japaneseaddress_parser.rbs

これを使うと、こんな感じの .rbs ファイルが自動で生成されました。

他にもたくさんの定義が出力されていましたが省略しています。
module JapaneseAddressParser
 VERSION: String

 def call: (untyped full_address) -> Models::Address?
 def call!: (untyped full_address) -> Models::Address
 def call: (untyped fulladdress) -> Models::Address
 def self.call: (untyped full_address) -> Models::Address?
 def self.call!: (untyped full_address) -> Models::Address
 def self.call: (untyped fulladdress) -> Models::Address
end

Steep の初期設定をして動かしてみる
RBS を使った型検査には Steep を使います。
bundle exec steep init で初期設定をしつつとりあえず steep check を実行してみると、こんな感じのエラーが出てしまいました：

$ bundle exec steep check
Type checking files:

..................................F...............................

sig/japaneseaddressparser.rbs:18:4: [error] Cannot find type Schmooze::Base
│ Diagnostic ID: RBS::UnknownTypeName
│
└ class NormalizeJapaneseAddressesSchmoozer > sig/schmooze_base.rbs

これで steep check による型検査が実行できるようになりました。

steep check をヒントに型定義やコードを修正していく
自動で生成された型定義は untyped なところも多く、このままではあまり実用性は高くありません。
steep check を頼りに .rbs ファイルやコードを直していきます。

今回はとてもシンプルなインターフェースを持つライブラリを扱ったため、修正箇所はあまりありませんでした。
唯一あったのは Hash のキーを文字列ではなくシンボルにしてしまったときで、Steep がこんなエラーを吐いてくれました：

$ bundle exec steep check
Type checking files:

........................................................................................................................................................F.

spec/japaneseaddressparser_spec.rb:11:37: [error] Cannot pass a value of type ::Symbol as an argument of type ::String
│ ::Symbol <: ::String
│ ::Object <: ::String
│ ::BasicObject <: ::String
│
│ Diagnostic ID: Ruby::ArgumentTypeMismatch
│
└ ::JapaneseAddressParser.call(:hoge)

ちなみに型解析に成功したときはこんな感じの結果が出力されます：

$ bundle exec steep check
Type checking files:

..........................................................................................................................................................

No type error detected. 🍵

修正を繰り返して、最終的にはこんな型定義になりました：

https://github.com/yamat47/japaneseaddressparser/blob/2135210039e3ae6290859b57cfcaa831a963fb4b/sig/japaneseaddressparser.rbs

CI でも型検査を実行する
このライブラリは GitHub Actions を使った CI を設定しています。
せっかくなので、今回準備した型検査も CI で実行するようにしました。

- name: Steep check
run: bundle exec steep check

以上、自作のライブラリに型検査を導入してみた体験談でした。

今後やりたいこと
先日の RubyKaigi 2022 でも言及されていましたが、Ruby にはさまざまな Gem の型定義を集めた gemrbscollection というリポジトリが存在します。
ここにある型定義を RBS から利用することで、Rails のように大量のライブラリに依存するようなプロジェクトでも手間を少なく型検査を実行できるようになります。

https://github.com/ruby/gemrbscollection

しかし現状では全体の 1% 未満のライブラリについての型定義しか登録されておらず、まだまだ実用化にはほど遠い状態です...。
「Rails アプリに Steep での型検査を入れてみた！」という事例はだんだんと増えていますが、どの記事もなかなかに苦労しているのが現状です。

この辺りの話は RubyKaigi 2022 のふーがさんの発表がとても参考になります：

@speakerdeck

今回せっかく型定義を追加してみたのでgemrbscollection にも型定義を追加してみようと思います。
（そこまでやっても良かったのですが、テストの書き方とか程度がわからず後回しにしちゃってます）

まとめ
この記事では、シンプルな Ruby のライブラリに Steep による型検査を導入してみました。
とても楽しかった一方でまだまだ情報はなかなかなく、VSCode などの IDE に導入するのも一苦労です。
この記事が「Ruby の型解析に興味はあるけどよくわからん」という方に少しでも参考になれば嬉しいです。

クラッソーネでは言語・技術の先端を追いかけるエンジニアを大募集しています。
ご興味ある方はぜひ採用サイトをご覧ください！

https://www.crassone.co.jp/recruit/engineer/

自作のGemにTypeprofとSteepを使った型検査の仕組みを導入してみた

こんにちは、クラッソーネで Rails エンジニアをしている山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
最近 <a href="https://dakaboku.jp/" target="_blank" rel="nofollow noopener noreferrer">『だから僕たちは、組織を変えていける』</a> という本を読んだのですが、図表がわかりやすかったり体系化された情報が心地よくて一気に読破してしまいました。 
その結果チーム作りや個人の動機付けといったトピックへの関心が高まりまくっていて... 
感想のシェアとか対話とかとってもしたい気分です、「私も読んだよ」という方いればぜひお話しませんか...！
<iframe id="zenn-embedded__8ffb40736d32a" src="https://embed.zenn.studio/tweet#zenn-embedded__8ffb40736d32a" data-content="https%3A%2F%2Ftwitter.com%2Fyamat47%2Fstatus%2F1515272560359149569" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://twitter.com/yamat47/status/1515272560359149569" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://twitter.com/yamat47/status/1515272560359149569</a>
さて今回は、わがままながら最近の私の嬉しかったできごとを共有させてください。 
2022年4月度の MVV アワード を受賞し、それに関して社内向けにプレゼンテーションをしたので、その辺りの話をお伝えします。
<h2 id="%E3%80%8Cmvv-%E3%82%A2%E3%83%AF%E3%83%BC%E3%83%89%E3%80%8D%E3%81%A3%E3%81%A6%E3%81%AA%E3%81%AB%EF%BC%9F"><a class="header-anchor-link" href="#%E3%80%8Cmvv-%E3%82%A2%E3%83%AF%E3%83%BC%E3%83%89%E3%80%8D%E3%81%A3%E3%81%A6%E3%81%AA%E3%81%AB%EF%BC%9F" aria-hidden="true"></a> 「MVV アワード」ってなに？</h2>
クラッソーネでは、四半期が始まるタイミングで方針を共有するための全社会議（通称クォーターミーティング、QMTG）を行なっています。 
コロナ禍の前までは全員が名古屋に集まっていたそうですが、最近では Zoom を利用したオンラインでの開催が中心です。
この QMTG にて、直前の四半期に会社のミッション・ビジョン・バリューを特に体現していた社員を表彰する機会があります。 
これを MVV アワードといい、受賞者はその具体的な成果やノウハウを共有することで、他の社員にも知識が広がっていくことを期待しています。 
（この辺りの詳しいことは以前 Wantedly でまとめた記事がでていたので、よければご覧ください）
<iframe id="zenn-embedded__0812841b0b61d" src="https://embed.zenn.studio/card#zenn-embedded__0812841b0b61d" data-content="https%3A%2F%2Fwww.wantedly.com%2Fcompanies%2Fcrassone%2Fpost_articles%2F288756%23h2-%25E2%2596%25B6mvv%25E3%2582%25A2%25E3%2583%25AF%25E3%2583%25BC%25E3%2583%2589" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.wantedly.com/companies/crassone/post_articles/288756#h2-%E2%96%B6mvv%E3%82%A2%E3%83%AF%E3%83%BC%E3%83%89" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.wantedly.com/companies/crassone/post_articles/288756#h2-▶mvvアワード</a>
そしてこの度、この MVV アワードに 2022 年 1 月から 3 月の間の実績をもとに選出していただきました！ 
個人で受賞するのは初めてだったので、素直に嬉しかったですね（とっても恥ずかしかったけど）
<img src="/images/posts/mvv-award-winning-report/receiving-certification.png" alt="授賞式の様子" />
（授賞式の様子はこんな感じでした）
<h2 id="%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E8%A9%95%E4%BE%A1%E3%81%95%E3%82%8C%E3%81%9F%E3%81%AE%EF%BC%9F"><a class="header-anchor-link" href="#%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E8%A9%95%E4%BE%A1%E3%81%95%E3%82%8C%E3%81%9F%E3%81%AE%EF%BC%9F" aria-hidden="true"></a> どんなことを評価されたの？</h2>
授賞式の様子には、私がいただいた表彰状も写っています。 
これをみると、このようなポイントで私のことを評価してくださっていました：
<ul>
<li>常に「全体が良くなるためには何をするべきか」を考えて行動し、アウトプットし続けた</li>
<li>ライブラリ開発などの「新たな挑戦」やドキュメント化などの「データ/情報の蓄積と共有」に取り組んだ</li>
<li>チームを超えて活動し、チーム内外の成果に貢献した</li>
</ul>
自分で書くと恥ずかしくてなんだかむずがゆくなりますね... 
私が大切にしていた価値観やそれを表した行動について述べてくださっていて、なおさら嬉しい受賞でした！
冒頭に紹介した『だかぼく』では、こうした性質を持つ人は「主体性を持つギバー」と呼ばれています。 
どれも私にとっては当たり前な行動なのですが、実際にはそうではないのかも...？ 
こういう価値観で動ける人が、仕事・プライベート問わず世の中にたくさん増えてほしいなと思っています。
<iframe id="zenn-embedded__02ac590a8bbd2" src="https://embed.zenn.studio/tweet#zenn-embedded__02ac590a8bbd2" data-content="https%3A%2F%2Ftwitter.com%2Fyamat47%2Fstatus%2F1515534582829162503%3Fconversation%3Dnone" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://twitter.com/yamat47/status/1515534582829162503?conversation=none" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://twitter.com/yamat47/status/1515534582829162503?conversation=none</a>
<h2 id="%E7%A4%BE%E5%86%85%E5%90%91%E3%81%91%E3%81%AE%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%81%A7%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E8%A9%B1%E3%81%97%E3%81%9F%E3%81%AE%EF%BC%9F"><a class="header-anchor-link" href="#%E7%A4%BE%E5%86%85%E5%90%91%E3%81%91%E3%81%AE%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%81%A7%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%82%92%E8%A9%B1%E3%81%97%E3%81%9F%E3%81%AE%EF%BC%9F" aria-hidden="true"></a> 社内向けのプレゼンではどんなことを話したの？</h2>
10 分弱のプレゼンでは、具体的に取り組んでいたことやそのときに考えていたことを皆さんにお伝えしました。 
いくつかスライドを抜粋しながら、大まかな内容をこちらにも載せてみます。
<img src="/images/posts/mvv-award-winning-report/slide-result.png" alt="実績の紹介" />
三ヶ月で取り組んだことの紹介です。 
業務時間の大部分は Rails を思い切り書いていたので、こうした活動はちょっとした空き時間や週末に取り組んでいました。
<img src="/images/posts/mvv-award-winning-report/slide-github.png" alt="GitHubの活動記録" />
ライブラリの開発をはじめとして GitHub 上で活動することも多かった三ヶ月でした。 
気付けば三ヶ月間、一日も欠かさず何かしらチャレンジしていました。 
（今はもう途切れちゃってます... 週末は読書ばかりしてます...）
<img src="/images/posts/mvv-award-winning-report/slide-motto.png" alt="行動するときに考えていたこと" />
こうした活動のきっかけは、すべてが最初は「自分のため」でした。 
プログラマーの三代美徳に従って、自動化をしたり質を高めたり、自動テストをしやすくしていただけでした。 
それを「せっかくなので他の人にも共有しよう」という動機でどんどんシェアしていた、そんな三ヶ月間でした。
<img src="/images/posts/mvv-award-winning-report/slide-message.png" alt="最近、自分の仕事の効率を上げるために何をしましたか？" />
エンジニアだと当たり前に取り組むようなことも、実はそれほど一般的ではないのかもしれません。 
徹底的な改善活動と、そこから生まれた仕組みを仲間にすぐに共有する。 
この流れをずっと繰り返してきたことが、さまざまな成果につながってくれました。 
こうした「自分にとって便利な知識や仕組みの共有」であふれる会社になるといいなと考えています。
発表の大まかな内容はこんな感じでした！
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
最近は「利他精神」や「他社貢献」など、周りの人の幸せに働きかけるようなマインドを大切にする組織が増えているように感じます。 
しかしこれは自分のよりどころを他者に依存する状態になるため、実はとても不安定な状態です。 
詳しく語ると長くなるのですが... そこからさらに一段階超えた「内発的動機付け」を促すことが大切です。
自分のための改善の方が、他人のための改善よりも行動しやすいはずです。 
まずはそこからチャレンジしてみて、それを段々と他者貢献につなげていく、そんな社会活動が盛り上がっていくといいなと考えています。
クラッソーネでは、社内外にノウハウを共有し続ける「主体性を持つギバー」のみなさんを大募集しています。 
この記事を読んで少しでも興味を持ってくださったなら、私と気軽にお話しましょう！
<iframe id="zenn-embedded__48642e85b5ed9" src="https://embed.zenn.studio/card#zenn-embedded__48642e85b5ed9" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>
<h2 id="%E3%81%8A%E3%81%BE%E3%81%91%EF%BC%9A%E7%A4%BE%E5%86%85%E5%90%91%E3%81%91%E3%81%AE%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%81%AE%E8%B3%87%E6%96%99"><a class="header-anchor-link" href="#%E3%81%8A%E3%81%BE%E3%81%91%EF%BC%9A%E7%A4%BE%E5%86%85%E5%90%91%E3%81%91%E3%81%AE%E3%83%97%E3%83%AC%E3%82%BC%E3%83%B3%E3%81%AE%E8%B3%87%E6%96%99" aria-hidden="true"></a> おまけ：社内向けのプレゼンの資料</h2>
会社の許可も出たので、発表資料の全体もこちらで共有しておきます：
<iframe src="https://speakerdeck.com/player/f3f804baff0a4670a6b5165f0692afa7" scrolling="no" allowfullscreen allow="encrypted-media" loading="lazy"></iframe>

こんにちは、クラッソーネで Rails エンジニアをしている山口拓弥（@yamat47）です。

最近 『だから僕たちは、組織を変えていける』 という本を読んだのですが、図表がわかりやすかったり体系化された情報が心地よくて一気に読破してしまいました。
その結果チーム作りや個人の動機付けといったトピックへの関心が高まりまくっていて...
感想のシェアとか対話とかとってもしたい気分です、「私も読んだよ」という方いればぜひお話しませんか...！

https://twitter.com/yamat47/status/1515272560359149569

さて今回は、わがままながら最近の私の嬉しかったできごとを共有させてください。
2022年4月度の MVV アワード を受賞し、それに関して社内向けにプレゼンテーションをしたので、その辺りの話をお伝えします。

「MVV アワード」ってなに？
クラッソーネでは、四半期が始まるタイミングで方針を共有するための全社会議（通称クォーターミーティング、QMTG）を行なっています。
コロナ禍の前までは全員が名古屋に集まっていたそうですが、最近では Zoom を利用したオンラインでの開催が中心です。

この QMTG にて、直前の四半期に会社のミッション・ビジョン・バリューを特に体現していた社員を表彰する機会があります。
これを MVV アワードといい、受賞者はその具体的な成果やノウハウを共有することで、他の社員にも知識が広がっていくことを期待しています。
（この辺りの詳しいことは以前 Wantedly でまとめた記事がでていたので、よければご覧ください）

https://www.wantedly.com/companies/crassone/post_articles/288756#h2-%E2%96%B6mvv%E3%82%A2%E3%83%AF%E3%83%BC%E3%83%89

そしてこの度、この MVV アワードに 2022 年 1 月から 3 月の間の実績をもとに選出していただきました！
個人で受賞するのは初めてだったので、素直に嬉しかったですね（とっても恥ずかしかったけど）

授賞式の様子

（授賞式の様子はこんな感じでした）

どんなことを評価されたの？
授賞式の様子には、私がいただいた表彰状も写っています。
これをみると、このようなポイントで私のことを評価してくださっていました：

常に「全体が良くなるためには何をするべきか」を考えて行動し、アウトプットし続けた
ライブラリ開発などの「新たな挑戦」やドキュメント化などの「データ/情報の蓄積と共有」に取り組んだ
チームを超えて活動し、チーム内外の成果に貢献した

自分で書くと恥ずかしくてなんだかむずがゆくなりますね...
私が大切にしていた価値観やそれを表した行動について述べてくださっていて、なおさら嬉しい受賞でした！

冒頭に紹介した『だかぼく』では、こうした性質を持つ人は「主体性を持つギバー」と呼ばれています。
どれも私にとっては当たり前な行動なのですが、実際にはそうではないのかも...？
こういう価値観で動ける人が、仕事・プライベート問わず世の中にたくさん増えてほしいなと思っています。

https://twitter.com/yamat47/status/1515534582829162503?conversation=none

社内向けのプレゼンではどんなことを話したの？
10 分弱のプレゼンでは、具体的に取り組んでいたことやそのときに考えていたことを皆さんにお伝えしました。
いくつかスライドを抜粋しながら、大まかな内容をこちらにも載せてみます。

実績の紹介

三ヶ月で取り組んだことの紹介です。
業務時間の大部分は Rails を思い切り書いていたので、こうした活動はちょっとした空き時間や週末に取り組んでいました。

GitHubの活動記録

ライブラリの開発をはじめとして GitHub 上で活動することも多かった三ヶ月でした。
気付けば三ヶ月間、一日も欠かさず何かしらチャレンジしていました。
（今はもう途切れちゃってます... 週末は読書ばかりしてます...）

行動するときに考えていたこと

こうした活動のきっかけは、すべてが最初は「自分のため」でした。
プログラマーの三代美徳に従って、自動化をしたり質を高めたり、自動テストをしやすくしていただけでした。
それを「せっかくなので他の人にも共有しよう」という動機でどんどんシェアしていた、そんな三ヶ月間でした。

最近、自分の仕事の効率を上げるために何をしましたか？

エンジニアだと当たり前に取り組むようなことも、実はそれほど一般的ではないのかもしれません。
徹底的な改善活動と、そこから生まれた仕組みを仲間にすぐに共有する。
この流れをずっと繰り返してきたことが、さまざまな成果につながってくれました。
こうした「自分にとって便利な知識や仕組みの共有」であふれる会社になるといいなと考えています。

発表の大まかな内容はこんな感じでした！

まとめ
最近は「利他精神」や「他社貢献」など、周りの人の幸せに働きかけるようなマインドを大切にする組織が増えているように感じます。
しかしこれは自分のよりどころを他者に依存する状態になるため、実はとても不安定な状態です。
詳しく語ると長くなるのですが... そこからさらに一段階超えた「内発的動機付け」を促すことが大切です。

自分のための改善の方が、他人のための改善よりも行動しやすいはずです。
まずはそこからチャレンジしてみて、それを段々と他者貢献につなげていく、そんな社会活動が盛り上がっていくといいなと考えています。

クラッソーネでは、社内外にノウハウを共有し続ける「主体性を持つギバー」のみなさんを大募集しています。
この記事を読んで少しでも興味を持ってくださったなら、私と気軽にお話しましょう！

https://www.crassone.co.jp/recruit/engineer/

おまけ：社内向けのプレゼンの資料
会社の許可も出たので、発表資料の全体もこちらで共有しておきます：

@speakerdeck


「当たり前」のことをしつづけたら四半期のMVPに選ばれた話

こんにちは、クラッソーネで Rails エンジニアをしている山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
今年のバレンダインデーは大量のチョコをおともに SUPER BOWL を楽しみました。 
しびれるシーソーゲームでしたね、とても楽しい試合でした！
<iframe id="zenn-embedded__b5607f3c3ac44" src="https://embed.zenn.studio/tweet#zenn-embedded__b5607f3c3ac44" data-content="https%3A%2F%2Ftwitter.com%2Fnfl%2Fstatus%2F1493057660836462594%3Fs%3D12" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://twitter.com/nfl/status/1493057660836462594?s=12" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://twitter.com/nfl/status/1493057660836462594?s=12</a>
さて今日は、私が最近作った Gem の紹介をします。 
日本の住所を解析していい感じに構造化してくれるライブラリ、JapaneseAddressParser です！
<iframe id="zenn-embedded__705d192a78f36" src="https://embed.zenn.studio/card#zenn-embedded__705d192a78f36" data-content="https%3A%2F%2Fgithub.com%2Fyamat47%2Fjapanese_address_parser" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/yamat47/japanese_address_parser" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/yamat47/japanese_address_parser</a>
<h2 id="%E3%81%9D%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%82%92%E4%BD%BF%E3%81%86%E3%81%A8%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%AE%EF%BC%9F"><a class="header-anchor-link" href="#%E3%81%9D%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%82%92%E4%BD%BF%E3%81%86%E3%81%A8%E3%81%A9%E3%82%93%E3%81%AA%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%AE%EF%BC%9F" aria-hidden="true"></a> そのライブラリを使うとどんなことができるの？</h2>
住所の文字列を入力すると、「都道府県」「市区町村」「町域」の3つを抽出して構造化したデータを返してくれます。 
例えばこんな感じです：
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')

address.class #=&gt; JapaneseAddressParser::Models::Address

prefecture = address.prefecture
prefecture.attributes #=&gt; {:code=&gt;"13", :name=&gt;"東京都", :name_kana=&gt;"トウキョウト", :name_romaji=&gt;"TOKYO TO"}

city = address.city
city.attributes #=&gt; {:code=&gt;"13103", :formatted_code=&gt;"13103", :prefecture_code=&gt;"13", :name=&gt;"港区", :name_kana=&gt;"ミナトク", :name_romaji=&gt;"MINATO KU"}

town = address.town
town.attributes #=&gt; {:name=&gt;"芝公園四丁目", :name_kana=&gt;"シバコウエン 4", :name_romaji=&gt;"SHIBAKOEN 4", :nickname=&gt;nil, :latitude=&gt;"35.656459", :longitude=&gt;"139.74764"}
</code></pre></div>都道府県や市区町村、町域のデータはふりがなの情報も持っています。 
そこで、こんな感じでふりがなデータにアクセスすることもできます：
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')
address.furigana #=&gt; "トウキョウトミナトクシバコウエン 4"
</code></pre></div>また、このライブラリの動作を試すための簡単な Rails アプリを公開しています。 
フォームから送信される値などのデータは一切保存していませんので、安心して色々試してみてください：
<iframe id="zenn-embedded__4f791914883b" src="https://embed.zenn.studio/card#zenn-embedded__4f791914883b" data-content="https%3A%2F%2Fjapanese-address-parser-demo.herokuapp.com%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://japanese-address-parser-demo.herokuapp.com/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://japanese-address-parser-demo.herokuapp.com/</a>
このライブラリは MIT で公開しています。 
ぜひ気軽に使ってみてください！
<h2 id="%E4%BD%99%E8%AB%87%EF%BC%9A%E6%8A%80%E8%A1%93%E7%9A%84%E3%81%AB%E5%B7%A5%E5%A4%AB%E3%81%97%E3%81%9F%E3%81%A8%E3%81%93%E3%82%8D"><a class="header-anchor-link" href="#%E4%BD%99%E8%AB%87%EF%BC%9A%E6%8A%80%E8%A1%93%E7%9A%84%E3%81%AB%E5%B7%A5%E5%A4%AB%E3%81%97%E3%81%9F%E3%81%A8%E3%81%93%E3%82%8D" aria-hidden="true"></a> 余談：技術的に工夫したところ</h2>
そもそも、こうした「日本の住所の解析」についてはすでに様々な OSS プロジェクトが存在します。 
その中の一つが geolonia/normalize-japanese-addresses で、今回紹介したライブラリと同様のことができる npm のライブラリです。
<iframe id="zenn-embedded__8ee9b7639b51b" src="https://embed.zenn.studio/card#zenn-embedded__8ee9b7639b51b" data-content="https%3A%2F%2Fgithub.com%2Fgeolonia%2Fnormalize-japanese-addresses" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/geolonia/normalize-japanese-addresses" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/geolonia/normalize-japanese-addresses</a>
しかしこれは npm のライブラリなので、当然 Rails アプリから利用するのは難しいです。 
「クライアント側の JavaScript から呼び出せばいいじゃん」といえば確かにそうなのですが... 
サーバーの処理の中で呼び出したいというのが元々の動機だったため、Ruby からアクセスできるものを作ることにしました。
Ruby から npm (Node.js) にアクセスをするためには Shopify/schmooze を利用すると便利です。
<iframe id="zenn-embedded__ce75ea1fca49" src="https://embed.zenn.studio/card#zenn-embedded__ce75ea1fca49" data-content="https%3A%2F%2Fgithub.com%2FShopify%2Fschmooze" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/Shopify/schmooze" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/Shopify/schmooze</a>
今回作ったライブラリでも <a href="https://github.com/yamat47/japanese_address_parser/blob/45aaa4e6145fd2161ac289c6f9e6b2902ec236e2/js/package.json" target="_blank" rel="nofollow noopener noreferrer">ライブラリ内に <code>package.json</code> を持ちつつ</a> 、<a href="https://github.com/yamat47/japanese_address_parser/tree/45aaa4e6145fd2161ac289c6f9e6b2902ec236e2/js/node_modules" target="_blank" rel="nofollow noopener noreferrer"><code>node_modules</code> をライブラリのソースコードに含める</a> という手法で geolonia/normalize-japanese-addresses を利用しています。
この辺りの実装方針はいただいたプルリクをきっかけに大きく軌道修正した内容でした。 
コントリビューション、ありがとうございました！
<iframe id="zenn-embedded__701acc610d62c" src="https://embed.zenn.studio/card#zenn-embedded__701acc610d62c" data-content="https%3A%2F%2Fgithub.com%2Fyamat47%2Fjapanese_address_parser%2Fpull%2F30" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/yamat47/japanese_address_parser/pull/30" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/yamat47/japanese_address_parser/pull/30</a>
<h2 id="%E3%81%95%E3%82%89%E3%81%AB%E4%BD%99%E8%AB%87%EF%BC%9A%E5%AE%9F%E9%9A%9B%E3%81%AE-rails-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E3%81%AE%E4%BD%BF%E7%94%A8%E4%BE%8B%E3%82%92%E7%B4%B9%E4%BB%8B"><a class="header-anchor-link" href="#%E3%81%95%E3%82%89%E3%81%AB%E4%BD%99%E8%AB%87%EF%BC%9A%E5%AE%9F%E9%9A%9B%E3%81%AE-rails-%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E3%81%AE%E4%BD%BF%E7%94%A8%E4%BE%8B%E3%82%92%E7%B4%B9%E4%BB%8B" aria-hidden="true"></a> さらに余談：実際の Rails アプリでの使用例を紹介</h2>
私たちが運営する <a href="https://www.crassone.jp" target="_blank" rel="nofollow noopener noreferrer">クラッソーネ</a> というサービスは Ruby on Rails で作られていて、HTML の生成も含めてサーバー側で行なっている昔ながらな構成のアプリです。
日々運営担当のメンバーがお客様のサポートをする中で、「お申し込みいただいた建物の住所が読めずにコミュニケーションがまごつく」という課題がありました。 
<a href="https://ja.wikipedia.org/wiki/%E9%9B%A3%E8%AA%AD%E5%9C%B0%E5%90%8D" target="_blank" rel="nofollow noopener noreferrer">難読地名</a> とされるところはまだしも、自分が暮らしている地域以外の地名はなかなか読みづらいものです。 
ありがたいことに全国様々な地域の方々にサービスを使っていただいていること、またそのサポート手段のメインがお電話であることも相まって、これがかなり深刻な課題になってしまっていました。
そこで運営担当向けの管理画面にて、今回作ったライブラリを使って住所の解析をし、ふりがなを表示するようにしました。 
誰の手を煩わせることもなくそこそこいい精度で表示してくれるようになり、毎日のサポート業務の効率を上げることができました。
<img src="/images/posts/introduction-for-japanese-address-parser-gem/show-furigana-for-administrator.png" alt="運営向けの管理画面に住所のふりがなを表示している様子" />
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
「住所の解析をしたい！」というシンプルな用途のライブラリですが、解析自体がとても複雑で大変だからか、これまで存在していなかった種類のものでした。 
きっかけは「住所の読み方を自動で解析できないか」というものでしたが、「ユーザーが入力した住所が妥当かどうか保存前に検証する」など他にも色々と応用ができそうです。
バグ報告や機能の提案など、コントリビュートはいつでも誰でも大歓迎です。 
少しでも気になったことがあればいつでもご提案ください！（スターしてくれると嬉しいな）
<iframe id="zenn-embedded__8c9aa065ebb26" src="https://embed.zenn.studio/card#zenn-embedded__8c9aa065ebb26" data-content="https%3A%2F%2Fgithub.com%2Fyamat47%2Fjapanese_address_parser" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/yamat47/japanese_address_parser" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/yamat47/japanese_address_parser</a>
クラッソーネでは、ソフトウェアの力で業務の効率化をしたいエンジニアを大募集しています。 
ここまで読んでくださった皆さま、ぜひ私とカジュアル面談でお話ししましょう！


こんにちは、クラッソーネで Rails エンジニアをしている山口拓弥（@yamat47）です。

今年のバレンダインデーは大量のチョコをおともに SUPER BOWL を楽しみました。
しびれるシーソーゲームでしたね、とても楽しい試合でした！

https://twitter.com/nfl/status/1493057660836462594?s=12

さて今日は、私が最近作った Gem の紹介をします。
日本の住所を解析していい感じに構造化してくれるライブラリ、JapaneseAddressParser です！

https://github.com/yamat47/japaneseaddressparser

そのライブラリを使うとどんなことができるの？
住所の文字列を入力すると、「都道府県」「市区町村」「町域」の3つを抽出して構造化したデータを返してくれます。
例えばこんな感じです：

address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')

address.class #=> JapaneseAddressParser::Models::Address

prefecture = address.prefecture
prefecture.attributes #=> {:code=>"13", :name=>"東京都", :namekana=>"トウキョウト", :nameromaji=>"TOKYO TO"}

city = address.city
city.attributes #=> {:code=>"13103", :formattedcode=>"13103", :prefecturecode=>"13", :name=>"港区", :namekana=>"ミナトク", :nameromaji=>"MINATO KU"}

town = address.town
town.attributes #=> {:name=>"芝公園四丁目", :namekana=>"シバコウエン 4", :nameromaji=>"SHIBAKOEN 4", :nickname=>nil, :latitude=>"35.656459", :longitude=>"139.74764"}

都道府県や市区町村、町域のデータはふりがなの情報も持っています。
そこで、こんな感じでふりがなデータにアクセスすることもできます：

address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')
address.furigana #=> "トウキョウトミナトクシバコウエン 4"

また、このライブラリの動作を試すための簡単な Rails アプリを公開しています。
フォームから送信される値などのデータは一切保存していませんので、安心して色々試してみてください：

https://japanese-address-parser-demo.herokuapp.com/

このライブラリは MIT で公開しています。
ぜひ気軽に使ってみてください！

余談：技術的に工夫したところ
そもそも、こうした「日本の住所の解析」についてはすでに様々な OSS プロジェクトが存在します。
その中の一つが geolonia/normalize-japanese-addresses で、今回紹介したライブラリと同様のことができる npm のライブラリです。

https://github.com/geolonia/normalize-japanese-addresses

しかしこれは npm のライブラリなので、当然 Rails アプリから利用するのは難しいです。
「クライアント側の JavaScript から呼び出せばいいじゃん」といえば確かにそうなのですが...
サーバーの処理の中で呼び出したいというのが元々の動機だったため、Ruby からアクセスできるものを作ることにしました。

Ruby から npm (Node.js) にアクセスをするためには Shopify/schmooze を利用すると便利です。

https://github.com/Shopify/schmooze

今回作ったライブラリでも ライブラリ内に package.json を持ちつつ 、node_modules をライブラリのソースコードに含める という手法で geolonia/normalize-japanese-addresses を利用しています。

この辺りの実装方針はいただいたプルリクをきっかけに大きく軌道修正した内容でした。
コントリビューション、ありがとうございました！

https://github.com/yamat47/japaneseaddressparser/pull/30

さらに余談：実際の Rails アプリでの使用例を紹介
私たちが運営する クラッソーネ というサービスは Ruby on Rails で作られていて、HTML の生成も含めてサーバー側で行なっている昔ながらな構成のアプリです。

日々運営担当のメンバーがお客様のサポートをする中で、「お申し込みいただいた建物の住所が読めずにコミュニケーションがまごつく」という課題がありました。
難読地名 とされるところはまだしも、自分が暮らしている地域以外の地名はなかなか読みづらいものです。
ありがたいことに全国様々な地域の方々にサービスを使っていただいていること、またそのサポート手段のメインがお電話であることも相まって、これがかなり深刻な課題になってしまっていました。

そこで運営担当向けの管理画面にて、今回作ったライブラリを使って住所の解析をし、ふりがなを表示するようにしました。
誰の手を煩わせることもなくそこそこいい精度で表示してくれるようになり、毎日のサポート業務の効率を上げることができました。

運営向けの管理画面に住所のふりがなを表示している様子

まとめ
「住所の解析をしたい！」というシンプルな用途のライブラリですが、解析自体がとても複雑で大変だからか、これまで存在していなかった種類のものでした。
きっかけは「住所の読み方を自動で解析できないか」というものでしたが、「ユーザーが入力した住所が妥当かどうか保存前に検証する」など他にも色々と応用ができそうです。

バグ報告や機能の提案など、コントリビュートはいつでも誰でも大歓迎です。
少しでも気になったことがあればいつでもご提案ください！（スターしてくれると嬉しいな）

https://github.com/yamat47/japaneseaddressparser

クラッソーネでは、ソフトウェアの力で業務の効率化をしたいエンジニアを大募集しています。
ここまで読んでくださった皆さま、ぜひ私とカジュアル面談でお話ししましょう！


日本の住所を解析できるGem JapaneseAddressParserを紹介したい！

こんにちは、バックエンドエンジニアの山口拓弥（@yamat47）です。

東京をはじめとして、またコロナがどんどん悪い意味で盛り上がってしまっていますね...
年末に友人からベンチプレスマシンなどウエイトトレーニング用のセットを手に入れた私には死角はありません、今日も充実したステイホームを満喫しています！

自宅のトレーニングセットの写真

（寂しい一人暮らしなのでトレーニングしている様子は撮れません、すみません...）

さて本日は、昨年末に取り組んだサーバーのレスポンスタイム改善の取り組みについてお伝えします。
ありがちな最適化からアプリ特有の事情へのアプローチなど赤裸々にまとめましたので、参考にしていただけると嬉しいです！

最適化をおこなったアプリの技術的な前提
今回対象にしたのは クラッソーネ というサービスで、Ruby on Rails 製のモノリシックなアプリケーションです。
大まかにはこのような技術を組み合わせて動いています：

Ruby は 2.7.5（最近 3.1.0 にあげました）。
Ruby on Rails は 6.0.2.1。
データベースは MySQL 8.0 系を Amazon RDS で利用している。
アプリのインフラ基盤は AWS をフルに活用。本番サーバーは ECS と Fargate で運用している。

Vue.js や React は利用しておらず、フロントエンドの実装にはせいぜい jQuery や Slim、SCSS を利用しているくらいです。
Rails の敷くレールに沿った、昔ながらな構成のアプリケーションです。

またアプリは大まかに分けて「施主様が利用する画面」「工事会社様が利用する画面」「運営メンバーが利用する画面」の三つに分かれています。
しかしそのほかの機能も含めて、一つの Rails アプリで実装を完結させています。
今回はそのうち「運営メンバーが利用する画面」に絞って最適化を行いました。

何はともあれ、最適化はうまくいったの？
結論、とてもうまくいきました！

元々は「めっちゃ頑張って2倍くらい速くなればいいな」と考えて目標を立てていましたが、画面によってはその何倍も速くなるページも...
アクセス頻度で重み付けした値を元に計算すると、最終的には 272% の改善ができました！

最適化できる余地がたくさんあることはわかっていましたが、それにしてもここまでうまくいくとは思っていませんでした。

最適化といっても、具体的には何をしたの？
細かく上げるとキリがないですが、大まかには5つの取り組みをしました。
以下、実際の画面もできるだけお見せしつつ、取り組んできたことをお伝えします。

1. Datadog を使ってアプリのパフォーマンスに影響を与えているところの調査
クラッソーネでは AWS と Datadog を連携させて、アプリケーションに関する様々な情報を Datadog 上で確認できるようにしています。
今回の取り組みでは、まずはあらかじめ決めた着手する対象のページに対して Datadog APM で1つずつ確認をしていき、どこにボトルネックがあるのかを調査しました。

例えばこのような調査記録を残していました：

Datadog APMで見た工事会社一覧画面の処理

Datadog APMで見た工事会社情報更新の処理

リストを表示しているところではきれいな N+1 クエリの要素がたくさん見られて、嬉しいような悲しいような複雑な気持ちになっていました...。
こうした画面をエンジニア何人かでにらめっこしながら「N+1 問題を解消しよう」「スロークエリをなんとかしよう」「遅延読み込みしたいね」「AWS S3 と連携しているところを切り離せないのか？」といった、実際に解消する課題の棚卸しを行いました。

振り返ってみるとこの棚卸しの活動がとても有効だったと感じています。
むやみやたらに取り組むのではなく、それぞれの施策の効果をある程度想像しながら着手順を決めて取り組んだことで、コスパの良い取り組みにできたと想像しています。

2. N+1 問題の解消
いろんなところで語られているので詳細は割愛しますが、クラッソーネでも残念ながら N+1 問題が発生してしまっていました。
Datadog でみると一目瞭然だったので、Bullet を武器に地道に一つずつ解消していきました。

https://github.com/flyerhzm/bullet

解決方法もよくある話ですが、ActiveRecord::QueryMethods#preload を使ってレコードの先読みをしていきました。
例えばこんな感じです（実際のアプリのコードから抜粋してきました）：

 def index
 @contractsummaries = ContractSummariesFinder.new(searchconditions).find
.preload(
contract: { project: %i[accurate_estimate estate] },
change_contract: [],
project: [
{ estate: %i[owner prefecture city] },
:company
]
)
 .order(contractid: :desc, basetablename: :desc, changecontract_id: :asc)
 .page(params[:page]).per(PAGINATES_PER)
 end

またついでに、ローカル開発環境で N+1 問題が発生していることにより気付きやすくしました。
もともと Bullet は導入されていたのですが、開発環境用に準備しているデータの数が少なく、N+1 が起きている扱いにならない画面がいくつかあり...
再び N+1 問題が発生したときに気付けるように、bin/setup をしたときに作られるデータのセットをたくさん増やしました。

3. ページネーションに関する部品を遅延して読み込むようにした
いわゆる一覧画面では、「1 - 30 （ 1462 件中 ）」のようなリストの件数を表示したり「次のページへ」のようなページの操作をする部品を表示したりしています。

ページネーションに関する部品

ページネーションに関する部品2

こうした表示には Kaminari を利用していますが、APM を解析したところこのページネーションに関する部品の表示に時間がかかっている画面がありました。
しかしこれは決してライブラリにパフォーマンス的な問題があるわけではなく...件数を取得するための COUNT すら遅いクエリが存在していた、ということでした。

https://github.com/kaminari/kaminari

包み隠さず正直にいうと、今回のこの取り組みではクエリのパフォーマンスチューニングまでは手が回りませんでした。
SQL VIEW を利用したそこそこ複雑なクエリで解決が難しそうだったのと、あまりたくさん時間をかけられるプロジェクトでもなかったので、アドホックな解決策を講じるだけにとどめています。
ページネーションに関する部品を画面が描画された後に遅延で読み込むようにして、最初の画面表示までの時間を短くしました。

ページネーションに関する部品の遅延読み込みの様子

↑ は画面をリロードしたときの様子です。
最初は「ページ情報を取得しています...」という固定の表示のみを出し、裏でページ情報を遅延読み込みしています。

実装ではあまり難しいことはしておらず、DOMContentLoaded のタイミングでサーバーに Ajax でリクエストを送っているだけです。
たったこれだけの対応ですが、数秒かかっていたクエリの実行を待たずに済むようになったため一気にレスポンスタイムが改善しました。

4. SQL VIEW をむやみやたらに呼び出さないようにした
先ほど出てきた SQL VIEW ですが、内容を取得するクエリは COUNT どころではない遅さで、遅延読み込みなどの小手先の対応だけではどうしてもレスポンスタイムを改善しきれませんでした。
そこで更なる解決策として「本当に必要になるまで SQL VIEW を呼び出さない」という対策を講じました。

先に解決策のイメージをお見せします：

Estate と EstateSummaries は いずれも ApplicationRecord を直接継承したクラス。
Estate はテーブルと結びついていて、EstateSummaries は SQL VIEW と結びついている。
module Admin
 class EstatesController < ApplicationController
 def index
 @estates =
 if sqlviewrequiredsearchcondition?
 EstateSummaries.where(...)
 else
 Estate.where(...)
 end
 end

 private
 def sqlviewrequiredsearchcondition?
SQL VIEW を使わないと検索できない条件かどうかを判定する。
 end
 end
end

SQL VIEW を利用しているのは一覧画面のリストを取得する部分で、検索の仕組みをシンプルにするために導入した仕組みでした。
しかしこれを必要とするのは一部の検索条件についてのみだったため、それ以外の検索条件のみで検索されているときには呼び出さないようにしました。

実際にはここに先ほど載せたページネーションに関する部品の遅延読み込みも絡んでくるため、#index アクションがそこそこ複雑になってしまっています。
しかしそれを上回る効果があることが確認できたため、入念な動作確認ののちに本番環境にリリースしました。

5. 滅多に使わない外部サービスを呼び出す処理を他の画面に切り離した
工事会社様についての管理画面では、社名や所在地などの情報の他に「会社ロゴ」など関連する画像を管理することができます。
この画像のデータは AWS S3 に保存していて、Rails との連携には Shrine を利用しています。

https://github.com/shrinerb/shrine

工事会社様の詳細画面

最適化を行うまで、この工事会社様の情報を更新する画面はひとつしかなく、そこで画像を含むさまざまな情報をいっぺんに更新できるようになっていました。
しかしそのため、S3 に置いてある画像データ以外を更新したときも Shrine の処理を呼び出してしまい、無駄な外部サービス呼び出しが発生してしまっていました。

そこで新しく「画像を変更するための画面」を準備し、画像以外の RDS に直接保存している情報と分けて更新できるようにしたことで、必要なときだけ外部サービスと接続するようにしました。
重たい処理を外に切り離しただけですが、運営メンバー曰く画像を更新する頻度は高くないとのことで、小さい変更で大きな成果を得ることができました。

最終的にどうなったの？
今回のプロジェクトで最適化にチャレンジしたのは全部で 10 の画面でした。
アクセス頻度とレスポンスタイムの悪さの二つを考慮して、一番影響が大きそうな画面たちを選びました。

取り組み前後での変化を表にまとめてみると改善度合いは一目瞭然です：

| 最適化をおこなった画面 | 取り組み前（p95） | 取り組み後（p95） | 改善度合い |
| --- | --- | --- | --- |
| 工事会社情報更新処理 | 2907.8 ms | 153.7 ms | 1892% |
| 物件一覧画面 | 8563 ms | 1255.3 ms | 682% |
| 工事会社情報編集画面 | 434.9 ms | 147.7 ms | 294% |
| 契約一覧画面 | 1027.8 ms | 452.6 ms | 227% |
| TODO一覧画面 | 417.8 ms | 243.5 ms | 172% |
| 工事会社詳細画面 | 1444 ms | 858.4 ms | 168% |
| 申し込み一覧画面 | 500.2 ms | 385.7 ms | 130% |
| 工事会社一覧画面 | 824.8 ms | 761.4 ms | 108% |
| 案件一覧画面 | 461.8 ms | 520.7 ms | 89% |
| 物件詳細画面 | 378.1 ms | 461.8 ms | 82% |

むしろ遅くなっている画面が2つありますが、これらはこの取り組みの間にほかの機能追加があり、さらにデータをたくさん表示するようになった画面でした。
何も取り組まなかったらさらに遅くなっていただろう変更だったので、なんとかこれくらいで食い止めたということにしています。

まとめ
実際には「カウンターキャッシュの導入」「スロークエリのチューニング」「インフラ基盤のアップグレード」など検討していたことは他にもたくさんありますが、かけられる時間の都合で上記の取り組みにとどまりました。
振り返ってみるとアプリケーションの変更に終始していて、それでも大きな影響を生み出すことができてよかったです。

運営メンバーからも 「物件一覧の絞り込み、速すぎて嘘だと思って3回試した」 など嬉しい反応をたくさんいただくことができました。
チームで「運営がユーザーの検討プロセスの支援を2倍のスピードで行えるようにする」という Objective を掲げた四半期にふさわしい取り組みにすることができました。

クラッソーネでは Rails アプリの最適化が好きなエンジニアを大募集しています。
ここまで記事を読んでくださったみなさま、ぜひカジュアル面談で私とお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/

アプリのコードの修正だけでRailsサーバーを3倍早くした話

この記事は Ruby on Rails Advent Calendar 2021 二日目の記事です。
昨日は kakudaisuke さんの「I18nを使いながらPCでもスマホでも狙ったところでレスポンシブに改行する」でした！

https://qiita.com/kakudaisuke/items/afc6e3f1544638812ec1

この記事で話すこと

この記事では、動画を再生するときの形式の一つである HLS（HTTP ライブストリーミング）について簡単にまとめつつ、Ruby on Rails 製のウェブサイトで実装をするための勘所をお伝えします。

HLS って？何が嬉しいの？
HLS とは Web 上で動画や音声のストリーミング配信・再生を行なうためのプロトコルの一つです。
元は Apple が開発をした形式でしたが、現在は Apple 製品にとどまらずさまざまなデバイス・ブラウザにて利用することができます。

HLS を利用した動画の再生は、大まかにはこのような仕組みになっています：

配信側は、もとの動画を一定間隔で細かく分割した MPEG2-TS ファイル（.ts）と、その再生順などを記したインデックスファイル（.m3u8）を用意する。
再生側はまず .m3u8 ファイルを受信し、その内容に従って順々に .ts ファイルを要求する。そして受信したものから順に再生する。

例えばサイトのファーストビューのメインビジュアルとして動画を利用するとき、素朴に MP4 の動画を読み込ませようとするとどうしても FCP スコア が下がってしまいます。
そのときに HLS を利用することで再生しながら動画の続きを読み込ませられるようになるため、ページの初期読み込み速度を抑えつつ動画を配信することができます。

HLS について、詳しくはこちらのサイトをご覧ください。

HTTPライブストリーミングとは？| HLSストリーミング | Cloudflare
オンデマンド動画配信を支える技術 - わかる！HLS編 - Qiita
FV動画をHLS形式で実装した時の備忘録 | COFUS技術ブログ

:::message
この記事ではいわゆるオンデマンドな動画の配信を対象にしています。
ライブ配信は扱っていませんのでご了承ください。
:::

HLS ってどうやって実装できるの？
HLS を使って動画の配信を実装するためには、大きく分けて三つの作業が必要です。

配信したい動画をもとに .m3u8 ファイルや .ts ファイルを生成する
.m3u8 ファイルや .ts ファイルを配信できるようにする
HLS 形式で動画を配信する仕組みを導入する

それぞれ順に見ていきます。

1. 配信したい動画をもとに .m3u8 ファイルや .ts ファイルを生成する
HLS に必要なファイルたちの生成は ffmpeg を利用すると簡単です。

例えばローカルにある video.mp4 から video.m3u8 というインデックスファイルと video000.ts、video001.ts、...のような動画ファイルを生成したいときは、このようなコマンドを実行すれば OK です。

ffmpeg -i video.mp4 -c:v copy -f hls -hlstime 5 -hlsplaylisttype vod -hlssegment_filename "video%3d.ts" video.m3u8

:::details オプションの意味
| オプション | 意味 |
| --- | --- |
| -i video.mp4 | 元のファイルの指定。 |
| -c:v copy | コーデックの指定。copyとすると元のファイルと同じコーデックになります。 |
| -f hls | フォーマットの指定。 |
| -hls_time 5 | 動画を分割する際の間隔の指定。単位は秒。 |
| -hlsplaylisttype vod | HLSのタイプを指定します。 |
| -hlssegmentfilename "video%3d.ts" | 小さく分割した動画ファイルの名前の指定。%3d と指定していることで 000、001、...といった三桁のインデックスが割り振られます。 |
| video.m3u8 | インデックスファイルの名前の指定。 |
:::

2. .m3u8 ファイルや .ts ファイルを配信できるようにする
Ruby on Rails において、静的なファイルの配信はさまざまな方法で行うことができます。
Sprockets を使った昔ながらの方法、Webpacker を使ったイマドキ（？）な方法、/public にあるファイルを参照する素朴な方法の三つが代表的なものでしょうか。

ここでは .m3u8 ファイル は Webpacker を使って配信し、.ts ファイルは /public に置いて配信してみます。

まずは Webpacker が動画ファイルを配信できるようにします。
app/assets/javascript/videos というディレクトリを作り、そこに video.m3u8 を置きつつ、application.js を次のようにします。

// この行があることで assetpackpath で動画ファイルを参照できるようになる。
require.context("../videos", true);

import Rails from "@rails/ujs"
Rails.start()

次に動画を表示するための HTML を作っていきます。
詳細は割愛しますが、Rails の View ファイルにて先ほど配置した video.m3u8 を参照してみます。

これだけで iOS Safari などのブラウザでは HLS 形式の動画を読み込むことができます。

しかし実際に試してみると .ts ファイルが見つからずに動画を再生することができません。
ファイルを探すときに Asset Pipeline の仕組みを使って探索に行ってしまうため、/public にファイルを置いてあると見つけてくれないのです。

/public に置いてあるファイルを直接参照させるために、video.m3u8 に手を加えましょう。
.ts ファイルを呼び出している行の先頭全てに ↓ のように / をつけてください。

-video000.ts
+/video000.ts

以上で、特別な設定が不要な iOS Safari などのブラウザでは HLS 形式の動画を読み込めるようになりました！

3. HLS 形式で動画を配信する仕組みを導入する
最後に、ネイティブにはサポートされていないその他のブラウザでも HLS 形式の動画を読み込めるようにしていきます。
ここではこの用途に特化した video-dev/hls.js というライブラリを利用します。

https://github.com/video-dev/hls.js/

基本的には README の通りに実装すれば正しく動きます。
せっかくなので今回は hls.js がサポートしていないブラウザ向けのフォールバックも含めて実装してみます。

:::details app/views/home/show.html.erb の変更
HLS をサポートしていないブラウザ向けに MP4 動画も配置しつつ、その動画のパスも指定しておきます。

:::

:::details package.json の変更
yarn add hls.js を実行してください。

  "dependencies": {
    "@rails/ujs": "^6.0.0",
    "@rails/webpacker": "5.4.3",
"hls.js": "^1.1.1",
    "webpack": "^4.46.0",
    "webpack-cli": "^3.3.12"
  },
:::

:::details app/javascript/packs/application.js の変更
 require.context("../videos", true);

 import Rails from "@rails/ujs"
 Rails.start()
+import "../src/loadHls"
:::

:::details app/javascript/src/loadHls.js の追加
import Hls from 'hls.js';

function loadHlsVideo (video) {
  const videoSrc = video.getAttribute('data-hls-src');
  const fallbackVideoSrc = video.getAttribute('data-fallback-src');

  // hls.jsがサポートしているブラウザの場合。
  if (Hls.isSupported()) {
    const hls = new Hls();
    hls.loadSource(videoSrc);
    hls.attachMedia(video);
  }
  // HLSをサポートしているブラウザの場合はsrc属性に直接m3u8ファイルを指定すればよい。
  else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    video.src = videoSrc;
  // どうしようもないときはフォールバック用の動画を再生する。
  } else {
    video.src = fallbackVideoSrc;
  }
}

document.addEventListener('DOMContentLoaded', () => {
  document.querySelectorAll('video.js-hls-video').forEach((video) => loadHlsVideo(video))
})
:::

こうすることで、hls.js がサポートする様々なブラウザ にて HLS 形式で動画を再生できるようになりました！

実装してみたコードは公開しています
今回実装してみたこれらのコードも含んだ、実際に動く Rails アプリのソースコードを公開しています。
理解・実践の参考にしていただけたら嬉しいです！

https://github.com/yamat47/rails-hls-sample

また Heroku でこの Rails アプリをデプロイしています。
実機での動作を確認したいときにお使いください！

https://rails-hls-sample.herokuapp.com/

開発者ツールでネットワークの状況を見てみると、少しずつ動画の続きが読み込まれていっているのがわかると思います。

tsファイルが少しずつ読み込まれていっている様子

:::message alert
2022年2月20日追記：デモンストレーション用のアプリの公開を終了しました。
コードは readonly で公開し続けています。
:::

感想：Rails にちょっと周辺領域の技術を組み合わせるのめっちゃ楽しい
この記事では、かなり枯れつつある Ruby on Rails に HLS というちょっと違った領域の技術を組み合わせてみました。
hls.js のおかげであまり複雑な実装をする必要はなくなっていますが、Rails ができることの広さをあらためて実感しました。

クラッソーネでは Ruby on Rails にいろんな技術を組み合わせるのが好きなエンジニアを大募集しています。
少しでもこの記事に興味を持っていただいた方、ぜひカジュアル面談でお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


Ruby on RailsでもHLS形式で動画を再生したい！

こんにちは、バックエンドエンジニアの山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
ようやくコロナ禍もちょっとずつ落ち着いてきましたね！ 
私は週末は <a href="https://twitter.com/Brandings_team" target="_blank" rel="nofollow noopener noreferrer">Brandings</a> というチームでアメフトをプレーしていますが、大会の開幕まで一ヶ月を切ってかなり緊張しています...。 
主将としてのファーストシーズン、なんならコロナが再燃するまでの束の間の期間かもしれないので、雨にも日焼けにも負けず思いっきり取り組んでいます！
<iframe id="zenn-embedded__3f6a3b80cf9b3" src="https://embed.zenn.studio/tweet#zenn-embedded__3f6a3b80cf9b3" data-content="https%3A%2F%2Ftwitter.com%2FBrandings_team%2Fstatus%2F1445237814581284865" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://twitter.com/Brandings_team/status/1445237814581284865" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://twitter.com/Brandings_team/status/1445237814581284865</a>
（写真は一昨年のものですが、寝っ転がっているのが私です）
<h2 id="%E3%81%A8%E3%81%A3%E3%81%A6%E3%82%82%E4%BE%BF%E5%88%A9%E3%81%AA-cli-%E3%83%84%E3%83%BC%E3%83%AB-ghq"><a class="header-anchor-link" href="#%E3%81%A8%E3%81%A3%E3%81%A6%E3%82%82%E4%BE%BF%E5%88%A9%E3%81%AA-cli-%E3%83%84%E3%83%BC%E3%83%AB-ghq" aria-hidden="true"></a> とっても便利な CLI ツール ghq</h2>
さて、みなさんは ghq という CLI ツールを知っているでしょうか？ 
clone してきたローカルのリポジトリをとってもいい感じに管理してくれるツールで、peco などのフィルターと組み合わせて使っている方も多いと思います。
<iframe id="zenn-embedded__59dfdd3f1f40c" src="https://embed.zenn.studio/card#zenn-embedded__59dfdd3f1f40c" data-content="https%3A%2F%2Fgithub.com%2Fx-motemen%2Fghq" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/x-motemen/ghq" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/x-motemen/ghq</a>
Rubyist の皆さんなら gem-src と組み合わせて、<code>bundle install</code> するたびに Gem のソースコードを全部 ghq の管理下に置いていますかね。 
ちょっとしたデバッグにとても強力なので、もしまだしていない方は gem-src の README や <a href="https://twitter.com/koic" target="_blank" rel="nofollow noopener noreferrer">@koic</a> さんのスライドを参考にぜひ一度試してみてください！
<iframe id="zenn-embedded__d942bf7feed51" src="https://embed.zenn.studio/card#zenn-embedded__d942bf7feed51" data-content="https%3A%2F%2Fgithub.com%2Famatsuda%2Fgem-src" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/amatsuda/gem-src" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/amatsuda/gem-src</a>
<iframe src="https://www.slideshare.net/slideshow/embed_code/key/iJ2i2AVGsIkRmA" scrolling="no" allowfullscreen loading="lazy"></iframe>
<h2 id="ghq-%2B-alfred-%3D-%E2%88%9E"><a class="header-anchor-link" href="#ghq-%2B-alfred-%3D-%E2%88%9E" aria-hidden="true"></a> ghq + Alfred = ∞</h2>
そんな ghq ですが、ランチャーアプリの <a href="https://www.alfredapp.com/" target="_blank" rel="nofollow noopener noreferrer">Alfred</a> と組み合わせて使うとさらに強力なツールになります。 
Alfred の workflow 機能を使うと「Alfred 起動 → <code>ghq xxx</code> でリポジトリを選択する → すぐに Visual Studio Code で起動」という流れを滑らかに行うことができます。
workflow を自前で作ってもいいのですが、私は alfred-workflow-ghq を使っています。 
最新リリースの <code>ghq.alfredworkflow</code> ファイルをダウンロードして開くだけで使える、とっても手軽なパッケージなのが好きな理由です。
<iframe id="zenn-embedded__197af133cfa61" src="https://embed.zenn.studio/card#zenn-embedded__197af133cfa61" data-content="https%3A%2F%2Fgithub.com%2Fjackchuka%2Falfred-workflow-ghq" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/jackchuka/alfred-workflow-ghq" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/jackchuka/alfred-workflow-ghq</a>
今回の記事はこの alfred-workflow-ghq を使うときのちょっとした tips の紹介です！
<h2 id="%E5%89%8D%E6%8F%90%E7%9F%A5%E8%AD%98%EF%BC%9Aghq-%E3%81%AF%E8%B5%B7%E7%82%B9%E3%81%A8%E3%81%AA%E3%82%8B%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E8%87%AA%E7%94%B1%E3%81%AB%E8%A8%AD%E5%AE%9A%E3%81%A7%E3%81%8D%E3%82%8B"><a class="header-anchor-link" href="#%E5%89%8D%E6%8F%90%E7%9F%A5%E8%AD%98%EF%BC%9Aghq-%E3%81%AF%E8%B5%B7%E7%82%B9%E3%81%A8%E3%81%AA%E3%82%8B%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%92%E8%87%AA%E7%94%B1%E3%81%AB%E8%A8%AD%E5%AE%9A%E3%81%A7%E3%81%8D%E3%82%8B" aria-hidden="true"></a> 前提知識：ghq は起点となるディレクトリを自由に設定できる</h2>
詳しくは README を読んでいただくのがよいですが、ghq には clone してきたリポジトリをどこに配置するかを指定する仕組みが備わっています。 
デフォルトは <code>~/ghq</code> ですが、さまざまな方法でこれを変えることができます。
私の場合は <code>.gitconfig</code> を使って <code>~/src</code> をこの起点に設定しています。
<div class="code-block-container"><pre><code>┏╸~
┗╸❯❯❯ ghq root
/Users/takuya_yamaguchi/src
</code></pre></div><h2 id="alfred-workflow-ghq-%E3%81%AF%E3%81%9D%E3%81%AE%E3%81%BE%E3%81%BE%E3%81%A0%E3%81%A8-ghq-%E3%81%AE%E8%B5%B7%E7%82%B9%E3%81%AE%E5%A4%89%E6%9B%B4%E3%82%92%E9%81%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%81%8F%E3%82%8C%E3%81%AA%E3%81%84"><a class="header-anchor-link" href="#alfred-workflow-ghq-%E3%81%AF%E3%81%9D%E3%81%AE%E3%81%BE%E3%81%BE%E3%81%A0%E3%81%A8-ghq-%E3%81%AE%E8%B5%B7%E7%82%B9%E3%81%AE%E5%A4%89%E6%9B%B4%E3%82%92%E9%81%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%81%8F%E3%82%8C%E3%81%AA%E3%81%84" aria-hidden="true"></a> alfred-workflow-ghq はそのままだと ghq の起点の変更を適用してくれない</h2>
<a href="https://github.com/jackchuka/alfred-workflow-ghq/blob/888456093ebed9984b1a6718500ae7bdc3911490/info.plist#L112-L124" target="_blank" rel="nofollow noopener noreferrer">この辺りのコード</a> を読むとわかりますが、alfred-workflow-ghq はとても素朴な shell script です。 
また <code>ghq</code> を呼び出すための PATH 設定すら書かれていることから分かる通り、Alfred の workflow が呼び出すシェルはユーザー設定が全く読み込まれていません。
このままだと <code>ghq</code> コマンドはデフォルトの状態で呼び出されることになります。 
すなわち ↑ で紹介した起点の変更は有効にならず、デフォルトの <code>~/ghq</code> を起点としてコマンドが実行されてしまいます。 
これでは検索結果が常に空になってしまい、なんとも悲しいコマンドになってしまいます...。
<img src="/images/posts/use-alfred-workflow-ghq-with-non-default-ghq-root/ghq-failed.gif" alt="検索結果が空なデモ" />
（最後はもう諦めて Google 検索を勧めちゃってる... ググレカスってことかな...）
<h2 id="%E8%B5%B7%E7%82%B9%E3%81%AE%E4%BD%8D%E7%BD%AE%E3%81%AF-%24ghq_root-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%A1%E3%82%83%E3%81%8A%E3%81%86"><a class="header-anchor-link" href="#%E8%B5%B7%E7%82%B9%E3%81%AE%E4%BD%8D%E7%BD%AE%E3%81%AF-%24ghq_root-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%A1%E3%82%83%E3%81%8A%E3%81%86" aria-hidden="true"></a> 起点の位置は <code>$GHQ_ROOT</code> を使って指定しちゃおう</h2>
ghq の起点の指定は環境変数（その名もズバリ <code>$GHQ_ROOT</code>）を使って行うことができます。 
起点の変更を適用するために、Alfred の workflow の設定をいじってこの環境変数も追加で読み込ませてしまいましょう。
Alfred の設定画面から「Workflows &gt; alfred-workflow-ghq」を選ぶとこのような画面になります。
<img src="/images/posts/use-alfred-workflow-ghq-with-non-default-ghq-root/alfred-preference.png" alt="alfred-workflow-ghqの設定画面" />
右上の <code>[χ]</code> のボタンから環境変数の設定画面を開くことができます。 
<code>GHQ_ROOT</code> を追加して、Value に指定したい ghq の起点の位置を指定しましょう。
<img src="/images/posts/use-alfred-workflow-ghq-with-non-default-ghq-root/ghq-root-setting.png" alt="環境変数の設定画面" />
これで <code>ghq</code> コマンドを呼び出すときに普段使っている起点の位置が使われるようになりました。 
ghq on Alfred の仕組みの完成です！
<img src="/images/posts/use-alfred-workflow-ghq-with-non-default-ghq-root/ghq-successed.gif" alt="検索に成功したデモ" />
<h2 id="%EF%BC%88%E4%BD%99%E8%AB%87%EF%BC%89%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%82%E5%87%BA%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F"><a class="header-anchor-link" href="#%EF%BC%88%E4%BD%99%E8%AB%87%EF%BC%89%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%82%E5%87%BA%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F" aria-hidden="true"></a> （余談）プルリクも出しました</h2>
同じようにハマる人が少しでも減るように、この設定に気付きやすくするプルリクを作りました。
<iframe id="zenn-embedded__f6825c6d74e47" src="https://embed.zenn.studio/card#zenn-embedded__f6825c6d74e47" data-content="https%3A%2F%2Fgithub.com%2Fjackchuka%2Falfred-workflow-ghq%2Fpull%2F2" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/jackchuka/alfred-workflow-ghq/pull/2" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/jackchuka/alfred-workflow-ghq/pull/2</a>
このプルリクがマージされてリリースされると、ワークフローの初期設定画面で <code>GHQ_ROOT</code> の設定を書き換えられることに気付きやすくなります。 
「alfred-workflow-ghq 動かない」とかでググる僕みたいな人が少しでも減るといいですね。
（2021年10月19日追記） 
こちらのプルリクは無事にマージされて、リリースも追加されていました。 
これで僕と同じようにハマる人が減るはず...！
<h2 id="%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AE%E6%97%85%E3%81%AF%E3%81%BE%E3%81%A0%E3%81%BE%E3%81%A0%E7%B6%9A%E3%81%8F..."><a class="header-anchor-link" href="#%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AE%E6%97%85%E3%81%AF%E3%81%BE%E3%81%A0%E3%81%BE%E3%81%A0%E7%B6%9A%E3%81%8F..." aria-hidden="true"></a> 開発環境の改善の旅はまだまだ続く...</h2>
今回はちょっとした tips として、ghq + Alfred な仕組みづくりで私がハマった問題とその解決策をお伝えしました。
クラッソーネでは、リポジトリへのアクセス方法に限らずさまざまな開発環境改善が大好きなエンジニアを大募集中です。 
少しでも興味を持っていただけた方、ぜひ私とカジュアル面談でお話ししましょう！
<iframe id="zenn-embedded__103657ff9d1ac" src="https://embed.zenn.studio/card#zenn-embedded__103657ff9d1ac" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>

こんにちは、バックエンドエンジニアの山口拓弥（@yamat47）です。

ようやくコロナ禍もちょっとずつ落ち着いてきましたね！
私は週末は Brandings というチームでアメフトをプレーしていますが、大会の開幕まで一ヶ月を切ってかなり緊張しています...。
主将としてのファーストシーズン、なんならコロナが再燃するまでの束の間の期間かもしれないので、雨にも日焼けにも負けず思いっきり取り組んでいます！

https://twitter.com/Brandings_team/status/1445237814581284865

（写真は一昨年のものですが、寝っ転がっているのが私です）

とっても便利な CLI ツール ghq
さて、みなさんは ghq という CLI ツールを知っているでしょうか？
clone してきたローカルのリポジトリをとってもいい感じに管理してくれるツールで、peco などのフィルターと組み合わせて使っている方も多いと思います。

https://github.com/x-motemen/ghq

Rubyist の皆さんなら gem-src と組み合わせて、bundle install するたびに Gem のソースコードを全部 ghq の管理下に置いていますかね。
ちょっとしたデバッグにとても強力なので、もしまだしていない方は gem-src の README や @koic さんのスライドを参考にぜひ一度試してみてください！

https://github.com/amatsuda/gem-src

@slideshare

ghq + Alfred = ∞
そんな ghq ですが、ランチャーアプリの Alfred と組み合わせて使うとさらに強力なツールになります。
Alfred の workflow 機能を使うと「Alfred 起動 → ghq xxx でリポジトリを選択する → すぐに Visual Studio Code で起動」という流れを滑らかに行うことができます。

workflow を自前で作ってもいいのですが、私は alfred-workflow-ghq を使っています。
最新リリースの ghq.alfredworkflow ファイルをダウンロードして開くだけで使える、とっても手軽なパッケージなのが好きな理由です。

https://github.com/jackchuka/alfred-workflow-ghq

今回の記事はこの alfred-workflow-ghq を使うときのちょっとした tips の紹介です！

前提知識：ghq は起点となるディレクトリを自由に設定できる
詳しくは README を読んでいただくのがよいですが、ghq には clone してきたリポジトリをどこに配置するかを指定する仕組みが備わっています。
デフォルトは ~/ghq ですが、さまざまな方法でこれを変えることができます。

私の場合は .gitconfig を使って ~/src をこの起点に設定しています。

┏╸~
┗╸❯❯❯ ghq root
/Users/takuya_yamaguchi/src

alfred-workflow-ghq はそのままだと ghq の起点の変更を適用してくれない
この辺りのコード を読むとわかりますが、alfred-workflow-ghq はとても素朴な shell script です。
また ghq を呼び出すための PATH 設定すら書かれていることから分かる通り、Alfred の workflow が呼び出すシェルはユーザー設定が全く読み込まれていません。

このままだと ghq コマンドはデフォルトの状態で呼び出されることになります。
すなわち ↑ で紹介した起点の変更は有効にならず、デフォルトの ~/ghq を起点としてコマンドが実行されてしまいます。
これでは検索結果が常に空になってしまい、なんとも悲しいコマンドになってしまいます...。

検索結果が空なデモ

（最後はもう諦めて Google 検索を勧めちゃってる... ググレカスってことかな...）

起点の位置は $GHQ_ROOT を使って指定しちゃおう
ghq の起点の指定は環境変数（その名もズバリ $GHQ_ROOT）を使って行うことができます。
起点の変更を適用するために、Alfred の workflow の設定をいじってこの環境変数も追加で読み込ませてしまいましょう。

Alfred の設定画面から「Workflows > alfred-workflow-ghq」を選ぶとこのような画面になります。

alfred-workflow-ghqの設定画面

右上の [χ] のボタンから環境変数の設定画面を開くことができます。
GHQ_ROOT を追加して、Value に指定したい ghq の起点の位置を指定しましょう。

環境変数の設定画面

これで ghq コマンドを呼び出すときに普段使っている起点の位置が使われるようになりました。
ghq on Alfred の仕組みの完成です！

検索に成功したデモ

（余談）プルリクも出しました
同じようにハマる人が少しでも減るように、この設定に気付きやすくするプルリクを作りました。

https://github.com/jackchuka/alfred-workflow-ghq/pull/2

このプルリクがマージされてリリースされると、ワークフローの初期設定画面で GHQ_ROOT の設定を書き換えられることに気付きやすくなります。
「alfred-workflow-ghq 動かない」とかでググる僕みたいな人が少しでも減るといいですね。

（2021年10月19日追記）
こちらのプルリクは無事にマージされて、リリースも追加されていました。
これで僕と同じようにハマる人が減るはず...！

開発環境の改善の旅はまだまだ続く...
今回はちょっとした tips として、ghq + Alfred な仕組みづくりで私がハマった問題とその解決策をお伝えしました。

クラッソーネでは、リポジトリへのアクセス方法に限らずさまざまな開発環境改善が大好きなエンジニアを大募集中です。
少しでも興味を持っていただけた方、ぜひ私とカジュアル面談でお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


ghqのルート設定を変えたらalfred-workflow-ghqが動かなくなった

こんにちは、バックエンドエンジニアの山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
ここ最近は <a href="https://www.jp.square-enix.com/octopathtraveler/" target="_blank" rel="nofollow noopener noreferrer">オクトパストラベラー</a> というちょっと昔のゲームに思いっきりハマっていて、気付いたら100時間以上もやりこんでいました。 
しかしそれもついにお盆で完結してしまって、なんだか心にぽっかり穴が空いた日々を過ごしています...。
<iframe id="zenn-embedded__db61c2d7dd06a" src="https://embed.zenn.studio/tweet#zenn-embedded__db61c2d7dd06a" data-content="https%3A%2F%2Ftwitter.com%2Fyamat47%2Fstatus%2F1425493827616342017" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://twitter.com/yamat47/status/1425493827616342017" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://twitter.com/yamat47/status/1425493827616342017</a>
さて今回は、くらそうね開発チームでのRuboCopに関する改善活動の様子をお伝えします。 
RuboCopの導入以来ずっと放置してしまっていた <code>.rubocop_todo.yml</code> をこの半年で（ほぼ）全て解消したのですが、そのために取り組んできたことをご紹介します！
<h2 id="rubocop%E3%81%A8-.rubocop_todo.yml-%E3%81%AE%E3%81%8A%E3%81%95%E3%82%89%E3%81%84"><a class="header-anchor-link" href="#rubocop%E3%81%A8-.rubocop_todo.yml-%E3%81%AE%E3%81%8A%E3%81%95%E3%82%89%E3%81%84" aria-hidden="true"></a> RuboCopと <code>.rubocop_todo.yml</code> のおさらい</h2>
<a href="https://docs.rubocop.org/" target="_blank" rel="nofollow noopener noreferrer">RuboCop</a> とはいわゆるRubyのリンターです。 
一度CIに設定しておけば「インデントは揃えてね」といった瑣末なコードレビューをせずとも最低限の質が保たれていくため、Rubyを使っているプロジェクトなら大抵の場合は導入されているのではないでしょうか。
RuboCopの便利さの紹介は今回の主題ではないので割愛するとして... 
RuboCopを導入・運用していく上で大切なファイルの一つが <code>.rubocop_todo.yml</code> です。
<code>.rubocop_todo.yml</code> とはRuboCopにおける設定ファイルの一つで、現状のコードが違反してしまっているルール（cop）を無効にすることができます。 
ただしあくまでも「Todo」なので、ルール自体を利用しないというよりは「後で直すよ」というニュアンスを含んだ無効の設定です。
RuboCopを導入するタイミングでいきなり全てのルール違反に対応するのはとても大変です。 
<code>gem install rubocop</code> をしたらまず最初に <code>rubocop --auto-gen-config</code> をして、現状の違反は全て無視する = 今後のファイル変更だけチェックさせるように設定することも多そうです。
<h2 id="%E3%81%8F%E3%82%89%E3%81%9D%E3%81%86%E3%81%AD%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A8rubocop%E3%81%AE%E5%87%BA%E4%BC%9A%E3%81%84"><a class="header-anchor-link" href="#%E3%81%8F%E3%82%89%E3%81%9D%E3%81%86%E3%81%AD%E9%96%8B%E7%99%BA%E3%83%81%E3%83%BC%E3%83%A0%E3%81%A8rubocop%E3%81%AE%E5%87%BA%E4%BC%9A%E3%81%84" aria-hidden="true"></a> くらそうね開発チームとRuboCopの出会い</h2>
くらそうね開発チームでは2019年12月20日にRuboCopを導入しました。 
<code>rails new</code> をしたのがその年の5月8日でしたので、半年以上経ってから使い始めたことになります。
私が入社する前の話なので当時の詳しい経緯はわからないことも多いのですが... 
多くの例に漏れず導入直後に <code>.rubocop_todo.yml</code> を自動生成しつつ、それ以降に修正されるコードに対してチェックしていく方針で運用をしていました。
<img src="/images/posts/resolve-rubocop-todos-step-by-step/rubocop-installed.png" alt="RuboCopを導入したときのコミット" />
自動生成した時点の <code>.rubocop_todo.yml</code> は 1239行 ありました。 
そこから約一年ほど、Todoが解消されることはなくむしろ少しずつ増えていってしまう日々が続いていました...。
<h2 id="%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6rubocop%E3%81%AEtodo%E3%82%92%E8%A7%A3%E6%B6%88%E3%81%97%E3%81%A6%E3%81%84%E3%81%A3%E3%81%9F%E3%81%AE%EF%BC%9F"><a class="header-anchor-link" href="#%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6rubocop%E3%81%AEtodo%E3%82%92%E8%A7%A3%E6%B6%88%E3%81%97%E3%81%A6%E3%81%84%E3%81%A3%E3%81%9F%E3%81%AE%EF%BC%9F" aria-hidden="true"></a> どうやってRuboCopのTodoを解消していったの？</h2>
放置されること幾年月、昨年の年末に一念発起してRuboCopのTodoを本格的に解消し始めました。 
そこから半年ほどかけてTodoを解消してきましたが、その間の <code>.rubocop_todo.yml</code> の行数の推移はこんな感じでした：
<img src="/images/posts/resolve-rubocop-todos-step-by-step/change-in-line-numbers.svg" alt=".rubocop_todo.ymlの行数の推移" />
以降、Todoの解消のために具体的に行ったことを紹介していきます。
<h3 id="todo%E3%82%92%E8%A7%A3%E6%B6%88%E3%81%99%E3%82%8B%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%8C%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AB%E8%87%AA%E5%8B%95%E3%81%A7%E4%BD%9C%E3%82%89%E3%82%8C%E3%82%8B%E4%BB%95%E7%B5%84%E3%81%BF%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%9F"><a class="header-anchor-link" href="#todo%E3%82%92%E8%A7%A3%E6%B6%88%E3%81%99%E3%82%8B%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%8C%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AB%E8%87%AA%E5%8B%95%E3%81%A7%E4%BD%9C%E3%82%89%E3%82%8C%E3%82%8B%E4%BB%95%E7%B5%84%E3%81%BF%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%9F" aria-hidden="true"></a> Todoを解消するプルリクエストが定期的に自動で作られる仕組みを作った</h3>
「怠慢な」チームであるために、まず考えるのは自動化でした。 
RuboCop ChallengerというライブラリをGitHub Actionsと組み合わせて、残っているTodoのうちの一つを解消するプルリクエストが毎週月曜日に自動で作られる仕組みを作りました。
<iframe id="zenn-embedded__c1a79d0fab3ff" src="https://embed.zenn.studio/card#zenn-embedded__c1a79d0fab3ff" data-content="https%3A%2F%2Fgithub.com%2Fryz310%2Frubocop_challenger" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://github.com/ryz310/rubocop_challenger" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://github.com/ryz310/rubocop_challenger</a>
ドキュメントがしっかりしているので実装で困ることはなさそうですが、GitHub Actionsでの仕組みづくりの勘所は別の記事にまとめています。 
よければ参考にしてください。
<iframe id="zenn-embedded__bc3a9f4df99b8" src="https://embed.zenn.studio/card#zenn-embedded__bc3a9f4df99b8" data-content="https%3A%2F%2Fzenn.dev%2Fyamat47%2Farticles%2F219e14ebcf31a1d13ff4" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://zenn.dev/yamat47/articles/219e14ebcf31a1d13ff4" style="display:none" target="_blank">https://zenn.dev/yamat47/articles/219e14ebcf31a1d13ff4</a>
先ほどの行数推移の画像の一部の期間では減っていく割合が大体一定でしたが、これはこの自動化の仕組みに乗って解消し続けていた表れです。 
人が行わなければならない活動をなるべく小さくすることで、無理なく続けることができました。
RuboCop Challengerを導入したプルリクエストも紹介しておきます：
<img src="/images/posts/resolve-rubocop-todos-step-by-step/pull-request-for-integrate-rubocop-challenger.png" alt="RuboCop Challengerを導入したプルリク" />
他にも「RuboCop Challengeとは？」という内容のドキュメントをつくり、チーム内での啓蒙も行いました。 
この活動はコードを介してチームメイト全員に強い影響があるものなので、どうやったら自分ごとにしてもらえるか（最低限関心を持ってもらえるか）という視点での仕組み作りが目的でした。
<img src="/images/posts/resolve-rubocop-todos-step-by-step/document-for-rubocop-challenger.png" alt="RuboCop Challengerのドキュメント" />
それでも緊急対応が続いて業務が逼迫していた期間は全く対応できず、プルリクエストが放置されて続けていました。 
ここまで整えてもそんな状況だったので、手動での削除を続けていたらどうなっていたことやら...
また慣れてきたらプルリクエストを自動で作る頻度を増やしました。 
これも最初に仕組みを丁寧に使ったことで、GitHub Actionsの設定ファイルを少し書き換えるだけで対応することができました。
<h3 id="%E7%B5%90%E5%B1%80%E3%81%AF%E6%99%82%E9%96%93%E3%82%92%E3%81%A8%E3%81%A3%E3%81%A6%E6%89%8B%E5%8B%95%E3%81%A7%E4%B8%80%E6%B0%97%E3%81%AB%E8%A7%A3%E6%B6%88%E3%81%97%E3%81%9F"><a class="header-anchor-link" href="#%E7%B5%90%E5%B1%80%E3%81%AF%E6%99%82%E9%96%93%E3%82%92%E3%81%A8%E3%81%A3%E3%81%A6%E6%89%8B%E5%8B%95%E3%81%A7%E4%B8%80%E6%B0%97%E3%81%AB%E8%A7%A3%E6%B6%88%E3%81%97%E3%81%9F" aria-hidden="true"></a> 結局は時間をとって手動で一気に解消した</h3>
RuboCop Challengerで解消できるのは <a href="https://docs.rubocop.org/rubocop/1.1/usage/auto_correct.html" target="_blank" rel="nofollow noopener noreferrer">RuboCopの自動修正機能</a> が有効なルールに限られます。 
いくつかのルールは自動修正に対応しておらず、それらは人が手動で解消する必要がありました。
それであれば...ということで、仕事の余裕ができたタイミングで一気に手動で解消をしました。 
ルールを一つずつ確認しつつ、次の手順でコード全体を確認していきました。
<ol>
<li><code>rubocop --auto-gen-config</code> をして設定ファイル群を最新の状態にする。</li>
<li>一つルールを選んでルールを無効にするかTodoを解消するか判断する。それに従って <code>.rubocop.yml</code> か <code>.rubocop_todo.yml</code> を編集する。</li>
<li><code>rubocop -A</code> をして（自動修正されることを期待しつつ）違反している部分を確認する。</li>
<li>自動修正されなかった箇所のコードを確認して違反しない形に直す。</li>
<li>差分を確認して <code>git commit</code>。</li>
</ol>
この中だと「一つルールを選んでルールを永久に無効にするかTodoを解消するか判断する。」というステップが一番大切です。 
<a href="https://docs.rubocop.org/rubocop/1.1/configuration.html#automatically-generated-configuration" target="_blank" rel="nofollow noopener noreferrer">公式のドキュメント</a> にもありますが、Todoは全てを解消しなければならないわけではありません。 
そもそもそのルール自体がチームのスタイルに合わない場合はルール自体を無効にしましょう。 
自動修正されるプルリクエストをレビューするときも、この視点は欠かさないようにしました（実際にルール自体を無効にしたこともありました）。
RuboCop Challengerのおかげで違反しているファイル数が少ないものが残っていたので、一つ一つの解消にはそこまで時間はかかりませんでした。 
当時のコミットの履歴はこんな感じです：
<img src="/images/posts/resolve-rubocop-todos-step-by-step/commit-histories.png" alt="手動で対応した履歴" />
行数の推移の画像での最後の期間は傾きがやや不規則でしたが、手動での解消に取り組んでいたのがその理由です。 
自動で解消できるものがなくなって以降はRuboCop Challengerの仕組みが不要になったので、最後は削除してしまいました。
<img src="/images/posts/resolve-rubocop-todos-step-by-step/good-bye-rubocop-challenger.png" alt="手動で対応した履歴" />
ありがとう、RuboCop Challenger...!!
<h2 id="%E6%9C%80%E7%B5%82%E7%9A%84%E3%81%AB%E3%80%811239%E8%A1%8C%E3%81%82%E3%81%A3%E3%81%9Ftodo%E3%82%9219%E8%A1%8C%E3%81%BE%E3%81%A7%E6%B8%9B%E3%82%89%E3%81%9B%E3%81%BE%E3%81%97%E3%81%9F%EF%BC%81"><a class="header-anchor-link" href="#%E6%9C%80%E7%B5%82%E7%9A%84%E3%81%AB%E3%80%811239%E8%A1%8C%E3%81%82%E3%81%A3%E3%81%9Ftodo%E3%82%9219%E8%A1%8C%E3%81%BE%E3%81%A7%E6%B8%9B%E3%82%89%E3%81%9B%E3%81%BE%E3%81%97%E3%81%9F%EF%BC%81" aria-hidden="true"></a> 最終的に、1239行あったTodoを19行まで減らせました！</h2>
こうした活動の結果、半年かけてTodoを19行にまで減らせました！ 
自動修正を活用したところも多くありましたが、65分の1にまでTodoを減らせたということで一定の成果を挙げられたかなと思っています。
半年間の活動の様子を行数の推移と照らし合わせるとこんな感じです：
<img src="/images/posts/resolve-rubocop-todos-step-by-step/change-in-line-numbers-with-comments.svg" alt="手動で対応した履歴" />
ちなみに、唯一残してしまっているTodoは <a href="https://docs.rubocop.org/rubocop/cops_naming.html#namingmemoizedinstancevariablename" target="_blank" rel="nofollow noopener noreferrer">Naming/MemoizedInstanceVariableName</a> というルールについてのものです。 
もちろん機械的に対応することはできますが、特にコントローラーでの変数名の変更の影響が読みづらく二の足を踏んでしまっています。 
自動テストがもうちょっと充実してきたら、CIの結果を踏まえて自信を持って対応するつもりです！
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB"><a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
今回はくらそうね開発チームにおけるRuboCopのTodoの解消への取り組みについてお伝えしました。
もちろんTodoの解消自体は目的ではありません。 
プロジェクトによって様々な考え方があるとは思いますが、私たちの場合は「RuboCopの設定の棚卸し」がその大きな理由でした。 
どのルールを有効にしていてどのファイルがTodoとして残っているのかわかりづらい状態だったのを整理できたので、半年間取り組んできた成果はそこそこあったのかなと感じています。
クラッソーネでは（RuboCopに限らず）開発環境改善やCIの改善に興味があるエンジニアを大募集中です。 
興味を持っていただけた方、ぜひ私と一度カジュアル面談でお話ししましょう！
<iframe id="zenn-embedded__bda1558078d24" src="https://embed.zenn.studio/card#zenn-embedded__bda1558078d24" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>

こんにちは、バックエンドエンジニアの山口拓弥（@yamat47）です。

ここ最近は オクトパストラベラー というちょっと昔のゲームに思いっきりハマっていて、気付いたら100時間以上もやりこんでいました。
しかしそれもついにお盆で完結してしまって、なんだか心にぽっかり穴が空いた日々を過ごしています...。

https://twitter.com/yamat47/status/1425493827616342017

さて今回は、くらそうね開発チームでのRuboCopに関する改善活動の様子をお伝えします。
RuboCopの導入以来ずっと放置してしまっていた .rubocop_todo.yml をこの半年で（ほぼ）全て解消したのですが、そのために取り組んできたことをご紹介します！

RuboCopと .rubocop_todo.yml のおさらい
RuboCop とはいわゆるRubyのリンターです。
一度CIに設定しておけば「インデントは揃えてね」といった瑣末なコードレビューをせずとも最低限の質が保たれていくため、Rubyを使っているプロジェクトなら大抵の場合は導入されているのではないでしょうか。

RuboCopの便利さの紹介は今回の主題ではないので割愛するとして...
RuboCopを導入・運用していく上で大切なファイルの一つが .rubocop_todo.yml です。

.rubocop_todo.yml とはRuboCopにおける設定ファイルの一つで、現状のコードが違反してしまっているルール（cop）を無効にすることができます。
ただしあくまでも「Todo」なので、ルール自体を利用しないというよりは「後で直すよ」というニュアンスを含んだ無効の設定です。

RuboCopを導入するタイミングでいきなり全てのルール違反に対応するのはとても大変です。
gem install rubocop をしたらまず最初に rubocop --auto-gen-config をして、現状の違反は全て無視する = 今後のファイル変更だけチェックさせるように設定することも多そうです。

くらそうね開発チームとRuboCopの出会い
くらそうね開発チームでは2019年12月20日にRuboCopを導入しました。
rails new をしたのがその年の5月8日でしたので、半年以上経ってから使い始めたことになります。

私が入社する前の話なので当時の詳しい経緯はわからないことも多いのですが...
多くの例に漏れず導入直後に .rubocop_todo.yml を自動生成しつつ、それ以降に修正されるコードに対してチェックしていく方針で運用をしていました。

RuboCopを導入したときのコミット

自動生成した時点の .rubocop_todo.yml は 1239行 ありました。
そこから約一年ほど、Todoが解消されることはなくむしろ少しずつ増えていってしまう日々が続いていました...。

どうやってRuboCopのTodoを解消していったの？
放置されること幾年月、昨年の年末に一念発起してRuboCopのTodoを本格的に解消し始めました。
そこから半年ほどかけてTodoを解消してきましたが、その間の .rubocop_todo.yml の行数の推移はこんな感じでした：

.rubocop_todo.ymlの行数の推移

以降、Todoの解消のために具体的に行ったことを紹介していきます。

Todoを解消するプルリクエストが定期的に自動で作られる仕組みを作った
「怠慢な」チームであるために、まず考えるのは自動化でした。
RuboCop ChallengerというライブラリをGitHub Actionsと組み合わせて、残っているTodoのうちの一つを解消するプルリクエストが毎週月曜日に自動で作られる仕組みを作りました。

https://github.com/ryz310/rubocop_challenger

ドキュメントがしっかりしているので実装で困ることはなさそうですが、GitHub Actionsでの仕組みづくりの勘所は別の記事にまとめています。
よければ参考にしてください。

https://zenn.dev/yamat47/articles/219e14ebcf31a1d13ff4

先ほどの行数推移の画像の一部の期間では減っていく割合が大体一定でしたが、これはこの自動化の仕組みに乗って解消し続けていた表れです。
人が行わなければならない活動をなるべく小さくすることで、無理なく続けることができました。

RuboCop Challengerを導入したプルリクエストも紹介しておきます：

RuboCop Challengerを導入したプルリク

他にも「RuboCop Challengeとは？」という内容のドキュメントをつくり、チーム内での啓蒙も行いました。
この活動はコードを介してチームメイト全員に強い影響があるものなので、どうやったら自分ごとにしてもらえるか（最低限関心を持ってもらえるか）という視点での仕組み作りが目的でした。

RuboCop Challengerのドキュメント

それでも緊急対応が続いて業務が逼迫していた期間は全く対応できず、プルリクエストが放置されて続けていました。
ここまで整えてもそんな状況だったので、手動での削除を続けていたらどうなっていたことやら...

また慣れてきたらプルリクエストを自動で作る頻度を増やしました。
これも最初に仕組みを丁寧に使ったことで、GitHub Actionsの設定ファイルを少し書き換えるだけで対応することができました。

結局は時間をとって手動で一気に解消した
RuboCop Challengerで解消できるのは RuboCopの自動修正機能 が有効なルールに限られます。
いくつかのルールは自動修正に対応しておらず、それらは人が手動で解消する必要がありました。

それであれば...ということで、仕事の余裕ができたタイミングで一気に手動で解消をしました。
ルールを一つずつ確認しつつ、次の手順でコード全体を確認していきました。

rubocop --auto-gen-config をして設定ファイル群を最新の状態にする。
一つルールを選んでルールを無効にするかTodoを解消するか判断する。それに従って .rubocop.yml か .rubocop_todo.yml を編集する。
rubocop -A をして（自動修正されることを期待しつつ）違反している部分を確認する。
自動修正されなかった箇所のコードを確認して違反しない形に直す。
差分を確認して git commit。

この中だと「一つルールを選んでルールを永久に無効にするかTodoを解消するか判断する。」というステップが一番大切です。
公式のドキュメント にもありますが、Todoは全てを解消しなければならないわけではありません。
そもそもそのルール自体がチームのスタイルに合わない場合はルール自体を無効にしましょう。
自動修正されるプルリクエストをレビューするときも、この視点は欠かさないようにしました（実際にルール自体を無効にしたこともありました）。

RuboCop Challengerのおかげで違反しているファイル数が少ないものが残っていたので、一つ一つの解消にはそこまで時間はかかりませんでした。
当時のコミットの履歴はこんな感じです：

手動で対応した履歴

行数の推移の画像での最後の期間は傾きがやや不規則でしたが、手動での解消に取り組んでいたのがその理由です。
自動で解消できるものがなくなって以降はRuboCop Challengerの仕組みが不要になったので、最後は削除してしまいました。

手動で対応した履歴

ありがとう、RuboCop Challenger...!!

最終的に、1239行あったTodoを19行まで減らせました！
こうした活動の結果、半年かけてTodoを19行にまで減らせました！
自動修正を活用したところも多くありましたが、65分の1にまでTodoを減らせたということで一定の成果を挙げられたかなと思っています。

半年間の活動の様子を行数の推移と照らし合わせるとこんな感じです：

手動で対応した履歴

ちなみに、唯一残してしまっているTodoは Naming/MemoizedInstanceVariableName というルールについてのものです。
もちろん機械的に対応することはできますが、特にコントローラーでの変数名の変更の影響が読みづらく二の足を踏んでしまっています。
自動テストがもうちょっと充実してきたら、CIの結果を踏まえて自信を持って対応するつもりです！

おわりに
今回はくらそうね開発チームにおけるRuboCopのTodoの解消への取り組みについてお伝えしました。

もちろんTodoの解消自体は目的ではありません。
プロジェクトによって様々な考え方があるとは思いますが、私たちの場合は「RuboCopの設定の棚卸し」がその大きな理由でした。
どのルールを有効にしていてどのファイルがTodoとして残っているのかわかりづらい状態だったのを整理できたので、半年間取り組んできた成果はそこそこあったのかなと感じています。

クラッソーネでは（RuboCopに限らず）開発環境改善やCIの改善に興味があるエンジニアを大募集中です。
興味を持っていただけた方、ぜひ私と一度カジュアル面談でお話ししましょう！

https://www.crassone.co.jp/recruit/engineer/


1200行あったRuboCopのTodoを半年かけて（ほぼ）解消した話

こんにちは、「くらそうね」開発チームでバックエンドエンジニアをしている山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
いきなりですが！ 
Railsエンジニアのみなさん、<code>config/routes.rb</code> ってどう書いてますか？
そもそもRailsはリソースベースのルーティング設定をとても簡単に書けますし、少し前に <a href="http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/" target="_blank" rel="nofollow noopener noreferrer">DHH流のルーティング設定</a>が周知（？）されたりもしました。 
そのため、ルーティング設定ではあまり複雑なことをしていないアプリがほとんどなのではと想像しています。
「くらそうね」でもこの考えに則り、新たに追加される設定はほぼ全てリソースフルなルーティングになっています。 
その上で最近、Constraintオブジェクトを使ったやや複雑なルーティング設定の実装をする機会があったのでその話をしてみようと思います。
<h2 id="%E6%BA%80%E3%81%9F%E3%81%97%E3%81%9F%E3%81%84%E8%A6%81%E4%BB%B6"><a class="header-anchor-link" href="#%E6%BA%80%E3%81%9F%E3%81%97%E3%81%9F%E3%81%84%E8%A6%81%E4%BB%B6" aria-hidden="true"></a> 満たしたい要件</h2>
「くらそうね」には、サービスを利用する際の参考にしていただくために、地域の解体費用の相場を表示しているページがあります。 
例えばこちらのページでは、東京都の解体工事費用の相場の情報を表示しています：
<iframe id="zenn-embedded__898f6fe6282d4" src="https://embed.zenn.studio/card#zenn-embedded__898f6fe6282d4" data-content="https%3A%2F%2Fwww.crassone.jp%2Fprice%2Ftokyo" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.jp/price/tokyo" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.jp/price/tokyo</a>
こうしたページは都道府県ごとに存在し、また相場情報などはリクエストがある度に動的に計算をしています。 
そのため静的なHTMLを返すわけにはいかず、RailsらしいMVCの仕組みを使ってレスポンスを返す必要があります。
また都道府県以外のページは準備をしていないため、こちらが想定していないパスでリクエストがあったときは404 Not Foundを返したいです。 
例えば...
<ul>
<li><code>/price/tokyo</code>, <code>/price/aichi</code> ...想定しているパスであり、それぞれ東京都と愛知県の情報を返したい。</li>
<li><code>/price/nihon</code>, <code>/price/musashi</code> ...想定していないパスであり、404 Not Foundとして扱いたい。</li>
</ul>
そして都道府県のデータはアプリのデータベース（<code>prefectures</code>テーブル）で管理されています。
<h2 id="%E3%81%93%E3%82%8C%E3%81%BE%E3%81%A7%E3%81%AE%E5%AE%9F%E8%A3%85%E6%96%B9%E6%B3%95"><a class="header-anchor-link" href="#%E3%81%93%E3%82%8C%E3%81%BE%E3%81%A7%E3%81%AE%E5%AE%9F%E8%A3%85%E6%96%B9%E6%B3%95" aria-hidden="true"></a> これまでの実装方法</h2>
ルーティング設定は素朴にシンプルにしようという考えのもと、パスの妥当性の検証も含めて具体的な処理はコントローラーに任せていました。
<div class="code-block-container"><div class="code-block-filename-container">config/routes.rb</div><pre class="language-ruby"><code class="language-ruby"># GET /price/:prefecture_slug -&gt; Price::PrefecturesController#show
Rails.application.routes.draw do
 namespace :price do
 get '/:prefecture_slug', to: 'prefectures#show'
 end
end
</code></pre></div><div class="code-block-container"><div class="code-block-filename-container">app/controllers/price/prefectures_controller.rb</div><pre class="language-ruby"><code class="language-ruby">module Price
 class PrefecturesController &lt; ApplicationController
 def show
 # もし都道府県のデータが見つからなかったときはActiveRecord::RecordNotFoundが吐かれる。
 # それを捕捉してpublic/404.htmlを返す処理はRailsに任せている。
 @prefecture = Prefecture.find_by!(slug: params[:prefecture_slug])

 # 以降、解体工事の費用の集計をするロジックが続く。
 end
 end
end
</code></pre></div>これでも満たしたい要件は問題なく満たせていましたが、よりよくできるポイントがいくつかありました。
<ul>
<li>Railsが捕捉する例外が <code>ActiveRecord::RecordNotFound</code> なこと。都道府県リストという広く周知されたものとは異なる値が指定されているのだから、ルーティング設定に沿っていないということで <code>ActionController::RoutingError</code> が吐かれるのが自然な気がする。</li>
<li><code>/price/the-legend-of-zelda</code> のような「絶対違うでしょ...」といったリクエストでも毎回コントローラー層の処理が起動してしまうこと。<code>ApplicationController</code> に様々な処理を書いている場合、無視できないコストになりそう。</li>
</ul>
調べてみるとRailsのルーティング設定を見直すことで課題を解消できそうだったので、試してみることにしました。
<h2 id="%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%A8%AD%E5%AE%9A%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%88%B6%E7%B4%84%EF%BC%88constraint%EF%BC%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%A8%AD%E5%AE%9A%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%88%B6%E7%B4%84%EF%BC%88constraint%EF%BC%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> ルーティング設定における制約（Constraint）について</h2>
Railsのルーティング設定では、制約（Constraint）を課すことでマッチするための条件を追加することができます。 
例えば <a href="https://railsguides.jp/routing.html" target="_blank" rel="nofollow noopener noreferrer">Railsガイド | Rails のルーティング</a> には次のような例が記載されています。
<blockquote>
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby">get 'photos/:id', to: 'photos#show', constraints: { id: /[A-Z]\d{5}/ }
</code></pre></div>上のルーティングは <code>/photos/A12345</code> のようなパスにはマッチしますが、<code>/photos/893</code> にはマッチしません。
</blockquote>
この例では正規表現を使ってマッチするための条件を指定していましたが、制約を課す方法はそれ以外にも様々あります。 
そのうちの一つに「<code>matches?</code>に応答できるConstraintオブジェクトを渡す」という方法があり、これを使うと例えば以下のような設定をすることができます。
<div class="code-block-container"><div class="code-block-filename-container">config/routes.rb</div><pre class="language-ruby"><code class="language-ruby">module SundayConstraint
 module_function

 # Constraintオブジェクトはmatches?メソッドが定義されていることを期待する。
 # このメソッドがtruthyな値を返すときに制約を満たしたとみなされる。
 #
 # 引数にはコントローラーなどで参照できるいわゆるrequestオブジェクトが渡されるため、
 # 例えばIPアドレスやリファラーといったリクエストの情報をもとにした制約を課すこともできる。
 # もちろんこの例のように全然関係ない条件を指定することもできる。
 def matches?(request)
 Date.current.sunday?
 end
end

Rails.application.routes.draw do
 # SundayConstraint.matches?がtruthyなときにだけ当てはまるルーティング設定。
 # ワイルドカードセグメントが指定されているため、当てはまったときはパスが丸々params[:path]に入っている。
 get '*path', to: 'enjoy_sunday#index', constraints: SundayConstraint
end
</code></pre></div><h2 id="constraint%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%92%E4%BD%BF%E3%81%86%E3%81%93%E3%81%A8%E3%81%A7%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%83%BC%E3%81%AE%E8%B2%AC%E4%BB%BB%E3%81%AE%E4%B8%80%E9%83%A8%E3%82%92%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%A8%AD%E5%AE%9A%E3%81%AB%E7%A7%BB%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F"><a class="header-anchor-link" href="#constraint%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%92%E4%BD%BF%E3%81%86%E3%81%93%E3%81%A8%E3%81%A7%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%83%BC%E3%81%AE%E8%B2%AC%E4%BB%BB%E3%81%AE%E4%B8%80%E9%83%A8%E3%82%92%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E8%A8%AD%E5%AE%9A%E3%81%AB%E7%A7%BB%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F" aria-hidden="true"></a> Constraintオブジェクトを使うことでコントローラーの責任の一部をルーティング設定に移してみた</h2>
ようやくこの記事の本題に入ります。 
Constraintオブジェクトを使った制約の指定を駆使して、コントローラーが担っていた責任範囲の一部をルーティング設定に移してみました。
<div class="code-block-container"><div class="code-block-filename-container">app/constraints/prefecture_constraint.rb</div><pre class="language-ruby"><code class="language-ruby">module PrefectureConstraint
 module_function

 # 想定通りな値がprefecture_slugとして渡ってきたかどうかを判定する。
 def matches?(request)
 Prefecture.exists?(slug: request.params[:prefecture_slug])
 end
end
</code></pre></div><div class="code-block-container"><div class="code-block-filename-container">config/routes.rb</div><pre class="language-ruby"><code class="language-ruby">Rails.application.routes.draw do
 namespace :price do
 # constraintsを指定することで、想定していないパスへのリクエストがこの設定に当てはまらないようにする。
 # その結果ActionController::RoutingErrorが発生し、
 # コントローラーを経由することなく404 Not Foundを返すことができる。
 get '/:prefecture_slug', to: 'prefectures#show', constraints: PrefectureConstraint
 end
end
</code></pre></div>このように変更したことで、ルーティング設定とコントローラーとの責任範囲を次のように明確にすることができました。 
ルーティング設定が担う役割が広がったことで、肥大化しやすいコントローラーの責務の一部を他に任せることができました。
<ul>
<li>ルーティング設定：リクエストが想定通りな形かどうかを判別する。</li>
<li>コントローラー：想定通りなリクエストに対してレスポンスを作って返す。</li>
</ul>
責任範囲を明確にすることは自動テストで担保する事柄を明確にすることにもつながります。 
RSpecでいうところのrouting spec, request spec, system specのそれぞれで何を検証していくのか、整理しやすい状態にすることができました。
<h2 id="%E8%89%B2%E3%80%85%E3%81%A8%E8%9B%87%E8%B6%B3%E3%81%AA%E8%A9%B1"><a class="header-anchor-link" href="#%E8%89%B2%E3%80%85%E3%81%A8%E8%9B%87%E8%B6%B3%E3%81%AA%E8%A9%B1" aria-hidden="true"></a> 色々と蛇足な話</h2>
上で挙げた実装例ですが、せっかくコントローラーを経由しないで判別しているにも関わらずConstraintオブジェクトが毎回データベースにアクセスするのはもったいないです。 
そこで実際にリリースしたコードでは、想定している値のリストを事前にCSVに吐き出し、それを使って想定通りのリクエストかどうかを判定しています。 
「Constraintオブジェクトの紹介」という本題からはそれるため、実装例ではシンプルさを優先して実際の形とは変えていました。
アプリが肥大化するに従って、ScaffoldしたばかりのようなRailsの最低限の構成では管理しきれないことが増えてきます。 
<a href="https://speakerdeck.com/toshimaru/how-to-deal-with-fat-model" target="_blank" rel="nofollow noopener noreferrer">Fat Modelの倒し方</a> などに表されるようにModelやControllerの複雑さに対する対処法は様々議論されていますが、ルーティングの複雑さと戦う記事はあまり見つけられていません。 
もし皆さまおすすめの記事や書籍などあればぜひ教えてください！
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB"><a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
今回はRailsのルーティング設定というちょっと地味なテーマで記事を書いてみました。 
こうしたほぼ静的なページはWordpressなどのCMSで管理しているチームも多いと思いますが、少しでもRailsエンジニアの皆さまの参考になれば嬉しいです。
クラッソーネでは、ConstraintオブジェクトのようなRailsのちょっとマイナーな機能が好きなエンジニアを大募集中です。 
少しでも興味がある方、ぜひ一緒にRailsガイド片手にカジュアル面談で語り合いましょう！
<iframe id="zenn-embedded__05ac1ef61bb5a" src="https://embed.zenn.studio/card#zenn-embedded__05ac1ef61bb5a" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>

こんにちは、「くらそうね」開発チームでバックエンドエンジニアをしている山口拓弥（@yamat47）です。

いきなりですが！
Railsエンジニアのみなさん、config/routes.rb ってどう書いてますか？

そもそもRailsはリソースベースのルーティング設定をとても簡単に書けますし、少し前に DHH流のルーティング設定が周知（？）されたりもしました。
そのため、ルーティング設定ではあまり複雑なことをしていないアプリがほとんどなのではと想像しています。

「くらそうね」でもこの考えに則り、新たに追加される設定はほぼ全てリソースフルなルーティングになっています。
その上で最近、Constraintオブジェクトを使ったやや複雑なルーティング設定の実装をする機会があったのでその話をしてみようと思います。

満たしたい要件
「くらそうね」には、サービスを利用する際の参考にしていただくために、地域の解体費用の相場を表示しているページがあります。
例えばこちらのページでは、東京都の解体工事費用の相場の情報を表示しています：

https://www.crassone.jp/price/tokyo

こうしたページは都道府県ごとに存在し、また相場情報などはリクエストがある度に動的に計算をしています。
そのため静的なHTMLを返すわけにはいかず、RailsらしいMVCの仕組みを使ってレスポンスを返す必要があります。

また都道府県以外のページは準備をしていないため、こちらが想定していないパスでリクエストがあったときは404 Not Foundを返したいです。
例えば...

/price/tokyo, /price/aichi ...想定しているパスであり、それぞれ東京都と愛知県の情報を返したい。
/price/nihon, /price/musashi ...想定していないパスであり、404 Not Foundとして扱いたい。

そして都道府県のデータはアプリのデータベース（prefecturesテーブル）で管理されています。

これまでの実装方法
ルーティング設定は素朴にシンプルにしようという考えのもと、パスの妥当性の検証も含めて具体的な処理はコントローラーに任せていました。

GET /price/:prefecture_slug -> Price::PrefecturesController#show
Rails.application.routes.draw do
  namespace :price do
    get '/:prefecture_slug', to: 'prefectures#show'
  end
end

module Price
  class PrefecturesController  > get 'photos/:id', to: 'photos#show', constraints: { id: /[A-Z]\d{5}/ }
> >
> 上のルーティングは /photos/A12345 のようなパスにはマッチしますが、/photos/893 にはマッチしません。

この例では正規表現を使ってマッチするための条件を指定していましたが、制約を課す方法はそれ以外にも様々あります。
そのうちの一つに「matches?に応答できるConstraintオブジェクトを渡す」という方法があり、これを使うと例えば以下のような設定をすることができます。

module SundayConstraint
  module_function

Constraintオブジェクトはmatches?メソッドが定義されていることを期待する。
このメソッドがtruthyな値を返すときに制約を満たしたとみなされる。

引数にはコントローラーなどで参照できるいわゆるrequestオブジェクトが渡されるため、
例えばIPアドレスやリファラーといったリクエストの情報をもとにした制約を課すこともできる。
もちろんこの例のように全然関係ない条件を指定することもできる。
  def matches?(request)
    Date.current.sunday?
  end
end

Rails.application.routes.draw do
SundayConstraint.matches?がtruthyなときにだけ当てはまるルーティング設定。
ワイルドカードセグメントが指定されているため、当てはまったときはパスが丸々params[:path]に入っている。
  get '*path', to: 'enjoy_sunday#index', constraints: SundayConstraint
end

Constraintオブジェクトを使うことでコントローラーの責任の一部をルーティング設定に移してみた
ようやくこの記事の本題に入ります。
Constraintオブジェクトを使った制約の指定を駆使して、コントローラーが担っていた責任範囲の一部をルーティング設定に移してみました。

module PrefectureConstraint
  module_function

想定通りな値がprefecture_slugとして渡ってきたかどうかを判定する。
  def matches?(request)
    Prefecture.exists?(slug: request.params[:prefecture_slug])
  end
end

Rails.application.routes.draw do
  namespace :price do
constraintsを指定することで、想定していないパスへのリクエストがこの設定に当てはまらないようにする。
その結果ActionController::RoutingErrorが発生し、
コントローラーを経由することなく404 Not Foundを返すことができる。
    get '/:prefecture_slug', to: 'prefectures#show', constraints: PrefectureConstraint
  end
end

このように変更したことで、ルーティング設定とコントローラーとの責任範囲を次のように明確にすることができました。
ルーティング設定が担う役割が広がったことで、肥大化しやすいコントローラーの責務の一部を他に任せることができました。

ルーティング設定：リクエストが想定通りな形かどうかを判別する。
コントローラー：想定通りなリクエストに対してレスポンスを作って返す。

責任範囲を明確にすることは自動テストで担保する事柄を明確にすることにもつながります。
RSpecでいうところのrouting spec, request spec, system specのそれぞれで何を検証していくのか、整理しやすい状態にすることができました。

色々と蛇足な話
上で挙げた実装例ですが、せっかくコントローラーを経由しないで判別しているにも関わらずConstraintオブジェクトが毎回データベースにアクセスするのはもったいないです。
そこで実際にリリースしたコードでは、想定している値のリストを事前にCSVに吐き出し、それを使って想定通りのリクエストかどうかを判定しています。
「Constraintオブジェクトの紹介」という本題からはそれるため、実装例ではシンプルさを優先して実際の形とは変えていました。

アプリが肥大化するに従って、ScaffoldしたばかりのようなRailsの最低限の構成では管理しきれないことが増えてきます。
Fat Modelの倒し方 などに表されるようにModelやControllerの複雑さに対する対処法は様々議論されていますが、ルーティングの複雑さと戦う記事はあまり見つけられていません。
もし皆さまおすすめの記事や書籍などあればぜひ教えてください！

おわりに
今回はRailsのルーティング設定というちょっと地味なテーマで記事を書いてみました。
こうしたほぼ静的なページはWordpressなどのCMSで管理しているチームも多いと思いますが、少しでもRailsエンジニアの皆さまの参考になれば嬉しいです。

クラッソーネでは、ConstraintオブジェクトのようなRailsのちょっとマイナーな機能が好きなエンジニアを大募集中です。
少しでも興味がある方、ぜひ一緒にRailsガイド片手にカジュアル面談で語り合いましょう！

https://www.crassone.co.jp/recruit/engineer/


Constraintオブジェクトを使ってルーティング設定が担う役割を広げてみよう

こんにちは、バックエンドエンジニアの山口拓弥（@yamat47）です。
夏にある友人の結婚式に向けて、最近ダイエットに勤しんでいます。
消費するカロリーよりも摂取するカロリーを少なくすればいいだけなんですが、それが難しいんですよね...。

さて、くらそうねは一部を除いてほとんどがRuby on Railsで作られています。
自動テストのフレームワークはRSpecを採用しており、アプリのコードが増えるに従ってテストも段々と増えてきました。

そんなRSpecですが、書き方を誤ると途端に 実行結果が不安定なテスト が爆誕します。
この記事では、くらそうねにかつて存在したそんな不安定なテストとその解決方法をいくつかご紹介します！

（サンプルコードは適宜一般的なテーマに変えています。）

そもそも「不安定なテスト」って？
この記事で扱う不安定なテストは、具体的には以下のようなものを指しています。

実行するたびに成功したり失敗したりするテスト
実行する日付や時間帯によって成功したり失敗したりするテスト
ローカル開発環境では成功するがCI環境では失敗するテスト

また不安定なテストというトピックはRSpecに限らず他のフレームワークでも起きうる一般的な話題です。
今回はRSpecをサンプルコードとして利用しますが、普段RSpecを書かない人でも雰囲気くらいは読み取っていただけると嬉しいです！

事例１：毎週日曜日と祝日に実行すると落ちるテスト
例えばAppointmentという面談を表すクラスがあったとします。
このクラスは#scheduled_dateという属性を持ち、そこには日曜日と祝日を登録できないという制約がかかっているとします。

class Appointment  { order(created_at: :desc) }
end

そして、この追加した.orderbycreated_atについてテストを追加しました。

RSpec.describe Appointment do
  describe '.orderbycreated_at' do
    let!(:first_appointment) { Appointment.create }
    let!(:second_appointment) { Appointment.create }
    let!(:third_appointment) { Appointment.create }

    subject { Appointment.orderbycreated_at }

    it { isexpected.to eq [thirdappointment, secondappointment, firstappointment] }
  end
end

しかしこれは残念ながら不安定なテストになってしまっています...。

自動テストは基本的にはかなり高速に実行されます。
そのため、複数のレコードを順番に作っていったときに、作成日時が全く一致してしまうことがたびたびあります。
特にRailsの古いバージョンから継続して開発されているアプリの場合、データベースに保存されている時刻が秒の単位までしか保存されていないため、作成日時が全く同じレコードが複数登録されることはそこそこ頻繁に起きてしまいます。

（補足：最近のRailsではデフォルトでマイクロ秒まで保存されるようになっているため、あまりこの問題は起きないかもしれません。）

そして、同じ時刻で登録されているレコードたちを時刻の順に並べ替えるときに どんな順番でデータが取り出されるかは完全に不定です。
実行環境が異なれば違う結果になることもままあるため「ローカル開発環境では成功するテストがCIでは失敗する」といったことが起き得ます。

というわけで明示的に作成日時を与えてデータを準備するようにテストを修正しました。

RSpec.describe Appointment do
  describe '.orderbycreated_at' do
    let!(:firstappointment) { Appointment.create(createdat: Time.current) }
    let!(:secondappointment) { Appointment.create(createdat: Time.current - 1.hour) }
    let!(:thirdappointment) { Appointment.create(createdat: Time.current + 1.hour) }

    subject { Appointment.orderbycreated_at }

    it { isexpected.to eq [thirdappointment, firstappointment, secondappointment] }
  end
end

利用しているデータベースクライアントやそのバージョンによっては、引き続きこのようなケースに遭遇するかもしれません。
何をテストしたいかを明確にするためにも、必要な条件は明示的に指定するのがよいと考えています。

おわりに
今回はユニットテストを作るときに起こしてしまった不安定なテストについてお伝えしました。
くらそうねではCapybaraを利用したシステムテストも書いていますが、こちらも不安定なテストがまだまだゴロゴロ転がっています...。
こちらも鋭意修正中なので、また落ち着いたらCapybaraと仲良くする方法をこちらのブログでお伝えできたら嬉しいです！

クラッソーネではCIの結果がGreenに保ち続けたいエンジニアを大募集しています。
ご興味を持ってくださいましたら、ぜひ一度カジュアル面談でCIやRSpecについて語り合いましょう！

https://www.crassone.co.jp/recruit/engineer/


くらそうねに実在した不安定なRSpecのテストとその倒し方

こんにちは、バックエンドエンジニアの山口拓弥（<a href="https://twitter.com/yamat47" target="_blank" rel="nofollow noopener noreferrer">@yamat47</a>）です。
普段はRailsを書いていることがほとんどなので、こちらのブログでもRailsの話題を中心に発信をしていきます。 
よろしくお願いします！
<h2 id="%E7%B5%90%E6%A7%8B%E3%81%8B%E3%82%86%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AB%E6%89%8B%E3%81%8C%E5%B1%8A%E3%81%8Frails"><a class="header-anchor-link" href="#%E7%B5%90%E6%A7%8B%E3%81%8B%E3%82%86%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AB%E6%89%8B%E3%81%8C%E5%B1%8A%E3%81%8Frails" aria-hidden="true"></a> 結構かゆいところに手が届くRails</h2>
Ruby on Railsはいわゆるフルスタックなアプリケーションフレームワークです。 
<a href="https://railsguides.jp/active_record_basics.html" target="_blank" rel="nofollow noopener noreferrer">Active Record</a> や <a href="https://railsguides.jp/action_controller_overview.html" target="_blank" rel="nofollow noopener noreferrer">Action Controller</a> をはじめとする、色々なレイヤーの様々な機能を標準で提供しています。
最近では特定の用途に限定したコア機能も増えてきました。 
受信メールを扱いやすくする <a href="https://railsguides.jp/action_mailbox_basics.html" target="_blank" rel="nofollow noopener noreferrer">Action Mailbox</a>、リッチテキスト形式のデータを扱いやすくする <a href="https://railsguides.jp/action_text_overview.html" target="_blank" rel="nofollow noopener noreferrer">Action Text</a> などですね。
またRubyのコア機能を拡張する <a href="https://railsguides.jp/active_support_core_extensions.html" target="_blank" rel="nofollow noopener noreferrer">Active Support</a> の仕組みもとても強力で、Railsアプリ内ではRubyのコードを普段よりもさらに楽しく &amp; 便利に書くことができます。 
<code>#blank?</code> や <code>#present?</code> はもちろん、<code>#with_options</code> やInflectionの仕組みなどは使っているエンジニアの皆さんも多いのではないでしょうか？
アプリケーションの核となる機能とメソッドなどの細かい機能の両方で、かなり広い範囲を守っているのが今のRailsだと思っています。
<h2 id="%E3%81%9D%E3%82%8C%E3%81%A7%E3%82%82%E6%89%8B%E3%81%8C%E5%B1%8A%E3%81%8B%E3%81%AA%E3%81%84%E5%A0%B4%E9%9D%A2%E3%81%AF%E3%81%82%E3%82%8B"><a class="header-anchor-link" href="#%E3%81%9D%E3%82%8C%E3%81%A7%E3%82%82%E6%89%8B%E3%81%8C%E5%B1%8A%E3%81%8B%E3%81%AA%E3%81%84%E5%A0%B4%E9%9D%A2%E3%81%AF%E3%81%82%E3%82%8B" aria-hidden="true"></a> それでも手が届かない場面はある</h2>
それでも実際にアプリを開発していると、Railsの挙動を変えたい場面が出てくるものです。 
そのときにRailsの文脈でいうと取ることのできる選択肢は次の二つです。
<ul>
<li>モンキーパッチを当てる</li>
<li>Railsプラグインを利用する = 今日の本題</li>
</ul>
いずれもRailsのコア機能を拡張（変更）するものですが、実装の抽象化の度合いが異なります。
<table>
<thead>
<tr>
<th></th>
<th>どこに実装するの？</th>
<th>実装の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>モンキーパッチ</td>
<td>開発しているアプリの中</td>
<td><a href="http://yamakichi.hatenablog.com/entry/2016/09/24/001219" target="_blank" rel="nofollow noopener noreferrer">kaminari/kaminariにモンキーパッチを当てた例</a></td>
</tr>
<tr>
<td>Railsプラグイン</td>
<td>Gemとしてインストール</td>
<td><a href="https://github.com/yamat47/activerecord_accessible_json" target="_blank" rel="nofollow noopener noreferrer">yamat47/activerecord_accessible_json</a></td>
</tr>
</tbody>
</table>
モンキーパッチは開発しているそのアプリの中に閉じた話ですが、Railsプラグインの場合は他アプリにも転用できるような仕組みです。
この記事ではこれ以降、Railsプラグインを使ったRailsの拡張についてお伝えしていきます。 
コア実装を拡張したいと思ったときに、モンキーパッチを当てる以外にRailsプラグインを作るという選択肢もあるというのを伝えるのがこの記事の趣旨です。
<h2 id="%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82rails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%81%A3%E3%81%A6%E4%BD%95%EF%BC%9F"><a class="header-anchor-link" href="#%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82rails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%81%A3%E3%81%A6%E4%BD%95%EF%BC%9F" aria-hidden="true"></a> そもそもRailsプラグインって何？</h2>
<blockquote>
Railsのプラグインは、コアフレームワークを拡張したり変更したりするのに使用されます。プラグインは以下の機能を提供します。
<ul>
<li>安定版コードベースに手を加えることなく最先端のアイディアを開発者同士で共有する手段を提供します。</li>
<li>アーキテクチャを分割し、それらのコード単位ごとに異なるスケジュールで修正や更新を進められるようにします。</li>
<li>コア開発者が価値ある新機能を実装しても、その全てオープンにすることなく共有できるようにします。</li>
</ul>
引用：<a href="https://railsguides.jp/plugins.html" target="_blank" rel="nofollow noopener noreferrer">Rails プラグイン作成入門 - Railsガイド</a>
</blockquote>
Railsプラグインの実体はただのRubyのGemで、<code>Gemfile</code> に記載してインストールするのが基本的な使い方です。
「Railsのコア実装を拡張するのに特化した特別な実装がされているGem」と捉えると大体よいです。 
実装について特徴的なのは以下の点でしょうか：
<ul>
<li>一般的なGemは <code>bundle gem</code> コマンドから作ることが多いが、Railsプラグインは <code>rails plugin new</code> から作るのが一般的。</li>
<li>コア機能を拡張されるためにRailtieの仕組みを使うことが多い。</li>
<li>Gemのソースコードにテスト用のRailsアプリが内包されることが多い。</li>
</ul>
実際にどのようにプラグインを作っていくかは <a href="https://slides.com/sophiedeziel/extracting-a-gem-from-your-rails-app-16/fullscreen" target="_blank" rel="nofollow noopener noreferrer">Extracting a Gem from your Rails app</a> が参考になります。
<h2 id="%E3%83%A2%E3%83%B3%E3%82%AD%E3%83%BC%E3%83%91%E3%83%83%E3%83%81%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8Frails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E5%88%A9%E7%82%B9"><a class="header-anchor-link" href="#%E3%83%A2%E3%83%B3%E3%82%AD%E3%83%BC%E3%83%91%E3%83%83%E3%83%81%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8Frails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E5%88%A9%E7%82%B9" aria-hidden="true"></a> モンキーパッチではなくRailsプラグインを作る利点</h2>
Railsプラグインを自作すると、アプリの中でモンキーパッチを当てるのに比べて様々なメリットを得られます。
<h3 id="%E6%8B%A1%E5%BC%B5%E3%81%97%E3%81%9F%E5%86%85%E5%AE%B9%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%81%8C%E3%81%97%E3%82%84%E3%81%99%E3%81%84"><a class="header-anchor-link" href="#%E6%8B%A1%E5%BC%B5%E3%81%97%E3%81%9F%E5%86%85%E5%AE%B9%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%81%8C%E3%81%97%E3%82%84%E3%81%99%E3%81%84" aria-hidden="true"></a> 拡張した内容のテストがしやすい</h3>
コア実装の拡張をする以上、そのテストは実際にRailsアプリを動かして行う必要があります。 
そのためのダミーのアプリを作る仕組みやそれを使ったテストの仕組みがRailsプラグインには備わっているため、拡張した内容のテストがとてもしやすいです。
ただしRSpecでテストを書こうとすると標準の方法では難しいため、少し工夫する必要があります。 
その際は <a href="https://easyramble.com/create-rails-plugin-gem.html" target="_blank" rel="nofollow noopener noreferrer">RailsプラグインGemの作成方法、RSpecテストまで含めたrails pluginの作り方 | EasyRamble</a> という記事が参考になります。
<h3 id="%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%83%99%E3%83%BC%E3%82%B9%E3%82%92%E5%B0%8F%E3%81%95%E3%81%8F%E3%81%A7%E3%81%8D%E3%82%8B"><a class="header-anchor-link" href="#%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%83%99%E3%83%BC%E3%82%B9%E3%82%92%E5%B0%8F%E3%81%95%E3%81%8F%E3%81%A7%E3%81%8D%E3%82%8B" aria-hidden="true"></a> アプリケーションのコードベースを小さくできる</h3>
保守しやすいアプリを作る上で、アプリケーションのコードベースを小さくするのは大切なことです。
ただでさえアプリのコードはどんどん肥大化していってしまうものなので... 
開発しているアプリに特化していない内容であればどんどん外に切り出すことで、保守しやすい状態を維持できます。
<h3 id="%EF%BC%88%E3%82%82%E3%81%97%E5%85%AC%E9%96%8B%E3%81%99%E3%82%8C%E3%81%B0%EF%BC%89oss%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E5%88%A9%E7%94%A8%E3%81%A7%E3%81%8D%E3%82%8B"><a class="header-anchor-link" href="#%EF%BC%88%E3%82%82%E3%81%97%E5%85%AC%E9%96%8B%E3%81%99%E3%82%8C%E3%81%B0%EF%BC%89oss%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E5%88%A9%E7%94%A8%E3%81%A7%E3%81%8D%E3%82%8B" aria-hidden="true"></a> （もし公開すれば）OSSのエコシステムを利用できる</h3>
RailsプラグインはGemであるため、OSSとして公開することができます（もちろん公開せずに利用することもできます）。 
他のアプリでも利用してもらいフィードバックを受けることでよりライブラリを磨き上げることができます。
同じような拡張をしたい他の開発者のためにも積極的に公開したいなと思っています！
<h2 id="rails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9"><a class="header-anchor-link" href="#rails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9" aria-hidden="true"></a> Railsプラグインを作るときの注意点</h2>
一方でRailsプラグインを作るときに気をつけなければならないポイントもあります。
<h3 id="%E5%A4%A7%E8%A2%88%E8%A3%9F%E3%81%AA%E8%A9%B1%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%8C%E3%81%A1"><a class="header-anchor-link" href="#%E5%A4%A7%E8%A2%88%E8%A3%9F%E3%81%AA%E8%A9%B1%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%8C%E3%81%A1" aria-hidden="true"></a> 大袈裟な話になりがち</h3>
Railsプラグインを書くためには色々なことを考えなければなりません。 
gemspecの内容、テスト用のアプリの構成、テストの書き方、Gemを公開するか、...などなど。
ちょっとしたパッチを当てたいだけという場合でもこれだけのことを考えなければならず、大袈裟な話になりがちです。 
ただ一方でコア実装を拡張するのはそれだけ影響の大きいテーマであり、それだけ時間をかける必要があると考えています。
Railsプラグインを作るかどうかは別としてもかなり丁寧に議論をしながら拡張をするかどうかを検討することをオススメします。
<h3 id="%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%8C%E5%A2%97%E3%81%88%E3%82%8B"><a class="header-anchor-link" href="#%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%8C%E5%A2%97%E3%81%88%E3%82%8B" aria-hidden="true"></a> 管理するリポジトリが増える</h3>
「アプリに関係ないコードをソースコードから除くことができる」という利点は同時にこの懸念を生み出します。
複数リポジトリを保守していく仕組みやチームの文化が育っていない状態ではかなり慎重になることをオススメします。 
特に開発メンバーが少ないチームの場合は致命的な課題になる可能性があります。
<h2 id="%E8%87%AA%E4%BD%9C%E3%81%AErails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%81%AE%E7%B4%B9%E4%BB%8B"><a class="header-anchor-link" href="#%E8%87%AA%E4%BD%9C%E3%81%AErails%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E3%81%AE%E7%B4%B9%E4%BB%8B" aria-hidden="true"></a> 自作のRailsプラグインの紹介</h2>
上でも例にあげましたが、<a href="https://github.com/yamat47/activerecord_accessible_json" target="_blank" rel="nofollow noopener noreferrer">yamat47/activerecord_accessible_json</a> というRailsプラグインを作りました。 
詳しくはREADMEにまとめていますが、ActiveRecordのJson型カラムを扱いやすくするライブラリです。
<div class="code-block-container"><pre class="language-ruby"><code class="language-ruby"># Both author and tags are JSON typed columns.
Post.create(author: { 'name': 'yamat47', 'age': 27 }, tags: %w[Rails TDD])

post = Post.last
post.author.class #=&gt; ActiveSupport::HashWithIndifferentAccess
post.author['name'] #=&gt; 'yamat47'
post.author['name'] == post.author[:name] #=&gt; true

post.author = { name: 'Andy', age: 30 }
post.author.class #=&gt; ActiveSupport::HashWithIndifferentAccess
post.author['name'] #=&gt; 'Andy'
post.author['name'] == post.author[:name] #=&gt; true

# If attribute's value is not changeable into HashWithIndifferentAccess,
# this gem does nothing.
post.tags.class #=&gt; Array
</code></pre></div>弊社が運営している「くらそうね」はRailsを使って作られていますが、ここ最近でJson型カラムを使うケースが増えていました。 
このカラムを扱うときだけキーが文字列なのがちょっと使いづらかったので... 値にアクセスしやすくするためにRailsプラグインを作ってみました。
このライブラリの開発や運用についても色々お伝えしたいことはあるのですが、またいつかの機会にします！
<h2 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h2>
それ自体がかなり巨大になってしまっているRuby on Railsに対してコア実装を拡張するのは非常に影響が大きいです。 
だからこそ慎重に、そして丁寧に行う必要があり、そのためにRailsが準備しているレールがRailsプラグインです。
モンキーパッチを当てたいなと思ったとき、この記事とそしてRailsプラグインのことを思い出していただけると嬉しいです。 
（ほどほどな範囲で）Railsプラグインをどんどん活用して、自分たちだけのRailsを作っていきましょう！
<h2 id="%E6%9C%80%E5%BE%8C%E3%81%AB"><a class="header-anchor-link" href="#%E6%9C%80%E5%BE%8C%E3%81%AB" aria-hidden="true"></a> 最後に</h2>
クラッソーネではエンジニアを積極採用中です！ 
Railsが大好きなエンジニアの皆さんもそこそこ好きな皆さんも、興味を持っていただけたらお気軽にご連絡ください。
<iframe id="zenn-embedded__d14d629d7ee" src="https://embed.zenn.studio/card#zenn-embedded__d14d629d7ee" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a>


こんにちは、バックエンドエンジニアの山口拓弥（@yamat47）です。

普段はRailsを書いていることがほとんどなので、こちらのブログでもRailsの話題を中心に発信をしていきます。
よろしくお願いします！

結構かゆいところに手が届くRails
Ruby on Railsはいわゆるフルスタックなアプリケーションフレームワークです。
Active Record や Action Controller をはじめとする、色々なレイヤーの様々な機能を標準で提供しています。

最近では特定の用途に限定したコア機能も増えてきました。
受信メールを扱いやすくする Action Mailbox、リッチテキスト形式のデータを扱いやすくする Action Text などですね。

またRubyのコア機能を拡張する Active Support の仕組みもとても強力で、Railsアプリ内ではRubyのコードを普段よりもさらに楽しく & 便利に書くことができます。
#blank? や #present? はもちろん、#with_options やInflectionの仕組みなどは使っているエンジニアの皆さんも多いのではないでしょうか？

アプリケーションの核となる機能とメソッドなどの細かい機能の両方で、かなり広い範囲を守っているのが今のRailsだと思っています。

それでも手が届かない場面はある
それでも実際にアプリを開発していると、Railsの挙動を変えたい場面が出てくるものです。
そのときにRailsの文脈でいうと取ることのできる選択肢は次の二つです。

モンキーパッチを当てる
Railsプラグインを利用する = 今日の本題

いずれもRailsのコア機能を拡張（変更）するものですが、実装の抽象化の度合いが異なります。

| | どこに実装するの？ | 実装の例 |
| --- | --- | --- |
| モンキーパッチ | 開発しているアプリの中 | kaminari/kaminariにモンキーパッチを当てた例 |
| Railsプラグイン | Gemとしてインストール | yamat47/activerecordaccessiblejson |

モンキーパッチは開発しているそのアプリの中に閉じた話ですが、Railsプラグインの場合は他アプリにも転用できるような仕組みです。

この記事ではこれ以降、Railsプラグインを使ったRailsの拡張についてお伝えしていきます。
コア実装を拡張したいと思ったときに、モンキーパッチを当てる以外にRailsプラグインを作るという選択肢もあるというのを伝えるのがこの記事の趣旨です。

そもそもRailsプラグインって何？
> Railsのプラグインは、コアフレームワークを拡張したり変更したりするのに使用されます。プラグインは以下の機能を提供します。
>
> * 安定版コードベースに手を加えることなく最先端のアイディアを開発者同士で共有する手段を提供します。
> * アーキテクチャを分割し、それらのコード単位ごとに異なるスケジュールで修正や更新を進められるようにします。
> * コア開発者が価値ある新機能を実装しても、その全てオープンにすることなく共有できるようにします。
>
> 引用：Rails プラグイン作成入門 - Railsガイド

Railsプラグインの実体はただのRubyのGemで、Gemfile に記載してインストールするのが基本的な使い方です。

「Railsのコア実装を拡張するのに特化した特別な実装がされているGem」と捉えると大体よいです。
実装について特徴的なのは以下の点でしょうか：

一般的なGemは bundle gem コマンドから作ることが多いが、Railsプラグインは rails plugin new から作るのが一般的。
コア機能を拡張されるためにRailtieの仕組みを使うことが多い。
Gemのソースコードにテスト用のRailsアプリが内包されることが多い。

実際にどのようにプラグインを作っていくかは Extracting a Gem from your Rails app が参考になります。

モンキーパッチではなくRailsプラグインを作る利点
Railsプラグインを自作すると、アプリの中でモンキーパッチを当てるのに比べて様々なメリットを得られます。

拡張した内容のテストがしやすい
コア実装の拡張をする以上、そのテストは実際にRailsアプリを動かして行う必要があります。
そのためのダミーのアプリを作る仕組みやそれを使ったテストの仕組みがRailsプラグインには備わっているため、拡張した内容のテストがとてもしやすいです。

ただしRSpecでテストを書こうとすると標準の方法では難しいため、少し工夫する必要があります。
その際は RailsプラグインGemの作成方法、RSpecテストまで含めたrails pluginの作り方 | EasyRamble という記事が参考になります。

アプリケーションのコードベースを小さくできる
保守しやすいアプリを作る上で、アプリケーションのコードベースを小さくするのは大切なことです。

ただでさえアプリのコードはどんどん肥大化していってしまうものなので...
開発しているアプリに特化していない内容であればどんどん外に切り出すことで、保守しやすい状態を維持できます。

（もし公開すれば）OSSのエコシステムを利用できる
RailsプラグインはGemであるため、OSSとして公開することができます（もちろん公開せずに利用することもできます）。
他のアプリでも利用してもらいフィードバックを受けることでよりライブラリを磨き上げることができます。

同じような拡張をしたい他の開発者のためにも積極的に公開したいなと思っています！

Railsプラグインを作るときの注意点
一方でRailsプラグインを作るときに気をつけなければならないポイントもあります。

大袈裟な話になりがち
Railsプラグインを書くためには色々なことを考えなければなりません。
gemspecの内容、テスト用のアプリの構成、テストの書き方、Gemを公開するか、...などなど。

ちょっとしたパッチを当てたいだけという場合でもこれだけのことを考えなければならず、大袈裟な話になりがちです。
ただ一方でコア実装を拡張するのはそれだけ影響の大きいテーマであり、それだけ時間をかける必要があると考えています。

Railsプラグインを作るかどうかは別としてもかなり丁寧に議論をしながら拡張をするかどうかを検討することをオススメします。

管理するリポジトリが増える
「アプリに関係ないコードをソースコードから除くことができる」という利点は同時にこの懸念を生み出します。

複数リポジトリを保守していく仕組みやチームの文化が育っていない状態ではかなり慎重になることをオススメします。
特に開発メンバーが少ないチームの場合は致命的な課題になる可能性があります。

自作のRailsプラグインの紹介
上でも例にあげましたが、yamat47/activerecordaccessiblejson というRailsプラグインを作りました。
詳しくはREADMEにまとめていますが、ActiveRecordのJson型カラムを扱いやすくするライブラリです。

Both author and tags are JSON typed columns.
Post.create(author: { 'name': 'yamat47', 'age': 27 }, tags: %w[Rails TDD])

post = Post.last
post.author.class #=> ActiveSupport::HashWithIndifferentAccess
post.author['name'] #=> 'yamat47'
post.author['name'] == post.author[:name] #=> true

post.author = { name: 'Andy', age: 30 }
post.author.class #=> ActiveSupport::HashWithIndifferentAccess
post.author['name'] #=> 'Andy'
post.author['name'] == post.author[:name] #=> true

If attribute's value is not changeable into HashWithIndifferentAccess,
this gem does nothing.
post.tags.class #=> Array

弊社が運営している「くらそうね」はRailsを使って作られていますが、ここ最近でJson型カラムを使うケースが増えていました。
このカラムを扱うときだけキーが文字列なのがちょっと使いづらかったので... 値にアクセスしやすくするためにRailsプラグインを作ってみました。

このライブラリの開発や運用についても色々お伝えしたいことはあるのですが、またいつかの機会にします！

まとめ
それ自体がかなり巨大になってしまっているRuby on Railsに対してコア実装を拡張するのは非常に影響が大きいです。
だからこそ慎重に、そして丁寧に行う必要があり、そのためにRailsが準備しているレールがRailsプラグインです。

モンキーパッチを当てたいなと思ったとき、この記事とそしてRailsプラグインのことを思い出していただけると嬉しいです。
（ほどほどな範囲で）Railsプラグインをどんどん活用して、自分たちだけのRailsを作っていきましょう！

最後に
クラッソーネではエンジニアを積極採用中です！
Railsが大好きなエンジニアの皆さんもそこそこ好きな皆さんも、興味を持っていただけたらお気軽にご連絡ください。

https://www.crassone.co.jp/recruit/engineer/


クラッソーネ開発者ブログ

山口拓弥が執筆した記事

.orを使ってActiveRecordのスコープを定義するときは.mergeで囲わないと意図しない挙動になるかも？

自作のGemにTypeprofとSteepを使った型検査の仕組みを導入してみた

「当たり前」のことをしつづけたら四半期のMVPに選ばれた話

日本の住所を解析できるGem JapaneseAddressParserを紹介したい！

アプリのコードの修正だけでRailsサーバーを3倍早くした話

Ruby on RailsでもHLS形式で動画を再生したい！

ghqのルート設定を変えたらalfred-workflow-ghqが動かなくなった

1200行あったRuboCopのTodoを半年かけて（ほぼ）解消した話

Constraintオブジェクトを使ってルーティング設定が担う役割を広げてみよう

くらそうねに実在した不安定なRSpecのテストとその倒し方

自作のRailsプラグインで君だけのRailsを作ろう！

山口 拓弥が執筆した記事

.orを使ってActiveRecordのスコープを定義するときは.mergeで囲わないと意図しない挙動になるかも？

自作のGemにTypeprofとSteepを使った型検査の仕組みを導入してみた

「当たり前」のことをしつづけたら四半期のMVPに選ばれた話

日本の住所を解析できるGem JapaneseAddressParserを紹介したい！

アプリのコードの修正だけでRailsサーバーを3倍早くした話

Ruby on RailsでもHLS形式で動画を再生したい！

ghqのルート設定を変えたらalfred-workflow-ghqが動かなくなった

1200行あったRuboCopのTodoを半年かけて（ほぼ）解消した話

Constraintオブジェクトを使ってルーティング設定が担う役割を広げてみよう

くらそうねに実在した不安定なRSpecのテストとその倒し方

自作のRailsプラグインで君だけのRailsを作ろう！

山口拓弥が執筆した記事