
## 概要

発売前から気になっていたこの書籍を読んだので学びをつらつらと書いていく。

自分が業務で担当しているアプリケーションもパフォーマンスがボトルネックとなることがあるので、少しでも何か吸収できれば。

## 1章: チューニングの基礎知識

本書ではリクエストレスポンス一連の動作が完了するまでの時間（RTT: Round Trip
Time）が短いWebサービスを高速なWebサービスと定義している。

Webサービスのキャパシティは単純化すると個々の性能×数になり、それを調整するアプローチは**垂直スケーリング（スケールアップ:
性能UP）**か**水平スケーリング(スケールアウト: 数増やす)**の2種類がある。

パフォーマンスチューニングの基本は下記2点

- ボトルネックだけにアプローチする
- ボトルネックの特定は外側から順番に
  - 2021年の一般的なWebサービスにおいてボトルネックになりがちな箇所はCPU、メモリ、ディスクI/O、ネットワークI/Oとのこと

負荷試験を実施して改善してのサイクルになる。負荷試験と言えるほどちゃんとしたものをやったことが無いな。

## 2章: モニタリング

モニタリングは外形監視と内部監視の2種類がある。

- 外部監視
  - アプリケーションの外側からモニタリングする手法。
  - 外部からリクエストを行って期待通りのレスポンスが返ってくるか確認。
- 内部監視
  - アプリケーション内部からモニタリングする手法。
  - CPU利用率やメモリなどの状態をウォッチ。

