この記事は <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/2022/yamap-engineers" target="_blank">YAMAP エンジニア Advent Calendar 2022</a> 2日目の記事です。
<h2 id="結論">結論</h2>
<code>--max-warnings=0</code>をコミットフックで実行してあげることで問題は解消できます。
以下は実際にあった事例とコミットフックのサンプルコードです。
<h2 id="ESLintの警告が対応されずにプルリクが作成される問題">ESLintの警告が対応されずにプルリクが作成される問題</h2>
ESLintを導入していると、実装者がESLintの警告を対応し忘れたままプルリクを作成してしまうことが多々あります。GitHubではCIで警告が発生した時に自動でプルリクのコード差分に警告のメッセージをコメントとして残してくれますが、実装者は自分が作成したプルリクの差分を見ることをしないので自動コメントに気づかず、レビュアーが自動コメントと同じ箇所に同様のコメントをするという無駄な作業が発生します。
<img src="/images/posts/eslint-pr-warning/github-warning-comment.png" alt="githubの警告コメント" width="1082" height="690" />
<h2 id="レビューで指摘されずに警告が残ってしまう時もある">レビューで指摘されずに警告が残ってしまう時もある</h2>
レビュー時に気づいて削除できたら良いですが、レビュアーも指摘が漏れてそのままプルリクがマージされてしまい気づいたら数個の警告が残ったまま放置された状態になることもあります。GitHubでは差分の最後に警告コメントを雪だるま式に追記する形式になっているので、差分ページのスクロール量が増えて修正量が多いと錯覚を起こしたり小さなモヤっと感が開発者の中に溜まってしまいます。
こういった害はないけど少しモヤッとする状態は目に見えない形で開発者の精神衛生を悪くして、同じ対応を繰り返して無駄な作業工数を発生させてしまいます。
<ol>
<li>ESLintの警告の対応を忘れてマージされる</li>
<li>ESLintの警告がいくつか溜まった状態になる</li>
<li>気になってESLintの警告を全て削除する対応をする</li>
<li>1に戻る（以下ループ）</li>
</ol>
<h2 id="--max-warnings=0で警告をゼロにする">--max-warnings=0で警告をゼロにする</h2>
ESLintには最大の警告数を制限する<code>--max-warnings</code>というオプションがあり、<code>eslint --max-warnings=0</code>と実行をすることで、一つでも警告が存在するとESLintのチェックをエラーとすることができます。
コミットフックのタイミングで<code>--max-warnings=0</code>を指定してESLintを実行することで、警告が存在する場合のコミットを自動的に禁止にすることで、最終的に警告が存在する状態でプルリクが作られない仕組みを作ることができます。
実際にこの仕組みを導入するだけで、チーム内で定期的に発生していたプルリクでのESLintの警告は完全にゼロになりました。🎉
<pre class="language-json"><code class="language-json">"lint-staged": {
 "*.{js,jsx,ts,tsx}": [
 "eslint --max-warnings=0"
 ]
},
</code></pre>

GitHubでのプルリクのESlintで警告が残ったままになってしまう問題とその解決策です。

GitHubでのプルリクのESlintの警告をゼロにする

会社でG.I.Gプログラムに参加する機会を得たので、勉強がてら定期的にWebスクレイピングして結果をSlackに通知するBotをGoogle Cloudで構築してみました。
<h2 id="全体構成">全体構成</h2>
Cloud Functionsでスクレイピングを実行してSlackに結果を通知するHTTP関数を用意して、Cloud Scheduler で定期的にCloud FunctionsにHTTPリクエストを送信するジョブを実行することでBotを構築します。
<img src="/images/posts/gcp-scraping-bot/archecture.png" alt="構成図" width="873" height="245" />
<h2 id="スクレイピングを実装">スクレイピングを実装</h2>
まずはローカルでスクレイピングを実行するコードを実装します。 
HTMLの取得と解析には<a href="https://axios-http.com/" target="_blank">axios</a>と<a href="https://cheerio.js.org/" target="_blank">cheerio</a>を利用します。
<pre class="language-javascript"><code class="language-javascript">const cheerio = require('cheerio');
const axios = require('axios');

const scrape = async () => {
 const res = await axios.get(
 'https://xxxx/xxxx'
 );
 const $ = cheerio.load(res.data);

 // (省略)

 return 'スクレピングの結果';
};

const main = async () => {
 const result = await scrape();
 console.log(result);
}

main();
</code></pre>
<h2 id="Slackへの通知を実装">Slackへの通知を実装</h2>
続いてスクレイピング結果をSlackへ通知する部分を実装します。 
Slackへのメッセージ送信には<a href="https://slack.com/intl/ja-jp/help/articles/115005265063-Slack-%E3%81%A7%E3%81%AE-Incoming-Webhook-%E3%81%AE%E5%88%A9%E7%94%A8" target="_blank">Incoming Webhook</a>でWebhook URLを発行してPOSTリクエストを送信します。
<pre class="language-javascript"><code class="language-javascript">const notifyToSlack = (message) => {
 return axios.post(
 "https://hooks.slack.com/services/xxxxx/xxxxxx/xxxxx",
 {
 text: message,
 }
 );
}

const main = async () => {
 const result = await scrape();
 notifyToSlack(result);
}

