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

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

<h2 id="問題">問題</h2>
自分は普段 Emacs キーバインドを利用しているのですが、Alfred の検索結果でカーソル移動をするために Ctrl + N をタイプするとカーソル移動せずにパッケージが選択される問題に悩まされていました。
<img src="/images/posts/alfred-ctrl-n/alfred-ctrl-n-bad.gif" alt="ctrl+nでパッケージ選択される" width="840" height="572" />
<h2 id="解決策">解決策</h2>
Alfredの設定で Features &gt; Actions &gt; 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を共有するだけでコードの共有が簡単にできるようになっています。 
外部にコードが保存されるという訳でもないので、どういう仕組みで共有が実現されているか気になったので、調べてみました。
<h2 id="仕組み">仕組み</h2>
仕組みとしては以下の流れでURLを通してコード共有がされていました。
<ol>
<li>エディターに記述してあるコードを文字列圧縮ライブラリで圧縮</li>
<li>URLに圧縮した文字列を挿入</li>
<li>URLを開くときに圧縮された文字列を展開してエディターにコードとして表示する</li>
</ol>
<h2 id="コードの文字列圧縮">コードの文字列圧縮</h2>
コードの圧縮処理は<a href="https://github.com/microsoft/TypeScript-website/blob/1e7ea49f60953aa446b591c6aff347a7c566e3cb/packages/sandbox/src/compilerOptions.ts#L85" target="_blank">ここのコード</a> で処理がされており、<a href="https://pieroxy.net/blog/pages/lz-string/index.html" target="_blank">lz-string</a> という文字列圧縮ライブラリが使われていました。
<pre class="language-typescript"><code class="language-typescript"> const hash = `code/${sandbox.lzstring.compressToEncodedURIComponent(sandbox.getText())}`
</code></pre>

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

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

