เห็น Web AI Engineering Landscape ทำการสรุปเครื่องมือ AI ต่าง ๆ
ที่ใช้ในการพัฒนาระบบงานมาเป็นกลุ่ม ๆ
ประกอบไปด้วย

• Prompt engineering
• Agent
• RAG
• Platform
• Provider ต่าง ๆ
• database และการ search
• Security
• Fine-tuning

จากที่ดูผ่าน ๆ มาเล็กน้อย คิดว่าน่าจะมีประโยชน์สำหรับผู้เริ่มต้น
มีหลายตัวที่น่าสนใจ และ ลองนำทดลองใช้งานได้

ว่าง ๆ มาลองสร้าง MCP Server ด้วยภาษา Go กันหน่อย
โดยมีคนสร้าง library มาให้ใช้งานคือ mcp-go
ดังนั้นจึงลองสร้าง server ทำหน้าที่คำนวณเลขบวก ลบ คูณ หาร ทั่วไป
จากนั้นทำการ build image ด้วย Docker
ปิดท้ายด้วยการทดสอบใช้งาน MCP Server ด้วย mcphost
ช่วยให้เราทดสอบ tool หรือ MCP server ต่าง ๆ ได้แบบง่าย ๆ
ที่สำคัญสามารถเลือก LLM provider ได้อีกด้วย
แสดงการทำงานดังรูป

มาลองสร้างกัน ตามขั้นตอนดังนี้

ขั้นตอนที่ 1 สร้าง MCP server ด้วยภาษา go

โดยจะสร้างการบวก ลบ คูณ หาร ตัวเลขปกติ ดังนี้

ขั้นตอนที่ 2 สร้าง Dockerfile สำหรับการ build image

โดยทำการสร้าง image ชื่อว่า calculator

ขั้นตอนที่ 3 ติดตั้ง และ config mcphost เพื่อใช้งาน MCP Server ที่สร้าง

ขั้นตอนที่ 4 ทำการ start mcphost เพื่อใช้งาน โดยกำหนดว่าจะใช้ LLM provider คือ Anthropic

เพียงเท่านี้ก็สามารถสร้าง MCP Server สำหรับการทำงานเรื่องต่าง ๆ ได้แล้ว
โดยใน mcphost จะเรียกว่า tool นั่นเอง
ลองเขียน prompt เพื่อทดสอบกัน
ลองเล่นกันได้ครับ

Reference websites

• Creating an MCP Server in Go and Serving it with Docker

ในการออกแบบและพัฒนาระบบงานนั้น
มักจะเจอปัญหาที่เรียกว่า Backpressure กันบ่อย ๆ
หรือเรามักจะเรียกว่า ปัญหาคอขวด ของระบบนั่นเอง
มันคือ สิ่งที่ขัดขวางการไหลของน้ำ ทำให้เกิดความดันย้อนกลับ (เหมือนกรดไหลย้อนไหมนะ)
พูดง่าย ๆ คือ ท่อตัน หรือ หนักกว่านั้นคือ ไฟลามทุ่ง !!

คำถามที่ตามมาคือ เราจะจัดการปัญหานี้อย่างไร ?
ซึ่งมีทั้งแบบ proactive และ reactive
หรือบางคนก็ ignore มันไปเลย เช่น ถ้ามีปัญหาก็ restart ไปไง ให้มันจบ ๆ
แต่ไม่น่าจะเป็นวิธีการที่ดีมากนัก
ดังนั้นมาเรียนรู้กันว่า มีวิธีการอย่างไรบ้าง ?

ถ้าระบบงานทำงานเป็นปกติ คงไม่ต้องทำอะไร
แต่เมื่อเกิดปัญหาขึ้นมาแล้ว ก็ต้องจัดการกัน
หรือถ้าเราเรียนรู้มากเพียงพอ ก็สามารถออกแบบและสร้างระบบเพื่อป้องกันไว้ได้