main();
</code></pre>
<h2 id="Google Cloud CLIのインストール">Google Cloud CLIのインストール</h2>
Google Cloudの構築を始める前にターミナルで操作するためにCLIツールをインストールしておきます。 
ここではHomebrewでインストールをしていますが、インストール方法は何でも大丈夫です。
<pre class="language-shell"><code class="language-shell">$ brew install --cask google-cloud-sdk
</code></pre>
<code>gcloud</code> コマンドでGoogle Cloudを操作するために認証が必要なためログインをしておきます。
<pre class="language-shell"><code class="language-shell">$ gcloud auth login
</code></pre>
<h2 id="プロジェクトの作成">プロジェクトの作成</h2>
Google Cloud サービスを構築するためのプロジェクトをGoogle Cloudで作成しておきます。
<h2 id="Cloud FunctionsのHTTPハンドラ関数を実装">Cloud FunctionsのHTTPハンドラ関数を実装</h2>
Google Cloudでアプリケーションを構築してきます。 
Cloud Functionsの詳細なガイドについては<a href="https://cloud.googles.ltd/functions/docs/how-to?hl=ja" target="_blank">公式のガイド</a>を参照してください。
Cloud Functionsで関数を実行するには、<a href="https://github.com/GoogleCloudPlatform/functions-framework-nodejs" target="_blank">Functions Framework for Node.js</a>でHTTPリクエストのハンドラ関数を登録する必要があります。
最初に<code>@google-cloud/functions-framework</code>をインストールします。
<pre class="language-shell"><code class="language-shell">$ yarn add @google-cloud/functions-framework
</code></pre>
続いてスクレイピングと通知の処理をHTTPハンドラ関数として登録します。
<pre class="language-javascript"><code class="language-javascript">const functions = require("@google-cloud/functions-framework");
const cheerio = require("cheerio");

functions.http("checkReservation", async (_req, res) => {
 const result = await scrape();
 await notifyToSlack(result);
 res.send("ok");
});

// (省略)
</code></pre>
デプロイ前にローカルでテスト用のサーバーを起動して関数が実行されるか確認してみましょう。
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "start": "functions-framework --target=checkReservation"
 }
}
</code></pre>
<pre class="language-shell"><code class="language-shell">$ yarn start
Serving function...
Function: checkReservation
Signature type: http
URL: http://localhost:8080/
</code></pre>
HTTPリクエストを送信してSlackへメッセージが送信されるのを確認できれば成功です。
<pre class="language-shell"><code class="language-shell"># 別タブ等で実行
$ curl http://localhost:8080/checkReservation
ok
</code></pre>
<h2 id="Cloud Functionsへデプロイ">Cloud Functionsへデプロイ</h2>
詳細は公式ガイドの<a href="https://cloud.googles.ltd/functions/docs/deploy?hl=ja" target="_blank">Cloud Functions の関数をデプロイする</a>で確認できます。
関数をデプロイするには<code>gcloud functions deploy</code>コマンドを実行します。
<pre class="language-shell"><code class="language-shell">$ gcloud functions deploy YOUR_FUNCTION_NAME \
[--gen2] \
--region=YOUR_REGION \
--runtime=YOUR_RUNTIME \
--source=YOUR_SOURCE_LOCATION \
--entry-point=YOUR_CODE_ENTRYPOINT \
TRIGGER_FLAGS
</code></pre>
今回はHTTPリクエストでトリガーしたいので次のようにデプロイコマンドを作成しました。
<ul>
<li><code>--gen2</code>は第2世代のCloud Functionsにデプロイすることを指定しています。</li>
<li><code>--trigger-http</code>はHTTPリクエストで関数をトリガーするために指定します。</li>
<li><code>--allow-unauthenticated</code>は認証なしで関数を呼び出し可能にするために指定します。Cloud Functionsはデフォルトで<a href="https://cloud.googles.ltd/functions/docs/calling/http?hl=ja" target="_blank">関数の呼び出しに認証が必要</a>になっているので、このフラグを指定しています。</li>
</ul>
<pre class="language-shell"><code class="language-shell">$ gcloud functions deploy reservation-notify \
 --gen2 
 --region=asia-northeast1 \
 --runtime=nodejs16 \
 --source=. \
 --entry-point=checkReservation \
 --trigger-http \
 --allow-unauthenticated \
 --project=reservation-notify
</code></pre>
このコマンドをnpmスクリプトとして登録してデプロイを実行します。
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "deploy": "gcloud functions deploy reservation-notify --gen2 --region=asia-northeast1 --runtime=nodejs16 --source=. --entry-point=checkReservation --trigger-http --allow-unauthenticated --project=reservation-notify"
 }
}
</code></pre>
<pre class="language-shell"><code class="language-shell">$ yarn deploy
...
uri: https://reservation-vacancy-notify-xxxxxx.run.app
</code></pre>
デプロイが成功したら発行されたURLが確認できるので、HTTPリクエストを送信してみます。 
Slackにメッセージが送信されたら成功です。
<pre class="language-shell"><code class="language-shell">$ curl https://reservation-vacancy-notify-xxxxxx.run.app
ok
</code></pre>
<h2 id="Cloud Schedulerで定期実行">Cloud Schedulerで定期実行</h2>
<code>gcloud scheduler jobs create http</code>コマンドでHTTPリクエストのジョブを作成できます。 
定期実行のスケジュールはcrontabの書式で設定し、タイムゾーンを指定する場合は<a href="https://en.wikipedia.org/wiki/List_of_tz_database_time_zones" target="_blank">List of tz database time zones 
</a>にあるタイムゾーンを指定できます。
今回は先程のCloud Functionsへ5分おきにHTTPリクエストを送信するジョブを作成してみます。
5分ほど待ってSlackにメッセージが飛んでくるのを確認できたら成功です。
<pre class="language-shell"><code class="language-shell">$ gcloud scheduler jobs create http check-reservation \
 --schedule="*/5 * * * *" \
 --time-zone=Asia/Tokyo \
 --location=asia-northeast1 \
 --uri="https://reservation-vacancy-notify-rkqokacy7q-an.a.run.app" \
 --http-method=GET \
 --project="reservation-notify" \
</code></pre>

会社でG.I.Gプログラムに参加する機会を得たので、勉強がてら定期的にWebスクレイピングして結果をSlackに通知するBotをGoogle Cloudで構築してみました。

