จากที่ทาง Android Developer ทำการเปลี่ยนแปลงเอกสารเกี่ยวกับ Testing strategies
เป็นคำแนะนำแนวทางในการทดสอบ android app
เพื่อสร้าง app ที่มีคุณภาพ ทั้งความเสถียรและน่าเชื่อถือให้มากที่สุด
โดยพยายามให้เจอปัญหาตั้งแต่การ develop process หรือ detect early นั่นเอง
เพื่อลดปัญหบน production รวมทั้งง่ายต่อการ debug หรือ profiling
มาดูกันว่าแนวทางเป็นอย่างไรบ้าง ?

แสดงการทดสอบเป็น 5 layer ดังรูป

Layer 1 Unit tests

เป็นการทดสอบส่วนการทำงานเล็ก ๆ ของ code
โดยไม่มีการทำงานกับ dependency ต่าง ๆ ของ android framework
และไม่จำเป็นต้องใช้งาน emulator หรือ real device

Layer 2 Component tests

เป็นการตรวจสอบการทำงานของ function ต่าง ๆ
เป็นการตรวจสอบการทำงานของ component หรือ module ต่าง ๆ
ว่าแต่ละส่วนทำงานได้ตามที่คาดหวังหรือไม่
ก่อนที่จะนะแต่ละส่วนมาประกอบ หรือ ทำงานร่วมกัน
ยกตัวอย่างเช่น Screenshot testing

Layer 3 Feature tests

เป็นการตรวจสอบการทำงานเมื่อนำเอา
function, component หรือ module ต่าง ๆ มาทำงานร่วมกัน
เป็นการทดสอบที่มีขนาดใหญ่ และ ซับซ้อนมากยิ่งขึ้น
แต่ถ้า layer 1 และ 2 ยังไม่ทำ หรือ ไม่ผ่าน ก็อาจจะทำให้ layer 3 มีปัญหามากยิ่งขึ้น
เช่น flaky test เป็นต้น

ยกตัวอย่างเช่น UI Behavior testing
ทำการตรวจสอบ state การทำงานต่าง ๆ บน UI
ซึ่งใน Android ได้เตรียม library ไว้ให้แล้ว ใช้งานตามที่ต้องการ เช่น

• Espresso
• Jetpack compose
• UI Automator
• Robolectric

Layer 4 Application tests

เป็นการทดสอบ application ที่ต้องทำการ build เป็น APK file ก่อน (dev/debug build)
จากนั้นทำการติดตั้งลงเครื่อง
เพื่อทำการตรวจสอบการทำงาน
มีการทำงานร่วมกับ external system มากมาย
ซึ่งจำเป็นจะต้องจัดการหรือควบคุมให้ดี
มิเช่นนั้นการทดสอบจะไม่มีคุณภาพ หรือ ขาดความน่าเชื่อถืออย่างมาก

ในการทดสอบจะทำงานร่วมกับการเปลี่ยนแปลงของ device ต่าง ๆ ด้วย
การเปลี่ยนหน้าจอ การหมุนหน้าจอ หรือ การเปลี่ยนภาษา หรือ การเปลี่ยน device เป็นต้น
สามารถใช้งาน UI behavior testing มาใช้งานได้ปกติ

Layer 5 Release candidate tests

ทำการตรวจสอบการทำงานของไฟล์ APK ที่จะ publish ออกไป
ซึ่งการทดสอบคล้ายกับ application tests
แต่ทำการ minify และ optimize แล้วสำหรับ production mode
มีการทดสอบแบบ end-to-end ที่ใหญ่และซับซ้อนขึ้นกว่า
รวมทั้ง environment ที่ทำงานด้วย ก็ใกล้เคียงกับ production อย่างมาก
เพื่อหาปัญหาต่าง ๆ ในการทำงาน
ตลอดจนเรื่องของ performance testing
ที่อาจจะส่งผลกระทบต่อ device และ ผู้ใช้งานอีกด้วย

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

• Device configuration
• Prevent synchronization issues
• Retry mechanisms

ลองศึกษา และ การแนะนำต่าง ๆ หล่านี้ไปใช้งานกันดู
ขอให้สนุกกับการ coding และ testing

ทางทีมพัฒนาของ Spring ได้ปล่อยตัว final ของ Spring Boot 3.4.0 มาให้ใช้งานแล้ว
โดยมีความสามารถที่น่าสนใจดังนี้

• Structured log
• สนับสนุน virtual thread ของ Java
• ปรับปรุงการทำงานร่วมกับ docker compose และ Testcontainer
• ปรับปรุงการทำงานของ Actuator
• ในการทดสอบเพิ่ม MockMvcTester เข้ามาเป็นตัวเลือกแทน MockMvc

