ในการออกแบบ REST API นั้น มักจะออกแบบในรูปแบบของ OpenAPI หรือ Swagger กัน
มีคำถามใน course Microservices workshop ว่า
ถ้าเป็น Async หรือพวก messaging หรือ Event-based
ที่ใช้งาน RabbitMQ, Apache Kafka
จะทำการออกแบบในรูปแบบใด
โดยหนึ่งในแนวทางที่ผมใช้งานอยู่คือ AsyncAPI

โดยสามารถเขียนและออกแบบรูปแบบของ message/event
ที่ producer/publisher ส่งไปยัง messaging
และ message ที่รับมาทำงานโดย consumer/subscriber
ตัวอย่างดังนี้

จากเอกสารหรือ specification ที่ออกแบบนั้น
สามารถนำไปสร้างสิ่งต่าง ๆ ดังต่อไปนี้ได้

• มี Async Studio สำหรับการเขียนเอกสาร และมีการ validate ให้ด้วย
• สร้างเอกสาร
• ทำการ generate code ออกมาได้ทั้งฝั่ง producer และ consumer
• มีชุดของเครื่องมือให้ใช้งานเพียบ

เป็นอีกแนวทางที่น่าสนใจ
สำหรับ Design-First ของการออกแบบและพัฒนาระบบงาน
ลองใช้งานกันดูครับ

หลังจากอ่านบทความเรื่อง The evolution of Figma’s mobile engine: Compiling away our custom programming language
เล่าถึงการเปลี่ยนแปลง code ของระบบ mobile engine ของ Figma ด้วยภาษา Skew
ทำหน้าที่ compile code ให้ทำงานได้ทั้ง web และ mobile
มาดูเหตุผล แนวคิดและแนวทางในการย้ายมายังภาษา TypeScript
ว่ามีอะไรที่น่าสนใจบ้าง

ในช่วงแรก ๆ ของการพัฒนาระบบด้วยภาษา Skew ที่พัฒนาขึ้นมาใช้เอง

ยังคงใช้งานดี ระบบทำงานได้ดี
เมื่อระบบใหญ่ขึ้น ทีมใหญ่ขึ้น ปัญหาก็เริ่มตามมา
ซึ่งเคยลองเปลี่ยนมาใช้งานภาษา TypeScript แล้วแต่ performance ไม่ดีเท่ากับของเดิมจึงล้มเลิกไป
แต่เมื่อเวลาผ่านไป technology ดีขึ้น เช่น WebAssembly ที่ทำงานบน web browser ได้
ทำให้ย้าย code ที่เป็นภาษา C+ มาทำงานได้เลย
โดยที่ performance ไม่ได้ลดลง
จึงทำให้มาสนใจอีกครั้ง
รวมทั้งมีปัญหาต่าง ๆ ตามมาเช่น

• การทำงานร่วมกับ library หรือเครื่องมือต่าง ๆ ยาก เพราะว่าใช้ภาษาที่สร้างใช้กันเอง
• เสียเวลาในการ training พนักงานใหม่ ๆ ที่เข้ามาเยอะมาก

ดังนั้นจึงมาใช้งาน TypeScript อีกครั้ง
ซึ่งมีข้อดี เช่น

• เขียน code ร่วมกัน หรือ ทำงานร่วมกันทั้งภายในและภายนอกได้ง่ายขึ้น เป็น static type รวมทั้ง package management ต่าง ๆ ครบ
• มี community ที่แข็งแรงและใหญ่ ทำให้มีเครื่องมือช่วยเหลือเยอะ ทั้ง linter, bundler และ static type analysis เป็นต้น
• มีความสามารถสมัยใหม่ ๆ เช่น async-await และเรื่องของ type system ที่มีความยืดหยุ่น
• ง่ายต่อการ tranining พนักงานใหม่ ๆ ขยายทีมได้ง่าย รวมทั้งการทำงานร่วมกันระหว่างทีม

มาดูขั้นตอนการย้าย code มาเป็น TypeScript

ขั้นตอนที่ 1 ทำการสร้าง transpiler เอง เพื่อแปลง code จาก Skew ไปยัง TypeScript

จากนั้นทำการ push ไปยัง GitHub เพื่อทำให้นักพัฒนาเห็นว่า code ของ TypeScript เป็นอย่างไร
ทำการ build code ด้วย esbuild
ส่วนผู้ใช้งานยังคงใช้งานจาก JavaScript ที่แปลงมาจาก Skew เหมือนเดิม
โดยนักพัฒนายังเขียน code ด้วย Skew
แสดงดังรูป

ขั้นตอนที่ 2 ทำการ build JavaScript จากนั้นก็ทำการ deploy

หลังจากที่ได้ code TypeScript มาก็ทำการ build
ทำการ run unit test ให้ผ่าน
จากนั้นก็ทำการ deploy ให้ผู้ใช้งานใช้ จะค่อย ๆ ทำไป
โดยนักพัฒนายังเขียน code ด้วย Skew
แสดงดังรูป

ขั้นตอนที่ 3 มาเขียน code ด้วย TypeScript

โดยจะตัดการ generate code แบบอัตโนมัติทิ้งไป
รวมทั้งผู้ใช้งานก็มาใช้งาน code จาก TypeScript ทั้งหมด
แสดงดังรูป

เป็นแนวคิดและแนวทางที่น่าสนใจมาก ๆ
ในบทความยังอธิบายเรื่องของการแปลง code ด้วย
ลองอ่านเพิ่มเติมกันดูครับ

มีโอกาสไปแบ่งปันความรู้ในเรื่องของการทดสอบระบบงานที่ Skooldio
โดยใช้ชื่อ course ว่า Full Stack Automation Testing จำนวน 2 วัน
เพื่อให้เห็นภาพของการทดสอบในขั้นตอนการส่งมอบ software ว่าเป็นอย่างไรบ้าง
จากนั้นทำการออกแบบ และ เข้าใจรูปแบบของการทดสอบ
ฝึกใช้งานเครื่องมือการทดสอบต่าง ๆ
จากนั้นก็ลง workshop กันต่อไป

หัวข้อหลัก ๆ ที่แบ่งปันไปประกอบไปด้วย

• ปัญหาในการทดสอบระบบงาน
• ปัญหาของการปรับเปลี่ยนจาก manual มา automation
• เรา focus ที่ Quality หรือ Quantity มากกว่ากัน
• เรียนรู้ขั้นตอนการส่งมอบ software ว่าเป็นอย่างไร
• แนวทางการทดสอบ ผมจะเรียกว่า ทำก่อนค่อยคิด หรือคิดก่อนแล้วค่อยทำ
• Test-First vs Test-Last vs Test-Later
• การทดสอบที่ดีเป็นอย่างไร
• การออกแบบ test case ใน level ต่าง ๆ
• การใช้เครื่องมือใน test level ต่าง ๆ
• การสร้างระบบ Continuous Integration เพื่อทดสอบอย่างต่อเนื่อง

สิ่งที่เน้นเยอะ ๆ มีดังนี้

การได้มาซึ่ง test case ตามขั้นตอนต่าง ๆ ของการส่งมอบ software เช่น

• Requirement ได้ acceptance test ไหม
• Architecture ได้ integration test ไหม
• Design ได้ function/flow/story test ไหม
• Implementation ได้ unit test ไหม

