Jaybanuan's Blog

調べたことをメモしていくブログ

関係副詞のwhereは柔軟すぎるらしい

Go言語を始めようと思い、英語の勉強も兼ねて以下の本を読んでいるところ。

この本から引用した次の1文で、関係詞whereの先行詞が場所でないのが気になった。

This design is intentional, since it prevents programs from relying on any particular ordering where none is guaranteed.

自分なりに訳すと、以下のようになる。

この設計は意図的であり、プログラムが採用の保証がない特定の順序付けに依存することを防ぐためである。

ここで、whereの先行詞はany particular orderingのはずで、それならば場所ではない。 調べてみたところ、このWebサイトに以下の説明があり、納得できた。

このように関係副詞whereは、話し手や書き手が対象(先行詞)を「空間的な場所のイメージ」でとらえてさえいれば、様々な先行詞に対して柔軟に用いることができます。

つまり、any particular orderingをモノが並んでいる空間的なイメージで捉えると、関係副詞whereで受けることができる、と理解した。

Ubuntu 20.04 LTS でコマンドを利用してISOイメージをBD-Rに焼く

はじめに

Ubuntu 20.04 LTS でコマンドを利用してISOイメージをBD-Rに焼く時に調べたのメモ。 参考情報のみ。

参考

Ansibleのカスタムフィルタを作成するための情報源

はじめに

Ansibleのカスタムフィルタを作成するための情報源のメモ。 結局作成しなかったが、せっかく調べたので、参考情報のみ残しておく。

参考

GitHubでReleaseしたファイルのダウンロード数を取得する

はじめに

GitHubのReleaseで公開しているファイルのダウンロード数を取得する方法を調べたので、メモしておく。

ここでは、Docker ComposeのReleaseを例に挙げて説明する。 Docker ComposeのReleaseのページは以下のようになっているが、このページのAssetsとして登録されているファイルのダウンロード数を取得することになる。

f:id:redj:20201219131213p:plain

特定のReleaseのダウンロード数の取得方法

Assetsに登録されているファイルのダウンロード数は、GitHubAPIで取得できる。 以下に、Docker Compose 1.27.4のReleaseページで公開されているファイルの情報を取得する例を示す。

$ curl \
    --silent \
    --header "Accept: application/vnd.github.v3+json" \
    https://api.github.com/repos/docker/compose/releases/tags/1.27.4

返却されるjsonには様々な情報が含まれているのだが、ダウンロード数のカウントに必要な部分だけ抜粋すると、以下のようになる。

{
  "html_url": "https://github.com/docker/compose/releases/tag/1.27.4",
  "assets": [
    {
      "name": "docker-compose-Darwin-x86_64",
      "download_count": 6705,
    },
    {
      "name": "docker-compose-Darwin-x86_64.sha256",
      "download_count": 191,
    },
    {
      "name": "docker-compose-Darwin-x86_64.tgz",
      "download_count": 813,
    },
    {
      "name": "docker-compose-Darwin-x86_64.tgz.sha256",
      "download_count": 129,
    },
    {
      "name": "docker-compose-Linux-x86_64",
      "download_count": 424905,
    },
    {
      "name": "docker-compose-Linux-x86_64.sha256",
      "download_count": 37947,
    },
    {
      "name": "docker-compose-Windows-x86_64.exe",
      "download_count": 23259,
    },
    {
      "name": "docker-compose-Windows-x86_64.exe.sha256",
      "download_count": 10752,
    },
    {
      "name": "run.sh",
      "download_count": 12628,
    }
  ],
}

全てのReleaseのダウンロード数の取得方法

特定のReleaseのダウンロード数の取得方法とほぼ同じで、指定するURLを以下のように変更すればよい。

$ curl \
    --silent \
    --header "Accept: application/vnd.github.v3+json" \
    https://api.github.com/repos/docker/compose/releases

返却されるjsonは、特定のReleaseの情報を配列形式にしたものである。 省略しつつ構造を示すと、以下のようになる。

[
  {
    "html_url": "https://github.com/docker/compose/releases/tag/1.28.0-rc1",
    "assets": [
        ...
    ],
    ...
  },
  {
    "html_url": "https://github.com/docker/compose/releases/tag/1.27.4",
    "assets": [
        ...
    ],
    ...
  },
  {
    "html_url": "https://github.com/docker/compose/releases/tag/1.27.3",
    "assets": [
        ...
    ],
    ...
  },
  ...
]

ただし、Releaseの数が多い場合はページネーション(つまり複数回の取得)が必要になるかもしれないが、GitHub APIのドキュメントを深くは読んでないので、よく分かってない。

ダウンロード数の集計の例

ダウンロード数の集計の例として、特定のRelease (ここでは Docker Compose 1.27.4)を、コマンドjqを利用して集計してみると、以下のようになる。

