全力で怠けたい

怠けるために全力を尽くしたいブログ。

Mac で Shift＋Command＋ ], [ の同時押しで tmux のウィンドウ間を移動する方法。

productive Mac

はじめに

tmux を使い始めたばかりだが、とても便利に使っている。

しかしながら、tmux のウィンドウ間を移動するデフォルトのキーバインドは、プレフィックスキーを押した後に Ctrl + n / Ctrl + p を押すというもので、これが少々面倒くさいと感じていた。 自分の場合、tmux のウィンドウ間の移動はプレフィックスキーを押した後にウィンドウ番号を押す、というキー操作を使うことが多いのだが、1つ次のウィンドウ / 1つ前のウィンドウへの移動は、プレフィックスキーを押すことなくサッと移動したいためだ。

そこで、Safari や多くのアプリケーションで採用されている、Shift＋Command＋ ], [ の同時押しで tmux のウィンドウ間を移動するようにしたところ、非常に捗るようになった。 このやり方をメモしておく。

tmux のバージョン。

$ tmux -V
tmux 3.3a

macOS のバージョン。

$ sw_vers | grep Product
ProductName:            macOS
ProductVersion:         13.5.1

やり方

やり方はごくシンプルで、ターミナルソフトへの Shift＋Command＋ ], [ キーの入力を、 tmux への プレフィックスキー & Ctrl + n / Ctrl + p に置き換えてしまう、というもの。 キー入力の置き換えには Karabiner-Elements を使う。

具体的には、次の変換ルールを Karabiner-Elements に追加するだけでよい。 自分は iTerm2 を使っているが、bundle_identifiers のところをいじれば、他のターミナルソフトでも同じことができると思う。

ただし、このやり方は Shift＋Command＋ ], [ の入力を他のキー入力に置き換えてしまうので、同ショートカットキーでの iTerm2 のタブ移動はできなくなってしまう。 しかしながら、個人的にはターミナルソフトを使うときはほとんど tmux を使っているので、ほとんど困ったことはない。

{
  "title": "change shift + command + square-bracket to ctrl + square-bracket",
  "rules": [
    {
      "description": "change shift + command + [ to ctrl + g and p",
      "manipulators": [
        {
          "type": "basic",
          "description": "change shift + command + [ to ctrl + g and p if iterm2",
          "from": {
            "key_code": "close_bracket",
              "modifiers": {
                "mandatory": [
                  "left_command",
                  "left_shift"
                ],
                "optional": ["any"]
              }
          },
          "to": [
            {
              "key_code": "g",
              "modifiers": [
                "left_control"
              ]
            },
            {
              "key_code": "p",
              "modifiers": []
            }
          ],
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": [
                "^com\\.googlecode\\.iterm2$"
              ]
            }
          ]
        }
      ]
    },
    {
      "description": "change shift + command + ] to ctrl + g and n",
      "manipulators": [
        {
          "type": "basic",
          "description": "change shift + command + ] to ctrl + g and n if iterm2",
          "from": {
            "key_code": "backslash",
            "modifiers": {
              "mandatory": [
                "left_command",
                "left_shift"
              ],
              "optional": ["any"]
            }
          },
          "to": [
            {
              "key_code": "g",
              "modifiers": [
                "left_control"
              ]
            },
            {
              "key_code": "n",
              "modifiers": []
            }
          ],
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": [
                "^com\\.googlecode\\.iterm2$"
              ]
            }
          ]
        }
      ]
    }
  ]
}

参考サイト

自分的 .tmux.conf の設定。

productive Mac

はじめに

tmux はごく一時期だけ使っていたことがあったが、あまり有用性を感じられず、その後はずっと使っていなかった。 少し前からまた使うようにしていて、まだ2週間くらいしか使っていないのだが、とても便利に使っていて、非常に有用性を感じている。

tmux.conf での設定はまだ少ないが、だいぶ使いやすくなったと思うので、内容をメモしておく。

tmux のバージョン。

$ tmux -V
tmux 3.3a

macOS のバージョン。

$ sw_vers | grep Product
ProductName:            macOS
ProductVersion:         13.5.1

あと、自分が使っている MacBook Pro は JIS 配列のものになる。

.tmux.conf でのカスタマイズ

プレフィックスキー