ยกตัวอย่างเช่น ถ้ามี traffic เยอะเกินไป
เช่นมี bot ยิงเข้ามาเยอะ ๆ เราอาจจะใส่ captcha เพื่อป้องกัน bot
หรือทำการกั้นด้วย firewall หรือพวก CDN ต่าง ๆ

แต่ถ้ายังเข้ามาในระบบเยอะ ๆ ก็มักจะทำการกำหนด Rate limit เข้ามา
โดยมี algorithm ที่เลือกได้ เช่น token bucket, fixed windows เป็นต้น
หรือทำการกำหนดจำนวน request ที่รับได้ในช่วงนั้น ๆ

ต่อมาอาจจะทำการกระจาย load traffic ไปยังที่ต่าง ๆ
เพื่อลดการ load เพียงที่เดียวก็ได้
มันคือเรื่อง load balance นั่นเอง
แต่ถ้าหลังบ้านยังมีปัญหา ก็แก้ไขเพัยงทางเข้า ส่วนในบ้านยังมีปัญหา

ดังนั้นถ้า traffic เข้ามาเยอะภายในมากไป
อาจจะต้องปรับเปลี่ยนการทำงาน
เช่น
การเขียน code จาก blocking มาเป็น non-blocking มากขึ้น
การติดต่อสื่อสารจาก synchronous มาเป็น asynchronous ไหม
ยกตัวอย่างเช่น

• batching process
• messaging queue

เพื่อสร้าง buffer ให้กับระบบ แต่จำเป็นต้องทำการปรับเปลี่ยน user/business flow ด้วย
หรือจะนำแนวคิดของ circuite breaker เข้ามาช่วยก็น่าสนใจ

บางครั้งเราอาจจะแยกส่วนการทำงานแบบ realtime process ออกจาก batch process
หรือระบบที่ทำงานได้เร็ว ออกจาก ส่วนการทำงานที่ช้าก็ได้
เพื่อเครื่องทำงานให้ใหญ่ขึ้น หรือ จำนวนมากขึ้น !!

ไม่ว่าทางใด ความซับซ้อนก็จะสูงขึ้นแน่นอน
มันคือ trade-off ที่เราต้องเลือกเช่นกัน
เราเลือกทางไหน ?

โดยรวมแล้วนั้นสิ่งที่เราต้องคำนึงเรื่องปัญหานี้คือ

• การควบคุม (control) การใช้งานจากฝั่งผู้ใช้งาน ว่าสามารถจัดการได้ไหม เช่นถ้าระบบที่เราจะใช้งานมีปัญหา เรายังจะเรียกใช้อยู่ไหม ?
• จัดการ buffer ให้ระบบ เพื่อใช้จำเก็บ request ต่าง ๆ ที่เข้ามา ซึ่งเวลาปกติอาจจะไม่จำเป็น แต่ถ้ามีปริมาณเยอะ ๆ จำเป็นต้องเปิดการใช้งาน
• บางครั้งอาจจะต้องทำการ drop request ต่าง ๆ ออกไปด้วย !!

เราจัดการปัญหาเหล่านี้กันอย่างไรบ้าง ?

เห็นทาง MongoDB ปล่อย library ในภาษา JavaScript ชื่อว่า MongoDB-RAG
สำหรับช่วยพัฒนา RAG application แบบง่าย ๆ
โดยใช้งาน MongoDB Atlas เป็น database จัดการข้อมูลในรูปแบบของ vector
มาทำความรู้จักและลองใช้งานกันหน่อย

เป้าหมายของ MongoDB-RAG มีดังนี้

• จัดการการสร้าง Vector search index ใน MongoDB Atlas ให้แบบอัตโนมัติ
• มี batch document ingestion สำหรับการแปลงข้อมูลพวก text, markdown และ PDF ไปเป็นข้อมูล vector เพื่อให้ค้นหาได้ง่าย (loader และ embedding)
• มี semantic search และ hybrid search ให้ใช้งานง่าย ๆ
• สนับสนุน embedding จาก provider ต่าง ๆ เช่น OpenAI, Ollama, DeepSeek และ Anthropic
• ใช้งานผ่าน CLI (command-line) เพื่อให้สามารถสร้างการทำงานแบบอัตโมัติได้ง่ายขึ้น

