https://gihyo.jp/magazine/SD/archive/2024/202411
わりと応用が効きそう.
試験内容つまみ食いできるかなり良い.
WHOIS提供については、ICANNの決定によりこれまでレジストラ、レジストリに義務付けられていたWHOIS提供が2025年1月に非義務化されます。
知らなんだ. 後継のRDAPを触れるようにならないと.
第1章, 第2章はツールの使い方なので使っている私自身には既知の内容ではある. 公式のドキュメントなどでは情報が不足しがちなので業務で導入するための参考にはなるかもしれない. 基本的にはLLMの考え方を意識して使うと良いということだと思う. One Shot のようなプロンプトパターンがそのまま応用できる. 個人的にはエラーメッセージを読み解いてくれるのはやっぱり便利.
「第4章：Infrastructure as Codeで生成AIを活用する アーキテクチャ図⇔IaCコードの変換も自由自在」の内容が独特で面白い. ただインフラ周りは設定間違いとかが難しい上に, 生成AIに対してフィードバックを与えづらいので, なかなか難しそう. まあそのうちAWSコンソールの右下にチャットAIがついて解消されそうな気がする.
「第5章：AI駆動開発の将来 AIによる今後の開発スタイルと求められるスキルとは？」の内容は現状を俯瞰して考える良い内容. 開発者の資質は「コピペエンジニア」のころから大きく変わってはいないはず.
ランサムウェアの侵入経路の大部分は標的型メールだと思っていたので, VPN機器の脆弱性が増えているという話は興味深い. やはり基本的な脆弱性対応はかなり重要.
CrowdStrikeの一件のおかげでEPPとEDRの違いが認知されたね...
突然論理式の話になって難しくなった. 論理式が重要というより, 正当性がどのように証明されるかということだと理解した.
検索エンジンそのものの Elasticsearch へのリプレイスと, 検索システムバックエンドのリアーキテクチャを同時に行っていると読めるけど, 両方同時に変更するのはなかなか大変そう.
1つ目は、バージョン更新対応に伴う作業の多さです。Elasticsearchは頻繁に新しいバージョンがリリースされます。これに対応するためには、既存の設定やプラグインの互換性を確認し、システム全体のテストが必要です。テストを実施する際には、バージョンアップ後の新しいクラスタを準備し、現行クラスタと新クラスタそれぞれのindexを同じ頻度で更新することで、同一の環境を構築し、リグレッションテストを行う方針を取りました。
つらい.
検索システムバックエンドのリプレイス作業として事前調査とPoCをやっていて, かなり周到に行われていたのがわかる. エンジニアは作り直したいと気軽に言うけど, 大規模になるとやはりこのくらい計画してやらないとダメなんだろうな.
「質と量の最大化」というと、「質と量はトレードオフでは」と言われることがありますが、筆者はそうは思いません。
プロダクトが乱立する不確実性の高い現代においては、いずれか1つを追うことで成果を出せるほど簡単ではありません。プロダクトが乱立する不確実性の高い現代においては、いずれか1つを追うことで成果を出せるほど簡単ではありません。
良い.
あまり本質的ではないけど, 心理的安全性の確保とモチベーションの高さ・当事者意識との結びつきは必要条件ではあるものの, 十分条件かというと自明でないと思う.
社内ツールに良いのでは.
時事的な話題がよくまとまっていて面白い.