เพื่อช่วยให้เราเข้าใจเกี่ยวกับ สิ่งที่กำลังจะลงมืออย่างชัดเจนมากยิ่งขึ้น
แต่จะทำกับ requirement ทั้งหมดเพียงครั้งเดียวคงไม่ไหว
ดังนั้นการทำแบบ iterative and incremental จึงน่าสนใจขึ้น

รูปแบบของ test ที่ดี ประกอบไปด้วย

• Fast
• Isolate
• Repeat
• Understand

ต่อมาถ้าจะให้การทดสอบละเอียดมากยิ่งขึ้น ต้องเข้าใจ Architecture ด้วย

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

โดยจะแนะนำรูปแบบของการทดสอบ ซึ่งประกอบไปด้วย

• End-to-end test
• Integration test
• Component/Isolated test
• Contract test
• Unit test

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

จากนั้นก็เลือกเครื่องมือของแต่ละส่วน และ การทดสอบแต่ละแบบ

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

• ในฝั่งของ API พาใช้งาน Postman + newman รวมทั้งเขียน code สำหรับการทดสอบภายในระบบงาน
• เขียน code ทดสอบด้วย JavaScript ด้วย library ต่าง ๆ เช่น jest, supertest และ nock เป็นต้น
• ไล่จาก blackbox testing ไปยัง gray และ white box testing
• การทดสอบฝั่ง UI เช่น Playwright เป็นต้น ซึ่งทดสอบทั้ง web browser testing และ visual testing
• การจัดการ dependency ต่าง ๆ เช่น Mock API server และ Database รวมทั้งเรื่องของ data test ซึ่งมีความสำคัญอย่างมาก

ปิดด้วยการรวมทั้งหมดมาอยู่ใน pipeline ของระบบ Continuous Integration and Delivery ต่อไป

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

สิ่งที่พบเจอบ่อย ๆ สำหรับการเขียน code คือ
ไม่ยอมเขียนเอกสารอธิบายการทำงานของ code
ถ้า code อ่านรูปเรื่องก็ว่าไปอย่าง
ยิ่งต้องมาทำงานเป็นทีมยิ่งสนุกไปกันใหญ่
ตัวอย่างเช่น ภาษา JavaScript ยิ่งไม่ค่อยเขียนกัน
ใช้งานใน VS Code ก็ไม่ช่วยแนะนำอะไรเลย
ทั้งไม่อธิบาย function/module รวมทั้ง type ต่าง ๆ

หลาย ๆ คนเลยอยากจะเปลี่ยนไปเขียนด้วย TypeScript ด้วยซ้ำ
ดังนั้นจึงแนะนำ หรือ พาทำก่อนคือ เขียนเอกสารอธิบาย code ด้วย JSDoc ก่อน
เพื่อช่วยอธิบายการใช้งาน code ทั้ง

• module
• function

ส่วน README อธิบายภาพรวมก็ยังคงต้องมีเช่นเดิม
ดังนั้นมาหัดเขียนกันเถอะนะครับ จะได้ไม่เป็นภาระต่อไป

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

ทำการเขียนอธิบาย function ว่าทำงานอะไร

• parameter แต่ละตัวมี data type อย่างไร ถ้าเป็น object ก็ระบุรายละเอียดไป
• มียกตัวอย่างการใช้งานอีกด้วย

ในการเขียน code นั้น ผู้ใช้งานก็จะเห็นแบบนี้ใน VS Code
น่าจะดีกว่าเดิมไหม ?

แถมยังเขียนด้วย Markdown format ได้อีก
ลองฝึกใช้งานกันดู

จากการแบ่งปันเรื่องของ Microservices และ Software architecture นั้น
มีคำถามเกี่ยวกับการ shared code ระหว่างระบบงาน
ว่าเราควรจัดการอย่างไรบ้าง
จึงทำการสรุปแนวทางที่แนะนำไว้นิดหน่อย ดังนี้

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

รูปแบบที่ 1 ทำการ copy ไปใช้งานจากต้นฉบับเลย (copy-and-paste)

ตัวอย่างเช่นการ copy จาก project หนึ่งไปยัง project หนึ่ง
หรือจาก service หนึ่งไปยัง service หนึ่ง นั่นเอง
สามารถใช้งานได้ปกติ
แต่ถ้า code ชุดนั้นมีการเปลี่ยนแปลง ต้องตามไปเปลี่ยนแปลงหรือไม่
ถ้าใช้ต้องเปลี่ยนหมดเลย มันสร้างความยุ่งยากและวุ่นวายหรือไม่
แต่ถ้าการเปลี่ยนแปลงของแต่ละที่ที่ copy code ไป
มันไม่เกี่ยวข้องกัน วิธีนี้ก็น่าสนใจมาก ๆ นะ

รูปแบบที่ 2 สร้างเป็น library ไว้ตรงกลาง (shared library)

อาจจะเริ่มจากพวก common/util ที่ใช้งานใน project/service เดียวกันก่อน
แต่เมื่อเริ่มใช้ซ้ำ ๆ หรือ เหมือนกันในหลาย project/service แล้ว
และเมื่อเปลี่ยนแปลง จะต้องเปลี่ยนแปลงในทุก ๆ ที่ที่ใช้งาน
ก็ให้นำออกมาสร้างเป็น shared library กันต่อไป
แล้วนำมาไว้ตรงกลางที่เป็น standard ของการจัดการในแต่ละภาษาโปรแกรม เช่น

• สำหรับภาษา Java สร้างเป็น JAR file หรือนำไป publish ขึ้น Maven/Gradle repository server (internal/public)
• สำหรับ JavaScript เก็บไว้ใน NPM package
• สำหรับ Python เก็บไว้ใน pip

การใช้งานแบบนี้จะผูกมัดกับระบบงานนั้น ๆ มาก
ดังนั้นควรจัดการเรื่องของ versioning ให้ดี
รวมทั้งการทดสอบใช้ครอบคลุม มิเช่นนั้นแล้ว ผลกระทบจากการเปลี่ยนแปลงจะเยอะมาก ๆ
ยิ่งมีการใช้งาน shared library เยอะ ๆ
ยิ่งต้องระมัดระวังเรื่องขนาดของ project ที่จะใหญ่ขึ้นอีกด้วย

ใช้ได้กับระบบงานที่พัฒนาด้วยภาษาโปรแกรมเดียวกันเท่านั้น

รูปแบบที่ 3 แยกออกมาเป็น service กันเลย (Shared service)

สร้างเป็น service ใหม่ แยกออกมาเป็นอีก process เป็นอิสระต่อระบบงานอื่น ๆ
ช่วยให้ระบบงานต่าง ๆ สามารถใช้งานได้
โดยไม่ต้องพัฒนาด้วยภาษาโปรแกรมเดียวกัน
ลดค่าใช้จ่าย ๆ และการดูแลตามที่ฝั่งคนคิดพูดให้ทาง management ฟัง !!

แต่ต้องระวังเรื่องปัญหาต่าง ๆ ของ shared service เช่นกัน
ยกตัวอย่างเช่น