<a href="https://twitter.com/money166" target="_blank">@money166</a> 
<a href="https://github.com/tatsuo48" target="_blank">@tatsuo48</a> 
と一緒に今年も YO!HEYHEYHEY! として <a href="https://isucon.net/archives/55706291.html" target="_blank">ISUCON11</a>に参加してきました。
今年も非常に楽しく参加できました。 
運営の皆さま、ありがとうございました！
<h2 id="結果">結果</h2>
予選の結果は参考スコアで 47258 で全参加チーム598チーム中80位でした。 
<a href="https://isucon.net/archives/56021246.html" target="_blank">ISUCON11 オンライン予選 全てのチームのスコア（参考値） : ISUCON公式Blog</a>
17:00以降の固定ダッシュボードで25位まで上昇していたので、これは！？と思ったのですが、壁は厚かったです。
<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />
5年間毎年参加して、ずっと初期実装のスコアから大きく点数を上げられなかったので、6年目の今年は非常に大きな進歩があって嬉しかったです！
<h2 id="テーマ">テーマ</h2>
今年のアプリケーションのテーマは自分が持っている椅子の状態を監視するWebサービスでした。 
登録している椅子が定期的にサーバーに自身の状態を送信して、ユーザーはその状態をWebサービスで確認することで椅子の状態を管理できます。
いわゆる IoT です。
サービスの説明からも予想できる通り、今年は常に大量のデーターがサーバーに送信されDBに書き込まれ続けるので、DBのCPU負荷が常に高い状態でした。（ベンチ回したら最初からCPU負荷が150%とか出ていました） 
このDB負荷をどう処理するかが問題のキーとなっている印象でした。
<h2 id="振り返り">振り返り</h2>
<h3 id="良かった点">良かった点</h3>
<ul>
<li>今年はZoomで繋いでオンラインで作業をしており、画面共有などでチームでの作業がやりやすかった</li>
<li>ベンチ回して効果が無い場合は前の状態に戻す徹底できたので、アプリケーションが動かなくなる問題が発生しなかった</li>
<li>基本は2人以上のペアプロを意識して進めたので、それによって気付ける事が多かった
<ul>
<li>ボトルネックの原因とか</li>
</ul>
</li>
<li>しっかりマニュアルを読み込んでスコア計算の仕様を意識して対応方針が決められた</li>
<li>Miroでタスク管理して誰が何をやっているか把握しながら進められた</li>
</ul>
<h3 id="反省点">反省点</h3>
<ul>
<li>Go言語をあまり勉強しておらずアプリケーションの修正に時間がかかった</li>
<li>勉強不足で New Relic での DB の監視を導入できなかった</li>
<li>全体的にスコア上がってから次の一手が思いつかず頭打ちになった</li>
</ul>
<h2 id="チームでやったこと">チームでやったこと</h2>
<ul>
<li>インフラ環境の初期構築をしてサーバーを立ち上げ</li>
<li>当日マニュアルやアプリケーションマニュアルを熟読</li>
<li>アプリケーションを実際に動かして機能一覧を把握</li>
<li>競技用サーバーへのデプロイ環境の整備</li>
<li>アプリケーションに New Relic のエージェントを追加</li>
<li>DBのスキーマ情報を整理</li>
<li>New Relic のダッシュボードでHTTPリクエストを確認してボトルネックを調査して対応方針を検討</li>
<li>==== ↓ ここからボトルネック対応 ====</li>
<li>サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 =&gt; 8000</li>
<li>isu テーブルで画像カラムをクエリしない修正を追加: スコア変わらず</li>
<li>椅子の状態のデータ送信をサーバー3台に分散: スコア変わらず</li>
<li>椅子の状態のDBへの書き込みをバルクインサートに変更: 上手く実装できず</li>
<li>サーバー構成を サーバー1: DB, サーバー2: アプリケーション, サーバー3: 椅子状態のデータ受信 に変更: スコア変わらず</li>
<li>対応方針を再検討</li>
<li>isu_condition の jia_isu_uuid にインデックスを追加: 8000 =&gt; 25000</li>
<li>isu_condition の timestamp にインデックスを追加: 25000 =&gt; 28000</li>
<li>データを捨てる割合を 90% =&gt; 75% に変更: 28000 =&gt; 33000</li>
<li>画像をクライアントにキャッシュさせる: 対応が上手くできなかった</li>
<li>Nginx や アプリケーション のデバッグログを停止: 33000 =&gt; 35000 （影響あった気がする）</li>
<li>/api/trend のリクエストもサーバー3に流すように変更: 35000 =&gt; 47000</li>
</ul>
<h3 id="アプリケーションを実際に動かして機能一覧を把握">アプリケーションを実際に動かして機能一覧を把握</h3>
今回は例年と比べてアプリケーション規模が小さい？印象だったので、全体の把握がスムーズにできた。 
オープニングでの事前のサービス紹介で概要が掴めたのも大きかった。
<h3 id="New Relic の Go エージェントの追加">New Relic の Go エージェントの追加</h3>
次のドキュメントを参考に echo のミドルウェアとしてエージェントを追加した
<ul>
<li><a href="https://docs.newrelic.com/jp/docs/agents/go-agent/installation/install-new-relic-go/" target="_blank">Go向けNew Relicのインストール | New Relic Documentation</a></li>
<li><a href="https://docs.newrelic.com/jp/docs/agents/go-agent/get-started/go-agent-compatibility-requirements/" target="_blank">Goエージェントの互換性と要件 | New Relic Documentation</a></li>
</ul>
<h3 id="HTTPリクエストを確認してボトルネックを調査して対応方針を検討">HTTPリクエストを確認してボトルネックを調査して対応方針を検討</h3>
リクエストの大半は <code>POST /api/condition/:jia_isu_uuid</code> が占めていた。 
これは椅子の状態を受け取ってDBに書き込むAPIエンドポイントなので、当初の想定通り。
<code>GET /api/trend</code> が最大で60sec、平均しても20secのレスポンス時間となっていた。
上記2つのAPIエンドポイントに絞って、実装の詳細を確認しながらボトルネックの調査と対応方針を決めた。
<h3 id="サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 =&gt; 8000">サーバー構成を サーバー1:DB, サーバー2: アプリケーション に変更: 1000 =&gt; 8000</h3>
DBのCPU負荷が150~180%とかなり高かったので、サーバー1をDB専用にして、リクエストをサーバー２で捌くように変更した。
7000点ほどスコアが上昇
<h3 id="isu テーブルで画像カラムをクエリしない">isu テーブルで画像カラムをクエリしない</h3>
isu_conditions テーブルには画像がバイナリで含まれていた。 
/api/trend では <code>SELECT * FROM isu</code> と未使用にも関わらず画像カラムも取得していたので、これで読み込みに時間がかかってレスポンス時間に影響していると予測して、必要なカラムだけをクエリするようにしたが、大きな変化は無かった。
<pre><code class="language-go">- &quot;SELECT * FROM `isu` WHERE `character` = ?&quot;,
+ &quot;SELECT `id`, `jia_isu_uuid` FROM `isu` WHERE `character` = ?&quot;,
</code></pre>
<h3 id="椅子の状態のデータ送信をサーバー3台に分散">椅子の状態のデータ送信をサーバー3台に分散</h3>
椅子状態のデータ送信が大量にリクエストされているので、これにより他のリクエストが待機状態で捌かれていないのでは？と思い3台にリクエストを分散してみた。 
あまり効果は無かった。
<pre><code class="language-go">- postIsuConditionTargetBaseURL string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL
+ postIsuConditionTargetBaseURLs []string // JIAへのactivate時に登録する，ISUがconditionを送る先のURL

