アジャイルサムライを読みました

なんかなんとなくやったことあるから分かってる、ググって断片的には知ってる、 っていう感じで、体系的に学びたかったので読んだ。

めちゃくちゃ学びがあるっていう感じでもない。 っていうのもここに書いてあることのエッセンスのほとんどを前職で体験していた。

そして開発進行にストレスを感じていなかったので、 アジャイル開発としての良い例を体験出来ていたんだなという学び。

反対に現職でストレスを感じていて、 自分があまりアジャイルを勉強していないこともあって、 こういうふうにしたいっていうのをあまり強く押し出せなかったのが、 ここでしっかりと勉強できたことで、ちゃんと持ち込めるなっていう気がした。

以下メモ

  • 書き方ちょっとうざいな
  • 明確な役割分担はしない
  • 誰もがこの働き方を求めているわけではない
  • 4つの質問をチームに投げかける
    • 得意なこと
    • どういうふうに仕事するか
    • 大切に思う価値
    • チームは自分に何を期待しているか
  • エンジニア
  • テスター
    • 専任の人と直接会って喋ったことがないのでこういう人がいるならいいなぁという願望
  • PM
    • 障害を取り除く
    • 優れたPMは1週間いなくてもチームが回っている
  • スクラムマスター
  • 曖昧な状況に抵抗がない人がいい
  • 駄目なプロジェクト
    • 答えるべき問に答えられない
    • 手強い質問をする勇気がない
  • インセプションデッキ
  • 顧客がコミットメント出来ないならそのプロジェクトはやらないほうがいい
  • アーキテクチャはチームメンバーによって決まってしまう
    • なので自分の出来ること得意なことを表明する
  • ニーバーの祈り
  • 四天王
    • 時間
    • 品質
    • 予算
    • スコープ
      • スコープは変えやすい
  • INVEST
  • 必要なときに必要な分だけ
  • イテレーションnで分析イテレーションn+1で実装
  • カンバン
    • WIPに上限
  • ストーリー計画ミーティング
    • 着手する準備は万全であるか確認する
  • おかわり
  • 人を動かす〜
  • デイリースタンドアップ
    • 会議体として正式に開催はしない
    • 毎日自主的に5~10分立ったままやる
    • 共有するのは3点
      • 昨日やったこと
      • 今日やったこと
      • 何か進捗を妨げる問題
    • ちょうど朝会に対する改善案を書いていたけど、いい感じに学べた
  • 成果がなくても披露する
    • 目を背けてはいけない
  • 毎回のイテレーションで10%はバグ潰しや改善に使うと良い
  • ユニットテスト〜
  • バグを修正する前に失敗するテストを書く
    • もうこれ親の顔より見た
  • 危なっかしいところをテストする
  • テストは自信を持つために書く
  • リファクタリング〜
    • 変数名・メソッド名から始める

実践JUnit 読んだ

夏季休暇取って連休なので、積本消化します。なぜか4冊追加したけど。

これね https://www.oreilly.co.jp/books/9784873117300/

書いてあること大体は首肯できる内容だった。 JUnit に関する内容だけど、テスト全般に言えることも多いのでjava以外にも応用できるはず。 コード自体はほっとんど読んでなくてザーッと見る程度。

以下メモ。書いてあることだけでなく、読者のお気持ちも含まれる。

  • めちゃくちゃ初心者向けという雰囲気
  • hamcrest は matchers のアナグラム
  • javaのサンプルコードよみたくねー
  • sut
    • system under test
  • クラスの振る舞いをテストする
    • なのでprivateをテストするのは良くない
      • privateも一応実行は出来なくはない
      • けどそれってテストとSUTが密結合になってしまう
      • ちょっと変更するたびにテストが落ちる => テストを修正する => めんどくせーからテスト書くの辞めるわになりがち
    • privateの中に興味深い処理がある
      • 単一責任になってないのでは
    • => クラスを分けるのが適切?
  • given-when-then
  • 全部のテストを実行すべき
    • は言い過ぎでなるべく多くのテストを実行する
    • DB操作など低速なのでパッケージを分けるなり、カテゴリ (@Category) 追加して遅いテストを分離しておく
  • 低速なコンポーネントへの依存を辞める
    • よく分からんやり方で実現してるけど、mock, stubで対処できそう
  • 時間を止めたいときは Clock を使う
  • test infected
  • infinitest?
    • ASだと動かないっぽい?
  • timely
    • 後からテスト追加しようはたいていしない
    • いま書こう
    • 実績がある古いコードはあまりテストを書く意味がない
      • 仕様書という意味でテストを書くのはありだと思ってる
  • 0-1-n
    • 0個か1個かn個かでテストを行えばいいケースがほとんど
  • リファクタリングにもテストは有効
    • リファクタリングしすぎてパフォーマンスが心配?
    • 「それがどうした」
    • まずはコードをクリーンにするのが最優先
    • クリーンならパフォーマンスを向上させるコードにするのも容易
  • ここらへんからかなりリファクタリングの話に寄ってくる
  • visitor パターン
  • モックがホントに使われているか確かめる
    • 実運用のコードをちょっと書き換えてみる
    • ありえない値をstubしてみる
      • 例えば緯度経度を0とかにしてみる
  • nullチェックはやらんでええ
    • javaだからかな
    • kotlinでもnullチェックしないで!!でunwrapするでも良いかも
  • 一つのテストに一つのアサーションが原則
    • 名前もわかりやすくなる
  • 他の関数を探し回らなくても理解できるのが良いテスト
  • ここでもAAAは出てた
    • arrange-act-assert-(after)
    • AAAごとに空行あける
    • Arrangeは@Beforeで分割出来るよね
  • テストのために設計を変えるのは嫌
    • テストで扱いやすい設計は実運用コードでも扱いやすい設計になっているはず
  • テストを書くときはまず失敗させろ
    • TDDでもよく言われているやつ
    • 成功するテストは何書いても成功する
    • 失敗するテストは成功させるために理解して書き直さなければいけない
  • マルチスレッドはテスト大変
    • アプリのロジックとマルチスレッドのロジックを分離する
  • 統合テストは大変
    • 例えばDB周り
    • ユニットテストで検証できるロジックを増やす
    • 統合テストは減らす
  • カバレッジ
    • 70%がライン
    • ただ数字だけを上げたいなら実は楽勝
      • assertしないで実行だけするとか
      • でもそれには意味がない