• performace การใช้งาน เพราะว่าเรียกผ่านระบบ network ไม่ใช้ process เดียวกันแล้ว ดังนั้น overhead จะสูง
• side effect จากการเปลี่ยนแปลง shared service ดังนั้น กระบวนการพัฒนา ทดสอบ และ deploy มีความสำคัญมาก ๆ ต้องมั่นใจว่า การเปลี่ยนแปลงไม่กระทบต่อผู้ใช้งานทุกคนด้วยเสมอ
• ปัญหาของการ scale เนื่องจากใช้งานจาก service มากมาย
• ที่สำคัญมาก ๆ อย่าให้ shared service เป็นมะเร็ง service คือ นำเอา logic ของผู้ใช้งานมาใส่ใน shared service จะสูญเสียความเป็นอิสระไป มันจะเป็นปัญหาแบบตายผ่อนส่ง ไม่เจอในช่วงแรก ๆ นะครับ

เป็น 3 รูปแบบที่แนะนำไว้
ซึ่งมีอีกหลายรูปแบบที่เกิดขึ้นมา เช่นใช้งาน sidecar เป็นต้น

ลองนำไปประยุกต์ใช้งานดูครับ
ว่ารูปแบบไหนที่เหมาะสมในแต่ละ use case ของเรา

ทาง Vercel ส่ง email มาแจ้งว่า
ระบบสนับสนุนระบบที่พัฒนาด้วย Python 3.12 และ Rail แล้ว
ตามจริงก็สนับสนุน version ก่อน ๆ มาแล้ว แต่ไม่ได้ใช้ (ตอนนี้ต้องใช้จริง ๆ แล้ว)
จึงลองทำการสร้างงระบบงานง่าย ๆ และ deploy ดูหน่อย
โดยระบบงานพัฒนาด้วยภาษา Python
กับ Web app ด้วย Flask 3
มาเริ่มกันเลย

เริ่มด้วยสร้าง project แบบปกติ
สร้าง requirements.txt ใส่ library Flask 3.0 เข้ามา

จากนั้นทำการสร้างไฟล์ vercel.json เพื่อทำการ config route ของระบบงาน
เพื่อให้มายังไฟล์ /api/index.py ดังนี้

จากนั้นก็ push code และจะทำการ auto deploy ดังรูป

จากนี้ก็สามารถ deploy ระบบใช้งานแบบง่าย ๆ ได้แล้ว

หลังจากที่แบ่งปันเรื่องการใช้งาน Docker ไปนั้น
มีคำถามเกี่ยวกับ Profile ใน Docker compose
ซึ่งไม่ค่อยได้ใช้งานเท่าไร
จึงทำการอธิบายถึงปัญหา และที่มาของ feature นี้
รวมทั้งการใช้งาน
ดังนั้นมาเริ่มกันเลย

แนวคิด หรือ ปัญหาหลัก ๆ คือ

ถ้าต้องการใช้งาน Docker compose file ใน environment ต่าง ๆ เช่น

• Dev
• Test
• Prod

ที่มีความแตกต่างกัน ทั้งเรื่องของ service ที่ start !!
จะทำการจัดการอย่างไร ?

วิธีการจัดการ ?

สร้างไฟล์แยกตาม environment ไปเลย หรือ ทำการ overrided เอาก็ได้
หรืออีกวิธีการคือ การใส่ profiles เข้าไปในแต่ละ service ไปเลย
ยกตัวอย่างเช่น

• ในการใช้งานทั่วไป จะไม่สร้าง service ชื่อว่า php-myadmin มาจัดการ database จะสร้างเฉพาะ profile = debug เท่านั้น

สามารถ run ด้วยการระบุ profile ดังนี้

ถ้าต้องการระบุหลาย ๆ profile ทำดังนี้

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

จากบทความเรื่อง System tests have failed ที่เขียนโดย DHH หรือ คุณ David Heinemeier Hansson
ทำการเขียนเรื่อง System test ของระบบ HEY.com
ซึ่งมีมากกว่า 300 ตัวพบว่า
ผลลัพธ์ที่ได้มันช่วยทดสอบระบบได้ดี มีความมั่นใจ
แต่เมื่อมีเยอะ ๆ แล้ว มันช้า พังง่าย (broken test)
ผลลัพธ์การทดสอบไม่ถูกต้อง (false negative เยอะ)
ดังนั้นการทดสอบด้วย System test เพียงอย่างเดียว ไม่น่าเป็นคำตอบที่ถูกต้อง
ดังนั้นเรามาดูในรายละเอียดกัน

ปัญหาการทดสอบนี้ ก็มีคำถามมาจาก course Fullstack Automation Software Testing ที่ Skooldio เช่นกัน
จึงคิดว่าบทความนี้น่าจะตอบได้ดีทีเดียวครับ

ก่อนอื่นทำความรู้จักกับ System test ของ RoR (Ruby on Rail) กันก่อน

เป็นการทดสอบที่เพิ่มเข้ามา ประกอบไปด้วย

• Capybara
• Selenium
• Run บน web browser แบบ headless

เราอาจจะเรียกได้ว่าเป็น UI testing นั่นเอง หรือเป็นการทดสอบแบบ black box
เป็นการทดสอบในมุมมองของผู้ใช้งานทั่วไป
จึงทำให้เรามีความมั่นใจต่อการทดสอบสูงมาก ๆ
และที่สำคัญคือ ถ้ามีการเปลี่ยน logic หรือ business process ภายในแล้ว
จะไม่กระทบต่อการทดสอบมากนัก หรือ ไม่กระทบเลย
นั่นก็เป็นอีกหนึ่งข้อดีของ System test นั่นเอง

แต่เมื่อจำนวนการทดสอบเยอะมากขึ้น ความซับซ้อนสูงขึ้น

ปัญหาที่ตามมาคือ ความช้า และ พังง่าย
เพราะว่าในฝั่งของ UI ที่พัฒนาด้วยภาษา JavaScript มีปัญหาหลายเรื่อง
ทั้งเรื่องรูปแบบการทำงาน การ load ต่าง ๆ ว่าครบหรือพร้อมหรือไม่
ตรงนี้จากที่ใช้งานมา Selenium จะเจอปัญหาเหล่านี้เยอะมาก ๆ
ทำให้เป็นที่มาของ Flaky test มาอีก

จากประสบการณ์ที่ใช้งานของผมเอง
โดยที่เครื่องมือใหม่ ๆ ของการทดสอบเช่น Cypress และ Playwright มาช่วยลดปัญหานี้ลงไป

จากเป้าหมายหรือหัวใจของ Automated testing คือ

Fast feedback จากการเปลี่ยนแปลงต่าง ๆ
แต่ผลที่ได้กลับตรงกันข้าม
ดังนั้นแนวทางนี้ไม่น่าจะถูกต้อง

จากบทความมีการพูดถึงว่า System test จะ work มาก ๆ สำหรับ Smoke test
ดังนั้นก็ต้องเข้าใจก่อนว่ามันคืออะไรอีก
ตามหลักการแล้ว Smoke test มันคือชุดการทดสอบที่

• ทดสอบ function ที่สำคัญ ๆ ของระบบเป็นหลัก ไม่ใช่ทั้งหมดเหมือน regression test
• ใช้เวลาการทดสอบไม่นาน
• ใช้สำหรับหา critical issue สำหรับ version ใหม่ ๆ ที่ update เข้ามา

ดังนั้น System test ไม่ได้เหมาะกับการทดสอบให้ครอบคลุมการทำงานภายใน
เพราะว่า มันคือ Black box testing
เนื่องจาก System test ที่ทำกันนั้น มีทั้ง Controller test, Domain test เป็นต้น
ตามโครงสร้างของ RoR project ที่เป็น MVC (Model-View-Controller)
ดังนั้นควรแยกออกไปทดสอบใน level อื่น ๆ บ้างจะดีกว่า
ส่งผลให้การทดสอบมีหลาย ๆ แบบ ทั้ง unit และ integration test เป็นต้น

