KLabGames Tech Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。 スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。 このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。

皆さんは Google Play Games Services (GPGS) を使っていますか?
おそらくスマートフォンゲームを制作している企業の開発者の方々は基本的な機能への対応を済ませていることと思います。

今回は、GPGS の Real-time Multiplayer という機能のリアルタイム性を検証すべく、2 端末間でメッセージを往復させた時にかかる時間について調べました。

まず、GPGS がどういうものか概要を見ていきましょう。

Google Play Games Services とは

Google Play Games Services では Google+ ログインによりプレーヤーを認証することで以下の様な機能が提供されています。

Leaderboards
全世界でのランキングやソーシャル内でのランキングが見ることができます。
Achievements(実績)
プレーヤーは条件を達成することで実績を得て、それに応じた経験値を得ることができます。
Saved Games(クラウド保存)
ゲームのセーブデータを Google のサーバーに保存でき、それらは複数端末で同期されます。
Real-time Multiplayer
最大8人の部屋を作りその中でリアルタイム通信をすることができます。
Turn-based Multiplayer
最大8人の部屋を作りその中でターン制ゲームをすることができます。
Events and Quests
プレーヤーの進行度合いを集計し統計解析することができます。

上記の機能は Google Play のデベロッパーコンソールでゲームを追加することで使うことができます。
GitHub にサンプルコードが用意されています。
https://github.com/playgameservices/android-basic-samples

Real-time Multiplayer

Real-time Multiplayer を使うことで、自分でサーバを用意しなくても複数人でのリアルタイム通信を実現できます。ここでのリアルタイム通信網は、基本的には P2P ネットワークで構成されます。ファイアーウォールを越えられない場合などは Google のサーバーが中継をします。

プレーヤーが Real-time Multiplayer を使ったゲームを開始するときの手順は下記の通りです。

  • ゲーム画面から Google+ ログイン
  • ゲーム画面から自動選択(ランダムマッチ)をするか、友達の招待をするかを選択
  • GPGS の画面が起動
    • 自動選択の場合は選択されるまで待機
    • 友達を招待する場合はどの友達を招待するかを選択してそれが許諾されるのを待機
  • お互いのプレーヤーの準備ができると、ゲーム画面に戻ってゲーム開始

検証実験

では、本記事の本題である Real-time Multiplayer を使って 2 端末間でメッセージを往復させた時にかかる時間の測定について以下にまとめます。

検証方法

使用回線

  • au LTE – docomo LTE(国内通信)
  • au LTE – AT&T LTE(日米間通信)

メッセージングプロトコル

  • Reliable messaging [max:1400 bytes]
    • 遅いが欠落なし
    • おそらく TCP
    • 1メッセージ当たりの最大データ量 1400 bytes
  • Unreliable messaging [max:1168 bytes]
    • 速いが欠落あり
    • おそらく UDP
    • 1メッセージ当たりの最大データ量 1168 bytes

それぞれのメッセージングプロトコルに対してデータ量を 10 bytes から 100 bytes ごとに最大まで、各データ量につき 10 回計測しました。

おまけ(上限調査)
Reliable messaging では上限とされている 1400 bytes 以上のデータを送信できたため、送信データ量を 5000 bytes ずつ増やしながら例外が吐かれるまで計測しました。
各データ量につき 1 回計測しました。

検証結果

検証結果1


国内通信、日米間通信

検証結果2


おまけ(上限調査)

詳細な計測数値は別表に示します。

まとめ

今回、Google Play Games Services の Real-time Multiplayer について、信頼性の高い Reliable messaging と信頼性の低い Unreliable messaging それぞれの通信速度を、送信データ量を変えながら計測しました。メッセージのデータ量による通信時間変化は、規格として定められている範囲では特に大きな差はありませんでした。
通信時間はおおよそ下記のとおりとなりました。

Reliable Unreliable
国内 約 750ms 約 120ms
日米間 約 700ms 約 230ms

