この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の22日目の記事です。
<h2 id="はじめに">はじめに</h2>
現在、輪読会で <a href="https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank">テスト駆動開発</a>（TDD）を読み進めています。 
本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。
<h2 id="なぜバグ修正から始めるのか？">なぜバグ修正から始めるのか？</h2>
TDDをする上で一番難しいなと感じるのが、実装前に何のテストを書けば良いか分からないという部分です。 
今までテストを書いた経験が少ないと、対象となるコードが無い状態からテストを書き始めるのはイメージがしづらく中々テストを書くことができません。
その点、バグ修正の場合は既にコードが存在しており、バグを再現するテストを書けば良く何をテストするかも明確になっているので、非常にテストコードが書きやすいという利点があります。
そのため、バグ修正は比較的スムーズにTDDのフローを回しやすく手軽にTDDを体験することができます。
<h2 id="TDDでバグ修正に挑戦する">TDDでバグ修正に挑戦する</h2>
<h3 id="概要">概要</h3>
ユーザーのアバター画像とユーザー名を表示する <code>UserBio</code> コンポーネントについて考えてみます。
このコンポーネントはアバター画像について考慮が漏れておりリンク切れのバグが発生する可能性があります。
<ul>
<li>バグ: アバター画像が未設定の場合にリンク切れで画像が表示される</li>
<li>期待する動作: アバター画像が未設定の場合はサムネイル画像を表示する</li>
</ul>
<pre class="language-tsx"><code class="language-tsx">// src/components/UserBio.tsx
import { FC } from 'react';

type Props = {
 user: {
 name: string;
 avatar?: string;
 }
}

export const UserBio: FC&lt;Props> = ({ user }) => {
 return (
 &lt;div>
 &lt;img src={user.avatar} />
 &lt;span>{user.name}&lt;/span>
 &lt;/div>
 )
}
</code></pre>
<h3 id="バグを再現するテストコードを書く">バグを再現するテストコードを書く</h3>
コードのバグを修正したい気持ちをぐっ！と抑えて、先にテストコードを書いていきます。
どんなテストコードを書けば良いでしょうか？ 
今回の目的はバグ修正のためバグを再現するテストコードを書けば良いので、何をテストするかは非常に明確です。
本来であれば、テストが全く書かれいない場合はアバター画像を表示するテストも先に書いておいた方が良いですが説明の都合で割愛しています。
<pre class="language-typescript"><code class="language-typescript">// src/components/UserBio.spec.tsx
import "@testing-library/jest-dom";
import { render, screen } from "@testing-library/react";
import { UserBio } from "./UserBio";

describe("UserBio", () => {
 it("アバター画像が未設定のときにサムネイル画像を表示する", () => {
 render(&lt;UserBio user={{ name: "テスト太郎" }} />);

 const expected = "https://example.com/images/avatar";
 expect(screen.getByRole("img")).toHaveAttribute("src", expected);
 });
});
</code></pre>
テストを実行してみます。 
正常にテストが失敗してくれたので、これでバグを再現するテストコードが実装できました。
<pre class="language-shell"><code class="language-shell">$ yarn jest src/components/UserBio.spec.tsx

 FAIL src/components/UserBio.spec.tsx
 UserBio
 ✕ アバター画像が未設定のときにサムネイル画像を表示する (85 ms)

 ● UserBio › アバター画像が未設定のときにサムネイル画像を表示する

 expect(element).toHaveAttribute("src", "https://example.com/images/avatar") // element.getAttribute("src") === "https://example.com/images/avatar"

 Expected the element to have attribute:
 src="https://example.com/images/avatar"
 Received:
 null
</code></pre>
<h3 id="バグ修正対応">バグ修正対応</h3>
バグを再現するテストができたので、後は楽しくバグ修正のコードを書くだけです。
<pre class="language-tsx"><code class="language-tsx">const AVATAR_THUMBNAIL = 'https://example.com/images/avatar';

export const UserBio: FC&lt;Props> = ({ user }) => {
 return (
 &lt;div>
 &lt;img src={user.avatar ?? AVATAR_THUMBNAIL} />
 &lt;span>{user.name}&lt;/span>
 &lt;/div>
 );
}
</code></pre>
バグ修正ができたので、改めてテストを実行してみます。 
無事にテストが通りバグが修正されたのを確認できました！ ⸜(｡˃ ᵕ ˂ )⸝
<pre class="language-shell"><code class="language-shell">$ yarn jest src/components/UserBio.spec.tsx

 PASS src/components/UserBio.spec.tsx
 UserBio
 ✓ アバター画像が未設定のときにサムネイル画像を表示する (61 ms)
</code></pre>
<h3 id="ブラウザ不要の検証">ブラウザ不要の検証</h3>
今回のバグ修正ではコードを変更してバグが修正されたことを確認する過程全くブラウザを利用しませんでした。 
PR作成前に念の為のブラウザ確認はしますが、検証でブラウザ操作をするのはその1度だけに抑えることができます。
フロントエンドをTDDで開発するメリットの一つとしてこの検証の簡略化があります。 
フロントエンドで検証を進めるために何度もコードとブラウザを行き来してブラウザ操作をする事が多いですが、この実装途中におけるブラウザ操作が地味に面倒で開発コストとして発生します。
TDDでテストを先に書いて検証を自動化することで、この検証コストを減らして開発効率を上げられるメリットがあります。
<h2 id="さいごに">さいごに</h2>
今回は非常に簡単なバグ修正を例にフロントエンドでのTDDについて紹介しました。
TDDやテストを書くには、どんな簡単なモノでも良いのでたくさんテストを書いて経験を得ることが何より大事だと思います。
TDDで開発をしてみたいけどなかなか初めの一歩が踏み出せない場合は、今回のケースのようなすごく簡単な修正からテストを書き始めてみましょう。

この記事は YAMAP エンジニア Advent Calendar 2021 の22日目の記事です。現在、輪読会で「テスト駆動開発」（TDD）を読み進めています。本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。

バグ修正から始めるフロントエンドのTDD入門