$ curl \
    --silent \
    --header "Accept: application/vnd.github.v3+json" \
    https://api.github.com/repos/docker/compose/releases/tags/1.27.4 \
    | jq "[.assets[].download_count] | add"

517666

また、全てのReleaseに対して集計する例は、以下のようになる。

$ curl \
    --silent \
    --header "Accept: application/vnd.github.v3+json" \
    https://api.github.com/repos/docker/compose/releases \
    | jq "[.[].assets[].download_count] | add"

11089246

前述したが、全てのReleaseの取得では、ページネーションを意識する必要があるかもしれない。

補足1:ソースのアーカイブはAssetではない(ようだ)

ところで、「Source code (zip)」と「Source code (tar.gz)」については、以下のように画面上はAssetsに含まれているが、GitHubAPIの呼び出しの結果には含まれていない。

f:id:redj:20201219131238p:plain

このことはGitHub APIのドキュメントには書かれていないようだが、GitHubの中の人と思われるIvan ZuzakさんがStack Overflowで以下のようにコメントしていた。

Assets are binaries you can upload when creating a release. Try creating a release and look for the "Attach binaries by dropping them here or selecting one." text. We track download counts only for those assets, not for releases themselves (currently).

行間を読むと、これら2つのファイルは単にソースコードアーカイブしたものであり、リリースバイナリではないので、Assetとはみなしていない、ということなのだろう。

補足2:ダウンロード数をカウントするWebサイト

ダウンロード数を単に目視確認したいだけなら、以下のWebサイトを利用するとよい。

このWebサイトのソースコードはGitHubにあるJavaScriptからGitHub APIを呼び出しているようだ。

参考

GitHub Container Registry (Preview版) を使ってみる

はじめに

GitHub Container Registryを使ってみたが、Preview版ならではのポイントがいくつかあったので、メモを残しておく。 ここでやりたいことは、GitHub Actionsを利用したCIで、コンテナイメージをビルドして、GitHub Container Registryにプッシュすること。

環境

# cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 20.04.1 LTS"

(1) リポジトリの作成

ひとつリポジトリを作成する。 今回はghcr-workflowという名前でリポジトリを作成した。

(2) Dockerfileの作成

リポジトリのトップディレクトリにDockerfileを作成する。 今回はGitHub Container Registryを使ってみることが目的なので、Dockerfileは以下のようなFROMがあるだけのシンプルなものにした。

FROM hello-world

(3) GitHub Actionsのワークフローの作成

以下の内容でワークフロー.github/workflows/build-and-push.ymlを作成する。 ここでは、実行のトリガを手動(workflow_dispatch)にしている。

name: build and push container image
on:
  workflow_dispatch:

jobs:
  build_and_push:
    name: build and push container image
    runs-on: ubuntu-latest
    steps:
      - name: checkout repository
        uses: actions/checkout@v2

      - name: login
        run: echo "${{ secrets.GHCR_TOKEN }}" | docker login --username "${{ github.repository_owner }}" --password-stdin ghcr.io

      - name: build
        run: docker build --tag "ghcr.io/${{ github.repository_owner }}/greeting:latest" .

      - name: push
        run: docker push "ghcr.io/${{ github.repository_owner }}/greeting:latest"

このワークフローでは、ソースコードをチェックアウトして、レジストリにログインして、コンテナイメージをビルドして、レジストリにプッシュする、という一連の流れを記述している。 レジストリへのログインの時にはGitHubのPersonal Access Tokenを利用する必要があり、ここではsecrets.GHCR_TOKENで指定している。 Personal Access Tokenについては次で説明する。

(4) Personal Access Tokenの作成

GitHub Container Registryの認証にはPersonal Access Tokenが必要なので、ここで作成しておく。 ドキュメントによると、Personal Access Tokenでは「read:packages」と「write:packages」と「delete:packages」の3つのスコープをチェックしておくことになる。

f:id:redj:20201217011740p:plain

そして、このPATをリポジトリのsecretsに登録する。ここではGHCR_TOKENという名前にしている。

f:id:redj:20201217014935p:plain

ちなみに、GitHub Actionsのワークフローの中では、secrets.GITHUB_TOKENという暗黙のPersonal Access Tokenが利用できるのだが、現時点ではこれを利用しての認証はできないようだ。 Docker社のブログには以下のようにある。

Unfortunately what this means is the automatically generated GITHUB_TOKEN will not work for authentication for the initial release. You will have to go to GitHub, generate a personal access token, and create a GitHub Action secret.

言葉を補って訳すと以下になる。

残念なことだが、このことは、GitHub Container Registryの初期リリースにおいて、自動で生成されるGITHUB_TOKENでは認証がうまく機能しないことを意味している。 そのため、GitHubのWebサイトにアクセスし、personal access tokenを生成し、そしてGitHub Actionのsecretを作成しなければならない。

(5) Feature Previewを有効化

