統計情報からサポートチャンピオンのクラスタリングと有利不利のグラフを作成してみた

lol

結論


統計をコネコネして最終的に今回得られた結果がこれ。
ただし情報元のサンプル数が少ないため、より正しい図を書くためにはサンプルの拡大が必要(でもお金と時間がかかるので尻込みしている)。
また統計解析の結果は見るものによって大きく解釈が異なるので、単一の解には程遠いし今の段階ではなんらかのヒントを示しているだけの段階。
平たく言うと、現段階の図はあまり真に受けないでください。

発端

slackで以下のtweetが回ってきたのがきっかけ。

観点として非常に面白いと思った(あと絵が素晴らしい！)。一方で統計的な勝敗情報(winrate)によりこのグラフを書いてみるとどうなるかと思った。
そこで、ゲームの勝敗結果のデータを使って上と同じようなグラフを作ってみることにした。

前提条件

同じタイプである、と分類できるほどタイプが似通っているチャンピオンは各チャンピオンに対するwinrateも似通ってくるはずである、という前提のもとクラスタ分析を行う。

例:
LeonaとBraumが同タイプのチャンピオンならば、Poke系Supportに対してはwinrateが低くInitiate系Supportに対してはwinrateが高い、といった同じ傾向のwinrateを示すはず。

入力(情報ソース)

Champion.ggのサポートチャンピオンのマッチアップ勝率
本当はRiotのAPIを直接叩いて一から統計データを構築するべきだが時間もお金もないのである程度集計されているchampion.ggを使用

出力(目指すアウトプット)

サポートチャンピオンのクラスタリング
似ているチャンピオンをはっきりさせ、どういった群のチャンピオンたちに対して有利/不利であるかを可視化する。

過程

1. champion.ggのページをスクレイピング、マッチアップ表を作成

コードは bigwheel/scrape-championgg-support-matchup
出来上がった表をgoogle spreadsheetに貼ったのがこれ https://docs.google.com/spreadsheets/d/1RmWnlCjvBqQvZIqdaANBEDo8vcIoUabL6Gt1LAvBQ4U/edit?usp=sharing

2. クラスター分析を使って各チャンプの勝率表からチャンピオンタイプを腑分け

データは出ているのであとは数学的手法で分類するだけ。こういった処理をクラスター分析というらしい。
クラスター分析にもいくつか手法があるらしいが、今回は一番シンプルそうな階層的クラスター分析を行う。

2.1 勝率テーブルから直接ユークリッド距離を算出して階層的クラスター分析

ツリーの近いところのものほど似ている(はず)という分析。
それほど悪くない分析かもしれないが、うまく言っているようにも見えない(特にLeonaとZyraが隣り合っていたりするところは明らかに直感に反する)。
もっともこれは想定内。勝率をそのままユークリッド距離の算出に利用しているため全体勝率が同じ程度のものは必然近くなってしまう(LeonaとZyraは勝率11位と12位で隣り合っている)。

全体勝率はそのときどきの他ロールのメタ(例えば他レーンでtankがはやっていないなら必然supportではtankを使うと勝ちやすくなる)やアイテムの強弱に影響されるため、
クラスター分析では全体勝率の影響を排除したい(各チャンピオンのタイプ分けという目的に対してノイズになるため)。

2.2 個別の勝率から全体勝率を差し引いたのち、直接ユークリッド距離を算出して階層的クラスター分析


こちらは結構想定通りのグラフが出てきている。
特にBraum, Nautilus, Leona, Alistarが同じ塊になっているところなどはドンピシャといっていい。
ただ、まだ少し直感に反するところがあるので(threshとsonaが隣り合っているところなど)もう少し分析手法を試行錯誤してみる。

個別勝率から全体勝率を差し引いたことで全体勝率の影響を弱めることには成功したはずだが、もうちょっと統計学的にまともな手法があったはず。
たしか偏差,標準偏差,分散とかがそれらに用いられた気がする・・・・。

2.3 勝率の偏差値を出したのち、直接ユークリッド距離を算出して階層的クラスター分析

よくなったような悪くなったような。分散で割ることによりサンプル数が少なくてピーキーな勝率になっていたtahm kenchがtankクラスタに吸収されたのは良くなった点だが、
Brand/Vel'kozの殺意100%クラスタの隣にsorakaがいるのは間違っている気がする。

ただ、これ以上により高い精度で分析するには現在データ元のサンプル数が少ないため(チャンピオン同士によっては100回も当たってないデータがある)、
クラスタリングの試行はこれぐらいにして、次はこれらのクラスタリングの解釈とそれぞれの相性関係を考察する。