この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の10日目の記事です。
<h2 id="はじめに">はじめに</h2>
コードレビュー難しいですよね。 
今年で6年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。
予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったり問題点を挙げればキリがありません。
コードレビューのことを考えるにあたり、自分が普段どんな感じでレビューしているか意識したことをがないなと思い、一度自分がレビュー時に意識していることを整理してみました。
<h2 id="仕様の把握">仕様の把握</h2>
コードレビューを始める時に自分が最初にやることは、修正内容の仕様の把握です。ここでいう仕様とは、「どういう場合にどういう状態になるか」を指しています。
コードレビューとは修正されたコードに問題がないかを客観的な目線でチェックする作業です。 
このとき、何が正しいか の基準が無いと問題が無いことを判断することはできないため、最初に何が正しいのか 知るためにも対象のPRでの仕様を理解することを意識しています。
<h3 id="概要欄を読み込む">概要欄を読み込む</h3>
チームでレビューをしていると、PRの概要欄には修正の目的などが記載されています。
まずは概要欄を読むことでざっくりと全体を把握できる事が多いので、最初に概要欄をしっかりと読むようにしています。（しっかり書かれている前提ですが）
<h3 id="ブラウザで動作確認">ブラウザで動作確認</h3>
修正内容を理解するために、ソースコードを読む前にブラウザで実際に動作確認をします。
先に実際に動かして確認をした方が理解を深めやすく、何をやっているかをイメージしながらコードリーディングができるので、コードレビューがやりやすくなります。
最初の動作確認で分からない点や気になった箇所があれば、そこだけピンポイントでコードを読んで仕様を理解するようにしています。この時にバグが見つかることも多々あります。
<h3 id="APIリクエストの仕様について">APIリクエストの仕様について</h3>
APIリクエストをしている場合はAPIレスポンスのデータ構造も意識的に確認するようにしています。 
フロントエンドはAPIのレスポンスデータを画面上に表示する事が主な役割なので、表示するデータの仕様を把握しないと正しくデータを扱えているかの判断が難しいためです。
外部APIのレスポンスでデータの意味が分からない場合は、念の為API仕様書でレスポンスの仕様を把握してレビューができると、予想外のバグが見つかったりします。
<h2 id="レビューの優先度">レビューの優先度</h2>
レビューをする時は自分の中で項目を分けて優先度を付けてレビューをしています。
<ol>
<li>バグ・デグレが発生しないか</li>
<li>セキュリティは問題ないか</li>
<li>変更は容易か（設計）</li>
<li>コードは読みやすいか</li>
</ol>
レビュー項目を分けて優先度を付けておくと、PRの内容に応じてレビューにかける時間配分をコントロールできるようになります。
<ul>
<li>コードレビューをする時間が少ない場合は最低限 2 まではしっかり確認して 3,4 にかける時間を短くする。</li>
<li>今後も変更が多い重要な機能は、多少を時間をかけてでも全ての項目について細かく確認する。</li>
</ul>
<h2 id="重点的に見る箇所">重点的に見る箇所</h2>
<ul>
<li>サービスとして重要な機能やお金が絡む部分</li>
<li>XSSなどのセキュリティバグが発生しやすい部分
<ul>
<li>クエリパラメーターを内部で参照する場合など</li>
</ul>
</li>
<li>多くの場所から参照されているファイル
<ul>
<li>共通ライブラリやコンポーネント</li>
</ul>
</li>
</ul>
<h2 id="バグ・デグレが発生しないか">バグ・デグレが発生しないか</h2>
<ul>
<li>意地悪な気持ちになって特殊な操作をしてみる</li>
<li>PC,スマホの両方のviewportでデザイン崩れが発生しないか</li>
<li>CSS, JS はサポートしているブラウザで利用可能か</li>
<li>ここら辺はESLintで自動テストをかけて、ある程度チェックを省略することもできます</li>
<li>条件分岐の条件は適切か</li>
<li>修正箇所を呼んでいる他の部分に影響がないか</li>
</ul>
<h3 id="バグ・デグレが発生やすい箇所">バグ・デグレが発生やすい箇所</h3>
次の箇所は経験的にバグ・デグレが発生しやすいので注意深くレビューをすることが多いです。
<ul>
<li>コードの可読性が低い部分</li>
<li>コードから実装者の意図が読み取れない箇所
<ul>
<li>裏側に複雑な仕様が隠れていることがあるので、デグレが発生しやすい</li>
</ul>
</li>
<li>データ構造が複雑な箇所
<ul>
<li>多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い</li>
</ul>
</li>
<li>条件分岐が複雑な箇所
<ul>
<li>多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い</li>
</ul>
</li>
<li>多くの箇所から参照されている部分
<ul>
<li>呼び出し元に応じた処理が1箇所に書かれて、処理が複雑になりやすい</li>
</ul>
</li>
<li>パッと見で特殊なことをやっている箇所
<ul>
<li>読んでいて普通だったらこんな実装しないなと感じる箇所は裏側に複雑な仕様が隠れていることがあるのでバグが発生しやすい</li>
</ul>
</li>
<li>なんかモヤモヤとした不安感を感じる箇所
<ul>
<li>モヤモヤの正体は経験則による直感であることが多く、過去に似た箇所でバグに遭遇したことがあったりするので、その直感は当たることが多い</li>
</ul>
</li>
</ul>
<h2 id="セキュリティに問題はないか">セキュリティに問題はないか</h2>
<ul>
<li>URLパラメーターなどユーザーが入力可能な値を参照している場合は、XSSなどに問題がないか</li>
<li>権限などで機能制限をしている場合は、ローカルプロキシなどでレスポンスを改竄して悪さできないか
<ul>
<li>レスポンスを改竄して制限をすり抜けられる場合は、それをやられた場合のサービスのリスクを考える</li>
</ul>
</li>
</ul>
<h2 id="変更は容易か（設計）">変更は容易か（設計）</h2>
<ul>
<li>発生する可能性のある仕様変更を想像して、その仕様変更に対して容易に対応可能か
<ul>
<li>仕様変更があった場合に複数箇所を修正する必要があると1箇所だけ修正を忘れてデグレが発生しやすい</li>
<li>修正時の影響範囲が多いとデグレが発生しやすい</li>
</ul>
</li>
<li>一つのファイルが責務を持ち過ぎていないか
<ul>
<li>1箇所で多くのことをしていると処理が複雑になりデグレが発生しやすい</li>
<li>修正時の影響範囲も把握がしづらくなる</li>
<li>修正時に考慮することが増えるので機能改修に時間がかかる</li>
</ul>
</li>
</ul>
<h2 id="コードの可読性">コードの可読性</h2>
<ul>
<li>1か月後の自分が同じコードを読んで理解できそうか</li>
<li>無駄に複雑に書かれていないか</li>
<li>変数名は誤解を生むような名前になっていないか</li>
<li>自分が実装する場合にどう実装するかをイメージする</li>
</ul>
<h2 id="レビューコメント">レビューコメント</h2>
<ul>
<li>可読性や設計を指摘する場合は、極力ダメな理由と改善案（サンプルコード）を一緒に提示する
<ul>
<li>一方的にダメと言われるとレビュイーも困りますし、気分が悪くなっちゃいます。</li>
</ul>
</li>
<li>ラベルをつける
<ul>
<li>レビュイーがコメントに対して優先度をつけて対応ができるので効率が上がります</li>
<li>FIX(バグ修正）, REFACTOR、COMMENT など</li>
<li><a href="https://qiita.com/godgarden/items/3ea57a7ee6dbff1df6e6" target="_blank">レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話 - Qiita</a></li>
</ul>
</li>
<li>絵文字やAAを使う
<ul>
<li>コードレビューは書いたコードに対して何かしらの指摘が発生する作業なので、ギスギスしてしまう可能性があります。</li>
<li>少しでもギスギスしないように絵文字やAAを使って雰囲気が柔らかくなるようにしています。</li>
</ul>
</li>
<li>良い点があれば Good なリアクションをする
<ul>
<li>褒められると嬉しい👍</li>
</ul>
</li>
<li>人を否定しない
<ul>
<li>こんなコードを書くなんて全然ダメだ！などと個人に対しての言及はダメ。ゼッタイ。</li>
<li>自分が言われたら辛い🥲</li>
</ul>
</li>
<li>宗教戦争になり得ると思った指摘はしない
<ul>
<li>ただ、宗教戦争になるかどうかの判断はかなり難しい</li>
<li>書き方の問題であれば、コーディング規約を決めてLinterでチェックできると良い</li>
<li>宗教戦争になりそうだと思ったら、「好みの問題かもしれないですが...」などと前置きをおいてお茶を濁す</li>
<li>COMMENT ラベル等でお気持ちの表明だけをする</li>
</ul>
</li>
</ul>
<h2 id="コードレビューを楽しむ🎉">コードレビューを楽しむ🎉</h2>
自分はコードレビューをゲーム感覚で実施することを心がけています。バグを見つけらたらレビュアーの勝ち！バグが無ければレビュイーの勝ち！という具合です。目標を持ってコードレビューをするとレビューをしていて楽しいですし、バグを見つけることに全力になります。
※ 勝ち負けは自分の中だけに留めておいてください。
<h2 id="参考資料">参考資料</h2>
丁寧にまとまっているので、併せて読んでみてください。
<ul>
<li><a href="https://engineering.mercari.com/blog/entry/2019-12-22-080000/" target="_blank">より良いコードレビューをするために気をつけていること | メルカリエンジニアリング</a></li>
<li><a href="https://qiita.com/awakia/items/8344ba751426e386e0f5" target="_blank">コードレビューの際に気をつけること - Qiita</a></li>
<li><a href="https://note.com/su_k/n/nf23ab5c6dba2" target="_blank">僕がコードレビューの時に気をつけていること｜su-｜note</a></li>
</ul>

この記事はYAMAP エンジニア Advent Calendar 2021 の10日目の記事です。コードレビュー難しいですよね。今年で6年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったりします。

僕がフロントエンドのコードレビューをする時に意識していること

初めてフロントエンドでコンポーネントのユニットテストを書く時に「何をテストするのか」が分からず、上手くテストが書けないという事があります。この記事ではコンポーネントの入力と出力を意識することでユニットテストで「何をテストするか」について、まとめています。

コンポーネントの入力と出力を意識してユニットテストを書いてみよう

複数行のテキストを <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について

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端末でのフォームの拡大表示に対応する

ESLintは毎回プロジェクト開始の最初だけ設定して、その後あまり触ることが無く毎回なんとなくで設定して、新しく設定する時に設定項目を忘れてしまう事が多いので、各設定項目や導入プラグインの目的をちゃんと理解したいと思い、まとめました。

ESLintをちゃんと理解する

<h2 id="はじめに">はじめに</h2>
年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。その影響でLighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-result.jpg" alt="改善前のLighthouseの結果" width="1522" height="676" />
<h2 id="原因調査">原因調査</h2>
<h3 id="Lighthouseの結果を考察">Lighthouseの結果を考察</h3>
Lighthouseの詳細を見てみると 722.4kb という巨大なJSファイルが配信されていました。「Potential Saving 99.8kb」とあるように、このJFファイルの中の大部分が未使用コードになっています。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-unused-js.png" alt="未使用なJavaScript" width="735" height="385" />
また巨大なjsファイルによりJavaScriptの「Script Evaluation」が 1,835ms と、長時間のレンダリングブロッキングが発生していました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-thread-work.png" alt="メインスレッドの実行時間" width="717" height="406" />
<h3 id="Webpack Bundle Analyzer">Webpack Bundle Analyzer</h3>
先ほどのLighthouseの結果で問題になっていた、巨大なjsファイルは chunks/pages/post/[slug]-xxx.js でした。これは記事の詳細ページでNext.jsのビルドにより生成されたファイルです。このファイルにバンドルされているモジュールを調査して、jsファイルが巨大化している原因を特定します。
Next.jsは内部でビルドにWebpackを利用しているので、<a href="https://github.com/webpack-contrib/webpack-bundle-analyzer" target="_blank">webpack-contrib/webpack-bundle-analyzer</a> を使うことで、生成されたJSファイルのバンドル情報を可視化することができます。
Next.js のプラグインとして <a href="https://github.com/vercel/next.js/tree/canary/packages/next-bundle-analyzer" target="_blank">@next/bundle-analyzer</a> が提供されているので、今回はこちらを導入していきます。
最初にパッケージをインストールします。
<pre class="language-bash"><code class="language-bash">$ yarn add -D @next/bundel-analyzer
</code></pre>
続いて Next.config.js にプラグインを利用する設定を書いていきます。 
環境変数として <code>ANALYZE=true</code> が指定されていた時だけ、bundle-analyzer を実行するようにしています。
<pre class="language-javascript"><code class="language-javascript">const withBundleAnalyzer = require('@next/bundle-analyzer')({
 enabled: process.env.ANALYZE === 'true',
});

const config = {
 // 省略
};

module.exports = withBundleAnalyzer(config);
</code></pre>
次のように実行することで確認ができます。
<pre class="language-bash"><code class="language-bash">$ ANALYZE=true next build
</code></pre>
今後のことも考えて実行コマンドは package.json に登録しておきます。
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "bundle-analyzer": "ANALYZE=true next build"
 }
}
</code></pre>
<h3 id="Webpack Bundle Analyzer の結果を考察">Webpack Bundle Analyzer の結果を考察</h3>
webpack-bundle-analyzer を実行することで、ビルド中にブラウザに可視化された情報が表示されます。 
可視化された結果をみてみると <a href="https://github.com/wooorm/refractor" target="_blank">refractor</a> というモジュールが大部分を占めており、このモジュールの読み込みが今回の問題の原因となっていそうです。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png" alt="bundle-analyzerの結果" width="2876" height="1532" />
<code>yarn.lock</code> を参照すると、 <code>refractor</code> は <a href="https://github.com/react-syntax-highlighter/react-syntax-highlighter" target="_blank">react-syntax-highlighter/react-syntax-highlighter</a> から読み込まれていることが分かりました。
<pre class="language-yaml"><code class="language-yaml">react-syntax-highlighter@^15.4.3:
 version "15.4.3"
 resolved "https://registry.yarnpkg.com/react-syntax-highlighter/-/react-syntax-highlighter-15.4.3.tgz#fffe3286677ac470b963b364916d16374996f3a6"
 integrity sha512-TnhGgZKXr5o8a63uYdRTzeb8ijJOgRGe0qjrE0eK/gajtdyqnSO6LqB3vW16hHB0cFierYSoy/AOJw8z1Dui8g==
 dependencies:
 "@babel/runtime" "^7.3.1"
 highlight.js "^10.4.1"
 lowlight "^1.17.0"
 prismjs "^1.22.0"
 refractor "^3.2.0"
