Kaggle CLIをアップデートする

以下のような警告が表示された場合、Kaggle CLIを最新バージョンにアップデートしましょう。

Warning: Looks like you're using an outdated API Version, please consider updating (server 1.5.15 / client 1.5.13)

Kaggle CLIをアップデートする

警告にも表示されていますが、念のため現在のバージョンを確認します。

$ kaggle --version
Kaggle API 1.5.13

次に最新バージョンを確認します。pip list --outdatedで更新が必要なパッケージをリストして最新バージョンを確認することができます。

$ pip list --outdated
Package                       Version     Latest       Type
----------------------------- ----------- ------------ -----
・・・
kaggle                        1.5.13      1.5.16       sdist
・・・

警告を見るとサーバーが1.5.15となっていたので、クライアントも1.5.15が最新版かと思いましたが、どうやら最新版は1.5.16のようです。

新しくなる分には問題ありませんので、最新版にアップデートします。

$ pip install --upgrade kaggle
Requirement already satisfied: kaggle in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (1.5.13)
Collecting kaggle
  Downloading kaggle-1.5.16.tar.gz (83 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 83.6/83.6 kB 4.5 MB/s eta 0:00:00
  Preparing metadata (setup.py) ... done
Requirement already satisfied: six>=1.10 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (1.16.0)
Requirement already satisfied: certifi in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2023.7.22)
Requirement already satisfied: python-dateutil in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2.8.2)
Requirement already satisfied: requests in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (2.29.0)
Requirement already satisfied: tqdm in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (4.65.0)
Requirement already satisfied: python-slugify in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (8.0.1)
Requirement already satisfied: urllib3 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (1.26.15)
Requirement already satisfied: bleach in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from kaggle) (6.0.0)
Requirement already satisfied: webencodings in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from bleach->kaggle) (0.5.1)
Requirement already satisfied: text-unidecode>=1.3 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from python-slugify->kaggle) (1.3)
Requirement already satisfied: charset-normalizer<4,>=2 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from requests->kaggle) (3.1.0)
Requirement already satisfied: idna<4,>=2.5 in /Users/t0k0sh1/miniforge3/envs/datascience/lib/python3.10/site-packages (from requests->kaggle) (3.4)
Building wheels for collected packages: kaggle
  Building wheel for kaggle (setup.py) ... done
  Created wheel for kaggle: filename=kaggle-1.5.16-py3-none-any.whl size=110685 sha256=9d938a633a89c1157e7dcf713de3ce949e873e92ac478bc1b88a6e2b8fe8b6d0
  Stored in directory: /Users/t0k0sh1/Library/Caches/pip/wheels/43/4b/fb/736478af5e8004810081a06259f9aa2f7c3329fc5d03c2c412
Successfully built kaggle
Installing collected packages: kaggle
  Attempting uninstall: kaggle
    Found existing installation: kaggle 1.5.13
    Uninstalling kaggle-1.5.13:
      Successfully uninstalled kaggle-1.5.13
Successfully installed kaggle-1.5.16

アップデートは成功していますが、念のためバージョンを確認しておきます。

$ kaggle --version
Kaggle API 1.5.16

もう一つ、アップデートが必要なパッケージにリストされていないことも確認します。

$ pip list --outdated | grep kaggle

まとめ

Pythonのパッケージは定期的に更新しないため、バージョンが古くなりがちです。安定しているバージョンを使っているという意味では頻繁に更新する必要はありませんが、Kaggle CLIのようにサーバーとやりとりを行うCLIパッケージについては、気づいたときに最新版にアップデートすることが重要です。

mambaを使ってパッケージのインストールを高速化しよう(conda installの高速化)

conda installを何気なくやるとかなり待たされることがあります。この待ち時間を減らすためにはmambaを使用することが解決策の一つとなります。

インストールが全然始まらない

pandasparquetを扱いたくてconda installpyarrowをインストールしようとしましたが、インストールが全然始まりませんでした。

 $ conda install pyarrow
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): | WARNING conda.models.version:get_matcher(546): Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 1.8.0.*, but conda is ignoring the .* and treating it as 1.8.0
WARNING conda.models.version:get_matcher(546): Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 1.9.0.
*, but conda is ignoring the .* and treating it as 1.9.0                                                                                                                           done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: |

conda installに時間がかかる原因としては以下が考えられます。

  1. 依存関係の解決: condaはパッケージの依存関係を非常に厳格に解決します。そのため、多くのパッケージや複雑な環境でのインストールでは、この解決プロセスが時間を要することがあります。
  2. サーバーの応答速度: 利用しているcondaのリポジトリサーバーの応答速度やネットワークの状態によっては、パッケージのダウンロードに時間がかかることがあります。
  3. インストールするパッケージのサイズ: 大きなパッケージや多数のパッケージをインストールする場合、当然ダウンロードやインストールに時間がかかります。

この問題を解決するためには以下のような対策が考えられます。

  • 特定のチャンネルを指定
  • mambaの利用
  • 環境を最小限に保つ
  • パッケージキャッシュのクリア

今回はこの中から、お手軽で高い効果のある「mambaの利用」を適用していきます。

mambaのインストール

まずはmambaをインストールします。

conda install -c conda-forge mamba

conda installにかかる時間を減らす一つのテクニックとしてチャネルを指定する方法があります。ただ、mambaをチャネル指定なしでインストールしてもそれほど時間がかからなかったので、チャネル指定がなくても大丈夫だと思います。

他にチャネルの指定する方法はあるので、conda-forgeへのリンクを貼っておきます。

condaのキャッシュをクリアする

念のためcondaのキャッシュをクリアしておきます。

$ conda clean -a
Will remove 411 (631.3 MB) tarball(s).
Proceed ([y]/n)? y

Will remove 1 index cache(s).
Proceed ([y]/n)? y

Will remove 83 (826.7 MB) package(s).
Proceed ([y]/n)? y

There are no tempfile(s) to remove.
There are no logfile(s) to remove.

何度か質問されるのでいずれの質問にもyを回答します。

mambaを使ってインストールする

では先ほど全然インストールが始まらなかったpyarrowmambaでインストールしていきます。

$ mamba install pyarrow 

Looking for: ['pyarrow']

conda-forge/osx-arm64                                6.7MB @  13.6MB/s  0.5s
conda-forge/noarch                                  12.4MB @  23.9MB/s  0.5s

・・・

Confirm changes: [Y/n] y

・・・

Downloading and Extracting Packages

Preparing transaction: done
Verifying transaction: done
Executing transaction: done

処理時間が格段に短くなるものそうですが、待ち時間が短縮されるので体感的にも早く感じられ、ストレスが軽減されるのがよいですね。

まとめ

データ分析や機械学習の作業でcondaを使ってインストール作業を行う場合はmambaコマンドを使った方が素早く作業を進められます。

外部プログラムをインストールする訳ではなく、conda installmambaをインストールできるので、ノックアウトファクターがほぼないので是非試してみてください。

テストやドキュメントで安全に使用できるドメイン名を知っておこう

テスト用に設定したメールアドレスに誤ってメールを送信してしまった、という経験はありませんか?

テストやドキュメントに使用できるドメインが予約されており、これらを活用することでメール誤送信などを防ぐことができます。

テストやドキュメントに使用できるドメインは予約されている

RFC 6761で、特別な使用のためのドメイン名として、特定のTLD(Top-Level Domain)やSLD(Second-Level Domain)が予約されています。

TLD(Top-Level Domain)

TLDとして、以下のドメインが予約されています。

  • .test: テスト用として予約されています
  • .example: ドキュメンテーションや例示に使用するために予約されています
  • .invalid: 明示的に無効なドメイン名として識別するために使用します
  • .localhost: 伝統的な意味でのlocalhostの名前解決のために予約されています

SLD(Second-Level Domain)

RFC 6761では、以下のドメインがドキュメントや例示のために予約されています。

  • example.com
  • example.net
  • example.org

ユースケース

ユースケース別にどのドメイン使用すればいいかについて見ていきましょう。

送受信の確認を行うメールアドレス

RFC 6761で予約されているドメインはメールの送受信には使用できないため、実際に送受信可能なメールアドレスを使用してください。

その際は、誤送信が起きないように十分ご確認ください。

ダミーのメールアドレス

システムのドメインがt0k0sh1.comの場合、t0k0sh1.testを使用すると良いでしょう。

書籍やドキュメント中に例示するURLやメールアドレス

URLやメールアドレスを書籍やドキュメント中に記載する場合、

  • https://www.example.com
  • test@example.com

のようにexample.comexample.netなどを使用すると良いでしょう。

example.jpなどは使用できないのか

RFC 6761にはexample.jpなどのccTLD(country code Top-Level Domain)については言及されていません。

各国で対応が異なると思いますが、日本の場合はJPRSがよくある質問で答えています。

例示に使用可能なドメイン名はありませんか?

次の文字列のJPドメイン名は、例示としてご利用いただけます。

“EXAMPLE”を用いたもの
例: EXAMPLE.JP
   EXAMPLE.CO.JP
   EXAMPLE.NE.JP

“EXAMPLE”の後に1桁の数字(””0″”から””9″”)がつく文字列を用いたもの
例: EXAMPLE1.JP
   EXAMPLE2.CO.JP
   EXAMPLE3.NE.JP

次の日本語ドメイン名

ドメイン名例.JP (日本語JPドメイン名)
XN–ECKWD4C7CU47R2WF.JP (「ドメイン名例.JP」のpunycode表記)

JPドメイン名の活用について | よくある質問 | JPRS https://jprs.jp/faq/use/#q2

example.jpexample.co.jpなどを書籍やドキュメントにおける例示に使用することは可能です。

まとめ

テスト用ドメインとしては、所有しているドメイン名を基に.testを使用することが推奨されます。一方、書籍やドキュメントで例示する場合はexample.comなどを使用すると良いでしょう。

本来の目的とは若干外れますが、テスト用のURLやメールアドレスとして、example.comなども安全に使用することもできます。

Dockerコマンドチートシート20選+α(実行例付き)

dockerコマンドの中でもよく使うコマンドを実行例付きで20個集めました。

Dockerの状態を確認する

Dockerのバージョン情報を表示

docker --version
$ docker --version
Docker version 24.0.5, build ced0996

より詳細なバージョン情報が知りたい場合は、docker versionコマンドを使用します。

docker version

こちらはクライアントおよび現在接続しているサーバーのより詳細なバージョン情報を得られます。

$ docker version
Client:
 Cloud integration: v1.0.35-desktop+001
 Version:           24.0.5
 API version:       1.43
 Go version:        go1.20.6
 Git commit:        ced0996
 Built:             Fri Jul 21 20:32:30 2023
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.22.1 (118664)
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.6
  Git commit:       a61e2b4
  Built:            Fri Jul 21 20:35:38 2023
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Dockerの実行状態を確認

docker info
$ docker info
Client:
 Version:    24.0.5
 Context:    desktop-linux
 Debug Mode: false
・・・
WARNING: daemon is not using the default seccomp profile

イメージの操作

イメージの一覧表示