สาย Java + Spring อย่าลืม upgrade กันด้วย

ช่วงวันหยุดลองทำ slide สำหรับการเขียน code และ test นิดหน่อย
ก็เลยคิดว่า น่าจะทำ slide อยู่ใน terminal ไปเลยดีกว่า
จะได้ไม่ต้องสลับหน้าจอไปมาให้วุ่นวาย
ดังนั้นจึงไปลองหาว่า มีเครื่องมืออะไรให้ใช้บ้าง ?

เริ่มจาก libary สำหรับการสร้าง slide ใน terminal

ยกตัวอย่างที่ใช้งานคือ Slides
สามารถสร้าง slide/presentation ในรูปแบบของ Markdown ได้เลย
ยกตัวอย่างเช่น

จากนั้นทำการติดตั้งและ run

เพียงเท่านี้ก็ใช้งานได้แบบง่าย ๆ แล้ว
ถือว่าสะดวกดีมาก ๆ
แถมยังเพิ่มพวก diagram ต่าง ๆ เข้าไปได้อีก (ASCII diagram)
หรือเพิ่ม live command line ได้เลย
หรือจะ custom theme ได้อีกด้วย
ลองใช้งานกันดูครับ

ทาง Anthropic ซึ่งให้บริการ Claude AI ได้ปล่อย Model Context Protocol (MCP)
ซึ่งเป็น opensource
มีเป้าหมายเพื่อให้เป็น standard ของการติดต่อสื่อสารที่ปลอดภัย
ระหว่าง LLM server ด้วยกัน
ระหว่าง LLM server กับ external datasource
หรือเครื่องมือต่าง ๆ ที่จำเป็นต่อการใช้งาน
ช่วยให้การตอบ หรือ การทำงานของ model ต่าง ๆ ดีขึ้นอย่างมาก
หรือมันคือเครื่องมือของ AI Agent นั่นเอง (มาแทนที่คนแน่นอน ... เริ่ม ..)

เริ่มที่ Architecture พื้นฐานของ MCP

มีการทำงานแบบ client-server ประกอบไปด้วย

• Host คือ LLM application สำหรับให้ผู้ใช้งานใช้ เช่น Cluade AI Desktop, IDE เป็นต้น
• MCP Client คือส่วนที่ทำงานอยู่บน Host เพื่อเชื่อมต่อไปยัง MCP server แบบ 1:1
• MCP Server คือ server ที่ทำงานเฉพาะอย่างไปเลย เช่น จัดการ local/remote resource และดึงข้อมูลจาก database และ web เป็นต้น โดยตอนนี้มีบริษัทหรือ product ต่าง ๆ มาสร้าง MCP server ให้ใช้งานแล้ว เช่น Cloudflare และ Zed.dev เป็นต้น

แสดงดังรูป

ตัวอย่างใน official website นั้นมีให้ลองเพียบ
ยกตัวอย่างเช่น ดึงข้อมูลจาก local database เลย คือ SQLite
โดยที่ MCP Server จะทำการเชื่อมต่อกับ SQLite
ส่วนฝั่ง client จะใช้งานผ่าน Claude Desktop
แสดงการทำงานดังรูป

ดังนั้นมาลองเล่นกันดู

มาดูการใช้งานผ่าน Cluade Desktop กันนิดหน่อย

ได้ผลการทำงานดังนี้ ซึ่งจะดึงข้อมูลจาก SQLite database ให้เลย

สะดวกมาก ๆ
แถมยังมี MCP SDK ให้ใช้งานด้วยทั้งภาษา Python และ TypeScript
ลองใช้งานกันดูครับ
สนุกแน่นอน

เห็นว่า WasmeEdge นั้นสนับสนุน opensource LLM แล้ว (เป็นภาษา Rust)
ชื่อ project คือ LlamaEdge
ซึ่งช่วยให้ง่าย และ ทำงานรวดเร็วมาก ๆ ทั้งการ run และ fine tune mode บน local นั่นเอง
มาลองใช้งานกันดู

เริ่มที่เป้าหมายของ LlamaEdge

• program จะมีขนาดเล็ก เป็น MB ซึ่งมีการเปรียบเทียบกับ Python และ Go ด้วยนะ
• สนับสนุนการทำงานบน hardware ต่าง ๆ รวมทั้งเน้นเรื่องของ performance ที่สูง
• สนับสนุน LLM model ต่าง ๆ ซึ่งดู model ได้ หรือที่ Hugging Face ก็ได้

มาลองติดตั้งและใช้งาน LLM บน local ดีกว่า

เพียงเท่านี้ก็สามารถใช้งาน Local LLM ได้แล้ว
โดยที่ยังมี API server ให้อีกด้วย มีทั้ง HTTP และ WebSocket
ซึ่งจะ compatibility กับ OpenAI API ดังนั้นการปรับเปลี่ยนจึงสะดวกยิ่งขึ้น