=======

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

+ postIsuConditionTargetBaseURLs = strings.Split(os.Getenv(&quot;POST_ISUCONDITION_TARGET_BASE_URLS&quot;), &quot;,&quot;)
+ if postIsuConditionTargetBaseURLs == nil {
+	e.Logger.Fatalf(&quot;missing: POST_ISUCONDITION_TARGET_BASE_URLS&quot;)
		return
}
</code></pre>
<h3 id="サーバー構成を変更">サーバー構成を変更</h3>
引き続き椅子状態のHTTPリクエストにより /api/trend などの他のリクエストが待ち状態になっていると推測して、POST /api/condition/:jia_isu_uuid へのリクエストだけを全て別サーバーで処理するように変更した。
スコアへの影響は無かったが、CPU負荷は分散された。
<ul>
<li>サーバー1: DB</li>
<li>サーバー2: アプリケーション</li>
<li>サーバー3: 椅子状態のデータ受信とDBへの書き込み</li>
</ul>
<h3 id="対応方針を再検討">対応方針を再検討</h3>
最初に目星をつけた対応を色々と試したが結果が出なかったので、改めて対応方針を検討した。
ベンチマークをログを見ていると「タイムアウトが多く発生しているため、サービスの評判が下がりこれ以上ユーザーは増えません」という怪しげなログを発見。 
ベンチマーク実行後の <code>user</code> テーブルを見てみると、ユーザー数が13人しか登録されていなかった。
改めて当日マニュアルのスコア計算の仕様を読み直すと
<blockquote>
スコアはユーザーがISUのコンディションやスコアを確認すると加点されます。
</blockquote>
との事なので、
新規ユーザーは最初にTOPページにアクセスする 
=&gt; TOPページのトレンド情報がリクエストされる 
=&gt; リクエストがタイムアウトしてユーザーが離脱 
=&gt; ユーザー登録されずにユーザーが増えない 
=&gt; スコアが伸びない
タイムアウトが大量に発生 
=&gt; ユーザーが加点となるリクエストができない 
=&gt; スコアが増えない
という2つのシナリオを仮定して、スコアを伸ばすためにはユーザーを増やす必要がありそうと判断
そのためには、ログにも出ているタイムアウトを改善する必要があり、タイムアウトとなっているリクエストは明らかに <code>/api/trend</code> だったので、このエンドポイントを改善する方針でボトルネック調査を継続
<h3 id="isu_condition の jia_isu_uuid にインデックスを追加: スコア改善: 8000 =&gt; 25000">isu_condition の jia_isu_uuid にインデックスを追加: スコア改善: 8000 =&gt; 25000</h3>
改めて <code>/api/trend</code> のボトルネックを考えていたら <code>isu_condition</code> への書き込みが常に発生しているので、テーブルロックが発生して <code>isu_condition</code> の読み込みが待ち状態になっている影響で時間がかかっているのでは？と推測
実際に調べてみたら
<blockquote>
InnoDBは行ロックだが、ユニーク制約 or インデックスが張られていないカラムで検索した場合はテーブルロックになってしまう。
</blockquote>
<a href="https://bluerabbit.hatenablog.com/entry/2013/12/07/075759" target="_blank">InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ＠日記</a>
という情報を発見
<code>/api/trend</code> は以下のクエリでデータを読み込んでおり、テーブルロックによるりデータの読み込みが待ち状態になっている可能性がありそうだったので、検索カラムにインデックスを追加した。
<pre><code class="language-sql">SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY timestamp DESC
</code></pre>
<pre><code class="language-sql">+ CREATE INDEX jia_isucon_uuid_index ON isu_condition(jia_isu_uuid);
</code></pre>
この修正 <code>/api/trend</code> のレスポンス時間が改善されて、スコアが大幅に上昇した。
<h3 id="isu_condition の timestamp にインデックスを追加: 25000 =&gt; 28000">isu_condition の timestamp にインデックスを追加: 25000 =&gt; 28000</h3>
同様の理由で <code>isu_condition</code> の <code>timestamp</code> にもインデックを追加して、スコアが上昇
<pre><code class="language-sql">+ CREATE INDEX jia_isucon_uuid_timestamp_index ON isu_condition(jia_isu_uuid, timestamp);
</code></pre>
<h3 id="データを捨てる割合を 90% =&gt; 75% に変更: 28000 =&gt; 33000">データを捨てる割合を 90% =&gt; 75% に変更: 28000 =&gt; 33000</h3>
初期実装では受信した椅子の状態の90%を捨てる実装になっていた。
<pre><code class="language-go">// TODO: 一定割合リクエストを落としてしのぐようにしたが、本来は全量さばけるようにすべき
dropProbability := 0.9
if rand.Float64() &lt;= dropProbability {
	c.Logger().Warnf(&quot;drop post isu condition request&quot;)
	return c.NoContent(http.StatusAccepted)
}
</code></pre>
<blockquote>
ISU のコンディション確認（GET /api/condition/:jia_isu_uuid）で、ユーザが前回確認したコンディションより新しいコンディションを確認した際に加点
</blockquote>
スコア計算では、ユーザーが新しい状態を確認した時に加点の対象となるため、椅子の状態を捨てていると加点の機会を大きく損なってしまうので、ここの割合を75%に減少させる調整を実施して、スコアが上昇した。
<pre><code class="language-go">- dropProbability := 0.9
+ dropProbability := 0.75
</code></pre>
<h3 id="画像をクライアントにキャッシュさせる">画像をクライアントにキャッシュさせる</h3>
ここまでの改善で新たに椅子の画像を取得する <code>GET /api/isu/:jia_isu_uuid/icon</code> が新たなボトルネックのエンドポイントとして浮上してきた。
ここは明らかにDBにバイナリで画像を保存している事による影響だと考えて、クライアント側に画像をキャッシュさせる対応を試みたが、上手く対応できなかった。
<h3 id="ログの停止: 33000 =&gt; 35000">ログの停止: 33000 =&gt; 35000</h3>
競技も終盤になっていたので、Nignx や アプリケーションのデバッグログ出力を停止した。 
ちゃんと覚えてないが、スコアが僅かに改善した気がする。
<h3 id="トレンドのリクエストもサーバー3に流すように変更: 35000 =&gt; 47000">トレンドのリクエストもサーバー3に流すように変更: 35000 =&gt; 47000</h3>
全体のCPU負荷を見ていて、サーバー2: アプリケーション のCPU負荷が高く、 サーバー3: 椅子の状態受信 のCPU負荷が低かったので、負荷を分散するために思い切って <code>/api/trend</code> のリクエストをサーバー3へリダイレクトする対応を追加
これが見事に成功してCPU負荷が分散されて、スコアが大幅に上昇した。
<h3 id="競技終了">競技終了</h3>
17:00で更新が停止された状態でのダッシュボード上での最終スコア
<img src="/images/posts/isucon11/dashboard-last-score.jpg" alt="ダッシュボードでの最終スコア" width="1798" height="330" />

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

