プロンプト表示をカスタマイズが容易な Starship に乗り換えた

Rust製の starship.rs が良さそうだったので乗り換えた。 乗り換えたといっても、プロンプト表示だけなので Shell は Zsh や Fish のまま移行できる。

インストール

$ brew install starship

して zsh を利用しているので 　~/.zshenv に

$ eval "$(starship init zsh)"

と書くだけ。

何が嬉しいの？

こんな感じにディレクトリのgitステータスやリポジトリ配下の言語のバージョンが表示されるようになる。

元々 zsh の RPROMPT とかにgitのブランチ名やステータスを表示していたが、Starshipの方がカンタンかつオシャレに表示できるので乗り換えた。

カスタマイズ

設定 | Starship を参考にしながら.config/starship.toml に設定を記述していくとカスタマイズが可能。

自分の設定を貼り付けて置くので参考にどうぞ。

# 表示順を再定義
prompt_order = [
    "username",
    "hostname",
    "kubernetes",
    "directory",
    "git_branch",
    "git_commit",
    "git_state",
    "git_status",
    "hg_branch",
    "package",
    "dotnet",
    "elm",
    "golang",
    "haskell",
    "java",
    "nodejs",
    "php",
    "python",
    "ruby",
    "rust",
    "terraform",
    "nix_shell",
    "conda",
    "memory_usage",
    "aws",
    "env_var",
    "crystal",
    "cmd_duration",
    "jobs",
    "battery",
    "time",
    "line_break",
    "character",
]

[directory]
truncation_length = 10 # 10ディレクトリまでは省略しない
truncate_to_repo = false # gitのルートディレクトリでもパスを省略しない
style = "bold green" # 太字の緑

[git_commit]
disabled = false # gitのコミットIDを表示する(rebase中などのみ表示される)

[git_state] # gitのステータスに応じて表示するメッセージをカスタマイズ(絵文字を追加)
rebase = "🛠 REBASING"
revert = "💥 REVERTING"
cherry_pick = "🍒 PICKING"

[time] 
disabled = false # 時刻を表示


# 利用予定のないモジュールを明示的に無効化
[dotnet]
disabled = true

[hg_branch]
disabled = true

[nix_shell]
disabled = true

東プレ R2TLA-US4G-BK REALFORCE RGB TKL R2 英語 テンキーレス（87配列）：黒 45g

macOSでcommand+Hを無効にした

macOS の command + H は最小化なのだが、最小化したいユースケースが殆どないにも関わらず、 control + H のつもりで押してしまったりすることが多かったので無効にすることにした。

Karabiner-Elements - Software for macOS で keycode を out にすれば無効になる。

{
    "description": "Disable Left_command + h",
    "manipulators": [
        {
            "from": {
                "key_code": "h",
                "modifiers": {
                    "mandatory": [
                        "left_command"
                    ],
                    "optional": [
                        "any"
                    ]
                }
            },
            "to": [
                {
                    "key_code": "out"
                }
            ],
            "type": "basic"
        }
    ]
}

どうしても利用したかったら right_command + H すればよい。

東プレ R2TLA-US4G-BK REALFORCE RGB TKL R2 英語 テンキーレス（87配列）：黒 45g

入力ソースが3種類以上ある時にVimで検索しようとするとIMEがおかしくなることがあった

macOSの入力ソースを3種類以上設定されている際に、MacVimで iminsert や imsearch の設定を0以外に設定していると想定通りにIMEが切り替わらない事象があった。

入力ソースが3種類ある例

Dvorakユーザーなので、Kinesisなどのハードウェア上でキーボードレイアウト変更が可能なキーボードの場合には ABC (QWERTY) を、 ハードウェア上でレイアウト変更ができないキーボードの場合には Dvorak を適宜選んで利用していた。

が、Vim起動後に QWERTY / Dvorak を切り替えると IME On / Off でなく QWERTY / Dvorak になったりしてしまった。

モード切り替え時にVim上からIMEを制御しないように、

set iminsert=0
set imsearch=-1

とすることで対応した。

プラチナエンド 1 (ジャンプコミックスDIGITAL)

