<h2 id="h659bcda10e">2022年総括</h2><p>技術的にできることが増え、仕事でも任されることが増えたことで全体的に充実した1年だった。<br>特に好きな技術領域ができてさらに学習意欲が高まったので、良い流れに乗れたと思っている。<br></p><h2 id="h4f06856a49">技術的にやったこと</h2><ul><li>TypeScriptの理解を深めた</li><li>React周りのエコシステムの知見を貯めた</li><li>CTIでテーブル設計した</li><li>色々なGemの選定をした</li><li>Docker開発環境の改善をした</li><li>Linuxの勉強を始めた</li><li>本番稼働しているRuby/Railsのアップグレードをした</li></ul><p><br>特に印象に残っているのは2つ。</p><ul><li>TypeScriptの理解を深めた</li><li>CTIでテーブル設計をした</li></ul><p><br>この2つが特に印象に残っている。記事に書き下ろしている。<br><a href="https://kdevlog.com/posts/0ok_nhfllo" target="_blank" rel="noopener noreferrer">type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング</a><br><a href="https://kdevlog.com/posts/delegated-types" target="_blank" rel="noopener noreferrer">&lt;Rails&gt;Delegated typesを利用した際の知見</a><br><br>また、JavaScriptのエコシステムにかなり興味関心を持ち始めたのも大きな影響がある。<br>今まで業務でRuby / TypeScriptを書く中でどういう技術が好きというのは無かったが、昨年は明確にJavaScriptのエコシステムが好きだと認知できた。<br>大学時代にJavaScriptを使った講義で簡単なWebアプリケーションを作って動かした経験からWebの表現力に感銘を受けて、エンジニアという職業を志した。<br>その際の感銘というのが具体化して今の興味関心につながっていると考えている。<br>例えば、Webブラウザの仕組みやレンダリングのパフォーマンス、CDNや仮想DOM、WebAssemblyなどブラウザの表現力に根底から関わる部分に自分は興味があるのだと認知した。<br>この部分をもっと極めていきたいと考えている。<br></p><h2 id="hf62b1e9823">今年の目標</h2><ul><li>JavaScriptエコシステムに関する技術的なインプット/アウトプットをする</li><li>それに関するOSSにコミットする</li><li>Rustを学ぶ（Denoを読めるようになりたい）</li></ul>

2022年振り返り

<p><br></p><h2 id="h9707d3a59a">概要</h2><p>DockerのRubyイメージを上げた時にpostgresql-client 11が見つからなかった<br>その際にDebianバージョンを知ったのでそのまとめ<br></p><h2 id="h89e7b98e09">詳細</h2><p>解決策の詳細は<a href="https://kdevlog.com/posts/7oo2u06co" target="_blank" rel="noopener noreferrer">Railsアップグレードをした際の知見</a>という記事に譲るとして、ここではDebianバージョンの全体感についてまとめる。<br></p><h3 id="hc7e7a511ca">Debianのリリースカテゴリについて</h3><p><a href="https://www.debian.org/releases/" target="_blank" rel="noopener noreferrer">https://www.debian.org/releases/</a> によると、Debianはstable(安定版)、testing(テスト版)、unstable(不安定版)の3つのカテゴリに分けてリリースを管理している。<br>unstableで開発をしていき、testingで動作確認を行い、stableでプロダクションリリースを行う形とのこと。<br>現在のstableバージョンは<code>bullseye</code>であると<a href="https://www.debian.org/releases/stable/" target="_blank" rel="noopener noreferrer">公表</a>されている。現在のtestingバージョンは<code>bookworm</code>とのこと。<br></p><h3 id="he2ea858c94">DebianのLTS</h3><p>DebianのLTSはそれぞれのリリースで3年間の全面サポートと LTS による2年間の延長サポートを想定できる。<br>例えば、現在のstableである<code>bullseye</code>は2021/8/14に初版リリースされたので、そこから約5年程度はサポートがあるということ。<br>詳しくはこちら<a href="https://wiki.debian.org/LTS" target="_blank" rel="noopener noreferrer">https://wiki.debian.org/LTS</a><br></p><h2 id="ha214098e44">まとめ</h2><p>意識する回数は少ないかもしれないが、今知識として知れたことは良かったと思う。<br></p>

Debianバージョンについて