ส่งผลทำให้การทดสอบเป็นไปตามเป้าหมาย คือ เร็ว และ น่าเชื่อถือ

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

จะเห็นได้ว่า การทดสอบของระบบนั้นมีหลายรูปแบบ

ต่างมีข้อดีและข้อเสีย
ดังนั้นเราจำเป็นต้องกำหนดเป้าหมายร่วมกันว่าจะทดสอบแบบไหน
สนใจเรื่องความเร็วและน่าเชื่อถือหรือไม่
ต้องมีการ monitor performance อย่างต่อเนื่อง
จากนั้นนำ feedback เหล่านั้นมาปรับปรุงให้ดีขึ้นอย่างต่อเนื่อง

Reference Websites สำหรับคนแก่ !!

• TDD is dead. Long live testing
• Is TDD Dead?
• Is TDD Dead? Final Thoughts about Teams

แนว 12-factors app นั้นเป็นแนวคิดที่สร้างมาผู้สร้างระบบ Heroku
โดยถูกหยิบมาพูด หรือ ใช้งานมากขึ้นในยุคของ Cloud Native App
ประกอบไปด้วย 12 ข้อ และดูเหมือนว่าจะมีคนคิดเพิ่มมาอีก 3 เป็น 15 ข้อ
ผมเคยเขียน blog อธิบายไว้เมื่อนานมาแล้ว
มาครั้งนี้มีคำถามจากการแบ่งปันเรื่อง Docker + Go + Microservices
ว่ามีตัวอย่างหรือไม่ จึงทำการสร้างตัวอย่างพร้อมอธิบายสั้น ๆ ไว้ให้
เพื่อช่วยให้เข้าใจมากยิ่งขึ้น
มาเริ่มกันเลย

ระบบตัวอย่างจะใช้งานเครื่องมือเหล่านี้

• ภาษา Go 1.22.3 ใช้งาน library Gin web framework
• Docker => Docker compose

จาก 12-factors นั้นในข้อที่ 1 เรื่อง Codebase จะข้ามไปเลย
ไม่น่าต้องคุยอะไรมากกันแล้ว

เรื่องที่ 2 คือ Dependencies ของระบบ

ภาษา Go มี Go module ให้ใช้งานแบบง่าย
ดังนั้นเริ่มสร้าง project กันเลย
โดย library ที่ใช้งานอยู่ถูก config ไว้ในไฟล์ go.mod
จะใช้ library อะไรก็เพิ่มกันเลย
โดยในระบบตัวอย่างจะใช้งาน library ดังนี้

• Gin web framework สำหรับสร้าง Web Server
• Testify ช่วยให้การเขียน test ง่ายขึ้น
• ส่วน logging ใช้ standard log ของ Go ไปเลย
• ใช้งาน Corba แทน flags เพื่อช่วยจัดการ Go CLI ให้ง่ายขึ้น เพื่อสร้าง admin tasks ในข้อ 12 :: Admin processes เช่น ขั้นตอนของการ migrate database เป็นต้น

ตัวอย่างการสร้าง

ส่วน code ในไฟล์ server.go ก็ทำการ copy มาจาก official web ของ Gin เลย

ในการจัดการ dependencies ของระบบนั้น
ไม่ได้สนใจเพียงสิ่งที่ code ใช้เท่านั้น
ถ้ามองให้กว้างขึ้นเรื่องของ OS และ software ต่าง ๆ ที่ใช้งานก็เช่นกัน
ควรที่จะคล้าย หรือ เหมือน production ให้ได้มากที่สุด
เพื่อช่วยให้เราเจอปัญหาได้รวดเร็วที่สุด
เพื่อแก้ไขปัญหาตั้งแต่เนิ่น ๆ ไม่ใช่ไปเจอตอนจะ deploy บน server
มักจะมีคำพูดที่ว่า "ผมทำการ run บนเครื่องผมได้นะ แต่พอเอาขึ้น server แล้วดันทำงานไม่ได้ ไม่รู้ทำไม"

ซึ่งจะตรงกับข้อที่ 10 :: Dev/prod parity
เป็นแนวปฏิบัติที่สำคัญของ Continuous Delivery นั่นเอง

ดังนั้นสามารถนำเอา Docker เข้ามาช่วยได้เลย
ด้วยการสร้าง Dockerfile + Multi-stage build เพื่อกำหนดสิ่งต่าง ๆ ที่จะใช้งานไปเลย เช่น

• OS ที่จะใช้งาน รวมทั้ง version ด้วย
• Go

เขียนได้ดังนี้

ทำให้สามารถแยกขั้นตอนการ build และ run ออกมาตามแนวคิดข้อที่ 5 :: Build, release, run
เพื่อความสะดวกอาจจะเขียนขั้นตอนการทำงานต่าง ๆ ใน

• Makefile
• Taskfile

เพื่อช่วยให้ทีมที่เกี่ยวข้องทำงานร่วมกันง่ายยิ่งขึ้น

เรื่องที่ 3 คือ Config ต่าง ๆ ของระบบงาน

โดยปกติเราต้องแยก config ออกจาก code หรือ ระบบงานอยู่แล้ว
มีแนวทางที่หลากหลาย เช่น

• File config ในรูปแบบต่าง ๆ เช่น properties, json และ YAML เป็นต้น โดยใช้งาน library พวก viper และ godotenv เป็นต้น
• ส่งผ่าน command line มาได้เลย เช่น flags หรือ ใช้งาน corba ในการจัดการ
• ส่งผ่าน environment ของ OS นั้น ๆ หรือผ่าน Docker ได้เลย
• ใช้งาน external config server ก็ได้ เช่น Vault, Consul และ Etcd เป็นต้น

ลองเลือกตาม use case ของระบบงานว่าแบบไหนที่เหมาะสม
หรืออาจจะใช้ร่วมกันก็ได้ เช่น .env ร่วมกับ Docker compose เป็นต้น

เรื่องที่ 5 คือ Backing services (resources) ช่วยให้ทำการเพิ่ม หรือ เปลี่ยนแปลงได้ง่าย

ในแต่ละ environment ด้วย โดยไม่ต้องทำการแก้ไข code ใด
ซึ่งทำงานร่วมกับข้อที่ 3 คือ Config นั่นเอง
ยกตัวอย่างเช่น database, messaging server และ external service เป็นต้น
ลดการผูกมัดให้น้อยลงไปอีก (Loose couple)

ยกตัวอย่างเช่นการใช้งาน PostgreSQL + Viper

ในการสร้าง database ก็ใช้งาน Docker มาช่วย
ก็ทำให้เราสามารถสร้าง database ได้เร็วขึ้น
และมีการทำงานคล้าย ๆ กับของจริงอีกด้วย

ส่วนข้อ 6,7 และ 8 ไม่น่าต้องอธิบายอะไรแล้ว น่าจะเป็นเรื่องพื้นฐาน

เรื่องที่ 9 คือ Disposability นั่นคือ start ให้เร็ว และ จบการแบบสมบูรณ์