セキュリティ診断で遊ぶために、4つのローカルプロキシツールを比較検討してみました。
<h2 id="やりたいこと">やりたいこと</h2>
特定サービスのJSONのAPIレスポンスの一部を改ざんする
※ 攻撃対象のサービスは自身が開発しているサービスの開発環境に対して実施をしています。
<h2 id="比較するツール">比較するツール</h2>
ツールは全て無料の範囲で比較しています。お試し期間で有料版が使える場合は、お試し期間の有料版の機能でツールを使用した感想を書いています。
比較方法は上に挙げた「APIレスポンスの改ざん」を試した時の肌感で評価しているので、個人の趣向が非常に強く出ています。
<ul>
<li><a href="https://www.telerik.com/fiddler/fiddler-everywhere" target="_blank">Fiddler Everywhere</a></li>
<li><a href="https://portswigger.net/burp/communitydownload" target="_blank">Burp Suite</a></li>
<li><a href="https://www.charlesproxy.com/" target="_blank">Charles</a></li>
<li><a href="https://mitmproxy.org/" target="_blank">mitmproxy</a></li>
</ul>
<h2 id="Fiddler（Fiddler Everywhere)">Fiddler（Fiddler Everywhere)</h2>
元々 Fiddler は Windows のみ対応のツールだったが、2020年頃に Fiddler Everywhere が MacOS, Linux にも対応したツールとして新たにリリースされた。2ヶ月ほどお試し期間としてPRO版（有料）が利用可能だった。
PRO版の料金は月額課金で $12/月 （年契約だと 10$/月）
<h3 id="良い点">良い点</h3>
<ul>
<li>UIが見やすい
<ul>
<li>レスポンスのタイプが一目で確認しやすい</li>
<li>レスポンスの書き換えのルールなどが直感的に登録できる（PRO版）</li>
</ul>
</li>
<li>リクエストの一覧をフィルタリングができる
<ul>
<li>キーワード と Headerの値 で絞り込みが可能</li>
</ul>
</li>
<li>SSL証明書のインストールやプロキシの設定の手間がない
<ul>
<li>気づいたら使えるようになってた</li>
</ul>
</li>
</ul>
<h3 id="悪い点">悪い点</h3>
<ul>
<li>無料版だとルールで設定できるアクションに制限がある
<ul>
<li>レスポンスの書き換えも無料版だと出来ない（PRO版なら可能）</li>
<li>有料版でルールのアクションが全て開放されいてる状態だと使いやすかった</li>
</ul>
</li>
<li>サインインが必須
<ul>
<li>Google認証ができるのでアカウント発行の手間はなし</li>
</ul>
</li>
</ul>
<h2 id="Burp Suite">Burp Suite</h2>
有料版ならセキュリティ診断ツールとして色々な機能が使えそうだった。 
SQLインジェクションの診断とかもできそう？だった。（試してないので正確なことは分からない）
<h3 id="良い点">良い点</h3>
<ul>
<li>自動でレスポンスの書き換えができる
<ul>
<li>部分文字列一致での置換ができる</li>
</ul>
</li>
<li>レスポンスを書き換えた場合にオリジナルのレスポンスボディと変更後のレスポンスボディの両方が確認できる</li>
<li>日本語の情報が多い</li>
<li>ステータスコードやレスポンスタイプなどによる柔軟なフィルタリングができる</li>
</ul>
<h3 id="悪い点">悪い点</h3>
<ul>
<li>UIが見づらい</li>
<li>慣れや好みの問題がもありそう</li>
<li>自分がJavaのGUI実装がデザインが好きでないので、その影響が大きい</li>
<li>無料版だとキーワードのフィルタリングができない
<ul>
<li>有料版だと可能</li>
</ul>
</li>
<li>有料版が $399/年 とかなり高い
<ul>
<li>プライベートやちょっとした開発での利用用途としては辛い</li>
</ul>
</li>
<li>自分でPCのネットワーク設定でプロキシ設定をやる必要がある</li>
<li>SSL証明書のインストールが少し手間
<ul>
<li>safariで特定のURLを開いて証明書をダウンロード</li>
<li>証明書をキーチェーンに追加</li>
<li>証明書を常に信頼するように変更</li>
</ul>
</li>
</ul>
<h2 id="Charles">Charles</h2>
無料版は30分に1度の頻度で強制終了する。
<h3 id="良かった点">良かった点</h3>
<ul>
<li>UIが見やすい
<ul>
<li>リクエストがドメインでグルーピングされるので、ドメイン単位でリクエストを見つけやすい</li>
</ul>
</li>
<li>レスポンスの書き替えルールが簡単に登録できる</li>
<li>料金が安い
<ul>
<li>$50/license</li>
<li>ライセンス購入時のメジャーバージョンしかアップデートができない</li>
<li>新しいメジャーバージョンのライセンス購入は定価の40%OFFで購入可能</li>
</ul>
</li>
</ul>
<h3 id="悪かった点">悪かった点</h3>
<ul>
<li>フィルタリング機能が弱い
<ul>
<li>キーワードでしか絞り込みができない</li>
</ul>
</li>
<li>設定画面の文字入力で日本語入力中に文字化けが発生して入力中の文字が見えない
<ul>
<li>確定して入力は完了するので、日本語の利用は可能</li>
</ul>
</li>
</ul>
<h2 id="mimproxy">mimproxy</h2>
OSSのローカルプロキシツールで、他のツールと比較して CLI で使えるのが大きな特徴
Homeblew でインストールが可能
<pre class="language-json"><code class="language-json">$ brew install mitmproxy
</code></pre>
ブラウザで Web Interface を使う場合は、次のコマンドを実行して <a href="http://localhost:8081" target="_blank">http://localhost:8081</a> にアクセスする。
<pre><code class="language-sh">$ mitmweb
</code></pre>
HTTPSの通信をキャプチャする場合は <code>~/.mitmproxy/mitmproxy-ca-cert.cer</code> をキーチェーンの証明書に登録して信頼する。
<h3 id="良かった点">良かった点</h3>
<ul>
<li>無料</li>
<li>Pythonでスクリプトを書けるので拡張がしやすい</li>
</ul>
<h3 id="悪かった点">悪かった点</h3>
<ul>
<li>メインはCUIツールのなので覚える事が多く学習コストが高い
<ul>
<li>WebインターフェースもあるがUIがシンプルな作りなので、操作性は高くない</li>
<li>覚えてしまえばCUIで操作が完結するので合う人には凄い合いそうなイメージ</li>
</ul>
</li>
<li>レスポンスの書き換えも少しだけ書き方にクセがある
<ul>
<li><code>/~s/xxxx/yyyy</code> みたいな形式で modify_body に追加する</li>
<li><code>~s</code> は mitmproxy の <a href="https://docs.mitmproxy.org/stable/concepts-filters/" target="_blank">filter expression</a> でレスポンスのみを対象とするフィルター</li>
</ul>
</li>
</ul>
<h2 id="結論">結論</h2>
<table>
<thead>
<tr>
<th>ツール</th>
<th>感想</th>
</tr>
</thead>
<tbody>
<tr>
<td>Fiddler Everywhere</td>
<td>UIは一番好き。年1万円の出費が許容できるなら検討する価値はありそう</td>
</tr>
<tr>
<td>Burp Suite</td>
<td>料金が高すぎるので本当に必要な場面が出てこない限りは使わない</td>
</tr>
<tr>
<td>Charles</td>
<td>一番バランスが良かった。 拡張性もありそうなので、お手軽にプロキシツールを使うなら、コレが一番良さそう。 我慢すれば無料のままでも使える</td>
</tr>
<tr>
<td>mitmproxy</td>
<td>使い方を覚えれば簡単なことは一通りできるので、完全無料でツールを探すならコレを使う。 拡張性が高いのは魅力的</td>
</tr>
</tbody>
</table>

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

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

