[2023年8月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2023年8月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：アジャイル開発の課題に立ち向かう
特集②：TiDB入門
Extra Feature
Development
Software Design 2023年8月号

特集①：アジャイル開発の課題に立ち向かう

XP（エクストリームプログラミング）
- コミュニケーション
- シンプリシティ
- フィードバック
- 勇気
- リスペクト
アジャイルでよくある課題と解決策
- アジャイルの経験がない
  - これは世のすべての事柄に当てはまるものなのでわざわざ取り上げる必要がないと思う
- 完成品の納品を要求される
  - ちゃんと準備しておけみたいなことが書いてある
  - 受注して始まるようなプロジェクトではそもそもアジャイルを採用すべきではないと個人的には思っている
- 要求はドキュメントが渡されるだけ
  - 解決策には「顧客がチームに参加していない、つまり丸投げ状態である」ことが原因だと書いてある。つまり、まさにさっき書いたように「これやってね～」なプロジェクトではそもそもアジャイルは向いていないのである
- 全部を開発してしまう
  - アジャイルは「動くもの」を「継続的にリリースする」ことが大事なので、動かないものだけをつくるスプリントなどは基本的にないほうがよい（はず、私ケン）。
  - なので毎回MVPを考えることの重要度が上がってくる
- 要求の変化に対応できない
  - これはアジャイルならではの課題ではないし、むしろアジャイルのほうがサイクルが小さい分対応しやすくなっているくらいじゃないとおかしい。文句が出るなら開発者サイドに問題があると思う
- 特定のメンバーに依存している
  - ベロシティがいわゆる「工数」で換算されていると、人の違いが出力に全く関連しない状態になるのでプロジェクトとして問題が浮き彫りになりやすくなる。ウォーターフォールだとそれが無視できるくらいのレベル感になるが、一単位が一週間とか二週間だとかなり問題になる。よね（感想）
効果的なデイリースクラム
- 昨日やったこと
- 今日やること
- 私「やチーム」が障害となるものがありそうか
  - ここ人間が出ますよね
効果的なスプリントレビュー
- 呼ぶべき人を呼ぶ
- マンネリを防ぐ
  - 「うまくいって士気があがった回はProblemよりポジティブな内容を議論した方がいい」とあったが、これは本当にそうなのだけど、問題なのはこれを気をつけるべきなのは僕たちではなくレビューのときだけ参加して口を出してくるチーム外の人であるということ。彼らはアジャイルに参加している立場のはずなのにチームビルディングに無神経なのが毎度本当に腹が立つ（感想！！）
アジャイルでの設計や開発
- ドキュメント
  - 「必要に応じて作成します」だそう
  - プロダクトとして完成やリリースが見えたらドキュメントだけは最後にちゃんとやるというのもかなりありだと思う
- ユニットテスト
  - もちろんやる
  - もちろん自動でやる
- CI/CDをいれる
  - 当然だね
- 技術的負債とのつきあいかた
  - この枠のものじゃないと思うので割愛
大規模アジャイル
- やったことないので覚えておく
- プロセス単位でわける
  - これアジャイルむずくない…？
- コンポーネント単位でわける
  - これはわかる
プロセスのフレームワークについて色々紹介があった
- Nexus
- LeSS
- Scrum@Scale
- SAFe

特集②：TiDB入門

NewSQL
- RDBMSとNoSQLの両方の特徴を持っている
- 「分散性を持ったRDBライクなデータベース」という表現
- ACID特性があり（つまり強い整合性がありながら）拡張性が高い
- SQLがインターフェースとして使える
- 非構造化データには弱い
  - これは別にいいよね
- 比較
  - 可用性はちょっと低い
  - ほかは全部◯で一見すると矛盾…
- 主要サービス
  - Google：Cloud Spanner
  - CockroachLabs：CockroachDB
  - PingCAP：TiDB
TiDB
- オープンソース
- タイデービー
- クラスターがアプリケーションからMySQLのインターフェースで接続を受ける、ストレージクラスターからデータを取ってくる
- ストレージの中はTiKVというたぶんキーバリューストアがいっぱいある感じになってて、このTiKVはCNCFでGraduatedなので相当安定していると思われる
  - 永続化はRocksDB！
  - Rust製！
- コンポーネントが多く分散量多いため、内部のレイテンシに気をつける必要がある
主な特徴
- マスターの冗長化がかんたん
  - 冗長化というワードが出るあたりはRDB、スケールや可用性を気にしなくてよさそうなのはNoSQLという感じで、このへんが一番融合されているのがわかりやすいところ？
- シャーディング不要
- スケール
  - 読んだ感じオートスケールっぽいものは普通にありそう
  - コンポーネントごとに設定できるのでI/Oだけとかディスク容量だけとかできる
- データ反映の遅延を気にする必要はない
- タイムトラベルクエリ！！
  - 過去のデータを見れる、すご。
- Web用のダッシュボードがある
４章に実際の決済アプリケーションでの負荷試験的な話がありとてもよかった

Extra Feature

マルウェア対策とエンドポイントセキュリティ
- Emotetの話、おもしろい
- 「Emotet自体は不正なコードをほぼ含んでおらず、あとからちょっとずつ悪いものをダウンロードするようになっているだけ」で、そのダウンロードもメールの添付ファイルでマクロを開かせてPowerShellで実行するのが多いのだと。
- 感染すると感染者同士でボットネットが構築されるようになり、被害をゼロにするのがどんどん不可能になっていく

Development

Nostrのしくみ
- Notes and Other Stuff Tranmitted by Relays：あらゆるものをリレーで転送する
- 公開鍵と秘密鍵だけ
- すべてのアクションはイベントというJSONで表現され、署名がされる
  - Nostrのトップページにでかでかと書いてあるあれがそうかな？
  - なので誰から送信されたイベントか簡単に検証できる、という仕組み
- これ自体はSNSではなくプロトコルなので、ゲームみたいに使われたりもする
  - この辺はやはりWeb3みがある
- リレーによる分散性はわかったけど、そのノードはどうやってそれぞれが運用するの？？
  - なんかいくつか「リレー」という名前でドメインが紹介されていたので、これを使うとオンラインでクライアントとして動けるようになる的な感じだろうか。
- なりすまし防止のために「ドメイン認証」があり、自分の持っているドメインを使って証明ができる
- ビットコインの投げ銭機能
  - Zap：NIP-57
  - やってることはサトシ単位でライトニングで送るだけ
  - 39サンキューや114いいよが多い
- 代表的なクライアント
  - Dams
    - ノストラダムス
    - iOSオンリー
  - その他いっぱい