Google Cloud でWebスクレイピングして結果を通知するBotを作成

久しぶりに英語の学習意欲が高まってきました。
今までの英語学習の反省点として、次に何をするか分からなくなって学習が続かないことが多かったので、今回は最初に学習計画を作ってみることにしました。
<h2 id="目標設定">目標設定</h2>
目標: TOEIC 800点
今まで英語を学習する上で計測できる明確な目標が無かったのが続かなった原因の一つでした。TOEICは数値目標として非常に分かりやすく計測しやすいので目標に設定しています。
また自分は今までTOEICで点数が高くても英語が話せる訳ではないので、スコアを上げることを目標にする意味は無いと思ってました。ただ、それはTOEICで実際に高得点を取っている人が考えるべきことで、そもそも点数取れてない人がそれを言うのは間違っているなと思い直しました。
<h2 id="学習スキルの取捨選択">学習スキルの取捨選択</h2>
学習対象: リスニング、リーディングのみ
今回は学習の対象をリスニングとリーディングに絞ってみます。これは単純にTOEICの範囲に合わせている訳ではなく、英語のスキルは大きく分けてインプットとアウトプットの2つがあります。
コミュニケーションにおいて最も重要なことは聞くこととされており、相手が何を伝えたいかを知ることができないとコミュニケーションが成立しません。そのため、リスニングとリーディングというインプットのスキルに絞って学習を進めようと考えました。
経験上言いたいことを伝えるだけなら、中学レベルの英文法と単語を並べるだけでも言いたいことはある程度伝えられます。スピーキングを学習するには、誰かとコミュニケーションを取るのが一番早いと考えており、その時に一定レベルのリスニング力があればスピーキングの学習効率が格段に上がるだろうという目算から、まずはリスニングとしています。
<img src="/images/posts/learning-english-plan-1/english-skills.png" alt="英語のスキル" width="682" height="201" />
<h2 id="リスニング学習の計画">リスニング学習の計画</h2>
<h3 id="課題">課題</h3>
<ul>
<li>少しでも話すスピードが速くなると単語が全く聞き取れない
<ul>
<li>自分が思っている音と実際の音が異なる</li>
<li>語彙力が無いので知らない単語が出てくると単語として認識できていない</li>
</ul>
</li>
<li>単語が聞き取れても英語として話すスピードに合わせて意味を理解できない
<ul>
<li>英語を文章として速く読めないとリーディングの速度に付いていけない</li>
</ul>
</li>
</ul>
<h3 id="発音の強化">発音の強化</h3>
目的: 自分が考えている音と聞こえる音のギャップを小さくして、英単語を聞き取れるようにする
読んでた本でオススメされていた、「英語喉 50のメソッド」という本を1冊やってみる。
<ul>
<li><s><a href="https://www.amazon.co.jp/CD%E4%BB%98-%E8%8B%B1%E8%AA%9E%E5%96%89-50%E3%81%AE%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89-%E4%B8%8A%E5%B7%9D-%E4%B8%80%E7%A7%8B/dp/4384054629" target="_blank">CD2枚・音声DL付 英語喉 50のメソッド</a>を1冊やる</s>
<ul>
<li>喉発音という独自の方法を紹介しており発音記号も独自のものが用いられているため、一般的な発音記号で見ると同じ音が別の音として区別されていたので混乱した</li>
<li>例: map(mˈæp) と man(mˈæn)</li>
<li>単語の発音記号を調べて発音を知るというやり方が通用しなさそうなので、最初にやる本としては適切でなかった</li>
<li>発音は感覚は口とか舌とかの使い方の説明よりも分かりやすかったので、慣れてからやるのが良いかも</li>
</ul>
</li>
<li>[ ] <a href="https://www.amazon.co.jp/%E6%94%B9%E8%A8%823%E7%89%88-%E8%8B%B1%E8%AA%9E%E8%80%B3-%E7%99%BA%E9%9F%B3%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%A8%E3%83%AA%E3%82%B9%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B-%E6%9D%BE%E6%BE%A4-%E5%96%9C%E5%A5%BD/dp/4041112591/ref=asc_df_4041112591/?tag=jpgo-22&amp;linkCode=df0&amp;hvadid=342406018218&amp;hvpos=&amp;hvnetw=g&amp;hvrand=8268392157830656677&amp;hvpone=&amp;hvptwo=&amp;hvqmt=&amp;hvdev=c&amp;hvdvcmdl=&amp;hvlocint=&amp;hvlocphy=1009717&amp;hvtargid=pla-1204985206696&amp;psc=1&amp;th=1&amp;psc=1" target="_blank">英語耳 発音ができるとリスニングができる</a>を1冊やる</li>
</ul>
その後はシャドーイングを進める。 
最初にシャドーイングの方法について学習して、題材を見つけて本格的にシャドーイングをやってみる。
<ul>
<li>[ ] <a href="https://www.amazon.co.jp/gp/product/4902091577/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&amp;psc=1" target="_blank">決定版 英語シャドーイング[超入門]</a> を1冊やる</li>
<li>[ ] <a href="https://www.amazon.co.jp/CD%E4%BB%98-%E6%B1%BA%E5%AE%9A%E7%89%88-%E8%8B%B1%E8%AA%9E%E3%82%B7%E3%83%A3%E3%83%89%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%B0%E3%80%90%E6%94%B9%E8%A8%82%E6%96%B0%E7%89%88%E3%80%91-%E9%96%80%E7%94%B0-%E4%BF%AE%E5%B9%B3/dp/4864541027/ref=pd_vtp_sccl_3_2/357-2633239-1991806?pd_rd_w=6QIwk&amp;pf_rd_p=cbb45385-7b99-44b7-a528-bff5ddaa153d&amp;pf_rd_r=G1N3RMRQRYHDRMVXBPNP&amp;pd_rd_r=565a596e-ecec-4f9a-8e5d-1ae7bd831236&amp;pd_rd_wg=bgGzD&amp;pd_rd_i=4864541027&amp;psc=1" target="_blank">[CD付]決定版 英語シャドーイング【改訂新版】</a> を1冊やる</li>
</ul>
<h3 id="語彙力の強化">語彙力の強化</h3>
目的: 知っている単語を増やして単語を聞き取れるようにする
単語帳を1冊決めて何周も繰り返す。夜に単語を覚えて朝に覚えているかのチェックをするサイクルで回してみる。読んだ本にこのやり方がオススメと書いてあったので。
本は適当に調べらオススメで出てきたので選んだだけで、強いこだわりはない。
<ul>
<li>[ ] <a href="https://www.amazon.co.jp/TOEIC-TEST-%E5%87%BA%E3%82%8B%E5%8D%98%E7%89%B9%E6%80%A5-%E9%87%91%E3%81%AE%E3%83%95%E3%83%AC%E3%83%BC%E3%82%BA-%E7%89%B9%E6%80%A5%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4023315680" target="_blank">TOEIC L &amp; R TEST 出る単特急 金のフレーズ (TOEIC TEST 特急シリーズ)</a> を何周も繰り返す</li>
</ul>
<h3 id="英単語の聞き取り力を強化">英単語の聞き取り力を強化</h3>
目的: 英単語を聞き取れるようにする
10秒リスニングを試しにやってみる。
<ul>
<li>[ ] <a href="https://www.amazon.co.jp/dp/B08LNWRXYL/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank">【音声DL付】英語を聞きとる力が飛躍的にアップする新メソッド 10秒リスニング</a>を1冊やる。</li>
</ul>
<h3 id="リーディング力の強化">リーディング力の強化</h3>
目的: リスニングに合わせて英語の意味を理解できるようにする
リーディングの学習を進める。
<h3 id="リスニング力向上のチェック">リスニング力向上のチェック</h3>
目的: 学習方法が正しいかの振り返り
定期的にTOEICのリスニング問題を解いてみて、学習方法が効果があるか振り返る機会にする。全く成長を実感できない場合は学習方法を見直す。
<ul>
<li>TOEICのリスニング問題を解く</li>
</ul>
<h2 id="リーディングの学習">リーディングの学習</h2>
<h3 id="課題">課題</h3>
<ul>
<li>知らない単語が出てくると内容が理解できない
<ul>
<li>シンプルに単語を知らないだけ</li>
</ul>
</li>
<li>読むスピードが遅い
<ul>
<li>途中で修飾関係が分からなくなり、前に戻ったりすることが多く読むのに時間がかかっている</li>
<li>分の区切りが分からなくなり主語と動詞を見失うことがある</li>
</ul>
</li>
</ul>
<h3 id="語彙力の強化">語彙力の強化</h3>
目的: 知らない単語を減らしてテキストを意味を理解する
自分が文章の意味が理解できないと感じる時は、知らない単語がいっぱい出てくるテキストを読んでいる時なので、逆に考えると単語さえ知っていれば、かなりリーディング力は向上するはず。
やることはリスニング学習の「語彙力の強化」と同じ。
<h3 id="英文法の再学習">英文法の再学習</h3>
目的: 英語の文章構造を理解して修飾関係を素早く把握できるようにする
思ったよりも中高で学んだ英文法は忘れていたりする部分があると痛感したので、試しにゼロから学び直す。 
「リーディング教本」は「ベーシック教本」をやってみて、良さそうなら2冊目としてやる。
<ul>
<li>[ ] <a href="https://www.amazon.co.jp/%E8%8B%B1%E8%AA%9E%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E6%95%99%E6%9C%AC%E2%80%95%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E3%82%8F%E3%81%8B%E3%82%8B-%E8%96%AC%E8%A2%8B-%E5%96%84%E9%83%8E/dp/4327451975/ref=asc_df_4327451975/?tag=jpgo-22&amp;linkCode=df0&amp;hvadid=295673331009&amp;hvpos=&amp;hvnetw=g&amp;hvrand=14382258585393884515&amp;hvpone=&amp;hvptwo=&amp;hvqmt=&amp;hvdev=c&amp;hvdvcmdl=&amp;hvlocint=&amp;hvlocphy=1009717&amp;hvtargid=pla-523771724866&amp;psc=1&amp;th=1&amp;psc=1" target="_blank">英語ベーシック教本―ゼロからわかる</a>を1冊やる。</li>
<li>[ ] <a href="https://www.amazon.co.jp/%E5%9F%BA%E6%9C%AC%E3%81%8B%E3%82%89%E3%82%8F%E3%81%8B%E3%82%8B%E8%8B%B1%E8%AA%9E%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E6%95%99%E6%9C%AC-%E8%96%AC%E8%A2%8B-%E5%96%84%E9%83%8E/dp/4327451371/ref=pd_bxgy_img_sccl_1/357-2633239-1991806?pd_rd_w=MTx0G&amp;pf_rd_p=020fee25-8ced-4191-bce3-27e7ce0c0e3b&amp;pf_rd_r=7K9F3Q0ZEZA9G0PMKA0D&amp;pd_rd_r=205b0587-fb35-4fba-888d-b45b4572e37f&amp;pd_rd_wg=8YTLT&amp;pd_rd_i=4327451371&amp;psc=1" target="_blank">基本からわかる英語リーディング教本</a>を1冊やる。</li>
</ul>
<h3 id="リーディングの速度向上">リーディングの速度向上</h3>
目的: 英語を読む速度を速くしてリスニングで英語を理解できるようにする
時間がかかる時を振り返ってみると全体を読んでから、右から左へ逆方向へ英語を読んでいることがある。左から右へそのまま英語を読めるようにする。
海外の技術ブログの記事を次のやり方でひたすら読む。 
途中で構造がうまく理解できない文に遭遇した場合は、スラッシュリーディングをして構造を理解できるようにする。
<ol>
<li>全体を読み進める</li>
<li>知らない単語は全て意味を調べる</li>
<li>全体を読む</li>
<li>一定時間内に読み終わるまで3を繰り返す。</li>
</ol>
<ul>
<li>[x] <a href="https://www.amazon.co.jp/dp/B085XQQFMB/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank">日本語脳のまま英文がスラスラ読めるすごい英語読解術</a>を1冊やる。</li>
</ul>

