テスト書きたいって話すと品質を向上させようとしてると思われる話
結構テスト！テスト！言い続けて、テスト書いたりしています。
という話を周りにしたときに、何故か「テストを書いて品質を向上or担保したいんですね」っていう話にすり替わっていることがあるっていう愚痴。
怒ってるっていうわけではなく、テスト=品質ってすぐに結び付けないでほしいという要望。この話毎回言ってる。
そもそもテストを書くことで品質は向上しない
https://www.slideshare.net/t_wada/jasst-2014-hokkaidotwadatdd
自分のテスト(CI含む)に対する認識は
- ライブラリを変更するとかリファクタリングするとか、変更前と変更後で違いが無いことを簡単にチェックできる機構
- 複雑な条件を人間の手と目を使わずにチェックしてくれる機構
です。
で、それが確かに品質に繋がる部分が無いわけではないが、品質とか *どうでもいい* って思ってます。
あくまで、開発するときにストレス無しにガシガシ開発、変更をするためにテスト書いてます。
これだけだとじゃあそんなのユーザのためになってない開発だからやめようぜって言われるので、
表向きの理由として挙げるなら、
- テストを書くにはテストしやすさを念頭に置いて開発していく必要があり、テストしやすい開発環境の土壌が出来る。そうすればリリースする前に(テストしにくい土壌と比べて)網羅的にテストしやすくなる。網羅的にテストすることで事前に異常に気づくことが出来る。結果品質の向上が見込まれる。
- ストレス無くガンガンコードを書き換えられる状態が作れれば、開発生産性が向上して、たとえ品質が悪いものがリリースされたとしても即座に改善したバージョンをリリースできる状態になる。結果として品質の向上が見込まれる。
くらいの言い訳は挙げておきたい。
テストしやすい環境があれば、(今までは面倒で避けてたけど)AパターンBパターンCパターン…のチェックをするようになる。
テストが充実していれば、1行直せば解決するバグのために1万行見る必要もないし、
リリース前のQAに人間がAパターンBパターンCパターン…ってチェックする必要もないし、
リリース後に実はDパターンのチェック漏れて問題発生してましたっていうことも無いと思っている。
15分くらいCI回しておっけー、QAサクッと2分で終わらせまーす、リリースしまーす。
っていう状態が出来ると良いよねと思ってます。
観点が品質ではなく、あくまで開発生産性ですよっていうことを言っていきたい。
Androidでスクショ撮ってgithubにissueを上げるライブラリ作った
Furufuruです。
ブログ駆動開発。
https://github.com/iaia/Furufuru
## 概要
アプリでここの画面ちょっとデザイン変だな、
みたいなとき、スクショして、
Github開いてNew issueでスクショ貼って何か書いて…
って結構面倒ですよね。
しかも個人所有の端末ではなく、
会社用の検証用端末だとgithubにまずログインしないと…
みたいなことも往々にしてあるかなと。
アプリを振ると、スクショ取ってgithubに投稿までしてくれるプラグインを作りました。
もともとの経緯は知らないんだが、
同じようなことができるサービスがあったらしい、今もあるらしいが、
そのサービスがかなりの値上げをしていて、
じゃあ自分で作るわっていうのが最初らしい。
## 使い方
詳しくはREADME参照
```
class MyApplication : Application() {
override fun onCreate() {
super.onCreate()
Furufuru.builder(
application = this,
githubApiToken = BuildConfig.GITHUB_API_TOKEN,
githubReposOwner = “iaia",
githubRepository = “Furufuru"
).build()
}
}
```
アプリ起動させて、振るとスクショ取って画面が出てきます。
## 仕様
アプリが起動している間生き続けていて、
onActivityStartedするとsensor用のサービスが起動、
onActivityPausedするとサービス止めます。
### sensor service
「振る」を検知するためのサービスです。
ここコピペなのであんまり理解してないんだよな。
検知したら次の準備用の画面を起動させます。
### 準備用画面
ここ無くしてます。activityのlifecycle callbackがあることに気づいたので、activityからスクショ取れるようになった。
~透明な画面を作ってます。スクショとってる。~
~MediaProjectionを使ってるのでダイアログが出ます。~
~取れたらissue起票画面起動。~
### issue起票画面
スクショ貼る
タイトル必須です。
bodyも何か詳細書いてくれると嬉しいので置いてます。
~送信ボタンが下にあって隠れてるので右上に置きたい。~ 置いた
投稿したら終了して、またsensor用のサービス起動させる。
## 苦労
まずサービスがめんどくさい。
アプリが起動中、ずっと起動し続けたいのでその調整で四苦八苦。
起票したあと、スクショキャンセルしたとき、とかパターンごとにちゃんと再起動してるかどうかとか。
なんかクラッシュしてるとか。
スクショもめんどくさい〜。
activity単位でスクショ取れるのがあったんだけど、
~activity渡すのどうするよって感じで結局mediaprojectionを使った。~ 使ってない
activity lifecycle callback便利だなー
最初マルチモジュールで作ってたんだけど、
マルチモジュールを1個のライブラリとして送信する方法が全然分からなくて、
結局一個のモジュールとして作ったほうが良いっていう結論になった。
難しいね。
jcenterに公開するの結構あっさりだった。
数日かかるのかなって思ったらその日のうちに認証されて公開されました！
投稿までテストしたいので、何回か送ったりするので
issueがいっぱい作られてて大変。
リファクタリングしたいけど、めんどくさい〜。
テストも書いていきたい。
HHKB HYBRID Type-s を買いました
普段HHKB無刻印(type-sでもない)を使ってたんですが、
色々思うところがあって買いました。
何が不満だったか
1. 有線
有線めんどいなっていうのが一点。
例えば膝の上に乗せたいなっていうときに、
ケーブルの長さ的に持ってけないケースがままある。
HHKBを常にディスプレイに繋いでいるんだけど、
他のなにかデバイス繋ぐと給電がどうも足りなくなるケースがあるらしく、
例えばmagic trackpadを外すとかして調整しないといけなくなるのも面倒だった。
2. 切り替えが面倒
それと、今私物のMacが2015のモデルで、
usb type-cが無いんだよね。
会社PCから私物PCに切り替えるとHHKBをディスプレイの裏から抜いて…
みたいなことをしないといけないのが不便だった。
まぁ私物のmacはそろそろ買い替えてもいいのかもなー。
キーボードもマシになったし。
HYBRIDは無線でもfn+control+[1234]とかで切り替えできるので良い。
3. 音
これリモート環境下になってからなんですが、
Web会議中にキーボード叩くとすっげーカチャカチャ音するのが気になるようになった。
前までは自分しか音聞かないので、特に気にしていなかったんだけど、
さすがにこのカチャカチャ音を相手に聞かせるのはなーっていうのがあった。
音が静かだと前までと違って優しくタイピングするようになった気がする。
上記三点が主な理由。
2台使いはまだ出来ないな。パームレストがもう一個必要。
自作パームレストずっと使ってるけど、
これを気に新しく買っていいなと思って注文してる。
現状不満はないかな。電源ついてんだかわからんのは困るが。
分割キーボード出してくれたら即買いします。
プランニングポーカーのサービスつくった
(前略)
プランニングポーカーしてたけど、リモート環境でプランニングポーカーどうするよ？
っていうお悩みがあったので、パッとググった感じいくつかサービスはあった。
でもアカウント登録とかめんどくせーって思われてたので使われず、
Google Meetsなんかのチャットでせーのって言って投稿する感じになっていた。
まぁ厳密にやる必要はないからそれでも良いんだけど、
なんか自分で作れるイメージ湧いたから自分で作るか！って思って作った。
https://planning-poke.herokuapp.com/
ソースも公開してる。
https://github.com/iaia/planning-poke
「アカウント登録めんどくせー」があったので、Userモデル作りたくなかったんだけど、
誰がこのestimateつけたのよとか、今ルームに誰が居るの?
ってのが管理大変で、結局作っちゃった。
でも名前だけで良いので「めんどくせー」にはならないかな?と思ってる。
(多分ルームに入ったときにセッションでUser作っちゃう方式にすれば良いのかな)
ログイン機能とか普通のサービスで必要じゃねって機能までモリモリ削ってる。
最近はAndroidばっかなので久しぶりにruby書けてよかったという気持ち。
チャレンジなところはVue使ってるところくらい。
今どきjQueryなんか書けるかよ！な気持ちでVueにした。
あとはActionCableをチャット以外で使えてるってところくらいか。
まぁチャット的な使い方もできるけど。
herokuに上げたらActionCable動かなくて、redisのpub/sub使うらしい。
herokuにクレカ登録するのドキドキするよねっていうチャレンジはあった。
まだまだまずいところはあって、例えばルームが閉じられないとかね。
ルームに入る方法がroom_idとパスワードなので、
パスワードでアタックかければ過去の見れちゃうっていう。
まぁplannning-poke内でCONFIDENTIALな情報出さなければいいだけだったりするけど。
herokuじゃなくてインフラ周りの勉強がてらAWSあたりにでも上げたいとか、
色々やりたいこともあってissue立てたりもしてるけど
モチベーションがなかなか持続できなくて全然開発できてない。
あえてこの記事を書いて宣伝することで、
ヤバいから直すぞ！っていうモチベーションを上げる作戦です。
というところまで書いてすぐに色々直した。これがブログ駆動開発です。
PullRequestお待ちしております！
なぜブログを書くのか
ブログ移行出来たので、一発目(厳密には二発目だけど)の記事として、
ブログを書き続けてる理由について書いておきたい。
今もブログ開設したときもTwitterがメインの発信源なので、
Twitterでいいじゃんっていうのはそう。
わざわざブログにするケースっていうのは、
- ある話題に関してまとまったお話を投稿したいっていうとき
- 主な発信源のtwitterよりは公開しまくりたくないとき
- ネタがすでにあって長文なケース
一つ目はまぁよく言われるやつ。
二つ目はtwitterと比べてこっちを見てる人は少ないだろうと思っているので。
実際PV少ないし。RSSで見てる人もまぁいると思うけど。
三つ目は、ある事柄に関して考えたときに、
それについて悶々と考え続けていつまで経っても抜け出せないことが結構ある。
よくストレス解消のために悩みを文字に書くと良い、みたいなことがあってそれです。
ああでもないこうでもないっていう思考を文字化するの割と良いなと思ってる。
仕事中なんかのときにはAppleのメモでとりあえずざっくり書いといて終わったりしてる。
今後もブログを続けていきたいってのは上のような頭の整理もあるし、
会社のテックブログで長文を書くケースがあるので、その訓練というのもある。
それよりなにより、最近外界との接触頻度が激減していて、やばいという危機感がある。
これが孤独感っていうのかは分からないけど、
自分自身の存在が外と切り離されていて、このままだと存在しないのと同じだなという感覚。
ブログでも何でも外に自分を出して、
自分が社会の中に存在しているという感覚を持ちたいという気持ちになったので積極的に書いていきたいと思った。
twitterも最近投稿頻度落ちてるしね。
こういう心境の変化って面白いなって思う。
つまんねーブログだな！とか思われても全く問題ないと思っていて、kono先生が
「ブログは自分が面白いと思ったことを書くから、後から見返したときに自分にとっては面白い。
他の人から見たらつまらなくて当然」
みたいなことをどこかで書いていて、なるほどと思った記憶。