実行結果に表示されるREPOSITORYがイメージ名、TAGがタグ名です。

docker images
$ docker images
REPOSITORY                                                TAG                                                                          IMAGE ID       CREATED         SIZE
ubuntu                                                    22.04                                                                        a2f229f811bf   3 weeks ago     69.2MB
ubuntu                                                    20.04                                                                        15c9d636cadd   4 weeks ago     65.7MB

イメージの検索

キーワードをイメージ名や説明に含むイメージを検索します。

docker search <キーワード>
$ docker search nginx
NAME                                              DESCRIPTION                                      STARS     OFFICIAL   AUTOMATED
nginx                                             Official build of Nginx.                         18963     [OK]
unit                                              Official build of NGINX Unit: Universal Web …   10        [OK]
nginxinc/nginx-unprivileged                       Unprivileged NGINX Dockerfiles                   114

イメージの検索はできますが、タグを検索することはできないため、Docker Hubで探してください。

イメージの取得

イメージ名またはイメージ名とタグ名を指定してイメージを取得します。

docker pull <イメージ名>[:タグ]

タグを省略するとデフォルトタグ(多くの場合はlatestタグ)が取得されます。

$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
db76c1f8aa17: Pull complete
Digest: sha256:ec050c32e4a6085b423d36ecd025c0d3ff00c38ab93a3d71a460ff1c44fa6d77
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview ubuntu

latestは取得タイミングによってバージョンが異なるため、基本的にはタグ(バージョン)を指定するのが推奨です。

$ docker pull ubuntu:20.04
20.04: Pulling from library/ubuntu
82d728d38b98: Pull complete
Digest: sha256:33a5cc25d22c45900796a1aca487ad7a7cb09f09ea00b779e3b2026b4fc2faba
Status: Downloaded newer image for ubuntu:20.04
docker.io/library/ubuntu:20.04

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview ubuntu:20.04

過去に取得したlatestタグのイメージを最新化する場合は再度docker pullしてください。

$ docker pull phpmyadmin/phpmyadmin
Using default tag: latest
latest: Pulling from phpmyadmin/phpmyadmin
faef57eae888: Pull complete
989a1d6c052e: Pull complete
0705c9c2f22d: Pull complete
621478e043ce: Pull complete
98246dcca987: Pull complete
bfed8c155cb6: Pull complete
7a7c2e908867: Pull complete
d176994b625c: Pull complete
2d8ace6a2716: Pull complete
c70df516383c: Pull complete
15e1b44fe4c7: Pull complete
65e50d44e95a: Pull complete
77f68910bc0a: Pull complete
605dd3a6e332: Pull complete
99ce27188f07: Pull complete
74d64e32c5d5: Pull complete
ef5fc9928b9f: Pull complete
163f3256e112: Pull complete
Digest: sha256:67ba2550fd004399ab0b95b64021a88ea544011e566a9a1995180a3decb6410d
Status: Downloaded newer image for phpmyadmin/phpmyadmin:latest
docker.io/phpmyadmin/phpmyadmin:latest

What's Next?
  View summary of image vulnerabilities and recommendations → docker scout quickview phpmyadmin/phpmyadmin

イメージの削除

docker rmi <イメージ名 or イメージ名:タグ or イメージID>

タグなしは:latestを指定しているのと同じです。

$ docker rmi hello-world
Untagged: hello-world:latest
Untagged: hello-world@sha256:dcba6daec718f547568c562956fa47e1b03673dd010fe6ee58ca806767031d1c
Deleted: sha256:b038788ddb222cb7d6025b411759e4f5abe9910486c8f98534ead97befd77dd7
Deleted: sha256:a7866053acacfefb68912a8916b67d6847c12b51949c6b8a5580c6609c08ae45

コンテナの操作

実行中のコンテナを一覧表示

実行中のコンテナのリストを表示します。

docker ps

一覧に表示されるCONTAINER IDがコンテナIDで、NAMESがコンテナ名です。

$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS                  NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   4 seconds ago   Up 3 seconds   0.0.0.0:8080->80/tcp   nginx01

すべてのコンテナを一覧表示

停止しているコンテナも表示したい場合は-aオプションを使います。

docker ps -a

ステータス(STATUS)で現在の状況を確認できます。Exitedになっている場合はすでに停止しているコンテナです。

CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS                      PORTS                  NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   6 minutes ago    Up 6 minutes                0.0.0.0:8080->80/tcp   nginx01
21dc45864d5f   busybox   "sh"                      29 minutes ago   Exited (0) 29 minutes ago                          bold_volhard

コンテナの起動

docker run <イメージ名>[:<タグ名>]
docker run <イメージID>

$ docker run nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/09/03 03:46:40 [notice] 1#1: using the "epoll" event method
2023/09/03 03:46:40 [notice] 1#1: nginx/1.25.2
2023/09/03 03:46:40 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)
2023/09/03 03:46:40 [notice] 1#1: OS: Linux 5.15.49-linuxkit-pr
2023/09/03 03:46:40 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/09/03 03:46:40 [notice] 1#1: start worker processes
2023/09/03 03:46:40 [notice] 1#1: start worker process 29
2023/09/03 03:46:40 [notice] 1#1: start worker process 30
2023/09/03 03:46:40 [notice] 1#1: start worker process 31
2023/09/03 03:46:40 [notice] 1#1: start worker process 32
2023/09/03 03:46:40 [notice] 1#1: start worker process 33

後述の-dオプションをつけないと制御が返ってこない点に注意が必要です。Ctrl+Cでコンテナを停止されることができます。

コンテナ名を指定して起動する

コンテナ名を指定しないと適当な名前で起動します。コンテナ名を指定したい場合は--nameオプションを使用します。

docker run --name <コンテナ名> <イメージ名>[:<タグ名>]
docker run --name <コンテナ名> <イメージID>
$ docker run -d --name web nginx
$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   3 seconds ago   Up 3 seconds   80/tcp    web

NAMESが指定したコンテナ名になっていることが確認できます。

すでに存在するコンテナ名を指定するとエラーになりますので、使用していないコンテナ名かどうかを確認するようにしましょう。

$ docker run -d --name web nginx
docker: Error response from daemon: Conflict. The container name "/web" is already in use by container "ce2fa12b11da0fcf214221c5cb4687ed48f5ac73e6e71586d2ddcee98202df7e". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.

コンテナ名は実行中でも変更可能です。

# 起動中のコンテナのコンテナ名がwebになっていることを確認
$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes   80/tcp    web

# コンテナIDと新しいコンテナ名を指定してリネームする
$ docker rename ce2fa12b11da web01

# コンテナ名がweb01に変更されていることを確認する
$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes   80/tcp    web01

ポートをマッピングしてコンテナを起動

docker run -p <ホスト側ポート番号>:<コンテナ側ポート番号> <イメージ名>[:<タグ名>]
docker run -p <ホスト側ポート番号>:<コンテナ側ポート番号> <イメージID>

nginxイメージで80ポートで公開されているポートを8080ポートでアクセスするには以下のようにします。

# -pオプションなしで80ポートが公開されていることを確認する
$ docker run -d nginx
d9fdeb14dbdbf035e12e7e6d45a24acd84c9da8cf8b8dbadc71d19baeb510ab0

$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS     NAMES
d9fdeb14dbdb   nginx     "/docker-entrypoint.…"   4 seconds ago   Up 3 seconds   80/tcp    zen_jepsen

# -pオプションをつけて8080ポートでアクセスできるようにする
$ docker run -d -p 8080:80 nginx
55378527d5381db7a3c50bc7a59ad2d8665499bee22f6a319d7e36ae44a08273

$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS          PORTS                  NAMES
55378527d538   nginx     "/docker-entrypoint.…"   2 seconds ago    Up 1 second     0.0.0.0:8080->80/tcp   great_lichterman
d9fdeb14dbdb   nginx     "/docker-entrypoint.…"   37 seconds ago   Up 36 seconds   80/tcp                 zen_jepsen

# 実際にアクセスできることも確認する
$ curl http://localhost/
curl: (7) Failed to connect to localhost port 80 after 6 ms: Couldn't connect to server
$ curl http://localhost:8080/
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
・・・

-pオプションをつけるとSTATUSの表示が0.0.0.0:8080->80/tcpとなり、ホスト側が8080ポートでアクセスするとコンテナ側の80ポートにフォワードする設定になっていることがわかります。

コンテナをバックグラウンド実行で起動する

docker run -d <イメージ名>[:<タグ名>]
docker run -d <イメージID>
$ docker run -d nginx
8e715a36735862e297ddc4cec19bb6c1ae96cd4f822e3f4cd915a0d183b87e59

$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS          PORTS     NAMES
8e715a367358   nginx     "/docker-entrypoint.…"   10 seconds ago   Up 10 seconds   80/tcp    pedantic_cohen

コンテナの停止

docker stop <コンテナID>
docker stop <コンテナ名>
# コンテナが起動していることを確認
$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes   80/tcp    web01

# コンテナを停止する
$ docker stop ce2
ce2

# コンテナがdocker psでの表示から消え、docker ps -aでのみ確認できるようになっていることを確認
$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS                     PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   32 minutes ago   Exited (0) 7 seconds ago             web01

コンテナの起動

docker start <コンテナID>
docker start <コンテナ名>
# 停止しているコンテナを確認する
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND                   CREATED        STATUS                      PORTS     NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   16 hours ago   Exited (0) 58 minutes ago             nginx01

# コンテナのコンテナIDの一部を指定してコンテナを起動
$ docker start 17e
17e

# コンテナが起動したことを確認する
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND                   CREATED        STATUS          PORTS                  NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   16 hours ago   Up 14 seconds   0.0.0.0:8080->80/tcp   nginx01

コンテナの削除

docker rm <コンテナID>
docker rm <コンテナ名>
# 停止しているコンテナのコンテナIDを確認する
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND                   CREATED        STATUS                     PORTS     NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   16 hours ago   Exited (0) 2 seconds ago             nginx01

# コンテナIDの一部を指定してコンテナを削除する
$ docker rm 17e
17e

# コンテナが削除されたことを確認する
$ docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

起動中のコンテナ内でコマンドを実行

docker exec -itコマンドを使うとコンテナ内で任意のコマンドを実行できます。

docker exec -it <コンテナID> <コマンド>
docker exec -it <コンテナ名> <コマンド>
$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS         PORTS     NAMES
ce2fa12b11da   nginx     "/docker-entrypoint.…"   39 minutes ago   Up 3 seconds   80/tcp    web01

# コンテナで「ls -l /var/log/nginx」を実行する
$ docker exec -it web01 ls -l /var/log/nginx
total 0
lrwxrwxrwx 1 root root 11 Aug 15 23:58 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Aug 15 23:58 error.log -> /dev/stderr

停止中のコンテナに実行してもエラーとなります。

$ docker stop web01
web01

$ docker exec -it web01 ls -l /var/log/nginx
Error response from daemon: Container ce2fa12b11da0fcf214221c5cb4687ed48f5ac73e6e71586d2ddcee98202df7e is not running