</code></pre>
これでパフォーマンス問題の原因が特定できたので、残りはこの問題を改修していきます。
<h2 id="パフォーマンス改善">パフォーマンス改善</h2>
<code>reflactor</code> には、シンタックスハイライトで利用する言語ごとのjsファイルが含まれており、それらが初回レンダリングのタイミングで全て読み込まれることで、パフォーマンス低下を引き起こしていました。<code>react-syntax-highlighter</code> は動的インポートにも対応しているので、今回は動的インポートによりレンダリングブロックをしないように修正をします。
ただ、最終的に読み込むファイルの転送量が多いことに変わりないので、将来的には別のアプローチで解決したいです。
<pre class="language-typescript"><code class="language-typescript">// import { Prism as SyntaxHilighter } from 'react-syntax-highlighter';
import { PrismAsync as SyntaxHilighter } from 'react-syntax-highlighter';
</code></pre>
動的インポートに変更した後の bundle anlyzer の結果をみると、 <code>refractor-import.xxx.js</code> として <code>refractor</code> の読み込みが新しいチャンクとして切り出されています。<code>[slug]-xxx.js</code> のファイルサイズ も 722.4kb から 216.54kb に削減されています。
<img src="/images/posts/nextjs-perf-improvement/dynamic-import-bundle-analyzer-result.png" alt="動的インポートのbundle-analyzerの結果" width="1514" height="1356" />
修正後の <code>[slug]-xxx.js</code> の中身を見てみると、新たに別の問題が見えてきました。<code>react-syntax-highlighter</code>が全てのテーマファイルを読み込んでいます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result-slug.png" alt="[slug]-xxx.jsのbundle-analyzerの結果" width="2876" height="1530" />
この読み込みも不要なので、必要なテーマファイルだけを読み込むように修正します。
<pre class="language-typescript"><code class="language-typescript">// import { vscDarkPlus as defaultVscDarkPlus } from 'react-syntax-highlighter/dist/cjs/styles/prism';
import defaultVscDarkPlus from 'react-syntax-highlighter/dist/cjs/styles/prism/vsc-dark-plus';
</code></pre>
最終的に <code>[slug]-xxx.js</code> のファイルサイズが 722.kb から 106.5kb と1/7のサイズ削減できました🎉 
これでレンダリングブロッキングの時間が大幅に削減されるので、Ligthouseのパフォーマンス結果も改善されます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-finally.png" alt="最終的なbundle-analyzerの結果" width="1698" height="1492" />
<h2 id="さいごに">さいごに</h2>
今回は1番大きな問題を対象として改善策を実施しましたが、画像の最適化や画像の遅延ロード、その他の不要なJavaScriptファイルの削除と改善項目はまだまだ沢山あります。また、Next.jsのリプレースによって新しく導入したライブラリにより意図せずにパフォーマンス低下が起きてしまったので、今後は <a href="https://github.com/GoogleChrome/lighthouse-ci" target="_blank">GoogleChrome/lighthouse-ci</a> などを導入して継続的にパフォーマンスなどを計測する仕組みを用意していきたいです。

年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。レプレースを実施した結果、Lighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。

Next.jsで作ったブログのパフォーマンス改善

