前回投稿の記事、「TypeScriptとhonoで作るDI実践入門」ではHonoとTypescriptで型安全なDIを実践しました。
しかし、前回の実装では以下の課題がありました。
今回はこの課題に対して、@hono/zod-openapiを導入し解決していきます。
@hono/zod-openapiを導入することで、ZodスキーマからOpenAPIドキュメントを自動生成し、リクエスト/レスポンスのバリデーション、そしてルートハンドラーのコンテキストの型安全性を更に向上させることができます。
Honoは軽快さとパフォーマンスで注目を集める最近注目されているWebフレームワークです。
TypeScriptとの相性も抜群で、一度使うとその虜になる開発者も多いのではないでしょうか。
しかし、アプリケーションが成長するにつれて、コンポーネント間の依存関係は複雑になりがちです。
「このサービスってどこでインスタンス化してるんだっけ…？」
「依存関係が複雑でテストが書きにくい！」そんな経験はないでしょうか？
そこで採用したいのが、Honoアプリケーションをより堅牢でメンテナンスしやすく進化させる方法が、DI（依存性注入）の導入です。
特に、インフラ層（データアクセスなど）とアプリケーション層（ビジネスロジック）を明確に分離することで、コードの見通しが良くなり、テストの容易性も向上します。
本記事では、シンプルながら強力なDIライブラリ hono-simple-di を活用し、HonoとTypeScriptで疎結合な構成を最小限のステップで実現する方法を徹底解説します。
「DIってなんだか難しそう…」と感じている方に対しても、わかりやすく解説できるようにサンプルコードと合わせて解説しますので、お付き合いいただければと思います。
なぜDIが必要になるのかは過去記事の「ソフトウェアアーキテクチャの本質と依存関係の整理、あるいはinterfaceの正しい使い所について」を参考にしていただければと思います。
こんにちは！ピヨコです。
今注目のAIエージェント(Cline)とMCPサーバーをiOSアプリ開発に活用できないか試してみました！今回はiOSアプリのSimulatorでの動作確認テストについて解説していきます。
AIエージェントがSimulatorで動作確認してコード修正を行えることがゴールとなります。
※いずれも記事作成時点の情報です。最新の情報とは異なる古い情報の可能性がありますので、必ず最新情報をお確かめの上でご自身の責任で検証等を行ってください。
こんにちは、EMの本田です。今回はソフトウェアアーキテクチャの話を自分なりの理解で整理してみようと思います。
ソフトウェアアーキテクチャを設計する上で大切なことの一つは、変更しやすく、テストも行いやすいシステムを目指すことではないでしょうか。その本質は、突き詰めていくと「モジュール間の依存関係をいかに整理整頓するか」という点にたどり着くように思います。
この記事では、「依存関係の整理」がソフトウェア開発においてなぜこれほど大切なのか、そして、その実現に役立つ interface を、どのような場面で、どのように活用していくと効果的なのか、といったポイントに焦点を当ててみたいと思います。
説明の際には、オニオンアーキテクチャのレイヤー構造をイメージした図や、TypeScriptを用いたサンプルコードを参考にしますが、ここで触れる考え方は、多くのプログラミング言語や設計の進め方にも応用できるはずです。
皆様、こんにちは。h12oです。情報システムオフィスに所属して、プロダクトセキュリティの第二線を担当しています。
当社はSPIDERPLUSをより良いプロダクトにするため、新規開発、機能拡張、不具合修正など様々な変更を日々加えています。SPIDERPLUSは、常に変化するプロダクトともいえます。
変化は進歩のために必要不可欠ですが、同時に新たなセキュリティリスクを生み出すおそれもあります。
プロダクトの小さな変更が、予期せぬ大きな脆弱性に繋がる可能性も否定できません。
インシデントを予防し、プロダクトのセキュリティを担保することを目的として、脆弱性診断を実施している会社は多いと思います。
脆弱性診断は、インシデントを防ぎ、プロダクトのセキュリティを維持するために重要ですが、それだけに頼ると、トータルコストの増大や、他のセキュリティ対策の不備につながるおそれがあります。
セキュリティをより強固にするためには、より前段階でのセキュリティ確保が重要になります。
そこで、スパイダープラスでは、開発プロセスの比較的初期段階で行う「脅威分析」を、早期に組み込む取り組みを始めました。
本記事では、その背景や具体的な取り組みについてご紹介します。
こんにちは。
プロダクト運用部CREチームの大畑です。
唐突ですが先日、ITパスポートを受験しました。
エンジニアとして働き始めて丸10年近く経つのですが、「エンジニアなら受かって当然という風潮だけど本当か？」と思ったのが発端です。
当然（？）合格点取りました（けど、正式な結果がまだなので合格と言い切れないのが締まりませんが……）。
さておき。
今回はITパスポートの試験を受けてみたら意外と学びが多かった話をまとめてみたいと思います。
まずITパスポートという試験の概要について触れたいと思います。
続きを読む
今日もまた、モニターを食い入るように見つめ、気の遠くなるような手作業の波が押し寄せる。
はじめまして、takahashiです。
プロダクトのE2Eテスト（ユーザー視点でシステム全体を最初から最後まで全て操作するテスト）って大変ですよね。
何十、何百ものテストケースを一つ一つクリックしていく作業は最終的なプロダクトのクオリティを決定付ける最後のピースであり非常に大事なタスクです。
さて、世間はAIを利用した開発が一気に進んでおりますが、弊社も例外なく「GitHub Copilot」「Cursor」「CLINE」「Devin」などを取り入れています。
そんな中どうやら巷ではMCP（Model Context Protocol）という仕組みが隆盛であり、AIが様々な外部ツールやデータを操作するものらしいです。
特に最近Microsoftからオープンソースで提供された「Playwright MCP」に至っては非常にセンセーショナルで、生成AIに自然言語で指示を出すとブラウザを意のままに操り、アプリケーションを隅々まで理解して、最適なテストケースを自動で生成する事ができるというE2Eテストの救世主とも言える存在です。
大変なE2Eテストの一助になるべく、今回はCLINEを使用してPlaywright MCPを導入するまでの流れを簡単にご紹介したいと思います。
※CLINEとはVSCode上で動作するAIエージェントです
※今回はCLINEの導入方法は割愛させて頂きます（ 参考）
続きを読む