quattro_4's diary

また同じ過ちを繰り返すと気付かんのか!?

自分専用のCIを使ってRailsの開発効率を上げる

テストをわざと壊して効率的に開発する - quattro_4's diary
の記事に書いた内容に関連して、最近自分専用のCI的なものを欲しいと思っていた

幾つかの手軽な方法として思い浮かんだのは

  • Travis CIを使う
  • 自分専用のCIをMac miniなど別のマシンで構築

Travis CIについては、会社で有料プランの2 Concurrent jobsで動いていて、現状運用としては十分なレベル
一つレガシーなプロジェクトが1時間くらいかかるものがあって、それが更新されると2つのjobsを占有して待ちが生じて多少効率悪いことがある
3 Concurrent jobsのプランがあればぜひ利用したいが、次のプランは5 Concurrent jobsでそこまでは必要ない

プランを上げても起こるデメリットとしては、テストを壊す目的で使うブランチがTravis CI上やgitレポジトリ上で他の人にとってノイズになる
Concurrencyが増えても、レガシープロジェクトにブロックされる可能性は残るなどがある

自分専用のCIをMac miniなど別のマシンで構築について
自分だけテスト専用のMac miniを置いておくというようなのは正直他の人から見たら少し変。
オフィス内で利用できるテスト専用端末を会社で導入というのも考えられる。
他の人も使ったらどうかという話になる。その端末のメンテも結局は必要。とか結局いろいろ面倒になりそう。
マシンの初期費用がかかるし、ベストとは言い切れない


最終的に落ち着いた方法は、自宅のiMacを利用する方法
最初はwemuxなどを使ってできないかと思ったが、リモートネットワーク経由で何かしないですむならその方が良いと思った
結果的にはかなりシンプルな方法になった

使うものは

Dropbox上に対象のプロジェクトを置く(コピーまたは、新規にチェックアウト)
pushを許可

cd ~/Dropbox/path/to/my_project
git config --add receive.denyCurrentBranch ignore

作業プロジェクト上からそのDropbox上のものへ参照

git remote add share ~/Dropbox/path/to/my_project

iMac上でjenkinsを動かして、ローカルのDropbox上のレポジトリをポーリングする
通常使う失敗時のEmailと合わせて、毎回失敗した内容を確認したいので「拡張Email通知」で「Always」を設定し、常時通知するようにする

あとは作業したブランチをDropbox上にpushするだけ

結果として、MacBook上で全テスト走らせるより多少早いフィードバックが得られるようになった(iMacは16Gのメモリがある)
後場合によってはjenkins上で早く結果の出るspecごと細分化・パイプラインまたは並列化してみる方法も考えられる
(models -> controllers -> features他)


一つつまづいた点としてはgitの"--bare --shared"などのオプションでレポジトリを使おうとしたけど、参照する側でなんかうまくいかなかったので諦めた
結果、なんらかのリスクがありそうな"receive.denyCurrentBranch"を使わざるを得なかった

SMTPで使っているGMailアカウントはメインのとは別の無くなってもそれほど困らないアカウント


今回のような方法に行き着いた流れとしては、別でMacBookの調子が悪かったのがあった
Macがkernel panicで予期せず再起動していたのを直した話 - quattro_4's diary

調子が悪くなったことで、最悪自宅のiMac上で開発できる状態に持っていくこと、wemuxなど試したことがヒントになった

テストをわざと壊して効率的に開発する

最近効率の良い開発の進め方について良く考えている

一番これ良いなと思える方法は、Breaking Driven Development
個人的な造語段階だが、破壊駆動
手法としては、変更を加えようとしている部分をわざとテストが落ちるように変えてすべてのテストを走らせて、その落ち方から次の方針を導き出す

これをやると

  • 影響範囲の把握が最速でわかる
  • デザインが洗練される
  • 無駄なテストが減る
    • 足りないテストがわかる
    • 足りない制約(validation, authorizationなど)がわかる
    • JSのコード内のリスクの発見

(破壊するための)変更の具体的なパターンは次のようなものが思い浮かぶ

  • factory/validation/relation/filterのオン・オフ
  • 一時的なraiseを追加
  • わざとtypoを混入

ただ一つ大きな欠点がある

全テストを走らすのに時間がかかる

全テストを走らすのに5分〜数十分かかっているものを数分に押さえるのが今一番に考えている課題


テストのFailuresの結果を見れば、その場その場で次どうしたら良いかはわかるのだけど、そのルール・パターンを明示的にまとめることはできていない
今後余裕があれば、具体的なコードと一緒にパターンを追求していきたい

Macがkernel panicで予期せず再起動していたのを直した話

使用しているマシーンはMacBook Pro (Retina, 13-inch、Early 2015)

症状としては

  • ある日から突然、1日に2〜3回予期せず再起動するようになった
  • 画面が一瞬(数秒)止まる、トラックパッドが反応しなくなる
  • 放置していても起きていることがある
    • 負荷が高いと起きるとは限らない
  • 落ちる時のアプリケーションに規則性はない
  • OS X El Capitan 10.11.6
    • 過去2週間で大きなアップデート、インストールは無し