-itオプションにはもう一つ使い方があり、sshコマンドを使わなくてもコンテナ内にログインできるようになります。

$ docker exec -it web01 /bin/bash
root@ce2fa12b11da:/#

コンテナのセキュリティを高めるためには不要なサービスは公開せず、不要なポートも開けない方がよいため、-itオプションでのログインは非常に重要なテクニックとなります。

コンテナのログを表示

コンテナが出力するログを確認します。

docker logs <コンテナID>
docker logs <コンテナ名>

この例ではnginxイメージから作成したコンテナのログを確認しています。

$ docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED        STATUS        PORTS                  NAMES
17e44cfb7902   nginx     "/docker-entrypoint.…"   15 hours ago   Up 15 hours   0.0.0.0:8080->80/tcp   nginx01
$ docker logs 17e
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/08/31 22:20:56 [notice] 1#1: using the "epoll" event method
2023/08/31 22:20:56 [notice] 1#1: nginx/1.25.2
2023/08/31 22:20:56 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)
2023/08/31 22:20:56 [notice] 1#1: OS: Linux 5.15.49-linuxkit-pr
2023/08/31 22:20:56 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/08/31 22:20:56 [notice] 1#1: start worker processes
2023/08/31 22:20:56 [notice] 1#1: start worker process 29
2023/08/31 22:20:56 [notice] 1#1: start worker process 30
2023/08/31 22:20:56 [notice] 1#1: start worker process 31
2023/08/31 22:20:56 [notice] 1#1: start worker process 32
2023/08/31 22:20:56 [notice] 1#1: start worker process 33

ボリュームの操作

ボリュームの一覧表示

一覧に表示されるVOLUME NAMEがボリューム名です。

docker volume ls
$ docker volume ls
DRIVER    VOLUME NAME
local     hello

ボリュームの作成

コンテナ起動にボリュームを作成できるため、使用頻度は低いですが、ボリューム単独で作成することもできます。

docker volume creare <ボリューム名>

helloボリュームを作成する場合は以下を実行します。

$ docker volume create hello
hello

ボリュームの削除

<ボリューム名>を指定してコンテナで使用していないボリュームを削除します。

docker volume rm <ボリューム名>

helloボリュームを削除する場合は以下を実行します。

$ docker volume rm hello
hello

コンテナで使用しているボリュームを削除しようとするとエラーになります。

# ボリュームを作成
$ docker volume rm hello
hello
$ docker volume ls
DRIVER    VOLUME NAME
local     hello

# ボリュームをコンテナで使用する
$ docker run -d -v hello:/world busybox
ef22b9ed8a199057d11e9303eb153872d434b56cf098358da6c761f0aca8b201

# 削除しようとするとエラーとなり、使用しているボリュームのコンテナIDが表示される
$ docker volume rm hello
Error response from daemon: remove hello: volume is in use - [ef22b9ed8a199057d11e9303eb153872d434b56cf098358da6c761f0aca8b201]
$ docker volume ls
DRIVER    VOLUME NAME
local     hello
$ ボリュームを使用しているコンテナを削除する
$ docker rm ef22
ef22

# 再度ボリュームの削除を試み、削除できることを確認する
$ docker volume rm hello
hello
$ docker volume ls
DRIVER    VOLUME NAME

ボリュームを使用しているコンテナを調べる(応用)

xargsコマンドとjqコマンドを組み合わせた方法になりますが、以下のようにすることで指定のコンテナ名(.Name == "hello"がボリューム名を指定している箇所)を使用しているコンテナのコンテナIDを調べることができます。

docker ps -aq | xargs docker inspect | jq '.[] | select(.Mounts[]? | .Name == "hello") | .Id'
"21dc45864d5fa616e293f53b9324f1461b0e14f73adbcd57c2801c4a4ea90b31"

asdfでmacOSにTerraformをインストールする

Terraformを使う必要があったので、asdfでTerraformをインストールしました。

Terraformのインストール

他の手段もありますが、バージョンアップをすることが多いため、asdfを使ってインストールします。

Terraformプラグインの追加

plugin addコマンドでTerraformプラグインを追加します。

