สรุป .NET Meetup – March 2026

สำหรับวันนี้รีบเลิกงานเลยครับ แต่ไม่วายติด Visual Studio 2026 Update + Window Update ไป แต่โชดดีที่รถเมล์ไม่ได้รอนาน เลยมา MRT อิสรภาพ > พระราม 9 ถึง Cleverse พอดีครับ เริ่มแรกแนะนำสถานที่ และ AI Product aerogram.ai ซี่งเป็น no code platform / one prompt multiple model / collaborate โดยมี template ตามแต่ละ role งาน hr / sale / marketing ครับ

Talk ในงานที่ผมจดมา ประมาณนี้ครับ

Local development with TestContainers

Speaker Joel Dickson

-Why TestContainers

📌 Speaker พบว่าการพัฒนาซอฟต์แวร์ในเครื่อง Local มักติดปัญหาเรื่อง QA Dependency มันต้องเชื่อมต่อกับระบบ QA ส่วนกลางของ Agoda อย่างเช่น

• Enviroment ต่างๆ ถ้าเป็น Frond End ที่เชื่อมกับ BFFs (Backend For Frontends Pattern) ของ ฝั่ง QA ที่มี ประมาณ 4x ตัวขัดข้องเพียงตัวเดียว มันทำให้งานของ Dev สะดุดได้ - ไปประมาณ 25x dev-hour/month
• นอกจากนี้ Data มัน Share กัน QA / DEV ถ้าใครแก้อะไรพังแบบ Data เปลี่ยน (Mutate) มันทำ Test สะดุดได้

📌 นอกจากนี้ต้องการเน้น Fail Fast มาเน้นส่วน Inner Loop (Local Dev Env) เพราะ Setup ได้ไว้ ส่วน Outer Loop (Integration Test via CI) มันช้าบางที อาจจะต้องรอนานถึง 90 นาที

📌 ที่นี้มันเลยที่มา อยากเพิ่ม Developer Experience ให้ดีขึ้นด้วยแนวคิด F5 กดปั๊บมีของพร้อมลุย Dev จากนั้นมันสร้างของที่เกี่ยวข้องมาให้

• ถ้าสนใจ Speaker แนะนำให้ไปอ่าน Blog ได้ https://medium.com/beer-and-servers-dont-mix/all?topic=f5-experience
• หรือ ลองไปดู Blog Recap The F5 Experience ผมก็ได้ จดมาจากงาน dotnet ต้นปีที่แล้วครับ

📌 แต่ทว่าการเอาแนวคิด F5 มาช่วย กดตุ๊มเดียวได้ Env มาแล้ว ยังพบปัญหาอยู่ ได้แก่

• Integration Test - มันต้องการของเยอะ อย่างพวก Database / Messsage Queue อย่าง kafka) หรือ 3rd Party API
• Set Infra จาก docker compose + file + db ที่เตรียมไว้ให้มันใหญ่ และช้า
• ขั้นตอนฝั่ง Local กับ CI ทำไม่เหมือนกัน

📌 มันเลยทำให้ SW Engineering มองว่า ถ้า Integration Test มันทำยาก ไม่ทำและ ส่งงานไปให้ CI จัดการ ไปแต่มันเกิด Feed back ที่ช้า

ถ้าเราทำให้ Inner Loop มันมี Developer Experience ที่ดีได้ เราสามารถใช้ประโยชน์จาก AI Agent ได้ดี

📌 ถ้าจะใช้ Test Container แล้ว Solution อื่นๆมันมีข้อดี ข้อเสียอย่างไร ตารางผมใช้ Gemini แปลจากภาพมานะ ถ้าผิดบอกได้

CONCERN	SHARED QA ENV	DOCKER COMPOSE	TESTCONTAINERS
Isolation	None — anyone can mutate	Per-developer	Per test suite run
Setup	Manual config / VPN	CLI commands outside IDE	dotnet test / F5
CI Parity	Different from local	Close but not identical	Identical — same code path
Credentials	Manage per-env secrets	Baked into compose file	Container gives you them
Data freshness	Stale snapshots	Baked images, stale	Fresh every run + migrations
Kafka support	Shared, side effects	Kafka says "don't use Compose"	First-class KRaft support

นอกจากนี้การใช้ TEST CONTAINERS

📌 ลดภาระเรื่องการจัดการ IP / Port ด้วย เดี๋ยว Test Container จัดการให้ แล้วส่ง Connection String มาให้เอง ปัญหา Credentials จะหมดไป