直した方法の結論から言うと「NVRAM/PRAMのリセットを行う」⌘⌥+P+R
参考にしたのは検索上位で見つかった次の記事
Macがカーネルパニックを起こした時に試したい8つの対処法 | gori.me(ゴリミー)

今回の問題について、いろいろ検索で調べて書かれている症状と比較して、自分の症状で特徴的だったのが、
(1) カーネルパニックが起きる時のタイミング、アプリケーション、ログの内容などに規則性が無かった

(2) 起動音を消すスクリプトを使用していて、これが電源を落とした時などに動作している
El CapitanやSierraでMacの起動音を確実に消す方法

直ってみれば、起動音消すのを試した時に、別の方法でnvramを変更する方法もあったので、このスクリプトが影響して壊れる可能性も十分ありうるなと思った


今回学んだことは、Appleのフォーラムなど読みにくい情報も多いが、複数の情報から理論的に考えていけば、正確な情報は見つけられると思った
買い替えやApple Store持ち込みをする前にできることはだいぶある

"PRAMクリア Appleの電話サポートでも、対策の一つとして一番初めににこれを勧められました。簡単にできる"
(再起動時の画像を検索したついでで見つけた記事)
Macのカーネルパニックが未だに頻発。解決の為に自分で試した6つ事! | [毎朝8時更新]Re:birthDesign Blog

他に見つけた正しく書いていそうなサイト(SMCはPRAMとは別物)
2017年2月からMacBookタイプのSMCリセットが変わった!? - Apple In

OSインストールはPRAMをリセットしない
"A fresh OS install won't reset the hardware, SMC or PRAM."
macos - Does clean install reset everything, including SMC? - Ask Different

規則性がないカーネルパニック(occasionally resulting in a kernel panic, random kernel panics)
Bad NVRAM NVRAM consists of a small amount of memory dedicated to storing important settings for the way Mac OS X interacts with hardware components. For instance, one NVRAM variable tells the system how much primary RAM to recognize.
These settings can sometimes become correct or otherwise problematic, occasionally resulting in a kernel panic. As such, clearing NVRAM can prove a quick fix when the cause of random kernel panics or particularly kernel panics at startup proves elusive. (see "Kernel panics at startup or shutdown" section below).
Tutorial: Avoiding and eliminating Kernel panics - CNET


やったこと、今回効果無かった

解決した方法

  • NVRAM/PRAMのリセット

なぜか「NVRAM/PRAM」は違うと予想してスキップしてしまい、無駄な作業も多かったがクリーンインストール復元とか、買い替えを余儀なくされた時の良い予行練習になった
DropboxGitHubに必要なものを全部上げておくことが重要と認識した

Rubyでスクレイピングする話をしました “Web Scraping with Capybara”

trbmeetup.doorkeeper.jp

Kindleの情報集めるやつ kindle_manager
Amazonの注文履歴を集めるやつ amazon_order
を作ったので興味ある人は試してほしい

特にamazon_orderは誰でも使えると思う
自分の過去のAmazonでの注文履歴10年以上を合計したら300万超えてて反省の余地ありそう

次のような感じで簡単に集計出せる

f:id:quattro_4:20170708220254p:plain

あとKindleも次の感じで概算できて、全然読まないくせに無料のコミック1巻を買いまくっているのをやめられないでいる
反省すると無料本や安売りセールの本は出費は問題ないが、
無駄に買うことで本来読むべき本が埋もれてしまっているのが大きな問題

f:id:quattro_4:20170708220333p:plain

今年やったこと

やらなかったことはブログを書かなかった


何をやっていたかというと
主に分析回り

形になったものに関連するものを挙げると

  • Exploratory
    • dplyr
  • shiny + shiny server
  • RStudio
    • RMarkdown (knitr)
  • Jupyter
    • pandas

自分の扱っているテーマは、世間的に盛り上がっている大きいデータとは違いあまり大きくないので、Machine Learningなどは興味はあるが、深くやる機会がない


形にならなかったが少し触って使い方は少し分かったもの

  • caret
    • RandomForest
  • scikit-learn
  • tensorflow
  • mecab
  • 画像処理

ずっとやってみたいが全く手をつけられていないもの

普段は、環境に恵まれているのでRails周り(Rails 5含む)を中心に手を動かしている



あまり思想的なことを書くことはしないのだが、いろいろ思ったこと(分析周りの雑感)


実感した事は、プログラム畑の人が分析スキルを身に付けようとする場合、ツールの使い方を知る事は大して難しい事じゃない
難しい事は考え方

分析において、新しい価値を生み出すには、まず第一に「考え方」と思うことが多々あった
その次は結局、その新しい考えを実現しようとすると、それに合わせたデータを作る必要が出てきて「データ加工」が重要と言うか、ただひたすら手間と時間がかかる
そのデータ加工は半分くらいの頻度で微妙に間違っている箇所があったりして、何度かやり直すことになる
そもそもデータが無くて収集から始めなければいけないこともある
結果が出た後の検証(測定)も大事