久しぶりに英語の学習意欲が高まってきました。今までの英語学習の反省点として、次に何をするか分からなくなって学習が続かないことが多かったので、今回は最初に学習計画を作ってみることにしました。

英語の学習計画を作ってみたよ〜L&R編〜

今回は自分のプルリクエストを自分でレビューをするメリットについて話をしたいと思います。
<h2 id="セルフレビューとは">セルフレビューとは</h2>
自分が作成したプルリクエストに対して自分でレビューをすることをここではセルフレビューと呼んでいます。
自分は複雑な実装や大きめのプルリクエストを作成した場合は、レビューをお願いする前に自分のプルリクエストを自分でレビューするといった事を偶に実施しています。
<h2 id="セルフレビューのメリット">セルフレビューのメリット</h2>
<ul>
<li>非効率な実装、無駄な処理、消し忘れのデバッグコード、コメントを書いておくべき箇所を見つけられる</li>
<li>レビュー時に他の人が自分のコードをどう見えているか客観的に把握できる</li>
<li>レビューで細かな点を指摘される事が減り、レビュアーの負担が軽減される</li>
<li>細かい指摘が減ることでレビュー事態のコミュニケーション量が減るので、レビュイーの負担も軽減される</li>
</ul>
開発に集中をしていると視野が狭くなる事があるので、意外と実装後にプルリクエストを見ながら全体を俯瞰してみると、もっと効率的な書き方や読みやすい実装などに気づくことが多々あります。開発中は知識が全て頭に入っていたので理解していたコードも後で見返すと非常に理解しにくいなと感じる実装が見つかることもあり、コメントを書いておくべき箇所が見つかることもあります。
客観的にセルフレビューをすることで、レビュアーの人が疑問に感じてコメントを書きそうな場所も見えてくるので、その場合は事前に説明コメントを書いておくことで、レビュアーの負担を減らし全体のレビューにおけるコミュニケーション量を軽減できるので結果として全体のレビューの負担も減らすことができます。
このようにセルフレビューは自分の為だけでなく、レビュアーの人の為にもなります。 
レビューをお願いする時は、如何にレビュアーの人の負担を減らすかを考えるのは非常に大切です。
<h2 id="セルフレビュー駆動開発">セルフレビュー駆動開発</h2>
最初に動くコードを実装してプルリクエストを作成し、セルフレビューを実施してコメントを残して、そのコメントに対してコードを修正して改善を進めることで、セルフレビューによる駆動開発をすることもできます。
個人開発など誰かにレビューお願いしたいけど難しいパターンでは、このスタイルを試してみると意外と何もやらない時よりも綺麗なコード実装ができます。

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

