<h2 id="h9707d3a59a">概要</h2><p>発売前から気になっていたこの書籍を読んだので学びをつらつらと書いていく。<br>自分が業務で担当しているアプリケーションもパフォーマンスがボトルネックとなることがあるので、少しでも何か吸収できれば。<br></p><h2 id="hae1a8bd226">1章: チューニングの基礎知識</h2><p>本書ではリクエストレスポンス一連の動作が完了するまでの時間（RTT: Round Trip Time）が短いWebサービスを高速なWebサービスと定義している。<br>Webサービスのキャパシティは単純化すると個々の性能×数になり、それを調整するアプローチは<strong>垂直スケーリング（スケールアップ: 性能UP）</strong>か<strong>水平スケーリング(スケールアウト: 数増やす)</strong>の2種類がある。<br><br>パフォーマンスチューニングの基本は下記2点</p><ul><li>ボトルネックだけにアプローチする</li><li>ボトルネックの特定は外側から順番に<ul><li>2021年の一般的なWebサービスにおいてボトルネックになりがちな箇所はCPU、メモリ、ディスクI/O、ネットワークI/Oとのこと</li></ul></li></ul><p>負荷試験を実施して改善してのサイクルになる。負荷試験と言えるほどちゃんとしたものをやったことが無いな。。<br></p><h2 id="h84ac650721">2章: モニタリング</h2><p>モニタリングは外形監視と内部監視の2種類がある。<br>アプリケーションの外側からモニタリングする手法。外部からリクエストを行って期待通りのレスポンスが返ってくるか確認。内部監視: アプリケーション内部からモニタリングする手法。CPU利用率やメモリなどの状態をウォッチ。<br>本書では<a href="https://prometheus.io/" target="_blank" rel="noopener noreferrer">Prometheus</a>というPull側のモニタリングツールを使用している。<br>基本的には内部監視の方が多いんじゃないかなと考える。外部監視だとネットワークの状態に左右されるから再現性が低そう。<br></p><h2 id="hd555499666">3章: 基礎的な負荷試験</h2><p>各種指標をどう見るかが大事。<br>本書では下記の数値が紹介されており、MySQLのボトルネックになっている箇所を調査していく流れ。<br>（スロークエリの発見。実行計画を見ていく）</p><ul><li>CPU2コアのうち50%程度が利用されている</li><li>MySQLのプロセス(mysqld) がCPUを100%(1コア)程度利用</li><li>WebアプリケーションのプロセスはCPU1% / Webサーバーのプロセスは0.3%</li></ul><p>実務でもスロークエリログがあってCPU使用率が跳ね上がった経験がある。<br>あのような事象はかなりインシデントにつながるので普段からパフォーマンスをより意識したい。<br>少なくとも自分が作成するPRでは発行されるSQLのチェックはよりパフォーマンスを意識したい。</p><h2 id="hf22b88ef3f"><br>4章: シナリオを持った負荷試験</h2><p>この章の内容は自分の勤務先でもやりたい...！<br>どの画面表示時に遅いのかをシナリオを使って調査して可視化できるのはとても良い。<br>よりユーザー目線に立ったテコ入れができると感じる。<br>テスト環境ではデータ量が足りず、どうしてもクライアントのボトルネックに気付けないという問題がある。<br>（ローカルだと開発生産性に影響するのでやりたくないから、それ用の環境を作るとかになるのかな。コスパとの相談かも）<br>それを事前に検知できる仕組みが欲しい。<br>書籍だとOSSの<a href="https://k6.io/open-source/" target="_blank" rel="noopener noreferrer">k6</a>というツールを紹介している。<br></p><h2 id="h7d0dc68114">5章: データベースのチューニング</h2><p>特に印象に残ったのはインデックス周りのこと。二分探索に適した構造であるBツリーについて。<br>インデックスの走査についてかなり丁寧に説明されていた。</p><ul><li>Covering Index</li><li>インデックスを貼る基準として頻繁に使われるカラム。それ以外は「ORDER BY」で並び替えを行うカラムに貼る</li></ul><p>特にCovering Indexの概念は知らなかったので詳細にまとめる。</p><blockquote>クエリーによって取得されたすべてのカラムを含むインデックス。完全なテーブル行を見つけるためのポインタとしてインデックス値を使用する代わりに、クエリーはインデックス構造から値を返し、ディスク I/O を節約します。InnoDB セカンダリインデックスには主キーカラムも含まれるので、InnoDB は MyISAM よりも多くのインデックスにこの最適化方法を適用できます。InnoDB は、トランザクションが終わるまで、そのトランザクションによって変更されたテーブルに対するクエリーにこの方法を適用できません。正しいクエリーの場合、どのカラムインデックスまたは複合インデックスでも、カバリングインデックスとして機能できます。可能な場合は必ず、この最適化方法を活用するようにインデックスおよびクエリーを設計してください。</blockquote><p><a href="https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index" target="_blank" rel="noopener noreferrer">https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos</a><a href="https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index" target="_blank" rel="noopener noreferrer"><em>covering</em></a><a href="https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index" target="_blank" rel="noopener noreferrer">index</a><br><br>usersテーブルのnameカラムにindexが貼ってあるとする。<br>これだとidがプライマリーインデックス / nameがセカンダリインデックスとなる。<br>下記のSQLクエリ結果セットで利用しているカラムはidとnameだけなのでCovering Indexが有効になる。（EXPLAIN結果のExtraにUsing Indexが付与される。）<br>これにより、テーブルフルスキャンでなくインデックススキャンのみで結果を返すのでパフォーマンスが良くなる。<br><code>SELECT *</code>の場合は、全てのカラムにインデックスを貼っていないのでCovering Indexは無効となる。</p><pre><code>SELECT id
FROM users
WHERE users.name = 'hoge'</code></pre><p><br></p><h2 id="hc42580f7e1">6章: リバースプロキシの利用</h2><p>Nginxなどプロキシ周りの概要を整理できた感じ。<br>リバースプロキシが必要な理由としてアプリケーション側のHTTPコネクションでは捌ききれないというものがある。<br>本書では例としてunicornを利用したRubyアプリケーションのマルチプロセス・シングルスレッドを紹介している。</p><ul><li>クライアントからの1リクエストを1プロセスが処理する。<ul><li>そのプロセスは処理を行なっている間に他のリクエストを処理できない。（プロセス数 = 最大リクエスト数）<ul><li> 大量リクエストの場合、パフォーマンスが極端に低下するC10K問題を抱えている（1万リクエストを受け取ると処理が急激に悪化する問題）<ul><li>プロセス切り替え時のコンテキストスイッチが大量発生。新しいプロセス用のキャッシュ切り替え =&gt; 処理悪化</li><li>異なるプロセス同士では通常メモリ共有ができないためメモリ使用量が多くなる</li></ul></li></ul></li></ul></li></ul><p><br>このように大量のリクエストを捌くのが難しいので、リバースプロキシでクライアントとのHTTPコネクションを解決する。<br>代表的なものとしてNginxがある。マルチプロセス・シングルスレッドは同じだがイベント駆動アーキテクチャであるため、1プロセスが複数クライアントのリクエストを処理できる。<br>ノンブロッキングI/O（他の処理でのファイル読み書きが完了するまで待たない）と多重I/Oを活用し、イベント駆動でリクエスト・レスポンスを大量に捌くことでC10Kを解決している。<br>業務でもNginxを利用しているがあまり触っていないため色々と忘れがちなので、適宜振り返っていきたいと思う。<br></p><h2 id="h3636ed4f0e">7章: キャッシュの活用</h2><p>この章を読んでキャッシュは慎重に利用したいと感じた。</p><ul><li>古いデータが表示されるリスク</li><li>想定外データを表示して情報流出のリスク</li><li>キャッシュミドルウェアがシステムの障害点に</li><li>プログラムの実装が複雑になる</li></ul><p>本書ではこのような問題があるのでまずはキャッシュを使わない方法を模索してみようと記述されている。<br>確かに扱い方によってはリスクを孕んでいる。<br>また、アプリケーションのインメモリで管理するか外部のミドルウェア（Redis等）で管理するかも色々と考慮ポイント。<br>キャッシュの生存時間（TTL）やThundering herd problem（キャッシュ無い状態で大量リクエスト =&gt; キャッシュ生成するまで処理が続くかつ大量リクエスト =&gt; パフォーマンス悪化）などの問題をちゃんと考慮しないと割とやばそうだということを認識できた。<br></p><h2 id="h81d2da71f8">8章: 抑えておきたい高速化手法</h2><p>特に印象深かったものだけ<br></p><ul><li>同一ホストへのコネクションを使い回す<ul><li>イテレーションで毎回コネクションを作るなどナンセンス。毎度TCPのハンドシェイクが必要になり大量のオーバーヘッドが発生してしまう。確立したコネクションを変数に入れて使い回すなどの対応が必要</li></ul></li><li>適切なタイムアウトを設定<ul><li>常に通信が成功するとは限らないので、ネットワーク障害などに備えて処理時間上限を設けておかないとそこがボトルネックになる。</li></ul></li><li>HTTPヘッダーを活用してクライアント側にキャッシュさせる<ul><li>画像ファイルやCSSファイルなどは更新頻度が低く、参照頻度が高いためCache-Controlヘッダーを活用してキャッシュデータを使いまわせるようにする</li><li>Cache-Controlヘッダーの期限切れの場合にのみリクエストを行うことで、無駄なリクエストを減らせる</li></ul></li><li>静的ファイル配信をリバースプロキシから直接配信する<ul><li>RDBMSに画像データを持たずに静的ファイルにしてNginxから配信させると、無駄な処理を省ける（RDBMSの場合大きなデータを読み込むのでMySQLのメモリを圧迫したり、ネットワーク帯域を圧迫するなど）</li></ul></li><li>CDN上にHTTPレスポンスをキャッシュする<ul><li>キャッシュしたレスポンスを返すことでアプリケーションサーバーへのリクエストを減らせる。</li><li>クライアントから近いCDNエッジからレスポンスを直接返せるので、高速な処理が実現できる</li></ul></li></ul><p>最近、CDN周り（特にCloudflare Workers）をちゃんと触ってみたい欲がすごい。<br></p><h2 id="hc1280a7891">9章: OSの基本知識とチューニング</h2><p>割とOS周りが詳しく記述されているがポイントだけ。<br>Linux周りがまだ分からないことだらけなのでもっと学びたい。</p><ul><li>Linux Kernelの基礎知識<ul><li>カーネル空間 / ユーザー空間<ul><li>System Callを発行する側（アプリケーションやブラウザなど）: ユーザー空間</li><li>System Callを受け取ってハードウェアを制御する側: カーネル空間</li></ul></li><li>プロセス<ul><li>ユーザー空間で実行中のプログラム単位（Webサーバー等）</li></ul></li><li>init / systemd<ul><li>Linuxにはinitという親プロセスがありその下に子プロセスが紐づく（initの実装は最近systemdが多い）</li></ul></li><li>コンテキストスイッチ<ul><li>複数のプロセスを動作させるため、超高速でプロセスを切り替えることで擬似的に複数プロセスが同時に動作しているように見せる =&gt; コンテキストスイッチ</li></ul></li><li>ディスクI/O<ul><li>逐次読み書き: シーケンシャルリード / ライト</li><li>現代では保存領域を上から逐次読み書きするのは現実的ではなくランダムリード/ライトが重視</li></ul></li><li>I/Oスケジューラ<ul><li>ディスク読み書き制御用パラメータ</li><li>Ubuntu20.04では、mq-deadlineスケジューラが採用</li></ul></li><li>ファイルディスクリプタ<ul><li>プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子</li><li>プロセス側からOSに対してこの識別子を指定することで読み書きできる</li></ul></li><li>UNIX domain socket<ul><li>同じホスト内の別プロセスに対して高速にデータを送受信する仕組み</li><li>同じホスト内であることが前提のためネットを介さないことを活かした高効率な通信。</li></ul></li></ul></li></ul><p><br></p><h2 id="ha214098e44">まとめ</h2><p>パフォーマンスチューニングの書籍だけれど、ミドルウェアの設計やアーキテクチャの基礎知識に対する説明が丁寧にされていたのが好印象。<br>Covering Indexの概念を知れたのはよかった。<br>Linux周りがまだ分からないことだらけなのでもっと学びたい。あとCDNも。<br></p>