มาลองใช้งานกันดู

ขั้นตอนที่ 1 ทำการติดตั้งผ่าน npm ได้เลย

ขั้นตอนที่ 2 ทำการ load และ seach ข้อมูล

เพียงเท่านี้ก็สร้าง RAG application แบบง่าย ๆ ได้แล้ว
ลองใช้งานกันดูครับ สำหรับ MongoDB-RAG
ขอให้สนุกกับการ coding

จากที่ Deno 2.2 ปล่อยออกมานั้น
หนึ่งในความสามารถที่น่าสนใจคือ สนับสนุน OpenTelemetry แล้ว
ทำให้การจัดการ log, trace และ metric ของระบบงานง่ายขึ้น
โดยจะทำงานแบบ auto instrumentation หรือแบบอัตโนมัติโดยที่ไม่ต้องเขียน code เลย
แต่ถ้าต้องการ custom หรือสร้าง span ต่าง ๆ ก็ได้อีกด้วย
ดังนั้นมาลองใช้งานกัน

เริ่มด้วยการติดตั้งหรือ upgrade Deno ก่อน

ในการทดลองจะใช้งานร่วมกัน LGTM stack ผ่าน Docker

จากนั้นทำการสร้าง server.ts เป็น web server
และทำการเรียกใช้งาน service 2 ผ่าน fetch()
code ตัวอย่างเป็นดังนี้

คำอธิบาย

• ทำการสร้าง span ใหม่ขึ้นมาจาก current trace (active) สำหรับการทำงานของ function doWork()

จากนั้นในการ run ต้องเปิดใช้งาน OpenTelemetry ใน Deno ก่อน
ด้วยการกำหนด OTEL_DEMO=true
และ feature นี้ยังคงพัฒนาอยู่ท่านั้น อย่าใช้งานจริงนะครับ !!
ดังนั้นในการ run ให้ใส่ flag --unstable-otel เข้าไปด้วย

ตัวอย่างของ Dockerfile ของการ run server

ทำการ run ทั้งหมดด้วย Docker compose

โดยทำการกำหนดชื่อ service, url ที่จัดเก็บข้อมูลต่าง ๆ ใน LGTM stack

ผลการทำงานจะมี trace เข้ามาใน LGTM stack ดังนี้

เพียงเท่านี้ก็สามารถลองใช้งานแบบง่าย ๆ ได้แล้ว

แต่ยังมีข้อจำกัดพอสมควร เช่น

• ยังไม่สนับสนุน auto propagation ของ Deno.serve() และ fetch() ทำให้เมื่อเมื่อการเรียกข้าม service จะทำให้ trace ไม่เชื่อมต่อกัน

Code ตัวอย่างอยู่ที่ GitHub:Up1

Reference websites

• Leveraging OpenTelemetry in Deno

จากหนังสือเรื่อง Team Topologies นั้นมีการอธิบายเรื่องของ Thinnest Viable Platform (TVP)
เป็นแนวคิดและแนวทางในการจัดการ feature ต่าง ๆ ใน platform ของเรา
ไม่ให้ซับซ้อนจนเกินไป
ไม่ให้มีมากกจนเกินความจำเป็น
อะไรที่ไม่ได้ใช้งาน ก็เอาออกไป
เป็นสิ่งที่ต้องทำอย่างต่อเนื่อง
เพื่อทำให้มั่นใจว่า ระบบสามารถ scale, maintain และมีประสิทธิภาพที่ดีในระยะยาว

แต่น่าจะขัดแย้งกับหลาย ๆ ที่ เพราะว่า ถ้าไม่ใช้ก็อย่าไปยุ่งกับมัน !!
เน้นสร้างของใหม่เข้าไป !!

โดยแนวคิดนี้ จะเริ่มจาก Minimum Viable Platform (MVP)

