次作の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かけても自分だけは大丈夫という精神安定剤ですね。
ぱくりと言われようと、便利なモノは便利なわけで。
swiftもPythonと同じようにdefault引数設定ができるわけだけど、Appleのドキュメントにはあまり明示的にこう使えと書いていないので、備忘。
まず、Pythonでもswiftでも私がdefault引数をよく使うシーンは、リファクタリングの時。
例えば、ある関数が外部とのIFとして立てられていたとする。
internal func hoge( ) {....
ただ、今この瞬間から似て非なる新仕様をぶち込まれ(みたくなっ)て、hogeに引数を待たせたバージョンがあると、全体設計として非常に管理しやすくなるじゃんという状況になったとしよう。
Javaなんかだったらこうする。
// テストが通っているのでこれは凍結
internal func hoge( ) {....}
// 新IFとして、新規コードからはこれを呼ぶ
internal func hoge(abc : [Abc]) {...
これはswiftでもPythonでも同じようにできたのでサブセットして道具箱に入れておくといいかもしれない。
ただしこれが、デフォルト引数を持っている言語だとこう表現できる
internal func hoge(_ abc: [Abc] = []) {
if abc.isEmpty {
// 昔のhoge()を一文字違えず埋め込むか、sub関数管理にする
....
} else {
// 新規コードからのIFとして引数版のhoge処理
}
Java版もそうだけど、これらの何が嬉しいのかというと、既にコード中にアホほど存在するcaller hoge()はびた一文書き換えなくてすむし、挙動変化が管理しやすい。あと従来関数と機能のfusionがしやすい。
なおJava版のほうも決して悪いわけではない。
ファイル長に寛大で、関数単位でバージョン管理するのがしっくりくるようなチームならむしろJava版の方が合っているでしょう。こっちもfusionするならhoge(abc:...)の中で条件によってhoge()を呼べばいい。
要はwrapperで統一IFにする。
私的になるたけ1ファイルは低ノイズで主張点だけに絞ってざっと読み込みたいほうなのと、Python流が苦ではないので後者のほうが好きというだけの話。
大事なのは、十分テストされたといえる既存コードは可能な限り保存して、新規コードとは分離できるところ。これがOOPの基本嬉しいこと。
なんなら引数に関数を放り込むIFにして、default nilにしておいてもいい。
こうするのがややこしくて、少人数で作ってて、連絡コストがそう高くないなら、hogeをnewHogeと改名する方向でもいいかも
// internal func hoge ...
available(*, deprecated: X.x, message: "ツカウナキケン")
private func hoge() {...}
internal func newHoge(....
こちらの方が、新IFからは確実に使えなくなり境界がはっきりするので、状況によっては一貫性を保ってテキスト全置換でいっそ変えてしまった方が理想。
コンパイラは関数名なんざ数列にしか見えてないので。
ただし文字ヅラに騙されて変なミス入れ込むのが人間。これが現実。
特に私は間抜けなので、よく全置換をやって、かつコメントも何も残してないもんだから、何時間もうんうん唸って(泣きながら)ふて寝したあとに、そういえばそうだった！とさもエウレカを得たような気分になって正常軌道に戻すことはあるけれど。。。でもそれって気をつけていれば一切支払わなくていいコストだったわけで、結局損失なのでよほどじゃない限り避けるようにはしている。
ちなみに、availableに頼るときはprojectで一貫したwarning controlがされていて、意識的にwarningの見分けが付く状況でないと意味はない。
砂丘の砂粒ほどwarningが存在する中で、"ツカウナキケン"を意識して見わけるのはもはや拷問。
Objective-C, 仕様検討, 個人的見解, 思案中
元OS屋から見て普通に考えるとCocoaでは演算高速化のため、NSExpressionによる統計関数を用意している(のだと思う)
なぜなら、開発サイドから見ればそうすることにより
なんて戦略が取れるから。
しかしググった感じ、iOSではNSExpression#expressionForFunction@”median:”は使えない?なんてレポートもちらほら…いや、中央値出せなくてpercentile出すのはめんどくさい。なにより統計コードの天敵は計算ミス。
中央値算出くらいなら奇数サイズなら配列の真ん中、偶数サイズなら中央2項の算術平均取るだけなので、簡単でバグも入りにくいから自分で書いてもいいけど、sciPyが使えれば演算速度以外のほぼ全ての問題は解決するので、iOSへのPython組み込みとのProsVSConsに関しては非常に悩ましい。 ;
ちなみに、自分の間抜けさを熟知しているプログラマほど自分で書くことを避ける。なにより、世の中で既に誰かが書いてて、公開されてて、かつ動いてるコードを僕がスクラッチから起こす必要はどこにもない。
とも思いつつ、だめもとで
NSExpression#expressionForFunction@”median:” arguments
NSArray*)…
使ってみた。
—– [XXX:XXX] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[theObject compare:]: unrecognized selector sent to instance 0xXXXXXX’
いやいやいや…自分の間抜けさを実感させられただけでした。このログはtheObjectを直比較してるので、どの属性で比較したいか解らんと怒られてます。
それだけ？使えんじゃん！
ちなみにiOS8.4 SDKのヘッダにはこうコメントされている
+ (NSExpression *)expressionForFunction
// Expression that invokes one of the predefined functions. Will throw immediately if the selector is bad; will throw at runtime if the parameters are incorrect.
// Predefined functions are:
// name parameter array contents returns
//————————————————————————————————————————————-
// sum: NSExpression instances representing numbers NSNumber
// count: NSExpression instances representing numbers NSNumber
// min: NSExpression instances representing numbers NSNumber
// max: NSExpression instances representing numbers NSNumber
// average: NSExpression instances representing numbers NSNumber
// median: NSExpression instances representing numbers NSNumber
// mode: NSExpression instances representing numbers NSArray (returned array will contain all occurrences of the mode)
// stddev: NSExpression instances representing numbers NSNumber
……….
つまり、公式に記述のあるOSX 10.5 laterにくわえ少なくともiOS8.4では最頻値まで使えるんじゃないか？
インチキ英語しか身につけてないので読み飛ばしただけかもしれないけど、だったらそう書け…
アルゴリズムとしては
以上。ヒンジならこれで必要十分なはず、あとはこれをネタ元に配列が更新されたら四分位数再設定
sciPyのscoreatpercentileみたいにするなら四分位数からバイナリ探索して何percentileか出す。
レコード数が大きいから毎回Zone評価してリンク組み替えよりは算術探索の方が速い(はず…
テスト用に組み込んであるPythonの検算コードとも値は一致したので、とりあえず一件落着?
pyObjC組み込んだはいいけど、全然速度が出ないなんていう事態が怖くていまいち腰の重い僕でした。
from WordPress
How to Struggle Against S/W
http://ift.tt/1Ns1dKL
