![wasm-othello](/images/posts/wasm-othello/wasm-othello.png)

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

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

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

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

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

## はじめに

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

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

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

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

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

![WebAssemblyを利用したイメージ図](/images/posts/wasm-othello/wasm.png)

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

例えば、次の盤面での白の打つべき最善手を考えてみます。ここでは、簡略化のためにAとBの2箇所に絞って探索を行い、2手先までを探索してみます。

![盤面](/images/posts/wasm-othello/board.png)

相手は常に最前手を打つと予測するので、Aを打った場合は最大評価値は100となる位置に石を置いてきます。これに対してBに打った場合は最大評価値は15の位置に石を置いてきます。ここではBに打った方が自分が有利なので、Bを最善手として決定します。

![Aに打った場合](/images/posts/wasm-othello/board_select_A.png)

![Bに打った場合](/images/posts/wasm-othello/board_select_B.png)

このアルゴリズムではよりN手先を探索する方が精度が上がり最善手の精度が高くなります。しかし、探索の深さが増えるほどに探索範囲が爆発的に増えて計算時間が膨大になるため、ある一定の深さで探索を打ち切るという事をします。逆に言えば、処理速度を向上させればそれだけ探索範囲を深くできるためCPUを強くすることができます。  

今回のオセロではCPUのレベルを探索の深さと合わせてあるため、レベルを上げるほど探索範囲が増大してCPUの計算時間が処理速度に依存するようになっています。