มาลอง Start API Server กัน

จากนั้นก็ลองเขียน code ใช้งานผ่าน openai library กัน

เพียงเท่านี้ก็ใช้งานได้แล้ว
ลองใช้งานกันดูครับ

ปัญหา
ต้องการทำการ screenshot หรือ capture หน้า web ที่ต้องการในทุก ๆ วัน
และต้อง capture หน้าจอแบบเต็มหน้าจอ หรือ ให้ scroll ไปจนครบทุกหน้า

วิธีการที่ใช้งานแบบง่าย ๆ

เนื่องจากใช้งาน Playwright อยู่พอดี ก็ใช้งานไปเลย
ด้วยคำสั่งง่าย ๆ ดังนี้

จากนั้นก็ตั้ง schedule job ในการ capture หน้าจอตามที่ต้องการ
ทำแบบง่าย ๆ กันเลย

RESP Protocol หรือ REdis Serialization Protocol
เป็น protocol ที่ Redis ใช้ในการติดต่อสื่อสารกัน
โดยมรเป้าหมายดังนี้

• ง่ายต่อการ implement
• ทำงานรวดเร็ว
• คนทั่วไปสามารถอ่านเข้าใจได้ง่าย

โดยข้อมูลที่ serialize ได้มีหลายหลายชนิดทั้ง integer, string และ array
ดังนั้นเพื่อความเข้าใจ มาลองศึกษา และ เขียน code สร้างขึ้นมาเองแบบง่าย ๆ

เริ่มด้วยรูปแบบพื้นฐานของ protocol ก่อน

• ใช้งาน TCP ในการติดต่อสื่อสาร
• เป็นการติดต่อสื่อสารแบบ request-response model (synchronous)
• มีรูปแบบการรับส่งข้อมูลง่าย ๆ

รูปแบบการรับา่งข้อมูล เป็นดังนี้

• * บอกจำนวนของ argument ที่ส่งมา เช่น *2 คือ argument 2 ตัว เช่น $get counter เป็นต้น
• $ คือจำนวน byte ของ argument
• \r\n บอกการจบหรือสิ้นสุด

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

มาลองเขียน code ด้วยภาษา go เพื่อสร้าง RESP server กันดีกว่า

ทำการ start TPC server ขึ้นมา
เพื่อรับ connection ของ client ผ่านทาง Redis-cli ปกติ
จากนั้นทำการ response กลับไปด้วยคำว่า OK
โดยมีรูปแบบคือ +OK\r\n

• + คือ type string
• - คือ error
• : คือ integer

ตัวอย่าง code แบบง่าย ๆ เพื่อให้ทำงานตามที่ต้องการ

เมื่อมีการ connect มาจาก Redis-cli จะเป็นดังนี้

ลองศึกษาไปทีละนิดทีละหน่อย ด้วยการเขียน code
ก็ทำให้เข้าใจมากขึ้นเช่นเดียวกัน
ลองเขียนเล่นกันดูนะครับ

จากการเปรียบเทียบ performance ของภาษาโปรแกรมต่าง ๆ ในสมาคม programmer
ด้วย Prime number ซึ่งใช้งาน algorithm ที่ชื่อว่า The sieve of Eratosthenes
ก็เลยลองไปดู code นิดหน่อย
เนื่องด้วยไม่ค่อยได้เขียนภาษาต่าง ๆ มากนัก
เลยหยิบมาพวกภาษา Go และ Java มาดูหน่อย ว่าเขียนอย่างไร ?

เริ่มด้วยภาษา Go พบว่าทำงานช้า เช่น

• การ allocate slide ซึ่งไม่ทำการ preallocate ทำให้ช้า
• ตามธรรมาชาติของ go สามารถทำพวก go routine และ go channel ได้
• มีการเขียน file สำหรับการบันทึกผล

ดังนั้นลองเปลี่ยน code นิดหน่อย ทำเพียงเอาการบันทึกผลลงไฟล์ออกไป ได้ประมาณนี้

ส่วน Java นั้นที่ผลการทำงานเร็วมาก ก็เลยเอาส่วนของบันทึกผลออกไป
กับเปลี่ยนการ initial ข้อมูลใน array ของ boolean ให้เป็น true ทั้งหมดนิดหน่อย
ได้ผลการทำงานดังนี้

ในส่วนของ C# ก็เอาส่วนบันทึกผลลงไฟล์ไปเช่นกัน
กับเปลี่ยนการ initial ข้อมูลใน array ของ boolean ให้เป็น true ทั้งหมดนิดหน่อย
ได้ผลการทำงานดังนี้

