<a href="https://fukuoka.a11yconf.net/" target="_blank">アクセシビリティカンファレンス福岡</a> に現地参加してきました。 
カンファレンスの発表内容のメモ書きで。
<h2 id="伝わるを拡張するアクセシビリティ">伝わるを拡張するアクセシビリティ</h2>
発表者: <a href="https://fukuoka.a11yconf.net/#speaker-majima" target="_blank">間嶋沙知さん</a>
<h3 id="アクセシビリティとは？">アクセシビリティとは？</h3>
<ul>
<li>Access + ability</li>
<li>アクセシビリティは0か100ではなく高めるもの</li>
<li>使えるレベルと満たしてから、使える状況の幅を広げる</li>
<li><a href="https://www.w3.org/WAI/perspective-videos/" target="_blank">Web Accessibility Perspective Video</a>
<ul>
<li>色々な状況でのa11yのメリットを紹介したビデオ</li>
</ul>
</li>
<li>a11yは障害者のためのものではない
<ul>
<li>怪我をして一時的に片手を使えない場合などもある</li>
<li>すべての人に意味がある</li>
</ul>
</li>
<li>障害のある人は既にニーズを知っているリードユーザーと見ることができる</li>
</ul>
<h3 id="「伝わる」を阻む壁を知る">「伝わる」を阻む壁を知る</h3>
<ul>
<li>5cmの壁があっても車椅子などでは超えるのが困難</li>
<li>壁が取り除かれるとみんなが便利になる</li>
<li>なにか壁を作るのか？
<ul>
<li>**「知らなかった」**が壁をつくる</li>
</ul>
</li>
<li>デザインをする時は「だれに」「何を」「どうやって」を考えるのが大事
<ul>
<li>アクセシビリティは新しい「知る」を教えてくれる。</li>
</ul>
</li>
</ul>
<h3 id="ここから始めるアクセシビリティ">ここから始めるアクセシビリティ</h3>
<ul>
<li>a11yはコストがかかるんでしょう？
<ul>
<li>上流から考慮すればコストを抑えれる</li>
<li>後から対応はコストが高い</li>
</ul>
</li>
<li>エンジニアが頑張るもの？デザイナーやディレクターができることはある？
<ul>
<li>企画・設計、デザイン、コンテンツ制作で取り組めることはたくさんある</li>
</ul>
</li>
<li>色覚特性をシミュレーションできるモバイルアプリ
<ul>
<li><a href="https://asada.website/cvsimulator/j/" target="_blank">色のシミュレータ</a></li>
<li>実際にそう見えている色ではないことに注意（あくまでシミュレーション）</li>
</ul>
</li>
<li>コントラストが低い問題は世界のサイトの80%で見受けられる
<ul>
<li>WCAGの1.4.11でコンストラスト比のガイドラインが決められている</li>
<li>使いたい色の役割を意識して配色をすると、コンストラストを適切に保てる</li>
</ul>
</li>
<li>WCAGを噛み砕いてアクセシビリティガイドラインを作成している国内企業のドキュメントを読むのがおすすめ
<ul>
<li>Freeee, Ameba, Liful, SmartHR</li>
</ul>
</li>
<li>コンテンツ制作
<ul>
<li>見出しをつけよう</li>
<li>ノンデザイナーズ、ガイドブック</li>
<li>情報を整理して内容ごとにまとめる</li>
<li>内容を予測できる見出しをつける</li>
</ul>
</li>
<li>代替テキストをつけよう</li>
<li><a href="https://www.aaa11y.com/" target="_blank">a11yギャラリー</a>はアクセシビリティ対応されたサイトが掲載されている</li>
<li>アクセシビリティに取り組むとデザインの視点や伝わる可能性が広がる
<ul>
<li>より良いデザイン</li>
<li>これまでのデザインを拡張する</li>
</ul>
</li>
<li>今日からできること
<ul>
<li>SNSの画像に代替テキストに入れてみる</li>
<li>今日のイベントについて周りの人と話してみる</li>
<li>気づいたこと、取り組んだことを発信してみる</li>
</ul>
</li>
</ul>
<h2 id="ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜">ウェブアクセシビリティ社内教育のすゝめ 〜品質か、営業か〜</h2>
発表者: <a href="https://fukuoka.a11yconf.net/#speaker-shibata" target="_blank">柴田宏仙さん</a> ✕ <a href="https://fukuoka.a11yconf.net/#speaker-ihara" target="_blank">伊原力也さん</a>
<h3 id="テーマについて">テーマについて</h3>
<ul>
<li>アクセシビリティに取り組む課題
<ul>
<li>知見がある人がいない/最適な人材がいない</li>
<li>何から手をつければ良いか分からない</li>
<li>リソースが足りない</li>
<li>開発予算がない</li>
<li>ビジネス上のインパクトが示しづらい</li>
<li>ユーザーからの要望がない</li>
</ul>
</li>
</ul>
<h3 id="品質について">品質について</h3>
<ul>
<li>div要素だけでHTMLが作られていたりスクリーンリーダーに対応できていない時に「もやもや」する人で溢れるチームになる</li>
<li>クリエイターは人が喜ぶサイトを作りたい</li>
<li>ステップ: 伝える =&gt; 見せる =&gt; やってもらう =&gt; 評価する</li>
<li>伝える
<ul>
<li>アクセシビリティやろうよ！と言っても共感は難しい</li>
<li>Webのすごさ（誰でも情報にアクセスできること）を伝えることで共感をしてもらう</li>
<li>耳で情報を得ている人でも自分たちのマークアップによって情報の収集をサポートできる</li>
<li>「武器になるHTML」に書いてあるよ</li>
</ul>
</li>
<li>見せる
<ul>
<li>自分たちのやっていることを他の人に見せる</li>
<li>サイトの拘りや競合サイトとの比較を見せる</li>
<li>フォント拡大への対応</li>
</ul>
</li>
<li>やってもらう
<ul>
<li>簡単にできることから</li>
<li>pxで文字サイズ指定されているモノをremに直したり</li>
</ul>
</li>
<li>評価する
<ul>
<li>やってもらった事に対して「うれしい」と感じれられるFBをする</li>
</ul>
</li>
</ul>
<h3 id="営業について">営業について</h3>
<ul>
<li>手元でひとりでやる =&gt; 仕事としてチームでやる</li>
<li>ポイント
<ul>
<li>3人以上でやろう</li>
<li>「やってみた」マインドでやってみる</li>
<li>表に出す（表に出すと中の人が見て、既成事実になる）</li>
</ul>
</li>
<li>社内でやってみる =&gt; 社内向けにまとめる =&gt; 社外向けになおす =&gt; 社外に出す =&gt; 中の人がみる</li>
<li>ステップ1 学んでみた
<ul>
<li>会社とアクセシビリティを紐付ける準備をする</li>
<li>勉強会レポートなどを社のブログ等で発信する</li>
</ul>
</li>
<li>ステップ2 調べてまとめてみた
<ul>
<li>アクセシビリティを調べて発信する</li>
<li>自治体サイトのa11y対応状況とか</li>
</ul>
</li>
<li>ステップ3 自分のところ直してみた
<ul>
<li>自分の裁量で触れるところを改善してみる</li>
</ul>
</li>
<li>ステップ4 仕事で一部やってみた
<ul>
<li>小さい、しかし意味のある単位で改善する</li>
</ul>
</li>
<li>ステップ5 仕事に組み込んでみた</li>
<li>ステップ6 仕事でまるっとやってみた
<ul>
<li>特定の機能をスクリーンリーダーでも使えるようにするとか</li>
</ul>
</li>
</ul>
<h3 id="まとめ">まとめ</h3>
ウェブにあるだけで圧倒的にアクセシブル
<h2 id="ヌーラボのウェブサイト課におけるアクセシビリティ関連の取組み">ヌーラボのウェブサイト課におけるアクセシビリティ関連の取組み</h2>
発表者: 松永知典さん
ヌーラボのミッション 
「&quot;このチームで一緒に仕事できてよかった&quot;を世界中に生み出していく。」
<h3 id="ミッションの作成">ミッションの作成</h3>
<ul>
<li>ワークショップでメンバーの相互理解をうかめてからミッションを作成
<ul>
<li>人生において大事な価値観を共有</li>
</ul>
</li>
<li>ミッション作成で実現したいこと
<ul>
<li>優先度を決める際の判断規準になる</li>
<li>自分のやっていることに誇りが持てる</li>
<li>困難にぶち当たった時にポジティブになれる</li>
</ul>
</li>
<li>気をつけたこと
<ul>
<li>会社の方向性や、ウェブサイト課、個人のwillの重なりを意識した</li>
<li>ミッションステートメントを一文で作成</li>
</ul>
</li>
</ul>
<h3 id="フロントエンドエンジニアの求人票を変更">フロントエンドエンジニアの求人票を変更</h3>
<ul>
<li>フロントエンドエンジニアからマークアップエンジニアに名称に変更</li>
<li>「セマンティックなマークアップを意識してWebサイトの開発に取り組める方」を記載
<ul>
<li>Webアプリの開発を主とした方々からの応募は減少傾向</li>
<li>マークアップからアクセシビリティの改善を意識して求職する方の応募が増えた</li>
</ul>
</li>
</ul>
<h3 id="社内へのアクセシビリティの浸透">社内へのアクセシビリティの浸透</h3>
<ul>
<li>社内の全体チャットへの投稿
<ul>
<li>「こちら」のリンクを止めましょうという話</li>
</ul>
</li>
<li>何が問題なのかハッキリしていて、分かりやすい</li>
</ul>
<h2 id="LINEヤフーにおけるこれからのアクセシビリティ">LINEヤフーにおけるこれからのアクセシビリティ</h2>
発表者: 岡崎晶彦さん・富田梓さん
<ul>
<li>a11yのタスクフォースのスタート</li>
<li>所属部署の年次の取り組みとして「アクセシビリティ」</li>
</ul>
<h3 id="TFの取り組み">TFの取り組み</h3>
<ul>
<li>障害当事者へのヒアリング
<ul>
<li>実際の理解が圧倒的に足りない</li>
<li>社内の視覚障害当事者を対象にしたヒアリング</li>
<li>視覚障害というもののグラデーションや、環境の多様性</li>
</ul>
</li>
<li>MeetUP 開催
<ul>
<li>社内イベント</li>
<li>頻度は2,3ヶ月に一回</li>
<li>当事者インタビュー、プロジェクトでの改善事情、色覚等区政</li>
<li>「アクセシビリティをやっている人間がいること」が見える</li>
</ul>
</li>
<li>ガイドラインの作成
<ul>
<li>WCAGはハードルが高い</li>
<li>他社のガイドラインをそのまま利用する？
<ul>
<li>社内向けにする場合に限界がある</li>
</ul>
</li>
<li>他社のガイドラインを参考に自社用のガイドラインを作成</li>
</ul>
</li>
<li>チェックリストと運用方法までドキュメント化</li>
</ul>
<h3 id="ドキュメントの浸透">ドキュメントの浸透</h3>
<ul>
<li>a11yブートキャンプを実施</li>
<li>完全な対応は諦める
<ul>
<li>ガイドラインを全部読んで理解する</li>
<li>読み合わせのガイドラインの項目を絞る</li>
</ul>
</li>
<li>最初の目標は、チェックを完了するところまでにした
<ul>
<li>見つかった問題はチケット作成</li>
</ul>
</li>
</ul>
<h3 id="a11yブートキャンプの実施">a11yブートキャンプの実施</h3>
<ul>
<li>全体スケジュール
<ul>
<li>2023/3~10月で全8回</li>
</ul>
</li>
</ul>
<h2 id="「違う人生を生きる人と一緒に働く」ということ">「違う人生を生きる人と一緒に働く」ということ</h2>
<h3 id="株式会社方角の設立の経緯">株式会社方角の設立の経緯</h3>
<ul>
<li>コロナ影響で就職が難しくフリーランスを初めて、そのまま仕事で会社として設立</li>
<li>エキマトペを制作</li>
<li>初期デザインへの対応
<ul>
<li>聴覚障がいの人が見慣れている横組み字幕を組むべき</li>
<li>手話をもっと大きく</li>
<li>情報の上にオノマトペを被せない方が良い</li>
</ul>
</li>
<li>世間の反応
<ul>
<li>聴覚障がいの人から色々な意見をもらえた</li>
<li>自分たちの言語が手話が大きく表示されていて嬉しい</li>
</ul>
</li>
<li>当事者が身近にいてもっと色々と知りたい
<ul>
<li>自社で雇用することにした</li>
</ul>
</li>
</ul>
<h3 id="コミュニケーションの仕方">コミュニケーションの仕方</h3>
<ul>
<li>対面では手話や筆談</li>
<li>リモートではテキストコミュニケーションを主としている</li>
<li>聴覚障がい者にも様々
<ul>
<li>手話を第一言語として日本語に苦手意識がある人とは、手話でコミュニケーション</li>
<li>唇を読み取れる人は口話で会話</li>
<li>盲ろうの人とは、テキストで会話</li>
<li>人によってコミュニケーションの手段を変えている</li>
</ul>
</li>
</ul>
<h2 id="デジタル庁でのアクセシビリティへの取り組み ―誰一人取り残されない、人にやさしいデジタル化をの実現に向けて―">デジタル庁でのアクセシビリティへの取り組み ―誰一人取り残されない、人にやさしいデジタル化をの実現に向けて―</h2>
アーカイブ禁止のためスキップ
<h2 id="今後やりたいと思ったこと">今後やりたいと思ったこと</h2>
<ul>
<li>業務で定期的に開催をしてくれているa11y勉強会で、半年・1年で達成したいことを洗い出してマイルストーンを作成
<ul>
<li>インプットが多くなっていると感じるので、プロダクトの改善という形でアウトプットを増やしていきたい</li>
</ul>
</li>
<li>業務でのa11yでの改善をブログなど何かしらの形で発信する</li>
<li><a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>を読む
<ul>
<li>コンポーネントやデザイントークンのライブラリ実装で<a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>を参考にしていく</li>
</ul>
</li>
<li><a href="https://www.digital.go.jp/" target="_blank">デジタル庁のサイト</a>のマークアップを読んでみる</li>
</ul>
<h2 id="感想">感想</h2>
<h3 id="セッションの感想">セッションの感想</h3>
アクセシビリティの社内への浸透など各社や各々の取り組みを色々と学べた。共通点として小さな改善を繰り返して共有していく事があり、継続して進めていける体制や仕組みづくりが大事なのかなと感じられ、a11yという話に限らない全てのことにおいて共通で適用される話だなと感じました。
片山さんのセッションでは、自分が想像している以上に障がい者と一緒に働くことの大変さや工夫が知れて、そこについて自分が全く考えたことがなかった事に気づけました。
デジタル庁のセッションでは、改めてデジタル庁がアクセシビリティへの対応として何をしていて、どのように進めているか聞けて非常に楽しかった。具体的な取り組みとして単に達成基準を満たせば良いということでも無いという話もあり、機械的に対応せずにちゃんと自分たちのプロダクトのことを考えていくことが大事。 
業務でのデザインシステムのライブラリ開発を進めているのに、困ったときに<a href="https://www.digital.go.jp/policies/servicedesign/designsystem" target="_blank">デジタル庁のデザインシステム</a>も参考にした方が良いな！という事に改めて気づけました。
<h3 id="参加しての感想">参加しての感想</h3>
コロナの関係もあり数年ぶりにカンファレンスに現地でオフライン参加できたが、会場独特の熱量や雰囲気はオフラインで参加しないと得られないものがあり、改めてオフラインの良さを実感できて非常に楽しかったです！