複数行のテキストを <code>...</code> で省略する便利なCSSプロパティとして <a href="https://developer.mozilla.org/ja/docs/Web/CSS/-webkit-line-clamp" target="_blank">-webkit-line-clamp</a> があります。
このCSSプロパティは使用方法に制限があり<code>display</code>プロパティに <code>-webkit-box</code> or <code>-webkit-inline-box</code> を設定して、かつ <code>-webkit-box-orient</code>プロパティに <code>vertical</code> を設定する必要があります。
<pre class="language-css"><code class="language-css">/* 大抵はこんな感じで指定する */
{
 display: -webkit-box;
 -webkit-box-orient: vertical;
 -webkit-line-clamp: 3;
 overflow: hidden;
}
</code></pre>
ここで指定する <code>-webkit-box</code> の正体は <code>flex</code> プロパティのベンダープレフィックスです。 
flexが草案時代に WebKit で <code>flex</code> を利用するときに使われていたプロパティです。
情報は<a href="https://compat.spec.whatwg.org/#css-keyword-mappings" target="_blank">WHATWGのページ</a>を参考にしました。

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

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

新センのスタートアップ企業が開発している物理的なキーの配列を自由に変更できる分割キーボード <a href="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" target="_blank">DUMANG DK6 Ergo</a> を購入しました。
この分割キーボードを MacOS 上で使う上でいくつか問題があったので、自分が行ったセットアップの手順をまとめています。 
※ この記事は 2021年01月23日 時点で発生した問題について記載しています。対象のキーボードは開発中のためこの記事をお読みになるタイミングでは状況が改善されている可能性があります。
<h2 id="キーコンビネーション">キーコンビネーション</h2>
<h3 id="問題">問題</h3>
DK6 Ergo は MacOS で動作させると左右のキーボードのキーの組み合わせの入力ができません。Emacs では <code>Ctrl+N</code> で下方向へカーソル移動しますが、これは同じ右側のキーボードにあるキーを同時に押す必要があり <code>左のCtrl + 右のN</code> という形でキーを押しても反応してくれません。
<h3 id="解決">解決</h3>
<a href="https://karabiner-elements.pqrs.org/" target="_blank">Karabiner-Elements</a> をインストールします。特別な設定は不要でアプリケーションを起動するだけで、左右キーボードのキーコンビネーションが動作します。

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

