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/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の警告コメント" loading="lazy" 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="構成図" loading="lazy" 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-plan-english-1/english-skills.png" alt="英語のスキル" loading="lazy" 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コマンドの実行の様子" loading="lazy" 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コマンドの実行の様子" loading="lazy" 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コマンドの実行の様子" loading="lazy" 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コマンドの実行の様子" loading="lazy" 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エイリアスと設定

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

記事一覧