เรื่องที่สำคัญมาก ๆ คือ gracefull shutdown หรือ การจบการทำงานแบบสมบูรณ์
ยกตัวอย่างเช่น
เราต้องการลบ process การทำงาน จะเกิดอะไรขึ้นกับระบบงานของเรา ?

สิ่งที่ระบบงานควรต้องทำคือ

• ไม่รับ request ใหม่ ๆ
• ตรวจสอบว่า มีการทำงานค้างไหม ถ้าใช่ ก็ทำให้เสร็จทั้งหมด
• จบการทำงานแบบสมบูรณ์

ส่วนที่มักมีปัญหาคือ ระบบงานของเรารับสัญญาณของการ kill/terminate process จาก OS ไหม ?
เช่น SIGTERM และ SIGKILL เป็นต้น
จากนั้นก็ทำการสั่งให้รอก่อน เช่นการ waiting หรือ delay
หรือถ้าเป็น process ที่สำคัญมาก ๆ อาจจะต้องมีการจัดการ task/job
ใน database หรือ messaging ไว้ก่อน process อีกด้วย
เพื่อทำให้มั่นใจว่า task/job จะทำงานได้ครบและสมบูรณ์จริง ๆ

ตัวอย่างของการรับ SIGTERM และ SIGKILL ในภาษา Go เป็นดังนี้

เท่าที่เห็นมา ไม่ค่อยมีใครทำเท่าไรนัก
ทำการรอ 5 วินาที ก่อนที่จะ shutdown

แต่ในการทำงานจริง ๆ ควรมีระบบ monitoring ที่ดี
เพื่อ monitor การทำงานของแต่ละ feature ด้วย ว่ามีทำงานเป็นปกติด้วยหรือไม่

อีกเรื่องที่ยังไม่พูดถึงคือ เรื่องที่ 11 คือ Logs

ตามจริงต้องพูดรวมเรื่องของ observability เลย ทั้ง

• Alert system
• Application metric
• Distributed tracing
• Log aggregation

แต่ในข้อนี้เน้นที่เรื่อง logs
ก่อนอื่นต้องทำการออกแบบของ log format ก่อน
ให้มีรูปแบบที่เป็นมาตรฐาน ว่าจะเก็บอะไรบ้าง
จากนั้นจึงมาสร้าง log ด้วย library ต่าง ๆ อีกที
โดยแนะนำควรมี format เป็น JSON เช่น logrus, zap และ log/slog เป็นต้น

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

จากนั้นให้สร้างระบบ Centralized log ขึ้นมา เช่น ELK หรือ OpenSearch และ LGTM ของ Grafana เป็นต้น
สำหรับจัดเก็บ ค้นหา visualization และ alert system ต่อไป

น่าจะเขียนยาวเกินไปละครับ
จบเพียงเท่านี้ดีกว่า เป็น note สำหรับการแบ่งปันเรื่อง 12 factor ที่ผ่านมา

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

ก่อนหน้านี้ HTTPie นั้น จะใช้งานผ่าน CLI หรือ command line
สำหรัยการทดสอบ API เช่น RESTful APIs เป็นต้น
อาจจะใช้ยากหน่อยสำหรับผู้ใช้งานทั่วไป
แต่ข้อดีของมันคือ ใช้งานง่ายมาก ๆ ประสิทธิภาพดีมาก ๆ
แต่ตอนนี้ได้ปล่อย Web app และ Desktop app มาให้ลองใช้งาน (public beta)
ดังนั้นเจอ bug แน่นอน
ดังนั้นมาลองใช้งานกันดู

ความสามารถหลัก ๆ ประกอบไปด้วย

• จัดการ request ได้ง่าย ทั้งพวก header, parameter ต่าง ๆ รวมทั้งจัดการใน space, collection และ tab ได้เลย
• ทำงานร่วมกับ environment variables ได้ง่าย ๆ
• สามารถ sync ข้ามเครื่อง หรือ device ได้ แถมมี auto-save ให้ด้วย
• สามารถ preview request ก่อนส่งจริงได้ด้วย
• ใช้งานแบบ offline ได้ แถมไม่ต้อง login ก็ใช้ได้
• มี HTTPie AI ให้ลองใช้งาน ช่วยการ generate request ด้วย prompt ได้อีกด้วย สะดวกเข้าไปอีก
• สามารถ import ข้อมูลมาจาก cURL, postman และ insomnia ได้

การใช้งาน HTTPie AI

อ่าน Doc เพิ่มเติมได้เลย
ลองใช้งานกันเลยครับ

หรือลองไปดู Issue และ request feature เพิ่มได้เลย
ดูเหมือนเรื่อง request chaning และ test ก็มี request เข้ามาด้วยครับ

ไปอ่านเจอบทความเรื่องของการ design UX/UI ของ Httpie app
น่าสนใจมาก ๆ UI design for HTTPie: macOS vibes for the API testing client

เพิ่งเปิดให้ใช้งานสำหรับ Firebase App Hosting (public preview version)
ช่วยทำให้เราสามารถ deploy ระบบที่พัฒนาด้วย Angular และ Next.js
ดังนั้นเรื่องของ SSR (Server-Side Rendering) ก็สบายแล้ว (Full stack ชัด ๆ)
จาก Github repository ได้เลย (เหมือนกับ vercel เลย)
โดยทำการ build ด้วย Cloud build และ deploy บน Cloud Run ทำให้ scale แบบอัตโนมัติ
ในส่วนของ static content จะทำ caching ไว้ที่ Cloud CDN
รวมทั้ง integrate กับ service อื่น ๆ ได้เช่น Cloud Secret Manager สำหรับจัดการพวก API keys ต่าง ๆ
มาลองใช้งานกันดู

ขั้นตอนการทำงานเป็นดังนี้

การใช้งานก็ง่าย ๆ ไปสร้าง project ใน Firebase เลย
เปิด Blaze pricing plan ซะ
จากนั้นก็ทำการผูกเข้ากับ GitHub Repository ของระบบงานของเรา
โดยตัวอย่างเป็น Next.js

จากนั้นทำการ setting ของการ deploy
โดยให้ทำการ deploy อัตโนมัติ เมื่อทำการ push code ไปยัง branch ที่กำหนด

สุดท้ายก็ชื่อที่เราต้องการ
จากนั้นก็รอ รอ รอ รอ รอ .....

ระหว่างรอการ build และ deploy ก็เข้าไปดูที่ Cloud Build console กันหน่อย
ว่าจะเจออะไรบ้าง ?

• สร้าง image ด้วน Ubuntu
• ทำการ build ด้วย buildpacks นั่นเอง
• ทำการสร้าง image และ push ขึ้น Google Container Registry ให้

สำหรับ starter project นั้นทำการ build image ประมาณ 2-3 นาที

รอสักพักนะครับ แล้วระบบงานเราจะ deploy บน cloud run เรียบร้อย !!!
ตอนนี้การ deploy แต่ละรอบใช้เวลานานพอสมควร

ปล. อย่าลืมไป enable Service account permission ให้กับ Cloud Run ด้วยนะ เดี๋ยวจะ deploy ไม่ได้ !!

เท่าที่ลองใช้งานพวก log การ deploy ยังไม่ดี รอตัวจริงต่อไป
link ไปยังเอกสารในหน้า error ยังผิดอีก !!

Referecne websites

• Introducing Firebase App Hosting
• Planet-scale reach for Next and Angular apps with Firebase App Hosting