ต้องดูว่า เราจะเอาการบันทึกผลลงไฟล์มาวัดกันหรือเปล่า เท่านั้นเอง
ว่าง ๆ เลยลองปรับปรุง code ดูนิดหน่อย สนุกดีนะครับ

ทาง Microsoft ได้ปล่อย MarkitDown library สำหรับภาษา Python
สำหรับการแปลงข้อมูลจากไฟล์ต่าง ๆ มาอยู่ในรูปแบบของ Markdown
เพื่อให้สามารถนำไปใช้งานต่อได้ง่าย ๆ
เช่นการ indexing ข้อมูล และ การวิเคราะห์ข้อมูล เป็นต้น

โดยจะสนับสนุนไฟล์ต่าง ๆ ดังนี้

• กลุ่มของ Microsoft Office
• PDF ซึ่งใช้งาน library ชื่อว่า pdfminer
• รูปภาพ ทั้งการดึงค่า EXIF metadata และ OCR
• เสียง
• HTML
• รวมทั้งพวก text-based format เช่น CSV, JSON และ XML เป็นต้น

การใช้งานก็ง่ายมาก ๆ เพียงแค่ติดตั้ง
จากนั้นก็เขียน code ใช้งานเลย

หรือใช้งานผ่าน uvx ได้เลย

แถมยังทำงานร่วมกับ LLM provider ได้อีกด้วย
เช่นการอ่านและอธิบายข้อมูลจากไฟล์รูปภาพ

ผลการทำงานเป็นดังนี้

ลองใช้งานกันดูครับ

พอดีทำการ deploy ระบบงานที่ใช้งาน Memcached
เพื่อจัดเก็บ caching หรือข้อมูลชั่วคราว
แต่จำไม่ได้ว่า จะดูข้อมูลต่าง ๆ ของ Memcached
หรือทำการ set/get ข้อมูลอย่างไร ผ่าน terminal
ซึ่งลืมทุกครั้ง เลยจดบันทึกกันลืมไว้นิดหน่อย

ปล. Memcached มันเป็น key-value แบบง่าย ๆ ในยุคเริ่มต้น web 2.0 (เก่าเยอะหน่อย)
แต่ก็ยังใช้งานได้ดีอยู่ในระดับหนึ่ง

มาใช้งานผ่าน terminal กัน

ปกติจะใช้งานผ่าน telnet กันเลย
แต่ปกติใช้งานผ่าน netcat จะง่ายกว่า
จึงทำการบันทึกกันลืมไว้นิดหน่อย
ประกอบไปด้วย

• ใช้งานด้วย command ทั่วไปที่ใช้งานคือ set, get, delete และ flush_all
• ใช้งาน stats command เพื่อดูข้อมูลใน server เช่นจำนวน key และสถิติการใช้ command ต่าง ๆ

ใช้งานผ่าน netcat ดังนี้

ไม่เคยจำได้เลย จึงจดไว้

จากข่าวการเปิดให้ใช้งาน GitHub Copilot for VS Code ได้แบบฟรีนั้น
ช่วยให้คนใช้งานเข้าถึงได้ง่ายขึ้น
เพียงแค่เป็นสมาชิก GitHub เท่านั้น
สามารถใช้ได้โดยไม่ต้อง subscription หรือผูกบัตรใด
แต่ว่ามี limit การใช้งานนะ ถ้าอยากใช้เพิ่มก็เสียเงิน

Limit ของ Copilot free มีดังนี้

• 2,000 code complete ต่อเดือน
• 50 chat request ต่อเดือน
• สามารถเลือกใช้ model ได้ทั้ง GPT-4o และ Claude 3.5 sonnet ถ้าอยากใช้ o1 และ gemini ต้องใช้ pro plan นะ

ตอนนี้ VS Code น่าจะเป็น AI Code Editor อีกตัว
ลองใช้งานกันดูนะครับ ว่าถูกใจไหม
ยังมีเครื่องมืออื่น ๆ ให้ใช้งานใน VS Code เช่น codium และ continue เป็น
หรือ IDE อื่น ๆ เช่น Windsurf, Cursor และ Zed เป็นต้น
น่าจะทำให้นักพัฒนามีตัวเลือก และ ทางเลือกมากยิ่งขึ้น

Update VS Code กันได้เลย

VS Code ตัวล่าสุดสนับสนุน font Ligatures ใน terminal แล้วนะ

มีโอกาสได้แบ่งปันเรื่องการนำเอา AI มาใช้ในการพัฒนา software
ตั้งแต่การจัดการ requirement
การออกแบบระบบงาน เช่นการเขียน flow และ diagram ต่าง ๆ
มาถึงการพัฒนา ทดสอบ และ deploy ระบบงาน
ว่าสามารถนำมาใช้งานอย่างไรบ้าง ?