<img src="/images/posts/wasm-othello/wasm-othello.png" alt="wasm-othello" width="1466" height="1488" />
この記事は <a href="https://qiita.com/advent-calendar/2020/hamee" target="_blank">Hamee Advent Calendar 2020</a> の3日目の記事です。
↓のURLからオセロが遊べるので、ぜひ遊んでみてください！ 
<a href="https://wasm-othello.t-yng.jp/" target="_blank">https://wasm-othello.t-yng.jp/</a>
最上位のレベル6は普通に強いです！CPUのアルゴリズムは自分の普段の思考をベースにしているので、レベル6に勝てない人はリアルで僕とオセロをやっても勝てないレベルです。(多分)
全体のソースコードは <a href="https://github.com/t-yng/wasm-othello" target="_blank">t-yng/wasm-othello</a> に置いてあります。
実装したのは2020年3月頃とかなり前なのですが供養も兼ねて記事にまとめました。 
余談ですが、もうすぐ令和2年が終わるという事実に衝撃を受けながら、この記事を書いています。
<h2 id="はじめに">はじめに</h2>
ブラウザでのWebAssemblyの処理速度がJavaScriptと比較してどれだけ向上するのかを体感したく、オセロのCPUをTypeScriptとWebAssemblyで実装して速度比較をしてみました。
WebAssemblyの実装にはRustを利用しています。Rustを選択した理由は自分がRustを書きたかったのが一番の理由ですが、Rustは言語の仕組みとしてガベージコレクションを持たないため、.wasm にコンパイルしたバイナリコードを軽量化できる特徴があります。
<h2 id="WebAssemblyとは？">WebAssemblyとは？</h2>
<blockquote>
WebAssemblyは、ウェブブラウザのクライアントサイドスクリプトとして動作するプログラミング言語（低水準言語）である。wasmとも称されており、ブラウザ上でバイナリフォーマットの形で実行可能であることを特徴とする。
<a href="https://ja.wikipedia.org/wiki/WebAssembly" target="_blank">WebAssembly - Wikipedia</a>
</blockquote>
バイナリ形式で実行されるので、JavaScriptと比較してより高速な処理速度が実現できます。RustやC/C++やTypeScriptなどの言語からコンパイルできるため、WebフロントエンドのビジネスロジックをJavaScript以外の言語で記述することができるのも一つの特徴です。
<h2 id="WebAssemblyを利用した動作イメージ">WebAssemblyを利用した動作イメージ</h2>
最善手を探索するビジネスロジック部分をRustで実装・コンパイルして .wasm 形式のバイナリコードを出力します。このファイルをJavaScriptファイルを同じ要領で配信して、ブラウザ上で読み込ます。JavaScriptからwasmのバイナリコードを呼び出すことで、一部のビジネスロジックをWebAssemblyで実行できます。
<img src="/images/posts/wasm-othello/wasm.png" alt="WebAssemblyを利用したイメージ図" width="758" height="652" />
<h2 id="ミニマックス法を用いたCPUの実装">ミニマックス法を用いたCPUの実装</h2>
ミニマックス法とは、オセロや将棋などのゲームアルゴリズムを実装する時に利用される事の多い探索手法の一つです。評価関数を用いて盤面の評価値を計算して、自分の手番では評価値が最大となり、相手の手番では評価値が最小となる最善手を選択するアルゴリズムです。
例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のためにAとBの2箇所に絞って探索を行い、2手先までを探索してみます。
<img src="/images/posts/wasm-othello/board.png" alt="盤面" width="401" height="401" />
相手は常に最前手を打つと予測するので、Aを打った場合は最大評価値は100となる位置に石を置いてきます。これに対してBに打った場合は最大評価値は15の位置に石を置いてきます。ここではBに打った方が自分が有利なので、Bを最善手として決定します。
<img src="/images/posts/wasm-othello/board_select_A.png" alt="Aに打った場合" width="860" height="558" />
<img src="/images/posts/wasm-othello/board_select_B.png" alt="Bに打った場合" width="860" height="528" />
このアルゴリズムではよりN手先を探索する方が精度が上がり最善手の精度が高くなります。しかし、探索の深さが増えるほどに探索範囲が爆発的に増えて計算時間が膨大になるため、ある一定の深さで探索を打ち切るという事をします。逆に言えば、処理速度を向上させればそれだけ探索範囲を深くできるためCPUを強くすることができます。
今回のオセロではCPUのレベルを探索の深さと合わせてあるため、レベルを上げるほど探索範囲が増大してCPUの計算時間が処理速度に依存するようになっています。
ミニマックス法は参考となるサイトが沢山あるので、詳細はそちらを参照してください。
<ul>
<li><a href="https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9%E6%B3%95" target="_blank">ミニマックス法 - Wikipedia</a></li>
<li><a href="https://www.webcyou.com/?p=6997" target="_blank">web帳 | 5分で覚えるAI Minimax（ミニマックス）法とalpha-beta法</a></li>
</ul>
実装したオセロのアルゴリズムでは次の評価ルールに基づいて評価関数を実装しました。
<ul>
<li>中盤までは相手の石が多い方が評価値を高くする</li>
<li>後半は自分の石が多い方が評価値を高くする</li>
<li>自分の石が角にある +500</li>
<li>相手の石が角にある - 500</li>
<li>自分の石が角の上下にある -30</li>
<li>相手の石が角の上下にある +30</li>
<li>自分の石が角の斜めにある -100</li>
<li>相手の石が角の斜めにある +100</li>
</ul>
<h2 id="速度結果">速度結果</h2>
TypeScript実装とWebAssembly（Rust実装）での処理速度をグラフで可視化してみました。
<img src="/images/posts/wasm-othello/speed.png" alt="処理速度のグラフ" width="1946" height="1122" />
盤面によっては7~8倍ぐらいの速度差が出ておりWebAssemblyの速度に驚きました。
<h2 id="さいごに">さいごに</h2>
オセロを実装したのは6月ぐらいだと思っていたのですが、実際は3月頃で想像以上の月日の流れの速さに驚きました。Rustで実装してみると所有権やライフタイムなど自分の知らない新しい概念が出てきて面白かったです。
Rustの所有権については、<a href="https://t-yng.jp/posts/rust-ownership/" target="_blank">Rustの所有権と借用を理解する</a>でまとめているので、興味があったら読んでみてください。

WebAssemblyの速度を体感するために、WebAssemblyでオセロのゲームアルゴリズムを実装しました

WebAssemblyでオセロを作った話

GatsbyJSで認証サイトを実装するチュートリアルをやった時のまとめです。

GatsbyJSで認証サイトを実装する

Mateial-UI + webpackの環境で開発を進めている時に、ある時から突然ビルドに時間がかかるようになりました。 
最初は、開発を進めていてファイル数が増えたからビルド時間が増えたのかなと思っていたのですが、それを理由にするには、時間がかかり過ぎていました。
改善のために、調査を進めると Material-UI のアイコン読み込みが原因であることが分かりました。
<h2 id="問題">問題</h2>
問題のコードでは次のようにアイコンを読み込んでいました。
<pre><code>import { AccountCircle } from &quot;@material-ui/icons&quot;;
</code></pre>
上記のパッケージ読み込みをしている1ファイルだけを対象にwebpackでビルドした時のパフォーマンスを計測してみると、1ファイルをビルドをするのに20sほどかかっていました。
※ <a href="https://github.com/stephencookdev/speed-measure-webpack-plugin" target="_blank">speed-measure-webpack-plugin</a> で計測
<pre><code>$ webpack

 SMP ⏱
General output time took 21.63 secs

 SMP ⏱ Loaders
modules with no loaders took 7.4 secs
 module count = 5702
ts-loader took 4.96 secs
 module count = 3

