はじめに
これは【その2】ドリコム Advent Calendar 2015の9日目です。
8日目は matsusaki さんの 組織における、エンジニアの情報共有について。あるいは、レビューや設計について。 です。
【その1】ドリコム Advent Calendar 2015はこちらからどうぞ。
自己紹介(公開当時のもの)
- id
- @massy
- ドリコム歴
- 2012/8/15 中途入社
- 4年目に突入しました、過去最長
- 仕事
- 組み込み開発エンジニア -> アプリケーションエンジニア
- ソーシャルゲームばんざい！
- 趣味
- T.M.R.を追いかけること
- ingress 緑 A15
dotfilesとは？
.(ドット)から始まる設定ファイルのことです。.bashrc とか .zshrc とか .tmux.conf とか .vimrc とかとか。エンジニアの皆さんにはおなじみのファイルだと思います。
どうして管理すべき？
こういう覚えはありませんか。
- HDDが吹っ飛んでしまった。バックアップ取ってない
- 作業環境をいい感じにしようとして色々なサイトを参考にして書き換えたりコピペしてきたりしたのに、後から見返してもなんでそう書いたか分からない
- PCを移行する必要があり、そうしたくても、設定ファイルを書き散らしてしまっていて、今からかき集めようにもできる気がしない
ひとつでも思い当たる節があれば管理するべきだと思います。
どう管理すべき？
githubにリポジトリを作って、そこで管理することをオススメします。
githubは無償で利用することができ、インターネットを経由していつでもアクセスすることができるので、バックアップ先として最適です。
普段gitを使って作業しているときのように、コミットの粒度を調節し、適切なメッセージを残すことで後から見返しやすくもできます。
また、リポジトリにまとめることになるので、設定ファイルが散らばりにくくなります。
管理してみよう
-
githubにログイン
-
githubのページから「New repository」を選択
3. 「dotfiles」という名前のリポジトリを作成
(私のアカウントは既にdotfilesを作成済なので、画像では適当な名前を入力しています。好きな名前でよいです)
4. ローカルにdotfilesディレクトリを作成して、管理したいdotfilesを移す
cd ~
mkdir dotfiles
mv .bashrc dotfiles
mv .bash_profile dotfiles
…
5. 移しただけでは読み込めなくなってしまうので、シンボリックリンクで読み込めるようにする。ファイルが増えてくると毎回リンクするのが面倒になってくるので、シンボリックリンクを作成するシェルスクリプトを用意する
vi dotfiles/setup.sh
#!/bin/bash
DOT_FILES=(.bashrc .bash_profile …)
for file in ${DOT_FILES[@]}
do
ln -s $HOME/dotfiles/$file $HOME/$file
done
6. シェルスクリプトを実行する
今の環境を崩さないよう、先ほど作成したシェルスクリプトを実行しておく
chmod +x dotfiles/setup.sh
cd ~/dotfiles
./setup.sh
これで環境が今まで通りに戻りました。
7. githubにpushする
git init
git add .
git commit -m "initial commit"
git remote add origin git@github.com:massy22/dotfiles.git
git push -u origin master
massy22の部分は自分のアカウント名に置き換えてください。
以上でdotfilesを管理することができました
次のステップ
github上で管理することで変更に強くなったので、dotfilesを修正しやすくなりました。
次はdotfilesに見直しをかけてみましょう。定期的に見直しをかけることで、日々の作業の効率が改善するかもしれません。
ただ、見直すといっても、どこをどうすればいいのかわからない人もいるでしょう。
そんなときは他の人のdotfilesを参考にすることをオススメします。
github上で検索してみるとこれだけのdotfilesが見つかります。
自分が使っている言語、フレームワークなどが近しい人を見つけて眺めてみたり、forkして使ってみたりするとよいと思います。
私の場合はyuroyoroさんのdotfilesをforkして使わせてもらっています。
yuroyoroさんは環境構築の手順を記事にして残されているので、これを参考に環境構築しました。
流石に結構前の記事なので、vundleからdeinに移行されていたり、vim-procがsetup.shでmakeするようになってたりと、様々な変更を含むコミットが重ねられています。
上記手順で環境構築がうまくいかないときは、コミットメッセージを読み、差分を読むと大抵解決策が載っていました。
これもgithubで管理されているからこそですね。
forkは簡単に人の環境に乗っかることができて楽ですが、もちろん人の環境なので、追随してると自分に合わない修正が入ってきて困惑したりします。
例えばある日突然寿司が表示されるようになったりします。
寿司耐性の弱い私はその日のお昼が寿司になりました。
上記は冗談ですが、急にソフトが起動しなくなったりすることもあるので、追随は余裕があるときに行うようにしたり、参考に留めたりするのもいいかもしれません。
10日目
次は hisanon さんの 新卒1年目と先輩たちのおはなし です。