この技術ブログはNetflifyでホスティングをしていますが、前からNetlifyは無料枠だとCDNのエッジサーバーが日本国内にはなくレイテンシーが発生して、遅いという話が気になっていました。
<ul>
<li><a href="https://blog.anatoo.jp/2020-08-03" target="_blank">Netlifyが日本からだと遅い - id:anatooのブログ</a></li>
<li><a href="https://www.suzu6.net/posts/268-blog-server/" target="_blank">NetlifyからVercelへの移行を検討した話</a></li>
</ul>
<h2 id="速度検証">速度検証</h2>
同じブログをVercelにもホスティングして、参考記事と同じようにNetlifyとVercelで1.3MBの画像の応答速度を比較してみます。 
※ 検証時間は水曜日の12:00頃に検証しています。
Netlifyは、応答速度: 629ms/req ,転送速度: 2.07MB/sec という結果でした。正直、この数字だけを見ても早いのか遅いのかよく分かっていません。
<pre><code># 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 &lt;$Revision: 1843412 $&gt;
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

（省略）
</code></pre>
Vercelの場合は、応答速度: 172ms/req, 転送速度: 7.5MB/sec となり、Netlifyの約4倍も高速という結果になりました。 
ここまで素直に違いが出ると思わなかったので、驚きました。
<pre><code>$ 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 &lt;$Revision: 1843412 $&gt;
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

