人生シーケンスブレイク

シーケンスブレイクとは

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

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

インストール

$ brew install starship

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

$ eval "$(starship init zsh)"

と書くだけ。

何が嬉しいの?

f:id:ShineSpark:20200303023422p:plain

こんな感じにディレクトリの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

macOSでcommand+Hを無効にした

macOScommand + 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 すればよい。

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

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

f:id:ShineSpark:20200221195803p:plain
入力ソースが3種類ある例

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

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

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

set iminsert=0
set imsearch=-1

とすることで対応した。

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 + EEsc としているので、こちらも同様にした。

{
    "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"
        }
    ]
}

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

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

TL;DR

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

事の発端

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

f:id:ShineSpark:20200219011053p:plain

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

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

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

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

WealthNavi

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

WealthNavi for 住信SBIネット銀行

移行に関する諸注意

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

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

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

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

再契約処理

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

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

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

で再契約が完了した。

現在

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

f:id:ShineSpark:20200219013757p:plain

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

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

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

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

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

ロボアドバイザー投資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

できた

こんな感じになる。

f:id:ShineSpark:20200213015624p:plain

いいですね。

実用Git

実用Git

Happy Hacking Keyboard HYBRIDのキーマップ変更機能が残念だった #hhkb

はじめに

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

f:id:ShineSpark:20191227034049j:plain

自分は過去に

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

を購入したのでこの度で5枚目の購入です。HHKB2枚でセパレートキーボードを試す為にType-Sを買い増して使っていました。

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

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

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

何が残念か

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

f:id:ShineSpark:20200508221955p:plain

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

f:id:ShineSpark:20200508222217p:plain

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

f:id:ShineSpark:20200508222722p:plain

これは 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

f:id:ShineSpark:20191227014056p:plain

HHKB公式サイト

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

f:id:ShineSpark:20191227014341p:plain

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

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

というか、QWERTYとはシェアは大きく差があるものの、DvorakmacOSUbuntuで標準サポートされている配列なのでDvorakで弊害があるとは思っていませんでした。

とはいっても、何かと配列周りはトラブルがありがちなので、念の為購入の際には確認しておこうと考えていました。

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

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

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

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

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

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

www.itmedia.co.jp

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

ハードウェアでリマップする為に買い替えたようなものなので、この時の落胆は相当のものでした。

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

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

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

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

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

PFUへ期待すること

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

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

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

と書いて欲しいです。

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

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

ので、購入する前にこの制約に気付くということはほぼ不可能だと思われます。
HYBRID購入者で購入前にこの制約を知っていた方は居るのでしょうか?

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

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

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

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

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

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

Ergodox EZ Configurator

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

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