<p>少し前にこのブログをNext.jsからAstroにリプレイスしたのですが、リプレイス前には60ポイント程度だった<a href="https://pagespeed.web.dev/?hl=ja">PageSpeed Insights</a>のスコアがリプレイス後にはほぼ100ポイントになり、大幅なパフォーマンス改善をすることができました。<br>
本記事ではAstroというフレームワークの紹介と、実際にAstroのを使ってみた感想をお伝えできればと思います。</p>
<h1>Astroとは？</h1>
<p>Astroの公式ドキュメントでは次のように述べられています。</p>
<blockquote>
<p>Astroは、ブログやマーケティング、eコマースなど、<strong>コンテンツ駆動のウェブサイト</strong>を作成するためのウェブフレームワークです。Astroは、新しいフロントエンドアーキテクチャを開拓し、他のフレームワークと比較してJavaScriptのオーバーヘッドと複雑さを低減することで知られています。高速でSEOに優れたウェブサイトが必要なら、Astroが最適です。</p>
</blockquote>
<p>ここで大事なのは当然太字になっている部分、すなわち「コンテンツ駆動のウェブサイト」です。<br>
コンテンツ駆動のウェブサイトというのは上記引用の通り、ブログやホームページなどコンテンツが載っているだけの「ウェブサイト」のことを指します。<br>
逆を言うと、XやFacebookのように頻繁なデータフェッチが必要だったり、人によって表示されるコンテンツが動的に変わるような、いわゆる「Webアプリケーション」には向かないということです。</p>
<p>ここからもわかる通り、Astroにははっきりと向き不向きが存在しており、Next.js等通常のフレームワークのように「とりあえずこれを使えば何でも作れる」といったフレームワークではありません。<br>
ただし、使い所さえ間違えなければ抜群の効果を発揮するという類のフレームワークです。</p>
<p><a href="https://astro.build/">linkCard</a></p>
<h1>実際に使ってみた感想</h1>
<h2>メリット</h2>
<h3>開発体験が改善した</h3>
<p>Next.jsで開発していた際にはバンドラーがwebpackだったこともあってローカルでのサーバーの立ち上げやページ遷移がかなり遅かったです。<br>
この問題はかなり深刻で、以前にもMSWを使ってAPIアクセスをモックしたり、APIアクセスの最適化をしたりと様々な施策を行っていました。<br>
今回Astroへリプレイスしたことによってバンドラーがwebpackからviteになり、結果的に以前行った施策を上回る改善効果を得られました。</p>
<p>また、Next.jsで開発していた時には正直使っていない機能がかなり多く、開発に際しての学習コストがただただかかっているような状況でした。<br>
Astroは機能がかなり絞られているので学習ハードルが低く済んだのも開発体験的にはかなり良かったです。</p>
<h3>ページパフォーマンスが劇的に改善した</h3>
<p>タイトルでも述べている通りページパフォーマンスはかなり改善しました。<br>
Next.jsでの実装も開発当初はページ数が少なかったからか80ポイント程度のスコアが出ていたのですが、しばらく見ないうちに60ポイント前後になってしまっていました。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/b61e09e3-af67-4906-9808-d7318f9782b2/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-08-05214056.png" alt="スクリーンショット2024-08-05214056.png"></p>
<p>これがAstroにリプレイスしてからは、安定的に100ポイント近くのスコアが出ています。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/277c7a8d-1e5e-4e02-802f-bda9b9c69481/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-08-05214140.png" alt="スクリーンショット2024-08-05214140.png"></p>
<p>この結果に最も大きく寄与したのはやはりAstroのアイランドアーキテクチャによるパフォーマンス最適化でしょう。</p>
<p>AstroはNext.jsなどと違いSPAではありません。<br>
その代わりMPAとしては完全に最適化されており、build後の各ページの生成ファイルはhtmlのペライチです。<br>
client:loadディレクティブをつけていなければscriptタグすら含まれません。</p>
<p>Next.jsではJavaScriptのロードが重すぎることがパフォーマンスに最も大きく影響していたのですが、Astroでは見事にその部分の課題が解決された形です。</p>
<h3>様々なUIフレームワークに対応しているためリプレイスが容易だった</h3>
<p>AstroはReact、Vue、Svelteなどの多くのUIフレームワークのコンポーネントをサポートしています。<br>
極端に言えば以下のように最上位のコンポーネントのみをAstroコンポーネントにして、それ以下をすべてReactコンポーネントにすれば既存コンポーネントのほとんどを使いまわしながらすぐにページを表示することができます。</p>
<pre><code>---
import MyReactComponent from '../components/MyReactComponent.jsx';
---
&lt;html&gt;
  &lt;body&gt;
    &lt;MyReactComponent client:load /&gt;
  &lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>ただし、上記のようにclient:loadをつけるとその配下のコンポーネントではJavaScriptが読み込まれてしまうので、このままだとAstroのアイランドアーキテクチャを存分に活かすことはできません。<br>
Astroのアイランドアーキテクチャを活かすのであれば最低でも動きのないコンポーネントとその親コンポーネントはAstroコンポーネントとして作成するべきです。</p>
<p>とはいえ、ReactコンポーネントをAstroコンポーネントに置き換える際にも親コンポーネントから計画的に置き換えていけば画面を崩すこと無く実装することが可能です。<br>
そういう意味でも他のフレームワークに比べるとリプレイスはかなりやりやすいと思います。</p>
<h2>デメリット</h2>
<h3>CSS in JSが使えない</h3>
<p>これは正直かなり痛かったです。<br>
以前はMUIを使っていたのですが、MUIではCSS in JSが使われているためそのままAstroコンポーネントの配下に置いてもCSSが効かないです。<br>
今回の場合ページネーション等の機能をMUIに依存していたので、この部分のコンポーネントは新規で作成する必要があり工数がかかりました。</p>
<p>この件に関してはGithub上にissueはありますがまだ開発は行われていないようです。<br>
<a href="https://github.com/withastro/roadmap/discussions/778">linkCard</a></p>
<h3>Astroコンポーネントはstorybookでサポートされていない</h3>
<p>これも正直痛いです。<br>
コンポーネント駆動で開発をするならstorybookは必須のライブラリといっても過言ではありません。<br>
加えて、Chromaticによるビジュアルリグレッションテスト等を行うのであれば一層storybookの重要性は増します。</p>
<p>個人開発程度であればこれでも十分開発することは可能ですが、チーム開発だと特に不便しそうな部分ではあります。</p>
<p>これについてもGithub上にissueがあるだけの状態です。<br>
<a href="https://github.com/storybookjs/storybook/issues/18356">linkCard</a></p>
<h3>日本語資料が多くない</h3>
<p>これは最初こそ不便でしたが他のデメリットに比べると痛手ではありませんでした。<br>
確かに資料は少ないのですが、Astroは機能がそこまで複雑ではないので公式資料だけでかなりのところまで理解を深められます。<br>
また、公式資料は結構しっかりと日本語に翻訳されているのでその部分だけ読めば十分な開発が可能でした。</p>
<p>とはいえ、ページネーションと動的ルーティングを同時に使う場合など、細かいユースケースへの対応は公式ドキュメントだけだと詰まる部分もあったので今回はデメリットとしてあげています。</p>
<h1>まとめ</h1>
<p>今回はAstroについて使ってみた感想を書きました。<br>
本ブログのAstro実装は以下のリポジトリにあります。<br>
<a href="https://github.com/Asunaro276/asunaro-blog-astro">linkCard</a></p>
<p>また、Next.js実装も以下のリポジトリにあるので興味があれば覗いてみてください。<br>
<a href="https://github.com/Asunaro276/asunaro-blog">linkCard</a></p>


<p><span style="background-color: rgb(255, 255, 255);">少し前にこのブログをNext.jsからAstroにリプレイスしたのですが、リプレイス前には60ポイント程度だった</span><a href="https://pagespeed.web.dev/?hl=ja" rel="noopener noreferrer" target="_blank" style="background-color: rgb(255, 255, 255); color: rgb(0, 82, 217);">PageSpeed Insights</a><span style="background-color: rgb(255, 255, 255);">のスコアがリプレイス後にはほぼ100ポイントになり、大幅なパフォーマンス改善をすることができました。</span><br><span style="background-color: rgb(255, 255, 255);">本記事ではAstroというフレームワークの紹介と、実際にAstroのを使ってみた感想をお伝えできればと思います。</span></p>

個人ブログを作るならAstroが最強だと思う

<p>tblsというDBドキュメンテーションツールを、docker composeを使って最速で導入する方法を紹介します。</p>
<p><a href="https://github.com/k1LoW/tbls">linkCard</a></p>
<h1>なぜtblsなのか？</h1>
<p>tblsはDBドキュメンテーションツールで、データベースのスキーマに基づいてドキュメントを自動生成してくれます。<br>
また、ドキュメントを生成するだけでなく、生成されたドキュメントに基づいてテーブルやカラムにコメントが付けられているかなどをCI上でチェックすることもできます。<br>
このような特徴のおかげで運用のしやすいDBドキュメント環境を作ることができます。<br>
実際に作ったドキュメントは以下のようなものです。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/b333b98e-644a-4c17-9d6a-7fa733727b51/tbls_dbdoc.png" alt="tbls_dbdoc.png"></p>
<h1>tblsの使い方</h1>
<p>ここで紹介する実装は以下のリポジトリで公開しています。<br>
<a href="https://github.com/Asunaro276/cms-challenge">linkCard</a></p>
<h2>compose.ymlを書く</h2>
<p>tblsの最も簡単な導入方法はdocker composeを使うことです。<br>
この方法では設定ファイルさえ作ればコマンド一つでドキュメントを生成できます。</p>
<p>設定はcompose.ymlに書き、書く内容はGitHubのREADMEにあるものを参考に書きます。</p>
<pre><code>version: &quot;3&quot;

services:
  db:
    image: mysql:8.3
    platform: linux/amd64
    environment:
      MYSQL_DATABASE: cms 
      MYSQL_USER: asunaro
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password
    ports:
      - &quot;3306:3306&quot;
    volumes:
      - db_volume:/var/lib/mysql:cached
      - ./db/conf.d:/etc/mysql/conf.d
  migrate:
    build: ./db/migrations
    depends_on:
      - db
    command: [&quot;up&quot;]
    environment:
      WAIT_HOSTS: db:3306
      MIGRATIONS_DIR: /migrations
      MYSQL_HOST: db
      MYSQL_PORT: 3306
      MYSQL_DATABASE: cms
      MYSQL_USER: asunaro
      MYSQL_PASSWORD: password
    volumes:
      - ./db/migrations/migrations:/migrations
  tbls:
    image: ghcr.io/k1low/tbls
    working_dir: /db
    volumes: 
    - ./db/:/db
    depends_on:
      - migrate
    entrypoint: &gt; 
      tbls doc mysql://asunaro:password@db:3306/cms

volumes:
  db_volume:
    driver: local
</code></pre>
<p>ここでは以下の3つのサービスを定義しています。</p>
<ul>
<li>db</li>
<li>migrate</li>
<li>tbls</li>
</ul>
<p>dbはその名の通りmysqlのコンテナを作ります。<br>
migrateはDBマイグレーションを行うためのサービスです。（これに関しては別記事で紹介する予定です）<br>
そして3つ目のtblsがDBドキュメントを生成するサービスです。</p>
<p>DBドキュメントの生成にはmysqlコンテナが立ち上がっているのはもちろんのことmigrateも行われている必要がありますのでdepends_onにmigrateを設定しています。<br>
また、volumesを設定しているのはdbドキュメントがコンテナ内に生成された際にそれをホスト側に反映させるためです。<br>
ここではコンテナ内のdbディレクトリをローカルのdbディレクトリにマウントさせ、コンテナ内のworking_dirをdbディレクトリに設定することでdb配下に吐き出したDBドキュメントがホストのdbディレクトリにそのまま反映されます。</p>
<p>このような設定を行ったうえで以下のコマンドを実行すればDBドキュメントを実際に生成することができます。</p>
<pre><code>docker compose up
</code></pre>
<h2>tblsの設定ファイルを書く</h2>
<p>tblsはドキュメントを生成する際にも様々な機能を使うことができ、代表的なものとしては以下に挙げるようなものがあります。</p>
<ul>
<li>viewpointsを使っていくつかのテーブルをまとめることができる</li>
<li>relationsで外部キー制約を設定せずともカラムの参照関係を表現できる</li>
<li>commentsを使ってスキーマに定義されていないコメントをドキュメントに記載できる</li>
</ul>
<p>これらの機能は<code>tbls.yml</code>という設定ファイル内に書くことでドキュメントに反映することができます。</p>
<h1>tblsのちょっと残念な点</h1>
<p>このように非常に簡単にDBドキュメント環境を作れるtblsですが、いくつか残念な点もあります。<br>
中でも自分が困ったのは以下の2つです。</p>
<ul>
<li>カラム同士の参照関係を自動判定する際の自由度が少ない</li>
<li>アウトプットとしてhtmlを指定できない</li>
</ul>
<p>前者は例えばsome_table.user_id -&gt; user.idなどの参照関係は自動判定できますが、some_table.user_id -&gt; user.user_idのように少し異なる命名規則を採用している場合には検出できなくなります。<br>
これに関してはrelations機能を使えばカバーできるのですが、どうしても運用に一手間かかってしまいます。</p>
<p>また、後者に関してはおそらくtblsがGitHub等で直接見れるドキュメントを生成することを目的としていることに起因しています。<br>
tblsのこの方針はドキュメントのインデックスページがREADME.mdとして吐き出されることからも察せられます。<br>
確かにエンジニアだけがDBドキュメントを見るのであればGitHub上で見れさえすれば全く問題ありません。<br>
ただ、得てしてDBドキュメントを欲しがっているのはシステムに明るくないPdMや営業さんだったりします。<br>
そして、これらの非エンジニアはGitHubのアカウントを持っていなかったりします。<br>
そうするとこれらのメンバーはGitHub上で直接ドキュメントを見ることはもちろんできず、GitHub Pages上でも見ることはできません。<br>
となるとS3等の静的ホスティングサービスを使うことになりますが、そのためにはmdファイルをhtmlファイルに変換する必要があります。<br>
mdファイルをhtmlファイルに変換するツールとしてはMkDocs等が有名なので、もちろんやろうと思えば可能ですが一手間かかってしまうのは事実です。</p>
<p><a href="https://www.mkdocs.org/">linkCard</a></p>
<h1>まとめ</h1>
<p>本記事ではDBドキュメントをおそらく最も簡単に生成する方法を紹介しました。<br>
ドキュメントは運用されなければ意味がありません。<br>
tblsは手軽に導入できるだけでなくそのような負担を軽減しつつ運用できるのでDBドキュメントを作りたい方にとってはかなりいいソリューションになり得ると思います。</p>


<p>tblsというDBドキュメンテーションツールを、docker composeを使って最速で導入する方法を紹介します。</p>

docker-compose × tblsでDBドキュメント環境を最速構築する｜データベース

<p>本記事ではクリーンアーキテクチャを0から理解することを目標としています。できるだけ優しく直感的に分かる形で書いていこうと思うのでどうぞお付き合いください。</p>

0から分かるクリーンアーキテクチャ（概要編）｜フロントエンド

<p>本エントリーではnuxt.jsやnext.jsでのレンダリングモード周りの話と挙動の違いについてまとめてみます。</p>

SPA、SSR、SSGってなんだ？｜フロントエンド

<p>お久しぶりの投稿です。<br>
PCが弱弱すぎたことと社会人生活1年めが忙しくてブログの更新ができていませんでした。<br>
今回は、今度LPICを受けることになったのでその学習のためにUbuntuをMacのDocker上で作った話をします。</p>
<h1>Dockerの概要</h1>
<h2>コンテナ型仮想化とは？</h2>
<p>Dockerについて説明するにはDockerが実現しようとしているコンテナ型仮想化という技術について説明する必要があります。</p>
<p>コンテナ型仮想化というのは、簡単に言うと軽量な仮想環境のことです。<br>
ここで言うコンテナというのは皆様が想像される通りのあの箱のことです。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/3e40e67a-6af1-4dd5-9f08-cb83b655c801/image.webp" alt="image.webp"></p>
<p>イメージとしては<strong>箱の中に必要なものだけを詰めてアプリケーションを動かす感じ</strong>です。<br>
これによって</p>
<ul>
<li>運ぶ（配布する）のが楽になる</li>
<li>同じような仕組み（Dockerfileなど）を使うことで効率よく環境構築ができる</li>
<li>開発環境で作ったものをそのままコンテナに入れて本番環境にデプロイできる</li>
</ul>
<p>といったようなメリットがあります。</p>
<p>技術的にはコンテナ型仮想化はゲストOSを使わない仮想化というのが一般的な説明です。<br>
OSなしでどうやってアプリケーションを動かすのか？というと、ホストOSの力を借ります。<br>
すなわち、ホストOSのカーネル（OSの重要な機能）を借りることでCPUやメモリにアクセスすることができます。<br>
環境の中にカーネルが入っていないというためにコンテナは軽量かつ高速になるというからくりです。</p>
<p>とはいえ、ではどんなOSのカーネルでも借りてくることができるのか？というとそんなことはなく、Linuxのカーネルしか借りてくることができません。<br>
そのため、WindowsやMac上でコンテナを使うにはまずLinuxをゲストOSとして導入するか、あるいは別途Linuxカーネルを用意する必要があります。<br>
本記事ではColimaを使ってこの環境を整えます。</p>
<h2>Dockerとは？</h2>
<blockquote>
<p>Docker（ドッカー）は、コンテナ仮想化を用いてアプリケーションを開発・配置・実行するためのオープンプラットフォームである。<br>
出典: フリー百科事典『ウィキペディア（Wikipedia）』</p>
</blockquote>
<p>Dockerはコンテナ型仮想環境を扱う上でのデファクトスタンダードとなっているツールです。<br>
Docker Hubを使ってDockerイメージ（コンテナを作るための設計書）を配布することができるなど、コンテナを扱う上で便利な機能を有しています。</p>
<h1>Colimaを使ったDocker環境の構築</h1>
<h2>Colimaとは？</h2>
<p><a href="https://github.com/abiosoft/colima">linkCard</a><br>
CoilimaというのはMac OSとLinux上でDockerを動かすためのランタイム（ツール）です。<br>
前節で述べた通りDockerはLinux上でしか動きません。<br>
Colimaは<a href="https://github.com/lima-vm/lima">Lima</a>というMac用のLinux仮想環境のラッパーでDockerによるコンテナ仮想環境を動かすことに特化したものです。</p>
<p>Mac上でDockerを動かす方法にはColimaの他にDocker Desktopを用いる方法もありますが、今回はColimaを使ってみます。</p>
<h2>Colimaの導入と起動</h2>
<p>Colimaの導入は基本的に上記のgithubに従えば問題ありません。<br>
今回はbrewを使ってインストールします。</p>
<pre><code>brew install colima
</code></pre>
<p>インストールが完了したら以下のコードでColimaが起動します。</p>
<pre><code>colima start
</code></pre>
<p>これだけでDockerを動かすことができます。<br>
非常に簡単ですね。</p>
<p>ただし、肝心のDockerが入っていなければどうしようもないので、ここからはDockerのインストールについて説明します。</p>
<h2>Dockerをインストールして起動</h2>
<p>Dockerもbrewを使ってインストールすることができます。</p>
<pre><code>brew install docker docker-compose
docker ps
</code></pre>
<p>dockerが正しく入っていて、なおかつColimaが正常に動いていればcontainer idなどのテーブルが表示されます。</p>
<h2>Docker上にUbuntuを構築</h2>
<p>ここからはDocker上に実際にUbuntu環境を構築していきます。<br>
といっても特段難しいことはなく、イメージを作成→起動を行うだけです。</p>
<p>今回はDockerfileを使ってDockerイメージを作成します。<br>
Docker Hubからイメージを取得して、それを起動させるだけでももちろんUbuntu環境を構築することはできますが、Dockerfileを使うとコンテナのビルド時に色々な設定（主にパッケージのインストール）を済ませることができるので後から設定する手間が省けます。</p>
<p>今回は以下のようなDockerfileを用意しました。</p>
<pre><code>FROM ubuntu:20.04

ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime &amp;&amp; echo $TZ &gt; /etc/timezone