「考え方」って漠然としているけど、具体例を一つ挙げると、
有名なtutorialのネタでTitanicの分析があるが、その模範解答の中に名前からFamilyを導き出すものがある
Titanic: Feature Engineering

模範解答のない身の回りの分析のデータに対して、そういった発想を思いつき、それを実際に加工・分析・検証できることが仕事で使えるスキルだと感じている


ここまでの話は条件付きというか前提がある
お金という成果で考えた時、前提として大きく
0を1にしたいのか
100を105にしたいのか
に分けて考えるのが良いと思っている

自分が言っている「考え方」というのは0を1にする方の話


ツールをいろいろ使ってみるとか、ツールの性能向上が役に立つシーンはもちろんあるが、それはすでに利益を上げていてデータがある企業に必要な事
ビッグデータとかディープラーニングとか流行りで良く聞くものがあるけど、そのほとんどは100を105にする方に適した手法だと思う

数だけで言えば、そもそも分析っぽいことをほとんどしていない企業が分析を活用してみたいという需要が結構あると思う(予算は小さい)
そういった比較的小さい企業の経営層が分析にお金を出すと決めた際に、
100を105にするための手法を売りつけられて、肌感覚では効果はあったような気がするみたいなことが多いんじゃないかと想像してる
(実際には測定が足りずに証明出来ないか、効果はプラスだが微妙なレベル)


個人的にいろいろやってみて思うことは、こうなったら改善するんじゃないかという仮説は5つくらい思いついたら、そのうち本当に効果があるのは1つくらいしかない
他はあったとしても微々たるもので、個人でやる分には良くない結果を捨てる判断はできるのだが、おそらく会社とかでやると、コストがかかっている建前もあって考えなしに導入することになる
こういった効果がわずかだが、メンテナンスコストを増やすものが技術的負債になるんだなと思う

リカバリ方法は無いわけではなく、効果の薄い機能・サービスを削除すれば良い

効果が無いって分かることも、無駄なことではなくて、すごい価値のあることだと思う

確定申告のまとめ - フリーランスエンジニアの確定申告

まとめ
各トピックへのリンクと一言

確定申告書の作成 - フリーランスエンジニアの確定申告

ここで書いている情報の注意事項についてはフリーランスエンジニアの場合をまず見てください

freeeやっぱすごいなと終わってから思ったのは、確定申告の書類作成の部分だと思った
質問に答えていくと書類が作成され、提出までにやるべきことなどの指示も画面に提示してくれる

公式の動画があるのでそれを見ると良いと思う
具体的なfreee上の画面は27分あたりから

まず取引の登録が終わっているいないに関わらず、確定申告書類の作成を実行してみると良い
実行して進めたら後から直せなくなるとかいうことはなかったし、むしろ、申告書出力、見直す、取引を修正するの繰り返しになる

質問に答えるだけでダメだったポイント

源泉徴収票を見て入力する質問があるけど、給与を前提としている質問で、自分の場合は前職の分があったのでそれを入力した
その後、進めていくと支払うべき税金が10万以上とかになっていた
が、これは結果的に間違った数字だった

問題としては、個人事業として収入を得ているが源泉徴収はある場合の源泉徴収額を入力する流れが欠けていた
つまり、前職の給与の源泉徴収事業収入での源泉徴収の2つが必要だった

解決方法は

  • 「直接編集」に行き、「所得の内訳」に新しく行を手入力で埋める
  • 所得の種類は「営業」
  • 重要となる源泉徴収税額は、取引先に支払調書を発行してもらってその金額を埋めるようにする

参考:所得の種類

正しく入力したら、最終的な税額は10万円以上還付されるという結果となった
一般的に、収入のほとんどが源泉徴収されている場合は、ほぼ間違いなく税金を払いすぎていると考えて良い
なので、計算された還付される税額がない場合は間違っているので見直した方が良い


今確定申告作成時の質問の部分を見直すと、複数の給与がある場合は「直接編集」で入力という注意書きはある
ただ、あくまで「給与」+源泉徴収票という前提で説明がなされているので、freeeの説明には改善の余地があるかと思う

参考:源泉徴収の入力

手作業に比べて何がすごいのか
  • 計算式とか自動でやってくれる
    • 自分で調べるだけだったら自信ない
  • 書類の種類がけっこういっぱいあり、手で埋めるとなると大変な気がした
    • 書類用意しなくていい
    • 数字を入力し間違える可能性が減る
  • 提出後の税務署から見た信頼度は正直高いと思う

細かいけど寄付の控除一つとっても、少し複雑な計算式があり、通常は2000円マイナスするところとか大した額じゃないけど実際間違えてたのでそういった細かいところに気付けた
手作業ならおそらく間違えて申告していたと思う

freeeはおまかせ
Railsと同じ


自分はもう提出したので、正直このブログのまとめが一気に面倒に思えてきた
ただ、大きく金額に影響するようなポイントはここまでですべてまとめたので良しとする

細かい部分でわからないところが出てきたら自分で調べてください