ใน Software Development มี Life cycle ดังนี้

• Requirement and Analysis
• Design
• Development
• Testing
• Deployment
• Maintenance

สามารถนำ AI มาใช้งานในแต่ละขั้นตอน
เป้าหมายเพื่อช่วยให้คำแนะนำ และ ช่วยลดงานต่าง ๆ ลงไป
แสดงดังรูป

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

• ในเรื่องของ requirement สามารถนำมาช่วยสร้าง User Story และ ช่วยตรวจสอบว่า requirement ของเรานั้นชัดเจนหรือไม่ แต่จะทำได้ก็กำหนดก่อนว่า คำว่าชัดเจนเป็นอย่างไรก่อน
• ขั้นตอนการออกแบบ เช่น การเขียน diagram ต่าง ๆ เช่น Flow chart, Sequence diagram และ ER diagram โดยสามารถใช้เครื่องมือพวก excalidraw และ database.build เข้ามาช่วยงานพวกนนี้ได้แบบง่าย ๆ
• ในส่วนของ User interface หรือฝั่ง frontend มีเครื่องมือให้มใช้เยอะมาก ๆ เช่น bolt.new และ v0.dev เป็นต้น
• การเขียน code สามารถ generate code ต่าง ๆ รวมทั้ง test case ต่าง ๆ ได้ เช่น การใช้เครื่องมือพวก Aider chat, IDE อย่าง cursor รวมทั้งพวก GitHub Copilot ใน VSCode ก็ช่วยลดงานได้เยอะมาก ๆ แต่ระวังการใช้งานด้วย เพราะว่า บ่อยครั้งมันช่วยการสร้าง แต่การ maintain ละ จะทำอย่างไรต่อไป รวมทั้งเราได้ความรู้หรือเรียนรู้อะไรบ้างหรือไม่ ?
• การ test ก็มีเครื่องมือช่วยในการออกแบบ test case จาก requirement หรือใน test tool ต่าง ๆ มี AI เข้ามาช่วย เช่นใน Postman ก็มี Postbot ให้ใช้งานเป็นต้น

เมื่อใช้งานเครื่องมือต่าง ๆ ได้แล้ว

ในการพัฒนา software นั้น เราสามารถเอา AI ต่าง ๆ มาเป็นหัวใจของระบบงานได้
เช่นการใช้งาน AI Model ต่าง ๆ ผ่าน API ได้เลย
ไม่ว่าจะ mode เสียเงิน หรือ ฟรีก็ตาม
เช่น Llama, phi, gemma model ผ่าน Ollama หรือใช้ model ต่าง ๆ จาก Huggingface ผ่าน LM Studio ก็ได้
หรือเป็นการเพิ่ม knowledge ให้ AI Model ต่าง ๆ ด้วยเทคนิค RAG (Retrieval Augmented Generation)
ที่ต้องเข้าใจเรื่องการทำ

• pre-processing data
• chunking
• embbedding
• vector database
• re-ranking

รวมถึงการทำ fine-tuning model อีกด้วย

ลองใช้งานกันดูครับ น่าสนุกมาก ๆ

ระบบงานต่าง ๆ นั้นจำเป็นต้องทำงานร่วมกับระบบงานอื่น ๆ ผ่านระบบ network
ซึ่งแน่นอนว่า พร้อมพัง เสมอ
ดังนั้นในการออกแบบ พัฒนา และ ทดสอบ
จำเป็นต้องสนใจ และ ใส่ใจมาก ๆ ถ้ามีปัญหาขึ้นมา
จะจัดการกันอย่างไร เพื่อให้ระบบมีความเสถียร ไม่พังง่าย ๆ
หรือไม่เกิดไฟลามทุ่ง คือ ปัญหาเกิดที่หนึ่ง แล้วส่งผลกระทบไปทั่วระบบ !!
ดังนั้นเรื่องของ Resiliency Pattern จึงสำคัญมาก
อาจจะเรียกว่า Design for failure ก็ได้

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

กลุ่มที่ 1 จัดการที่ฝั่งของผู้เรียกใช้งาน หรือ consumer

เมื่อระบบงานที่เราเรียกใช้มีปัญหา เช่น พัง หรือ ช้า
จะไม่ส่งผลต่อผู้เรียกมากนัก หรือ ไม่พังไปด้วยกัน
ยกตัวอย่างรูปแบบที่ใช้จัดการ