$ asdf plugin add terraform
updating plugin repository...HEAD is now at b03baaa feat: add asdf-oapi-codegen plugin (#864)

plugin listコマンドで追加済みのプラグインをリストし、terraformがあれば追加されています。

$ asdf plugin list
nodejs
python
terraform
yarn

Terraformをインストールする

list allコマンドでTerraformの利用可能なすべてのバージョンをリストします。

$ asdf list all terraform
・・・
1.5.0
1.5.1
1.5.2
1.5.3
1.5.4
1.5.5
1.5.6
1.6.0-alpha20230719
1.6.0-alpha20230802
1.6.0-alpha20230816

今回は1.5.6をインストールすることにします。

installコマンドでバージョンを指定してインストールします。

$ asdf install terraform 1.5.6
Downloading terraform version 1.5.6 from https://releases.hashicorp.com/terraform/1.5.6/terraform_1.5.6_darwin_arm64.zip
Skipping verifying signatures and checksums either because gpg is not installed or explicitly skipped with ASDF_HASHICORP_SKIP_VERIFY
Cleaning terraform previous binaries
Creating terraform bin directory
Extracting terraform archive

ログを見ても適切なバイナリ(darwin_arm64)が使用されていることがわかりますが、あとでバージョンを確認したときにもう一度確認しておきましょう。

今回インストールしたバージョンは普段使いするバージョンですので、globalコマンドを使ってグローバルに使用できるようにします。

$ asdf global terraform 1.5.6

複数のプロジェクトを担当していて、プロジェクトによって使用するバージョンが異なる場合は、localでプロジェクトごとにバージョンを制御できるようにしてください。

インストールできたことを確認するために-vオプションを指定してバージョンを確認します。

$ terraform -v
Terraform v1.5.6
on darwin_arm64

インストール時に指定したバージョンで、バイナリの種類も適切であることを確認できました。

まとめ

Terraformのバージョン管理の手段としては、tfenvが有名です。

こちらでもいいのですが、せっかくasdfをインストールしているので、asdfを使ってインストールしてみました。待ち時間もほとんどなくサクッとインストールすることができました。

RxJSとは Part 1

RxJSはかなりボリュームがあるので何回かに分けて取り扱います。まずは、RxJSの概要、ObservableObserverについて説明します。

RxJSとは?

RxJSは、ReactiveXプロジェクトの一部として開発されたJavaScript用のリアクティブプログラミングライブラリです。このライブラリを用いることで、非同期データストリームをシンプルかつ効果的に扱うことができます。Webアプリケーションでのユーザーインタラクションのハンドリングや外部データソースからのデータ更新の監視はもちろん、Node.jsベースのバックエンドでの開発においても有効です。

特に、Node.jsにおける利用ケースとしては、WebSocketメッセージのストリーム処理、外部システムやデータベースからのイベントドリブンアーキテクチャ、ストリームベースのファイル処理、外部APIのポーリングやマイクロサービス間の非同期通信など、非同期やデータストリーム処理が中心となるシナリオでの使用が挙げられます。

リアクティブプログラミングの概要

リアクティブプログラミングは、データストリームとそのデータストリームに対する変化の伝播に基づくプログラミングパラダイムの1つです。これは、変数の変更やイベント、ユーザーの操作など、さまざまな情報源からのデータを非同期的に扱うのに適しています。

例えば、ユーザーインターフェイスのイベント、APIからのレスポンス、または定期的に発生するイベントなど、様々なものがデータストリームとして表現されます。そして、これらのデータストリームに変更や操作を行うための処理を結合・合成することで、高度な動作やデータの流れを簡単に表現することができます。

ObservableとObserver

RxJSの中心となる概念は、ObservableObserverです。

Observable

データストリームの源となるオブジェクトです。非同期的にゼロ以上の値を生成し、それらの値をObserverに通知します。例として、ユーザーのクリックイベントやHTTPリクエストのレスポンスなどが考えられます。

Observer

Observableからのデータの通知を受け取るオブジェクトです。3つの主要なメソッドがあります。

  • next: 新しいデータがObservableから送られてきたときに呼び出される。
  • error: エラーが発生したときに呼び出される。
  • complete: データの送信が完了したときに呼び出される。

Observableを購読することで、データストリームを監視し、新しいデータやエラー、完了の通知を受け取ることができます。この購読の過程でObserverの各メソッドが関連付けられ、データの流れに応じて適切な処理が行われます。

RxJSの主要な概念

Observableの作成

Observableは、非同期なデータや複数のデータの流れを表現するオブジェクトです。RxJSでは、様々な方法でObservableを生成することができます。

of

静的な値からObservableを作成します。

import { of } from 'rxjs';
const observable = of(1, 2, 3);

from

配列やPromise、繰り返し可能なオブジェクトからObservableを作成します。

import { from } from 'rxjs';
const observable = from([1, 2, 3]);

create

カスタムのObservableを作成します。特定のロジックや外部のデータソースと結合したい場合に使用します。

import { Observable } from 'rxjs';
const observable = new Observable(observer => {
  observer.next('Hello');
  observer.next('World');
  observer.complete();
});

pipe関数

pipe関数 は、与えられたオペレータを左から右の順番で適用して、新しい Observable を返すObservableの関数です。このメカニズムにより、非同期データの変換、フィルタリング、エラーハンドリングなどの一連の操作を組み合わせることができます。

import { of } from 'rxjs';
import { map, filter } from 'rxjs/operators';

const data$ = of(1, 2, 3, 4, 5);

const processedData$ = data$.pipe(
  filter(num => num % 2 === 0),  // 偶数だけをフィルタリング
  map(num => num * 10)           // 値を10倍に変換
);

processedData$.subscribe(console.log);  // 20, 40 が出力される

Operatorsの概要

Operatorsは、Observableのデータストリームに対して操作を行い、新しいObservableを生成する関数です。これにより、非同期データのフィルタリング、変換、結合などの様々な操作を行うことができます。

mapオペレーター

map オペレーターは、Observable が発行する各アイテムに関数を適用します。入力として関数を受け取り、この関数をストリームの各アイテムに適用します。入力としての関数は、アイテムを別の形に変換するために使用されます。

import { of } from 'rxjs';
import { map } from 'rxjs/operators';
const nums = of(1, 2, 3);
const squareValues = nums.pipe(map(val => val * val));

filterオペレーター

filter オペレーターは、指定された条件に基づいて Observable のアイテムをフィルタリングします。入力として関数を受け取り、この関数は各アイテムに対して真偽値を返します。返された真偽値が true の場合、そのアイテムは出力されるストリームに含まれます。false の場合、アイテムは出力されるストリームから除外されます。

import { from } from 'rxjs';
import { filter } from 'rxjs/operators';
const nums = from([1, 2, 3, 4, 5]);
const evenNums = nums.pipe(filter(val => val % 2 === 0));

tapオペレーター

tap オペレータは、Observable の各要素に対して副作用を持たせるためのものです。つまり、データストリーム自体には影響を及ぼさず、Observable の要素に何らかの操作を適用するために使用します。これはデバッグやログ出力などの目的でよく使用されます。

import { of } from 'rxjs';
import { tap } from 'rxjs/operators';

of(1, 2, 3).pipe(
  tap(val => console.log(`Before map: ${val}`)),
  tap(val => val * 2),
  tap(val => console.log(`After map: ${val}`)) // 値は変わらない
).subscribe();

これ以外にも、数多くのOperatorsが提供されており、様々なデータ操作を容易に行えます。

まとめ

ObservableとObserverはリアクティブプログラミングの考え方に即した比較的わかりやすいクラスです。また、今回扱ったオペレータはごく一部ですが、とてもよく使用するものを挙げました。

次回はSubjectを扱います。

ChatGPTで質問するときの工夫

最近では、プロンプトエンジニアリングという言葉は一部の界隈でしか聞かなくなりましたが、ChatGPTを活用した仕事術という形で結構広まってきました。

メリットもあればデメリットもあるため、業務での使用を禁止している企業の話題も出てきています。

使い方を間違えなければ強い味方になるのは間違いないので、今回は自分の知らないことを検索して調べるのではなく、ChatGPTに聞いてみます。

とはいえ、合っているかどうかわからないと正しさを検証できないので、ここでは「フェーン現象」について質問してみました。

普通に聞いてみる

まずは普通に聞いてみましょう。GPT 4も使えたのですが、使えない方もいると思いますので、GPT 3.5で質問しています。

Q:フェーン現象について教えてください。

A:フェーン現象(フェーンげんしょう)は、風が山脈を越える際に発生する気象現象の一種です。この現象は、風が山脈の風下側(山を背にして吹く側)に吹く際に、急激な温度上昇や乾燥化が起こることを特徴としています。以下にフェーン現象の主な要因と影響を説明します。

フェーン現象の主な要因:
1.風上側の山脈:風が山脈を越える際、山を登る際には空気が上昇し、冷却されていきます。しかし、山を下る際には空気が急速に下降し、圧縮されます。この圧縮過程により、空気が急激に温まる現象が発生します。
2.エンタルピーの変化:風が山を上る際には、山を登ることに伴ってエネルギーが消費されるため、気温が低下します。一方、山を下る際には、エネルギーが放出されるため気温が上昇します。これによって、風下側での温度上昇が起こるのです。

フェーン現象の影響:
1.温暖化と乾燥化:フェーン風が吹くことにより、空気が急激に温まるため、気温が上昇します。このため、風下側の地域では急激な温暖化が起こります。また、フェーン風は湿度も低下させるため、風下側の地域は乾燥化することがあります。
2.気象条件の変化:フェーン風は局地的な気象条件を変化させることがあります。たとえば、雲の消失や雨の停止などが起こることがあります。
3.風速の変化:フェーン風はしばしば風速を増加させることがあります。これは、山脈を下る空気が圧縮されて加速するためです。
4.地域差:フェーン現象は地域によって異なる影響を持ちます。山脈や地形、風の方向などによってフェーン風の特性が変わり、影響も異なる場合があります。

フェーン現象は、気象学や地形に関する興味深い現象であり、その影響は風下側の生態系や農業、気象予測にも影響を与えることがあります。

内容が正しいとかの前に読む気にならないですよね。制約条件を追加することで文章量自体を減らすことは可能ですが、そもそもの文章が硬いので、ぱっと見て頭に入ってきません。

制約条件を設定する – 読者の年齢層を指定する

制約条件を追加したわかりやすくしましょう。ここでは12歳以下でもわかるようにすることを制約条件として追加します。

Q:フェーン現象について教えてください。
# 制約条件
・12歳以下にもわかる内容にする

A:もちろんです!フェーン現象は、風の影響で起こる天気の変化を説明する現象です。

まず、山や山脈の向こう側に風が吹くと、風は山を越えるときに上昇します。このとき、風は山を迂回するように上昇し、山の上に達すると冷えて湿度が高まります。そして、山の反対側に下降するとき、空気は山を越える前よりも乾燥して暖かくなります。
この暖かく乾燥した空気は、山を越えた向こう側で風として吹き出し、空気中の湿度が低いため雲が発生しにくく、晴れた日が続くことがあります。また、この現象によって気温が急激に上昇することもあります。

つまり、フェーン現象は、山を越えた風が上昇・冷却・乾燥し、山の反対側で下降・温暖・乾燥することで、天気の変化を引き起こす現象なんですよ!

文章量が減りつつ、内容も簡単になっていますね。まったく知らない用語や事柄を調べる場合、いきなり理論的なことを書かれても頭に入ってこないので、低年齢の方に向けて書いてもらうことでわかりやすい内容で書いてくれるようになります。

制約条件を設定する – ポイントを強調する

もう一つ制約条件を追加してみましょう。文章を最初から読むのはつらいので、ポイントとなる箇所を太字にしてもらいます。

Q:フェーン現象について教えてください。
# 制約条件
・12歳以下にもわかる内容にする
・ポイントとなる部分を太字にする

A:もちろんです!フェーン現象は、風が山を越えるときに起こる特別な気象のことを指します。これをわかりやすく説明しましょう。

まず、山と風の関係を考えてみましょう。山は高いところですよね。風が山に当たると、風は山を登っていくのですが、山を越えるときには面白いことがおこるのです。
フェーン現象では、風が山を登るときに山の風が強く吹き、山の向こう側(風の吹かない側)に下りるときに風が温かく乾燥した状態に変わるのです。
具体的に説明すると、風が山を登るとき、山の斜面を登るにつれて空気が上昇します。そして、上昇すると、空気は高いところで冷たくなります。その冷たい空気が山のてっぺんを越えると、山の向こう側へ降りていくとき、空気が下りながら温まるんです。

これがフェーン現象の大まかな仕組みです。フェーン現象が起こると、山を越えた向こう側では風が暖かくて乾燥しているため、雨が降りにくくなります。そのため、フェーン現象が起こる地域では、雨が少ないことがよくあります。

簡単にまとめると、風が山を登っていくときに冷たくなり、山を越えて下りてくるときに温かくなる現象がフェーン現象です。これによって、山を越えた向こう側では晴れていることが多いですよ!

最後の太字部分がポイントでここを読んでから他の箇所を読むと理解しやすいです。

内容を深掘りする

概要を理解したところで、追加の質問をして理解を深めましょう。ここでは、空気が高いところで冷たくなる理由を聞いてみます。

Q:「空気は高いところで冷たくなります」とありますが、空気が高いところで冷やされる理由を教えてください。
# 制約条件
・12歳以下にもわかる内容にする
・ポイントとなる部分を太字にする

A:もちろんです!空気が高いところで冷やされる理由を教えますね。

空気は実は、高いところに行くほど薄くなっているんです。イメージすると、山を登るとどんどん空気が薄くなるような感じです。そして、薄い空気は温度を持ちにくい性質があるんです。
こう考えると、低いところにある空気は分子同士がたくさん集まっていて、一緒に熱を持っています。でも高いところに行くと、空気の分子が少なくなるので、熱を持ちにくくなるんです。
たとえば、山を登ると、頂上に行くにつれて空気が薄くなるので、その空気は冷たく感じることがあります。これと同じように、空気が高いところにあると、分子同士のぶつかり合いも少なくなって、熱を逃がしやすくなるんです。だから、空気が高いところで冷えてしまうんですね。

要するに、空気は高いところほど薄くて、分子同士が離れているので熱を持ちにくく、それが高いところでの冷たさの理由なんです!

太字にするのはうまくいきませんでしたが、内容の深掘りはできています。回答が気に入らなければRegenerateしてください。

まとめ

ChatGPTに質問をする場合、制約条件を追加することで制約条件にあった回答を得られるようになります。

今回試した、読者の年齢層の指定やポイントとなる箇所を太字にするなどすると、回答を理解しやすくなります。常に読者の年齢層を下げて質問できるかというと場合によりますが、年齢層の指定や概要のみを回答してもらうことで、理解しやすくなります。概要を理解したところで、詳細を一つずつ聞く方が理解しやすいだけでなく、適切な回答を得られやすくなります。

ChatGPTに質問するやり方は検索エンジンで検索するよりもずっと早く答えにたどり着くことができます。ある程度概要を理解したり、関連する用語などを把握してからそれらの情報を元に検索エンジンで調べた方が、検索の精度が上がりますし、情報の精査もしやすいです。

適切に使用することで効率的に情報収集することができます。

リアクティブプログラミング

Angularのサービスの説明をする前にリアクティブプログラミングについて説明します。

リアクティブプログラミングとは

リアクティブプログラミングは、データの流れ(ストリーム)に着目し、データを受け取るたびに処理を処理するプログラミングパラダイムです。

リアクティブプログラミングは、用語が独特で概念の通常のプログラミングとは少し異なっているため、理解しづらい場合があります。また、実装系によっても違いがあります。今回は一般的なリアクティブプログラミングについて説明し、次回RxJSについて説明します。

リアクティブプログラミングの用語

リアクティブプログラミングには多くの用語があり、異なるライブラリやフレームワークによって少し異なる言い回しがされることもあります。しかし、以下はリアクティブプログラミングのコンセプトを理解する上で基本となる用語のリストです。これらの用語は、多くのリアクティブプログラミングの文脈で一般的に使用されています。

発行者(Publisher)

生産者(Producer)やオブザーバブル(Observable)とも呼ばれます。データやイベントを生み出し、それをストリームとして発行するエンティティです。発行者は、一つまたは複数の購読者にデータを非同期的に供給する役割を果たします。

購読者(Subscriber)

消費者(Consumer)やオブザーバー(Observer)とも呼ばれます。発行者からのデータやイベントを受け取り、それを処理するエンティティです。購読者は、発行者からデータを受け取ることを購読する(subscribe)と言われ、この購読関係を通じてデータが非同期的に供給されます。

操作(Operators)

購読者が購読しているデータストリームからデータを受け取る際に適用する操作です。フィルタ(filter)やマップ(map)など様々な操作があります。

バックプレッシャー(Back pressure)

データの発行速度と購読速度の不均衡を管理する概念。発行側が高速で、購読側がそれに追いつけない場合に対処するための機構を提供します。

ColdとHot

  • Cold:購読が開始されるまでデータを発行しない
  • Hot:購読の有無に関係なくデータを発行する

リアクティブプログラミングの概念

リアクティブプログラミングの概念について説明します。

発行者はデータを発行し、データストリームを形成します。データの発行は一般に非同期で行われますが、同期で行われることもあります。

購読者は発行者を購読し、データを待ち受けます。データを受け取るたびに処理を実行します。ただし、すべてのデータを処理するわけではなく、Operatorsによって受け取るかどうかをフィルタすることもできます。

購読者が処理できる量には限界があります。発行者がデータを発行するペースよりも購読者が処理できるペースの方が遅い場合、発行済み未処理のデータをどうするかという問題がでてきます。購読者の処理能力を発行者の発行能力が上回る状態に対する対処を行う機構をバックプレッシャーと言います。具体的な対処方法としては、

  • 購読者が購読可能なデータ量を発行者に伝え、発行者はそれに合わせてデータを発行する
  • 発行者の発行しているデータをバッファリングする
  • 受け取れないデータは捨てる

などがあります。どの戦略が適しているかはデータの性格(失われると困るのか、多少失われても問題ないのか)やデータ発行の処理(購読者の要求に応じて発行できるのか、とりあえず生成し続けるしかないのか)によって変わります。

リアクティブプログラミングのユースケース

リアクティブプログラミングを適用できるユースケースをいくつか挙げます。

  1. リアルタイムデータのストリーミング:フィンテック、株価のストリーミングや、ライブスポーツのスコア更新など
  2. リアルタイムのダッシュボード:ユーザーアクティビティ、システムメトリクス、eコマースの販売統計など、リアルタイムで更新する必要があるダッシュボード
  3. チャットアプリケーション:ユーザー間でリアルタイムにメッセージを交換するアプリ
  4. オンラインゲーム:特にマルチプレイヤーオンラインゲームで、プレイヤー間のリアルタイムのインタラクションが必要
  5. イベント駆動のマイクロサービスアーキテクチャ:サービスが非同期的にデータを交換する
  6. 非同期なバッチ処理:大量のデータを効率的に処理する必要がある場面で、特にデータの供給速度が不均一な場合
  7. リアルタイムの通知システム:ユーザーにリアルタイムで通知やアラートを提供するシステム
  8. センサーデータの処理:IoTデバイスからのリアルタイムデータを効率的に収集、分析、反応する
  9. 動的なネットワーク応答:ユーザーのリクエストに応じて、非同期的にコンテンツを動的に生成・配信するウェブサービス
  10. リソース制限のある環境:例えばモバイルデバイスや組み込みシステムなど、リソースが制限されている環境での非同期処理やリアルタイム処理

最近ではWebアプリケーションで使用することが多いため、サーバーが発行者、クライアントが購読者という組み合わせや画面のコンポーネント間での使用をイメージしやすいですが、サービス間でのやりとりや非同期バッチなどに使用することもあります。

まとめ

サービスを作成しようとするとRxJSを使うことになるため、先にリアクティブプログラミングについて説明しました。次回はRxJSについて説明します。

Angularでモジュール(NgModule)を作成する

前回作成したコンポーネントがAppModuleに登録されているので、SharedModuleを作成してそちらに登録するように変更します。

これは後からモジュールを作成するパターンになりますが、一般的には先にモジュールを作成する方が多いため、今後使用するUserModuleも作成しておきます。

モジュールとは

Angularのモジュールは、アプリケーションの一部を構成し、関連するコンポーネント、ディレクティブ、パイプ、サービスなどをグループ化するコンテナです。モジュールはアプリケーションの機能を整理し、再利用しやすくする役割を果たします。

特に、Angularのモジュールは@NgModuleデコレータを使用して定義され、以下の主要なメタデータプロパティを持ちます:

  • declarations: モジュール内で使用されるコンポーネント、ディレクティブ、パイプを宣言します。
  • imports: 他のモジュールがエクスポートしたクラスを使用できるように、このモジュールが他のモジュールに依存していることを指定します。
  • exports: 他のモジュールで使用できるように、宣言されたクラスの一部をエクスポートします。
  • providers: アプリケーション全体で使用できるサービスのプロバイダーを登録します。
  • bootstrap: アプリケーションの起点となるルートコンポーネントを指定します。

モジュールを作成する

モジュールを作成するにはng generate moduleコマンドを使用します。

--dry-runオプション

モジュールを作成する前に--dry-runオプションについて確認しておきましょう。

--dry-runオプションはコマンドを実行せずに、コマンドで作成・更新される内容を確認できるオプションです。前回のようにコンポーネントを指定する際に、appから指定すればいいのかappの下から指定すればいいのか迷うことがあると思います。このような場合には、--dry-runオプションでどんなファイルが作成されてどんなファイルが更新されるかを確認するとよいでしょう。

$ ng generate module shared --dry-run
CREATE src/app/shared/shared.module.ts (192 bytes)

NOTE: The "--dry-run" option means no changes were made.

実際に実行してみると、作成されるモジュールのパスと名前が確認でき、「NOTE: The “–dry-run” option means no changes were made.」と変更がなかった旨のメッセージ表示されています。

SharedModuleはルーティングを必要としない共通コンポーネント・サービス等をまとめたモジュールですので、--routingオプションなしで実行します。

では、--dry-runなしで実行しましょう。

$ ng generate module shared
CREATE src/app/shared/shared.module.ts (192 bytes)

気づいたかもしれませんが、コンポーネントのときとは違ってモジュールクラスのファイルが作成された以外に更新されたファイルなどはありません。すなわち、作成したモジュールが自動的にどこかのモジュールに自動登録されることはありません。

まずはSharedModuleを修正します。まずは修正前の状態を確認しておきましょう。

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';



@NgModule({
  declarations: [],
  imports: [
    CommonModule
  ]
})
export class SharedModule { }

前回作成したTitleComponentを追加していきます。モジュールに属するコンポーネント、ディレクティブ、パイプはdeclarationsに記載します。加えて、他のモジュールに公開するためにexportsに記載します。

修正後のモジュールが以下のようになります。

import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';
import { TitleComponent } from './components/title/title.component';

@NgModule({
  declarations: [TitleComponent],
  imports: [CommonModule],
  exports: [TitleComponent],
})
export class SharedModule {}

次にAppModuleを修正します。これまではTitleComponentapp.component.htmlで使用するためにAppModuleに登録していました。

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';
import { TitleComponent } from './shared/components/title/title.component';

@NgModule({
  declarations: [AppComponent, TitleComponent],
  imports: [BrowserModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

今後は、SharedModuleをインポートすることでTitleComponentを使用できるようにします。まずはdeclarationsからTitleComponentを削除し、その代わりにimportsTitleComponentが登録されているSharedModuleを追加します。

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppComponent } from './app.component';
import { SharedModule } from './shared/shared.module';

@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, SharedModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

実際に動作するか確認してみましょう。http://localhost:4200/にアクセスし、これまでどおり

のように表示されれば正しく修正できています。

UserModuleを作成する

次に今後使用するUserModuleを作成します。

モジュール名は単数形か複数形か

結論からいうと、チームによって異なります。これは個人的な見解となりますが、単数形と複数形で意味が異なる単語もあるため、単数形で書くことを基本にして複数形の意味を使いたい場合は複数形を使用する、というのがよいのではないかと考えています。

モジュールを作成する

ではUserModuleを作成します。今回はルーティングを伴うモジュールとするため、--routingオプションを使用します。また、今回は省略形であるng g mコマンドで実行します。--dry-runオプションをつけて確認しましょう。

$ ng g m user --routing --dry-run
CREATE src/app/user/user-routing.module.ts (247 bytes)
CREATE src/app/user/user.module.ts (272 bytes)

NOTE: The "--dry-run" option means no changes were made.

appディレクトリの下にuserディレクトリが作成され、user.module.tsが作成されます。加えて、ルーティングモジュールであるuser-routing.module.tsも作成されることが確認できます。

期待したとおりに作成されることを確認できたので、--dry-runオプションを外して実行します。

$ ng g m user --routing
CREATE src/app/user/user-routing.module.ts (247 bytes)
CREATE src/app/user/user.module.ts (272 bytes)

UserModuleは現時点ではコンポーネントなど何も属していないのでこのままにしておきます。とりあえず作成したコードだけ確認しておきます。

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

import { UserRoutingModule } from './user-routing.module';


@NgModule({
  declarations: [],
  imports: [
    CommonModule,
    UserRoutingModule
  ]
})
export class UserModule { }
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class UserRoutingModule { }

これまでに作成したモジュールとは異なり、user-routing.module.tsにはroutesという定数があります。使い方については今後確認していきます。

変更をコミット&プッシュする

毎度のことですが、ここまでの変更をコミット&プッシュします。

$ git add . 
$ git commit -m 'create SharedModule and UserModule'
✔ Preparing lint-staged...
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Cleaning up temporary files...
[main ed5311a] create SharedModule and UserModule
 4 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 src/app/shared/shared.module.ts
 create mode 100644 src/app/user/user-routing.module.ts
 create mode 100644 src/app/user/user.module.ts
$ git push
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 10 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.12 KiB | 1.12 MiB/s, done.
Total 10 (delta 5), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (5/5), completed with 4 local objects.
To github.com:t0k0sh1/angular-tutorial.git
   90cd6c9..ed5311a  main -> main

まとめ

今回はSharedModuleを作成し、TitleComponentAppModuleからSharedModuleに移しました。今後は共通コンポーネントはSharedModuleに登録していくことにします。

また、今後に備えてルーティング設定をもったUserModuleも作成しました。こちらは今後使用していきます。

次回は画面にメッセージを表示するコンポーネントの作成を通じてサービスを使ったコンポーネント間のデータの受け渡しについて見ていきます。

AngularプロジェクトにTailwind CSSを導入する

今回はTailwind CSSを導入し、簡単なコンポーネントを作成します。

Tailwind CSSとは


Tailwind CSSは、高度にカスタマイズ可能なユーティリティファーストのCSSフレームワークです。ユーティリティファーストとは、小さい単位(ユーティリティ)のクラスを組み合わせてデザインを構築するアプローチのことで、そのための多くのプリセットクラスが提供されています。

特徴

  1. ユーティリティファースト: HTMLの中で直接、スタイリングができるため、CSSファイルを跨いで行ったり来たりする必要がありません。
  2. カスタマイズ可能: プロジェクトの特定のデザイン要件に合わせて、設定ファイルを使って色、サイズ、余白などをカスタマイズすることが可能です。
  3. レスポンシブデザイン: レスポンシブデザインのプレフィックスが提供されているため、さまざまなデバイスサイズでの表示を容易にコントロールできます。
  4. プラグインシステム: カスタムユーティリティやコンポーネントを簡単に追加するためのプラグインシステムも提供しています。

Angularでのサポート状況

Angular v11.2から公式にサポートされています。

Tailwind CSSを導入する

では、AngularプロジェクトにTailwind CSSを導入していきます。基本的には公式の手順に従って進めます。

$ npm install -D tailwindcss postcss autoprefixer

added 26 packages, changed 1 package, and audited 1161 packages in 3s

186 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
$ npx tailwindcss init

Created Tailwind CSS config file: tailwind.config.js

必要なパッケージをインスト−ルし、tailwind.config.jsが作成されます。

続いてtailwind.config.jsを以下のように変更します。

/** @type {import('tailwindcss').Config} */
module.exports = {
- content: [],
+ content: [
+   "./src/**/*.{html,ts}",
+ ],
  theme: {
    extend: {},
  },
  plugins: [],
}

修正後のtailwind.config.jsは以下のようになります。

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ['./src/**/*.{html,ts}'],
  theme: {
    extend: {},
  },
  plugins: [],
};

続いてsrc/styles.cssを以下のように編集します。

/* You can add global styles to this file, and also import other style files */
@tailwind base;
@tailwind components;
@tailwind utilities;

元々あるコメントは追加しても削除してもどちらでも構いません。

ここまででインストールは完了です。実際に使用可能か動作確認をしてみます。

まずは開発サーバーを起動します。

$ ng serve
✔ Browser application bundle generation complete.

Initial Chunk Files   | Names         |  Raw Size
vendor.js             | vendor        |   1.98 MB | 
polyfills.js          | polyfills     | 333.16 kB | 
styles.css, styles.js | styles        | 242.41 kB | 
main.js               | main          |  46.29 kB | 
runtime.js            | runtime       |   6.53 kB | 

                      | Initial Total |   2.59 MB

Build at: 2023-08-06T07:20:58.691Z - Hash: 34fc5b5c11ac8fa2 - Time: 4089ms

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **


✔ Compiled successfully.

ng serveコマンドは開発サーバーを起動するコマンドです。デフォルトでは4200ポートを使用します。

動作確認をするために、src/app/app.component.htmlを以下のように書き換えます。

<h1 class="text-3xl font-bold underline">Hello world!</h1>

元々ある大量のコードはすべて削除しています。

変更保存をするとすぐに反映されます。では、http://localhost:4200/にアクセスし、以下のように表示されればTailwind CSSが有効になっています。

Tailwind CSSを便利にする拡張機能をインストールする

Tailwind CSSでのプログラミングを便利にする拡張機能をいくつかご紹介します。

Tailwind CSS IntelliSense

Tailwind CSSのオートコンプリート、リント、class属性で設定されるスタイルのプレビューなどの機能を提供する拡張機能です。

Tailwind Fold

Tailwind CSSを使用するとclass属性が長くなりがちです。これはコード全体の可読性低下にもつながるため、この拡張機能で普段は省略表示しておくとよいでしょう。

Tailwind Documentation

Tailwind CSSのドキュメントにすばやくアクセスするための拡張機能です。最近ではチートシートサイトがいくつもりますので、そちらの方が使いやすければこの拡張機能は特に使う必要はありません。

コンポーネントを作成する

動作確認は行っていますが、実際にコンポーネントを作成してみましょう。

ここで作成するコンポーネントは先ほど動作確認のために作成したタグをコンポーネント化してみましょう。

コンポーネントのひな形を自動生成する

ng generateコマンドを使ってコンポーネントのひな形を作成します。コンポーネントを作成する場合はcomponentを指定して、その後に生成するコンポーネントのパスを書きます。

$ ng generate component shared/components/title
CREATE src/app/shared/components/title/title.component.css (0 bytes)
CREATE src/app/shared/components/title/title.component.html (20 bytes)
CREATE src/app/shared/components/title/title.component.spec.ts (552 bytes)
CREATE src/app/shared/components/title/title.component.ts (198 bytes)
UPDATE src/app/app.module.ts (390 bytes)

コマンドは省略形もありますが、今回は省略せずに書きました。また、コンポーネントのパスにはsrc/app/を含まない点に注意してください。

コンポーネントを作成する

このコンポーネントは呼び出し元からテキスト(先ほど作成したタグのHello world!の部分)を受け取って表示するコンポーネントにします。

まずはtitle.component.tsから作成します。自動生成したコードは次のようになっています。

import { Component } from '@angular/core';

@Component({
  selector: 'app-title',
  templateUrl: './title.component.html',
  styleUrls: ['./title.component.css']
})
export class TitleComponent {

}

詳しくは別途解説しますが、コンポーネントを使用する側から何か値を受け取るには@Inputディレクティブを使用します。

修正後のtitle.component.tsは以下のとおりです。

import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-title',
  templateUrl: './title.component.html',
  styleUrls: ['./title.component.css'],
})
export class TitleComponent {
  @Input() title: string;