プルリクエストのセルフレビューのススメ

この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の23日目の記事です。
自分は普段ターミナルでgitの操作をしているのですが、開発とレビューを並行して多くのブランチを切り替えたりするなど地味にgitの操作に時間を要する事が多く、効率化を求めて色々とgitエイリアスを設定したら良い感じになったのでまとめてみました。
<h2 id="git switch-pr">git switch-pr</h2>
<h3 id="課題">課題</h3>
自分がPRレビューをするためにブランチを切り替える時は「GitHub上でブランチ名をコピーしてターミナルに貼り付けて...」という作業をよくやっていました。 
1日に3,4件かそれ以上のPRレビューをしていると、この作業が地味にストレスとして感じていました。
<h3 id="改善">改善</h3>
<img src="/images/posts/good-git-alias/swpr.gif" alt="switch-prコマンドの実行の様子" width="641" height="296" />
<code>git switch-pr</code> はリモートリポジトリのプルリクの一覧からブランチ移動をするためのエイリアスです。
ブランチ名をコピペする手間が減りPRレビューが非常に快適になりました！
プルリクの一覧は <a href="https://github.com/cli/cli" target="_blank">GitHub CLI</a> で取得をしています。
自分が管理しやすいように <code>switch-pr</code> としてエイリアスを作成してから、その短縮形として別に <code>swpr</code> を設定するという設定をしています。
<pre class="language-shell"><code class="language-shell">// ~/.gitconfig
[alias]
 switch-pr = !gh pr list | awk '{print $(NF-1)}' | peco | xargs git switch
 swpr = switch-pr
</code></pre>
<h2 id="git history">git history</h2>
<h3 id="課題">課題</h3>
feature ブランチで開発を進めながらPRレビューをしていると、1日に3,4個のブランチを移動することもあります。 
複数のブランチを行き来する時に、わざわざブランチ名を思い出しながらブランチを切り替えるのは非常に面倒でした。 
特にチケットとPRを紐づけるためにブランチ名にチケット番号などを記載していると、余計に入力が大変になります。
<h3 id="改善">改善</h3>
<img src="/images/posts/good-git-alias/history.gif" alt="historyコマンドの実行の様子" width="641" height="296" />
<code>git history</code> は過去に移動したブランチ一覧からブランチを選択して移動ができるエイリアスです。
<code>peco</code> を使って一覧からブランチを選択可能にしているので、ブランチ名を覚えていなくてもスムーズに移動ができるようになりました。
<pre class="language-shell"><code class="language-shell">// ~/.gitconfig
[alias]
 history = !git --no-pager reflog | awk '$3 == \"checkout:\" &amp;&amp; /moving from/ {print $8}' | awk '!a[$0]++' | head | peco | xargs git checkout
