Mac の iTerm2 上で Home/End キーを使いたい

MacBook に PC 用キーボードをつないで使っていますが、Terminal での行頭/行末移動が不便。なので、Windows 同様、Home/End キーで行頭/行末移動ができるようになりたい。

というのを実現したのでその手順を。

なお、 以下手順は iTerm2 で確認しています。標準のターミナルでは使えないようです。

  1. Home/End キーの Escape Sequence を確認
    iTerm2 上で Ctrl+V の直後に特殊キーを押すと、そのキーのエスケープコードが表示されます。例えば Ctrl+V Home と押すと、^[[HCtrl+V End^[[F が出力されます。

  2. bindkey コマンドでエスケープコードと動作の関連付けを行う
    (zshの場合 )1 で確認した Escape Sequence にカーソル移動の動作を紐つけます。(.zshrc などに追記しておくといいでしょう)

bindkey "^[[H" beginning-of-line
bindkey "^[[F" end-of-line     

※試してませんが、bash なら bind -x でも同様のことができるかも知れません。

以上で、 iTerm2 上で Home/End キーによる行頭/行末移動ができるようになります。

anyenv で tfenv を入れると init でエラーが出るので回避する

数多ある *env 系のツール導入をぐっと簡単にしてくれる anyenv ですが、現行バージョン (1.1.1) では、tfenv を導入すると、シェルログイン時にエラーが出るようになります。

No such command 'init'
Usage: tfenv <command> [<options>]

Commands:
   install       Install a specific version of Terraform
   use           Switch a version to use
   uninstall     Uninstall a specific version of Terraform
   list          List all installed versions
   list-remote   List all installable versions

anyenv はログイン時、導入されている *env すべての init サブコマンドを順に実行するのですが、 tfenv には init サブコマンドがないのでエラーとなるようです。

修正 PR も上がっているようなのでそのうち取り込まれると思いますが、当面の回避方法のメモ。

ここでは、Mac で homebrew を使って anyenv をインストールした前提で書きます。

anyenv のインストール先を確認

% brew ls anyenv
/usr/local/Cellar/anyenv/1.1.1/bin/anyenv
/usr/local/Cellar/anyenv/1.1.1/completions/ (3 files)
/usr/local/Cellar/anyenv/1.1.1/libexec/ (14 files)

で、 libexec 以下の anyenv-init を修正します。

% cp /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init.backup
% vim /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init

修正内容は以下のような感じ。

% diff -up /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init.backup /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init
--- /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init.backup 2020-01-26 22:57:10.000000000 +0900
+++ /usr/local/Cellar/anyenv/1.1.1/libexec/anyenv-init    2020-01-26 22:59:09.000000000 +0900
@@ -140,5 +140,5 @@ for env in $(anyenv-envs); do
     ;;
   esac

-  echo "$(${ENV_ROOT}/bin/${env} init - ${no_rehash_arg}${shell})"
+  [ "${env}" != 'tfenv' ] && echo "$(${ENV_ROOT}/bin/${env} init - ${no_rehash_arg}${shell})"
 done

homebrew を使わず git clone でインストールした場合は、 .anyenv/libexec/anyenv-init を同じように修正すればOKです。

本当はちゃんと 「init のない *env」を判定したいところなんですが、まあ一時的な回避策ということで。

CircleCI で CIRCLE_SHA1 を使う場合の注意

過去に自分がミスった内容と似た事例を他にも見かけたので、今更ながらメモ。

TL; DR

  • CircleCI の ECS/ECR へのデプロイに関するドキュメントで、コンテナイメージのタグに CIRCLE_SHA1 の値が設定されているが、これには要注意
  • CircleCI における CIRCLE_SHA1 の値は、最終コミットを識別するハッシュ値だよ
  • Git上のブランチやタグに依って変わるわけではないので、ブランチ・タグによって異なるものの識別には使えないよ
  • イメージタグのような識別子を作成する場合、それが必要なユニーク性を持っているか確認することが必要だよ

CircleCI で ECR/ECS にデプロイするときのコンテナイメージタグ

CircleCI 公式のドキュメントとして、以下の記事が公開されています。 (2019/12/15現在)

AWS ECR/ECS へのデプロイ - CircleCI

上記記事より引用

version: 2.1
orbs:
  aws-ecr: circleci/aws-ecr@0.0.2
  aws-ecs: circleci/aws-ecs@0.0.3
workflows:
  build-and-deploy:
    jobs:
      - aws-ecr/build_and_push_image:
          account-url: "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com"
          repo: "${AWS_RESOURCE_NAME_PREFIX}"
          region: ${AWS_DEFAULT_REGION}
          tag: "${CIRCLE_SHA1}"
      - ...

ビルドの結果出来上がる個々の コンテナイメージを識別するものとしてタグを設定します(上記例の tag )が、ここでは、タグに設定する値は "${CIRCLE_SHA1}" となっています。

(以前のドキュメントでは、普通に docker コマンドを使用して docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com:${CIRCLE_SHA1} という感じになっていたはず…)

CIRCLE_SHA1 って?

さて、この CIRCLE_SHA1 に設定される値はどのようなものでしょうか。こちらも CircleCI の公式ドキュメントで説明されています。

環境変数の使い方 - CircleCI

CIRCLE_SHA1 String 現在のビルドの最後のコミットに関する SHA1 ハッシュ。

VCS が Git であれば、 Git のコミットハッシュと同一の値になります。CircleCI でビルドを開始する際に Git リポジトリから取得した内容 (バージョン断面) を識別するものと考えていいと思います。

コンテナイメージタグに CIRCLE_SHA1 を設定すると

この CIRCLE_SHA1 をコンテナイメージタグに使うと、どうなるでしょう?

「Git リポジトリの内容が同一ならば、ビルドされるコンテナイメージも同一である」という条件が成り立つのであれば、これで問題ありません。CIRCLE_SHA1リポジトリの内容ごとにユニークであるので、そこと 1:1 に対応付けられるコンテナイメージも CIRCLE_SHA1 で識別することができます。

しかし、上記の条件が必ずしも成り立たない場合、つまりGitリポジトリが同一であっても、できあがるコンテナイメージが異なる場合がある(異なるイメージそれぞれを管理する必要がある)場合は注意が必要です。

例えば、よく見かける方式として、本番環境やステージング環境にリリースを行うために、Git 上の master から特定のブランチにマージし、それをトリガーとして CircleCI で各環境向けのビルドおよびデプロイを行う、という方式を考えます。

コンテナイメージ内に環境の情報を含める場合は、当然、リポジトリの内容が同一であっても、本番環境向けとステージング環境向けでできあがるコンテナイメージに差異が発生します。しかし、 CIRCLE_SHA1 の値は、トリガーとなったブランチに依らず。あくまでも最終コミットのハッシュ値によって決定されるため、それぞれのコンテナイメージに同一のタグが設定されることになります。

Docker および ECR の仕様上、すでに存在するタグと同一のタグを付与して Push した場合、古い方のイメージからはタグが剥がされてしまうため、例えば ステージング環境へのデプロイ後に本番環境へのデプロイを行った場合、ステージング環境の ECS クラスタにも本番環境用のコンテナイメージがデリバリされてしまうことになります。また、並行して複数環境のビルド・デプロイを行って、完了する順番が不定となるような場合、見かけ上ランダムにコンテナイメージが切り替わるため、再現検証の難しい障害となることがあります。

回避方法

この問題をするには、以下のやり方が考えられます

  • ECR リポジトリを環境ごとに用意する
  • CIRCLE_SHA1 以外の、適切な識別文字列を用意する。
  • タグにデプロイ先環境を識別する文字列を付加する

インフラ構成や実装の手間、ユニーク性の要件、費用等に合わせた方法を取るとよいでしょう。

まとめ

CIRCLE_SHA1 (に限りませんが) を何かの識別子として使用する場合、そのユニーク性が識別する対象のユニーク性と合致するかどうか、毎回きちんと検証しましょうというお話でした。

必要最低限のrequirements.txtを作成する (virtualenv版)

2017年に書いた、「必要最低限のrequirements.txtを作成する」という記事に未だに多少のアクセスがありまして、今現在でこれを参考にされてしまうとちょっとアレだなあと思いましたので。

(当時は Docker 憶えたてでイキっていました。反省)

noisyspot.hatenablog.com

クリーンな Python 環境を得るには virtualenv がおすすめ

virtualenv は、システムの Python 環境から、任意のディレクトリ以下に最低限のライブラリや実行ファイルをコピーし、クリーンな仮想 Python 環境を構成できるツールです。

virtualenv.pypa.io

通常は、開発したいプロジェクトやプロダクトごとに仮想環境を構成し、そのプロダクトに必要なライブラリだけ仮想環境にインストールして使用する、という使い方になると思いますが、開発で試行錯誤した結果、開発環境がプロダクションに不要なライブラリで汚染されていて整理したい、なんてこともあると思います。

そんなときは慌てず、別のディレクトリに改めてクリーンな仮想環境を作って、作成したソースコードをコピーした上で、改めて必要最低限のライブラリを pip install してテストし、問題なければ pip freeze してあげれば良いです。

使い方

virtualenv が未インストールであれば、インストールします。 pip install virtualenv でインストールできますが、特定のバージョンを入れたいなどオプションについてはドキュメントを参照

仮想環境を作りたいディレクトリに移動し、環境を作成します。

$ mkdir -p ~/path/to/project
$ cd ~/path/to/project
$ virtualenv .
Using base prefix '/home/user/.pyenv/versions/3.7.5'
New python executable in /home/user/path/to/project/bin/python3.7
Also creating executable in /home/user/path/to/project/bin/python
Installing setuptools, pip, wheel...
done.

すると、このディレクトリの下に bin, include, lib というディレクトリができます。bin 以下にある activate というスクリプトを source すると、仮想環境を使用するモードになります。

$ source bin/activate
(project) $   

プロンプトに (ディレクトリ名) が付加されていれば、そのディレクトリの仮想環境に入っている状態です。

この状態で、必要なライブラリを pip install し、 pip freeze すれば、明示的にインストールしたライブラリと依存ライブラリだけのリストが出力されます。

仮想環境から出たい場合は deactivate コマンドを実行する ( activate 時に alias が設定されている ) か、シェルからログアウトしてください。

細かすぎて伝わらないJava10のvar仕様

いろいろ試したのでメモ。

初期化時に型が決まる

まあ当たり前ですが。

public class Main {
    public static void main(String... args) {
        var hoge = 1;              // hoge は int型になる
        hoge = 2147483648;         // Integer.MAX_VALUE + 1
        System.out.println(hoge);
    }
}
> javac Main.java
Main.java:4: エラー: 整数2147483648が大きすぎます
        hoge = 2147483648; // Integer.MAX_VALUE + 1
               ^
エラー1個

以下のようににすると、iはint型になるので桁溢れして無限ループになります。

for (var i = 0; i < 2147483648; i++) {
....

プリミティブ型も推論してくれる

public class Main {
    public static void main(String... args) {
        var i = 1;
        i.getClass().getName();
    }
}
>javac Main.java
Main.java:4: エラー: intは間接参照できません
        i.getClass().getName();
         ^
エラー1個

余計な Boxing/Unboxing は発生しないようで一安心。

匿名クラスのインスタンスで初期化すると匿名クラス型の変数になる

        var hoge = new Object() {
            int a = 1;
            String s = "Hello!";
            int func(int a, int b) {
                return a + b;
            }
        };

のようにすると、hoge は Object 型ではなくここで定義された匿名クラスの型 (Main$1とか) になります。 従って、この同じメソッドの中であれば、 hoge.ahoge.func(1, 2); のように匿名クラス内のメンバを Interface定義なしで 呼び出すことができます。おもしろいけど使い所あるかな?


以降思いついたら順次追加

無限Streamに終了条件を設定する (Java9版)

noisyspot.hatenablog.com

というのを以前書きましたが、Java9では Stream#takeWhile というメソッドが追加されてこういうケースが簡単に書けるようになりました。

    public static String getTreePathTakeWhile(Node node, String delimiter) {
        List<String> names = Stream.iterate(node, Node::getParent)
                .takeWhile(n -> n != null)
                .map(n -> n.getName())
                .collect(Collectors.toList());
        Collections.reverse(names);

        return delimiter + String.join(delimiter, names);
    }

これでSupplierを使った無限Streamがとても使いやすくなりますね。

必要最低限のrequirements.txtを作成する

シチュエーション

Pythonでつくったサーバーアプリを環境へのデプロイするために、依存モジュールのバージョンを固定したrequirements.txtを作りたいけど、開発環境のPython環境がだいぶ使い古しで、試しに導入した不要なモジュールもあるので、単純にpip freezeしちゃうと余計なモジュールが大量に混ざってしまう…なんてときの対処法。

手順


注(2019/12/08追記):

この記事では Docker を使った方法を説明していますが、 Python だけ気にするのであれば virtualenv を使用する方法のほうがシンプルかつ早いので、そちらを使用しましょう。

noisyspot.hatenablog.com


Dockerできれいな仮想環境を作る

とりあえず、pyenvでPythonをインストールできる最低限の環境を作ります。導入するモジュールによっては追加が要るかも。

以下のようなDockerfileを作る。とりあえずUbuntu14ベースで作ってますが、他のディストロならもうちょっとシンプルになるかも。

FROM ubuntu:14.04

ARG http_proxy
ARG https_proxy

ENV http_proxy=${http_proxy:-} \
    https_proxy=${https_proxy:-}

RUN apt-get update && apt-get install -y \
    build-essential python git curl zlibc zlib1g-dev \
    libssl-dev libreadline-dev libbz2-dev libsqlite3-dev \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /root

RUN git clone https://github.com/yyuu/pyenv.git .pyenv
ENV PATH /root/.pyenv/bin:$PATH
RUN echo 'eval "$(pyenv init -)"' >> .bashrc

CMD ["/bin/bash", "-i"]

これを適当なディレクトリに置いてdocker buildします。

$ cd clean_pyenv # 上記Dockerfileがおいてあるディレクトリに移動
# 直接インターネットが見られる環境の場合
$ docker build -t clean_pyenv ./
# プロキシが必要な場合
$ docker build --build-arg http_proxy=$http_proxy --build-arg https_proxy=$https_proxy -t clean_pyenv ./

仮想環境内で、pyenvを使ってターゲットバージョンのPython環境を作る

上記で作ったDockerイメージにはpyenvがインストール済みなので、これを使って必要な環境を作っていきます。 コンテナを起動してログイン、pyenv installで目的のバージョンをインストールして切り替えます。

$ docker run -it --rm clean_pyenv
$ pyenv install 2.7.13
$ pyenv global 2.7.13

アプリから直接参照しているモジュールのリストを用意してpip install -rした後、pip freezeする

例として、アプリから直接参照している外部モジュールがboto3 1.4.4だけだとします。 (モジュールがたくさんあるようであれば、列挙したテキストファイルを別のターミナルからdocker cpで送り込んであげればよいです。モジュールバージョンが最新でよければ、バージョン番号は省略でもOK)

$ echo boto3==1.4.4 > reqirements_part.txt
$ pip install -r reqirements_part.txt
$ pip freeze > requirements.txt

これで、依存モジュールも含むrequirements.txtが生成されるはずです。

途中間違えたら、コンテナからログアウトして終了してしまえば、pyenvだけのきれいな状態からやり直すことができます。もちろんDockerイメージは再利用可能。