📌 ใน TEST CONTAINERS ของ Database ยังสามารถใช้ Database Migration เพื่อมาเตรียม Data สำหรับ Test Case ต่างได้ด้วย

📌 สำหรับส่วนของ Messsage Queue อย่าง kafka อันนี้

• Official เอง ไม่ค่อยแนะนำการ Run kafka - Docker Compose ใน Production หรือ Dev เพราะมันใช้พลังเยอะมาก และ อาจจะมีปัญหาจุกจิมากมาย ทำให้ Integration Test ไม่เสถียรได้ น่าจะตำกว่า 50% แล้วพอย้ายใช้ TestContainers ความเสถียรขึ้นมาเป็น 96%

• นอกจากนี้เรายังสามารถทำ Helper ปั๊ม Message โยนเข้าไปได้
• หรือ Test ทั้ง Flow ก็ได้

จากที่คุยมาทั้งส่วน Database / ภาพรวมของ TestFixture (NUnit) จะเห็นภาพรวมการ Setup ทั้ง Spin Resource และ TearDown จัดการ Resource ทั้งหมด

-TestContainers Trick

📌 Project Structure - Gemini ถอดมานะ

src/
├── Agoda.BookingSearch.WebApi/            → Your real API
│   └── Program.cs
│
├── Agoda.BookingSearch.Core/              → Business logic
│
├── Agoda.BookingSearch.IntegrationTests/  → Test project
│   ├── MainIntegrationTestFixture.cs      → WebApplicationFactory + TestContainers
│   ├── Controllers/
│   │   └── SearchIntegrationTest.cs       → Inherits fixture, uses _client + _kafka
│   ├── Util/
│   │   ├── KafkaHelper.cs                 → Extension: produce messages
│   │   └── BookingDetailKafkaMessageCreator.cs
│   └── Extensions/
│       └── MicroDbExtention.cs            → Extension: ClearDb, InsertBookingDetail
│
├── Agoda.BookingSearch.StartupLocalDev/   → Local dev project
│   ├── BookingSearchHostingStartup.cs     → IHostingStartup, same containers!
│   └── Agoda.BookingSearch.StartupLocalDev.csproj
│
└── PGSQL/
    └── booking-search-api/
        └── bkng_search_db/migrations/     → SQL migrations (shared!)

📌 จากภาพรวมที่ทำสำหรับ 1 Test เพื่อให้ Code Clean และ Reuse ได้ง่าย Speaker แนะนำว่า เราต้องมาทำตัวช่วย Inject Setup ชุดนี้เข้าใน Integration Test

• IHostingStartup - เป็๋น Feature มาใน NET7 ถ้า Class ไหน มี Interface ตัวนี้ ตัว Kestrel (Web Server ของ .NET) ดึงขึ้นมาให้ทำงานเลย แม้ว่าจะไม่มี Code ไปเรียกมัน
• นอกจากนี้ DLL ส่วน TestContainers มีการกำหนดให้ถูก Build และ Complile ในช่วง Debug Mode เท่านั้น เพื่อไม่ให้ DLL ส่วนนี้มันไป รกในส่วน Production

📌 ถ้า Run Test เดี๋ยวๆ ในสวนของ WithName ให้เพิ่ม GUID ต่อท้ายไปจะได้ไม่ชนกัน
📌 หรือ ในกรณีที่ Test มันเชื่อมโยงกัน หรือไม่อยากเสียเวลา Spin Container ขึ้นมาใหม่ทุก Test สามารถกำหนด WithReuse(true) ได้่

📌 และ WebApplicationFactory ตัวช่วย Inject ทุกอย่างเข้าไปใน Test ได้ง่ายขึ้น

-You Can Improve what you don't measure

จากที่ Speaker บอก Stat เช่น

• ใช้ TestContainers Integration Test มีความเสถียรขึ้นจากเดิม 50% > 96%
• หรือ ทำให้ Dev Happy ขึ้นจากการ Run Local Integration Test 20% > 70% ตัวเลขนี้ไม่ได้วัดความความรู้สึกนะ แต่มีการเก็บข้อมูล วัดอย่างชัดเจน
• หรือ ลด Context Swtiching จากการ Run Setup เพราะทุกอย่างกด F5 แล้วพร้อมภายใน 30 Sec
• หรือ เวลา 25x dev-hour/month ที่ SW Dev วุ่นกับการ Test ไม่ได้ เพราะต้องรอ Dependency อื่นๆ เป็นต้น

