
この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の22日目の記事です。

## はじめに
現在、輪読会で [テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)（TDD）を読み進めています。  
本を読んで色々と知識が入ってきているので、業務でアウトプットしてみたいなと思い、バグ修正からTDDを初めてみたら良かったので紹介します。

## なぜバグ修正から始めるのか？
TDDをする上で一番難しいなと感じるのが、**実装前に何のテストを書けば良いか分からない**という部分です。  
今までテストを書いた経験が少ないと、対象となるコードが無い状態からテストを書き始めるのはイメージがしづらく中々テストを書くことができません。

その点、バグ修正の場合は既にコードが存在しており、バグを再現するテストを書けば良く何をテストするかも明確になっているので、非常にテストコードが書きやすいという利点があります。

そのため、バグ修正は比較的スムーズにTDDのフローを回しやすく手軽にTDDを体験することができます。

## TDDでバグ修正に挑戦する
### 概要
ユーザーのアバター画像とユーザー名を表示する `UserBio` コンポーネントについて考えてみます。

このコンポーネントはアバター画像について考慮が漏れておりリンク切れのバグが発生する可能性があります。
- バグ: アバター画像が未設定の場合にリンク切れで画像が表示される  
- 期待する動作: アバター画像が未設定の場合はサムネイル画像を表示する

```tsx
// src/components/UserBio.tsx
import { FC } from 'react';

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

export const UserBio: FC<Props> = ({ user }) => {
  return (
    <div>
      <img src={user.avatar} />
      <span>{user.name}</span>
    </div>
  )
}
```

### バグを再現するテストコードを書く
コードのバグを修正したい気持ちをぐっ！と抑えて、先にテストコードを書いていきます。

どんなテストコードを書けば良いでしょうか？  
今回の目的はバグ修正のため**バグを再現する**テストコードを書けば良いので、何をテストするかは非常に明確です。

本来であれば、テストが全く書かれいない場合はアバター画像を表示するテストも先に書いておいた方が良いですが説明の都合で割愛しています。

```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(<UserBio user={{ name: "テスト太郎" }} />);

    const expected = "https://example.com/images/avatar";
    expect(screen.getByRole("img")).toHaveAttribute("src", expected);
  });
});
```

テストを実行してみます。  
正常にテストが失敗してくれたので、これでバグを再現するテストコードが実装できました。

```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
```

### バグ修正対応
バグを再現するテストができたので、後は楽しくバグ修正のコードを書くだけです。

```tsx
const AVATAR_THUMBNAIL = 'https://example.com/images/avatar';

export const UserBio: FC<Props> = ({ user }) => {
  return (
    <div>
      <img src={user.avatar ?? AVATAR_THUMBNAIL} />
      <span>{user.name}</span>
    </div>
  );
}
```

バグ修正ができたので、改めてテストを実行してみます。  
無事にテストが通りバグが修正されたのを確認できました！ ⸜(｡˃ ᵕ ˂ )⸝