（省略）
</code></pre>
<h2 id="なぜNetlifyは遅いのか？">なぜNetlifyは遅いのか？</h2>
最初にも書いたとおり、CDNのエッジサーバーが日本国内になくシンガポールなどの国外のサーバーを経由して配信されるため、その分だけ通信のレイテンシーが発生しているのが原因です。
Netlifyにホスティングしているドメインに対して通信経路を表示してみたら、シンガポールっぽいサーバーにアクセスをしていました。
<pre><code class="language-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 * *
</code></pre>
<h2 id="Vercelへの移行">Vercelへの移行</h2>
<h3 id="Netlifyとのインテグレーションを解除">Netlifyとのインテグレーションを解除</h3>
最初にNetlifyへの自動デプロイを停止するため、Githubリポジトリのインテグレーションを削除しました。 
自分のGithubリポジトリに移動して、Settings &gt; Integrations &gt; Netlify を選択して削除を実行する。
<h3 id="Vercelへデプロイ">Vercelへデプロイ</h3>
Next.jsで実装しているので<a href="https://nextjs.org/docs/deployment#vercel-recommended" target="_blank">Next.jsの公式ドキュメント</a>を参考にして進める。 
基本的にはVercelのページ上でポチポチしてGithubリポジトリをVercelのプロジェクトとしてインポートするだけです。
<h3 id="Netlifyのカスタムドメインの登録解除">Netlifyのカスタムドメインの登録解除</h3>
独自ドメインの向き先を Netlify =&gt; Vercel に変更する。 
Netlifyではカスタムドメインを設定する為に、ドメイン管理会社側のネームサーバーを変更する必要があった。変更していたネームサーバーをデフォルトのドメイン管理会社のネームサーバーに戻す作業を実施する。
<h3 id="Vercelにカスタムドメインを登録">Vercelにカスタムドメインを登録</h3>
その後、Vercelでプロジェクトを選択して Settings &gt; Domains からカスタムドメインを追加する。 
カスタムドメインの追加後にDNSレコードの設定情報が表示されるので、ドメイン管理会社側にDNSレコードを登録する。
<img src="/images/posts/netlify-to-vercel/vercel-domains-settings.png" alt="カスタムドメインの設定画像" width="1540" height="832" />
以上で Netlify =&gt; 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のテンプレートリテラル型を使う機会がありました。
<h2 id="モチベーション">モチベーション</h2>
フロントエンドで i18n を導入するために <a href="https://github.com/i18next/i18next" target="_blank">i18next/i18next</a> を利用して文字列の辞書対応を進めていました。
辞書ファイルを入れ子のオブジェクトとして定義ができますが、キーを指定する場合は <code>common.badge.required</code> と指定する必要があります。TypeScripeで実装をするときの問題として、キーの文字列に対して型チェックが有効にならないため、タイポをしても気づかない問題があります。
<pre class="language-typescript"><code class="language-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'));
</code></pre>
<h2 id="テンプレートリテラル型で型定義">テンプレートリテラル型で型定義</h2>
この問題はテンプレートリテラル型を活用してオブジェクトからキーを <code>.</code> で繋いだリテラル型を生成することで解消することができます。
<code>FlattenKeyOf</code> のユーティリティ型は型引数としてオブジェクトの型を受け取り、Mapped Types を利用してキーの一覧を取得します。取得したキーに対応する値の型を Conditional Types で判定しオブジェクト型である場合は、キーを <code>.</code> で先頭に結合して、対応する値のオブジェクトを <code>FlattenKeyOf</code> の型引数に渡して再帰的に呼び出すことで残りのキーを文字列として結合します。値がオブジェクトでない場合はキーをリテラル型として返します。
<code>string &amp; K</code> と書いている部分は <code>K</code> が <code>string | number | symbol</code> 型として扱われますが、テンプレートリテラル型が受け付ける型はプリミティブ型となっているため、型のミスマッチが発生してエラーが発生するので、Intersection Types を利用して <code>string</code> 型であれば <code>K</code> を返し違う場合は <code>never</code> を返すようにすることで型のエラーを回避しています。
<pre class="language-typescript"><code class="language-typescript">// const translation = { link: { top: 'トップページ' }}
// type keys = FlattenKeyOf&lt;typeof translation> = 'link.top'
// FlattenKeyOf&lt;{link: { top: 'トップページへ' }}> = {
// ['link']: `link.top` &lt;= `link.${FlattenKeyOf&lt;{top: 'トップページへ'}}`
// }['link'] ^
// |__ 'top' = FlattenKeyOf&lt;{top: 'トップページへ'}> = { ['top']: 'top' }['top']
type FlattenKeyOf&lt;T extends Record&lt;string, unknown>> = {
 [K in keyof T]: T[K] extends Record&lt;string, unknown> ? `${string &amp; K}.${FlattenKeyOf&lt;T[K]>}` : string &amp; K
}[keyof T]

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

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

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

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