• Timeout (มักจะมาพร้อมกันการ retry) เพื่อลดการจองหรือใช้งาน resource ต่าง ๆ นานจนเกินไป
• Circuit breaker หรือตัดก่อนตาย เตือนก่อนวายวอด เป็นการ monitor ตาม rate ของ failure ที่เกิดขึ้น ถ้าถึงจุดที่กำหนดไว้ จะทำการ disable การเรียกแบบชั่วคราว รอจนกว่าปลายทางจะกลับมาทำงานเป็นปกติ จึงจะเรียกไปแบบอัตโนมัติ เพื่อลดการเรียกไปยังปลายทางที่ไม่เสถียร ต้องทำการร่วมกับระบบ monitoring ของระบบ รวมทั้งระบบ alert จะช่วยทำให้เรารู้ทันทีว่าตรงจุดใดในระบบมีปัญหา เพื่อเข้าไปแก้ไขได้ง่ายขึ้น
• Client-load balancing ทางฝั่ง consumer ทำการเลือกได้ว่า จะส่ง request ไปยัง provider instance ไหนเองได้

กลุ่มที่ 2 จัดการที่ฝั่งของผู้ถูกเรียก หรือ provider

เมื่อมี request เข้ามายังฝั่งของ provider มาก ๆ หรือ มากจนเกินไป
ส่งผลต่อ reponse time ของการเรียกใช้งาน
รวมทั้งอาจจะทำให้ระบบงานพังได้ง่าย ๆ
แล้วกระทบคนอื่น ๆ อีก ดังนั้นจึงมีรูปแบบการจัดการ

• Rate limit ทำการกำหนด limit การใช้งานตามเงื่อนไขที่กำหนด เช่น ตามระบบ ตาม ip ตาม user เป็นต้น เราจะเจอกันทุกเดือน !!
• Bulkhead เป็นแนวทางในการแยกส่วนต่าง ๆ ของระบบออกจากกัน เพื่อป้องกันปัญหา casecade failure หรือ ไฟลามทุ่ง นั่นให้ให้พังเป็นส่วน ๆ ไป ส่วนอื่น ๆ ก็ยังคงทำงานได้อยู่ นั่นคือการลดเรื่อง single point of failure
• Load balance ทำงานร่วมกับ health check ของระบบงาน ซึ่งใช้ความสามารถของ load balance เพื่อกระจาย request ไปยัง provider instance ต่าง ๆ แต่ก็ทำการ monitor ด้วยว่า provider instance นั้น ๆ ยังคงมีสุขภาพดีไหมผ่าน health check ถ้าไม่ดี ก็จะไม่ส่ง request ไปนั่นเอง
• Load Shedding หรือ sharding request ทำการจัดการ request เข้ามาช่วง peak load ระบบ provider จะรับมืออย่างไรบ้าง เพื่อให้ request ของแต่ละ user ทำงานตามลำดับความสำคัญได้ เช่น การใช้ priority queue มาช่วยจัดการ กระจาย request ไปตามกลุ่มของงาน หรือการใช้งาน token bucket มาช่วยจัดการเป็นต้น

Reference websites

• Resilience design patterns: retry, fallback, timeout, circuit breaker
• Cloud design patterns that support reliability

คำถาม ใน Playwright นั้น ถ้าเราต้องการ run test case เฉพาะที่เปลี่ยนแปลงเท่านั้น
จะต้อง run อย่างไรบ้าง ?
คำตอบมี 2 แบบคือ

• แบบที่ 1 ใช้ watch mode ใน Playwright UI mode
• แบบที่ 2 ใช้ผ่าน CLI ด้วย option --only-changed

ในแบบแรกใช้ผ่าน Playwright UI Mode ไม่น่ามีอะไร
แต่แบบที่สอง ใช้งานผ่าน CLI​
ซึ่งน่าจะใช้งานบ่อยได้การ run ทั้งหมด หรือใน pipeline ของระบบ CI/CD
ปกติจะใช้งานด้วยคำสั่ง

แต่ถ้าเราต้องการ run เฉพาะ test case ที่ทำการเปลี่ยนแปลงเท่านั้น
โดยใน Playwright จะทำการตรวจสอบผ่าน git commit นั่นเอง
ด้วยคำสั่ง

จะทำการตรวจสอบการเปลี่ยนแปลงปัจจุบันกับตำแหน่ง HEAD ใน git บนเครื่องเรานั่นเอง

ถ้าเราทำงานแบบ feature branch แล้วต้องทำการ merge ไปยัง main branch เสมอ
ก่อนการ merge เราต้องทำการ run test ใน branch ของเราก่อนเสมอ
จะทำการ run ด้วยคำสั่ง

หรือนำเอาการ run test ไปใส่ใน pre-commit ก็ได้
จะได้ run test ทุก ๆ ครั้งที่ commit ได้เลย
และ run เฉพาะ test case ที่มีการเปลี่ยนแปลงเท่านั้น

