単純に、qemu-user-staticをインストールして実行しようとすると、次のようなエラーが出る。

sudo apt-get update
sudo apt-get install qemu-user-static

qemu-aarch64-static bin

/lib/ld-linux-aarch64.so.1: No such file or directory

これはaarch64向けのlibcないために起こるためで、このunix.stackexchange.comにある通りarm64のアークテクチャを追加して、libc6:arm6をインストールすればよい。

ただし、ただ追加してapt-get updateしても404エラーが出る。

sudo dpkg --add-architecture arm64

sudo apt-get update

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-updates/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.83 80]
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-backports/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

これはそのままlibc6:arm6がリポジトリに見つからないことを指すエラーなので、このaskubuntu.comにある通り、ソースを追加すると解決できる。

つまり例えば、/etc/apt/sources.list.d/arm64.listを作成して、次のように記述する。

deb [arch=arm64] http://ports.ubuntu.com/ focal main restricted
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ focal universe
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates universe
deb [arch=arm64] http://ports.ubuntu.com/ focal multiverse
deb [arch=arm64] http://ports.ubuntu.com/ focal-updates multiverse
deb [arch=arm64] http://ports.ubuntu.com/ focal-backports main restricted universe multiverse

これをコマンドで行う場合は例えばこう。

UBUNTU=$(lsb_release -cs)

sudo tee /etc/apt/sources.list.d/arm64.list <<EOF
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU main restricted
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU universe
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates universe
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU multiverse
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates multiverse
deb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-backports main restricted universe multiverse
EOF

加えて、デフォルトの/etc/apt/sources.listを現在のアーキテクチャ専用に書き換えておく必要がある。

# 念の為バックアップ
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

# 例えばamd64
ARCH=$(dpkg --print-architecture)

# 置換
sudo sed -i "s/deb /deb [arch=$ARCH] /g" /etc/apt/sources.list

これで、libc6:arm6をインストールでき、qemu-aarch64-staticによるaarch64バイナリの実行が可能になるはず。

sudo apt-get install libc6:arm6

qemu-aarch64-static bin

error: linker `i686-w64-mingw32-gcc` not found
  |
  = note: program not found

原因は、ターゲットを追加してもコンパイルに必要なrust-mingwというコンポーネントがインストールされないこと（rust-lang/rustup#607）だったので、インストールのコマンドを次のようにすることで解決した。

rustup toolchain install stable-i686-pc-windows-gnu
rustup default stable-i686-pc-windows-gnu

• https://doc.rust-lang.org/cargo/guide/build-cache.html

デフォルトでは、targetディレクトリはプロジェクトのルートディレクトリ、すなわち（ワークスペースであればワークスペースの）Cargo.tomlがあるディレクトリに作成されるが、複数のプロジェクトで多くの同じパッケージを依存関係として持つ場合、同じものをプロジェクトごとにビルドすることになるため、ビルド時間的にもディスク容量的にもかなりの重複が生じることになる。

project-a/target/...
project-b/target/...
project-c/target/...

より高度な方法として、sccacheのようなツールを使うこともできるが、単純な方法として、Cargoの設定でtargetディレクトリに同じディレクトリを使うように指定することができる。

• https://doc.rust-lang.org/cargo/reference/config.html#buildtarget-dir

環境変数CARGO_TARGET_DIRを設定したり、

export CARGO_TARGET_DIR="/path/to/shared/target"

$CARGO_HOME/config.tomlにbuild.target-dirを設定したり、

[build]
target-dir = "/path/to/shared/target"

といった方法があるが、実はこれらより先に、現在のディレクトリ以上にある.cargo/config.tomlを下から上へと再帰的に読んでくれるという仕組みがあるので、これを使うと、プロジェクトごとだったり、親ディレクトリごとだったりに、targetディレクトリを指定することもできる。

• https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

.cargo/config.tomlの相対パスは、.cargoのあるディレクトリを基準として解釈される。

• https://doc.rust-lang.org/cargo/reference/config.html#config-relative-paths

なので、例えば次のような.cargo/config.tomlを作成することで、そのディレクトリ以下のすべてのプロジェクトで同じtargetディレクトリ（.cargo/target）を使うようにできる。

[build]
target-dir = ".cargo/target"

.cargo/config.toml
.cargo/target/...
project-a/
project-b/
project-c/

その際、あるプロジェクトだけ例外として扱いたい場合は、現在のディレクトリを含めてより近いディレクトリにある.cargo/config.tomlが優先されるので、そのプロジェクトのディレクトリに次のような.cargo/config.tomlを作成して、targetディレクトリを指定すれば良い。

[build]
target-dir = "target"

例えば、project-cにこのファイルを追加した場合、project-cのビルド結果はproject-c/targetに出力されるようになる。

.cargo/config.toml
.cargo/target/...
project-a/
project-b/
project-c/.cargo/config.toml
project-c/target/...

このような使い方をする場合、.gitignore_globalなどに.cargo/config.tomlを追加しておくと良いかもしれない。

.cargo/config.toml

ただし、その場合は逆にtargetディレクトリを.gitignoreに追加することを忘れないようにしなければならないだろう。

/target

依存関係には、@swc/coreとswc-loaderを追加する。

# npm
npm install -D @swc/core swc-loader
# yarn
yarn add -D @swc/core swc-loader
# pnpm
pnpm add -D @swc/core swc-loader

あとは、ts-loaderの代わりにswc-loaderを使うように設定する。

webpack.config.js:

module.exports = {
    module: {
        rules: [
            {
                test: /\.([jt]sx?)?$/,
                exclude: /node_modules/,
                use: {
                    loader: "swc-loader",
                    // https://swc.rs/docs/configuration/compilation
                    options: {
                        jsc: {
                            parser: {
                                syntax: "typescript",
                                tsx: true,
                            },
                        },
                    },
                },
            },
        ],
    },
};

設定にはoptionsを使ってもいいが、.swcrcを使っても良い。

webpack.config.js:

module.exports = {
    module: {
        rules: [
            {
                test: /\.([jt]sx?)?$/,
                exclude: /node_modules/,
                use: "swc-loader",
            },
        ],
    },
};

.swcrc:

{
    "jsc": {
        "parser": {
            "syntax": "typescript",
            "tsx": true
        }
    }
}

特に、Node.jsが既にインストールされている環境であれば、npxやdlxを使って環境を汚さずその場でサーバーを立てることができる。

# npm
npx serve
# yarn
yarn dlx serve
# pnpm
pnpm dlx serve

もちろん依存関係に追加して、package.jsonのscriptsに追加するなどしても良い。

# npm
npm install -D serve
# yarn
yarn add -D serve
# pnpm
pnpm add -D serve

{
    "scripts": {
        "serve": "serve"
    }
}

グローバルインストールするならこう。

# npm
npm install -g serve
# yarn
yarn global add serve
# pnpm
pnpm add -g serve

コマンドラインオプションは、-h（--help）で確認できる。

serve -h
serve --help

ディレクトリを指定する場合は、引数に指定する。デフォルトはカレントディレクトリ。

serve public

ポートを指定する場合は、-pまたは-l（--listen、より複雑な指定が可能）を使う。デフォルトは3000。

serve -p 8080
serve -l 8080

serve.jsonを使って設定を行うこともできる。プロパティの詳細は、https://github.com/vercel/serve-handler#options を参照。

公開ディレクトリを指定する場合は、publicプロパティを使う。

{
    "public": "public"
}

export {};
    ^^^^^^

    SyntaxError: Unexpected token 'export'

よく見ると、ビルド後のJavaScriptファイル（ここではdist内にあるとする）がテストファイルとして認識されていたことが原因だったので、jest.config.jsに次のような設定を追加した。

module.exports = {
    // 追加:
    testPathIgnorePatterns: ["<rootDir>/node_modules/", "<rootDir>/dist/"],
    // デフォルト:
    // testPathIgnorePatterns: ["/node_modules/"],
}

testPathIgnorePatternsには、ファイルのフルパスに対してマッチされる正規表現を文字列で指定するようになっている。<rootDir>はプロジェクトのルートディレクトリに置き換えられる。

特定のディレクトリのみからテストファイルを探させたい場合はrootsを使うこともできる。ただし、そのディレクトリが存在しない場合はエラーが出るようなので注意が必要。

module.exports = {
    // 追加:
    roots: ["<rootDir>/src/", "<rootDir>/tests/"],
    // デフォルト:
    // roots: ["<rootDir>"],
}

