実用的なテストに関する話をしました “Practical Testing Tips”
時間があって気が向いたら、ところどころ日本語でブログ記事にするかもしれないししないかもしれません
基本的に自分はテスト好きな人間なので、自分が気になってきた問題はほとんど解決できていてテストに関する悩みはあまりない
近年の一番の悩みはスライドの一番最後のページのトピックにも挙げているYAGNI的なもの
すごい締め切りで急かされたり、苦労して期限守って作ったり直したりしても、実際それが全くもしくは期待ほど使われていないと、時間を詰めてストレスを感じてやってきたことがなんだったって感じになる
去年のやつ
Rubyでスクレイピングする話をしました “Web Scraping with Capybara” - quattro_4's diary
確定申告で忘れがちなもの
確定申告で忘れがちなものがあって、ちょうど今年も締め切り一週間前で気づいた
去年も忘れてて、次回のためのメモまでしてあったのに
少し前の時点でしっかり準備すべきものがある
提出書類
取引の登録とかはギリギリまで調整可能だけど、提出書類は手元になくて発行を待つことになると少し時間がかかる
主なもの(自分が必要だったもの)を挙げると
- 社会保険(健康保険)に入っている場合はその納入証明書(任意継続とか)
- これが去年に続き直前に無いことに気づいた。電話で伝えたところすぐに手配を開始してくれた
- 国民健康保険の場合は特に必要ないらしい情報を見た
- 支払調書
- 源泉徴収をする会社から支払がある時。ちゃんとした会社なら送ってくれるはず(一般には前年12月分の支払後、2月頭ころか)
- ふるさと納税 寄付金受領証明書
- 送られてくるので通常問題ないが、紛失とかすると面倒かも?
- 国民年金 控除証明書
- 送られてくるはず、無くさないようにする
- 医療費関連
- 控除対象額(10万など)に達していなければあまり気にする必要はないかも
freeeを使って数年になるが、初期よりは慣れたと思う
近年良くなった点
同期はできなくなった口座があったり、全体的にあまり改善していないか悪くなっている部分があるような気がする
欲しい機能
- 月次登録をしやすくする機能
- 必ず月1回登録するものを、テンプレートをもとに"自動で経理"みたいな感じで登録待ちにしてくれる(日付、金額、備考などを都度調整するだけで、瞬時に登録できる)
- 必ず月1回登録するものが、各月登録済みか簡単に把握できるようにする
- 集計額(レポート)を数年(3~5年以上)比較できるような集計画面・エクスポートが欲しい
- 項目ごとの額を別の年と比較してその違いによって、登録忘れ・登録間違いなどに気づける
- 年ごとの自身の推移を振り返れる
- 他のサービスも試そうか頭をよぎったことあるけど、これがあったらサービスを使い続ける動機になると思う
- フリーズした過去の年の取引にタグだけは付け替えできて検索に使える
以前のやつ
レガシーコード改善ガイド 感想
- 作者: マイケル・C・フェザーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/15
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
メモ
- レガシーコードとは、単にテストのないコードです
- eXtreme Programming:エクストリームプログラミング
- Uncle Bob Books - Clean Coder
- テストの最大の障害となるのが依存関係
- 一貫して小さな改善を続ければ、数ヶ月の間にシステムは見違えるような状態になる
- スプラウトメソッドとラップメソッド
- Null を渡す (nilを渡すのは便利な手法)
- 一度にあまりにたくさんの変更をしようとしているのかも
- 「そのメソッドを壊したら、この場所で変更を検出できるか?」と、問いかけてみることです
- 仕様化テスト(characterization test)
- コードの実際の振る舞いを明らかにするテスト
- 試行リファクタリング(scratch refactoring)
- あらゆる方法を用いてリファクタリング
- そのコードは再びチェックインせずに破棄
- 「どうしてもprivateメソッドをテストしたいのなら、そのメソッドはprivateにすべきではない」ということ
感想
- 長かった
- 以前少し読み始めていたが序盤で断念してた
- Javaのコードだったのもあって、コードがある部分は結構飛ばし読み
- 本が10冊以上くらい紹介されていた
- この辺りは個人的に結構身につけられていると思うので、斬新な発見はあまりなかった
- スプラウトメソッドとかよくわからないところもあった
- テストを壊したり、リファクタリングしたり参考になる手法がいくつかあった
レガシーコードはだんだんそうなるんじゃなくて、書く人や状況によっては最初からレガシーコードなんじゃないかって思った。
ただ、それらを後からレガシーコードじゃなくすることは可能だとわかったし、個人的にテストを重視することを続けてきて良かったと思えた。
自分のコードでさえ、それが1ヵ月以上後の自分にとってわかりにくいコードならそれもレガシーコード。
最近コードを見る時、頭を空っぽにする(前提知識のない人を想像する)ことや、視界を狭めたり(エディタで見える範囲で変数名などの妥当性を考える)広げたりするのをよく意識している。
レガシーソフトウェアについてはレガシーだったり、そうじゃないコードの集大成なので、だんだんレガシーになるもので合ってると思う。
せめて自分の触る部分は、レガシーを生み出さない、レガシーを治すようにしたい。
最近テストが落ちるような変更をしてコードを改善していく手法を、自分で発明したかのように思っていたのだけど、
(→ テストをわざと壊して効率的に開発する - quattro_4's diary )
色々試して場合によっては破棄するという点で「試行リファクタリング」とほぼ同じなんじゃないかと気づいた。
昔からあったものだった。
それと、過去の自分まあまあ良いこと書いてあった
新装版 リファクタリング―既存のコードを安全に改善する 感想 - quattro_4's diary
個人的に最近新しく聴いてる音楽
以前も聴いてる音楽を振り返ったことあったけどまたやってみる
特にYATSUI FESきっかけでいくつか聴くようになったのもある
SATANIC CARNIVALまた抽選落ちたし、PUNK SPRING FINALだったし、パンク離れするのかもしれない
YATSUI FESで見たけど良かった
MCとかネタとか全体通してコントみたいな雰囲気で完成度高いし楽しい
ネタ系の楽曲ばかりが目立っているけど、アルバムの後半にある真面目な曲もかなり良い
打ち込みすごい
sumika - ソーダ
今年発見して一番のお気に入りはこれかな
テンポにしてもメロディーにしても自分好み
最近量産されている速い4つ打ちバンドとは一味違う感じもして良い
一曲の長さでsumikaが分かる動画 - YouTube
never young beach - 明るい未来
21世紀のバンドでこんなトロピカルなの聴いたことない
兄は高橋一生
yahyel - Once
YATSUI FESで教えてもらって見た
使っている機材とかの関係か、クラブ系に分類されたりもするらしく、コメント欄とかでアンチに変に批評されてて不思議
実際ライブで聴いた感じは、むしろ爆音(ラウド)系に思えたのと、曲と連動する映像にこだわっている部分もよくわかった
個人的にはFACTに通じるものを感じた(作品では素顔を見せない。海外志向っぽいこだわり)
たまにラウド系を含みつつ、映像面含めてSigur Rós的な神秘的な路線を目指せば面白いんじゃないかとは思っている
スペル、名前(ヤイエル)が覚えられない
ラブリーサマーちゃん - 青い瞬きの途中で
YATSUI FESに誘ってきた友達にすすめられなければ見つけることすらなさそう
すごい洋楽も聴いてて詳しい感じ
打ち込みもいろんな楽器もできて、自分で作るし演奏もする
SoundCloud
全体まとめると、作ることにこだわるいかにもクリエイターみたいなアーティストばかりで、岡崎体育とかラブサマとかここに挙げていないがtofubeatsとか、一人で宅録してたりするしすごくて応援したくなる
自分の仕事的な部分と重ねて良く思えるのかもしれない
あなたのセキュリティ対応間違っています 感想
- 作者: 辻伸弘
- 出版社/メーカー: 日経BP社
- 発売日: 2016/10/25
- メディア: Kindle版
- この商品を含むブログを見る
以前やってたが、久しぶりに読んだ本のログ取ることにしてみた
けっこうすぐ読める感じだし、どんな立場の人でも軽く一読するのは良いと思う
メモ
- 守れないルールによる運用は、大変危険な脆弱性
- 必ず1次情報の内容を自らの目で確認
- アノニマス派閥
- 手帳にパスワードをメモ
- 万が一紛失したときのことを考慮して、書き方を一工夫
- パスワードの一部を省略してメモしておき、落として誰かに知られても、ログインできないようにしておきます
- piyolog
- (n) – life is penetration. geeks cheer. geeks be ambitious.
ITリテラシーが低い人など相手によって、手帳にパスワードをメモを取ることを勧めているあたり、著者は現実的で実現可能な考えを提示してくれるし情報が信頼できそう
セキュリティなんかは特に堅い立場の人や組織ほど、間違いでもないが実用的でない対策を提示するものだと思う
4+ hours
Speed 3/5
★★★★☆
MAN WITH A MISSION - database feat.TAKUMA(10-FEET)
自分専用のCIを使ってRailsの開発効率を上げる
テストをわざと壊して効率的に開発する - quattro_4's diary
の記事に書いた内容に関連して、最近自分専用のCI的なものを欲しいと思っていた
幾つかの手軽な方法として思い浮かんだのは
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の結果を見れば、その場その場で次どうしたら良いかはわかるのだけど、そのルール・パターンを明示的にまとめることはできていない
今後余裕があれば、具体的なコードと一緒にパターンを追求していきたい