Unreliable(内部ではおそらく UDP が使われている)では距離の差が通信時間に表れました。
一方 Reliable(内部ではおそらく TCP が使われている)は、コネクションの確立等で Unreliable よりも距離の影響を受けそうですが、今回の計測では日本国内でも日米間でもほぼ変わらないという結果となりました。
GPGS Real-time Multiplayer の通信では、Google のサーバーでユーザーのマッチング処理をした後、できれば P2P でできれなければ Google のサーバーを経由で通信します。なので、地理的距離が近い場合でも遠い Google のサーバーに接続している可能性があります。
ただし、今回はパケットキャプチャを行わなかったので正確な原因は分かりません。

使いにくい点は多々あるかとは思いますが、自身でサーバーを用意することなく Android 開発者アカウントがあれば手軽にリアルタイム通信を使えることは大きなメリットかと思います。興味のある方はぜひ使ってみてください。

以上、Google Play Games Services Real-time Multiplayer の通信時間計測レポートでした。

別表 検証結果

Reliable(国内)

データ量 [byte] 10 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400
1 回目 [ms] 640 836 862 698 724 701 703 694 730 707 719 722 745 734 724
2 回目 [ms] 920 713 774 714 703 687 725 716 712 712 720 681 822 758 747
3 回目 [ms] 715 680 659 888 903 691 725 725 725 821 758 716 741 739 727
4 回目 [ms] 726 891 702 706 696 716 711 707 704 696 721 756 783 869 700
5 回目 [ms] 693 714 737 691 773 792 697 819 836 716 716 765 742 708 691
6 回目 [ms] 770 733 690 825 729 777 789 757 722 707 737 721 732 708 694
7 回目 [ms] 705 771 714 710 742 700 738 718 706 731 739 755 733 722 704
8 回目 [ms] 747 804 681 783 766 784 700 838 739 689 760 889 726 722 750
9 回目 [ms] 707 664 713 694 858 723 707 711 766 773 838 746 723 726 709
10 回目 [ms] 706 776 683 682 708 706 762 736 743 735 854 728 824 697 720
平均 [ms] 732.9 758.2 721.5 739.1 760.2 727.7 725.7 742.1 738.3 728.7 756.2 747.9 757.1 738.3 716.6

Unreliable(国内)

データ量 [byte] 10 100 200 300 400 500 600 700 800 900 1000 1100 1168
1 回目 [ms] 249 105 105 128 117 114 291 130 107 150 118 136 142
2 回目 [ms] 102 89 84 94 108 107 103 113 85 143 130 131 169
3 回目 [ms] 78 110 110 127 96 213 127 116 155 123 107 164 99
4 回目 [ms] 94 98 81 80 111 109 116 195 96 115 131 134 72
5 回目 [ms] 126 93 106 79 97 114 122 112 110 133 128 112 96
6 回目 [ms] 104 109 84 98 112 111 110 124 125 140 151 120 94
7 回目 [ms] 86 130 109 93 113 129 116 111 113 139 126 135 116
8 回目 [ms] 100 109 97 110 127 132 109 108 123 111 126 115 86
9 回目 [ms] 94 81 90 100 119 129 125 109 115 100 117 111 120
10 回目 [ms] 86 80 83 110 124 177 123 151 146 128 122 139 107
平均 [ms] 100.4 94.9 101.9 112.4 133.5 134.2 126.9 117.5 128.2 125.6 125.6 129.7 110.1

Reliable(日米)