• 公式サイト: https://jestjs.io
• リポジトリ: https://github.com/facebook/jest
• ドキュメンテーション: https://jestjs.io/docs/getting-started
  • API（グローバル）: https://jestjs.io/docs/api
  • API（expect）: https://jestjs.io/docs/expect
  • 設定: https://jestjs.io/docs/configuration
  • CLI: https://jestjs.io/docs/cli

ドラッグ&ドロップによるアップロードもできるが、

• https://developers.cloudflare.com/pages/platform/direct-upload/#drag-and-drop

ここではWranglerを使った方法を紹介する。

• https://developers.cloudflare.com/pages/platform/direct-upload/#wrangler-cli

Wrangler

現在のバージョンは、

wrangler --version

2.0.9

もしWrangler 1を使っている場合は、Wrangler 2に移行する必要がある。

# Wrangler 1
npm uninstall -g @cloudflare/wrangler
# Wrangler 2
npm install -g wrangler

• https://developers.cloudflare.com/workers/wrangler/migration/migrating-from-wrangler-1/

アップロード

アップロードは次のコマンドで行う。

wrangler pages publish [DIRECTORY] [OPTIONS]

distディレクトリをアップロードしたい場合は、

wrangler pages publish dist

新しくデプロイする場合は、プロンプトでまずプロジェクトを作成することになる。

既存のプロジェクト名を指定したい場合は、

wrangler pages publish dist --project-name my-project

プロジェクト

既存のプロジェクトを確認するには、

wrangler pages project list

プロジェクトを作成するには、

wrangler pages project create [PROJECT-NAME] [OPTIONS]

例えばmy-projectという名前のプロジェクトを作成するには、

wrangler pages project create my-project

さらにプロダクション用のブランチ名を指定するには、

wrangler pages project create my-project --production-branch main

参考リンク

• https://developers.cloudflare.com/workers/wrangler/commands/#pages
• https://developers.cloudflare.com/pages/platform/direct-upload/
• https://blog.cloudflare.com/cloudflare-pages-direct-uploads/

調べてみると仮想ワークスペースではパッケージのようにエディションを指定しないので、依存関係の解決アルゴリズムに古いバージョンのものがデフォルトで使われてしまうことが原因のようで、resolver = "2"を指定すると解決した。

[workspace]
members = ["crates/*"]
resolver = "2"

• https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions

なお解決したあとで検索してみるとBevyの非公式チートブックにもよくある落とし穴としてしっかり記載されていた。

• https://bevy-cheatbook.github.io/pitfalls/build-errors.html#multi-crate-workspaces

