先週くらいからゆるゆると社内で共有してきた事業部の組織変更が発表になった。自分自身の立場や動きは変わっていないが、一番近くのチームを分解して、よりミッションが明確になるようにしたというのが身近なところでの変化だろうか。今回の組織変更は、自分の思いというか、意見を全面的に取り入れてもらった形に近いので、うまくいってもいかなくても、１年後くらいには結果をアウトプットしようと思う。
夜、お風呂で121. 日常の切り取り方 | Ossan.fmを聞いていたら、突然この日記が紹介されてびっくりした。これがラジオでお便りを読まれる感覚かと思って嬉しくなった。
今日のウェブログ
フロントエンド初心者がGatsbyでブログを作り直した話 - As a Futurist...
60 Best Google Analytics alternatives: The Complete List for 2020 | Plausible Analytics
riywoさんのブログを作り直した話で、GAのalternativesの話がでていたので調べていた。riywoさんが使っているPlausibleにちょうどいいまとめがあったので見ていたが、たしかにこれらを見てもPlausibleはよく出来てるようにみえる。乗り換えてみようかなぁ。
Clubhouse: Drop-in audio chat
ウェブログとはちょっと違うけど今話題のやつ。せっかくなのでやってみようと、会社の方に招待してもらったが、自分が配信するようになるイメージはあまりわかないよなぁ。夜にいくつかのルームにお邪魔して話をきいてた。
今日の読書
1ポモドーロでサイトリライアビリティエンジニアリングの8章と9章、第3部の導入を読んだ。
リリースエンジニアリングは安定して繰り返せることが大事なので「個性的」でないほうがよいというのは納得。また、初期から始めたほうがよいというのもその通りだと思う。最初から入れたほうがレバレッジが聞くというのはもちろんだが、リリースプロセスはアプリケーション自体の設計や実装よりも安定した基盤であるインフラや実行環境に依存していて、ツールやプロセスを大きく変更する理由が少ない。概ね満足できるものが最初にあればそれを使い続けることに不満は出にくいように思う。ただ、逆に最初がまずいものだと、それを変えるインセンティブが働きにくく、長い目で見たときに強力なブレーキになりうるものだと思った。
9章は引用の文章がどれもよかったのだけど、特に「ソフトウェアは退屈であることのよい」というのはとても共感できた。特にソフトウェア開発という文脈では、サプライズはいらないのだ。ユーザインタフェースの文脈では「驚き最小の原則」とも言われる事があるが、思ったとおりにことが運ぶというのはソフトウェアでとても大切なことだと思う。
ソースコードリーディングがスムーズに進むのは、自分のメンタルモデルとソフトウェアの構成要素が一致しているときだ。ただ、勘違いしてはいけないのは「自分のメンタルモデル」と一致しているのが大事なのではなく、「私達」あるいは「世の中の優れたエンジニア」のメンタルモデルと一致していることが重要なのだ。そのためには、日々学習し続けるしかないのだよなぁ。伸びしろしかない。
今日の英語
ラジオ英会話のLesson196。文法の解説で、省略されてるのを説明してくれると理解が深まるなぁと思った。英語では「～しないと思う」ではなく「～すると思わない」という表現が好まれるというのを見て、こういうの昔習った記憶はあるんだけど、ぜんぜん自分のものになってないなぁと思ってしまった。
i don't think that will work.