福岡で開催されたアクセシビリティカンファレンスの参加して聞いた発表内容のメモ書きです。

アクセシビリティカンファレンス福岡 参加メモ

このブログのCSSライブラリをVanillaExtractからLinariaに置き換えました。
Linariaに置き換えるにあたり全体のCSSを移行する必要がありデザイン崩れが心配だったので、Playwrightでビジュアルリグレッションテストを実施してデザイン崩れがないことを自動テストしました。
Playwrightの導入とLinariaへの移行は次のPRで確認できます。
<ul>
<li><a href="https://github.com/t-yng/blog/pull/543" target="_blank">Playwrightでのビジュアルリグレッションテストを導入 #543</a></li>
<li><a href="https://github.com/t-yng/blog/pull/544" target="_blank">vanilla-extractをlinariaに移行 #544</a></li>
</ul>
<h2 id="Playwrightのインストールと環境構築">Playwrightのインストールと環境構築</h2>
パッケージ単体としてインストールもできますが<code>create</code>コマンドを利用すれば、設定ファイルの自動生成など環境構築を自動で行ってくれます。
<pre class="language-sh"><code class="language-sh">$ yarn create playwright
</code></pre>
<h2 id="設定ファイルの修正">設定ファイルの修正</h2>
自動生成された設定ファイルを自分の好みに合わせて修正します。
<ul>
<li>VRTのスクリーンショットを管理しやすくするためにファイルパスを設定</li>
<li>テスト対象の端末を設定
<ul>
<li>Desktop ChromeとMobile Safari iPhoneSE の2つを対象とする</li>
</ul>
</li>
<li>webServerでテスト実行前にローカルサーバーを起動する設定を追加</li>
</ul>
<pre class="language-ts"><code class="language-ts">// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