(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function

原因はどうやらMDX 2を使っていたことのようだったので、

• https://storybook.js.org/docs/react/writing-docs/mdx#mdx-2

に書かれている通り、

npm install @storybook/mdx2-csf --save-dev

.storybook/main.js:

module.exports = {
    // ...
    features: {
        previewMdx2: true,
    },
}

を追加すると解決した。

• 公式サイト: https://storybook.js.org
• リポジトリ: https://github.com/storybookjs/storybook/

ffmpeg -i video.mov video.gif

フレームレートは-rで、サイズは-vf scale=で指定できる。-1はアスペクト比を保つという意味。

ffmpeg -i video.mov -r 30 -vf scale=1280:-1 video.gif

• 公式サイト: https://ffmpeg.org

• https://www.netlify.com

ブラウザ（各種メニューの「手動デプロイ」、Netlify Drop）からデプロイすることもできるが、ここではNetlify CLIを使う。

• https://github.com/netlify/cli/

インストール

今回はCI環境では使わないので、グローバルインストールする。

npm install netlify-cli -g

もしCI環境でもNetlify CLIを使うのであれば、開発依存パッケージとしてインストールする。（ビルドには別のCIサービスを使い、デプロイ先だけNetlifyにしたいような場合に便利。）

npm install --save-dev netlify-cli

コマンドが実行できるかを確認するには次を実行する。

netlify

ログイン

現在の環境でログインするには次を実行する。実行するとブラウザが開く。

netlify login

ログイン情報はユーザーディレクトリ以下の次の場所にあるconfig.jsonに保存される。

• macOS: Library/Preferences/netlify/config.json
• Linux: .config/netlify/config.json
• Windows: AppData\Roaming\netlify\Config\config.json

なおアカウントを切り替えるには次を実行する。

netlify switch

デプロイ

デプロイにはnetlify deployコマンドを使う。

netlify deploy

何もなしで実行するとカレントディレクトリの中身全てをそのままプレビュー環境にデプロイすることになる。ちなみに初回実行時はディレクトリとサイトが結び付けられていないので、コマンドライン上のプロンプトでサイトを作成または選択することになる。

多くの場合プロジェクトのルートディレクトリにカレントディレクトリがあり、その下にあるビルドディレクトリをアップロードすることになると思う。そのような場合、--dirオプションと使うとアップロードするディレクトリを指定できる。例えばビルドディレクトリがカレントディレクトリの./distにあるとすると次のようになる。

netlify deploy --dir=dist

上記を実行してもデプロイ先はプレビュー環境になる。本番環境にデプロイし公開したい場合は--prodオプションをつける。

netlify deploy --dir=dist --prod

もちろんカレントディレクトリの中身全てを公開したい場合は、--dirを省けばよい。

netlify deploy --prod

既存のサイトに対して手動デプロイを行う場合は、--siteオプションでサイト名またはサイトIDを指定してアップロードすることもできる。

netlify deploy --dir=dist --site=my-site --prod

既存のサイトの一覧は次のコマンドで確認できる。

netlify sites:list

既存サイトとのリンク

サイトの設定はディレクトリ内の.netlify/state.jsonに保持される。

サイトとディレクトリを結び付けるには次を実行する。

netlify link

上記のように何もオプションを指定しないと、プロンプトでサイトを選択することになる。

サイト名を使って結び付けたい場合は、次のように--nameオプションを使用する。

netlify link --name my-site

なお先述の通り、既存サイトの一覧は次のコマンドで確認できる。

netlify sites:list

逆にリンクを解除したい場合は、次を実行する。

netlify unlink

新規サイトの作成

新しくサイトを作成してディレクトリとリンクするには、次のコマンドを実行する。

netlify sites:create

サイト名を指定して作成するには、--nameオプションを使用する。

netlify sites:create --name my-site

参考リンク

• https://github.com/netlify/cli/
• https://docs.netlify.com/cli/get-started/
• https://cli.netlify.com

変更履歴

2022-06-12

• Cloudflare Pagesでも「ダイレクトアップロード」ができるようになっていたので、できないとしていた記述を改訂。

• 公式サイト: https://www.netlify.com
• Netlify CLI: https://cli.netlify.com
• Netlify Docs: https://docs.netlify.com

これはMayaやGodot、Minecraftなどとは同じだが、UnityとはZ軸の正負が逆となっている。

参考リンク

• https://github.com/bevyengine/bevy/discussions/1979
• https://github.com/bevyengine/bevy/blob/main/crates/bevy_transform/src/components/transform.rs
• https://docs.rs/bevy/latest/bevy/transform/components/struct.Transform.html
• https://bevy-cheatbook.github.io/features/coords.html

• 公式サイト: https://bevyengine.org
• 公式ブック: https://bevyengine.org/learn/book/
• リポジトリ: https://github.com/bevyengine/bevy
• docs.rs: https://docs.rs/bevy/latest/bevy/
• チートブック: https://bevy-cheatbook.github.io/

仕組みとしては、ローカルサーバーでホストした拡張機能をlocaltunnelを使ってグローバルにアクセスできるようにし、それをvscode.devのDeveloper: Install Web Extensionコマンドによってサイドロードする、という流れになっている。

なお、localtunnelによるトンネリングに使うサーバーにはデフォルトでhttps://localtunnel.meが使われるようになっているが、自前でホストすることも可能。もちろんトンネリングには別のツールを使ってもいいのだが、VS Codeの公式ドキュメントで紹介されていたので、ここではそのままlocaltunnelを使うことにする。

方法

ローカルサーバーのポート番号としてここでは8080を使うことにする。

まずターミナルを一つ開いてローカルサーバーを立ち上げ拡張機能をホストする（ビルドが必要な場合あらかじめビルドしておく）:

npx serve --cors -l 8080

次に別のターミナルを開いてトンネリングを開始する:

npx localtunnel -p 8080

ここで発行される次のようなURLをコピーしてメモしておく:

your url is: https://hungry-mole-48.loca.lt/

まずURLブラウザでこのURLを開き、そこで表示される

Click to Continue

という青いボタンを、注意を読んだ上で押す。

あとはvscode.devのコマンドパレットから:

Developer: Install Web Extension...

を実行し、発行されたURLを入力欄にペーストしてEnterすると、拡張機能の読み込みが実行される。

参考リンク

• 公式ドキュメント: Web Extensions - Test your web extension in on vscode.dev
  • https://code.visualstudio.com/api/extension-guides/web-extensions#test-your-web-extension-in-on-vscode.dev

• 公式サイト: https://code.visualstudio.com/
• リポジトリ: https://github.com/microsoft/vscode

• 公式ドキュメンテーション: https://code.visualstudio.com/api

ECMAScript（現行: 2023）では、反復処理（iteration）のためのインターフェースとして、

• Iterable
• Iterator
• AsyncIterable
• AsyncIterator
• IteratorResult

の5つが定義されている。

Iterable

Iterableは、Iteratorにしたがうオブジェクトを返す関数@@iterator（Symbol.iterator）をプロパティとして必ず持つことを示すインターフェースである。

TypeScriptではそのまま次のように定義されている。

src/lib/es2015.iterable.d.ts#L30-L32

interface Iterable<T> {
    [Symbol.iterator](): Iterator<T>;
}

※引用するコードにもともとあったコメントは省略してある。以下同様。

この@@iteratorは、for...of文、yield*式、...演算子などを使った際にも暗黙的に呼ばれる（抽象操作GetIteratorを参照）。

for (const item of [1, 2, 3, 4]) {
    console.log(item)
}

AsyncIterable

AsyncIterableは、Iterableの非同期版で、AsyncIteratorにしたがうオブジェクトを返す関数@@asyncIterator（Symbol.asyncIterator）をプロパティとして必ず持つことを示すインターフェースである。

こちらもTypeScriptではそのまま次のように定義されている。

src/lib/es2018.asynciterable.d.ts#L19-L21

interface AsyncIterable<T> {
    [Symbol.asyncIterator](): AsyncIterator<T>;
}

この@@asyncIteratorも、for await...of文、yield*式、などを使った際に暗黙的に呼ばれうる（同じく抽象操作GetIteratorを参照）。

Iterator

Iteratorは、IteratorResultを返す関数nextをプロパティとして必ず持ち、オプションとして同じくIteratorResultを返す関数return、throwを持つことを示すインターフェースとなっている。

TypeScriptでの定義は次のようになっている。

src/lib/es2015.iterable.d.ts#L23-L28

interface Iterator<T, TReturn = any, TNext = undefined> {
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return?(value?: TReturn): IteratorResult<T, TReturn>;
    throw?(e?: any): IteratorResult<T, TReturn>;
}

反復はnextを呼ぶことによって進められる。nextは引数を任意で1つとり、IteratorResultを返す。ECMAScriptの仕様には、一度doneがtrueのIteratorResultが返されたら、それ以降返されるIteratorResultのdoneはすべてtrueであるべき旨が書かれているが、一方でこの要求は強制的なものではないとも書かれている。

またECMAScriptの仕様には、Iteratorはnextが引数なしで呼ばれることもあることを前提としなければならない旨の注釈も付け加えられてある。TypeScriptでのnextの引数がタプルで表現されているのはそのチェックを厳密にするためであると思われる（省略したソースコード中のコメントにそのような旨が記載されている）。

returnとthrowはそれぞれIteratorに反復処理の終了やエラーによる中断を知らせるためのもので、ECMAScriptの仕様では、典型的な振る舞いはvalueで指定した値をvalueとして持つIteratorResultを返したり、eで指定した値をthrowしたりして、以降のIteratorResultのdoneをtrueにすることであるが、実際の振る舞いはIteratorがどのように実装されているかに依存するとされている。

AsyncIterator

AsyncIteratorは、Iteratorの非同期版で、プロパティとしてもつ関数がすべて、IteratorResultの代わりにIteratorResultのPromiseを返すインターフェスである。

TypeScriptでの定義は次のようになっている。

src/lib/es2018.asynciterable.d.ts#L12-L17

interface AsyncIterator<T, TReturn = any, TNext = undefined> {
    next(...args: [] | [TNext]): Promise<IteratorResult<T, TReturn>>;
    return?(value?: TReturn | PromiseLike<TReturn>): Promise<IteratorResult<T, TReturn>>;
    throw?(e?: any): Promise<IteratorResult<T, TReturn>>;
}

IteratorResult

イテレーターから返されるIteratorResultは、doneとvalueの二つの値をプロパティーとして持ちうるインターフェースである。doneはtrueまたはfalse、valueは任意のECMAScriptの値をとるが、存在しない可能性もある。

doneがfalseまたは存在しない場合、valueの値は反復の一要素として解釈される。一方、doneがtrueである場合、それは反復の終了を意味し、そのときのvalueはイテレーター自体の返却値として解釈される。

これをTypeScriptでは次のように表現している。

src/lib/es2015.iterable.d.ts#L11-L21

interface IteratorYieldResult<TYield> {
    done?: false;
    value: TYield;
}

interface IteratorReturnResult<TReturn> {
    done: true;
    value: TReturn;
}

type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;

組み込みの反復可能オブジェクト

ECMAScriptで定義されている次の組み込みオブジェクトはIterableインターフェースを満たしてる。

• String
• Array
• TypedArray
• Map
• Set

そのため、これらのオブジェクトは、for...ofなどで直接反復させることができる。

for (const char of "abc") {
  console.log(char)
}

イテレーターの反復可能性

IterableIterator

ECMAScriptで定義されている上記のようなIteratorを満たすオブジェクトは、そのイテレーター自身（this）を返す@@iterator（Symbol.iterator）をプロパティとして持つプロトタイプ%IteratorPrototype%を継承しているため、イテレーター自身もIterableインターフェースを満たしている。

これをTypeScriptでは次のように再帰的に表現している。

src/lib/es2015.iterable.d.ts#L34-L36

interface IterableIterator<T> extends Iterator<T> {
    [Symbol.iterator](): IterableIterator<T>;
}

これを使って例えばArrayのinterfaceの一部は、次のように定義されている。

src/lib/es2015.iterable.d.ts#L38-L56

interface Array<T> {
    [Symbol.iterator](): IterableIterator<T>;
    entries(): IterableIterator<[number, T]>;
    keys(): IterableIterator<number>;
    values(): IterableIterator<T>;
}

AsyncIterableIterator

ECMAScriptで定義されているAsyncIteratorを満たすオブジェクトもまた、そのイテレーター自身（this）を返す@@asyncIterator（Symbol.asyncIterator）をプロパティとして持つプロトタイプ%AsyncIteratorPrototype%を継承しているため、イテレーター自身がAsyncIterableインターフェースを満たすようになっている。

これもTypeScriptでは同様に次のように再帰的に表現している。

src/lib/es2018.asynciterable.d.ts#L23-L25

interface AsyncIterableIterator<T> extends AsyncIterator<T> {
    [Symbol.asyncIterator](): AsyncIterableIterator<T>;
}

イテレーターと反復可能オブジェクトの作成

先に挙げたインターフェースを満たすようにオブジェクトを作成すれば、自身でイテレーターや反復可能オブジェクトを作成することもできる。

たとえば、次のコードは1から10を出力する。

const ONE_TO_TEN = {
  [Symbol.iterator]() {
    let i = 0;
    return {
      next: () => {
        i += 1;
        return i <= 10 ? {
          value: i,
        } : {
          done: true
        }
      }
    }
  }
}

for (const i of ONE_TO_TEN) {
  console.log(i)
}

ジェネレーター関数とジェネレーター

組み込みの反復可能オブジェクトのように、IteratorでありかつIterable、あるいはAsyncIteratorでありかつAsyncIterableであるようなイテレーターを作成するために、ECMAScriptではジェネレーター関数というものが用意されている。

• GeneratorFunction
• Generator
• AsyncGeneratorFunction
• AsyncGenerator

GeneratorFunctionは、IteratorでありかつIterableなオブジェクトGeneratorを返す関数であり、function*を使って定義される。

AsyncGeneratorFunctionはその非同期版で、AsyncIteratorでありかつAsyncIterableなオブジェクトAsyncGeneratorを返す関数であり、async function*を使って定義される。

これらのジェネレーター関数の中では、値を反復の一要素として出力するyieldや、処理を別のジェネレーターや反復可能オブジェクトに委任するyield*が使えるため、反復処理を柔軟に記述することができる。

たとえば、ONE_TO_TENを定義して作成した1から10を出力するコードは、loからhiまで（両端含む）のnumberを列挙するrange関数をジェネレーター関数として定義することで、次のように書き直すことができる。

function* range(lo: number, hi: number): Generator<number> {
  for (let i = lo; i <= hi; i++) {
    yield i;
  }
}

for (const i of range(1, 10)) {
  console.log(i)
}

Generatorは、TypeScriptでは次のように定義されている。

src/lib/es2015.generator.d.ts#L3-L9

interface Generator<T = unknown, TReturn = any, TNext = unknown> extends Iterator<T, TReturn, TNext> {
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return(value: TReturn): IteratorResult<T, TReturn>;
    throw(e: any): IteratorResult<T, TReturn>;
    [Symbol.iterator](): Generator<T, TReturn, TNext>;
}

IterableIteratorとの違いは、returnとthrow、およびそれらの引数にあった?がついていない点で、典型的なIteratorの振る舞いとして先に述べておいた、returnの場合valueをそのまま返して終了し、throwの場合eをthrowして終了する、という既定の動作が自動で定義されるようになっている。

またnextに対して与えた引数は、yieldの返却値として与えられるようになっており、ジェネレーター関数内で受け取れるようになっている。

function* makeLogger(limit: number): Generator<void, void, string> {
    for (let i = 0; i < limit; i++) {
        console.log(yield)
    }
}

const logger = makeLogger(3)
logger.next("hello") // "hello"
logger.next("hello") // "hello"
logger.next("hello") // "hello"
logger.next("hello") // 出力されない

async function*を使って定義されるAsyncGeneratorFunctionはその非同期版で、返されるAsyncGeneratorはTypeScriptで次のように定義されている。

src/lib/es2018.asyncgenerator.d.ts#L3-L9

interface AsyncGenerator<T = unknown, TReturn = any, TNext = unknown> extends AsyncIterator<T, TReturn, TNext> {
    next(...args: [] | [TNext]): Promise<IteratorResult<T, TReturn>>;
    return(value: TReturn | PromiseLike<TReturn>): Promise<IteratorResult<T, TReturn>>;
    throw(e: any): Promise<IteratorResult<T, TReturn>>;
    [Symbol.asyncIterator](): AsyncGenerator<T, TReturn, TNext>;
}

これも返される値（および返される値としてあたえる値）がPromiseとなっていることを除いて、Generatorと同様である。

async function* fetchAllText(urls: string[]): AsyncGenerator<string> {
  for (const url of urls) {
    const res = await fetch(url)
    yield await res.text()
  }
}

async function main() {
  for await (const text of fetchAllText([])) {
    console.log(text)
  }
}

main().catch(console.error)

参考リンク

• MDN: JavaScript
  • Guide: Iterators and Generators
    • https://developer.mozilla.org/docs/Web/JavaScript/Guide/Iterators_and_Generators
  • Reference: Iteration protocols
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Iteration_protocols
  • Reference: function*
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/function*
  • Reference: function* expression
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/function*
  • Reference: yield
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/yield
  • Reference: yield*
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/yield*
  • Reference: for...of
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/for...of
  • Reference: for await...of
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/for-await...of
  • Reference: Symbol.iterator
    • https://developer.mozilla.or/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
  • Reference: Symbol.asyncIterator
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Symbol/asyncIterator
  • Reference: Generator
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Generator
  • Reference: GeneratorFunction
    • https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/GeneratorFunction
• TypeScript: Documentation
  • Iterators and Generators
    • https://www.typescriptlang.org/docs/handbook/iterators-and-generators.html
• TypeScript: Source
  • src/lib/es2015.symbol.d.ts
    • https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.symbol.d.ts
  • src/lib/es2015.iterable.d.ts
    • https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.iterable.d.ts
  • src/lib/es2015.generator.d.ts
    • https://github.com/microsoft/TypeScript/blob/main/src/lib/es2015.generator.d.ts
  • src/lib/es2018.asynciterable.d.ts
    • https://github.com/microsoft/TypeScript/blob/main/src/lib/es2018.asynciterable.d.ts
  • src/lib/es2018.asyncgenerator.d.ts
    • https://github.com/microsoft/TypeScript/blob/main/src/lib/es2018.asyncgenerator.d.ts
• ECMAScript® Language Specification
  • 6.1.5.1 Well-Known Symbols
    • https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-well-known-symbols
    • Table 1: Well-known Symbols
      • https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#table-well-known-symbols
  • 7.4 Operations on Iterator Objects
    • https://tc39.es/ecma262/#sec-operations-on-iterator-objects
  • 13.15 Assignment Operators
    • https://tc39.es/ecma262/#sec-assignment-operators
  • 14.7 Iteration Statements
    • https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-iteration-statements
  • 15.5 Generator Function Definitions
    • https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-generator-function-definitions
  • 15.6 Async Generator Function Definitions
    • https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-async-generator-function-definitions
  • 27.1 Iteration
    • https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-iteration
  • 27.3 GeneratorFunction Objects
    • https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generatorfunction-objects
  • 27.4 AsyncGeneratorFunction Objects
    • https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgeneratorfunction-objects
  • 27.5 Generator Objects
    • https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generator-objects
  • 27.6 AsyncGenerator Objects
    • https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgenerator-objects

• Θ記法（big-theta notation、上界と下界をあたえる、タイトな限界という）
• O記法（big-o notation、上界のみをあたえる、タイトな限界であるとは限らない）
• Ω記法（big-omega notation、下界のみをあたえる、タイトな限界であるとは限らない）
• o記法（little-o notation、タイトな限界ではない上界をあたえる）
• ω記法（little-omega notation、タイトな限界ではない下界をあたえる）

たとえば、

• $2 n^2 = \Theta(n^2)$
• $2 n^2 \ne \Theta(n^3)$
• $2 n^2 \ne \Theta(n)$
• $2 n^2 = O(n^2)$
• $2 n^2 = O(n^3)$
• $2 n^2 = \Omega(n^2)$
• $2 n^2 = \Omega(n)$
• $2 n^2 \ne o(n^2)$
• $2 n^2 = o(n^3)$
• $2 n^2 \ne \omega(n^2)$
• $2 n^2 = \omega(n)$

Θ記法

定義

ある関数 $g(n)$ について、$\Theta(g(n))$ とは、ある正の定数 $c_1, c_2, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le c_1 g(n) \le f(n) \le c_2 g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

Θ記法（big-theta notation）は、漸近的な上界と下界をあたえる。

すなわち、 $f(n)$ が $\Theta(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c_1 g(n)$ および $c_2 g(n)$ ）につねに挟まれることを意味する。

$n \ge n_0$ において、 $g(n)$ はつねに $f(n)$ と定数倍の範囲で等しくなるので、Θ記法で与えられる $g(n)$ を特に、漸近的にタイトな限界（asymptotically tight bound）という。

たとえば、 $2 n^2 = \Theta(n^2)$ であるが、 $2 n^2 \ne \Theta(n^3)$　、 $2 n^2 \ne \Theta(n)$ である。

（正確には $2 n^2 \in \Theta(n^2)$ だが、このように略記する。詳しくは「等式および不等式における漸近記法」総合版でp.41-を参照。）

なお、他の文献ではΘ記法の意味でO記法が用いられる場合もある。

O記法

定義

ある関数 $g(n)$ について、$O(g(n))$ とは、ある正の定数 $c, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le f(n) \le c g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

O記法（big-o notation）は、 漸近的な上界をあたえる。

すなわち $f(n)$ が $O(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c g(n)$ ）よりつねに小さくなる（上からおさえられる）ことを意味する。

たとえば、 $2 n^2 = O(n^2)$ であるが、上界しか示さないので、 $2 n^2 = O(n^3)$ も成り立つ。

なお、他の文献ではΘ記法の意味でO記法が用いられる場合もある。

Ω記法

定義

ある関数 $g(n)$ について、$\Omega(g(n))$ とは、ある正の定数 $c, n_0$ が存在して、すべての $n \ge n_0$ に対して、 $0 \le c g(n) \le f(n)$ を満たすような関数 $f(n)$ の集合である。

説明

Ω記法（big-omega notation）は、漸近的な下界をあたえる。

$f(n)$ が $\Omega(g(n))$ である（属する）とは、 $n$ が十分大きいければ（ $n \ge n_0 \ge 0$ ）、 $f(n)$ が $g(n)$ の定数倍（ $c g(n)$ ）よりつねに大きくなる（下からおさえられる）ことを意味する。

たとえば、 $2 n^2 = \Omega(n^2)$ であるが、下界しか示さないので、 $2 n^2 = \Omega(n)$ も成り立つ。

o記法

定義

ある関数 $g(n)$ について、$o(g(n))$ とは、任意の正の定数 $c \gt 0$ に対して、ある正の定数 $n_0 \gt 0$ が存在して、 すべての $n \ge n_0$ に対して $0 \le f(n) \lt c g(n)$ を満たすような関数 $f(n)$ の集合である。

説明

o記法（little-o notation）は、漸近的にタイトな限界ではない、漸近的な上界をあたえる。

すなわち、たとえば $2 n^2 = o(n^3)$ であるが、 $2 n^2 = \Theta(n^2)$ であるため、 $2 n^2 \ne o(n^2)$ となる。

o記法では、 $n$ が大きくなるにつれて、 $f(n)$ は $g(n)$ に対して相対的に無限小に近づくので、

が成立する。

ω記法

定義

ある関数 $g(n)$ について、$\omega(g(n))$ とは、任意の正の定数 $c \gt 0$ に対して、ある正の定数 $n_0 \gt 0$ が存在して、 すべての $n \ge n_0$ に対して $0 \le c g(n) \lt f(n)$ を満たすような関数 $f(n)$ の集合である。

説明

ω記法（little-omega notation）は、漸近的にタイトな限界ではない、漸近的な下界をあたえる。

すなわち、たとえば $2 n^2 = \omega(n)$ であるが、 $2 n^2 = \Theta(n^2)$ であるため、 $2 n^2 \ne \omega(n^2)$ となる。

ω記法では、 $n$ が小さくなるにつれて $f(n)$ は $g(n)$ に対して相対的に無限大に近づくので、

が成立する。

漸近関係の性質

推移性は、Θ、O、Ω、o、ωのすべてにおいて成り立つ。すなわち、

• $f(n) = \Theta(g(n)) \land g(n) = \Theta(h(n)) \implies f(n) = \Theta(h(n))$
• $f(n) = O(g(n)) \land g(n) = O(h(n)) \implies f(n) = O(h(n))$
• $f(n) = \Omega(g(n)) \land g(n) = \Omega(h(n)) \implies f(n) = \Omega(h(n))$
• $f(n) = o(g(n)) \land g(n) = o(h(n)) \implies f(n) = o(h(n))$
• $f(n) = \omega(g(n)) \land g(n) = \omega(h(n)) \implies f(n) = \omega(h(n))$

反射性は、Θ、O、Ωにおいてのみ成り立つ。すなわち、

• $f(n) = \Theta(f(n))$
• $f(n) = O(f(n))$
• $f(n) = \Omega(f(n))$

対称性は、Θにおいてのみ成り立つ。すなわち、

• $f(n) = \Theta(g(n)) \iff g(n) = \Theta(f(n))$

また、OとΩ、oとωのそれぞれについて転置対称性が成り立つ。すなわち、

• $f(n) = O(g(n)) \iff g(n) = \Omega(f(n))$
• $f(n) = o(g(n)) \iff g(n) = \omega(f(n))$

これらの性質について、実数の同値関係・順序関係と比較すると、

• $\Theta \approx a = b$
• $O \approx a \le b$
• $\Omega \approx a \ge b$
• $o \approx a \lt b$
• $\omega \approx a \gt b$

のような類似性が見出されるが、漸近関係についてはかならずしもどれかひとつが成立するとは限らないことに注意。

参考

• 『アルゴリズムイントロダクション 第3版 総合版』2013年、近代科学社
  • 原著: Introduction to Algorithms
    • Thomas H. Cormen
    • Charles E. Leiserson
    • Ronald L. Rivest
    • Clifford Stein
  • 翻訳:
    • 浅野 哲夫
    • 岩野 和生
    • 梅尾 博司
    • 山下 雅史
    • 和田 幸一
  • ISBN: 978-4764904088

準備

ここではmacOS/VS Codeで進めていく。

Denoのインストール

参考リンク: https://github.com/denoland/deno_install

macOSでHomebrewを使う場合は:

brew install deno

公式のインストールスクリプトも用意されている。

Shell（macOS/Linux）の場合:

curl -fsSL https://deno.land/x/install/install.sh | sh

PowerShell（Windows）の場合:

iwr https://deno.land/x/install/install.ps1 -useb | iex

DenoのCLI

参考リンク: https://deno.land/manual/getting_started/command_line_interface

バージョンの確認は次のコマンドで行う:

deno --version

更新は次のコマンドで行う:

deno upgrade

ヘルプは次のコマンドで表示される:

deno help
deno -h
deno --help

Denoの設定ファイル

Denoではすべてデフォルトのままで使う場合、設定ファイルは必要ない。ただし、TypeScriptやリンター、フォーマッターの設定を記述したい場合、--configオプションで渡すことのできる.jsonファイルまたは.jsoncファイルを用意しておくことができる。

デフォルトの名前は決められていないが、将来的なサポートのためにdeno.jsonまたはdeno.jsoncという名前が推奨されている。

IDEの設定

参考リンク: https://deno.land/manual/getting_started/setup_your_environment

VS Code

参考リンク: https://deno.land/manual/vscode_deno

Deno公式拡張機能のhttps://marketplace.visualstudio.com/items?itemName=denoland.vscode-denoをインストールし、設定からDeno: Enable（deno.enable）を有効にする。Deno: Initialize Workspace Configurationコマンドで.vscode/settings.jsonを作成してもよい。

.vscode/settings.jsonの例:

{
    "deno.config": "./deno.json",
    "deno.enable": true,
    "deno.lint": true,
    "deno.unstable": true,
    "[typescript][typescriptreact][javascript][javascriptreact][json][jsonc][markdown]": {
        "editor.defaultFormatter": "denoland.vscode-deno"
    }
}

なお、設定ファイルの名前にdeno.jsoncまたはdeno.jsonを使っている場合は自動で認識されるので、deno.configで設定する必要はない。

tasks.jsonで使えるタスク定義やプロブレムマッチャーも提供されている。

.vscode/tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "deno",
            "command": "run",
            "args": ["src/main.ts"],
            "problemMatcher": ["$deno"]
        },
        {
            "type": "deno",
            "command": "test",
            "problemMatcher": ["$deno-test"]
        },
        {
            "type": "deno",
            "command": "lint",
            "problemMatcher": ["$deno-lint"]
        }
    ]
}