<h2 id="h9707d3a59a">概要</h2><p>本書籍では、オブジェクト指向や設計パターンなどソフトウェア設計に関する基本的な概念が紹介されている。<br>章ごとに読んだ感想を述べていく。<br></p><h2 id="h28de596f4c">CHAPTER1: 小さくまとめてわかりやすくする</h2><p>ソフトウェアは常に変更され得るから、変更しやすいコードを書くには何を意識すべきかがまとめられている。<br>分かりやすさに主眼が置かれており、変数名を明確にしたり、値オブジェクトを使うことやイミュータブルなデータに関して言及されている。<br>「クラス名やメソッド名と業務の用語を一致させること」これはかなり大事。異音同義語があると認識のズレとか生まれやすいし、話していてツラミ感じる。<br></p><h2 id="ha15bdf6dc7">CHAPTER2: 場合分けのロジックを整理する</h2><p>ソフトウェア変更容易性を妨げるのが複雑なロジックなので、簡単に書こうという内容や方法がまとめられている。<br>メソッドに切り出すとか、ifのネスト、ガード節による早期returnなど。<br>switch文などで分けるより、クラス化しロジックをカプセル化して呼び出すだけにすると見通しが良くなるなど。<br>使う側のクラスが使われる先のクラスに関する知識が少ないほど疎結合になって良い。<br>Railsで開発しているとどうしても密結合になりがちなので、改めて意識したいと思った。<br></p><h2 id="ha7493dcb4e">CHAPTER3: 業務ロジックをわかりやすく整理する</h2><p>1,2章が部品レベルの話だったが、この章ではアプリケーション全体の組み立てレベルでのロジックの分かりやすさについてまとめている。<br>ドメインオブジェクトをクラスとして管理していく際に下記のことに気をつける。</p><ul><li>メソッドをロジックの置き場所にする<ul><li>getter / setterメソッドだけになっていないか？（=ドメインモデル貧血症）</li></ul></li><li>ロジックを、データを持つクラスに移動する<ul><li>ロジックが点在していないか？共通化できないか？</li></ul></li><li>使う側のクラスにロジックを書き始めたら設計を見直す</li><li>メソッドを短くして、ロジックの移動をやりやすくする</li><li>メソッドでは必ずインスタンス変数を使う<ul><li>Railsの文脈だとクラス内のカラム等</li><li>受け取った引数だけ使っているのであればそのクラスに定義する意味がない</li></ul></li><li>クラスが肥大化したら小さく分ける</li><li>パッケージを使ってクラスを管理する</li></ul><p><br>上記を組み立てる段階で、プレゼンテーション層にドメインロジックが書かれていないか？アプリケーション層との結合はどうか？等の責務を意識していく。<br>基本的にドメインオブジェクトにロジックをまとめることで凝集性を高める方が好ましい。<br></p><h2 id="hc67bfc2306">CHAPTER4: ドメインモデルの考え方で設計する</h2><p>ドメインの関心事を適切にモデルに落とし込んで独立した単位として扱えるようにする重要性についてまとめられている。<br>ドメイン内のユビキタス言語を定めてクラス名に落とし込むことや、「コト」を中心に考えることで関心事を特定しやすくなるなど。<br>特に学びだったのがドメインオブジェクトの基本設計パターンと業務の関心事パターン<br></p><h3 id="h96db50827d">ドメインオブジェクトの基本設計パターン</h3><ul><li>値オブジェクト<ul><li>数値、日付、文字列などをラップしてロジック整理する</li></ul></li><li>コレクションオブジェクト<ul><li>配列やコレクションをラップしてロジック整理</li></ul></li><li>区分オブジェクト<ul><li>区分の定義と区分ごとのロジックを整理</li></ul></li><li>列挙型の集合操作<ul><li>状態遷移ルールなどを列挙型の集合として整理</li></ul></li></ul><p><br>この4種類で業務ロジックを整理していくと業務ロジックがドメインモデルに集約できる。<br></p><h3 id="hf8f9909063">業務の関心事パターン</h3><ul><li>口座パターン<ul><li>現在の値を表現し妥当性を管理<ul><li>数値の増減や現在の値を保持</li><li>銀行の口座や在庫数量の管理など時系列が重要なパターン</li></ul></li></ul></li><li>期日パターン<ul><li>約束の期日と判断を表現<ul><li>期日が適切に守れているかを管理<ul><li>期限切れの場合はどうするかなどの表現</li></ul></li></ul></li></ul></li><li>方針パターン<ul><li>様々なルールが複合する複雑な業務ロジックを表現</li></ul></li><li>状態パターン<ul><li>状態と、状態遷移できる/できないを表現<ul><li>決済ステータスなどで利用される<ul><li>ある状態ではどうなるべきなのかを表現</li></ul></li></ul></li></ul></li></ul><p><br>上記4種類が主な関心事パターンとして挙げられるが、ドメイン理解をしていくことが適切に関心事を扱えるようになるポイント。<br>異音同義語に注意したい。あと、話を深掘り真の課題を抽出すること。<br></p><h2 id="h934a2ff4fe">CHAPTER5: アプリケーション機能を組み立てる</h2><p>サービスクラスに業務ロジックを書かないようにする。<br>防御的プログラミングの形式で多くのガード節があると、ドメインモデルにロジックを移すかクラスを用意するなりした方が良い。<br>あくまでサービスクラスは処理を呼び出すだけ。尋ねるな命じろ。<br></p><h2 id="hb7145337f9">CHAPTER6: データベースの設計とドメインオブジェクト</h2><p>データベース設計がうまくいくとアプリケーションロジックも書きやすくなる。<br>NOT NULL制約だったり、一意性制約、外部キー制約など。詳細はSQLアンチパターンなどの書籍に譲る。<br>というよりDB設計の細かい話より、ドメインの中でテーブル単位をどう切り分けるのかという話の方が重要。<br>「コトの記録」を徹底すると本書には書かれている。<br>実体があるものはモデリングしやすいが、実体の無いものこそ業務ロジックの中ではモデリングすることが大事。<br>texta.fmというラジオでも和田さんが同じことをおっしゃっていた。<br></p><h2 id="h893e2c96ed">CHAPTER7: 画面とドメインオブジェクトの設計を連動させる</h2><p>汎用画面は複数の関心事が混ざっておりロジックを複雑にしてしまう。<br>何事も関心事の分離が肝とあるが、ビジネスサイドからは1つの画面で全部行いたいという要望もあるので落とし所は難しいなと思う。<br>逆に言うと、1つの画面で共通の関心事をまとめられていないという側面もあるのかもしれない。<br>複数の関心事が混ざっていることだけでなく、同じ関心事が複数画面に点在していないかも意識できると良さそう。<br></p><h2 id="h5645107752">CHAPTER8: アプリケーション間の連携</h2><p>APIの粒度を適切に保つことが再利用性や利用容易性を高める。<br>本書では大は小を兼ねるAPIはビジネスの発展を阻害するとあるが、まさにその通りだと思う。<br>ユースケース上では不要なパラメータや戻り値など、複雑にする要因があると連携がスムーズにいかない。<br>将来的な拡張性も難しくしてしまうと感じる。<br>関心事の不一致が起きていないかどうかはこういう場面でも意識したい。<br></p><h2 id="h75d5aa7c28">CHAPTER9: オブジェクト指向の開発プロセス</h2><p>オブジェクト指向らしく分析と設計を一体にすることで、変更が楽で安全なソフトウェア開発を進められる。<br>業務ロジックをドメインモデルに集約して整理することが肝。<br>分析工程と設計工程を分割せずに一貫して行うことや、コードが自己文書化すべき等の記載がある。<br>兎にも角にもドメインを深く理解してモデリングすることが大事。<br></p><h2 id="ha9422fdb63">CHAPTER10: オブジェクト指向設計の学び方と教え方</h2><p>オブジェクト指向設計の考え方を習得するには、リファクタリングが手っ取り早い。<br>コードの重複や巨大なメソッド/クラス、引数が多すぎるメソッドなどをリファクタリングすることでなぜ使いやすくなるのかを肌で感じることが大事。<br>話は少し逸れるが、最近は脱オブジェクト指向が主流になりつつあるような気がするので別途ブログにまとめたい。<br></p><h2 id="ha214098e44">まとめ</h2><p>再利用性が高くDRYなコードを書くのはもちろん、ドメインを適切にモデリングすることを意識したい。</p>

【読書ログ】現場で役立つシステム設計の原則

<h2 id="h9707d3a59a">概要</h2><p>社内の新規アプリケーション開発時にマルチテナント対応をしたいという話になり、Railsでそれを実現するGemを選定して実装した際の振り返り<br></p><h2 id="hc69c85bcf9">背景</h2><p>PostgresqlのRLS(<a href="https://www.postgresql.jp/document/9.6/html/ddl-rowsecurity.html" target="_blank" rel="noopener noreferrer">Row Level Security</a>)も考慮してテナントごとのデータを安全に扱いたかったため、それを前提にGemを探した<br>RLSのGemは <a href="https://github.com/suus-io/rls_rails" target="_blank" rel="noopener noreferrer">https://github.com/suus-io/rls_rails</a> も候補としてあったが、DSLみが強くconfigが複雑になりそうだったので不採用。<br>色々探した結果、SmartHRさんがRLSのGemを公開したという<a href="https://tech.smarthr.jp/entry/2022/02/15/202241" target="_blank" rel="noopener noreferrer">記事</a>を読んで、結果的にそのGem (<a href="https://github.com/kufu/activerecord-tenant-level-security" target="_blank" rel="noopener noreferrer">https://github.com/kufu/activerecord-tenant-level-security</a>) を採用。<br>採用したGemが <a href="https://github.com/citusdata/activerecord-multi-tenant" target="_blank" rel="noopener noreferrer">https://github.com/citusdata/activerecord-multi-tenant</a> でのマルチテナント実装を推奨していたため、それを元に進めた。<br></p><h2 id="h89e7b98e09">詳細</h2><p>まず<a href="https://github.com/kufu/activerecord-tenant-level-security#usage" target="_blank" rel="noopener noreferrer">usage</a>に書かれているようにconfigでテナント分離できる設定を追記。</p><pre><code>TenantLevelSecurity.current_tenant_id { MultiTenant.current_tenant_id }</code></pre><p>その後下記手順で動作確認を行なった。<br></p><ul><li>テスト用のテーブルをマイグレーション（tenant_idをカラムにもたせる）</li><li>テストレコードのINSERT</li><li>Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成</li><li>テストユーザーでのコネクション確立</li><li>テナント分離動作確認</li></ul><p><br></p><h3 id="h85b05474f3">手順1: テスト用のテーブルをマイグレーション</h3><p>usageに従いpolicyをテーブルに付与（tenant_idのカラムも持たせる）してマイグレーション</p><pre><code>class CreateEmployee &lt; ActiveRecord::Migration[6.0]
&nbsp;def change
&nbsp;&nbsp;create_table :employees do |t|
&nbsp;&nbsp;&nbsp;t.integer :tenant_id
&nbsp;&nbsp;&nbsp;t.string :name
&nbsp;&nbsp;end