</code></pre>
<h2 id="push.default current">push.default current</h2>
<h3 id="課題">課題</h3>
作業後に初めてブランチをプッシュする時は <code>git push origin feat/123-feature1</code> というような形式でプッシュをしていました。 
これは上流ブランチの紐付けが存在しないためです。
<h3 id="改善">改善</h3>
<code>git push</code> の引数を省略した場合の挙動は <code>push.default</code> で設定することができ <code>push.default current</code> を設定することで、作業中のブランチと同名のリモートブランチに対してpushしてくれるようになります。
この設定をすることで、初めてのプッシュでも <code>git push</code> だけでプッシュができるようになります。
<pre class="language-shell"><code class="language-shell">$ g config --global push.default current

~/.gitconfig
[push]
	default = current
</code></pre>
<h2 id="git create-pr">git create-pr</h2>
<h3 id="課題">課題</h3>
GitHub上でプルリクエスト(PR)を作成する場合に、初回プッシュをした場合はターミナル上にPR作成のURLを表示してくれます。 
しかし、2回目以降の場合はこのURLが表示されずGitHub上からPR作成を進める必要があります。 
正直、1回目のURLクリックだけでも面倒だと思っていたので、GitHub上で数クリックの操作が発生するのは非常に手間でした。
<h3 id="改善">改善</h3>
<img src="/images/posts/good-git-alias/create-pr.gif" alt="create-prコマンドの実行の様子" width="1425" height="810" />
<code>git create-pr</code> は現在の作業ブランチのプルリクエストを作成するGitHubのページをブラウザで表示するエイリアスです。 
ターミナル上でコマンド一つでPR作成の準備が整うので非常に快適になりました。
仕組みとしては GitHub CLI のコマンドをエイリアスで登録しているだけなので、複雑なことは何もしていません。
<pre class="language-shell"><code class="language-shell">~/.gitconfig
[alias]
 create-pr = !gh pr create --web
</code></pre>
<h2 id="git open-pr">git open-pr</h2>
<h3 id="課題">課題</h3>
コードレビュー時にローカルでコードを確認したり、レビューで指摘をもらった箇所の修正後に、改めてGitHub上のPRを表示したい時にいちいちブラウザでページ移動するのが面倒なことがあったりします。
<h3 id="改善">改善</h3>
<img src="/images/posts/good-git-alias/open-pr.gif" alt="open-prコマンドの実行の様子" width="1425" height="810" />
<code>git open-pr</code> は現在の作業ブランチのPRをブラウザで表示するエイリアスです。
これも GitHub CLI のコマンドをエイリアスで登録しているだけです。
<pre class="language-shell"><code class="language-shell">~/.gitconfig
[alias]
 create-pr = !gh pr view --web
</code></pre>

この記事は YAMAP エンジニア Advent Calendar 2021 の23日目の記事です。自分は普段ターミナルでgitの操作をしているのですが、開発とレビューを並行して多くのブランチを切り替えたりするなど地味にgitの操作に時間を要する事が多く、効率化を求めて色々とgitエイリアスを設定したら良い感じになったのでまとめてみました。

開発効率を劇的に改善しているgitエイリアスと設定

この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank">YAMAP エンジニア Advent Calendar 2021</a> の21日目の記事です。
<h2 id="ts-jestの課題感">ts-jestの課題感</h2>
ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。
YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。 
またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが開発効率に直結してきます。
そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。
<h2 id="導入効果">導入効果</h2>
@swc/jest に置き換えた結果、CIでのユニットテストの実行時間が1/2に短縮されました🎉
<table>
<thead>
<tr>
<th>変更前</th>
<th>変更後</th>
</tr>
</thead>
<tbody>
<tr>
<td>53s</td>
<td>21s</td>
</tr>
</tbody>
</table>
<h2 id="@swc/jest とは">@swc/jest とは</h2>
@sec/jest は Rust製の TypeScriptコンパイラーの swc を利用して作られた Jest の Transformer です。 
個人的に感じる @swc/jest のメリットは次の点です。
<ul>
<li>swc が Rust製のため ts-jest(tsc) と比較して、高速に動作する</li>
<li>設定を <code>jest.config.js</code> 内に書くことができるので、<code>tsconfig.test.json</code> のようにテスト用の tsconfig ファイルを持つ必要がない</li>
</ul>
<h2 id="ts-jest を @swc/jest に置き換える">ts-jest を @swc/jest に置き換える</h2>
まずはコンパイラー本体の<code>@swc/core</code>と Transformer の<code>@swc/jest</code>をインストールします。
<pre class="language-shell"><code class="language-shell">$ yarn install -D @swc/core @swc/jest
</code></pre>
変更前のJestの設定ファイルはこんな感じです。
<pre class="language-js"><code class="language-js">/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
 preset: 'ts-jest/presets/js-with-babel',
 testEnvironment: 'jsdom',
 (省略),
 globals: {
 'ts-jest': {
 tsconfig: '&lt;rootDir>/tsconfig.test.json',
 },
 },
};
</code></pre>
これを @swc/jest を使うように変更します。 
設定ファイル内に swc の設定を追加して <code>transform</code> を @swc/jest を使うように修正しています。 
また、tsconfigは不要になったので <code>globals</code> の設定ごと削除しています。
swc の設定項目についてはコメントに記載してあります。詳細は<a href="https://swc.rs/docs/configuration/compilation" target="_blank">公式ドキュメント</a>を参照ください。
<pre class="language-js"><code class="language-js">/** @type {import('@swc/core').Config} */
const swcConfig = {
 // ソースマップの出力を有効にする
 sourceMaps: true,
 module: {
 // JestがCommonJSでモジュールを読み込むのでCommonJS形式で出力する
 type: 'commonjs',
 },
 jsc: {
 parser: {
 // TypeScriptとしてコンパイルする
 syntax: 'typescript',
 // Reactのコンポーネントをテストしたいのでtsxのコンパイルを有効化
 tsx: true,
 },
 transform: {
 react: {
 // React の JSX トランスフォームの指定
 // Reactインポートの手間を省略するために React17 から導入された 
 // _jsx(react/jsx-runtime) の形式にコンパイルする
 runtime: 'automatic',
 },
 },
 },
};