JetBrainsのIDE

JetBrains公式プラグインのhttps://plugins.jetbrains.com/plugin/14382-denoをインストールする。

ファイルの実行

参考リンク: https://deno.land/manual/getting_started/command_line_interface

Denoでファイルを実行するにはdeno runコマンドを用いる。

hello.ts:

console.log("Hello, World!");

コマンド:

deno run hello.ts

出力:

Hello, World!

リモートのファイルも実行できる。

コマンド:

# 最新版
deno run https://deno.land/std/examples/welcome.ts
# 0.133.0
deno run https://deno.land/std@0.133.0/examples/welcome.ts

出力:

Welcome to Deno!

ファイル名の後の引数はすべてスクリプトに対する引数となる。

deno run main.ts --help

パーミッション

参考リンク: https://deno.land/manual/getting_started/permissions

Denoではデフォルトでネットワークやファイルシステムへのアクセスがすべてオフになっている。プログラムからのアクセスを許可するには、実行時にオプションやプロンプトから許可を与える必要がある。

以下、オプションを列挙するが、実際にdeno runを実行するには実行するファイル名が引数として必要となるとなることには注意。

# ネットワークアクセス
deno run --allow-net
deno run --allow-net=github.com,localhost:8080
# ファイルシステムアクセス（読み取り）
deno run --allow-read
deno run --allow-read=
# ファイルシステムアクセス（書き込み）
deno run --allow-write
deno run --allow-write=
# 環境変数
deno run --allow-env
deno run --allow-env=HOME,PATH