ทุกอย่างต้องมีการเก็บข้อมูล / Data

ข้างใน Agoda เองมี ทำ 3 Lib Agoda.Builds.Metrics / Agoda.DevFeedback.AspNetStartup / Agoda.Tests.Metrics วิธีใช้ดูใน Git https://github.com/agoda-com/dotnet-build-metrics เก็บข้อมูลในเคสก่อน และหลัง และเอามาเทียบกัน

- ช่วง Q&A

📌 หากมีหลาย Test Case ที่ต้องอัปเดตข้อมูลในฐานข้อมูล มี Business Flow ที่ต่างกัน ควร Mock ข้อมูลอย่างไรใน TestContainers? รวม หรือแยกกัน

Ans: แนะนำให้แยก Instance ของ PostgreSQL ออกจากกันตามความเหมาะสม เพราะ PostgreSQL มีน้ำหนักเบา (Lightweight) การรันแยกจะช่วยลดปัญหาข้อมูลตีกันได้ดีกว่า

📌 Integration Test ทั้งหมดในเครื่อง Local หรือรอรันบน CI?

Ans: ควรเลือกรันเฉพาะชุดการทดสอบ (Suite) ที่เกี่ยวข้องกับส่วนที่เราแก้ไขเพื่อให้ทำงานได้เร็วที่สุด ส่วนการรันทั้งหมดให้เป็นหน้าที่ของ CI

📌. NET Aspire ในการช่วยเรื่อง F5 Experience?

Ans: .NET Aspire เน้นไปทาง .NET ระดับนึงใน Agoda ใช้หลายภาษา แต่เขาก็ใช้ตัว Aspire Dashboard อยู่ แม้แต่กับโปรเจกต์ที่เป็น JVM ตอนนี้ .NET Aspire น่ารองรับหลายภาษาแล้วพวก JS / Python

Back to the origin with the Al

Speaker Giorgio Desideri

- AI Problem

📌 การใช้ Agent คุยกันเองเพื่อแก้ปัญหา แต่ Agent คุยกันวนไปมาจนค่า Token พุ่งสูงจาก 1,000 เป็น 45,000 ต่อ Request และเสียค่าใช้จ่ายเพิ่มจาก 30 เหรียญเป็น 1,350 เหรียญต่อวัน โดยงานไม่เสร็จ !!!

• METR Report - คาดหวังว่าเอา AI มาใช้แล้ว Productivity พุ่ง แต่ความจริงมันแย่ลง
• Stanford Institute for Human-Centered AI (HAI) Repprt - AI ยังไม่สามารถจัดการ Complex Task แล้วคนเข้าใจผิด Generative AI ทุกอย่างเกิดจาก Prob คาดเดาตัวต่อไป

เราต้องทำอะไรผิดแน่ๆ Productivity แย่ / Cost พุ่งสูงขึ้น

- What we can do > What we want

📌 AI is not AI - ปัจจุบันเป็นเพียง "Generative AI" แต่ไม่ใช่ "Thinking AI" เพราะมันยังขาดการให้เหตุผล (Reasoning) แบบมนุษย์
📌 Cost - การใช้ AI ผิดวิธีส่งผลให้ต้นทุนสูงมาก ดังนั้นใช้ในจุดที่เหมาะสม
📌 KISS (Keep It Simple and Short) - ตอนแรกที่ทำ เน้นส่วน Minimalistic approach รวมถึงอาจจะยังไม่จำเป็นต้องใช้ Lib หรือ Framework ต่างๆ เพราะ เราไม่รู้มันยัดอะไรมาให้ อาจจะส่งผลถึง Cost ได้
📌 Orchestration

• Established Workflow กำหนด Workflow ที่ชัดเจน เราเข้าใจได้ - DIY
• เน้น Declarative approach คือ การประกาศความต้องการผ่าน Natural Language แทนที่จะเขียนโค้ดสั่งการทำงานที่ซับซ้อนแบบเดิม (Imperative approach ) ผม Take Course ของคุณ Giorgio ใน Course Ho Ho AI Key - แล้วให้ AI ทำงานเฉพาะจุดที่เรากำหนด เล็กที่สุด ในระดับ Task ของ Workflow เพื่อลดการหลอน และคุม Cost ด้วย

ไม่ควรปล่อยให้ AI จัดการกันเองแบบไร้ทิศทาง เพราะจะทำให้ควบคุมผลลัพธ์และต้นทุนไม่ได้

