https://gihyo.jp/magazine/SD/archive/2024/202401
Software Design 2024年1月号 レビュー
すでにKubernetesの導入を始めている組織でも、コンテナ化が難しい一部の既存システムだけ仮想マシンとして残り、二重の管理が必要になっているというケースがよく見られます。
これに限る. k8sに全部載せてメリットが大きいようなシステムでないと利点はなさそう. プラットフォームチームがよっぽどうまく回っているとか既存のVMシステムとk8sシステムとが分けられないような場合に当てはまるのかもしれない.
LoRAは知っていたけどその発展型が出ているということまで知らなかったのでよかった.
画像生成AIは現在も驚異的なスピードでアップデートが繰り返されており、2023年7月には“Stable Diffusion XL”（SDXL）が公開されています。
アップデートが日進月歩なのは良いことだけどこれをツールとして使っていくためにフォローするのは大変そう.
実際に過去の筆者のチームでは、報連相が原因で次のような手戻りが発生したことがあります。
- 成果物の作成途中で相談したりレビューしたりせず、成果物をすべて作り切ってからレビューで初めて見せたところ、そもそもの方針が間違っていた
- タスクの遂行中に状況変化があったにもかかわらず、タスクの進め方の再判断をしなかったため、無駄な時間を使ってしまった
- 技術的な調査を行うタスクにて、自ら考えた調査方法で進めた結果、適切な調査ができていなかった
わかりみが深い.
手戻りをなくすと言っても、「技術的な知識やスキルが足りないことによる手戻りはしかたがない」ということもチームで共有しています。知識やスキルは長く経験を積むことで蓄積されるものであり、短期間で習得できるものではありません。そのため、スキル不足による手戻りは成長するための必要な時間と位置づけます。なくしたい手戻りは「報連相が遅いことによる手戻り」のみとします。
🤔 うーん, 技術的に手戻りが発生するのであればペアワークなりペアプロなりで解消したいかな.
正直こういう内容はネットで出てくるし, 実用面でもすぐに腐敗してしまうのであまり価値を感じない. ただ, GitHub copilotに関してここまで紙面を割いているものはあまりないのでその点は良い.
ワークスペース全体をもとに質疑応答をする場合は「@workspace」を付けましょう。
知らなかった.
個人的にLSPそのものについて知らなかったのでよかった.
このへんは自分でもよく使っているのでもう少し紙面を割いて欲しかったかも.
PostgreSQLを使ったことがないのであまりピンとこず.
比較対象が明確に定められていないのであまり特徴もピンとこず. リリースサイクルと標準SQLの対応の話はわかりやすかったかな.
JSONを扱う機能が追加されたのは良さそう.
とてもよかった.
当たり前ですが、エンジニアの開発生産性だけでは、経営目線では片手落ちなのです。
https://speakerdeck.com/mtx2s/technical-debt-and-developer-experience?slide=91
これ思い出した. 当然だけど開発者の側だけ見ていてもダメなのよね.
DX Criteria を使ってきちんと計測をもとに改善していくというのも良い.
要するにドメインモデリングをちゃんとしましょうということだと理解したが, 現実難しいのもわかる. 後から気づくこともあるし. データベースのリファクタリング方法について詳しく説明されているけど実際にこれをやるのはかなり難しいと思う. アプリ側で変更するという方法も説明されていて良き. 実際にはパフォーマンスとかも考慮しつつデータベースをきれいにすることを目指してアプリ側の変更と合わせて少しずつ変更とかかな.
かなり詳しく評価方法について説明されていてよかった. 個人的にあまり情報として得られていないので良い. 異常検知システムという具体例をもとに説明されていてわかりやすい.
並行処理はメモリリークが起きやすい上にテストやデバッグも難しいのできちんとコード設計でケアしないといけない. なので言語レベルでうまく設計されているととても良い. Rustとかもそうだけどこういう言語の設計思想が伝わりやすい言語が個人的には良い言語なんじゃないかなと思う.
かなり具体性の高い脅威(SSRF) の話で導入もしやすくていい感じ.