コンシステントハッシュ法は、Content Delivery Network (CDN) 規模のキャッシュシステムの負荷分散に使われている。 コンシステントハッシュ法を提案したConsistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Webは、特定のキャッシュサーバーへのリクエストの集中を避けることを目的にする。
コードカバレッジに対する批判を散見する。 たとえば、Googleのソフトウェアエンジニアリングの11.2.4節「コードカバレッジについてもメモ」には、コードカバレッジに対する2つの批判がある。 まず、最低限満たすべきコードカバレッジを設定すると、すぐに水準を下回るコードがすぐにリポジトリに取り込まれはじめる。 次に、テストカバレッジが保証するのはテストがコードが実行することだけであり、実行したコードにあるバグを見つけるとは限らない。
このような経験則や論理による批判にくらべると、実験にもとづく批判を見聞することは少ないだろう。 Coverage Is Not Strongly Correlated with Test Suite Effectivenessは、ICSE 2024でMost influential paper ICSE N-10に選ばれた文献で、OSSのテストカバレッジとテストの有効性の相関を調べた。 Apache POI, Closure, HSQLDB, JFreeChart, Joda Timeのコードベースをミューテーション解析し、テストケースの有効性を、テストケースを失敗させた変異体の数で定量化した。 テストケースの数とテストスイートのカバレッジは、有効性との間に中から高の相関があった。 一方、テストケースの数を固定すると、カバレッジと有効性の相関は低から中に減少した。
Go1.5で、ガベージコレクション (GC) のアルゴリズムが3色マーキングによるコンカレント マーク&スイープに変わった。 このアルゴリズムの起源を辿ると、1978年のOn the Fly Garbage Collection an Exercise in Cooperationにいきつく。 ポインタをたどってヒープを黒や灰色に着色するマーキングフェーズと、解放してよい白のヒープを解放するアペンディングフェーズ、この2つのフェーズを繰り返す。 アルゴリズムはStop The World (STW)を抑制することを主眼におく。
2015年に書かれたThe Go BlogのGo GC: Prioritizing low latency and simplicityによれば、3色マーキングのコンカレント マーク&スイープはエンタープライズ向けのGCではない。 それでも、3色マーキングの考え自体はJavaのZGCなど他のガベージコレクションで採用されている。
CAP定理の一貫性、可用性、ネットワークの分断耐性のトリレンマは、1つを完全に切り捨てるのではなく、現実には、3つの性質の優先順位をつける問題になる。 システムの一貫性と可用性の均衡を設計するときは、求める一貫性に対して実現できる可用性を知らないといけない。 Highly Available Transactions Virtues and Limitations は、既存の一貫性を両立できる可用性の水準と対応させ、両性質の強さで一貫性と可用性のペアを半順序関係に整理した。
分散システムのテストをClojureで実装するためのフレームワークにJepsenがある。 Jepsenのテストケースは、システムへの操作、操作後のシステムに期待する状態、障害と操作のスケジューリングの3要素からなる。 テストケースは、スケジューリング通りに操作と障害を起こし、最後にシステムの応答が期待通りか確認する。 Jepsenの公式サイトにはJepsenによる主要な分散システムのテスト結果が公開されている。 また、Kubernetes内部で使わているKVSのetcdの公式ウェブサイトにもJepsenのテスト結果が公開されている。 分散システムの開発側からも参照されているので、分散システムにおけるJepsenの認知度は高いように思える。
その一方で、公式ドキュメントは整備されていないようだった。 たとえば、チュートリアルはetcdを例題にJepsenの使い方を解説しているが、etcdのクライアントライブラリが古く、実際に実装してもチュートリアル通りに実行できない。 かわりに、2相コミットするアプリケーションとテストケースを実装したが、実装のためにJepsenのソースコードを調べる必要があった。 実装したアプリケーションとテストケースはGitHubのリポジトリに公開してある。
それでも、依然として、Jepsenを使ってテストケース実装するほうが、スクラッチからテストケースを実装するよりも効率的ではあると思う。 そこで、今後の備忘録をかねて、Jepsenを試すにあたって、チュートリアルに不足を感じた部分を書き留めておく。
型理論の起源はラッセルのパラドクスにある。 ただし、厳密な起源となる出来事は何かという問いになると、意見は分かれると思う。 名前の通り、ラッセルのパラドクスはラッセルが見つけたものだが、集合論を確立したカントールも同時期に独立して同等のパラドクスを発見した。 またラッセルとフレーゲの往復書簡の中で、フレーゲは、彼の概念記法における述語は述語を引数にとらないと回答した。 ラッセルが概念記法の要素の階層関係を発展させてパラドクスの解消を試みたことを考えれば、フレーゲの述語論理を型理論の起源とみなすこともできるだろう。
runcは抽象度の低いコンテナのランタイムであると同時に、そのランタイムを操作するCLIでもある。 もともとruncはdockerの一部だったが、2015年にdockerからのスピンアウトされた。 containerdがruncでコンテナの操作するので、今でもdockerはruncでコンテナを操作していることになる。 この記事は、runcの実装に使われているLinuxの機能を紹介する。
システム設計の面接では、与えられた情報からシステムに求められるシステムリソースを試算することを、back of the envelope calculations (estimation)という。
システム設計面接におけるNetflixやYoutubeのような動画サービスの問題における要点を整理する。