  constructor() {
    this.title = '';
  }
}

titleというメンバ変数に@Input()を付与し、呼び出し元から受け取れるようにしています。

次にtitle.component.htmlを作成します。

<h1 class="text-3xl font-bold underline">{{ title }}</h1>

先ほどTitleComponentに追加したtitleを表示しています。

では実際に使ってみましょう。app.component.htmlを以下のように修正します。

<app-title title="{{ title }}" />

app-titleコンポーネントのtitle属性にAppComponenttitleを設定します。

AppComponenttitleメンバに設定されている文言が表示されれば期待したとおりの動作になっています。

テストを行う

最後にテストを行いましょう。

今回作成したTestComponentとHTMLを変更したAppComponentの両方を修正します。

まずはTestComponentのテストです。

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { TitleComponent } from './title.component';

describe('TitleComponent', () => {
  let component: TitleComponent;
  let fixture: ComponentFixture<TitleComponent>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [TitleComponent],
    });
    fixture = TestBed.createComponent(TitleComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create the title component', () => {
    expect(component).toBeTruthy();
  });

  it('should have as title an empty string', () => {
    expect(component.title).toEqual('');
  });

  it('should display the title', () => {
    const expected = 'Test title';
    component.title = expected;
    fixture.detectChanges();

    const compiled = fixture.nativeElement;
    expect(compiled.querySelector('h1').textContent).toContain(expected);
  });
});