เพื่อสร้าง platform สำหรับการพัฒนาและส่งมอบ product ต่าง ๆ อย่างรวดเร็วและมีคุณภาพ
เริ่มจากเล็ก ๆ เพื่อให้ได้รับ feedback ที่เร็วจากการทำงานภายใน
ตั้งแต่การพัฒนา ทดสอบ ส่งมอบงาน และระบบ monitoring ต่าง ๆ
จนการได้รับ feedback จากผู้ใช้งานด้วยเช่นกัน

ดังนั้น MVP จะช่วยลดหรือหลีกเลี่ยงระบบที่ซับซ้อนในช่วงเริ่มต้น
แต่เมื่อเวลาผ่านไปก็ต้อง maintain ให้ดี ให้เหมาะสม
ทั้งเรื่องของความซับซ้อน
ทั้งเรื่องของค่าใช้จ่าย
ทั้งเรื่องของเวลาในการจัดการ
มีการ update สิ่งต่าง ๆ ที่ใช้งานอย่างสม่ำเสมอ
และระบบต้องทำงานได้ดี รองรับการ scale ได้
นั่นคือที่มาของ TVP นั่นเอง

ซึ่งเป็นพื้นฐานของ Platform as a Product

ที่ต้องเข้าใจถึงความต้องการของกลุ่มคนใช้งานเสมอ
แน่นอนว่า ความต้องการเปลี่ยนไปอย่างแน่นอน
ดังนั้น platform ก็ต้องสามารถปรับเปลี่ยนด้วยเช่นกัน !!
เพื่อช่วยลดงาน ไม่ต้องจดจำการทำงานมากจนเกินไป
นั่นคือการแบ่งกรอบการทำงานที่ชัดเจน และ แต่ละกรอบต้องจบภายในตัวเอง

อะไรที่มันใช้ซ้ำ ๆ ก็ควรต้องมาทำไว้ตรงกลาง
แต่ก่อนจะทำตรงกลาง ต้องมั่นใจก่อนว่า มันซ้ำจริง ๆ !!
แสดงดังรูป

ยกตัวอย่างเช่น

• จากเดิมเป็น on-prem ใช้ VM ต่อไปใช้ Cloud แบบ public มาเป็น private สักพักเป็น hybrid
• หรือจากบน Cloud จะติดตั้งเอง ก็เปลี่ยนไปใช้ Managed-service
• หรือจากใช้ IaaS มาเป็น SaaS และมาเป็น PaaS
• หรือในทางตรงข้ามก็เช่นกัน

ล้วนเกิดมาจากความต้องการที่เปลี่ยนไป
ไม่มาจะเรื่อง การดูแลรักษา การ scale รวมทั้งค่าใช้จ่ายต่าง ๆ
จะมีการเปลี่ยนแปลงไปอย่างต่อเนื่อง
ดังนั้นสิ่งที่เราต้องจัดการ platform คือ การปรับเปลี่ยนให้ได้นั่นเอง

Reference Websites

• Trade Me’s Journey Towards a Thinnest Viable Platform (TVP)
• Scaling Platform Building: Balancing What is Unique to Your Org and Common Across Teams
• MVP or TVP? Why Your Internal Developer Platform Needs Both
• Define the problem space
• TVP - Thinnest Viable Platform

วันนี้อ่านบทความเรื่อง Scaling PayPay with Rust
ซึ่งเป็นการทำ Poc (Proof of concept) ของการเปลี่ยนภาษา program ของระบบงาน
จากเดิมที่พัฒนาด้วย Java และ NodeJS ซึ่งทำงานได้ดี
แต่เมื่อระบบใหญ่ขึ้น การใช้งานมากขึ้น
จำเป็นต้องการ scale ระบบมากขึ้นเช่นกัน
แต่ด้วยการ deploy บน Kubernetes cluster นั้น
มีการใช้งาน CPU และ memory มากขึ้นด้วยเช่นกัน
นั่นคือการมาพร้อมด้วยค่าใช้จ่ายที่สูงขึ้นมาก
นี่คือเหตุผลหลัก ๆ ของการเปลี่ยนแปลงนั่นเอง