```shell
$ yarn jest src/components/UserBio.spec.tsx

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

### ブラウザ不要の検証
今回のバグ修正ではコードを変更してバグが修正されたことを確認する過程全くブラウザを利用しませんでした。  
PR作成前に念の為のブラウザ確認はしますが、検証でブラウザ操作をするのはその1度だけに抑えることができます。

フロントエンドをTDDで開発するメリットの一つとしてこの検証の簡略化があります。  
フロントエンドで検証を進めるために何度もコードとブラウザを行き来してブラウザ操作をする事が多いですが、この実装途中におけるブラウザ操作が地味に面倒で開発コストとして発生します。

TDDでテストを先に書いて検証を自動化することで、この検証コストを減らして開発効率を上げられるメリットがあります。

## さいごに
今回は非常に簡単なバグ修正を例にフロントエンドでのTDDについて紹介しました。

TDDやテストを書くには、どんな簡単なモノでも良いので**たくさんテストを書いて経験を得る**ことが何より大事だと思います。  

TDDで開発をしてみたいけどなかなか初めの一歩が踏み出せない場合は、今回のケースのようなすごく簡単な修正からテストを書き始めてみましょう。


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

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


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の10日目の記事です。

## はじめに
コードレビュー難しいですよね。  
今年で6年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。

予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったり問題点を挙げればキリがありません。

コードレビューのことを考えるにあたり、自分が普段どんな感じでレビューしているか意識したことをがないなと思い、一度自分がレビュー時に意識していることを整理してみました。

## 仕様の把握
コードレビューを始める時に自分が最初にやることは、修正内容の仕様の把握です。ここでいう仕様とは、「どういう場合にどういう状態になるか」を指しています。

コードレビューとは修正されたコードに問題がないかを客観的な目線でチェックする作業です。  
このとき、**何が正しいか** の基準が無いと問題が無いことを判断することはできないため、最初に**何が正しいのか** 知るためにも対象のPRでの仕様を理解することを意識しています。

### 概要欄を読み込む
チームでレビューをしていると、PRの概要欄には修正の目的などが記載されています。  

まずは概要欄を読むことでざっくりと全体を把握できる事が多いので、最初に概要欄をしっかりと読むようにしています。（しっかり書かれている前提ですが）

### ブラウザで動作確認
修正内容を理解するために、ソースコードを読む前にブラウザで実際に動作確認をします。

先に実際に動かして確認をした方が理解を深めやすく、何をやっているかをイメージしながらコードリーディングができるので、コードレビューがやりやすくなります。

最初の動作確認で分からない点や気になった箇所があれば、そこだけピンポイントでコードを読んで仕様を理解するようにしています。この時にバグが見つかることも多々あります。

### APIリクエストの仕様について
APIリクエストをしている場合はAPIレスポンスのデータ構造も意識的に確認するようにしています。
フロントエンドはAPIのレスポンスデータを画面上に表示する事が主な役割なので、表示するデータの仕様を把握しないと正しくデータを扱えているかの判断が難しいためです。

外部APIのレスポンスでデータの意味が分からない場合は、念の為API仕様書でレスポンスの仕様を把握してレビューができると、予想外のバグが見つかったりします。

##  レビューの優先度
レビューをする時は自分の中で項目を分けて優先度を付けてレビューをしています。

1. バグ・デグレが発生しないか
2. セキュリティは問題ないか
3. 変更は容易か（設計）
4. コードは読みやすいか

レビュー項目を分けて優先度を付けておくと、PRの内容に応じてレビューにかける時間配分をコントロールできるようになります。
- コードレビューをする時間が少ない場合は最低限 2 まではしっかり確認して 3,4 にかける時間を短くする。
- 今後も変更が多い重要な機能は、多少を時間をかけてでも全ての項目について細かく確認する。

## 重点的に見る箇所
- サービスとして重要な機能やお金が絡む部分
- XSSなどのセキュリティバグが発生しやすい部分
    - クエリパラメーターを内部で参照する場合など
- 多くの場所から参照されているファイル
    - 共通ライブラリやコンポーネント

## バグ・デグレが発生しないか
- 意地悪な気持ちになって特殊な操作をしてみる
- PC,スマホの両方のviewportでデザイン崩れが発生しないか
- CSS, JS はサポートしているブラウザで利用可能か
 - ここら辺はESLintで自動テストをかけて、ある程度チェックを省略することもできます
- 条件分岐の条件は適切か
- 修正箇所を呼んでいる他の部分に影響がないか

### バグ・デグレが発生やすい箇所
次の箇所は経験的にバグ・デグレが発生しやすいので注意深くレビューをすることが多いです。

- コードの可読性が低い部分
- コードから実装者の意図が読み取れない箇所
  - 裏側に複雑な仕様が隠れていることがあるので、デグレが発生しやすい
- データ構造が複雑な箇所
  - 多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い
- 条件分岐が複雑な箇所
  - 多くのことをやり過ぎている可能性が高く処理が複雑になっている可能性が高い
- 多くの箇所から参照されている部分
  - 呼び出し元に応じた処理が1箇所に書かれて、処理が複雑になりやすい
- パッと見で特殊なことをやっている箇所
  - 読んでいて普通だったらこんな実装しないなと感じる箇所は裏側に複雑な仕様が隠れていることがあるのでバグが発生しやすい
- なんかモヤモヤとした不安感を感じる箇所
  - モヤモヤの正体は経験則による直感であることが多く、過去に似た箇所でバグに遭遇したことがあったりするので、その直感は当たることが多い

## セキュリティに問題はないか
- URLパラメーターなどユーザーが入力可能な値を参照している場合は、XSSなどに問題がないか
- 権限などで機能制限をしている場合は、ローカルプロキシなどでレスポンスを改竄して悪さできないか
  - レスポンスを改竄して制限をすり抜けられる場合は、それをやられた場合のサービスのリスクを考える

## 変更は容易か（設計）
- 発生する可能性のある仕様変更を想像して、その仕様変更に対して容易に対応可能か
  - 仕様変更があった場合に複数箇所を修正する必要があると1箇所だけ修正を忘れてデグレが発生しやすい
  - 修正時の影響範囲が多いとデグレが発生しやすい
- 一つのファイルが責務を持ち過ぎていないか
    - 1箇所で多くのことをしていると処理が複雑になりデグレが発生しやすい
    - 修正時の影響範囲も把握がしづらくなる
    - 修正時に考慮することが増えるので機能改修に時間がかかる

## コードの可読性
- 1か月後の自分が同じコードを読んで理解できそうか
- 無駄に複雑に書かれていないか
- 変数名は誤解を生むような名前になっていないか
- 自分が実装する場合にどう実装するかをイメージする

## レビューコメント
- 可読性や設計を指摘する場合は、極力ダメな理由と改善案（サンプルコード）を一緒に提示する
  - 一方的にダメと言われるとレビュイーも困りますし、気分が悪くなっちゃいます。
- ラベルをつける
  - レビュイーがコメントに対して優先度をつけて対応ができるので効率が上がります
  - FIX(バグ修正）, REFACTOR、COMMENT など
  - [レビューコメントにラベルをつけるだけで開発効率があがって幸せになれそうな話 - Qiita](https://qiita.com/godgarden/items/3ea57a7ee6dbff1df6e6)
- 絵文字やAAを使う
  - コードレビューは書いたコードに対して何かしらの指摘が発生する作業なので、ギスギスしてしまう可能性があります。
  - 少しでもギスギスしないように絵文字やAAを使って雰囲気が柔らかくなるようにしています。
- 良い点があれば Good なリアクションをする
  - 褒められると嬉しい👍
- 人を否定しない
  - こんなコードを書くなんて全然ダメだ！などと個人に対しての言及はダメ。ゼッタイ。
  - 自分が言われたら辛い🥲
- 宗教戦争になり得ると思った指摘はしない
  - ただ、宗教戦争になるかどうかの判断はかなり難しい
  - 書き方の問題であれば、コーディング規約を決めてLinterでチェックできると良い
  - 宗教戦争になりそうだと思ったら、「好みの問題かもしれないですが...」などと前置きをおいてお茶を濁す
  - COMMENT ラベル等でお気持ちの表明だけをする

## コードレビューを楽しむ🎉
自分はコードレビューをゲーム感覚で実施することを心がけています。バグを見つけらたらレビュアーの勝ち！バグが無ければレビュイーの勝ち！という具合です。目標を持ってコードレビューをするとレビューをしていて楽しいですし、バグを見つけることに全力になります。

※ 勝ち負けは自分の中だけに留めておいてください。

## 参考資料
丁寧にまとまっているので、併せて読んでみてください。

- [より良いコードレビューをするために気をつけていること | メルカリエンジニアリング](https://engineering.mercari.com/blog/entry/2019-12-22-080000/)
- [コードレビューの際に気をつけること - Qiita](https://qiita.com/awakia/items/8344ba751426e386e0f5)
- [僕がコードレビューの時に気をつけていること｜su-｜note](https://note.com/su_k/n/nf23ab5c6dba2)


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

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


この記事は [YAMAP エンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yamap-engginers) の7日目の記事です。

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

この記事ではコンポーネントの入力と出力を意識することでユニットテストで「何をテストするか」について、まとめています。

## 自動テストは何をテストするのか？
最初に一般的に自動テストでは何をテストするのかを明確にします。

自動テストでは**与えた入力に対して期待した出力が得られるか？** をテストします。基本的にはこれだけ意識しておけば大抵の自動テストは書くことができます。（暴論）

例えば次ような url が Googleのドメインかどうかを判定する関数のテストを考えてみます。

```typescript
const isGoogleDomain = (url: string): boolean => {
  return url.match(/^http[s]:\/\/google.com\//) != null;
}
```

この関数をテストしてくださいとお願いされたら、どのようなテストを書くでしょうか？  
大抵は最低限、次の2つのテストを考えるのではないでしょうか？
1. https://google.com/search?q=テスト の時に true を返すか
2. https://example.com の時に false を返すか

このテストケースの入力と出力をまとめると次のようになります。

|入力|出力|
|--|--|
|https://google.com/search?q=テスト|true|
|https://example.com|false|

## コンポーネントのテストが難しい理由
先ほど見たように、util 系の関数は入力と出力が分かりやすいので、比較的テストが書きやすい部類になると思います。それに比較してコンポーネントは意識しないと入力と出力が分かりにくいのではないでしょうか？

コンポーネントのテストが難しいと感じる理由は **テストの書き方が分からない** のではなく **入力と出力が分からない** ことが大きな原因となっていると考えています。

逆に言えばコンポーネントの入力と出力が把握できれば、コンポーネントのテストも util系の関数と同じように書くことができます。

## コンポーネントの入力と出力
ここからReactの関数コンポーネントを例に話を進めますが、基本的な考え方は Vue のコンポーネントでも同じです。
Reactの関数コンポーネントは名前の通りただの関数です。ただの関数ということは入力と出力が定義できるということです。

では、関数コンポーネントの出力とは何でしょうか？
それは、**HTMLのDOM構造** です。

それに対して入力は主に次の3種類です。
1. props
2. クリックなどのユーザーイベント
3. Reduxなどのグローバルストア

以上のことから、それぞれ**3種類の入力に対して正しくHTMLの構造が出力されるか**を確認することで、コンポーネントのテストを書くことができます。

## コンポーネントはテストを書かない違和感
このように入力と出力を意識して考えると、関数コンポーネントもutil系の関数も同じ関数です。

関数コンポーネントを実装する時には、〇〇なpropsの場合は△△なDOMを出力するといったように条件分岐や、開始日や終了日から滞在日数を計算してテキストを表示するといったような実装をすることがあります。

これらは明らかなロジックにも関わらず、util系の関数のロジックはテストを書くのにコンポーネントのロジックのテストは書かないのは明らかに違和感を感じてしまいます。

なので、コンポーネントのテストもutil関数と同じような感覚でテストを書いていって良いと思います。

## 入力と出力を考えてテストを書いてみる
### 入力と出力を考える
実際に次のカウンターコンポーネントの入力と出力を考えてみます。

次に進む前に試しに自分で入力とを出力を考えてみてください。

```tsx
const Counter = ({count}: {count: number}) => {
    const [countState, setCount] = useState(count);

    const handleClick = () => {
        setCount(count => count + 1);
    }

    return (
        <div>
            <span>{count}</span>
            <button onClick={handleClick}>カウントアップ</button>
        </div>
    );
}
```

入力と出力はこんな感じになります。

|入力|出力|
|--|--|
|count props|count値のテキスト|
|ボタンクリックイベント|現在のcountに+1された値のテキスト|

ここでは、span要素として出力されのるが重要ではなく、**カウントの値がテキストとして出力される**ことが期待している結果なので、出力はテキストという表現をしています。

### テストを書いてみる
入力とを出力を洗い出せたのでテストを書いてみます。

テストの記述には jest + testing-library を利用しますが、触ったことない方でも何をやっているかを把握できると思うので、こんな感じでテストを書くんだという雰囲気を掴む程度で大丈夫です。

最初に props の入力に対する出力のテストを書いてみます。
|入力|出力|
|--|--|
|count props|count値のテキスト|

期待する振る舞いが「props として渡したカウントの値がHTMLのテキストとして出力されるか」なので、入力としてpropsで渡した値(5)が出力としてDOM上にテキストとして表示されているかを確認すればテストを書くことができます。

```tsx
import { render } from '@testing-library/react';
import { Counter } from './Counter';

describe('Counter', () => {
    it('propsで指定したカウント数を表示する',  () => {
        render(<Counter count={5} />);
        const count = screen.queryByText(5);
        expect(count).toBeInTheDocument();
    }
});
```

次にボタンクリックの入力に対してもテストを書いてみます。

|入力|出力|
|--|--|
|ボタンクリックイベント|現在のcountに+1された値のテキスト|

ユーザーイベントの場合もpropsの場合と考え方は同じです。

入力としてボタンクリックイベントを与えた時に、現在のカウントを+1した値がテキストとして出力されるかを確認すればテストを書くことができます。

```tsx
import { render } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Counter } from './Counter';

describe('Counter', () => {
    it('propsで指定したカウント数を表示する',  () => {
        render(<Counter count={5} />);
        const count = screen.queryByText(5);
        expect(count).toBeIntTheDocument();
    }

    it('ボタンをクリックすることで表示するカウント数が増える',  () => {
        render(<Counter count={5} />);
        const button = screen.getByRole('button');
        userEvent.click(button);
        userEvent.click(button);
        const count = screen.queryByText(7);
        expect(count).toBeInTheDocument();
    }
});
```

## 具体的なコンポーネントのテストを考えてみる
サンプルのカウンターコンポーネントではピン来ないと思うので、もう少し具体的なコンポーネントとして通知内容に応じてリンクを表示する `NotificationLink` というコンポーネントのテストを考えてみます。

`NotificationLink` は props で `Notification` オブジェクトを受け取り、プロパティの値に従ってaタグを返す関数コンポーネントです。

仕様は次の通りです。
- `webLaunchUrl` が null or 空文字の場合は span要素でテキストを表示する
- `webLaunchUrl` が外部リンクの場合は、別タブで対象のリンクを開くa要素を表示する
- `webLaunchUrl` が内部リンクの場合は、相対パスをリンクとしたa要素を表示する

これらの情報を元に今までの例に習って、入力と出力を考えみましょう。

```tsx
export const NotificationLink = ({notification}: Notification) => {
    const webLaunchUrl = notification.webLaunchUrl;

    if(webLaunchUrl == null || webLaunchUrl === '') {
        return <span>{notification.text}</span>
    }

    if (isExternalLink(webLaunchUrl)) {
        return <a href={webLaunchUrl} target="_blank">{notification.text}</a>
    }

    const relativePath = getRelativePath(webLaunchUrl);
    return <a href={relativePath}>{notification.text}</a>   
}
```

入力と出力はこんな感じです。

|入力|出力|
|--|--|
|webLaunchUrl が null の notification|notification.textのテキスト(a要素でない)|
|webLaunchUrl が外部リンクの notification|別タブで外部リンクを開くa要素|
|webLaunchUrl が内部リンクの notification|相対パスがリンクとして指定されたa要素|

入力と出力が分かったので、これを元にテストを書いてみます。

```tsx
import { render } from '@testing-library/react';
import { NotificationLink } from './NotificationLink';

describe('NotificationLink', () => {
    it('webLaunchUrlがnullのときにテキストのみを表示する', () => {
        const notification = { webLaunchUrl: null, text: 'test' };
        render(<NotificationLink notification={notification} />;
        const text = screen.queryByText(notification.text);
        const link = screen.queryByRole('link');

        expect(text).toBeInTheDocument();
        expect(link).not.toBeInTheDocument();
    });

    it('webLaunchUrlが外部リンクの時に別タブのリンクを表示する', () => {
        const notification = { webLaunchUrl: 'https://example.com', text: 'test' };
        render(<NotificationLink notification={notification} />;
        const link = screen.queryByRole('link');

        expect(link).toHaveAttribute('href', notification.webLaunchUrl);
        expect(link).toHaveAttribute('target', '_blank');
        expect(link).toHaveTextContent(notification.text);
    });

    it('webLaunchUrlが内部リンクの時に相対パスでリンクを表示する', () => {
        const notification = { webLaunchUrl: 'https://t-yng.jp/tag/typescript', text: 'test' };
        render(<NotificationLink notification={notification} />;
        const link = screen.queryByRole('link');

        expect(link).toHaveAttribute('href', '/activities');
        expect(link).not.toHaveAttribute('target', '_blank');
        expect(link).toHaveTextContent(notification.text);
    });
})
```

## コンポーネントのテストを書くメリット
### 設計の良し悪しの基準になる
「テストが書きにくいコードは設計が良くない」というのはテストを書くときに頻繁に言われる話ですが、コンポーネントでもこの考えは当てはまります。

色々な責務を持っている複雑なコンポーネントに対してテストを書いてみようとすると、入力と出力が分かりにくくなり、様々なモックを利用する必要が出てくるので非常にテストを書くのが困難になります。

特にコンポーネントの設計は良し悪しが難しい部分があるので、テストを書くことでテストが書きやすい=設計が悪くない、と判断して自信を持って実装を進めることができるのは大きなメリットです。

### 安心してリファクタリングができる
一般的に自動テストが効力を発揮するのはリファクタリングをしたときです。つまり、既存コードを修正するタイミングです。

コードレビューをしていると、レビューの指摘を受けてコンポーネントをリファクタするのは日常茶飯事なので、この時にテストを書いておけば安心してコード修正することができます。

テストはリリース前のタイミングでも書いてあるだけで十分に恩恵を得ることができます。

### 検証コストの削減
先ほどの `NotificationLink` コンポーネントに渡される `notification` オブジェクトがAPIレスポンスとして取得される場合には、手動検証をするにはパターンごとにAPIのレスポンスをモックしてブラウザ操作をする必要があり非常に面倒です。準備なども含めると10~15分ほどかかる場合もあるかもしれません。

コンポーネントのテストを書けば入力をモックできるので、1回テストを書けばボタンをポチッと押すだけで、5秒で検証することができます。

このように、APIレスポンスによって表示を切り替えるようなパターンでは手動検証よりもテストを書いた方が圧倒的に検証コストを減らせるメリットがあります。

## まとめ
- コンポーネントのテストも入力と出力を明確にして、期待した出力が得られるかを確認するようにするとテストが書きやすくなる。
- コンポーネントの単体テストは検証コストの削減など十分にテストを書くメリットは多い

コンポーネントのテストは実際に書いてみないと分からないことが多いので、とりあえず簡単な1ケースだけからでも良いので書き始めてみましょう！


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

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

複数行のテキストを `...` で省略する便利な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について


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

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

## ESLintとは？
ESLint は EcmaScript/JavaScript のリンターツールです。チームでコードの利用規約を決め、各自がルールを守って開発するのは大変です。新しくメンバーが増えたときにも、その人がチームのルールに馴染むまで何度もコードレビューで指摘する必要があるかもしれません。ESLintを導入することで、コードのルールチェックを自動化して、統一性のあるコードを担保することができます。

## ESLintの設定
ESLintは設定ファイルで全てルールのON/OFFなどを設定することができます。ESLintの基本的な設定項目について見ていきます。

[Configuring ESLint - ESLint - Pluggable JavaScript linter](https://eslint.org/docs/user-guide/configuring)

### Rules
`rules` オプションはESLintがどのような構文をエラーとするか無視するかを設定するオプションです。デフォルトで定義されているルールとしては「文末にセミコロンを必須とする」 `semi` などがあります。ユーザーは設定ファイルでこれらのルールを設定することで、自分好みにリンターの挙動をカスタマイズすることができます。  
ルールは `off` or `0` , `warn` or `1` , `error` or `2` を指定することで設定ができます。文字列でも数値でも、どちらを指定しても問題ありません。

ESLintは構文チェックで `error` となるルールが見つかった場合は 0以外のexit code で終了し、 `warn` の場合は警告として出力するが構文チェックとしては通過するようになっています。全てを `error` に設定するのも手ですが、Linterの構文エラーを解消するために思わず時間がかかる場合もあるので、チーム内で相談してルールの厳格性を決めると良いです。

次の例では `"quotes": ["error", "single"]` を指定して `'` を使わない場合に構文エラーとしています。また `"no-unused-var": "warn"` と設定することで、未使用の変数を警告として扱うようにしています。 `off` は次で紹介する `extends` を使った場合などに併用する場合が多いです。

```javascript
// error  Strings must use singlequote  quotes
const name = "taro"
// warning  'age' is assigned a value but never used  no-unused-vars
const age = 10
console.log(name)
```

```json
// .esrintrc
{
	"rules": {
		"quotes": ["error", "single"],
        "no-unused-var": "warn"
    }
}
```

### Extends
`extends` オプションではベースとなる設定を指定することで、その設定を継承することができます。先の `rules` オプションの例では、一つ一つルールを設定していました。しかし、毎回プロジェクトごとにルールを全て設定していくのは大変な作業です。そこで ESLint には公式が推奨しているプリセットが存在します。

`extends` オプションで `eslint:recommended` を指定することで、ベース設定を継承して一括で設定をすることができます。

どのようなルールが設定されるかは [公式ドキュメント](https://eslint.org/docs/rules/) を参照すれば確認することができます。

```json
{
	"extends": "eslint:recommended"
}
```

ベースとなる設定で一部のルールを無効にしたい場合には、先ほど説明した `rules` オプションで `off` を指定することで設定できます。

```json
{
	"extends": [
		"eslint:recommended"
	],
	"rules": {
        "no-ununsed-vars": "off"
    }
}
```

`extends` は配列で複数指定することが可能です。 `no-unsued-vars` などのルール設定が重複していた場合は、後から指定した設定で上書きされます。  
次の例では、 `eslint:recommended` で定義されている設定が  `plugin:react/recommended` で定義されている設定で上書きされます。

```json
{
	"extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ]
}
```

### Parser Options

ESLintはデフォルトでES5の構文をサポートしています。ES6以降の構文やJSXの構文を対象にする場合は `parserOptions` で設定します。

ここでは次の3つの項目について説明します。
- ecmaVersion
- sourceType
- ecmaFeatures 

`ecmaVersion` はEcmaScriptのバージョンを指定します。デフォルトの値は 5 です。  
デフォルトの設定で次のコードを構文チェックした場合は `The keyword 'const' is reserved` という構文エラーが発生します。

```javascript
// error  Parsing error: The keyword 'const' is reserved
const hello = () => {
    console.log("hello");
};
```

`ecmaVersion` のを指定すれば、構文チェックする EcmaScript のバージョンを変更できます。

```json
{
	"parserOptions": {
		"ecmaVersion": 2020
	}
}
```

`sourceType` はモジュールのタイプを指定します。デフォルトの値は `"script"` です。

デフォルトの設定で ESLint を利用すると import/export などのESモジュールを利用すると構文エラーとなります。

```javascript
// 'import' and 'export' may appear only with 'sourceType: module'
import { pick } from 'lodash';
```

import/export を利用する場合は `"module"` を指定します。

```json
{
	"parserOptions": {
		"sourceType": "module"
	}
}
```

`ecmaFeatures` は JavaScript で有効にする追加の構文拡張を指定します。

例えば、JSX は JavaScript の構文拡張のため、デフォルトの設定では構文エラーとなります。

```javascript
// error  Parsing error: Unexpected token <
const Hello = ({ name }) => <div>{name}</div>;
```

`"jsx": true` を指定することで、JSX も構文チェックができます。

```json
{
    "parserOptions": {
        "ecmaVersion": 2020,
        "ecmaFeatures": {
            "jsx": true
        }
    }
}
```

### Parser
ESLintはデフォルトで [Espree](https://github.com/eslint/espree) を構文解析のパーサーとして利用しています。TypeScript を構文チェックする場合に type キーワードなどは ECMAScript の構文ではないなため構文解析に失敗します。そのため、 `Parser` オプションで別のパーサーを指定する必要があります。

```typescript
// error  Parsing error: Unexpected token User
type User = {
    name: String;
}
```

TypeScriptの構文解析する場合は @typescript-eslint/parser をパーサーを指定します。

```bash
$ yann add -D typescript @typescript-eslint/parser
```

```json
{
  "parser": "@typescript-eslint/parser"
}
```

### Processor
一部のプラグインは特定の機能としてプロセッサーを提供しています。プロセッサーは Markdown ファイルから JavaScript のコードを抜き出して ESLint をかけたりできます。  
例えば、特定のファイルパスで一部のプラグインを無効にする [mradionov/eslint-plugin-disable](mradionov/eslint-plugin-disable) では、次のように `processer` オプションでプロセッサーを指定します。

```json
{
    "plugins": ["react", "disable"],
    "processor": "disable/disable",
    "overrides": [
        {
            "files": ["tests/**/*.test.js"],
            "settings": {
                "disable/plugins": ["react"]
            }
        }
    ]
}
```

### Environments
ブラウザや jest などのグローバル変数や関数を定義済みとして認識するための設定です。  
例えば、jest ではグローバル関数として `describe` や `it` などの関数が定義されますが、ESLint はその関数が定義されていることを認識することができません。 `no-undef` のルールを有効にした状態で、jestのコードを構文チェックを未定義のエラーが発生します。

```javascript
// error  'describe' is not defined  no-undef
describe("test", () => {
	// error  'it' is not defined  no-undef
    it("test", () => {});
});
```

```json
{
    "parserOptions": {
        "ecmaVersion": 6
    },
    "rules": {
        "no-undef": "error"
    },
}

```

`env` オプションで `jest` を設定することで `describe` などのグローバル関数が定義済みであることを ESLint に伝えることで、構文エラーを解消することできます。  
設定可能な環境の一覧は [公式のページ](https://eslint.org/docs/user-guide/configuring#specifying-environments) で確認できます。

```json
{
  "env": {
    "jest": true,
  }
}
```

### Globals
環境に依存しない独自に定義したグローバル変数をESLintに認識させるための設定です。  
値として `writable` , `readonly` , `off` が設定できます。

```javascript
// error  'bar' is not defined  no-undef
bar = "bar"
// error  'hoge' is not defined  no-undef
console.log(hoge)
```

```json
{
    "rules": {
        "no-undef": "error",
    "no-global-assign": "error"
    },
    "env": {
        "browser": true
    }
}
```

`writable`, `readonly` は定義済みのグローバル変数に対しての可能な操作を表しています。グローバル変数を上書きする事はほぼ無いのと、そもそも上書き自体がバッドプラクティスなので、基本的には `readonly` を指定すれば大丈夫です。

```javascript
// "readonly" と指定したグローバル変数を上書きしているので、まだ構文エラーが発生している。
// error  Read-only global 'bar' should not be modified  no-global-assign
bar = "bar"
console.log(hoge)
```

```json
// .eslintrc
{
    // (省略)
	"globals": {
		"hoge": "readonly",
		"bar": "readonly"
    }
}
```

上の例では、`no-global-assign` を有効にしている状態で `globals` オプションで `readonly` を設定している `bar` のグローバル変数に対して上書きを実行しており、ESLint の構文エラーが発生しています。  
グローバル変数を上書きする場合は `writable` を指定することで、構文チェックのエラーを解消できます。

```javascript
hoge = 'new hoge'
console.log(hoge)
```

```json
// .eslintrc
{
    // (省略)
	"globals": {
		"hoge": "readonly",
		"bar": "writable"
    }
}
```

### Plugins
ESLintでは「JSX が記述されている場合は React モジュールがインポートされていること」などの独自ルールをプラグインという形で組み込むことができます。  
`plugins` オプションでは利用したいプラグインを配列の形で指定します。また、プラグインを利用する場合は、事前にパッケージとしてインストールしておく必要があります。

例として、React の構文チェックプラグインである [yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react) を導入してみます。

最初にプラグインをインストールします。

```bash
$ yarn add -D eslint-plugin-react
```

次にインストールしたプラグインを `plugins` オプションで指定して、使いたいルールを有効化します。
プラグイン名を指定するときに `eslint-plugin` のプレフィックは省略可能です。

```json
{
    // eslint-plugin-react でもOK
	"plugins": ["react"],
	"parserOptions": {
		"ecmaFeatures": {
			"jsx": true
		}
	},
	"rules": {
		"react/jsx-uses-react": "error",
        "react/jsx-uses-vars": "error"
    }
}
```

先の例では `plugins` オプションの例を示すために、敢えて冗長な書き方をしています。プラグインが提供するプリセットの設定をそのまま適用する場合には、次のように `extends` オプションで一括指定することも可能です。

```json
{
	"extends": [
	    "eslint:recommended",
	    "plugin:react/recommended"
    ]
}
```

### Shared Settings
`settins` オプションはESLintのルール実行時に参照される共通の設定値です。独自のカスタムルールから共通の値に参照したい場合などに利用できます。

 [yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react) を利用する場合に次の設定を書く事でReactのバージョンを指定することができます。

```json
{
	"plugins": ["react"],
	"settings": {
		"react": {
			"version": "16.3"
        }
    }
}
```

## Prettierとの併用
Prettier とはコードの自動整形ツールです。

Prettier は `eslint --fix` では整形されないコードも整形してくれるため、ESLint よりも整形ツールとして優れているという利点があります。 次のようなコードは `eslint --fix` は自動整形してくれませんが、 Prettier はコードを自動整形してくれます。

```typescript
// eslint --fix ではこのコードは整形されない
const getAllPostsImpl: GetAllPosts = new GetAllPostsImpl(postsRepository, directoryRepository);
```

```typescript
// prettier だと整形される
const getAllPostsImpl: GetAllPosts = new GetAllPostsImpl(
	postsRepository, 
	directoryRepository
);
```

ESLint と Prettier の併用方法をインターネットで検索すると [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier) をインストールして、ESLint 上で Prettier を実行する方法を見かけることがあります。しかし、この方法では Prettier を直接実行するよりも処理に時間がかかったり、自動整形されるコードが構文エラーとして表示される問題があり [公式のドキュメント](https://prettier.io/docs/en/integrating-with-linters.html) で非推奨とされています。

対応方法としては [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) を導入してPrettierと競合するルールをオフにして、`prettier && eslint` と先に Prettier でコードを整形をした後に ESLint で構文チェックを実行します。

```json
{
	"extends": [
		"eslint:recommended",
		"prettier"
	]
}
```

```bash
# 実行
$ prettier && eslint
```

## Reactの設定例
インストールするパッケージ

- [yannickcr/eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react)
- [eslint-plugin-react-hooks](https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks)

React v17.0 以降を利用する場合は Reactのモジュールをインポートする必要がなくなったので `react/react-in-jsx-scope` を `off` にしておくことをオススメします。

設定ファイル

```json
{
    "plugins": [
        "react-hooks"
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
    ],
    "parserOptions": {
        "sourceType": "module",
        "ecmaVersion": 2020
    },
    "env": {
        "browser": true,
        "jest": true
    },
    "rules": {
        "react-hooks/rules-of-hooks": "error",
        "react-hooks/exhaustive-deps": "warn",
        "react/react-in-jsx-scope": "off",
        "react/prop-types": "off",
        "react/display-name": "off",
    }
}
```

## TypeScriptの設定例

インストールするパッケージ

- [@typescript-eslint/pareser](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser)
- [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin)

```bash
$ yarn add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin
```

設定ファイル

```json
{
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parserOptions": {
        "sourceType": "module",
        "ecmaVersion": 2020
    },
    "env": {
        "browser": true,
        "jest": true
    }
}
```

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

ESLintをちゃんと理解する


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

<img src="/images/posts/nextjs-perf-improvement/lighthouse-result.jpg" alt="改善前のLighthouseの結果" width="1522" height="676" />

## 原因調査
### Lighthouseの結果を考察
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" />

### Webpack Bundle Analyzer
先ほどのLighthouseの結果で問題になっていた、巨大なjsファイルは chunks/pages/post/[slug]-xxx.js でした。これは記事の詳細ページでNext.jsのビルドにより生成されたファイルです。このファイルにバンドルされているモジュールを調査して、jsファイルが巨大化している原因を特定します。

Next.jsは内部でビルドにWebpackを利用しているので、[webpack\-contrib/webpack\-bundle\-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer) を使うことで、生成されたJSファイルのバンドル情報を可視化することができます。

Next.js のプラグインとして [@next/bundle-analyzer](https://github.com/vercel/next.js/tree/canary/packages/next-bundle-analyzer) が提供されているので、今回はこちらを導入していきます。

最初にパッケージをインストールします。

```bash
$ yarn add -D @next/bundel-analyzer
```

続いて Next.config.js にプラグインを利用する設定を書いていきます。  
環境変数として `ANALYZE=true` が指定されていた時だけ、bundle-analyzer を実行するようにしています。

```javascript
const withBundleAnalyzer = require('@next/bundle-analyzer')({
    enabled: process.env.ANALYZE === 'true',
});

const config = {
    // 省略
};

module.exports = withBundleAnalyzer(config);
```

次のように実行することで確認ができます。

```bash
$ ANALYZE=true next build
```

今後のことも考えて実行コマンドは package.json に登録しておきます。

```json
{
    "scripts": {
        "bundle-analyzer": "ANALYZE=true next build"
    }
}
```

### Webpack Bundle Analyzer の結果を考察
webpack-bundle-analyzer を実行することで、ビルド中にブラウザに可視化された情報が表示されます。  
可視化された結果をみてみると [refractor](https://github.com/wooorm/refractor) というモジュールが大部分を占めており、このモジュールの読み込みが今回の問題の原因となっていそうです。

<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png" alt="bundle-analyzerの結果" width="2876" height="1532" />

`yarn.lock` を参照すると、 `refractor` は [react\-syntax\-highlighter/react\-syntax\-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter) から読み込まれていることが分かりました。

```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"
```

これでパフォーマンス問題の原因が特定できたので、残りはこの問題を改修していきます。

## パフォーマンス改善
`reflactor` には、シンタックスハイライトで利用する言語ごとのjsファイルが含まれており、それらが初回レンダリングのタイミングで全て読み込まれることで、パフォーマンス低下を引き起こしていました。`react-syntax-highlighter` は動的インポートにも対応しているので、今回は動的インポートによりレンダリングブロックをしないように修正をします。

ただ、最終的に読み込むファイルの転送量が多いことに変わりないので、将来的には別のアプローチで解決したいです。

```typescript
// import { Prism as SyntaxHilighter } from 'react-syntax-highlighter';
import { PrismAsync as SyntaxHilighter } from 'react-syntax-highlighter';
```

動的インポートに変更した後の bundle anlyzer の結果をみると、 `refractor-import.xxx.js` として `refractor` の読み込みが新しいチャンクとして切り出されています。`[slug]-xxx.js` のファイルサイズ も 722.4kb から 216.54kb に削減されています。

<img src="/images/posts/nextjs-perf-improvement/dynamic-import-bundle-analyzer-result.png" alt="動的インポートのbundle-analyzerの結果" width="1514" height="1356" />

修正後の `[slug]-xxx.js` の中身を見てみると、新たに別の問題が見えてきました。`react-syntax-highlighter`が全てのテーマファイルを読み込んでいます。

<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result-slug.png" alt="[slug]-xxx.jsのbundle-analyzerの結果" width="2876" height="1530" />

この読み込みも不要なので、必要なテーマファイルだけを読み込むように修正します。

```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';
```

最終的に `[slug]-xxx.js` のファイルサイズが 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" />

## さいごに
今回は1番大きな問題を対象として改善策を実施しましたが、画像の最適化や画像の遅延ロード、その他の不要なJavaScriptファイルの削除と改善項目はまだまだ沢山あります。また、Next.jsのリプレースによって新しく導入したライブラリにより意図せずにパフォーマンス低下が起きてしまったので、今後は [GoogleChrome/lighthouse\-ci](https://github.com/GoogleChrome/lighthouse-ci) などを導入して継続的にパフォーマンスなどを計測する仕組みを用意していきたいです。


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

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

<img src="/images/posts/wasm-othello/wasm-othello.png" alt="wasm-othello" width="1466" height="1488" />

この記事は [Hamee Advent Calendar 2020](https://qiita.com/advent-calendar/2020/hamee) の3日目の記事です。  

↓のURLからオセロが遊べるので、ぜひ遊んでみてください！  
[https://wasm-othello.t-yng.jp/](https://wasm-othello.t-yng.jp/)

最上位のレベル6は普通に強いです！CPUのアルゴリズムは自分の普段の思考をベースにしているので、レベル6に勝てない人はリアルで僕とオセロをやっても勝てないレベルです。(多分)

全体のソースコードは [t-yng/wasm-othello](https://github.com/t-yng/wasm-othello) に置いてあります。

実装したのは2020年3月頃とかなり前なのですが供養も兼ねて記事にまとめました。  
余談ですが、もうすぐ令和2年が終わるという事実に衝撃を受けながら、この記事を書いています。

## はじめに

ブラウザでのWebAssemblyの処理速度がJavaScriptと比較してどれだけ向上するのかを体感したく、オセロのCPUをTypeScriptとWebAssemblyで実装して速度比較をしてみました。

WebAssemblyの実装にはRustを利用しています。Rustを選択した理由は自分がRustを書きたかったのが一番の理由ですが、Rustは言語の仕組みとしてガベージコレクションを持たないため、.wasm にコンパイルしたバイナリコードを軽量化できる特徴があります。

## WebAssemblyとは？
> WebAssemblyは、ウェブブラウザのクライアントサイドスクリプトとして動作するプログラミング言語（低水準言語）である。wasmとも称されており、ブラウザ上でバイナリフォーマットの形で実行可能であることを特徴とする。
> 
> [WebAssembly - Wikipedia](https://ja.wikipedia.org/wiki/WebAssembly)

バイナリ形式で実行されるので、JavaScriptと比較してより高速な処理速度が実現できます。RustやC/C++やTypeScriptなどの言語からコンパイルできるため、WebフロントエンドのビジネスロジックをJavaScript以外の言語で記述することができるのも一つの特徴です。

## WebAssemblyを利用した動作イメージ
最善手を探索するビジネスロジック部分をRustで実装・コンパイルして .wasm 形式のバイナリコードを出力します。このファイルをJavaScriptファイルを同じ要領で配信して、ブラウザ上で読み込ます。JavaScriptからwasmのバイナリコードを呼び出すことで、一部のビジネスロジックをWebAssemblyで実行できます。

<img src="/images/posts/wasm-othello/wasm.png" alt="WebAssemblyを利用したイメージ図" width="758" height="652" />

## ミニマックス法を用いたCPUの実装
ミニマックス法とは、オセロや将棋などのゲームアルゴリズムを実装する時に利用される事の多い探索手法の一つです。評価関数を用いて盤面の評価値を計算して、自分の手番では評価値が最大となり、相手の手番では評価値が最小となる最善手を選択するアルゴリズムです。

例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のために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の計算時間が処理速度に依存するようになっています。

ミニマックス法は参考となるサイトが沢山あるので、詳細はそちらを参照してください。  
- [ミニマックス法 \- Wikipedia](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)
- [web帳 \| 5分で覚えるAI Minimax（ミニマックス）法とalpha\-beta法](https://www.webcyou.com/?p=6997)

実装したオセロのアルゴリズムでは次の評価ルールに基づいて評価関数を実装しました。

- 中盤までは相手の石が多い方が評価値を高くする
- 後半は自分の石が多い方が評価値を高くする
- 自分の石が角にある +500
- 相手の石が角にある - 500
- 自分の石が角の上下にある -30
- 相手の石が角の上下にある +30
- 自分の石が角の斜めにある -100
- 相手の石が角の斜めにある +100

## 速度結果
TypeScript実装とWebAssembly（Rust実装）での処理速度をグラフで可視化してみました。

<img src="/images/posts/wasm-othello/speed.png" alt="処理速度のグラフ" width="1946" height="1122" />

盤面によっては7~8倍ぐらいの速度差が出ておりWebAssemblyの速度に驚きました。

## さいごに
オセロを実装したのは6月ぐらいだと思っていたのですが、実際は3月頃で想像以上の月日の流れの速さに驚きました。Rustで実装してみると所有権やライフタイムなど自分の知らない新しい概念が出てきて面白かったです。

Rustの所有権については、[Rustの所有権と借用を理解する](https://t-yng.jp/posts/rust-ownership/)でまとめているので、興味があったら読んでみてください。

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

WebAssemblyでオセロを作った話


[Making a Site with User Authentication \| Gatsby](https://www.gatsbyjs.com/tutorial/authentication-tutorial/) のチュートリアルを試した時の作業を備忘録としてまとめました。

全体の実装は [t-yng/examples/gatsby-auth](https://github.com/t-yng/examples/tree/master/gatsby-auth) を参照してください。

## 要件
* ログイン、ログアウトができる
* 非ログイン状態で要認証ページが表示できないこと

## プロジェクトの作成

```
$ gatsby new gatsby-auth gatsbyjs/gatsby-starter-hello-world
$ cd gatsby-auth
```

## ナビゲーションバーを実装
ナビゲーションバーのコンポーネントを作成する。

```typescript
// src/components/NavBar.tsx
import React from "react";
import { Link } from "gatsby";

export const NavBar = () => (
  <div
    style={{
      display: "flex",
      flex: "1",
      justifyContent: "space-between",
      borderBottom: "1px solid #666",
    }}
  >
    <span>gatsby-auth</span>
    <nav>
      <Link to="/">Home</Link>
    </nav>
  </div>
);
```

ページのレイアウトコンポーネントを実装して、NavBarを追加します。

```typescript
// src/components/Layout
import React from "react";
import { NavBar } from "./NavBar";

export const Layout = ({ children }) => (
  <>
    <NavBar />
    {children}
  </>
);
```

ホーム画面をLayoutコンポーネントを使って、修正します。

```typescript
// src/pages/index.tsx
import React from "react";
import { Layout } from "../components/Layout";

const Home = () => (
  <Layout>
    <div>This is Home</div>
  </Layout>
);

export default Home;
```

## ユーザー認証の実装

最初にユーザーの型定義をモデルとして実装します。

```typescript
// src/models/user.ts
export type User = {
  name: string;
  password: string;
};
```

次にユーザー認証のロジックを実装します。

```typescript
// src/services/auth.ts
import { User } from '../models/user';

export const login = (username: string, password: string) => {
  if (username === 'taro' && password === 'password') {
    setUser({ name: username, password });
    return true;
  } else {
    return false;
  }
};

export const getUser = (): User | undefined => {
  const user = sessionStorage.getItem('user');
  return user != null ? JSON.parse(user) : undefined;
};

export const isLoggedIn = () => {
  const user = getUser();
  return user != null;
};

const setUser = (user: User) => {
  sessionStorage.setItem('user', JSON.stringify(user));
};
```

## クライアントサイドのルーティングを追加
GatsbyJSは `pages` ディレクトリ配下のファイルはビルド時に静的ページとして出力されます。しかし、認証が必要なサイトではユーザー毎にレンダリングする内容が異なるため、静的ページのビルドでは要件を満たせません。  
この場合は、アプリケーションページを用意して、ルーティング定義を書く事でクライアント側で動的にレンダリングをする事で解決することができます。詳しい説明は [Client\-only Routes & User Authentication \| Gatsby](https://www.gatsbyjs.com/docs/client-only-routes-and-user-authentication/) に書かれています。

最初にアプリケーションページを用意します。

```typescript
// src/pages/app.tsx
import React from 'react';
import { Layout } from '../components/Layout';
import { Router } from '@reach/router';
import { Login } from '../components/app/Login';

const App = () => (
  <Layout>
    <Router basepath="/app">
      <Login path="/login" />
      <Profile path="/app/profile" /> {/* ルート定義を追加 */}
    </Router>
  </Layout>
);

export default App;
```

ログインページはこんな感じで実装します。

```typescript
// src/components/app/Login.tsx
import React, { ChangeEvent, FC, FormEvent, useState } from 'react';
import { RouteComponentProps } from '@reach/router';
import { navigate } from 'gatsby';
import { isLoggedIn, login } from '../../services/auth';

interface LoginProps extends RouteComponentProps {}

export const Login: FC<LoginProps> = () => {
  const [user, setUser] = useState({ username: '', password: '' });

  const handleUpdate = (event: ChangeEvent<HTMLInputElement>) => {
    setUser({
      ...user,
      [event.target.name]: event.target.value,
    });
  };

  const handleSubmit = (event: FormEvent) => {
    event.preventDefault();
    const success = login(user.username, user.password);
    if (success) {
      navigate('/app/profile');
    } else {
      alert('ログインに失敗しました');
    }
  };

  return (
    <form method="POST" onSubmit={handleSubmit}>
      <div style={{ marginBottom: 10 }}>
        <label style={{ display: 'block' }}>ユーザー名</label>
        <input id="username" name="username" onChange={handleUpdate} />
      </div>
      <div style={{ marginBottom: 10 }}>
        <label style={{ display: 'block' }}>パスワード</label>
        <input id="username" name="username" onChange={handleUpdate} />
      </div>
      <button
        type="submit"
        style={{ backgroundColor: '#2e43ff', color: 'white', border: 'none' }}
      >
        ログイン
      </button>
    </form>
  );
};
```

ログイン後のプロフィールページも実装しておきます。ユーザー情報の表示は後で実装するので、今はページだけ作っている状態です。

```typescript
// src/components/app/Profile.tsx
import React, { FC } from 'react';
import { RouteComponentProps } from '@reach/router';

interface ProfileProps extends RouteComponentProps {}

export const Profile: FC<ProfileProps> = () => (
  <>
    <div>ユーザー名: ここに名前が表示される</div>
  </>
);
```


ナビゲーションバーにリンクを追加します。

```typescript
// src/components/NavBar.tsx
import React from 'react';
import { Link } from 'gatsby';

export const NavBar = () => (
  <div
    style={{
      display: 'flex',
      flex: '1',
      justifyContent: 'space-between',
      borderBottom: '1px solid #666',
    }}
  >
    <span>gatsby-auth</span>
    <nav>
      <Link to="/">Home</Link>
      {` `}
      <Link to="/app/profile">Profile</Link> {/* プロフィールページへのリンクを追加 */}
      {` `}
      <Link to="/app/login">Login</Link> {/* ログインページへのリンクを追加 */}
    </nav>
  </div>
);
```

クライアントでルーティングするために、gatsby-node.jsで設定を追加します。この設定を追加しないと、`/app/login` などにアクセスした時に静的ページの取得としてルーティングされます。

```javascript
// gatsby-node.js
exports.onCreatePage = async ({ page, actions }) => {
  const { createPage } = actions;

  if (page.path.match(/^\/app/)) {
    page.matchPath = '/app/*';
    createPage(page);
  }
};
```

## 認証状態によるページ遷移
今の実装だと認証状態に関わらず、プロフィールページにアクセスできる状態になっています。これをログイン状態でない場合はログイン画面にリダイレクトするよう変更します。

認証が必要なページへのアクセスを制御する `PrivateRoute` コンポーネントを実装します。

```typescript
// src/components/PrivateRoute.tsx
import React, { Component, ComponentType, FC } from 'react';
import { navigate } from 'gatsby';
import { RouteComponentProps } from '@reach/router';
import { isLoggedIn } from '../services/auth';

interface PrivateRouteProps extends RouteComponentProps {
  component: ComponentType;
}

export const PrivateRoute: FC<PrivateRouteProps> = ({
  component: Component,
  ...others
}) => {
  if (!isLoggedIn()) {
    navigate('/app/login');
    return null;
  }

  return <Component {...others} />;
};
```

プロフィールへのルート定義を変更します。

```typescript
// src/pages/app.tsx
import React from 'react';
import { Router } from '@reach/router';
import { Layout } from '../components/Layout';
import { Login } from '../components/app/Login';
import { Profile } from '../components/app/Profile';
import { PrivateRoute } from '../components/PrivateRoute';

const App = () => (
  <Layout>
    <Router>
      <Login path="/app/login" />
      <PrivateRoute path="/app/profile" component={Profile} /> {/* プロフィールへのルート定義を修正 */}
    </Router>
  </Layout>
);

export default App;
```

## ログアウト機能の実装
ログアウト処理を実装します。

```typescript
// src/services/auth.ts
export const logout = () => {
  sessionStorage.removeItem('user');
};
```

ナビゲーションバーのリンクにログアウトを追加する。

```typescript
// src/components/NavBar.tsx
import React from 'react';
import { Link, navigate } from 'gatsby';
import { isLoggedIn, logout } from '../services/auth';

export const NavBar = () => {
  const handleClickLogout = (
    event: React.MouseEvent<HTMLAnchorElement, MouseEvent>
  ) => {
    event.preventDefault();
    logout();
    navigate('/app/login');
  };

  return (
    <div
      style={{
        display: 'flex',
        flex: '1',
        justifyContent: 'space-between',
        borderBottom: '1px solid #666',
      }}
    >
      <span>gatsby-auth</span>
      <nav>
        <Link to="/">Home</Link>
        {` `}
        <Link to="/app/profile">Profile</Link>
        {` `}
        {isLoggedIn() ? (
          <a href="/" onClick={handleClickLogout}>
            Logout
          </a>
        ) : (
          <Link to="/app/login">Login</Link>
        )}
      </nav>
    </div>
  );
};
```

## プロフィール情報の表示
プライベートなページへユーザー情報を渡すように変更する。

```typescript
// src/components/PrivateRoute.tsx
import React, { ComponentType, FC } from 'react';
import { navigate } from 'gatsby';
import { RouteComponentProps } from '@reach/router';
import { getUser, isLoggedIn } from '../services/auth';
import { User } from '../models/user';

export interface PrivateRouteComponentProps {
  user?: User;
};

interface PrivateRouteProps extends RouteComponentProps {
  component: ComponentType<PrivateRouteComponentProps>;
}

export const PrivateRoute: FC<PrivateRouteProps> = ({
  component: Component,
  ...others
}) => {
  if (!isLoggedIn()) {
    navigate('/app/login');
    return null;
  }

  const user = getUser();

  return <Component {...others} user={user} />;
};
```

プロフィールページにユーザー情報を表示する。

```typescript
// src/components/app/Profile.tsx
import React, { FC } from 'react';
import { PrivateRouteComponentProps } from '../PrivateRoute';

interface ProfileProps extends PrivateRouteComponentProps {}

export const Profile: FC<ProfileProps> = ({ user }) => (
  <>
    <div>ユーザー名: {user.name}</div>
  </>
);
```


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

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


Mateial-UI + webpackの環境で開発を進めている時に、ある時から突然ビルドに時間がかかるようになりました。
最初は、開発を進めていてファイル数が増えたからビルド時間が増えたのかなと思っていたのですが、それを理由にするには、時間がかかり過ぎていました。

改善のために、調査を進めると Material-UI のアイコン読み込みが原因であることが分かりました。

## 問題
問題のコードでは次のようにアイコンを読み込んでいました。

```
import { AccountCircle } from "@material-ui/icons";
```

上記のパッケージ読み込みをしている1ファイルだけを対象にwebpackでビルドした時のパフォーマンスを計測してみると、1ファイルをビルドをするのに20sほどかかっていました。

※ [speed-measure-webpack-plugin](https://github.com/stephencookdev/speed-measure-webpack-plugin) で計測

```
$ 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.
```

## 原因
これは不要なファイルを大量に読み込んでいる事が原因でした。

`@material-ui/icons/index.js`の実装を見てみると、で各アイコンのファイルをrequireしているため、上記のパッケージ読み込みの方法だと、1000個近いアイコンファイルを全て読み込む状態になっていました。

```
var _AccountCircle = _interopRequireDefault(require("./AccountCircle"));

var _AccountCircleOutlined = _interopRequireDefault(require("./AccountCircleOutlined"));
```

## 解決策
解決策としてはシンプルに特定アイコンファイルだけ読み込むように修正すればOKです。

```
import AccountCircle from "@material-ui/icons/AccountCircle";
```

修正版のwebpackのビルド時間を見てみると、無事にパフォーマンスが改善されており、バンドルサイズについても発生していた Warning も消えてくれてました。

```
$ 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.
```

## 参考
[How to improve the build speed in React\-Typescript, when using material ui \- DEV](https://dev.to/janpauldahlke/how-to-improve-material-ui-speed-in-react-typescript-1199)

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

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


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

参考実装は [t-yng/examples/nextjs-localstorage](https://github.com/t-yng/examples/tree/master/nextjs-localstorage) を参照してください。

## Storage オブジェクトを使ってみる
`sessionStorage` からユーザー情報を取得して画面に表示する例を考えてみます。

```typescript
// hooks/useUser.ts
import { useState } from "react";
import { User } from "../interfaces";

const readUser = (): User | undefined => {
  const user = sessionStorage.getItem("user");
  return user != null ? JSON.parse(user) : undefined;
};

export const useUser = () => {
  const [user] = useState<User | undefined>(readUser());

  return {
    user,
  };
};
```

```tsx
// pages/index.tsx
import { useUser } from "../hooks/useUser";

const IndexPage = () => {
  const { user } = useUser();

  return (
    <>
      <h1>ユーザー情報</h1>
      {user == null ? (
        <p>ユーザー情報が存在しません</p>
      ) : (
        <>
          <p>ID: {user.id} </p>
          <p>ユーザー名: {user.name} </p>
        </>
      )}
    </>
  );
};

export default IndexPage;
```

このコードをビルドすると、`undefined sessionStorage` のエラーが発生します。Next.jsはSSRが不要なページはビルド時にSSGにより Rre Rendering されます。これは、Node.js 上で実行されますが、Node.js には `sessionStorage` が存在しないため下記のエラーが発生するのです。

```sh
$ yarn build
Error occurred prerendering page "/". Read more: https://err.sh/next.js/prerender-error
ReferenceError: sessionStorage is not defined
...
```

## useEffectで実行する
この問題は `useEffect()` 内で非同期でユーザー情報を取得する事で解決できます。`useEffect()` の実行は ブラウザ上でのみ限定され、SSRやSSGのタイミングでは実行されません。実行が非同期になるので、新しく `loading` を状態として追加します。

```typescript
// hooks/useUser.ts
export const useUser = () => {
  const [user] = useState<User | undefined>(readUser());

  const [user, setUser] = useState<User | undefined>();
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setUser(readUser());
    setLoading(false);
  }, []);

  return {
    user,
    loading,
  };
};
```

```tsx
// pages/index.tsx
const IndexPage = () => {
  const { user, loading } = useUser();

  if (loading) {
    return <h1>読み込み中...</h1>;
  }

  return (
    <>
      <h1>ユーザー情報</h1>
      {user == null ? (
        <p>ユーザー情報が存在しません</p>
      ) : (
        <>
          <p>ID: {user.id} </p>
          <p>ユーザー名: {user.name} </p>
        </>
      )}
    </>
  );
};
```

上記の対応で `sessionStorage` を使えるようになりましたが、一つだけ問題が発生しました。せっかく `sessionStorage` にデータをキャッシュしているのに、`useEffect()` を利用する関係上、非同期で読み込む必要があるので、例えばページ遷移の度に「読み込み中...」が表示されてしまいます。  

※ デモは分かりやすくするために意図的に表示を遅らせています。

<img src="/images/posts/nextjs-storage/move-page.gif" alt="ページ読み込み" width="446" height="300" />

## Dynamic import
Next.js は [Dynamic import](https://nextjs.org/docs/advanced-features/dynamic-import) で読み込むことで、サーバーサイドでモジュールを読み込まないようにする事ができます。これにより、フロントでのみ `sessitionStorage` の参照します。

```tsx
// pages/user.tsx
import Link from "next/link";
import dynamic from "next/dynamic";
import { useUser } from "../hooks/useUser";

const UserPage = () => {
  const { user } = useUser();

  return (
    <>
      <h1>ユーザー情報</h1>
      {user == null ? (
        <p>ユーザー情報が存在しません</p>
      ) : (
        <>
          <p>ID: {user.id} </p>
          <p>ユーザー名: {user.name} </p>
        </>
      )}
      <p>
        <Link href="/">ホーム</Link>
      </p>
    </>
  );
};

const DynamicUserPage = dynamic(
  {
    loader: async () => UserPage,
  },
  { ssr: false }
);

export default DynamicUserPage;
```

```typescript
// hooks/useUser.ts
import { useState } from "react";
import { User } from "../interfaces";

const readUser = (): User | undefined => {
  const user = sessionStorage.getItem("user");
  return user != null ? JSON.parse(user) : undefined;
};

export const useUser = () => {
  const [user] = useState<User | undefined>(readUser());

  return {
    user,
  };
};
```

サーバーサイドを意識する必要がなくなったので、`useEffect()` で非同期に読み込む必要がなくなり、「読み込み中...」を表示する必要もなくなりました。

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

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


JavaScriptで小数点の桁数を指定してフォーマット表示するには、 `toFixed()` メソッドを使用します。

[Number.prototype.toFixed() - JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed)

```js
const number = 12.3456789; 
console.log(seconds.toFixed()) // 1 : 近似値で表現され、引数省略した場合は少数点の桁数は0。
console.log(milliseconds.toFixed(2)) // 12.35 : 近似値で表現される
```

個人的な利用ケースとして、パフォーマンス計測で処理時間を表示する時に使うことが多いです。

```js
const start = performance.now();
// 何かしらの処理
const end = performance.now();

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


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

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


前に Ajax でフォームの送信をする時に form と div どちらを使うのが良いのか？という質問をされました。質問の意図としては、form タグで実装した場合は送信イベントを止めるために `preventDefault()` を呼ぶ必要があり、この処理を毎回呼ぶのが面倒なので挙動が変わらないなら div タグ の方が良いのでないか？という話でした。

結論だけ先に書いておくと **form タグを使おう** です。

div タグでの実装例

```html
<script>
    const button = document.getElementById('send');
    button.addEventListener('click', () => {
        // inputの値を取得してデータバリデーションとかする
        fetch(...);
    });
</script>

<div id="form">
    <input type="text" id="name" />
    <div>
        <button id="send">send</button>
    </div>
</div>
```

form タグでの実装例

```html
<script>
    const form = document.getElementById('form');
    form.addEventListener('submit', (event) => {
        event.preventDefault();
        // inputの値を取得してデータバリデーションとかする
        fetch(...);
    });
</script>

<form id="form">
    <input type="text" id="name" />
    <div>
        <button type="submit" id="send">send</button>
    </div>
</form>
```

## form タグと div タグの違い

form タグで実装した場合は以下の挙動がブラウザのデフォルトとして動作します。

1. キーボードの Enter を押してリクエストの送信ができる
2. type="password" を含むフォームの送信が成功したら、ブラウザのパスワード保存を自動で確認してくれる

div タグで実装した場合はこれらを自前で実装する工数が発生します。

1. Enter キーのイベントを監視してコールバックを登録する。
2. ブラウザのパスワード保存の確認は API 経由で出来るのか不明

特に 2 つめのパスワード保存については、簡単に調べた感じだと API が提供されていないので、対応ができない可能性が高い気がします。  
このようにブラウザのデフォルトの挙動を考えると、フォームを div タグ で実装するメリットはあまりなく、特別な理由が無ければ素直に form タグ で実装しておいた方が良いです。


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

Rust は所有権の機能を導入することでガベージコレクションを実装せずにメモリ安全を実現しています。これを理解しないとコンパイルエラーが発生した時になぜエラーなのかを把握するのか困難になるので、Rust を使う上で重要な概念です。

ドキュメントなどを読み概要が把握できたので、整理のために説明を書いていきます。

## 所有権の特徴

現在のプログラムにおける一般的なメモリの管理方法は大きく分けて二つあります。  
一つは C や C++のようにプログラマが自分でメモリの確保と開放を宣言するやり方、二つ目は Java や Go のようにベージコレクションによって定期的に不要なメモリを開放する方法です。  
一つ目の方法ではプログラマが常にメモリを意識して開発する必要があり非常にコストがかかり、メモリ管理を誤った場合にダングリングポインタやメモリ 2 重開放などでエラーが発生する危険性があります。また、二つ目の方法では定期的に実行されれるガベージコレクターがアプリケーションの動作の妨げになる事があります。

Rust では所有権システムに基づいてコンパイラがコンパイル時にメモリ安全性のチェックを行うことで、ガベージコレクションを組み込む事なく自動でメモリ安全性を保証しています。

### 所有権規則

所有権システムは次の規則を持っています。

-   規則 1: 値は所有者と呼ばれる変数と対応している
-   規則 2: 値を所有できる変数は必ず一つだけである
-   規則 3: 値を所有する変数がスコープを抜けたら、値は破棄される

### メモリと変数スコープ

```rust
fn main() {
    let s1 = String::from("hello");  // ここで
    println!("{}", s1);
} // ここでs1がスコープから抜けるので "hello" の値も破棄される
```

ここで登場している String 型 は可変の値なので、コンパイル時にサイズを決定する事ができないので、値はヒープ領域に配置されます。  
このとき「値を所有する変数がスコープを抜けたら、値は破棄される」の規則に則り、s1 がスコープから抜ける時に、"hello" のメモリ解放がされます。

<img src="/images/posts/rust-ownership/memory1.png" alt="memory1" width="524" height="372" />

### 所有権のムーブ

次に、変数を別の変数に代入した場合のメモリの状態を考えてみます。

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
}
```

この状態で先ほどと同じようにメモリの解放を考えてみます。最初に s2 がスコープから抜けるタイミングで、"hello" のメモリが解放されます。次に s1 がスコープから外れるので同じようにメモリを解放します。  
ちょっと待ってください、ここで問題が発生しました！  
"hello" のメモリは既に解放されているため、s1 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。



しかし、対象のコードはコンパイルに成功して正常に実行されます。  
なぜでしょうか？

ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は `let s2 = s1;` の部分で "hello" の所有権が s1 から s2 へ移動しており、s1 は値を所有しておらず変数として無効となっているのです。そのため、Rust は s1 がスコープから抜けるタイミングでメモリ解放をする必要がなくなり、結果として s2 に対してのみメモリ解放が実行されるため、正常に動作します。

この、値を所有する変数が移動することを **所有権のムーブ** といいます。

<img src="/images/posts/rust-ownership/move_ownership.png" alt="move_ownership" width="524" height="372" />

この仕組みを考えると、例えば、次のコードはどうなるのでしょうか？

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
             -- value moved here
    println!("{}", s1);
                   ^^ value borrowed here after move
}
```

このコードはコンパイルエラーになります。"hello" の所有権が s1 から s2 にムーブしており、既に無効となっている s1 を使おうとしているためコンパイルエラーになるのです。

また所有権のムーブは関数に値を渡す場合も同様に発生します。

```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
}
```

### 借用

それでは、先ほどの例で関数に値を渡したい時はどうすればいいのでしょうか？  
この問題は **借用** を使う事で解決できます。借用は `&` を使って表現します。

```rust
fn hello(s: &String) {
    println!("hello! {}", s);
}

fn main() {
    let name = String::from("taro");
    hello(&name);
    println!("{}", name);
}
```

借用は name への参照を作成し、これを所有しません。つまり、s は所有権を持たないのでスコープを抜けてもメモリ解放は実行されず、name がスコープを抜けたタイミングでメモリ解放が実行されます。
これは、コンパイラに対して「s は値を借りているだけなので、スコープを抜けてもメモリの解放をする必要がないよ」と教えているのです。

メモリ状態を表現すると次のようになります。

<img src="/images/posts/rust-ownership/memory3.png" alt="memory3" width="742" height="372" />

この借用を用いることで、所有権をムーブさせずに値を参照することができます。

## 参考

-   [What is Ownership? \- The Rust Programming Language](https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html)
-   [所有権とは？ \- The Rust Programming Language](https://doc.rust-jp.rs/book/second-edition/ch04-01-what-is-ownership.html) （公式の日本語翻訳）

## まとめ

Rust の所有権と借用の仕組みは理解するのに、かなり時間がかかりました。理解すると意外とシンプルな考えなんだなと感じました。  
この記事は参考ドキュメントで理解した事を自分用に噛み砕いて書いただけなので、詳しい説明はドキュメントを読んだ方が良いです。

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


フロントエンド実装においてセキュリティを考慮する際に意識した方が良いHTTPレスポンスヘッダーについてまとめています。

## X-Powered-By

### ヘッダーの説明
サーバー側で利用しているフレームワークやバージョン情報を含むHTTPヘッダー

```
例: 
X-Powered-By: Next.js
```

### 脆弱性
サーバー側で利用されているフレームワークやバージョンが含まれているため、他に脆弱性が存在した場合に攻撃者に攻撃を助ける情報を与える可能性がある。

### 対策方法
サーバー側で X-Powered-By ヘッダーを出力しないように設定する。

## X-Runtime

### ヘッダーの説明
サーバーの応答時間を含むHTTPヘッダー

```
例: 
X-Runtime: 0.094235
```

### 脆弱性
タイミング攻撃（Timing Atacking）に利用される可能性がある。

### タイミング攻撃
サーバーの応答時間の違いを利用する事でサービスを分析する攻撃手法です。  
例えば、次のようにログイン処理が実装されていたとします。  

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

この時、ユーザー名がサービスに登録済みの場合はパスワードチェック処理が追加で実行される影響で応答時間が少し長くなるため、攻撃者はランダムなユーザー名でリクエストを送信して X-Runtime の応答時間の違いを比較することで、サービスに登録済みのユーザー名を特定する事ができます。

```
# 未登録のユーザー名の場合
X-Runtime: 0.3949

# 登録済みのユーザー名の場合
X-Runtime: 0.6421
```

参考: [X\-Runtime Header Timing Attacks \- Virtue Security](https://www.virtuesecurity.com/kb/x-runtime-header-timing-attacks/)

### 対策方法
X-Runtime ヘッダーを出力しないように設定する。

## Cache-Control

### ヘッダーの説明
キャッシュの生存期間や保存可否などを制御するHTTPヘッダー  
HTTPレスポンスヘッダーとして指定された場合は、サーバーからのレスポンスを Cache-Control の指定に基づいて制御する。

```
例 画像などを1日キャッシュする
Chach-Control: max-age=86400
```

### 脆弱性
ブラウザは何の指定も無い場合はデフォルトでサーバーレスポンスを可能な場合にキャッシュします。  
この時サーバーレスポンスにユーザーのパスワード情報などが含まれていた場合に、何らの方法で攻撃者がユーザーの物理マシンにアクセス可能な状態であれば、マシンに保存されているブラウザキャッシュなどからパスワード情報を盗み出される可能性がある。

### 対策方法
Cache-Control を指定して、扱う情報に応じた適切なキャッシュ制御を行う。  
例えば、ユーザーの端末に保存するべきでない情報を含む場合は `nostore` を指定してキャッシュを保存しないようにする。

```
Cache-Control: nostore
```

## X-Frame-Options

### ヘッダーの説明
[X\-Frame\-Options \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options)

ブラウザが自分のWebページを \<iframe\> や \<object\> の中へ表示することを禁止することで、Webページが他のサイトに埋め込まれないことを保証することができます。

### 脆弱性の説明
適切に設定していない場合にクリックジャッキング攻撃に利用される可能性がある。

### クリックジャッキング攻撃
外部ページを埋め込んだiframeを透明化して通常のWebページの上に被せることで、攻撃者がユーザーに意図しない操作をさせる攻撃手法です。

例えば、次の要件を満たすようなサービスをユーザーが利用しているとします。

```
1. ログイン情報をCookieで管理している
2. same-site属性はnone
3. アカウント画面の削除ボタンを押すだけで確認なしでアカウントが削除できる
```

このとき対象サービスのアカウントページをiframeに埋め込み透明化した状態でWebページの上に重ねた場合、ユーザーがログイン済みであればユーザーのアカウントページが透明な状態で上に重なって表示されます。  
対象サービスの削除ボタンに重なる位置にクリックしたくなるようなリンクを配置することで、ユーザーに削除ボタンをクリックさせて、アカウントを削除するように誘導する事ができます。

### 対策方法
`X-Frame-Options: Deny` を指定する事で iframe 等へのページの埋め込みを禁止する。

## Content-Security-Policy（CSP）

### ヘッダーの説明
[コンテンツセキュリティポリシー $CSP$ \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/CSP)

インラインスクリプトの実行を禁止してXSSなどの攻撃を軽減する事ができます。

例えば、次のようにHTTPレスポンスヘッダーに含める事で、掲示板のサービスなどでサニタイズ処理をせず任意の文字列をサービスに埋め込める脆弱性があった場合でも、インラインスクリプトの実行ができないためXSS攻撃を軽減する事ができます。

```
# 外部ドメインのファイル読み込みやインラインスクリプトの実行を禁止する
Content-Security-Policy: default-src 'self'
```

IEは CSPの sandbox ディレクティブのみが利用可能になっており、IE9以下は CSP 未対応なので、次に紹介する X-XSS-Protection を利用する必要があります。

詳しい設定は上記のMDNのリンクを参照してください。

### 脆弱性の説明
掲示板などでユーザーが入力した値をサニタイズせずに画面上に表示していた場合にXSS攻撃を仕込まれる可能性がある。

### 注意点
外部ドメインからのスクリプト読み込みを禁止した場合に、CDN経由でのライブラリ読み込みなどが出来なくなってしまいます。  
そのため、自身のサービスの特性に合わせて適切に設定する必要があります。

例えば、次の設定をする事で自身のドメインと特定ドメインの CDN からのみスクリプト読み込みを許可する事ができます。  

```
Content-Security-Policy: default-src 'self' cdnjs.cloudflare.com
```

### 対策方法
Content-Security-Policyを適切に設定する。

※ CSPの設定とは別でユーザーが入力した値を表示する箇所で適切にサニタイズ処理はするべきです。

## X-XSS-Protection

### ヘッダーの説明
ブラウザがXSS攻撃を検出した時にページの読み込みを自動で停止します。

CSPが厳しく設定済みであれば、このヘッダーは本来不要です。  
しかし、ユーザーがCSPに未対応の古いブラウザ（IE9以下）を利用している場合に有効な対策になります。

## Strict-Transport-Security

### ヘッダーの説明

[Strict\-Transport\-Security \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security)

HTTPS でページにアクセスした時にHTTPレスポンスヘッダーに含めることで、次回以降はブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示する事ができます。  

初めてのユーザーが HTTP でページにアクセスした場合は Strict-Transport-Security 無視されるため、ユーザーが HTTPS アクセスを一度もしていない場合には有効でない事に注意してください。  
HTTPS アクセスをしてSSL証明書が確認されたタイミングで設定が有効になります。

```
# HTTPSアクセスの設定を1年間有効にする（有効期限はアクセスの度に更新される）
Strict-Transport-Security: max-age=31536000;
```

### 脆弱性の説明
HTTPアクセスが許可されている銀行サイトを普段から利用していたとします。  
カフェで無料のWifiに接続した状態で、その銀行サイトをHTTP経由で利用をしてしまった場合に、攻撃者にHTTPリクエストの内容を傍受され銀行口座やログイン情報などが盗まれる可能性があります。

### 対策方法
Strict-Transport-Security ヘッダーを指定する。

上の例では、もし銀行サイトが Security-Transport-Security を設定しており、一度でも HTTPS で銀行サイトにアクセスしていた場合には、誤ってHTTPアクスした場合でも HTTPS 経由で自動で接続されるため被害を防ぐことができます。


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

アクセス解析をするためにブログにGoogleアナリティクスを導入しました。\
今後イベント取得の度に、リリースをするのは面倒なので、Googleタグマネージャーを設定して、アナリティクスの計測を設定しています。

今回はGatsby製のブログにGoogleタグマネージャーを設定する方法をまとめておきます。

## Googleタグマネージャーのコンテナ作成

最初にGoogleタグマネージャーのコンテナを作成しておきます。

<img src="/images/posts/gatsbyjs-gtm/gtm-container-new.png" alt="コンテナの作成" width="714" height="619" />

## Googleアナリティクスの設定

管理 > +プロパティを作成 から新たに計測用のプロパティを作成しておきます。

## プラグインの追加

### gatsby-plugin-google-tagmanager

[gatsby-plugin-google-tagmanager](https://www.gatsbyjs.org/packages/gatsby-plugin-google-tagmanager/) を利用してGoogleタグマネージャーをページに埋め込みます。  
（\<head>タグに直接\<script>タグを埋め込む方法がが分からず、公式のプラグインがあったので利用しました。）

### インストール

```bash
$ yarn add gatsby-plugin-google-tagmanager
```

gastby-config.js にプラグインの設定を追記します。

```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',
  }
}
```

設定する値は 管理 > Live（公開中）> コードを取得 の埋め込みコードから確認することができます。

<img src="/images/posts/gatsbyjs-gtm/gtm-script.png" alt="Googleタグマネージャーの埋め込みコード" width="1171" height="368" />

## Googleタグマネージャーの設定

### トリガーの作成

GatsbyJSはSPAでCSRで動作するため、変更の履歴をトリガーとして作成しておきます。

### 変数の作成

GAのトラッキングIDを設定した Googleアナリティクス設定 を変数として設定します。

<img src="/images/posts/gatsbyjs-gtm/gtm-ga-variable.png" alt="Googleアナリティクスの変数を作成" width="720" height="290" />

### タグの作成

Googleアナリティクスにページビューを送信するタグを作成します。

Googleアナリティクスの設定には上で作成した変数を指定し、トリガーには「ページビュー」と「履歴の変更」の2つを設定しました。

初回のページ読み込みもトリガーさせるために、「ページビュー」も指定しています。

<img src="/images/posts/gatsbyjs-gtm/gtm-tag.png" alt="タグの作成" width="731" height="384" />

## リリース前の確認

Googleタグマネージャーのプレビューモードを利用すれば、ローカルで埋め込みが正常に出来ているか確認できます。  

ワークスペース > プレビュー をクリックしてプレビューモードにした後に、ローカルで ページを表示します。

その際は次の設定を true に変更しておく必要があります。

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

ワークスペース > プレビュー をクリックしてプレビューモードにした後に、ローカルでサーバーを立ち上げてページを表示します。

正常にタグが埋め込まれている場合は、ローカルで表示したページ下部にGoogleタグマネージャーのプレビュー画面が表示されます。

## リリース

以上の設定を終えたら、Googleタグマネージャーの公開 と プラグイン追加の変更を本番環境にリリースすれば導入は完了です。

## おまけ

自分のアクセスを計測対象外とするために [Google Analytics オプトアウト アドオン (by Google)](https://chrome.google.com/webstore/detail/google-analytics-opt-out/fllaojicojecljbmefodhfapmkghcbnh) を利用しています。  
「ga.jsと連携して...」と書いてありますが、Googleタグマネージャーを経由する場合でも正常に動作してくれました。


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

[gatsbyjs/gatsby-starter-blog](https://github.com/gatsbyjs/gatsby-starter-blog) で作成したブログはデフォルトの状態ではコードのシンタックハイライトが無く非常に見辛いです。
プラグインを設定してシンタックハイライトを導入します

## プラグインの導入
gatsby-starter-blog には最初から [gatsby-remark-prismjs](https://gatsbyjs.org/packages/gatsby-remark-prismjs) がプラグインとしてインストールされています。
そのため、新たにプラグインをインストールする必要はなく、ハイライトのcss読み込み設定を修正するだけでシンタックハイライトを有効化できます。

```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`,
        ],
      },
```

### CSSの読み込み設定
gatsby-browser.jsにて prismjs のテーマのCSS読み込みを追記します。  
デフォルトで利用できるテーマの一覧は [PrismJS/prism/themes](https://github.com/PrismJS/prism/tree/1d5047df37aacc900f8270b1c6215028f6988eb1/themes) で確認できます。

```js
import "prismjs/themes/prism-tomorrow.css"
```

## シンタックハイライトを利用
pre記法に言語タグを指定することでシンタックハイライトを利用できます。  
利用可能な言語タグの一覧は [prismjs](https://prismjs.com/#supported-languages) の公式ページに記載してあります。

~~~js
```js
console.log('シンタックハイライトだよ')
```
~~~


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

## Netfify CMSとは？

任意の静的サイトジェネレーターと組み合わせて利用可能なNetlifyが提供するCMSツールです。\
テキスト編集やプレビュー機能、画像アップロードなどの機能をWebベースのUIとして提供してくれます。\
また、GitHubのAPIを内部で利用しており、管理画面上で記事作成 => githubにpush => netlifyにデプロイ のフローを自動で実施してくれます。

## GastbyJSのテンプレートからブログを作成

立ち上げるブログが無いと何も始まりません。

最初に GatbyJS の [gatsbyjs/gatsby-starter-blog](https://github.com/gatsbyjs/gatsby-starter-blog) を利用してテンプレートからブログを作成します。

```shell
$ yarn add global gatsby-cli
$ gatsby new blog https://github.com/gatsbyjs/gatsby-starter-blog
```

たった2行でブログの作成が完了しました！\
デザインの修正とかやりだすと、やる事が増えて結局途中で諦めてしまう可能性がある（自分の性格上そうなる）ので、とりあえず公開する事だけを目標とします。  

デザインとかは後からゆっくり修正していきましょう。

### Netlify CMS をインストール

続いて Netlify CMS をインストールします。

```shell
$ cd blog
$ yarn add netlify-cms-app gatsby-plugin-netlify-cms
```

`static/admin/gatsby-config.yml` ファイルを作成して次の内容を貼り付けます。

```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" }
```

画像をアップロードする空ディレクトリを追加します。

```shell
$ mkdir -p static/images/uploaded
$ touch static/images/uploaded/.gitkeep
```

最後に `gatsby-config.js` にプラグインを追記します。

```
plugins: [`gatsby-plugin-netlify-cms`]
```

CMSのインストールはこれだけです。 すごい簡単で感動ですね。

実際にローカル環境で確認してみましょう。

```
$ yarn development
```

http://localhost:8000/admin にアクセスしてCMSのログイン画面が表示されたらOKです。 

ログインするには後述する Netlify の認証設定が必要です。

### ブログを公開する

ここまで来たら、いよいよNetlifyにブログを公開します。

最初にGitHubにリポジトリをデプロイします。

```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
```

続いて Netlify のページ上で `New Site From Git` を選択して手順に沿ってブログを公開します。

ビルド設定は次ように設定します。

```
Build Command: gatsby build
Publish directory: public/
```

<ブログのドメイン名>/admin にアクセスすれば管理画面を表示できます。

<img src="/images/posts/netlify-cms/blog-template.png" alt="テンプレートの画面" width="1930" height="1460" />

テンプレートのままですが、自分のブログが公開されました (*'ω'ﾉﾉﾞ☆ﾊﾟﾁﾊﾟﾁ

## CMSの管理ユーザーの作成

CMSの管理画面にログインするために Netlify の認証設定をして管理ユーザーを作成しましょう。 Netlifyの管理画面から公開したサイトを選択して次の手順に沿ってアカウント作成の作業を進めます。

1. Settings > Identity > Enable Identity を選択
2. Registration preferences > Edit Settings > Invite only を選択 この設定をしないと誰でもアカウントを作成して管理画面にログインできてしまうので、よほどの理由がない限りは設定しておくことをオススメします
3. Services > Git Gateway > Enable Git Gateway をクリック
4. Identityタブに移動 > Invite users をクリック 自分のメールアドレスを指定して自分を管理者として招待 送信された招待メールからアカウントを作成

これでCMSの管理画面にログイン出来るようになりました。

## 記事を投稿する

最後にCMSで最初の記事を投稿していきます。

1. /admin にアクセスして、管理画面にログイン
2. `new blog` をクリック
3. 記事を書いて `Save` をクリック
4. 問題なければ Publish をクリック

以上で記事が公開されます。


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

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