iOS端末ではフォームの入力要素のフォントサイズが16px未満だと、入力要素にフォーカスした時に自動で拡大する仕様があります。 
自動拡大が発生すると、ユーザーに対して拡大された状態を戻す操作を強いてしまうため、ユーザービリティを考慮するとできる限り避けたいです。
<h2 id="対応策">対応策</h2>
<h3 id="フォントサイズを16px以上にする">フォントサイズを16px以上にする</h3>
入力要素のフォントサイズを 16px 以上にすることで、ブラウザが自動拡大するのを防ぐことができます。
<pre class="language-css"><code class="language-css">input, textarea, select {
 font-size: 16px;
}
</code></pre>
<h3 id="viewport を設定する">viewport を設定する</h3>
デザインを考えると入力要素のフォントサイズを 16px 未満にしたい状況は往々にして存在します。 
また、入力要素のフォントサイズを <code>rem</code> などの相対値で指定していた場合に基準値を変更して予期せずフォントサイズが 16px 未満になる危険性もあるため、フォントサイズを 16px 以上に設定するのは良い解決策とは思えません。
そこで、別のアプローチとして <code>viewport</code> の <code>maximum-scale=1</code> を設定する方法があります。 
<code>maximum-scale</code> の初期値は <code>1.6</code> に設定されているため、この値を <code>1.0</code> に変更することで、ブラウザの自動拡大が発生しても最大倍率が1倍となるため、拡大表示を防ぐことができます。
<pre class="language-html"><code class="language-html">&lt;meta name="viewport" content="initial-scale=1.0, width=device-width, maximum-scale=1.0" />
</code></pre>
<h2 id="どちらを使うべきか？">どちらを使うべきか？</h2>
フォントサイズを 16px 以上に設定する対応は暗黙的な仕様となり得るので避けたいです。 
また、個人的に入力要素のフォントサイズを 16px にするのは、サイズ的に大きいと感じるのとデザインに制約が発生するので、基本は viewport を設定する方針がベストの対応かなと思います。

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

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

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