/**
 * See https://playwright.dev/docs/test-configuration.
 */
export default defineConfig({
 testDir: './e2e',
 // スナップショットのファイルパスを設定
 snapshotPathTemplate:
 '{testDir}/__snapshots__/{testFilePath}/{projectName}{ext}',
 /* Run tests in files in parallel */
 fullyParallel: true,
 /* Reporter to use. See https://playwright.dev/docs/test-reporters */
 reporter: 'html',
 /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
 use: {
 /* Base URL to use in actions like `await page.goto('/')`. */
 baseURL: 'http://127.0.0.1:3000',

 /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
 trace: 'on-first-retry',
 },

 // テスト対象のブラウザを設定
 projects: [
 {
 name: 'Desktop Chrome',
 use: { ...devices['Desktop Chrome'] },
 },
 {
 name: 'Mobile Safari iPhoneSE',
 use: { ...devices['iPhone SE'] },
 },
 ],

 /* Run your local dev server before starting the tests */
 webServer: {
 command: 'yarn dev',
 url: 'http://127.0.0.1:3000',
 reuseExistingServer: !process.env.CI,
 },
});
</code></pre>
<h2 id="ビジュアルリグレッションテストの作成">ビジュアルリグレッションテストの作成</h2>
Playwrightでは内部的に画像差分比較の仕組みが導入されているので、ページを表示して<code>toHaveScreenshot</code>を実行するだけでビジュアルリグレッションテストを実現できます。
ページごとにテストファイルを作成していビジュアルリグレッションテストだけを実行するテストケースを実装していきます。
<pre class="language-ts"><code class="language-ts">// e2e/top.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<pre class="language-ts"><code class="language-ts">// e2e/post.spec.ts
import { test, expect } from '@playwright/test';

