卵がだめだったのか、食べ過ぎだったのか、子供が繰り返し嘔吐していた。
もう吐き終わって大丈夫かと思って出かけてみたら、最終的に車で吐いたので引き返して、心配なので休日に見てくれる小児科に行った。
ちょっとした不調でもハラハラするので、今後やってくるさらなる身体の不調（風邪、インフルエンザ、骨折、四十肩、痛風など）に遭遇したときには、やっていけるか心配。
ティファールのIH非対応フライパンは食洗機で洗えない
取っ手の取れるフライパンを以前から妻が持ってたので使っていたのだけど、説明書（中火で使ってください）を無視して最強火力でチャーハンを作ったりするので黒焦げになっていた。
子供が生まれたタイミングで、同僚たちからカンパで同じのを送ってもらった。
うちはガスコンロなので、IH非対応のほうが軽くてよいだろう、という選択だったのだけど、のちに気づいたことは、IH対応のモデルは、食洗機にも対応している、ということ。
これまでも鍋は手で洗っていたのでまあいいのだけど、今後めちゃくちゃ忙しくなってくると、鍋を洗う時間が取れなくなってくる恐れがある。それが心配。
最大火力で使っている時点で想定と使い方をしていることは明らかなので、気にせず食洗機で洗うことになるかもしれない。
というのを、この日記を読んで思い出したので書いておく。
blog.3qe.us
■
良かった
引っ越しによって浴室乾燥がなくなった人いたらコメントください！
引越し先ここでいいか、というところが見つかった。募集がかかってすぐの部屋を見つけて問い合わせして、これから退去、改装があるのだけど、退去後あたりのタイミングで部屋を見せてもらってから契約、という流れで話を進めさせてもらっている。
いったん同じレイアウトの別室を見学させてもらって、ここならいいだろう、という雰囲気だった。他の方に取られる心配をしていたけど、もう募集は止めてくれたとのこと。
気になるのが、いま住んでるのが分譲賃貸の設備充実マンションなのが、普通のレトロマンションくらいの設備になるので、ビルトイン食洗機と浴室乾燥機がなくなること。
食洗機は周りの子育て世代はみなパナソニックの40点洗える大きめのを使ってるので、そういうのを買うのがよさそう。水栓が交換不能なタイプだったらあきらめてタンク式のを買うしかないけど、そこは大家さんに蛇口の型番を聞く。
panasonic.jp
食洗機は置いたらいいのだけど、カワック24を設置するのは不可能で、別のアプローチが必要そう。花粉症なので外に干すのは避けたくて、浴室に干して、換気扇を回して、ドアを開けて、サーキュレーターでも回しておけば良いのかな？エアコンをつけっぱなしにしてドアを開ければ良い？ドラム式洗濯機は持っているので、だいたいはそれで乾かして、シャツとか縮むと情けない服だけ干している。バスタオルがじめっとした部屋に干されている、みたいなシチュエーションは避けられそうで、それは救い。
普通の人は生活レベルを下げないためか、引っ越したら浴室乾燥がなくなったのでこうしました、みたいなことをブログに書いている人を発見できなくて、あまり知見を得られない。今のところ、こういう、そうですね…という情報しかみつけられていない。
乾燥機能は、浴室乾燥機でなくても換気扇や窓の利用によっても得られます。浴室を使用しないときには常に換気扇を回しておくようにすれば、湿気がこもるのを防ぐことは十分に可能です。
https://www.homes.co.jp/cont/rent/rent_00604/
承認ではなくて、よさそう、と思って暮らしている
普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。
なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。
レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと
- レビューを通した以上、以後は私の責任です、という態度
- 職人魂を感じる
- 見たところよさそうに思いました、という態度
- 通りすがり風情を感じる
- まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度
- やっつけ仕事
かるぱさんのチームでは1になっているのかな(追記)こうなっている、ということではなくて、こういう感覚に近い人がいるのか？というくらい、とのことだった。
だとしたら、DevとOpsがわかれていて、コードを放り投げると運用してくれる、みたいなモデルに近そう。
そのモデルを推し進めていくと、DevとOpsがサイロ化しているチームでは、DevがめちゃくちゃなSQLを発行してもOpsがサーバーを増強して動かしてくれるように、めちゃくちゃなコードを書いてレビュー依頼に出したら、以後、レビュワーがsuggest changeし続けて直してくれる、ということになって、コード書く側はやっつけ仕事でいいことになってしまう。
うちのチームでは、レビューの時点では、私が見ても理解できました、よさそう、Looks Good To Me、みたいな、上のモデルでは2で、それでも壊れてしまったときは、誰の責任、ということはなくて、壊れてたらユーザーさんが困るので、みんなで寄ってたかって直しているように思う。
変なコードを書いてもCIが落ちずにそのままリリースしてしまう、ということは開発フローが悪いという、チームとしての課題でもある。
SLOは定めてはいるので、本当は、SLO的にギリギリなので慎重に(1の態度)、とか、今週はSLOに余裕があることだし、壊れても大した影響のない部分なので雑レビューで出してみよう(3の態度)、とか使い分けられるとよいのだろうけど、まだそこまでは活用できていない。
ただ、リリース前に延々と詰将棋みたいに議論しているよりは、リリースして動くか様子を見ればいいじゃん、実験できるなら安全に本番環境で実験できればいいじゃん、という想いはあって、リリースできるか、よりは、問題があったら引っ込められるか、ということのほうを重視している。
techblog.karupas.org
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せあくまでLooks Good To Meであって、私にとっては良いと思います、第三者から見ても大丈夫そう、くらいのニュアンスでapproveしてました
2021/11/08 09:55
ちょっと似たような違う話で、コードレビューのさいに何往復で収束するか、そのやりとりの回数を減らせるとよいことでしょう、ということを以前考えていた。権威的になると、許可を得るために何度もお願いする、みたいになって疲れていきそう。お互い歩み寄って、最速で収束させるぞ！みたいな気持ちが大事だと思う。
blog.sushi.money
