
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タグを使うか


[alievk/avatarify: Avatars for Zoom and Skype](https://github.com/alievk/avatarify)

この記事は MacOS でのセットアップ方法を記述しています。  
環境でセットアップ手順が異なるので、LinuxやWindowsの場合はリポジトリのREADME.mdを参照してください。

【環境】  
OS: MacOS Catalina 10.15.3  
端末: MacBook Pro 2017  
プロセッサ: 2.3 GHz デュアルコアIntel Core i5  
メモリ: 16 GB 2133 MHz LPDDR3  
グラッフィックス: Intel Iris Plus Graphics 640 1536 MB  
GPU: なし

## インストール

### miniconda3 をインストール  
[Installing on macOS — conda 4\.8\.3\.post14\+07a113d8 documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/install/macos.html#installing-on-macos)

[Miniconda — Conda documentation](https://docs.conda.io/en/latest/miniconda.html#macosx-installers) よりインストーラーをダウンロードする。  

```bash
# 対話シェルが起動するので、内容に沿ってインストールを進める。
$ zsh Miniconda3-latest-MacOSX-x86_64.sh
$ export PATH="$HOME/miniconda3/bin:$PATH"
```

### avatarify のリポジトリをクローンしてインストール

```bash
$ git clone https://github.com/alievk/avatarify.git
$ cd avatarify
$ zsh scripts/install_mac.sh
$ conda activate avatarify
```

### 学習済みモデル vox\-adv\-cpk\.pth\.tar をダウンロード  
[Google ドライブ](https://drive.google.com/file/d/1L8P-hpBhZi8Q_1vP2KlQ4N6dvlzpYBvZ/view)からダウンロードして avatarify ディレクトリ配置する。  
※ tarファイルは解凍せずにそのまま配置する

### CamTwist をダウンロード  
[ここ](http://camtwiststudio.com/download/)からダウンロードする

## 実行

### avatify を起動  
"Cannot open camera" のエラーが発生したら、scripts/settings.sh の CAMID を 0 から 1, 2, ... に変更する。  
自分の場合は 1 に変更したら、正常に起動しました。

```bash
$ zsh run_mac.sh
```

### CamTwistを起動

2.1 「Desktop+」 を選んで Select をクリック  
2.2 Settingsの項目内で 「Confine to Application Window」を選択してセレクトボックスで「Python(avatarify)」を選ぶ  

アバターが表示されたウィンドウで 1, 2, ... と数字キーを押せばアバターの切替えができます。

### Zoomdでバーチャルカメラを利用できるようにする  
Mac の Zoom v4.6.8 以降のバージョンでは仮想カメラが使えないようになっているので、ライブラリ署名を削除して仮想カメラを利用できるようにする。

```bash
$ codesign --remove-signature /Applications/zoom.us.app
```

### Zoomを起動
4.1 Zoom で 設定 > カメラ > CamTwist を選択

![zoom](/images/posts/avatarify/zoom.gif)

GPUが無いと ~1FPS しかパフォーマンスが出ないので、動いてはいるのですが全く楽しめないです。😢  


Zoomでアインシュタインになってみた

Rust は所有権の機能を導入することでガベージコレクションを実装せずにメモリ安全を実現しています。これを理解しないとコンパイルエラーが発生した時になぜエラーなのかを把握するのか困難になるので、Rust を使う上で重要な概念です。

ドキュメントなどを読み概要が把握できたので、整理のために説明を書いていきます。

## 所有権の特徴

現在のプログラムにおける一般的なメモリの管理方法は大きく分けて二つあります。  
一つは C や C++のようにプログラマが自分でメモリの確保と開放を宣言するやり方、二つ目は Java や Go のようにベージコレクションによって定期的に不要なメモリを開放する方法です。  
一つ目の方法ではプログラマが常にメモリを意識して開発する必要があり非常にコストがかかり、メモリ管理を誤った場合にダングリングポインタやメモリ 2 重開放などでエラーが発生する危険性があります。また、二つ目の方法では定期的に実行されれるガベージコレクターがアプリケーションの動作の妨げになる事があります。

Rust では所有権システムに基づいてコンパイラがコンパイル時にメモリ安全性のチェックを行うことで、ガベージコレクションを組み込む事なく自動でメモリ安全性を保証しています。

### 所有権規則

所有権システムは次の規則を持っています。

-   規則 1: 値は所有者と呼ばれる変数と対応している
-   規則 2: 値を所有できる変数は必ず一つだけである
-   規則 3: 値を所有する変数がスコープを抜けたら、値は破棄される

### メモリと変数スコープ

```rust
fn main() {
    let s1 = String::from("hello");  // ここで
    println!("{}", s1);
} // ここでs1がスコープから抜けるので "hello" の値も破棄される
```

ここで登場している String 型 は可変の値なので、コンパイル時にサイズを決定する事ができないので、値はヒープ領域に配置されます。  
このとき「値を所有する変数がスコープを抜けたら、値は破棄される」の規則に則り、s1 がスコープから抜ける時に、"hello" のメモリ解放がされます。

![memory1](/images/posts/rust-ownership/memory1.png)

### 所有権のムーブ

次に、変数を別の変数に代入した場合のメモリの状態を考えてみます。

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
}
```

この状態で先ほどと同じようにメモリの解放を考えてみます。最初に s2 がスコープから抜けるタイミングで、"hello" のメモリが解放されます。次に s1 がスコープから外れるので同じようにメモリを解放します。  
ちょっと待ってください、ここで問題が発生しました！  
"hello" のメモリは既に解放されているため、s1 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。



しかし、対象のコードはコンパイルに成功して正常に実行されます。  
なぜでしょうか？

ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は `let s2 = s1;` の部分で "hello" の所有権が s1 から s2 へ移動しており、s1 は値を所有しておらず変数として無効となっているのです。そのため、Rust は s1 がスコープから抜けるタイミングでメモリ解放をする必要がなくなり、結果として s2 に対してのみメモリ解放が実行されるため、正常に動作します。

この、値を所有する変数が移動することを **所有権のムーブ** といいます。

![move_ownership](/images/posts/rust-ownership/move_ownership.png)

この仕組みを考えると、例えば、次のコードはどうなるのでしょうか？

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
             -- value moved here
    println!("{}", s1);
                   ^^ value borrowed here after move
}
```

このコードはコンパイルエラーになります。"hello" の所有権が s1 から s2 にムーブしており、既に無効となっている s1 を使おうとしているためコンパイルエラーになるのです。

また所有権のムーブは関数に値を渡す場合も同様に発生します。

```rust
fn hello(s: String) {
    println!("hello! {}", s);
}

fn main() {
    let name = String::from("taro");
    hello(name);
          ---- value moved here
    println!("{}", name);
                   ^^^^ value borrowed here after move
}
```

### 借用

それでは、先ほどの例で関数に値を渡したい時はどうすればいいのでしょうか？  
この問題は **借用** を使う事で解決できます。借用は `&` を使って表現します。

```rust
fn hello(s: &String) {
    println!("hello! {}", s);
}

fn main() {
    let name = String::from("taro");
    hello(&name);
    println!("{}", name);
}
```

借用は name への参照を作成し、これを所有しません。つまり、s は所有権を持たないのでスコープを抜けてもメモリ解放は実行されず、name がスコープを抜けたタイミングでメモリ解放が実行されます。
これは、コンパイラに対して「s は値を借りているだけなので、スコープを抜けてもメモリの解放をする必要がないよ」と教えているのです。

メモリ状態を表現すると次のようになります。

![memory3](/images/posts/rust-ownership/memory3.png)

この借用を用いることで、所有権をムーブさせずに値を参照することができます。

## 参考

-   [What is Ownership? \- The Rust Programming Language](https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html)
-   [所有権とは？ \- The Rust Programming Language](https://doc.rust-jp.rs/book/second-edition/ch04-01-what-is-ownership.html) （公式の日本語翻訳）

## まとめ

Rust の所有権と借用の仕組みは理解するのに、かなり時間がかかりました。理解すると意外とシンプルな考えなんだなと感じました。  
この記事は参考ドキュメントで理解した事を自分用に噛み砕いて書いただけなので、詳しい説明はドキュメントを読んだ方が良いです。

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


フロントエンド実装においてセキュリティを考慮する際に意識した方が良いHTTPレスポンスヘッダーについてまとめています。

## X-Powered-By

### ヘッダーの説明
サーバー側で利用しているフレームワークやバージョン情報を含むHTTPヘッダー

```
例: 
X-Powered-By: Next.js
```

### 脆弱性
サーバー側で利用されているフレームワークやバージョンが含まれているため、他に脆弱性が存在した場合に攻撃者に攻撃を助ける情報を与える可能性がある。

### 対策方法
サーバー側で X-Powered-By ヘッダーを出力しないように設定する。

## X-Runtime

### ヘッダーの説明
サーバーの応答時間を含むHTTPヘッダー

```
例: 
X-Runtime: 0.094235
```

### 脆弱性
タイミング攻撃（Timing Atacking）に利用される可能性がある。

### タイミング攻撃
サーバーの応答時間の違いを利用する事でサービスを分析する攻撃手法です。  
例えば、次のようにログイン処理が実装されていたとします。  

```typescript
const login = (user_name, password) => {
    const user = User.get(user_name);
    if (user == null) return res.send(400);

    // 登録済みのユーザー名の場合はパスワードチェク処理が実行される分だけ応答時間が長くなる
    const mached = user.matchPassword(password);
    if (matched) res.send(200);
    else res.send(400);
}
```

この時、ユーザー名がサービスに登録済みの場合はパスワードチェック処理が追加で実行される影響で応答時間が少し長くなるため、攻撃者はランダムなユーザー名でリクエストを送信して X-Runtime の応答時間の違いを比較することで、サービスに登録済みのユーザー名を特定する事ができます。

```
# 未登録のユーザー名の場合
X-Runtime: 0.3949

# 登録済みのユーザー名の場合
X-Runtime: 0.6421
```

参考: [X\-Runtime Header Timing Attacks \- Virtue Security](https://www.virtuesecurity.com/kb/x-runtime-header-timing-attacks/)

### 対策方法
X-Runtime ヘッダーを出力しないように設定する。

## Cache-Control

### ヘッダーの説明
キャッシュの生存期間や保存可否などを制御するHTTPヘッダー  
HTTPレスポンスヘッダーとして指定された場合は、サーバーからのレスポンスを Cache-Control の指定に基づいて制御する。

```
例 画像などを1日キャッシュする
Chach-Control: max-age=86400
```

### 脆弱性
ブラウザは何の指定も無い場合はデフォルトでサーバーレスポンスを可能な場合にキャッシュします。  
この時サーバーレスポンスにユーザーのパスワード情報などが含まれていた場合に、何らの方法で攻撃者がユーザーの物理マシンにアクセス可能な状態であれば、マシンに保存されているブラウザキャッシュなどからパスワード情報を盗み出される可能性がある。

### 対策方法
Cache-Control を指定して、扱う情報に応じた適切なキャッシュ制御を行う。  
例えば、ユーザーの端末に保存するべきでない情報を含む場合は `nostore` を指定してキャッシュを保存しないようにする。

```
Cache-Control: nostore
```

## X-Frame-Options

### ヘッダーの説明
[X\-Frame\-Options \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options)

ブラウザが自分のWebページを \<iframe\> や \<object\> の中へ表示することを禁止することで、Webページが他のサイトに埋め込まれないことを保証することができます。

### 脆弱性の説明
適切に設定していない場合にクリックジャッキング攻撃に利用される可能性がある。

### クリックジャッキング攻撃
外部ページを埋め込んだiframeを透明化して通常のWebページの上に被せることで、攻撃者がユーザーに意図しない操作をさせる攻撃手法です。

例えば、次の要件を満たすようなサービスをユーザーが利用しているとします。

```
1. ログイン情報をCookieで管理している
2. same-site属性はnone
3. アカウント画面の削除ボタンを押すだけで確認なしでアカウントが削除できる
```

このとき対象サービスのアカウントページをiframeに埋め込み透明化した状態でWebページの上に重ねた場合、ユーザーがログイン済みであればユーザーのアカウントページが透明な状態で上に重なって表示されます。  
対象サービスの削除ボタンに重なる位置にクリックしたくなるようなリンクを配置することで、ユーザーに削除ボタンをクリックさせて、アカウントを削除するように誘導する事ができます。

### 対策方法
`X-Frame-Options: Deny` を指定する事で iframe 等へのページの埋め込みを禁止する。

## Content-Security-Policy（CSP）

### ヘッダーの説明
[コンテンツセキュリティポリシー $CSP$ \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/CSP)

インラインスクリプトの実行を禁止してXSSなどの攻撃を軽減する事ができます。

例えば、次のようにHTTPレスポンスヘッダーに含める事で、掲示板のサービスなどでサニタイズ処理をせず任意の文字列をサービスに埋め込める脆弱性があった場合でも、インラインスクリプトの実行ができないためXSS攻撃を軽減する事ができます。

```
# 外部ドメインのファイル読み込みやインラインスクリプトの実行を禁止する
Content-Security-Policy: default-src 'self'
```

IEは CSPの sandbox ディレクティブのみが利用可能になっており、IE9以下は CSP 未対応なので、次に紹介する X-XSS-Protection を利用する必要があります。

詳しい設定は上記のMDNのリンクを参照してください。

### 脆弱性の説明
掲示板などでユーザーが入力した値をサニタイズせずに画面上に表示していた場合にXSS攻撃を仕込まれる可能性がある。

### 注意点
外部ドメインからのスクリプト読み込みを禁止した場合に、CDN経由でのライブラリ読み込みなどが出来なくなってしまいます。  
そのため、自身のサービスの特性に合わせて適切に設定する必要があります。

例えば、次の設定をする事で自身のドメインと特定ドメインの CDN からのみスクリプト読み込みを許可する事ができます。  

```
Content-Security-Policy: default-src 'self' cdnjs.cloudflare.com
```

### 対策方法
Content-Security-Policyを適切に設定する。

※ CSPの設定とは別でユーザーが入力した値を表示する箇所で適切にサニタイズ処理はするべきです。

## X-XSS-Protection

### ヘッダーの説明
ブラウザがXSS攻撃を検出した時にページの読み込みを自動で停止します。

CSPが厳しく設定済みであれば、このヘッダーは本来不要です。  
しかし、ユーザーがCSPに未対応の古いブラウザ（IE9以下）を利用している場合に有効な対策になります。

## Strict-Transport-Security

### ヘッダーの説明

[Strict\-Transport\-Security \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security)

HTTPS でページにアクセスした時にHTTPレスポンスヘッダーに含めることで、次回以降はブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示する事ができます。  

初めてのユーザーが HTTP でページにアクセスした場合は Strict-Transport-Security 無視されるため、ユーザーが HTTPS アクセスを一度もしていない場合には有効でない事に注意してください。  
HTTPS アクセスをしてSSL証明書が確認されたタイミングで設定が有効になります。

```
# HTTPSアクセスの設定を1年間有効にする（有効期限はアクセスの度に更新される）
Strict-Transport-Security: max-age=31536000;
```

### 脆弱性の説明
HTTPアクセスが許可されている銀行サイトを普段から利用していたとします。  
カフェで無料のWifiに接続した状態で、その銀行サイトをHTTP経由で利用をしてしまった場合に、攻撃者にHTTPリクエストの内容を傍受され銀行口座やログイン情報などが盗まれる可能性があります。

### 対策方法
Strict-Transport-Security ヘッダーを指定する。

上の例では、もし銀行サイトが Security-Transport-Security を設定しており、一度でも HTTPS で銀行サイトにアクセスしていた場合には、誤ってHTTPアクスした場合でも HTTPS 経由で自動で接続されるため被害を防ぐことができます。


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


## インストール
[denoland/deno: A secure JavaScript and TypeScript runtime](https://github.com/denoland/deno)

```shell
$ curl -fsSL https://deno.land/x/install/install.sh | sh
$ vi ~/.zshrc
# Denoのパス設定
export DENO_INSTALL="/Users/t-yng/.local"
export PATH="$DENO_INSTALL/bin:$PATH"

$ source ~/.zshrc
```

インストール直後はパスが通っていない状態なので ~/.zshrc にDenoのパス設定を追加して再読み込みします。  
※ 個人の環境に合わせて適宜読み替えてください

HomeblewやCargoを利用してもインストールできます。  
詳細は [https://deno.land/](https://deno.land/) を確認してください。

## VsCodeの拡張

今の状態でVSCodeでコードを書くとTypeScriptとして認識されるので、Denoの構文でエラーが発生します。  
そこで [Deno - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno) をインストールしておきます。

デフォルトでは設定が false になっているので .vscode/setting.json で拡張を有効化します。  
自分は Node.js 環境で TypeScript を書く場合に競合する事を避けるために、プロジェクト単位で有効化しています。

```json
{
  "deno.enable": true
}
```

## Hello World を表示する
最初に「Hello World」を表示するサンプルコードを実装してみます。

```shell
$ mkdir deno-sample
$ cd deno-sample
$ touch server.ts
```

### server.ts
deno-sample/server.ts に次のサンプルコードを記述します。

```typescript
import { serve } from "https://deno.land/std@v0.39.0/http/server.ts";

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000/");

for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}
```

最初のimport文はモジュール読み込みです。  
Denoは npm を利用せずにURLやファイルパスでモジュールを読み込む仕組みになっており、サンプルコードでは deno.land にホスティングされた標準APIのモジュールを読み込んでいます。

次に `serve({port: 8000})` でサーバーインスタンスを生成しています。

ここで生成されるサーバーインスタンスはPromiseのイテレーターとなっているので、 `for await` でループ処理にてリクエストのインスタンスを取得して、 Hello World の文字列をレスポンスとして返しています。

### 実行
エラーが発生しました。

```shell
$ deno server.ts

Compile file:///Users/xxxxxx/workspace/deno/deno-sample/server.ts
error: Uncaught PermissionDenied: network access to "127.0.0.1:8000", run again with the --allow-net flag
```

Denoではネットワークアクセスやファイルアクセスには許可が必要なため、今回はネットワークアクセスを許可するために `--allow-net` フラグを指定します。

```
$ deno --allow-net server.ts
access to http://localhost:8000/
```

今度は成功しました。
この状態で http://localhost:8000/ にアクセスすれば、「Hello World」がブラウザに表示されます。🎉

## HTMLを返す
次にHTMLを返すWebサーバーを実装してみます。

### ディレクトリ構造
public/index.html は適当に作成してください。

```
.
├── public
│   └── index.html
└── server.ts
```

### server.ts

fs モジュールの `readFileStr` でHTMLファイルの文字列を読み込みをしています。

正しく実装するなら、[File Server](https://deno.land/std/manual.md#file-server)として実装した方が良さそうですが、ファイル読み込みをを試してみたかったので、この書き方をしています。

```typescript
import { serve } from "https://deno.land/std/http/server.ts";
import { readFileStr } from "https://deno.land/std/fs/mod.ts";

// HTMLファイルを読み込んで文字列を取得
const html = await readFileStr("./public/index.html", {
    encoding: "utf8",
}).catch((error) => {
    console.log(error);
    return "読み込みに失敗したよ";
});

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000");
for await (const req of s) {
    req.respond({ body: html }); // HTML文字列をレスポンスBodyにセット
}
```

### 実行
ファイル読み込みをしているので `--allow-read` フラグを新たに指定しています。

```shell
$ deno --allow-net --allow-read server.ts
access to http://localhost:8000/
```

## パッケージ管理

### 問題
現状では npm のようなパッケージ管理ツールがなく、ソース単位で外部モジュールの読み込みを書いている状態です。  
依存している外部ライブラリを把握するためには、ソースコードを全て見る必要があり管理が困難になってしまいます。

### deps.ts
deps.ts ファイルを新しく作り、モジュール読み込みの記述をまとめることで簡易的なパッケージ管理が実現できます。  
deps.ts はマニュアルで紹介されいているファイル名で名前は何でもOKです。  
ライブラリを見ていると、deps.ts か package.ts をファイル名として利用しているパターンが多かったです。

先ほどのHTMLを返すサンプルコードの一部を deps.ts を利用して書き直してみるとこんな感じです。

deps.ts
```typescript
export { serve } from "https://deno.land/std/http/server.ts";
export { readFileStr } from "https://deno.land/std/fs/mod.ts";
```

server.ts
```typescript
import { serve, readFileStr } from "./deps.ts";

// 後は同じ
...
```

## ドキュメント

* [Dono 公式ドキュメント](https://deno.land/)
* [API Reference](https://deno.land/typedoc/)


Denoを触ってみよう

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