โดยเริ่มทำการศึกษาและทดลองมาตั้งแต่ปี 2023 แล้ว
มีการศึกษาทั้ง GraalVM, Go, Rust และอื่น ๆ
ซึ่งจาก use case ของทาง PayPay นั้น ได้ทำการเลือก Rust
ที่ตอบโจทย์ ทั้งเรื่องของ performance, type safety และ resource ที่ใช้ทั้ง CPU และ Memory
มาดูแนวทางของทาง PayPay สำหรับนำ Rust มาใช้งาน

แนวทางในการทำ Poc เป็นดังนี้

จะไม่ทำการ replace ทั้งหมดแบบทันที หรือ big bang
แต่จะเริ่มจากการ poc เป็น project เล็ก ๆ ก่อน
เพื่อดูว่ามันเข้ามาช่วยแก้ไขปัญหาของเราหรือไม่
ทั้ง development และ deployment บน production
เมื่อได้ผลที่น่าพอใจแล้ว จึงจะนำผลนี้ขยายผลออกไปในส่วนต่าง ๆ

เป้าหมายของการ Poc มี 3 เรื่อง ประกอบไปด้วย

• ปรับปรุงการใช้งาน resource ได้ดีหรือไม่
• ในการ deploy บนระบบเดิมนั้นทำได้หรือไม่ และทำได้ดีหรือไม่ โดยที่การเปลี่ยนแปลงไม่เยอะ
• ระบบเล็ก ๆ (microservice) ที่พัฒนาด้วย Rust นั้น สามารถรองรับ traffic บน production ได้หรือไม่

โดยในการ Poc จะทำการสร้าง API gateway ขึ้นมาด้วย Rust

ซึ่งจะมี feature ต่าง ๆ ดังนี้

• rate limit
• authentication
• touting request
• aggregate data

เป็นส่วนงานที่ต้องรับ request จำนวนมาก จากทางฝั่งของ frontend
ไม่ว่าจะเป็น web, mobile และช่องทางอื่น ๆ

• Rate limit layer ใช้งาน nginx
• Business logic layer ใช้ Java/NodeJS

ดังนั้นถ้าทำการลดการใช้งาน resource ต่าง ๆ ลงไปได้
รวมทั้งประสิทธิภาพการทำงานยังดี และ มีความน่าเชื่อถือ
น่าจะส่งผลดีต่อบริษัทอย่างมาก
แสดงโครงสร้างดังรูป

ในการทำ Poc นั้นจะต้องไม่กระทบต่อการทำงานของระบบเดิม
แถวต้องรองรับ traffic บน production ให้ได้ด้วย
ด้วยการเขียน plugin ใน nginx ด้วยภาษา Lua เพื่อ route traffic มาให้
ดังนั้นทางทีมจึงเลือกแนวคิดของ Sidecar container มาใช้งาน

โดยจะสร้าง helper sidecar service ขึ้นมาด้วยภาษา Rust

ใช้งาน web framework ชื่อว่า Actix Web
อีกทั้งยังใส่ opentelemetry เข้าไปได้ง่าย

ลองใช้งานง่าย ๆ แถมยิงแล้วแรงใช้ได้เลย

ผลของการ rollout ป็นดังนี้

• ในครั้งแรกนั้น รองรับ traffic น้อย ๆ พบว่า ช่วยลด CPU และ memory จาก Java ลงไป 10 และ 80 เท่าตัว
• จากนั้นจึงทำการเพิ่มไปยัง feature อื่น ๆ และใหญ่ขึ้น พบว่า ช่วยลด CPU และ memory จาก NodeJS ลงไป 16 และ 100 เท่าตัว