&nbsp;&nbsp;create_policy :employees
&nbsp;end
end</code></pre><p><br>DB側でもpolicyが付与されていることを確認</p><pre><code>development=# \d employees
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Table "public.employees"
&nbsp;Column&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;Type&nbsp;&nbsp;&nbsp;&nbsp;| Collation | Nullable |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-----------+-------------------+-----------+----------+---------------------------------------
&nbsp;id&nbsp;&nbsp;&nbsp;&nbsp;| bigint&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| not null | nextval('employees_id_seq'::regclass)
&nbsp;tenant_id | integer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;
&nbsp;name&nbsp;&nbsp;&nbsp;| character varying |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;
Indexes:
&nbsp;&nbsp;"employees_pkey" PRIMARY KEY, btree (id)
Policies (forced row security enabled):
&nbsp;&nbsp;POLICY "tenant_policy"
&nbsp;&nbsp;&nbsp;USING (((tenant_id)::text = current_setting('tenant_level_security.tenant_id'::text)))
&nbsp;&nbsp;&nbsp;WITH CHECK (((tenantid)::text = currentsetting('tenant_level_security.tenant_id'::text)))</code></pre><p><br></p><h3 id="h1ce9c6f4f3">手順2: テストレコードのINSERT</h3><pre><code>2.times do |i|
&nbsp; Employee.create(tenant_id: i+1, name: "e#{i+1}")
end;nil</code></pre><p><br>この段階ではテナント分離されておらず全レコード取得できる</p><pre><code>irb(main):003:0&gt; Employee.all
&nbsp;&nbsp;(0.2ms)&nbsp;SET tenant_level_security.tenant_id TO DEFAULT
&nbsp;Employee Load (0.6ms)&nbsp;SELECT "employees".* FROM "employees"&nbsp;&nbsp;&nbsp;&nbsp;
=&gt; [#&lt;Employee:0x0000ffffb2ef9770 id: 1, tenant_id: 1, name: "e1"&gt;, #&lt;Employee:0x0000ffffb2c8acf0 id: 2, tenant_id: 2, name: "e2"&gt;]</code></pre><p><br></p><h3 id="hd67ad5402a">手順3: Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成</h3><p>テストユーザーにはSELECTだけ付与</p><pre><code>$ CREATE USER user WITH PASSWORD 'password';
$ \c development;
$ GRANT SELECT ON employees To user;</code></pre><p><br></p><h3 id="h096de0225e">手順4: テストユーザーでのコネクション確立</h3><p>ActiveRecordの<a href="https://api.rubyonrails.org/classes/ActiveRecord/ConnectionHandling.html#method-i-establish_connection" target="_blank" rel="noopener noreferrer">establish_connection</a>を利用してテストユーザーでコネクション確立</p><pre><code>irb(main):017:1* app_user_config = {
irb(main):018:1*&nbsp;&nbsp;adapter: "postgresql",
irb(main):019:1*&nbsp;&nbsp;encoding: "UTF8",
irb(main):020:1*&nbsp;&nbsp;database: "development",
irb(main):021:1*&nbsp;&nbsp;username: "user",
irb(main):022:1*&nbsp;&nbsp;password: "password",
irb(main):023:1*&nbsp;&nbsp;host: "db",
irb(main):024:1*&nbsp;&nbsp;port: 5432,
irb(main):025:0&gt; }
=&gt; {:adapter=&gt;"postgresql", :encoding=&gt;"UTF8", :database=&gt;"development", :username=&gt;"user", :password=&gt;"password", :host=&gt;"db", :port=&gt;5432}
irb(main):026:0&gt; ActiveRecord::Base.establish_connection(app_user_config)</code></pre><p><br></p><h3 id="h9bac615da0">手順5: テナント分離動作確認</h3><p>tenant_idが1のレコードのみ返却される</p><pre><code>irb(main):016:1* TenantLevelSecurity.with(1) do
irb(main):017:1*&nbsp;&nbsp;Employee.pluck(:name)
irb(main):018:0&gt; end
&nbsp;&nbsp;(0.9ms)&nbsp;SHOW tenant_level_security.tenant_id
&nbsp;&nbsp;(0.5ms)&nbsp;SET tenant_level_security.tenant_id TO DEFAULT
=&gt; ["e1"]</code></pre><p><br>これだけではまだ使い物にならないので、実装時に裏側でコネクション確立するような実装や明示的にコネクション抜ける方法も考えないといけない。<br></p><h2 id="ha214098e44">まとめ</h2><p>RLSという単語を初めて知ったので新しい知見を得られた。<br>Gemの選定も運用を考えた現実的なラインで判断できたので良い経験になった。<br></p>

<Rails>マルチテナント対応時に選定したGemの話

<h2 id="h9707d3a59a">概要</h2><p> CTIで設計したテーブルをアプリケーションに落とし込むために<a href="https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html" target="_blank" rel="noopener noreferrer">Delegated types</a>を利用したのでその振り返り<br></p><h2 id="hc69c85bcf9">背景</h2><ul><li>サブクラスごとに異なるカラムを使う前提があった</li><li>今後の拡張時に既存処理の影響を与えずにロジックを記述できるようにしたかった</li><li>そのため、STIよりかはCTI（MTI）的にサブクラスごとにテーブルを分けてその状態を実現したかった</li><li>STIのような共通インターフェースでサブクラスにアクセスしたかった</li></ul><p><br>要は、サブクラスごとにテーブルを分けたいけれど、STIのように共通インターフェースでサブクラスにアクセスしたかった。<br>最初は<a href="https://max.engineer/mti#multiple-table-inheritance-simulated" target="_blank" rel="noopener noreferrer">https://max.engineer/mti#multiple-table-inheritance-simulated</a> などを見て、メタプロで実現しようと考えていた。<br>ただ、納期が迫っていたのでメタプロでやり切れるのか不明瞭だったのと、今後の保守性 / 拡張性まで考えると懸念があった。<br>色々とググった結果、<a href="https://stackoverflow.com/a/63273663" target="_blank" rel="noopener noreferrer">https://stackoverflow.com/a/63273663</a> でどうやらMTIがRails6.1.0からネイティブサポートされたという情報を見つけた。それが<a href="https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html" target="_blank" rel="noopener noreferrer">Delegated types</a>。<br>メタプロよりネイティブサポートされた機能を使う方がベターだと考え、これを使って実装をしていこうと決断。（そのためにRailsのバージョンまで上げた）<br></p><h2 id="h89e7b98e09">詳細</h2><p><a href="https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html" target="_blank" rel="noopener noreferrer">Delegated types</a>は委譲（Delegate）を使って、スーパークラスから具象サブクラスへアクセスできるようにしている。<br><br>クラス設計は下記のようになる。<br>まず、スーパークラスとしてEntryが存在しており、具象サブクラスとして<code>Message</code> / <code>Comment</code>が存在している。<br>スーパークラスには<code>delegated_type</code>の宣言をしており、サブクラスには<code>Entryable</code>モジュールをincludeしている。</p><pre><code># Schema: entries[ id, account_id, creator_id, created_at, updated_at, entryable_type, entryable_id ]
class Entry &lt; ApplicationRecord
&nbsp;belongs_to :account
&nbsp;belongs_to :creator
&nbsp;delegated_type :entryable, types: %w[ Message Comment ]
end

module Entryable
&nbsp;extend ActiveSupport::Concern

&nbsp;included do
&nbsp;&nbsp;has_one :entry, as: :entryable, touch: true
&nbsp;end
end</code></pre><p><br></p><pre><code># Schema: messages[ id, subject, body ]

class Message &lt; ApplicationRecord
&nbsp;include Entryable
end</code></pre><p><br></p><pre><code># Schema: comments[ id, content ]

class Comment &lt; ApplicationRecord
&nbsp;include Entryable
end</code></pre><p><br>スーパークラスの<code>entryable_id</code> に具象サブクラスのプライマリID、<code>entryable_type</code>にサブクラスのtypeが格納される。<br>スーパークラス側の<code>delegated_type</code>メソッドの <code>types</code>オプションで許可するtypeを定義できる。<br>上記例では、<code>Message</code>と<code>Comment</code>typeのみ許可することになっている。<br>この時、スーパークラスとサブクラスのレコードは下記のようになっている。<br></p><pre><code>[1] pry(main)&gt; Entry.first
=&gt; #&lt;Entry:0x0000ffff7c3996b8
&nbsp;id: 1,
&nbsp;account_id: 1,
&nbsp;creator_id: 1,
&nbsp;entryable_id: 1,
&nbsp;entryable_type: "Comment"
&nbsp;created_at: Wed, 26 Oct 2022 07:04:34 UTC +00:00,
&nbsp;updated_at: Mon, 28 Nov 2022 05:42:32 UTC +00:00,
&nbsp;&gt;

&nbsp;[1] pry(main)&gt; Comment.first
=&gt; #&lt;Comment:0x0000ffff7c3996b8
&nbsp;id: 1,
&nbsp;content: "content"
&nbsp;&gt;</code></pre><p><br>これにより、下記のようにスーパークラスから<code>entryable</code>インターフェースを経由して具象サブクラスにアクセスできる。（ifによるtype分岐などは必要としない。尋ねるな命じよ(Tell, Don't Ask!)）</p><pre><code>Entry.first.entryable
=&gt; Comment.first

Entry.first.entryable.id
=&gt; Comment.first.id

Entry.first.entryable.content
=&gt; Comment.first.content</code></pre><p><br></p><h2 id="ha214098e44">まとめ</h2><p><a href="https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html" target="_blank" rel="noopener noreferrer">Delegated types</a> を選定することで新たな知見を得られたのが良かった。<br>STIとCTIの違いを抑えられただけでなく、Railsのアップグレード（<a href="https://kdevlog.com/posts/7oo2u06co" target="_blank" rel="noopener noreferrer">こちら</a>の記事）についても知見を得られたのもGood。<br></p>

<Rails>Delegated typesを利用した際の知見

<h2 id="h9707d3a59a">概要</h2><p>自分の会社でproduction運用しているアプリケーションのRailsバージョンをアップグレードした際の振り返り<br></p><h2 id="hc69c85bcf9">背景</h2><p>新機能追加にあたってCTIでテーブル設計をして、<a href="https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html" target="_blank" rel="noopener noreferrer">ActiveRecord::DelegatedType</a>（以下DelegatedType） を利用したかった<br>ただ、DelegatedTypeはRails6.1.0からしか利用できないので、アップグレードが必要だった<br></p><h2 id="hd26ba9f505">詰まったこと</h2><ul><li><code>GLIBC_2.29</code>以上が必要だった<ul><li>それに伴いRubyのバージョンをアップグレード</li></ul></li><li>PostgreSQLのバージョンが見当たらなかった</li></ul><p><br></p><h2 id="h01a6fd60f2">GLIBC_2.29以上が必要だった</h2><p>Railsを6.0.2から6.1.0にアップグレードした際、<code>nokogiri</code>インストール時に<code>GLIBC_2.29</code>がないと怒られた</p><pre><code>ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc &lt; 2.17:

&nbsp;/lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so) - /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so

&nbsp;If that's the case, then please install Nokogiri via the `ruby` platform gem:
&nbsp;&nbsp;&nbsp;gem install nokogiri --platform=ruby
&nbsp;or:
&nbsp;&nbsp;&nbsp;bundle config set force_ruby_platform true</code></pre><p>アプリケーションのRubyイメージ (<code>2.6.7-slim</code>)では、GLIBCが2.28であることから、GLIBC2.29以上が同梱されたイメージを利用する必要があった<br><br>そのため、Rubyのアップグレードも同時に行いイメージを<code>2.7.6-slim</code>にして、GLIBCを2.31にしたらinstallに成功</p><pre><code># ldd --version
ldd (Debian GLIBC 2.31-13+deb11u4) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.&nbsp;There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.</code></pre><p>良い機会だからRubyのアップグレードまで行ったが、GLIBCの指定バージョンをインストールするだけでも良かった<br></p><h2 id="h7f3605cb81">PostgreSQLのバージョンが見当たらなかった</h2><p>修正前は<code>deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main</code>で探していたが見つからないと怒られる</p><pre><code>#5 33.87 Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
#5 34.28 OK
#5 35.11 cat: /tmp/Aptfile: No such file or directory
#5 35.11 Reading package lists...
#5 35.42 Building dependency tree...
#5 35.52 Reading state information...
#5 35.57 E: Unable to locate package postgresql-client-11</code></pre><p><br>Rubyのimageを変えたのでDebianバージョンが変わったから見つからないのではと考えたらその通りだった</p><pre><code>$ docker run --rm ruby:2.7.6-slim sh -c "cat /etc/*-release"
Unable to find image 'ruby:2.7.6-slim' locally
2.7.6-slim: Pulling from library/ruby
3d898485473e: Already exists
755e58a55855: Already exists
68a9083723f3: Already exists
b8edf3cdc5de: Already exists
93fc5708079e: Already exists
Digest: sha256:86f0a40ff15ddb9fbdc0a64bcf9ad4e048fec31a3e538a79a526b0461fca9bf8
Status: Downloaded newer image for ruby:2.7.6-slim
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUGREPORTURL="https://bugs.debian.org/"</code></pre><p><code>bullseye</code>だったので、<code>deb http://apt.postgresql.org/pub/repos/apt/ bullseye-pgdg main</code>で探すと見つかった<br></p><h2 id="ha214098e44">まとめ</h2><p>本番稼働しているアプリケーションのFWバージョンを上げるのは中々できないと思うのでとても良い経験になった<br>色々と詰まってしまったが、自分で一つ一つ調査して解決できた経験を次に活かしたい</p>

Railsアップグレードをした際の知見

<h2 id="h9707d3a59a">概要</h2><p>STIとポリモーフィック関連の理解が混同していたので改めて整理した記事。<br></p><h2 id="h6515c1f26a">STIとは</h2><p>1つのテーブルを継承して複数のモデルを表現する形式。<br></p><h3 id="hcf4c0ae6f0">具体例</h3><p>carsテーブルとtrainsテーブルがvehiclesテーブルを継承すると仮定する。<br>クラス間の関係性は下図のようになる。<br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/4434c9d0b52c48458ff830b069195b06/sti_models.png" alt=""><br><br>STIはテーブル一つで表現するため、DBに存在するテーブルはvehiclesテーブルのみ。<br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/68b0c8ee878a4cb88723cfdbcc51932a/sti_table.png" alt=""><br>vehiclesテーブルのtypeカラムを使って、trains or carsの判別をする。<br></p><h3 id="h3ab24f6f50">メリット</h3><ul><li>テーブルが増えない</li><li>Railsの場合だと<a href="https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html" target="_blank" rel="noopener noreferrer">STIをサポートしている</a>ので実装容易性がある</li><li>サブクラスのレコードを取得するためにJOINする必要が無い</li></ul><p><br></p><h3 id="h7e4a670898">デメリット</h3><ul><li>カラム数が多くなる</li><li>別のサブクラスで利用しなければnull値が増える</li><li>特定のサブクラスのみを参照すべき他テーブルの外部キー制約が、誤ったサブクラスを参照することを防げない</li></ul><p><br></p><h3 id="h3de35099b3">参考</h3><p><a href="https://qiita.com/yebihara/items/9ecb838893ad99be0561" target="_blank" rel="noopener noreferrer">https://qiita.com/yebihara/items/9ecb838893ad99be0561</a><br></p><h2 id="h01c3f30303">ポリモーフィック関連とは</h2><p>複数のモデルから同じモデルを参照する際の関連付けの仕組み。<br>多態性という言葉より複数のモデルに対して共通のインターフェースを設けられる。<br><a href="https://guides.rubyonrails.org/association_basics.html#polymorphic-associations" target="_blank" rel="noopener noreferrer">https://guides.rubyonrails.org/association_basics.html#polymorphic-associations</a><br></p><h3 id="hcf4c0ae6f0">具体例</h3><p>ProductモデルとEmployeeモデルはPictureモデルを参照すると仮定（railsガイドそのまま）<br></p><pre><code>class Picture &lt; ApplicationRecord
&nbsp;belongs_to :imageable, polymorphic: true
end

class Employee &lt; ApplicationRecord
&nbsp;has_many :pictures, as: :imageable
end

class Product &lt; ApplicationRecord
&nbsp;has_many :pictures, as: :imageable
end</code></pre><p><br>picturesテーブルには参照元の親テーブルを表すカラム（<code>imageable_id</code> / <code>imageable_type</code>）を持たせる。</p><pre><code>class CreatePictures &lt; ActiveRecord::Migration[7.0]
&nbsp;def change
&nbsp;&nbsp;create_table :pictures do |t|
&nbsp;&nbsp;&nbsp;t.string&nbsp;:name
&nbsp;&nbsp;&nbsp;t.bigint&nbsp;:imageable_id
&nbsp;&nbsp;&nbsp;t.string&nbsp;:imageable_type
&nbsp;&nbsp;&nbsp;t.timestamps
&nbsp;&nbsp;end

&nbsp;&nbsp;add_index :pictures, [:imageable_type, :imageable_id]
&nbsp;end
end</code></pre><p><br><code>@picture.imageable</code>を介して親テーブルにアクセスできる。<br><code>@picture</code>がどの親に紐づいているかどうかの分岐が必要ない。（typeによる分岐等）<br></p><h3 id="h3ab24f6f50">メリット</h3><ul><li>DRYに書ける<ul><li>中間テーブルを省いて相互に関連付けが可能</li><li>共通インターフェースで関連付けが可能</li></ul></li></ul><p><br></p><h3 id="h7e4a670898">デメリット</h3><ul><li>外部キーを貼れないので参照整合性制約が担保されない</li></ul><h2 id="ha214098e44"><br>まとめ</h2><p>ポリモーフィックとSTIの言語の意味を考えると自然とどちらか分かる。<br>まずは言語の意味をしっかり抑えようと思った。</p>

STIとポリモーフィック関連の整理

<h2 id="h5fcec0cf90">所感</h2><p>ドメイン駆動設計に関して本格的に学ぼうと思って読んだ1冊<br>ドメインモデルをうまく表現することの利点や技法などをバラバラだった知識をまとめられた印象<br>ビジネスドメインを丁寧にモデリングして扱えるようにしたい<br></p><h2 id="h8c5d914f64">Chapter2</h2><h3 id="h2d0c893345">「システムに最適な値が必ずしもプリミティブな値であるとは限らない」</h3><p>ドメイン固有の値をどう扱うと良いのかにフォーカスすることが大事。<br>イミュータブルであることによりデータの信頼性が向上されるし、それにより交換可能になる。（逆に言うと交換以外で値を変更できない）<br>クラスとして実装していくことで値オブジェクト固有のバリデーションロジックも内包できるというのも扱いやすくなるポイントかなとも思う。<br></p><h3 id="h5090a00f8c">値オブジェクトとして扱う基準</h3><p>また、値オブジェクトとして扱うべきかどうかの判断基準として「そこにルールが存在しているか」「それ単体で取り扱いたいか」という点を筆者が重視しているという点も印象に残った。<br>ドメイン内で特別視されている（ドメイン固有の呼び名が付いているなど）の場合は、値オブジェクトになり得るのかなと思った。<br><br>値オブジェクトに関しては下記のpodcastもとても参考になる。<br><a href="https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0" target="_blank" rel="noopener noreferrer">https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0</a><br></p><h2 id="h93ba759808">Chapter3</h2><h3 id="h13f1e49b2f">値の同一性</h3><ul><li>エンティティは識別子(ID)で同一性を判断</li><li>値オブジェクトは値で同一性を判断<ul><li>別のオブジェクトだとしても値が同じであれば同一とみなす</li></ul></li></ul><p><br></p><h3 id="h53c5bce5d7">エンティティの判断基準</h3><p>「ライフサイクルが存在し、そこに連続性が存在する」ことがエンティティかどうかの基準。<br>作成されて誕生し、削除されて死を迎える。つまりCRUD処理が発生し得る可変なオブジェクト。<br>値オブジェクトは不変であるため、エンティティではないということが分かる。<br></p><h3 id="h594938b0f9">ドメインオブジェクトを定義するメリット</h3><p>印象に残ったのは「仕様書というのはマクロな要件については有効であってもミクロな要件については無力であることが多い」ということ。<br>その通りであるし、そこまで記述する必要がないからそうなっているはず。<br>だからこそ、コードからその要件を汲み取りやすくしておく必要があるなと再認識した。<br>クラスにドメインオブジェクトのルールを記述して凝集度は高く保つというのは、ドキュメンテーションという文脈においても重要。<br></p><h2 id="ha5af9db5f8">Chapter4</h2><h3 id="hddaa2692b7">サービスへのロジック切り出しはドメインモデル貧血症を引き起こす</h3><p>ドメインモデルの振る舞いをサービスに切り出しすぎると、ドメインモデルがデータだけを保持している無口なオブジェクトになってしまう。それによってドメインモデル自身が語るべきことを語っていない状態が出来上がってしまう。<br>データと振る舞いが点在してしまうことで可読性や保守性に欠けてしまう。<br>そうならないために、ドメインモデルに不自然な振る舞いのみサービスに切り出すことが重要。<br>複数のモデルを横断する操作を行う際など、ドメインモデル固有ではないロジックが出てきた場合は検討の余地あり。<br></p><h2 id="h3172a3f7da">Chapter5</h2><h3 id="h3a0df8ba04">ビジネスロジックをより純粋なものに昇華する</h3><p>リポジトリパターンを利用して永続化処理を抽象化して隠蔽することで、ビジネスロジックを簡潔にできる。<br>自分の会社のフロントエンドアプリケーションはリポジトリパターンを利用しており既知の知識としてある。<br>だからこそ今一度下記のようなアンチパターンを実装してしまわないように意識したい。<br><a href="https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf" target="_blank" rel="noopener noreferrer">https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf</a><br></p><h2 id="h442fcfdf7d">Chapter6</h2><h3 id="h9937c71719">アプリケーションサービスはオブジェクトの操作に徹する</h3><p>ドメインロジックの責務外の振る舞いを記述することに徹する。<br>サービスオブジェクトはロジックが雑多になりがち（ドメインロジックが記述されてる / 責務が複数等）なので、今一度サービスクラスを作る際は注意したいと思う。<br><a href="https://qiita.com/joker1007/items/25de535cd8bb2857a685" target="_blank" rel="noopener noreferrer">https://qiita.com/joker1007/items/25de535cd8bb2857a685</a><br></p><h2 id="h144df606cc">Chapter7</h2><h3 id="h17650846c2">依存を避けるよりコントロールせよ</h3><p>抽象に依存することが重要。依存関係逆転の原則。<br>抽象に依存することで変更箇所が最小になる。改めて思うのは良い設計は変更容易性が担保されていること。<br></p><h2 id="h200703e706">Chapter12</h2><h3 id="ha8b99f80ff">オブジェクトの境界線が秩序をもたらす</h3><p>デメテルの法則（最小知識の原則）を元にコード設計する。<br>Wikipediaによると、デメテルの法則の基本骨子は下記である。</p><blockquote>基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべき</blockquote><p><a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87" target="_blank" rel="noopener noreferrer">https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87</a><br><br>つまり、他のオブジェクトの情報（どういう状態/値であるのか等）を知らなくて良いということ。<br>「尋ねるな、命じろ」というソフトウェアの格言があるが、その通りに設計していけばルールが漏れ出すのを防げる。<br>変更が面倒な時は大体同じロジックが書かれているので、改めて意識してコードを書いていきたい。<br>下記資料の図が分かりやすい。<br><a href="https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B" target="_blank" rel="noopener noreferrer">https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B</a><br></p><h2 id="h7a3b06c7df">Chapter13</h2><h3 id="h642977dc12">仕様オブジェクトがドメインルールの点在を防ぐ</h3><h4 id="hacbbee1047">仕様オブジェクトについて</h4><p>ドメインの重要なルールだが処理が複雑になってしまうロジックを格納するオブジェクト<br>目的としては、ロジックの点在を防ぐこと。<br>例えば、こういったロジックはサービス層で実装されがちだが、それだとドメインルールが点在してしまう。<br>そういった状況を防ぐために仕様オブジェクトでロジックをラップする。<br></p><h4 id="h3f4f4f9aaf">リポジトリのフィルターとしても機能する</h4><p>リポジトリに仕様オブジェクトを渡してメソッドを呼び出すようにすることで、ドメイン知識を記述せずに済むようになる。<br></p><pre><code>// 仕様オブジェクト
public class CircleRecommendSpecification {
&nbsp;&nbsp;private readonly DateTime executeDateTime;

&nbsp;&nbsp;public CircleRecommendSpecification(DateTime executeDateTime) {
&nbsp;&nbsp;&nbsp;&nbsp;this.executeDateTime = executeDateTime;
&nbsp;&nbsp;};

&nbsp;&nbsp;public bool IsSatisfiedBy(Circle circle) {
&nbsp;&nbsp;&nbsp;&nbsp;if(circle.CountMembers() &lt; 10) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return false;
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;return circle.Created &gt; executeDateTime.AddMonths(-1);
&nbsp;&nbsp;};
}

// リポジトリ
public class CircleRepository: CircleRepository {
&nbsp;&nbsp;private readonly ICircleRepository circleRepository;
&nbsp;&nbsp;private readonly DateTime now;
&nbsp;&nbsp;...
&nbsp;&nbsp;public CircleGetRecommendResult GetRecommend(CircleGetRecommendRequest request) {
&nbsp;&nbsp;&nbsp;&nbsp;var circleRecommendSpecification = new CircleRecommendSpecification(now);
&nbsp;&nbsp;&nbsp;&nbsp;// リポジトリに仕様を引き渡して抽出(フィルタリング)
&nbsp;&nbsp;&nbsp;&nbsp;var recommendCircles = circleRepository.Find(circleRecommendSpecification)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Take(10)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.ToList();
&nbsp;&nbsp;&nbsp;&nbsp;return new CircleGetRecommendResult(recommendCircles);
&nbsp;&nbsp;};
}</code></pre><p><br></p><h2 id="hf6a55646d4">Chapter14</h2><h3 id="h7e510f830b">レイヤーの隔離と責務の分割</h3><p>本書ではドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することと説明されている。<br>レイヤードアーキテクチャやクリーンアーキテクチャなどのアーキテクチャも依存の方向を定めて、レイヤーごとに責務を分割している。ドメイン駆動設計の文脈上で最も重要なのはドメインの隔離を促すこと。<br></p><h2 id="h9c70a17397">Chapter15</h2><h3 id="hee5f67d1d8">軽量DDDに陥らないこと</h3><p>デザインパターンなどを盲目的に利用してそれで終わらないこと。<br>重要なのはドメインの本質に向き合い続けること。ユーザーを知り対話を続けドメインを改善していくことを意識したい。<br></p><h2 id="ha214098e44">まとめ</h2><p>依存の方向性 / 責務の分割 / ロジック隠蔽を意識したいと思った。<br>パターンはある程度分かったが、エリックエヴァンスの書籍を読んで根本的な思想の部分を知りたい。</p>

【読書ログ】ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

<h2 id="h9707d3a59a">概要</h2><p>先日社内のPRコードレビューを受けて、<code>Array#include?</code>より<code>Set#include?</code>の方が高速だということを知った<br>その時にソースを追ってみたまとめ<br></p><h2 id="h9ced1f0f73">要約</h2><ul><li><code>Array#include?</code>は計算量が<code>O(n)</code></li><li><code>Set#include?</code>は計算量が<code>O(1)</code></li></ul><p><br></p><h2 id="hf27beb394c">Array#include?</h2><pre><code>VALUE
rb_ary_includes(VALUE ary, VALUE item)
{
&nbsp;&nbsp;long i;
&nbsp;&nbsp;VALUE e;

&nbsp;&nbsp;for (i=0; i&lt;RARRAY_LEN(ary); i++) {
&nbsp;&nbsp;&nbsp;&nbsp;e = RARRAY_AREF(ary, i);
&nbsp;&nbsp;&nbsp;&nbsp;if (rb_equal(e, item)) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return Qtrue;
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;}
&nbsp;&nbsp;return Qfalse;
}</code></pre><p><a href="https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430" target="_blank" rel="noopener noreferrer">https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430</a><br></p><pre><code>/**
&nbsp;* This function is an optimised version&nbsp;of calling `#==`.&nbsp;It checks equality
&nbsp;* between two&nbsp;objects by first&nbsp;doing a fast&nbsp;identity check using&nbsp;using C's
&nbsp;* `==` (same&nbsp;as `BasicObject#equal?`).&nbsp;If&nbsp;that check fails, it&nbsp;calls `#==`
&nbsp;* dynamically.&nbsp;&nbsp;This optimisation&nbsp;actually affects&nbsp;semantics, because&nbsp;when
&nbsp;* `#==`&nbsp;returns false&nbsp;for the&nbsp;same object&nbsp;obj, `rb_equal(obj,&nbsp;obj)` would
&nbsp;* still&nbsp;return true.&nbsp;&nbsp;This happens&nbsp;for `Float::NAN`,&nbsp;where `Float::NAN&nbsp;==
&nbsp;* Float::NAN` is `false`, but `rb_equal(Float::NAN, Float::NAN)` is `true`.
&nbsp;*
&nbsp;* @param[in]&nbsp;lhs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Comparison LHS.
&nbsp;* @param[in]&nbsp;rhs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Comparison RHS.
&nbsp;* @retval&nbsp;&nbsp;&nbsp;RUBY_Qtrue&nbsp;&nbsp;They are the same.
&nbsp;* @retval&nbsp;&nbsp;&nbsp;RUBY_Qfalse&nbsp;They are different.
&nbsp;*/
VALUE rb_equal(VALUE lhs, VALUE rhs);</code></pre><p><a href="https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178" target="_blank" rel="noopener noreferrer">https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178</a><br>説明によるとオブジェクト同士の比較ということ<br></p><pre><code>&nbsp;describe "rb_equal" do
&nbsp;&nbsp;it "returns true if the arguments are the same exact object" do
&nbsp;&nbsp;&nbsp;s = "hello"
&nbsp;&nbsp;&nbsp;@o.rb_equal(s, s).should be_true
&nbsp;&nbsp;end

&nbsp;&nbsp;it "calls == to check equality and coerces to true/false" do
&nbsp;&nbsp;&nbsp;m = mock("string")
&nbsp;&nbsp;&nbsp;m.should_receive(:==).and_return(8)
&nbsp;&nbsp;&nbsp;@o.rb_equal(m, "hello").should be_true

&nbsp;&nbsp;&nbsp;m2 = mock("string")
&nbsp;&nbsp;&nbsp;m2.should_receive(:==).and_return(nil)
&nbsp;&nbsp;&nbsp;@o.rb_equal(m2, "hello").should be_false
&nbsp;&nbsp;end
&nbsp;end</code></pre><p><a href="https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779" target="_blank" rel="noopener noreferrer">https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779</a><br>念の為テストも確認して同値比較メソッドであることを確認<br><br>つまり<code>Array#include?</code>は1つずつ同値比較をしているので計算量が<code>O(n)</code><br></p><h2 id="ha2ec9ec4f7">Set#include?</h2><pre><code>&nbsp; # Returns true if the set contains the given object.
&nbsp; #
&nbsp; # Note that &lt;code&gt;include?&lt;/code&gt; and &lt;code&gt;member?&lt;/code&gt; do not test member
&nbsp; # equality using &lt;code&gt;==&lt;/code&gt; as do other Enumerables.
&nbsp; #
&nbsp; # See also Enumerable#include?
&nbsp; def include?(o)
&nbsp; &nbsp; @hash[o]
&nbsp; end
&nbsp; alias member? include?</code></pre><p><a href="https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406" target="_blank" rel="noopener noreferrer">https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406</a><br><br>hashでのアクセスにより <code>O(1)</code>の計算量を実現していることが分かった<br>ちなみにSetはイニシャライズでhashとして扱われている</p><pre><code>&nbsp;def initialize(enum = nil, &amp;block) # :yields: o
&nbsp;&nbsp;@hash ||= Hash.new(false)

&nbsp;&nbsp;enum.nil? and return

&nbsp;&nbsp;if block
&nbsp;&nbsp;&nbsp;do_with_enum(enum) { |o| add(block[o]) }
&nbsp;&nbsp;else
&nbsp;&nbsp;&nbsp;merge(enum)
&nbsp;&nbsp;end
&nbsp;end</code></pre><p><a href="https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255" target="_blank" rel="noopener noreferrer">https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255</a><br><br><br></p>

<Ruby> SetとArrayのinclude?の違い

<h2 id="h9707d3a59a">概要</h2><p>ReactベースのフルスタックフレームワークのRemixが前から気になっており、公式のチュートリアルを触ってみた感想やその思想を深ぼっていく。<br></p><h2 id="h5144c00308">Remixの思想</h2><p><a href="https://remix.run/docs/en/v1/pages/philosophy#philosophy" target="_blank" rel="noopener noreferrer">Remix公式</a>によるとこのFWは4つの思想をベースとしている。</p><ul><li>サーバー/クライアントモデルを利用（データとコンテンツの分離）</li><li>ブラウザやHTMLなどの基礎技術と協調してく</li><li>JavaScriptを使用してブラウザの動作をエミュレートすることでUX向上</li><li>基盤技術を過度に抽象化しないこと</li></ul><p><br><a href="https://zenn.dev/kaa_a_zu/articles/fbd06ca2cc3b86#0.-%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%80%81remix%E3%81%AE%E6%80%9D%E6%83%B3" target="_blank" rel="noopener noreferrer">zennで他の方が書かれている</a>ように「サーバー/クライアントモデルを利用」に対する説明が他の3つに比べて厚く書かれている印象を受けた。<br><br><a href="https://remix.run/docs/en/v1/pages/philosophy#serverclient-model" target="_blank" rel="noopener noreferrer">公式doc</a>の記載によると下記の記載がある。</p><blockquote>With today's web infrastructure you don't need static files to make your server fast.<br>We leveraged distributed systems at the edge instead of static builds. We can fix a typo and the site reflects it within seconds: no rebuilds, no redeploys, not even HTTP caching.</blockquote><p><br>サーバーを早くするために静的ファイルは必要ない。<br>静的ビルドの代わりにエッジを使って分散システムを構築した。タイポ修正しても再ビルドや再デプロイ、HTTPキャッシュいらずで数秒のうちにサイトに反映される。とのこと。<br><br>つまりSSGの機能は持っておらず、毎度SSRしてコンテンツを返している。<br>エッジを使った分散システムによりSSRを高速に返すことを実現している。<br><br><a href="https://remix.run/blog/remix-and-the-edge" target="_blank" rel="noopener noreferrer">Remix公式ブログ</a>に詳細に記載があり、以前のエッジは静的コンテンツの配信だけだったが最近はDeno deployやCloudflare Workersなど動的コンテンツも返せるようになっている。<br>Remixはそのエッジコンピューティング技術を利用して任意の場所で高速でコンテンツを返せるようにしているよう。<br></p><h2 id="h966596d311">QuickStartを触ってみる</h2><p>Remix公式で紹介されている<a href="https://remix.run/docs/en/v1/tutorials/blog#quickstart" target="_blank" rel="noopener noreferrer">QuickStart</a>を触ってみる。<br><br><a href="https://www.gitpod.io/" target="_blank" rel="noopener noreferrer">Gitpod</a>で動作環境を構築したのでローカルで作らなくて済んだ。便利すぎる。<br>Gitpodは後日記事にしたい。<br>触ってみて分かったことを色々とまとめる。<br></p><ul><li>routesディレクトリ配下のファイルがroutingになる</li><li><a href="https://remix.run/docs/en/v1/guides/api-routes" target="_blank" rel="noopener noreferrer">API routes</a>を作成可能</li><li>Dynamic routes</li><li>ErrorBoundary</li><li>Nested Routes</li></ul><p><br>特に印象深かったのが下記3点</p><ol><li>API routes</li><li>Nested Routes</li><li>ErrorBoundary</li></ol><p><br></p><h3 id="hcee6d8d79f">API routes</h3><p><code>.t(j)sx</code>ファイルでDBからの値取得やfetchなどを行って値を取ってこれる。<br>特にDBと直接連携して値を簡単に取得できるのは驚いた。<br>ORMはprismaだった。（prismaをしっかり使ってみたい欲が湧いた。）<br></p><h3 id="he19764b370">Nested Routes</h3><p><a href="https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing" target="_blank" rel="noopener noreferrer">Remix公式</a>の説明だと、URLのセグメントをUIのコンポーネント階層に一致させる考え方。<br>下記のgif分かりやすい。<br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/3c55d282fa6242429030a1d06c81c4bd/nested_routing.gif" alt=""><br>つまりURLのセグメントとコンポーネントが対応しておりそれを1ページで表している形<br>下記のディレクトリ階層で言うと、<code>app/root.jsx</code>をトップとしてその中にroutesディレクトリ配下のコンポーネントがそれぞれ表示されている。</p><pre><code>app
├── root.jsx
└── routes
&nbsp;&nbsp;├── accounts.jsx
&nbsp;&nbsp;├── dashboard.jsx
&nbsp;&nbsp;├── expenses.jsx
&nbsp;&nbsp;├── index.jsx
&nbsp;&nbsp;├── reports.jsx
&nbsp;&nbsp;├── sales
&nbsp;&nbsp;│&nbsp;&nbsp;├── customers.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── deposits.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── index.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── invoices
&nbsp;&nbsp;│&nbsp;&nbsp;│&nbsp;&nbsp;├── $invoiceId.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;│&nbsp;&nbsp;└── index.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── invoices.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;└── subscriptions.jsx
&nbsp;&nbsp;└── sales.jsx</code></pre><p><br>また<code>ErrorBoundary</code>を併用することで1つのコンポーネントがエラーで表示できなくなったとしてもページ全体が表示できないということを防げる。<br></p><h3 id="h553936e1aa">ErrorBoundary</h3><p>コンポーネントのクライアントサイドでのレンダリング時にエラーがあった場合の表示を設定するエラーハンドリング。<br>＊<code>CatchBoundary</code>はレンダリング時にAPIからのfetchやDB更新などでエラーがあった場合にキャッチする。</p><pre><code>export function ErrorBoundary({ error }: { error: Error }) {
&nbsp;return (
&nbsp;&nbsp;&lt;div className="bg-rose-500"&gt;
&nbsp;&nbsp;&nbsp;&lt;div&gt;
&nbsp;&nbsp;&nbsp;&nbsp;{error.message}
&nbsp;&nbsp;&nbsp;&lt;/div&gt;
&nbsp;&nbsp;&lt;/div&gt;
&nbsp;);
}</code></pre><p><br>QuickStartで使ったソースコードを使って実際にNested Routesと<code>ErrorBoundary</code>の動作を確認してみた。<br><strong><code>posts/admin/new</code></strong>のNested Routesでそれぞれコンポーネントを表示させている。<br><code>Create a New Post</code>を押すとadminディレクトリ配下の<code>new.tsx</code>コンポーネントがレンダリングされる。<br>その<code>new.tsx</code>コンポーネントでエラーが起きた想定で<code>ErrorBoundary</code>を利用している。<br><br><strong>通常</strong><br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/740cc2b13a54486a96f204c5d004f42e/nested_routes_normal.gif" alt=""><br><br><strong>ErrorBoundaryなし</strong><br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/c28663cb01ca4fb1800abc3227e7c6a4/not_boundary.gif" alt=""><br><br><strong>ErrorBoundaryあり</strong><br><img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/5965b6c2bbde4fdfa0648a8a70e23587/boundary.gif" alt=""></p><h2 id="hcf83e1357e"><br></h2><p><br></p><h2 id="ha214098e44">まとめ</h2><p>Nested Routesという概念によりまた一つUX体験を向上させる手段を知れたのでよかった。<br>Next.jsと違いSSGやISRといった静的ビルドはないけれど、エッジを使ってSSRを高速化しているというところのアーキテクチャの違いが興味深かった。<br>ちなみこのブログはNext.jsを使って作っておりSSGには日々お世話になっている。<br>エッジらへんもっと知りたいなと思う。<br></p>

Kdevlog