# 高分解能時間測定（high-resolution time measurement）
deno run --allow-hrtime

DenoはV8エンジンのサンドボックス機能を使うことでセキュアな実行をサポートしているが、コマンドやFFIはサンドボックス外での実行を許可することになるので、注意が必要となる。

# コマンド（サブプロセス）の実行
deno run --allow-run
deno run --allow-run=imagemagick,ffmpeg

# FFI（外部関数インターフェース）によるダイナミックライブラリの読込・実行
deno run --allow-ffi

上記のすべてを許可するには--allow-allまたは-Aが使えるが、当然注意が必要となる。

# すべて許可
deno run --allow-all
deno run -A

テスト

参考リンク: https://deno.land/manual/testing

テストの記述

ファイル名が以下の形式のファイルが、テストファイルとして認識される。

• test.ts
• *.test.ts
• *_test.ts

hello.test.ts

import { assert } from "https://deno.land/std@0.133.0/testing/asserts.ts"

Deno.test("Hello, Test!", () => {
    assert("Hello, Test!".includes("Test"))
})

Deno.testのAPIについては:

• https://doc.deno.land/deno/stable/~/Deno.test

std/testing/asserts.tsモジュールについては:

• https://doc.deno.land/https://deno.land/std/testing/asserts.ts

をそれぞれ参照。

テストの実行

deno test

でカレントディレクトリ以下の{*_,*.,}test.{ts, tsx, mts, js, mjs, jsx, cjs, cts}、つまり、

hello/test.ts
hello.test.ts
hello_test.ts

のようなファイルに記述されているテストがすべて実行される。

# ディレクトリの指定
deno test hello/

# ファイルの指定
deno test hello.test.ts

も可能。

import { assert } from "https://deno.land/std@0.133.0/testing/asserts.ts"

Deno.test("Hello, Test!", { permissions: { read: true } }, () => {
    assert(true)
})

のようにパーミッションが必要な場合は、deno runの場合と同様にオプションにより実行に許可を与える。

deno test --allow-read

リント

参考リンク: https://deno.land/manual/tools/linter

コードのリントはdeno lintコマンドで行う。

# すべてのファイル（カレントディレクトリ以下）
deno lint
# 指定したディレクトリ
deno lint src/
# 指定したファイル
deno lint src/main.ts　src/lib.ts

ルールの一覧は:

• https://lint.deno.land/

を参照。

設定ファイルで、含めるファイルやリントのルールを指定できることもできる。

{
    "lint": {
        "files": {
            "include": ["src/"],
            "exclude": ["src/testdata/"]
        },
        "rules": {
            "tags": ["recommended"],
            "include": ["ban-untagged-todo"],
            "exclude": ["no-unused-vars"]
        }
    }
}

フォーマット

参考リンク: https://deno.land/manual/tools/formatter

コードのフォーマットはdeno fmtコマンドで行う。

# すべてのファイル（カレントディレクトリ以下）
deno fmt
# 指定したディレクトリ
deno fmt src/
# 指定したファイル
deno fmt src/main.ts　src/lib.ts

設定ファイルで、含めるファイルやフォーマットのオプションを指定することもできる。

{
    "fmt": {
        "files": {
            "include": ["src/"],
            "exclude": ["src/testdata/"]
        },
        "options": {
            "useTabs": true,
            "lineWidth": 80,
            "indentWidth": 4,
            "singleQuote": true,
            "proseWrap": "preserve"
        }
    }
}

依存パッケージの管理

deps.ts

参考リンク: https://deno.land/manual/examples/manage_dependencies

依存パッケージを何らかのファイルにまとめて管理したい場合は、一つの慣習として次のような名前のファイルにリモートの依存先を記述し、そこからimportして使う。

• deps.ts（dependencies）
• dev_deps.ts（devDependencies）

src/deps.ts:

export * as yaml from "https://deno.land/std@0.133.0/encoding/yaml.ts"

src/main.ts:

import { yaml } from "./deps.ts"

const article = yaml.parse(`
title: Hello, Deno!
description: An introduction to Deno.
`)

console.log(article)

lock.json

参考リンク: https://deno.land/manual/linking_to_external_code/integrity_checking.md

複数の環境で本当に同一のパッケージが使われているか整合性を確かめるには、ロックファイルを使う。

ファイル名は公式マニュアルの例ではlock.jsonとなっているが、個人的にはdeno.lock.jsonを使いたい。

ロックファイルを生成するには:

deno cache --lock-write --lock=deno.lock.json src/deps.ts

ロックファイルを使ってキャッシュを再読み込みするには:

deno cache --reload --lock=deno.lock.json src/deps.ts

感想

Node.jsへの反省として発表されてからしばらく経っているが、当初思ったよりは普及しておらず、開発中の機能も多い。

特に、外部ライブラリを使う起点となるパッケージ管理の仕組みについては、Goが結局go.modやgo.sumを導入したように、ファイルでまとめて管理するように戻してしまったほうがいいのではという感がいなめなず、結果として、外部ライブラリを使うときにこそ良さを発揮するであろうサンドックス機能の恩恵にも与りにくくなっている。

とはいえ、TypeScriptとawaitがそのまま使えるのと、テストランナーやフォーマッター、リンターがデフォルトでついてくるのは、プロジェクトをミニマルに保ちたい場合にはうれしい利点となっている。

当面はTypeScriptのみで外部ライブラリさえ使わない小さな個人プロジェクトで使いつつ、今後の行く末に期待したい。 $

• 公式サイト: https://deno.land/
• 公式マニュアル: https://deno.land/manual
• リポジトリ: https://github.com/denoland/deno
• ランタイムAPI: https://doc.deno.land/deno/stable
• 標準ライブラリ: https://deno.land/std

next build && next export

スクリプトを、

{
  "scripts": {
    "build": "next build && next export"
  }
}

のようにしておくと便利。

参考

• https://nextjs.org/docs/advanced-features/static-html-export
• https://github.com/vercel/next.js/tree/canary/examples/with-static-export

npm i -D sass

TypeScriptを作っている場合、custom.d.tsのようなファイルを作り:

declare module "*.module.css"
declare module "*.module.sass"
declare module "*.module.scss"

参考

• https://nextjs.org/docs/basic-features/built-in-css-support#sass-support

• 公式サイト: https://sass-lang.com
• リポジトリ: https://github.com/sass/dart-sass

npm i -D prettier eslint-config-prettier

.eslintrc.jsonへの追記:

{
  "extends": ["next/core-web-vitals", "prettier"]
}

.prettierignoreへの追記:

/.next/
/out/

npmスクリプトの追加（任意）:

{
  "scripts": {
    "format": "prettier --write ."
  },
}

go mod init example/hello

次のようなgo.modが生成される:

module example/hello

go 1.18

main.goを作成する（ファイル名は任意）:

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

実行は:

go run .

パッケージの追加

例えば:

go get github.com/labstack/echo/v4

main.goを次のように書き直して:

package main

import (
	"net/http"

	"github.com/labstack/echo/v4"
)

func main() {
	// Echo instance
	e := echo.New()

	// Routes
	e.GET("/", hello)

	// Start server
	e.Logger.Fatal(e.Start(":1323"))
}

// Handler
func hello(c echo.Context) error {
	return c.String(http.StatusOK, "Hello, World!")
}

実行すると:

go run .

http://localhost:1323/

で"Hello, World!が表示されるようになる。

npx create-next-app@latest --ts .

yarn:

yarn create next-app --ts .

pnpm:

pnpm create next-app --ts .

// @ts-check
"use strict"

/**
 *
 * @param { string } phase
 * @param {{ defaultConfig: import("next").NextConfig }} config
 * @returns { Promise<import("next").NextConfig> }
 */
export default async function createNextConfig(phase, { defaultConfig }) {
    return {
        reactStrictMode: true,
    }
}

参考

• https://github.com/vercel/next.js/blob/e57d621fb38562b1d5ae02fb6f7efd343e1db405/packages/next/server/config-shared.ts#L475-L481

• 公式サイト: https://nextjs.org/
• リポジトリ: https://github.com/vercel/next.js

.font-weight {
    font-weight: 100; /* thin */
    font-weight: 200; /* extra light */
    font-weight: 300; /* light */
    font-weight: 400; /* normal */
    font-weight: 500; /* medium */
    font-weight: 600; /* semi bold */
    font-weight: 700; /* bold */
    font-weight: 800; /* extra bold */
    font-weight: 900; /* black */
}

参考

• https://www.w3.org/TR/css-fonts-3/#font-weight-numeric-values
• https://docs.microsoft.com/typography/opentype/spec/os2#usweightclass

• 仕様: https://www.w3.org/TR/css/
• WG: https://www.w3.org/Style/CSS/
• MDN: https://developer.mozilla.org/docs/Web/CSS

仕様

• True Type Font（ttf、仕様）
• Open Type Font（otf、仕様）
• Web Open Font Format（woff、仕様）
• Web Open Font Format 2.0（woff2、仕様）

資料