หลังจากที่แนะนำเครื่องมือสำหรับ API testing ไปหลายตัว เช่น

• Postman + newman
• Bruno
• Hoppscotch
• HTTPie

มีคนแนะนำเครื่องมืออีกตัวคือ Hurl
ซึ่งเป็น command line tool (CLI) สำหรับการทดสอบผ่าน HTTP
ด้วยการเขียนใน text file ปกติ
ดังนั้นมาลองใช้งานกันดู

เท่าที่เข้าไปดูความสามารถคร่าว ๆ ของ Hurl พบว่า
มันสามารถทำ API testing ได้แบบง่าย ๆ เลย
ด้วยการเขียนไฟล์นามสกุล hurl ขึ้นมา
จากนั้น run ผ่าน command line ได้เลย
แถมเขียน test case หรือ assert ได้เลย
รวมทั้งสามารถเขียนร้อย flow การทำงานของแต่ละ API ได้อีกด้วย
ด้วยการกำหนดค่าลงใน environment variable
เพียงแค่ไม่มี UI ให้ใช้งานแบบง่าย ๆ นั่นเอง

ดังนั้นมาดูตัวอย่างการทดสอบด้วย Hurl กันดู

ทำการทดสอบ API= https://jsonplaceholder.typicode.com/users
ต้องการตรวจสอบดังนี้

• HTTP response code = 200
• Content type จาก HTTP Response ต้องเป็น application/json; charset=utf-8
• มีข้อมูล user จำนวน 10 คน
• ชื่อของ username ของคนแรกต้องชื่อ Bret

สามารถเขียนได้ดังนี้

ทำการ run ใน mode testing

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

มีคำถามจากการ share เรื่อง Docker จากสถาบัน IMC ว่า
ในการใช้งาน docker image นั้น ควรระบุด้วย tag หรือ digest ดี ?

โดยปกติในการใช้งาน docker image จาก container/image registry server
ยกตัวอย่างเช่น nginx ใน Docker Hub
เราจะใช้งานด้วยการระบุชื่อพร้อม tag ที่ต้องการ
จาก best practice นั้น ไม่แนะนำให้ใช้ tag latest

แต่ถ้าเรื่องความถูกต้อง และ ความปลอดภัย
แนะนำให้ทำการระบุชื่อ image พร้อม digest ของ image

เนื่องจากถ้าทำการ build image ทับใน tag เดิม สามารถทำได้แน่นอน
ทำให้อาจจะเกิดปัญหาได้ เพราะว่า image ไม่เหมือนเดิม
ขัดกับแนวทางเรื่องของ immutable !!

ดังนั้นเพื่อความมั่นใจให้ระบุด้วย image digest
สร้างขึ้นมาเพื่อไม่ให้เกิดการชนกันของ image แต่ละตัวที่ push ขึ้นมา
ซึ่งในแต่ละ tag และการ build จะมีการคำนวณ digest ให้ใหม่
นำเอาทุก ๆ layer ของ image มา hash กันอีกรอบ !!
คล้ายกับ checksum นั่นเอง
สามารถดูเพิ่มเติมเรื่อง Manifest ได้ (ถ้าว่าง ๆ จะมาอธิบายการคำนวณค่า digest ให้อีกครั้ง)
ดังนั้นถ้ามีการเปลี่ยนแปลงเพียงเล็กน้อยค่า digest ก็เปลี่ยน

ตัวอย่างการใช้งาน

ทำการ pull image ลงมา จากนั้นดู digest ของแต่ละ image ดังนี้

ใน Dockerfile ทำการระบุได้ดังนี้

เพียงเท่านี้ก็ทำให้เรามั่นใจขึ้นแล้วนะครับ
ลองดูครับ

หรือเพื่อความปลอดภัยไปอีก ให้ทำการ signed Docker image ไปเลย
เช่น OpenPubKey , Docker Trust และ Connaisseur

เครื่องมือสำหรับจัดการหรือทำงานกับ Kubernetes นั้นมีเยอะมาก ๆ
จนมีการรวมเครื่องมือที่น่าสนใจเอาไว้
ในรูปแบบของตารางธาตุสวย ๆ ดูง่าย ๆ
ชื่อว่า Kubetools - A Curated List of Kubernetes Tools
แสเงไว้ดังรูป

โดยทำการแบ่งออกเป็นกลุ่มย่อย ๆ ให้ค้นหาหรือดูได้ง่ายขึ้น
ยกตัวอย่างเช่น

• Cluster management
• Observability
• CI/CD integration
• Security tool
• Network policy
• Backup
• Storage provider
• Development toolkit

แต่ยังดูยากอยู่นะ ใครสนใจลองไปร่วม contribute ได้เลย
ยังมี link ต่าง ๆ อีกเพียบ ลองดูเพิ่มเติมได้จาก GitHub:Collabnix

มีคำถามเกี่ยวกับการมาเป็น Test Automation Engineer ว่า
ควรมี technical skill อะไรบ้าง ?
เพื่อช่วยให้การทดสอบดีขึ้น
จากสิ่งที่ทำและเจอมา สามารถสรุปคร่าว ๆ ได้ดังนี้

ให้เริ่มจากวิธีคิดก่อนว่า ต้องปรับปรุงให้ดีกว่าเดิม
อย่าไปกลัวที่จะเรียนรู้สิ่งใหม่ ๆ
จากนั้นลงมือทำ วัดผล ให้ได้รับ feedback และปรับปรุงด้วยการลงมือทำซ้ำ ๆ

มาเริ่มกันเลย

เรื่องแรก programming skill ให้เลือกสักภาษาก่อนเพื่อศึกษา

เนื่องจากการทำ automation test นั้นจำเป็นต้องเขียน script หรือ code เสมอ
แต่เป็นการเขียนในเชิงการทดสอบ ไม่ใช่การพัฒนาระบบงาน
แต่เรื่องนี้เป็นกำแพงอันยิ่งใหญ่ สำหรับ QA/Tester ที่ทำ manual มาตลอด หรือ non-technical
จึงต้องอาศัยวิธีคิด ความพยายามสูงกว่าคนอื่น ๆ

แต่ส่วนใหญ่มักจะหนีไปใช้เครื่องมือพวก

• AI หรือ GenAI
• Record and playback tool
• Scriptless/No code/Low Code tool

ซึ่งมันคือการหนีนั่นเอง ดังนั้นจะไม่ได้มีความรู้ด้าน programming มากนัก
ก็จะไม่ได้สนใจเรื่องนี้เท่าไร เน้น tool ล้วน ๆ
จะส่งผลดีในช่วงแรก แต่ในการดูแลระยะยาวจะวุ่นวายหรือลำบากมาก ๆ
เช่นเกิด flaky test ขึ้นมาอีก
สุดท้ายจะบอกว่า ทดสอบแบบเดิมดีกว่า !!

แต่แน่นอนว่า มันก็คือ หนึ่งในการเรียนรู้เช่นกัน

เรื่องที่สองคือ การใช้งาน Version Control เช่น Git

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

แนะนำให้เริ่มที่ command line tool ก่อนนะครับ
อย่าเพิ่มเริ่มด้วย GUI tool
ยากหน่อยในการเริ่มต้น แต่พื้นฐานสำคัญมาก ๆ

อีกอย่างเรื่องของ การใช้ command line tool ต่าง ๆ ก็ฝึกเอาไว้
ถ้าเขียน shell script ได้ก็จะดียิ่งขึ้น