# 以下に行いたい設定を記入
RUN apt-get update &amp;&amp; apt-get upgrade
RUN apt-get install -y binutils build-essential golang sysstat python3-matplotlib python3-pil fonts-takao fio qemu-kvm virt-manager libvirt-clients virtinst jp docker.io containerd libvirt-daemon-system
RUN adduser `id -un ` libvirt
RUN adduser `id -un ` libvirt-qemu
RUN adduser `id -un ` kvm
</code></pre>
<p>最初の行はubuntu20.04のイメージをDocker Hubから取得しています。<br>
その次でタイムゾーンの設定をしています。<br>
その後にパッケージのインストールなどを行っています。<br>
今回は以下の本の環境を作りたかったので、そのような設定を行っていますが、ここは作りたい環境によって適宜書き直してください。<br>
<a href="https://amzn.to/43i4hCP">linkCard</a></p>
<p>このDockerfileをもとにDockerイメージをビルドします。<br>
Dockerイメージは動作環境（コンテナ）を作るためのテンプレートファイルです。<br>
この中にはOS、コマンド、データ（ファイルなど）、メタデータ（バージョン情報など）が入っています。<br>
Dockerイメージは次のようなコマンドを用いることでビルドすることができます。</p>
<pre><code>docker build -t ubuntu .
</code></pre>
<p>上記のように<code>docker build &lt;Dockerfileのパス&gt;</code>でDockerイメージをビルドします。<br>
ここで、docker buildの<code>-t</code>オプションは<code>--tag</code>の省略記法でdockerイメージに名前をつけることができます。<br>
また、dockerイメージのビルドにはdocker composeなどを使うこともありますが、今回はdockerコマンドのみで作っています。</p>
<h2>コンテナを立ち上げる</h2>
<p>最後に上で作成したDockerイメージをもとにDockerコンテナを立ち上げ、bashにアクセスします。</p>
<pre><code>docker run -it ubuntu bash
root@◯◯◯◯◯◯:/#
</code></pre>
<p>上記のようなプロンプトが出ていればdockerコンテナの立ち上げは成功です。<br>
ここで、docker runのシグネチャーは<code>docker run [OPTIONS] &lt;dockerイメージ&gt; &lt;コマンド&gt;</code>で、今回は<code>-i</code>オプションと<code>-t</code>オプションの2つを指定しています。<br>
<code>-i</code>オプションは<code>--interactive</code>の省略記法で、コンテナの標準入出力を開き続けます。<br>
<code>-t</code>オプションは<code>--tty</code>の省略記法で、コンテナに疑似ttyを割り当てます。<br>
ttyというのは簡単に言うとターミナルのことです。<br>
例えば、<code>-i</code>オプションのみを付した場合、ターミナルが割り当てられないのでプロンプトが表示されません。<br>
その反面、コンテナの標準入出力は開いているので<code>ls</code>コマンドを打ち込むとファイル・ディレクトリの一覧が表示されます。<br>
一方、<code>-t</code>オプションのみを付すとターミナルがアタッチされるのでプロンプトは表示されますが、コンテナの標準入出力が開いていないのでコンテナにコマンドを送ることができなくなります。</p>
<h1>まとめ</h1>
<p>本記事ではMac OSでDocker on Colima上にUbuntu環境を構築する方法を説明しました。<br>
こんな簡単なことでも仮想化・Linuxの基礎的な部分の勉強ができて結構おもしろいです。<br>
この環境上でLPICの勉強するぞ～</p>
<h1>おまけ</h1>
<p>ColimaはMacをシャットダウンすると停止してしまい、再起動のたびにターミナルで起動し直す必要があります。<br>
これは非常に面倒くさいので、頻繁にDocker環境を使う場合にはMac OSのAutomatorを使うことをおすすめします。<br>
これはアプリケーションなどのトリガーを設定できる機能で、起動した際にシェルスクリプトを実行させるようなこともできます。</p>
<p>設定は簡単で以下のような手順です。</p>
<ol>
<li>FinderのアプリケーションからAutomatorを選択</li>
<li>アプリケーションを選択</li>
<li>検索ボックスに「シェル」と打ち込み、「シェルスクリプトを実行」を選択</li>
<li>右のアクション設定で以下のように打ち込む。注意点としてAutomatorからのパスが全然通っていないので、1行目がないとcommand not foundになってしまう。</li>
</ol>
<pre><code>export PATH=/opt/homebrew/bin:$PATH
colima start
</code></pre>
<ol start="5">
<li>実行を押してテスト</li>
<li>うまく行ったらファイル→保存で保存。この際*.appという名前をつける。</li>
<li>システム設定で「ログイン項目」で検索し、ログイン時に開くの+を押して先程作ったファイルを追加</li>
</ol>
<p>これで設定完了です。<br>
ぜひお試しを。</p>


<p>Mac上でDocker on Colimaを使ってUbuntu環境を構築する方法について解説します。</p>

Dockerを使ってMacでUbuntuを動かす｜LPIC備忘録

<p>やっと社会人になって多少忙しくなったのですが、このブログは備忘録的に続けていきたいと思います。<br>
以前KaTeXを使って数式をきれいに表示する方法を解説しました。<br>
<a href="https://asunaroblog.net/blog/641d77aab5b671fd667829c8">linkCard</a></p>
<p>しばらく使ってみたところこのやり方だと色々と問題があることに気づいたので、別の方法を模索して実装し直しました。<br>
新しい方法のメリット・デメリットも含め解説していきたいと思います。</p>
<h1>環境</h1>
<ul>
<li>Next.js: 12.1.5</li>
<li>Katex: 0.16.2</li>
<li>newt-client-js: 3.2.4</li>
</ul>
<h1>解説と実装</h1>
<h2>解説</h2>
<p>前に書いた方法との大きな違いは、前はKaTeXの<code>rendetToString</code>を使っていました。<br>
この関数にはdelimiter（どこからどこまでが数式なのかの識別子）を判別したり、削除したりする機能がありませんでした。<br>
そのため、正規表現とTypeScriptの文字列操作を使ってmicroCMSのAPIによって取得したHTMLタグ付き文字列から無理やり数式部分を抜き出していました。</p>
<p>一方、今回の方法ではKaTeXのauto-render extensionを使います。<br>
この方法は開発者が特に何もしなくても生成したdomツリーから指定したdelimiterを元に勝手に数式部分を抜き出して数式をきれいにレンダリングしてくれます。</p>
<p>今回この方法を採用した背景には、ヘッドレスCMSを変更したことがあります（別の記事で書くかもしれませんが、microCMSからNewtというヘッドレスCMSにお引越ししました）。<br>
それに伴って各CMSから送られてくるHTMLタグ付き文字列の内容に微妙な違いがあり、それが原因でKaTeXが動かなくなってしまいました。<br>
そのため、この修正と合わせてKaTeXによる数式レンダリングの方法を今回改めて見直しています。</p>
<h2>新手法のメリット・デメリット</h2>
<p>この方法のメリットは以下のようになります。</p>
<ul>
<li>複雑な文字列操作をしなくても数式部分を勝手に抜き出してくれるため、楽に数式をレンダリングできる。</li>
<li>導入が簡単</li>
<li>動作不良を起こしにくい</li>
</ul>
<p>一方、この方法にはデメリットもあります</p>
<ul>
<li>DOMツリーを元に数式をレンダリングするため、DOMツリー内で別のノードとして認識されると数式表示できなくなる</li>
<li>サーバーサイドで修飾したHTMLを受け取るわけではないのでパフォーマンス的には若干不利（？）</li>
</ul>
<p>このうち、1つ目のデメリットの意味としては、例えば数式内に改行タグ（<code>&lt;br&gt;</code>）等があるとうまく数式として認識されなかったりします。<br>
そのため、数式を一行で書く必要があり、CMS上でLaTeX表現を書くのが多少不便だったりします。<br>
とはいえ、今のところそんなに大量の数式を書く予定はないので、当面はこれで大丈夫でしょう。</p>
<h2>実装</h2>
<p>実装自体は前に書いた方法に比べかなり簡単です。</p>
<pre><code>import { useEffect } from &quot;react&quot;;
import renderMathInElement from &quot;katex/contrib/auto-render&quot;;
import 'katex/dist/katex.min.css'

const PostBody = (props: Props) =&gt; {
  useEffect(() =&gt; {
    renderMathInElement(document.body, {
      delimiters: [
        { left: '$$', right: '$$', display: true },
        { left: '$', right: '$', display: false },
        { left: &quot;\$&quot;, right: &quot;\$&quot;, display: false },
        { left: &quot;\[&quot;, right: &quot;\]&quot;, display: true }
      ],
      ignoredTags: [&quot;code&quot;]
    })
  }, [])
  return (
        &lt;div dangerouslySetInnerHTML={{ __html: props.blog.body }} /&gt;
  )
}

</code></pre>
<p>これだけでHTMLタグ付き文字列から数式部分を取り出してレンダリングまでしてくれます。<br>
ポイントはuseEffectを使っている点です。<br>
useEffectの第2引数に空の配列を指定することで最初にレンダリングしたタイミングでのみrenderMathInElementを作用させます。</p>
<p>また、renderMathInElementの第2引数はオプションになっており、ここではdelimiters（識別子）とignoredTagsを指定しています。<br>
ignoredTagsにcodeを指定しているのはcheerioなどのjQuery系のライブラリを使う際にドルマークを使ったりしますし、コードブロック内に数式を書く機会はないだろうという判断から無視するようしています。</p>
<h1>まとめ</h1>
<p>実はこの方法はchatGPTが提案してくれた方法です。<br>
この方法にたどり着くまでにサーバー側でjsdomを動かして仮想DOMツリーを元に数式のレンダリングをしたあと、さらにHTMLタグ付き文字列を作り直すという回りくどい方法を試したりもしました。<br>
やっぱりchatGPTからうまいこと知りたい答えを引き出すのって難しいですね。<br>
とはいえ、それって人間に対する質問でも同じなので結局コミュニケーションが難しいってことなんでしょうか。。。</p>


KATEXのロゴ

<p>以前KaTeXを使って数式をきれいに表示する方法を解説しましたが、しばらく使ってみたところこのやり方だと色々と問題があることに気づいたので、別の方法を模索して実装し直しました。新しい方法のメリット・デメリットも含め解説していきたいと思います。</p>

Next.js+Newt+KaTeXで改めて数式をきれいに表示する｜自作ブログ

<p>修論書きがようやく終わり、久しぶりの投稿です。<br>
その手始めに、Webセキュリティの基本のキである同一オリジンポリシーやCORSについてまとめたものを書き残したいと思います。</p>
<h1>同一オリジンポリシー</h1>
<h2>オリジン</h2>
<p>はじめにそもそもオリジンとはなんなのかを説明します。<br>
オリジンとはウェブコンテンツにアクセスするために使うURLの中のプロトコル、ドメイン、ポート番号という3つの値の組のことです。<br>
もっと直感的にはウェブコンテンツの配給元の詳細で、どのサーバーから（ドメイン）どの出口を通って（ポート番号）どのよう配給されたのか（プロトコル）という情報です。</p>
<p>例えば</p>
<ol>
<li><code>http://example.com/app1/index.html</code></li>
<li><code>http://example.com/app2/index.html</code></li>
</ol>
<p>というhtmlファイルの位置を示す2つのURLがあったとします。<br>
このとき、1のhtmlファイルについて言えば、</p>
<ul>
<li>プロトコル：http</li>
<li>ドメイン：example.com</li>
<li>ポート番号：80（WebサーバはHTTPコンテンツを配信するのに80番を既定で使う）</li>
</ul>
<p>となり、この組み合わせがそのままオリジンと呼ばれます。<br>
一方で、2のhtmlファイルのオリジンはどうかというと、実は1のhtmlファイルのオリジンと同じになります。<br>
このように2つのリソース（ファイルなど）が同じオリジンから提供されていることを同一オリジンであるといいます。</p>
<h2>同一オリジンポリシー</h2>
<p>上の説明を読めばだいたい分かるかもしれませんが、同一オリジンポリシーというのはあるリソースについて、そのリソースからアクセスできるのは同一オリジンのリソースに限るという約束事のことです。<br>
同一オリジンポリシーを守ったリソース間アクセスをざっくりと図解すると次のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/452a9360-da3a-41e5-9fb5-2686e414faae%2F%E5%90%8C%E4%B8%80%E3%82%AA%E3%83%AA%E3%82%B8%E3%83%B3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BCOK.webp" alt="同一オリジンポリシーOK.webp"></p>
<p>この場合、ファイルAもファイルBも共に<code>http://example.com:80</code>という同一のオリジンから提供されたファイルなのでファイルAからファイルBへは同一オリジンポリシーに反することなくアクセスできます。</p>
<p>逆に、同一オリジンポリシーに反するリソース間アクセスは次のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/63020eb1-ceaa-4bd2-be3d-1cc2e1dd743d%2F%E5%90%8C%E4%B8%80%E3%82%AA%E3%83%AA%E3%82%B8%E3%83%B3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BCNG.webp" alt="同一オリジンポリシーNG.webp"></p>
<p>この場合、ファイルAのオリジンは<code>http://example.com:80</code>である一方で、ファイルBのオリジンは<code>http://www.example.com:80</code>でありこれらはドメインが異なっているため異なるオリジンのリソースです。<br>
なので、ファイルAからファイルBへのアクセスは同一オリジンポリシーに基づいて制限されます。</p>
<h2>同一オリジンポリシーが必要な理由</h2>
<p>どうして同一オリジンポリシーなんて言うめんどくさいルールがあるのか？<br>
それはひとえに、これを設けることで防げる攻撃があるためです。<br>
その例を下に示します。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/f50e6cd7-426a-420f-af74-9b998a4b0bf3%2F%E5%90%8C%E4%B8%80%E3%82%AA%E3%83%AA%E3%82%B8%E3%83%B3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E7%BD%A0.webp" alt="同一オリジンポリシー罠.webp"></p>
<p>これは罠サイトを使ったサイバー攻撃の一つで、次のような仕掛けになっています。</p>
<p>まず、利用者はexample.comにアクセスしようとします。<br>
しかし、誘導により罠サイトのtrap.example.comを閲覧してしまいます。<br>
trap.example.comから送られたhtmlにはexample.comのページが埋め込まれており、パッと見では罠にかかったと気づきません。<br>
そして、利用者はパスワードなどを打ち込んで送信します。</p>
<p>このような仕掛けはhtmlのiframe要素を使えば作ることができます。<br>
この時、仮に同一オリジンポリシーが無いとすればtrap.example.comから送られたhtml（の中のスクリプト）からexample.comのhtmlにアクセスできてしまうので、上で説明したようにその情報を抜き出すことができます。<br>
しかし、実際には同一オリジンポリシーがあるため、trap.example.comとexample.comという別のオリジンのコンテンツ間のアクセスは制限され、クライアントは守られるようになっています。<br>
これが同一オリジンポリシーによって防げる攻撃です。</p>
<h1>CORS</h1>
<h2>CORSの必要性</h2>
<p>上で説明したように、別のオリジンから提供されたコンテンツ同士のアクセスは同一オリジンポリシーによって制限されます。<br>
しかし、時と場合によっては同一オリジンポリシーによる制限が邪魔になるケースもあります。</p>
<p>例えば、このブログはmicroCMSというheadless CMSを使って管理しています。<br>
これは同一オリジンポリシーに則ると、このブログの記事はmicroCMS上で管理されているコンテンツにしかアクセスできないということです。<br>
これだとこのブログ記事に貼る画像などもmicroCMS上にないといけませんし、アマゾンの商品説明などにも気軽にアクセスできず、非常に不便です。<br>
そこで、「同一オリジンポリシーを超えて異なるオリジンのコンテンツ間アクセスをできるようにしよう」というのがCORSです。</p>
<h2>CORS</h2>
<p>上でも説明したように、CORS（Cross-Origin-Resource Sharing）とは「異なるコンテンツ間アクセスを可能にする仕組み」のことです。<br>
CORSの実現はコンテンツ間のリクエストの種類によって次の2種類に分けられます。</p>
<ol>
<li>単純なリクエストの場合：アクセスによる機密情報の漏洩などの心配がないので特に何もしなくてもコンテンツ間アクセスを許可</li>
<li>単純でないリクエストの場合：プリフライトリクエストを使って許可されたオリジンからのリクエストかどうかを確認</li>
</ol>
<p>ここで、「単純なリクエスト」と「プリフライトリクエスト」という2つの概念が出てきました。<br>
以下ではこれらのリクエストについて説明したいと思います。</p>
<h3>単純なリクエスト</h3>
<p>単純なリクエストというのは以下のような要件を満たすリクエストのことです。</p>
<ul>
<li>メソッド：次のうちのいずれか
<ul>
<li>GET</li>
<li>HEAD（ヘッダのみをGETするメソッド）</li>
<li>POST</li>
</ul>
</li>
<li>ヘッダーの種類：次のうちのいずれか
<ul>
<li>Accept</li>
<li>Accept-Language</li>
<li>Content-Language</li>
<li>Content-Type</li>
<li>Range</li>
<li>ユーザーエージェント（ざっくり言うとクライアントのOSとブラウザのこと）によって自動的に指定されたヘッダー（Connection、User-Agentなど）</li>
</ul>
</li>
<li>Content-Type：次のうちのいずれかのメディアタイプ
<ul>
<li>application/x-www-form-urlencoded（urlをパーセントエンコーディングしたもの）</li>
<li>multipart/form-data（フォームのデータで複数種類のデータをもつもの）</li>
<li>text/plain（プレーンテキスト）</li>
</ul>
</li>
</ul>
<p>これ以外にも細かい仕様がいくつかありますが、おおきいところではこの辺になります。</p>
<p>要するに単純なリクエストというのは「HTMLフォームから送られるリクエストと同程度のリスクであるようなリクエスト」であるといえます。<br>
というのも同一オリジンポリシーの目的がXMLHttpRequest（JavaScriptからの非同期な通信）などによるクロスオリジンアクセスを全開放すると危ないので、これを制限しようというものでした。<br>
HTMLフォームからのアクセスで悪さをするのは難しいので、これに合わせているということです。</p>
<p>ただし、この要件によってクロスサイトリクエストフォージェリなどの危険性は高まってしまうので、全く同程度のリスクとはいかないようです。</p>
<h3>プリフライトリクエスト</h3>
<p>クロスオリジンリクエストが単純なリクエスト出なかった場合、クライアントは自動的にプリフライトリクエストといういわばテストリクエストを送ります。<br>
プリフライトリクエストは次のような内容のリクエストです。</p>
<ul>
<li>メソッド：OPTIONS</li>
<li>パス：クライアントの送り先</li>
<li>ヘッダー：Access-Control-Request-Method、Access-Control-Request-Origin、 Originなど</li>
<li>ボディ：なし</li>
</ul>
<p>Access-Control-Request~系のヘッダーは実際のリクエストがどのようなもの（オリジン、ヘッダの種類など）であればリソース共有を許可するかということを指定します。<br>
また、メソッドにはOPTIONSという変わったものを使います。<br>
これはサーバが受取可能なメソッドの一覧を返すメソッドで、プリフライトにはぴったりなメソッドです。</p>
<h1>終わりに</h1>
<p>CORSを含めセキュリティ関連のお話は、Web系の勉強をするなら真っ先にやるべき項目だと思ったので今回まとめてみました。<br>
セキュリティ系の話を勉強するとHTTPなどネットワーク系の話も一緒に勉強できるので、大変ですが得るものが多いですね。<br>
今後もセキュリティ系の話題は積極的に上げていきたいと思います。</p>


