場所が自宅からかなり遠い幕張メッセだったので、参加するか少し迷いがあったのだが
２日目だけ参加することにした。
参加当日。
朝から雨。天気予報を見たら昼間になるにづれ、もっと酷くなるらしいので、少し早めに出ることにした。
朝食を作り終えたのが5:30だったけど
丁度、子供が起きてパパーと呼んでた。昨日、結構昼寝したせいかと。
家から出るギリギリまで子供にご飯食べさせてた。
東京駅は混んでた。子どもたちはいつもこんな感じで東京まで行っているのか。
俺はもう出来なさそう。
京葉線までの乗り換えは遠かったが、幸い道が分かりやすく案内されていた。
京葉線に乗ってtwitterを見たら、2日目は前日より人が少ないらしい。
クッションはともかく、お弁当は欲しい。
駅には結構人がいた。小雨の雨
会場の前で行列になっていた。管理画面にログインしてQRコードを見せるように案内があったが、パスワードが思い出せない。幸い事前に印刷した入場券のQRコードでなんとかなった。
少し焦った気分で早歩きで入場したら、丁度隣でクッションを配っていた。
残り少ない感じだったけど無事にゲットした。
今まで、パイプ椅子に座りっぱなしだとお尻が痛くなりがちだったので助かる。
基調講演 ビルダーとテクノロジーが加速する次のイノベーション（10:00 - 11:30）
いつも基調講演はAWSの宣伝みたいなものなので、あまり見たくなかった。
セッションを聴きながらmacを開いて会社のslackを見ようとしていたが、昔と同じくwifiがないことに気づいた。会社でモバイルwifiを借りるべきなのか。
そんな中、偶然見たJR東海の話は良かった。
サーバーレス開発のベストプラクティス ～より効果的に、より賢く使いこなすために～（11:50 - 12:30）
・サーバーレスの歴史。個人レベルではあるが、AWSを使い始めようとした頃からlambdaがサービスを始めていた
・コードを書くことは責任が伴うことになる。Lambdaから別のサービスに責務を移譲する
・単一責務の原則とLambda関数の単位
責務単位でLambdaを分けるべき
適切な粒度（グループ）で分ける
粒度が大きいと、パフォーマンス低下やIAM権限が大きくなる
粒度が小さいと運用は大変
参考：
https://zenn.dev/chihi_t/articles/79eccb4a8c53e6
https://dev.classmethod.jp/articles/aws-summit-tokyo-2024-session-report-aws-30/
プロンプトエンジニアリング入門（12:50 - 13:30）
AI関連セッションで、おそらく選び間違えたらしい。
丁度、弁当の整理券をもらえなかった人の為の弁当配りが13:00からだったので
並んで弁当をgetできた。
まい泉、というどこかで聞いた覚えがある店のカツサンドをもらった。
ちょっとしたミニセッション（PHP SDK関連）があったので弁当を食べながら見てた。
余っている時間はAWS認定者ラウンジに入ってみた。
入る時に認定資格を取得した際にもらったバッチを見せる必要があった。
欲しかった認定資格のシールは3枚もらえるはずだったが、SAAとCPFしかもらえなかった。意外とDeveloper Associate取った人が多かったのかな。
無料の飲み物をもらえて、電源とwifiが使えた。
ここでしばらく会社のslackを見ながらお仕事。
次からは基調講演を見る前にこちらへ直行しよう。
あと、初めてsnow ballの実物を見た。ブースの担当の方が「持ち上げてみても良いですよ〜」と言ってたので、持ち上げてみたが、だいぶ重かった。
参考：
https://iret.media/106679
同期という思い込み 世界は非同期で構成されている（13:50 - 14:30）
・仕様と実装の乖離が許されないAPI = 契約
契約は公開されるが、強制できるものではない
API 仕様書（Swaggerなど）が契約書になる
・同期的なAPIの課題
確か、依存関係の為、同時デプロイが必要だった
・結合度を実例で確認（非同期Event）
結合されていた各サービスを非同期Eventで繋ぐ
・非同期アーキテクチャによる応答の課題
非同期で処理されるAPIを呼んだ場合、どう処理結果を確認するかが課題になる
その時はpush処理で結果を渡すべき
・トラフィックの方向性
North-South Traffic
参考：
https://dev.classmethod.jp/articles/aws-summit-tokyo-2024-session-report-aws-56/
規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（14:50 - 15:30）
かなりよかった。今後、この人のセッションがあったらまた聴きたい
・マイクロサービスが良い選択肢ではない場合
開発メンバーが少数、の場合も考慮対象だった。
・マイクロサービスの利点としては、スケーリングを柔軟にできる、こともあった
参考：
https://dev.classmethod.jp/articles/aws-summit-2024-aws-57/
インシデントの影響を封じ込めるクラウドアーキテクチャの実践（15:50 - 16:30）
ここは冒頭だけみて、認定者ラウンジに戻った。
距離も遠いので、少し早めに出て、秋葉原でラーメンを食べた。