• Microsoft Typography
  • https://docs.microsoft.com/typography/
• Adobe
  • https://helpx.adobe.com/fonts/using/adobe-type-resources-faq.html
  • https://github.com/adobe-type-tools/font-tech-notes
• FontForge Technical References
  • https://fontforge.org/docs/techref.html
  • https://fontforge.org/docs/appendices/bibliography.html
• Google
  • https://fonts.google.com/knowledge
  • https://googlefonts.github.io
• SIL International
  • https://scripts.sil.org/cms/scripts/page.php?item_id=IWS-Chapter07
  • https://scripts.sil.org/cms/scripts/page.php?item_id=IWS-Chapter08
  • https://scripts.sil.org/IWS-AppendixC

CSS

• CSS Fonts: https://www.w3.org/TR/css-fonts/
• CSS Fonts (Draft): https://drafts.csswg.org/css-fonts/
• MDN @font-face: https://developer.mozilla.org/docs/Web/CSS/@font-face
• web.dev - Fonts: https://web.dev/tags/fonts/

ブログ

• https://fonts.googleblog.com
• https://blog.typekit.com
• https://ccjktype.fonts.adobe.com

実装

• .NET (WPF)
  • Language: C#
  • Source: https://github.com/dotnet/wpf
    • MS.Internal
    • System.Windows.Media
  • Documentation: https://docs.microsoft.com/dotnet/
    • System.Windows.Media
  • Note: Developed by Microsoft. Used by Windows.
• Core Text
  • Language: C with Objective-C/Swift API
  • Source: Closed.
  • Documentation: https://developer.apple.com/documentation/coretext
  • Note: Developed by Apple. Used by iOS, macOS, tvOS, and watchOS.
• Adobe Font Development Kit for OpenType (AFDKO)
  • Language: C
  • Source: https://github.com/adobe-type-tools/afdko
  • Documentation: https://adobe-type-tools.github.io/afdko/
  • Note: Developed by Adobe.
• FreeType
  • Language: C
  • Source: https://gitlab.freedesktop.org/freetype/freetype/
  • Documentation: https://www.freetype.org/freetype2/docs/documentation.html
  • Note: Used by iOS, Android, Chromium, GNU/Linus, and more.
• HarfBuzz
  • Language: C++
  • Source: https://github.com/harfbuzz/harfbuzz
  • Documentation: https://harfbuzz.github.io
  • Note: Used with FreeType by Android, Chromium, Firefox, and more.
• fontTools
  • Language: Python
  • Source: https://github.com/fonttools/fonttools
  • Documentation: https://fonttools.readthedocs.io
  • Note: Used by Google and Adobe.
• OpenType Sanitizer
  • Language: C++
  • Source: https://github.com/khaledhosny/ots
  • Documentation: https://github.com/khaledhosny/ots/tree/main/docs
  • Note: Used by Chromium and Firefox to validate font files.
• golang.org/x/image/font
  • Language: Go
  • Source: https://github.com/golang/image
  • Documentation: https://pkg.go.dev/golang.org/x/image/font
  • Note: Go's library.

const HtmlWebpackPlugin = require("html-webpack-plugin")

module.exports = {
    // ...
    plugins: [
        // ...
        new HtmlWebpackPlugin({
            filename: "index.html",
            template: "src/index.html.tsx",
        }),
    ],
};

のように設定し、index.html.tsxで、

import React from "react"
import { renderToStaticMarkup } from "react-dom/server"

export default function () {
    return (
        `<!DOCTYPE html>` +
        renderToStaticMarkup(
            <html lang="en">
                <head>
                    <meta charSet="utf-8" />
                    <meta
                        name="viewport"
                        content="width=device-width,initial-scale=1.0"
                    />
                    <title>Title</title>
                </head>
                <body>
                    <p>Hello, html-webpack-plugin.</p>
                </body>
            </html>
        )
    )
}

のように、renderToStaticMarkupを使って文字列を返す関数をexportすればよい。

• 公式サイト: https://reactjs.org
• リポジトリ: https://github.com/facebook/react/

• 公式サイト: https://www.typescriptlang.org/
• リポジトリ: https://github.com/microsoft/TypeScript
• FAQs: https://github.com/microsoft/TypeScript/wiki/FAQ
• 古い仕様: https://github.com/microsoft/TypeScript/blob/main/doc/spec-ARCHIVED.md
• コンパイラ資料: https://github.com/microsoft/TypeScript-Compiler-Notes/

たとえば次のような型を用意しておけば:

type Nominal<T extends string> = {
    __nominal__: T
}

次のように型でのみ区別可能な文字列型を作ることができる:

type PlaceId = string & Nominal<"PlaceId">
type EventId = string & Nominal<"EventId">

ただし次のように型アサーションが必要となる:

const placeId = "place1" as PlaceId
const eventId = "event1" as EventId

function escape(html: string) {
    return html.replaceAll(/[<>&'"]/g, c => {
        switch (c) {
            case "<":
                return "&lt;"
            case ">":
                return "&gt;"
            case "&":
                return "&amp;"
            case "'":
                return "&apos;"
            case '"':
                return "&quot;"
            default:
                return c
        }
    })
}

• HTML Standard: https://html.spec.whatwg.org/multipage/
• MDN: https://developer.mozilla.org/docs/Web/HTML

• ECMAScript Language Specification: https://tc39.es/ecma262/multipage/
• HTML Standard 8.1 Scripting: https://html.spec.whatwg.org/multipage/webappapis.html#scripting
• MDN: https://developer.mozilla.org/docs/Web/JavaScript

• The Cargo Book: https://doc.rust-lang.org/cargo/
• リポジトリ: https://github.com/rust-lang/cargo/

ワークスペースのマニフェスト

ワークスペースは[workspace]セクションのあるCargo.tomlによって定義され、そのマニフェストファイルのあるディレクトリはワークスペースのルートディレクトリと呼ばれる。

[workspace]
members = []
default-members = []
exclude = []

[workspace]セクションは[package]セクションを持つパッケージのマニフェストにも追加可能で、その場合そのパッケージはワークスペースのルートパッケージと呼ばれる。反対に[package]セクションを持たないワークスペースのマニフェストは、バーチャルマニフェストと呼ばれる。

ワークスペースのメンバー

ワークスペース内のパッケージは、ワークスペースのメンバーと呼ばれる。

メンバーは[workspace]セクションのmembersキーで指定することができる（?や*などのグロブパターンが使用可能）。

[workspace]
members = ["path/to/member1", "../external/member2", "members/*"]

その他、ルートパッケージやメンバーのマニフェストに記載されている依存パッケージのうち、ワークスペースのルートディレクトリに含まれるpathによって指定されているもの（path dependency）も、自動的にワークスペースのメンバーとなる。

そのため、ルートパッケージの[workspace]セクションが空となることもありうる。

[package]
name = "my-root-package"
version = "0.1.0"

[dependencies]
member1 = { path = "./member1" }

[workspace]

pathによる依存パッケージが自動でメンバーに追加されるのを防いだり、一部パッケージをグロブパターンから除外したりのするには、excludeキーを使うことができる。なおexcludeではグロブパターンは使えず、指定されたパス以下のすべてのパッケージがメンバーから除外される仕様になっている。

[workspace]
members = ["crates/*"]
exclude = ["crates/bar"]

ワークスペースの認識

ワークスペースのマニフェストはCargoによって、自動的に親ディレクトリへと遡って探索される。ワークスペースのメンバーがルートディレクトリ外にある場合などのようにこの動作の上書きがしたい場合は、パッケージのマニフェストでpackage.workspaceキーを用いることで、パッケージの属するワークスペースを指定することができる。

[package]
name = "member"
version = "0.1.0"
workspace = "../../path/to/workspace"

ワークスペースの機能

ワークスペースによってメンバーは以下を共有することになる。

• 依存パッケージの解決
  • Cargo.lockファイルはワークスペースのルートディレクトリにのみ置かれる
• 出力ディレクトリ
  • デフォルトではワークスペースのルートディレクトリ直下のtarget
• Cargo.tomlの[patch]、[replace]、[profile.*]セクション
  • ワークスペースのマニフェストのもののみが認識され、メンバーのマニフェストのものは無視される

[workspace]
members = ["crates/*"]

[profile]
opt-level = s

また、cargo newやcargo initで行われるgitリポジトリの初期化も、作成されるパッケージが属することになるワークスペースが既にバージョン管理されている場合は行われなくなる。