EscでVimのinsertモードを抜けつつIME OFFにして直接入力にする

Vimのinsertモードを抜ける際に、 Esc だけではIMEが有効なままになっていたのをそろそろ見直すことにした。

Karabiner-Elements - Software for macOS のkarabiner.jsonに以下を追加して、 Esc キー押下時に、Esc + 英数キー 押下と同じ挙動を行うようにした。 設定して1ヶ月以上経つが、 Esc を押す度に英数も押されてしまうことによる副作用は今の所まったく感じられない。

    "description": "Change Escape to Escape + Eisuu",
    "manipulators": [
        {
            "from": {
                "key_code": "escape"
            },
            "to": [
                {
                    "key_code": "escape"
                },
                {
                    "key_code": "japanese_eisuu"
                }
            ],
            "type": "basic"
        }
    ]
}

自分は Command + E で Esc としているので、こちらも同様にした。

{
    "description": "Change Left_command + e to Escape + Eisuu",
    "manipulators": [
        {
            "from": {
                "key_code": "e",
                "modifiers": {
                    "mandatory": [
                        "left_command"
                    ],
                    "optional": [
                        "any"
                    ]
                }
            },
            "to": [
                {
                    "key_code": "escape"
                },
                {
                    "key_code": "japanese_eisuu"
                }
            ],
            "type": "basic"
        }
    ]
}

今ではもっと早く設定しておけばよかったと思っているぐらい快適。

東プレ R2TLA-US4G-BK REALFORCE RGB TKL R2 英語 テンキーレス（87配列）：黒 45g

WealthNavi for 住信SBIネット銀行 を解約して、よりおトクな WealthNavi を契約した

TL;DR

住信SBIネット銀行きっかけでWealthNavi for 住信SBIネット銀行を使っていたけれども、WealthNaviの方がおトクなのでWealthNaviに移行した

事の発端

元々住信SBIネット銀行のランク判定条件だったこともありWealthNavi for 住信SBIネット銀行を契約していたが、昨年11月頃にたまたまアプリの不具合で 長期割 というWealthNavi限定のプログラムの存在を知った。

長期割が適用されると、手数料が最大で0.90%まで割引されるようになる。

自分が200万円ほど運用していた時には月々数千円手数料として差し引きされていたことと、向こう数十年引かれる手数料が少し安くなるのは大きなメリットになるのではと思ったので長期割について調べてみることにした。

WealthNavi と WealthNavi for 住信SBIネット銀行 の違い

調べたり実際にウェルスナビ株式会社に問い合わせをした結果、以下の違いがあることがわかった。

WealthNavi

• 独自キャンペーンがある
• 長期割がある

WealthNavi for 住信SBIネット銀行

• スマプロランク3の判定条件の1つ スマプロランクについて | スマートプログラム | 住信SBIネット銀行
• 独自キャンペーンがある
• 長期割がない

移行に関する諸注意

自分は既にスマプロランク3であったし、キャンペーンはどちらも独自とのことなので実質長期割があるWealthNaviの方が良さそうだったので、WealthNaviに移管することにした。

移管方法についてウェルスナビ株式会社に問い合わせた所、WealthNaviやWealthNavi for ○○は、特定口座の為下記の制約を受けることを知った。

• 移管といった概念はない
• いずれか1つしか契約できない
• 同一年内に再開設はできない

もしWealthNaviへ変更する場合には一度WealthNavi for 住信SBIネット銀行を解約し、翌年以降にWealthNaviを新規に申し込む必要がある。

再契約処理

昨年11月に長期割の存在を知りこれらの情報を確認したので、早々に手続きを行った。手続きはスムーズですぐに解約・登録口座に入金が行われた。

自分の場合、200万円強を2年程度運用していたのだが、解約時に幾つか税務処理等々で数万円差し引かれたものの10万円オーバーの金額がプラスで返ってきた。

• 11月中旬には解約申し込み
• 外国証券取引口座解約請求書 が郵送で届くので、必要事項を記入の上で返送
• 予定通り年内に解約手続きが完了
• 1月4日にWealthNaviを新規に申し込み
• 1月中旬から運用開始