クラスタ結果考察


上記の樹形図をだいたい5.4ぐらいの高さでぶった切って、以下のようにチャンピオンたちを分類する。

  1. バーストメイジA(バーストA)
    • Annie
    • Zyra
  2. ピール寄りユーティリティ(ピール弱)
    • Lulu
    • Taric
  3. その他(その他)
    • Lux
    • Sona
    • Thresh
    • Blitzcrank
    • Karma
    • Nami
  4. ピールガチ勢(ピール強)
    • Zilean
    • Morgana
    • Bard
    • Janna
  5. バーストメイジB(バーストB)
    • Soraka
    • Brand
    • Velkoz
  6. CCタンク(CCタンク)

これらのクラスタごとにwinrateの偏差値の平均値を取った表がこちら

さらにこれから強弱関係が際立っているもののみを抽出した有向グラフがこれ。
矢印の元のクラスタは矢印の先のクラスタに対して優位に立っているという意味。

ここから図に起こしたらこんな感じ
https://drive.google.com/file/d/0Bx1bwUKdICdQT2EzQVl2VWdyUkU/view?usp=sharing


参考資料

基本的に各ページを斜め読みしかしていないので、正しい知識を付けたいのなら直接各ページへ飛んで読んだほうがよい。
(余談だけど、このような素晴らしい資料がネット上に転がっているなんてすごい時代になったもんだなあ)

Ergodox Ez買ってキーマップ変更までしてみた

ergodox

この記事はとりあえずErgodox周りで感じたことなどをまとめるので割ととりとめないです。

購入動機

ErgoDoxを購入して人生がバラ色になった - YAMAGUCHI::weblog
などのページを見ててどうしても欲しくなったため購入。
キーボードへの出費としては今使っているRealForce 91(20k)を超える34K円の価格。

最近肩こりがひどくて、その原因が社内で使っているHHKが原因でないかと考えているのが1点。
社内で使っているMacBookProはディスプレイを1枚でも多く使いたい関係で閉じることができず、必然普通のフルキーボードは置き場所に厳しいのが1点。
昔からキー配置をいじるのが好きで試行錯誤を繰り返していたのだけど、Windows/Mac/Linuxと全環境でそれぞれのキー配置設定を行うのが辛くなってきて、またソフトウェア側でキー配置をいじるとペア・プロするときに問題があったり他人のPCを触るときにキー配置の違いで軽く困ったり、意図せず特定のキーをキー配置からなくしてしまって最悪OSにログインできなくなるようなリスクがあるのでOS側でキー配置をいじるのが嫌になり、ハードウェア側に配置を焼き付けられるようなキーボードが欲しかったのが1点。

注文から到着までの日数

公式サイトから購入。先駆者のレポートだと数カ月や2週間という記述が多かったので1ヶ月ぐらいは覚悟していたのだが実際には購入から到着までわずか8日しかかからなかった。安定して供給できるようになって到着までの時間が短くなっている模様（あとで比較的新しいレポートを読んだらやはり8日で届いたという記述があった）。
配達は海外から国内まで一貫してUPSだったのだが、ここ18時以降は配達してくれないらしく社会人が平日受け取るのはなかなか厳しい感じ。

到着から組み立て

僕は組立済みフルセットを買ったのでケーブルつなぐだけでとりあえず使えるようになった。

キー配置の試行錯誤

デフォルトのキー配置は最初から使うつもりがなかった。
理由は僕がQWERTYと大きく異なる配置を使うつもりがないから。
エンターの位置が違うのはいいとしてもCtrlや特に日本語入力を切り替えるためのキーがないこと、なにより数字キーがQWERTYとずれているのは許容できない。
（ちなみになぜQWERTYとの互換を気にするかというと今後もErgodox以外のキーボードを使う機会や、あるいはErgodoxを脱却する可能性を見越しているため。また他人に自分のキーボードを打ってもらう時や逆に自分が他人のキーボードを打つときになるべく混乱を起こしたくないから。数字キーとか1列ずつQWERTYとずれているものに慣れると戻った時にひどいことが起こるのは目に見えている。この辺はDVORAK配列を試した時の教訓から）。