เพิ่มเติมกับการ run เฉพาะ test case ที่ failure จากการ run ครั้งล่าสุดด้วย --last-failed

ลองใช้งานกันดู สะดวกสบายดี

Reference websites

• Five Playwright CLI features you should know
• Playwright test cli
• Run Only Changed Test Files Since Last GIT Commit in Playwright ?
• Is it possible to run only Playwright Tests that changed in GitHub actions on a pull request ?

ตั้งแต่ Spring Boot 3.1 ที่สนับสนุนการทำงานร่วมกับ Docker compose
ไม่ว่าจะเป็น compose.yml หรือ docker-compose.yml
ช่วยให้สามารถ build และ run ได้แบบอัตโนมัติเลย
แต่ในการใช้งานนั้น Docker compose รองรับการทำงานแบบหลาย ๆ ไฟล์ได้
ทั้ง composition/merge (include) และ extend/override กันด้วย
โดยใน Spring Boot 3.4 ที่ออกมาใหม่ ก็สนับสนุนด้วยเช่นกัน
ดังนั้นมาลองใช้งานกัน

โดยใน project ของเราเพิ่ม Docker compose support มาได้เลย

จากนั้นในไฟล์ application.yml ก็ทำการ config ได้ง่าย ๆ ดังนี้

• ไฟล์แรกจัดการ database
• ไฟล์ที่สองจัดการ cached data

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

Platform Engineering นั้นถูกออกแบบ สร้าง และเป็นระบบแบบ self-service
เน้นที่การส่งมอบ software ตาม Software development life cycle (SDLC)
ให้เกิด productivity และ และประสิทธิภาพของทีมมากที่สุด
โดย platform นี้จะเปิดโอกาสให้

• เลือกเครื่องมือ และ framework ที่เหมาะสม
• เลือกหรือลองขั้นตอนการทำงานให้เหมาะสม
• เป็น centralized platform ที่ต่อไปจะทำให้เกิดความเป็นมาตรฐานต่อไป
• มี reuse component ให้ใช้งาน ไม่ต้องทำซ้ำ
• คนทำงานสามารถทำงานร่วมกันได้ง่าย ลดปัญหาคอขวด หรือ คนกลาง
• No-one-size-fit-all

เป้าหมายหลัก ๆ ของ Platform Engineering

• การทำงานแบบอัตโนมัติ
• ขั้นตอนการทำงานที่เป็นมาตรฐาน
• Self-service
• Developer-centric design
• Scalability and Reliability
• Collaboration ระหว่างทีมให้มากยิ่งขึ้น ลดช่องว่างระหว่างทีมให้น้อยลง

เนื่องจาก platform นี้ใช้งานใน SDLC
ดังนั้นคนที่ควรมีส่วนร่วมในการออกแบบและสร้างระบบนี้
คือคนที่อยู่ในแต่ละขั้นตอนนั้นเอง
เพื่อสร้างให้ตรงกับความต้องการหรือเป้าหมายของระบบนั่นเอง

สิ่งที่สำคัญของ Platform Engineering

• Infrastructure as Code (IaC)
• Continuous Integration and Delivery ตั้งแต่ code, test และ deploy เป็นต้น
• Observability and monitoring เช่น log, trace, metric, exception tracking และ alert system
• Containerization เช่น Docker และ Kubernetes เป็นต้น

ผลที่ตามมาของการใช้งาน Platform Engineering

• Waiting time ที่น้อยลง
• คุณภาพของ software ที่สูงขึ้น
• Delivery time หรือ lead time ที่ลดลง ทำให้ time to market เร็วขึ้น
• เพิ่มความพึงพอใจของ developer ให้มากขึ้น รวมทั้งเพิ่มเรื่อง Developer Experience (DX)
• ลด technical debt ลง
• ปรับปรุงเรื่องของ security และ compilance ต่าง ๆ ให้ดีและมีมาตรฐานมากยิ่งขึ้น

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

เห็นผ่านใน feed เลยนำมาเขียนบันทึกไว้หน่อยว่า มันคืออะไร กับ Watergile
ซึ่งมี manifesto ด้วยดังนี้

• Everything is ASAP (as soon as possible)
• Everything id High priority
• Overtime over Planning
• Excel is enough !
• Management over Communication

ในการทำงานมี DOAD (Definition Of Almost Done) อีกด้วย !!

น่าสนใจดีนะ

จากเรื่อง Fallacies of distributed computing นั้น
ซึ่งอธิบาย 8(7+1) ข้อ ของเรื่องเข้าใจผิดเกี่ยวกับระบบ Distributed
มาดูในข้อแรกกันคือ The network is reliable (ความน่าเชื่อถือ)
ว่าเป็นอย่างไร มีปัญหาอะไร และ วิธีการแก้ไขทำอย่างไรบ้าง ?
มาเริ่มกันเลย