【読書ログ】達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践

<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</code></pre><p><br></p><pre><code>class Employee &lt; ApplicationRecord
&nbsp;has_many :pictures, as: :imageable
end</code></pre><p><br></p><pre><code>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="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>先日社内の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=""><br></p><h2 id="ha214098e44">まとめ</h2><p>Nested Routesという概念によりまた一つUX体験を向上させる手段を知れたのでよかった。<br>Next.jsと違いSSGやISRといった静的ビルドはないけれど、エッジを使ってSSRを高速化しているというところのアーキテクチャの違いが興味深かった。<br>ちなみこのブログはNext.jsを使って作っておりSSGには日々お世話になっている。<br>エッジらへんもっと知りたいなと思う。<br></p>

Remix触ってみた

<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><a href="https://www.amazon.co.jp/%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%EF%BC%8F%E6%82%AA%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A7%E5%AD%A6%E3%81%B6%E8%A8%AD%E8%A8%88%E5%85%A5%E9%96%80%E2%80%95%E4%BF%9D%E5%AE%88%E3%81%97%E3%82%84%E3%81%99%E3%81%84-%E6%88%90%E9%95%B7%E3%81%97%E7%B6%9A%E3%81%91%E3%82%8B%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9-%E4%BB%99%E5%A1%B2-%E5%A4%A7%E4%B9%9F-ebook/dp/B09Y1MWK9N/ref=sr_1_1?adgrpid=138533859594&amp;gclid=Cj0KCQjw9ZGYBhCEARIsAEUXITXOAPVhOaHQQa4hqqOZa-kQs3jzzYi2QNCaelEBYFrRALHNtJCGumkaAg2BEALw_wcB&amp;hvadid=605173539758&amp;hvdev=c&amp;hvlocphy=1009306&amp;hvnetw=g&amp;hvqmt=e&amp;hvrand=59047735669653945&amp;hvtargid=kwd-1657035072382&amp;hydadcr=27493_14541156&amp;jp-ad-ap=0&amp;keywords=%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E6%82%AA%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A7%E5%AD%A6%E3%81%B6%E8%A8%AD%E8%A8%88%E5%85%A5%E9%96%80&amp;qid=1661299099&amp;sr=8-1" target="_blank" rel="noopener noreferrer">良いコード/悪いコードで学ぶ設計入門</a> を読んで学びになったことをつらつらと書いていく。<br>改めてコードの書き方について見直すきっかけとなった。<br>また、デザインパターンがあまり理解できていないのでそこを学びたいと思った。<br></p><h2 id="h689fdb9e1c">内容<br>1章: 悪しき構造の弊害を知覚する</h2><p><strong>低凝集は避ける</strong><br>データやロジックが分散して低凝集になっていると人間が認知できなくなる。<br>具体的に言うと、ある操作のロジックを追加するときに複数箇所を修正しないといけない場合、変更漏れが起こる可能性が高い。<br>そうなると、対応したのに対応していないというクレームが上がってきて追加修正しないといけない。信頼も失ってしまうので、<br>また、それを知らずに重複コードを書いてしまう可能性や可読性の低下を招いてしまう。さらに、そのコード動作前に初期化処理が必要な場合、それを忘れてしまってnullに対してロジックを実行してしまって実行時エラーになったりとか。<br>個人だけでなくチーム全体の生産性にも悪影響なので、そういったコードは書かない方が良いなと改めて感じた。<br></p><h3 id="h28d4df9be2">2章: 設計の初歩</h3><p><strong>変数への再代入を避ける</strong><br>変数を使い回すと期待通りの出力にならない可能性があり、バグを埋め込んでしまうことになる。<br>読み手も混乱させてしまうので、変数を使い回さずに目的ごとに変数を用意して処理した方が良い。<br></p><h2 id="h1aad4207d5">3章: クラス設計</h2><p>クラス設計のエッセンス</p><ul><li>クラスが単体で正常動作するように疎結合を保つ（高凝集）</li><li>複雑な初期設定をせずとも使えるようにする</li><li>外部公開メソッドは慎重に</li></ul><p><br><strong>コンストラクタで確実に正常値を設定する</strong><br>これによりインスタンス化する際に正常値が確実に設定されることを担保できる<br><br><strong>メソッド引数やローカル変数を不変にする</strong><br>途中で値が変化すると追うのが難しくなるのでバグを引き起こしてしまう<br><br><strong>値の渡し間違いを型で防止する</strong><br>関数は通貨の数字が渡されるのを期待しているのに、number型で定義しているので通過以外の数字が渡ってきてしまう<br></p><pre><code>// NG
const totalMoney = (money: number) =&gt; {
&nbsp;// 処理
}
totalMoney(3)
// OK
const totalMoney = (money: Money) =&gt; {
  // 処理
}
totalMoney(3)</code></pre><p><br>上記例ではMoney型の変数を渡しているがこの変数は「<strong>完全コンストラクタ + 値オブジェクト（</strong>値そのものとクラスとして切り出し表現する<strong>）</strong>」でガード節で不正値を弾き、正常値だけを持つインスタンスを生成するためのコンストラクタ。オブジェクト指向設計の基本形。<br><br>異常値をいかに生み出さないかに焦点が置かれていると思った。<br>クラス設計とは、インスタンス変数を不正状態に陥らせないための仕組みづくりと言っても過言ではありませんと筆者が述べているように、いかに異常値を防ぐかがポイント。<br>確かに普通に考えて設計図から意図しないものが生まれてきたら設計図の意味を成してないよなと思う。<br></p><h2 id="h1519a38524">4章: 不変の活用</h2><p><strong>副作用のデメリット</strong><br>副作用とは、関数が戻り値を返す以外に外部の状態（変数など）を変更すること<br>副作用ってどこまで許容するべきなのかは割と難しいかもしれないと感じる。<br>影響範囲を留めるべきというのは分かるが関数内で引数を操作して返すというのは割とやっている気がする。<br>クラスやサービス横断して副作用を生み出すのは良くなさそう。<br></p><h2 id="hca89c52d5c">5章: 低凝集</h2><p>モジュール内のデータとロジックの関係性の強さ<br><br><strong>共通処理クラスを安易に作らない</strong><br><strong>Common</strong>とか<strong>Util</strong>とか<strong>神クラス</strong>とか<br>ログ出力やエラー処理、デバッグや例外処理などの横断的関心事であれば<br>共通処理として切り出しても良いが、それ以外の場合は本当に共通処理が必要か考えた方が良い。<br>共通処理という名の雑多なロジック生まれがち。<br><br><strong>引数は少なく</strong><br>引数が多すぎると低凝集に陥りがち。<br>引数が多いとそれだけ処理内容が増えるのでロジックの複雑化や重複コードにつながってしまう。<br>そういう場合、データを引数として扱うのではなくそのデータをインスタンス変数としてもつクラスへと変更してみる。<br>この考え方は学びになった。<br>メソッド内で複数のオブジェクトを操作している状態から、クラスとして切り出し関心事を分離していく。<br>そうすることで全体として見通しが良くなるなと感じた。<br><br><strong>尋ねるな命じろ</strong><br>他のオブジェクトの状態を問い合わせるのではなく、呼び出し側はただメソッドを呼び出すだけにする。<br>オブジェクトの状態を判定するロジックなどは呼ばれる側で実装するべき。<br>こうすることでロジックの高凝集につながる。<br>この考え方はAPI設計に通ずるものがあると感じた。外部インターフェースとして呼び出すものを与えるだけで、内部状態は気にさせない。呼び出す時も余計なロジックを考えずに済む。<br></p><h2 id="h3a4df45a80">6章: 条件分岐</h2><p>この章は条件分岐はinterfaceに書き換えると良いということが学びになった。<br></p><h2 id="h1d365a9066">8章: 密結合</h2><p>継承はなるべく非推奨とのこと。サブクラスがスーパークラスに依存するので密結合やロジック混乱などになりがちとのこと。<br>書籍には「ある継承クラスにとっては関係があっても、別の継承クラスには無関係なメソッドが登場し始めると問題」とあったけれど、これは単一責任の原則を破っているからだと思う。<br><a href="https://qiita.com/tonluqclml/items/c0110098722763caa556" target="_blank" rel="noopener noreferrer">Qiita</a>とかに参考記事があったけれど、共通メソッドや変数を共有するためなどの安易な継承は避けるべきだというのを見て納得した。<br><br></p><h2 id="hcca18313f3">10章: 名前設計</h2><p>書籍では目的駆動名前設計を推してる。<br>目的ベースでの命名。確かに商品や顧客にもいろいろな切り口があるのでしっかりと目的を検討して区別する必要ある。<br>ドメイン理解と元に切り分ける大事さ。<br>特に印象に残ったのが、「<strong>形容詞で区別が必要なときはクラス化のチャンス</strong>」ということ。<br>正しくその通りだなと思ったので、今後意識していきたいなと考えている。<br></p><h2 id="he9b3718a37">12章 メソッド</h2><h3 id="h685e355525">CQS（コマンドクエリ分割）</h3><p>メソッドはコマンド（変更）またはクエリ（問い合わせ）のどちらか一方だけを行うようにするという考え方らしい。<br>これは自然と意識するようにしてるなと思う。パターン名があったというのが発見かも。<br></p><h2 id="hfa4a437f7a">13章 モデリング</h2><p>10章名前設計の章と被るところだが、任意のモデルが適切に分割されていることが大事だなと思う。<br>単一責任の原則をどれだけ意識できているか？自分達のドメインでCustomerモデルはどういう種類の顧客を扱っているのか？<br>それをするには事業ドメインを深く理解することが大事。<br></p><h2 id="had71b19400">16章 設計を妨げる開発プロセスとの戦い</h2><p>色々記述されているが「<strong>既存コードを信用せず、冷静に正体を見破る</strong>」を意識したい。<br>既存実装を模倣することが多いけれど、その実装は本当にベストなのか？は今一度冷静になって見極める意識を持ちたい。<br></p><h2 id="ha214098e44">まとめ</h2><p>今のチームが拡大するにあたって保守性を第一に考えたいと思っていて、設計周りをきちんと抑えておきたかったので読んだ。<br>筆者の主張がいくらか強い部分もあったけれど、クラス設計やCQSなど勉強になった。今一度良いコードとは何かを考え直すきっかけになったと思う。次はドメイン駆動設計やデザインパターンをちゃんと抑えたい。<br></p>