先駆者兄貴の記事から方法を調べてキー配置を流しこむ方法を確立。
その後は少し変えてはキーを打って感触を確かめる、を繰り返して最終的に落ち着くキー配列までたどり着いた。
かかった期間は約2週間、作業時間はながら作業で約10~15時間程度。
ただしこの時間はいろいろ試行錯誤しつつ最適なキー配置を目指しながらだったので、
自分の中でこういう配列にしたいという確固たる方針が決まっていればもっとさっくり終わるとは思う。

作成したキーマップ

Ergodox Ez Apple JIS キーボードに寄せたキーマップを晒す - Qiita

自分が忘れないためにも、このようなキー配置に至った背景を書いておく。

まず、僕が作ったキー配置は基本的にMACのJISキーボードと極力配置を合わせており、Ergodox defaultをMac JISキーボードに合わせたような配置にしている。
既存のキーボードへ極力準拠している理由は今後も普通のキーボードと併用していくことを考えているから。
今回買ったErgodoxは仕事用で会社に持っていくつもりだが、自宅ではRealForceを使い続けることになる。
また仕事柄他人のPCやサーバのキーボードを利用する機会もあり、そのような機会に余計なリスクを持ちたくないため。

またErgodoxもいつまで使うかわからない。いつかまた別の配列のキーボードを購入した時、またそのキーボードのためにキー配置を大きく変更することは不毛。
よって基本的に既存のQWERTYへ準拠した配置にしている。

準拠の対象がMACのJISキーボードであるのは現在使っているキーボード配列の中で最も使いやすいから。
まあ結局のところ違うのは日本語入力で、Ergodox EZ を使ってみよう - Qiitaでも述べられているが日本語入力のON/OFFをそれぞれ1キーで行うのが使いやすい。半角全角キーがいらないためErgodoxでは数字キーの行をよりQWERTYに近い配置にできるという利点もある。

あと追加しているのはErgodoxのファームウェア流し込み用のRESETボタン程度でLAYER1,2はほぼ変更していない。
LAYER1,2はまだほとんど使っていないため、今後使っていく中で変更したくなるかも。

キー入力速度を測ってみた

2時間ぐらい前にやっとキー配置に満足してこの記事はそのErgodoxを使って書いている。
タイピングソフトを利用して普段使っているRealforce91とどの程度速度差があるか測ってみた。


前者がErgodoxで後者が今まで使っていたRealforce
こんな感じでErgodoxの方もすぐ慣れてそこそこの速度でタイピングできるようになっている。
ちなみにこれ最初に実行したのがErgodoxだったので問題に対する慣れによりRealforceのほうが有利なのだけど、それほど差が出ていない。
慣れていない状態でこれだけでているのですぐにErgodoxの方での入力速度もRealForceに追いつきそう。

これから購入する人たちに対する奨め

Ergodox Ezは完全に組立済みの製品を送ってくれるため、組立作業は一切要りませんが一方で実用的に使用するためにはキーマップの書き換えがほぼ必須です。
キーマップの流しこみ手順はErgodox EZ を使ってみよう - QiitaやErgoDox EZのキーマップを変更する - Qiitaの記事などで非常に丁寧に説明されていますが、それでも最低限C言語の知識は必要になります。
現実的にはプログラム経験のある人でないと厳しいでしょう。
もしキー配列を変えないのであれば、むしろKINESISでいいかもしれません。
値段は上がりますがErgodox Ezのデフォルト配列に比べれば比較的素直なキー配置になっています。

また、まだ3万円超と非常に高価なデバイスですのでキーボード作業を頻繁に行わないような人も費用対効果が薄いでしょう。

キー配置自体、まだ日本語入力用のデファクトスタンダードのようなものは認知されておらず各々が試行錯誤しながら自分のキー配置を決めている段階です。
自分でキー配置をいじるようなことを過去にしてきた、またはこれからする覚悟のある人間でないと難しいでしょう。



もし購入することを決断したら、はじめてのErgoDox EZ購入ガイド - Qiitaをチェックすることをおすすめします。
僕は勢いで買ったのでものが届いてから印字されたキーキャップと印字されていないキーキャップはキーキャップの形も違ったことなどを知りました（幸いフラットでないほうが良かったので後悔せずに住みましたが）。

キー配置については現状は各々考えがあると思います。
好みや経験によって人により最適な配置は違うと思うのでこうすれば良いというのはないのですが、
先駆者が推奨しているRESETキーの配置だけは絶対にやっておくことをおすすめします。
理由はそこにも書かれている通り非常にRESETボタンが深いためで、シャーペンも安全ピンもない我が家では部屋中探しまわって細長いものを探しました。