...

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets:
 bundle.js (2.16 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
 main (2.16 MiB)
 bundle.js

WARNING in webpack performance recommendations:
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/
✨ Done in 23.36s.
</code></pre>
<h2 id="原因">原因</h2>
これは不要なファイルを大量に読み込んでいる事が原因でした。
<code>@material-ui/icons/index.js</code>の実装を見てみると、で各アイコンのファイルをrequireしているため、上記のパッケージ読み込みの方法だと、1000個近いアイコンファイルを全て読み込む状態になっていました。
<pre><code>var _AccountCircle = _interopRequireDefault(require(&quot;./AccountCircle&quot;));

var _AccountCircleOutlined = _interopRequireDefault(require(&quot;./AccountCircleOutlined&quot;));
</code></pre>
<h2 id="解決策">解決策</h2>
解決策としてはシンプルに特定アイコンファイルだけ読み込むように修正すればOKです。
<pre><code>import AccountCircle from &quot;@material-ui/icons/AccountCircle&quot;;
</code></pre>
修正版のwebpackのビルド時間を見てみると、無事にパフォーマンスが改善されており、バンドルサイズについても発生していた Warning も消えてくれてました。
<pre><code>$ webpack

 SMP ⏱
General output time took 6.3 secs

 SMP ⏱ Loaders
ts-loader took 5.47 secs
 module count = 3
modules with no loaders took 1.81 secs
 module count = 160

...

✨ Done in 7.69s.
</code></pre>
<h2 id="参考">参考</h2>
<a href="https://dev.to/janpauldahlke/how-to-improve-material-ui-speed-in-react-typescript-1199" target="_blank">How to improve the build speed in React-Typescript, when using material ui - DEV</a>

Mateial-UI + webpack の環境でアイコンのパッケージ読み込み方法がビルド時間に影響する問題について紹介しています。

Material-UI + webpack のアイコン読み込みでハマった

Next.jsでブラウザの Storage オブジェクト を使う時の対応策をまとめています。

Next.jsでStorageオブジェクトを使う

JavaScriptで小数点の桁数を指定してフォーマット表示するには、 <code>toFixed()</code> メソッドを使用します。
<a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed" target="_blank">Number.prototype.toFixed() - JavaScript | MDN</a>
<pre class="language-js"><code class="language-js">const number = 12.3456789; 
console.log(seconds.toFixed()) // 1 : 近似値で表現され、引数省略した場合は少数点の桁数は0。
console.log(milliseconds.toFixed(2)) // 12.35 : 近似値で表現される
</code></pre>
個人的な利用ケースとして、パフォーマンス計測で処理時間を表示する時に使うことが多いです。
<pre class="language-js"><code class="language-js">const start = performance.now();
// 何かしらの処理
const end = performance.now();

const seconds = ((start - end) / 1000).toFixed(2);
console.log('処理時間: ', seconds, 's'); // 1.23s 
</code></pre>

JavaScriptで小数点の桁数を指定してフォーマットする方法です。

JavaScriptで小数点の桁数を指定してフォーマット表示

前に Ajax でフォームの送信をする時に form と div どちらを使うのが良いのか？という質問をされました。質問の意図としては、form タグで実装した場合は送信イベントを止めるために <code>preventDefault()</code> を呼ぶ必要があり、この処理を毎回呼ぶのが面倒なので挙動が変わらないなら div タグ の方が良いのでないか？という話でした。
結論だけ先に書いておくと form タグを使おう です。
div タグでの実装例
<pre class="language-html"><code class="language-html">&lt;script>
 const button = document.getElementById('send');
 button.addEventListener('click', () => {
 // inputの値を取得してデータバリデーションとかする
 fetch(...);
 });
&lt;/script>

&lt;div id="form">
 &lt;input type="text" id="name" />
 &lt;div>
 &lt;button id="send">send&lt;/button>
 &lt;/div>
&lt;/div>
</code></pre>
form タグでの実装例
<pre class="language-html"><code class="language-html">&lt;script>
 const form = document.getElementById('form');
 form.addEventListener('submit', (event) => {
 event.preventDefault();
 // inputの値を取得してデータバリデーションとかする
 fetch(...);
 });
&lt;/script>

&lt;form id="form">
 &lt;input type="text" id="name" />
 &lt;div>
 &lt;button type="submit" id="send">send&lt;/button>
 &lt;/div>
&lt;/form>
</code></pre>
<h2 id="form タグと div タグの違い">form タグと div タグの違い</h2>
form タグで実装した場合は以下の挙動がブラウザのデフォルトとして動作します。
<ol>
<li>キーボードの Enter を押してリクエストの送信ができる</li>
<li>type=&quot;password&quot; を含むフォームの送信が成功したら、ブラウザのパスワード保存を自動で確認してくれる</li>
</ol>
div タグで実装した場合はこれらを自前で実装する工数が発生します。
<ol>
<li>Enter キーのイベントを監視してコールバックを登録する。</li>
<li>ブラウザのパスワード保存の確認は API 経由で出来るのか不明</li>
</ol>
特に 2 つめのパスワード保存については、簡単に調べた感じだと API が提供されていないので、対応ができない可能性が高い気がします。 
このようにブラウザのデフォルトの挙動を考えると、フォームを div タグ で実装するメリットはあまりなく、特別な理由が無ければ素直に form タグ で実装しておいた方が良いです。

フォーム実装にformタグを使うかdivタグを使うか

Rust は所有権の機能を導入することでガベージコレクションを実装せずにメモリ安全を実現しています。これを理解しないとコンパイルエラーが発生した時になぜエラーなのかを把握するのか困難になるので、Rust を使う上で重要な概念です。
ドキュメントなどを読み概要が把握できたので、整理のために説明を書いていきます。
<h2 id="所有権の特徴">所有権の特徴</h2>
現在のプログラムにおける一般的なメモリの管理方法は大きく分けて二つあります。 
一つは C や C++のようにプログラマが自分でメモリの確保と開放を宣言するやり方、二つ目は Java や Go のようにベージコレクションによって定期的に不要なメモリを開放する方法です。 
一つ目の方法ではプログラマが常にメモリを意識して開発する必要があり非常にコストがかかり、メモリ管理を誤った場合にダングリングポインタやメモリ 2 重開放などでエラーが発生する危険性があります。また、二つ目の方法では定期的に実行されれるガベージコレクターがアプリケーションの動作の妨げになる事があります。
Rust では所有権システムに基づいてコンパイラがコンパイル時にメモリ安全性のチェックを行うことで、ガベージコレクションを組み込む事なく自動でメモリ安全性を保証しています。
<h3 id="所有権規則">所有権規則</h3>
所有権システムは次の規則を持っています。
<ul>
<li>規則 1: 値は所有者と呼ばれる変数と対応している</li>
<li>規則 2: 値を所有できる変数は必ず一つだけである</li>
<li>規則 3: 値を所有する変数がスコープを抜けたら、値は破棄される</li>
</ul>
<h3 id="メモリと変数スコープ">メモリと変数スコープ</h3>
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello"); // ここで
 println!("{}", s1);
} // ここでs1がスコープから抜けるので "hello" の値も破棄される
</code></pre>
ここで登場している String 型 は可変の値なので、コンパイル時にサイズを決定する事ができないので、値はヒープ領域に配置されます。 
このとき「値を所有する変数がスコープを抜けたら、値は破棄される」の規則に則り、s1 がスコープから抜ける時に、&quot;hello&quot; のメモリ解放がされます。
<img src="/images/posts/rust-ownership/memory1.png" alt="memory1" width="524" height="372" />
<h3 id="所有権のムーブ">所有権のムーブ</h3>
次に、変数を別の変数に代入した場合のメモリの状態を考えてみます。
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello");
 let s2 = s1;
}
</code></pre>
この状態で先ほどと同じようにメモリの解放を考えてみます。最初に s2 がスコープから抜けるタイミングで、&quot;hello&quot; のメモリが解放されます。次に s1 がスコープから外れるので同じようにメモリを解放します。 
ちょっと待ってください、ここで問題が発生しました！ 
&quot;hello&quot; のメモリは既に解放されているため、s1 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。

しかし、対象のコードはコンパイルに成功して正常に実行されます。 
なぜでしょうか？
ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は <code>let s2 = s1;</code> の部分で &quot;hello&quot; の所有権が s1 から s2 へ移動しており、s1 は値を所有しておらず変数として無効となっているのです。そのため、Rust は s1 がスコープから抜けるタイミングでメモリ解放をする必要がなくなり、結果として s2 に対してのみメモリ解放が実行されるため、正常に動作します。
この、値を所有する変数が移動することを 所有権のムーブ といいます。
<img src="/images/posts/rust-ownership/move_ownership.png" alt="move_ownership" width="524" height="372" />
この仕組みを考えると、例えば、次のコードはどうなるのでしょうか？
<pre class="language-rust"><code class="language-rust">fn main() {
 let s1 = String::from("hello");
 let s2 = s1;
 -- value moved here
 println!("{}", s1);
 ^^ value borrowed here after move
}
</code></pre>
このコードはコンパイルエラーになります。&quot;hello&quot; の所有権が s1 から s2 にムーブしており、既に無効となっている s1 を使おうとしているためコンパイルエラーになるのです。
また所有権のムーブは関数に値を渡す場合も同様に発生します。
<pre class="language-rust"><code class="language-rust">fn hello(s: String) {
 println!("hello! {}", s);
}

