
この記事は
[タイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜](https://qiita.com/advent-calendar/2021/timeleap-typescript)  
5日目の記事です。

## はじめに
自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

調べても型の指定方法が分からず、泣く泣く `as any` でコンパイラーを黙らせて、補完が効かなくなりモヤモヤしながらテストコードを書いていました。

TypeScriptで型を妥協してテストコードを書いていた時は次のような弊害もあったので、どう型安全にテストコードを書けば良いのか非常に知りたかったです。  
- 補完が効かなくなるのでコーディングが面倒になる
- プロパティをタイポした事に気づかずに、テストが失敗しても失敗している原因に気付けず疲弊する

## もくじ
- [モジュールモックの型指定](/post/jest-typescript-types#モジュールモックの型指定)
- [関数モックの型指定](/post/jest-typescript-types#関数モックの型指定)
- [スパイモックの型指定](/post/jest-typescript-types#スパイモックの型指定)

## モジュールモックの型指定
APIからユーザーの一覧を取得する関数のテストを考えてみます。

```typescript
// users.ts
import axios from 'axios';

export const all = () => {
  return axios.get('/users').then(res => res.data);
}
```

APIを直接リクエストせずにモックデータを返してテストが出来るように axios のモジュールをモックしてテストを書いてみます。

次の例では TypeScript は axios がモック化されたモジュールとして認識ができないので `axios.get.mockResolvedValue()` は型エラーとなります。  

当時はこの型エラーを解消するために `(axios.get as any).mockResolvedValue()` と書いていました。

```typescript
// users.spec.ts
import axios from 'axios';
import Users from './users';

jest.mock('axios');

test('should fetch users', async () => {
  const usersMock = [{name: 'taro'}];
  // error TS2339: Property 'mockResolvedValue' does not exist on type
  axios.get.mockResolvedValue({ data: { users: usersMock } });  
});
```

モジュールをモックする場合は、モジュールを別の変数に代入して型指定を行うことでモック化されたモジュールとして扱うことができます。

Jestにはモック化の型定義が複数用意されており、モジュールモックの場合は `jest.Mocked<T>` の型定義を利用してモック化されていることを表現できます。  

`typeof axios` と指定することで、ジェネリクスの型もモジュールから自動生成ができます。

```typescript
// users.spec.ts
import axios from 'axios';
import * as users from './users';

jest.mock('axios');

const axiosMock = axios as jest.Mocked<typeof axios>;

test('should fetch users', async () => {
  const usersMock = [{name: 'taro'}];
  axiosMock.get.mockResolvedValue({ data: { users: usersMock } });
});
```

## 関数モックの型指定
次にデータをフェッチする関数を引数として渡す場合の実装を考えてみます。

```typescript
export type Fetch<T = any> = (url: string) => Promise<{ data: T }>;

export const all = (fetch: Fetch) => {
  return fetch("/users").then((res) => res.data);
};
```

関数のモックは `jest.fn()` を使い生成できます。

次のテストコードでは、 `mockImplementation()` を利用してモック関数を実装していますが、実装関数の引数と戻り値が `any` となるので、モック関数に不適切な実装を渡しても型エラーが発生しません。

そのため、型チェックは通過しますがテスト実行時に `fetch(...).then is not a function` というエラーが発生してしまいます。  

このエラーも型安全にテストコードが書けていれば、未然に回避することができます。

```typescript
import * as users from "./users";

describe("users", () => {
  it("fetch all", async () => {
    const usersMock = [{ name: "Bob" }];
    const response = { data: { users: usersMock } };

    // Promise<{data: any}> を返すべき所を誤って、User[] を返している
    // 型エラーにはならない
    const fetchMock = jest.fn().mockImplementation(() => usersMock);

    const result = await users.all(fetchMock);
    expect(result).toEqual(usersMock);
  });
});
```

`jest.fn()` の関数を型安全に実装するには大きく2つの方法があります。

1つは関数実装を`jest.fn()` の引数として直接渡す方法です。

引数として渡した場合に型推論により、モック関数の型が決まるので正しく実装されていない場合に `users.all(fetchMock)` の引数の型チェックで失敗します。

```typescript
const fetchMock = jest.fn(() => usersMock);
// Argument of type 'Mock<{ name: string; }[], []>' is not assignable to parameter of type 'Fetch<any>'.
const result = await users.all(fetchMock);
```

型が正しい関数実装を渡せば、型チェックが通過します。  

```typescript
const fetchMock = jest.fn(async (_url: string) => response);
const result = await users.all(fetchMock);
```

`mockImplementation()` で型安全に関数を実装したい場合は `jest.fn<T, Y>()` のジェネリクスで関数の引数と戻り値の型を指定できます。

```typescript
const fetchMock = jest.fn<ReturnType<Fetch>, Parameters<Fetch>>();

// error Argument of type '() => { name: string; }[]' is not assignable to parameter of type '(url: string) => Promise<{ data: any; }>'.
fetchMock.mockImplementation(() => usersMock);

// 型が正しい実装
fetchMock.mockImplementation(async (_url: string) => response);
users.all(fetchMock);
```

他には `jest.MockedFunction<T>` で変数に型注釈を書く方法があります。  
こちらの方が、ジェネリクスの指定をシンプルに書くことができます。

```typescript
const fetchMock: jest.MockedFunction<Fetch> = jest.fn();

// error Argument of type '() => { name: string; }[]' is not assignable to parameter of type '(url: string) => Promise<{ data: any; }>'.
fetchMock.mockImplementation(() => usersMock);

// 型が正しい実装
fetchMock.mockImplementation(async (_url: string) => response);
const result = await users.all(fetchMock);
```

`jest.MockedFunction<T>` で変数に型注釈を書くやり方は、`beforeEach()` で毎回モックの実装を初期化する場合には特に有効です。

```typescript
let fetchMock: jest.MockedFunction<Fetch>;

beforeEach(() => {
  fetchMock.mockImplementation(async (_url: string) => response);
});

it('fetch all users', () => {
  const result = await users.all(fetchMock);
})
```

## スパイモックの型指定
フロントエンドの実装をしていると、次のような Storage API をラップした `Storage` クラスを書くことがあります。

```typescript
export class Storage {
  get(key: string) {
    return localStorage.getItem(key);
  }
}
```

このクラスをテストしたい場合には `localStorage.getItem` をモックしてテストを書く必要があり、このようなモジュールの一部の関数だけをモックしたい場合には `jest.spyOn()` を利用してテストを書くことができます。

`jest.spyOn()` を普通に書く場合には、型推論によって型が決定されるため、そのままでも型安全に書くことができます。

```typescript
import { Storage } from "./storage";

describe("Storage", () => {
  it("get data", () => {
    const storage = new Storage();
    const spyGet = jest.spyOn(window.localStorage, "getItem");
    // error TS2345: Argument of type '42' is not assignable to parameter of type 'string | null'
    spyGet.mockReturnValue(42);
  });
});
```

`jest.spyOn()` でモックをする場合は、戻り値の型をジェネリクスで指定するような関数をモックする時に型に関する問題が発生します。

改めてユーザー情報の一覧を取得するモジュールを例に考えてみます。

```typescript
import axios from "axios";

export const all = () => {
  return axios.get("/users").then((res) => res.data);
};
```

今回は axios をモジュールモックせずに `axios.get` だけをモックしてテストを書いてみます。

`jest.spyOn<T, M>()` でジェネリクスを指定する場合には、モジュールの型とモックする関数名を文字列で指定します。

次のテストコードではジェネリクスで型を指定していますが、`spyAxiosGet.mockResolvedValue(usersMock)` で型エラーが発生しません。

```typescript
import axios from "axios";
import * as users from "./users";

describe("users", () => {
  it("update user", async () => {
    const usersMock = [{ name: "taro" }];
    const response: AxiosResponse = {
      data: { users: usersMock },
      status: 200,
      statusText: "OK",
      headers: {},
      config: {},
    };

    // spyAxiosGet: SpayInstance<Promise<unknown>>, ...>
    const spyAxiosGet = jest.spyOn<typeof axios, "get">(
      axios,
      "get"
    );
    // Promise<AxiosResponse>} を返すべき所を誤って User[] を返している
    // 型エラーになって欲しいがエラーにならない
    spyAxiosGet.mockResolvedValue(usersMock);
  });
});
```

`jest.spyOn()` と `axios.get()`の型定義をそれぞれ見てみると、`jest.spyOn()` の `SpyInstance<ReturnType<Required<T>[M]>, ...>` の部分で関数の型を取得していますが、関数のジェネリクスを指定していないため、`axios.get()` の戻り値は `Promise<unknown>` となってしまいます。

その結果 `spyAxiosGet` の変数が `SpayInstance<Promise<unknown>>, ...>` という型注釈となります。

上のテストコードでは `spyAxiosGet` の戻り値の型が `Promise<unknown>` となるため型エラーとならないのです。

```typescript
// jest/index.d.ts
function spyOn<T extends {}, M extends FunctionPropertyNames<Required<T>>>(
    object: T,
    method: M
): Required<T>[M] extends (...args: any[]) => any
    ? SpyInstance<ReturnType<Required<T>[M]>, ArgsType<Required<T>[M]>>
    : never;

// axios/index.d.ts
get<T = any, R = AxiosResponse<T>, D = any>(url: string, config?: AxiosRequestConfig<D>): Promise<R>;
```

この問題は型アサーションで `spyAxiosGet` の型を上書きすることで解消できます。

ここで `jest.fn()` と同様に型注釈で書こうとすると、戻り値の型が `Promise<unknown>` と`Promise<Partial<AxiosResponse<users.User[]>>>` で不一致が発生するので上手くいきません。

```typescript
const spyAxiosGet = jest.spyOn(axios, "get") as jest.SpyInstance<
  Promise<Partial<AxiosResponse>>
>;

// error Argument of type '{ name: string; }[]' is not assignable to parameter ...
spyAxiosGet.mockResolvedValue(usersMock);

// 型エラーは解消される
spyAxiosGet.mockResolvedValue(response);
```

## さいごに
自分のググり力が低いせいかTypeScriptをちゃんと書き始めた頃(2,3年前？)は、ここら辺の情報を検索しても全く見つけることが出来ませんでした。

ライブラリの型定義ファイルをちゃんと読むようにしたら、この型定義を使えば良いのか！このジェネリクスを指定すれば良いのか！と型の指定方法が分かるようになってきました。  

TypeScriptを書き始めて他のライブラリで似たような問題に直面している方がいたら、一歩踏み出してライブラリの型定義ファイルをしっかり読む事から始めてみると色々と型について理解できてくるのでオススメです。


この記事はタイムリープTypeScript 〜TypeScript始めたてのあの頃に知っておきたかったこと〜の5日目の記事です。自分がTypeScriptを書き始めた頃に苦労したのが、Jestでテストを書くときのモックの型をどう書けば良いか分からないことでした。

TypeScript+Jestでテストを書くときに型安全にモックする方法を教えてほしかった


## 問題
自分は普段 Emacs キーバインドを利用しているのですが、Alfred の検索結果でカーソル移動をするために Ctrl + N をタイプするとカーソル移動せずにパッケージが選択される問題に悩まされていました。

<img src="/images/posts/alfred-ctrl-n/alfred-ctrl-n-bad.gif" alt="ctrl+nでパッケージ選択される" width="840" height="572" />

## 解決策
Alfredの設定で Features > Actions > Show Actions で ctrl のチェックボックスを外せば問題は解消しました。

<img src="/images/posts/alfred-ctrl-n/alfred-settings.jpeg" alt="Alfredの設定画面" width="2280" height="826" />


Alfred で Ctrl + N でパッケージ選択できない問題を解消

Alfred で Ctrl + N でカーソル移動ができない問題を解消


TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっています。  
外部にコードが保存されるという訳でもないので、どういう仕組みで共有が実現されているか気になったので、調べてみました。

## 仕組み
仕組みとしては以下の流れでURLを通してコード共有がされていました。

1. エディターに記述してあるコードを文字列圧縮ライブラリで圧縮
2. URLに圧縮した文字列を挿入
3. URLを開くときに圧縮された文字列を展開してエディターにコードとして表示する

## コードの文字列圧縮
コードの圧縮処理は[ここのコード](https://github.com/microsoft/TypeScript-website/blob/1e7ea49f60953aa446b591c6aff347a7c566e3cb/packages/sandbox/src/compilerOptions.ts#L85) で処理がされており、[lz-string](https://pieroxy.net/blog/pages/lz-string/index.html) という文字列圧縮ライブラリが使われていました。

```typescript
  const hash = `code/${sandbox.lzstring.compressToEncodedURIComponent(sandbox.getText())}`
```



TypeScript Playground はURLを共有するだけでコードの共有が簡単にできるようになっている。その仕組みを調べてみました。

TypeScript Playground のコード共有の仕組み


[@money166](https://twitter.com/money166)  
[@tatsuo48](https://github.com/tatsuo48)  
と一緒に今年も YO!HEYHEYHEY! として [ISUCON11](https://isucon.net/archives/55706291.html)に参加してきました。

今年も非常に楽しく参加できました。  
運営の皆さま、ありがとうございました！

## 結果
予選の結果は参考スコアで 47258 で全参加チーム598チーム中80位でした。  
[ISUCON11 オンライン予選 全てのチームのスコア（参考値） : ISUCON公式Blog](https://isucon.net/archives/56021246.html)

17:00以降の固定ダッシュボードで25位まで上昇していたので、これは！？と思ったのですが、壁は厚かったです。

<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />

5年間毎年参加して、ずっと初期実装のスコアから大きく点数を上げられなかったので、6年目の今年は非常に大きな進歩があって嬉しかったです！

## テーマ
今年のアプリケーションのテーマは自分が持っている椅子の状態を監視するWebサービスでした。  
登録している椅子が定期的にサーバーに自身の状態を送信して、ユーザーはその状態をWebサービスで確認することで椅子の状態を管理できます。

いわゆる IoT です。

サービスの説明からも予想できる通り、今年は常に大量のデーターがサーバーに送信されDBに書き込まれ続けるので、DBのCPU負荷が常に高い状態でした。（ベンチ回したら最初からCPU負荷が150%とか出ていました）  
このDB負荷をどう処理するかが問題のキーとなっている印象でした。

## 振り返り
### 良かった点
- 今年はZoomで繋いでオンラインで作業をしており、画面共有などでチームでの作業がやりやすかった
- ベンチ回して効果が無い場合は前の状態に戻す徹底できたので、アプリケーションが動かなくなる問題が発生しなかった
- 基本は2人以上のペアプロを意識して進めたので、それによって気付ける事が多かった
	- ボトルネックの原因とか
- しっかりマニュアルを読み込んでスコア計算の仕様を意識して対応方針が決められた
- Miroでタスク管理して誰が何をやっているか把握しながら進められた

### 反省点
- Go言語をあまり勉強しておらずアプリケーションの修正に時間がかかった
- 勉強不足で New Relic での DB の監視を導入できなかった
- 全体的にスコア上がってから次の一手が思いつかず頭打ちになった

## チームでやったこと
- インフラ環境の初期構築をしてサーバーを立ち上げ
- 当日マニュアルやアプリケーションマニュアルを熟読
- アプリケーションを実際に動かして機能一覧を把握
- 競技用サーバーへのデプロイ環境の整備
- アプリケーションに New Relic のエージェントを追加
- DBのスキーマ情報を整理
- New Relic のダッシュボードでHTTPリクエストを確認してボトルネックを調査して対応方針を検討
- **==== ↓ ここからボトルネック対応 ====**
- サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 => 8000
- isu テーブルで画像カラムをクエリしない修正を追加: スコア変わらず
- 椅子の状態のデータ送信をサーバー3台に分散: スコア変わらず
- 椅子の状態のDBへの書き込みをバルクインサートに変更: 上手く実装できず
- サーバー構成を サーバー1: DB, サーバー2: アプリケーション, サーバー3: 椅子状態のデータ受信 に変更: スコア変わらず
- 対応方針を再検討
- isu_condition の jia_isu_uuid にインデックスを追加: 8000 => 25000
- isu_condition の timestamp にインデックスを追加: 25000 => 28000
- データを捨てる割合を 90% => 75% に変更: 28000 => 33000
- 画像をクライアントにキャッシュさせる: 対応が上手くできなかった
- Nginx や アプリケーション のデバッグログを停止: 33000 => 35000 （影響あった気がする）
- /api/trend のリクエストもサーバー3に流すように変更: 35000 => 47000

### アプリケーションを実際に動かして機能一覧を把握
今回は例年と比べてアプリケーション規模が小さい？印象だったので、全体の把握がスムーズにできた。  
オープニングでの事前のサービス紹介で概要が掴めたのも大きかった。

### New Relic の Go エージェントの追加
次のドキュメントを参考に echo のミドルウェアとしてエージェントを追加した
- [Go向けNew Relicのインストール \| New Relic Documentation](https://docs.newrelic.com/jp/docs/agents/go-agent/installation/install-new-relic-go/)
- [Goエージェントの互換性と要件 \| New Relic Documentation](https://docs.newrelic.com/jp/docs/agents/go-agent/get-started/go-agent-compatibility-requirements/)

### HTTPリクエストを確認してボトルネックを調査して対応方針を検討
リクエストの大半は `POST /api/condition/:jia_isu_uuid` が占めていた。  
これは椅子の状態を受け取ってDBに書き込むAPIエンドポイントなので、当初の想定通り。

`GET /api/trend` が最大で60sec、平均しても20secのレスポンス時間となっていた。

上記2つのAPIエンドポイントに絞って、実装の詳細を確認しながらボトルネックの調査と対応方針を決めた。

### サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 => 8000
DBのCPU負荷が150~180%とかなり高かったので、サーバー1をDB専用にして、リクエストをサーバー２で捌くように変更した。

7000点ほどスコアが上昇

### isu テーブルで画像カラムをクエリしない
isu_conditions テーブルには画像がバイナリで含まれていた。  
/api/trend では `SELECT * FROM isu` と未使用にも関わらず画像カラムも取得していたので、これで読み込みに時間がかかってレスポンス時間に影響していると予測して、必要なカラムだけをクエリするようにしたが、大きな変化は無かった。

```go
- "SELECT * FROM `isu` WHERE `character` = ?",
+ "SELECT `id`, `jia_isu_uuid` FROM `isu` WHERE `character` = ?",
```

### 椅子の状態のデータ送信をサーバー3台に分散
椅子状態のデータ送信が大量にリクエストされているので、これにより他のリクエストが待機状態で捌かれていないのでは？と思い3台にリクエストを分散してみた。  
あまり効果は無かった。

```go
- postIsuConditionTargetBaseURL string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL
+ postIsuConditionTargetBaseURLs []string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL

=======

- postIsuConditionTargetBaseURL = os.Getenv("POST_ISUCONDITION_TARGET_BASE_URL")
- if postIsuConditionTargetBaseURL == "" {
-	e.Logger.Fatalf("missing: POST_ISUCONDITION_TARGET_BASE_URL")
	return
}

+ postIsuConditionTargetBaseURLs = strings.Split(os.Getenv("POST_ISUCONDITION_TARGET_BASE_URLS"), ",")
+ if postIsuConditionTargetBaseURLs == nil {
+	e.Logger.Fatalf("missing: POST_ISUCONDITION_TARGET_BASE_URLS")
		return
}
```

### サーバー構成を変更
引き続き椅子状態のHTTPリクエストにより /api/trend などの他のリクエストが待ち状態になっていると推測して、POST /api/condition/:jia_isu_uuid へのリクエストだけを全て別サーバーで処理するように変更した。

スコアへの影響は無かったが、CPU負荷は分散された。

- サーバー1: DB
- サーバー2: アプリケーション
- サーバー3: 椅子状態のデータ受信とDBへの書き込み

### 対応方針を再検討
最初に目星をつけた対応を色々と試したが結果が出なかったので、改めて対応方針を検討した。

ベンチマークをログを見ていると「タイムアウトが多く発生しているため、サービスの評判が下がりこれ以上ユーザーは増えません」という怪しげなログを発見。  
ベンチマーク実行後の `user` テーブルを見てみると、ユーザー数が13人しか登録されていなかった。

改めて当日マニュアルのスコア計算の仕様を読み直すと  
> スコアはユーザーがISUのコンディションやスコアを確認すると加点されます。

との事なので、

新規ユーザーは最初にTOPページにアクセスする  
=> TOPページのトレンド情報がリクエストされる  
=> リクエストがタイムアウトしてユーザーが離脱  
=> ユーザー登録されずにユーザーが増えない  
=> スコアが伸びない  

タイムアウトが大量に発生  
=> ユーザーが加点となるリクエストができない  
=> スコアが増えない  

という2つのシナリオを仮定して、スコアを伸ばすためにはユーザーを増やす必要がありそうと判断

そのためには、ログにも出ているタイムアウトを改善する必要があり、タイムアウトとなっているリクエストは明らかに `/api/trend` だったので、このエンドポイントを改善する方針でボトルネック調査を継続

### isu_condition の jia_isu_uuid にインデックスを追加: スコア改善: 8000 => 25000
改めて `/api/trend` のボトルネックを考えていたら `isu_condition` への書き込みが常に発生しているので、テーブルロックが発生して `isu_condition` の読み込みが待ち状態になっている影響で時間がかかっているのでは？と推測

実際に調べてみたら
> InnoDBは行ロックだが、ユニーク制約 or インデックスが張られていないカラムで検索した場合はテーブルロックになってしまう。  

[InnoDBで行ロック/テーブルロックになる条件を調べた \#mysqlcasual Advent Calendar 2013 \- あおうさ＠日記](https://bluerabbit.hatenablog.com/entry/2013/12/07/075759)

という情報を発見  

`/api/trend` は以下のクエリでデータを読み込んでおり、テーブルロックによるりデータの読み込みが待ち状態になっている可能性がありそうだったので、検索カラムにインデックスを追加した。

```sql
SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY timestamp DESC
```

```sql
+ CREATE INDEX jia_isucon_uuid_index ON isu_condition(jia_isu_uuid);
```

この修正 `/api/trend` のレスポンス時間が改善されて、スコアが大幅に上昇した。

### isu_condition の timestamp にインデックスを追加: 25000 => 28000
同様の理由で `isu_condition` の `timestamp` にもインデックを追加して、スコアが上昇

```sql
+ CREATE INDEX jia_isucon_uuid_timestamp_index ON isu_condition(jia_isu_uuid, timestamp);
```

### データを捨てる割合を 90% => 75% に変更: 28000 => 33000
初期実装では受信した椅子の状態の90%を捨てる実装になっていた。

```go
// TODO: 一定割合リクエストを落としてしのぐようにしたが、本来は全量さばけるようにすべき
dropProbability := 0.9
if rand.Float64() <= dropProbability {
	c.Logger().Warnf("drop post isu condition request")
	return c.NoContent(http.StatusAccepted)
}
```

> ISU のコンディション確認（GET /api/condition/:jia_isu_uuid）で、ユーザが前回確認したコンディションより新しいコンディションを確認した際に加点

スコア計算では、ユーザーが新しい状態を確認した時に加点の対象となるため、椅子の状態を捨てていると加点の機会を大きく損なってしまうので、ここの割合を75%に減少させる調整を実施して、スコアが上昇した。

```go
- dropProbability := 0.9
+ dropProbability := 0.75
```

### 画像をクライアントにキャッシュさせる
ここまでの改善で新たに椅子の画像を取得する `GET /api/isu/:jia_isu_uuid/icon` が新たなボトルネックのエンドポイントとして浮上してきた。

ここは明らかにDBにバイナリで画像を保存している事による影響だと考えて、クライアント側に画像をキャッシュさせる対応を試みたが、上手く対応できなかった。

### ログの停止: 33000 => 35000
競技も終盤になっていたので、Nignx や アプリケーションのデバッグログ出力を停止した。  
ちゃんと覚えてないが、スコアが僅かに改善した気がする。

### トレンドのリクエストもサーバー3に流すように変更: 35000 => 47000
全体のCPU負荷を見ていて、サーバー2: アプリケーション のCPU負荷が高く、 サーバー3: 椅子の状態受信 のCPU負荷が低かったので、負荷を分散するために思い切って `/api/trend` のリクエストをサーバー3へリダイレクトする対応を追加

これが見事に成功してCPU負荷が分散されて、スコアが大幅に上昇した。

### 競技終了
17:00で更新が停止された状態でのダッシュボード上での最終スコア  

<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />


ISUCON11予選に参加して自己ベストを更新しました


セキュリティ診断で遊ぶために、4つのローカルプロキシツールを比較検討してみました。

## やりたいこと
特定サービスのJSONのAPIレスポンスの一部を改ざんする

※ 攻撃対象のサービスは自身が開発しているサービスの開発環境に対して実施をしています。

## 比較するツール
ツールは全て無料の範囲で比較しています。お試し期間で有料版が使える場合は、お試し期間の有料版の機能でツールを使用した感想を書いています。

比較方法は上に挙げた「APIレスポンスの改ざん」を試した時の肌感で評価しているので、個人の趣向が非常に強く出ています。

- [Fiddler Everywhere](https://www.telerik.com/fiddler/fiddler-everywhere)
- [Burp Suite](https://portswigger.net/burp/communitydownload)
- [Charles](https://www.charlesproxy.com/)
- [mitmproxy](https://mitmproxy.org/)

## Fiddler（Fiddler Everywhere)
元々 Fiddler は Windows のみ対応のツールだったが、2020年頃に Fiddler Everywhere が MacOS, Linux にも対応したツールとして新たにリリースされた。2ヶ月ほどお試し期間としてPRO版（有料）が利用可能だった。

PRO版の料金は月額課金で $12/月 （年契約だと 10$/月）

### 良い点

- UIが見やすい
    - レスポンスのタイプが一目で確認しやすい
    - レスポンスの書き換えのルールなどが直感的に登録できる（PRO版）
- リクエストの一覧をフィルタリングができる
    - キーワード と Headerの値 で絞り込みが可能
- SSL証明書のインストールやプロキシの設定の手間がない
    - 気づいたら使えるようになってた

### 悪い点

- 無料版だとルールで設定できるアクションに制限がある
    - レスポンスの書き換えも無料版だと出来ない（PRO版なら可能）
    - 有料版でルールのアクションが全て開放されいてる状態だと使いやすかった
- サインインが必須
    - Google認証ができるのでアカウント発行の手間はなし

## Burp Suite

有料版ならセキュリティ診断ツールとして色々な機能が使えそうだった。  
SQLインジェクションの診断とかもできそう？だった。（試してないので正確なことは分からない）

### 良い点

- 自動でレスポンスの書き換えができる
    - 部分文字列一致での置換ができる
- レスポンスを書き換えた場合にオリジナルのレスポンスボディと変更後のレスポンスボディの両方が確認できる
- 日本語の情報が多い
- ステータスコードやレスポンスタイプなどによる柔軟なフィルタリングができる

### 悪い点

- UIが見づらい
- 慣れや好みの問題がもありそう
- 自分がJavaのGUI実装がデザインが好きでないので、その影響が大きい
- 無料版だとキーワードのフィルタリングができない
    - 有料版だと可能
- 有料版が $399/年 とかなり高い
    - プライベートやちょっとした開発での利用用途としては辛い
- 自分でPCのネットワーク設定でプロキシ設定をやる必要がある
- SSL証明書のインストールが少し手間
    - safariで特定のURLを開いて証明書をダウンロード
    - 証明書をキーチェーンに追加
    - 証明書を常に信頼するように変更

## Charles

無料版は30分に1度の頻度で強制終了する。

### 良かった点

- UIが見やすい
    - リクエストがドメインでグルーピングされるので、ドメイン単位でリクエストを見つけやすい
- レスポンスの書き替えルールが簡単に登録できる
- 料金が安い
    - $50/license
    - ライセンス購入時のメジャーバージョンしかアップデートができない
    - 新しいメジャーバージョンのライセンス購入は定価の40%OFFで購入可能

### 悪かった点

- フィルタリング機能が弱い
    - キーワードでしか絞り込みができない
- 設定画面の文字入力で日本語入力中に文字化けが発生して入力中の文字が見えない
    - 確定して入力は完了するので、日本語の利用は可能

## mimproxy

OSSのローカルプロキシツールで、他のツールと比較して CLI で使えるのが大きな特徴

Homeblew でインストールが可能

```json
$ brew install mitmproxy
```

ブラウザで Web Interface を使う場合は、次のコマンドを実行して [http://localhost:8081](http://localhost:8081) にアクセスする。

```sh
$ mitmweb
```

HTTPSの通信をキャプチャする場合は `~/.mitmproxy/mitmproxy-ca-cert.cer` をキーチェーンの証明書に登録して信頼する。

### 良かった点
- 無料
- Pythonでスクリプトを書けるので拡張がしやすい

### 悪かった点
- メインはCUIツールのなので覚える事が多く学習コストが高い
    - WebインターフェースもあるがUIがシンプルな作りなので、操作性は高くない
    - 覚えてしまえばCUIで操作が完結するので合う人には凄い合いそうなイメージ
- レスポンスの書き換えも少しだけ書き方にクセがある
    - `/~s/xxxx/yyyy` みたいな形式で modify_body に追加する
    - `~s` は mitmproxy の [filter expression](https://docs.mitmproxy.org/stable/concepts-filters/) でレスポンスのみを対象とするフィルター


## 結論

|ツール|感想|
|--|--|
|Fiddler Everywhere|UIは一番好き。年1万円の出費が許容できるなら検討する価値はありそう|
|Burp Suite|料金が高すぎるので本当に必要な場面が出てこない限りは使わない|
|Charles|一番バランスが良かった。<br>拡張性もありそうなので、お手軽にプロキシツールを使うなら、コレが一番良さそう。<br>我慢すれば無料のままでも使える|
|mitmproxy|使い方を覚えれば簡単なことは一通りできるので、完全無料でツールを探すならコレを使う。<br>拡張性が高いのは魅力的|



4つのローカルプロキシツールを簡単に触って比較してみました。

ローカルプロキシツールの比較

複数行のテキストを `...` で省略する便利なCSSプロパティとして [-webkit-line-clamp](https://developer.mozilla.org/ja/docs/Web/CSS/-webkit-line-clamp) があります。

このCSSプロパティは使用方法に制限があり`display`プロパティに `-webkit-box` or `-webkit-inline-box` を設定して、かつ `-webkit-box-orient`プロパティに `vertical` を設定する必要があります。

```css
/* 大抵はこんな感じで指定する */
{
    display: -webkit-box;
    -webkit-box-orient: vertical;
    -webkit-line-clamp: 3;
    overflow: hidden;
}
```

ここで指定する `-webkit-box` の正体は `flex` プロパティのベンダープレフィックスです。  
flexが草案時代に WebKit で `flex` を利用するときに使われていたプロパティです。

情報は[WHATWGのページ](https://compat.spec.whatwg.org/#css-keyword-mappings)を参考にしました。


複数行テキストの省略時に使用される-webkit-boxについて簡単に調べました。

複数行テキストの省略と-webkit-boxについて


新センのスタートアップ企業が開発している物理的なキーの配列を自由に変更できる分割キーボード [DUMANG DK6 Ergo](http://www.beyondq.com/%E8%B6%85%E9%85%B7%E7%A7%91%E6%8A%80-%E6%AF%92%E8%9F%92%E9%94%AE%E7%9B%98-%E6%A8%A1%E5%9D%97%E5%8C%96%E9%94%AE%E7%9B%98-dk6-dumang.html) を購入しました。

この分割キーボードを MacOS 上で使う上でいくつか問題があったので、自分が行ったセットアップの手順をまとめています。  
※ この記事は 2021年01月23日 時点で発生した問題について記載しています。対象のキーボードは開発中のためこの記事をお読みになるタイミングでは状況が改善されている可能性があります。

## キーコンビネーション

### 問題

DK6 Ergo は MacOS で動作させると左右のキーボードのキーの組み合わせの入力ができません。Emacs では `Ctrl+N` で下方向へカーソル移動しますが、これは同じ右側のキーボードにあるキーを同時に押す必要があり `左のCtrl + 右のN` という形でキーを押しても反応してくれません。

### 解決

[Karabiner-Elements](https://karabiner-elements.pqrs.org/) をインストールします。特別な設定は不要でアプリケーションを起動するだけで、左右キーボードのキーコンビネーションが動作します。


MacOS で DK6 Ergo をセットアップする


この技術ブログはNetflifyでホスティングをしていますが、前からNetlifyは無料枠だとCDNのエッジサーバーが日本国内にはなくレイテンシーが発生して、遅いという話が気になっていました。

- [Netlifyが日本からだと遅い \- id:anatooのブログ](https://blog.anatoo.jp/2020-08-03)
- [NetlifyからVercelへの移行を検討した話](https://www.suzu6.net/posts/268-blog-server/) 

## 速度検証
同じブログをVercelにもホスティングして、参考記事と同じようにNetlifyとVercelで1.3MBの画像の応答速度を比較してみます。  
※ 検証時間は水曜日の12:00頃に検証しています。

Netlifyは、応答速度: 629ms/req ,転送速度: 2.07MB/sec という結果でした。正直、この数字だけを見ても早いのか遅いのかよく分かっていません。

```
# Netlifyの応答速度（1.3MBの画像をリクエスト）
$ ab -n 10 -c 1 -k https://t-yng.jp/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking t-yng.jp (be patient).....done


Server Software:        Netlify
Server Hostname:        t-yng.jp
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-AES256-GCM-SHA384,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        t-yng.jp

Document Path:          /images/posts/nextjs-perf-improvement/bundle-analyzer-result.png
Document Length:        1337519 bytes

Concurrency Level:      1
Time taken for tests:   6.294 seconds
Complete requests:      10
Failed requests:        0
Keep-Alive requests:    10
Total transferred:      13378950 bytes
HTML transferred:       13375190 bytes
Requests per second:    1.59 [#/sec] (mean)
Time per request:       629.442 [ms] (mean)
Time per request:       629.442 [ms] (mean, across all concurrent requests)
Transfer rate:          2075.71 [Kbytes/sec] received

（省略）
```

Vercelの場合は、応答速度: 172ms/req, 転送速度: 7.5MB/sec となり、Netlifyの約4倍も高速という結果になりました。  
ここまで素直に違いが出ると思わなかったので、驚きました。

```
$ ab -n 10 -c 1 -k https://blog-eta-beryl.vercel.app/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking blog-eta-beryl.vercel.app (be patient).....done


Server Software:        Vercel
Server Hostname:        blog-eta-beryl.vercel.app
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        blog-eta-beryl.vercel.app

Document Path:          /images/posts/nextjs-perf-improvement/bundle-analyzer-result.png
Document Length:        1337519 bytes

Concurrency Level:      1
Time taken for tests:   1.721 seconds
Complete requests:      10
Failed requests:        0
Keep-Alive requests:    10
Total transferred:      13380710 bytes
HTML transferred:       13375190 bytes
Requests per second:    5.81 [#/sec] (mean)
Time per request:       172.050 [ms] (mean)
Time per request:       172.050 [ms] (mean, across all concurrent requests)
Transfer rate:          7594.93 [Kbytes/sec] received

（省略）
 ```

## なぜNetlifyは遅いのか？
最初にも書いたとおり、CDNのエッジサーバーが日本国内になくシンガポールなどの国外のサーバーを経由して配信されるため、その分だけ通信のレイテンシーが発生しているのが原因です。

Netlifyにホスティングしているドメインに対して通信経路を表示してみたら、シンガポールっぽいサーバーにアクセスをしていました。

```zsh
$ traceroute t-yng.jp

traceroute: Warning: t-yng.jp has multiple addresses; using 104.248.158.121
traceroute to t-yng.jp (104.248.158.121), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  2.072 ms  1.227 ms  1.110 ms
 2  192.168.24.1 (192.168.24.1)  1.391 ms  1.580 ms  1.406 ms
 3  153.153.253.241 (153.153.253.241)  6.315 ms  7.216 ms  7.145 ms
 4  153.153.253.133 (153.153.253.133)  5.132 ms  4.885 ms  5.025 ms
 5  118.23.46.65 (118.23.46.65)  7.509 ms  12.750 ms  8.127 ms
 6  180.8.119.137 (180.8.119.137)  8.569 ms  6.889 ms  5.825 ms
 7  153.149.219.49 (153.149.219.49)  14.854 ms  15.650 ms  20.806 ms
 8  153.149.219.146 (153.149.219.146)  22.481 ms  21.862 ms  27.243 ms
 9  ae-12.r02.osakjp02.jp.bb.gin.ntt.net (61.200.80.9)  15.422 ms  18.149 ms  23.293 ms
10  ae-3.r25.osakjp02.jp.bb.gin.ntt.net (129.250.2.129)  17.947 ms
    ae-2.r25.osakjp02.jp.bb.gin.ntt.net (129.250.7.32)  18.441 ms  19.506 ms
11  ae-9.r22.sngpsi07.sg.bb.gin.ntt.net (129.250.2.66)  84.407 ms  90.269 ms  88.346 ms
12  ae-0.a00.sngpsi07.sg.bb.gin.ntt.net (129.250.2.74)  85.529 ms  87.029 ms
    ae-0.a01.sngpsi07.sg.bb.gin.ntt.net (129.250.2.122)  91.914 ms
13  ae-0.digital-ocean.sngpsi07.sg.bb.gin.ntt.net (116.51.17.166)  86.345 ms
    ae-1.digital-ocean.sngpsi07.sg.bb.gin.ntt.net (116.51.17.194)  86.923 ms  88.386 ms
14  138.197.245.9 (138.197.245.9)  90.475 ms * *
```

## Vercelへの移行
### Netlifyとのインテグレーションを解除
最初にNetlifyへの自動デプロイを停止するため、Githubリポジトリのインテグレーションを削除しました。  
自分のGithubリポジトリに移動して、Settings > Integrations > Netlify を選択して削除を実行する。

### Vercelへデプロイ
Next.jsで実装しているので[Next.jsの公式ドキュメント](https://nextjs.org/docs/deployment#vercel-recommended)を参考にして進める。  
基本的にはVercelのページ上でポチポチしてGithubリポジトリをVercelのプロジェクトとしてインポートするだけです。

### Netlifyのカスタムドメインの登録解除
独自ドメインの向き先を Netlify => Vercel に変更する。  
Netlifyではカスタムドメインを設定する為に、ドメイン管理会社側のネームサーバーを変更する必要があった。変更していたネームサーバーをデフォルトのドメイン管理会社のネームサーバーに戻す作業を実施する。  

### Vercelにカスタムドメインを登録
その後、Vercelでプロジェクトを選択して Settings > Domains からカスタムドメインを追加する。  
カスタムドメインの追加後にDNSレコードの設定情報が表示されるので、ドメイン管理会社側にDNSレコードを登録する。

<img src="/images/posts/netlify-to-vercel/vercel-domains-settings.png" alt="カスタムドメインの設定画像" width="1540" height="832" />

以上で Netlify => Vercel の移行は完了です。

ページ読み込み時の画像表示を含めたページ読み込みの速度が体感として非常に早くなりました！

**Netlify でのページ読み込み**

<img src="/images/posts/netlify-to-vercel/netlify.gif" alt="Netlifyでのページ読み込み" width="1425" height="730" />

**Vercel でのページ読み込み**

<img src="/images/posts/netlify-to-vercel/vercel.gif" alt="Vercelでのページ読み込み" width="1425" height="730" />

技術ブログのホスティングをNetlifyからVercelに移行しました

NetlifyからVercelに移行した


先日、TypeScriptのテンプレートリテラル型を使う機会がありました。

## モチベーション
フロントエンドで i18n を導入するために [i18next/i18next](https://github.com/i18next/i18next) を利用して文字列の辞書対応を進めていました。

辞書ファイルを入れ子のオブジェクトとして定義ができますが、キーを指定する場合は `common.badge.required` と指定する必要があります。TypeScripeで実装をするときの問題として、キーの文字列に対して型チェックが有効にならないため、タイポをしても気づかない問題があります。

```typescript
import { t } from 'i18next';

const translation = {
    common: {
        badge: {
            required: '必須',
            optional: '任意'
        }
    }
}

export const resources = {
    ja: {
        translation: translation,
    },
} as const;

i18n.init({
    lng: 'ja',
    resources: resources,
})

// badge => bage とタイポしているが実行時まで気づけない
console.log(t('common.bage.required'));
```

## テンプレートリテラル型で型定義
この問題はテンプレートリテラル型を活用してオブジェクトからキーを `.` で繋いだリテラル型を生成することで解消することができます。

`FlattenKeyOf` のユーティリティ型は型引数としてオブジェクトの型を受け取り、Mapped Types を利用してキーの一覧を取得します。取得したキーに対応する値の型を Conditional Types で判定しオブジェクト型である場合は、キーを `.` で先頭に結合して、対応する値のオブジェクトを `FlattenKeyOf` の型引数に渡して再帰的に呼び出すことで残りのキーを文字列として結合します。値がオブジェクトでない場合はキーをリテラル型として返します。  

`string & K` と書いている部分は `K` が `string | number | symbol` 型として扱われますが、テンプレートリテラル型が受け付ける型はプリミティブ型となっているため、型のミスマッチが発生してエラーが発生するので、Intersection Types を利用して `string` 型であれば `K` を返し違う場合は `never` を返すようにすることで型のエラーを回避しています。

```typescript
// const translation = { link: { top: 'トップページ' }}
// type keys = FlattenKeyOf<typeof translation> = 'link.top'
// FlattenKeyOf<{link: { top: 'トップページへ' }}> = {
//     ['link']: `link.top` <= `link.${FlattenKeyOf<{top: 'トップページへ'}}`
// }['link']                               ^
//                                         |__ 'top' = FlattenKeyOf<{top: 'トップページへ'}> = { ['top']: 'top' }['top']
type FlattenKeyOf<T extends Record<string, unknown>> = {
    [K in keyof T]: T[K] extends Record<string, unknown> ? `${string & K}.${FlattenKeyOf<T[K]>}` : string & K
}[keyof T]

// common.badge.required | common.badge.optional
type ResourceKeys = FlattenKeyOf<typeof messages>;

// 引数のキー文字列が辞書ファイルのキー文字列のユニオン型に限定されるため、型チェックでエラーとなる。
console.log(t<string, ResouceKeys>('common.bage.required'))
```

TypeScriptのテンプレートリテラル型の利用例を紹介します。

TypeScriptのテンプレートリテラル型の利用例


iOS端末ではフォームの入力要素のフォントサイズが16px未満だと、入力要素にフォーカスした時に自動で拡大する仕様があります。  
自動拡大が発生すると、ユーザーに対して拡大された状態を戻す操作を強いてしまうため、ユーザービリティを考慮するとできる限り避けたいです。

## 対応策
### フォントサイズを16px以上にする
入力要素のフォントサイズを 16px 以上にすることで、ブラウザが自動拡大するのを防ぐことができます。  

```css
input, textarea, select {
  font-size: 16px;
}
```

### viewport を設定する
デザインを考えると入力要素のフォントサイズを 16px 未満にしたい状況は往々にして存在します。  
また、入力要素のフォントサイズを `rem` などの相対値で指定していた場合に基準値を変更して予期せずフォントサイズが 16px 未満になる危険性もあるため、フォントサイズを 16px 以上に設定するのは良い解決策とは思えません。

そこで、別のアプローチとして `viewport` の `maximum-scale=1` を設定する方法があります。  
`maximum-scale` の初期値は `1.6` に設定されているため、この値を `1.0` に変更することで、ブラウザの自動拡大が発生しても最大倍率が1倍となるため、拡大表示を防ぐことができます。

```html
<meta name="viewport" content="initial-scale=1.0, width=device-width, maximum-scale=1.0" />
```

## どちらを使うべきか？
フォントサイズを 16px 以上に設定する対応は暗黙的な仕様となり得るので避けたいです。  
また、個人的に入力要素のフォントサイズを 16px にするのは、サイズ的に大きいと感じるのとデザインに制約が発生するので、基本は viewport を設定する方針がベストの対応かなと思います。


iOS端末でフォームの入力要素にフォーカスした時に発生する自動拡大への対応策をまとめています。

iOS端末でのフォームの拡大表示に対応する

神奈川の田舎で働いてるフロントエンドエンジニアのブログ