ทำให้สามารถ scale down บน Kubernetes cluster ลงไปได้อีก
แต่ไม่ใช่แค่ลด cost/resource อย่างเดียว
แต่ latency ก็ลดลงไปประมาณ 30%
เหตุผลไม่ใช่มาจากการเปลี่ยนภาษาเพียงอย่างเดียว
แต่มาจากการลด service ที่ไม่จำเป็นออกไป ทำให้ลด hop ของ network นั่นเอง

ผลของการ rollout จากระบบ monitoring เรื่อง latency

นี่เป็นเพียงการเริ่มต้นเท่านั้น
ยังไม่ได้ rollout ส่วนการทำงานหลักของระบบที่มีความยากและซับซ้อน
แต่มีแนวโน้มในเชิงบวก ซึ่งน่าสนใจมาก ๆ

หัวใจหลัก ๆ ของการเปลี่ยนแปลง คือ ต้องไม่กระทบต่อระบบการทำงานหลัก

เพิ่งเปิดตัวกันไปสำหรับ Gemini Code Assist แบบ individual ให้ใช้ฟรี แต่มีข้อจำกัดนะ
โดยสนับสนุนภาษาต่าง ๆ มากมาย
และใช้งานผ่าน IDE เช่น VS Code, ตระกูลต่าง ๆ ของ Jetbrain
รวมทั้ง editor ใน Google cloud หรือใน GitHub ก็มี app ให้ใช้งาน
ช่วยอำนวยความสะดวกในการเขียน code มากยิ่งขึ้น
มาลองใช้งานกันดู

ความสามารถของ Gemini Code Assist ประกอบไปด้วย

• ทำการสร้าง code อธิบาย code และ test case ต่าง ๆ ให้
• มีคำแนะนำต่าง ๆ ของการเขียน code และ run ชุดคำสั่งต่าง ๆ
• ใช้ context ของ code ใน project เพื่อถามตอบใน chat
• ช่วยหา bug และการแก้ไขให้

จะใช้งานผ่าน VS Code โดยการติดตั้ง extension Gemini Code Assist

จากนั้นทำการ authentication ผ่าน Google account
และเปิดใช้งานแบบ Chat mode ได้เลย

มาลองมช้งานกันได้เลยใน chat mode
เลือกไฟล์และบรรทัดที่ต้องการได้

มาดู limit ของ verison ฟรีกันหน่อยว่าเป็นอย่างไร

• Code completion 6,000 ครั้งต่อวัน
• Chat ได้ 240 ครั้งต่อวัน

อีกอย่าง default เรื่อง privacy ก็ระวังด้วยนะครับ อ่านดี ๆ เพราะว่า default คือ เปิดเผยนะครับ !!

ดูเอกสารการใช้งานเพิ่มเติมได้ที่

• Gemini Code Assist overview 
• A Tour of Gemini Code Assist Standard and Enterprise for Developers in Google Cloud Shell Editor

ปล. จากที่ใช้งานมานิดหน่อย ยังช้า ๆ อยู่พอควร
เมื่อเทียบกับ GitHub Copilot และ Codeium

Reference websites

• Get coding help from Gemini Code Assist — now for free

มาลองใช้งาน Claude Code จาก Anthropic เป็น research preview version กัน
จากที่ปล่อยออกมา ต้องลงชื่อใน waiting list ใช้งาน
มาวันนี้ได้รับ invite ให้เข้าใช้งานแล้ว
ดังนั้นมาลองใช้งานกันหน่อย โดยใช้งานผ่าน CLI กันเลย

ติดตั้งก่อนใช้งาน

ความสามารถพื้นฐานที่ทำได้ และลองใช้งานแล้ว ประกอบไปด้วย

• ทำการสร้าง project เช่น NodeJS ซึ่งจะ run command ให้เลย
• ทำการสร้าง code และสร้างไฟล์ จากการเขียน prompt สำหรับสร้าง REST API จาก specification และ API document ได้เลย
• ทำการ download library ต่าง ๆ ที่ต้องใช้งาน โดยก่อนจะทำงานจะถามเราเสมอ
• ทำการ refactor code ให้ทดสอบได้ง่ายขึ้น (Testable)
• ทำการเขียน test cases จาก code ที่มีอยู่ใน project หรือตามไฟล์ที่เราเลือกได้เลย
• ทำงานร่วมกับ git ได้ง่าย ๆ ทั้งค้นหาใน commit, merge และ แก้ไข conflict ให้
• ที่แจ่มคือ สร้าง commit message ให้เลย เมื่อสั่ง git commit