次にAppComponentのテストです。

import { TestBed } from '@angular/core/testing';
import { AppComponent } from './app.component';
import { TitleComponent } from './shared/components/title/title.component';

describe('AppComponent', () => {
  beforeEach(() =>
    TestBed.configureTestingModule({
      declarations: [AppComponent, TitleComponent],
    }),
  );

  it('should create the app', () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app).toBeTruthy();
  });

  it(`should have as title 'angular-tutorial'`, () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app.title).toEqual('angular-tutorial');
  });

  it('should render title', () => {
    const fixture = TestBed.createComponent(AppComponent);
    fixture.detectChanges();
    const compiled = fixture.nativeElement as HTMLElement;
    expect(compiled.querySelector('app-title h1')?.textContent).toContain('angular-tutorial');
  });
});

テストの実行はng testコマンドを使用します。

$ ng test
✔ Browser application bundle generation complete.
06 08 2023 20:16:25.133:WARN [karma]: No captured browser, open http://localhost:9876/
06 08 2023 20:16:25.140:INFO [karma-server]: Karma v6.4.2 server started at http://localhost:9876/
06 08 2023 20:16:25.140:INFO [launcher]: Launching browsers Chrome with concurrency unlimited
06 08 2023 20:16:25.141:INFO [launcher]: Starting browser Chrome
06 08 2023 20:16:25.984:INFO [Chrome 115.0.0.0 (Mac OS 10.15.7)]: Connected on socket A-bmpclSUPRNDYqsAAAB with id 34000686
Chrome 115.0.0.0 (Mac OS 10.15.7): Executed 6 of 6 SUCCESS (0.035 secs / 0.024 secs)
TOTAL: 6 SUCCESS

テストではブラウザが開き結果が表示されます。

テストは起動しっぱなしにしておいて、コードを変更すればリロードされます。

コミットとプッシュを行う

ここまでの変更をコミット、プッシュします。

$ git add .
$ git commit -m 'add tailwind css'
✔ Preparing lint-staged...
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Cleaning up temporary files...
[main 90cd6c9] add tailwind css
 11 files changed, 428 insertions(+), 633 deletions(-)
 create mode 100644 src/app/shared/components/title/title.component.css
 create mode 100644 src/app/shared/components/title/title.component.html
 create mode 100644 src/app/shared/components/title/title.component.spec.ts
 create mode 100644 src/app/shared/components/title/title.component.ts
 create mode 100644 tailwind.config.js
$ git push
Enumerating objects: 26, done.
Counting objects: 100% (26/26), done.
Delta compression using up to 10 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (17/17), 5.50 KiB | 1.10 MiB/s, done.
Total 17 (delta 6), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
To github.com:t0k0sh1/angular-tutorial.git
   58ad1f8..90cd6c9  main -> main

まとめ

今回はTailwind CSSを導入し、コンポーネントを作成しました。

今回sharedにTitleComponentを作成したのですが、このコンポーネントはAppModuleに含まれています。AppModuleにすべてのコンポーネントを含めるのではなく、いくつかのモジュールに分けた方が管理しやすいです。

次回はSharedModuleを作成してTitleComponentを含めるように変更する手順を解説します。

AngularプロジェクトにHuskyを導入する

今回、Huskyを導入しますが、これにはトレードオフ(メリットとデメリット)があります。

メリット:

  1. コードの品質を保つ: Huskyはコードがリポジトリにコミットされる前に自動的にリントやテストを行うことができます。これにより、間違ったコードやコーディング規約に適合しないコードがマージされるのを防ぐことができます。
  2. 自動化: Huskyを設定することで、手動でリントやテストを行う手間を省くことができます。
  3. チームの一貫性: Huskyをプロジェクトに組み込むことで、全ての開発者が同じリントやテストを実行することを保証することができます。

デメリット:

  1. 初期設定の複雑さ: Huskyの設定は少々複雑であり、最初に設定する際には時間と労力が必要となります。
  2. 間違った設定による問題: Huskyが間違って設定された場合、全く関係のないファイルがコミットの対象になってしまったり、正常なコードでもコミットできなくなる可能性があります。
  3. コミットの遅延: もし大きなプロジェクトでテストが時間を要する場合、Huskyによりコミットが遅延する可能性があります。ただし、これは通常はリントやテストの速度問題であり、Husky自体の問題ではありません。

最も注意しなければならないのは、修正した箇所とは関係ない箇所でリントエラーが発生してコミットができないという自体が起こる可能性があるか、という点です。特に途中から導入する場合はリントエラーだらけでその対応に追われるということがあります。

リントエラーが解消したコードがコミットされることが理想的ではありますが、時と場合によってはそれよりもコミットすることが優先事項であることもありますし、プロジェクトの事情で修正箇所以外のエラーは一旦見なかったことにしたいということもあると思います。

また、コードベースが非常に大きく、リントに時間がかかってコミットがストレスになるというリスクもあります。こちらについては対策がありますので、併せてご紹介します。

Huskyとは

Huskyは、JavaScriptプロジェクトにおいてGitのフック(特定のGitイベントが発生した時に実行されるスクリプト)を簡単に管理できるようにするツールです。

Gitフックは、コミット、プッシュなどのGit操作の前後に自動的に実行されるスクリプトです。これを活用することで、コードの品質を一定に保つためのチェックやテストを自動化したり、特定の操作を制限したりすることが可能になります。

しかし、GitフックはGitリポジトリごとに設定され、通常はGitリポジトリ自体と一緒にバージョン管理されません。これは、他の開発者が同じフックを設定するのを難しくするだけでなく、フックの変更を追跡するのも困難にします。

Huskyはこれらの問題を解決します。Huskyを使用すると、フックはプロジェクトの一部としてバージョン管理でき、設定はすべての開発者間で共有できます。また、Huskyの設定は通常、プロジェクトのpackage.jsonファイルに記述され、設定の変更もGitを通じて追跡することができます。