<p>Webセキュリティの基本のキである同一オリジンポリシーやCORSについてまとめた記事です。</p>

CORSについてやさしく解説｜webセキュリティの基礎

<p>Connect-WebはgRPCを使いたい人にとっては導入も簡単で使い勝手の良いブラウザ用APIライブラリです。<br>
一方で新しい技術であることからも日本語ドキュメントが少ないという弱点もある。</p>
<p>今回は、Connect-Webのモックについて述べた記事があまりなかったので、これについて調べた内容を書き残します。</p>
<h1>Connect-Web</h1>
<h2>Connect-Webの概要</h2>
<p>Connect-Webはブラウザで利用できるgRPC互換のHTTP通信用のライブラリです。<br>
gRPC互換であることからもわかる通りProtocol Buffersを使ってインターフェースの定義を行います。<br>
また、クライアントなどの作成も全てProtocol Buffersに基づいて自動生成することができます。</p>
<h2>gRPC-webとの違い</h2>
<p>送受信の方法など細かい違いがあれど、一番大きな違いはconnect-webにはproxyが必要ないということです。<br>
このおかげでproxyの煩わしい設定なしにいきなりgRPCを使うことができるため、導入が非常に簡単です。</p>
<h1>MSW</h1>
<h2>MSWの概要</h2>
<p>MSW（Mock Service Worker）はサービスワーカーを用いてブラウザとサーバーのAPI通信をモックするためのライブラリです。<br>
<a href="https://mswjs.io/">linkCard</a></p>
<h2>モックとは？</h2>
<p>そもそもモックとはなにかというと、外見だけそれっぽく作ったとりあえずの試作品のことです。<br>
この場合ではAPIの試作品のことを指しています。<br>
つまり、サーバー側の処理やAPIがまだできていないときに、リクエストに対するレスポンスを適当に作っておくということです。<br>
これによってバックエンドが開発できていなくてもフロントエンドの開発を滞りなく進めることができます。</p>
<h2>MSWのメリット</h2>
<p>MSWのメリットはいくつかありますが主には次のようなものが挙げられます。</p>
<ul>
<li>実際のリクエストをそのままインターセプトしてモックできる。</li>
<li>GraphQLのモックができる</li>
<li>storybook内でも利用できる</li>
</ul>
<p>特に一番最後のstorybook内でも使えるというのはフロントエンドのコンポーネント開発を行う上では非常にありがたいです。</p>
<h1>実装</h1>
<p>実際にConnect-Webのチュートリアルをモックしてみる。</p>
<h2>Connect-Webのチュートリアル</h2>
<p>まず、適当なディレクトリでcreate react-appを行います。<br>
今回は適当にconnectという名前のアプリにしておきます。</p>
<pre><code>npm create vite@latest -- connect-msw-example --template react-ts
</code></pre>
<p>次にsrc/protosにeliza.protoを作成します。</p>
<pre><code>cd src
mkdir protos
cd protos
touch eliza.proto
</code></pre>
<p>これがAPIのインターフェース定義になっており、これに基づいてAPIのクライアントを作ったりします。</p>
<p>eliza.protoの内容は次のようになります。</p>
<pre><code>syntax = &quot;proto3&quot;;

package buf.connect.demo.eliza.v1;

service ElizaService {
  rpc Say(SayRequest) returns (SayResponse) {}
  rpc Converse(stream ConverseRequest) returns (stream ConverseResponse) {}
  rpc Introduce(IntroduceRequest) returns (stream IntroduceResponse) {}
}

message SayRequest {
  string sentence = 1;
}

message SayResponse {
  string sentence = 1;
}

message ConverseRequest {
  string sentence = 1;
}

message ConverseResponse {
  string sentence = 1;
}

message IntroduceRequest {
  string name = 1;
}

message IntroduceResponse {
  string sentence = 1;
}
</code></pre>
<p>protoファイルを含めProtocol Buffersについては別記事で詳しく書こうと思います。</p>
<p>次に、eliza.protoから必要なコードを生成します。<br>
そのための準備としてprotoファイルのコンパイラーをインストールします。<br>
今回はConnectのチュートリアルでも紹介されており、Connectと連携が強いbufというコンパイラーを採用します。</p>
<pre><code>npm install --save-dev @bufbuild/protoc-gen-connect-web @bufbuild/protoc-gen-es
npm install @bufbuild/connect-web @bufbuild/protobuf
</code></pre>
<p>続いてコンパイラーの設定ファイルを用意します。</p>
<p>package.jsonと同じディレクトリにbuf.gen.yamlを作成し、次の内容を書きます。</p>
<pre><code>version: v1
plugins:
  - name: es
    out: src/codegen
    opt: target=ts
  - name: connect-web
    out: src/codegen
    opt: target=ts
</code></pre>
<p>さらに、protoファイルをコンパイルするスクリプトをpackage.jsonに登録しておきます。</p>
<pre><code>&quot;scripts&quot;: {
  ...
  &quot;buf:generate&quot;: &quot;buf generate ./protos&quot;
},
</code></pre>
<p>これでターミナルに次のように入力すればsrc/codegen下にtypescriptファイルが生成できます。</p>
<pre><code>npm run buf:generate
</code></pre>
<p>App.tsxの内容を次のように書き換えるとチュートリアルのアプリを動かせるようになります。</p>
<pre><code>import { useState } from 'react'
import './App.css'

import {
  createConnectTransport,
  createPromiseClient,
} from &quot;@bufbuild/connect-web&quot;;
import { ElizaService } from './codegen/eliza_connectweb';

// Import service definition that you want to connect to.

// The transport defines what type of endpoint we're hitting.
// In our example we'll be communicating with a Connect endpoint.
const transport = createConnectTransport({
  baseUrl: &quot;https://demo.connect.build&quot;,
});

// Here we make the client itself, combining the service
// definition with the transport.
const client = createPromiseClient(ElizaService, transport);

function App() {
  const [inputValue, setInputValue] = useState(&quot;&quot;);
  const [messages, setMessages] = useState&lt;
      {
        fromMe: boolean;
        message: string;
      }[]
      &gt;([]);
  return &lt;&gt;
    &lt;ol&gt;
      {messages.map((msg, index) =&gt; (
          &lt;li key={index}&gt;
            {`${msg.fromMe ? &quot;ME:&quot; : &quot;ELIZA:&quot;} ${msg.message}`}
          &lt;/li&gt;
      ))}
    &lt;/ol&gt;
    &lt;form onSubmit={async (e) =&gt; {
      e.preventDefault();
      // Clear inputValue since the user has submitted.
      setInputValue(&quot;&quot;);
      // Store the inputValue in the chain of messages and
      // mark this message as coming from &quot;me&quot;
      setMessages((prev) =&gt; [
        ...prev,
        {
          fromMe: true,
          message: inputValue,
        },
      ]);
      const response = await client.say({
        sentence: inputValue,
      });
      setMessages((prev) =&gt; [
        ...prev,
        {
          fromMe: false,
          message: response.sentence,
        },
      ]);
    }}&gt;
      &lt;input value={inputValue} onChange={e =&gt; setInputValue(e.target.value)} /&gt;
      &lt;button type=&quot;submit&quot;&gt;Send&lt;/button&gt;
    &lt;/form&gt;
  &lt;/&gt;;
}

export default App
</code></pre>
<p>試し起動してみる。</p>
<pre><code>npm run dev
</code></pre>
<p>すると次のようなアプリが起動し、connectが無事に動いていることが確認できる。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/e14342b5-c7c8-4ea0-bb4e-24ddb810de92%2Fconnect-msw.gif" alt="connect-msw.gif"><br>
ここまでがconnectのチュートリアルの内容です。<br>
次は、現在バックエンドと通信している部分をモックに置き換える作業を行っていきます。</p>
<h2>MSWの導入</h2>
<p>まず、以下のコマンドでMSWを導入します。</p>
<pre><code>npm install msw --save-dev
</code></pre>
<p>次にいくつかの設定を行っていきます。<br>
まず、MSWの初期化とサービスワーカーの配置を行うために次のコマンドを打ちます。</p>
<pre><code>npx msw init public/ --save
</code></pre>
<p>これでブラウザからのリクエストをサービスワーカーがインターセプトすることができるようになります。</p>
<p>続いて、src下にmockディレクトリを作成し、その中にhandlers.tsとbrowser.tsを作成します。</p>
<pre><code>cd src
mkdir mock
cd mock
touch handlers.ts browser.ts
</code></pre>
<p>handlers.tsにはモックの挙動、すなわちどんなリクエストに対してどんなレスポンスを返すかということを書いていきます。<br>
今回は先程作ったelizaアプリの入力をインターセプトしたいので次のように書きます。</p>
<pre><code>import { rest } from 'msw'
import { SayResponse } from '../codegen/eliza_pb'
import { ElizaService } from '../codegen/eliza_connectweb'

const payload = new SayResponse({sentence: &quot;This is mock response&quot;})

export const handlers = [
  rest.post(`https://demo.connect.build/${ElizaService.typeName}/${ElizaService.methods.say.name}`, (req, res, ctx) =&gt; {
    return res(
      ctx.status(200),
      ctx.json(payload)
      )
    }),
]
</code></pre>
<p>connectで行われていることはほとんどrestと同じなので、rest用のhandlerでインターセプトが行なえます。<br>
ただし、ステータスコードなどに細かな違いがあるのでその点だけ注意する必要があります。<br>
詳しくはconnectのドキュメントのconnect protocolの項が参考になります。</p>
<p><a href="https://connect.build/docs/protocol">linkCard</a></p>
<p>また、browser.tsではワーカーインスタンスをセットアップしておきます。</p>
<pre><code>import { setupWorker } from 'msw'

import { handlers } from './handlers'

export const worker = setupWorker(...handlers)
</code></pre>
<p>これで準備が整ったので</p>
<p>実際にモックを行ってみます。</p>
<p>試しにApp.tsxの最上段から数行を次のように書き換えてみます。</p>
<pre><code>import { useState } from 'react'
import './App.css'

import {
  createConnectTransport,
  createPromiseClient,
} from &quot;@bufbuild/connect-web&quot;;
import { ElizaService } from './codegen/eliza_connectweb';
import { worker } from './mock/browser'
if (process.env.NODE_ENV === 'development') {
  await worker.start()
}
</code></pre>
<p>これでアプリを再起動すると次のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/c25239fc-59df-4b94-909c-c857f0233435%2Fconnect-msw-mock.gif" alt="connect-msw-mock.gif"><br>
しっかりとモックができていることが確認できます。</p>
<h1>終わりに</h1>
<p>本記事ではconnectをMSWでモックする際の手順について説明しました。<br>
connectは新しい技術ですが、protocol buffersの有用性なども考えると今後も使われる技術になっていくのではないかと思います。<br>
今後もgRPC、protocol buffers界隈の話題は注目していきたいですね。</p>
<p>ホントはMSWのstorybook addonを使うところまで説明したかったのですが、今日はつかれたのでまた別記事を作ろうと思います。</p>


<p><br></p><p>Connect-WebはgRPCを使いたい人にとっては導入も簡単で使い勝手の良いブラウザ用APIライブラリです。一方で新しい技術であることからも日本語ドキュメントが少ないという現状があります。今回は、Connect-Webのモックについて述べた記事があまりなかったので、これについて調べた内容を書き残します。</p>

Connect-WebをMSWでモックする方法｜Webフロントエンド