อีกอย่างเมื่อ test script มีการเปลี่ยน ก็จะเป็นต้องทำการ execute test ทั้งหมดทุก ๆ ครั้งอีกด้วย
ตรงนนี้ช่วยให้สามารถเพิ่มการทดสอบแบบอัตโนมัติ
ใน pipeline ของ CI/CD process ได้ง่ายอีกด้วย

ลด ละ เลิก การส่ง test script ผ่าน email หรือ chat tool กันได้แล้ว !!

เรื่องที่สาม เรียนรู้เรื่อง format file ต่าง ๆ ที่จำเป็นต่อการใช้งาน

ยกตัวอย่างเช่นส่วนใหญ่ต้องรู้ และ เขียนพวก JSON, YAML ได้
ก่อนนี้จะมีพวก XML, CSV เป็นต้น

หรือถ้าต้องการ validate โครงสร้างข้อมูลก็ต้องรู้ เช่น

• JSON ต้องรู้ JSON Schema
• XML ต้องรู้ XML Schema

เรื่องที่สี่ จะทดสอบระบบอะไรก็ต้องรู้เรื่องนั้น ๆ

ยกตัวอย่างเช่น ทดสอบ web application ผ่าน web browser
ก็ต้องมีความรู้เรื่องพื้นฐานของ web ก่อนด้วย เช่น

• HTML/CSS/JavaScript พื้นฐาน
• การเข้ามถึง element ต่าง ๆ เช่น id/name/xpath/css seclector
• ใช้ web browser เช่น Google Chrome ก็ต้องเข้าใจ หรือใช้งาน DevTool ได้อย่างดีเช่นกัน

พวก Database ทั้ง SQL และ NoSQL
ถ้ามีความรู้จะช่วยให้เราเข้าใจโครงสร้างระบบมากยิ่งขึ้น

เรื่องที่ห้า ชุดเครื่องมือต่าง ๆ ในการทดสอบของแต่ละแบบ

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

• UI test ของ web app
• UI test ของ mobile app
• API test ของ REST API, GraphQL
• Service component test
• Contract test
• .....

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

เรื่องที่หก เข้าใจเรื่องของ Architecture ของระบบงาน หรือ Software design บ้าง

ปัญหาที่เจอสำหรับการทดสอบคือ
จะทดสอบแต่ในมุมมองของ Black box testing เยอะมาก ๆ
รอให้เสร้จแล้วค่อยทดสอบ
บอกได้เลลย เอาอะไรมาช่วยก็ไม่รอด
เพราะว่าการทดสอบอยู่ในช่วงท้าย
ทำได้แค่ตามทดสอบให้มันจบ ๆ ไป

ดังนั้นอยากให้กลับมาดูเป็น Gray box หรือ white box testing มากยิ่งขึ้น
คือการเข้ามาดู หรือ เข้าใจโครงสร้าง หรือ architecture ของระบบงานให้มากขึ้น
เช่นระบบงานมี Frontend, Backend, Database, Caching, API gateway, Load balancer
จะช่วยทำให้เข้าใจมากขึ้นมาว่า
ควรจะมี test strategy อะไรบ้างที่เหมาะสม
เพื่อค่อย ๆ ทดสอบในแต่ละส่วนว่าถูกต้อง
ส่วนไหนต้องจำลอง (Test double) แบบไหน อย่างไร เครื่องมืออะไร
ส่วนไหนที่มีปัญหา หรือ คอขวด
อย่างเช่น Load balancer จะทดสอบอย่างไร ?
แนวทางในการเตรียม data test ให้เหมาะสม หรือ ไปจนถึงการ generate data test อีกด้วย
จากนั้นค่อยมาทำ End-to-end test ในขั้นตอนสุดท้าย !!

แต่เหนือสิ่งอื่นใด คือการฝึก ฝึก ฝึก ครับ
ลงมือศึกษา ลงมือทำ

จากการแบ่งปันเรื่อง Microservices นั้น มักจะแนะนำให้เริ่มจาก Monolithic app ไปก่อน
ทำให้มันดีก่อน ที่จะแยกไปเป็น service ย่อย ๆ
จากนั้นทำการ monitor ว่าแนวทางนั้นมันส่งผลกระทบต่อระบบ และ การทำงานหรือไม่
เช่น productivity ของการส่งมอบ ผลกระทบจากการส่งมอบ
รวมถึงการ maintain ระบบ ว่ายากขึ้นหรือไม่ ?

มีคำถามว่า Monolithic App นั้นมีรูปแบบไหนบ้าง ?

จึงทำการสรุปไว้คร่าว ๆ ดังนี้

• รูปแบบที่ 1 มุมมองของ code คือ Single repository นั่นเอง เข้าที่เดียวมีครบ เช่นรวม frontend กับ backend เป็นต้น
• รูปแบบที่ 2 มุมมองของ database คือ Single database มีจำนวน table เยอะ ๆ หนักกว่านั้นแยก database scahema นะ แต่ join ข้าม database​ซะงั้น
• รูปแบบที่ 3 Service ใหญ่ ๆ มีหน้าที่รับผิดชอบเยอะมาก ๆ เพิ่มไปเรื่อย ๆ รูปว่าไม่ดีก็ยังเพิ่มเข้าไปอีก ไม่ใช่หน้าที่โดยตรงก็ดันเพิ่มเข้าไป
• รูปแบบที่ 4 App ใหญ่ ๆ เพิ่ม feature ไปเรื่อย ๆ ส่งช้าลงเรื่อย ๆ มีปัญหาขึ้นเรื่อย ๆ เช่น Supur app เป็นต้น แต่ถ้าจัดการดีก็ดีไป

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

• ความเข้าใจใน requirement แบบ end-to-end ไม่ใช่เพียงรู้ในส่วนที่ตัวเองทำหรือรับผิดชอบเท่านั้น
• แบ่งส่วนการทำงานแบบ modular ให้ดี ลดการผูกมักระหว่าง module ลงไปให้เยอะ (loose couple)
• ออกแบบโครงสร้างข้อมูลของแต่ละ module/domain ให้ชัดเจน แยก database schema ให้ชัดเจน
• แนวทางในการทดสอบที่ดี
• ในแต่ละ service ควรมีการแยกการ deploy ให้เป็นอิสระมากยิ่งขึ้น
• ระบบ monitoring และ observability ที่ดี เพื่อเป็นข้อมูลในการตัดสินใจ

ข้อควรระวัง !!!

• เมื่อแยก database schema แล้ว ก็อย่าให้เรียกข้ามกัน
• เมื่อแยก module แล้วก็อย่าให้ผูกมัดกัน
• เมื่อแยก service กัน ก็อย่าเรียกกันไปมา มันจะเกิด Distributed monolithic ได้
• เมื่อ productivity เริ่มลดลง ก็ได้เวลาหยุด เพื่อทำการปรับปรุง ( Later === Never )

จากการแบ่งปันเรื่อง Robot framework ที่ Software Park Thailand นั้น
มีการใช้งาน library สำหรับทดสอบระบบ web บน web browser ด้วย SeleniumLibrary 6.4.0
พบว่ามีความสามารถและการเปลี่ยนแปลงพอสมควร
ดังนั้นมาดูกันว่ามีอะไรบ้าง