このように、HuskyはJavaScriptプロジェクトにおけるGitフックの管理を効率化し、プロジェクト全体のコード品質を向上させる強力なツールとなることができます。

Huskyのインストール

まずはじめにHuskyをインストールします。

$ npm install husky --save-dev

added 1 package, and audited 1098 packages in 1s

165 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

インストール自体に難しいところはありません。

pre-commitフックを設定する

では早速pre-commitフックを設定しましょう。

$ npx husky install
husky - Git hooks installed

上記のコマンドを実行すると.huskyディレクトリが作成されます。

次にpre-commitフックを追加します。実行するコマンドは前回設定したnpm run lintにします。

$ npx husky add .husky/pre-commit "npm run lint"
husky - created .husky/pre-commit

では実際に実行してみましょう。Huskyをインストールしたときの変更のコミットがまだなので、これをコミットします。

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   package-lock.json
        modified:   package.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .husky/

no changes added to commit (use "git add" and/or "git commit -a")
$ git add .  
$ git commit -m 'install husky'

> angular-tutorial@0.0.0 lint
> ng lint


Linting "angular-tutorial"...

All files pass linting.

[main e0c8f78] install husky
 3 files changed, 21 insertions(+)
 create mode 100755 .husky/pre-commit

コミット時にリントが実行されていることが確認できます。

pre-commitフックでフォーマットを行う

次にpre-commitフックでPrettierを実行するようにしてみましょう。ついでに動作を確認もしてみます。

まず、Huskyのコマンドにはpre-commitフックを削除するコマンドがありません。では変更したい場合はどのようにするかを見ていきます。

現在の状態を確認する

まず、現在の状態はnpm run lintを設定してある状態です。

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run lint

ここに新たなコマンドを追加する場合は変わらずnpx husky addコマンドを使用します。

$ npx husky add .husky/pre-commit "npm run format"
husky - updated .husky/pre-commit

npx husky addコマンドを実行することで現在設定されているコマンドに加えて新たなコマンドがpre-commitフックに追加されます。

次にnpm run formatを削除してnpm run lintだけの状態にしてみます。これを実現するには、npx husky setコマンドを使用してnpm run lintを設定することでnpm run lintだけの状態になります。

$ npx husky set .husky/pre-commit "npm run lint"
husky - created .husky/pre-commit

このコマンドの実行するとnpm run lintだけになっていることが確認できます。

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run lint

最後にすべて削除する方法を確認します。先ほど使用したnpx husky setコマンドを使って削除ができます。

$ npx husky set .husky/pre-commit ""
husky - created .husky/pre-commit

上記コマンドを実行するとコマンドが削除されます。

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"


pre-commitフックでlintとフォーマットの設定を行う

話を戻してpre-commitフックにnpm run lintコマンドとnpm run formatを設定します。npx husky addコマンドを2回呼び出してコマンドを追加します。

$ npx husky add .husky/pre-commit "npm run lint"
husky - updated .husky/pre-commit
$ npx husky add .husky/pre-commit "npm run format"
husky - updated .husky/pre-commit

これにより期待したとおりコマンドが登録されます。

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"


npm run lint
npm run format

では、動作確認をしていきます。.husky/pre-commitが変更されているのでこれをコミットすることで動作確認とします。

$ git add .
$ git commit -m 'update pre-commit hook'

> angular-tutorial@0.0.0 lint
> ng lint


Linting "angular-tutorial"...

All files pass linting.


> angular-tutorial@0.0.0 format
> prettier "src/**/*.{js,jsx,ts,tsx,html,css,scss}" --write

src/app/app.component.css 9ms
src/app/app.component.html 85ms
src/app/app.component.spec.ts 71ms
src/app/app.component.ts 3ms
src/app/app.module.ts 2ms
src/index.html 1ms
src/main.ts 2ms
src/styles.css 0ms
[main aeba2e0] update pre-commit hook
 1 file changed, 2 insertions(+)

git commitをするとリントに続いてフォーマットが行われていることが確認できます。

リントおよびフォーマットの対象を限定する

現在は非常にコードが少ないためリントやフォーマットの時間がそれほどかかりません。ただ、実際のプロジェクトでは非常にたくさんのコードがある場合もあります。そのような場合、リントやフォーマットに時間がかかるだけでなく、対応した範囲とは関係ない箇所でエラーになってしまい、コミットがいつまでもできない、ということが起きることは容易に想像できます。

こういった問題を解決する一つの方法として、lint-stagedを導入します。

lint-stagedをインストール

普通のパッケージと同じようにインストールしていきます。

$ npm install --save-dev lint-staged

added 37 packages, and audited 1135 packages in 3s

180 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

lint-stagedを設定する

lint-stagedを設定していきます。まずはHuskyがpre-commitフックで実行するコマンドをnpx lint-stagedに変更します。

$ npx husky set .husky/pre-commit "npx lint-staged"
husky - created .husky/pre-commit

次にlint-stagedでnpm run lintコマンドとnpm run formatを実行するようにします。

{
  "name": "angular-tutorial",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test",
    "lint": "ng lint",
    "format": "prettier \"src/**/*.{js,jsx,ts,tsx,html,css,scss}\" --write"
  },
+ "lint-staged": {
+   "*.{js,jsx,ts,tsx}": [
+     "npm run lint"
+   ],
+   "*.{js,jsx,ts,tsx,html,css,scss}": [
+     "npm run format"
+   ]
+ },
  "private": true,
  "dependencies": {
    "@angular/animations": "^16.1.0",
    "@angular/common": "^16.1.0",
    "@angular/compiler": "^16.1.0",
    "@angular/core": "^16.1.0",
    "@angular/forms": "^16.1.0",
    "@angular/platform-browser": "^16.1.0",
    "@angular/platform-browser-dynamic": "^16.1.0",
    "@angular/router": "^16.1.0",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "zone.js": "~0.13.0"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^16.1.6",
    "@angular-eslint/builder": "16.1.0",
    "@angular-eslint/eslint-plugin": "16.1.0",
    "@angular-eslint/eslint-plugin-template": "16.1.0",
    "@angular-eslint/schematics": "16.1.0",
    "@angular-eslint/template-parser": "16.1.0",
    "@angular/cli": "~16.1.6",
    "@angular/compiler-cli": "^16.1.0",
    "@types/jasmine": "~4.3.0",
    "@typescript-eslint/eslint-plugin": "5.62.0",
    "@typescript-eslint/parser": "5.62.0",
    "eslint": "^8.44.0",
    "eslint-config-prettier": "^8.9.0",
    "husky": "^8.0.3",
    "jasmine-core": "~4.6.0",
    "karma": "~6.4.0",
    "karma-chrome-launcher": "~3.2.0",
    "karma-coverage": "~2.2.0",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.1.0",
    "lint-staged": "^13.2.3",
    "prettier": "^3.0.0",
    "typescript": "~5.1.3"
  }
}

"lint-staged"がコマンドの設定を行っている箇所です。リントとフォーマットで対象としたいファイルが異なるため分けて設定しています。

pre-commitフックを確認するまえに、npx lint-stagedコマンドを実行して動作を確認してみましょう。

$ npx lint-staged
→ No staged files found.

ステージされているファイルが何もないため、処理が行われませんでした。

では、現在変更されているコードをステージしてから実行してみましょう。

$ npx lint-staged
→ No staged files match any configured task.

少しメッセージが変わりました。ステージされているファイルはありましたが、条件にマッチするファイルがなかったため、処理が行われませんでした。

では、1つだけ処理対象となるファイルを変更してステージして動作を確認してみましょう。

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
  title = 'angular-tutorial';
}

app.component.tsを以下のように変更します。

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css'],
})
export class AppComponent {
* title = 'angular-tutorial1';
}

titleをちょっとだけ変更しています。

変更をステージして実行してみます。

$ git add .
$ npx lint-staged
✔ Preparing lint-staged...
❯ Running tasks for staged files...
  ❯ package.json — 4 files
    ❯ *.{js,jsx,ts,tsx} — 1 file
      ✖ npm run lint [FAILED]
    ✔ *.{js,jsx,ts,tsx,html,css,scss} — 1 file
↓ Skipped because of errors from tasks. [SKIPPED]
✔ Reverting to original state because of errors...
✔ Cleaning up temporary files...

✖ npm run lint:
Error: Invalid values:
  Argument: project, Given: "/Users/t0k0sh1/Workspace/angular-tutorial/src/app/app.component.ts", Choices: "angular-tutorial"

> angular-tutorial@0.0.0 lint
> ng lint /Users/t0k0sh1/Workspace/angular-tutorial/src/app/app.component.ts 

実行したところエラーになりました。

結論からいうと、lint-stagedに指定したコマンドが原因です。リントを行うためにeslintを使用しているのではなく、ng lintを使用しています。

ng lintはプロジェクト全体に対して実行するコマンドのため、ステージしたファイルに対して限定的に使用することができません。ですので、少しコマンドを変更します。

{
  "name": "angular-tutorial",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test",
    "lint": "ng lint",
    "format": "prettier \"src/**/*.{js,jsx,ts,tsx,html,css,scss}\" --write"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
*     "eslint --fix"
    ],
    "*.{js,jsx,ts,tsx,html,css,scss}": [
      "npm run format"
    ]
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "^16.1.0",
    "@angular/common": "^16.1.0",
    "@angular/compiler": "^16.1.0",
    "@angular/core": "^16.1.0",
    "@angular/forms": "^16.1.0",
    "@angular/platform-browser": "^16.1.0",
    "@angular/platform-browser-dynamic": "^16.1.0",
    "@angular/router": "^16.1.0",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "zone.js": "~0.13.0"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^16.1.6",
    "@angular-eslint/builder": "16.1.0",
    "@angular-eslint/eslint-plugin": "16.1.0",
    "@angular-eslint/eslint-plugin-template": "16.1.0",
    "@angular-eslint/schematics": "16.1.0",
    "@angular-eslint/template-parser": "16.1.0",
    "@angular/cli": "~16.1.6",
    "@angular/compiler-cli": "^16.1.0",
    "@types/jasmine": "~4.3.0",
    "@typescript-eslint/eslint-plugin": "5.62.0",
    "@typescript-eslint/parser": "5.62.0",
    "eslint": "^8.44.0",
    "eslint-config-prettier": "^8.9.0",
    "husky": "^8.0.3",
    "jasmine-core": "~4.6.0",
    "karma": "~6.4.0",
    "karma-chrome-launcher": "~3.2.0",
    "karma-coverage": "~2.2.0",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.1.0",
    "lint-staged": "^13.2.3",
    "prettier": "^3.0.0",
    "typescript": "~5.1.3"
  }
}

実行するコマンドをnpm run lintからeslint --fixに変更しました。変更したついでに--fixオプションをつけて修正もできるようにしてあります。

再度実行してみましょう。

$ npx lint-staged
✔ Preparing lint-staged...
✔ Hiding unstaged changes to partially staged files...
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Restoring unstaged changes to partially staged files...
✔ Cleaning up temporary files...

今度はすべて成功しています。

最後にコードを整理してコミット&プッシュ