test('visual regression', async ({ page }) => {
 await page.goto('/post/improve-a11y');
 await expect(page).toHaveScreenshot({
 fullPage: true,
 animations: 'disabled',
 });
});
</code></pre>
<h2 id="スクリーンショットの作成">スクリーンショットの作成</h2>
初回実行時は差分となるスクリーンショットが存在しない状態なので、まずはベースとなるスクリーンショットを作成します。
<pre class="language-sh"><code class="language-sh"># 最初にスクリーンショットを作成
$ yarn playwright test --update-snapshots
</code></pre>
<h2 id="テストを実行">テストを実行</h2>
ビジュアルリグレッションの準備ができたので、実際にテストを実行してみます。
<pre class="language-sh"><code class="language-sh"># テスト実行
$ yarn playwright test

 4 failed
 [chromium] › post.spec.ts:3:5 › visual regression ──────────────────────────────────
 # 省略
</code></pre>
テストを実行したら画像の差分が発生して、テストに失敗しました。
<img src="/images/posts/playwright-vrt/failed.png" alt="ビジュアルリグレッションテストの結果" loading="lazy" width="2116" height="816">
コードを確認してみるとLinariaに移行するためにCSSの記述をJS ObjectからCSSスタイルに書き換えるにあたり、フォント指定の値が誤って文字列のままとなっていました。
ビジュアルリグレッションテストをしていなかったら、気づかずにそのままになっていました。
<pre class="language-css"><code class="language-css">/* 文字列で囲っているのでCSSの構文として正しくない */
font-family: "'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif";

/* 正しくはこう */
font-family: 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif;
</code></pre>
<h2 id="まとめ">まとめ</h2>
ビジュアルリグレッションテストを導入することで、マージ前に事前にバグに気づけて非常に良かったです。 
プライベートで個人開発をしていると第3者のコードレビューは基本無いので、自動テストで可能な限りバグを出さない仕組みを自動化するのはとても有益だなーと改めて実感しました。😊

今回は自分のプルリクエストを自分でレビューをするメリットについて話をしたいと思います。

Playwrightでビジュアルリグレッションテストを導入して安全にCSSライブラリを置き換える

Reactでフォーカス中にのみ表示されるポップアップをデバッグする時にハマったので解決法をまとめました。
<h2 id="直面した問題">直面した問題</h2>
次のようなinput要素にフォーカスが当たっている時だけ表示される、ポップアップのCSSをデバッグする状況を考えます。
<iframe width="100%" height="400px" src="https://stackblitz.com/edit/react-ts-gnwa6a?embed=1&file=App.tsx&view=preview"></iframe>
ポップアップが表示された状態でdevtoolsで対象のDOM要素をクリックすると、フォーカスが外れるためポップアップが消えてしまいます。
Reactでは状態に応じてDOM要素を描画しないことが多く、今回のケースでもポップアップのDOM要素がDOMツリーから消えてしまうためCSSを確認できなくなります。
<h2 id="Enable a focused page を有効にする">Enable a focused page を有効にする</h2>
More tools &gt; Rendering &gt; Enable a focused page を有効にすることで、この問題を解消できます。
この設定を有効にすることでページ全体がフォーカスされた状態を維持できるので、devtoolsをクリックしてもポップアップが消えずに残り続けてデバッグすることできます。
<img src="/images/posts/devtools-debug-only-focus-element/emulate-focus-page.png" alt="devtoolsでDOMをクリックしてもポップアップが非表示ならない様子" loading="lazy" width="1089" height="542">