データ量 [byte] 10 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400
1 回目 [ms] 601 651 635 648 678 719 703 753 709 583 702 709 773 707 660
2 回目 [ms] 588 654 663 677 680 679 603 606 639 696 665 745 741 709 834
3 回目 [ms] 711 651 671 689 708 673 731 593 700 663 574 711 643 749 891
4 回目 [ms] 639 650 675 651 744 696 619 692 807 684 767 721 687 706 692
5 回目 [ms] 713 652 677 660 656 628 606 658 716 644 656 703 727 662 723
6 回目 [ms] 620 684 661 671 741 872 655 590 734 656 625 754 668 805 723
7 回目 [ms] 625 620 696 688 650 638 708 710 606 648 754 576 678 682 693
8 回目 [ms] 630 681 671 649 668 719 621 614 849 725 625 705 647 722 687
9 回目 [ms] 712 678 627 644 659 659 830 746 643 693 753 686 699 683 749
10 回目 [ms] 597 588 669 652 782 658 628 661 804 648 606 662 669 752 658
平均 [ms] 643.6 650.9 664.5 662.9 696.6 694.1 670.4 662.3 720.7 664 672.7 697.2 693.2 717.7 731

Unreliable(日米)

データ量 [byte] 10 100 200 300 400 500 600 700 800 900 1000 1100 1168
1 回目 [ms] 236 219 212 217 206 242 240 246 234 226 256 286 273
2 回目 [ms] 189 240 234 214 234 189 241 200 226 244 238 243 258
3 回目 [ms] 238 191 215 196 207 210 188 216 216 278 219 244 272
4 回目 [ms] 204 203 228 209 222 250 231 227 189 245 246 249 258
5 回目 [ms] 190 198 189 202 186 250 235 190 240 281 266 232 299
6 回目 [ms] 190 194 245 192 199 202 210 250 259 263 276 255 247
7 回目 [ms] 196 245 177 205 265 194 190 249 240 223 257 276 230
8 回目 [ms] 234 186 209 196 201 216 240 231 239 252 212 281 259
9 回目 [ms] 190 236 248 304 196 208 222 220 231 198 277 291 253
10 回目 [ms] 208 222 214 220 201 179 201 226 233 217 257 381 229
平均 [ms] 213.4 217.1 215.5 211.7 214 219.8 225.5 230.7 242.7 250.4 250.4 273.8 257.8

Reliable(上限調査)

データ量 [byte] 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 55000 60000 65000 70000 75000 80000 85000 90000 95000 100000 105000 110000 115000 120000 125000 130000 135000 140000 145000 150000
計測時間 [ms] 713 1012 1018 1187 1381 1473 1679 1666 1759 1772 2056 2067 2103 2297 2544 2589 2350 2820 2897 2455 2574 2742 2981 2835 3189 3104 3338 2903 3161 3183

データ量 [byte] 155000 160000 165000 170000 175000 180000 185000 190000 195000 200000 200000 205000 210000 215000 220000 225000 230000 235000 240000 245000 250000 255000 260000 265000 270000 275000 280000 285000 290000 295000
計測時間 [ms] 3455 3360 3417 3448 3719 3561 3807 3823 3843 3979 5285 4780 4444 4242 4269 4592 4748 4546 4864 4729 4165 4785 4713 4511 4887 4712 4796 4736 5795 4907

データ量 [byte] 300000 305000 310000 315000 320000 325000 330000 335000 340000 345000 350000 355000 360000 365000 370000 375000 380000 385000 390000 395000 400000 405000 410000 415000 420000 425000 430000 435000 440000 445000
計測時間 [ms] 5066 5412 5170 5720 5593 5316 5819 5838 6311 6648 5678 6015 6304 5979 8921 5989 5811 6122 6216 6326 6606 6305 6233 7926 7991 6561 9879 7096 6791 7075

データ量 [byte] 450000 455000 460000 465000 470000 475000 480000 485000 490000 495000 500000 505000 510000 515000
計測時間 [ms] 7523 6933 9748 6916 7174 6760 7049 7158 7512 7119 7131 7070 7295 7856

Yuta Watanabe, @kakkun61

こんにちは。@kokukumaです。

昨日ふと調べたgitのブランチ名補完が異常に遅い原因について書きたいと思います。

現象