コンビニを使うのは難しい

自分 品を置く
自分「25番二つ」←あ、をつけないで喋れる数少ないセリフ
店員 振り向いて25番を一つ取り出す
店員「こちらでよろしいですか」
自分「あ、二つね二つ」
店員 バーコード読み取り
自分 年齢確認ボタンを押す (おそらくこの間にもう一個取り出しているはず
店員 他の品をバーコード読み取り
自分「suicaで」←あ、をつけないでｒｙ
店員「袋はあｓｄｆ」
自分「あ、袋お願いします」
店員 袋代つける
店員「タッチお願いします」
自分 suicaタッチする
自分 袋詰を眺めながらタバコが一つしか無いのに気付き
(そういえば1000円だったから通じてなかったのか...) とか考えるが何も言えない
店員 「ｱﾘｶﾞﾄｳｺﾞｻﾞｲﾏｼﾀ-」

家に帰って冷蔵庫に入れてるときにタバコが二つあることに気付く...。

コンビニ、客にも店員にもオペレーションを要求しすぎていて、
お互いのミスに気付きづらい。
多分店員は初手「袋はあｓｄｆ」をかましたかったのを
こっちがタバコで先手を打って、さらに二つ要求したことと、
「suicaで」が早すぎたことで潰してしまったんだろうな。

そしてこっちは「袋は」と言われたことで、
(ああそうか言わないといけないんだっけか) とか考えて反省しているので
会計の値段がおかしいことに気づかない。
さらにsuicaタッチしている間に袋詰されているので、
一個目のタバコが先に袋詰されていることにも気づけず...っていう。

同じことが別のコンビニでもあったので、もうコンビニ難しくて行きづらい。

花を愛でる心

f:id:iaiabot:20200803204403j:plain

ベンジャミン

 

あったらしい。

ベンジャミンっていうらしいです。
調べるとゴムの木の仲間らしくて、母がゴムの木を育ててたのを思い出す。
確かに葉のツヤ感が似てる。

水やりは、母に言われて水やりをしたこともあったりして、
ホントにたまーにしか水をあげてないので「毎日水あげなくていいの」と質問したことが。

- たまーにでいい
- あげすぎると根腐れするから駄目
- あげるときは鉢から水が溢れてくるくらいあげる

ってのを実践してます。
2ヶ月くらい経ったけど元気そうだし大丈夫そう。

実家に住んでるときは観葉植物に全然意識がいってなかったので、
ここに置いてもあんまり気にせんのじゃないかなと思ってた。

が、自分で買って育ててみると違うもんらしい。
割と毎日鉢ごと持ち上げて、葉っぱの様子を観察しています。
買ったときより葉っぱの数増えてるんじゃないかなぁとか。

これが花を愛でる心ですよ。

パームレスト買った

 

f:id:iaiabot:20200721212435j:plain

パームレスト買った。いや、パームレストという商品名ではないので不適切かも。

PFUで売ってるのはこれなんだけど、 https://www.pfu.fujitsu.com/direct/hhkb/hhkb-option/detail_palmrest_wal-4.html

デカすぎじゃねっていう。 D80mmはでかいなーと思っていて、D60のものを自作したんだよね。

が最近やっぱり分割したいよねって思っていて、 自作したやつを切って分割するのも大変なので、マルトクショップでいくつか作ってもらうことにした。 っていうものが1ヶ月待ちでようやく届いたので書く。

シナ(バスウッド)　無垢板フリーカット   四角形   015*0060*0150mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：690 円    数量：1    金額：690 円
マホガニー　無垢板フリーカット   四角形   015*0060*0150mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：690 円    数量：1    金額：690 円
ユーカリ　無垢板フリーカット    四角形   015*0060*0300mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：1,190 円  数量：1    金額：1,190 円
【国産材】桧(無節)　無垢板フリーカット      四角形   015*0175*0160mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：1,340 円  数量：1    金額：1,340 円
ウォールナット　無垢板フリーカット     四角形   015*0060*0160mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：860 円    数量：1    金額：860 円
【国産材】ナラ(節・白太あり)　無垢板フリーカット     四角形   015*0115*0160mm | ◆面[A]:糸面 ＋ 磨き ◆面[B]:糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:糸面 ＋ 磨き ◆反り止め:無し  ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：800 円    数量：1    金額：800 円
【国産材】屋久島地杉　無垢板フリーカット      四角形   018*0060*0150mm | ◆面[A]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[B]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆面[C]:糸面 ＋ 磨き ◆面[D]:上Ｒ面（5R）＋ 下糸面 ＋ 磨き ◆反り止め:無し ◆塗装:ウレタンクリアー 裏捨て塗り（ツヤ全消し） | 用途:三方向使用
単価：690 円    数量：1    金額：690 円

謹製のもの4千超えるので、2個だけなら送料いれてもこっちのほうが安いと思う。 素材の違いで使用感違うかなーとか、サイズちょっと高さ上げるとどうだろう、とか 色々試してみたかったのでバリエーション豊かになってしまって最終的にちょっとお高めになってる。

素材の違いは、重量違いで結構違うなーという感想。 一番黒っぽいやつ(多分ウォールナット)が一番重くて、こいつが安定感がとても良い。 W175mmとかの横長のだと気づかないんだけど、W60mmくらいちっこいと手汗なんかでベタついてると軽くて簡単に動いちゃう。それが無いので良い。これでパームレスト注文し直しても良いかも。色の雰囲気は屋久島地杉(右手trackpadのパームレスト)が気に入ってる。

ゴム足は適当にamazonで見かけたものを貼り付けてる。無いと高さが微妙に足りないしススススっと動くの音も含めてストレス。

ついでにmagic trackpadの台も注文した。

 

f:id:iaiabot:20200721215240j:plain



HHKBと同じくらいまでの高さにして小指で操作したいよねっていう願望があって、そうするとある程度の高さのパームレストも欲しいよねというのでついで買い。 台とパームレスト別になってるのが良いのか一体型が良いかも試したかった。

一体型は一体型で良いんだけど、キーボードのパームレストと干渉してしまうのがちょっと微妙。 手首置くところはやっぱりちょっと高さあったほうが良いのでメインじゃない左手側のmagic trackpadに使ってる。
段々になっている一体型も考えたんだけど、CAD作らないと注文できないっぽいので断念。

自作したのは捨てちゃった。まぁ微妙だったし。もう一回チャレンジしたい気持ちはある。

テスト書きたいって話すと品質を向上させようとしてると思われる話

結構テスト！テスト！言い続けて、テスト書いたりしています。

という話を周りにしたときに、何故か「テストを書いて品質を向上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()
  }
}
```

アプリ起動させて、振るとスクショ取って画面が出てきます。

furufuru

furufuru

## 仕様

アプリが起動している間生き続けていて、
onActivityStartedするとsensor用のサービスが起動、
onActivityPausedするとサービス止めます。

### sensor service

「振る」を検知するためのサービスです。
ここコピペなのであんまり理解してないんだよな。

検知したら次の準備用の画面を起動させます。

### 準備用画面

ここ無くしてます。activityのlifecycle callbackがあることに気づいたので、activityからスクショ取れるようになった。
~透明な画面を作ってます。スクショとってる。~
~MediaProjectionを使ってるのでダイアログが出ます。~
~取れたらissue起票画面起動。~

### issue起票画面

スクショ貼る

タイトル必須です。
bodyも何か詳細書いてくれると嬉しいので置いてます。
~送信ボタンが下にあって隠れてるので右上に置きたい。~ 置いた
投稿したら終了して、またsensor用のサービス起動させる。

## 苦労

まずサービスがめんどくさい。
アプリが起動中、ずっと起動し続けたいのでその調整で四苦八苦。
起票したあと、スクショキャンセルしたとき、とかパターンごとにちゃんと再起動してるかどうかとか。
なんかクラッシュしてるとか。

スクショもめんどくさい〜。
activity単位でスクショ取れるのがあったんだけど、
~activity渡すのどうするよって感じで結局mediaprojectionを使った。~ 使ってない
activity lifecycle callback便利だなー

最初マルチモジュールで作ってたんだけど、
マルチモジュールを1個のライブラリとして送信する方法が全然分からなくて、
結局一個のモジュールとして作ったほうが良いっていう結論になった。
難しいね。

jcenterに公開するの結構あっさりだった。
数日かかるのかなって思ったらその日のうちに認証されて公開されました！

投稿までテストしたいので、何回か送ったりするので
issueがいっぱい作られてて大変。

リファクタリングしたいけど、めんどくさい〜。
テストも書いていきたい。