re:Invent 2023: AWSが提供するToolkitとCodeWhispererで.NET開発の生産性向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Boost your productivity with AWS Toolkits and Amazon CodeWhisperer (XNT304)
この動画では、AWS Toolkit for Visual StudioとAmazon CodeWhispererを使って、.NET開発者の生産性を向上させる方法を学べます。サーバーレスアプリケーションの作成からデプロイまでの全プロセスを30分で体験できます。AWS SDKの3つの使用方法を知るCodeWhispererの驚くべき能力や、IDEを離れずにAWSリソースを操作できるToolkitの便利さが分かります。生産性が27%向上し、タスク完了が57%速くなるという具体的な効果も紹介されています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS Toolkitと Amazon CodeWhispererによる.NET開発者の生産性向上
みなさん、こんにちは。今日はいかがお過ごしですか？昨晩のPeterのキーノートと今朝のAdamのキーノートで元気をもらえたことと思います。素晴らしい内容でしたね。そして、これからのSwamiとWernerのキーノートにもぜひご期待ください。きっと素晴らしい内容になるはずです。
まず、みなさんに質問させてください。「もっと多くのことをこなさなければならないのに、リソースも時間も増えない」という経験をしたことがある方はどれくらいいらっしゃいますか？はい、そうですね。私だけではないようです。みなさんも同じ経験をされているのですね。だからこそ、生産性や開発者の生産性についてよく耳にするのでしょう。このセッションでは、AWS ToolkitとAmazon CodeWhispererを使って、.NET開発者としてより生産的になる方法を学んでいただきます。
本日は、素晴らしい同僚のChristopher Christouさんと一緒です。彼はAWS Toolkitチームのソフトウェア開発エンジニアIIIです。彼のチームは、Visual StudioとRiderのAWS Toolkitの素晴らしい機能すべてを担当しています。もちろん、Visual StudioとRiderのAWS Toolkitで経験する可能性のあるバグや問題にも責任を持っています。いや、冗談ですよ。私は開発者アドボケートとしての仕事を真剣に行っています。みなさんが素晴らしい体験ができるよう、AWS Toolkitを徹底的に使用しています。
開発者の喜びとフロー状態：生産性の本質
これは次のトピックにつながります。私は.NET開発者です。毎日コーディングをしていますが、みなさんはどうでしょうか？私は生産性だけでなく、喜びのために人生を最適化しています。喜びは、自分の仕事が成果に結びつくのを見ることだけでなく、日々の小さな問題解決や、課題の修正、同僚との共有からも生まれます。本当に難しい問題を解決した初めての経験、あるいはそのような経験を覚えていますか？私は覚えています。
ヨーロッパのコア貸付会社で働いていたとき、私は財務バックオフィスのテックリーダーでした。毎月、すべての財務データを処理する重要なジョブが実行されていました。このジョブは、スタートアップにとって非常に重要でした。なぜなら、翌月にどれだけの住宅ローンを提供できるかを決定していたからです。ある日、悪意のある攻撃を受けました。攻撃者はジョブを少し変更しました。一見して明らかではありませんでしたが、会社にとっては致命的な変更でした。幸いなことに、財務チームの誰かがデータに問題があることに気づき、私たちに警告してくれたので、調査を開始しました。
私は2人の同僚と24時間を過ごしました。はい、厳しい一夜でしたが、問題を見つけて修正し、会社を前進させることだけに集中しました。私たちは方法論的にバックアップを使って時間を遡り、何が起こったのかを確認しました。問題を特定し、いつ発生したのか、そしてどう修正すべきかを見つけ出しました。修正が完了したとき、私たちはとても嬉しかったです。素晴らしい経験でした。ある意味で、このスタートアップを救ったのです。会社にとって本当に危機的な状況になり得たからです。これこそが、私たちがこの種の役割で働いている理由だと思います。この喜びの感覚を味わい、経験するためです。
ハンガリー系アメリカ人の心理学者、Mihaly Csikszentmihalyiが「flow」という概念を開発しました。これは、何かに没頭しているときの状態で、周りの世界が存在しなくなるほど夢中になっている状態です。時間が止まったかのように感じ、ある意味でEinsteinの相対性理論を実際に体験しているようで、時間が飛ぶように過ぎていきます。
この心理学者は、flowの概念を説明し、タスクを遂行する際に感じる感情の次元を示すダイアグラムを開発しました。横軸には、取り組んでいるタスクに必要なスキルレベルがあります。
縦軸には、タスクの難易度があります。非常に難しいタスクに取り組んでいるが、そのタスクに対するスキルが低い場合、不安を感じます。逆に、高いスキルを持っていて、非常に難しいタスクを解決する場合、flowの状態に達することができます。そこでは、自分の最高の能力が要求され、成功して結果を出せるため、本当に楽しんで作業できます。これがflowの状態であり、それに伴う喜びを経験する場所です。
AWS Toolkitを活用したサーバーレスアプリケーション開発の実践
しかし、私の意見では、このモデルには常に存在する重要な要素が欠けています。それは摩擦です。創造的な作業における、あらゆる厄介な中断のことです。私たちの邪魔をして速度を落とす、あの厄介なものたちです。とてもよくあることなので、もはや気づかないこともあります。肩を叩かれたり、Slackのメッセージが来たり、またはもう一つの急な会議かもしれません。カリフォルニア大学アーバイン校でデジタルな気散じを研究しているGloria Markによると、中断後に元のタスクに戻るまでに平均約25分かかるそうです。そして、複数の研究がこれを裏付けています。
私の意見では、多くの場合、このフリクションは、フローの可能性を阻害するツールやプロセスにおける無限の小さな不満でもあります。UIが直感的でなく、ドキュメントが理解しにくく、これらすべてが私が「成功までの平均時間」と呼ぶものに影響を与えます。プロジェクトを開始してから最初の成功を得るまでにどれくらい時間がかかるでしょうか？この指標は生産性に関するものではなく、あなたが経験しているフリクションのレベルを測定するものです。そして、AWSでは、このフリクションを排除したいと考えています。
私は、昨年のre:Inventで、AWSの開発者体験をどこに持っていきたいかというビジョンを描いた、Generative BuildersのVPであるAdam Seligmanに触発されました。彼は3つのことを考え出し、誰かがすでにそれを俳句にしています：「すべての開発者とすべての開発チームのための素晴らしいフロー」。ここには3つの重要な部分があります。1つ目は素晴らしいフローについてで、フリクションを取り除き、あなたに適した素晴らしい開発者体験を提供することです。2つ目のポイントは、私たちが多くの異なるタイプの開発者にサービスを提供しており、世界中のさらに多くの開発者にサービスを提供したいということです。彼らには異なる好み、スキルがあり、異なる分野やプロジェクトで働いています。最後に、開発者はみなチームで働いており、誰もが包括的に感じるべきです。
今日は、素晴らしいフローと、開発者がお気に入りのIDEで作業しながらフローを維持するために必要なものに焦点を当てたいと思います。 あなたたちが私たちに伝えてくれたのは、豊富なIDEサポートが欲しいということです。コーディングをしているときに、AWSコンソールに行って使いたいDynamoDBテーブルのARNや名前などの情報を取得するためにIDEを離れたくありません。これをIDEに直接入れたいのです。 また、あなたたちは、より速く、かつ安全にコードを書きたいと言っています。なぜなら、常により多くのことをする必要があるからです。
最後に、あなたたちはサーバーレスアプリケーションを開発している場合、特にローカルで簡単にアプリケーションをデバッグできるようにしたいと言っています。小さな変更をテストするためにAWSコンテンツとの間で頻繁にやり取りをしたくありません。これがまさにAWS Toolkitsが目指しているものであり、私たちはそれがあなたの役に立つと単に言うだけでなく、それを示したいと思います。
AWS Toolkitによるプロジェクト作成とLambda関数の実装
今日、私たちは一緒に住宅ローンサービスを構築する任務を負っています。いつものように、最初のAPIを昨日までに提供する必要があるので、非常に生産的でなければなりません。このAPIは、ローン金額、年間金利、ローン期間を与えられた場合の月々のローン支払額を計算します。しかし、デモに飛び込む前に、私はよくAWSの.NETコミュニティへのコミットメントについて質問されます。AWS Toolkitの物語と歴史は、私にとって、AWSの.NETコミュニティへの長期的なコミットメントの証拠です。そこで、Chris、この歴史についてもっと共有してほしいと思います。
はい、その通りです。AWS Toolkit for Visual Studio は、AWS で動作するシステムを開発する際に生産性を向上させる機能を提供するプラグインです。 AWS Toolkit for Visual Studio は、AWS SDK for .NET を広範に活用しています。そこから私たちの話が始まります。ところで、AWS SDK for .NET がどれくらい前からあるかご存知の方はいますか？挙手してみましょう。この SDK が最初にリリースされたのが過去2年以内だと思う方は手を挙げてください。はい、もう少し前からありますね。では、AWS SDK for .NET が最初にリリースされたのが過去10年以内だと思う方は手を挙げてください。数人いますね。実は14年前の2009年でした。どのボタンですか？
緑のボタンですね。緑のボタン、了解しました。チームが SDK を開発している間、彼らは非常に反復的な多くのタスクをこなさなければなりませんでした。AWS Console にログインし、状態を変更し、多くのリソースを更新する必要がありました。そして、これらのタスクを自動化し、より簡単に実行できるようにすれば、生産性が向上すると気づきました。これが最初の疑問につながりました：「これらの生産性向上機能を作れるなら、それらを集めて共有するのに適した場所はどこだろうか？」
一方で、彼らは別の疑問に直面しました：皆さんのような .NET 開発者に AWS 上の .NET の認知度を高めるには、どうすればいいだろうか？開発時間の多くを Visual Studio で過ごしているという事実は、Visual Studio がこれら両方の疑問に対する理想的な候補、あるいは適切な解決策であることを意味していました。これが Visual Studio 拡張機能として知られる AWS Toolkit for Visual Studio の誕生につながりました。
これは2年後の2011年にリリースされ、初期の機能セットの一部として EC2 インスタンスの作成と管理が可能でした。また、私のお気に入りの機能の1つも含まれています。数回クリックするだけで、EC2 インスタンスに SSH 接続できるのです。この機能を初めて試したとき、François が話していた開発者の喜びを感じました。IP アドレスを調べる必要もなく、数回クリックするだけでターミナルにアクセスでき、素晴らしかったです。
それ以来、私たちは最新バージョンの Visual Studio（現在は Visual Studio 2022）のサポートを継続的に維持し、最近ではさらに新しい ARM64 バージョンの Visual Studio のサポートも追加しました。AWS SDK for .NET と AWS Toolkit for Visual Studio の長寿命性は、AWS の .NET コミュニティへの長期的なコミットメントを示す2つの例に過ぎません。Toolkit がどのように誕生したかについて少し話しましたが、これを使ってこの住宅ローンサービスを作成していきます。では、私が準備している間に、住宅ローンサービスについてもう少し詳しく教えていただけますか？
はい、もちろんです。 このモーゲージサービスはサーバーレスアプリケーションとして構築します。フロントエンドにはAPI Gatewayを配置します。このAPI GatewayはGETリクエストを受け取ります。これらのGETリクエストでは、ローン金額、年間金利、期間（年数）をクエリストリングパラメータとして取得します。各GETリクエストに対して、API GatewayはAWS Lambda関数（.NETで記述）をトリガーします。このAWS Lambda関数はパラメータを処理し、月々のローン支払額を計算し、両方のデータをAmazon DynamoDBテーブルに保存します。
その後、関数は結果を返します。これが今日のデモで構築したいものです。
Amazon CodeWhispererを活用したビジネスロジックの実装
.NETシステムを書き始める準備ができたら、新しいプロジェクトを作成することから始めます。比喩的に言えば、白紙の状態から始めるようなものです。いくつかの疑問が浮かびます。どのプロジェクトタイプが適切なのか？そのプロジェクトのメインエントリーポイントはどこにあり、どのような形なのか？システムに必要な依存関係はあるのか？そして、クラウドにデプロイするためにどのように設定すればいいのか？AWS Toolkitには、これらの疑問を軽減または解消するのに役立つプロジェクトテンプレートがあります。
新規プロジェクトダイアログから、プラットフォームをAWSに絞り込むと、Toolkitが提供するオプションが表示されます。 今日作成するモーゲージサービスには、追加のAWSリソースも関連付けられているので、サーバーレスアプリケーションプロジェクトを作成します。 プロジェクトに名前を付けます。テンプレート内には、Toolkitが様々なユースケースをサポートする複数のブループリントを提供しています。今日は、モーゲージサービスをゼロから構築するので、 空のブループリントから始めます。
これは完全に空というわけではありません。プロジェクトには、独自のモーゲージシステムの作成に集中できるよう、必要最小限の設定が用意されています。また、後ほど説明するLambda Annotation Frameworkを基盤としています。プロジェクトが作成されたので、簡単に概要を説明しましょう。まず、このserverlessテンプレートファイルから始めます。これはサーバーレスアプリケーションモデルテンプレートで、システムのインフラストラクチャをコードで表現したものです。これをAWSアカウントにデプロイすると、このファイルで定義された複数のリソースが作成され、アプリケーションが構成されます。
ここに注目すべき点がいくつかあります。 Lambda関数がリソース上で定義され作成されることがわかります。そして、その関数が実行するコードへの参照があり、これはこのプロジェクト内のコードを指しています。これについては後ほど見ていきます。 そして、これらの数行が、Françoisが言及していたAPI Gatewayリソースを作成する役割を果たしています。
Functions.csに移ると、これがシステムのメインエントリーポイントです。これがLambda関数が実行するものです。ここには単一のクラスがあり、そのクラスには単一の関数があります。 現時点では、その関数は単にLambdaロガーにメッセージを書き込むだけの簡単なものです。この関数にはいくつかの属性がついていますが、これが興味深い部分です。これはLambda Annotation Frameworkの一部です。LambdaFunction属性は、アカウント内でそのLambda関数を定義し、その動作を設定する役割を果たします。RestApi属性は、そのHTTPエンドポイント、つまりAPI Gatewayリソースを作成する役割を果たします。
これらを組み合わせると、この場所にGETベースのリクエストが来たら、このLambda関数を実行し、ここにあるこのコードを実行するということを意味しています。通常、Lambda関数を実装する際、Lambdaサービスはイベントペイロードを提供し、そのペイロードからデータをマーシャリングし、ビジネスロジックに接続する責任があります。しかし、ここではビジネスロジックだけがあり、マーシャリングなどは一切ありません。これがLambda Annotation Frameworkの本当にクールな側面の一つです。
舞台裏では、コードジェネレーターを使用していくつかのことを行っています。プロジェクトを書いたり変更したりする際、これはserverlessテンプレートファイルをそれらのリソース定義で更新し、また詳細をマーシャリングするボイラープレートコードも書いています。それを簡単に見てみましょう。依存関係を見ると、このプロジェクトですでに参照されているLambda関連のNuGetパッケージがいくつかあることがわかります。その中の一つがここにあるLambda Annotationsパッケージです。 これにより、プロジェクトに一連のアナライザーが提供されます。これを開くことができます。これが舞台裏で生成されるコードで、あなたが心配する必要のないものです。これはかなりクールですね。
これが作成されるプロジェクトの簡単なツアーです。もうすぐモーゲージサービスの作成を始められますが、その前に、このプロジェクトがそのままで動作することを確認したいと思います。ローカルで実行してみます。これによってテストハーネスが起動します。これについては、Françoisが数分後にもう少し詳しく説明します。 ここでは、LambdaサービスがAPI Gatewayイベントを送信し、GETベースのリクエストを模倣するシミュレーションを行います。これを実行してみましょう。 すると、Lambda関数が確かにLambdaロガーにメッセージを書き込んでいることがわかります。これで、このコードをチェックインしたいと思います。
CodeWhispererによるAWS SDK for .NETの効率的な活用
François がこれから実装を始めます。
コードの公開を忘れないでくださいね。さて、ここでラップトップを切り替えます。
では、まずコードをチェックアウトします。必要なのはコードを取得することだけで、そうすれば業務ロジックの実装を始められます。よし、大丈夫ですね。 私たちは CodeCatalyst Git リポジトリを使ってコードを共有しています。さて、これから業務ロジックを実装したいと思います。もちろん、Lambda のボイラープレートコードの中に 業務ロジックを実装したくはありませんので、新しいクラス、新しいファイルを作成します。MonthlyLoanPaymentService と呼ぶことにしましょう。
まず、インターフェースを定義します。 IMonthlyLoanPaymentService と呼ぶことにして、calculate monthly payment メソッドを定義します。 このメソッドは decimal を返します。これは金融の値ですね。パラメータとしてローン金額を取ります。 これも decimal 型です。それから年利 と期間（年数）も必要ですね。はい、これで実装するだけです。
あれ、問題が。Chris、これの計算方法知ってる？ ないか。会場の誰か知ってますか？ じゃあ、友達に聞く必要がありそうですね。そう、新しい友達、Visual Studio に組み込まれた AI コーディング・コンパニオンのことです。Visual Studio に組み込まれた CodeWhisperer のことですね。どうやら Amazon CodeWhisperer はこの計算方法を知っているようです。calculate monthly payment メソッドの実装方法を提案してくれていますね。素晴らしい！ IDE の中で Amazon CodeWhisperer が使えるなんて、驚きじゃありませんか？
プログラマーなら誰でもそうですが、私もいつもコードを再利用します。ここでは、数値の変換に関して小さなミスがありました。コンテキストが不足していたため、年利を百分率として与えていると勘違いして100で割っていますが、私は百分率ではなく小数で与えたいので、これを削除します。では、CodeWhispererがもう少しコーディングをできるか見てみましょう。というのも、コードにコメントを付ける必要があるからです。私はこれが得意ではないので、CodeWhispererが助けてくれるか見てみましょう。
この部分を削除しましょう。CodeWhispererは日曜日にVisual Studioでプレビューモードでリリースされたばかりです。おや、コードコメントの書き方を知っていますね。ここでCodeWhispererを起動しています。素晴らしいですね。抑制されたメッセージまでありました。これらは削除できます。本当に素晴らしいです。このように、数分でビジネスロジックを実装できました。
AWS Toolkitを使用したサーバーレスアプリケーションのデプロイ
そこに到達するには、Code Editorウィンドウの下部にあるCodeWhispererアイコンをクリックして、コンテキストメニューを表示します。AIコーディングアシスタントには2つの考え方があります：自動提案を好む人と、必要なときにAIコーディングアシスタントを起動したい人です。どちらを好むかは、あなた次第です。前述したように、私たち全員が異なるので、これは個人的な選択です。
ここでビジネスロジックが定義されたので、これを依存性注入メカニズムに追加したいと思います。シングルトンを追加しましょう...これで完了です。では、Functions.csファイルに戻りましょう。私がやりたいのは、privateで読み取り専用のIMonthlyLoanPayment属性を持つことです。CodeWhispererが私のコンストラクタ関数を書き直すのを手伝ってくれるか見てみましょう。はい、コンストラクタ関数の書き直しを手伝ってくれました。素晴らしいですね。これをここに追加します。手伝ってくれて良かったです。
さて、AIコーディングアシスタントはAIですから、魔法ではありません。あなたが何をしたいのかを理解してもらうには、コンテキストを提供する必要があります。私は月々のローン支払いサービスを使って、月々のローン支払いを計算したいのです。ここで、「これは月々のローン支払いを計算します。ローン金額をdecimal型で、年利をdouble型で、期間を年単位でint型で与えます。」と言えます。よし。後で設定方法をお見せするために、パスを変更しておきます。
では、CodeWhispererがこのメソッドを書き換えるのに役立つかどうか見てみましょう。トリガーをかけると、良い提案が出てきました。見せましょう。API gatewayのプロパティリクエストを使用し、QueryStringParameters属性を使ってオブジェクトから必要なパラメータを取得することを提案しています。しかし、私はこの方法を使いたくありません。そこで、CodeWhispererにもう少し文脈を提供して、私が何をしたいのか、どのメソッドを使いたいのかを理解させましょう。
今度は、FromQuery属性を使いたいということを理解してくれました。これは.NET Lambda Annotation Frameworkでパラメータを定義する新しい方法です。これを試してみましょう。うまくいきました。完成させるだけで、それで終わりです。ビジネスロジックを実装してLambda関数に組み込んだので、ローカルでテストしてみましょう。Mock Lambda Test Toolを実行します。
ここでは、先ほどChrisがやったように、API gateway AWS proxyイベントを使ってシミュレーションします。パスを変更したいと思います。例えば、monthly paymentsとしましょう。GETメソッドで、ローン金額を定義できます。例えば、10,000ドルを借りたいとします。年間金利については、アメリカのことはよく分かりませんが、フランスでは4.5%が良い金利でしょう。借入期間は5年としましょう。テストするたびにこれらのパラメータを全部入力し直したくありません。
そこで、後で再利用できるようにリクエストを保存できます。では実行してみましょう。ここで結果がBase64でエンコードされています。オブジェクトを変更して、月々の支払額を匿名オブジェクトとして返すことができます。もう一度実行してみると、結果が計算されているのが分かります。リクエストを再利用して実行してみましょう。ここでログと結果が見えます。匿名オブジェクトが自動的にシリアライズされ、月々の支払額は186となっています。これが正しい数字です。計算方法は分からないと言いましたが、実は以前コアレンディング企業で働いていたので、実際には計算方法を知っています。これはかなりクールですね。
開発環境でのトラブルシューティングとAWS Explorerの活用
次に、このデータをAmazon DynamoDBテーブルに保存したいと思います。そのためには、DynamoDBのNuGetパッケージが必要です。しかし、ローカルでテストしてデバッグしたいことを忘れないでください。ここで、AWS Explorerビューを見てみましょう。このエクスプローラービューはAWS Toolkitに付属しています。ローカルのDynamoDBテーブルを閲覧できます。例えば、Dockerコンテナを通じてAmazon DynamoDBテーブルをローカルで実行し、ローカルでテストできます。ローカルで動作しているDynamoDBテーブルインスタンスがあり、ローカルでテストできます。これを使うには、ちょっとしたコツがあります。Amazon DynamoDBクライアントに、AWSではなくローカルに接続する必要があることを知らせたいのです。
どうやってこれを行うのでしょうか？デバッグモードの場合、単に入力するだけです。 デバッグモードの場合、依存性注入メカニズムで行いたいのは、Amazon DynamoDB clientを使用することです。 ただし、このAmazon DynamoDB clientには特定の設定が必要です。 サービスURLを定義して、「ローカルインスタンスに接続してください」と指示したいのです。 デバッグモードでない場合は、AWSアカウントにデプロイされているということになります。 その場合は単にAmazon DynamoDBを使用します。さらにもう一歩進めて、「実際には、Amazon DynamoDB interfaceを使用します。このインターフェースには、既に設定したものを使用します」と指定します。これは少し技巧的ですが、これが実現方法です。
これにより、依存性注入メカニズムが設定され、開発モードの時はローカルでAmazon DynamoDB clientを使用し、デプロイ時にはAWSアカウントを使用するようになります。では、Functions.csファイルに戻って、Amazon CodeWhispererがAmazon DynamoDBの使用方法や学習をどのようにサポートしてくれるか見てみましょう。Amazon DynamoDBに少しコンテキストを提供する必要があります。あれ、助けてくれないですね？これらの名前空間を使用したいのです。
IAmazonDynamoDBのような、もう一つのprivate read-only属性を持つことになります。Amazon CodeWhispererがコンストラクタの書き直しを手伝ってくれるか見てみましょう。 はい、コンストラクタの書き直しを手伝ってくれました。さて、ここでコンテキストを提供したいと思います。月々の支払い、ローン金額、年間金利、期間（年単位）をAmazon DynamoDBテーブルに入れます。テーブル名はMonthlyPaymentで、一意の識別子としてIdを使用します。また、例外をキャッチして例外メッセージをログに記録します。CodeWhispererが何を提案するか見てみましょう。
tryブロックから始まっていますね。なかなかいいですね。 APIの使い方を知っているようで、印象的です。また、例外メッセージをログに記録したいという私の意図も理解しています。ここでは、Amazon DynamoDBの低レベルAPIを使ってデータを保存する方法を知っているようです。では、実際に動作するか簡単に確認してみましょう。はい、動作しています。 OK、データがDynamoDBテーブルに入りました。 少し心配だったのは、チェックし忘れたことがあったのですが、それも代わりにやってくれています。ここではPutItemAsyncメソッドを使用していますが、Getメソッドはawaitメソッドではないので、賢くもWaitメソッドを使用して問題が発生しないようにしてくれています。
しかし、このプレゼンテーションの準備中に同僚のJames Isamが「それはあまり良い例ではありませんね。低レベルAPIを使っていますよ」と言ってきました。そこで私は「じゃあ、CodeWhispererが本当に.NET用のAWS SDKを知っているかどうか見てみましょう」と思いました。.NET SDKを使ってAmazon DynamoDBテーブルにデータを保存する方法は他に2つあるからです。ここでは低レベルAPIを使っていますが、他に2つのモデルがあります：ドキュメントモデルとオブジェクト永続化モデルです。CodeWhispererがドキュメントモデルを知っているか見てみましょう。名前空間を変更して、やりたいことのコンテキストを少し与えます。そして、トリガーを引いて、何を提案するか見てみましょう。
Lambda関数の権限設定とDynamoDBテーブルの作成
どうやら理解しているようですね...はい。申し訳ありません。ええ、小さなミスをしてしまいました。PutItemメソッドを使いたくなかったようです。まあ、それはそれで良かったのですが、このメソッドは非同期メソッドではありません。そしてオブジェクトのメソッドはPutItemだと思います。そのため、少し矛盾があったので、PutItemsではなくPutItemと書いたのです。
時々、プログラマーの判断が少し外れることがあるので、レビューする必要があります。ここで私がやりたいのは、これを書き込み可能なメソッドに変換して、ただ「ねえ、ちょっと...」と言うことです。試してみましょう。結果はここにあります。テーブルに結果があるか見てみましょう。テーブルをチェックしましょう。さて、オブジェクト永続化モデルを知っているかどうか見てみましょう。本当にチャレンジしたいですね。では、移動して、ここでもう一度namespaceを変更しましょう。
ここで提案されているのは、Amazon DynamoDBクライアントを渡してDynamoDBContextオブジェクトを作成し、SaveAsyncメソッドを使用することです。SaveAsyncメソッドでは、まだ存在しないMonthlyPaymentオブジェクトを使用しています。では、仕事を完了させるほど賢いかどうか見てみましょう。ここで、MonthlyPaymentオブジェクトには両方の属性が必要であることを知っており、Idプロパティに[DynamoDBHashKey]属性を付けて、これがハッシュキーであることをシステムに知らせる必要があります。[DynamoDBTable]属性を付け忘れていましたが、CodeWhispererを再度トリガーすると、それに気づきます。あ、何か見落としていました。では、うまくいくか見てみましょう。どこかでミスをしてしまいました。ああ、そうですね、もちろん。もう一度やってみましょう。はい、実行しましょう。まだ同じ結果です。スキャンしてみましょう。データがあります。
今見たのは、CodeWhispererがAWS SDK for .NETを使用してDynamoDBテーブルにデータを保存する3つの方法を知っているということです。これは本当に素晴らしいことです。これこそがまさにAmazon CodeWhispererの約束なのです。AWSを使用する際には、最高のAIコーディング・コンパニオンです。C#コード、Javaコードなど、あなたのコードからAWSを使用したい場合、Amazon CodeWhispererは最高のAIコーディング・コンパニオンです。なぜなら、AWS SDKを完璧に理解しているからです。これが私たちが今見たことです。最後にもう一つやりたいことがあります...実際のデプロイメントでは、ここを変更してHTTPを入れたいと思います。はい、そしてここではHTTP結果を返したいと思います。Internal server errorメッセージです。つまり、HTTP resultクラスですね。ここにメッセージを管理するためのヘルパークラスがあります。そして、ここに例外メッセージを追加したいと思います。そしてここで返したいのはHTTP resultsです。OKの結果です。そして、ここに私のオブジェクトがあります。これで準備ができました。では、これらの変更をすべてコミットして、Chrisに任せましょう。すべて良好です。プッシュしています。はい、プッシュされました。さて、Chris、このステーションは今あなたのものです。
私たちが今見たことを覚えておいてください。これは本当に、CodeWhispererが知っているということについてです。想像してみてください。DynamoDBのAWS SDKを使用する3つの方法を知っているのです。つまり、AWS SDKの使用方法を本当にスピードアップするのに役立ちます。これはCode Explorerのためであり、DynamoDBのためでもありますが、他のSDK、他のAWSサービスにも当てはまります。そして、心に留めておいてほしいメッセージは、すべてはコンテキストに関するものだということです。つまり、CodeWhispererや一般的なAIコーディング・コンパニオンに提供しているコンテキストについて考える必要があるのです。
はい、Chris、お願いします。
AWS Toolkitによるエンドツーエンドの開発プロセス
さて、システムを開発し、チームがその実装に満足したら、次は「自分のコンピューターでは動作する」という段階に到達します。そこで、本番環境にデプロイした際に期待通りに動作するという確信を得たいところです。そのための良い方法は、まず開発環境にデプロイすることです。「でも、どうやって環境に持っていけばいいの？プログラムをzip圧縮してどこかにアップロードする必要があるの？」と思うかもしれません。ここでは、AWS Toolkitを使って住宅ローンサービスを開発環境に持ち込む方法を紹介し、それがいかに簡単にできるかをお見せします。
さて、Françoisの変更内容を同期したところです。すべてが揃っているか確認しましょう。ローン支払い？はい、大丈夫です。AWS Toolkitには、さまざまなプロジェクトタイプに対応したデプロイメントサポートがあります。通常、デプロイしたいプロジェクトのコンテキストメニューのSolution Explorerで見つけることができます。 今回の場合、Lambda関数とサーバーレステンプレートファイルを含むプロジェクトがあります。 そのため、ToolkitはこれをCloudFormationにデプロイする方法を知っています。ここでいくつかの詳細を入力し、デプロイメントを開始しましょう。
Toolkitが行うことは... おや、これは何でしょう？ パブリッシュに失敗しました。リビルドしてみましょう。おっと。もう一度試してみます。 だめですね。大丈夫です、デモビデオに切り替えましょう。時には予期せぬことが起こりますが、準備しておくことができます。
Toolkitは、システムをコンパイルし、パッケージ化し、そのパッケージを開発環境にアップロードします。そして、そのパッケージをCloudFormationテンプレートと共にCloudFormationサービスに渡します。その間、CloudFormationはこのCloudFormationスタックの作成を進め、サーバーレステンプレートファイルに関連付けられたすべてのリソースを作成し続けます。デプロイが完了したので、ここに別のスタックがあります。同じAWS Explorerから見ることができます。
ここから、アカウント内のリソースとやり取りできる様々なサービスタイプがあります。その中の1つがCloudFormationスタックです。この場合、開発環境で稼働している住宅ローンサービスがあります。そこで、試してみたいと思います。「住宅ローンの支払額を確認できるかな？」と。このURLを使って、Visual Studioの組み込みサポートであるHTTPファイルを通して実行してみましょう。これにより、ファイルから直接RESTベースのリクエストを行うことができます。
URLを貼り付けて、クエリパラメータが正しく設定されているか確認します。私の場合、今日の朝に不動産リストを見ていて、40万ドルの平屋の家を見つけました。25年ローンで金利6%で借りられるとしましょう。住宅ローンの支払額がいくらになるか見てみましょう。すると、500 Internal Server Errorが出ました。Françoisのシステムではこのエラーは出ていませんでしたね。
CodeWhispererの生産性向上効果と内部機能
Françoisも自分のマシンでは動作しないと言っていました。クラウドで実行しているときに期待通りの結果が得られない場合は、アプリケーションログとアプリケーションの状態を確認する必要があります。Lambda関数のログを確認して、トラブルシューティングする方法をお見せしましょう。AWS Explorerに戻って、デプロイメントスタックに対応するLambda関数を探します。
このパネルはとても便利です。いくつかの詳細が表示され、関数の動作を変更したり、ペイロードを提供して一回限りの実行を行ったりすることもできます。今日はトラブルシューティングが目的なので、ログを見てみましょう。これにより、Lambda関数に対応するCloudWatchロググループが表示されます。今日実行したばかりなので、このCloudWatchログストリームを読み込んでみましょう。すると、エラーメッセージが表示されています。もう少し詳しく見てみましょう。Lambda関数がDynamoDBテーブルとやり取りする権限がないと言っています。
Françoisが言っていたように、いつも権限の問題ですね。でも、IDEを離れる必要はありませんでした。無限の可能性から始まって、権限ポリシーの問題にまで絞り込むことができました。これで変更を加えることができますね。Lambda Annotation Frameworkとそれらの属性に戻りましょう。Lambda関数の動作を変更できると言いましたよね？ここでポリシーを追加できます。DynamoDBと通信する権限をこの関数に付与しましょう。面白いことに、Amazon CodeWhispererが同じポリシーを提案してくれていますね。
さて、先ほど申し上げたように、Lambda Annotation Frameworkがバックグラウンドでサーバーレステンプレートを更新するのですが、ここで実際にファイルが更新され、そのポリシーが適用されているのが確認できます。 では、これをクラウドにデプロイしていきましょう。開発環境を更新するわけですが、ここではデプロイの様子を動画でお見せします。 さて、すでにデプロイは完了しています。ここに別のスタックがありますね。このURLをコピーして、HTTPファイルに貼り付けましょう。では、これを実行してみましょう。
おっと、うまくいかないようですね。あ、そうか。もう一つ忘れていたことがありました。François氏がDynamoDBテーブルのローカルコピーでプロトタイピングしていたのを覚えていますか？開発環境にもDynamoDBテーブルが必要なんです。ここからテーブル名「MonthlyPayment」をコピーしましょう。AWS Explorerを使えば、いくつかのサービスについてプロトタイプリソースを作成できるんです。 DynamoDBもその一つなので、このテーブルを開発環境に追加しましょう。
実装に満足したら、 インフラストラクチャ・アズ・コードの一部としてコード化する必要があります。ただ、反復作業をしながら調整している段階では、 このようにすばやく反復ループに戻って進捗を出せるのが素晴らしいですね。さて、これで住宅ローンの支払いが約2,577ドルになることがわかりました。こうして最初から最後まで、IDEを離れることなく、いくつかの問題を解決し、満足のいく実装にたどり着きました。あとはリリースするだけですね。
まとめとAWS Toolkitの活用方法
François氏も同意して、「やりましたね」と言っています。およそ30分で目標を達成しました。AWS Toolkit for Visual Studio Codeを使用して、サーバーレスアプリケーションの作成、デバッグ、デプロイの全プロセスを経験し、AWSサービスの開発ワークフローがいかに簡素化されるかを示しました。では、見てきたことをまとめましょう。
このモーゲージAPIをデプロイしました。 AWSリソースを使用したプロジェクトのブートストラップに使えるたくさんのテンプレートを含む、スタートアップ体験を見てきました。AWS Explorerを使えば、IDE内からAWSサービスにアクセスし、CloudWatchログの取得などの操作ができることも分かりました。 Mock Lambdaツールのおかげで、AWS Lambda関数をローカルでテストしデバッグできます。 サーバーレステンプレートファイルを使ってインフラストラクチャ・アズ・コードを構築できますし、AWS Toolkitを使ってCloudFormationファイルを書くこともできます。AWSアカウントへのデプロイやAmazon CloudWatchログへのアクセスも可能です。
これは Toolkit のおかげでかなりクールですね。 さらに、Visual Studio 内の Toolkit を使えば、AI コーディングアシスタントである Amazon CodeWhisperer にアクセスできます。CodeWhisperer はリアルタイムで、あるいはトリガーに応じてコード提案を生成します。CodeWhisperer には脆弱性を見つける機能もあります。現在、この統合はプレビュー段階なので、この機能はまだ Visual Studio では利用できませんが、VS Code や JetBrains IDE では利用可能です。オープンソースのトレーニングデータに似たコードをフラグ付けするので、提案されたコードがオープンソースのトレーニングデータに似ている場合、「このコードはおそらくオープンソースで、このライセンスの下にあります」と知らせてくれます。そのため、そのコードを自分のコードに組み込むかどうかを判断できます。
生産性チャレンジを実施したところ、CodeWhisperer を使用した参加者は、使用しなかった参加者と比べてタスクを成功裏に完了する可能性が 27% 高く、平均して 57% 速くタスクを完了しました。これは、CodeWhisperer による生産性向上の大まかな目安となります。では Chris さん、内部的にどのように機能するか簡単に見てみましょうか？
早速、どのように使い始めるかをお見せしましょう。こちらに切り替えます。はい、CodeWhisperer の使用方法をご覧いただきましたが、皆さんも試すことができます。最新バージョンの Toolkit を入手し、IAM Identity Center 接続か AWS Builder ID 接続のいずれかが必要です。接続が完了すれば、Toolkit には入門パネルがあり、ガイドに従って進めることができます。私は既に接続済みです。初回実行時には、接続詳細を入力するプロセスがあり、その後接続が完了します。これで試し始めることができます。ぜひ試してみて、体験についてフィードバックをお寄せください。
最後に、ぜひダウンロードして試していただき、フィードバックをお寄せください。左側の QR コードは AWS Toolkit for Visual Studio のダウンロード用で、右側の QR コードは GitHub リポジトリでフィードバックを提供するためのものです。ダウンロードして試していただき、体験を向上させるためにフィードバックをお寄せください。以上でこのセッションは終了です。ご清聴ありがとうございました。 セッションのアンケートにもぜひご協力ください。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion