パルカワ2

最近はFlutterをやっています

Audible契約した

Audibleは前に一回契約したことあったんだけど、本読んだほうが気になったところをハイライトしやすいし読み返しやすいので本を読む方がいいなと思ってその時は解約した。

それから数年歳を取り、疲労も相まって目がしょぼしょぼ状態になってしまい本を読むのもつらいという状態だったので、目を一切使わず(目を閉じていたり遠くを眺めている状態)本を読みたいと思ったのでAudibleを契約した。

契約したものの興味のある本があまりなさそうと思ったんだけど、ファスト&スローがあったので上巻を聴いた。聴き終わるには上巻だけで通常13 時間半くらいだけど2倍速で聴いたら半分で読み終わると思ったら本を読むよりかなり早いかもしれない。さすがに最初から2倍速は早すぎたので、1.5倍速1.7倍速と徐々に慣らして聴いた。なので8,9時間くらいで聴き終わった感じ。最初から最後までずっと集中して聴いていたかというとそうでもないんだけど、一回読んだ本だからまあそれでもいいかくらいの感じだった。

ダニエル・カーネマンのNOISE上下も6月と7月に更新予定らしいのでKindle買ったけどAudible待とうかな。

クソ長い本を読んだ(聴いた)のに当たり前だけど目が全然疲れなくて夜になっても元気だったので、具体と抽象も聴いた。これは読んだことなかったんだけど、短いし簡単な内容だったので2倍速で寝る前にサクッと聴けた。

ツイートでは読んだと言っているんだけど聴いてた。読んだと言っていいのか悩ましい。

Audibleを聴きながら、目薬をさしたりベランダから遠くのマンションの避雷針やスカイツリーを見つめていたりしていたからか目はかなりマシになった。散歩中とか運動中に良さそう。あとプロのナレーターなので、なんて?がない。倍速でも聞きやすい。

一方で「この図を見てほしい」みたいなことを言われるとすぐ見れないので困る。図を見なくてもわかるようになっている気はしていて、ファスト&スローについては一切見ずに聴いてた。

MacbookProのためにUSB扇風機を買った

最近Google meetで画面共有をしているとNoitonやVSCodeへの文字入力がまともに出来なくなっていた。文字を入力すると10秒くらいあとに反映されるのでめちゃくちゃタイポするし、意味不明な文章になり困り果てていた。

その状況を再現させてアクティビティモニタを眺めているとkernel_taskが1000%とかになってた。

kernel_task は、その機能の 1 つとして、CPU を集中的に使うプロセスの CPU 使用率を下げるというやり方で、温度管理を助けています。つまり、kernel_task は、Mac 本体の温度が高く感じられない場合でも、CPU の温度が上がり過ぎる原因となる状況に対処するプロセスです。それ自体がその状況を引き起こしているわけではありません。CPU の温度が下がれば、kernel_task の活動は自動的に治まります。 kernel_task の Mac CPU の使用率が高い場合 - Apple サポート (日本)

CPUの温度を確認してみたけど65度くらいで盛り上がってるとは思えなかったけど「Mac 本体の温度が高く感じられない場合でも、CPU の温度が上がり過ぎる原因となる状況に対処するプロセス」と言っているので、とりあえず風当てて冷やせばいいんじゃね???と思ったのでUSB扇風機を買った。

正直あんまり効果ないだろうなと思っていたんだけど、意外と効果はあって画面共有しながら日本語が打てる状態になったので感動した。風をぶち当ててからkernel_taskは鳴りを潜めている。音は扇風機がない時よりはうるさいかもしれないけど、大体ノイズキャンセリングのヘッドホンをしているので気にならない。

JIRA結構気に入った

使っているのはNew Jira issue viewなので前のは知らないし、設定など先に使っていた人がやってくれたのでデフォルトのJIRAとGithubとの比較とかでは特にない。

