2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。
デッドレターメッセージが循環する可能性がある。例えば、queue がデッドレター用のルーティングキーを指定せずに、デフォルトの exchange にメッセージをデッドレターした場合などに起こる。このとき同じ queue に2回届いたメッセージは no rejections in the entire cycle だった場合にドロップされる。
前々から Windows マシンがほしいと思っていて、次のお仕事が決まったので思い切って購入することにした。買おうかどうしようかを迷っている心の中の動きのコストというか、検討事項としてずっと残り続けるのもあまり生産的ではないなと最近は思うようになっていた。私が Widnows マシンが必要になった背景はこれら。
行政の電子申請・手続きはまだまだ Windows アプリが主流
最近は Windows アプリ版とは別に、Web 版というブラウザベースのアプリケーションが提供されつつあるが、まだまだ黎明期で一部の機能しか対応してなかったり、不具合で macos だと動きませんと障害情報が出てたり、ひどい場合だとブラウザベースなのに Linux はサポートしてませんとか言われたりする。毎年この申請は Web 版で対応したやろか?と調べて、やっぱりまだできんかったと紙ベースの申請に切り替えるときの、調べるコスト (とがっかりするコスト) がしんどくなった。
VR 系アプリケーションのプラットフォームは Windows
Facebook 社が Meta 社になって、ややメタバースが盛り上がりをみせつつある。Oculus Quest 2 を買ったものの、VR 系アプリケーションは Windows がメインターゲットらしく macos や linux は、現時点ではサポートしていないことが多い。Oclus Link も Windows しかサポートしていない。せっかくヘッドマウントディスプレイを購入したので、そのデバイスをもっと活用するためにも Windows マシンがあった方がよいと考えた。
Microsoft Teams を使いたい
私の周りでも Microsoft Teams を使うことが増えてきた。ゲストアカウントでも会議できるのでエージェントと打ち合わせするときは Teams を使ったりしていた。社内システムを MS 系のプロダクトで固めている企業は普通に Teams を使っているし、顧問さんから聞く話しでも Teams (と MS 製品とのインテグレーション) の評判はよい。チャットツールを対象としたプロダクトを作っていくにあたり、今後は Slack だけではなく Teams 対応も必須になっていく気がする。実際に私も Slack/Teams 両対応のプロダクトもみかけるようになりつつある。Microsoft Teams を Linux で使えるかどうかは調べてないのでわからないけど、Windows マシンが1台あった方が手っ取り早いと考えた。
オフィスと自宅にパソコンを据え置きたい
オフィスでは普段デスクトップマシンを使いつつ、macbook をサブマシンとして使っている。自宅で作業するときは macbook を持ち帰ったりしていた。人間はどんどん怠惰になるのでこの持ち運びが面倒になってきたり、持ち帰ってないときにパソコンで作業したくなったりしたときは、オフィスに出かけるといったことをするようになってストレスにもなってた。徒歩でも15分あれば行ける場所にオフィスがあるので、タブレットやスマホでの作業効率を考えたらオフィスに行ってしまう。ラップトップを自宅とオフィスに置いておけるといいなぁとは薄々思っていた。これを機にオフィスには asus マシンを、自宅には macbook を据え置くようにしたい。
あと「役に立たない CAP 定理」というコラムもおもしろい。CAP 定理とは次の3つはすべて成り立たず、2つを選択することを強いる。
一貫性(Consistency)
可用性(Availability)
分断耐性(Partition tolerance)
CAP 定理は歴史的にデータベースのトランザクションのトレードオフについての議論の出発点として引用され、有名な定理ではあるが、分散データベースの研究者の中では1970年代から知られていたことであったらしい。そして、ネットワークを介した分散システムは、分断耐性が必須 (ネットワークが切断しないことはないから) であることから一貫性か可用性のどちらかを選択するしかない。ここで一貫性とは線形化可能なシステムを実装することだが、これはパフォーマンスのデメリットが大きい。そのため、現代の多くの分散データベースは線形化可能性を提供しないことを選択しており、結果として可用性と分断耐性を選択することになっている。したがって、CAP 定理から議論を始めることは無意味であると言う。
冒頭の格言で kafka というキーワードが気になったので原文を探して (deepl で翻訳して) 読んでみた。一般論で考えたらこの問いの答えは停止してしまう方を選択するように私は考えてしまったが、原文の記事によると、この答えはアプリケーションに依るという。ダウンタイム=データの損失という特性のアプリケーションであれば、間違っている可能性があってもすぐに復旧して動かした方がよいという場合もあると言っている。kafka はどちらかと言えば、間違っていても動き続ける方のシステムに分類されると思う。メッセージの到達保証も At Least Once だし。