届いたら、個人的にはすぐキー配置を変更し始めることをおすすめします。
Ergodox Ez標準のキー配置はレイヤー等独自の概念を覗いたとしてもかなりの変態であり、特にキーボード最上段の数字キーがずれている点と左手小指左側のCtrl/Caps/Tab等が全く違う点、日本語入力用の英数/かな/入力切替等がまったくない点などそのままでは多くの人が使いづらいと感じるはずです。

それに合わせると決めて全力でデフォルト配置になれるのも一つですが、僕はデフォルト配置はなるべく使わずすぐに自分の使いやすいように変更することをおすすめします。
その際、できるだけ集中して素早く自分のキー配置を決めることをおすすめします。ここでだらだらするとErgodoxを使わないまま机の脇において使い慣れたキーボードを使ってしまい、そのまま誇りをかぶらせて3万円の置物にしてしまいます（Ergodox挫折する人がいると聞きましたが大方が自分のキー配置を決める手前で挫折するのだと思います）。
僕も自分のキー配置を決めるまで2周間かかりました。自分に最適なキー配置を試行錯誤していたためですが、動画等見つつながら作業で10時間以上はかかったと思います。もともとキー配置などを最適化することが好きだったためずっと楽しみながら作業していたのですが、すぐ使いたい人にとっては結構な苦痛かもしれません。

蛇足

Ergodox、これ完全ワイヤレスだったら+1万払っていいという人は多そう。というか僕は出す。
Ergodox Ezがワイヤレス版をリリースしてくれないかなあ。してくれたら今回買ったのは会社用にしてワイヤレスのを自宅用で追加購入するのだけど。

今後できたらいいなあと思うもの

Ergodox用のキー配置を共有、評価できるような専用サービスがあると便利そう。
あとkeymap.cをアップロードすると自動でコンパイルしてhexファイルをダウンロードできるようなサービスもあると便利だけどC言語だからセキュリティ関係の問題で厳しいか。

lol中に激しいラグが発生したため調査したこと その後1

lol

本日、以前と同じ現象がゲーム中に発生した(logsoflagの可視化結果はこちら)。
pathpingコマンドとpingコマンドでパケットロスが発生する箇所を調べたところ、やはりルータを出て直ぐの箇所(tok7nn1m3.vectant.ne.jp)だった。
おそらくマンション内にかなり近いところで問題があるとかんがえられるため、NTTフレッツのサポートへ連絡する。

続きを読む

lol中に激しいラグが発生したため調査したこと

lol

現象

lolをプレイ中にaaの間隔が不規則になったり移動がキャンセルされたり(ラバーバンド現象)敵やミニオンが瞬間移動するような現象が発生した。

目的

プレイ精度・ストレスを改善するために問題原因・解決法を見つける

調査過程

一緒にプレイしている友人に依頼してLogs of Lagを利用してネットワークログを調査した結果、以下のことがわかった。

  • 上記現象を感じたときは http://logsoflag.com/#N7Jcqlkw1VP のようにパケットロスが大量に発生
  • 現象を感じなかったプレイのときはパケットロスはほぼなし
  • 自分が現象を感じたとき、同じゲームを同時にプレイしていた友人側ではパケットロスなし
  • 上記現象が起こるのは平日の22時前後もしくは休日の昼間が多い
  • Logs of Lagサイトで表示される典型的なbad networkは http://logsoflag.com/#v1yiEVKr7_p のようにping値も瞬間的に増えるが自分のケースではすべてping値は120前後で安定している

今後の行動

調査の結果、まず自分の通信経路のどこでパケットロスが頻発しているのかを調べる必要があるという結論になった。
よって今後は以下のように動く。

  1. 次に上記現象を感じたプレイ中にコマンドを実行 「pathping -q 200 66.150.148.1」
  2. パケットロスが大きく発生する場所を確認
    • 国内で発生してる場合 → NTTもしくはプロバイダーに報告、改善を要求
    • 国外で発生している場合 → VPNを通して接続することで改善するか確認

参考:ラグを(それほど)感じない時のpathping結果とパケットロス

パケットロスが100%になっている箇所はおそらく直接のネットワーク接続を禁止している箇所かもしくはpingを拒否している箇所なので、もっとも怪しいのは5%のパケットロスを発生させている ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109] か。

http://logsoflag.com/#L_12aS5cgJ5

C:\Users\kbigwheel>pathping 66.150.148.1