フォーカス中にのみ表示されるDOM要素をChromeのdevtoolsでデバッグする方法について解説します

Reactでフォーカス中にのみ表示される要素をChromeのdevtoolsでデバッグする

HTMLを仕様に基づいて正しく書くには思ったよりも必要な専門知識が必要です。 
例えば以下のコードは<code>p</code>要素で許可されている内容は記述コンテンツのみなので、HTMLの仕様としては誤ったコードになります。
<pre class="language-html"><code class="language-html">&lt;p>
 &lt;h1>見出し&lt;/h1>
&lt;/p>
</code></pre>
<h2 id="HTMLの仕様に基づいてコーディングする目的">HTMLの仕様に基づいてコーディングする目的</h2>
先ほどのコードはHTMLとしては構文エラーとなりますが、ブラウザ上では問題なく表示されます。見た目上問題ないのであれば、些細な問題なので別に良いのでは？と思うかもしれません。
ページを閲覧する対象は人だけでなくスクリーンリーダーや検索BOTなどの機械も含まれます。これらの機械が正確にページを解釈するには、HTMLの仕様に基づいて正しく記述されている事が重要になってきます。
<h2 id="markuplintの導入">markuplintの導入</h2>
最初にも書いたように仕様に基づいてHTMLを記述するのは一定の専門知識が必要です。知識を持つ人がプルリクのタイミングでコードをチェックする事も可能ですが、それをするには全てコードをレビューする必要があり負担が膨大になります。
<a href="https://markuplint.dev/" target="_blank">markuplint</a>を利用することで、HTMLの構文チェックを自動化でき全員が実装の段階で構文エラーに気づく事ができるようになります。また、構文エラーを通してHTMLの仕様を学ぶことも出来るので一石二鳥です。
<h3 id="インストール">インストール</h3>
まずは必要なパッケージをインストールします。
<code>markuplint</code>パッケージはHTML構文チェクのコア機能を提供するCLIツールです。
<code>@markuplint/jsx-parser</code>パッケージはjsxで記述されたコードをHTML文字列にパースして構文チェック可能にするためのパッケージです。
<code>@markuplint/react-spec</code>パッケージはReactで定義されている<code>key</code>属性などを仕様として認識されるためのパッケージです。Reactのコードを構文チェックすると<code>error: 属性「key」は許可されていません (invalid-attr)</code>とHTML仕様に定義されていない<code>key</code>属性が不正な属性として検知されてしまうため、それを防ぐためにこのパッケージをインストールします。
vueやsvelteなどの他のライブラリに対応したparserやspecは<a href="https://github.com/markuplint/markuplint/tree/dev/packages/@markuplint" target="_blank">公式リポジトリ</a>で探すことができます。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint @markuplint/jsx-parser @markuplint/react-spec
</code></pre>
<h3 id="設定ファイルを作成">設定ファイルを作成</h3>
プロジェクトのルートに<code>.markuplintrc</code>を以下の内容で作成します。
<pre class="language-json"><code class="language-json">// .markuplintrc
{
 // テストファイルやストーリーファイルを除外
 "excludeFiles": [
 "./**/*.{test,spec,stories}.tsx"
 ],
 // ツールの推奨設定を利用
 "extends": [
 "markuplint:recommended"
 ],
 // jsxをHTMLテキストにパース
 "parser": {
 ".tsx$": "@markuplint/jsx-parser"
 },
 "specs": {
 ".tsx$": "@markuplint/react-spec"
 }

}
</code></pre>
<h3 id="構文チェックを実行する">構文チェックを実行する</h3>
実際に以下のコンポーネントファイルを対象として構文チェックを実行してみます。
<pre class="language-tsx"><code class="language-tsx">// src/
const Hello = () => {
 return (
 &lt;p>
 &lt;h1>こんにちは&lt;/h1>
 &lt;/p>
 )
}
</code></pre>
構文チェックの対象をblobパターンで指定をして実行をします。デフォルトでは対象ファイルの全て結果が表示されるので、<code>-p</code>オプションを付与することでエラーだけを出力するようにできます。
無事にHTMLの構文エラーが検出することができました。
<pre class="language-shell"><code class="language-shell">$ yarn markuplint -p src/**/*.tsx
&lt;markuplint> error: HTMLの仕様において、要素「p」の内容は妥当ではありません (permitted-contents) 
 4: ••••••••&lt;p>
 5: ••••••••••••&lt;h1>テスト&lt;/h1>
</code></pre>
VSCodeを利用している場合には<a href="https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint" target="_blank">markuplintプラグイン</a>もあるので、合わせてインストールしておくと便利です。

Reactのプロダクトにmarkuplintを導入する

freeeさんが公開しているアクセシビリティー・チェックリストを活用して個人のブログのアクセシビリティーをチェックして改善をしてみました。

個人ブログのアクセシビリティー・チェックと改善を実践してみた

この記事は<a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア アドベントカレンダー2022</a> 14日目の記事です。
業務でReactで実装されたフォームのパフォーマンス改善をしたので、その時の問題を一般化してパフォーマンス改善を体験できる練習問題を作ってみました。
<h2 id="練習問題">練習問題</h2>
Reactで<code>&lt;input&gt;</code>要素がリストで表示されており、<code>&lt;input&gt;</code>要素にテキストを入力してみると非常にレスポンスが遅い状態になっています。このレスポンス速度を改善するのが今回の問題です。
<iframe src="https://stackblitz.com/edit/react-ts-evcw6y?embed=1&file=src/App.tsx" style="width: 100%; height: 400px"></iframe>
ソースコードを眺めてみるとApp.tsxでTodoの一覧を管理しており<code>TotoList</code>コンポーネントを描画しています。 
<code>onChange</code>propsには<code>setTodos</code>を渡しておりTodoの一覧を更新します。
<pre class="language-tsx"><code class="language-tsx">// App.tsx
const initialTodos: TodoModel[] = [...Array(100)].map((_, i) => ({
 id: i,
 text: 'aaa',
}));