ตัวอย่างการแก้ไข จะทำการแสดงส่วนที่แก้ไขให้ด้วย

ตัวอย่างของ prompt ที่สั่ง

ลองสั่งให้ git commit สวย ๆ หน่อยสิ

ต่อให้ต้องการจะเขียน test แต่ code ที่มีนั้น ยังไม่เหมาะสม

จึงสั่งให้ทำการ refactor code ด้วยการ split file ออกมา
จากนั้นทำการสั่งให้เขียน test ด้วย library ที่ต้องการ
เช่นจากการทดลองใช้งาน jest และ supertest ได้ผลดังนี้

• ทำการติดตั้ง library ทั้ง jest และ supertest ให้
• ทำการสร้าง folder __tests__ สำหรับสร้าง test case ให้
• ทำการสร้าง test case ต่าง ๆ จากไฟล์ที่เรากำหนดไว้
• ยังไม่พอ เพิ่ม script การ run test ในไฟล์ package.json ให้อีก
• ปิดด้วยการ run test พร้อมสรุปผลให้

ในการ commit นั้น สามารถบอกให้ใช้ตาม Conventional Commits ก็จะสวยขึ้นอีก

ลองทดลองเล่นกันดูครับ

ปล. ใครที่ใช้งาน aider chat มาก่อน จะสนุกกับตัวนี้มาก ๆ

ใน Bun v1.2.4 ที่ปล่อยออกมานั้น
สนับสนุน static site แล้ว
ดังนั้นสามารถ run พวกไฟล์ html ตรง ๆ ได้เลย
ทำให้ง่ายต่อสาย frontend development
มาลองใช้งานกันดู

ปล. bun build บน Mac เร็วขั้น 60%

ความสามารถของ Bundle frontend & static sites

ประกอบไปด้วย