66.150.148.1 へのルートをトレースしています。経由するホップ数は最大 30 です

  0  flagship [192.168.24.20]
  1  192.168.24.1
  2  tok7nn1m3.vectant.ne.jp [163.139.126.199]
  3  163-139-126-222.rv.vectant.ne.jp [163.139.126.222]
  4  163-139-68-53.rv.vectant.ne.jp [163.139.68.53]
  5  ae0.core1.otemachi.vectant.ne.jp [163.139.128.54]
  6  ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109]
  7  ae-11.r25.tokyjp05.jp.bb.gin.ntt.net [61.213.162.173]
  8  ae-1.r20.tokyjp05.jp.bb.gin.ntt.net [129.250.6.210]
  9  ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.12]
 10  ae-1.r05.sttlwa01.us.bb.gin.ntt.net [129.250.5.47]
 11  be3048.ccr21.sea02.atlas.cogentco.com [154.54.11.9]
 12  be2083.ccr21.sea01.atlas.cogentco.com [154.54.0.249]
 13  be2075.ccr21.sfo01.atlas.cogentco.com [154.54.0.233]
 14  be2164.ccr21.sjc01.atlas.cogentco.com [154.54.28.34]
 15  be2160.ccr21.lax01.atlas.cogentco.com [154.54.27.161]
 16  be2019.ccr21.lax04.atlas.cogentco.com [154.54.88.10]
 17  38.88.197.162
 18  border1.po1-40g-bbnet1.lax010.pnap.net [216.52.255.13]
 19  66.150.148.1

統計を 475 秒間計算しています...
            ソースからここまで   このノード/リンク
ホップ  RTT    損失/送信 = Pct  損失/送信 = Pct  アドレス
  0                                           flagship [192.168.24.20]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.24.1
                                0/ 100 =  0%   |
  2    4ms     0/ 100 =  0%     0/ 100 =  0%  tok7nn1m3.vectant.ne.jp [163.139.126.199]
                                1/ 100 =  1%   |
  3    6ms     2/ 100 =  2%     1/ 100 =  1%  163-139-126-222.rv.vectant.ne.jp [163.139.126.222]
                                0/ 100 =  0%   |
  4    7ms     2/ 100 =  2%     1/ 100 =  1%  163-139-68-53.rv.vectant.ne.jp [163.139.68.53]
                                0/ 100 =  0%   |
  5    8ms     2/ 100 =  2%     1/ 100 =  1%  ae0.core1.otemachi.vectant.ne.jp [163.139.128.54]
                                0/ 100 =  0%   |
  6    8ms     6/ 100 =  6%     5/ 100 =  5%  ae-2.a21.tokyjp01.jp.ra.gin.ntt.net [61.213.160.109]
                                0/ 100 =  0%   |
  7    9ms     4/ 100 =  4%     3/ 100 =  3%  ae-11.r25.tokyjp05.jp.bb.gin.ntt.net [61.213.162.173]
                                0/ 100 =  0%   |
  8    8ms     4/ 100 =  4%     3/ 100 =  3%  ae-1.r20.tokyjp05.jp.bb.gin.ntt.net [129.250.6.210]
                                0/ 100 =  0%   |
  9  101ms     3/ 100 =  3%     2/ 100 =  2%  ae-2.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.12]
                                0/ 100 =  0%   |
 10  111ms     1/ 100 =  1%     0/ 100 =  0%  ae-1.r05.sttlwa01.us.bb.gin.ntt.net [129.250.5.47]
                                3/ 100 =  3%   |
 11  128ms     5/ 100 =  5%     1/ 100 =  1%  be3048.ccr21.sea02.atlas.cogentco.com [154.54.11.9]
                                0/ 100 =  0%   |
 12  ---     100/ 100 =100%    96/ 100 = 96%  be2083.ccr21.sea01.atlas.cogentco.com [154.54.0.249]
                                0/ 100 =  0%   |
 13  ---     100/ 100 =100%    96/ 100 = 96%  be2075.ccr21.sfo01.atlas.cogentco.com [154.54.0.233]
                                0/ 100 =  0%   |
 14  123ms     6/ 100 =  6%     2/ 100 =  2%  be2164.ccr21.sjc01.atlas.cogentco.com [154.54.28.34]
                                0/ 100 =  0%   |
 15  126ms     4/ 100 =  4%     0/ 100 =  0%  be2160.ccr21.lax01.atlas.cogentco.com [154.54.27.161]
                                0/ 100 =  0%   |
 16  119ms     5/ 100 =  5%     1/ 100 =  1%  be2019.ccr21.lax04.atlas.cogentco.com [154.54.88.10]
                                0/ 100 =  0%   |
 17  119ms     4/ 100 =  4%     0/ 100 =  0%  38.88.197.162
                                0/ 100 =  0%   |
 18  114ms     5/ 100 =  5%     1/ 100 =  1%  border1.po1-40g-bbnet1.lax010.pnap.net [216.52.255.13]
                                0/ 100 =  0%   |
 19  114ms     4/ 100 =  4%     0/ 100 =  0%  66.150.148.1