fn main() {
 let name = String::from("taro");
 hello(name);
 ---- value moved here
 println!("{}", name);
 ^^^^ value borrowed here after move
}
</code></pre>
<h3 id="借用">借用</h3>
それでは、先ほどの例で関数に値を渡したい時はどうすればいいのでしょうか？ 
この問題は 借用 を使う事で解決できます。借用は <code>&amp;</code> を使って表現します。
<pre class="language-rust"><code class="language-rust">fn hello(s: &amp;String) {
 println!("hello! {}", s);
}

fn main() {
 let name = String::from("taro");
 hello(&amp;name);
 println!("{}", name);
}
</code></pre>
借用は name への参照を作成し、これを所有しません。つまり、s は所有権を持たないのでスコープを抜けてもメモリ解放は実行されず、name がスコープを抜けたタイミングでメモリ解放が実行されます。 
これは、コンパイラに対して「s は値を借りているだけなので、スコープを抜けてもメモリの解放をする必要がないよ」と教えているのです。
メモリ状態を表現すると次のようになります。
<img src="/images/posts/rust-ownership/memory3.png" alt="memory3" width="742" height="372" />
この借用を用いることで、所有権をムーブさせずに値を参照することができます。
<h2 id="参考">参考</h2>
<ul>
<li><a href="https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html" target="_blank">What is Ownership? - The Rust Programming Language</a></li>
<li><a href="https://doc.rust-jp.rs/book/second-edition/ch04-01-what-is-ownership.html" target="_blank">所有権とは？ - The Rust Programming Language</a> （公式の日本語翻訳）</li>
</ul>
<h2 id="まとめ">まとめ</h2>
Rust の所有権と借用の仕組みは理解するのに、かなり時間がかかりました。理解すると意外とシンプルな考えなんだなと感じました。 
この記事は参考ドキュメントで理解した事を自分用に噛み砕いて書いただけなので、詳しい説明はドキュメントを読んだ方が良いです。

Rustの所有権と借用を理解する

フロントエンド実装においてセキュリティを考慮する際に意識した方が良いHTTPレスポンスヘッダーについてまとめています。
<h2 id="X-Powered-By">X-Powered-By</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
サーバー側で利用しているフレームワークやバージョン情報を含むHTTPヘッダー
<pre><code>例: 
X-Powered-By: Next.js
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
サーバー側で利用されているフレームワークやバージョンが含まれているため、他に脆弱性が存在した場合に攻撃者に攻撃を助ける情報を与える可能性がある。
<h3 id="対策方法">対策方法</h3>
サーバー側で X-Powered-By ヘッダーを出力しないように設定する。
<h2 id="X-Runtime">X-Runtime</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
サーバーの応答時間を含むHTTPヘッダー
<pre><code>例: 
X-Runtime: 0.094235
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
タイミング攻撃（Timing Atacking）に利用される可能性がある。
<h3 id="タイミング攻撃">タイミング攻撃</h3>
サーバーの応答時間の違いを利用する事でサービスを分析する攻撃手法です。 
例えば、次のようにログイン処理が実装されていたとします。
<pre class="language-typescript"><code class="language-typescript">const login = (user_name, password) => {
 const user = User.get(user_name);
 if (user == null) return res.send(400);

 // 登録済みのユーザー名の場合はパスワードチェク処理が実行される分だけ応答時間が長くなる
 const mached = user.matchPassword(password);
 if (matched) res.send(200);
 else res.send(400);
}
</code></pre>
この時、ユーザー名がサービスに登録済みの場合はパスワードチェック処理が追加で実行される影響で応答時間が少し長くなるため、攻撃者はランダムなユーザー名でリクエストを送信して X-Runtime の応答時間の違いを比較することで、サービスに登録済みのユーザー名を特定する事ができます。
<pre><code># 未登録のユーザー名の場合
X-Runtime: 0.3949

# 登録済みのユーザー名の場合
X-Runtime: 0.6421
</code></pre>
参考: <a href="https://www.virtuesecurity.com/kb/x-runtime-header-timing-attacks/" target="_blank">X-Runtime Header Timing Attacks - Virtue Security</a>
<h3 id="対策方法">対策方法</h3>
X-Runtime ヘッダーを出力しないように設定する。
<h2 id="Cache-Control">Cache-Control</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
キャッシュの生存期間や保存可否などを制御するHTTPヘッダー 
HTTPレスポンスヘッダーとして指定された場合は、サーバーからのレスポンスを Cache-Control の指定に基づいて制御する。
<pre><code>例 画像などを1日キャッシュする
Chach-Control: max-age=86400
</code></pre>
<h3 id="脆弱性">脆弱性</h3>
ブラウザは何の指定も無い場合はデフォルトでサーバーレスポンスを可能な場合にキャッシュします。 
この時サーバーレスポンスにユーザーのパスワード情報などが含まれていた場合に、何らの方法で攻撃者がユーザーの物理マシンにアクセス可能な状態であれば、マシンに保存されているブラウザキャッシュなどからパスワード情報を盗み出される可能性がある。
<h3 id="対策方法">対策方法</h3>
Cache-Control を指定して、扱う情報に応じた適切なキャッシュ制御を行う。 
例えば、ユーザーの端末に保存するべきでない情報を含む場合は <code>nostore</code> を指定してキャッシュを保存しないようにする。
<pre><code>Cache-Control: nostore
</code></pre>
<h2 id="X-Frame-Options">X-Frame-Options</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options" target="_blank">X-Frame-Options - HTTP | MDN</a>
ブラウザが自分のWebページを &lt;iframe&gt; や &lt;object&gt; の中へ表示することを禁止することで、Webページが他のサイトに埋め込まれないことを保証することができます。
<h3 id="脆弱性の説明">脆弱性の説明</h3>
適切に設定していない場合にクリックジャッキング攻撃に利用される可能性がある。
<h3 id="クリックジャッキング攻撃">クリックジャッキング攻撃</h3>
外部ページを埋め込んだiframeを透明化して通常のWebページの上に被せることで、攻撃者がユーザーに意図しない操作をさせる攻撃手法です。
例えば、次の要件を満たすようなサービスをユーザーが利用しているとします。
<pre><code>1. ログイン情報をCookieで管理している
2. same-site属性はnone
3. アカウント画面の削除ボタンを押すだけで確認なしでアカウントが削除できる
</code></pre>
このとき対象サービスのアカウントページをiframeに埋め込み透明化した状態でWebページの上に重ねた場合、ユーザーがログイン済みであればユーザーのアカウントページが透明な状態で上に重なって表示されます。 
対象サービスの削除ボタンに重なる位置にクリックしたくなるようなリンクを配置することで、ユーザーに削除ボタンをクリックさせて、アカウントを削除するように誘導する事ができます。
<h3 id="対策方法">対策方法</h3>
<code>X-Frame-Options: Deny</code> を指定する事で iframe 等へのページの埋め込みを禁止する。
<h2 id="Content-Security-Policy（CSP）">Content-Security-Policy（CSP）</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/CSP" target="_blank">コンテンツセキュリティポリシー (CSP) - HTTP | MDN</a>
インラインスクリプトの実行を禁止してXSSなどの攻撃を軽減する事ができます。
例えば、次のようにHTTPレスポンスヘッダーに含める事で、掲示板のサービスなどでサニタイズ処理をせず任意の文字列をサービスに埋め込める脆弱性があった場合でも、インラインスクリプトの実行ができないためXSS攻撃を軽減する事ができます。
<pre><code># 外部ドメインのファイル読み込みやインラインスクリプトの実行を禁止する
Content-Security-Policy: default-src 'self'
</code></pre>
IEは CSPの sandbox ディレクティブのみが利用可能になっており、IE9以下は CSP 未対応なので、次に紹介する X-XSS-Protection を利用する必要があります。
詳しい設定は上記のMDNのリンクを参照してください。
<h3 id="脆弱性の説明">脆弱性の説明</h3>
掲示板などでユーザーが入力した値をサニタイズせずに画面上に表示していた場合にXSS攻撃を仕込まれる可能性がある。
<h3 id="注意点">注意点</h3>
外部ドメインからのスクリプト読み込みを禁止した場合に、CDN経由でのライブラリ読み込みなどが出来なくなってしまいます。 
そのため、自身のサービスの特性に合わせて適切に設定する必要があります。
例えば、次の設定をする事で自身のドメインと特定ドメインの CDN からのみスクリプト読み込みを許可する事ができます。
<pre><code>Content-Security-Policy: default-src 'self' cdnjs.cloudflare.com
</code></pre>
<h3 id="対策方法">対策方法</h3>
Content-Security-Policyを適切に設定する。
※ CSPの設定とは別でユーザーが入力した値を表示する箇所で適切にサニタイズ処理はするべきです。
<h2 id="X-XSS-Protection">X-XSS-Protection</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
ブラウザがXSS攻撃を検出した時にページの読み込みを自動で停止します。
CSPが厳しく設定済みであれば、このヘッダーは本来不要です。 
しかし、ユーザーがCSPに未対応の古いブラウザ（IE9以下）を利用している場合に有効な対策になります。
<h2 id="Strict-Transport-Security">Strict-Transport-Security</h2>
<h3 id="ヘッダーの説明">ヘッダーの説明</h3>
<a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security" target="_blank">Strict-Transport-Security - HTTP | MDN</a>
HTTPS でページにアクセスした時にHTTPレスポンスヘッダーに含めることで、次回以降はブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示する事ができます。
初めてのユーザーが HTTP でページにアクセスした場合は Strict-Transport-Security 無視されるため、ユーザーが HTTPS アクセスを一度もしていない場合には有効でない事に注意してください。 
HTTPS アクセスをしてSSL証明書が確認されたタイミングで設定が有効になります。
<pre><code># HTTPSアクセスの設定を1年間有効にする（有効期限はアクセスの度に更新される）
Strict-Transport-Security: max-age=31536000;
</code></pre>
<h3 id="脆弱性の説明">脆弱性の説明</h3>
HTTPアクセスが許可されている銀行サイトを普段から利用していたとします。 
カフェで無料のWifiに接続した状態で、その銀行サイトをHTTP経由で利用をしてしまった場合に、攻撃者にHTTPリクエストの内容を傍受され銀行口座やログイン情報などが盗まれる可能性があります。
<h3 id="対策方法">対策方法</h3>
Strict-Transport-Security ヘッダーを指定する。
上の例では、もし銀行サイトが Security-Transport-Security を設定しており、一度でも HTTPS で銀行サイトにアクセスしていた場合には、誤ってHTTPアクスした場合でも HTTPS 経由で自動で接続されるため被害を防ぐことができます。