const App = () => {
 const [todos, setTodos] = useState(initialTodos);

 return (
 &lt;div>
 &lt;button
 onClick={() => {
 alert(todos[0].text);
 }}
 >
 保存
 &lt;/button>
 &lt;TodoList todos={todos} onChange={setTodos} />
 &lt;/div>
 );
};
</code></pre>
次に<code>TodoList</code>コンポーネントの実装を見てみます。
<code>TodoList</code>では<code>&lt;input&gt;</code>要素として<code>Todo</code>コンポーネントを描画しており、変更があったときに新しい<code>Todo</code>のオブジェクトを受け取り新しいTodoリストを引数としてpropsで渡された<code>onChange</code>コールバック関数を実行して、親要素に新しいTodoリストを渡しています。
<pre class="language-tsx"><code class="language-tsx">export const TodoList: FC&lt;TodoListProps> = ({ todos, onChange }) => {
 const handleChange = useCallback(
 (updatedTodo: TodoModel) => {
 const index = todos.findIndex((todo) => todo.id === updatedTodo.id);
 onChange?.([
 ...todos.slice(0, index),
 updatedTodo,
 ...todos.slice(index + 1),
 ]);
 },
 [onChange, todos]
 );

 return (
 &lt;ul>
 {todos.map((todo) => {
 return (
 &lt;li key={todo.id}>
 &lt;Todo todo={todo} onChange={handleChange} />
 &lt;/li>
 );
 })}
 &lt;/ul>
 );
};
</code></pre>
最後に<code>Todo</code>コンポーネントの実装を見てみます。
<code>Todo</code>コンポーネントではpropsで受け取った<code>todo</code>のテキストの内容を<code>&lt;input&gt;</code>要素のvalueとして表示しています。テキストが変更された時に新しいテキストでTodoオブジェクトを作成して<code>onChange</code>関数を実行して親要素に新しいTodoオブジェクトを渡しています。
<code>[...Array()]</code>はコンポーネントの描画速度を疑似的に遅くするために仕込んでいます。は問題を作成するための疑似コードなので、ここを削除しないでください。
<pre class="language-tsx"><code class="language-tsx">export const Todo: FC&lt;TodoProps> = memo(({ todo, onChange }) => {
 [...Array(100000)].forEach(() => 1 + 1);

 return (
 &lt;input
 type="text"
 defaultValue={todo.text}
 onChange={(evt) => {
 onChange({
 ...todo,
 text: evt.target.value,
 });
 }}
 />
 );
});
</code></pre>
このコンポーネント単体の描画速度は約10msほどになっており、実際の実装でも再現し得る問題になっています。
<img src="/images/posts/react-performance-question/profile.png" alt="プロファイルの結果" loading="lazy" width="1136" height="462">
<h2 id="解説">解説</h2>
問題の解答は別の記事で書こうと思います。 
興味があれば解いてみてください。

業務でReactのパフォーマンス改善をする機会があったので問題を一般化して練習問題を作ってみました

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

<h2 id="Google検索で見つかるサンプル実装の課題">Google検索で見つかるサンプル実装の課題</h2>
Checkboxのデザインをカスタマイズするには、従来のCheckboxでは難しく自前でCheckboxを実装する必要があります。Googleで「チェックボックス デザイン 変更」と検索して上位に出てくる記事を見ると次のサンプルのように<code>input[type=&quot;checkbox&quot;]</code>を<code>display:none</code>で非表示にしている実装が多くあります。
この実装では<code>&lt;input&gt;</code>要素にフォーカルを当てることができないため、Tabキーで選択してスペースでトグルするようなキーボード操作ができない状態になっています。 
また、スクリーンリーダーがチェックボックスを認識できないので、スクリーンリーダーユーザーはチェックボックスの存在に気づくことすらできません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/BadCheckbox/style.css&initialpath=?bad" style="width: 100%; height: 400px;"></iframe>
<h2 id="アクセシビリティを考慮してチェックボックスを実装">アクセシビリティを考慮してチェックボックスを実装</h2>
<code>display:none</code>だとフォーカスができなくなってしまうので、代わりに<code>opacity:0;</code>で<code>&lt;input&gt;</code>を非表示にします。 
<code>&lt;input&gt;</code>は非表示のままのため、フォーカスが当たっている時のデザインを追加します。
この考慮を入れて上げるだけで、キーボード操作可能になり操作性が上がりスクリーンリーダーユーザーもチェックボックスの操作が可能になります。
<pre class="language-css"><code class="language-css">/* src/GoodCheckbox/style.css */

/* 元のチェックボックス（非表示） */
input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