トレースを完了しました。

第4回elasticsearch勉強会

elasticsearch

第4回elasticsearch勉強会 - elasticsearch勉強会 | Doorkeeperのログ
発表スライドは第4回Elasticsearch勉強会を開催しました。#elasticsearchjp - @johtaniの日記 2ndにまとまってる。超助かる。

株式会社シーマーク　大谷　純　@johtani タイトル：「アナライズ処理の仕組みとクエリDSL」

  • elasticsearchのcharFilter, tokenizer, tokenFilterの適応順番
  • そもそもanalyzeされるクエリとそうじゃないクエリがある。どれが適応されるクエリか
  • apache solrのanalyze画面のように、analyzeの仮定を表示するプラグインの紹介

株式会社マーズフラッグ R&D部　やまかつ さん　@yamakatu タイトル：「elasticsearch-hadoopを使ってごにょごにょしてみる」

  • 本質的にはhadoopのストレージとしてelasitcsearch上のデータを扱えるようになる
    • hadoop上のデータを検索できるようになる、ではない。注意
    • hadoop上のデータをelasticsearchにwriteするだけっていうのもできる

株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak タイトル: 「CouchbaseとElasticsearchが手を結んだら」

  • couchbase - couchdbではない
    • メモリ+ストレージのハイブリッド・キーバリューストア
    • スケールアウトなども考慮されてる
    • ただし、現状データ横断的な処理は苦手
  • couchbaseのcross data center rsync...? の機能を使って、elasticsearchをcouchbaseに見せかけるプラグインを使用して、elasticsearchをさもcouchbaseの1クラスタのように見せる
    • ただ、RDB, couchbase, elasticsearchの3構成でcouchbaseはDB
  • ちなみに、以下のように統一していく流れ
    • 外部からElasticSearchへ流し込むプラグイン → River Plugin
    • Elasticsearchから外部へ転送するプラグイン → Transport Plugin

Wantedly, Inc 内田誠悟さん @spesnova タイトル：未定

  • 詳細忘れた。この会社の知名度がすごく高くて驚いた

LTその1 スクリプト使ってみた

  • dinamyc script - 開発向け
  • server side script? - 運用向け
  • native? script(java)

LTその2 basistechさんのプラグイン宣伝

git-trash-branchを作ってみました

git

gitでブランチを操作しながら開発してるとき、よくブランチを完全削除ではなく一旦ゴミ箱的な場所に移したいと思うケースがありました。
gitのブランチ削除は復元する方法がないため、もし削除してしまったブランチをもとに戻す場合は泣きながらreflogでハッシュ番号を漁る必要があります。しかし、それを恐れて無駄なブランチを削除しないと使わないブランチがどんどん増えて、どれが今開発してる（生きている）ブランチなのかわからなくなってきます。
現状ではそういった「たぶんいらないブランチ」はgit branch -mオプションを利用してtrash/というプレフィックスをつけていました。これにより今使ってるブランチといらないブランチをはっきりと区別することができます。ただ、branchAをtrashへ移動させたい場合、

$ git branch -m branchA trash/branchA

とbranchAという文字列を2度打つ必要があり面倒でした。加えて、全体的にコマンドが長いです。
そこで、gitのサブコマンドを自作して以下のように打てるようにしました。

$ git trash-branch branchA

ソースコード、インストール方法、使い方はbigwheel/git-trash-branchを参照してください。

今回はシェルスクリプトのコードに対してrspecで単体テストを書くという自分では初めての挑戦をしています。これ、やってみるとかなり良かったです。ruby自体がかなりコマンド実行と親和性が高いため、両方書ける人ならかなり直感的に書くことができます。

あとやり残したこととしてはインストールをchefで書いて、chef-applyからコマンド一発でできるようにすることぐらい。

gitサブコマンドの書き方備忘録

git プログラミング

gitのサブコマンドを書こうとしてもはや何度目かわからないshell scriptの書き方再勉強をしていた。不毛なので、ここに関連URLを残しておく。