📌 Avoid Complexity - แม้ว่าเราใช้ Multiple Agent แต่ต้องทำงานภายใต้ "Established Workflow" เพื่อป้องกัน Agent มันออกทะเลไป

-Sample Implementation

📌 Flow User > App (AI Agent + Workflow ที่เรากำหนดไว้) ติดต่อิกับ External Data File / DB / API / RAG (Vector DB)

📌 จากนั้นจะ Demo Console App แบบ Clean Architecture หรือ Ports and Adapters (ใน Live ถ้าใครไปฟังจะ keyword Chocolate Cake

• Infrastructure (ฐานเค้ก): เป็นส่วนล่างสุดที่รองรับระบบทั้งหมด
• Domain (ช็อกโกแลตข้างใน): เป็นหัวใจสำคัญของแอปพลิเคชัน
• Application & Console (ครีม + สตรอว์เบอร์รี): ส่วนของ Console Application คือสตรอว์เบอร์รีที่อยู่ด้านบนสุดเพื่อปฏิสัมพันธ์กับ user

📌 ถ้ามองที่ Code แกจะแยก Agent UseCase ที่ทำหน้าที่ควบคุม AI ซึ่งประกอบด้วย

• Agent Configuration:
  - เก็บข้อมูล เช่น Model ID (GPT, Gemini), API Key และชื่อ Agent
  - กลุ่ม Skills (Instructions & Guidelines): คำแนะนำ มาตรฐาน และแนวทางที่ AI ต้องปฏิบัติตาม เพื่อให้ผลลัพธ์ออกมาตามความต้องการ

• Agent Service - Control over the process
  - History Management: มีการเก็บประวัติการสนทนา (History) เพื่อให้ Agent สามารถทำงานต่อเนื่องได้
  - Input Handling: ของแต่ละ Task
  - ส่วนของการ BuildXXX สิ่งที่เป็น Outcome ของ Task ย่อยๆนั้น ส่วนนี้ เราจะ AI เข้ามาช่วย ตาม Agent Configuration ให้ AI มันคิด แล้วออกมา เช่น จุด Gen SQL ยัด Config ที่เกี่ยวข้องพอ Context ไม่บวมด้วย
  - ส่วนบันทึกผลเอาไปใช้ต่อ

- Considertion

📌Developer

• Your Orchestration Workflow - Declarative approach - Instuction
• Responsibility: รับผิดชอบต่อผลลัพธ์ (Outcome) ทั้งในแง่คุณภาพ Code / SW และ Cost ที่เกิดขึ้นด้วย

📌Embrace - ถอยออกมามองภาพรวม

• [HOW] ไม่ควรโฟกัส จุดที่ตัวเองทำ ต้องมองภาพรวมด้วย
• รวมถึงมองภาพรวมมุม Business / Project Managmert แล้วตอบคำถามส่วน Why What How
• AI จะช่วยให้ทำงานเร็วขึ้น แต่การตัดสินใจเชิงสถาปัตยกรรมและการกำหนดแนวทางยังเป็นหน้าที่คนนะ

📌Quantum Computing

• แนวคิด Quantum มันไม่ใช่แค่ 0 / 1 มันมีได้หลาย State แล้วอาจจะมาช่วยให้ AI/ML ทำงานได้ไวขึ้น รวมถึงจาก Generative AI > การใช้เหตุผล Reasoning
• Entanglement to Manage Architecture - มองว่า Quantum ความพัวพัน จาก Action A > B เคสนี้แก้ Code จาก Dev > Prod โดยอัตโนมัติ หรือ กลับกันก็เป็นได้
• Paper อ่านเพิ่ม 2505.23860v3
• DOTNET มี Quantum SDK + Q#

-ช่วง Q&A

📌 ความเห็นเกี่ยวกับซอฟต์แวร์ที่ใช้ AI?
Ans: ปัจจุบัน AI ยังเป็นเพียงเครื่องมือช่วยสร้าง (Generative AI) แต่ยังขาดการใช้เหตุผล (Reasoning) แบบมนุษย์จริงๆ เชื่อว่าในอีก 5-10 ปีข้างหน้า เราจะเห็นการก้าวกระโดดเมื่อนำ Quantum Computing มาช่วยเพิ่มพลังการประมวลผลให้ AI สามารถคิดหาความสัมพันธ์ของแนวคิดต่างๆ ได้เหมือนสมองมนุษย์มากขึ้น

Reference

• https://luma.com/0qzl6my7?tk=aqskGJ
• Live https://www.facebook.com/dotNETConfTH/videos/1460580082384014/