ミニマックス法は参考となるサイトが沢山あるので、詳細はそちらを参照してください。  
- [ミニマックス法 \- Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9%E6%B3%95)
- [web帳 \| 5分で覚えるAI Minimax（ミニマックス）法とalpha\-beta法](https://www.webcyou.com/?p=6997)

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

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

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

![処理速度のグラフ](/images/posts/wasm-othello/speed.png)

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

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

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

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

WebAssemblyでオセロを作った話


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

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

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

## プロジェクトの作成

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

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

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

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

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

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

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

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

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

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

export default Home;
```

## ユーザー認証の実装

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

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

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

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

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

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

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

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

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

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

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

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

export default App;
```

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

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

interface LoginProps extends RouteComponentProps {}

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

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

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

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

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

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

interface ProfileProps extends RouteComponentProps {}

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


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

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

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

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

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

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

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

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

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

interface PrivateRouteProps extends RouteComponentProps {
  component: ComponentType;
}

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

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

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

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

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

export default App;
```

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

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

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

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

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

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

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

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

export interface PrivateRouteComponentProps {
  user?: User;
};

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

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

  const user = getUser();

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

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

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

interface ProfileProps extends PrivateRouteComponentProps {}

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


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

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


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

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

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

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

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

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

```
$ webpack

 SMP  ⏱
General output time took 21.63 secs

 SMP  ⏱  Loaders
modules with no loaders took 7.4 secs
  module count = 5702
ts-loader took 4.96 secs
  module count = 3

...

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets:
  bundle.js (2.16 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
  main (2.16 MiB)
      bundle.js

WARNING in webpack performance recommendations:
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/
✨  Done in 23.36s.
```

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

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

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

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

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

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

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

```
$ webpack

 SMP  ⏱
General output time took 6.3 secs

 SMP  ⏱  Loaders
ts-loader took 5.47 secs
  module count = 3
modules with no loaders took 1.81 secs
  module count = 160

...

✨  Done in 7.69s.
```

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

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

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


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

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

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

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

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

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

  return {
    user,
  };
};
```

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

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

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

export default IndexPage;
```

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

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

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

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

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

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

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

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

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

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

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

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

![ページ読み込み](/images/posts/nextjs-storage/move-page.gif)

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

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

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

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

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

export default DynamicUserPage;
```

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

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

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

  return {
    user,
  };
};
```

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

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

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


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

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

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

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

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

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


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

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


1つのリポジトリ内でフロントエンドとサーバーのコードをディレクトリ分割の形式で管理していましたが、色々と辛くなってきたので、リファクタしてモノリポ化しました。  
その時に考慮した事をまとめています。

※ リファクタ後のリポジトリはプライベートリポジトリなので公開していません。

## 開発環境
フロントエンドのフレームワークとしてNext.jsを利用しており、外部へのAPIリクエストのプロキシを目的としてBFFをNext.jsのカスタムサーバーとしてexpressを用いて実装しています。

* BFF: TypeScript, Node.js, express（Next.jsのカスタムサーバー）
* フロントエンド: TypeScript, Next.js

### 初期構成
リファクタ前の構成は次のようになっており、ディレクトリ分割によりフロントとサーバーのコードを管理している状態でした。

```
.
├── .storybook
├── pages
├── public
├── src
│   ├── client
│   ├── common
│   ├── config
│   ├── server
│   └── types
├── stories
├── test
│   ├── src
│   │   ├── client
│   │   ├── common
│   │   └── server
│   └── tsconfig.json
├── next.config.js
├── nodemon.json
├── package.json
├── server.ts
├── tsconfig.json
├── tsconfig.common.json
└── tsconfig.server.json
```

### 初期構成の問題
初期のディレクトリ構成ではルートに大量のファイルやディレクトリが存在していて、初見で見た時にどのファイルやディレクトリがフロントとサーバーのどちらに関係しているのか非常に分かり辛い状態でした。また `src` や `test` の中で `server` と `client` でディレクトリを分けていますが、フロントとサーバーではTypeScriptの設定が異なるため、tsconfigの設定も複雑化していました。  
※ 説明のために省略していますが、実際は他にもDockerのディレクトリなども存在します。

## モノリポ化

### 利用ツールの検討
今回は yarn workspace のみを利用してモノリポ化を進めました。

モノリポ化で利用されるライブラリとしては [lerna](https://github.com/lerna/lerna) が有名ですが、採用を見送りました。今回のケースでは yarn workspace のみで目的が達成できたのと、lerna が BabelなどのOSSプロジェクト（一般に公開する前提のプロジェクト）をモノリポ化する目的で作られているように見え、プライベートなリポジトリでは冗長かつ依存ツールを追加して管理コストが増える事は避けたかったからです。

フロントとサーバーをモノリポで管理するツールとして [Nx](https://nx.dev/react) も検討しましたが、簡単に触った感じでは想像以上にフルスタックな印象を受け、Nx のディレクトリ構成に従う必要がありそうで、既存プロジェクトの移行コストが非常に高そうだったので見送りました。

参考として、 [Yarn Workspaces: monorepo management without Lerna for applications and coding examples](https://codewithhugo.com/yarn-workspaces-application-monorepo/) とかの記事もありました。

### TypeScript Project Reference
モノリポ化にあたり、TypeScript の [Project Reference](https://www.typescriptlang.org/docs/handbook/project-references.html) を新たに導入しました。これは、TS3.0 から追加された仕組みでTypeScriptのプロジェクトを独立して管理する事ができます。モノリポによりパッケージを分割するので、合わせてTypeScriptのビルドなどもパッケージ単位で分割したくて導入しました。

モノリポ環境では、@app/web => @app/server と依存している時に、@app/web を先にビルドすると、@app/server がビルドされておらずモジュール解決に失敗する問題が発生する可能性があります。Project Reference を導入すると、`tsc --build` と実行することで、@app/web をビルドする時に合わせて @app/server を必要に応じてビルドしてくれるので、依存関係の問題を解消する事もできます。

### 最終構成

モノリポ化した後のディレクトリ構成は次のようになりました。フロントとサーバーがパッケージ単位で分割されて関連する設定ファイルやディレクトリもパッケージでまとめられたので、非常に見通しが良くなりました。

```
├── workspaces
|   ├── common                複数のパッケージから共通で利用するパッケージ
|   │   ├── src               ソースコード置き場
|   |   ├── package.json
|   |   └── tsconfig.json     
|   ├── config                設定ファイルを保持するパッケージ
|   │   ├── index.ts          バレルファイル
|   │   ├── firebase.ts       
|   |   ├── package.json
|   |   └── tsconfig.json     TypeScriptの設定ファイル
|   ├── server                サーバー側のパッケージ
|   │   ├── src               ソースコード置き場
|   │   ├── test              テストコード置き場
|   │   ├── types             型定義ファイル置き場
|   |   ├── package.json
|   |   └── tsconfig.json     
|   ├── web
|   |   ├── .storybook        Storybookの設定ファイル置き場
|   |   ├── public            画像などの公開ファイル置き場
|   |   ├── pages             Next.jsのページコンポーネント置き場
|   |   ├── src
|   |   ├── stories           Storybookのストーリーファイル置き場
|   |   ├── test              テストコード置き場
|   |   ├── next.config.js    Next.jsの設定ファイル
|   |   ├── nodemon.json      開発環境でのNext.jsのカスタムサーバー自動起動の設定
|   |   ├── package.json
|   |   ├── server.ts         Next.jsのカスタムサーバー（実装はserverパッケージを参照）
|   |   ├── tsconfig.json
|   |   └── tsconfig.server.json
|   └── tsconfig.json
└── pakcage.json
```

`web` パッケージの package.json と tsconfig.json の一部です。

```json
# web/package.json

{
    "dependencies": {
        "@app/server": "*"
    }
}
```

```json
# web/tsconfig.json

{
    "extends": "../tsconfig.json",
    "references": [
        { "path": "../server" }
    ]
}
```


ディレクトリ分割でフロントエンドとサーバーのコードを管理していたリポジトリをリファクタしてモノリポ化した時のまとめ。

TypeScriptプロジェクトをモノリポ化した時のまとめ


ISUCON10に向けた復習として [ISUCON 夏季講習 2017](http://isucon.net/archives/50648750.html) をやりました。ボトルネック発見のための基本的なデータ収集の部分だけまとめています。

## 環境構築
仮想マシンとしてVirtualBoxを用いて、問題は [isucon7の予選問題](https://github.com/matsuu/vagrant-isucon/tree/master/isucon7-qualifier) を利用します。

```shell
# プライベートネットワークのIPアドレスを指定
$ vi Vagrantfile
   # Create a private network, which allows host-only access to the machine
   # using a specific IP.
-  config.vm.network "private_network", ip: "192.168.33.10"
+  config.vm.network "private_network", ip: "192.168.33.10"

# 仮想環境を構築
$ g clone https://github.com/matsuu/vagrant-isucon.git
$ cd vagrant-isucon/icuon7-qualifier
$ vagrant up
$ vagrant halt # 初回起動だとimageの仮想マシンでアプリケーションが起動しなかった
$ vagrant up 
```

## ベンチマークを実行

最初にアプリケーションサーバーの仮想マシンに割り当てられたIPアドレスを確認する。

```shell
$ vagrant ssh image
$ ifconfig 
...
enp0s9    Link encap:Ethernet  HWaddr 08:00:27:4a:09:63
          inet addr:172.28.128.8  Bcast:172.28.128.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe4a:963/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4968 (4.9 KB)  TX bytes:1332 (1.3 KB)
...          
```

確認したIPアドレスに対してベンチを実行する。

```shell
$ vagrant ssh bench
$ cd /home/isucon/isubata/bench
$ bin/bench -remotes 172.28.128.8 # imageマシンのIPアドレスを指定
[isu7q-bench] 2020/07/26 09:33:46.171614 dataset.go:37: datapath ./data
[isu7q-bench] 2020/07/26 09:33:47.656776 bench.go:472: Remotes [172.28.128.8]
[isu7q-bench] 2020/07/26 09:33:47.656810 bench.go:346: State.Init()
[isu7q-bench] 2020/07/26 09:33:47.663825 bench.go:348: State.Init() Done
[isu7q-bench] 2020/07/26 09:33:47.663853 bench.go:350: requestInitialize()
[isu7q-bench] 2020/07/26 09:33:47.756337 bench.go:358: requestInitialize() Done
[isu7q-bench] 2020/07/26 09:33:47.756358 bench.go:363: preTest()
[isu7q-bench] 2020/07/26 09:33:58.556061 bench.go:371: preTest() Done
[isu7q-bench] 2020/07/26 09:33:58.556186 bench.go:380: validationMain()
[isu7q-bench] 2020/07/26 09:33:59.560581 bench.go:267: Increase Load Level.
[isu7q-bench] 2020/07/26 09:34:00.557278 bench.go:263: Cannot increase Load Level. Reason: SlowPath /message Before 11.790899ms
[isu7q-bench] 2020/07/26 09:34:01.557413 bench.go:263: Cannot increase Load Level. Reason: SlowPath /profile/yamaoka_shinsuke Before 415.740187ms
[isu7q-bench] 2020/07/26 09:34:02.557313 bench.go:260: Cannot increase Load Level. Reason: RecentErr 2020-07-26 09:34:02.336753948 +0000 UTC m=+16.304791155 リクエストがタイムアウトしました (POST /message ) Before 220.553901ms
```

## アプリケーションの動作確認

ブラウザで [http://192.168.33.10](http://192.168.33.10) にアクセスすれば動作確認ができます。ベンチマーク実行前の場合はデータが無く動作確認がやり辛いので、ベンチマークを先に実行しておく事をオススメします。アカウントは適当に新規登録してログインしてください。

## 仮想環境のMySQLに接続する

sshの設定を確認する。MySQLの接続情報は [ansibleの設定ファイル](https://github.com/matsuu/ansible-isucon/blob/master/isucon7-qualifier/roles/mysql/tasks/main.yml) を参照しました。

```shell
$ vagrant ssh-config image
Host image
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/tomohiro/workspace/isucon/vagrant-isucon/isucon7-qualifier/.vagrant/machines/image/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL
```

MySQLクライアントで次の設定でMySQLに接続します。

```
MySQLホスト: 127.0.0.1
ユーザー名: isucon
パスワード: isucon
データベース: isubata
SSHホスト: 192.168.33.10
SSHユーザー: vagrant
秘密鍵: ~/isucon7-qualifier/.vagrant/machines/image/virtualbox/private_key
```

## 実装言語を変更する
ISUCONでは複数の言語から自分たちが好きな言語を利用できます。ここでは、JavaScript(Node.js)に実装言語を変更します。参考実装の切り替えは、[ISUCON7 予選マニュアル](https://gist.github.com/941/8c64842b71995a2d448315e2594f62c2)を参照しました。

```shell
# アプリケーションサーバーで作業
$ vagrant ssh image

# サービスの一覧を確認
$ ls -l /etc/systemd/system/ | grep isubata
-rw-r--r-- 1 root root  331 Jul 26 09:01 isubata.golang.service
-rw-r--r-- 1 root root  363 Jul 26 09:01 isubata.nodejs.service
-rw-r--r-- 1 root root  367 Jul 26 09:01 isubata.perl.service
-rw-r--r-- 1 root root  386 Jul 26 09:01 isubata.php.service
-rw-r--r-- 1 root root  386 Jul 26 09:01 isubata.python.service
-rw-r--r-- 1 root root  382 Jul 26 09:01 isubata.ruby.service

# 実行中の参考実装を確認
vagrant@ubuntu-xenial:~$ systemctl list-unit-files --type=service | grep isubata
isubata.golang.service                     disabled
isubata.nodejs.service                     disabled
isubata.perl.service                       disabled
isubata.php.service                        disabled
isubata.python.service                     enabled
isubata.ruby.service                       disabled

# 参考実装の言語を変更
$ sudo systemctl stop isubata.python.service
$ sudo systemctl disable isubata.python.service
$ sudo systemctl start isubata.nodejs.service
$ sudo systemctl enable isubata.nodejs.service
```

起動を確認する。

```shell
$ service isubata.nodejs status
● isubata.nodejs.service - isucon7 qualifier main application in nodejs
   Loaded: loaded (/etc/systemd/system/isubata.nodejs.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-07-26 12:24:52 UTC; 2min 59s ago
 Main PID: 5901 (node)
   CGroup: /system.slice/isubata.nodejs.service
           └─5901 /home/isucon/local/node/bin/node /home/isucon/isubata/webapp/nodejs
```

## ボトルネック計測

### 監視ツールのインストール
以下のツールから好きなのを選んでインストールします。

* htop
* dstat
* glances
* netdata

```shell
$ sudo apt install htop
$ sudo apt isntall dstat
$ sudo apt install glances
$ bash <(curl -Ss https://my-netdata.io/kickstart-static64.sh)
```

### 監視ツール実行の様子

ベンチマーク実行中のCPUやメモリなどのリソース状況を可視化できます。

#### glances

```shell
$ glances
ubuntu-xenial (Ubuntu 16.04 64bit / Linux 4.4.0-184-generic)                                                     Uptime: 3:06:11

CPU      99.7%  nice:     0.2%             LOAD    2-core             MEM     53.6%  active:    1.51G             SWAP      0.0%
user:    74.7%  irq:      0.0%             1 min:    7.61             total:  1.95G  inactive:   262M             total:       0
system:  23.1%  iowait:   0.2%             5 min:    6.71             used:   1.05G  buffers:   54.1M             used:        0
idle:     0.3%  steal:    0.0%             15 min:   3.86             free:    928M  cached:     779M             free:        0

NETWORK     Rx/s   Tx/s   TASKS 123 (228 thr), 1 run, 122 slp, 0 oth sorted automatically by cpu_percent, flat view
enp0s3       6Kb    6Kb
enp0s8        0b     0b     CPU%  MEM%  VIRT   RES   PID USER        NI S    TIME+ IOR/s IOW/s Command
enp0s9     133Kb 40.1Mb    179.3  20.1 1.52G  402M  1225 mysql        0 S 20:15.77     0     0 /usr/sbin/mysqld
lo         550Mb  550Mb     12.8  22.8 1.53G  456M  5901 isucon       0 S  1:12.94     0     0 /home/isucon/local/node/bin/node
                             2.9   1.4 89.8M 27.6M  6345 vagrant      0 R  0:00.83     0     0 /usr/bin/python3 /usr/bin/glances
DISK I/O     R/s    W/s
sda1           0   359K
sdb            0      0   Warning or critical alerts (lasts 4 entries)
                          2020-07-26 12:38:07 (ongoing) - CPU_SYSTEM (99.7)
FILE SYS    Used  Total   2020-07-26 12:37:55 (ongoing) - CPU_USER (74.8)
/ (sda1)   3.68G  9.63G   2020-07-26 12:37:51 (0:00:04) - WARNING on CPU_SYSTEM (81.2)
2020-07-26 12:38:07       2020-07-26 12:37:36 (ongoing) - LOAD (1.9)
```

#### netdata
ブラウザで http://<imageマシンのIPアドレス>:19999 にアクセスします。今回の場合は、http://172.28.128.8:19999/ にアクセスすれば確認ができます。

![netdata](/images/posts/isucon-summer-course-2017/netdata.png)

## alpでアクセスログを解析

### alpをインストール

```shell
$ wget https://github.com/tkuchiki/alp/releases/download/v1.0.3/alp_linux_amd64.zip
$ sudo apt install unzip
$ unzip alp_linux_amd64.zip
$ sudo install ./alp /usr/local/bin
```

### nginxにalp用の出力を追加

```shell
$ sudo vi /etc/nginx/nginx.conf
http {
        ...

        ##
        # Logging Settings
        ##

        log_format ltsv "time:$time_local"
                        "\thost:$remote_addr"
                        "\tforwardedfor:$http_x_forwarded_for"
                        "\treq:$request"
                        "\tstatus:$status"
                        "\tmethod:$request_method"
                        "\turi:$request_uri"
                        "\tsize:$body_bytes_sent"
                        "\treferer:$http_referer"
                        "\tua:$http_user_agent"
                        "\treqtime:$request_time"
                        "\tcache:$upstream_http_x_cache"
                        "\truntime:$upstream_http_x_runtime"
                        "\tapptime:$upstream_response_time"
                        "\tvhost:$host";

        access_log /var/log/nginx/access.log ltsv;
        error_log /var/log/nginx/error.log;

$ sudo rm /var/log/nginx/access.log && sudo systemctl reload nginx
```

### alpでアクセスログを解析
ベンチマークを実行後にalpでアクセスログを集計して計測結果を見てみます。処理時間の合計で降順ソートした結果を見てみると、 `/message` と `/fetch` へのアクセスに時間を要しています。また、 `/icons` 配下の画像のレスポンスも気になりますね。  
ここで修正した気持ちをグッと抑えて次はMySQLのクエリ解析を実施していきます。

```shell
$ alp ltsv -r --sort sum --file /var/log/nginx/access.log
+-------+-----+-----+-----+-----+-----+--------+------------------------------------------------------+-------+--------+---------+--------+--------+--------+--------+--------+------------+------------+--------------+------------+
| COUNT | 1XX | 2XX | 3XX | 4XX | 5XX | METHOD |                         URI                          |  MIN  |  MAX   |   SUM   |  AVG   |   P1   |  P50   |  P99   | STDDEV | MIN(BODY)  | MAX(BODY)  |  SUM(BODY)   | AVG(BODY)  |
+-------+-----+-----+-----+-----+-----+--------+------------------------------------------------------+-------+--------+---------+--------+--------+--------+--------+--------+------------+------------+--------------+------------+
|    90 |   0 |  60 |   0 |  30 |   0 | GET    | /message                                             | 0.002 | 10.216 | 397.354 |  4.415 |  0.003 |  3.236 | 10.084 |  4.455 |      5.000 |  52648.000 |  1261915.000 |  14021.278 |
|    44 |   0 |   7 |   0 |  37 |   0 | GET    | /fetch                                               | 0.002 | 10.085 | 350.770 |  7.972 |  0.002 | 10.001 |  0.002 |  3.769 |      0.000 |   3098.000 |    21687.000 |    492.886 |
|    18 |   0 |   5 |   0 |  13 |   0 | GET    | /icons/7598595abd317f5ae637300a27f95e3c700376a7.png  | 0.820 | 10.028 | 143.519 |  7.973 |  0.820 | 10.002 |  7.973 |  2.878 |      0.000 | 437319.000 |  2186261.000 | 121458.944 |
|    17 |   0 |   6 |   0 |  11 |   0 | GET    | /icons/c434098fec37fd0d2c1e646d104220f6ffabbea7.png  | 0.132 | 10.009 | 137.344 |  8.079 |  0.132 | 10.005 |  7.973 |  2.903 |      0.000 | 103218.000 |   619208.000 |  36424.000 |
|    17 |   0 |   5 |   0 |  12 |   0 | GET    | /icons/61463cd868570a29cc1b74232000e84d3276e315.png  | 0.228 | 10.130 | 136.311 |  8.018 |  0.228 | 10.015 | 10.000 |  3.084 |      0.000 | 381286.000 |  1905666.000 | 112098.000 |
|    18 |   0 |   6 |   0 |  12 |   0 | GET    | /icons/5e981ef46ec0f47bdc2f188673325b85078f5235.png  | 0.144 | 10.043 | 135.467 |  7.526 |  0.144 | 10.000 |  9.019 |  2.927 |      0.000 | 769314.000 |  4613375.000 | 256298.611 |
|    17 |   0 |   7 |   0 |  10 |   0 | GET    | /icons/158fa9df919970ac8bc3bc2724ed5b02fe30968d.png  | 0.140 | 10.047 | 125.555 |  7.386 |  0.140 | 10.047 |  9.999 |  3.542 |      0.000 | 115188.000 |   806284.000 |  47428.471 |
|    14 |   0 |   3 |   0 |  11 |   0 | GET    | /icons/0614f0cea1b70fb71b4c3b88545a42327157a41e.jpg  | 4.715 | 10.138 | 125.212 |  8.944 |  4.958 | 10.021 | 10.047 |  2.104 |      0.000 | 559681.000 |  1678461.000 | 119890.071 |
|    14 |   0 |   5 |   0 |   9 |   0 | GET    | /icons/ba2d2384f825a83862f3b61302468b2e07f0a0f7.png  | 3.736 | 10.026 | 119.459 |  8.533 |  3.736 | 10.026 | 10.025 |  2.271 |      0.000 | 294773.000 |  1473311.000 | 105236.500 |
|    14 |   0 |   4 |   0 |  10 |   0 | GET    | /icons/65ea5a70b1fcf8f5f816b01b87f2aca2251315b0.png  | 2.330 | 10.039 | 117.397 |  8.386 |  2.330 | 10.039 |  9.191 |  2.362 |      0.000 | 299543.000 |  1197726.000 |  85551.857 |
```

## MySQLのクエリ解析

スロークエリログの出力設定を追加して、改めてベンチマークを実行してログを出力します。設定が正常に完了していれば、 `/var/log/mysql/mysql-slow.log` が出力されます。

```shell
$ sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
slow_query_log = 1
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 0

$ sudo systemctl restart mysql
$ sudo sytemtctl restart isubata.nodejs.service
```

### pt-query-digestのインストール
[pt-query-digest](https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html) はMySQLのクエリログを集計するサポートツールです。

apt 経由でインストールするとパッケージのバージョンが古くバグが存在するので注意してください。  
[mariadb \- Pipeline process 5 $iteration$ caused an error: Redundant argument in sprintf at /usr/bin/pt\-query\-digest line 2556 \- Stack Overflow](https://stackoverflow.com/questions/38245395/pipeline-process-5-iteration-caused-an-error-redundant-argument-in-sprintf-at)

```shell
$ wget percona.com/get/percona-toolkit.tar.gz
$ tar xf percona-toolkit.tar.gz
$ cd percona-toolkit-3.2.0
$ perl Makefile.PL && make && sudo make install
$ sudo pt-query-digest --help
```

### スロークエリのログを見る

`pt-query-digest` でスロークエリログを見ていきます。

`SELECT * FROM image WHERE name = 'c434098fec37fd0d2c1e646d104220f6ffabbea7.png'\G` の実行が非常に時間が掛かってるっぽいですね。

```shell
$ sudo pt-query-digest --limit 10 /var/log/mysql/mysql-slow.log
# Profile
# Rank Query ID                      Response time  Calls R/Call V/M   Ite
# ==== ============================= ============== ===== ====== ===== ===
#    1 0x086EF2D69E0CA10C16A13978... 989.3391 93.5%   751 1.3174  0.09 SELECT image
#    2 0xB36405B8C0D2F0C74866C96B...  47.8231  4.5%  4012 0.0119  0.02 SELECT message
#    3 0x23E986FD32D530D2691DE3FA...   5.1509  0.5%  5077 0.0010  0.02 SELECT user
#    4 0xDF664753A9FC79D32CF41F09...   3.3720  0.3%  4000 0.0008  0.01 SELECT haveread
#    5 0xE8390778DC20D4CC04FE01C5...   2.6107  0.2% 11863 0.0002  0.01 ADMIN PING
#    6 0xEC97B582BC15F46A85799218...   2.4980  0.2%    89 0.0281  0.04 SELECT message
#    7 0x6CB85ADF7C155CAA91283C30...   2.0849  0.2%    49 0.0425  0.03 SELECT message
#    8 0xE1F097E42A11604ECA5E8124...   0.9187  0.1%    17 0.0540  0.02 INSERT image
#    9 0x34E80BA8226FB17741883793...   0.8466  0.1%   268 0.0032  0.07 SELECT user
#   10 0x98584C6216E0B67546AAE7D3...   0.7411  0.1%    89 0.0083  0.02 INSERT UPDATE haveread
# MISC 0xMISC                          2.2539  0.2%   838 0.0027   0.0 <16 ITEMS>

# Query 1: 11.92 QPS, 15.70x concurrency, ID 0x086EF2D69E0CA10C16A13978F3B7FCFA at byte 13991086
# Scores: V/M = 0.09
# Time range: 2020-08-02T06:11:47 to 2020-08-02T06:12:50
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count          2     751
# Exec time     93    989s   121ms      3s      1s      2s   338ms      1s
# Lock time      6   154ms    23us    35ms   205us   287us     1ms    76us
# Rows sent     25  11.77k       1      25   16.04   22.53    3.89   15.25
# Rows examine   1 745.91k    1001    1018 1017.06 1012.63    8.50 1012.63
# Query size     0  57.81k      46      80   78.83   76.28    2.31   76.28
# String:
# Databases    isubata
# Hosts        localhost
# Users        isucon
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms  #######
#    1s  ################################################################
#  10s+
# Tables
#    SHOW TABLE STATUS FROM `isubata` LIKE 'image'\G
#    SHOW CREATE TABLE `isubata`.`image`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT * FROM image WHERE name = 'c434098fec37fd0d2c1e646d104220f6ffabbea7.png'\G

...
```

ISUCON 夏季講習 2017をやり、ボトルネック発見までの基本的なデータ収集の部分だけをまとめました。

ISUCONの夏季講習2017をやった


CDK for Terraform のチュートリアルを TypeScript で試してみました。  
[CDK for Terraform: Enabling Python & TypeScript Support](https://www.hashicorp.com/blog/cdk-for-terraform-enabling-python-and-typescript-support/)

## Terraformのインストール
[Install Terraform \| Terraform - HashiCorp Learn](https://learn.hashicorp.com/terraform/getting-started/install.html)

```shell
$ brew install terraform
```

## CDK for terraform のインストール

```shell
$ yarn global add cdktf-cli
```

## AWSでVPCを構築するチュートリアル

### プロジェクトの作成
Terraform Cloud でリモートステートを管理するか聞かれるので "no" とする。

```shell
$ mkdir vpc-example
$ cd vpc-example
$ cdktf init --template=typescript
...
Do you want to continue with Terraform Cloud remote state management (yes/no)? no
Project Name: (default: 'vpc-example')
Project Description: (default: 'A simple getting started project for cdktf.')
```

### 実装
TerraformのHCLと比較すると、型のおかげで必須オプションの漏れなどが、リアルタイムで分かるのは良いですね。

```typescript
import { Construct } from 'constructs';
import { App, TerraformStack, Token } from 'cdktf';
import { Vpc } from './.gen/providers/aws/vpc';
import { Subnet } from './.gen/providers/aws/subnet';
import { AwsProvider } from './.gen/providers/aws'

class MyStack extends TerraformStack {
 constructor(scope: Construct, name: string) {
   super(scope, name);

   new AwsProvider(this, 'aws', {
     region: 'ap-northeast-1'
   });

   const vpc = new Vpc(this, 'my-vpc', {
     cidrBlock: '10.0.0.0/16'
   });
    new Subnet(this, 'my-subnet', {
     vpcId: Token.asString(vpc.id),
     cidrBlock: '10.0.0.0/24'
   });
 }
}

const app = new App();
new MyStack(app, 'vpc-example');
app.synth();
```

### TerraformのJSONファイルを生成
TypeScriptのコードからTerraformのJSON形式の設定ファイルをに生成します。ファイルは`cdk.tf`ディレクトリに出力されます。

```shell
$ cdktf synth
Generated Terraform code in the output directory: cdktf.out

$ tree cdktf.out
cdktf.out
└── cdk.tf.json
```

### Terraformを実行
生成された設定ファイルを元に terraform を実行することで、AWSにVPCを構築できます。  
設定がまだの場合は事前に `aws configure` で設定を完了させておく必要があります。

AWSコンソールのVPCを確認すれば、新しくリソースが作成されている事が確認できます。

```shell
$ cd cdktf.out
$ terraform init
$ terraform plan
...
# 追加されるVPCの情報が表示される

$ terraform apply
aws_vpc.vpcexample_myvpc_80A1790F: Creating...
aws_vpc.vpcexample_myvpc_80A1790F: Still creating... [10s elapsed]
aws_vpc.vpcexample_myvpc_80A1790F: Creation complete after 10s [id=vpc-09aeca6257ae5fe31]
aws_subnet.vpcexample_mysubnet_3769B309: Creating...
aws_subnet.vpcexample_mysubnet_3769B309: Creation complete after 3s [id=subnet-0264b990708ed4f69]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
```

### リソースの削除
最後に今回のチュートリアルで作成したVPCを削除しておきます。

```
$ terraform destroy
```

CDK for Terraform でVPCを構築するチュートリアルです

CDK for Terraform でVPCを構築するチュートリアル


Rustで標準出力に色を付けるだけなら、次のように書けば可能です。ただ、コードにこのまま書くのは保守性の面でも避けたいです。

```rust
fn main() {
    let output = "Hello, World";
    println!("\x1b[38;5;1m{}\x1b[m ", output);
}
```

## mackwic/colored
[mackwic/colored](https://github.com/mackwic/colored) はターミナルの標準出力の色付けが簡単にできるクレートです。  
これを利用すれば、簡単に実装ができます。

#### インストール

```toml
[dependencies]
colored = "1.9" # バージョンは随時更新してください
```

#### 使い方

```rust
use colored::*;

fn main() {
    let output = "Hello, World";
    println!("{}", output.red());
    println!("{}", output.blue().bold());
}
```


Rustで標準出力に色を付ける


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

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

div タグでの実装例

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

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

form タグでの実装例

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

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

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

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

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

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

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

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


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

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