僕のwindows環境としては、conemuを入れて、その中でgitつかっています。

非常に鬱陶しいのが、ブランチの補完が異常に遅いことです。

git checkout ori TAB! TAB! ...................... 遅い。。。

git-complete.bashの中を確認する

とりあえず、git-complete.bashの中でどこが遅いのか読んでみます。

雰囲気で、git for-each-refが遅いと察することができます。

for-each-refとは、.git内にあるrefsを出力するためのgitコマンドです。詳しくは、for-each-refを参照のこと。

とりあえず、時間を測ってみます。

※ 以下、gitの挙動を知りたいだけなので、linux上で実施。

vagrant@debian-jessie:~/projects/lovelive$ time git for-each-ref --format="%(refname)" refs/tags refs/heads refs/remotes >/dev/null

real    0m0.064s
user    0m0.004s
sys     0m0.032s
vagrant@debian-jessie:~/projects/lovelive$ time git for-each-ref --format="%(refname:short)" refs/tags refs/heads refs/remotes >/dev/null

real    0m1.107s
user    0m0.008s
sys     0m0.496s

なぜか、shortつけただけで、すごく時間が伸びています。

システムコールを見てみる

原因を調べるため、straceを使って実行されているシステムコールのsummaryをとってみます。

vagrant@debian-jessie:~/projects/lovelive$ strace -cf git for-each-ref --format="%(refname)" refs/tags refs/heads refs/remotes > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000907          17        54           openat
  0.00    0.000000           0       145           read
vagrant@debian-jessie:~/projects/lovelive$ strace -cf git for-each-ref --format="%(refname:short)" refs/tags refs/heads refs/remotes > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 87.62    0.015765           1     13131     13047 lstat
  6.27    0.001128          21        54           openat

でました。

ちょくちょく遅い原因となっているlstat。

参考: VirtualBoxのファイルシステムを10倍速くする ~ find編 ~

gitのコードを確認する

次に、なぜshortをつけただけでlstatが大量発行されるのかを、gitのコードを追って調べてみます。

// git-2.1.4/builtin/for-each-ref.c

