パルカワ2

最近はFlutterをやっています

インナーチャイルド 本当のあなたを取り戻す方法〔改訂版〕 を読んだ

インナーチャイルドという言葉を初めて知ったので読んだ。

子供(乳児期、歩行期、学童前期、学童期)の頃の経験からどんな大人にもインナーチャイルドはいて、なんらかの理由によってインナーチャイルドが傷ついていれば色々と人生に問題が起きてしまうみたいな話から始まり、オリジナルペイン・エクササイズといったエクササイズによってインナーチャイルドを救い出そうみたいな話である。

結構これのエクササイズと似たような話をキレる私をやめたいでも読んだことがあって、その本ではゲシュタルト・セラピーと呼ばれていた。手法とかは改めて読んでみると違ってたんだけど、自分の心(インナーチャイルド)を自分で客観視してみるところは同じだなと思った。

あと考えることも依存の一種と書かれててそうなの!?!!!?ってなった。エクササイズやってはないんだけどやってみてもいいかもしれん。

ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3 を読んだ

SQuBOKというのがあるというのを知って読んでみようと思って読んだ。ソフトウェアの品質マネジメントや品質技術に関連する技法から事例や国際規格などが整理されていて非常に良かった。

実際困ったときとかに辞書のようにあとで読み返したりすると思う。

新居のにおい問題

今回の家は築15年でめちゃくちゃ古いわけではなく基本綺麗。前に住んでいた家はいい感じの新築だったからか辛いと思うことがまったくなかったのだけど、今の家はくさいところがいくつかあった。見た目はそんな違いはないので気にならないけど、臭いはしんどいのでどうにかしたい。

洗面台の横の棚

エグい臭いを放っていた。何回か嗅ぐと喉に違和感を感じたのと吐き気がした。タオルを入れると臭いが移ってしまう。

6年ほど住んだ団地(築年数49年くらい)にあった棚でもこの臭いを嗅いだことがあり、そのときは管理会社に言ってみたもののどうにもならなかったのでその時は入居してから棚を一切開けないという戦術を取っていた。今回は洗面所なので開けれないとかなり不便なのでどうにかしたい。

消臭スプレー

消臭スプレーをぶっかけた。なんか前にツイッターで話題になってたスプレーで一瞬臭いは消えて感動したけど、少し経つと復活していた。

水につける

調べてみると棚で利用している接着剤にホルムアルデヒドとかいうのが含まれていてそれの臭いっぽいと思った。ホルムアルデヒドは水に溶けやすいらしいので試しに棚の板を取り外して浴槽に水を貼ってそこにぶちこんでから干してみたところ、板からは臭わなくなった。ただ若干の木クズの臭いみたいなのがした。

また棚の外枠からも臭っているけど取り外せないので水をかけた。水をかけた直後は臭いがなくなったが、5時間ほど放置していると臭いは復活していた。ただ前は本当にひどかったのでマシになるだけ良かった。

あとあまり長時間かけたりすると腐ったり水漏れしそうなのでそこまではやってない。

棚の板を買い換える

賃貸なので棚の板を捨てると原状回復が出来なくなるので板を捨てるという選択肢は元々なかったのだけど、もういいか…という気持ちになってきたので棚の板を買い換えることにした。AmazonでF☆☆☆☆仕様で見えるところはすべて化粧仕上げであり、自分の好きなサイズでオーダ出来る板があったのでサイズを測ってそれを頼んだ。購入した板は新品の家具の匂いはするけど臭くはなかったので良かった。届いて1ヶ月ほど経ったけど満足している。

リバースワックスを塗る

調べるとリバースワックスというのがあり、ワックスを上から塗れば臭わなくなるらしいので何度か塗ったら全然臭わなくなった。購入した板は新品の家具の匂いはするけど臭くはないので外枠にだけ塗った。外枠に塗るか原状回復がしにくいので悩んだが、板を買い替えたのだから関係ないと思った。これでほぼ臭いがしなくなった。ちなみに何度か塗った。

また原状回復が出来なくなるのではとビビっていたけど気にしすぎだったかもしれない。試してないけど一応剥離は出来るらしい。