/** @type {import('@jest/types').Config.InitialOptions} */
module.exports = {
 transform: {
 '^.+\\.(t|j)sx?$': ['@swc/jest', swcConfig],
 },
 (省略),
};
</code></pre>
<h2 id="コンパイラーが異なることによる懸念">コンパイラーが異なることによる懸念</h2>
babelで設定を書いている影響でプロダクションのコンパイルは引き続き tsc を使用しており、テストとプロダクションの実行環境でコンパイラーが異なる状況になってしまっています。コンパイラー依存の問題でテストでは正常に動くみたいな事が起こる可能性はあるかもとという懸念は少し持っています。
ただ、それによるバグが起こる可能性はかなり低くテスト実行の速度向上による開発効率化の方がメリットが大きいと判断しているので、そこは許容範囲かなと考えています。
<h2 id="さいごに">さいごに</h2>
思ったよりもスムーズに導入ができて特に問題が発生することもなく、今までと変わらずにテスト実行が使い続けれているので、導入して良かったです。

この記事は YAMAP エンジニア Advent Calendar 2021 の21日目の記事です。ts-jestを使っているとコンパイル時間の問題で地味にテストに実行がかかります。YAMAPではフロントエンドでもユニットテストを書き始めたので、約180ケースで1分ほどCIでテスト実行に時間がかかるようになりました。またTDDで開発を進めていると、開発中に非常に多くユニットテストを実行するので ts-jest の実行時間の遅さが、開発効率に直結してきます。そこで、ts-jest を @swc/jest に置き換えて、実行時間の改善を試みました。

実務でts-jestを@swc/jestに置き換えてCIの実行時間を1/2に短縮した

この記事は <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> の14日目の記事です。
<h2 id="経緯">経緯</h2>
ある時、チーム内のコードレビューをしていてスペルミスの指摘が目立つようになってきました。
スペルミスのチェックは人がやるより機械がやった方が早いということで、CIでスペルチェックを自動化してコードレビューで自動でスペルミスを指摘する仕組みを導入してみたので、導入方法とその後の効果をまとめました。
この記事で書いているコードは全て <a href="https://github.com/t-yng/ci-spell-check-sample" target="_blank">t-yng/ci-spell-check-sample</a> に置いてあります。
<h2 id="導入手段の検討">導入手段の検討</h2>
<h3 id="既存のGithub Actions">既存のGithub Actions</h3>
マーケットプレイスの GitHub Actions をリポジトリに導入するパターン。 
いくつか試したが期待する結果が得られなかったので、後述する GitHub Actions を自作する形式にした。
<ul>
<li><a href="https://typoci.com/" target="_blank">Typo CI</a>
<ul>
<li>Github Actions でリポジトリにスペルチェックを導入可能</li>
<li>調査段階では Github が 404 になっていたので詳細は調べてない</li>
<li>執筆時点(2021/12/13 時点）で確認したら参照可能になっていた</li>
</ul>
</li>
<li><a href="https://github.com/marketplace/actions/check-spelling" target="_blank">Check spelling</a>
<ul>
<li>調査時点では β版 の状態だった</li>
</ul>
</li>
<li><a href="https://github.com/marketplace/actions/misspell-fixer-action" target="_blank">misspell-fixer-action</a>
<ul>
<li>Developers.ioで<a href="https://dev.classmethod.jp/articles/spellcheck-on-actions/" target="_blank">オススメ記事</a>があった</li>
</ul>
</li>
</ul>
<h3 id="スペルチェックのライブラリを GitHub Actions に組み込む">スペルチェックのライブラリを GitHub Actions に組み込む</h3>
自前でスクリプトを書いて Github Actions を構築するパターン。 
<a href="https://github.com/streetsidesoftware/cspell" target="_blank">cspell</a> を GitHub Actions に組み込みCIを構築することにしました。
<ul>
<li>
<a href="https://github.com/client9/misspell" target="_blank">misspell</a>
<ul>
<li>試してみたが期待したようにスペルミスを判定してくれなかった</li>
<li>ライブラリとして JavaScript などの言語はサポート外に見えた</li>
</ul>
</li>
<li>
<a href="https://github.com/vlajos/misspell-fixer" target="_blank">misspell-fixer</a>
<ul>
<li>↑で挙げた misspell-fixer-action で利用されているライブラリ</li>
<li>環境構築が面倒そうだったので試してない</li>
</ul>
</li>
<li>
<a href="https://github.com/streetsidesoftware/cspell" target="_blank">cspell</a>
<ul>
<li>VSCode の拡張で圧倒的な人気を誇る <a href="https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker" target="_blank">Code Spell Checker 
</a> で利用されているライブラリ</li>
<li>cliがあり手軽に実行できるのとVSCodeの拡張として使われている実績がある</li>
<li>prismjs などのライブラリ名や固有名詞がスペルミスとして扱われる点だけがデメリット 
(単語辞書を作成すればスキップは可能）</li>
</ul>
</li>
</ul>
<h2 id="CIの構築">CIの構築</h2>
<h3 id="cspellの導入とnpmスクリプトの作成">cspellの導入とnpmスクリプトの作成</h3>
cspell のインストール
<pre class="language-shell"><code class="language-shell">$ yarn add -D cspell
</code></pre>
cspellの設定ファイル(.cspell.json)を作成
<pre class="language-json"><code class="language-json">// .cspell.json
{
 "version": "0.2",
 "language": "en",
 "words": [], // 固有名詞などチェックをスキップしたい単語を登録する
 "dictionaries": [
 "softwareTerms", 
 "misc",
 "companies",
 "typescript", 
 "node", 
 "html", 
 "css", 
 "fonts", 
 "filetypes", 
 "npm"
 ],
 "ignorePaths": [
 "**/node_modules/**",
 "**/.git/**",
 "**/.vscode/**",
 "**/.next/**",
 "**/__generated__/**",
 "**/package.json",
 "**/yarn-error.log",
 "**/yarn.lock"
 ]
}
</code></pre>
npmスクリプトの作成
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "spell-check": "cspell lint -c .cspell.json --show-suggestions"
 }
}
</code></pre>
適当にタイポがあるコードを作って実行してみる。 
スペルチェックが正常に動作して代替の単語の提案してくれる部分ができた。
<pre class="language-javascript"><code class="language-javascript">// src/index.js
const heloo = (name) => console.log(`hello, ${name}`);
</code></pre>
<pre class="language-shell"><code class="language-shell">$ yarn spell-check
1/1 ./src/index.js 597.00ms X
/Users/tomohiro/workspace/examples/ci-spell-check/src/index.js:1:7 - Unknown word (heloo) Suggestions: [helot, helio, hello, Helot, holo]
</code></pre>
<h3 id="GitHub Actions の実装">GitHub Actions の実装</h3>
スペルチェックを実行するスクリプトは作れたので、あとは GitHub Actions でスクリプトを実行するだけです。 
<code>.github/workflows/spell-check.yaml</code> を作成してプッシュしたタイミングでスペルチェックが走るようにします。
<pre class="language-yaml"><code class="language-yaml"># .github/workflows/spell-check.yaml
name: review-on-push