WebセキュリティのためのHTTPレスポンスヘッダー

アクセス解析をするためにブログにGoogleアナリティクスを導入しました。 
今後イベント取得の度に、リリースをするのは面倒なので、Googleタグマネージャーを設定して、アナリティクスの計測を設定しています。
今回はGatsby製のブログにGoogleタグマネージャーを設定する方法をまとめておきます。
<h2 id="Googleタグマネージャーのコンテナ作成">Googleタグマネージャーのコンテナ作成</h2>
最初にGoogleタグマネージャーのコンテナを作成しておきます。
<img src="/images/posts/gatsbyjs-gtm/gtm-container-new.png" alt="コンテナの作成" width="714" height="619" />
<h2 id="Googleアナリティクスの設定">Googleアナリティクスの設定</h2>
管理 &gt; +プロパティを作成 から新たに計測用のプロパティを作成しておきます。
<h2 id="プラグインの追加">プラグインの追加</h2>
<h3 id="gatsby-plugin-google-tagmanager">gatsby-plugin-google-tagmanager</h3>
<a href="https://www.gatsbyjs.org/packages/gatsby-plugin-google-tagmanager/" target="_blank">gatsby-plugin-google-tagmanager</a> を利用してGoogleタグマネージャーをページに埋め込みます。 
（&lt;head&gt;タグに直接&lt;script&gt;タグを埋め込む方法がが分からず、公式のプラグインがあったので利用しました。）
<h3 id="インストール">インストール</h3>
<pre class="language-bash"><code class="language-bash">$ yarn add gatsby-plugin-google-tagmanager
</code></pre>
gastby-config.js にプラグインの設定を追記します。
<pre class="language-javascript"><code class="language-javascript">{
 resolve: `gatsby-plugin-google-tagmanager`,
 options: {
 id: `GTM-5MKNQWX`,

 // Include GTM in development.
 // Defaults to false meaning GTM will only be loaded in production.
 includeInDevelopment: false,

 // datalayer to be set before GTM is loaded
 // should be an object or a function that is executed in the browser
 // Defaults to null
 defaultDataLayer: { platform: "gatsby" },

 // Specify optional GTM environment details.
 gtmAuth: "xNwDtuXDGlgZTO1P8TF2cg",
 gtmPreview: "env-1",
 dataLayerName: 'dataLayer',
 }
}
</code></pre>
設定する値は 管理 &gt; Live（公開中）&gt; コードを取得 の埋め込みコードから確認することができます。
<img src="/images/posts/gatsbyjs-gtm/gtm-script.png" alt="Googleタグマネージャーの埋め込みコード" width="1171" height="368" />
<h2 id="Googleタグマネージャーの設定">Googleタグマネージャーの設定</h2>
<h3 id="トリガーの作成">トリガーの作成</h3>
GatsbyJSはSPAでCSRで動作するため、変更の履歴をトリガーとして作成しておきます。
<h3 id="変数の作成">変数の作成</h3>
GAのトラッキングIDを設定した Googleアナリティクス設定 を変数として設定します。
<img src="/images/posts/gatsbyjs-gtm/gtm-ga-variable.png" alt="Googleアナリティクスの変数を作成" width="720" height="290" />
<h3 id="タグの作成">タグの作成</h3>
Googleアナリティクスにページビューを送信するタグを作成します。
Googleアナリティクスの設定には上で作成した変数を指定し、トリガーには「ページビュー」と「履歴の変更」の2つを設定しました。
初回のページ読み込みもトリガーさせるために、「ページビュー」も指定しています。
<img src="/images/posts/gatsbyjs-gtm/gtm-tag.png" alt="タグの作成" width="731" height="384" />
<h2 id="リリース前の確認">リリース前の確認</h2>
Googleタグマネージャーのプレビューモードを利用すれば、ローカルで埋め込みが正常に出来ているか確認できます。
ワークスペース &gt; プレビュー をクリックしてプレビューモードにした後に、ローカルで ページを表示します。
その際は次の設定を true に変更しておく必要があります。
<pre class="language-javascript"><code class="language-javascript">// Include GTM in development.
// Defaults to false meaning GTM will only be loaded in production.
includeInDevelopment: true,
</code></pre>
ワークスペース &gt; プレビュー をクリックしてプレビューモードにした後に、ローカルでサーバーを立ち上げてページを表示します。
正常にタグが埋め込まれている場合は、ローカルで表示したページ下部にGoogleタグマネージャーのプレビュー画面が表示されます。
<h2 id="リリース">リリース</h2>
以上の設定を終えたら、Googleタグマネージャーの公開 と プラグイン追加の変更を本番環境にリリースすれば導入は完了です。
<h2 id="おまけ">おまけ</h2>
自分のアクセスを計測対象外とするために <a href="https://chrome.google.com/webstore/detail/google-analytics-opt-out/fllaojicojecljbmefodhfapmkghcbnh" target="_blank">Google Analytics オプトアウト アドオン (by Google)</a> を利用しています。 
「ga.jsと連携して...」と書いてありますが、Googleタグマネージャーを経由する場合でも正常に動作してくれました。

Gatsby製のブログにGoogleタグマネージャー経由でGoogleアナリティクスを導入する