<p>私は情報系の学部に所属していなかったので、コンピュータサイエンス系の基本的な教養が足りていません。</p>
<p>そこで本記事は現在よく使われているJavaScript, Python, Go, Rubyなどの言語たちはどういう経緯で生まれてきたのだろうということをざっくりと理解することを目的としています。<br>
浅学の仲書いているので間違いなどはご容赦のほど。</p>
<h1>本記事の内容</h1>
<p>本記事では現在よく使われているプログラミング言語の先祖となったような重要な言語を取り上げ、その開発の経緯やどんな名残があるのか、誰が作ったのかなどを中心に書き残したいと思います。</p>
<p>とはいえあまり長い解説になっても良くないので、今回は特に重要と思われる5つの言語に絞って書いていきます。</p>
<h1>モダンな言語の先祖たち</h1>
<h2>FORTRAN</h2>
<h3>言語の概要</h3>
<p>FORTRANは世界初の高水準言語です。<br>
なので他のほとんどの高水準言語に対して直接・間接的に影響を与えた言語であるといえます。</p>
<p>FORTRANのすごいところは何と言っても現在でも現役で使われ続けている言語であるということです。<br>
私の知人にもプラズマ研究のためにFORTRANを使っている方が実際にいます。<br>
昔から続いている科学研究分野ではコードやライブラリが知見として蓄積されているので言語を変えないほうがいいし、必要がないという考えみたいですね。</p>
<h3>開発者</h3>
<p>FORTRANの開発者はIBMのエンジニアであったジョン・バッカスです。<br>
この方は現在ではバッカス・ナウア記法などにその名前を残しています。<br>
バッカスはIBM 704というメインフレームコンピュータ（でかくてパーソナルじゃないコンピュータ）で使用することを目的としてFORTRANを開発しました。</p>
<p>実はバッカスはFORTRAN開発の前にspeedcodingという言語を同じくIBMのメインフレーム用に開発しています。<br>
なので、厳密に言うとspeedcodingが世界初の高水準言語ということになるわけですが、speedcodingの事実上の進化系として作られたのがFORTRANであることから、現在ではFORTRANが世界初の高水準言語として紹介されることがほとんどです。</p>
<h3>名残</h3>
<p>FORTRANの手続き型プログラミングのパラダイムは現在の多くの言語に受け継がれています。<br>
それまでの機械語やアセンブリも手続き的に書かれていたわけなので、手続き型プログラミングの考え方はコンピュータ登場初期から現在まで通底しているもののようです。</p>
<h2>ALGOL</h2>
<h3>言語の概要</h3>
<p>ALGOLは最初期の高水準言語の一つです。<br>
ALGOLはalgorithmic languageの略であることからも分かる通り、アルゴリズムの記述を目的として開発された言語です。<br>
なので、商用的な目的というよりは学術的な分野で広く用いられていたという経緯を持っています。</p>
<p>ALGOL自体はFORTRANに影響を受けていますが、この言語が後の言語に与えた影響を考えるとFORTRAN以上に成功した言語として紹介されることもあります。<br>
というか、FORTRANもALGOLの構造化プログラミングに影響を受けていると思います。</p>
<h3>開発者</h3>
<p>ALGOLは、アメリカで開発されたFORTRANに対抗する形でヨーロッパの研究者グループが1950年代中頃に開発した言語です（この時代にもまだ新世界と旧世界の対抗意識ってあったんですね）。</p>
<p>とはいいつつ、後にFORTRAN開発者のジョン・バッカスなどもALGOLの開発に貢献しており、バッカス・ナウア記法などはALGOLを対象として開発されたメタ言語です。</p>
<h3>名残</h3>
<p>何と言っても現在の殆どの言語に共通する構造化プログラミングが導入された初めての言語としてALGOLが紹介されることが多いです。<br>
構造化プログラミングというのはざっくりいうと「goto文をやめてif文やwhile文にしよう」という考え方です。</p>
<p>今では当然ですが、昔はgoto文というものがあってコードのどこにでも飛べたみたいです。<br>
この仕組を使って条件分岐や繰り返しに相当するものを実装していました。<br>
goto文はアセンブリなどではいまでも現役なので、アセンブリを触る経験があると実感できると思います。</p>
<h2>C</h2>
<h3>言語の概要</h3>
<p>C言語は現在でもバリバリ現役の高水準言語です。<br>
おそらくプログラミング言語の中では最も有名なものの一つかと思います。<br>
JavaScriptやPythonなどに比べてメモリ管理などの低水準言語的な特徴を持っているので、厳密なメモリ管理が必要だったり速度が求められる現場ではよく利用されています。<br>
例としては組み込み系やOSなどですね。</p>
<h3>開発者</h3>
<p>開発者はベル研究所のデニス・リッチーです。<br>
リッチーはケン・トンプソンが開発したB言語の改良としてC言語を開発しました。<br>
当初はOS上で動くユーティリティ（カレンダーとか時計とかスクショとかの機能）を作成する目的で作られましたが、後にUNIXまるごとがC言語で置き換えられました。</p>
<h3>名残</h3>
<p>文法的な面はもちろんPythonなんかはそれ自体Cで実装されています。<br>
また、RustはCの代替として作られましたし、JavaはCの拡張版であるC++の構文を参考に作られています。</p>
<h2>Simula・Smalltalk</h2>
<h3>言語の概要</h3>
<p>Simulaは世界初のモダンなオブジェクト指向言語です。<br>
一方のSmalltalkはSimulaで確立されたオブジェクト指向という概念をさらに一般化し、世間に広めた言語です。</p>
<p>こういう経緯もあってこれらの言語は「オブジェクト指向を作った言語」として、特別にひとまとめで紹介しています。</p>
<h3>開発者</h3>
<p>Simulaの開発者はノルウェーの数学者クリステン・二ゴールです。<br>
Simulaは当初コンピュータ・シミュレーションのための言語として開発されており、一般のシステム開発などへの利用を想定していなかったことも相まって一部の研究者などが利用する程度にとどまりました。</p>
<p>このSimulaのオブジェクト指向的な発想をハード、OS、GUIなどフルセットで開発・提供したのがアラン・ケイのSmalltalkです。</p>
<h3>名残</h3>
<p>現在よく使われているプログラミング言語ではオブジェクト指向が当たり前のように使われています。</p>
<p>現在主流のオブジェクト指向はSimulaやそれを発展させたC++のオブジェクト指向を受け継いでいます。<br>
しかし、オブジェクト指向という考え方そのものを確立させたSmalltalkの功績も大きく、多くの言語が直接・間接的にSmalltalkの影響を受けています。</p>
<h2>Perl</h2>
<h3>言語の概要</h3>
<p>Perlは最初に広まった実用的なサーバーサイドスクリプト言語です。<br>
現在もオープンソースでの開発が進められており、様々なプロダクトで使用されています。</p>
<h3>開発者</h3>
<p>Perlを開発したのはプログラマの三大美徳などでよく知られるラリー・ウォールです。<br>
ウォールはサーバーサイドで軽量かつ気軽に動作できる言語としてPerlを開発しました。</p>
<p>Perlは現在Perl 5まで開発されていますが、開発者がPerl 5と全然互換性のないPerl 6（後にRakuとして分離）を作ってしまったので、Perl今後は緩やかに衰退する可能性の高い悲しき存在です。</p>
<h3>名残</h3>
<p>Perlは軽量なサーバーサイドスクリプト言語という文脈でPythonやRubyなどの言語に大きな影響を与えています。<br>
また、オープンソースでのプログラミング言語開発におけるプロジェクトのあり方を最初に示したという功績もあります。</p>
<h1>まとめ</h1>
<p>今回は現在使われているWeb言語たちの先祖について書き残しました。<br>
こうしてみると、よく知られている言語よりも知られていない言語のほうが後に影響を与えたりもしていて面白いです。<br>
もちろん、ここに取り上げた他にもBASICやAda、Java、Pascalなど重要な言語はいくらでもあるわけですが、それらのお勉強は別記事で機会があれば。</p>


<p>本記事では現在よく使われているプログラミング言語の祖先となったような重要な言語を取り上げ、その開発の経緯やどんな名残があるのか、誰が作ったのかなどを中心に書き残したいと思います。</p>

モダンなWeb言語たちの先祖｜プログラミング言語の歴史を解説

<p>MUIは非常に便利なライブラリでかっこいいコンポーネントが一通り揃っていますしドキュメントも充実しています。</p>
<p>さすが天下のGoogleさんです。</p>
<p>ただ、使ってみると思うのですがMUIのコンポーネント自体は非常に豊富な機能を有している一方、ドキュメントに関しては案外痒いところに手が届かない説明になっていたりします。</p>
<p>今回は自分と同じ痒さを患っている方の手助けをするためにも、Next.jsのLinkコンポーネントとMUIのPaginationコンポーネントを使った簡単なページネーションの実装方法を書き残します。</p>
<p>実際の動きを見たい方はこのブログのホームを見てみてください。</p>
<p>また、今回の実装の内容は私のgithubにおいてあるので、全貌を知りたい方は参照してみてください。<br>
<a href="https://github.com/Asunaro276/pagination-sample">linkCard</a></p>
<h1>環境</h1>
<ul>
<li>OS: Ubuntu 20.04.3 LTS</li>
<li>Node: 16.13.1</li>
<li>next: 12.1.5</li>
<li>@mui/material: 5.6.2</li>
</ul>
<h1>事前準備</h1>
<h2>Next.jsアプリの作成</h2>
<p>まずターミナルから適当な空ディレクトリを作り、そこに入ります。</p>
<pre><code>mkdir pagination-sample
cd pagination-sample
</code></pre>
<p>次に、Next.jsアプリを作るために次のコマンドをターミナルで実行します。</p>
<pre><code>yarn create next-app .
</code></pre>
<p>create next-appの引数はアプリ名を指すので.をつけることで当該ディレクトリに諸々のファイルを展開できます。</p>
<p>試しに次のコマンドを実行すれば下の画像のような画面をブラウザに表示することができます。</p>
<pre><code>yarn dev
</code></pre>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/c619fe05-bd59-45d6-8efe-25e0cabac40a%2Fcreate-next.webp" alt="create-next.webp"></p>
<h2>MUIのインストール</h2>
<p>MUIのインストールは公式に従って次のコマンドを実行します。</p>
<pre><code>yarn add @mui/material @emotion/react @emotion/styled
</code></pre>
<h1>実装</h1>
<h2>基本的なページネーションの実装</h2>
<p>pagesと同じディレクトリにcomponents/Pagination.jsxを作ります。</p>
<pre><code>mkdir components
touch Pagination.jsx
</code></pre>
<p>Paginationは次のように実装ができます。</p>
<pre><code>import { Link as MuiLink, Pagination as MuiPagination, PaginationItem } from '@mui/material'

const Pagination = ({ pageNumber, totalCount }) =&gt; {
  return (
    &lt;MuiPagination
      page={pageNumber}
      count={totalCount}
      renderItem={item =&gt; (
        &lt;PaginationItem
          component={MuiLink}
          href={item.page === 1 ? `/` : `/${item.page}`}
          {...item}
        /&gt;
      )}
    /&gt;
  )
}

export default Pagination
</code></pre>
<p>引数のpageNumberは現在のページ数、totalCountは最後のページのページ番号を表しています。</p>
<p>注意としては、PaginationItemのpageは1から始まるので1ページめをホームにしたい場合は上のような書き方をします。</p>
<p>これを実際に動かすと次のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/54aab728-34b4-42a8-96f5-70d39c546cf2%2F%E3%83%9A%E3%83%BC%E3%82%B8%E3%83%8D%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3.gif" alt="ページネーション.gif"></p>
<h2>next/linkと組み合わせる</h2>
<p>次にNext.jsのルーティング用コンポーネントのnext/linkと組み合わせてみます。<br>
といっても、そんなに難しい話ではなく、ただPaginationItemをnext/linkでラップすればよいだけです。</p>
<pre><code>import { Link as MuiLink, Pagination as MuiPagination, PaginationItem } from '@mui/material'
import Link from 'next/link'

const Pagination = ({ pageNumber, totalCount }) =&gt; {
  return (
    &lt;MuiPagination
      page={pageNumber}
      count={totalCount}
      renderItem={item =&gt; (
        &lt;Link href={item.page === 1 ? `/` : `/${item.page}`} passHref&gt;
          &lt;PaginationItem
            {...item}
            component={MuiLink}
          /&gt;
        &lt;/Link&gt;
      )}
    /&gt;
  )
}

export default Pagination
</code></pre>
<p>注意としてはLinkコンポーネントにpassHrefを入れています。<br>
これはラップされているaタグ（MuiLinkコンポーネント）にhref属性を渡すためです。<br>
というのも、aタグがhref属性を持っていないのはSEO的に不利らしいので、多くの場合next/linkでaタグをラップする場合にはpassHrefをTrueにします。</p>
<p>このときのPaginationの動きは次のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/6be1cccb-3233-4afa-a1ee-eb48b3987e93%2F%E3%83%9A%E3%83%BC%E3%82%B8%E3%83%8D%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%8D%E3%82%AF%E3%82%B9%E3%83%88.gif" alt="ページネーションネクスト.gif"></p>
<h1>まとめ</h1>
<p>今回はMUIのPaginationコンポーネントとNextのLinkコンポーネントを使って簡単なページネーション機能を実装しました。<br>
MUIを使うとおしゃれなUIが簡単に作れるので本当に便利ですね。<br>
これからもおせわになりそうです。</p>
<p>なお、今回の実装はMUIの公式ドキュメントを参考にしています。<br>
気になる方は参照してみてください。<br>
<a href="https://mui.com/material-ui/react-pagination/#router-integration">linkCard</a></p>


MUIのロゴ

<p>MUIは非常に便利なライブラリでかっこいいコンポーネントが一通り揃っていますしドキュメントも充実しています。ただ、使ってみると思うのですがMUIのコンポーネント自体は非常に豊富な機能を有している一方、ドキュメントに関しては案外痒いところに手が届かない説明になっていたりします。今回は自分と同じ痒さを患っている方の手助けをするためにも、Next.jsのLinkコンポーネントとMUIのPaginationコンポーネントを使った簡単なページネーションの実装方法を書き残します。</p>

Next.js+MUIでページネーションを実装｜ブログづくり

<p>最近業務でZendeskを使っている関係でテクニカルサポートの方からZendesk Showcaseを紹介してもらったので今回参加してきました。<br>
いままで体験したことのない雰囲気のオフラインイベントで個人的に非常に面白かったので感想を書き残します。</p>
<h1>講演前</h1>
<p>当日は開場が朝9:00で講演が朝10:00からスタートでした。<br>
会場は恵比寿のウェスティンホテル東京（高級ホテル！）で入った瞬間から「金かけてるな～」という印象でした。</p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/7f32bf67-9923-45ff-95c3-b7a7b96d901e/1722425687282.jpg" alt="1722425687282.jpg"></p>
<p>講演前の時間にはZendesk AIのデモブースと朝食会場が設置されており、早く来ても暇をするようなことはまったくなかったです。<br>
（今回のイベントでは総合的に食事・飲み物類にはかなり力が入ってる様子でした🔥）</p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/45fc31c5-fc3c-4c78-98f1-f423c1b6ada0/5394_0.jpg" alt="5394_0.jpg"><br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/25c0c0ae-e19d-401e-85c5-2485af7f419c/5405_0.jpg" alt="5405_0.jpg"></p>
<h1>講演</h1>
<h2>基調講演</h2>
<p>要約すると</p>
<ul>
<li>AI頑張る
<ul>
<li>AIボット、エージェントのcopilot、ワークフォースマネージャーの開発</li>
</ul>
</li>
<li>人のやることをより高度に
<ul>
<li>エージェントの教育プログラムの拡充</li>
</ul>
</li>
</ul>
<p>最近の動き（買収や機能発表）を見てるととにかくAIに力を入れていることが感じられました。</p>
<p>正直初めて業務でZendesk AIの機能を見た時には「思ってたよりも限定した機能だな」と思ったんですが、やはりセキュリティや精度面でかなり注意を払っているためっぽいです。<br>
加えてセキュリティや精度の壁を突破することには今現在かなりの注力をしていることが伺えました。</p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/bc2f7cb6-c462-45b0-bdc2-c51c63096966/1722432034756.jpg" alt="1722432034756.jpg"></p>
<h2>Zendeskの発表</h2>
<p>こちらもやはりZendesk AIの話がかなり多かったです。<br>
それに加えてワークフォースエンゲージメントやワークフローオーケストレーション等新しい機能についての発表も行われました。</p>
<p>個人的には社内ヘルプセンターに対してslackと連携してZendeskを使う動きなんかが気になりました。<br>
生成AIなんかも社内利用ならガンガン使えますしね。</p>
<p>また、講演者がガチガチに作り込んだペルソナとカスタマージャーニーを下に機能のデモンストレーションをしていたのがとても印象的でした。<br>
こういう発表形式にするとシナリオといっしょに話が頭に入るので一般的なユースケースを説明するにはかなり刺さる方法だなと思います。</p>
<p>そして、Zendeskからの講演を一通り聞いて、こういう機能の多いツールは「きれいに使う」ことが実は結構大事なんじゃないかということを感じました。</p>
<p>すなわち、できる限りZendesk側が想定している一般的なユースケースに寄せることでZendeskが開発する各機能をより効果的に使えるんじゃないかということです。<br>
もちろん各機能を部分部分で使っても効果はあるんですが、Zendesk側は組み合わせて使った時にシナジーを生むようにプロダクトを設計しているので、一般的なユースケースに寄せられるならそのほうが本当はいいんだろうと思います。</p>
<p>とはいえプロダクトで工夫した（一般的でない）アーキテクチャを取ると自ずとZendeskの使い方も一般的なものからは逸れていくような気もするので難しい部分ですね...</p>
<h2>各社のユースケース</h2>
<h3>アダストリア</h3>
<p>nico andやグローバルワークで知られるファッション企業です。</p>
<p>講演の中で面白いなと思ったのがCSを守りだけでなく攻めに使おうという考え方です。<br>
確かによく言われていることではあるんですが、組織課題の特定など具体的な粒度で説明してもらえたおかげで自分の業務に活かすイメージが湧きました。</p>
<h3>EARTHBRAIN</h3>
<p>コマツの子会社でスマートコンストラクションの企業です。</p>
<p>特に印象に残ったのがCS改革を以下の3Stepに分けて行ったという部分です。</p>
<ol>
<li>タイムリーな回答</li>
<li>自己解決</li>
<li>課題からの開放</li>
</ol>
<p>この話を聞いて私はこれこそがCS改善の普遍的なロードマップだと思いました。<br>
すなわち、対エンドユーザー・対社内問わず、どんな業界のどんな企業であろうと、CS改善をやろうと思うと基本的にはこのロードマップに従い、各地点に適したソリューションがあるだろうということです。</p>
<p>そういう意味ではCSクライテリア的なものが作れそうだなとも思います（もうある？）</p>
<h3>サトー</h3>
<p>バーコード等の自動認識に関する商品を販売する企業です。</p>
<p>EARTHBRAINもそうでしたが、海外展開している企業はCSチャネルも複雑化して相当大変そうだと感じました。</p>
<p>また、チャット等のチャネルの改善より先にヘルプデスクの改善をやっていたのが印象的でした。<br>
この辺は直近の課題感がどこにあるかにも依存しそうですが、ヘルプデスクが整っていないとチャットが効果を発揮しきれないのは各社の発表を見ている限り間違いなさそうです。</p>
<h1>講演後の懇親会</h1>
<p>講演後の懇親会では過去最多の4組の方からお話を伺うことができました🙌</p>
<p>今までオフラインのセミナーはエンジニア向けのものしか行ったことがなかったので、当然相手もエンジニアで話しもしやすかったんですが、今回はCSの方やバックオフィスの方など開発者以外の方がたくさんいたのでどういう切り口で話しをすべきかかなり迷いました。</p>
<p>とはいえ、何度かオフラインイベントに参加して慣れてきたのか、今回は自分から積極的に話しかけられたのでそこは成長です。<br>
（次回は発表者に質問持って突撃したい...）</p>
<p>また、懇親会の心得として</p>
<ul>
<li>孤立しているグループを狙う</li>
<li>乾杯の時にすっと近づいて乾杯してもらう → 流れで話す</li>
</ul>
<p>みたいなことは今後も有効そうだなと思います。</p>
<p>自分が聞きたいことを聞き出しつつ、相手にも楽しんでもらえるようなコミュニケーションができるよう、もっとオフラインイベントに行って慣れていきたいですね。</p>
<h1>まとめ</h1>
<p>今回のイベントは会場から参加者から、今まで経験したこと無い感じだったので非常にワクワクしました。<br>
来年も参加したいですが、平日の昼に開催なのが辛いところですよね～。<br>
ともあれ、こういうイベントはブログのネタにもなるので今後も積極的に参加していきたいですね。</p>


<p>最近業務でZendeskを使っている関係でテクニカルサポートの方からZendesk Showcaseを紹介してもらい、今回参加してきました。</p><p>いままで体験したことのない雰囲気のオフラインイベントで個人的に非常に面白かったので感想を書き残します。</p>

Zendesk Showcase - Tokyo 2024に行ってきた！｜セミナー参加録

<p>最近PlateUp!というゲームにハマって会社の同期と何度かプレイしていたんですが、その中でこのゲームの本質は開発組織における開発生産性と近しいのでは？という話が出たのでその話をします。</p>
<h1>PlateUp!ってなに？</h1>
<p>PlateUp!はSteamで販売されているインディーゲームです。<br>
内容としてはレストラン経営をするアクションゲームで、ホール・キッチンのタスクをこなしながら客を捌いていき、稼いだお金で店を拡張することを目指します。（Overcookedにホールの要素が加わっているといえばわかりやすいでしょうか）</p>
<p>そもそものゲーム自体がめちゃめちゃ面白いのでプレイしたこと無い方は開発生産性に興味なくても一度プレイすることを強くおすすめします。</p>
<p><a href="https://store.steampowered.com/app/1599600/_/?l=japanese">linkCard</a></p>
<h1>PlateUp!のどこが開発生産性と関係してるの？</h1>
<p>このPlateUp!、タイトルがアッパーキャメルケースになっていること以外にも様々な要素がエンジニアリングと関係しています。</p>
<h2>リソース効率よりフロー効率</h2>
<p>PlateUp!ではどれだけ仕事をしようと客に料理（価値）を届けられなければ意味がありません。<br>
早く料理を提供しなければ客は怒ってかえってしまいますし、1人でも客が起こると強制閉店させられます。（シビアすぎる...）<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/2fc6e4fe-7909-4da8-888c-00fae62a004c/20240413153705.jpg" alt="20240413153705.jpg"></p>
<p>逆に暇な時間があったとしても、客に料理を提供できているならそれでいいのです。<br>
特に複数人で仕事をする際にはどうしても待ちが発生しがちですし、タスクがなくなるときもあります。<br>
そういうときに別のタスクをすると他の人の導線の邪魔をすることになったり、タスクによっては失敗率が高くなったりします。（肉を焦がしたり、焼きすぎたり...）</p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/b27dcbdb-b586-4e0b-8045-fe0191388ac0/37fa990a-ffa7-45ad-82df-5eed827e7d57.avif" alt="37fa990a-ffa7-45ad-82df-5eed827e7d57.avif"></p>
<p>プロダクト開発でもしばしば同様の現象が起こります。<br>
チームでの開発なので当然営業さんとの調整による待ちやデザイナーからのデザイン待ちはあります。<br>
そんな時に無理にリソースの空きを潰す必要はないのです。<br>
大切なのは顧客にできるだけ早く価値を届けること。<br>
そのためには自分の稼働率を上げることよりもむしろ他メンバーの状況把握に時間を使ったほうがいいことも往々にしてあるのです。</p>
<h2>4keys</h2>
<p>4keysは開発組織におけるパフォーマンスを示す代表的な指標です。</p>
<p><a href="https://newrelic.com/jp/blog/best-practices/what-is-four-keys">linkCard</a></p>
<p>4keysは以下の4要素からなっています。</p>
<ul>
<li>デプロイ頻度</li>
<li>リードタイム</li>
<li>変更障害率</li>
<li>平均修復時間</li>
</ul>
<p>開発組織における4keysはPlateUp!の以下の4要素に対応すると考えることができます。</p>
<ul>
<li>料理提供頻度</li>
<li>一皿の提供スピード</li>
<li>作業失敗率（焼きすぎ、間違ったレシピ）</li>
<li>失敗で出たゴミを捨ててゴミ出しする時間</li>
</ul>
<p>上述したフロー効率とリソース効率でも述べたように、リソース効率を高めて料理提供頻度や一皿の提供スピードを上げても作業失敗率が上がっては意味がありません。<br>
また、作業に失敗した時にすぐに復旧できるレイアウトを組んでいないと致命的な遅延を招き、最悪店を潰すことに繋がります。</p>
<p>このようにPlateUp!をプレイしているとこのゲームの攻略法がそのまま開発生産性の文脈にアナロジーとして引用できることに気づきます。</p>
<h1>私がPlateUp!から学んだこと</h1>
<h2>関心事はなんで増やしちゃいけないの？</h2>
<p>プロダクト開発ではしばしば関心事を増やすことを悪と考え、WIP制限などの取り組みが取り入れられることもあります。<br>
これはなぜかといえば、もちろんフロー効率の観点で価値を一つ一つ素早く提供すべきという考え方があるからですが、PlateUp!をプレイしているとこれ以外にも</p>
<ul>
<li>余裕がなくなって失敗率が上がる</li>
<li>全体を把握する暇がなくなる</li>
</ul>
<p>などの弊害があることに気づけます。</p>
<h2>チームの人数によって最適な立ち回りは異なる</h2>
<p>一般的にチームメンバーが少なくてもタスクの種類はそれに比例して減ったりはしません。<br>
ですので、チームメンバーが少ないと一人一人の関心事は基本的に増えます。<br>
こういう状態だと各メンバーの稼働率がチーム全体のフロー効率に直結したりします。（スタートアップが激務になりやすいのはこういう側面もあると思います。）</p>
<p>一方でチームメンバーが増えてくると一人一人は専門のタスクに集中するようになり関心事がどんどんと減っていきます。<br>
ですがその分どうしても視野が狭くなって他メンバーに不満を溜め込んだり、全体の目標認識が疎かになったりします。<br>
チームメンバーが増えて自分の専門タスクに集中できるようになっても常に全体が見える余裕は持っていたいものです。</p>
<h2>結局最後は自動化に行き着く</h2>
<p>結局自動化こそフロー効率もリソース効率も向上させる最高の手段です。<br>
自動化さえされれば少ない人数でも多くの価値を顧客に届けることができます。<br>
ただ、自動化には専門知識がいるというのはどこの世界でも変わらないようで...</p>
<p><a href="https://www.youtube.com/watch?app=desktop&amp;v=cW9c-tzY574">linkCard</a></p>
<h1>まとめ</h1>
<p>今回はPlateUp!というゲームをやっていて私が気づいたことをつらつらと書きました。<br>
普段の業務でも開発生産性を意識はしていますが、PlateUp!をやっていると別視点で開発生産性を見直せて個人的には大きな学びがありました。</p>
<p>ところでこれだけ色々語っておきながら、実は私はPlateUp!をソロで15日目までクリアできたことがありません。<br>
いつかクリアしたいな～と思いながらのんびりバイトする今日このごろです。</p>


<p>最近PlateUp!というゲームにハマって会社の同期と何度かプレイしていたんですが、その中でこのゲームの本質は開発組織における開発生産性と近しいのでは？という話が出たのでその話をします。</p>

PlateUp!から学ぶ開発生産性｜ポエム

<p>2023/10/28にVue Fes Japan 2023が開催されました。<br>
初めてのセミナー参加でアフターパーティまで参加したのでその感想を書き残したいと思います。</p>
<h1>全体の感想</h1>
<p>非常に有意義な時間だったと思います。<br>
Vueの開発者であるEvan YouさんやNuxt LabのCEOであるSebastien Chopinさんなど参加者がまず豪華でした。<br>
そして、各セッションの内容も自分が困っている部分についてヒントを与えてくださったり、あるいは自分が全く知らない技術情報について発信してくださったりとどれもためになるものばかりでした。</p>
<h1>特に印象に残ったセッション</h1>
<h2>山本 一将さん（ユニークビジョン）の発表</h2>
<p>フロントエンドの精鋭チームで社内UIコンポーネントライブラリを作ったことが社内全体に良い影響を与えたという内容の発表でした。</p>
<p>自分がまずオモシロイと思ったのは、フロントエンドエンジニアが少ないという事実です。<br>
私が所属している会社は全員がフルスタックエンジニアなので、フロントエンドエンジニアが少ないとか人数に偏りがあるなど考えたことがなかったので、とても新鮮な気持ちになりました。</p>
<p>また、各プロダクトチームに所属する精鋭のフロントエンドエンジニアを縦割りにしてUIコンポーネントライブラリチームを作ったという話もとてもおもしろいなと思いました。<br>
自分たちに寄り添ったドキュメンテーションができれば他のメンバーは効率的にスキルアップができますし、プロダクトのクオリティも上がるので一石二鳥ですよね。<br>
精鋭にいちばん核となる部分を作ってもらって、他のメンバーはそれを見て周辺を作るというのはフロントエンドに限らず取り入れられそうだなと感じます。</p>
<h2>鵜木 義秀さん（リンクアンドモチベーション）の発表</h2>
<p>社内でフロントエンド周りのアーキテクチャを刷新しようと思った際に、その提案がうまく行かなくて開発全体に悪影響がでたという内容でした。</p>
<p>この発表は結論がとても面白かったです。<br>
普通は「提案」という工程は、偉い人に承認してもらうための工程であると考えがちですが、実はその後の設計や開発において不確実性を減らすためのいわば最も上流の開発工程なんだという話でした。</p>
<p>自分も現在、自社で新技術の導入を勧めたいと思っているので、この話はとても身にしみました。<br>
特に、最後にお話されていた「エンドクライアントだけでなく社内の人に向けても”使う人のことを考える”ということをやった方がいい」という話はとても含蓄のある言葉だと思います。<br>
自分もまず提案から見直してみようと思います。</p>
<h2>安積 洋さん（MNTSQ）の発表</h2>
<p>PMF（プロダクトが市場に受け入れられた状態）後の開発で重要なのは読む速さであり、それを意識したプロジェクト設計についての取り組み事例などを話してくださいました。</p>
<p>「良いドキュメントは勝手に仕事をしてくれる」とか「大事なところは自分たちで作る、大事じゃないところは流行に乗る」とかかなりいいお言葉をいただけました。<br>
また、chromiumの新機能勉強会をやっているという話からは、流行に乗るためには最先端を知っておかないといけないという姿勢が見え、自分もこの考え方を学ばないといけないなと感じさせられました。</p>
<h2>mizdraさん（はてな）の発表</h2>
<p>Vueから生まれたVolar.jsというOSSがめちゃくちゃ面白いという話を実際のデモと一緒にお話してくださいました。</p>
<p>自分はこの発表を聞くまでLanguage Serverというものについて殆ど知らなかったのですが、この発表の秀逸だった部分はそのLanguage Serverがどういうもので、どういう規格のもとに作られていて、どう動くというところから解説していただけたところです。<br>
このおかげでVueのLanguage Serverのどこが特殊なのかやVolarがなぜ汎用的に使えるのかということを納得しながら理解することができました。</p>
<p>自分もVolar.jsを触ってみたいと思いましたし、なにより自分もブログ記事を書く際にはこういう論の立て方をしたいなと思いました。</p>
<h2>ota-meshiさん（フューチャー）の発表</h2>
<p>eslint-plugin-vueのcore authorであるota-meshiさんがeslint-plugin-vueのこれまでや今後について話すという内容でした。</p>
<p>自分はvueの公式推奨eslint pluginが日本人によって開発されているということ自体知りませんでしたし、この発表を聞いてOSSに対する興味が一層高まりました。<br>
また、eslintの開発の何が難しいのかと言う部分の一端が理解出来、技術的な知見も含んだとてもいい内容だなと思いました。</p>
<h1>アフターパーティ</h1>
<p>アフターパーティは総じてとても楽しく、一瞬で終わった感じでした。<br>
自分のコミュ力の問題で数人の人にしか話しかけることができませんでしたが、その方々には悩み相談をさせていただいて、自分の課題に対するいくつかのヒントをいただくことができました。<br>
また、エンジニアと一口に言っても色々なバックグラウンドの方がいらっしゃって、それぞれに考えながらVueを使っているんだなということを一番実感できた場でした。</p>
<p>なお、アフターバーティは当初想定していた十倍は豪華で、人もめちゃくちゃたくさんいました。<br>
なにより食事が美味しかったです（GMOさんに感謝🤜）</p>
<h1>反省点</h1>
<p>実は今回反省点がいくつかあるので、次のカンファレンスに向けて書き残します。</p>
<ul>
<li>写真を取らなかった
<ul>
<li>ブログ用に取ればよかった～</li>
</ul>
</li>
<li>ネームプレート用の会社ロゴステッカーはあった方がいい
<ul>
<li>あったほうがコミュニケーションはかどる気がします</li>
</ul>
</li>
<li>アフターパーティでの行動は速く
<ul>
<li>話したら絶対楽しいので、最初の一歩を踏み出す勇気がめっちゃ大事</li>
</ul>
</li>
<li>最初に社名と名前を聞いといた方がいい
<ul>
<li>無理なら後で名刺交換！（名刺にはXアカウント書いたほうが良いかも）</li>
<li>つながりは大切にしたい！</li>
</ul>
</li>
<li>X整備
<ul>
<li>やっぱみんな発信の主戦場はXっぽいので、プロフィール周りだけでも整備したら良さそう</li>
</ul>
</li>
</ul>
<p>といったところで反省点もありましたが、総じて楽しかったです！<br>
次はReactとかScalaとかのカンファレンスもでてみたいですね～</p>


<p>2023/10/28にVue Fes Japan 2023が開催されました。初めてのセミナー参加でアフターパーティまで参加したのでその感想を書き残したいと思います。</p>

Vue Fes Japan 2023に行ってきた！｜セミナー参加録

