MacからWinに即Vimが移植できた話
tl;dr;
dotfileは、PublicなGithub管理がいいぞ
背景(という名のポエム)
それはゴリラ.vim#10当日のことでした。
それまで社用PCとしてMacbookProを利用していたのですが、「好きなPC買って良いよ！」と会社から言われ「じゃあThinkpadで！」と答えたのが数週間前。
そこから恒例の納入延期が入り、12月上旬に届く予定だったのですが……
「0Deltaさん、PC何か突然来たんだけど……」「……へっ？」
というやりとりが行われました。ゴリラ.vim当日(11/13)に。
何はともあれ、念願のThinkpadです。セットアップしないわけにはいきません。
重要なデータは全てGoogleDriveにぶん投げ、ThinkpadのOSや生体認証をセットアップし終わった頃にはもうイベントに出発しなければならない時間でした。
いそいそと机を片付け、Macはデータバックアップだけ走らせて置いていきました。
そして「念願のゴリラ.vim初参加だ！」と着席した後、Vimでメモを取ろうとしたのですが
「/bin/bash vim command is Not found」
……Vim入ってないやん！！
なんということでしょう、VimのイベントにVim無しで参加していたのです！
あっ、コレはいかん！ と思い、超速でセットアップしました。
そして、2人目のLTが始まる頃には、ほぼほぼ完全にセットアップができていました。やったぜ。
しかし、0からセットアップをしていた訳ではなく、いくつかの準備があったからこそ、爆速セットアップができたのでした。
準備しといて良かった！ と思えたTipsを、この記事で少しでも共有できればなと思います。
やっていたこと
- dotfilesに設定ファイルを集約していた
- 社用PCが壊れた際にできるだけダウンタイムを減らして復旧できるように、最初から作業環境だけでも復旧できるようにしてました。
- そもそもMac→Winの移行は辛過ぎるのでWSL2前提にした
- 特にパス周りがとても辛い事は明白だったので、できるだけ共通化しようとしていました。
- Vimのビルドスクリプト組んでた
- これは移行の為ではなかったのですが、最新のパッチを取り込みたかったので自作のビルドスクリプトを組んでいました。
環境の変化
- 強力なデバックは行なわなくなった
- ぶっちゃけて言えば、インストールだけで分割画面+ブレークポイントを含めたデバックができるのはとても強力で、それを求めてVimを選ぶのは無謀です。(もちろん、Vimをしっかり拡張すればとても快適にデバック可能です。)
逆に今は、デバック機能がなくとも追えるログを出すプログラミングを意識しています。
- ぶっちゃけて言えば、インストールだけで分割画面+ブレークポイントを含めたデバックができるのはとても強力で、それを求めてVimを選ぶのは無謀です。(もちろん、Vimをしっかり拡張すればとても快適にデバック可能です。)
- Windowsでdockerやgitを扱う関係上、ターミナルでの作業がほとんどになっており、同じターミナルでちょっとした変更は完結させたくなった。
- Emacsも手ですが、慣れの問題からVimを選んでいます。
- Vim日本語ユーザ会に入った
- 英語の勉強がてら、Vimのヘルプファイル翻訳方法を求めて入ったのですが、とても濃いメンバでとても楽しい。
- そして質問や疑問が爆速で解決して行くので楽しい。
で、結果どうなったの？
これだけで構築完了です！
git clone http://github.com/0Delta/dotfiles
cd dotfiles && bash ./install.sh
git clone http://github.com/0Delta/myvim
sudo apt update && sudo apt install <Vimビルド用色々>
vim myvim/install.sh # ここだけ素のVim、インストールパス等を合わせる
cd myvim && bash ./install.sh
途中の設定書き換えだけはどうしようもならないので手動です。
また、初回インストールのaptは自動化済で、first.shという名前のスクリプトで一発で行けるようになってます。
ところで、何故privateじゃダメなのか
ダメじゃないです。
もう一度言います。ダメじゃないです。
じゃあ何でそんな事言ったのさ？ というと、僕個人の意見として以下のような意見があるから。
- そもそも機密情報は別PCに持ち出せない方が良い
- 例えば鍵なら再生成が好ましいのでは?
- ユーザ名は固定じゃないのを想定しておくべき
- ${HOME}を参照するか
~を使えば良い
- ${HOME}を参照するか
- Publicにしておくとマサカリが飛んで来る
- 改善チャンスが生まれる
-
git pullする時に認証がいらない- privateだと、先に鍵を生成して登録する必要がでてくる~~、更に言えば先にEdgeを捨ててChromeを入れる必要もある~~
あくまで僕の意見です。
特に設定ファイルに自動で書き込まれてgit pushしてしまい、問題が起こる可能性も高いので、そこはトレードオフです。
(僕はgit-secretsで予防しています。)
まさかを見越してprivateなリポジトリにするのは賢い選択です。決して間違いではないです。
まとめ(まとまってない)
そもそもこれだけアウトプットするのが久々な上、プライベートで急な要件が来てあまり纏められませんでしたが……
言いたいことは積極的に自動化しておこうということ。
そしてできるだけ他の人に見せられる状態を維持しておくこと。自然と良いコードになりますし、改善のチャンスも増えます。
更に良いコードを書く習慣がつけば、仕事で書くコードも高品質になりやすく良いスパイラルになります。
特に「もし壊れたら」にまつわる事柄はできるだけ自動化/障害耐性を持たせるべきだと再認識しました。
(今回の件とは別になりますが、あやうく3年分の家族写真データが消えかけた事もありました……)
実際に動いているプログラム
実際に使っているプログラムを晒して終わりにしたいと思います。
またリポジトリは公開状態なので、フルが気になる人は探してみると良いでしょう。
dotfilesのリンクを張るスクリプト
#!/bin/bash
cd $(dirname $0)
DOTFILES_DIR=$(pwd)
links=(
".vimrc ~/"
".vim ~/"
# : <ここにコピーするファイルとコピー先>
)
for link in "${links[@]}"; do
from="${DOTFILES_DIR}/${link%% *}"
to="${link#* }"
if [ "${to##*/}" = "" ]; then
to="${to}${from##*/}"
fi
if [ "${to%%/*}" = "~" ]; then
to="${HOME}/${to#*/}"
fi
if [ -e "${to}" ]; then
echo ${to} is exists. skipping...
else
echo link ${from} ${to}
ln -s ${from} ${to}
fi
done
Vimのビルドスクリプト
#!/bin/bash
CONFIG=()
CONFIG+=("enable-fail-if-missing")
CONFIG+=("disable-gui")
# : <ここにconfigに与える引数(Vimに持たせる/持たせない機能)>
CONFIG+=("with-compiledby=0Delta")
CONFIG+=("prefix=/usr/local")
CONFIG_CMD="./configure"
for v in "${CONFIG[@]}"
do
CONFIG_CMD+=" --${v}"
done
git submodule foreach git fetch origin && git pull origin master && git add vim && git commit -m "update vim repo" && git push
cd vim/src
make distclean
eval ${CONFIG_CMD}
make -j $(sysctl -n hw.ncpu) && make install
vim --version | head -n 4
それでは、クリスマスも良いVimライフを！