はい、わかりました。では、以下が今日の「zenncast」の原稿です。
---
みなさん、おはようございます！「zenncast」のマイクです。今日は2024年5月23日、木曜日ですね。今日もZennでトレンドの記事をみなさんにご紹介していきたいと思います。
前回紹介した記事は、「エンジニア勉強会でFigma使ってプレゼンしたら思ったより良さげでした」、「ベクトルデータの容量を96%削減するBinary Embedding」、そして「AlphaFold3の中身の日本語解説」でした。Figmaでのプレゼンやデータの効率化、AlphaFold3の解説など、非常に興味深い内容でしたね。
さて、今日ご紹介する記事は全部で5本です。それでは、早速一つ目の記事からいきましょう。
。。。。
最初にご紹介するのは、「CQRS設計パターンをモダナイズする」という記事です。
CQRS、つまりCommand Query Responsibility Segregationの設計パターンについてです。これはシステムの書き込み操作と読み取り操作を分離することで、スケーラビリティやパフォーマンス、セキュリティの向上を図るアーキテクチャパターンです。最近ではサーバレスデータベースや分散アーキテクチャの進化により、データベースの管理負担が軽減され、インフラ設計を気にすることなく高可用性や耐障害性のあるデータベースを構築できるようになりました。
具体例としては、AWS Aurora ServerlessやPlanetScale、Cloud Spannerなどが挙げられます。また、バックエンドAPIの自動生成ツールの普及により、開発者はコマンドモデルに集中し、クエリモデルは自動生成ツールに任せることが可能になりました。これにより、エンジニアはボイラープレートコードから解放され、サービスにとって重要なロジックに集中できるようになります。
Aurora Serverless v2とPostGraphileを使用することで、インフラエンジニアの運用リソースの節約やバックエンドエンジニアの認知負荷の軽減、フロントエンドとバックエンド間のコミュニケーションコストの削減が実現されています。このようなモダンCQRSアーキテクチャを導入することで、少人数のチームでも大規模な開発が可能となり、効率的なシステム構築が期待されています。
。。。。
次にご紹介するのは、「なぜDependency Injectionなのか？ ～関心の分離と疎結合～」という記事です。
この記事では、Dependency Injection（DI）という設計パターンについて詳しく解説しています。DIとは、オブジェクトの依存関係を外部から注入することで、疎結合やモジュール性、テスト容易性、保守性を向上させる手法です。DIはInversion of Control（制御の反転）の概念の一部で、2000年代初頭から注目され、2004年にマーティン・ファウラーが発表した文献で広く普及しました。
DIの利点は、依存関係を管理しやすくし、変更の影響を最小限に抑えることです。具体例として、位置情報から店舗を検索するアプリケーションでのリファクタリングを通じて、DIがどのようにシステム設計を改善するかが示されています。また、DIコンテナを使うことで、さらなる利便性と柔軟性が得られ、インスタンス生成の管理が容易になります。
DIはパラダイムシフトを伴うため初めは難しく感じるかもしれませんが、慣れると複雑性を増すことなく設計の柔軟性を向上させることができます。これに対して、サービスロケーターパターンも紹介されていますが、DIのほうが依存関係の管理が容易であり、疎結合を保つ点で優れています。DIを理解することで、エンジニアはより良いシステム設計ができるようになります。
。。。。
続いての記事は、「RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)」です。
RDBの主キーには、用途やシステムアーキテクチャに応じて適切な採番方法を選ぶ必要があります。例えば、単純なモノリシックアプリケーションにはAutoIncrementが効率的ですが、ドメイン駆動設計(DDD)やクリーンアーキテクチャでは、データの生成と永続化を分離するためにAutoIncrementは適さない場合があります。
アプリケーション側で主キーを生成する場合、UUID（Universally Unique Identifier）が一般的です。特にUUIDv7は時系列ソートが可能で、分散システムでも推奨されています。ただし、主キーは基本的に公開しない方が良いです。外部公開用のIDを別に生成することが推奨されます。
時系列性とユニーク性を両立させるためには、UUIDv7やULIDが適していますが、完全な時系列性が必要な場合には専用のインフラを用意することが望ましいです。金融や入札など、時系列の厳密性が求められるシステムではAutoIncrementを使用することも検討されますが、冪等性を保つ工夫が必要です。
結論として、UUIDv7は分散採番の新しい標準となり得ますが、システム要件に応じて他の採番方法を使い分けることが重要です。また、主キーを外部に公開しない設計が推奨されます。
。。。。
次にご紹介するのは、「Microsoft Build 2024の新発表10選【GPT-4o / Copilot / Phi】」という記事です。
「Microsoft Build 2024」では多くの新発表があり、特に注目されたのは以下の10項目です。
1. CopilotにおけるGPT-4oの利用
2. Azure AIにおけるGPT-4oのGA化
3. MaaSにおける新モデル追加
4. Phi-3モデルの発表
5. Azure AI StudioのGA化
6. Real-Time intelligence in MS Fabricの発表
7. GitHub Copilot Extensionsの発表
8. GitHub Copilot Azureの発表
9. Microsoft Copilot Connectersの発表
10. Team Copilotの発表
これらの新機能やサービスにより、エンジニアにとっての開発環境がさらに強化されることが期待されています。特に、CopilotやAzure AIの新機能は、日常の開発プロセスを大きく変える可能性があります。例えば、GitHub Copilot Extensionsを使って独自の拡張機能を作成し、VS Codeのチャット画面で自前のエージェントを呼び出すことが可能になります。また、Microsoft Copilot Connectersを使って自社データとCopilotを連携させることで、業務効率化が進むことが期待されます。
。。。。
最後にご紹介するのは、「CSS を使って HTML を Markdown に復元してみよう！」という記事です。
この記事では、HTMLをCSSを使用してMarkdown形式に変換する方法を紹介しています。MarkdownからHTMLへの変換は一般的ですが、その逆をCSSで行うのは珍しい試みです。具体的な実装方法としては、`::before`と`::after`疑似要素を使用し、見出しやリスト、強調表示などの各要素に対応するMarkdown記号を追加します。
例えば、見出しには対応する数の`#`を、リスト項目にはリスト記号を追加します。また、強調表示や引用文、コードブロック、リンク、テーブルなどもそれぞれMarkdownに変換するためのスタイルを適用します。ただし、疑似要素は選択できないため、Markdown形式のままテキストをコピーすることはできません。また、`br`や`img`などの一部要素には疑似要素が適用できないため、これについては別記事で詳しく解説されています。
このプロジェクトは、CSSの応用例として非常に興味深く、エンジニアにとっても多くの学びが得られる内容となっています。
。。。。
さて、今日ご紹介した記事を駆け足で振り返ってみましょう。
1. 「CQRS設計パターンをモダナイズする」
2. 「なぜDependency Injectionなのか？ ～関心の分離と疎結合～」
3. 「RDBの主キー、UUID使った方がいいの？(DDD, CleanArchitecture対応)」
4. 「Microsoft Build 2024の新発表10選【GPT-4o / Copilot / Phi】」
5. 「CSS を使って HTML を Markdown に復元してみよう！」
今日も盛りだくさんの内容でしたね。詳しい内容はショーノートに書いてありますので、ぜひチェックしてください。そして、番組の感想や質問などがあれば、ぜひおたよりを送ってくださいね。
それでは、次回もお楽しみに！マイクでした。さようなら！
---