<p>最近初任給をもらえたので念願のゲーミングPCが手に入りました。<br>
さっそくMinecraftのModを入れようとしたんですが、予想以上に難しくて非エンジニアの方とかはかなり苦労しそうだなと思ったので、本記事ではその際に調べたことなどを書き残しておきます。<br>
本記事では1.19.4のMinecraftを例に画像などを作っていますが、どのバージョンでも入れられるような説明をしていますので、ご安心ください。<br>
本記事がMinecraftのModの考え方などを理解する一助になれば幸いです。</p>
<h1>MinecraftのModに関する用語</h1>
<p>まず、MinecraftにModを入れる際に重要となるいくつかの用語を紹介します。</p>
<h2>バージョン</h2>
<p>Modを導入する際に最も重要となるものの一つがバージョンです。</p>
<p>Minecraftは世界で最も売れたゲームと呼ばれるほど人気のゲームなので、現在でもマイクロソフトによって活発に開発がされています。<br>
小さいリリースでいうと数日から数週間に一度程度、1.18 → 1.19 などの大型のアップデートは数ヶ月に一度程度の頻度で行われています。</p>
<p>各Modは特定のバージョンのMinecraftに合わせて作られているので、想定されているバージョン以外のバージョンのMinecraftを動かそうとするとクラッシュすることが度々あります。<br>
そのため、MinecraftのModを入れる際には<strong>Minecraft本体とModのバージョンを揃える</strong>ことが非常に重要です。</p>
<h2>前提Mod</h2>
<p>Modの中には軽量化Modなどを入れることが前提となっているModがあります。<br>
例えば影Modなどについても<a href="https://irisshaders.net/">Iris</a>や<a href="https://www.optifine.net/home">OptiFine</a>などの軽量化Modを入れることを前提としているものがほとんどです。</p>
<p>この前提Modの中にはOptiFineのようにMinecraftの環境を作ってしまえるものがあります。<br>
しかし、前提Modで環境を作ってしまうと後述するMod管理ツールを利用できなくなってしまうため注意が必要です。</p>
<h2>Mod管理ツール</h2>
<p>名前の通りModを管理するためのツールで、有名なものではMinecraft Forgeなどがあります。<br>
これ以外にもGUIでModを管理できるCurseForgeなどもありますが、本記事ではForgeの方を使っていきます。</p>
<p>このMod管理ツールで作った環境に前提Modなどを導入し、その中で影Modなどを使う形となります。<br>
これを図で表すと下のようになります。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/0ef755be-daf7-4d15-a84a-d56e64d8edbb/Minecraft-1.webp" alt="Minecraft-1.webp"></p>
<p>そしてこれらの<strong>ver.A, ver.A', ver.A'', ver.A'''のすべてを合わせてあげないとModどころか最悪ゲーム自体が動かなくなる</strong>こともあります。</p>
<p>以下では影Modを例にとってこれらのModのバージョンを合わせる方法について説明していきます。</p>
<h1>影Modの入れ方</h1>
<p>今回は<a href="https://www.curseforge.com/minecraft/customization/bsl-shaders">BSL</a>という影Modを入れていきます。<br>
入れた後のイメージはこんな感じ↓<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/3adbbf7f-81de-4fa2-88d0-c5d77463c004/image-1.webp" alt="image-1.webp"></p>
<p>手順としては、まずOptiFineをダウンロードします。<br>
次にForgeをダウンロード・インストールし、その中にダウンロードしておいたOptiFineを導入して、最後に影Modを導入するという流れになります。</p>
<p>前提として、Minecraft Launcheについては入れてあるものとしますので、もし入れていない方はそちらを先に入れてみてください。</p>
<p><a href="https://www.minecraft.net/ja-jp/download">linkCard</a></p>
<p>また、この手順を進める前に<strong>必ずワールドデータのバックアップを取っておいてください。</strong><br>
デフォルトではワールドデータは<code>C:\Users\&lt;ユーザーネーム&gt;\AppData\Roaming\.minecraft</code>フォルダ内に入っています。</p>
<h2>OptiFineのダウンロード</h2>
<p>まずはOptiFineをダウンロードしてきます。<br>
OptiFineは以下のリンクからダウンロードすることができます。<br>
<a href="https://optifine.net/downloads">linkCard</a></p>
<p>ただし、ここで注意として、OptiFineのバージョンとMinecraftのバージョンを揃える必要があります。<br>
具体的には下の図で示している2つの数字が一致するようなバージョンを選びます。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/b14eaa16-3435-43ee-996d-45f600f09553/optifine-ver.webp" alt="optifine-ver.webp"><br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/39faf09c-8cb1-48f7-8684-39d7cc98be8c/minecraft-ver-1.webp" alt="minecraft-ver-1.webp"></p>
<p>ダウンロードしてファイルはとりあえず一旦おいておきます。</p>
<h2>Forgeのダウンロード</h2>
<p>次にForgeの導入手順を説明します。<br>
Forge導入のためにまずはJavaの実行環境をインストールしていきます。<br>
最も簡単な方法はPowerShellなどのシェルを使ってコマンドでインストールする方法です。<br>
PowerShellは↓こういうやつです。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/87026a42-d310-47fa-9e41-bff312130297/powershell.webp" alt="powershell.webp"><br>
これをWindowsの下の検索から開き、次のように打てば最新のJavaの実行環境がインストールできます。</p>
<pre><code>winget search Microsoft.OpenJDK
winget install Microsoft.OpenJDK.表示された中で一番新しいやつ
例） winget install Microsoft.OpenJDK.17
</code></pre>
<p>ただこれは非エンジニアの方には少しハードルが高いかもしれません。</p>
<p>一応ブラウザからzipファイルをダウンロードしてインストールする方法もあるので、もし難しい方はそちらも検討してみてください。<br>
<a href="https://www.javadrive.jp/start/install/index1.html">listCard</a></p>
<p>次にForgeを導入します。<br>
まず、以下のリンクからインストーラーをダウンロードします。<br>
<a href="https://files.minecraftforge.net/net/minecraftforge/forge/">linkCard</a></p>
<p>ここで、現在の自分のマインクラフトのバージョンとForgeのバージョン、そしてOptiFineのバージョンを合わせる必要があります。<br>
OptiFineとMinecraftのバージョンは先程確認したので、後はForgeとOptiFineのバージョンを合わせれば大丈夫です。<br>
図の2箇所の数字が一致していることを確認してダウンロードを行ってください。<br>
OptiFineに表示されているForgeのバージョンとForgeの公式サイトの一番上にあるForgeのバージョンが一致することは殆どないので、下にあるshow all versionから一致するものを探しましょう。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/238db9aa-32a4-426c-9e82-b02e91ca41e8/optifine-ver-forge.webp" alt="optifine-ver-forge.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/00354d43-f14c-4681-891c-99e40e14bd59/forge-ver-1.webp" alt="forge-ver-1.webp"></p>
<p>ダウンロードサイトに飛んだら右上のスキップを押せばダウンロードが始まります。</p>
<h2>影Modのダウンロード</h2>
<p>後は影Modをダウンロードしてきます。<br>
今回は以下のBSL Shadersを使いますが、これは好みによって変更してください。<br>
<a href="https://www.curseforge.com/minecraft/customization/bsl-shaders/files?version=1.19.4">linkCard</a></p>
<p>上のリンクからBSLのダウンロードサイトに飛べます。<br>
自分のマインクラフトのバージョンに合うものを選んでダウンロードしてください。<br>
複数ある場合はとりあえず一番新しいものを選んでおけば大丈夫かと思います。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/01f2628e-ae69-4477-81ea-57d63855af3e/bsl-ver.webp" alt="bsl-ver.webp"></p>
<h2>各ツールのインストール</h2>
<p>まずはForgeをインストールします。<br>
先程ダウンロードした <code>forge-~</code>というファイルをダブルクリックで実行し、手順に従えばインストールすることができます。<br>
この際、必ず<strong>自分のマインクラフトのワールドデータのバックアップを取っておいてください</strong>。<br>
ワールドデータは <code>C:\Users\&lt;ユーザーネーム&gt;\AppData\Roaming\.minecraft</code>フォルダ内に入っています。</p>
<p>次に、先程作ったForge環境にOptiFineを導入します。<br>
正常にForgeがインストールされていれば <code>C:\Users\&lt;ユーザーネーム&gt;\AppData\Roaming\.minecraft</code>に<code>mods</code>というフォルダができているので、ここに先ほどダウンロードしてきた <code>OptiFine-~</code>を置きます。</p>
<p>この状態でMinecraft Launcherを起動するとForgeの起動構成が追加されているかと思います。<br>
そのまま起動し、設定画面のビデオ設定からシェーダーの詳細設定を開きます。<br>
シェーダーフォルダーを押すと <code>C:\Users\&lt;ユーザーネーム&gt;\AppData\Roaming\.minecraft\shaderpacks</code>というフォルダが開かれるので、ここに先ほどダウンロードしてきた影Modのzipファイル（<code>BSL_~</code>）を配置し、シェーダーの詳細でBSLを選択します。<br>
<img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/01be403e-8892-4a3a-937d-380ff90bfc4b/launch-conf.webp" alt="launch-conf.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/5fa83177-7b8c-4f57-b6ea-95938de589b4/micra-home.webp" alt="micra-home.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/7f3f91e9-b7e4-454e-af42-ed9bead726f6/setting.webp" alt="setting.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/67efe71c-39ac-4100-88e6-d26700563bda/setting-video.webp" alt="setting-video.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/93a3dc36-c466-4ba7-8839-097bb0794a20/setting-shader.webp" alt="setting-shader.webp"></p>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/7289e6b8-c390-4a18-b267-f62f2c4a5f1c/setting-shader-bsl.webp" alt="setting-shader-bsl.webp"></p>
<p>ここまで来れば、後は起動して確認するだけです。<br>
ブロックの質感が変わっていれば成功です。</p>
<h1>まとめ</h1>
<p>長々と説明してきましたが、正直この通りにやってもうまく行かないことはあると思います。<br>
そういうときはダウンロードしたバージョンが正しいかなどを改めて確認してみてください。</p>
<p>これもうほとんどデバッグに近いので非エンジニアの方には本当に優しくないと思います。<br>
マイクラでModを自力で入れられるとこまで来たらかなりITリテラシ高いので、めげずに取り組んでみてください。<br>
それでは、よいマイクラライフを！</p>


<p>MinecraftのModの入れ方が予想以上に難しく、非エンジニアの方とかはかなり苦労しそうだなと思ったので、本記事ではその際に調べたことなどを書き残しておきます。</p>

Minecraftに影Modを導入する際の考え方｜Minecraft Java ver.

<p>いままでエンジニアらしくこのブログの機能をいろいろと自作してきたわけですが、ここ最近ようやっとまともに見れる程度のできになってきたのでここらで全体の構成を記事にしようかと思い立ちました。</p>
<p>なにぶん初めてのシステムづくりなので汚い部分もあるとは思いますが温かい目で見守って上げてください。</p>
<p>↓はこのブログのソースコードです。随時更新中です。</p>
<p><a href="https://github.com/Asunaro276/asunaro-blog">linkCard</a></p>
<h1>全体構成</h1>
<h2>技術スタック</h2>
<h3>TypeScript</h3>
<p>最近はWEBフロントエンドを作ろうと思うとまずTypeScriptみたいですね。<br>
私はJavaScriptをほとんど触ったことがないので、みなさんがおっしゃるTypeScriptならではのうざさにあまり共感できないでいるわけですがこれは幸せなのか不幸なのか。</p>
<h3>Next.js</h3>
<p>普通にreactでも良いのですが、Nextは痒いところに手が届きます。<br>
特に頼りになったと思う機能は以下です。</p>
<ul>
<li>動的ルーティングを勝手に作ってくれる</li>
<li>画像を勝手に最適化してくれる</li>
<li>SSG</li>
</ul>
<p>特に最後のSSGはJamstack構成には必須ですし、画像の最適化はパフォーマンスチューニングには欠かせませんでした。<br>
こういう静的なブログを作る場合にはGatsbyなどのフレームワークの方が向いているという意見も見受けられたので、一度Gatsbyのブログテンプレートを見てみたのですが開発経験の浅さも相まって初見では意味ぷー過ぎたので、よりわかりやすいNext.jsに飛びつきました。</p>
<h3>MUI</h3>
<p>コンポーネントが最初から用意されているのでほんとに楽です。<br>
特に、ちょっとした機能なのにスクラッチからだと案外めんどくさい機能（ボタンの波紋とかページネーションとか）を最初から用意してくれているのが最高です。<br>
sxでスタイルも気軽にいじれますしね。</p>
<h3>Tailwind CSS</h3>
<p>本当はMUIだけでそれなりのウェブサイトは作れるのですが、今回はサーバーサイドで静的レンダリングをする際に生のHTMLを扱う必要があったので、そのスタイリングにはTailwind CSSを使いました。<br>
ただ、MUIとTailwind CSSは両方とも強力な分、いろいろと競合が起きることも多いので併用には注意が必要です。</p>
<h2>CMS</h2>
<h3>microCMS</h3>
<p>みんな大好きmicroCMSです。比較的新しいサービスということもあり、記事が充実していないかと思いきや、公式の発信する情報やドキュメントが神がかっているのでかなりおすすめです。</p>
<p>機能についても記事公開に合わせた自動デプロイ機能やカスタムフィールドなどシンプルながらも組み合わせ次第でいくらでも強力にできそうなものを備えています。</p>
<h2>ホスティングサービス</h2>
<h3>Cloudflare Pages</h3>
<p>比較的新しいサービスらしいですが、他のサービスに比べて無料枠でできることがかなり幅広いです。</p>
<p>例として、アクセス制限やアクセス解析、セキュリティ機能、速度分析などを無料で提供してくれています。<br>
また、もともとがCDNの企業ということもあり配信パフォーマンスも高いです。</p>
<h3>Netlify</h3>
<p>実は最初はNetlifyにデプロイしておりCloudflareにはあとから移管しました。<br>
Netlifyもビルドキャッシュによるビルドの高速化やプレビュー機能など十分に強力な機能を無料で提供してくれていたのですが、無料枠だと使えるCDNが限定されているらしく、パフォーマンスの点でどうしても満足がいきませんでした。<br>
まあ、うちみたいな零細弱小ブログがなにイキってパフォーマンスチューニングとか語ってんだと言われれば反論の余地もないわけですが、勉強も兼ねたブログづくりなのでやはり突き詰められる部分は突き詰めていきたいという思いがありまして、移管を決断しました。<br>
いままでありがとう、グッバイNetlify。</p>
<h1>今までに作った機能</h1>
<h2>数式表示</h2>
<p>KaTeXを使って作りました。</p>
<p>インラインにも数式を貼れますし（$\mathrm{e}^{\mathrm{i}\theta} = \cos(\theta) + \mathrm{i}\sin(\theta)$）、次のようにディスプレイ型の数式も使えます。</p>
<p>$$\cos(\theta) = \frac{\mathrm{e}^{\mathrm{i}\theta} + \mathrm{e}^{-\mathrm{i}\theta}}{2},\ \sin(\theta) = \frac{\mathrm{e}^{\mathrm{i}\theta} - \mathrm{e}^{-\mathrm{i}\theta}}{2\mathrm{i}}$$</p>
<p>数式表示については以下の記事で詳しい解説をしているので気になる方は参照どうぞ。<br>
<a href="https://asunaroblog.net/blog/641d77aab5b671fd667829c8">linkCard</a></p>
<h2>ソースコードのハイライト</h2>
<p>サーバーサイドでのハイライトに関してはmicroCMSブログに素晴らしい解説記事が載っているのでそちらを参照するのがよろしいかと思います。<br>
一応以下のような形でファイル名を含めてハイライトができるようにしています。</p>
<pre><code>def main():
    print(&quot;Hello World&quot;)

main()
</code></pre>
<p><a href="https://blog.microcms.io/syntax-highlighting-on-server-side/">linkCard</a></p>
<h1>今後実装するかもな機能</h1>
<h2>テスト</h2>
<p>これはさっさとやりたいです。<br>
storybookも導入はしているもののあまり有効活用できていないという状況があるので、うまい付き合い方を模索しながら自分なりの使い方をしていきたいですね。</p>
<h2>ダークモード対応</h2>
<p>こちらはやり方はわかっているのですがいざやろうとすると色決めたりパレットの設定をしたりちょっと面倒だったりします。<br>
ただ、寝る前に電気消してスマホいじってるときとかにダークモードがないサイトとか開くと目が痛くて辛いときがたまにあるので、このブログの読者にはそういった不便をおかけしないようなるだけはやく取り組みたいとは思っています。</p>
<h2>こちらの記事もおすすめ</h2>
<p>これはすぐにでも作れる機能です。<br>
自分がブログ記事見るときには正直あまり必要だと思わない機能なのですが、記事を一番下まで読んだときにいきなりフッターが来るとちょっと寂しい感じがあるのでできればつけたいです。<br>
まあ、フッターと記事の間にごちゃごちゃ色々あるのも汚らしくて嫌という意見もありますが。</p>
<h2>関連記事カード</h2>
<p>アマゾンなどへの誘導リンクカードはあるのですが、このブログ内の他記事への誘導カードはもう少しリッチなものを簡単に作れそうなので作ろうかと思っています。</p>
<h2>月ごとアーカイブ</h2>
<p>これも別にどちらでも良いと思うのですが、記事の投稿頻度を自分に戒めるためにも必要なのかしら。<br>
まあ、サイドバーがごちゃごちゃしてるのも個人的には嫌いなのですが、汚らしくて。</p>
<h2>問い合わせ機能</h2>
<p>これはいつか欲しいですね。<br>
まあ、こんな零細弱小貧弱ブログにいらっしゃる物好きな方がまず少ない中で、私に問い合わせしてくださる方がいるとは思いませんが、いつかお仕事の依頼とか（妄想）受けるのに役立ってくれたらいいなあ。</p>
<p>といっても、この機能自体はmicroCMSのポストメソッドを使って実装するのでAPIやフォーム作りの勉強もできるのでモチベーション自体は割りとあったりします。</p>
<h2>SNSなどとの連携</h2>
<p>これ、必要でしょうか？<br>
そもそも私はSNSを何一つやっていないのでこの機能があってもあまり利用しなさそうという気がしています。<br>
とはいえ、RSSなんかはあってもいいのかなと思いつつ。<br>
あとは将来Twitterなんかを始めたら実装するかもですね。</p>
<h2>SEO対策</h2>
<p>いい加減SEO対策についてはしっかりやったほうがいいということはわかっています。<br>
ですが、めんどくさいですよね正直。</p>
<p>モチベーションが上がってきたらやります。</p>
<h1>まとめ</h1>
<p>今回はこのブログの構成や実装した機能について改めて説明してみました。<br>
今後ブログを作ろうという方の一助になることを願っています。</p>
<p>「ブログで会社員の10倍稼ごう！」みたいな話がたびたび持ち上がるわけですが、エンジニアなら金がどうとかではなく単にブログを作ることそのものを楽しんだらいいと思います。<br>
特にJamstackならAPIの勉強にもなりますし、新米エンジニアが初めて作るシステムとしてはうってつけだと思います。</p>
<p>だからといって金がいらないというわけではないですよ？<br>
いつかこのブログが金のなる木になってくれることを密かに期待しつつ、今後も楽しみながらブログづくりに励んでいく所存です。</p>


<p>いままでエンジニアらしくこのブログの機能をいろいろと自作してきたわけですが、ここ最近ようやっとまともに見れる程度のできになってきたのでここらで全体の構成を記事にしようかと思い立ちました。なにぶん初めてのシステムづくりなので汚い部分もあるとは思いますが温かい目で見守って上げてください。</p>

Next.js+microCMSで作るJamstackな技術ブログ｜自作ブログ

<p>前回の記事を作ろうとした際に数式の表示で死ぬほど苦労したのでその悔しさを忘れないための備忘録です。</p>
<p>同じように苦しんでいる方の参考になれば幸いです。</p>
<h1>前提</h1>
<h2>数式表示ライブラリの選択肢</h2>
<h3>MathJax</h3>
<p>最もポピュラーな数式表示ライブラリです。<br>
LaTeXとMathMLの表記が使えます。<br>
アメリカ数学会によって管理されているらしいのでほぼデファクトスタンダードになっているみたいです。<br>
その割にはサーバーサイドレンダリングとかNext.jsに関連した情報があまりなく、個人的には使いにくかったので使いませんでした。</p>
<h3>KaTeX</h3>
<p>数式の高速描画のためのライブラリです。<br>
こちらもLaTeX表記が使えますが、MathJaxと比べ表示できる記号類が限られているようです。<br>
今回、こちらのほうがシンプルにサーバーサイドレンダリングができると判断したためこちらを利用しました。</p>
<h2>この記事の内容</h2>
<p>この記事ではKaTeXとNext.jsのSSG機能を使ってサーバーサイドで数式表示されたHTMLを静的に作ろうという内容です。<br>
CMSにはmicroCMSを使っているので、Markdownファイルをgithubで管理するような構成の場合はちょっと変更が必要になると思われます。</p>
<p>また、今回の実装は正直かなりゴリ押しです。<br>
おそらくKaTeXのオプションなどをうまく使えばもっとスマートにできるでしょうが、ひとまず目標の機能は得られたのでこの実装でオーケーとしておきます。</p>
<h1>実装（下準備）</h1>
<h2>流れ</h2>
<p>全体の流れとしては</p>
<ul>
<li>コンテンツを取得</li>
<li>コンテンツを整形（今回はcheerioを使っています）</li>
<li>数式を変換（←ここがメインディッシュ）</li>
</ul>
<p>となります。</p>
<p>上2つはmicroCMSやcheerioを使っており、構成にかなり依存するので構成が違う方は3つ目のみ参照してみてください。</p>
<h2>コンテンツを取得</h2>
<p>まずはコンテンツ（ここではmicroCMSのリッチエディタのコンテンツ）を取得します。<br>
microcms-sdkを使えばこれは簡単にできます。<br>
この辺の細かい内容は↓の記事に詳しいです。<br>
<a href="https://blog.microcms.io/microcms-next-jamstack-blog/">linkCard</a></p>
<h2>コンテンツを整形</h2>
<p>コンテンツの整形にはcheerioを使っています。<br>
microCMSのブログで詳しく解説がされているので、そちらを見ることをおすすめします。<br>
個人的にはパースの処理は分けたいので別ファイルを作っています。<br>
この際のスタイリングにはTailwindCSSを使っています。</p>
<pre><code>import cheerio from 'cheerio'