そのほかpackage.metadataと同様にworkspace.metadataテーブルも許容されており、Cargo以外のツールが自由に使うことが可能となっている。

[workspace]
members = ["crates/*"]

[workspace.metadata.site]
title = "Project Site"
icon = { path = "icon.png" }

CLIのオプション

Cargoのコマンドでは、-p（--package）オブションを使うことで、カレントディレクトリが属するワークスペース内にあるパッケージを指定することができる。

cargo run -p member1

また--workspaceオプションを使うと、カレントディレクトリが属するワークスペース内にあるすべてのパッケージを対象に、そのコマンドが実行される。

cargo test --workspace

何も指定しなかった場合は、カレントディレクトリが属するパッケージに対して、コマンドが実行される（メンバーのディレクトリ内ではない場合は、ルートパッケージ）。

cargo build

属するパッケージがなく、代わりにバーチャルマニフェストに属するディレクトリで実行した場合は、デフォルトでは--workspaceを指定した場合と同様に振る舞うが、default-membersキーを用いるとその際実行されるメンバーを指定しておくことができる。なおdefault-membersでもグロブパターンは使えるが、メンバーに含まれないパッケージが選択されることはない。

[workspace]
members = ["crates/*", "others/*"]
default-members = ["crates/*"]
exclude = ["crates/bar"]

参考

• https://doc.rust-lang.org/cargo/reference/workspaces.html

We have also revised the slogan. Historically, it has been:

Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

Like the bullet list of features, this doesn't convey what you can do with Rust. So we've updated the slogan:

Rust: The programming language that empowers everyone to become a systems programmer.

ここで「システムプログラミング言語」としてのRustから、現在の「効率的で信頼できるソフトウェアを誰もがつくれる言語（A language empowering everyone to build reliable and efficient software.）」としてのRustに変わったらしい。

npm i -D monaco-editor-webpack-plugin

次のようにプラグインとして追加するだけで、勝手に設定してくれる:

const MonacoEditorWebpackPlugin = require("monaco-editor-webpack-plugin")

module.exports = {
    plugins: [new MonacoEditorWebpackPlugin()],
}

プレビュー用にここでは以下を追加:

npm i -D webpack-cli webpack-dev-server html-webpack-plugin

webpack.config.js:

const path = require("path")
const MonacoEditorWebpackPlugin = require("monaco-editor-webpack-plugin")
const HtmlWebpackPlugin = require("html-webpack-plugin")

module.exports = {
    entry: path.resolve(__dirname, "src", "index.js"),
    plugins: [new MonacoEditorWebpackPlugin(), new HtmlWebpackPlugin()],
    // webpack 6 ではいらなくなるはず:
    experiments: {
        css: true,
    },
}

例えば次のようなJavaScriptとCSSを読み込むと:

src/index.js

import * as monaco from "monaco-editor"
import "./index.css"

monaco.editor.create(
    document.body.appendChild(document.createElement("div")),
    {
        language: "javascript",
        value: `console.log("Hello, 世界")`,
    }
)

src/index.css

html,
body,
body > div {
    height: 100%;
}

画面いっぱいにMonaco Editorが表示されるはず:

webpack serve --mode development

• 公式サイト: https://microsoft.github.io/monaco-editor/
• リポジトリ: https://github.com/microsoft/monaco-editor
• API: https://microsoft.github.io/monaco-editor/api/index.html
  • monaco.d.tsが生成元

• 公式サイト: https://webpack.js.org/
• リポジトリ: https://github.com/webpack/webpack

• MUST
• MUST NOT
• REQUIRED
• SHALL
• SHALL NOT
• SHOULD
• SHOULD NOT
• RECOMMENDED
• MAY
• OPTIONAL

すべてのRFCがこの解釈に従うわけではないが、多くのRFCがこのRFCを参照することで、表現を厳密に解釈できるようにしている。

本文は:

• https://datatracker.ietf.org/doc/html/rfc2119

日本語訳には、たとえば:

• https://www.ipa.go.jp/security/rfc/RFC2119JA.html

なおRFC 8174は大文字で表記されている場合のみRFC 2119の意味で解釈することで曖昧さをなくそうというRFCであり、RFC 2119とともに参照されることが多い。

しなければならない（必要）

• MUST（「しなければならない」）
• REQUIRED（「要求される」）
• SHALL（「することになる」）

は仕様を満たすには絶対必要であることを示す。

強い要求なので、この表現を用いる場合は、細心の注意が必要となる。

してはならない（禁止）

• MUST NOT（「してはならない」）
• SHALL NOT（「することはない」）

は仕様を満たすには絶対禁止であることを示す。

強い要求なので、この表現を用いる場合は、細心の注意が必要となる。

すべきである（推奨）

• SHOULD（「すべきである」）
• RECOMMENDED（「推奨される」）

は特定の条件における正当な理由なく、その項目を無視してはならないことを示す。

その項目を無視するには、細心の注意が必要となる。

すべきでない（非推奨）

• SHOULD NOT（「すべきでない」）
• NOT RECOMMENDED（「推奨されない」）

は特定の条件における正当な理由なく、その項目を満たしてはならないことを示す。

その項目を満たすには、細心の注意が必要となる。

してもよい（任意）

• MAY（「してもよい」）
• OPTIONAL（「任意である」）

は、その項目を満たすか満たさないかが実装者に任されることを示す。

逆にいえば、その項目を満たしてる実装も満たしていない実装も両方仕様を満たしているものとして正当に扱わなければならない。

• https://www.ietf.org/standards/rfcs/
• https://www.rfc-editor.org

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader

原因はどうやら現時点でのCloudflare PagesのデフォルトのNode.jsのバージョンが12.18.0であることだったようなので、環境変数のNODE_VERSIONをひとまず16に設定すると解決した。

なお.nvmrcや.node-versionなどのファイルもサポートされているので、これで指定しておくとより取り回しがきくかもしれない。

• 公式サイト: https://www.cloudflare.com/

• 公式サイト: https://pages.cloudflare.com/

• 公式サイト: https://typicode.github.io/husky/
• リポジトリ: https://github.com/typicode/husky

npm install husky -D

npm set-script prepare "husky install"
npm run prepare

npx husky add .husky/pre-commit "npm run precommit"

例えば、

npm set-script precommit "npm run check && npm run lint && npm run format"

Googleアナリティクス

本サイトはGoogleの提供するGoogleアナリティクスを利用しています。またそれによって、Cookie、モバイルデバイスの識別情報（Android の広告識別子、iOS の広告識別子など）、およびその他データの収集に使われる類似の技術なども利用しています。Googleアナリティクスでデータが収集、処理される仕組みについては、「ユーザーが Google パートナーのサイトやアプリを使用する際の Google によるデータ使用」をご覧ください。

• 公式サイト: https://www.rust-lang.org/
• リポジトリ: https://github.com/rust-lang/rust

#![doc = include_str!("../README.md")]

pub fn distance_ptr(a: &str, b: &str) -> usize {
    (b.as_ptr() as usize) - (a.as_ptr() as usize)
}

コンパイルすると:

movq %rdx, %rax
subq %rdi, %rax
retq

補足

これを使うと、ある文字列（source）に対してその部分文字列（span）がどの位置や範囲にあるかを、追加情報なしに取得することができるはず（安全な操作かどうかは正直なところ分からない）。

なお_unwrapのついている関数では、spanとして与えられた文字列スライスが本当にsourceの範囲内にあるかを確認してOptionで返すようになっている。

fn position_ptr_unwrap(source: &str, span: &str) -> usize {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;
    span_start - source_start
}

fn position_ptr(source: &str, span: &str) -> Option<usize> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;

    if span_start < source_start {
        return None;
    }

    let source_end = source_start.checked_add(source.len())?;
    let span_end = span_start.checked_add(span.len())?;

    if source_end < span_end {
        return None;
    }

    Some(span_start - source_start)
}

fn range_ptr_unwrap(source: &str, span: &str) -> core::ops::Range<usize> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;
    let range_start = span_start - source_start;
    range_start..(range_start + span.len())
}

fn range_ptr(source: &str, span: &str) -> Option<core::ops::Range<usize>> {
    let source_start = source.as_ptr() as usize;
    let span_start = span.as_ptr() as usize;

    if span_start < source_start {
        return None;
    }

    let source_end = source_start.checked_add(source.len())?;
    let span_end = span_start.checked_add(span.len())?;

    if source_end < span_end {
        return None;
    }

    let range_start = span_start - source_start;
    let range = range_start..(range_start + span.len());
    Some(range)
}