で再契約が完了した。

現在

こんな感じで長期割までのカウンタが表示されるようになった。

200万円以上預けると長期割の手数料割引率が上がっていくので、当面は月々の積立金額を増やして運用することにしている。

ちなみに、自動積立した金額の反映は 引落日の【3営業日後】に行われ、恐らく反映日の夜間にETFの購入が行われる為時間が掛かるので、住信SBIネット銀行の定額自動振込サービスでクイック入金を行って入金している。

こちらであれば平日10時までに入金されればその日の夜間にETFの購入が行われるので反映が早い。

これでWealthNaviは最適化ができた。

ロボアドバイザー投資1年目の教科書

コミットメッセージに自動でチケットIDを入れたい

やりたいこと

feature/${チケットID}-awesome-function みたいなブランチ名でコミットした時に、自動でコミットメッセージのプレフィクスに [#チケットID] を挿入しておきたい。

実行環境に左右されたくなかったので、bash / zshだけで実装したい。

githooks prepare-commit-msg を使う

Git - githooks Documentation

#!/bin/sh
COMMIT_MSG_FILE=$1
CURRENT_BRANCH=$(git rev-parse --abbrev-ref @)

if [[ $CURRENT_BRANCH =~ ^[^/]+/([0-9A-Za-z]+)[-|_]?.+$ ]]; then
  TICKET_ID=${BASH_REMATCH[1]}
  if [[ -n "$TICKET_ID" ]]; then
    echo "[#$TICKET_ID] $(cat $COMMIT_MSG_FILE)" > $COMMIT_MSG_FILE
  fi
fi

以下解説。

• $1 には $git commit した際にエディタでコミットメッセージを入力する際のメッセージ。 sampleに倣って変数に格納した。
• 現在のブランチ名は git rev-parse --abbrev-ref @ で取得できる
• BASH_REMATCH[1]は 正規表現でマッチした1番目のキャプチャを取得する。この場合にはifの条件式内の () で括った箇所。
• チケットIDがうまく取得できていたら、オリジナルのコミットメッセージファイルの中身の先頭にチケットIDを追加したものを出力する。なお、きちんと > $COMMIT_MSG_FILE しないとエディタ上に反映されない

オリジナルのサンプルはこちら git/hooks--prepare-commit-msg.sample at master · git/git

できた

こんな感じになる。

いいですね。

実用Git

HHKBのキーマップ変更機能が残念だった #hhkb

はじめに

2019/12/10に発売されたHappy Hacking Keyboard HYBRID Type-S / 無刻印を発売日に購入しました。

HHKB Professional HYBRID Type-S 無刻印／白（英語配列）

自分は過去に

• HHKB Lite2
• HHKB Lite2 for Mac
• HHKB Professional2
• HHKB Professional Type-S

を購入したのでこの度で5枚目の購入です。最近はHHKBを2枚配置して疑似分割キーボードとして使っていました。

Dvorakユーザーの私は発売当日のプレスリリースを見てキーマップ変更ができると知り、その日に開催された HHKBユーザーミートアップ vol.3 | Peatix に参加した折にHYBRID Type-Sを早速購入しました。

世のレビュー記事では概ね高評価ですし、私も打鍵感やUSB Type-C対応には満足しています。

しかしながらキーマップ変更機能で非常に残念だった点がありました。この記事がPFUの担当者の方の目に止まり、いつかファームウェアアップデートで対応してもらえることを期待して敢えてこの記事を書きます。

何が残念か

Dvorak配列では右Shiftの左隣のキーがZなので、このキーをZに割り当てようとすると、

Zキーは"特殊な動作を行うために予約されている"というポップアップが出て、

FnレイヤーまでZにされてしまい、長年HHKBで打鍵してきた ↓ が従来のキーで打てなくなる。

これは Q, X, Z, 左Ctrl, 右Shift キーをリマップした際にはFnレイヤーも同キーで強制的に上書きするという仕様に起因する為、Dvorak配列に限らずそれらのキーをリマップした際にも同様の問題が発生します。

どうしても↓を入力したい場合には、長年HHKBで打鍵してきたキーマップとは異なる位置に↓をリマップするしかありません。

とはいえ、他のカーソルキー配置との兼ね合いや、使い慣れたキー配置を変更するのは難しく、結果としてハードウェアでのキーマップを諦め、今まで通りOS/ソフトウェア上でのリマップに頼ることになります。

これではキーマップ変更機能は全く使い物になりません。

キーマップ変更機能について

キーマップ変更機能について、PFUではこのように紹介されています。

プレスリリース

制御キーの割り当てを変更できるDIPスイッチに加えて、キーマップ全般をカスタマイズできる(注3)「キーマップ変更機能」を装備しました。 専用ソフトウェア（Windowsで動作）による操作は直感的でわかりやすく、設定内容はHHKB本体に保存するため、接続するPCやスマホを変えても、同じキーマップで使用できます。[HYBRID Type-S／HYBRIDのみ]
（注3）キーマップ変更は、特別な機能を割り当てられた一部のキーを除きます。 PRESS RELEASE | 高性能コンパクトキーボード「Happy Hacking Keyboard」ラインナップ一新 | 株式会社PFU

HHKB公式サイト

制御キーの割り当てを変更できるDIPスイッチに加えて、「HYBRID Type-S」「HYBRID」は制御キーと文字キー全般（※）のキーマップをカスタマイズできる「キーマップ変更機能」を装備。 ソフトウェア（Windowsで動作）によるキーマップ変更は直感的で扱いやすく、設定はHHKB本体に保存されるため、他のデバイスでも同じキーマップで使用できます。 好みの反映、最速追求、タイピング競技やeスポーツのための最適化など、よりプロフェッショナルな“マイ・キーボード”の構築が可能です。 キーマップ変更ツールは無償でダウンロードいただけます。 ※特別な機能を割り当てられた一部のキーを除く。 Happy Hacking Keyboard | HHKB HYBRID Type-S | PFU

「特別な機能を割り当てられた一部のキー」 とは

特別な機能を割り当てられた一部のキーを除くという表現がありましたが、modifireキーやSpace, Fnキーと私は読み違えてしまいました。

というか、QWERTYとはシェアは大きく差があるものの、DvorakはWindowsやmacOSやUbuntuで標準サポートされている配列なので、新機能としてキーマップ変更機能をアピールするのであればDvorak配列ぐらいは考慮されているだろうと思っていました。

それでも、キーボード配列周りは何かとトラブルがありがちなので、念の為購入の際には確認しておこうと考え、ユーザーミートアップの際に直接スタップに確認することにしました。

HHKBユーザーミートアップ vol.3 にて

両サイトを一通り熟読の上で、発売日夜の HHKBユーザーミートアップ vol.3 | Peatix に参加しました。

HHKB HYBRIDの実機とキーマップツールが並んでおり、スタッフも常駐していたので、早速キーマップツールの仕様について「私はDvorak配列ユーザーなのですが、Fnレイヤーも含めて問題なくリマップできますか？具体的にリマップできないのはどのキーですか？」とスタッフに質問しました。

スタッフの方も具体的にどのキーがリマップできないかまでは把握していなかったようで、実際にツールをお試しくださいとデモPCがあるブースへ案内されました。
(Dvorak配列を普段使っていない方にとって私の質問に回答するのは難しいと思っているので、ここで具体的な回答がいただけなかったことは気にしていません。)

私はそこで幾つかのキーのリマップを試しました。
HHKB HYBRIDの実機が初めてお披露目された場なので、デモブースには沢山の人だかりがあったので、手早く気になるFnレイヤーのリマップの挙動だけ急いで確認しました。

30キーほどリマップすればこの問題に気付いたかもしれませんが、よもやDvorak時にリマップすることになるキーの内Q, X, Zキーに限りFnレイヤーをリマップできないとは知らなかったので、幾つかのキーでFnレイヤーも個別にリマップできることを確認したところですっかりすべてのキーでリマップできるだろうと思ってしまいました。

また、PFU公式のテキストではありませんが、発売日当日に公開されたITmediaのレビュー記事にはDvorak配列などを想定した機能だろうと書いてあったこともあり、まあリマップできるだろうと安心してしまいました。

www.itmedia.co.jp

購入後、いざ自宅ですべてのキーをリマップしようと試みた際にこの仕様に気付き、ハードウェアでDvorakに変更するデメリットが大きいので、あれこれ試行錯誤したものの今まで通りソフトウェア上でリマップするしかないとの結論に至りました。

元々Type Sを所有しており、ハードウェアでリマップする為に買い替えたようなものなので、この時の落胆は相当のものでした。

何故ハードウェアでキーマップ変更をしたいのか

キーマップを変更したいというユーザーは少数だと思うので、簡単に理由を述べてみようと思います。

QWERTY以外のキーマップ利用者にとっては、個人利用のPCは自分でキーマップを一度変更すればよいのですが、それ以外の環境ではOSやソフトウェアでキーマップを都度変更する必要があります。

それ以外の環境とは、私にとってはVirtualBoxやAmazon WorkSpacesなどの仮想環境やiPadです。検証などで一時的に仮想環境を利用する際に環境単位でリマップするのが非常に手間です。
特にWindowsはレジストリを書き換えるか何かしないとリマップできないので触ること自体が億劫だったり、ハードウェア上でリマップできるKinesisキーボードを利用したりしていました。

HHKBでもハードウェア上でキーマップ変更ができるようになることで、仮想環境でも同じ鞍を利用し続けられるようになるというのは非常に魅力的なアップデートだったのです。
それが実現できないと知ってしまった時の落胆は非常に大きいものでした。

PFUへ期待すること

個別にFnレイヤーをリマップできないキーを公式サイトにも明記して欲しい

「※特別な機能を割り当てられた一部のキーを除く。」 のような曖昧な表現でなく、最初からハッキリと

以下のキーも特殊な操作用に予約されているため、Fn押下時のキーの割り当てができません。
`Q`, `X`, `Z`, '左Ctrl', '右Shift'

と書いて欲しいです。

私はこの制限について、PFUのサポートセンターに問い合わせ回答を貰うまで知ることができませんでした。
サポートセンターの方からは、キーマップツールのヘルプ（ツールを起動し、右上の3つ点アイコンをクリックして表示されるメニュー内）にも記載があるとの案内もいただきましたが、

• 公式サイト, 説明書にはリマップできないキーについて具体的な記述なし
• 購入前にキーマップツールを起動してヘルプを読むという発想が困難
  • そもそも、キーマップツールはHHKB HYBRIDをUSB接続した状態でないとヘルプ画面に遷移できない

ので、購入前にこの制限に気付くということは不可能です。
HYBRID購入者で購入前にこの制限を知っていた方は居るのでしょうか？

もし購入前にこの情報を知っていたら、元々Type-Sを所有していたので私は購入を見送りました。
プロモーションとしては正しい表記かも知れませんが、買ってからリマップできないと気付いた時の落胆はユーザーの満足度を大きく損ねています。

ファームウェアアップデート、キーマップツールのアップデートでこれらのFn押下時のキーも任意にリマップできるようにして欲しい

一番求めているのはこれです。

キーボードへのこだわりが強いユーザーが多いことや、非常時にはUSB経由で初期化等ができれば充分だと思うので、制限を外して任意にリマップできるようにして欲しいです。

どうしても制御用のキーを配置する必要があるのであれば、ツール上で制御キーを必ず何かしらのキーにマッピングするまで書き込みできないUIにすればよいだけで、先述のキーにだけFn押下時もリマップできない制約をつける必要はないはずです。

過去にergodox-ezを利用していましたが、Layerごとに任意のキー配置ができるのが理想です。

Oryx: The ZSA Keyboard Configurator

〆

キーマップ変更機能が不要なユーザーにとっては打鍵感もよく、ケーブルも無くなり、有事の際にはUSBハブなど無しで直接Type-CでMacBook Proと接続できるようになった最高のキーボードだと思います。

だからこそキーマップ変更だけ何とかしてください！お願いします！！

HHKB Professional HYBRID Type-S 無刻印／墨（英語配列）