<a href="https://github.com/gatsbyjs/gatsby-starter-blog" target="_blank">gatsbyjs/gatsby-starter-blog</a> で作成したブログはデフォルトの状態ではコードのシンタックハイライトが無く非常に見辛いです。 
プラグインを設定してシンタックハイライトを導入します
<h2 id="プラグインの導入">プラグインの導入</h2>
gatsby-starter-blog には最初から <a href="https://gatsbyjs.org/packages/gatsby-remark-prismjs" target="_blank">gatsby-remark-prismjs</a> がプラグインとしてインストールされています。 
そのため、新たにプラグインをインストールする必要はなく、ハイライトのcss読み込み設定を修正するだけでシンタックハイライトを有効化できます。
<pre class="language-js"><code class="language-js"> {
 resolve: `gatsby-transformer-remark`,
 options: {
 plugins: [
 {
 resolve: `gatsby-remark-images`,
 options: {
 maxWidth: 590,
 },
 },
 {
 resolve: `gatsby-remark-responsive-iframe`,
 options: {
 wrapperStyle: `margin-bottom: 1.0725rem`,
 },
 },
 `gatsby-remark-prismjs`,
 `gatsby-remark-copy-linked-files`,
 `gatsby-remark-smartypants`,
 ],
 }, {
 resolve: `gatsby-transformer-remark`,
 options: {
 plugins: [
 {
 resolve: `gatsby-remark-images`,
 options: {
 maxWidth: 590,
 },
 },
 {
 resolve: `gatsby-remark-responsive-iframe`,
 options: {
 wrapperStyle: `margin-bottom: 1.0725rem`,
 },
 },
 `gatsby-remark-prismjs`, // 初期状態でインストール済み
 `gatsby-remark-copy-linked-files`,
 `gatsby-remark-smartypants`,
 ],
 },
</code></pre>
<h3 id="CSSの読み込み設定">CSSの読み込み設定</h3>
gatsby-browser.jsにて prismjs のテーマのCSS読み込みを追記します。 
デフォルトで利用できるテーマの一覧は <a href="https://github.com/PrismJS/prism/tree/1d5047df37aacc900f8270b1c6215028f6988eb1/themes" target="_blank">PrismJS/prism/themes</a> で確認できます。
<pre class="language-js"><code class="language-js">import "prismjs/themes/prism-tomorrow.css"
</code></pre>
<h2 id="シンタックハイライトを利用">シンタックハイライトを利用</h2>
pre記法に言語タグを指定することでシンタックハイライトを利用できます。 
利用可能な言語タグの一覧は <a href="https://prismjs.com/#supported-languages" target="_blank">prismjs</a> の公式ページに記載してあります。
<pre class="language-js"><code class="language-js">```js
console.log('シンタックハイライトだよ')
```
</code></pre>

gatsby-starter-blogでコードのシンタックスハイライトを設定

<h2 id="Netfify CMSとは？">Netfify CMSとは？</h2>
任意の静的サイトジェネレーターと組み合わせて利用可能なNetlifyが提供するCMSツールです。 
テキスト編集やプレビュー機能、画像アップロードなどの機能をWebベースのUIとして提供してくれます。 
また、GitHubのAPIを内部で利用しており、管理画面上で記事作成 =&gt; githubにpush =&gt; netlifyにデプロイ のフローを自動で実施してくれます。
<h2 id="GastbyJSのテンプレートからブログを作成">GastbyJSのテンプレートからブログを作成</h2>
立ち上げるブログが無いと何も始まりません。
最初に GatbyJS の <a href="https://github.com/gatsbyjs/gatsby-starter-blog" target="_blank">gatsbyjs/gatsby-starter-blog</a> を利用してテンプレートからブログを作成します。
<pre class="language-shell"><code class="language-shell">$ yarn add global gatsby-cli
$ gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog
</code></pre>
たった2行でブログの作成が完了しました！ 
デザインの修正とかやりだすと、やる事が増えて結局途中で諦めてしまう可能性がある（自分の性格上そうなる）ので、とりあえず公開する事だけを目標とします。
デザインとかは後からゆっくり修正していきましょう。
<h3 id="Netlify CMS をインストール">Netlify CMS をインストール</h3>
続いて Netlify CMS をインストールします。
<pre class="language-shell"><code class="language-shell">$ cd blog
$ yarn add netlify-cms-app gatsby-plugin-netlify-cms
</code></pre>
<code>static/admin/gatsby-config.yml</code> ファイルを作成して次の内容を貼り付けます。
<pre class="language-yaml"><code class="language-yaml">backend:
 name: git-gateway
 branch: master

media_folder: static/images/uploaded
public_folder: /images/uploaded

collections:
 - name: "blog"
 label: "Blog"
 folder: "content/blog"
 create: true
 slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
 editor:
 preview: true # プレビュー表示を有効化
 publish_mode: editorial_workflow # ワークフロー管理を有効化
 fields:
 - { label: "Title", name: "title", widget: "string" }
 - { label: "Publish Date", name: "date", widget: "datetime" }
 - { label: "Description", name: "description", widget: "string" }
 - { label: "Body", name: "body", widget: "markdown" }
</code></pre>
画像をアップロードする空ディレクトリを追加します。
<pre class="language-shell"><code class="language-shell">$ mkdir -p static/images/uploaded
$ touch static/images/uploaded/.gitkeep
</code></pre>
最後に <code>gatsby-config.js</code> にプラグインを追記します。
<pre><code>plugins: [`gatsby-plugin-netlify-cms`]
</code></pre>
CMSのインストールはこれだけです。 すごい簡単で感動ですね。
実際にローカル環境で確認してみましょう。
<pre><code>$ yarn development
</code></pre>
http://localhost:8000/admin にアクセスしてCMSのログイン画面が表示されたらOKです。
ログインするには後述する Netlify の認証設定が必要です。
<h3 id="ブログを公開する">ブログを公開する</h3>
ここまで来たら、いよいよNetlifyにブログを公開します。
最初にGitHubにリポジトリをデプロイします。
<pre class="language-shell"><code class="language-shell">$ git add .
$ git commit -m "Initial Commit"
$ git remote add origin https://github.com/YOUR_USERNAME/NEW_REPO_NAME.git
$ git push -u origin master
</code></pre>
続いて Netlify のページ上で <code>New Site From Git</code> を選択して手順に沿ってブログを公開します。
ビルド設定は次ように設定します。
<pre><code>Build Command: gatsby build
Publish directory: public/
</code></pre>
&lt;ブログのドメイン名&gt;/admin にアクセスすれば管理画面を表示できます。
<img src="/images/posts/netlify-cms/blog-template.png" alt="テンプレートの画面" width="1930" height="1460" />
テンプレートのままですが、自分のブログが公開されました (*'ω'ﾉﾉﾞ☆ﾊﾟﾁﾊﾟﾁ
<h2 id="CMSの管理ユーザーの作成">CMSの管理ユーザーの作成</h2>
CMSの管理画面にログインするために Netlify の認証設定をして管理ユーザーを作成しましょう。 Netlifyの管理画面から公開したサイトを選択して次の手順に沿ってアカウント作成の作業を進めます。
<ol>
<li>Settings &gt; Identity &gt; Enable Identity を選択</li>
<li>Registration preferences &gt; Edit Settings &gt; Invite only を選択 この設定をしないと誰でもアカウントを作成して管理画面にログインできてしまうので、よほどの理由がない限りは設定しておくことをオススメします</li>
<li>Services &gt; Git Gateway &gt; Enable Git Gateway をクリック</li>
<li>Identityタブに移動 &gt; Invite users をクリック 自分のメールアドレスを指定して自分を管理者として招待 送信された招待メールからアカウントを作成</li>
</ol>
これでCMSの管理画面にログイン出来るようになりました。
<h2 id="記事を投稿する">記事を投稿する</h2>
最後にCMSで最初の記事を投稿していきます。
<ol>
<li>/admin にアクセスして、管理画面にログイン</li>
<li><code>new blog</code> をクリック</li>
<li>記事を書いて <code>Save</code> をクリック</li>
<li>問題なければ Publish をクリック</li>
</ol>
以上で記事が公開されます。

GatsbyJS + Netlify CMS でエンジニアブログを立ち上げる

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