เริ่มด้วยสนับสนุน Python 3.8 ถึง 3.11
จากนั้นทำการเพิ่มความสามารถเข้ามาคือ
การ print page ให้เป็น PDF ซึ่งเป็นความสามารถของ Selenium 4
ส่วนใน SeleniumLibrary เพิ่งเพิ่ม Keyword ชื่อว่า Print Page As Pdf

ทำการปรับปรุงในเรื่องของการแนะนำ Keyword เมื่อใช้งานผิด
กับเริ่มเอน code ของ Seleinium2Library ออกไปจาก project

ปล. ใครที่ยังใช้ Seleinium2Library อยู่ แนะนำให้เปลี่ยนได้แล้วนะครับ
เพราะว่าเลิกพัฒนาไปนานแล้ว !! 7 ปีแล้วนะ

สุดท้ายแล้วอย่าลืม update บ่อย ๆ ด้วยนะครับ
มิเช่นนั้นจะต้องแก้ไขเยอะแน่ ๆ
หรือใช้แต่ verision เก่า ๆ ไปตลอด !!

สัปดาห์ที่ผ่านมา Spring Boot 3.3.0 ถูกปล่อยออกมาแล้ว
ใครจะไม่ upgrade แนะนำเลยครับ
โดยความสามารถที่น่าสนใจประกอบไปด้วย

• สนับสนุน CDS (Class Data Sharing) ทำให้ start เร็วขึ้น และใช้งาน memory น้อยลง
• ปรับปรุงเรื่อง observability เช่นเพิ่ม @SpanTag เข้ามา สำหรับ tracing แบบง่าย ๆ
• เพิ่ม SBOM (Software Bill of Materials) actuator endpoint เข้ามา ช่วยให้เราเห็นว่าระบบงานใช้ library อะไรบ้าง
• ทำการเปลี่ยนแปลงเอกสารใหม่

ความสามารถที่น่าสนใจมาก ๆ คือ CDS (Class Data Sharing)

เป็น feature ใน JVM ที่มีมาตั้งแต่ Java 12
โดยจะทำการสร้างไฟล์สำหรับ load standard library ที่จะใช้งานขึ้นมา
จากนั้นในการใช้งานก็ load จากไฟล์เดียวเท่านั้น
ไม่ต้องไป load แบบ class-by-class เหมือนเดิม
รวมทั้งถ้า class ไหนใช้ซ้ำก็ใช้ที่เดียวกันไปเลย ไม่ต้อง load ใหม่
จึงช่วยลดการใช้งาน memory และ load เร็วขึ้นนั่นเอง

ดังนั้นมาลองดูกันว่า เร็วขึ้น และ ใช้ memory น้อยลงจริงไหมกัน ?

เป็นการทดลองใช้งาน Spring 3.3.0 กับ 3.2.6 บน Java 22

ก่อนอื่นทำการ print การใช้งาน memory ของ app มาก่อน

จากนั้นสร้าง JAR fil แบบปกติ

ต่อจากนั้นทำการสร้าง CDS JAR file และลองใช้งาน

ผลออกมาไม่ต่างมากเท่าไร ถ้าระบบใหญ่ ๆ น่าจะเห็นชัดมากขึ้น

อีกเรื่องคือ การเพิ่ม SBOM endpoint เข้ามา ทำงานกับ CycloneDX

สามารถ config เพิ่มมาได้ดังนี้

จากนั้นเปิด management web endpoint ใน Actuator ดูได้เลย

• http://localhost:8080/actuator/sbom/application

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

ช่วยให้เราเอาไป analyze ต่าง ๆ ได้ง่าย เช่น Security เป็นต้น

Upgrade กันได้แล้วนะ ตอนนี้ Spring Boot 3.1 ไม่ support แล้วนะครับ !!

เห็น feed ใน facebook มี share บทความเรื่อง SSL for localhost takes 5 seconds now
ว่าด้วยการสร้าง SSL สำหรับ localhost ใช้สำหรับการพัฒนา
เครื่องมือสร้างโดย developer เพื่อ developer นั่นเอง
จึงสร้างเป็น app ขึ้นมา ตอนนี้เป็น open source ที่ GitHub:Ophiuchi

โดยผมทำการ build app มาจาก source code ที่ GitHub เลย
เพื่อทดสอบการใช้งาน

ซึ่งจะทำสิ่งต่าง ๆ นี้ให้

• Generating a Self-Signed Certificate
• ทำการแก้ไขไฟล์ /etc/hosts ของเครื่อง ใส่ password ด้วย !!
• Trusting the Certificate
• Start proxy ก็เรียบร้อย

ตัวอย่างการใช้งาน

ทำการ start web server ก่อน เช่น port 3001
จากนั้นก็สร้าง proxy เลย

ใส่ password ของเครื่องด้วย อันตรายใช้ได้เลย !!
เมื่อสร้างเสร็จแล้ว เป็นดังนี้

จากนั้นก็ start container ผ่าน Docker ได้เลย เป็นอันจบการใช้งาน

เข้า web browser ใช้ได้ดังนี้

ลองเล่นขำ ๆ นะครับ ระมัดระวังการใช้งานด้วย
เพราะว่า มันขอสิทธิ์ได้น่ากลัวมาก ๆ

ตอนนี้ current version ของ NodeJS คือ 22
มีความสามารถต่าง ๆ เพิ่มเข้ามาเยอะมาก ๆ
โดยที่ไม่ต้องไปใช้ library ข้างนอกอีกแล้ว
ดังนั้นจึงทำการสรุปความสามารถของ NodeJS ไว้นิดหน่อย
มาเริ่มกันเลย

เรื่องแรก Test runner

เราสามารถเขียน test และ run test ได้เลยใน NodeJS
ไม่ต้องติดตั้งแล้ว ยกตัวอย่างเช่น jest, mocha และ vitest เป็นต้น
ลองใช้งานกัน รวมทั้งเรื่องของ test coverage ก็มีให้อย่างครบครัน

ในการเขียน test นั้นต้องทำการ mock/stub ของ module ต่าง ๆ
ซึ่งใน NodeJS ก็เตรียมการ mock ไว้ให้อีกด้วย

เรื่องที่สอง อ่านไฟล์ .env ได้แล้ว

เรื่องที่สาม เพิ่ม watch mode เข้ามาให้ ไม่ต้องใช้ nodemon แล้ว

เรื่องที่สี่ Node.js Corepack อยู่ในช่วงทดลอง

เพิ่มเข้ามาตั้งแต่ version 16 แล้ว แต่ยังอยู่ในช่วงการทดลอง !!
ใช้จัดการ version ของ package manager ที่ใช้งาน เช่น yarn และ pnpm เป็นต้น

เรื่องที่ 5 Resource Permission Model เหมือนกัน Deno นั่นเอง

ทำการกำหนด permission ของแต่ละ process ว่าทำอะไรได้บ้าง
เพื่อช่วยทำให้ระบบงานปลอดภัยมากยิ่งขึ้น
ลดผลกระทบจาก node module ที่ไม่ปลอดภัย
โดยเปิดการใช้งานผ่าน option --experimental-permission ในการ start node process
กำหนด permission ได้ดังนี้

• อ่านเขียนไฟล์
• ทำการสร้างและเรียกใช้งาน child process และ thread

อีกทั้งยังจัดการ policy ในระดับ module ได้อีกด้วย

ลองใช้งานกันดูครับ NodeJS มีของเล่นเยอะมาก ๆ