あと調べたら漆喰を塗るというのもありっぽい。なるほど。

漆喰で「シックハウス症候群」を予防する!|納得!素晴らしき漆喰の世界‐4 | 漆喰うま~くヌレール 公式サイト

シックリーンを使う

リバースワックスを塗ってほぼ臭いがしなくなったけど、シックリーンを買っていたので使った。別の場所で単品で使ってみたけど、まあ若干マシになった気がするが少し物足りない気はする。

洗面台の棚

洗面台の横の棚と同じようにエグい臭いを放っていた。こっちは化粧品?のキツめのにおいが合わさっていてかなりきつかった。水をかけたところマシにはなったが、洗面台の横の棚と同じようにリバースワックスを塗った。 棚の板は変えたいけど、ダボの部分が凹んでいたり少し特殊な板だったので変えれなかった。ただ水につけてリバースワックスを何度か塗ったら臭いは許せる程度になったので気にしないことにした。外枠も水をかけてリバースワックスを何度か塗った。あとシックリーンで仕上げた。

台所の食器棚

洗面台の横の棚や洗面台の棚と同じ臭いがする。

長時間食器を入れていると食器が臭くなるのでつらい。水洗いしてから使う必要がある。

板は特殊な加工がされていて新しい板に変更する事が出来なかったので水で洗ってシックリーンをかけて乾拭きした。特殊な加工がされているからというのもあるけど、板自体はあんまり臭いはしなかったのでリバースワックスは塗る必要はなさそう。外枠にはリバースワックスを何度か塗ってシックリーンで仕上げた。

リビングの棚

洗面台の横の棚や洗面台の棚と同じ臭いがする。

今の家は他にも棚が付いててこの棚は使う予定がない棚でめんどくさいので未着手。ただ板は新品を買ったので届いたらやろうと思う。外枠を水をかけるのはリビングなので厳しいので水拭きしてリバースワックスを何度か塗ってシックリーンで仕上げる感じになりそう。

まとめ

すべてにおいてエセっぽいな〜と思いながらやっていて効果が出ればラッキーくらいの気持ちで買っていた。リバースワックスを使うことでだいぶマシになったので良かったが、この記事を書くにあたってまた調べていたら保健所に相談するとよいと書いてあった。実際調べると自分が住んでる区の保健所では住居衛生の相談を受け付けていた。有効活用出来るとよさそう

また内見の時点(クリーニング前)でホルムアルデヒドの臭いには気づいていたのだけど、クリーニングでどうにかなるかなと思ったけどそんなことはなかった。

安心してリリースしたい

最近所属するチームが変わって"リリースされるプロダクトの品質担保"について考えている。リリースされるプロダクトということはリリースされる前のプロダクトであり、ユーザーに届く前に品質を担保せえというのが僕の考えることであると理解した。

ユーザーに届く前に品質を担保されている状態とはなにかを考えるとリリース前に客観的に「これは品質が高い!」といえる状態だと考えた。客観的に品質が高いと言えれば開発者は安心してリリースすることが出来る。

品質が高い=想定外のことが起きない(バグが出ない)だとするとリリース前に100%これはバグがない!といえるかというとありえない気がしていて、なにをやっても結局バグは絶対出る。このあたりは僕がプログラムを書き始めるよりずっと前から考えられてきたことでなるべく想定外を潰す方法はあるにはあるらしいんだけど、ハイコストでありリリースの速度を下げることはやりたくない。なので現実的ではないですね………みたいな事になる。

結局バグが出るのであればバグをなくすことを頑張るのは"ある程度"で収めておいて、バグの影響範囲を小さくすること・バグを早く検知し元に戻すことに注力するのが安心してリリース出来ることに繋がり、ひいてはリリースされるプロダクトの品質担保に繋がるのではないかと思う。

ただそれだけやってもまだ安心とは言えないと感じていて問題は2個あると思っている。

  • 品質が高い=想定外のことが起きない(バグが出ない)はかなりいい加減な定義であること
  • "ある程度"が人によって違い客観的ではないこと

