githubのバックアップ

次作のMASネタでは、ちょいとしたgistの管理を一部機能として企てているため、github api v3について調べてたついでにgithubのバックアップスクリプトを書いて、10.11動作検証兼、BackupマシンのMid 2010 MBP機で毎7600secごとに走らせているのだけど、手元で私的に走らせるだけではもったいないのでgistに置いてみた。

 

最後のほう読めば解るけど、定期的にrepoを見て、backupサーバに展開されてなければclone、あればfetchしてlocalはなるべく最新に保つ。

そこまでやっておけば、もし別環境から新しくrepoを立てたり、forkしたとしてもローカルにとっておいてくれるし、macなのでHDDに落としておけばTimeMachineにお願いできる。

 

加えて全issueとそのときの全ラベルをprojectごとにjsonで取っておく。

私的にはissueってただの申し送り、もしくはtodo管理をするものではなく、knowhowを最もリアルに動くコーディング作業に即して書き留められるノートなので、open/close関係なくこれが全部吹っ飛ぶと思うとぞっとする。

もちろんprivate gistにsnnipetsとして書き留めるように心がけてはいるけど、どのコンテキストでどう動くかまではgistではちょっと辛いので、調査結果として動くコードをまるごと何がどう動いているのか取っておきたい。

 

残課題は、

issueに即したcommitの紐付けまではまだ取れていないのと、csv化。

個人的にcsvつまりエクセルやらシートでissueをみたいと思ったことがないのでcsvはやらないかも。

ただ、ネットに転がってるコードをいくつか見てて、各issueをcsvとかに変換するなら、webApiから持ってきたjsonをいきなりcsvライブラリで書き換えるより一旦jsonをオリジナルとして持ってて、別目的としてコンバートコードを噛ますほうが好みなので、この方針で行くなら今回のコードは論理的にどちらにせよ必要になる。

csvもしくはエクセル変換はそのうち気が向いたら(何かしら価値をみいだせたら)書き加えるかも知れない

(python, ruby, CPANあたりだと、色付けたりグラフ書いたりかなりゴリゴリと直でエクセルいじれるんで）

できればcsv等似非データに書き換えるのではなく、waffle.ioみたくオリジナルを都度興味の対象だけ読み替えて、エクセルIFのみを提供するような形に持って行きたい。

 

ちなみに下記pythonコードには元があるのだけど、v3で全然走らなかったのと、関数の分け方に難があった、目的がjsonのcsv化だったため99%書き直した。クラス化されていないのはその名残りです。

 

あ！これだけあればなんとかなりそうというところまでは取ってあるけど、リストアのリハーサルはしてないや。。。やだなー怖いなー

とりあえず目的はknowhowの実践テストといつまたどこぞの愚か者がIoT向けDNSにDDOSかけても自分だけは大丈夫という精神安定剤ですね。