app.component.tsに加えた変更は不要なので、戻しておきます。

$ git restore --staged src/app/app.component.ts
$ git checkout -- src/app/app.component.ts

それ以外の変更は正式に採用するので、ステージしてコミットし、これまでの変更も含めてプッシュしておきます。

$ git add .
$ git commit -m 'set up husky and lint-staged'
→ No staged files match any configured task.
[main 58ad1f8] set up husky and lint-staged
 3 files changed, 504 insertions(+), 3 deletions(-)
$ git push
Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 10 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (16/16), 5.23 KiB | 892.00 KiB/s, done.
Total 16 (delta 7), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (7/7), completed with 3 local objects.
To github.com:t0k0sh1/angular-tutorial.git
   f20d6df..58ad1f8  main -> main

まとめ

少し長くなりましたが、Huskyとlint-stagedを導入してリントとフォーマットをpre-commitフックで実行できるようになりました。

もう少し設定が必要ですが、それは必要になったときに設定することとします。

開発を行う前に結構時間がかかりましたが、こういった設定は最初の段階で整備しておいた方がよいです。開発途中で導入しようとすると、これまでの分の修正に追われ、本来やるべきことに集中できなくなりますので、最初に説明しました。

次回はTailwind CSSを導入してコンポーネントを作成してみたいと思います。

AngularプロジェクトにPrettierとESLintを導入する

AngularプロジェクトではPrettierとESLintは最初から導入されてはいません。プロジェクト作成後にセットアップすることで利用可能となります。

実際のプロジェクトではPrettierとESLintは導入した方がよいので、実際にセットアップしていきます。

ESLintを導入する

Angular CLIにはng lintというコマンドが用意されています。プロジェクト作成直後はESLintが導入されていないため、lintの実行の代わりにELintのインストールを行うことができます。実際にやってみましょう。

$ ng lint
? Would you like to share pseudonymous usage data about this project with the Angular Team
at Google under Google's Privacy Policy at https://policies.google.com/privacy. For more
details and how to change this setting, see https://angular.io/analytics. No
Global setting: enabled
Local setting: disabled
Effective status: disabled
Cannot find "lint" target for the specified project.
You can add a package that implements these capabilities.

For example:
  ESLint: ng add @angular-eslint/schematics

Would you like to add ESLint now? Yes
ℹ Using package manager: npm
✔ Found compatible package version: @angular-eslint/schematics@16.1.0.
✔ Package information loaded.

The package @angular-eslint/schematics@16.1.0 will be installed and executed.
Would you like to proceed? Yes
✔ Packages successfully installed.
    
    All @angular-eslint dependencies have been successfully installed 🎉
    
    Please see https://github.com/angular-eslint/angular-eslint for how to add ESLint configuration to your project.
    
    We detected that you have a single project in your workspace and no existing linter wired up, so we are configuring ESLint for you automatically.
    
    Please see https://github.com/angular-eslint/angular-eslint for more information.
    
CREATE .eslintrc.json (991 bytes)
UPDATE package.json (1424 bytes)
UPDATE angular.json (3085 bytes)
✔ Packages installed successfully.

一番最初の質問はAngular CLIの使用状況データを提供するかどうかを聞いています。その後に@angular-eslint/schematicsのインストールを行うかの確認があります。基本的にはデフォルトのまま進めていただいて構いません。

インストールが完了すると、以下が行われます。

  • AngularプロジェクトでESLintを使用する基本的なパッケージがインストールされる
  • lintを実行するためのスクリプトがpackage.jsonに追加される
  • ESLintの設定ファイル(.eslintrc.json)が追加される
  • angular.jsonにESLintに関する設定が追加される

これでlintが使用可能になります。実際に使ってみましょう。

$ ng lint

Linting "angular-tutorial"...

All files pass linting.

ESLint拡張機能を導入する

Visual Studio Codeを使用している場合は、ESLint拡張機能を導入するとリアルタイムに違反をチェックできるようになりますので、導入をお勧めします。

拡張機能にはいくつか設定項目がありますが、特に設定変更しなくても動作します。

Prettierを導入する

次にPrettierを導入します。こちらはAngular CLIに専用のコマンドが用意されているわけではないため、インストールおよび設定作業は手動で行います。

Prettierをインストールしますが、先にインストールしたESLintと競合した設定が一部あるため、eslint-config-prettierを併せてインストールします。

$ npm install --save-dev prettier eslint-config-prettier

added 2 packages, and audited 1097 packages in 4s

164 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

これでインストール作業が完了しました。続いて設定作業を行います。

ESLintとPrettierを併用できるようにする設定を追加する

.eslintrc.jsonにPrettierを併用できるようにするための設定を追加します。

{
  "root": true,
  "ignorePatterns": ["projects/**/*"],
  "overrides": [
    {
      "files": ["*.ts"],
      "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@angular-eslint/recommended",
        "plugin:@angular-eslint/template/process-inline-templates",
+       "prettier"
      ],
      "rules": {
        "@angular-eslint/directive-selector": [
          "error",
          {
            "type": "attribute",
            "prefix": "app",
            "style": "camelCase"
          }
        ],
        "@angular-eslint/component-selector": [
          "error",
          {
            "type": "element",
            "prefix": "app",
            "style": "kebab-case"
          }
        ]
      }
    },
    {
      "files": ["*.html"],
      "extends": [
        "plugin:@angular-eslint/template/recommended",
        "plugin:@angular-eslint/template/accessibility"
      ],
      "rules": {}
    }
  ]
}

"prettier"を追記します。前の行にカンマをつけるのを忘れないように気をつけてください。

.prettierrc.jsonを作成する

Prettierの設定ファイルである.prettier.jsonを作成します。

$ touch .prettierrc.json

ファイルを作成したら以下のように記述します。

{
  "printWidth": 120,
  "singleQuote": true
}

ここでは1行の文字数を120文字、文字列でシングルクォーテーションを使用するように設定しています。シングルクォーテーションを使用する設定はEditorConfigの設定ファイル.editorconfigに記載されている

[*.ts]
quote_type = single

と一致するように設定してください。ダブルクォーテーションを使用したい場合は、.prettierrc.jsonの設定を"singleQuote": falseにし、.editorconfigの設定をquote_type = doubleに変更します。ただし、Angularプロジェクトを作成したときに自動生成されているコードはシングルクォーテーションを使用しているため、特段理由がなければシングルクォーテーションを使用してください。

コマンドでフォーマットできるようにする

package.jsonを編集してコマンドでフォーマットできるようにしましょう。

{
  "name": "angular-tutorial",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "watch": "ng build --watch --configuration development",
    "test": "ng test",
    "lint": "ng lint",
+   "format": "prettier \"src/**/*.{js,jsx,ts,tsx,html,css,scss}\" --write"
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "^16.1.0",
    "@angular/common": "^16.1.0",
    "@angular/compiler": "^16.1.0",
    "@angular/core": "^16.1.0",
    "@angular/forms": "^16.1.0",
    "@angular/platform-browser": "^16.1.0",
    "@angular/platform-browser-dynamic": "^16.1.0",
    "@angular/router": "^16.1.0",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "zone.js": "~0.13.0"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "^16.1.6",
    "@angular-eslint/builder": "16.1.0",
    "@angular-eslint/eslint-plugin": "16.1.0",
    "@angular-eslint/eslint-plugin-template": "16.1.0",
    "@angular-eslint/schematics": "16.1.0",
    "@angular-eslint/template-parser": "16.1.0",
    "@angular/cli": "~16.1.6",
    "@angular/compiler-cli": "^16.1.0",
    "@types/jasmine": "~4.3.0",
    "@typescript-eslint/eslint-plugin": "5.62.0",
    "@typescript-eslint/parser": "5.62.0",
    "eslint": "^8.44.0",
    "eslint-config-prettier": "^8.9.0",
    "jasmine-core": "~4.6.0",
    "karma": "~6.4.0",
    "karma-chrome-launcher": "~3.2.0",
    "karma-coverage": "~2.2.0",
    "karma-jasmine": "~5.1.0",
    "karma-jasmine-html-reporter": "~2.1.0",
    "prettier": "^3.0.0",
    "typescript": "~5.1.3"
  }
}

コマンド名は何でも構いませんが、ここではnpm run formatで実行できるようにしています。

これから動作確認のためにコマンドを実行しますが、実行するといくつかのファイルが変更されます。変更したくない場合は記事を読むだけにしてください。

$ npm run format

> angular-tutorial@0.0.0 format
> prettier "src/**/*.{js,jsx,ts,tsx,html,css,scss}" --write

src/app/app.component.css 9ms
src/app/app.component.html 84ms
src/app/app.component.spec.ts 72ms
src/app/app.component.ts 3ms
src/app/app.module.ts 3ms
src/index.html 1ms
src/main.ts 2ms
src/styles.css 1ms

実行するといくつかのファイルについて変更されたことが表示されます。

Prettier – Code formatter拡張機能を導入する

Visual Studio Codeを使用している場合はPrettier – Code formatter拡張機能を導入することで、コードフォーマットを自動化することができます。

こちらは拡張機能導入後にいくつかの設定を行う必要があります。主な設定項目は以下の3つです。

  • Format On Paste
  • Format On Save
  • Default Formatter

他からコピーしたコードをペーストしたときにフォーマットする場合はFormat On Pasteの設定にチェックを入れてください。これは好みかもしれませんが、ペースト後に少しいじってから保存することがほとんどなので私はチェックを入れていません。

次に保存時にフォーマットを行うようにすることでコードフォーマットを自動化できます。基本的にはチェックを入れていただくとよいのですが、自動フォーマットを有効化していると操作性が気になる場合があるかもしれません。実際に試していただいて好みに合うように調整してください。

デフォルトのフォーマッタをPrettierに変更します。これによりPrettierが有効化します。一つだけ注意点があり、PrettierはPythonには対応していません。そのため、Pythonでの開発もVisual Studio Codeで行う場合は、デフォルトのフォーマッタをPrettierに変更した上で、settings.jsonに以下の記述を追加してください。

  "[python]": {
    "editor.defaultFormatter": null,
  },

これにより.pyファイルではPrettierをフォーマッタとして使用しなくなります。少し脱線しますが、blackをフォーマッタとして使用している場合は、

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "python.formatting.provider": "black",
  "[python]": {
    "editor.defaultFormatter": null,
  },
}

のような記載になります。

変更をコミットする

前回からずっとコミットしていなかったので、ここまでの変更をコミットしておきます。

$ git add .
$ git commit -m 'install eslint and prettier'
[main f20d6df] install eslint and prettier
 11 files changed, 3137 insertions(+), 327 deletions(-)
 create mode 100644 .eslintrc.json
 create mode 100644 .prettierrc.json

本記事で使用しているプロジェクトは以下にありますので、必要に応じて参考にしてみてください。

まとめ

ちょっと長くなったので今回はここまでにします。次回はHuskyを使ってpre-commitフックでESLintとPrettierを自動実行するようにしたいと思います。

ただし、若干のトレードオフがあるため、その点についても解説します。

モバイルバージョンを終了