{ "version": "https://jsonfeed.org/version/1.1", "title": "Public Theta Blog", "description": "Public Thetaの個人技術ブログです。", "home_page_url": "https://blog.publictheta.com", "feed_url": "https://blog.publictheta.com/feed.json", "language": "ja", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ], "items": [ { "id": "https://blog.publictheta.com/tags/qemu", "url": "https://blog.publictheta.com/tags/qemu", "title": "QEMU", "summary": "", "content_html": "", "date_published": "2024-10-19T06:19:35.545Z", "date_modified": "2024-10-19T06:19:35.545Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2024-10-19-qemu-aarch64-static", "url": "https://blog.publictheta.com/memos/2024-10-19-qemu-aarch64-static", "title": "x86_64のUbuntuでqemu-aarch64-staticする", "summary": "", "content_html": "

x86_64のUbuntu（環境はGitHub ActionsのUbuntu 22.04のランナー）で、qemu-aarch64-staticを使ってaarch64のバイナリを実行する際に、少しハマったのでメモ。

\n

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

\n
sh
↓
sudo apt-get update\nsudo apt-get install qemu-user-static
\n
sh
↓
qemu-aarch64-static bin
\n
↓
/lib/ld-linux-aarch64.so.1: No such file or directory\n
\n

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

\n

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

\n
sh
↓
sudo dpkg --add-architecture arm64
\n
sh
↓
sudo apt-get update
\n
↓
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]\nE: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-updates/multiverse/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]\nE: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.83 80]\nE: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal-backports/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.81 80]\nE: Some index files failed to download. They have been ignored, or old ones used instead.\n
\n

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

\n

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

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

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

\n
sh
↓
UBUNTU=$(lsb_release -cs)\n\nsudo tee /etc/apt/sources.list.d/arm64.list <<EOF\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU main restricted\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates main restricted\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU universe\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates universe\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU multiverse\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-updates multiverse\ndeb [arch=arm64] http://ports.ubuntu.com/ $UBUNTU-backports main restricted universe multiverse\nEOF
\n

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

\n
sh
↓
# 念の為バックアップ\nsudo cp /etc/apt/sources.list /etc/apt/sources.list.bak\n\n# 例えばamd64\nARCH=$(dpkg --print-architecture)\n\n# 置換\nsudo sed -i \"s/deb /deb [arch=$ARCH] /g\" /etc/apt/sources.list
\n

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

\n
sh
↓
sudo apt-get install libc6:arm6
\n
sh
↓
qemu-aarch64-static bin
", "date_published": "2024-10-19T06:19:13.117Z", "date_modified": "2024-10-19T06:19:13.117Z", "tags": [ "QEMU" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/windows", "url": "https://blog.publictheta.com/tags/windows", "title": "Windows", "summary": "", "content_html": "", "date_published": "2024-10-19T05:44:07.333Z", "date_modified": "2024-10-19T05:44:07.333Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2024-10-19-rust-i686-w64-mingw32-gcc", "url": "https://blog.publictheta.com/memos/2024-10-19-rust-i686-w64-mingw32-gcc", "title": "Windows上でのi686-pc-windows-gnu向けRustビルドで\"linker `i686-w64-mingw32-gcc` not found\"が出る", "summary": "", "content_html": "

GitHub ActionsのWindowsのランナーでターゲットをi686-pc-windows-gnuにしてRustのバイナリーをビルドしようとしたら、以下のエラーが出た。

\n
text
↓
error: linker `i686-w64-mingw32-gcc` not found\n  |\n  = note: program not found
\n

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

\n
bash
↓
rustup toolchain install stable-i686-pc-windows-gnu\nrustup default stable-i686-pc-windows-gnu
", "date_published": "2024-10-19T05:38:40.472Z", "date_modified": "2024-10-19T05:38:40.472Z", "tags": [ "Rust", "Windows" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2024-06-14-cargo-target", "url": "https://blog.publictheta.com/memos/2024-06-14-cargo-target", "title": "Rustのtargetディレクトリをあるディレクトリ以下で共有する", "summary": "", "content_html": "

Rustのビルドによるアーティファクトはビルドのキャッシュを含め、すべてtargetディレクトリに出力される。

\n\n

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

\n
plaintext
↓
project-a/target/...\nproject-b/target/...\nproject-c/target/...
\n

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

\n\n

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

\n
bash
↓
export CARGO_TARGET_DIR=\"/path/to/shared/target\"
\n

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

\n
toml
↓
[build]\ntarget-dir = \"/path/to/shared/target\"
\n

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

\n\n

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

\n\n

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

\n
toml
↓
[build]\ntarget-dir = \".cargo/target\"
\n
plaintext
↓
.cargo/config.toml\n.cargo/target/...\nproject-a/\nproject-b/\nproject-c/
\n

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

\n
toml
↓
[build]\ntarget-dir = \"target\"
\n

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

\n
plaintext
↓
.cargo/config.toml\n.cargo/target/...\nproject-a/\nproject-b/\nproject-c/.cargo/config.toml\nproject-c/target/...
\n

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

\n
gitignore
↓
.cargo/config.toml\n
\n

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

\n
gitignore
↓
/target\n
", "date_published": "2024-06-14T04:08:21.822Z", "date_modified": "2024-06-14T04:08:21.822Z", "tags": [ "Rust", "Cargo" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2024-05-20-webpack-swc", "url": "https://blog.publictheta.com/memos/2024-05-20-webpack-swc", "title": "webpackでswcを使う", "summary": "", "content_html": "

webpackでTypeScriptをトランスパイルする際に、ts-loaderの代わりにesbuild（esbuild-loader）を使うこともできるが、swc（swc-loader）を使うこともできる。

\n

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

\n
bash
↓
# npm\nnpm install -D @swc/core swc-loader\n# yarn\nyarn add -D @swc/core swc-loader\n# pnpm\npnpm add -D @swc/core swc-loader
\n

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

\n

webpack.config.js:

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

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

\n

webpack.config.js:

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

.swcrc:

\n
json
↓
{\n    \"jsc\": {\n        \"parser\": {\n            \"syntax\": \"typescript\",\n            \"tsx\": true\n        }\n    }\n}
", "date_published": "2024-05-20T11:19:20.373Z", "date_modified": "2024-05-20T11:19:20.373Z", "tags": [ "webpack" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2024-05-20-npm-serve", "url": "https://blog.publictheta.com/memos/2024-05-20-npm-serve", "title": "npmのserveパッケージを使ってローカルサーバーを立てる", "summary": "", "content_html": "

serve（vercel/serve）を使うと、ローカルサーバーを簡単に立てることができる。

\n

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

\n
bash
↓
# npm\nnpx serve\n# yarn\nyarn dlx serve\n# pnpm\npnpm dlx serve
\n

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

\n
bash
↓
# npm\nnpm install -D serve\n# yarn\nyarn add -D serve\n# pnpm\npnpm add -D serve
\n
json
↓
{\n    \"scripts\": {\n        \"serve\": \"serve\"\n    }\n}
\n

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

\n
bash
↓
# npm\nnpm install -g serve\n# yarn\nyarn global add serve\n# pnpm\npnpm add -g serve
\n

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

\n
bash
↓
serve -h\nserve --help
\n

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

\n
bash
↓
serve public
\n

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

\n
bash
↓
serve -p 8080\nserve -l 8080
\n

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

\n

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

\n
json
↓
{\n    \"public\": \"public\"\n}
", "date_published": "2024-05-20T10:35:31.892Z", "date_modified": "2024-05-20T10:35:31.892Z", "tags": [ "JavaScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-06-24-jest-typescript-unexpected-token", "url": "https://blog.publictheta.com/memos/2022-06-24-jest-typescript-unexpected-token", "title": "Jest + TypeScriptで`SyntaxError: Unexpected token 'export'`が出る", "summary": "", "content_html": "

TypeScriptのプロジェクトにts-jestを使ってJestを導入しようとしたところ、次のようなエラーが出た。

\n
text
↓
export {};\n    ^^^^^^\n\n    SyntaxError: Unexpected token 'export'
\n

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

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

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

\n

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

\n
js
↓
module.exports = {\n    // 追加:\n    roots: [\"<rootDir>/src/\", \"<rootDir>/tests/\"],\n    // デフォルト:\n    // roots: [\"<rootDir>\"],\n}
", "date_published": "2022-06-24T13:14:13.064Z", "date_modified": "2022-06-24T13:14:13.064Z", "tags": [ "Jest", "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/jest", "url": "https://blog.publictheta.com/tags/jest", "title": "Jest", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-06-24T13:14:13.064Z", "date_modified": "2022-06-24T13:14:13.064Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-06-11-cloudflare-direct-upload", "url": "https://blog.publictheta.com/memos/2022-06-11-cloudflare-direct-upload", "title": "Cloudflare Pagesのダイレクトアップロードでビルド済みの静的サイトをそのままデプロイする", "summary": "", "content_html": "

Cloudflare PagesでCIやローカルからビルド済みのコンテンツをそのままアップロードするには「ダイレクトアップロード」を使う。

\n

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

\n\n

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

\n\n

Wrangler

\n

現在のバージョンは、

\n
shell
↓
wrangler --version
\n
text
↓
2.0.9
\n

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

\n
shell
↓
# Wrangler 1\nnpm uninstall -g @cloudflare/wrangler\n# Wrangler 2\nnpm install -g wrangler
\n\n

アップロード

\n

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

\n
shell
↓
wrangler pages publish [DIRECTORY] [OPTIONS]
\n

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

\n
shell
↓
wrangler pages publish dist
\n

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

\n

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

\n
shell
↓
wrangler pages publish dist --project-name my-project
\n

プロジェクト

\n

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

\n
shell
↓
wrangler pages project list
\n

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

\n
shell
↓
wrangler pages project create [PROJECT-NAME] [OPTIONS]
\n

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

\n
shell
↓
wrangler pages project create my-project
\n

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

\n
shell
↓
wrangler pages project create my-project --production-branch main
\n

参考リンク

\n", "date_published": "2022-06-11T20:34:02.771Z", "date_modified": "2022-06-11T20:34:02.771Z", "tags": [ "Cloudflare Pages" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-05-29-cargo-resolver-2", "url": "https://blog.publictheta.com/memos/2022-05-29-cargo-resolver-2", "title": "RustでCargoの仮想ワークスペース（virtual workspaces）使用時にのみ依存パッケージのコンパイルに失敗する", "summary": "", "content_html": "

RustでゲームエンジンのBevyを使ってパッケージとして書いていたものをワークスペースに移行してビルドしてみると、なぜか突然依存パッケージのコンパイルに失敗するようになった。

\n

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

\n
toml
↓
[workspace]\nmembers = [\"crates/*\"]\nresolver = \"2\"
\n\n

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

\n", "date_published": "2022-05-29T09:24:05.542Z", "date_modified": "2022-05-29T09:24:05.542Z", "tags": [ "Rust", "Cargo", "Bevy" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-05-26-storybook-react-mdx-not-function", "url": "https://blog.publictheta.com/memos/2022-05-26-storybook-react-mdx-not-function", "title": "Storybook + React + MDX で TypeError `(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function` が出る", "summary": "", "content_html": "

Storybookの構築時にハマったのでメモ。ビルドは正常にされるが、Storybookを開いた時に次のようなTypeErrorが出た。

\n
text
↓
(0 , _mdx_js_react__WEBPACK_IMPORTED_MODULE_2__.mdx) is not a function
\n

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

\n\n

に書かれている通り、

\n
shell
↓
npm install @storybook/mdx2-csf --save-dev
\n

.storybook/main.js:

\n
js
↓
module.exports = {\n    // ...\n    features: {\n        previewMdx2: true,\n    },\n}
\n

を追加すると解決した。

", "date_published": "2022-05-26T12:55:50.409Z", "date_modified": "2022-05-26T12:55:50.409Z", "tags": [ "Storybook" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/storybook", "url": "https://blog.publictheta.com/tags/storybook", "title": "Storybook", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-05-26T12:55:50.409Z", "date_modified": "2022-05-26T12:55:50.409Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-05-14-ffmpeg-video-to-gif", "url": "https://blog.publictheta.com/memos/2022-05-14-ffmpeg-video-to-gif", "title": "FFmpegで動画をGIF化する", "summary": "", "content_html": "
shell
↓
ffmpeg -i video.mov video.gif
\n

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

\n
shell
↓
ffmpeg -i video.mov -r 30 -vf scale=1280:-1 video.gif
", "date_published": "2022-05-14T23:01:59.795Z", "date_modified": "2022-05-14T23:01:59.795Z", "tags": [ "FFmpeg", "GIF" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/ffmpeg", "url": "https://blog.publictheta.com/tags/ffmpeg", "title": "FFmpeg", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-05-14T23:01:59.795Z", "date_modified": "2022-05-14T23:01:59.795Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/gif", "url": "https://blog.publictheta.com/tags/gif", "title": "GIF", "summary": "", "content_html": "

Graphics Interchange Formatの略。設計者（Steve Wilhite）による読み方は「ジフ」。

", "date_published": "2022-05-14T23:01:59.795Z", "date_modified": "2022-05-14T23:01:59.795Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-05-10-netlify-local-deploy", "url": "https://blog.publictheta.com/memos/2022-05-10-netlify-local-deploy", "title": "Netlifyでローカルビルドをそのまま静的ホストする", "summary": "", "content_html": "

Netlifyの手動デプロイを使うと、ブラウザまたはCLIからフォルダをアップロードして静的ホストすることができる。

\n\n

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

\n\n

インストール

\n

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

\n
shell
↓
npm install netlify-cli -g
\n

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

\n
shell
↓
npm install --save-dev netlify-cli
\n

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

\n
shell
↓
netlify
\n

ログイン

\n

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

\n
shell
↓
netlify login
\n

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

\n\n

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

\n
shell
↓
netlify switch
\n

デプロイ

\n

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

\n
shell
↓
netlify deploy
\n

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

\n

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

\n
shell
↓
netlify deploy --dir=dist
\n

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

\n
shell
↓
netlify deploy --dir=dist --prod
\n

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

\n
shell
↓
netlify deploy --prod
\n

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

\n
shell
↓
netlify deploy --dir=dist --site=my-site --prod
\n

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

\n
shell
↓
netlify sites:list
\n

既存サイトとのリンク

\n

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

\n

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

\n
shell
↓
netlify link
\n

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

\n

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

\n
shell
↓
netlify link --name my-site
\n

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

\n
shell
↓
netlify sites:list
\n

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

\n
shell
↓
netlify unlink
\n

新規サイトの作成

\n

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

\n
shell
↓
netlify sites:create
\n

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

\n
shell
↓
netlify sites:create --name my-site
\n

参考リンク

\n\n

変更履歴

\n

2022-06-12

\n", "date_published": "2022-05-10T02:47:01.890Z", "date_modified": "2022-06-11T20:34:02.771Z", "tags": [ "Netlify" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/netlify", "url": "https://blog.publictheta.com/tags/netlify", "title": "Netlify", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-05-10T02:47:01.890Z", "date_modified": "2022-05-10T02:47:01.890Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-04-30-bevy-coordinate-system", "url": "https://blog.publictheta.com/memos/2022-04-30-bevy-coordinate-system", "title": "Bevyの座標系", "summary": "", "content_html": "

Bevyでは座標系として、Y軸上向きの右手系が使われている。

\n

\"Y軸上向き右手座標系\"

\n

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

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
軸符号向き
X+右
X-左
Y+上
Y-下
Z+後
Z-前
\n

参考リンク

\n", "date_published": "2022-05-02T21:25:43.713Z", "date_modified": "2022-05-02T21:25:43.713Z", "tags": [ "Rust", "Bevy", "3D" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/3d", "url": "https://blog.publictheta.com/tags/3d", "title": "3D", "summary": "", "content_html": "", "date_published": "2022-05-02T21:25:43.713Z", "date_modified": "2022-05-02T21:25:43.713Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/bevy", "url": "https://blog.publictheta.com/tags/bevy", "title": "Bevy", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-05-02T21:25:43.713Z", "date_modified": "2022-05-02T21:25:43.713Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-04-11-vscode-side-load-extension", "url": "https://blog.publictheta.com/memos/2022-04-11-vscode-side-load-extension", "title": "`vscode.dev`に開発中の拡張機能をローカルから読み込む", "summary": "", "content_html": "

vscode.devでは、ローカルで開発中の拡張機能をマーケットプレイスなどに公開することなく、実際にインストールして試すことができる。

\n

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

\n

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

\n

方法

\n

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

\n

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

\n
shell
↓
npx serve --cors -l 8080
\n

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

\n
shell
↓
npx localtunnel -p 8080
\n

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

\n
text
↓
your url is: https://hungry-mole-48.loca.lt/
\n

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

\n
text
↓
Click to Continue
\n

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

\n

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

\n
text
↓
Developer: Install Web Extension...
\n

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

\n

参考リンク

\n", "date_published": "2022-04-11T17:39:44.728Z", "date_modified": "2022-04-11T17:39:44.728Z", "tags": [ "VS Code", "VS Code拡張機能" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/vscode", "url": "https://blog.publictheta.com/tags/vscode", "title": "VS Code", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-04-11T17:39:44.728Z", "date_modified": "2022-04-11T17:39:44.728Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/vscode-extension", "url": "https://blog.publictheta.com/tags/vscode-extension", "title": "VS Code拡張機能", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-04-11T17:39:44.728Z", "date_modified": "2022-04-11T17:39:44.728Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/articles/2022-04-03-typescript-iterator-generator", "url": "https://blog.publictheta.com/articles/2022-04-03-typescript-iterator-generator", "title": "TypeScriptのイテレーターとジェネレーター", "summary": "", "content_html": "

ECMAScriptの反復処理インターフェース

\n

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

\n\n

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

\n

Iterable

\n

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

\n

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

\n

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

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

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

\n

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

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

AsyncIterable

\n

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

\n

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

\n

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

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

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

\n

Iterator

\n

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

\n

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

\n

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

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

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

\n

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

\n

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

\n

AsyncIterator

\n

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

\n

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

\n

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

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

IteratorResult

\n

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

\n

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

\n

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

\n

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

\n
ts
↓
interface IteratorYieldResult<TYield> {\n    done?: false;\n    value: TYield;\n}\n\ninterface IteratorReturnResult<TReturn> {\n    done: true;\n    value: TReturn;\n}\n\ntype IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
\n

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

\n

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

\n\n

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

\n
ts
↓
for (const char of \"abc\") {\n  console.log(char)\n}
\n

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

\n

IterableIterator

\n

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

\n

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

\n

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

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

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

\n

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

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

AsyncIterableIterator

\n

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

\n

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

\n

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

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

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

\n

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

\n

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

\n
ts
↓
const ONE_TO_TEN = {\n  [Symbol.iterator]() {\n    let i = 0;\n    return {\n      next: () => {\n        i += 1;\n        return i <= 10 ? {\n          value: i,\n        } : {\n          done: true\n        }\n      }\n    }\n  }\n}\n\nfor (const i of ONE_TO_TEN) {\n  console.log(i)\n}
\n

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

\n

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

\n\n

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

\n

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

\n

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

\n

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

\n
ts
↓
function* range(lo: number, hi: number): Generator<number> {\n  for (let i = lo; i <= hi; i++) {\n    yield i;\n  }\n}\n\nfor (const i of range(1, 10)) {\n  console.log(i)\n}
\n

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

\n

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

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

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

\n

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

\n
ts
↓
function* makeLogger(limit: number): Generator<void, void, string> {\n    for (let i = 0; i < limit; i++) {\n        console.log(yield)\n    }\n}\n\nconst logger = makeLogger(3)\nlogger.next(\"hello\") // \"hello\"\nlogger.next(\"hello\") // \"hello\"\nlogger.next(\"hello\") // \"hello\"\nlogger.next(\"hello\") // 出力されない
\n

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

\n

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

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

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

\n
ts
↓
async function* fetchAllText(urls: string[]): AsyncGenerator<string> {\n  for (const url of urls) {\n    const res = await fetch(url)\n    yield await res.text()\n  }\n}\n\nasync function main() {\n  for await (const text of fetchAllText([])) {\n    console.log(text)\n  }\n}\n\nmain().catch(console.error)
\n

参考リンク

\n", "date_published": "2022-04-04T02:08:06.486Z", "date_modified": "2022-04-04T02:08:06.486Z", "tags": [ "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/articles/2022-04-03-notations-intro-algo", "url": "https://blog.publictheta.com/articles/2022-04-03-notations-intro-algo", "title": "計算量の漸近記法（Θ記法・O記法・Ω記法・o記法・ω記法）", "summary": "", "content_html": "

『アルゴリズムイントロダクション 第3版』（原著: Introduction to Algorithms）で用いられている次の5つの漸近記法について、まとめておく。詳細は第3章（総合版でp.36-）を参照。

\n\n

たとえば、

\n\n

Θ記法

\n

定義

\n

ある関数 g(n)g(n)g(n) について、Θ(g(n))\\Theta(g(n))Θ(g(n)) とは、ある正の定数 c1,c2,n0c_1, c_2, n_0c1​,c2​,n0​ が存在して、すべての n≥n0n \\ge n_0n≥n0​ に対して、 0≤c1g(n)≤f(n)≤c2g(n)0 \\le c_1 g(n) \\le f(n) \\le c_2 g(n)0≤c1​g(n)≤f(n)≤c2​g(n) を満たすような関数 f(n)f(n)f(n) の集合である。

\n

説明

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

O記法

\n

定義

\n

ある関数 g(n)g(n)g(n) について、O(g(n))O(g(n))O(g(n)) とは、ある正の定数 c,n0c, n_0c,n0​ が存在して、すべての n≥n0n \\ge n_0n≥n0​ に対して、 0≤f(n)≤cg(n)0 \\le f(n) \\le c g(n)0≤f(n)≤cg(n) を満たすような関数 f(n)f(n)f(n) の集合である。

\n

説明

\n

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

\n

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

\n

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

\n

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

\n

Ω記法

\n

定義

\n

ある関数 g(n)g(n)g(n) について、Ω(g(n))\\Omega(g(n))Ω(g(n)) とは、ある正の定数 c,n0c, n_0c,n0​ が存在して、すべての n≥n0n \\ge n_0n≥n0​ に対して、 0≤cg(n)≤f(n)0 \\le c g(n) \\le f(n) 0≤cg(n)≤f(n) を満たすような関数 f(n)f(n)f(n) の集合である。

\n

説明

\n

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

\n

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

\n

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

\n

o記法

\n

定義

\n

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

\n

説明

\n

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

\n

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

\n

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

\nlim⁡n→∞f(n)g(n)=0\\lim_{n \\to \\infty} \\frac{f(n)}{g(n)} = 0n→∞lim​g(n)f(n)​=0\n

が成立する。

\n

ω記法

\n

定義

\n

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

\n

説明

\n

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

\n

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

\n

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

\nlim⁡n→∞f(n)g(n)=∞\\lim_{n \\to \\infty} \\frac{f(n)}{g(n)} = \\inftyn→∞lim​g(n)f(n)​=∞\n

が成立する。

\n

漸近関係の性質

\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n

参考

\n", "date_published": "2022-04-03T17:36:57.843Z", "date_modified": "2022-04-03T17:36:57.843Z", "tags": [ "アルゴリズム", "データ構造" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/algorithm", "url": "https://blog.publictheta.com/tags/algorithm", "title": "アルゴリズム", "summary": "", "content_html": "", "date_published": "2022-04-03T17:36:57.843Z", "date_modified": "2022-04-03T17:36:57.843Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/data-structure", "url": "https://blog.publictheta.com/tags/data-structure", "title": "データ構造", "summary": "", "content_html": "", "date_published": "2022-04-03T17:36:57.843Z", "date_modified": "2022-04-03T17:36:57.843Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/articles/2022-04-02-deno-getting-started", "url": "https://blog.publictheta.com/articles/2022-04-02-deno-getting-started", "title": "Denoをはじめる", "summary": "", "content_html": "

煩雑な設定なしにTypeScriptを実行/テスト/リント/フォーマットできる環境を試してみたかったので、Denoを改めて使ってみる。

\n

準備

\n

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

\n

Denoのインストール

\n

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

\n

macOSでHomebrewを使う場合は:

\n
shell
↓
brew install deno
\n

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

\n

Shell（macOS/Linux）の場合:

\n
shell
↓
curl -fsSL https://deno.land/x/install/install.sh | sh
\n

PowerShell（Windows）の場合:

\n
shell
↓
iwr https://deno.land/x/install/install.ps1 -useb | iex
\n

DenoのCLI

\n

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

\n

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

\n
shell
↓
deno --version
\n

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

\n
shell
↓
deno upgrade
\n

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

\n
shell
↓
deno help\ndeno -h\ndeno --help
\n

Denoの設定ファイル

\n

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

\n

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

\n

IDEの設定

\n

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

\n

VS Code

\n

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

\n

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

\n

.vscode/settings.jsonの例:

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

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

\n

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

\n

.vscode/tasks.json

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

JetBrainsのIDE

\n

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

\n

ファイルの実行

\n

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

\n

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

\n

hello.ts:

\n
ts
↓
console.log(\"Hello, World!\");
\n

コマンド:

\n
shell
↓
deno run hello.ts
\n

出力:

\n
text
↓
Hello, World!
\n

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

\n

コマンド:

\n
shell
↓
# 最新版\ndeno run https://deno.land/std/examples/welcome.ts\n# 0.133.0\ndeno run https://deno.land/std@0.133.0/examples/welcome.ts
\n

出力:

\n
text
↓
Welcome to Deno!
\n

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

\n
shell
↓
deno run main.ts --help
\n

パーミッション

\n

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

\n

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

\n

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

\n
shell
↓
# ネットワークアクセス\ndeno run --allow-net\ndeno run --allow-net=github.com,localhost:8080\n# ファイルシステムアクセス（読み取り）\ndeno run --allow-read\ndeno run --allow-read=\n# ファイルシステムアクセス（書き込み）\ndeno run --allow-write\ndeno run --allow-write=\n# 環境変数\ndeno run --allow-env\ndeno run --allow-env=HOME,PATH\n\n# 高分解能時間測定（high-resolution time measurement）\ndeno run --allow-hrtime
\n

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

\n
shell
↓
# コマンド（サブプロセス）の実行\ndeno run --allow-run\ndeno run --allow-run=imagemagick,ffmpeg\n\n# FFI（外部関数インターフェース）によるダイナミックライブラリの読込・実行\ndeno run --allow-ffi
\n

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

\n
shell
↓
# すべて許可\ndeno run --allow-all\ndeno run -A
\n

テスト

\n

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

\n

テストの記述

\n

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

\n\n

hello.test.ts

\n
ts
↓
import { assert } from \"https://deno.land/std@0.133.0/testing/asserts.ts\"\n\nDeno.test(\"Hello, Test!\", () => {\n    assert(\"Hello, Test!\".includes(\"Test\"))\n})
\n

Deno.testのAPIについては:

\n\n

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

\n\n

をそれぞれ参照。

\n

テストの実行

\n
shell
↓
deno test
\n

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

\n
text
↓
hello/test.ts\nhello.test.ts\nhello_test.ts
\n

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

\n
shell
↓
# ディレクトリの指定\ndeno test hello/
\n
shell
↓
# ファイルの指定\ndeno test hello.test.ts
\n

も可能。

\n
ts
↓
import { assert } from \"https://deno.land/std@0.133.0/testing/asserts.ts\"\n\nDeno.test(\"Hello, Test!\", { permissions: { read: true } }, () => {\n    assert(true)\n})
\n

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

\n
shell
↓
deno test --allow-read
\n

リント

\n

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

\n

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

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

ルールの一覧は:

\n\n

を参照。

\n

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

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

フォーマット

\n

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

\n

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

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

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

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

依存パッケージの管理

\n

deps.ts

\n

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

\n

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

\n\n

src/deps.ts:

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

src/main.ts:

\n
ts
↓
import { yaml } from \"./deps.ts\"\n\nconst article = yaml.parse(`\ntitle: Hello, Deno!\ndescription: An introduction to Deno.\n`)\n\nconsole.log(article)
\n

lock.json

\n

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

\n

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

\n

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

\n

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

\n
shell
↓
deno cache --lock-write --lock=deno.lock.json src/deps.ts
\n

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

\n
shell
↓
deno cache --reload --lock=deno.lock.json src/deps.ts
\n

感想

\n

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

\n

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

\n

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

\n

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

", "date_published": "2022-04-02T20:53:03.766Z", "date_modified": "2022-04-02T20:53:03.766Z", "tags": [ "Deno", "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/deno", "url": "https://blog.publictheta.com/tags/deno", "title": "Deno", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-04-02T20:53:03.766Z", "date_modified": "2022-04-02T20:53:03.766Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-21-next-static-export", "url": "https://blog.publictheta.com/memos/2022-03-21-next-static-export", "title": "Next.jsで静的サイトとしてエクスポートする", "summary": "", "content_html": "
bash
↓
next build && next export
\n

スクリプトを、

\n
json
↓
{\n  \"scripts\": {\n    \"build\": \"next build && next export\"\n  }\n}
\n

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

\n

参考

\n", "date_published": "2022-03-21T17:02:27.182Z", "date_modified": "2022-03-21T17:02:27.182Z", "tags": [ "Next.js" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-21-next-sass", "url": "https://blog.publictheta.com/memos/2022-03-21-next-sass", "title": "Next.jsでSass/SCSSを有効にする", "summary": "", "content_html": "

Sassの追加:

\n
bash
↓
npm i -D sass
\n

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

\n
ts
↓
declare module \"*.module.css\"\ndeclare module \"*.module.sass\"\ndeclare module \"*.module.scss\"
\n

参考

\n", "date_published": "2022-03-21T16:51:53.757Z", "date_modified": "2022-03-21T16:51:53.757Z", "tags": [ "Next.js", "Sass/SCSS" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/sass", "url": "https://blog.publictheta.com/tags/sass", "title": "Sass/SCSS", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-21T16:46:33.543Z", "date_modified": "2022-03-21T16:46:33.543Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/prettier", "url": "https://blog.publictheta.com/tags/prettier", "title": "Prettier", "summary": "", "content_html": "", "date_published": "2022-03-21T16:34:03.186Z", "date_modified": "2022-03-21T16:34:03.186Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-21-next-prettier", "url": "https://blog.publictheta.com/memos/2022-03-21-next-prettier", "title": "Next.jsのプロジェクトに`prettier`を追加する", "summary": "", "content_html": "

依存パッケージの追加:

\n
bash
↓
npm i -D prettier eslint-config-prettier
\n

.eslintrc.jsonへの追記:

\n
json
↓
{\n  \"extends\": [\"next/core-web-vitals\", \"prettier\"]\n}
\n

.prettierignoreへの追記:

\n
↓
/.next/\n/out/\n
\n

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

\n
json
↓
{\n  \"scripts\": {\n    \"format\": \"prettier --write .\"\n  },\n}
", "date_published": "2022-03-21T16:32:22.689Z", "date_modified": "2022-03-21T16:32:22.689Z", "tags": [ "Next.js", "Prettier" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-21-go-create-app", "url": "https://blog.publictheta.com/memos/2022-03-21-go-create-app", "title": "Goアプリケーションの作成", "summary": "", "content_html": "

プロジェクトの作成

\n
bash
↓
go mod init example/hello
\n

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

\n
go-mod
↓
module example/hello\n\ngo 1.18\n
\n

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

\n
go
↓
package main\n\nimport \"fmt\"\n\nfunc main() {\n    fmt.Println(\"Hello, World!\")\n}
\n

実行は:

\n
bash
↓
go run .
\n

パッケージの追加

\n

例えば:

\n
bash
↓
go get github.com/labstack/echo/v4
\n

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

\n
go
↓
package main\n\nimport (\n\t\"net/http\"\n\n\t\"github.com/labstack/echo/v4\"\n)\n\nfunc main() {\n\t// Echo instance\n\te := echo.New()\n\n\t// Routes\n\te.GET(\"/\", hello)\n\n\t// Start server\n\te.Logger.Fatal(e.Start(\":1323\"))\n}\n\n// Handler\nfunc hello(c echo.Context) error {\n\treturn c.String(http.StatusOK, \"Hello, World!\")\n}
\n

実行すると:

\n
bash
↓
go run .
\n

http://localhost:1323/

\n

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

", "date_published": "2022-03-21T15:52:39.293Z", "date_modified": "2022-03-21T15:52:39.293Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-17-create-next-app", "url": "https://blog.publictheta.com/memos/2022-03-17-create-next-app", "title": "`create-next-app`を使って現在のディレクトリにTypeScriptのNext.jsプロジェクトの雛形を生成する", "summary": "", "content_html": "

npm:

\n
bash
↓
npx create-next-app@latest --ts .
\n

yarn:

\n
bash
↓
yarn create next-app --ts .
\n

pnpm:

\n
bash
↓
pnpm create next-app --ts .
", "date_published": "2022-03-17T21:11:11.180Z", "date_modified": "2022-03-17T21:11:11.180Z", "tags": [ "Next.js", "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-11-nextjs-config-typing", "url": "https://blog.publictheta.com/memos/2022-03-11-nextjs-config-typing", "title": "Next.jsの設定ファイルの型定義", "summary": "", "content_html": "

next.config.mjs:

\n
js
↓
// @ts-check\n\"use strict\"\n\n/**\n *\n * @param { string } phase\n * @param {{ defaultConfig: import(\"next\").NextConfig }} config\n * @returns { Promise<import(\"next\").NextConfig> }\n */\nexport default async function createNextConfig(phase, { defaultConfig }) {\n    return {\n        reactStrictMode: true,\n    }\n}
\n

参考

\n", "date_published": "2022-03-11T09:53:49.488Z", "date_modified": "2022-03-11T09:53:49.488Z", "tags": [ "Next.js" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/nextjs", "url": "https://blog.publictheta.com/tags/nextjs", "title": "Next.js", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-11T09:53:49.488Z", "date_modified": "2022-03-11T09:53:49.488Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-10-font-weight-name", "url": "https://blog.publictheta.com/memos/2022-03-10-font-weight-name", "title": "フォントのウェイト名と数値の対応表", "summary": "", "content_html": "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
数値名前
100Thin
200Extra Light (Ultra Light)
300Light
400Normal
500Medium
600Semi Bold (Demi Bold)
700Bold
800Extra Bold (Ultra Bold)
900Black (Heavy)
\n
css
↓
.font-weight {\n    font-weight: 100; /* thin */\n    font-weight: 200; /* extra light */\n    font-weight: 300; /* light */\n    font-weight: 400; /* normal */\n    font-weight: 500; /* medium */\n    font-weight: 600; /* semi bold */\n    font-weight: 700; /* bold */\n    font-weight: 800; /* extra bold */\n    font-weight: 900; /* black */\n}
\n

参考

\n", "date_published": "2022-03-10T20:52:36.745Z", "date_modified": "2022-03-10T20:52:36.745Z", "tags": [ "フォント", "CSS" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/css", "url": "https://blog.publictheta.com/tags/css", "title": "CSS", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-10T20:52:36.745Z", "date_modified": "2022-03-10T20:52:36.745Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/font", "url": "https://blog.publictheta.com/tags/font", "title": "フォント", "summary": "", "content_html": "

リンク

\n

仕様

\n\n

資料

\n\n

CSS

\n\n

ブログ

\n\n

実装

\n", "date_published": "2022-03-10T20:52:36.745Z", "date_modified": "2022-03-10T20:52:36.745Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-10-webpack-html-react", "url": "https://blog.publictheta.com/memos/2022-03-10-webpack-html-react", "title": "`html-webpack-plugin`でReactをテンプレートに使う", "summary": "", "content_html": "

テンプレートに指定したファイルからmodule.exportsでstringまたはそれを返す関数、Promiseを出力すればいいので、

\n
js
↓
const HtmlWebpackPlugin = require(\"html-webpack-plugin\")\n\nmodule.exports = {\n    // ...\n    plugins: [\n        // ...\n        new HtmlWebpackPlugin({\n            filename: \"index.html\",\n            template: \"src/index.html.tsx\",\n        }),\n    ],\n};
\n

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

\n
tsx
↓
import React from \"react\"\nimport { renderToStaticMarkup } from \"react-dom/server\"\n\nexport default function () {\n    return (\n        `<!DOCTYPE html>` +\n        renderToStaticMarkup(\n            <html lang=\"en\">\n                <head>\n                    <meta charSet=\"utf-8\" />\n                    <meta\n                        name=\"viewport\"\n                        content=\"width=device-width,initial-scale=1.0\"\n                    />\n                    <title>Title</title>\n                </head>\n                <body>\n                    <p>Hello, html-webpack-plugin.</p>\n                </body>\n            </html>\n        )\n    )\n}
\n

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

", "date_published": "2022-03-10T12:56:45.979Z", "date_modified": "2022-03-10T12:56:45.979Z", "tags": [ "webpack", "React", "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/react", "url": "https://blog.publictheta.com/tags/react", "title": "React", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-10T12:56:45.979Z", "date_modified": "2022-03-10T12:56:45.979Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/typescript", "url": "https://blog.publictheta.com/tags/typescript", "title": "TypeScript", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-06T21:08:08.625Z", "date_modified": "2022-03-06T21:08:08.625Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-06-typescript-nominal", "url": "https://blog.publictheta.com/memos/2022-03-06-typescript-nominal", "title": "TypeScriptでNominalな型付けを実現する", "summary": "", "content_html": "

TypeScript公式リポジトリのWiki内にあるFAQ「Can I make a type alias nominal?」でワークアラウンドとして紹介されているように、交差型（&）を利用する。

\n

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

\n
ts
↓
type Nominal<T extends string> = {\n    __nominal__: T\n}
\n

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

\n
ts
↓
type PlaceId = string & Nominal<\"PlaceId\">\ntype EventId = string & Nominal<\"EventId\">
\n

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

\n
ts
↓
const placeId = \"place1\" as PlaceId\nconst eventId = \"event1\" as EventId
", "date_published": "2022-03-06T21:06:25.109Z", "date_modified": "2022-03-06T21:06:25.109Z", "tags": [ "TypeScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-05-html-escape-js", "url": "https://blog.publictheta.com/memos/2022-03-05-html-escape-js", "title": "HTMLの特殊文字をJavaScriptでエスケープする", "summary": "", "content_html": "
ts
↓
function escape(html: string) {\n    return html.replaceAll(/[<>&'\"]/g, c => {\n        switch (c) {\n            case \"<\":\n                return \"&lt;\"\n            case \">\":\n                return \"&gt;\"\n            case \"&\":\n                return \"&amp;\"\n            case \"'\":\n                return \"&apos;\"\n            case '\"':\n                return \"&quot;\"\n            default:\n                return c\n        }\n    })\n}
", "date_published": "2022-03-05T17:37:12.065Z", "date_modified": "2022-03-05T17:37:12.065Z", "tags": [ "HTML", "JavaScript" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/html", "url": "https://blog.publictheta.com/tags/html", "title": "HTML", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-05T17:37:12.065Z", "date_modified": "2022-02-13T15:29:19.534Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/javascript", "url": "https://blog.publictheta.com/tags/javascript", "title": "JavaScript", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-05T17:37:12.065Z", "date_modified": "2022-02-13T15:28:32.728Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/cargo", "url": "https://blog.publictheta.com/tags/cargo", "title": "Cargo", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-04T14:45:09.081Z", "date_modified": "2022-03-04T14:45:09.081Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/articles/2022-03-04-cargo-workspace", "url": "https://blog.publictheta.com/articles/2022-03-04-cargo-workspace", "title": "Cargoのワークスペース", "summary": "", "content_html": "

RustのパッケージマネージャーであるCargoには、複数のパッケージの依存パッケージのバージョンや、出力ディレクトリ、プロファイルなどの設定を共有できるワークスペース機能がある。

\n

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

\n

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

\n
toml
↓
[workspace]\nmembers = []\ndefault-members = []\nexclude = []
\n

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

\n

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

\n

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

\n

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

\n
toml
↓
[workspace]\nmembers = [\"path/to/member1\", \"../external/member2\", \"members/*\"]
\n

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

\n

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

\n
toml
↓
[package]\nname = \"my-root-package\"\nversion = \"0.1.0\"\n\n[dependencies]\nmember1 = { path = \"./member1\" }\n\n[workspace]
\n

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

\n
toml
↓
[workspace]\nmembers = [\"crates/*\"]\nexclude = [\"crates/bar\"]
\n

ワークスペースの認識

\n

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

\n
toml
↓
[package]\nname = \"member\"\nversion = \"0.1.0\"\nworkspace = \"../../path/to/workspace\"
\n

ワークスペースの機能

\n

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

\n\n
toml
↓
[workspace]\nmembers = [\"crates/*\"]\n\n[profile]\nopt-level = s
\n

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

\n

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

\n
toml
↓
[workspace]\nmembers = [\"crates/*\"]\n\n[workspace.metadata.site]\ntitle = \"Project Site\"\nicon = { path = \"icon.png\" }
\n

CLIのオプション

\n

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

\n
bash
↓
cargo run -p member1
\n

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

\n
bash
↓
cargo test --workspace
\n

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

\n
bash
↓
cargo build
\n

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

\n
toml
↓
[workspace]\nmembers = [\"crates/*\", \"others/*\"]\ndefault-members = [\"crates/*\"]\nexclude = [\"crates/bar\"]
\n

参考

\n", "date_published": "2022-03-04T14:42:43.821Z", "date_modified": "2022-03-04T14:42:43.821Z", "tags": [ "Rust", "Cargo" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-02-rust-slogan", "url": "https://blog.publictheta.com/memos/2022-03-02-rust-slogan", "title": "Rustのスローガンが「効率的で信頼できるソフトウェアを誰もがつくれる言語」になったタイミング", "summary": "", "content_html": "

Rust Blogの2018-11-29の記事「A new look for rust-lang.org」に次の記載がある:

\n
\n

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

\n
\n

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

\n
\n

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

\n
\n

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

\n
\n
\n

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

", "date_published": "2022-03-02T20:40:09.848Z", "date_modified": "2022-03-02T20:40:09.848Z", "tags": [ "Rust" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-01-monaco-editor-webpack", "url": "https://blog.publictheta.com/memos/2022-03-01-monaco-editor-webpack", "title": "Monaco Editorをwebpackのプロジェクトに追加する", "summary": "", "content_html": "

monaco-editor-webpack-pluginを使うのが簡単:

\n
bash
↓
npm i -D monaco-editor-webpack-plugin
\n

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

\n
js
↓
const MonacoEditorWebpackPlugin = require(\"monaco-editor-webpack-plugin\")\n\nmodule.exports = {\n    plugins: [new MonacoEditorWebpackPlugin()],\n}
\n

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

\n
bash
↓
npm i -D webpack-cli webpack-dev-server html-webpack-plugin
\n

webpack.config.js:

\n
js
↓
const path = require(\"path\")\nconst MonacoEditorWebpackPlugin = require(\"monaco-editor-webpack-plugin\")\nconst HtmlWebpackPlugin = require(\"html-webpack-plugin\")\n\nmodule.exports = {\n    entry: path.resolve(__dirname, \"src\", \"index.js\"),\n    plugins: [new MonacoEditorWebpackPlugin(), new HtmlWebpackPlugin()],\n    // webpack 6 ではいらなくなるはず:\n    experiments: {\n        css: true,\n    },\n}
\n

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

\n

src/index.js

\n
js
↓
import * as monaco from \"monaco-editor\"\nimport \"./index.css\"\n\nmonaco.editor.create(\n    document.body.appendChild(document.createElement(\"div\")),\n    {\n        language: \"javascript\",\n        value: `console.log(\"Hello, 世界\")`,\n    }\n)
\n

src/index.css

\n
css
↓
html,\nbody,\nbody > div {\n    height: 100%;\n}
\n

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

\n
bash
↓
webpack serve --mode development
", "date_published": "2022-03-01T17:43:22.787Z", "date_modified": "2022-03-01T14:47:18.358Z", "tags": [ "Monaco Editor", "webpack" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/monaco-editor", "url": "https://blog.publictheta.com/tags/monaco-editor", "title": "Monaco Editor", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-01T17:43:22.787Z", "date_modified": "2022-03-01T14:50:50.870Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/webpack", "url": "https://blog.publictheta.com/tags/webpack", "title": "webpack", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-01T17:43:22.787Z", "date_modified": "2022-03-01T15:11:59.595Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-03-01-rfc2119", "url": "https://blog.publictheta.com/memos/2022-03-01-rfc2119", "title": "RFC 2119: RFCにおいて要求レベルを示すために用いるキーワード", "summary": "", "content_html": "

RFC 2119は、各種RFCにおいて次の用語や表現がどの程度の要求レベルを示すと解釈されるべきかを定義している。

\n\n

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

\n

本文は:

\n\n

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

\n\n

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

\n

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

\n\n

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

\n

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

\n

してはならない（禁止）

\n\n

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

\n

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

\n

すべきである（推奨）

\n\n

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

\n

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

\n

すべきでない（非推奨）

\n\n

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

\n

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

\n

してもよい（任意）

\n\n

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

\n

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

", "date_published": "2022-03-01T07:59:17.799Z", "date_modified": "2022-03-01T07:09:44.432Z", "tags": [ "RFC" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/rfc", "url": "https://blog.publictheta.com/tags/rfc", "title": "RFC", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-03-01T07:59:17.799Z", "date_modified": "2022-03-01T07:55:30.110Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-02-26-cloudflare-pages-err-unsupported-esm-url-scheme", "url": "https://blog.publictheta.com/memos/2022-02-26-cloudflare-pages-err-unsupported-esm-url-scheme", "title": "Cloudflare Pagesでエラー`Only file and data URLs are supported by the default ESM loader`がでる", "summary": "", "content_html": "

Cloudflare PagesでNode.jsのプロジェクトをビルドする際に、次のようなエラーが出た。

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

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

\n

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

", "date_published": "2022-02-26T08:54:37.708Z", "date_modified": "2022-02-26T08:54:37.708Z", "tags": [ "Cloudflare", "Cloudflare Pages" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/cloudflare", "url": "https://blog.publictheta.com/tags/cloudflare", "title": "Cloudflare", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-02-26T08:54:37.708Z", "date_modified": "2022-02-13T15:27:26.730Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/cloudflare-pages", "url": "https://blog.publictheta.com/tags/cloudflare-pages", "title": "Cloudflare Pages", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-02-26T08:54:37.708Z", "date_modified": "2022-02-26T08:56:23.019Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/husky", "url": "https://blog.publictheta.com/tags/husky", "title": "husky", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-02-26T08:11:40.016Z", "date_modified": "2022-02-26T08:11:40.016Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-02-26-add-husky", "url": "https://blog.publictheta.com/memos/2022-02-26-add-husky", "title": "`husky`を追加する", "summary": "", "content_html": "
shell
↓
npm install husky -D
\n
shell
↓
npm set-script prepare \"husky install\"\nnpm run prepare
\n
shell
↓
npx husky add .husky/pre-commit \"npm run precommit\"
\n

例えば、

\n
shell
↓
npm set-script precommit \"npm run check && npm run lint && npm run format\"
", "date_published": "2022-02-26T08:11:05.392Z", "date_modified": "2022-02-26T08:11:05.392Z", "tags": [ "husky" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/privacy", "url": "https://blog.publictheta.com/privacy", "title": "プライバシーポリシー", "summary": "プライバシーポリシーについてはこちらをご覧ください。", "content_html": "

本サイトはGoogleの提供するGoogleアナリティクスを利用しています。

\n

Googleアナリティクス

\n

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

", "date_published": "2022-02-16T11:28:12.186Z", "date_modified": "2022-02-16T11:33:45.416Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/tags/rust", "url": "https://blog.publictheta.com/tags/rust", "title": "Rust", "summary": "", "content_html": "

リンク

\n", "date_published": "2022-02-13T15:27:42.376Z", "date_modified": "2022-02-13T15:27:42.376Z", "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-02-13-rust-include-str-doc", "url": "https://blog.publictheta.com/memos/2022-02-13-rust-include-str-doc", "title": "RustでREADME.mdをドキュメントコメントとしてインクルードする", "summary": "", "content_html": "
rust
↓
#![doc = include_str!(\"../README.md\")]
", "date_published": "2022-02-13T15:25:26.303Z", "date_modified": "2022-02-13T15:25:26.303Z", "tags": [ "Rust" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] }, { "id": "https://blog.publictheta.com/memos/2022-02-13-rust-str-distance", "url": "https://blog.publictheta.com/memos/2022-02-13-rust-str-distance", "title": "Rustで文字列スライスのポインタ間の距離を測る", "summary": "", "content_html": "
rust
↓
pub fn distance_ptr(a: &str, b: &str) -> usize {\n    (b.as_ptr() as usize) - (a.as_ptr() as usize)\n}
\n

コンパイルすると:

\n
asm
↓
movq %rdx, %rax\nsubq %rdi, %rax\nretq
\n

補足

\n

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

\n

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

\n
rust
↓
fn position_ptr_unwrap(source: &str, span: &str) -> usize {\n    let source_start = source.as_ptr() as usize;\n    let span_start = span.as_ptr() as usize;\n    span_start - source_start\n}\n\nfn position_ptr(source: &str, span: &str) -> Option<usize> {\n    let source_start = source.as_ptr() as usize;\n    let span_start = span.as_ptr() as usize;\n\n    if span_start < source_start {\n        return None;\n    }\n\n    let source_end = source_start.checked_add(source.len())?;\n    let span_end = span_start.checked_add(span.len())?;\n\n    if source_end < span_end {\n        return None;\n    }\n\n    Some(span_start - source_start)\n}\n\nfn range_ptr_unwrap(source: &str, span: &str) -> core::ops::Range<usize> {\n    let source_start = source.as_ptr() as usize;\n    let span_start = span.as_ptr() as usize;\n    let range_start = span_start - source_start;\n    range_start..(range_start + span.len())\n}\n\nfn range_ptr(source: &str, span: &str) -> Option<core::ops::Range<usize>> {\n    let source_start = source.as_ptr() as usize;\n    let span_start = span.as_ptr() as usize;\n\n    if span_start < source_start {\n        return None;\n    }\n\n    let source_end = source_start.checked_add(source.len())?;\n    let span_end = span_start.checked_add(span.len())?;\n\n    if source_end < span_end {\n        return None;\n    }\n\n    let range_start = span_start - source_start;\n    let range = range_start..(range_start + span.len());\n    Some(range)\n}
", "date_published": "2022-02-13T15:24:44.489Z", "date_modified": "2022-05-29T13:58:22.415Z", "tags": [ "Rust" ], "authors": [ { "name": "Public Theta", "url": "https://publictheta.com" } ] } ] }