GitHub Container Registryは、本ブログの執筆時点ではまだFeature Previewであり、デフォルトでは無効化されている。 そのため、ワークフローの実行前に有効化しておく必要がある。 まずはGitHubのサイトの画面右上のメニューから「Feature Preview」を選択する。

f:id:redj:20201217033900p:plain

そして、「Improved Container Support」のボタン「Enable」をクリックして有効化する。

f:id:redj:20201217033913p:plain

(6) ワークフローの実行

以下の画面のように、作成したワークフローのジョブ「build and push container image」を実行する。

f:id:redj:20201217033939p:plain

ジョブの実行が完了すると、以下の画面のように実行時の標準出力を確認することができる。 ここではdocker pushが成功していることが分かる。

f:id:redj:20201217035745p:plain

(7) コンテナイメージの公開の設定

デフォルトではコンテナイメージは非公開(private)になっているので、公開(public)にしておく。 この手順は、当該コンテナイメージを最初にGitHub Container Registryに登録したときだけ行えばよい。 タブ「Packages」で「Packages settings」を開き、「Make this packages public」でボタン「Make public」をクリックする。

f:id:redj:20201217233127p:plain

コンテナイメージの公開は必須ではないが、以下の2点を気に留めておく必要がある。

  • コンテナイメージの取得(docker pull等)には、コンテナレジストリへのログイン(docker login)が必要になる
  • Feature Previewが終了してGeneral Availableになった際に、非公開のコンテナイメージは課金対象になる可能性がある

(8) 動作確認

docker runを実行して動作確認。

$ docker run ghcr.io/jaybanuan/greeting
Unable to find image 'ghcr.io/jaybanuan/greeting:latest' locally
latest: Pulling from jaybanuan/greeting
Digest: sha256:90659bf80b44ce6be8234e6ff90a1ac34acbeb826903b02cfa0da11c82cbc042
Status: Downloaded newer image for ghcr.io/jaybanuan/greeting:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

上記の通り、Hello from Docker!というメッセージと、その下に解説文が表示されれば、動作確認は成功である。

参考

暗号化ソフトウェアに関する米国輸出管理規制

はじめに

アメリカのサーバ(例えばGoogle Playなど)からソフトウェアを配布する場合、アメリカからの輸出とみなされるため、アメリカの輸出管理規制(EAR: Export Administration Regulations)に従う必要がある。 特に、暗号化ソフトウェアや暗号化を利用するソフトウェアに関する規制は、注意深く対応する必要がある。

Bureau of Industry and Security

日本語の情報源

分類の事例

サービスの方針の事例

自分のVisual Studio Codeの設定 (2020/11版)

はじめに

諸事情で複数の開発環境を使い分ける必要があり、環境ごとにVisual Studio Codeの設定を合わせるのが面倒。 なので、設定を使い回せるように、自分のVisual Studio Codeの設定をメモしておく。

settings.json

{
    "editor.fontFamily": "'MS Gothic'",
    "editor.fontSize": 18,

    "editor.renderWhitespace": "all",
    "workbench.colorCustomizations": {
        "editorWhitespace.foreground": "#00B000"
    },

    "files.autoGuessEncoding": true,
    
    "[plaintext]": {
        "editor.detectIndentation": false,
        "editor.insertSpaces": false,
        "editor.comments.insertSpace": false
    }
}

画面イメージは以下のようになる。

f:id:redj:20201128143038p:plain

フォント

Windowsではデフォルトだと等幅フォントではないので、MS Gothicに変更する。 また、フォントサイズはデフォルト14だが、少し大きめに18にしておく。

{
    "editor.fontFamily": "'MS Gothic'",
    "editor.fontSize": 18,

    (略)
}

ちなみに、複数のフォントを指定すると、フォントが見つからない場合にCSSの仕様に従って(?)順にフォールバックしていくらしい。

空白の表示

空白を可視化しておくと、半角スペースのつもりで全角スペースだったとか、タブにしたかったのに空白に変換されていたとか、そういったミスを減らせる。

{
    (略)
    "editor.renderWhitespace": "all",
    "workbench.colorCustomizations": {
        "editorWhitespace.foreground": "#00B000"
    },
    (略)
}

文字コードの自動識別

大抵はUTF 8を使っているが、時々Shift JISも使うので、文字コードの自動識別を有効化しておく。

{
    (略)
    "files.autoGuessEncoding": true,
    (略)
}

テキストファイルでのタブの入力

テストデータをテキストファイルに書いておくことがあるので、そういう場合はタブを勝手にスペースに変換されると困る。 言語plaintextでタブを入力できるようにしておく。

{
    (略)
    "[plaintext]": {
        "editor.detectIndentation": false,
        "editor.insertSpaces": false,
        "editor.comments.insertSpace": false
    }
}

ちなみに、どの言語にも紐付けられていない拡張子を持つファイルは「plain text」になるようだ。 言語個別の設定方法の詳細は以下に説明がある。