本書では[Prometheus](https://prometheus.io/)というPull側のモニタリングツールを使用している。

基本的には内部監視の方が多いんじゃないかなと考える。外部監視だとネットワークの状態に左右されるから再現性が低そう。

## 3章: 基礎的な負荷試験

各種指標をどう見るかが大事。
本書では下記の数値が紹介されており、MySQLのボトルネックになっている箇所を調査していく流れ。
（スロークエリの発見。実行計画を見ていく）

- CPU2コアのうち50%程度が利用されている
- MySQLのプロセス(mysqld) がCPUを100%(1コア)程度利用
- WebアプリケーションのプロセスはCPU1% / Webサーバーのプロセスは0.3%

実務でもスロークエリログがあってCPU使用率が跳ね上がった経験がある。

あのような事象はかなりインシデントにつながるので、普段からパフォーマンスをより意識したい。

## 4章: シナリオを持った負荷試験

この章の内容は自分の勤務先でもやりたい...！

どの画面表示時に遅いのかをシナリオを使って調査して可視化できるのはとても良い。

よりユーザー目線に立ったテコ入れができると感じる。

テスト環境ではデータ量が足りず、どうしてもクライアントのボトルネックに気付けないという問題がある。

ローカルだと開発生産性に影響するのでやりたくないから、それ用の環境を作るとかになるのかな。
コスパとの相談かも

それを事前に検知できる仕組みが欲しい。

書籍だとOSSの[k6](https://k6.io/open-source/)というツールを紹介している。

## 5章: データベースのチューニング

特に印象に残ったのはインデックス周りのこと。二分探索に適した構造であるBツリーについて。

インデックスの走査についてかなり丁寧に説明されていた。

- `Covering Index`
- インデックスを貼る基準として頻繁に使われるカラム。それ以外は「ORDER BY」で並び替えを行うカラムに貼る

### Covering Index について

ref. [https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index](https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index)

> クエリーによって取得されたすべてのカラムを含むインデックス。完全なテーブル行を見つけるためのポインタとしてインデックス値を使用する代わりに、クエリーはインデックス構造から値を返し、ディスク I/O
> を節約します。InnoDB セカンダリインデックスには主キーカラムも含まれるので、InnoDB は MyISAM よりも多くのインデックスにこの最適化方法を適用できます。InnoDB
> は、トランザクションが終わるまで、そのトランザクションによって変更されたテーブルに対するクエリーにこの方法を適用できません。正しいクエリーの場合、どのカラムインデックスまたは複合インデックスでも、カバリングインデックスとして機能できます。可能な場合は必ず、この最適化方法を活用するようにインデックスおよびクエリーを設計してください。

usersテーブルのnameカラムにindexが貼ってあるとする。

これだとidがプライマリーインデックス / nameがセカンダリインデックスとなる。

下記のSQLクエリ結果セットで利用しているカラムはidとnameだけなので`Covering Index`が有効になる。（EXPLAIN結果のExtraにUsing
Indexが付与される。）

これにより、テーブルフルスキャンでなくインデックススキャンのみで結果を返すのでパフォーマンスが良くなる。

`SELECT *`の場合は、全てのカラムにインデックスを貼っていないので `Covering Index` は無効となる。

```sql
SELECT id
FROM users
WHERE users.name = 'hoge'
```

## 6章: リバースプロキシの利用

リバースプロキシが必要な理由としてアプリケーション側のHTTPコネクションでは捌ききれないというものがある。

本書では例としてunicornを利用したRubyアプリケーションのマルチプロセス・シングルスレッドを紹介している。

- クライアントからの1リクエストを1プロセスが処理する。
  - そのプロセスは処理を行なっている間に他のリクエストを処理できない。（プロセス数 = 最大リクエスト数）
    - 大量リクエストの場合、パフォーマンスが極端に低下するC10K問題を抱えている（1万リクエストを受け取ると処理が急激に悪化する問題）
      - プロセス切り替え時のコンテキストスイッチが大量発生。新しいプロセス用のキャッシュ切り替え => 処理悪化
      - 異なるプロセス同士では通常メモリ共有ができないためメモリ使用量が多くなる

このように大量のリクエストを捌くのが難しいので、リバースプロキシでクライアントとのHTTPコネクションを解決する。

代表的なものとしてNginxがある。

マルチプロセス・シングルスレッドは同じだがイベント駆動アーキテクチャであるため、1プロセスが複数クライアントのリクエストを処理できる。

ノンブロッキングI/O（他の処理でのファイル読み書きが完了するまで待たない）と多重I/Oを活用し、イベント駆動でリクエスト・レスポンスを大量に捌くことでC10Kを解決している。

業務でもNginxを利用しているがあまり触っていないため色々と忘れがちなので、適宜振り返っていきたいと思う。

## 7章: キャッシュの活用

この章を読んでキャッシュは慎重に利用したいと感じた。

- 古いデータが表示されるリスク
- 想定外データを表示して情報流出のリスク
- キャッシュミドルウェアがシステムの障害点に
- プログラムの実装が複雑になる

本書ではこのような問題があるのでまずはキャッシュを使わない方法を模索してみようと記述されている。

確かに扱い方によってはリスクを孕んでいる。

また、アプリケーションのインメモリで管理するか外部のミドルウェア（Redis等）で管理するかも考慮ポイント。

- キャッシュの生存時間（TTL）
- Thundering herd problem
  - キャッシュ無い状態で大量リクエスト
    - => キャッシュ生成するまで処理が続くかつ大量リクエスト
    - => パフォーマンス悪化

などの問題をちゃんと考慮しないといけないということを認識できた。

## 8章: 抑えておきたい高速化手法

特に印象深かったものだけ

- 同一ホストへのコネクションを使い回す
  - イテレーションで毎回コネクションを作るなどナンセンス。毎度TCPのハンドシェイクが必要になり大量のオーバーヘッドが発生してしまう。確立したコネクションを変数に入れて使い回すなどの対応が必要
- 適切なタイムアウトを設定
  - 常に通信が成功するとは限らないので、ネットワーク障害などに備えて処理時間上限を設けておかないとそこがボトルネックになる。
- HTTPヘッダーを活用してクライアント側にキャッシュさせる
  - 画像ファイルやCSSファイルなどは更新頻度が低く、参照頻度が高いためCache-Controlヘッダーを活用してキャッシュデータを使いまわせるようにする
  - Cache-Controlヘッダーの期限切れの場合にのみリクエストを行うことで、無駄なリクエストを減らせる
- 静的ファイル配信をリバースプロキシから直接配信する
  - RDBMSに画像データを持たずに静的ファイルにしてNginxから配信させると、無駄な処理を省ける（RDBMSの場合大きなデータを読み込むのでMySQLのメモリを圧迫したり、ネットワーク帯域を圧迫するなど）
- CDN上にHTTPレスポンスをキャッシュする
  - キャッシュしたレスポンスを返すことでアプリケーションサーバーへのリクエストを減らせる。
  - クライアントから近いCDNエッジからレスポンスを直接返せるので、高速な処理が実現できる

最近、CDN周り（特にCloudflare Workers）をちゃんと触ってみたい欲がすごい。

## 9章: OSの基本知識とチューニング

割とOS周りが詳しく記述されているがポイントだけ。Linux周りがまだ分からないことだらけなのでもっと学びたい。

- Linux Kernelの基礎知識
  - カーネル空間 / ユーザー空間
    - System Callを発行する側（アプリケーションやブラウザなど）: ユーザー空間
    - System Callを受け取ってハードウェアを制御する側: カーネル空間
  - プロセス
    - ユーザー空間で実行中のプログラム単位（Webサーバー等）
  - init / systemd
    - Linuxにはinitという親プロセスがありその下に子プロセスが紐づく（initの実装は最近systemdが多い）
  - コンテキストスイッチ
    - 複数のプロセスを動作させるため、超高速でプロセスを切り替えることで擬似的に複数プロセスが同時に動作しているように見せる => コンテキストスイッチ
  - ディスクI/O
    - 逐次読み書き: シーケンシャルリード / ライト
    - 現代では保存領域を上から逐次読み書きするのは現実的ではなくランダムリード/ライトが重視
  - I/Oスケジューラ
    - ディスク読み書き制御用パラメータ
    - Ubuntu20.04では、mq-deadlineスケジューラが採用
  - ファイルディスクリプタ
    - プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子
    - プロセス側からOSに対してこの識別子を指定することで読み書きできる
  - UNIX domain socket
    - 同じホスト内の別プロセスに対して高速にデータを送受信する仕組み
    - 同じホスト内であることが前提のためネットを介さないことを活かした高効率な通信。

## まとめ

パフォーマンスチューニングの書籍だけれど、ミドルウェアの設計やアーキテクチャの基礎知識に対する説明が丁寧にされていたのが好印象。

`Covering Index`の概念を知れたのはよかった。Linux周りがまだ分からないことだらけなのでもっと学びたい。あとCDNも。


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


## 概要

良いコード/悪いコードで学ぶ設計入門を読んで学びになったことをつらつらと書いていく。

改めてコードの書き方について見直すきっかけとなった。

また、デザインパターンがあまり理解できていないのでそこを学びたいと思った。

## 1章: 悪しき構造の弊害を知覚する

**低凝集は避ける**

データやロジックが分散して低凝集になっていると人間が認知できなくなる。

具体的に言うと、ある操作のロジックを追加するときに複数箇所を修正しないといけない場合、変更漏れが起こる可能性が高い。

そうなると、対応したのに対応していないというクレームが上がってきて追加修正しないといけない。

信頼も失ってしまうので、また、それを知らずに重複コードを書いてしまう可能性や可読性の低下を招いてしまう。

さらに、そのコード動作前に初期化処理が必要な場合、それを忘れてしまってnullに対してロジックを実行してしまって実行時エラーになったりとか。

個人だけでなくチーム全体の生産性にも悪影響なので、そういったコードは書かない方が良いなと改めて感じた。

## 2章: 設計の初歩

### 変数への再代入を避ける

変数を使い回すと期待通りの出力にならない可能性があり、バグを埋め込んでしまうことになる。

読み手も混乱させてしまうので、変数を使い回さずに目的ごとに変数を用意して処理した方が良い。

## 3章: クラス設計

クラス設計のエッセンス

- クラスが単体で正常動作するように疎結合を保つ（高凝集）
- 複雑な初期設定をせずとも使えるようにする
- 外部公開メソッドは慎重に

### コンストラクタで確実に正常値を設定する

これによりインスタンス化する際に正常値が確実に設定されることを担保できる。

### メソッド引数やローカル変数を不変にする

途中で値が変化すると追うのが難しくなるのでバグを引き起こしてしまう。

### 値の渡し間違いを型で防止する

関数は通貨の数字が渡されるのを期待しているのに、number型で定義しているので通過以外の数字が渡ってきてしまう。

```js
// NG
const totalMoney = (money: number) => {
// 処理
}
totalMoney(3)
// OK
const totalMoney = (money: Money) => {
// 処理
}
totalMoney(3)
```

上記例ではMoney型の変数を渡しているが、この変数は正常値だけを持つインスタンスを生成するためのコンストラクタ。

「**完全コンストラクタ + 値オブジェクト（**値そのものとクラスとして切り出し表現する**）**」

オブジェクト指向設計の基本形。

異常値をいかに生み出さないかに焦点が置かれていると思った。

"クラス設計とは、インスタンス変数を不正状態に陥らせないための仕組みづくりと言っても過言ではありません"
と筆者が述べているように、いかに異常値を防ぐかがポイント。

確かに普通に考えて設計図から意図しないものが生まれてきたら設計図の意味を成してないよなと思う。

## 4章: 不変の活用

### 副作用のデメリット

副作用とは、関数が戻り値を返す以外に外部の状態（変数など）を変更すること副作用ってどこまで許容するべきなのかは割と難しいかもしれないと感じる。

影響範囲を留めるべきというのは分かるが関数内で引数を操作して返すというのは割とやっている気がする。

クラスやサービス横断して副作用を生み出すのは良くなさそう。

## 5章: 低凝集

### 共通処理クラスを安易に作らない

**Common**とか**Util**とか**神クラス**とか

ログ出力やエラー処理、デバッグや例外処理などの横断的関心事であれば
共通処理として切り出しても良いが、それ以外の場合は本当に共通処理が必要か考えた方が良い。

共通処理という名の雑多なロジック生まれがち。

### 引数は少なく

引数が多すぎると低凝集に陥りがち。

引数が多いとそれだけ処理内容が増えるのでロジックの複雑化や重複コードにつながってしまう。

そういう場合、データを引数として扱うのではなくそのデータをインスタンス変数としてもつクラスへと変更してみる。

この考え方は学びになった。

メソッド内で複数のオブジェクトを操作している状態から、クラスとして切り出し関心事を分離していく。

そうすることで全体として見通しが良くなるなと感じた。

### 尋ねるな命じろ

他のオブジェクトの状態を問い合わせるのではなく、呼び出し側はただメソッドを呼び出すだけにする。

オブジェクトの状態を判定するロジックなどは呼ばれる側で実装するべき。

こうすることでロジックの高凝集につながる。

この考え方はAPI設計に通ずるものがあると感じた。外部インターフェースとして呼び出すものを与えるだけで、内部状態は気にさせない。呼び出す時も余計なロジックを考えずに済む。

## 6章: 条件分岐

この章は条件分岐はinterfaceに書き換えると良いということが学びになった。

## 8章: 密結合

継承はなるべく非推奨とのこと。サブクラスがスーパークラスに依存するので密結合やロジック混乱などになりがちとのこと。

書籍には「ある継承クラスにとっては関係があっても、別の継承クラスには無関係なメソッドが登場し始めると問題」とあったけれど、これは単一責任の原則を破っているからだと思う。

[Qiita](https://qiita.com/tonluqclml/items/c0110098722763caa556)とかに参考記事があったけれど、共通メソッドや変数を共有するためなどの安易な継承は避けるべきだというのを見て納得した。

## 10章: 名前設計

書籍では目的駆動名前設計を推してる。

目的ベースでの命名。確かに商品や顧客にもいろいろな切り口があるのでしっかりと目的を検討して区別する必要ある。

ドメイン理解と元に切り分ける大事さ。

特に印象に残ったのが、「**形容詞で区別が必要なときはクラス化のチャンス**」ということ。

正しくその通りだなと思ったので、今後意識していきたいなと考えている。

## 12章 メソッド

### CQS（コマンドクエリ分割）

メソッドはコマンド（変更）またはクエリ（問い合わせ）のどちらか一方だけを行うようにするという考え方らしい。

これは自然と意識するようにしてるなと思う。パターン名があったというのが発見かも。

## 13章 モデリング

10章名前設計の章と被るところだが、任意のモデルが適切に分割されていることが大事だなと思う。

単一責任の原則をどれだけ意識できているか？自分達のドメインでCustomerモデルはどういう種類の顧客を扱っているのか？

それをするには事業ドメインを深く理解することが大事。

## 16章: 設計を妨げる開発プロセスとの戦い

色々記述されているが「**既存コードを信用せず、冷静に正体を見破る**」を意識したい。

既存実装を模倣することが多いけれど、その実装は本当にベストなのか？は今一度冷静になって見極める意識を持ちたい。

## まとめ

今のチームが拡大するにあたって保守性を第一に考えたいと思っていて、設計周りをきちんと抑えておきたかったので読んだ。

筆者の主張がいくらか強い部分もあったけれど、クラス設計やCQSなど勉強になった。今一度良いコードとは何かを考え直すきっかけになったと思う。次はドメイン駆動設計やデザインパターンをちゃんと抑えたい。


<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方


## 概要

ReactベースのフルスタックフレームワークのRemixが前から気になっており、公式のチュートリアルを触ってみた感想やその思想を深ぼっていく。

## Remixの思想

[Remix公式](https://remix.run/docs/en/v1/pages/philosophy#philosophy)によるとこのFWは4つの思想をベースとしている。

- サーバー/クライアントモデルを利用（データとコンテンツの分離）
- ブラウザやHTMLなどの基礎技術と協調してく
- JavaScriptを使用してブラウザの動作をエミュレートすることでUX向上
- 基盤技術を過度に抽象化しないこと

[zennで他の方が書かれている](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)ように「サーバー/クライアントモデルを利用」に対する説明が他の3つに比べて厚く書かれている印象を受けた。

### 公式doc

[公式doc](https://remix.run/docs/en/v1/pages/philosophy#serverclient-model)の記載によると下記の記載がある。

> With today's web infrastructure you don't need static files to make your server fast. 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.

サーバーを早くするために静的ファイルは必要ない。

静的ビルドの代わりにエッジを使って分散システムを構築した。

タイポ修正しても再ビルドや再デプロイ、HTTPキャッシュいらずで数秒のうちにサイトに反映される。とのこと。

つまりSSGの機能は持っておらず、毎度SSRしてコンテンツを返している。

エッジを使った分散システムによりSSRを高速に返すことを実現している。

[Remix公式ブログ](https://remix.run/blog/remix-and-the-edge)に詳細に記載があり、以前のエッジは静的コンテンツの配信だけだったが、最近はDeno deployやCloudflare Workersなど動的コンテンツも返せるようになっている。

Remixはそのエッジコンピューティング技術を利用して任意の場所で高速でコンテンツを返せるようにしているよう。

## QuickStartを触ってみる

Remix公式で紹介されている[QuickStart](https://remix.run/docs/en/v1/tutorials/blog#quickstart)を触ってみる。

[Gitpod](https://www.gitpod.io/)で動作環境を構築したのでローカルで作らなくて済んだ。

便利すぎる。Gitpodは後日記事にしたい。触ってみて分かったことを色々とまとめる。

- routesディレクトリ配下のファイルがroutingになる
- [API routes](https://remix.run/docs/en/v1/guides/api-routes)を作成可能
- Dynamic routes
- ErrorBoundary
- Nested Routes

特に印象深かったのが下記3点

1. API routes
2. Nested Routes
3. ErrorBoundary

### API routes

`.t(j)sx`ファイルでDBからの値取得やfetchなどを行って値を取ってこれる。
特にDBと直接連携して値を簡単に取得できるのは驚いた。
ORMはprismaだった。（prismaをしっかり使ってみたい欲が湧いた。）

### Nested Routes

[Remix公式](https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing)の説明だと、URLのセグメントをUIのコンポーネント階層に一致させる考え方。

下記のgif分かりやすい。

![Nested Routing](/images/nested_routing.gif)

つまりURLのセグメントとコンポーネントが対応しておりそれを1ページで表している形

下記のディレクトリ階層で言うと、`app/root.jsx`をトップとしてその中にroutesディレクトリ配下のコンポーネントがそれぞれ表示されている。

```plaintext
app
├── root.jsx
└── routes
    ├── accounts.jsx
    ├── dashboard.jsx
    ├── expenses.jsx
    ├── index.jsx
    ├── reports.jsx
    ├── sales
    │   ├── customers.jsx
    │   ├── deposits.jsx
    │   ├── index.jsx
    │   ├── invoices
    │   │   ├── $invoiceId.jsx
    │   │   └── index.jsx
    │   ├── invoices.jsx
    │   └── subscriptions.jsx
    └── sales.jsx
```

また`ErrorBoundary`を併用することで1つのコンポーネントがエラーで表示できなくなったとしてもページ全体が表示できないということを防げる。

### ErrorBoundary

コンポーネントのクライアントサイドでのレンダリング時にエラーがあった場合の表示を設定するエラーハンドリング。
＊`CatchBoundary`はレンダリング時にAPIからのfetchやDB更新などでエラーがあった場合にキャッチする。

```javascript
export function ErrorBoundary({ error }: { error: Error }) {
  return (
    <div className="bg-rose-500">
      <div>
        {error.message}
      </div>
    </div>
  );
}
```

QuickStartで使ったソースコードを使って実際にNested Routesと`ErrorBoundary`の動作を確認してみた。

`posts/admin/new`のNested Routesでそれぞれコンポーネントを表示させている。

`Create a New Post`を押すとadminディレクトリ配下の`new.tsx`コンポーネントがレンダリングされる。

その`new.tsx`コンポーネントでエラーが起きた想定で`ErrorBoundary`を利用している。

#### 通常

![Normal](/images/nested_routes_normal.gif)

#### ErrorBoundaryなし

![Without ErrorBoundary](/images/not_boundary.gif)

#### ErrorBoundaryあり

![With ErrorBoundary](/images/boundary.gif)

## まとめ

Nested Routesという概念によりまた一つUX体験を向上させる手段を知れたのでよかった。

Next.jsと違いSSGやISRといった静的ビルドはないけれど、エッジを使ってSSRを高速化しているというところのアーキテクチャの違いが興味深かった。

ちなみこのブログはNext.jsを使って作っておりSSGには日々お世話になっている。

エッジらへんもっと知りたいなと思う。


Remix触ってみた


## 概要

[type-challenges](https://github.com/type-challenges/type-challenges) というTS文法の練習問題リポジトリがある。

興味本位で解いてみたら楽しくなってきてeasyレベルからmediumレベルまで81問解いてしまった。

その際にTSについての学びが色々あったので共有する。

## 学び一覧

- mapped types
- conditional types
- infer
- minus operator
- union distribution
- never
- template literal types
- length property
- index(numeric) signature
- bottom type

### mapped types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/mapped-types.html](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html)
型引数が主にユニオン型orオブジェクトの場合に利用することが多い。型引数をイテレーションして結果出力する。

```typescript
type MappedTypes<T extends object> = { [P in keyof T]: T[P] };
type s = MappedTypes<{ key: 'test'; value: 'test' }>;
// type s = {
//   key: 'test';
//   value: 'test';
// }

type MappedTypes2<T extends string> = { [P in T]: string };
type t = MappedTypes2<'test' | 'tt'>;
// type t = {
//   test: string;
//   tt: string;
// }
```

### conditional types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/conditional-types.html](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html)
型の条件分岐を実現する。

```typescript
TypeA extends TypeB ? true : false
```

公式docによるとこの条件はextendsの左の型が右の型に代入可能かどうかを判定している。

> When the type on the left of the extends 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).

そのためこれはもちろんfalse

```typescript
type test = string extends number ? true : false;
// => false
```

こちらは原則から考えてtrueになる。

```typescript
type test = 't' extends string ? true : false;
// => true
```

bottom typeの節でneverやundefinedをconditional typesで比較検証する。

### infer

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types)
型を割り出してその後利用できる。

conditional typesとセットで利用する。

例えば、type-challengesの[Last of Array](https://github.com/type-challenges/type-challenges/blob/main/questions/00015-medium-last/README.md) の問題では下記のように解ける。

型引数Tをconditional typesで分岐させ、その中でinferを利用して推論した変数L（配列の最後の要素）を利用する。

```typescript
type Last<T extends any[]> = T extends [...infer _, infer L] ? L : never;
type s = Last<[]>;
// => never

type t = Last<[1, 2, 3]>;
// => 3
```

### minus operator

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#improved-control-over-mapped-type-modifiers)
mapped types内のreadonlyや?を削除するための修飾子例えば、type-challengesの[Mutable](https://github.com/type-challenges/type-challenges/blob/main/questions/02793-medium-mutable/README.md) の問題では下記のように解ける。

```typescript
type Mutable<T> = {
  -readonly [K in keyof T]: T[K];
};

type s = Mutable<{ readonly test: 1 }>;
// type s = {
//   test: 1;
// }
```

### union distribution

**conditional types**や**mapped types**にunion型を渡すと1つずつ処理される。

conditional typesでは条件の左部分が型変数である場合にunion型が分配される。

```typescript
type Equal<U> = U extends 1 ? U : never;
type s = Equal<1 | 2>;
// type s = 1
```

例のコードでは型変数Uにunion型が渡っており1だけを返す。つまり下記が行われている。

```typescript
type TypeA = (1 extends 1) ? U : never
type TypeB = (2 extends 1) ? U : never
```

mapped typesでは以下のような形の場合にunion distributionが発生する。

```typescript
{ [P in keyof T]: X}
```

```typescript
type Distribution<T> = { [P in keyof T]: T[P] };
type val = Distribution<{ foo: string } | { bar: number }>;
// type val = Distribution<{
//    foo: string;
// }> | Distribution<{
//    bar: number;
// }>
```

### never

[サバイバルTypeScript](https://typescriptbook.jp/reference/statements/never)より

> TypeScriptのneverは「値を持たない」型。
> 1️⃣特性1: neverへは何も代入できない
> 2️⃣特性2: neverは何にでも代入できる
> 💥常に例外を起こす関数の戻り値に使える

[TypeScript Deep Dive](https://typescript-jp.gitbook.io/deep-dive/type-system/never)より

> プログラミング言語の設計には、bottom型の概念があります。
> それは、データフロー解析を行うと現れるものです。
> TypeScriptはデータフロー解析(😎)を実行するので、決して起こりえないようなものを確実に表現する必要があります。
> never型は、このbottom型を表すためにTypeScriptで使用されます。

[Wikipedia](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) より

> データフロー解析（英: Data-flow analysis）は、プログラム内の様々な位置で、取りうる値の集合に関する情報を収集する技法である。

制御フローグラフ (CFG)を使って変数の値が伝播するかどうかなどの情報を集め、利用する。

このようにして集められた情報はコンパイラが最適化に利用する。

データフロー解析の基本は到達定義 (reaching definition) である。

### template literal types

JSのテンプレートリテラルを使って展開した値をそのまま型として定義できる。

```typescript
type Join<T extends string, U extends string> = `${T}-${U}`;
type joinedStr = Join<'foo', 'bar'>;
// type joinedStr = "foo-bar"
```

conditional types + inferを利用していこんな風にも書ける。

```typescript
type TemplateLiteral<T extends string> = T extends `${infer F}${infer _L}`
  ? F
  : never;
type str = TemplateLiteral<'foo'>;
// type str = "f"
```

type-challengesで文字列操作するときに初めて知って表現力に驚いたな。

### length property

配列やタプルの要素数をカウントして返す

```typescript
type val = [1, 3]['length'];
// type val = 2
```

Arrayのinterfaceにlengthプロパティが存在する。

```typescript
interface Array<T> {
  /**
   * Gets or sets the length of the array. This is a number one higher than the highest index in the array.
   */
  length: number;
}
```

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402)

### index (numeric) signature

配列(orタプル)TにおいてT[number]がunion型で返ることから知った
[公式doc](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html) にも記載ある。

[stackoverflow](https://stackoverflow.com/a/59188070) の記事では、Arrayは下記のようなinterfaceになっていて numberを使ってindexをまとめて取得できるよう。

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392)
かな？

### bottom type

neverは値を持たないということを表す型でありbottom型とも呼ばれる。集合論で表すと空集合。

never型には何も代入できない（値持たないから）が、never型は他の型に代入できる。

他の全ての型のサブタイプ（部分型）となる。

is-aの関係。逆はできない（他の型をnever型に代入）

```typescript
let neverVal: never = 1 as never;
// never 型は bottom type なのでstring型に代入可能

let str: string = neverVal;
```

ちなみにunkhownは全ての型のスーパータイプなのでどんな型でも代入可能

```typescript
let str = 'str';

// unkhown 型は super type なのでstring型を代入可能
let neverVal: unknown = str;
```

[TS型の階層性](https://zenn.dev/estra/articles/typescript-type-set-hierarchy#%E5%9E%8B%E3%81%AE%E9%9A%8E%E5%B1%A4%E6%80%A7) に詳しく説明がある。

## 今後知りたいこと

- type widening
- homomorphic mapped types
- union distributionをキャンセルする
- etc...

## まとめ

[type-challenges](https://github.com/type-challenges/type-challenges) でTSの型プログラミングにどっぷりハマった。

また再帰的に解く問題が多かったので自然と再帰的に考えられたのもとても良かった。

この経験を通じてTSが好きになったのでもっと深掘りたいと思えたのは大きな収穫。


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


## 概要

React18リリースがあった関係でWEB DB PRESS vol.129にReactの深層シリーズが掲載されていたので、改めてReactの思想や設計原則などを見直した。

## Reactの特徴

- 宣言的UI
- コンポーネント志向
- 仮想DOM
- 単方向データフロー

の4つが大まかな特徴と捉えている。

### 宣言的UI

UIとして表示する部品をコンポーネントとしてラップして定義した上で、「この場合はこのdivタグを置いて..」みたいな細かい制御ロジックが書かれる命令的UIではなく、あるべき状態を **宣言** したUIを記述する形式。

命令的UIのように画面描写の変化過程を記述するのではなく、結果のみを記述していく。

### 仮想DOM

WEB+DBPRESSに記載のある「宣言的UIでは **状態(state)** と **UI** が明確に分けられており、ユーザーがアプリケーションを使うということはアプリケーションの状態を操作するということであって、**UIというのは現在の状態をユーザーに知らせるための映写装置である** 」部分が印象に残っている。

つまり、命令的UIで扱っていたロジックを状態管理に持ち込むことで、UIは現在の状態を映写するだけという感じ。

状態が変更されて仮想DOMが生成され、実際のDOMとの差分検出を行い、DOMの更新を行う。jQueryなど実際のDOMをいじるのではなく差分検出してDOM構築して一括更新。

mizhiさんの記事がとても勉強になる。[https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766]("https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766")

### 単方向データフロー

そして単方向データフロー。
従来のMVCではModelとViewの間に双方向のデータフローが作られる可能性があるので、理解やデバッグが困難。

例えば、Viewが複数Modelのデータ参照/更新を行うことでデータフローが循環する形。これが多くなると複雑度が増す。
そういった背景からFLUXアーキテクチャが登場し、ViewからのイベントがStoreに発行され、Storeが更新されたらViewも更新するという単一のデータフローが構築された。

この記事が参考になる。[https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/]("https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/")

## Reactのimmutabilityについて

単方向データフローやコンポーネントのカプセル化なども重要だけど、同じくらい、immutabilityの重要性も重要。

[Reactの公式tutorial]("https://ja.reactjs.org/tutorial/tutorial.html#why-immutability-is-important")にもあるけれど、immutabilityが重要な理由として下記3つ挙げられている。

- 複雑な機能が簡単に実装できる
- React自身がオブジェクトの変更を検知しやすくなる
- コンポーネント再描画のタイミングが決定しやすくなる

このブログ記事が参考になる。
[https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/]("https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/")

[https://tech.kitchhike.com/entry/react-should-component-update]("https://tech.kitchhike.com/entry/react-should-component-update")

### 内部のロジック

Reactは [shouldComponentUpdate()]("https://ja.reactjs.org/docs/react-component.html#shouldcomponentupdate") という APIを通じてrenderするかを決定している。
その際、コンポーネントに新しいpropsが渡されるもしくは状態(state)が更新されたら呼び出されてbooleanを返す。
trueならばrenderされて、falseならば逆。

内部実装を見てみる。

[https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js]("https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js")

```javascript
// @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)
  );
}
```

内部的には areEqualもしくはshallowDiffers 関数を呼んでいることがわかる。

areEqual内部でもshallowDiffers関数を呼んでいるので、実質shallowDiffersの中身がstate or propsの変更を検知するロジックになっていそう。
shallowDiffersの中身を見てみる。

[https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5]("https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5")

```javascript
// @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;
}
```

やっていることはシンプルで

- 1つ目のfor文で変更前と変更後のstate or propsを比較して新しい要素が追加されたのかを確認
- 2つ目のfor文で変更前と変更後のstate or propsで指定されたkeyの値が一致するのかを確認

をやっている。
ここから分かることは、**propsやstateをmutableに変更してしまったら再renderされない可能性がある** ということ。

JSでは、プリミティブではないオブジェクトと配列だけがmutableなので、そういったstateやpropsを更新する時はimmutabilityを担保する必要がある。

[https://developer.mozilla.org/ja/docs/Glossary/Mutable]("https://developer.mozilla.org/ja/docs/Glossary/Mutable")
Object.assign()やスプレッド演算子などを利用してimmutableに更新する。

＊どちらもshallow copyなので1階層しかコピーされないことに注意。ディープコピーを行うには、オブジェクトをJSON.stringify()でJSON文字列化して、それをJSON.parse()でオブジェクトとして復元する方法やloadashなどのライブラリを利用する形になる。

## パフォーマンスチューニングについて

Reactのパフォーマンスはいかに再レンダリングを防ぐかに焦点が置かれている気がする。

あるコンポーネントがレンダリングされると子コンポーネントもレンダリングされるので、コンポーネントの数が多かったりAPIからデータフェッチする関数が多かったりするとかなりコストがかかる処理となる。

この記事がとても参考になる。[https://blog.ojisan.io/react-re-render-history/]("https://blog.ojisan.io/react-re-render-history/")

### shouldComponentUpdate()のオーバーライドとPureComponent

前節で出てきたshouldComponentUpdate()のAPIは再レンダリングを防ぐために利用されていた場合も多かったよう。

クラスコンポーネント時代は、shouldComponentUpdate()を各コンポーネントでオーバーライドしてレンダリングのタイミングを調整することで、不要なレンダリングを防いでいた。

それか、[PureComponent]("https://ja.reactjs.org/docs/react-api.html#reactpurecomponent")を利用して新旧propsとstateを浅く比較して変更がなければレンダリングしないようにするか。

### hooksでのReact.memoとuseMemo useCallback

PureComponentと同じく新旧propsで浅い比較が行われる形。

```tsx
const Component = React.memo((props) => {
  return <div>{props.value}</div>;
});
```

useMemoは変数のメモ化をするhooksAPI。変数を作るコストが高いときに有効。

```tsx
const memo = () =>
  useMemo(() => {
    createVal();
  }, [val]);
```

useCallbackは第二引数の依存配列に渡した要素が更新されたら実行される。

```tsx
const memo = () =>
  useCallback(() => {
    doSomething();
  }, [val]);
```

## まとめ

stateとpropsのimmutableはしっかり意識しようということ。
パフォーマンスチューニングの話はもうちょっと深掘りたい。


Kdevlog

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

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方

Remix触ってみた

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

React基本概念の整理

Kdevlog

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

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

Remix触ってみた

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

React基本概念の整理

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

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方