最近いろんなソフトウェアテストの本を読んでいると品質が高い=想定外のことが起きない(バグが出ない)はかなりいい加減な定義であると思った。このあたりも色々とすでに知見はあって、ソフトウェア品質特性モデルや利用時の品質特性モデル(正式な名前がわからない)というのがある。

つながる世界のソフトウェア品質ガイド(PDF)

これらの品質特性が高い状態を品質が高いと定義し品質特性をブレイクダウンして"ある程度"の基準を明確に設けて開発者(というよりプロダクトチーム全員)が参照できるようにしておくといいのではないかと考えている。

ちなみにエリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blogにあるようなメトリクスはリリース後に得れるものなのでここで必要なものとは別物という認識であるがこれらはリリースされたあとに分析などを行うために必要なので別途取る必要がある。その分析を行い課題を見つけることでより洗練された基準になっていくはず。

hisaichi5518.hatenablog.jp

hisaichi5518.hatenablog.jp

ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方 を読んだ

ソフトウェアテストの基礎はソフトウェアテストの教科書によって理解できたので更に深堀りしたいなと思って社内のおすすめ本一覧にあったこの本を読んだ。

気づきがあったのは、このツイートに書いてることで複雑度が高くてhotspotが高いコードはそのままでもバグが起きる場所なんだから早めにリファクタリングしたほうがいいみたいなの書かれてるのはなるほどと思った。

と書いてて思ったけど、前職でAndroidアプリをリファクタリングしているときは機能追加や変更をする場所からリファクタリングして、リファクタリングが終わったあとに機能追加や変更をしていた。一気にリファクタリングとか出来ないからそうしてたんだけど間違えてなかったんだなと思った。実際かなり早く機能追加の実装が終わったりしてたし。「ソフトウェア品質を担保するにはリファクタリングは必須」と書かれていて僕もそれに同意見でとにかくリファクタリングが重要だと思う。

ただこんな感じでよくわからないところもある。

クラス図とか図を書く意味が正直よくわからなくて、実装より前に書くならテストを書いたほうが良いのではないかと思ってしまう。どうなんだ。このあたりはもしかしたらTDDの話につながっていくのかもしれない。

ちなみにこの本は、Kindleに最適化していたので読みやすかった。あとリファクタリングだけじゃなくSHIFT LEFTとかにも言及していたりしてよかった。

そして例のごとく知ってそうなところは飛ばした。

ソフトウェアテストの教科書 [増補改訂 第2版] を読んだ

ソフトウェアエンジニアとして10年くらいやってきていて単体テストは人並みに書いた経験はあると思うんだけど、ソフトウェアテストをこれまでしっかり学んだことがなかったので学んでいる。

これまでテストに関する単語や品質に関する単語は、なんとなく聞いたことがあってなんとなく意味を知っているみたいな状態だったのだけど、この本によってしっかり理解できたように感じる。

ちなみに知ってるところとか比較的飛ばして読んだ。

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方 を読んだ

最近同僚と話したら「説明が大変だ〜」って言ってて「説明って難しいし大変だよな ガハハ」とか言ってたんだけど、そういえばそういう本あんま読んでないなと思ったので読んだ。

説明する事をソースからコンテンツを作成し、それをターゲットにデリバリーすることで成果を出すことと書いてていい話だなと思いました。 あと普段気にすることのない説明するとき(=デリバリーするとき)の身振りなどが書かれていたりして面白かった。こういうのすぐ忘れるので意味ないんだけど。

↑は、自分で課題感を持っている相手に課題をそのまま伝えると不愉快な気持ちになるみたいな事が書かれてて、まあそうだろうけどそうなんだってなった。

個人的には、社内の人に説明することが今後増えそうなので、ソースからコンテンツを作成するあたりをより深く学んだほうがいいだろうなという感じ。 同じ著者のこれとか読むといいかもしれない。

ここまで書いてこれを読んだことを思い出した。全然本の内容覚えてないけど、自分が書いた読書メモを見ると気をつけていることが書かれていたのですごいとなった。