Software Designのほかに最新知識を追い掛けるのにWEB+DB PRESSを定期購読することにした。オフィスに紙のはあるんだけど、電子版でほしかったので自腹。
積ん読消化月間でちょっと読み飛ばしぎみ…（vol.132来てるし）。
- サバンナ便り
- t_wadaさん記事。
- 「テストサイズ」という考え方。テストをSmall/Medium/Largeにサイズ分けする。
- Small: 単一プロセス。高速・スケールするがネットワークやデータベースは使えない、プロセス外通信はテストタプルで置き換える。1件100ms未満、最長1分。おおむねユニットテストと同じ。テストタプルを使いすぎると実装の変化に弱くなり保守性が損われるので、必要十分な量のテストタプルを適切な箇所に使用するスキルが必要。
- Medium: 単一に閉じた環境であれば外部リソース利用を許容。1件1秒未満、最長5分。テストの実行にDBとの接続が必要など。fake実装やコンテナ組み合わせなどのスキルが必要。
- Large: リモートマシンアクセスも許容。最長15分。実際にデプロイして動かすなど。外部環境起因の物事を可能な限り抑える実装スキルが必要。
- CIとの組み合わせを考えると、Smallテストの比率を上げ、Largeテストの比率を下げる。
- 実装して学ぶHTTP/3
- フロントエンドコンポーネント駆動開発
- SREで開発を加速させる
- masayoshiさん記事、サービス障害対応の話。
- 開発をより効率的に進めるために、平均修復時間を減らす、障害の発生回数を減らす。
- 正常なときの動作を知る。技術を知り、サービスを知る。障害対応を知る。
- 障害対応フォーメーション。山火事対応のICS（Incident Command System）の枠組を参考に、実作業の対応と調整、障害対応のステークホルダーとのコミュニケーション、障害対応自体のコントロール。オンボーディングでは書記役に入れてみるとよい。
- 障害対応のドキュメント化。リンク集や担当の役割分担をテンプレート化しておくとよい。障害発生時にまずテンプレートをコピーして議事録や情報を集める。
- 対応訓練。目的を絞った小さな訓練を複数設計し、定期的に実施する。テンプレートを確認してロールプレイする、DBのフェイルオーバーのような特定の実作業を訓練する、抽象度を上げて原因だけ（スロークエリ、AWS AZが落ちたなど）を決めて作業を作ってみる、擬似的な障害に対して原因の特定から行う（アプリケーションに一定の確率でエラーとなるバグを仕込んだり、AWSのセキュリティグループを変更してDBに接続できない状況にする、など）。カオスエンジニアリングだとこれらをステージングでなく本番環境で行うが、Observabilityがないと単に障害を起こすだけになってしまうので上級め。
- 障害の振り返り（ポストモーテム）。非難しない、ポストモーテムを書くことを目的にするのではなくSLOを利用して信頼性のもとで開発速度を最大化することが目標。障害の原因・時系列やトリガ・再発防止アクションのほか、障害対応の仕方やユーザーへの告知内容などの対応自体も含める。
- 過去のポストモーテムを活用して障害対応訓練をしてみる。
- Goに入りては…
- みんな大好き文字列連結。+は1桁遅い。bytes.Bufferかstrings.Builderがよさそう、Growメソッドを使って先に領域指定するなど。
- 現場のPython
- フリガナ振り。おおむね同じようなことは挑戦したことがあって（総ルビなどは書籍制作だと「たまによくある」要求ケース）、アプローチ的にも同じ感じではあった。辞書のメンテが難しいんだよねぇ……。
- PHPで複雑さに立ち向かう
- 非同期や並行処理の仕組み、実装の話。イベントループ、Promise、コルーチン。
- Ruby3標準添付ライブラリ紹介
- znzさん記事、rakeとthorの話。rakeは使っているけど、thorはそういえば使ってないな。Railsあんまり使っていなかったせいか。