• สนับสนุน HTML, CSS และ JavaScript
• สามารถ run แบบระบุ html ตรง ๆ หรือหลาย ๆ หรือ ไฟล์แบบ pattern ได้ (glob pattern) เช่น ***/*.html
• สนับสนุน TypeScript และ JSX
• มี plugin ให้ใช้งาน เช่น tailwind

ใช้งานกัน

ทำการ upgrade กันเลย

จากที่ได้แบ่งปันเรื่องการเขียน test เพื่อให้ได้ผลที่ดี
ว่าต้องทำอย่างไรบ้าง จึงทำการสรุปำว้นิดหน่อย
สิ่งหนึ่งที่เน้นย้ำคือ เราทดสอบเพื่อสร้างความมั่นใจของเราที่มีต่อระบบ
ไม่ได้ทำเพื่อใคร แต่เพื่อตัวเราเอง
เดินไปข้างหน้า โดยไม่ห่วงข้างหลัง
แล้วผลอื่น ๆ ที่ตามมา มันเป็นเพียงผลพลอยได้
ดังนั้น สำหรับใครก็ตามที่เขียน code ขึ้นมาได้
ก็น่าจะต้องสร้างความมั่นใจให้กับตัวเองด้วย
หนึ่งในวิธีการคือ การเขียน test นั่นเอง

อีกหนึ่งคำถามที่ต้องตอบให้ได้คือ
ถ้าตอนนี้เรากำลังเพิ่ม feature ใหม่เข้าไป
เรามั่นใจไหมว่า feature ก่อนหน้านี้ยังทำงานได้เช่นเดิม

แนวทางที่ได้แบ่งปันไว้มีดังนี้

• เริ่มจาก code ที่ testable หรือ สามารถทดสอบได้ง่าย นั่นคือ คิดก่อนว่าจะทดสอบอย่างไร ก่อนจะทดสอบหรือสร้าง
• เรื่องของ test strategy สำคัญมาก ๆ ต้องตอบให้ได้ หรือ ตกลงกันก่อน ว่าจะทดสอบแบบไหน อย่างไร มีขอบเขตอย่างไร ก็ลงมือ เช่น unit test, integration test, component test, contract test และ end-to-end test เป็นต้น
• ใน test case จะมีโครงสร้างมาตรฐาน โดยมักจะแนะนำ AAA (Arrange-Act-Assert)
• แต่ละ test case ควรที่จะเป็นอิสระแก่กัน ไม่ใช่ต้อง test แบบเรียงลำดับ เพื่อลดปัญหาของการทดสอบ ทั้ง flaky test, ไม่สามารถทำ parallel testing ได้ รวมทั้งเรื่องเวลาในการทดสอบที่อาจจะนานจนเกินไป ต้องตกลงกันให้ชัดเจน ว่าแนวทางไหนที่ส่งผลดีต่อการพัฒนาและส่งมอบระบบ
• แต่ละ test case ควรจัดการ external dependency ให้ดี ๆ ทั้ง datetime, random value, database และ external system เป็นต้น เพราะว่า ถ้าจัดการไม่ดี การทดสอบซ้ำเป็นไปได้ยากมาก ๆ ไม่ใช่อะไรก็จะ mock กันอย่างเดียว !!
• ในการทดสอบควรต้องเข้าใจเรื่องของ data test ด้วย ควรให้ครบและครอบคลุม ทั้ง normal case, edge case และ invalid case อาจจะรวมไปถึง non-functional case ด้วย
• ชื่อของ test case ควรอ่านเข้าใจได้ง่าย มีความหมายชัดเจน ว่ากำหนดทดสอบเรื่องอะไร ด้วยเงื่อนไขอะไร ผลที่คาดหวังคืออะไร เพื่อให้ง่ายต่อการดูแลรักษาต่อไป ไม่ใช่ทำแล้วทิ้งนะ
• เมื่อเจอ bug ต่าง ๆ ทั้งจากการพัฒนา ทดสอบ หรือ บน production ก็ตาม ควรเขียน test case เพื่อ reproduce bug เหล่านั้น ก่อนทำการแก้ไข code ต่อไป มันคือ การเรียนรู็จากความผิดพลาด ไม่ใช่ผิดพลาดเรื่องเดิม ๆ ซ้ำ ๆ แต่เปลี่ยนแค่ data นะ !!
• ทุกครั้งที่ทำการ commit code ให้ลองทำการ run test ดูก่อนแบบอัตโนมัติดู เช่น run unit test เป็นต้น ถ้าไม่ผ่าน ก็ไม่ให้ทำการ commit เป็นต้น รวมทั้งยังเอา test ต่าง ๆ ไป run ใน pipline ของ CI/CD ด้วย
• Code/test coverage ไม่ได้บอกอะไรเลย เป็นเพียงผลพลอยได้จากการเขียน test เท่านั้น

สุดท้ายเดี๋ยวนี้ เราให้ Generative AI เข้ามาช่วยเขียน test case ให้ได้อีกด้วย
ก็ช่วยเพิ่มทางเลือกในการเขียน test ให้สะดวกขึ้น
แต่ก็ยังจำเป็นที่ต้องตรวจสอบด้วยคนด้วยเสมอ (Trust but Verify)

ดังนั้น test case ต่าง ๆ ควรมีความน่าเชื่อถือ
ทำงานได้อย่างรวดเร็วตามที่หวัง หรือ เหมาะสมกับระบบนั้น ๆ
ครอบคุลมใน business logic/use case ต่าง ๆ ที่จำเป็น

คำถามสุดท้ายคือ
การทดสอบที่คุณสร้างขึ้นมานั้น ได้เพิ่มความเชื่อมั่นหรือไม่ ?
ผลการทำงานของระบบงาน มีปัญหาน้อยลงไหม ?