ระบบ network นั้นเกิดมาเพื่อพร้อมพังได้เสมอ
ยิ่งระบบงานมีการแบ่งแยกการทำงานต่าง ๆ ออกมา
แล้วต้องติดต่อสื่อสารกัน เช่น

• Frontend
• Backend
• Service ต่าง ๆ
• Database
• Caching

ปัญหาที่สามารถเกิดขึ้นได้ประกอบไปด้วย

• ปัญหาทางด้าน hardware
• ปัญหาทางด้าน software
• ปัญหาทางด้าน security
• ปัญหาของ environment ต่าง ๆ
• ปัญหาจากการโดนโจมตีระบบ

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

ตัวอย่างของวิธีการแก้ไขหรือรับมือ เช่น

• Timeout
• Retry พร้อมกับ indempotent
• Circuite breaker
• Rate limit
• ถ้าเป็นระบบ queue ก็ต้องจัดการเรื่อง acknowledge ระหว่าง producer และ consumer ให้ดี หรือต้องจัดการพวก Dead letter queue เพื่อการันตีว่า message ต่าง ๆ สามารถส่งและรับได้อย่างถูกต้อง

ลองดูว่าระบบงานที่เราออกแบบได้วางแผนเรื่องเหล่านี้ไว้หรือไม่ ?

มาทำความรู้จักกับ Keyv for JavaScript ซึ่งจัดการข้อมูลแบบ key-value
โดยสามารถเปลี่ยนที่จัดเก็บได้ด้วย apdater ต่าง ๆ
ประกอบไปด้วย

• Redis
• ValKey
• MongoDB
• SQLite
• PostgreSQL
• MySQL
• etcd
• Memcached
• หรือทำการ custom adapter ได้อีกด้วย

และยังมีการบีบอัดข้อมูลที่จัดเก็บ เช่น gzip และ brotli เป็นต้น
มาเริ่มทำความรู้จักกัน

ลองใช้งานกันเลย

• ใช้งาน Redis หรือ SQLite ในการจัดเก็บข้อมูลผ่าน Adapter
• ใช้งาน namespace เพื่อจัดการข้อมูลแต่ละกลุ่ม
• การ monitoring ผ่าน Hook

ลองใช้งานกันดูครับ
ในภาษาอื่น ๆ ก็เห็นพัฒนาขึ้นมาเช่นเดียวกัน เช่น Keyv for Rust เป็นต้น

วันนี้ว่าง ๆ หลังจาก share เรื่องของการพัฒนาและทดสอบระบบงานมา
จึงมาดูเรื่องของการใช้งาน Claude’s Model Context Protocol (MCP)
สำหรับการทดสอบระบบงานทั้ง web และ API ด้วย Playwright กันหน่อย
ว่าจะช่วยอย่างไรได้บ้าง ?

ก่อนอื่นก็ลองไปดูก่อนว่า มีใครทำ Playwright + MCP server ไว้หรือไม่ ?
ถ้าไม่มีก็จะลองทำเอง
โดยไปหาดูได้ที่ List of MCP Server สำหรับ browser automation
ก็พบว่ามีคนทำไว้ให้ลองเล่น และ ใช้งานด้วย ทั้ง

• Web
• API

ดังนั้นลองใช้งานกันหน่อย

MCP server สำหรับ Playwright ที่ใช้งานคือ @executeautomation/playwright-mcp-server
ในการใช้งานในเครื่องของเราต้องมี NodeJS ก่อน
จากนั้นทำการเพิ่ม config file ใน Claude Desktop App ดังนี้

จากนั้นก็ลองมาเขียน prompt เพื่อสั่งให้ทำการทดสอบระบบ web application แบบง่าย ๆ กัน
ว่าทำอย่างไร

ผลที่ได้คือ

• ทำการเปิด browser ขึ้นมา และเข้าไปยัง url ที่กำหนดไว้
• ทำการ generate test script ของ Playwright มาให้พร้อมทำ execute ให้เลย
• ทำการตรวจสอบตามสิ่งที่เขียนไว้ใน prompt ให้เลย พร้อมแจ้งผลการตรวจสอบ

แสดงดังรูป

ได้ผลการทำงานที่น่าสนใจมาก ๆ
น่าจะเป็นอีกทางเลือกหนึ่งของการทดสอบระบบงานกันเลยทีเดียว

จากนั้นลองทดสอบระบบ REST API กันหน่อยว่าทำงานได้หรือไม่ ?
ได้ผลดังนี้

ลองใช้งานเล่นกันดูครับ
น่าจะช่วยให้การทดสอบสนุกมากยิ่งขึ้น