/* フォーカスが当たっている時のデザインを追加 */
input[type='checkbox']:focus-visible + label::before {
 border-color: blue;
}
</code></pre>
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/GoodCheckbox/style.css" style="width: 100%; height: 400px;"></iframe>
<h2 id="デザイン実装をリファクタする（おまけ）">デザイン実装をリファクタする（おまけ）</h2>
ここから先は好みの問題かもですが、CSSを利用したサンプル実装は疑似要素を使った実装になっており直感できないため、少し保守がしづらく感じます。疑似要素を使わずに直感的にデザイン指定できるようにリファクタをしてみます。
疑似要素を使わずにカスタムなチェックボックスを<code>&lt;span&gt;</code>タグで実装してCSSでデザインを指定することで、宣言的になり直感的に分かりやすくなりました。
チェックアイコンを<code>&lt;svg&gt;</code>タグで直接表示するように変更しています。この時の注意点としてチェックアイコンの画像は視覚的な情報なのでスクリーンリーダーユーザーにとっては唯のノイズになってしまいます。実際に<code>aria-hidden</code>を消してスクリーンリーダーに読み上げさせると、チェック済みの場合に「イメージ」という無駄な読み上げが発生します。そのため、忘れないように<code>&lt;svg aria-hidden=&quot;true&quot;&gt;</code>と設定してあげる必要があります。<code>@mui/icons-material</code>ではデフォルトで<code>aria-hidden=&quot;true&quot;</code>となるので別途指定はしていません。
<iframe src="https://stackblitz.com/edit/react-ts-2tdsqo?embed=1&file=src/Checkbox/Checkbox.tsx&initialpath=?refactor" style="width: 100%; height: 400px;"></iframe>
<pre class="language-tsx"><code class="language-tsx">// src/Checkbox/Checkbox.tsx

import * as React from 'react';
import CheckRoundedIcon from '@mui/icons-material/CheckRounded';
import './style.css';

type CheckboxProps = {
 checked: boolean;
 onChange: (event: React.ChangeEvent&lt;HTMLInputElement>) => void;
};

export const Checkbox: React.FC&lt;CheckboxProps> = ({ checked, onChange }) => {
 return (
 &lt;label className="checkbox">
 &lt;input type="checkbox" defaultChecked={checked} onChange={onChange} />
 &lt;span className="custom-checkbox">
 {checked &amp;&amp; &lt;CheckRoundedIcon fontSize="small" />}
 &lt;/span>
 &lt;span>ラベル&lt;/span>
 &lt;/label>
 );
};
</code></pre>
<pre class="language-css"><code class="language-css">/* src/Checkbox/Checkbox.tsx */

.checkbox {
 display: inline-flex;
 cursor: pointer;
 gap: 8px;
}

.checkbox input[type='checkbox'] {
 opacity: 0;
 position: absolute;
}

.checkbox .custom-checkbox {
 display: inline-block;
 width: 24px;
 height: 24px;
 border: 2px solid lightgray;
 border-radius: 4px;
 background-color: white;
 box-sizing: border-box;
}

.checkbox input[type='checkbox']:checked + .custom-checkbox {
 background-color: lightcoral;
}

.checkbox input[type='checkbox']:focus + .custom-checkbox {
 border-color: blue;
}
</code></pre>

アクセシビリティを考慮したカスタムなCheckboxを実装する方法です。

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップして便利なutil関数を実装します。

mswをラップした便利関数をつくる

この記事は <a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア Advent Calendar 2022</a> 7日目の記事です。
<h2 id="mswとは？">mswとは？</h2>
ネットワークレベルでAPIリクエストをモックできるAPIモックライブラリです。 
<a href="https://mswjs.io/" target="_blank">MSW – Seamless API mocking library for browser and Node | Mock Service Worker</a>
<h2 id="Node.js18とグローバルfetch()">Node.js18とグローバルfetch()</h2>
今までは<code>fetch()</code>を利用したフロントエンドのコードをNode.js環境でユニットテストを実行するには、グローバルスコープに<code>fetch()</code>が存在しないので、モックをしたりテスト実行時に<a href="https://github.com/node-fetch/node-fetch" target="_blank">node-fetch</a>をPolyfillとして適用してグローバルスコープに<code>fetch()</code>を生やすなどの対応をしていました。
Node.js18から新たにグローバルスコープのfetch APIがデフォルトで利用可能になり、モック対応をせずともテスト実行時に<code>fetch()</code>が利用できる状態になりました。
<h2 id="Node.js18環境でmswが動かない">Node.js18環境でmswが動かない</h2>
グローバルスコープでfetch APIが利用可能になったので、何の対応もせずそのままmswでテストを実行できると思い次のサンプルコードを実行したら、mswがAPIリクエストをインターセプトしてくれずリクエスエラーが発生して盛大にハマりました。 
<code>Caused by: Error: connect ECONNREFUSED ::1:3000</code>
当たり前に使えると思っていたので、無駄に時間を溶かしました。
<pre class="language-ts"><code class="language-ts">// User.tsx
export const User = () => {
 const [user, setUser] = useState&lt;User | null>(null);

 useEffect(() => {
 fetch("/user").then(async (res) => {
 const user = await res.json();
 setUser(user);
 });
 }, []);

 if (user == null) {
 return null;
 }

 return &lt;span>{user.name}&lt;/span>;
};

// User.test.tsx
import { rest } from "msw";
import { render, screen, waitFor } from "@testing-library/react";
import { server } from "../../test/server";

describe("User", () => {
 it("show user name", async () => {
 server.use(
 rest.get("/user", (_req, res, ctx) => {
 return res(ctx.json({ name: "taro" }));
 })
 );

 render(&lt;User />);
 await waitFor(() => expect(screen.getByText("taro")).toBeInTheDocument());
 });
});
</code></pre>
<h2 id="mswのインターセプターと対象モジュール">mswのインターセプターと対象モジュール</h2>
<a href="https://github.com/mswjs/interceptors" target="_blank">mswのインターセプター</a>は
<ul>
<li><code>http.get</code>/<code>http.request</code></li>
<li><code>https.get</code>/<code>https.request</code></li>
<li><code>XMLHttpRequest</code></li>
<li><code>window.fetch</code></li>
<li>その他のAPIクライアント(i.e. axios, request, node-fetch, supertest, etc.)</li>
</ul>
により発行されたリクエストを割り込み対象としてサポートしています。
Node.jsのfetch APIは標準の<code>http</code>モジュールを利用しておらず、<a href="https://github.com/nodejs/undici" target="_blank">undici</a>という別のモジュールによって実装されています。そのため、標準のfetch APIで発生したリクエストはmswのインターセプターの対象とならず今回のエラーが発生していました。
参考: <a href="https://shisama.hatenablog.com/entry/2022/04/20/011103" target="_blank">Node.js v18 の主な変更点</a>
<h2 id="node-fetchでfetch()を置き換える">node-fetchでfetch()を置き換える</h2>
現時点でmswを利用するには今まで通り<code>fetch()</code>をnode-fetchで置き換えてあげる必要があります。
<pre class="language-ts"><code class="language-ts">// test/setup.ts
import _fetch from "node-fetch";
import { server } from "./server";

