rubyXLが神
openpyxl → 罫線が消える。rubyXLが表の再計算できないと思ってrubyから呼び出していた。
rubyのその他 → excelが壊れる、officeへの依存があるっぽい
rubyXL → 昔は表の再計算機能がなかったらしいが現在は実装済み。xlsx形式で保存ができるし、罫線が消えない。
rubyXLデフォルトでは再計算しないので以下のあれをあれする
book = RubyXL::Parser.parse(path) book.calc_pr.full_calc_on_load = true book.calc_pr.calc_completed = true book.calc_pr.calc_on_save = true book.calc_pr.force_full_calc = true
危うくいちいち罫線をプログラムで引くところだった。
これを書いた人はtemplateとして元となるエクセルを読み込んでrubyXLで数値を書き込むというプログラムを書いています。
GKE debug memo
gcloud auth login gcloud config set project ${project-name} gcloud compute instances list gcloud compute ssh ${instance-name}
えくせる
rubyでexcel操作をしたく、spreadsheetというgemを使って対応していた。そこそこ装飾のあるエクセルをテンプレート的に読み込んで保存すると、Excelを開いたとき謎のエラーが出て辛かった。これはヤバイ、納期間に合わん。うまいことテンプレート側のExcelを調整してエラーにならないように運用でカバーしていたが、rubyXL使ったらすべてが解決した。
太古のExcelを使ったいる人のためを思いxls形式にしていたけど、xlsxのほうが安全に操作できるんだろうなぁ、中身xmlだし。おそらくだがxlsのバイナリだとあれがあれした場合にライブラリが対応できていないんだろう。
もう4/25か。早いな。
This IP can't make requests for that application.
Goのテストパッケージの末尾に_testをつけるかつけないか問題
一行
原則つけたほうが良い。
違い
末尾に_testを付ける場合
対象のパッケージとは別物と認識され、private methodを呼び出すことはできなくなる。
ここでprivate methodのテストができないじゃないか問題が発生するが、外部に公開している振る舞いのテストが担保されていれば問題ないという考え方をベースにすればprivate methodのテストを行う必要は無いため問題ない。public methodを呼び出すことでprivate methodを疎通させてカバレッジをカバーすれば良い。
private methodまでテストを書くと、継続的にリファクタリングや機能追加を攻めて行うためにテストコードを書いているのに、それのメンテコストがかかり足を引っ張ってしまうことになるっぽい。例えば機能追加をしようと思ったらテストコードめっちゃ書き換えないといけない・・・とか。
どうしてもprivate methodのテストを行いたい場合は、_internal_test.goとかいう名前のファイルを作り別だしにして書いている人とかいるみたい。
末尾に_testをつけない場合
実コードと同じパッケージとみなされるため、private methodも含めすべて参照できる。詳細なテストが可能。
闇雲にすべてのテストを書くと見通しが悪くなることがあるのと、メンテのコストも掛かるので気をつけるべし。
どうするのが良いのか（個人的な意見）
原則として_testをつけて、このパッケージの利用者観点で振る舞いのテストが行えればOK。
private methodのテストも行いたい場合は_testをつけずにファイル名を_internal_test.goとしてテストコードを書く。
private methodのテストがとても重要なら、_testをつけずに xxx_test.go などのファイルにテスト書いてしまってもいいと思う。