on: push

jobs:
 spell-check:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2

 - uses: actions/setup-node@v1
 with:
 node-version: '16.x'

 - name: Install Dependencies
 run: yarn install
 env:
 NODE_AUTH_TOKEN: ${{ secrets.AUTH_TOKEN_FOR_GITHUB_PKG }}

 - name: execute spell-check
 run: yarn spell-check
</code></pre>
<h3 id="Reviewdog でPRにコメントする">Reviewdog でPRにコメントする</h3>
今の状態はどこのコードでスペルミスが発生しているのか分かりにくい状態なので Reviewdog でPRにコメントします。 
さらに cspell はスペルミスが見つかった時にエラーとしてスクリプトが終了するので Reviewdog を通すことでCIがエラーとなるのを防ぐこともできます。
<pre class="language-yaml"><code class="language-yaml"># .github/workflows/spell-check.yaml
- uses: reviewdog/action-setup@v1
- run: reviewdog -version

(省略)

- name: execute spell-check
 env:
 REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: |
 yarn spell-check \
 | reviewdog -level=warning -efm="%f:%l:%c - %m" -reporter=github-pr-review
</code></pre>
これでスペルミスがあった時に Reviewdog がPRに自動でコメントしてくれます。
<img src="/images/posts/spell-check-ci/spell-check-reviewdog.png" alt="Reviewdogのコメント" width="1844" height="794" />
<h3 id="修正差分に対してのみスペルチェックを実行する">修正差分に対してのみスペルチェックを実行する</h3>
リポジトリが肥大化していくとスペルチェックの対象コードが膨大になりスペルチェックの実行に時間がかかるので、修正差分だけを対象としてスペルチェックを実行するようにします。
<pre class="language-yaml"><code class="language-yaml">- uses: actions/checkout@v2
 with:
 fetch-depth: 0 # 差分取得のために全てのブランチを取得する

(省略)

- name: execute spell-check
 env:
 REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: |
 git diff remotes/origin/$GITHUB_BASE_REF --name-only \ 
 | yarn spell-check \
 | reviewdog -level=warning -efm="%f:%l:%c - %m" -reporter=github-pr-review
</code></pre>
<h2 id="導入後の結果">導入後の結果</h2>
導入後はPRでスペルミスが自動で見つかり一定の効果を得ることができました。
しかし、デメリットでも書いたようにライブラリ名や固有名詞がスペルミスとして判定されてしまい、スペルミスでない単語もコメントで指摘されてしまっていました。この指摘が非常にノイズとなりコードレビューがやりづらくなってしまったので、結局CIは廃止する流れになりました。:smiling_face_with_tear:
<h2 id="結局どうしたか？">結局どうしたか？</h2>
最終的には個々人の開発エディタにプラグインとしてスペルチェックの拡張を導入して、開発中にスペルチェックに気づけるようにする形で落ち着き、結果としてコードレビューでスペルミスを指摘することはほぼ無くなりました！
正直言うと最初からこの方法で良いとも思っていたのですが、個々人の開発環境に依存する解決策はできれば避けたく個人的にやってみたかったという理由でCIを導入を試していました。
CIは廃止する流れになりましたが、チームの問題への意識が高まって結果としてスペルミスの問題を解消されたので良かったです。

この記事はYAMAP エンジニア Advent Calendar 2021の14日目の記事です。ある時、チーム内のコードレビューをしていてスペルミスの指摘が目立つようになってきました。スペルミスのチェックは人がやるより機械がやった方が早いということで、CIでスペルチェックを自動化してコードレビューで自動でスペルミスを指摘する仕組みを導入してみたので、導入方法とその後の効果をまとめました。

CIでスペルチェックを自動化してみたけど最終的にやめた話

この記事は <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年目になりますが未だにコードレビューが出来ると胸を張って言うことができません。予定よりも時間をかけてしまったり、そこまで指摘しなくても良かったなーという点を細かくレビューしてしまったり、逆に指摘すべき箇所を見逃してしまったりします。

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

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

記事一覧