感想

  • 課題自体に期日などのプロパティがあるのがよい
    • Slackや口頭で「ではこれは何日までで」みたいなやり取りがあるけど、それを書く場所がちゃんと決まっているのはよい
    • まぁちゃんと書けばの話なんだけど…
  • エピック・ストーリー・サブタスクがあるのがよい
    • 機能や課題はまずフワフワした状態から始まる
    • それをまずエピックに書き出して、それを分解したものをストーリー、さらにストーリーを分解したものをサブタスクとするのはわかりやすい
    • またサブタスクのサブタスクみたいな地獄が作れなくなっているのもポイントが高い
  • ロードマップはストーリーの期日が表示されない
    • ストーリーに期日という概念を持ち込むべきではないのかもなと思いつつ期日での管理なので困っている
    • アジャイルな計画づくりであれば、ストーリーはスプリントレビューの日以外の期日を持つことは基本なく、スプリントで管理するはずなので気にしなくてもいいはずという認識
  • 自分がアサインされているタスク課題一覧が見にくい
    • 現状、期日でのタスク管理をしているので、自分がアサインされている課題一覧を把握し期日が近いものからこなしていきたい
    • ロードマップは、エピックとストーリーを階層表示してくれるのでまだ見やすいがサブタスクが見れないので結局ストーリーの中をちまちま見ることになる
    • アジャイルな計画づくりをしていれば、スプリント中にやるべきことはバックログにまとまるのでそれに集中すればよいという認識

まとめ

みんなが「JIRAは…ねえ…」みたいな反応をしていたので、使うまで一体どんなもんなんや…とドキドキしていたけど結構気に入っている。 一方でアジャイルな計画づくりをしていないと使いにくい部分があるなとおもったが、それは使い方が間違えているような気もする。

開発×テスト LT会 - vol.2でソフトウェアエンジニアが品質保証を学んでわかったことを発表した

speakerdeck.com

約1年ぶりの勉強会の登壇だったので緊張した。毎回緊張したって言ってる。主催者の人たちが話している時に頷いてくれていたのが見れたので話しやすかったです。ありがとうございました!

発表した内容は、ここ最近学んでいることなので大体このブログに書いてることをまとめたみたいな感じになった。品質保証というのをどう伝えるのかを結構直前まで悩んでいたんだけど発表は多分好評だったので良かったです。

そういえば他の登壇者の人たちが会社採用スライドみたいなのを出してなかったので、僕も出さなかったんだけど絶賛採用中なので品質の作り込みなどに興味があるQAエンジニア、ソフトウェアエンジニア、SETはぜひご連絡ください

jobs.10x.co.jp

他にも色々喋れることはあるので、発表していきたいという気持ちだけはある。

新居の鳩襲来問題 2

hisaichi5518.hatenablog.jp

前回は、ベランダの一部にテグスを貼って忌避剤で鳩を撃退するという形を取った。最初は効果はあったのだけど、一ヶ月経った今もまだ鳩は来ている。テグスを張っていないところには忌避剤を振りまいているのだけどそこにも止まったりするようになってきている。なのでベランダ全体にテグスを張ることにした。

前回は、ミツギロン 鳥よけ テグスセット ベランダ 手すり 侵入阻止 10m 簡単設置 取り外し簡単 鳥獣被害対策 ハットラップ EG-51 1セットを買ったのだけど以下のような部分が不満だった。

  • 見た目が悪い。支柱部分が黒いので目立つ
  • テグスが張りにくい
  • テンション調整がしにくい
  • スリーブの力が弱い。風が強いと外れてることがあったのでマスキングテープで止めていた。見た目が悪い

テグスの効果がわからなくてとりあえず1000円くらいのやつを選んだのでまあ値段相応ですねという感じ。

これらをどうにかしたかったので色々探していたらハトワイヤーというものを見つけた。今回はハトワイヤーで揃えた。

ベランダなどの鳩よけ・着地防止に ハトワイヤー | 鳩よけ・鳥害対策なら株式会社コーユー

  • ハトワイヤー 標準ベース支柱 * 3
  • ワンタッチスプリング * 4
  • ステンレスバンド160 * 3
  • ステンレスワイヤー(φ0.72) 20m巻 * 1

支柱を何本買えばいいのかみたいな割り付けはここで見れる。

ハトワイヤーの施工方法 | 鳩よけ・鳥害対策なら株式会社コーユー

嬉しいところは以下。前回の不満を取り除ける。

  • ワンタッチスプリングを使えばカシメ作業が不要でテグスを素早く綺麗に張れる。テンション調整も出来る最高
  • ステンレスワイヤー、支柱があんまり目立たない

朝起きて朝日を浴びるついでにベランダに出ている。前はテグスを見て汚え〜と思ってたのだけど今は綺麗じゃんとなるので体験が良い。