// グローバルスコープのfetch()をnode-fetchで置き換える
// @ts-ignore
global.fetch = _fetch;

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// jest.config.js
module.exports = {
 setupFilesAfterEnv: ['./test/setup.ts'], 
}
</code></pre>
<h2 id="mswのFetch APIへの対応">mswのFetch APIへの対応</h2>
調べてみたら<a href="https://github.com/mswjs/interceptors/pull/283" target="_blank">標準のfetch APIに対応するPR</a>が既に作成されていたので、近い将来にはモック対応をせずにそのままmswが使えるかもです。

Node.js18の環境でmswを使った時にネットワークをインターセプトできない問題にハマった話です

Node.js18の環境でmswを使ったらハマった話

この記事は <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の結果" loading="lazy" 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" loading="lazy" width="735" height="385">
また巨大なjsファイルによりJavaScriptの「Script Evaluation」が 1,835ms と、長時間のレンダリングブロッキングが発生していました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-thread-work.png" alt="メインスレッドの実行時間" loading="lazy" 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の結果" loading="lazy" 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の結果" loading="lazy" 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の結果" loading="lazy" 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の結果" loading="lazy" 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" loading="lazy" 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を利用したイメージ図" loading="lazy" width="758" height="652">
<h2 id="ミニマックス法を用いたCPUの実装">ミニマックス法を用いたCPUの実装</h2>
ミニマックス法とは、オセロや将棋などのゲームアルゴリズムを実装する時に利用される事の多い探索手法の一つです。評価関数を用いて盤面の評価値を計算して、自分の手番では評価値が最大となり、相手の手番では評価値が最小となる最善手を選択するアルゴリズムです。
例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のためにAとBの2箇所に絞って探索を行い、2手先までを探索してみます。
<img src="/images/posts/wasm-othello/board.png" alt="盤面" loading="lazy" width="401" height="401">
相手は常に最前手を打つと予測するので、Aを打った場合は最大評価値は100となる位置に石を置いてきます。これに対してBに打った場合は最大評価値は15の位置に石を置いてきます。ここではBに打った方が自分が有利なので、Bを最善手として決定します。
<img src="/images/posts/wasm-othello/board_select_A.png" alt="Aに打った場合" loading="lazy" width="860" height="558">
<img src="/images/posts/wasm-othello/board_select_B.png" alt="Bに打った場合" loading="lazy" 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="処理速度のグラフ" loading="lazy" 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" loading="lazy" 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 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。
<img src="/images/posts/rust-ownership/memory2.png" alt="memory2" loading="lazy" width="524" height="372">
しかし、Rustでは対象のコードはコンパイルに成功して正常に実行されます。 
なぜでしょうか？
ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は <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" loading="lazy" 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" loading="lazy" 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="コンテナの作成" loading="lazy" 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タグマネージャーの埋め込みコード" loading="lazy" 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アナリティクスの変数を作成" loading="lazy" width="720" height="290">
<h3 id="タグの作成">タグの作成</h3>
Googleアナリティクスにページビューを送信するタグを作成します。
Googleアナリティクスの設定には上で作成した変数を指定し、トリガーには「ページビュー」と「履歴の変更」の2つを設定しました。
初回のページ読み込みもトリガーさせるために、「ページビュー」も指定しています。
<img src="/images/posts/gatsbyjs-gtm/gtm-tag.png" alt="タグの作成" loading="lazy" 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="テンプレートの画面" loading="lazy" 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 でエンジニアブログを立ち上げる

とあるフロントエンドエンジニアのブログ

フロントエンドの記事一覧

アクセシビリティカンファレンス福岡参加メモ

Playwrightでビジュアルリグレッションテストを導入して安全にCSSライブラリを置き換える

Reactでフォーカス中にのみ表示される要素をChromeのdevtoolsでデバッグする

Reactのプロダクトにmarkuplintを導入する

個人ブログのアクセシビリティー・チェックと改善を実践してみた

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップした便利関数をつくる

Node.js18の環境でmswを使ったらハマった話

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

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

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

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

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

ESLintをちゃんと理解する

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

WebAssemblyでオセロを作った話

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

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

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

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

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

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

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

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

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

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

フロントエンドの記事一覧

アクセシビリティカンファレンス福岡 参加メモ

Playwrightでビジュアルリグレッションテストを導入して安全にCSSライブラリを置き換える

Reactでフォーカス中にのみ表示される要素をChromeのdevtoolsでデバッグする

Reactのプロダクトにmarkuplintを導入する

個人ブログのアクセシビリティー・チェックと改善を実践してみた

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

アクセシビリティを考慮してチェックボックスのデザインを変更する

mswをラップした便利関数をつくる

Node.js18の環境でmswを使ったらハマった話

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

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

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

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

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

ESLintをちゃんと理解する

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

WebAssemblyでオセロを作った話

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

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

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

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

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

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

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

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

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

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

アクセシビリティカンファレンス福岡参加メモ