static void populate_value(struct refinfo *ref)
{
(省略)
            if (!strcmp(formatp, "short"))
                refname = shorten_unambiguous_ref(refname,      // <- ここでrefnameを短くしているぽい。
                              warn_ambiguous_refs);
// git-2.1.4/refs.c
char *shorten_unambiguous_ref(const char *refname, int strict)
{
(省略)

    /* skip first rule, it will always match */
    for (i = nr_rules - 1; i > 0 ; --i) {
        (省略)
        /*
         * check if the short name resolves to a valid ref,
         * but use only rules prior to the matched one
         */
        for (j = 0; j < rules_to_fail; j++) {
            (省略)
            mksnpath(refname, sizeof(refname),
                 rule, short_name_len, short_name);
            if (ref_exists(refname))                    // <- ここの中でlstatしてる。
                break;
        }
        (省略)
}

わかったこと

shorten_unambiguous_refがやっていることは、refsをshort nameに変換する作業です。

例えば、refs/heads/branch_name を branch_name に変換する感じ。

やり方は単に、refs/headsとかに引っかかったら、その部分を削るだけです。

しかし短くすると、ブランチ名を一意にsha1に変換できなくなる可能性がでてきます。

  • refs/heads/branch_name -> f62a336
  • refs/tags/branch_name -> 865fe2e
  • git checkout branch_name => f62a336 ? or 865fe2e ?

そこでshorten_unambiguous_refでは、同じshort_nameで表すことができるrefsがあるか確認して、あったら短くしないと動いています。

これによって、for-each-refで出力される結果がすべて、一意にsha1に変換できることを保証しているわけです。

ただ、その存在確認のやり方が、

  • branch_nameにrefs/remotesとかrefs/tagsとかつけてpathをつくる
  • lstatして、そのpathにファイルがあるか確認する
  • open -> read -> sha1を確認する

となっているので、1つのrefsに対して、4、5回lstatを実行しています。

そのためレポジトリのブランチが増加すると、lstatの回数が増加して、1TABにつき1万回のlstat発行!とかになります。

そして、gitbashのlstatや、VM(over vboxsf)のlstatが凄く遅いせいで、windowsでブランチ補完が遅くなるという感じ。

対応

for-each-refを上手く直す方が正しいでしょうが、ちょっと大変そうなので、雑な対応で乗り切ることにしました。

:shortつけるのが遅い原因なら、:shortやめてsedでrefs/headを削る作戦。

zatu-git-complete.bash

これをすることで、一意にsha1に変換出来ないブランチ名が補完される可能性があります...

でもまぁ、remotesには基本originがつくでしょうし、ブランチ名と同じ名前のタグとかつけない(たぶん)ので大丈夫。

効果は体感で5倍。

zatu-git-complete.bashを手元に保存して、.bashrcとかに以下みたいに書いておけば使えます。

source (保存したpath)/zatu-git-complete.bash

まとめ

なんでwindowsのgitのブランチ補完が遅い原因が分かった。

雑対応で雰囲気速くなった。

こんにちは。突然ですけど、マシン間でのドットファイルの共有ってどうしてますか?

最近ではドットファイルをGitHubやBitBucket上のリポジトリでバージョン管理している人は珍しくありませんし、Dropboxを活用している人もいるようです。何にせよ、インターネットにつながっていれば自分の作業環境を再現できたり、変更を同期できたりするのは非常に便利ですよね。

ところで、これらのファイルを管理するdotfilesプロジェクトのディレクトリ構造や初期化スクリプトの機能などは人によってバラバラなようです。実際に身の回りの数人に聞いてみたのですが、特に他人のdotfilesプロジェクトをベースにしたりせず、自分だけの仕組みを使っている人が多い印象でした。それほど難しい内容ではありませんから、自作の方が自由度が高くて便利なこともあるでしょう。

一方で、他人のドットファイル管理を見ると気づきがあったりします。私自身、以前は独自の仕組みを使っていましたが、最近は「Zach Holman's dotfiles」をカスタマイズして使っています。本稿では他人のdotfilesプロジェクトに乗っかってみてのメリット・デメリットを紹介します。

Zach Holman's dotfiles とは

Zach Holman's dotfilesはStar数3000・Fork数2000と、GitHub上で公開されているdotfilesプロジェクトの中でも有名なものの一つです。

また、作者のZach Holmanさんは5年前にブログ記事「Dotfiles Are Meant to Be Forked(dotfilesはforkされるべき)」という記事を書いて最近でも話題にされたりしています(参考:redditのスレッド)。

この記事自体は賛否両論ある内容なのですが、「リファクタリングやコードの最小化に知見があるソフトウェアエンジニアが200行のグチャグチャな.bashrcを使っていて平気なのが理解できない、他人が再利用できるように整理して公開しよう」という主張はわからなくもありません。

Zach Holman's dotfiles の使い方

このZach Holman's dotfilesを手元で使う方法を紹介します。

新しいマシンにログインしたら、次のようにgit cloneして初期化スクリプトを実行するだけで普段の設定ファイルが使えるようになります。

$ git clone https://github.com/[自分のユーザー名]/dotfiles.git ~/.dotfiles
(略)
$ cd ~/.dotfiles
$ script/bootstrap

  [ OK ] linked /home/hnw/.dotfiles/zsh/zshrc.symlink to /home/hnw/.zshrc
  [ OK ] linked /home/hnw/.dotfiles/emacs.d.symlink to /home/hnw/.emacs.d
  [ OK ] linked /home/hnw/.dotfiles/tmux/tmux.conf.symlink to /home/hnw/.tmux.conf
  [ OK ] linked /home/hnw/.dotfiles/ruby/gemrc.symlink to /home/hnw/.gemrc
  [ OK ] linked /home/hnw/.dotfiles/ruby/irbrc.symlink to /home/hnw/.irbrc
  [ ? ] File already exists: /home/hnw/.profile (profile.symlink), what do you want to do?
        [s]kip, [S]kip all, [o]verwrite, [O]verwrite all, [b]ackup, [B]ackup all B
  [ OK ] moved /home/hnw/.profile to /home/hnw/.profile.backup
  [ OK ] linked /home/hnw/.dotfiles/bash/profile.symlink to /home/hnw/.profile
  [ OK ] moved /home/hnw/.bash_logout to /home/hnw/.bash_logout.backup
  [ OK ] linked /home/hnw/.dotfiles/bash/bash_logout.symlink to /home/hnw/.bash_logout
  [ OK ] linked /home/hnw/.dotfiles/atom.symlink to /home/hnw/.atom
  [ OK ] linked /home/hnw/.dotfiles/git/gitconfig.symlink to /home/hnw/.gitconfig
  [ OK ] linked /home/hnw/.dotfiles/git/gitconfig.local.symlink to /home/hnw/.gitconfig.local
  [ OK ] linked /home/hnw/.dotfiles/git/gitignore.symlink to /home/hnw/.gitignore
  [ OK ] linked /home/hnw/.dotfiles/git/git_templates.symlink to /home/hnw/.git_templates
  [ OK ] linked /home/hnw/.dotfiles/vim/vimrc.symlink to /home/hnw/.vimrc
  [ OK ] linked /home/hnw/.dotfiles/system/inputrc.symlink to /home/hnw/.inputrc
  [ OK ] linked /home/hnw/.dotfiles/system/dir_colors.symlink to /home/hnw/.dir_colors

  All installed!
$

ホームディレクトリに大量のシンボリックリンクが作られるという、ありがちな挙動です。既存ファイルを上書きするか、バックアップファイルするかなど聞いてくれるのは親切ですが、自作できないほど高機能というわけでもありません。

また、Macの場合は初期化スクリプト中でHomebrewからgrcsparkをインストールされたりします。試す前にbootstrapの中身を追いかけておいた方が良いでしょう。

Zach Holman's dotfiles のよいところ

既に回っている仕組みに乗っかれる

私が自前のdotfilesプロジェクトを管理していたころは、当初は管理対象としてファイルしか想定しておらず、後から~/.atom/のようなディレクトリを管理したくなったタイミングで初期化スクリプトを書き直す、などということがありました。

既存のdotfilesプロジェクトであれば既に多くの人のニーズに応えているため、後から不満が出てくるようなことは滅多にないはずです。

また、初期化スクリプトも自作出来る程度の内容とはいえ、既に多くの人の手元で動いているものを使えるのは安心感があります。過去に私が自作したスクリプトは手元の環境に依存していたりして、新しい環境で動かずにデバッグする羽目になったりしました。

新しい環境で普段と同じドットファイルを素早く使う目的であれば、どの環境でも即座に動くのは地味ながら重要です。その意味で、他人の成果物を利用するのは良い手のように思います。

ドットファイルを整理して管理できる

Zach Holman's dotfilesの特徴的なところは、関係の深い設定を同じサブディレクトリにまとめて管理するというポリシーです。

たとえば私の~/.dotfiles/gitには次のようなファイルがあります。

-rw-r--r--  1 hnw staff  616  4 26 11:37 aliases.zsh
-rw-r--r--  1 hnw staff  289  4 26 11:37 completion.zsh
drwxr-xr-x  3 hnw staff  102  6 26 00:08 git_templates.symlink
-rw-r--r--  1 hnw staff  658  9 23 17:48 gitconfig.local.symlink
-rw-r--r--  1 hnw staff 1395 10 19 12:20 gitconfig.symlink
-rw-r--r--  1 hnw staff  179  4 26 11:56 gitignore.symlink

このように、gitの設定ファイルとzshの設定ファイルの断片とが共存しています。特定のプログラムに関する設定が同じディレクトリにまとまっていると多少は保守性が上がるように思います。

また、この仕組みに乗っかることで長大だったzshの設定ファイルが多少整理されたのも事実です。

以前自分でdotfileを管理していたころは設定を複数マシンで共有することだけが目的で、整理するという観点は無かったので、その意味では良かったと言えそうです。

gitサブコマンドがすごい

実は私がZach Holman's dotfilesを導入して一番気に入ったものは設定ではなく、git wtfという独自サブコマンドだったりします。これは、gitのワーキングディレクトリ上で打つと今どういう状況かを教えてくれるものです(ソースコード:dotfiles/bin/git-wtf)。

$ git wtf
Local branch: master
[x] in sync with remote
Remote branch: origin/master (git@github.com:hnw/dotfiles.git)
[ ] NOT in sync with local (you should merge)
    - init-loader.elでinit.elを分割 [39bece5]
$

たとえば上の出力例は、git fetchだけしてgit mergeしていない状況です。ローカルリポジトリとワーキングディレクトリの同期が取れてないよ、というのをズレているコミットのコミットログと合わせて教えてくれています。他にもgit push -fして歴史がひどいことになったときなど、状況を把握するのに便利だと思います。

他にも独自のgitサブコマンドや他の便利コマンドがbin/以下に含まれており、$PATHに入れて使う前提になっています。設定と密接に関わるようなスクリプトをドットファイルと一緒に管理するのも良いアイデアですよね。

Zach Holman's dotfiles のイマイチなところ

大げさすぎる

このZach Holman's dotfilesの狙いはわかりますが、得られるメリットに対して若干大げさな印象があります。

確かに、設定ファイルをディレクトリ分けして整理できるのは良いことですが、その代わりにファイル数が増え、ディレクトリ階層が深くなってしまいます。ファイル数が増えると心理的にもメンテナンスのハードルは上がります。また、「この設定どこに入れりゃいいんだ?」みたいな状況になって悩みが増えたりもします。

公開したくない設定の扱いが示されていない

設定ファイルを公開しようとするプロセスで、グチャグチャだった設定ファイルが他人に見せられる程度に整理されるというのは確かにメリットかもしれません。

しかし、設定ファイルは整理さえすれば公開できるというものではありません。外部に公開していないホスト名など、設定ファイル中には公開に向かない内容も含まれているはずです。こうした公開できない設定をどう取り扱うかがZach Holman's dotfilesでは示されていません。

このあたりがクリアにならないと、「メリットはわからなくもないけど面倒だからプライベートリポジトリで管理しよう」という発想になる方が自然な気がします。

この記事を読んで「いっちょdotfilesリポジトリ作るかな」と思った方も、公開すべきでない内容をうっかり公開しないよう、注意してください。ちなみに私は公開できない情報は別ファイルにしてgit update-index --skip-worktreeでcommitの対象にしないようにしていますが、あまりスマートではないと感じています。

まとめ

  • Zach Holman's dotfilesというdotfilesプロジェクトを紹介しました
  • 初期化スクリプトや命名ルールなど、細かい点が既に決まっているのは楽です
  • 確かに設定ファイルを整理するきっかけになりました
  • 大げさすぎる印象は否定できません
  • 公開すべきでない設定を公開しないよう注意してください

そもそも論として、他人の環境を使ってみると何かしら気づきがあると思うので、まずは試してみるだけでも価値があると思います(環境設定まわりは時間泥棒なので、ほどほどが大切ですが…)。

今回紹介したZach Holman's dotfilesは合わなさそうだなと思われた方も、dotfiles.github.ioで紹介されている他のdotfilesプロジェクトの中には合うものがあるかもしれません。良いものがあったら私にも教えてください!


@hnw

↑このページのトップヘ