hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

発育状況

9ヶ月過ぎてしまった。早い…。

  • 離乳食が1日3回になった
  • 座れるようになった、何も楽しいことがなくても手拍子したり笑ったりして機嫌が良い
    • 座って本棚をバラまく活動が始まった
  • 多少はハイハイして動き回れる、換気のため扉を開けていたら、気づくと風呂場で遊んでいたりして危険
  • つかまり立ちしつつあって、そこは耐久性的に無理でしょ…っていうところで構わず試みるので危険
  • いないいないばあっ!が気に入っているようで録画して、もう無理…というときに見せている
  • リビングで寝てもらってたけど、一緒にいるほうが目覚めたときの機嫌が良いのでは?という仮説があって、きのうはベビーベッドを寝室に動かして一緒に寝るようにしてみた。今朝は朝5時から大騒ぎしていてめっちゃねむい
    • 睡眠がうまくいくかで、その日作業できるコンディションかどうかが決まるので、めっちゃねむい日はゆったり過ごせるようなスケジュールになっていると良いけど、締切もあるのでやるしかない

日々できることが増えているので、在宅勤務していて、様子の見れる時間が長いのは嬉しいことだと思う。
そのかわり、機嫌悪いときには抱っこしながら仕事することになり、物理的にキーボードに触れないまま音声入力で仕事することになったりと、苦労することはあるけど、保育園に入れるまでのあと数ヶ月のことだろうから、今だけの苦労だろうと思う。
とはいえ、保育園に入れるとなると、荷物の準備とか、時間通りに送り迎えする、障害対応中で送り迎えに行くのが困難など、さらなる苦労が待っていることだろうと思う。

児童施設にAmazon欲しいものリストでものを送りつけられる取り組みを発見した。
自分はAmazon経済圏の民で、ブログのアフィリエイト収入をほそぼそと得ているので、適当な近所の施設に絵の具を送っておいた。
こういうとき、税金をどんどん取られるよりは自分の意志で寄付するほうが気分が良いことをなにかに利用できないだろうか?

www.amazon.co.jp

木曜日くらいに保育園の書類を出せて待ち状態になったのでちょっと気楽になっている。
今日は鬼滅の刃を1巻から読み始めて最終巻まで読んだら一日が終わった。永久に続いたりせず、サクッと終わってて偉い。
柱が続々出てきたり、敵キャラも大集合しているのを見て、こんなにキャラクターが出てきて大丈夫なの?って心配になったけどちゃんと全員それなりに出番があって終わっていた。
漫画固有の文化ってあると思って、刀を持って戦っているのに斬撃が飛んでいく、という文化。何の違和感もなく読んでいたけど、初見だとびっくりしそう。

部屋のレイアウト考えるの難しい。いま寝室で仕事してるのだけど一日中明るさが一定で、朝5時に起きて仕事するぞ、というときも、夜2時に眠すぎるってパソコン触ってるときも、昼ごはん食べたあとも、同じLEDの明るさに照らされている。
引っ越したらもうちょっと明るい場所に出ていきたい気がしつつ、リビングの真ん中で会議するんじゃなくて、ちょっと奥まったところというか、プライバシーは確保したい。
いまのところ独房を作る案が有力で、いま気づくと5日連続とかでまったく家から出ないことがあるので、仕事をするには一度ベランダに出る必要がある、という形にすれば、毎日外出できてよさそう。

GitHubの 👎 を無効化する

この記事とほぼ同じことをやっていて、自分の場合はちょっとモチベーションがちがって、誤クリックでうっかり👎をつけてしまって、あわてて取り消す、みたいなことがたびたびあったので、Stylishで無効化していた。
この記事だと、他人のつけた👎も見えなくしていて良いと思う。
techblog.kayac.com

コントラストを下げて、pointer-events: none;でクリックできないようにしている。

@-moz-document domain("github.com") {
button[data-reaction-label="-1"], button[data-reaction-label="Confused"] {
    pointer-events: none;
    filter: contrast(0);
}
}

f:id:hitode909:20211217134448p:plain

レビュワーランダムアサインの使いづらさ

以前は手作りのおみくじを使ったり、GitHubのCode review assignmentを使ったりで、レビュワーをランダムアサインする暮らしを続けているけど、いまいち使いづらい点がある。

  • 知ってるところで呼ばれるならいいけど、いきなり全然知らないところを読むことになると腰が重い
  • Pull Requestが何個かセットで完成するようなシリーズ物の場合に一部だけ見ても理解できない
  • レビューにかかる手間を考えると、実装の大きさは最小になっていることが求められるので、追加でリファクタリングとか、品質アップとか、ついでにここも直したよ、とか、根本対応、みたいなことをやりづらい
    • 特に、このことを最近思うようになってきた


これがコードレビューじゃなくて設計レビューなら、毎日別の人に話しかけるということはしなくて、手伝ってくれる余裕のある人を探して相談に行くし、そういう余裕のある人が居ないなら、設計レビューできる人がいないなら、今この開発はできませんね、となる。
レビューコストも誰かの時間を取っているわけなので、思考停止して、おみくじすれば時間や人は出てくるじゃん、じゃなくて、これからこういう、大きめのものを作るのでレビュー手伝ってもらえませんか、みたいな話をして、先に協力をお願いして、おけるとよいのだろう。
その上で、たしかにリファクタリングしたほうがいいのでレビューがんばります、みたいに合意できればお願いできそうだし、場合によっては、今この規模のものをレビューする余裕はないので、今回は実装しない、という流れもありえると思う。


先月も似たようなことを考えていた。ここでいう1と2の間で、1.5の立場で、たびたび見ているけどよさそう、という粒度の様子見具合になってほしい場合がある。
blog.sushi.money


おみくじじゃなくて、ここのコンポーネントはこの人が作ったよ、おすすめ、という推薦にしたがってレビューをお願いしていくほうが、やりたいことには近いかもしれない。
これだと、全然知らない部分のリファクタリングをいきなり見せられることはないし、シリーズになってるなら、だいたい同じようなメンバーが推薦されてきそう。

f:id:hitode909:20211217070738p:plain
レビュワーの推薦機能
Pull Request レビューをリクエストする - GitHub Docs