デメリットとしては、以下のようなことがあった。

  • 金切鋏みたいな強いニッパーがないとステンレスバンドを切るときに苦労する。僕はプラモ用のニッパーでやったので苦労した
    • 強いニッパー・ハンマー・レンチが家にない場合、気合が必要。買ったほうがいい
  • ステンレスバンドをよくわからないまま適当に触った結果元に戻せなくなってしまった+長さも足りていないことに気づいたので3本買い直した。動画で向きなどを見てから触ったほうがいい+長さは余裕を持って長めのものを買うと良い
  • 値段が高い

www.youtube.com

鳩を撃退出来ているか動画を撮っているのだけどちゃんと鳩も撃退出来ている。良かった。

仕様書は必要か?

ここでいう仕様書とは、仕様(=システムにおける検証可能な振る舞い)が記載されたドキュメントである。

社会人として10年くらいソフトウェアエンジニアをやってきて、今まで関わってきたサービスでいわゆる仕様書を書いたことがない気がする。プロダクトマネージャーやデザイナーたちと顧客からの要求を元に「こういう感じで作りましょう」という話をして実際に作っていくし、そこで話した内容とかは議事録とかに残ってるかもしれないが「はい、これが仕様書です」って渡されたこともない気がする。

仕様書は書いてこなかったが自動テストは書いてきた。ソフトウェアのテストを書けば”システムにおける検証可能な振る舞い”がテストに記載されるわけだし、仕様とはシステムにおける検証可能な振る舞いであるはずで自動テストがあれば仕様を記載する仕様書なるものは不要であると思っていた。

自動テストを仕様書とするのでは不十分?

先に書いた通り、仕様が書かれるのは自動テストで十分であると思っていたのだが品質やソフトウェアテストなどについて学んでいると品質の作り込みのために以下のようなことを満たしたいと思えてきた。

  • 早い段階での仕様の定義とレビューが出来ること
  • すでに実装された仕様がいつでも誰でも把握できること

これらを満たすには、エンジニア以外を含む開発に関わるメンバーが仕様を定義出来て、理解もできる形で記載されている必要があると思った。

つまり、自動テストのようにプログラムで仕様が書かれているとプログラムを書ける人しか書けないしプログラムを理解出来る人にしか理解出来ない*1。実装を理解していないとどこに仕様が記載されているかも把握出来ない。これだと早い段階での定義やレビューもいつでも誰でも仕様を把握することも満たすことは出来ない。

なので、仕様書と自動テストは分離されているべきではないかと考えた。

どのような仕様書がよいのか?

いま必要な仕様書は、開発に関わるメンバーが仕様を定義出来て理解も出来る仕様書である。

これらを満たすのは、ある程度ルールが定まった自然言語で記載された仕様書だと思った。例えば、仕様書を日本語で書くとすると日本語が理解して書ける人間は当然理解出来るし当然書ける。

逆にデメリットは自然言語は自由なので曖昧になりがちだと思う。それを防ぐためにルールを作ると良さそうだと思っているが自分はある程度こうすればいいなというのは見えているもののまだ模索中である。

仕様書と自動テストを分けた場合の課題とは?

仕様書と自動テストを分離すると更新する場所が増えるのが問題になる。仕様書を更新しただけでは自動テストは更新されないし、自動テストを更新しただけでは仕様書は更新されない。

それを防ぐのに仕様書に記載された情報を使って自動テストを実行する仕組みであるGuageやCucumberを使うとよいと思う。個人的には、Markdown-likeなsyntaxで記載出来るGuageがいい。まぁDartのRunnerがないので僕らは自前で頑張る必要があるんですが………。

gauge.org

追記:DartのGherkinパッケージには、Runnerもあるみたいなのでそれを利用するとよさそう。

まとめ

品質を作り込むには仕様書は必要だと思う。しかし仕様書と自動テストを分けると更新する場所が2箇所になってだるい問題が出てくる。なのでGuageなどを使うとよいと思う。

*1:実行すれば理解出来る形にアウトプットされるかもしれないが、実行しないといけない

ソフトウェア要求と仕様: 実践,原理,偏見の辞典 を読んだ

そうだねって内容でありつつも例え話が多くて自分にはあまりシックリ来なかった。