プレフィックスキーは Ctrl + b から Ctrl + g に変更した。

キーボード上では g と b は斜めに隣接しているキーではあるのだが、自分の場合は g のほうが b よりも断然押しやすく、手にかかる負担もだいぶ小さく感じる。 個人的には「プレフィックスキーを押すのがダルい」と感じていたのだが、Ctrl + g に変えてからはあまり気にならなくなった。

また、プレフィックスキーの候補はいくつかあったが、Ctrl + g は Mac のシステムショートカットキーや他のアプリと競合しない *1 ことも決め手となった。左手だけで押せるのもよい。

unbind C-b
set -g prefix C-g

プレフィックスキーを押した後、コマンドを連続入力できる長さ

プレフィックスキーを押した後、コマンドを連続入力できる時間を1000ミリ秒に変更した。

プレフィックスキーを押した後、デフォルトでは 500ミリ秒の間はコマンドを連続入力できるが、ウィンドウを複数のペインに分割している場合等、パッと移動先のキーを打てないことがあったため。 もう少し短くてもいいかもしれない。

set -g repeat-time 1000

ウィンドウ、ペインのインデックスは1から始める

ウィンドウ、ペインのインデックスは1から始めるように変更した。 ターミナルソフトは iTerm2 を使っているのが、iTerm2 ではタブ番号は1から始まるため、それに合わせた形になる。

set -g base-index 1
set -g pane-base-index 1

あと、ウィンドウを閉じたときにインデックスが詰まるようにしている。

set -g renumber-windows on

ペインの操作

ペインを | で水平分割、- で垂直分割するように変更した。

bind -r | split-window -h -c '#{pane_current_path}'
bind -r - split-window -v -c '#{pane_current_path}'

ペインの移動を Vim ライクなキーバインドで行えるように変更した。

bind -r h select-pane -L
bind -r j select-pane -D
bind -r k select-pane -U
bind -r l select-pane -R

ペインのサイズ調整を Vim ライクなキーバインドで行えるように変更した。

bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5

また、Ctrl + z でペインを最大化 / 元に戻せるようにしてある。

bind -n C-z resize-pane -Z

新規のウィンドウをカレントディレクトリで開く

新規のウィンドウを開く際、カレントディレクトリが作業ディレクトリになるようにした。

bind c new-window -c '#{pane_current_path}'

マウスでスクロールできるようにする

マウスホイールでスクロールできるように変更した。

マウスをホイールすると、デフォルトではコマンド履歴をスクロール (？) するようになっているが、バッファをスクロールするようにした。

set -g mouse on
set -g terminal-overrides 'xterm*:smcup@:rmcup@'

ステータスラインをいい感じにする

ステータスラインがいい感じになるように、最小限だが変更した。

set -g status-justify "centre"
set -g status-bg green
setw -g window-status-current-style fg=default,bg=magenta
set -g status-interval 5

コピー操作

コピーモードに入った後、Vim ライクなキーバインドで操作できるように変更した。

setw -g mode-keys vi

デフォルトでは Space で範囲選択を開始するが、Vim ライクに v で範囲選択を開始するように。

bind -T copy-mode-vi v send-keys -X begin-selection

デフォルトでは Enter で選択範囲をコピーするが、Vim ライクに y で範囲選択をクリップボードにコピーするように。

bind -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "pbcopy"

通常の範囲選択 / 矩形選択の切り替えを、Vim ライクに Ctrl + v で範囲選択を開始するように。

bind -T copy-mode-vi C-v send-keys -X rectangle-toggle