【読書ログ】良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

<h2 id="h9707d3a59a">概要</h2><p><a href="https://github.com/type-challenges/type-challenges" target="_blank" rel="noopener noreferrer">type-challenges</a> というTS文法の練習問題リポジトリがある。<br>興味本位で解いてみたら楽しくなってきてeasyレベルからmediumレベルまで81問解いてしまった。<br>その際にTSについての学びが色々あったので共有する。<br></p><h2 id="h3c2838a701">学び一覧</h2><ul><li>mapped types</li><li>conditional types</li><li>infer</li><li>minus operator</li><li>union distribution</li><li>never</li><li>template literal types</li><li>length property</li><li>index(numeric) signature </li><li>bottom type</li></ul><p><br></p><h3 id="h5a9ee7e81f">mapped types</h3><p>公式doc: <a href="https://www.typescriptlang.org/docs/handbook/2/mapped-types.html" target="_blank" rel="noopener noreferrer">https://www.typescriptlang.org/docs/handbook/2/mapped-types.html</a><br><br>型引数が主にユニオン型orオブジェクトの場合に利用することが多い。<br>型引数をイテレーションして結果出力する。</p><pre><code>type MappedTypes&lt;T extends object&gt; = { [P in keyof T]: T[P] }&nbsp;
type s = MappedTypes&lt;{ key: 'test', value: 'test'}&gt;
// type s = {
//&nbsp;&nbsp;key: 'test';
//&nbsp;&nbsp;value: 'test';
// }
type MappedTypes2&lt;T extends string&gt; = { [P in T]: string }&nbsp;
type t = MappedTypes2&lt;'test' | 'tt'&gt;
// type t = {
//&nbsp;&nbsp;test: string;
//&nbsp;&nbsp;tt: string;
// }</code></pre><p><br></p><h3 id="h0f18470ad3">conditional types</h3><p>公式doc: <a href="https://www.typescriptlang.org/docs/handbook/2/conditional-types.html" target="_blank" rel="noopener noreferrer">https://www.typescriptlang.org/docs/handbook/2/conditional-types.html</a><br><br>型の条件分岐を実現する。</p><pre><code>TypeA extends TypeB ? true : false</code></pre><h3 id="hcf83e1357e"><br></h3><p>公式docによるとこの条件はextendsの左の型が右の型に代入可能かどうかを判定している。</p><blockquote>When the type on the left of the&nbsp;<code>extends</code>&nbsp;is assignable to the one on the right, then you’ll get the type in the first branch (the “true” branch); otherwise you’ll get the type in the latter branch (the “false” branch).</blockquote><p><br>そのためこれはもちろんfalse</p><pre><code>type test = string extends number ? true : false
// =&gt; false</code></pre><p><br>こちらは原則から考えてtrueになる。</p><pre><code>type test = 't' extends string ? true : false
// =&gt; true</code></pre><p>bottom typeの節でneverやundefinedをconditional typesで比較検証する。<br></p><h3 id="h2e45f7d90e">infer</h3><p><a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types" target="_blank" rel="noopener noreferrer">公式doc</a><br>型を割り出してその後利用できる。conditional typesとセットで利用する。<br>例えば、type-challengesの<a href="https://github.com/type-challenges/type-challenges/blob/main/questions/00015-medium-last/README.md" target="_blank" rel="noopener noreferrer">Last of Array</a> の問題では下記のように解ける。<br>型引数Tをconditional typesで分岐させ、その中でinferを利用して推論した変数L（配列の最後の要素）を利用する。</p><pre><code>type Last&lt;T extends any[]&gt; = T extends [...infer _, infer L] ? L : never
type s = Last&lt;[]&gt;
// =&gt; never
type t = Last&lt;[1,2,3]&gt;
// =&gt; 3</code></pre><p><br></p><h3 id="h7bec72aa54">minus operator</h3><p><a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#improved-control-over-mapped-type-modifiers" target="_blank" rel="noopener noreferrer">公式doc</a><br>mapped types内の<strong>readonly</strong>や<strong>?</strong>を削除するための修飾子<br>例えば、type-challengesの<a href="https://github.com/type-challenges/type-challenges/blob/main/questions/02793-medium-mutable/README.md" target="_blank" rel="noopener noreferrer">Mutable</a> の問題では下記のように解ける。</p><pre><code>type Mutable&lt;T&gt; = {
&nbsp;-readonly [K in keyof T]: T[K]
}
type s = Mutable&lt;{ readonly test: 1 }&gt;
// type s = {
//&nbsp;&nbsp;&nbsp;test: 1;
// }</code></pre><p><br></p><h3 id="h9f9cf84c8f">union distribution</h3><p><strong>conditional types</strong>や<strong>mapped types</strong>にunion型を渡すと1つずつ処理される。<br><br>conditional typesでは条件の左部分が型変数である場合にunion型が分配される。<br></p><pre><code>type Equal&lt;U&gt; = U extends 1 ? U : never
type s = Equal&lt;1 | 2&gt;
// type s = 1</code></pre><p><br>例のコードでは型変数Uにunion型が渡っており1だけを返す。つまり下記が行われている。</p><pre><code>(1 extends 1) ? U : never
(2 extends 1) ? U : never</code></pre><p><br>mapped typesでは以下のような形の場合にunion distributionが発生する。</p><pre><code>{ [P in keyof T]: X}</code></pre><p><br></p><pre><code>type Distribution&lt;T&gt; = { [P in keyof T]: T[P] };
type val = Distribution&lt;{ foo: string } | { bar: number }&gt;
// type val = Distribution&lt;{
//&nbsp;&nbsp;&nbsp;foo: string;
// }&gt; | Distribution&lt;{
//&nbsp;&nbsp;&nbsp;bar: number;
// }&gt;</code></pre><p><br></p><h3 id="h8d802c5abf">never</h3><p><a href="https://typescriptbook.jp/reference/statements/never" target="_blank" rel="noopener noreferrer">サバイバルTypeScript</a>より<br></p><blockquote>TypeScriptのneverは「値を持たない」型。<br>1️⃣特性1: neverへは何も代入できない<br>2️⃣特性2: neverは何にでも代入できる<br>💥常に例外を起こす関数の戻り値に使える</blockquote><p><br><a href="https://typescript-jp.gitbook.io/deep-dive/type-system/never" target="_blank" rel="noopener noreferrer">TypeScript Deep Dive</a>より</p><blockquote>プログラミング言語の設計には、bottom型の概念があります。それは、データフロー解析を行うと現れるものです。TypeScriptはデータフロー解析(😎)を実行するので、決して起こりえないようなものを確実に表現する必要があります。<br>never型は、このbottom型を表すためにTypeScriptで使用されます。</blockquote><p><br><a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E8%A7%A3%E6%9E%90" target="_blank" rel="noopener noreferrer">Wikipedia</a> より</p><blockquote>データフロー解析（英: Data-flow analysis）は、プログラム内の様々な位置で、取りうる値の集合に関する情報を収集する技法である。制御フローグラフ (CFG) を使って変数の値が伝播するかどうかなどの情報を集め、利用する。このようにして集められた情報はコンパイラが最適化に利用する。データフロー解析の基本は到達定義 (reaching definition) である。</blockquote><p><br></p><h3 id="h4c7717a3dd">template literal types</h3><p>JSのテンプレートリテラルを使って展開した値をそのまま型として定義できる。</p><pre><code>type Join&lt;T extends string, U extends string&gt; = `${T}-${U}`&nbsp;
type joinedStr = Join&lt;'foo', 'bar'&gt;
// type joinedStr = "foo-bar"</code></pre><p><br>conditional types + inferを利用していこんな風にも書ける。</p><pre><code>type TemplateLiteral&lt;T extends string&gt; = T extends `${infer F}${infer _L}` ? F : never
type str = TemplateLiteral&lt;'foo'&gt;
// type str = "f"</code></pre><p><br>type-challengesで文字列操作するときに初めて知って表現力に驚いたな。<br></p><h3 id="h092b022bfe">length property</h3><p><br>配列やタプルの要素数をカウントして返す<br></p><pre><code>type val = [1,3]['length']
// type val = 2</code></pre><p><br>Arrayのinterfaceにlengthプロパティが存在する。<br></p><pre><code>interface Array&lt;T&gt; {
&nbsp;&nbsp;/**
&nbsp;&nbsp;&nbsp;* Gets or sets the length of the array. This is a number one higher than the highest index in the array.
&nbsp;&nbsp;&nbsp;*/
&nbsp;&nbsp;length: number;
&nbsp;&nbsp;/**</code></pre><p><a href="https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402" target="_blank" rel="noopener noreferrer">https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402</a><br></p><h3 id="h043e2b5c2d">index (numeric) signature</h3><p><br>配列(orタプル)TにおいてT[number]がunion型で返ることから知った<br><a href="https://www.typescriptlang.org/docs/handbook/2/conditional-types.html" target="_blank" rel="noopener noreferrer">公式doc</a> にも記載ある。<br><a href="https://stackoverflow.com/a/59188070" target="_blank" rel="noopener noreferrer">stackoverflow</a> の記事では、Arrayは下記のようなinterfaceになっていて numberを使ってindexをまとめて取得できるよう。<br><a href="https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392" target="_blank" rel="noopener noreferrer">https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392</a> かな？ちょっと分からないけど。<br></p><h3 id="h721c73850c">bottom type</h3><p>neverは値を持たないということを表す型でありbottom型とも呼ばれる。<br>集合論で表すと空集合。never型には何も代入できない（値持たないから）が、never型は他の型に代入できる。<br>他の全ての型のサブタイプ（部分型）となる。is-aの関係。逆はできない（他の型をnever型に代入）<br></p><pre><code>let neverVal: never = 1 as never;
// never 型は bottom type なのでstring型に代入可能
let str: string = neverVal;</code></pre><p><br>ちなみにunkhownは全ての型のスーパータイプなのでどんな型でも代入可能</p><pre><code>let str = 'str'
// unkhown 型は super type なのでstring型を代入可能
let neverVal: unknown = str</code></pre><p><br><a href="https://zenn.dev/estra/articles/typescript-type-set-hierarchy#%E5%9E%8B%E3%81%AE%E9%9A%8E%E5%B1%A4%E6%80%A7" target="_blank" rel="noopener noreferrer">TS型の階層性</a> に詳しく説明がある。</p><h3 id="hcf83e1357e"><br></h3><h2 id="hd65d520d41">今後知りたいこと</h2><ul><li>type widening</li><li>homomorphic mapped types</li><li>union distributionをキャンセルする</li><li>etc...</li></ul><p><br></p><h2 id="ha214098e44">まとめ</h2><p><a href="https://github.com/type-challenges/type-challenges" target="_blank" rel="noopener noreferrer">type-challenges</a>&nbsp;でTSの型プログラミングにどっぷりハマった。<br>また再帰的に解く問題が多かったので自然と再帰的に考えられたのもとても良かった。<br>この経験を通じてTSが好きになったのでもっと深掘りたいと思えたのは大きな収穫。</p>

type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

<p><br></p><h2 id="h9ced1f0f73">要約</h2><p>TSの基礎的な内容が割と網羅されている印象。<br>抜けていた基礎知識を補えたのが良かった。<br></p><h2 id="h69b6fd00fa">1章</h2><p>TSバージョンの年表が面白かった印象。<br>TS 4.1から応用性の高いtemplate literal typesが導入されてお祭り騒ぎになったらしい。元<a href="https://github.com/microsoft/TypeScript/pull/40336" target="_blank" rel="noopener noreferrer">PR</a><br>template literal typesってinferと組み合わせると有用だなと思ったり。<br><br>あとはenum使わない方が良いみたいなのは知らなかった。<br>JSには存在しない独自機能だからとのこと。<br><br><a href="https://engineering.linecorp.com/ja/blog/typescript-enum-tree-shaking/" target="_blank" rel="noopener noreferrer">LINE社の記事</a> を見ると、JSに存在しないenumを表現するためにIIFE(即時実行関数)を含んだコードをトランスパイルするらしい。それがバンドルされてしまうからtree-shakingできなくなるよとのこと。なるほど。<br><br></p><h2 id="h6e1fa0b8f7">2章</h2><p>値がない状況を表すのにundefinedの方が推奨されるとのこと。<br><a href="https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined" target="_blank" rel="noopener noreferrer">MicrosoftのTSコーディング規約</a>にも <strong>Use undefined. Do not use null. </strong>の記載がある。<br><a href="https://typescriptbook.jp/reference/values-types-variables/undefined-vs-null" target="_blank" rel="noopener noreferrer">サバイバルTypeScript</a>にはこのような記述がある<br></p><ul><li>undefinedは「値が代入されていないため、値がない」nullは「代入すべき値が存在しないため、値がない」</li><li>nullは自然発生しない</li><li>undefinedは変数</li><li>undefinedはtypeofの結果がプリミティブ名を表す"undefined"になるのに対し、nullは"null"ではなく"object"になります。</li></ul><p>最後のは割とびっくりする挙動。<br>言語使用的にundefinedが自然発生してくれるのでそれに合わせにいくのが良さそう。<br>ただ外部APIとのやり取りでnullが渡ってくるのはあると思うので、そこの考慮が必要そう。<br><br><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator" target="_blank" rel="noopener noreferrer">Null 合体演算子 (??)&nbsp;</a> と <a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR" target="_blank" rel="noopener noreferrer">論理 OR 演算子 (||)&nbsp;</a> の違いを知った。<br><strong>|| </strong>はnullやundefinedだけでなく空文字や0、falseなども "ない"と評価して右辺値を返すが、<strong>??</strong>はnull or undefinedの場合のみ右辺値を返す。<br><br>ES2021の新機能として <a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment" target="_blank" rel="noopener noreferrer">||=(論理和代入)</a><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment" target="_blank" rel="noopener noreferrer"><strong> </strong></a>や<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment" target="_blank" rel="noopener noreferrer"><strong>&amp;&amp;=</strong></a><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment" target="_blank" rel="noopener noreferrer">(論理積代入)</a>演算子もある。<br>論理和代入はrubyの自己代入演算子と同じ。論理積代入は左辺がtruthyなものの場合に右辺の値を左辺に代入。<br></p><h2 id="hef71cdba9a">3章</h2><h3 id="h694e0c6ca5">スプレッド構文とシャローコピー</h3><p>スプレッド構文はシャローコピーであること。<br>下記よりスプレッド構文でコピーしてもネストしたオブジェクトは同じアドレスを共有している。</p><pre><code>const object = {
  name: 'test',
  type: {
    a: 'a'
  }
}
const anotherObject = { ...object }
object.name = 'object'
anotherObject.type.a = 'b'
console.log('object', object)
console.log('anotherObject', anotherObject)
// object { name: 'object', type: {a: 'b'} }
// anotherObject { name: 'test', type: {a: 'b'} }</code></pre><p><br><a href="https://developer.mozilla.org/ja/docs/Glossary/Deep_copy" target="_blank" rel="noopener noreferrer">ディープコピーをする方法</a>の1つとして、<strong>JSON.stringify()</strong> でオブジェクトを JSON 文字列に変換し、 <strong>JSON.parse()</strong> で文字列から（完全に新しい） Javascript のオブジェクトに変換する方法がある。<br>また、ネストしたオブジェクトもスプレッド構文で展開する等々。<br></p><h3 id="h872384eb1f">インデックスシグネチャについて</h3><p><a href="https://typescript-jp.gitbook.io/deep-dive/type-system/index-signatures" target="_blank" rel="noopener noreferrer">インデックスシグネチャ</a>は型安全性を破壊する。<br>オブジェクトのkeyがstringの場合、obj.key でアクセスできるが、obj.foo / obj.aなど任意のkeyにもアクセスできてコンパイルエラーにならないので型安全ではない。</p><pre><code>type Obj = { [key: string]: number }
const obj: Obj = { foo: 1 }
console.log(obj.t)
// =&gt; コンパイルエラーにならない</code></pre><p><br></p><h3 id="h1d84c5f837">部分型関係について</h3><p>型Sが型Tの部分型であるとは、S型の値がT型の値でもあることを指す。<br>下記の例ではFooBarBaz がFooBar の部分型である。<br>FooBarBazはFooBarの要素を全て持つ。FooBarBaz型であればFooBar型でもあるということ。</p><pre><code>type FooBar = {
  foo: string,
  bar: number,
}
type FooBarBaz = {
  foo: string,
  bar: number,
  baz: boolean,
}
const obj: FooBarBaz = {
  foo: "hi",
  bar: 1,
  baz: false,
}
const obj2: FooBar = obj;
console.log('obj', obj)
// =&gt; 
// "obj",  {
//   "foo": "hi",
//   "bar": 1,
//   "baz": false
// } 
console.log('obj2', obj2)
// =&gt; 
// "obj2",  {
//   "foo": "hi",
//   "bar": 1,
//   "baz": false
// } </code></pre><p><br></p><h3 id="h6a9786ad7c">タプル型</h3><p>要素数が固定された配列型。<br>要素数が固定されている代わりに、それぞれの要素に異なる型を与えられる。<br></p><h3 id="h985f997464">オブジェクトの分割代入（destructuring assignment）について</h3><p>型注釈つけられないで型推論していく<br></p><h3 id="he4b216a320">プリミティブのプロパティ</h3><p>文字列や数値などのプリミティブ型は、プロパティを持ったオブジェクトとして扱える。<br>プリミティブ型をまるでobjectのように扱えるのはJSの特徴。JSには、プリミティブ型をオブジェクトに自動変換するオートボクシングと呼ばれる機能がある。参考: https://typescriptbook.jp/reference/values-types-variables/primitive-types</p><pre><code>"name".length; // 4</code></pre><p><br></p><h2 id="ha3ab08a7dd">4章</h2><h3 id="hc105ec4742">contextual typing</h3><p>逆方向の方推論のことで、型が事前に分かっている場合の推論。<br>通常の型推論は型注釈は無いけれど値から型を推論できる場合に発動</p><pre><code>const xRepeat = (arg: number): string =&gt; "x".repeat(arg)
// xRepeatの型が自動的にconst xRepeat: (arg: number) =&gt; string と判定される</code></pre><p>逆方向の型推論は型を事前に割り当てているから式中の型を省略できる。</p><pre><code>type F = (arg: number) =&gt; string
const xRepeat: F = (arg) =&gt; "x".repeat(arg)
// (arg: number): string の指定は不要</code></pre><p>コールバック関数なども指揮中で引数の型を書かない場合が多い。<br>例えばfilterなどはレシーバを元に型引数が決まる。</p><pre><code>const nums = [1,2,3]
const ary = nums.filter((x) =&gt; x &gt; 2);
// 式中xの変数をnumberとしなくても x&gt;2 でコンパイルエラーが起きない
// (value: number) =&gt; unkhown</code></pre><p><br></p><h2 id="h20aab41515">5章</h2><p>protectedはクラス自身だけでなく子クラスからもアクセス可能。rubyと同じだな。<br></p><h3 id="h42d608e030">プライベートプロパティについて</h3><p>#プロパティ名 と private修飾子をつけたもの両方で表現可能。</p><ul><li>privateはTS独自機能なのでトランスパイル後のランタイム上では普通のプロパティとして扱う。</li><li>#プロパティ名はJSの機能なのでランタイム上でもプライベート性が担保される</li></ul><p><br></p><h3 id="ha4932b1f17">this</h3><p>thisはプロパティを参照することが多く、そのプロパティがundefinedであった場合にランタイムエラーが発生する可能性あり。</p><ul><li>アロー関数は外側のthisを引き継ぐ</li><li>普通の関数は呼び出し時のレシーバをthisとする</li></ul><p>アロー関数への書き換えをするリファクタリングを業務で行ったなあ。<br></p><h2 id="h08f5f7bf4b">6章</h2><h3 id="h6d915dfb24">インターセクション型</h3><p>T型でありかつU型でもある値を意味する型<br>参考: https://typescriptbook.jp/reference/values-types-variables/intersection<br>ちなみに string &amp; numberのプリミティブのインターセクション型は存在しないのでnever返る<br></p><h3 id="h384b8598ca"><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Optional_chaining" target="_blank" rel="noopener noreferrer">Optional chaining</a></h3><p>レシーバに対する参照が nullish (null または undefined) の場合にエラーとなるのではなく、式が短絡され undefined が返される。<br>?.はそれ以降のプロパティアクセス・関数呼び出し・メソッド呼び出しをまとめて飛ばす効果を持つ。<br></p><pre><code>const adventurer = {
&nbsp; name: 'Alice',
&nbsp; cat: {
&nbsp; &nbsp; name: 'Dinah'
&nbsp; }
};
const dogName = adventurer.dog?.name.t;
console.log(dogName);
// expected output: undefined
// dogが存在しないのでそれ以降の .name.t は評価されずにundefinedが返る
console.log(adventurer.someNonExistentMethod?.());
// expected output: undefined</code></pre><p><br></p><h3 id="hc2e602cb99">リテラル型のwidening</h3><p>リテラルが自動的に対応するプリミティブ型に変化する（広げられる）特徴。<br>const の場合はリテラル型なのにletの場合はプリミティブ型に変化している。<br>letは再代入が期待されるのでプリミティブ型に変化する。<br>ちなみにconstで宣言したオブジェクトリテラルも再代入可能なのでwideningされる。</p><pre><code>const test1 = "test"
// const test1: "test"
let test2 = "test"
// let test2: string
const test = {
  a: "a",
  b: 1
}
// const test: {
//   a: string;
//   b: number;
// }</code></pre><p><br>wideningを防ぎたい場合は、リテラル型を含む型注釈をつけるか as constを利用して宣言する。<br></p><h3 id="hf6b843d5cc">ユニオン型</h3><p>型の絞り込みに対応している点が素晴らしいとのこと。なるほど、そういう解釈ができるのか。<br>関数の引数をユニオン型で取って、式中で型の分岐を行つつ処理をしていけるということに価値があるのか。<br></p><h3 id="h3768d01934">lookup型</h3><p><strong>T[K]</strong>のようにオブジェクトプロパティにアクセスする際の型<br></p><h3 id="hae52de7bd8">as const </h3><p>asを使った型アサーションは型安全性を破壊しかねないけれど、as constはそれとは異なる。</p><ol><li>配列リテラルの型推論結果を配列型ではなくタプル型にする</li><li>オブジェクトリテラルから推論されるオブジェクト型は全てreadonlyになる（配列リテラルも）</li><li>プリミティブのリテラル型がwideningしない</li><li>テンプレート文字列リテラルの方がstringではなくテンプレートリテラル型になる</li></ol><p><br></p><pre><code>// readonly
const names = ["taro", "jiro"] as const
// =&gt; const names: readonly ["taro", "jiro"]
const obj = { name: "test", address: { city: "xxxx" }} as const
// const obj: {
//&nbsp;&nbsp;readonly name: "test";
//&nbsp;&nbsp;readonly address: {
//&nbsp;&nbsp;&nbsp;&nbsp;readonly city: "xxxx";
//&nbsp;&nbsp;};
// }
// wideningされない
const name1 = "name" as const
let name2 = name1
// let name2: "name"
let name3 = "name3"
// let name3: string
// templateliteral type
const n: number = 1
const value = `${n}px` as const;&nbsp;
// const value: `${number}px`</code></pre><p><br></p><h3 id="h24f64eac56">any型とunkhown型</h3><ul><li>any型<ul><li>型チェックを無効化する型。基本的に何でも代入可能なのでコンパイルエラーにならない。</li><li>JSからTSへの移行を支援するためや、型をうまく表現できないためのエスケープハッチとしての存在理由あり</li><li>anyよりasやユーザー定義型ガードの利用を検討した方が良い</li></ul></li><li>unkhown型<ul><li>なんでも入れられる型。何かは入っているが何かは分からないような状況を表す</li><li>anyはコンパイルエラーにならないので、val.nameなどにアクセスできるがunkhownはできない。TSコンパイラがunkhownは値がないことを読み取ってできることを制限してくれる。</li></ul></li></ul><p><br></p><h3 id="h2c66b8addf"><strong>never型</strong></h3><p>値を持たないことを表す型<br>never型には何も代入できない。（never型にnever型は代入可能）<br>他の型にnever型は代入できる。<br>そのため、<a href="https://typescript-jp.gitbook.io/deep-dive/type-system/never" target="_blank" rel="noopener noreferrer">TSではbottom型と呼ばれている</a>。（<a href="https://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B#:~:text=%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B%EF%BC%88%E3%83%9C%E3%83%88%E3%83%A0%E3%81%8C%E3%81%9F,%E3%81%84%E3%81%8B%E3%81%AA%E3%82%8B%E5%80%A4%E3%82%82%E8%BF%94%E3%81%95%E3%81%AA%E3%81%84%E3%80%82" target="_blank" rel="noopener noreferrer">取りうる値の集合が一番大きい</a> =&gt; ボトム型は全ての型の部分型）<br></p><h4 id="hfdb3b8d308"><a href="https://typescriptbook.jp/reference/statements/never" target="_blank" rel="noopener noreferrer">voidとneverの違い</a></h4><ul><li>voidはundefinedを代入できるがneverはできない（値を持たないから）</li><li>どちらも戻り値がないことは同じ<ul><li>voidは関数がreturnされるか、最後まで実行されることを表す</li><li>neverは中断されるか永遠に実行される</li></ul></li></ul><p><br></p><h3 id="h92387e8573"><strong>ユーザー定義型ガード</strong></h3><p>型の絞り込みの一種<br><strong>引数名 is 型名</strong>という形で引数を型名で絞り込んで処理する。<br>下記の関数は戻り値がbooleanであり、trueならば引数がstring or numberであるということを意味する。</p><pre><code>function isStringOrNumber(value: unknown): value is string | number {
&nbsp;return typeof value === "string" || typeof value === "number";
}
function useUnknown(v: unknown) {
&nbsp;// v はここでは unknown 型
&nbsp;if (isStringOrNumber(v)) {
&nbsp;// v はここでは string | number 型
&nbsp;console.log(v.toString());
&nbsp;}
}</code></pre><p><br>参考: <a href="https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/" target="_blank" rel="noopener noreferrer">https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/</a><br><br><strong>asserts 引数名 is 型名</strong>という型述語もある。<br>この場合は戻り値がvoidで「関数が無事に終了すれば引数名は型名である」<br></p><h3 id="h9f9cf84c8f"><strong>union distribution</strong></h3><p>conditional typesの性質<br>conditinal typesを利用している型にユニオン型を渡すと分配して処理してくれる<br><a href="https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types" target="_blank" rel="noopener noreferrer">公式</a> のやつコピペしただけだけどこんな感じになる。</p><pre><code>type ToArray&lt;Type&gt; = Type extends any ? Type[] : never;
&nbsp;
type StrArrOrNumArr = ToArray&lt;string | number&gt;;
//&nbsp;&nbsp;ToArray&lt;string&gt; | ToArray&lt;number&gt;; と等しいので、string[] | numbe[]が返る</code></pre><p><br></p><h2 id="h853e373df0">7章</h2><h3 id="h1f15e26673">commonJS</h3><p><a href="https://nodejs.org/docs/latest/api/modules.html" target="_blank" rel="noopener noreferrer">nodejsで利用されているソースコードをパッケージ化するモジュール。</a><br>最近はECMAScriptのESmodule形式も採用しているよう。<br>requireを利用してimportする。</p><pre><code>const circle = require('./circle.js');
console.log(The area of a circle of radius 4 is ${circle.area(4)});</code></pre><p> </p><h2 id="hec95416674">今後</h2><p>(本書付録2の更なる学習の道しるべコピペしただけ)<br>JS言語機能</p><ul><li>イテレータ・ジェネレータ</li><li>メタプロ系<ul><li>オブジェクトの操作（Object.keys）など</li><li>プロパティディスクリプタ・プロパティ属性</li><li>Reflect・Proxy</li></ul></li><li>シンボル</li><li>prototype</li></ul><p>TSの言語機能</p><ul><li>標準ライブラリに属する他の型（Record・Parameters・Awaitedなど）</li><li>abstractクラス・abstract new シグネチャ</li><li>型レベルプログラミング</li><li>mapped types conditionaltypes<ul><li>infer / union distribution / homomophic typesなど</li></ul></li></ul><p><br></p>

【読書ログ】プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで

<h2 id="h9707d3a59a">概要</h2><p>React18リリースがあった関係でWEB DB PRESS vol.129にReactの深層シリーズが掲載されていたので、改めてReactの思想や設計原則などを見直した。<br></p><h2 id="h024acb2e84">Reactの特徴</h2><ul><li>宣言的UI</li><li>コンポーネント志向</li><li>仮想DOM</li><li>単方向データフロー</li></ul><p>の4つが大まかな特徴と捉えている。<br><br>UIとして表示する部品をコンポーネントとしてラップして定義した上で、「この場合はこのdivタグを置いて..」みたいな細かい制御ロジックが書かれる命令的UIではなく、あるべき状態を<strong>宣言</strong>したUIを記述する形式。<br>命令的UIのように画面描写の変化過程を記述するのではなく、結果のみを記述していく。<br><br>WEB+DB PRESSに記載のある「宣言的UIでは<strong>状態(state)</strong>と<strong>UI</strong>が明確に分けられており、ユーザーがアプリケーションを使うということはアプリケーションの状態を操作するということであって、<strong><u>UIというのは現在の状態をユーザーに知らせるための映写装置である</u></strong>」部分が印象に残っている。<br>つまり、命令的UIで扱っていたロジックを状態管理に持ち込むことで、UIは現在の状態を映写するだけという感じ。<br><br>状態が変更されて仮想DOMが生成され、実際のDOMとの差分検出を行い、DOMの更新を行う。jQueryなど実際のDOMをいじるのではなく差分検出してDOM構築して一括更新。<br><br>mizhiさんの記事がとても勉強になる。<br><a href="https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766" target="_blank" rel="noopener noreferrer">https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766</a><br><br>そして単方向データフロー。<br>従来のMVCではModelとViewの間に双方向のデータフローが作られる可能性があるので、理解やデバッグが困難。<br>例えば、Viewが複数Modelのデータ参照 / 更新を行うことでデータフローが循環する形。これが多くなると複雑度が増す。<br>そういった背景からFLUXアーキテクチャが登場し、ViewからのイベントがStoreに発行され、Storeが更新されたらViewも更新するという単一のデータフローが構築された。<br><br>この記事が参考になる。<br><a href="https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/" target="_blank" rel="noopener noreferrer">https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/</a><br></p><h2 id="h45d9515eb6">Reactのimmutabilityについて</h2><p>単方向データフローやコンポーネントのカプセル化なども重要だけど、同じくらい、immutabilityの重要性も重要。<br><a href="https://ja.reactjs.org/tutorial/tutorial.html#why-immutability-is-important" target="_blank" rel="noopener noreferrer">Reactの公式tutorial</a>にもあるけれど、immutabilityが重要な理由として下記3つ挙げられている。</p><ul><li>複雑な機能が簡単に実装できる</li><li>React自身がオブジェクトの変更を検知しやすくなる</li><li>コンポーネント再描画のタイミングが決定しやすくなる</li></ul><p><br>このブログ記事が参考になる。<br><a href="https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/" target="_blank" rel="noopener noreferrer">https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/</a><br><a href="https://tech.kitchhike.com/entry/react-should-component-update" target="_blank" rel="noopener noreferrer">https://tech.kitchhike.com/entry/react-should-component-update</a><br><br>Reactは <a href="https://ja.reactjs.org/docs/react-component.html#shouldcomponentupdate" target="_blank" rel="noopener noreferrer">shouldComponentUpdate()</a> という API を通じてrenderするかを決定している。<br>その際、コンポーネントに新しいpropsが渡されるもしくは状態(state)が更新されたら呼び出されてbooleanを返す。<br>trueならばrenderされて、falseならば逆。<br><br>内部実装を見てみる。<br><a href="https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js" target="_blank" rel="noopener noreferrer">https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js</a><br></p><pre><code>// @flow
import areEqual from './areEqual';
import shallowDiffers from './shallowDiffers';
// Custom shouldComponentUpdate for class components.
// It knows to compare individual style props and ignore the wrapper object.
// See https://reactjs.org/docs/react-component.html#shouldcomponentupdate
export default function shouldComponentUpdate(
  nextProps: Object,
  nextState: Object
): boolean {
  return (
    !areEqual(this.props, nextProps) || shallowDiffers(this.state, nextState)
  );
}</code></pre><p><br>内部的には areEqualもしくはshallowDiffers 関数を呼んでいることがわかる。<br>areEqual内部でも shallowDiffers関数を呼んでいるので、実質shallowDiffersの中身がstate or propsの変更を検知するロジックになっていそう。<br><br>shallowDiffersの中身を見てみる。<br><a href="https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5" target="_blank" rel="noopener noreferrer">https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5</a><br></p><pre><code>// @flow
// Pulled from react-compat
// https://github.com/developit/preact-compat/blob/7c5de00e7c85e2ffd011bf3af02899b63f699d3a/src/index.js#L349
export default function shallowDiffers(prev: Object, next: Object): boolean {
  for (let attribute in prev) {
    if (!(attribute in next)) {
      return true;
    }
  }
  for (let attribute in next) {
    if (prev[attribute] !== next[attribute]) {
      return true;
    }
  }
  return false;
}</code></pre><p><br>やっていることはシンプルで</p><ul><li>1つ目のfor文で変更前と変更後のstate or propsを比較して新しい要素が追加されたのかを確認</li><li>2つ目のfor文で変更前と変更後のstate or propsで指定されたkeyの値が一致するのかを確認</li></ul><p>をやっている。<br><br>ここから分かることは、<strong style="color:#c7243a"><u>propsやstateをmutableに変更してしまったら再renderされない可能性がある</u></strong>ということ。<br><br>JSでは、プリミティブではないオブジェクトと配列だけがmutableなので、そういったstateやpropsを更新する時はimmutabilityを担保する必要がある。<br><a href="https://developer.mozilla.org/ja/docs/Glossary/Mutable" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/ja/docs/Glossary/Mutable</a><br><br>Object.assign()やスプレッド演算子などを利用してimmutableに更新する。<br>＊どちらもshallow copyなので1階層しかコピーされないことに注意。ディープコピーを行うには、オブジェクトをJSON.stringify()でJSON文字列化して、それをJSON.parse()でオブジェクトとして復元する方法やloadashなどのライブラリを利用する形になる。<br></p><h2 id="h29571f2aef">パフォーマンスチューニングについて</h2><p>Reactのパフォーマンスはいかに再レンダリングを防ぐかに焦点が置かれている気がする。<br>あるコンポーネントがレンダリングされると子コンポーネントもレンダリングされるので、コンポーネントの数が多かったりAPIからデータフェッチする関数が多かったりするとかなりコストがかかる処理となる。<br><br>この記事がとても参考になる。<br><a href="https://blog.ojisan.io/react-re-render-history/" target="_blank" rel="noopener noreferrer">https://blog.ojisan.io/react-re-render-history/</a><br></p><h3 id="h179bc85ed0">shouldComponentUpdate()のオーバーライドとPureComponent</h3><p>前節で出てきたshouldComponentUpdate()のAPIは再レンダリングを防ぐために利用されていた場合も多かったよう。<br>クラスコンポーネント時代は、shouldComponentUpdate() を各コンポーネントでオーバーライドしてレンダリングのタイミングを調整することで、不要なレンダリングを防いでいた。<br>それか、<a href="https://ja.reactjs.org/docs/react-api.html#reactpurecomponent" target="_blank" rel="noopener noreferrer">PureComponent</a>を利用して新旧propsとstateを浅く比較して変更がなければレンダリングしないようにするか。<br></p><h3 id="haaa375d8d9">hooksでのReact.memoとuseMemo useCallback</h3><p>PureComponentと同じく新旧propsで浅い比較が行われる形。</p><pre><code>const Component = React.memo(props =&gt; {
  return &lt;div&gt;{props.value}&lt;/div&gt;
})</code></pre><p><br>useMemoは変数のメモ化をするhooksAPI。変数を作るコストが高いときに有効。</p><pre><code>const memo = () =&gt; useMemo(() =&gt; {
  createVal()
}, [val])</code></pre><p><br>useCallbackは第二引数の依存配列に渡した要素が更新されたら実行される。</p><pre><code>const memo = () =&gt; useCallback(() =&gt; {
  doSomething()
}, [val])</code></pre><p><br></p><h2 id="ha214098e44">まとめ</h2><p>stateとpropsのimmutableはしっかり意識しようということ。<br>パフォーマンスチューニングの話はもうちょっと深掘りたい。</p>

Kdevlog

【読書ログ】達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践

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

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

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

Remix触ってみた

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

【読書ログ】良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方

type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

【読書ログ】プロを目指す人のためのTypeScript入門安全なコードの書き方から高度な型の使い方まで

Reactの基本概念の整理