export const parseParagraph = (paragraph: string) =&gt; {
  const $ = cheerio.load(paragraph)
  $(&quot;h1&quot;).each((_, element) =&gt; {
    $(element).addClass('ml-8 my-5 text-3xl font-semibold font-body')
    $(element).wrap('&lt;div class=&quot;bg-slate-100 mb-5 mt-20 flex&quot;&gt;&lt;/div&gt;')
    $(element).parent().prepend('&lt;div class=&quot;w-2 bg-yellow-400&quot;&gt;&lt;/div&gt;')
  })
  $(&quot;h2&quot;).each((_, element) =&gt; {
    $(element).addClass('ml-4 my-2 text-xl font-semibold font-body')
    $(element).wrap('&lt;div class=&quot;mb-5 flex&quot;&gt;&lt;/div&gt;')
    $(element).parent().prepend('&lt;div class=&quot;w-2 bg-yellow-400&quot;&gt;&lt;/div&gt;')
  })
  $('p').each((_, element) =&gt; {
    $(element).addClass('text-lg font-body leading-loose')
    $(element).wrap('&lt;div class=&quot;mt-5 mb-10&quot;&gt;&lt;/div&gt;')
  })

  $('ul').each((_, element) =&gt; {
    $(element).addClass('list-disc list-inside text-lg space-y-2 ml-6 pl-4 indent-[-1em]')
    $(element).children().addClass('font-thin')
  })

  $('blockquote').each((_, element) =&gt; {
    $(element).addClass('ml-4 text-xl opacity-90 font-body')
    $(element).wrap('&lt;div class=&quot;flex&quot;&gt;&lt;/div&gt;')
    $(element).parent().prepend('&lt;div class=&quot;w-2 bg-slate-200&quot;&gt;&lt;/div&gt;')
  })

  return $(&quot;body&quot;).html() as string
}
</code></pre>
<p><a href="https://blog.microcms.io/contents-parse-way/">linkCard</a></p>
<h1>KaTeXを使った数式の変換</h1>
<h2>KaTeXの導入</h2>
<p>KaTeXの導入には</p>
<ul>
<li>ローカルにインストール</li>
<li>CDN経由で利用</li>
</ul>
<p>の二種類の方法があります。</p>
<p>ローカルに入れる場合は次のようにします。</p>
<pre><code>yarn add katex
</code></pre>
<p>CDN経由で利用したい場合については今回はあまり調べていないのですが、公式を見るのがベストかと思われます。</p>
<p>ただし、Next.jsの場合は_document.jsに色々書き込むと思うのですが、HTMLの<Head>内に書き込むのとは少しだけ勝手が違うので注意が必要です。</p>
<p><a href="https://katex.org/docs/browser.html">linkCard</a></p>
<h2>数式の変換</h2>
<p>KaTeXを使って数式を変換します。<br>
サーバーサイドで処理したい場合には<code>katex.renderToString</code>を使います。</p>
<pre><code>const html = katex.renderToString(&quot;c\\pm\\sqrt{a^2 + b^2}&quot;)
</code></pre>
<p>引数としてlatexの数式を渡せば変換した結果を文字列として返してくれます。<br>
この結果は次のような形でレンダリングすることができます。</p>
<pre><code>&lt;div dangerouslySetInnerHTML={{ __html: html }} /&gt;
</code></pre>
<p>数式を変換するだけならこれだけなのですが、ブログなどで使っていくとなるとこれだけでは少々問題です。<br>
というのも、<code>renderToString</code>に文字列すべてを投げるのは現実的ではありませんし、変換してほしくない部分まで変換してしまう危険があります。</p>
<p>おそらくほとんどの人はlatex等と同様に&quot;$&quot;や&quot;[&quot;などで囲った部分のみ変換したいと思うはずなのですが、私の調べた範囲ではKaTeXの設定ではこれができませんでした。<br>
なので、今回はjavascriptの文字列操作で強引に数式部分を抜き出してしまおうという作戦に出ました。</p>
<p>なお、クライアントサイドで数式を処理する場合には&quot;$&quot;で囲った部分を自動で処理するようにできるようです。</p>
<h2>数式の抜き出し</h2>
<p>作戦としてはまず、</p>
<pre><code>htmlText.replace(正規表現, 変換処理)
</code></pre>
<p>の形でhtmlTextから数式（今回は&quot;$&quot;で囲った部分）を抜き出して、これに対して<code>renderToString</code>を適用していきます。<br>
例えば次のようになります。</p>
<pre><code>const htmlReplaced = htmlText.replaceAll(/\$\$[^\$]*\$\$/g, (substring) =&gt;
katex.renderToString(substring.replaceAll(&quot;$&quot;, &quot;&quot;).replaceAll(/(&lt;br&gt;|&lt;\\br&gt;|&amp;nbsp;|amp;)/g, &quot;&quot;),
{ output: &quot;mathml&quot;, displayMode: true, strict: &quot;ignore&quot; }))
</code></pre>
<p>htmlTextには数式を含むコンテンツが入っています。<br>
そこから<code>replaceAll</code>を使ってパターンに該当する数式部分をKaTeXで変換します。<br>
この際、正規表現を使っていますが、これの意味としては「ドルマーク2つで囲まれた部分を取り出し、その間にはドルマークを含まない文字列が入る」ようなものをマッチングします。</p>
<p>このように取り出したものはドルマーク2つで囲まれた文字列（&quot;$x=e^{10}$&quot;のような形）になっているので、ドルマークを削除するためにもう一度replaceを行っています。</p>
<p>これだけでとりあえず機能的には完成なのですが、今回はmicroCMSのリッチエディタを使っているので、その中で書きやすくするためにいくつか無視したい文字列を削除する処理を行っています。<br>
今回削除したのは<br>（改行タグ）、 （空白文字）、amp;（&amp;）の3つです。<br>
この辺は今後増えていくかもしれません。</p>
<h1>まとめ</h1>
<p>今回はKaTeXを使ったサーバーサイドでの数式の静的レンダリングについて解説しました。<br>
やっぱり自作ブログは作りたてだとちょっとした機能がなくて不便しますよね。<br>
まあ、こういうのを地道に作るのが醍醐味なんですが。<br>
これからもちょっとずつ気長に機能を作っていこうかと思います。</p>


<p>前回の記事を作ろうとした際に数式の表示で死ぬほど苦労したのでその悔しさを忘れないための備忘録です。同じように苦しんでいる方の参考になれば幸いです。</p>

Next.js+microCMS+KaTeXで数式をサーバーサイドレンダリングする｜ブログづくり

<p>先日、効果検証入門を読んでいたところ条件付き独立の仮定（Conditional Independence Assumption, CIA）という言葉が出てきました。</p>
<p>重要な概念にしてはすぐに意味の分からない言葉だったので自分なりに解釈した結果を書き残します。</p>
<p>参考にしたのは「ほとんど無害」な計量経済学と計量経済学---ミクロデータ分析へのいざないです。前者の文献は効果検証入門においてもよく引かれていた文献ですね。</p>
<p>なお、後者の文献では表題の概念は「無視可能性の仮定」という呼ばれ方をしていますのでご注意を。</p>
<p><a href="https://amzn.to/3yJSQHv">linkCard</a><br>
<a href="https://amzn.to/3D22Uyc">linkCard</a><br>
<a href="https://amzn.to/3eBvxIZ">linkCard</a></p>
<h1>条件付き独立の仮定</h1>
<h2>定義</h2>
<p>介入変数$Z_i$、外的条件（介入変数以外の結果に影響を与えるファクター）$X_i$、潜在的結果変数$Y_{0i}, Y_{1i}$について次のような関係が成り立つことを条件付き独立の仮定（無視可能性の仮定）といいます。</p>
<p>$${Y_{0i}, Y_{1i}} \perp Z_i \mid X_i$$</p>
<p>※用語の説明は一番下にまとめて載せてあります。</p>
<h2>どういう意味があるの？</h2>
<p>条件付き独立の仮定が満たされることで、回帰分析による効果測定を行うことができます。<br>
逆に言うと、回帰分析による効果測定を行ったとしても、条件付き独立の仮定が満たされていなければバイアスを含んだ測定結果になってしまう可能性があるということです。</p>
<h2>詳細な説明</h2>
<p>数式を一見しただけではわかりにくいですが、噛み砕くと次のような説明ができます。</p>
<p>例えば「大学に行くと所得は増えるか？」という問題を考えてみます。</p>
<p>このとき、まず最初に思いつくのは次のような比較だと思います。</p>
<p>「大学に行った人と大学に行っていない人で所得を比較してみる」</p>
<p>これを単純に数式に落とし込むと次のように表せます。</p>
<p>$$Y_i = \beta_{1i} + \beta_{2i} Z_i + u_i$$</p>
<p>ここで$Y_i$は所得、$Z_i$は大学に行く（$Z_i=1$）かいかない（$Z_i=1$）かを表す介入変数、$u_i$が誤差項です。</p>
<p>そして、ここでは$\beta_{2i}$（大学に行くとどれだけ所得が増えるのか）を知りたいとします。</p>
<p>つまり、この式の$Z_i$について$Z_i=1,0$とした2つの式を用意し、それぞれの$Y_i$に大学に行った人と行っていない人の平均給与を入れて連立方程式を作れば$\beta_{2i}$が求まるように思えます。</p>
<p>しかし、この方法では正確な$\beta_{2i}$を求めることができません。</p>
<p>というのも、そもそも大学に行った人（$Z_i=1$の人）というのはそうでない人に比べて所得を多くもらうような能力を初めから持っている人たちなのではないかという可能性を否定出来ないからです。</p>
<p>小難しい言い方をすると、$Z_i=1$の人たちと$Z_i=0$の人たちで潜在結果変数$Y_{0i}, Y_{1i}$に違いがあるのではないかということです。</p>
<p>つまり、$Z_i=1$の人たちの潜在結果変数を$Y_{0i, z=1}, Y_{1i, z=1}$とし、$Z_i=0$の人たちの潜在結果変数を$Y_{0i, z=0}, Y_{1i, z=0}$とすると、</p>
<p>$$Y_{0i, Z=0} \neq Y_{0i, Z=1}, Y_{1i, Z=0} \neq Y_{1i, Z=1}$$</p>
<p>となってしまっており、<strong>$Y_{0i}, Y_{1i}$の値が$Z_i$に依存してしまっている</strong>ということです。</p>
<p>これでは$Z_i=1$としたときの結果の違いが本来の効果とは別の要因（比較対象の能力の差など）にも依存してしまっており、測定にバイアスが含まれてしまいます。</p>
<h2>条件付き独立の仮定が成立するには？</h2>
<p>ではどうすれば条件付き独立の仮定が成立するのか？</p>
<p>すなわち、バイアスがかからないような測定ができるのか？</p>
<p>これにはいろいろな方法が知られており、有名なものでは</p>
<ul>
<li>能力などが似た者同士を比較してやる</li>
<li>変数$X_i$を追加して$Z_i$から介入の効果以外のバイアス（欠落変数バイアス）を抜いてやる（他の変数に吸収させる）。</li>
</ul>
<p>というようなものがあるみたいです。この辺は勉強中なので、また別記事にまとめるかもしれません。</p>
<h1>まとめ</h1>
<p>数理科学で「仮定」とか名前の付いてるものって、当たり前の概念だけど案外わかりにくいことが多いと思うのですが私だけでしょうか？</p>
<p>今回の執筆にあたっては計量経済学---ミクロデータ分析へのいざないが一番わかりやすい説明をしてくれていたと思います。いろいろな文献をあたるのってやっぱり大事ですね。</p>
<h1>用語の説明</h1>
<h2>介入変数</h2>
<p>介入するかしないかなどを表す変数で本記事では$i$さんの介入変数を$Z_i$で表しています。例えば「大学に行くと所得が増えるか？」について議論したいときは、大学に行った人には$Z_i=1$、大学に行っていない人には$Z_i=0$を与えて比較するなどの使い方をします。</p>
<h2>潜在的結果変数</h2>
<p>介入変数$Z_i$について、潜在的結果変数は次のように定義されます。</p>
<p>$$潜在的な結果変数 =\begin{cases}Y_{1i} &amp; (Z_i = 1)\\Y_{0i} &amp; (Z_i =0)\end{cases}$$</p>
<p>例えば、「大学に行くと所得は増えるか？」について検証することを考えます。</p>
<p>このとき、$Y_{1i}$はある個人$i$が大学に行ったときの賃金、$Y_{0i}$は同じ個人が大学にいかなかったときの賃金を表します。</p>
<p>注意としては、$Y_{1i}, Y_{0i}$はある個人が大学に行ったときと行かなかったときの所得を表しているので、両方を観測するのは不可能であるということです（なので&quot;潜在的&quot;結果変数です）。これを「因果推論の根本問題」といいます。</p>


<p>先日、効果検証入門を読んでいたところ条件付き独立の仮定（Conditional Independence Assumption, CIA）という言葉が出てきたのですが、重要な概念にしてはすぐに意味の分からない言葉だったので自分なりに解釈した結果を書き残します。</p>

「条件付き独立の仮定」をしっかり理解する｜計量経済学の基礎

<h1>何があった？</h1>
<p>react-hooks-testing-libraryを使ってcustom hooksをテストした際にhooks内で作ったstateが更新されない問題が起きたのでその対処法を書き残します。</p>
<p>※↓はサンプルコード</p>
<pre><code>import { useCallback, useState } from &quot;react&quot;

const useCount = () =&gt; {
  const [count, setCount] = useState&lt;number&gt;(0)
  const increment = useCallback(() =&gt; setCount((x) =&gt; x + 1), [])
  return {
    count: count,
    increment: increment
  }
}

export default useCount
</code></pre>
<pre><code>import { renderHook } from &quot;@testing-library/react&quot;
import { act } from &quot;react-dom/test-utils&quot;
import useCount from &quot;./count&quot;

test(&quot;should count up&quot;, () =&gt; {
  const { result } = renderHook(() =&gt; useCount())
  const { count, increment } = result.current
  act(() =&gt; {
    increment()
    increment()
    increment()  
  })
  expect(count).toBe(3) \\ count = 0になる
})
</code></pre>
<p><img src="https://storage.googleapis.com/p_641d41d3a492e5ac4c9226fe/fc66f7b2-7194-471e-8c21-0607914407c0%2F%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%83%86%E3%82%B9%E3%83%88.gif" alt="カウントテスト.gif"></p>
<h1>解決策</h1>
<p>当たり前のような話ですが、result.currentは現在の値しか保持してくれないらしいです。なので一回取り出すとsetStateで更新しても反映されません。ということで正しいコードは↓のようになるらしいです。</p>
<pre><code>import { renderHook } from &quot;@testing-library/react&quot;
import { act } from &quot;react-dom/test-utils&quot;
import useCount from &quot;./count&quot;

test(&quot;should count up&quot;, () =&gt; {
  const { result } = renderHook(() =&gt; useCount())
  const { increment } = result.current
  act(() =&gt; {
    increment()
    increment()
    increment()  
  })
  expect(result.current.count).toBe(3) \\ 現在の値を取り出したいなら毎回result.currentから取り出す
})
</code></pre>
<h1>まとめ</h1>
<p>今回の敗因はreactのライフサイクルをきちんと把握していないせいだと思います。これに関しても一度勉強し直してまとめたほうがよいかしら...</p>


<p>react-hooks-testing-libraryを使ってcustom hooksをテストした際にhooks内で作ったstateが更新されない問題が起きたのでその対処法を書き残します。</p>

custom hooksのテストでuseStateが更新されないときの対処法

<p>先日、来年度から入社予定の会社からインターネット広告に関する書籍が送られてきたのですが、専門用語がわからな過ぎたので、一通り調べた結果を書き残します。</p>
<p>ウェブ広告に関する解説が主で、SNS広告に関しては深掘りしていないのでその辺はご留意ください。</p>
<p><a href="https://amzn.to/3Oqj9uK">linkCard</a><br>
<a href="https://amzn.to/43g4jeq">linkCard</a></p>
<p>用語が多く、また多岐にわたるので今回は</p>
<ul>
<li>主な広告の種類</li>
<li>重要な効果指標と課金の種類</li>
<li>広告運用のための用語</li>
<li>アドテクノロジー用語</li>
</ul>
<p>に分類して掲載します。<br>
とりあえず出現頻度の高い重要な用語は目次に全て掲載し、枝葉の用語はその他の用語として分類ごとにまとめています。</p>
<h1>主な広告の種類</h1>
<h2>リスティング広告（検索連動型広告）</h2>
<p>Googleなどの検索エンジンにのせる広告。上位に出てきて広告と書いてあるやつはだいたいこれ。クリック単価が主流。</p>
<h2>ディスプレイ広告</h2>
<p>ウェブサイトの広告枠に掲載されている広告。クリック単価、インプレッション単価の両方がある。</p>
<h2>純広告（予約型広告）</h2>
<p>広告主が広告枠を事前に購入して出向する広告。新聞広告などはこれに当たる。</p>
<h1>重要な効果指標</h1>
<p>インプレッション・クリック・コンバージョンという3つの効果指標は広告の表示・クリック・成果という3つの課金ポイントにそれぞれ対応しています。これら3つを理解すれば広告のシステムに対する理解がかなり深まります。</p>
<h2>効果指標</h2>
<p>広告効果を定量的に判断・分析するための指標。広告用語の中で略語のほとんどが効果指標ということを理解しておくと頭の整理が付きやすいです。</p>
<h3>なんで大事？</h3>
<ul>
<li>インターネット広告の用語は半分くらいこれ関連</li>
<li>費用、効果（収益）などについて考える上で定量的な判断が避けて通れない</li>
</ul>
<h2>インプレッション（Imp）</h2>
<p>特定の広告の表示回数のこと。</p>
<h3>インプレッション課金</h3>
<p>表示回数に応じて課金される課金形態。</p>
<h3>なんで大事なの？</h3>
<ul>
<li>広告がどれだけユーザーの目にとまっているかの指標になる</li>
<li>他の指標（CTRなど）の算出に使う</li>
</ul>
<h2>クリック（Click）</h2>
<p>ユーザーが広告にタッチした回数。</p>
<h3>クリック課金</h3>
<p>クリック数に応じて課金される課金形態。</p>
<h3>なんで大事なの？</h3>
<ul>
<li>広告がどれだけユーザーに興味を持たれているかの指標になる</li>
<li>他の指標（CPCなど）の算出に使う</li>
</ul>
<h2>コンバージョン（CV）</h2>
<p>Webサイトにおける最終的な成果のこと。</p>
<h3>コンバージョン課金（アフィリエイト）</h3>
<p>コンバージョン数に応じて課金される課金形態。</p>
<h3>なんで大事なの？</h3>
<ul>
<li>広告運用における効果に直結する</li>
<li>他の指標（CPAなど）の算出に使う</li>
</ul>
<h2>その他の効果指標</h2>
<h3>CTR（Click Through Rate、クリック率）</h3>
<p>表示された広告がクリックされた割合（Click ÷ Imp）。リスティング広告で3～5%、ディスプレイ広告で0.4～1%くらい。</p>
<h3>CVR（Conversion Rate、コンバージョン率）</h3>
<p>クリックされた広告に対して実際に買われるなどの成果がでた割合（Conversion ÷ Click）。カテゴリにかなり依存するが10%前後くらい</p>
<h3>CPM（Cost Per Mille、インプレッション単価）</h3>
<p>1000回の広告表示あたりにかかる広告費用。インプレッション課金型の広告で主に使われる。相場は10円～500円程度。</p>
<h3>CPC（Cost Per Click、クリック単価）</h3>
<p>1クリック獲得のためにかかる費用（Cost ÷ Click）。クリック課金型の広告で主に使われる。相場はディスプレイ広告だと数円～数百円、リスティング広告だと数十円～数万円。</p>
<h3>CPA（Cost Per Action、コンバージョン単価）</h3>
<p>コンバージョン（成果）1件にかかる費用（Cost ÷ Conversion）。 コンバージョン課金型（アフィリエイト型）の広告で主に使われる。相場はカテゴリによるが数千円～数万円。</p>
<h3>SNS広告に関する指標</h3>
<p>CPF（Cost Per Follow）、CPF（Cost Per Fan）、CPV（Cost Per View）など</p>
<h1>広告運用のための用語</h1>
<h2>クリエイティブ</h2>
<p>広告として制作されたコンテンツの全て。バナー動画、画像、テキストなど。</p>
<h2>広告在庫</h2>
<p>今後のある一定期間に予想されるインプレッション数。ちょっとわかりにくいので以下詳細説明</p>
<h3>インプレッションの売買</h3>
<p>広告の売買はメディアが広告主に<strong>インプレッション（広告表示の機会）を売る行為</strong>と言い換えられる。<br>
コンバージョン（成果）の数はインプレッション数に比例するので、インプレッションが増えれば広告主はそれだけ収益を得られる。</p>
<h3>在庫が余る</h3>
<p>上の理論で行くと広告の在庫とはつまりインプレッションの余りということになる。在庫が余った状態とはつまり「インプレッション（広告を表示する機会）がまだあるのに買い手（広告を掲載したい人）がいません」という状況。<br>
広告媒体側からすると、在庫が余っていると収益を得られる機会を失っていることになるため、是が非でも広告を出してほしい。つまり<strong>広告枠が安くなる</strong>。</p>
<h3>在庫が足りない</h3>
<p>逆に在庫が足りない状況とは「広告枠の買い手がたくさんいるのにインプレッション（つまり広告枠）が余っていません」という状況。</p>
<p>広告枠はオーディションで売買されるのが一般的なので、買い手が多いと<strong>広告枠は高くなる</strong>。</p>
<h3>たまに逆の意味で使われる</h3>
<p>広告在庫という言葉はたまに出す広告（クリエイティブ）の余りという意味で使われることがある。例えば、ゲームなどで動画広告を何度もみると「動画広告の在庫切れで広告を流せません」とでることがある。</p>
<p>これを本来の意味で表現し直すと「動画広告の在庫が余っていて広告を流せません」となるわけだが、ユーザーからすると「？？？」という感じだと思う。なんで在庫が余ってるのに出せないんだ？となる。そこで、広告を見る側へのわかりやすさを優先してこのような表現にしているのだと思われる。</p>
<h1>アドテクノロジー用語</h1>
<p>アドテクノロジーとは広告の効率化のためのシステム全般のことです。効果指標ではないですが略語が多くて嫌になります。</p>
<h2>アドネットワーク</h2>
<p>複数の広告掲載メディア（Webサイト、ブログ、SNSなど）を束ねたディスプレイ広告の配信ネットワークのこと。たとえばGoogle Display Networkに登録するとGmail、ニュースサイト、ブログ、Youtubeなどのさまざまなメディアに対して一挙に広告を出すことができる。</p>
<h3>メリット</h3>
<p>広告掲載者はアドネットワークサービスに対してクリエイティブ（掲載する画像やテキスト）などを言えば複数のメディアに対して一括して広告配信ができるので楽。</p>
<h3>デメリット</h3>
<p>媒体のジャンルは選べるが、具体的な媒体は選べないのでブランドイメージを下げるようなサイトにも広告が掲載される可能性がある。<br>
また、複数のアドネットワークを使う場合管理が面倒。</p>
<h2>アドエクスチェンジ</h2>
<p>複数のアドネットワーク、掲載メディアなどを束ねた広告枠取引市場。ここでの「Exchange」とは交換ではなく取引所という意味です（これを交換だと思っている人のなんと多いことか...）。↓<br>
<a href="https://bitbank.cc/glossary/exchange">linkCard</a></p>
<h3>アドネットワークとアドエクスチェンジの違い</h3>
<p>株式市場からのアナロジーで考えるとわかりやすい。すなわち、アドエクスチェンジが株式市場（東証とか）であるとすると、アドネットワークは株式ブローカー（証券会社）、そして各メディアは各株式会社というふうに理解できる。このような環境だと、たしかにブローカーから直接株を買う人もいるだろうが、大きなシェアを占めるのは株式市場での売買になっていく。</p>
<h3>メリット</h3>
<p>特定の広告枠に対して入札できる。アドネットワークではネットワーク単位でしか広告を出せなかったのに対し、アドエクスチェンジは広告枠ごとに入札ができる。</p>
<h3>アドエクスチェンジの特徴</h3>
<ul>
<li>インプレッション単位での入札。
<ul>
<li>アドネットワークでは課金形式（クリック課金、インプレッション課金など）が統一されていなかったがアドエクスチェンジはインプレッション課金で統一されている。</li>
</ul>
</li>
<li>アドネットワークの広告在庫を融通しあえる。
<ul>
<li>アドエクスチェンジではアドネットワーク同士も広告在庫の売買ができるということ。これにより、在庫（=広告枠）が余っているアドネットワークは他のアドネットワークに対してその在庫を転売することで利益を得られ、市場全体の需要と供給が調整される。</li>
</ul>
</li>
<li>RTB（Real Time Bitting）と呼ばれるオークション方式によって広告枠の落札者が決まる。</li>
</ul>
<h2>オーディエンスデータターゲティング</h2>
<p>ユーザーの属性情報（性別、年齢、国など）や行動履歴（主にCookie）からその人の興味の有りそうな広告を配信する手法。行動履歴はデータエクスチェンジと呼ばれるデータの取引市場で売買される。</p>
<h2>DSP</h2>
<p>広告主（広告在庫の需要）側の利益最大化のためのプラットフォーム。広告在庫の買付、配信、クリエイティブの分析、入札単価の調整、オーディエンスターゲティングなどのあらゆる最適化を行う。</p>
<h2>SSP</h2>
<p>メディア（広告在庫の供給）側の収益最大化のためのプラットフォーム。インプレッションがあるごとに最も収益率の高い広告をDSPから選んで配信する。</p>
<h1>まとめ</h1>
<p>とりあえず今回はここまでです。アクセス解析やSEO用語についてはまた別の記事でまとめるかも。</p>


<p>先日、来年度から入社予定の会社からインターネット広告に関する書籍が送られてきたのですが、専門用語がわからな過ぎたので、一通り調べた結果を書き残します。</p>

インターネット広告の仕組みと用語｜初心者向けにわかりやすく解説

<p>tailwindcssとMUIを併用しているときにButtonコンポーネントのvariantにcontainedを指定するとホバーしていない際にボタンが表示されなくなったので、その原因と解決策を書き残します。</p>
<h1>解決策</h1>
<p>一番簡単な解決策はtailwindcssのpreflightを停止することです。</p>
<pre><code>module.exports = {
  // 省略
  corePlugins: {
    preflight: false,
  },
}
</code></pre>
<p>他にはpreflightを書き換えるなどでも対応可能なようです。詳しくは公式ドキュメントを参照のこと。↓<br>
<a href="https://tailwindcss.com/docs/preflight">linkCard</a></p>
<h1>原因</h1>
<p>このバグの原因はtailwind CSSのpreflightにあるようです。preflightとはスタイルの統一性を整えるためにtailwind CSSを使った際にデフォルトで付けられるスタイルのことです。以下のファイルで適用されています。</p>
<pre><code>@tailwind base; /* Preflight will be injected here */

@tailwind components;

@tailwind utilities;
</code></pre>
<p>ここでbuttonタグすべてにbackground-color: transparentが適用されてしまっていました。</p>
<p>今回のようにMUIを使う際にはスタイルの統一性はそちらでとればよく、むしろ干渉してバグが起こりやすいのでpreflightは切ってしまってもよいと個人的には思います。ただ、それだとtailwindを使うメリットは減ってしまうのでmuiのsxのみ利用でもいいのかなと思ったりもします。</p>


<p>MUI+tailwindcssでButton componentが透明になる問題の原因と対処法です</p>

MUI+tailwindcssでButton componentが透明になる問題の解決策

<p>先日、来年度から入社予定の会社から論理的推論に関する以下の課題図書が送られてきました。</p>
<p><a href="https://amzn.to/3Sg5hlT">linkCard</a></p>
<p>この本の内容で、演繹法と帰納法については以前からなんとなく知っていたのですが、アブダクションについては知らなかったので、調べた結果を書き残します。</p>
<h1>論理的推論</h1>
<h2>論理的推論とは</h2>
<p>ウィキペディアによると</p>
<blockquote>
<p>推論（すいろん、英語: inference）とは、既知の事柄を元にして未知の事柄について予想し、論じる事である。</p>
</blockquote>
<p>だそうです。さらに、論理的推論といった場合には論理学における推論のことを指しており、これは</p>
<ul>
<li>演繹法</li>
<li>帰納法</li>
<li>アブダクション</li>
</ul>
<p>の三つに大別されるそうです。</p>
<h2>問題設定</h2>
<p>この記事では簡単に以下のような問題設定を使って各推論方法についての説明を試みます。</p>
<pre><code>前提条件：夏が暑い
規則：夏が暑いとアイスクリームがよく売れる
結果：アイスクリームがよく売れる
</code></pre>
<p>論理的推論が使えるのはこの3つのうちの<strong>2つが既知で1つが未知</strong>の場合です。そのような状況で残り1つの未知の事柄を予想するのが論理的推論です。</p>
<h1>演繹法</h1>
<h2>演繹法とは</h2>
<p>まず最初に説明するのが演繹法です。演繹法は結果が未知の場合の推論方法で、上の例題では次のようになります。</p>
<ul>
<li>前提条件：今年の夏は暑い</li>
<li>規則：夏が暑いとアイスクリームがよく売れる</li>
<li>結果（予想）：今年の夏はアイスクリームがよく売れるだろう</li>
</ul>
<p>ここで注意すべきなのは、推論は<strong>あくまで予想</strong>なのでこれが本当に当たっているのかどうかには、検証作業が別途必要であるということです。</p>
<h2>使い道</h2>
<p>演繹法は一般に数学者の頭の使い方であるといわれることがあります。例えば方程式を解く場合、与式（前提条件）を変形規則（規則）に従って変形し、結論（結果）を導きます。</p>
<p>一方、ビジネスにおいては検証と未来予想に使われることが多いようです。例えば、次に説明する帰納法から得た規則を検証したり、企画立案のための方針にいかしたりということですね。</p>
<h1>帰納法</h1>
<h2>帰納法とは</h2>
<p>2つ目に説明するのが帰納法です。帰納法は規則が未知の場合の推論方法で、上の例題では次のようになります。</p>
<pre><code>前提条件1：2年前の夏は暑かった
結果1：2年前の夏はアイスクリームがよく売れた
前提条件1：去年の夏は暑かった
結果1：去年の夏はアイスクリームがよく売れた
規則（予想）：夏が暑いとアイスクリームがよく売れるだろう
</code></pre>
<p>ここで注意すべきは、前提条件と結果の組み合わせが複数なければ帰納法の信ぴょう性は下がってしまうということです。また、演繹法と同じくあくまで予想なので、推論の正しさについては別途検証が必要です。</p>
<h2>使い道</h2>
<p>帰納法は一般に科学者（物理学者など）の頭の使い方であるといわれることがあります。例えばニュートンは木にぶら下がったりんご（前提条件）が落ちた（結果）ことから物質は引き合う（規則）という結論を出しました。</p>
<p>ビジネスにおいてもこのような事象と事象をつなぐ規則を知っておくことで戦略立案などに役立つそうです。（よくわからぬ）</p>
<h1>アブダクション</h1>
<h2>アブダクションとは</h2>
<p>最後にに説明するのが本記事のメインディッシュであるアブダクションです。アブダクションは前提条件が未知の場合の推論方法で、上の例題では次のようになります。</p>
<ul>
<li>結果：20年前の夏はアイスクリームがよく売れた</li>
<li>規則：夏が暑いとアイスクリームがよく売れる</li>
<li>前提条件（予想）：20年前の夏は暑かった</li>
</ul>
<h2>よくある間違い</h2>
<p>アブダクションは帰納法と混同することが多いようです（実際私の読んだ書籍でもこの二つをごっちゃにしている節が見受けられました）。以下によくある間違いを紹介します。</p>
<ul>
<li>結果：20年前の夏はアイスクリームがよく売れた</li>
<li>前提条件（仮説）：20年前の夏は暑かったのではないか</li>
<li>規則（結論）：夏が暑いとアイスクリームがよく売れる</li>
</ul>
<p>この例と一つ上の例の違いは、前提条件のみが未知なのか前提条件と規則の二つが未知となっているのかということです。前提条件と規則の二つが未知の場合には基本的にアブダクションは使用できません。この場合、まずは帰納法を使うのが定石です。すなわち、まず前提条件と結果の組（今回の場合「夏が暑く、かつアイスクリームが売れた」年の組）を複数用意し、ここから帰納法により「夏が暑いとアイスクリームが売れる」という規則を導きます。そこから、あぶだくしょんにより前提条件を導くという流れを取るのが正しい推論になります。</p>
<h2>使い道</h2>
<p>アブダクションは歴史学者の頭の使い方であるといわれることがあります。例えば歴史学者は、ある遺物がここにあり（結果）、この遺物は特定の宗教を信仰している人々の遺跡からよく出土する（規則）ため、この地ではその宗教が信仰されていた、というような考え方をします。</p>
<p>また、ビジネスでも売り上げが伸びた原因、売上が落ちた原因などを調べるためにアブダクションを用います。</p>
<p>まとめ</p>
<ul>
<li>演繹法、帰納法、アブダクションは混同しやすいので前提条件、規則、結果という三つの要素と紐づけて覚えよう</li>
<li>三つの推論はわざわさ考えるまでもなく直感的にもわかるようなことを言っています。しかし、この三つを意識的にうまく組み合わせていくことで、直感ではわからないような深い洞察を得ることができるようになります（論理的思考ってそういうものですよね）。</li>
</ul>


<p>論理的推論の方法の一つであるアブダクションとはどのようなものでしょうか？この記事ではアブダクションを含めた論理的推論の手法について具体例をもとに解説しています。</p>

アブダクションとは｜意味から具体的な例題まで解説

<p>状況</p>
<p>TypeScript + Next.js + Reduxで以下のようにuseSelectorを使おうとした際，useSelectorの引数でts(2339)が出た。</p>
<pre><code>const Component = () =&gt; {
  const current_page = useSelector(state =&gt; state.page.current_page)　// ← この部分
  switch (current_page) {
    case 'project':
      return &lt;HomeProject /&gt;
    default:
      return &lt;Dashboard /&gt;
 }

</code></pre>
<p>解決策</p>
<p>useSelectorの引数の無名関数における引数（上のコードのstate）の型を指定する</p>
<ol>
<li>useSelectorで取り出す状態の型（ここではRootState）を定義</li>
</ol>
<pre><code>import { combineReducers } from &quot;redux&quot;;
import inputReducer from &quot;./reducers/input&quot;;
import pageReducer from &quot;./reducers/page&quot;;
import { configureStore } from &quot;@reduxjs/toolkit&quot;;

const rootReducer = combineReducers({input: inputReducer, page: pageReducer})

export const store = configureStore({
  reducer: rootReducer
})

store.subscribe(()=&gt; {console.log(store.getState())})

export type RootState = ReturnType&lt;typeof store.getState&gt;
export type RootDispatch = typeof store.dispatch
</code></pre>
<p>2.stateの型を指定</p>
<pre><code>const Component = () =&gt; {
  const current_page = useSelector((state: RootState) =&gt; state.page.current_page)
  switch (current_page) {
    case 'project':
      return &lt;HomeProject /&gt;
    default:
      return &lt;Dashboard /&gt;
 }
</code></pre>
<p>↓参考リンク<br>
<a href="https://stackoverflow.com/questions/60777859/ts2339-property-tsreducer-does-not-exist-on-type-defaultrootstate">linkCard</a></p>


<p>TypescriptでuseSelectorを使った時に出てくるエラーProperty '〇〇' does not exist on type 'DefaultRootState'の対処法を解説しています。</p>