Shift＋Command＋ ], [ の同時押しで tmux のウィンドウ間を移動する

個人的には、tmux が最高に手に馴染むようになった設定 → Mac で Shift＋Command＋ ], [ の同時押しで tmux のウィンドウ間を移動する方法。

参考サイト

*1:Vim と競合してしまうが、Vim のほうではあまり使わないキーなので許容した

Pixela の CLI ツール pa が v1.9.0 にバージョンアップしました。

Pixela command y2

Pixela の CLI ツール pa が v1.9.0 にバージョンアップしました。

v1.9.0 アップデート内容

Pixela v1.27.0 に対応するバージョンアップとなります。

具体的には、graph stats サブコマンドで取得できる情報に maxDate, minDate, yesterdayQuantity フィールドが追加されています。

自分は仕事で残業した時間を Pixela に記録しているんですが、最長の残業時間を記録したブラックな日がいつなのか、一目で分かってしまってしまいます。 残業時間はともかく、Pixela の1ユーザーとしては、maxDate, minDate の2つは便利だなと感じることが多いです。 pa を使われている方には、ぜひ v1.9.0 にアップデートして、Pixela v1.27.0 で追加されたフィールドを試してみていただきたいですね。

$ pa graph stats --id <残業記録> | jq
{
  "totalPixelsCount": 884,
  "maxQuantity": 10,
  "maxDate": "2019-08-03",
  "minQuantity": 0,
  "minDate": "2018-06-01",
  "totalQuantity": 1810,
  "avgQuantity": 2.05,
  "todaysQuantity": 1,
  "yesterdayQuantity": 0
}

v1.9.0 へのアップグレード方法

Homebrew を使っている場合は、次のコマンドにてアップグレードできます。

$ brew update && brew upgrade pa

go install コマンドでアップグレードすることもできます。

$ go install github.com/ebc-2in2crc/pa/cmd/pa@latest

現場からは以上です。

pixela4go が v1.8.0 にバージョンアップしました。

Pixela y2

pixela4go が v1.8.0 にバージョンアップしました。

Pixela v1.27.0 に対応するバージョンアップとなります。

v1.8.0 アップデート内容

Pixela v1.27.0 で /stats API に追加された、maxDate, minDate, yesterdayQuantity の3つのフィールドに対応しています。

Pixela の1ユーザーとしては、maxDate, minDate の2つは便利だなと感じることが多いです。 pixela4go を使われている方には、ぜひ v1.8.0 にアップデートして、Pixela v1.27.0 で追加されたフィールドを試してみていただきたいですね。

現場からは以上です。

GoLand の Find Usages 機能で、プロダクションコード / テストコードだけを検索する方法。

GoLand

はじめに

JetBrains 製の Go 言語向け IDE の GoLand に搭載されている Find Usages 機能で、プロダクションコード / テストコードだけを検索する方法について記載する。

GoLand の Find Usages 機能は、変数を参照 / 値を設定したり、関数やメソッドを呼び出している箇所を調べられる機能で、とても便利。 しかしながら、変数や関数の参照元 / 呼び出し元を調べる際、デフォルトでは「プロダクションコードからの参照だけを調べたい」「テストコードからの呼び出しだけを調べたい」ということができず、少々不便さを感じる *1

でも、GoLand でも少し設定を追加してあげると、プロダクションコード / テストコードだけを検索できるようになる。 以下、その設定方法について記載していく。

Find Usages 機能で、プロダクションコード / テストコードだけを検索する方法

Preferences > Settings > Appearance & Behavior > Scopes にて、次の2つのスコープを追加する。

  1. プロダクションコードだけを検索するスコープ
    • Name: Project Production Files
    • Pattern: file:*/&&!file:vendor//*&&!file:*_test.go
  2. テストコードだけを検索するスコープ
    • Name: Project Test Files
    • Pattern: file:*/&&!file:vendor//*&&file:*_test.go

あとは、Find Usages 機能を使う際に目的に応じたスコープを指定することによって、プロダクションコード / テストコードだけを検索することができる。

↓スコープ: All Places を指定したとき

↓スコープ: Project Production Files を指定したとき

↓スコープ: Project Test Files を指定したとき

以上。

参考サイト

*1:このあたり、同じ JetBrains 製の IntelliJ IDEA の場合は、プロダクションコードだけ / テストコードだけを調べる、ということがデフォルトでできるので、GoLand でもデフォルトでできるようになるといいな、と思っている

AWS Elastic Beanstalk にて構築した環境にアプリケーションをデプロイする際、更新処理がタイムアウトしてしまう事象の解消方法。

AWS Beanstalk

はじめに

AWS の Elastic Beanstalk にて構築した環境にアプリケーションをデプロイする際、Beanstalk 環境の更新処理がタイムアウトしてしまう事象が発生した。

結論としては、アプリケーションサーバーをホストしている EC2 インスタンスを入れ替えることで、事象が解消した。

この事象を解消するために行ったこと、調査したことを記載していく。

事象

AWS の Elastic Beanstalk にて構築した環境にアプリケーションをデプロイする際、Beanstalk 環境の更新処理がタイムアウトしてしまう事象が発生した。

INFO    Environment update is starting.
INFO    Deploying new version to instance(s).
INFO    Environment health has transitioned from Ok to Info. Application update in progress on 1 instance. 0 out of 1 instance completed (running for 30 seconds).
ERROR   During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version.
ERROR   Failed to deploy application.
ERROR   Unsuccessful command execution on instance id(s) '<インスタンス ID>'. Aborting the operation.
INFO    Command execution completed on all instances. Summary: [Successful: 0, TimedOut: 1].
WARN    The following instances have not responded in the allowed command timeout time (they might still finish eventually on their own): [<インスタンス ID>].
WARN    Environment health has transitioned from Info to Warning. Application update is aborting (running for 14 minutes).

また、アプリケーションのデプロイ以外の操作ではどうなるか？ を確認するためにアプリケーションサーバーを再起動したところ、やはり Beanstalk 環境の更新処理がタイムアウトしてしまうことが分かった。 次のような挙動から、アプリケーションサーバーをホストしている EC2 インスタンスにて異常が発生している可能性が高いと想定した。

  • 事象が発生している Beanstalk 環境のアプリケーションサーバーの再起動は、普段であれば数十秒もかからずに完了する
  • Beanstalk 環境の更新ログの内容が、アプリケーションのデプロイに失敗している際のログと同じような内容になっている
INFO    restartAppServer is starting.
INFO    Environment health has transitioned from Ok to Info. Application restart in progress (running for 4 seconds).
ERROR   Unsuccessful command execution on instance id(s) '<インスタンス ID>'. Aborting the operation.
INFO    Command execution completed on all instances. Summary: [Successful: 0, TimedOut: 1].
WARN    The following instances have not responded in the allowed command timeout time (they might still finish eventually on their own): [<インスタンス ID>].
INFO    Environment health has transitioned from Info to Ok. Application restart completed 57 seconds ago and took 14 minutes.

次に、アプリケーションサーバーをホストしている EC2 インスタンスのログを調べた。

アプリケーションサーバーをホストしている EC2 インスタンスに SSH ログインし、各種ログを調べたところ、/var/lib/log/message にて、cfn-hup.service が停止 / 起動を繰り返していることを示唆するログが出力されていた。 cfn-hup.service は、Beanstalk の環境を更新する際、ユーザーが指定した操作を実行するデーモンのようで、サーバーのデプロイがタイムアウトしてしまうのは、cfn-hup.service が停止 / 起動を繰り返していて、ユーザーが指定した操作が実行されていない可能性が高そう。

The cfn-hup helper is a daemon that detects changes in resource metadata and runs user-specified actions when a change is detected. This allows you to make configuration updates on your running Amazon EC2 instances through the UpdateStack API action.

↓ /var/lib/log/message に出力されていた、cfn-hup.service が停止 / 起動を繰り返しているログ

systemd: cfn-hup.service: main process exited, code=exited, status=1/FAILURE
systemd: Unit cfn-hup.service entered failed state.
systemd: cfn-hup.service failed.
systemd: cfn-hup.service holdoff time over, scheduling restart.
systemd: Stopped This is cfn-hup daemon.
systemd: Starting This is cfn-hup daemon...
systemd: Started This is cfn-hup daemon.

事象を解消するために行ったこと

ユーザーが指定した操作がタイムアウトしてしまう原因は、cfn-hup.service の異常動作にある可能性が高そう。 ということは、cfn-hup.service を再起動することで事象が解消できそうだが、すでに cfn-hup.service が停止 / 開始を繰り返している状態のため、cfn-hup.service を再起動しても事象が解消されない可能性がある *1

今回は、アプリケーションサーバーをホストしている EC2 インスタンスを入れ替えて、事象を解消した *2

事象が発生していたアプリケーションサーバーは部内でのみ使われているもので、多少ダウンタイムが発生してもまったく問題がないものではあったが、ダウンタイムを極小化するため、次のようにして EC2 インスタンスを入れ替えた。

  1. アプリケーションサーバーをホストする EC2 インスタンスはもともと1台だったが、1台増やして2台にする
  2. 元々の EC2 インスタンスを停止する
    • 新しい EC2 インスタンスが起動してくる
    • 新しく起動した EC2 インスタンスは、cfn-hup.service が問題なく稼働していることを確認
    • つまり、起動している 2台の EC2 インスタンスは、cfn-hup.service が問題なく稼働しているということ
  3. アプリケーションサーバーをホストする EC2 インスタンスを1台減らし、2台→1台にする
    • 残った1台の EC2 インスタンスは、cfn-hup.service は問題なく稼働しているということ

以上。

参考サイト

*1:実際に cfn-hup.service を再起動してみたが、事象が解消されなかった

*2:後から思ったことだけど、やっぱりまずは cfn-hup.service の再起動を行えばよかったとは思う

パーセンタイル値を計算する percentile コマンドを作りました。

command y2

What is percentile コマンド？

データ分析において、パーセンタイル値はしばしば重要な指標となります。

percentile コマンドは、ファイルや標準入力から数値を読み込み、パーセンタイル値を表示する CLI プログラムです。

github.com

percentile コマンドの特長

percentile コマンドには、次のような特徴があります。

  1. ファイルおよび標準入力から数値を読み込み、読み込んだ数値のパーセンタイル値を表示する
  2. 読み込んだ数値はデフォルトでソートされるため、事前にソートする必要がない
  3. 表示するパーセンタイル値は、デフォルトでは p25, p50, p75, p90, p95, p99 だが、オプションで指定することができる
  4. パーセンタイル値はデフォルトでは切り捨てられるが、切り捨てないようにオプションで指定できる

使い方の実行例

percentile コマンドを実行する例を示します。

ファイルから数値を読み込む

percentile <ファイル> と実行すると、ファイルから読み込んだ数値のパーセンタイルを表示します。

$ percentile <(seq 1 100)
p25: 25
p50: 50
p75: 75
p90: 90
p95: 95
p99: 99

標準入力から数値を読み込む

<他のコマンド> | percentile - と実行すると、標準入力から読み込んだ数値のパーセンタイルを表示します。

$ seq 1 100 | percentile -
p25: 25
p50: 50
p75: 75
p90: 90
p95: 95
p99: 99

表示するパーセンタイル値を指定する

表示するパーセンタイル値は、デフォルトでは p25, p50, p75, p90, p95, p99 ですが、-p オプションで表示するパーセンタイル値を指定できます。 表示するパーセンタイル値が複数ある場合は、-p 25,50 のようにカンマで区切ります。

$ seq 1 100 | percentile -p 25,50 -
p25: 25
p50: 50

パーセンタイル値を切り捨てない

表示するパーセンタイル値は、デフォルトでは切り捨てられて整数になりますが、-r オプションを指定すると小数点第1位までが表示されます。

$ seq 1 100 | percentile -r -
p25: 25.5
p50: 50.5
p75: 75.5
p90: 90.5
p95: 95.5
p99: 99.5

インストール方法

percentile をインストールするには、以下の方法があります。

開発者向け

Go 言語の開発環境が整っている場合は、次のコマンドを実行することにより、percentile コマンドをインストールできます。

$ go install github.com/ebc-2in2crc/percentile/cmd/percentile@latest

手動でのインストール

https://github.com/ebc-2in2crc/percentile/releases にアクセスし、お使いの OS 向けの実行ファイルをダウンロードできます。

Homebrew

Homebrew を使う場合は、次のコマンドを実行することにより、percentile コマンドをインストールできます。

$ brew install ebc-2in2crc/tap/percentile

動機

最近、ちょっとしたデータ分析をする際に、パーセンタイル値を求めることが何回かありました。

CLI でパーセンタイル値を求められるコマンドを探したところ、そういったツールはいくつかあったのですが、次のようなところが自分の使い方にはマッチしませんでした。

  • 数値の読み込み元として、ファイルと標準入力の両方をサポートしていない
  • 表示するパーセンタイル値が固定されてしまっている

そこで、パーセンタイル値を計算 & 表示するコマンドをサッと実装してしまいました *1

まとめ

percentile の開発やバグレポート、質問などがあったら、GitHub のリポジトリに issue や PR を作ったり、Twitter でお気軽にお声がけいただけたら嬉しいです。

github.com

ということで、 percentile コマンドの紹介でした。

*1:また、再発明をしてしまいました