เห็นว่า Bun 1.0 เพิ่มปล่อยออกมา
ก็เลยมาทำการสรุปประสบการณ์
ในการนำ Bun ไปพัฒนาระบบงานเล็ก ๆ ไว้นิดหน่อย
ซึ่งก็สามารถส่งมอบระบบงานได้ดีเลย
มาดูกันว่าใช้อะไรบ้าง

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

• สามารถพัฒนาด้วย JavaScript และ TypeScript
• สนับสนุน .env ให้เลย
• การจัดการ dependency ต่าง ๆ ให้ ซึ่งทำงานร่วมกับ package manager อื่น ๆ ได้เลย
• จัดการ transpiler ให้
• ทำ bundler ให้ แล้วเร็วกว่าตัวอื่น ๆ อีก
• มี bunx เหมือนกับ npx แต่เร็วกว่า
• มี testing library ให้ ซึ่ง compatible กับ Jest ทำให้ใช้ได้เหมือนกัน
• มี hot reload ให้
• สามารถเขียน plugin เพื่อเพิ่มความสามารถได้

Bun มีชุดดของ build-in library ที่มีประสิทธิภาพอย่างมาก

ตัวที่ใช้ประจำคือ Bun.serve() สำหรับการสร้าง HTTP server และ Web socket server
มีประสิทธิภาพที่สูงมาก ๆ ซึ่งเคยเขียนอธิบายไว้แล้ว

ส่วนการติดต่อ database นั้นจะมี SQLite มาให้เลย
ถ้าต้องการใช้งาน database อื่น ๆ ก็มี
เช่นตัวที่ใช้งานประกอบไปด้วย

• PostgreSQL ใช้งาน Postgres.js
• MySQL ใช้งาน mysql2
• Redis ใช้งาน node-redis

เขียน HTTP Server แบบง่าย ๆ

ในการส่งมอบระบบงานนั้นจะใช้งานผ่าน Docker
ซึ่งทำการใช้งาน based image จาก Oven/Bun

และจะทำการ build ระบบงานออกมาเป็น single exeutable binary
ทำให้การส่งมอบง่ายขึ้น

ส่วนการทดสอบก็เขียนง่าย ๆ

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

อีกทั้งยังมีการสรุป framework และเครื่องมือต่าง ๆ ของ Bun ไว้ที่ Awesome-bun

ขอให้สนุกกับการ coding

Spring Boot 3.2 จะปล่อยตัว final ออกมาในเดือนพฤศจิกายนนี้นั้น
ตอนนี้ปล่อย version 3.2 M2 มาให้ใช้งาน
โดยความสามารถที่น่าสนใจคือ

เปิดการใช้งาน Virtual thread executor ได้แบบง่าย ๆ

ในไฟล์ application.properties

สิ่งที่น่าสนใจคือ Spring Boot 3.2 + Java 21 + GraalVM support Java 21 !!
แต่ยังไม่ใช่ตัว final สักตัว

ดังนั้นถ้าต้องการทดลองใช้งานกับ Java 21 แล้วนั้นต้อง config เอง ดังนี้

ซึ่งน่าสนใจ ของ version 3.2 มาก ๆ
ลอง download มาใช้งานเล่น ๆ กันดู

จากการแบ่งปันเรื่องการพัฒนาระบบงานด้วย Spring Boot และ Testing
มีคำถามเกี่ยวกับ Spring Boot Testing
จึงทำการสรุปความรู้พื้นฐานไว้นิดหน่อยดังนี้
มาเริ่มกันเลย

Spring Boot testing นั้นจะมีให้กับ project ที่สร้างจาก Spring Initalizr

ซึ่งจะทำการจัดการ dependency ต่าง ๆ ให้แบบอันโนมัติ
ประกอบไปด้วย

• JUnit 5 คือ testing framework สำหรับภาษา Java ตัวนี้สำคัญสุด ๆ
• Spring Test และ Spring Boot Test ตัวนี้ Spring Boot เตรียมไว้ให้ ใช้งานง่าย ๆ เป็น integration test นั่นเอง ช้าหน่อย แต่ชัวร์
• Mockito สำหรับการจำลอง dependency ต่าง ๆ ใช้ทั้งแบบ unit test และ integration test กับ Spring Boot
• Hamcrest สำหรับการ assert หรือตรวจสอบผลการทำงาน
• AssertJ เหมือนกับ Hamcrest นั่นเอง เลือกได้ตามความชอบ
• JSONAssert สำหรับการตรวจสอบข้อมูลในรูปแบบ JSON ทั้ง object และ array
• JsonPath สำหรับการเข้าถึง property ต่าง ๆ ใน JSON

ถ้าต้องการ test ในรูปแบบอื่น ๆ ก็ต้องเพิ่ม dependency เพิ่ม เช่น

• WireMock สำหรับจำลอง external api ใช้งาน Contract Stub Runner
• Test container สำหรับทำงานร่วมกับ docker container

มาดูรายละเอียดของ 4 สิ่งที่น่าสนใจ

เรื่องที่ 1 :: JUnit 5

เป็น testing framework สำหรับ Java ซึ่งมีโครงสร้างหลัก ๆ ดังนี้

เรื่องที่ 2 :: Spring Boot testing

ทาง Spring Boot นั้นได้เตรียมไว้ให้
ซึ่งเป็น integration test นั่นเอง โดยสิ่งที่เตรียมไว้ให้มีดังนี้

• Spring Boot Testing สำหรับ start web server และชุดการทดสอบต่าง ๆ ไว้ให้ ทำงานเหมือนจริงทุกอย่าง เป็นตัวแทนของจริงได้เลย ว่าถ้าทดสอบผ่านแล้ว จะ run ได้ตามที่ต้องการแน่นอน แต่ข้อเสียคือ ช้าที่สุด

ตัวอย่างการใช้งานง่าย ๆ เป็นการทดสอบ API ผ่าน TestRestTemplate

• Slicing Testing เป็นการทดสอบเฉพาะ layer ใน Spring Boot เท่านั้น ซึ่งเร็วมาก ๆ เพราะว่า load บาง layer เท่านั้น เช่น
  • Controller layer จะทดสอบผ่าน WebMvcTest
  • Repository layer จะทดสอบผ่าน library ที่ติดต่อกับ database เช่น Spring Data จะมีให้หมด ทั้ง JDBCTest และ JPATest เป็นต้น

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

เรื่องที่ 3 ทั้ง JUnit 5 และ Spring Boot Testing สามารถทำงานกับ Mockito ได้

แต่ว่าใช้งาน และ ทำงานแตกต่างกัน

• ใช้งาน @Mock และ @InjectMock ในโลกของ Unit testing หรือ Java เท่านั้น ปกติใช้ทดสอบ logic การทำงานใน service layer เพราะว่า ไม่ต้องการ start web server ใด ๆ
• ใช้งาน @MockBean สำหรับการจำลอง dependency ใน integration testing ของ Spring Boot ได้ทั้ง Spring Boot test และ WebMvcTest

เรื่องที่ 4 ในการทดสอบ JSON message สามารถใช้งาน JSONPath และ JSONAssert ได้

แต่ปกติผมชอบใช้ JSONMapper มาแปลงเป็น object ก่อน

โดยทั้งหมดนี้ได้มาทันทีเมื่อสร้าง project ขึ้นมา
ดังนั้นไม่มีเหตุผลใด ๆ ที่จะไม่เขียน test นะ !!

ตอนนี้ทาง Postman สนับสนุน MQTT (Message Queuing Telemetry Transport) แล้ว
เป็น communication protocol สำหรับอุปกรณ์ IoT
ซึ่งมีการทำงานในรูปแบบ pub/sub
โดยก่อนหน้านี้สนับสนุน WebSocket และ Socket.io

โดยที่ใน open beta จะมีความสามารถดังนี้

• สามารถ subscribe และ publish ไปยัง topic ของ MQTT Server ได้
• สนับสนุน SSL authentication
• สนับสนุน MQTT version 3.1.1 และ 5
• Payload รองรับทั้ง plain text, JSON และ base64
• สามารถเขียนเอกสาร จัดเก็บในรูปแบบ collection และ share ให้กับทีมได้แบบปกติ

อีกอย่างมีการ monitor และ visualize แบบสวย ๆ ให้ด้วย

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

โดยสามารถร่วมงานผ่าน Youtube ได้เลย
ซึ่งมีหัวข้อต่าง ๆ เหล่านี้

• การเปลี่ยนแปลงต่าง ๆ ของ Java 21
• เรื่อง Virtual Thread
• Java ในโลกของ Cloud
• Pattern matching
• Performance improvement ต่าง ๆ ใน Java 21

พร้อมหรือยังสำหรับ Java 21

เห็นใน feed มีการ share เรื่อง SQL Query Optimization! กันเยอะ
ซึ่งอธิบายการปรับปรุงประสิทธิภาพการทำงานของ SQL กัน
ยกตัวอย่างเช่น

• LIKE vs REGEXP_LIKE
• REGEXP_EXTRACT
• ใช้ temp table แทน IN สำหรับข้อมูลเยอะ ๆ

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

แต่ที่ผมใช้งานจริง ๆ มักจะเป็นดังนี้

• พวกการ LIKE ต่าง ๆ มักจะไม่ใช้เลย ไปใช้ database model สำหรับการ search ดีกว่าเยอะ แต่ถ้าข้อมูลไม่เยอะ คนใช้งานไม่เยอะ ก็ใช้ ๆ ไปก็ได้มั้ง !! แต่อย่าลืมทำ performacne test ดูด้วยละ หรือ explain ดูด้วยว่าใช้ cost ไปเท่าไร มันสำคัญมาก ๆ
• อีกอย่าง %X% แบบนี้ลด ละ เลิก ใช้ X% แบบนี้ยังพอทน !
• ลดการ join ลง โดยใช้การทำ pre-joined หรือเตรียมข้อมูลให้ง่ายต่อการ query ตั้งแต่การจัดเก็บดีกว่า ลด cost ได้เยอะ แถม performance ดีกว่ามาก ๆ (ลูกอีกชั่ง join ลดให้เยอะ ๆ ครับ มันเปลือง)
• เน้น design for write และ design for read จะมีความยากในการออกแบบพอสมควร แต่ได้ผลดี ลดงาน ลดเวลาไปเยอะ
• ถ้าต้องมี parameter หรือ ข้อมุลใน IN เยอะ ๆ ตรงนี้ ถ้าไม่เยอะ และ fixed size ถึงจะใช้ IN แต่ถ้าเยอะ และ ไม่รูปขนาดที่ชัดเจน แนะนำให้ใช้ EXISTS ดีกว่า
• พวก index ก็ใส่ให้ถูก และ มีประสิทธิภาพด้วย ไม่งั้น เดี๋ยวจะเจอปัญหา คือ ขนาดของ index ใหญ่กว่า data ที่เก็บกันอีก !!
• โลกนี้ไม่ใช่มีแต่ RDBMS นะครับ

ไม่มีผิดมีถูก ต้องดูตามระบบที่ใช้งานด้วย
ว่า performance ตรงตาม business requirement หรือไม่
ถ้าไม่ น่าจะต้องปรับปรุงและเปลี่ยนแปลงกันแล้ว

ทาง Vercel Lab ได้ปล่อย V0.dev ออกมา (private alpha)
ให้ไปลองใช้งาน (ลง waiting list) ไว้ก่อน
โดยเป็นระบบที่จะ generate user interface ออกมาให้ (Generative UI)
ซึ่งจะเป็น ReactJS กับใช้งาน framework คือ

• shadcn/ui
• Tailwind CSS

แต่ในอนาคตก็จะเพิ่มตัวอื่น ๆ เข้ามาเช่นเดียวกัน

คนใช้งานสามารถพิมพ์คำสั่งหรือ prompt ง่าย ๆ ได้เลย
แล้วระบบจะทำ generate code ให้ทันที
จากนั้นก็ COPY -> PASTE -> SHIP ได้เลย !!
ตอนนี้มีตัวอย่างออกมาให้ลองไปดูกันก่อน

ข้อมูลที่ใช้ในการ train หรือใช้สอนระบบนั้น
จะมาจาก open source หลากหลายที่
ซึ่งจากเอกสารยังไม่ได้บอกอะไรมาก
แต่ที่เน้น ๆ คือ จะไม่ได้ใช้ข้อมูลจากลูกค้าที่ใช้งาน Vercel แน่ ๆ

ลองลงทะเบียนใช้งานกันดูครับ

เพิ่งเห็นผ่าน ๆ ใน feed เกี่ยวกับเรื่องของ DevOps
พบว่าหลาย ๆ ที่จะเรียกว่า DevOops !!
มันมีที่มาที่ไปอย่างไรนะ จะหาก็หาไม่เจอ
เลยนำเอาสิ่งที่เคยเจอมาอธิบายดีกว่า
ส่วนใหญ่ไม่น่าจะใช่เรื่องจริง !!

เริ่มจากหลาย ๆ บริษัทนั้น
ฝั่ง Development และ Operation ไม่น่าจะถูกกันสักเท่าไร

• Development ก็อยากทำให้เสร็จ ส่งมอบให้ได้ตรงตามเวลาที่กำหนด
• Operation ก็ไม่อยากให้ระบบมีปัญหา เพราะว่า 24x7 และ 99.999% มันค้ำคอ

หลาย ๆ ที่มี Test/QA คั่นกลางด้วยนะ
หรืออาจจะเรียกว่า DevTestOps ก็ได้
หรือเพิ่ม security เข้ามาก็เรียกว่า DevSecOps, DevTestSecOps, DevTestPerfSecOps !!

แต่ก็กลายเป็นการทำงานต่างฝ่ายต่างทำเช่นเดิม !!
ไหลมาตาม process คือ

• Development พัฒนาให้เสร็จ
• Test/QA มาตรวจสอบ หา bug ให้ได้มากที่สุด
• Operation รอเอา software ที่ Test/QA บอกว่า ok แล้ว ไปทำงาน deploy ต่อไป

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

แต่ชีวิตจริง deploy ไปกี่ครั้ง ก็มีปัญหาทุกครั้ง
เราได้เรียนรู้อะไรจากปัญหาเหล่านั้นไหมนะ ?

พอเจอปัญหาเหล่านี้ ก็เริ่มเห็นว่า DevOps น่าจะช่วยได้

ก็เลยจะนำมาใช้ด้วยการ

• ตั้งทีมใหม่ชื่อว่า DevOps ไหมนะ
• ซึ่ง DevOps tools หรือ DevOps platform มาให้ใช้เลย

ถ้าไปดู DevOps team topologies จะเป็นแบบไหนนะ ?
มันคือ Anti-types เลยนะ
คงไม่น่าใช่แน่ ๆ

แต่ถ้าทำแล้วได้ผลดีตาม High performance DevOps team จาก DORA ก็แจ่มนะครับ

ซึ่งประกอบไปด้วย

สิ่งที่น่าสนใจต่อมาคือ
Deploy ได้บ่อยนะ หรือ Deploy ได้ตามที่ต้องการเลย
แต่มีปัญหาจากการ deploy ต้องมาแก้ไขทุกครั้งเลย
แบบนี้เรื่องของ Change failure rate ก็แย่นะ !!

บางทีมพอเจอปัญหา กว่าจะ recovery ระบบกลับมาได้ ใช้เวลานานขึ้น
แบบนี้ก็ไม่ดีเช่นกัน

ดังนั้นเรื่องของ team performance ที่ 4 ตัวด้านบน
จึงเป็นสิ่งที่ต้องให้ความสนใจ

ยกตัวอย่างเช่น ต้องมีการทดสอบในแต่ละขึ้นตอนด้วยไหม เช่น

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

มิฉะนั้น DevOps จะหลายเป็น DevOops ได้นะ !!

ช่วงเสาร์และอาทิตย์ที่ผ่านมา
มีโอกาสแบ่งปันเรื่อง Postman in the right way ที่ SCK Dojo
โดยมีเป้าหมายเพื่อแนะนำการใช้งาน Postman
ซึ่งเป็นเครื่องมือสำหรับการทดสอบระบบงาน
แต่จากเท่าที่เจอมาหลาย ๆ ทีมพบว่า
ใช้ Postman ไม่เต็มความสามารถมากนัก
แทนที่จะช่วยลดงาน กลับเพิ่มงานอีก
ดังนั้นจึงเป็นที่มาของการแบ่งปันครั้งนี้

เริ่มต้นจากเป้าหมายของการทดสอบ ประกอบไปด้วย

• Fast feedback loop เพื่อให้เรารู้ปัญหาจากทุก ๆ การเปลี่ยนแปลง
• High quality คือคุณภาพที่สูงขึ้น ไม่สามารถต่อรองได้
• เพิ่มความเชื่อมั่นให้สูงขึ้น

สิ่งที่สำคัญมาก ๆ คือ regression test
ดังนั้นถ้าเราใช้ Postman แล้ว จะช่วยให้เราเข้าถึงเป้าหมายเหล่านี้หรือไม่ ?
ถ้าไม่ใช่ น่าจะใช้เครื่องมือผิดวิธีแน่นอน
มาเริ่มกัน

Postman นั้นมีความสามารถเยอะมาก ๆ

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

• ทดสอบผ่าน protocol ต่าง ๆ เช่น HTTP, MQTT (beta), WebSocket, Socket.io, GraphQL, gRPC
• เขียน test script สำหรับตรวจสอบ response ว่าเป้นไปตามที่คาดหวังหรือไม่ และจัดการ request ต่าง ๆ ก่อนส่ง request ด้วย pre-request script โดยเขียนในรูปแบบของภาษา JavaScript
• ทำการจัดการสร้าง request สำหรับทดสอบ protocol ต่าง ๆ ด้วย Collection และ folder
• โดยปกติจะให้แต่ละ collection มีจำนวน request ไม่เยอะ หรือ แยกตาม flow หรือ scenario เลย ทำให้จัดการง่ายขึ้น
• อีกอย่าง Postman นั้นมี workspace ให้อีกด้วย
• การใช้งาน variables สำหรับการจัดการข้อมูลต่าง ๆ ใน Postman ซึ่งมีทั้ง request variable, collection variable และ global variable
• ชนิดของ variable มีทั้ง plain text และ secret
• การใช้งาน environment สำหรับจัดการ variable ตาม environment ต่าง ๆ ของระบบที่จะทดสอบเช่น dev, test, staging และ prod เป็นต้น
• สามารถทำการออกแบบ HTTP Request API ก่อนที่จะพัฒนาได้ รวมทั้งสามารถเขียนเอกสารในรูปแบบ markdown ของ collection และ request ได้เลย ดังนั้นทำให้เราพัฒนาในรูปแบบของ API-first ได้
• ในส่วนของการออกแบบ API นั้น สามารถกำหนดในส่วนของ response ตามแต่ละรูปแบบ เช่น success และ fail ด้วยการเพิ่ม example เข้าไปในแต่ละ request ได้เลย
• การกำหนด working directory สำหรับ postman ในการจัดการเกี่ยวกับ data file ต่าง ๆ ที่ใช้ใน postman เพื่อให้ทุกคนในทีมสามารถใช้งานได้เหมือนกัน เพื่อตัดปัญหาเรื่อง path ของ file
• หลังจากการออกแบบแล้วนั้น สามารถทำการสร้าง Mock Server ผ่าน collection (จะมี request อยู่ใน collection) ที่เราสร้างขึ้นมาได้
• สิ่งที่เจอปัญหาคือ Mock Server ทำงานแปลก ๆ เรื่องของการ matching example ซึ่งมีแนวคิดและขั้นตอนใน Understanding example matching
• สามารถ export collection ต่าง ๆ ออกมาเป็นไฟล์ แล้วจัดเก็บใน version control system เพื่อ share กันในทีม (ใช้เมื่อไม่ต้องการใช้งานผ่าน postman team)
• ในการทดสอบนั้น จะใช้ newman เข้ามาใช้งาน เพื่อ run collection ผ่าน command line ได้ เพื่อให้สามารถทดสอบได้บ่อย และ ง่ายขึ้น รวมทั้งไป integrate เข้ากับ CI/CD ได้อีกด้วย
• มี API platform สามารถทำงานร่วมกับ Swagger หรือ Open API Specification ได้เลย
• คร่าว ๆ น่าจะประมาณนี้

รูปแบบของการทดสอบนั้นสำคัญมาก ๆ

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

• Integration test
• Component test (mock/fake dependencies)
• Contract test ทั้ง Postman และ Pact

ซึ่งต้องรุปตั้งแต่ architecture ของระบบงาน
เพื่อวาง test strategy ต่าง ๆ ออกมา
เพื่อให้ออกแบบระบบให้รองรับกับแนวทางในการทดสอบต่อไป
มันคือ กระบวนการคิดก่อนทำ

ในการทดสอบจะทำทั้ง functional test และ non-functional test

โดย non-functional test คือ performance test
ซึ่ง postman สนับสนุนด้วย
แต่ถ้าอยากทดสอบด้วยเรื่องมืออื่น ๆ
ก็สามารถทำการ convert จาก postman collection ไปยัง script ของเครื่องมืออื่น ๆ ได้
ยกตัวอย่างเช่น

• Postman to K6
• Postman to Apache JMeter

สิ่งที่สำคัญคือ load type ของการทดสอบว่าต้องการอย่างไรบ้าง

ไว้เจอกันการ sharing ต่อ ๆ ไป

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

Java 21 GA นั้นเพิ่งปล่อยออกมานั้น
มี JEPs ออกมา 15 ตัว พร้อมกับแก้ไข bug ไปมากกว่า 2,000 ตัว
โดย feature มีดังนี้

• Vector API (Sixth Incubator)
• String Templates (Preview)
• Unnamed Patterns and Variables (Preview)
• Unnamed Classes and Instance Main Methods (Preview)
• Scoped Values (Preview)
• Foreign Function & Memory API (Third Preview)
• Structured Concurrency (Preview)

มาดูตัวที่น่าจะได้ใช้กัน

Record Patterns – JEP 440

เพิ่มเข้ามาตั้งแต่ Java 19 แล้ว
สามารถทำงานร่วมกัย instanceof และ switch-case ได้

String Templates (Preview)

Unnamed Patterns and Variables (Preview)

Structured Concurrency (Preview)

สำหรับ concurrent program ใน thread ต่าง ๆ ตัวอย่างเช่น

Unnamed Classes and Instance Main Methods (Preview)

พร้อม upgrade Java 21 กันหรือยัง

Reference Websites

• The Arrival of Java 21!
• Java 21 features
• Java 21 Features: Practical Examples and Insights

มีคำถามเกี่ยวกับการใช้งาน newman
สำหรับการ run collection ของ Postman ผ่าน command line
จึงทำการสรุปไว้ดังนี้

คำถามที่ 1 ทำการ run collection อย่างไร

ขั้นตอนหลังจากที่สร้าง colelction ใน Postman แล้ว
เราสามารถ share หรือ export collection ออกมาได้
ในกรณีที่ export เป็นไฟล์ออกมา จะอยู่ในรูปแบบ JSON
ทำการ run ดังนี้

สามารถ run โดยระบุชื่อง folder ที่ได้การได้ด้วย
ในกรณีที่แบ่งกลุ่มของ request ด้วย folder ใน collection
หรือแบ่งเป็น flow/scenario นั่นเอง
ทำการ run ดังนี้

ถ้าจะให้ดีแยกแต่ละ flow/scenario เป็นคนละ collection ดีกว่านะ

คำถามที่ 2 ในการจัดการเกี่ยวกับไฟล์ data ต่าง ๆ

ใน request ของ postman มักจะมีการใช้งานไฟล์ต่าง ๆ
เช่นใน request ต้องทำการ upload file
ปัญหาที่ตามมาคือ เครื่องอื่นไม่สามารถทดสอบได้
เนื่องจากไม่เจอไฟล์ที่เรากำหนดไว้ใน request/collection

ปัญหานี้แก้ไขด้วยการกำหนด working directory ของ Postman ก่อน
โดยเข้าไปที่ settings ได้เลย

จากนั้นก็นำไฟล์ต่าง ๆ ที่ใช้งานไปไว้ใน working directory
ก็จะสามารถ run request/collection ได้แล้ว

ส่วนใน newman ก็กำหนด working directory ได้ด้วย ดังนี้

คำถามที่ 3 ถ้าต้องการให้ newman ทำการหยุดทดสอบเมื่อเจอ error (Fail fast)

ถ้าต้องการ fail fast สามารถทำได้ดังนี้

สามารถดู option ต่าง ๆ ของ newman ได้ด้วยคำสั่ง

ขอให้สนุกกับการทดสอบครับ

มีโอกาสไปร่วมงาน LINE Conference Thailand 2023 ที่ BITEC บางนา
เนื่องจากติดงาน เลยเข้าร่วมงานสาย
แต่ก็ได้ฟังหลาย ๆ เรื่อง
เป็นเรื่องที่น่าสนใจ ทั้งสถิติการใช้งาน ทั้ง product ใหม่ ๆ
แน่นอนรวมทั้งฝั่ง development ที่ได้เพิ่มหลายสิ่งอย่างเข้ามาใน platform
มาดูกันว่ามีอะไรบ้างแบบคร่าว ๆ

ในฝั่งของข้อมูลสถิติที่น่าสนใจ

• LINE user ในไทยมีจำนวน 54 ล้าน ลองคิดตามดูว่า คนไทย 70+ ล้านคน แสดงว่านับที่สมัครในไทย หรือ คนไทย หรือว่า 1 คนมีมากกว่า 1 account
• กลุ่มคนใช้งาน LINE เยอะ คือ 15-19 ปี และ 50 ปี ขึ้นไป แสดงว่านักเรียน นักศึกษา กับผู้สูงอายุ
• คนไทยใช้งาน LINE เพื่อตามงานสูงมาก ๆ เป็นอันดับต้น ๆ ของทั้งโลก แสดงว่าใช้งานคล้าย ๆ กัน แถมในกลุ่มทำงาน active 7 วันต่อสัปดาห์ นี่ไม่พักกันเลย
• มีการส่งรูป และ ไฟล์ต่าง ๆ สูงมาก ๆ
• ดังนั้นใน Line group จึงมีการเพิ่ม feature สำหรับจัดการไฟล์ และ การจัดตารางงาน เข้ามา
• มี product ใหม่คือ LINE Sticker Premium !! เป็น subscription-based หรือเหมา ๆ ไปเลย
• LINE Chatbot น่าจะ active สุด ๆ แล้ว เพราะว่ามีการนำมาใช้งานเยอะมาก ๆ
• สวัสดีวันจันทร์ มีแต่ในไทยเท่านั้น !!!

ในฝั่งของนักพัฒนาก็มีดังนี้

• เพิ่มความสามารถใหม่ ๆ เข้ามา เช่น Rich-menu personalized, Retarget rich-menu และ Flex message (hecto และ deca) และมี Rich Menu Batch API เพิ่มเข้ามา ทำให้เปลี่ยน Rich menu ภายใน request เดียวกันได้เลย
• Flex message ตามชื่อเลยคือ ออกแบบ message ให้ยืดหยุ่นตามแต่ละ device หรือ app เลย ทั้ง LINE app บนมือถือ และ PC หรือผ่าน LIFF app ก็ได้ และได้เพิ่ม bubble size เข้ามา ทำให้มี giga, mega(default), kilo, hecto, deca, micro, nano รวมทั้ง scale ขนาดของ font ต่าง ๆ ตาม user setting ไว้ได้เลย
• เพิ่ม Quick reply message ใน LINE บน PC desktop
• Bot สามารถตอบกลับ @all ในกลุ่มได้แล้ว ซึ่งจะมี webhook ไว้ให้ใช้งาน
• สามารถส่ง message หาคนที่ไม่ได้อยู่ในกลุ่ม หรือ ไม่ได้ follow ได้ด้วย โดยจะใช้งานผ่านเบอร์มือถือ เรียกว่า Line Official Notification (LON)
• ใน Message API เพิ่ม Stateless Channel Access Token เข้ามา โดยมีอายุ 15 นาที ไม่มีจำกัดการ issue token ใหม่ ทำให้ไม่ต้องมาเสียเวลาจัดเก็บ token อีกต่อไป เปลี่ยนมาเป็นใช้แล้วทิ้ง ลดงานและเพิ่มความปลอดภัยมากขึ้น

ดังนั้นเรื่องของ channel token จึงมีทางเลือก 3 ทางคือ

• Long-live
• Short-live
• Stateless

• มี OpenAPI Specification มาให้เลย ไม่ได้มานั่งหา หรือ ทำ หรือ share Postman collection กันแล้ว โดยทำไว้ให้ใน GitHub LINE OpenAPI

เพิ่มเติมสำหรับ OpenAPI Specification เราสามารถนำไปใช้อย่างไรได้บ้าง ?

• ทำการ import เข้า Postman เพื่อทดสอบได้เลย
• ทำการ Mock server ได้ง่าย ๆ
• ทำเอกสารแบบชิว ๆ
• ทำการ generate code เพื่อสร้าง server ได้เองอีกด้วย

• ในส่วนของ LINE Shopping API ก็มาเยอะเช่นกัน ทั้งเป็น Open Platform และได้เพิ่ม API ใหม่ ๆ เข้ามาให้ใช้ ทั้งการจัดการ product ที่แต่ก่อนมีแต่ดึงข้อมูล ตอนนี้ครบ รวมทั้งการจัดการ order หรือ เปิด order ไปถึงการ cancle order อีกด้วย โดยในส่วนนี้ได้ทำเป็น webhook ให้ ทำใมห้สามารถ integrate กับระบบงานได้ง่ายอีกด้วย มองว่าตัวเองเป็น Platform จริง ๆ ตรงนี้น่าสนใจ
• มี API เพิ่มคือ product, inventory, order, order webhook
• ปลายปีนี้จะมีจัดงาน hackaton สำหรับ LINE Shopping API อีกด้วยนะ ติดตามข่าวกันดี ๆ

• อีกทั้งในเรื่องของหน้า API Document ก็ทำการปรับปรุงใหม่
• ลองไปดู API Document เหมือนจะ generate มาจาก OpenAPI Specification หรือ Swagger ด้วยเครื่องมือชื่อว่า redoc

• เปิด LINE Developers Codelabs ให้เข้าไปเรียนเรื่อง Generative AI ฟรี ๆ

ปล. 1 โดด workshop สุดท้าย เพื่อไปสนามบิน ... เดี๋ยวตกเครื่อง

ปล. 2 เวทีแสบตามาก ๆ ยิ่ง slide เป็นพื้นสีขาวนะ มันจ้าซะเหลือเกิน

ปล. 3 ของว่างอร่อยมาก กินไปเยอะเลย

เห็นว่ามีระบบ Unit Tests Generator จาก AI นี่แหละ
เป็นอีกแนวทางที่น่าสนใจกับการทดสอบ
โดยจะสนับสนุน code ในภาษาต่าง ๆ เช่น

• Go
• C#
• Java
• Python
• NodeJS
• JavaScript

และยังแยกไปตาม framework หรือ library ในแต่ละภาษาได้อีกด้วย

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

มีโอกาสแบ่งปันความรู้เรื่อง Mobile Testing ด้วย Appium และ Robot framework
โดยสิ่งที่ทำการแบ่งปันประกอบไปด้วย

• รูปแบบของการทดสอบ
• ขั้นตอนการใช้งาน Appium ในการทดสอบ
• ขั้นตอนในการทดสอบของ app ต่าง ๆ เช่น Native App และ Flutter app
• การเขียน test case ด้วย Robot framework และ library เพิ่มเติม
• การ scale ระบบหรือ platform ของการทดสอบแบบอัตโนมัติของ appium

มาดูรายละเอียดการแบ่งปันกัน

รูปแบบของการทดสอบ Mobile app

แบ่งออกเป็น 2 ชนิดหลัก ๆ คือ

• External testing หรือ black-box testing
• Internal testing หรือ white-box testing

โดยที่ External testing เป็นการทดสอบในมุมมองของผู้ใช้งานเป็นหลัก
เป็นการทดสอบผ่าน mobile app จริง ๆ
ซึ่งมีความน่าเชื่อถือสูง แต่ใช้เวลาในการทดสอบสูง
รวมทั้งการ setup ระบบที่เกี่ยวข้อง และ การ initial data ต่าง ๆ เยอะ
ผลที่ตามมาคือ การทดสอบไม่ค่อยเสถียร และ ทดสอบซ้ำ ๆ ได้ยากมาก
ดังนั้นจึงมักจะต้องทำการ mock dependency ต่าง ๆ ขึ้นมา
รวมทั้งการส่งข้อมูลไปมา จะเข้ารหัส หรือ ไม่เข้ารหัส
หรือการทดสอบแบบ flow ต้องกดเยอะ ๆ ไปทุกหน้าเองหรือไม่
ยิ่งระบบมี flow ที่ซับซ้อน ยิ่งลำบากไหม
ตรงนี้ต้องวางแผนกันก่อนที่จะเริ่มพัฒนานะ

ส่วน internal testing เป็นการทดสอบในมุมมองของทีมสร้างหรือพัฒนา
จะเห็นทุกสิ่งอย่าง ของการพัฒนา mobile app ว่า
แต่ละส่วนงานทำงานอย่างไรบ้าง ซึ่งจะมีการทดสอบหลายชนิดเช่น

• Unit testing
• Widget testing (Flutter)
• Integrate testing

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

การใช้งาน Appium สำหรับทดสอบ Mobile app

โดยเป็นการทดสอบแบบ External testing นั่นเอง
จะต้องมีการติดตั้ง software เยอะใช้ได้ ดังนี้

• Appium server จะติดตั้งผ่าน npm ดังนั้นต้องติดตั้ง NodeJS ก่อน
• ส่วน Appium Server Destop ที่เป็น GUI นั้นเลิกพัฒนาแล้วตั้งแต่ต้นปี 2023 ดังนั้นเลิกใช้ได้แล้ว
• Appium Inspector สำหรับดูว่า element ต่าง ๆ ในหน้าจอของ mobile app เป็นอย่างไร
• โดยที่ Appium Inspector จะรองรับกับ Native app เท่านั้น ส่วน app ที่พัฒนาด้วย Flutter จะไม่สามารถ inspect ได้ ต้องไปใช้งาน Flutter Inspector แทนเอา
• ก่อนที่จะติดตั้ง appium ให้ใช้งาน appium doctor ในการตรวจสอบ environment ของเครื่องว่ายังขาดอะไรบ้าง ส่วน flutter ก็น flutter doctor ได้เลย
• สำหรับ Flutter app นั้น ทาง appium server จะต้องลง flutter driver ด้วย รวมทั้งใน code ก็ต้องเพิ่ม dependency ของ flutter driver อีกด้วย ยังไม่พอใน code ของ widget นั้น ต้องเพิ่ม key เข้าไป เพื่อใช้ในการเข้าถึง widget หรือ element ต่าง ๆ ได้จากชุดการทดสอบ จะเยอะนิดหน่อย !!

การเขียน test case ด้วย Robot framework

• ถ้าเป็น Native app จะใช้งานผ่าน AppiumLibrary
• ถ้าเป็น Flutter app ที่ใช้งาน appium flutter driver จะใช้งานผ่าย AppiumFlutterLibrary

ปล. ระวังเรื่อง selenium library ด้วย !!

การ Scale appium ด้วย Selenium grid

การทดสอบแบบ EXternal testing นั้น เมื่อจำนวน test case เยอะขึ้น ปัญหาก็ตามมา
ยกตัวอย่างเช่น

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

ดังนั้นเราสามารถลด หรือ แก้ไขปัญหาเหล่านี้
ด้วยการสร้าง Mobile testing platform หรือ Mobile farm ด้วย Selenium grid

มีโครงสร้างการทำงานดังนี้

ขอให้สนุกกับการทดสอบ Mobile app ด้วย Appium
แต่จะให้ดี แนะนำให้ไปทดสอบแบบ internal testing เยอะ ๆ ครับ

ทาง MongoDB เพิ่ม feature preview ชื่อว่า Generative AI เข้ามาใน Atlas compass
เพื่อช่วยในการสร้าง query และ aggregate ของ MongoDB ให้เลย
จาก prompt ที่เราสามารถเขียนและส่ง request ไปได้เลย
รวมทั้งแปลง SQL มาเป็น MongoDB query ให้เลย
ยังมีการสร้าง graph ของข้อมูล ใน Atlas chart และค้นหาเอกสารในรูปแบบ chatbot ได้

ลอลใช้งานการ query และ aggregate ดูได้เลย

ลองเขียน prompt เพื่อให้สร้าง query ให้แบบง่าย ๆ

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

Reference Websites

• MongoDB Announces Four New AI-Powered Capabilities to Improve Developer Productivity and Accelerate Application Modernization

เพิ่งสังเกตว่าใน Google Chrome นั้น จะแสดงการใช้งาน memory ในแต่ละ tab ให้แล้ว
เพียงแค่นำ mouse มา over ที่ tab นั้น ๆ ก็เห็น
ไม่ต้องไปดู task manager แล้ว

แสดงการทำงานดังรูป

อีกทั้งสามารถทำการเปิด หรือ ปิด ความสามารถนี้ได้ใน
chrome://flags/#memory-saver-memory-usage-in-hovercards

และยังมีความสามารถเรื่อง Memory saver
เพื่อช่วยลดการใช้งาน memory สำหรับ tab ที่ inactive ให้อีกด้วย
chrome://settings/performance

เป็นอีก feature ที่น่าสนใจ
จะได้ show ให้เห็นเลยว่า Google Chrome ในแต่ละ tab
ใช้งาน memory กันอย่างไรบ้าง !!!

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

เริ่มง่าย ๆ ก่อนคือ Selenium Grid ที่ใช้งานเป็น version อะไร ?

ในตอนนี้คือ Selenium Grid 4 จะมี component และ architecture ดังรูป

และ version ของ Appium ที่ใช้งานคือ 2.1
เพื่อช่วยให้เรารู้ก่อนว่า จะต้องอ่านเอกสารอะไรบ้าง ให้ถูกต้อง

ใน blog นี้จะใช้ version ล่าสุด โดยมีขั้นตอนดังนี้

ขั้นตอนที่ 1

สร้าง Appium server สำหรับ run mobile app ใน device ต่าง ๆ ด้วย driver

• ถ้า ios จะใช้ driver = xcuitest
• ถ้า android จะใช้ driver = UIAutomator2 หรือ Espresso

ตัวอย่างของ config

ทำการ start appium server ดังนี้

ขั้นตอนที่ 2

ทำการ start SeleniumGrid :: Hub ขึ้นมา ดังนี้

ขั้นตอนที่ 3

ทำการ start Selenium Grid ด้วย node role
เพื่อสร้าง node สำหรับ Appium server ที่สร้างขึ้นมา และ register ไปยัง Hub ที่สร้างไว้

ทำการ start Node ดังนี้

จากนั้นเข้าไปที่หน้า UI ของ Selenium Grid ที่ http://localhost:4444/ui
จะแสดงข้อมูล Node ดังนี้

เพียงเท่านี้ก็สามารถ setup Selenium Grid และ Appium มาได้แล้ว
จากนั้นก็ส่ง request การทดสอบมายัง Hub
ก็จะส่ง request นั้นไปยัง Node ที่เหมาะสมต่อไป

หนึ่งในคำถามใน course Microservice Design ที่ Skooldio ที่น่าสนใจคือ
แนวทางในการปรับปรุงประสิทธิภาพการทำงานของ APIs ให้ดีขึ้น
ว่าเราควรทำอย่างไรบ้าง ?
เท่าที่จำได้ก็จะตอบไปบางส่วน
จึงได้ทำการหาและสรุปข้อมูลเพิ่มเติม ได้ดังนี้
คิดว่าน่าจะพอมีประโยชน์

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

• VDO Top 7 Ways to 10x Your API Performance จาก ByteByteGo
• 8 Tips for Optimizing an API

มาดูรายละเอียดกันนิดหน่อย

เรื่องที่ 1 คือ การออกแบบ API ให้มีมาตรฐานเดียวกัน (Consistency)

อาจจะไม่เกี่ยวกับ performance มากเท่าไร
แต่เป็นสิ่งที่สำคัญมาก ๆ เพื่อให้ทั้งคนออกแบบ และ ใช้งาน และ พัฒนา ทำงานง่ายขึ้น
เพื่อเพิ่ม productivity ให้กับงานอีกด้วย
รวมทั้งเรื่องของการ monitoring/observability อีกด้วย
แล้วอย่างลืมเรื่องของ API compatablity ด้วย

เรื่องที่ 2 การจัดการกับข้อมูลจำนวนมาก

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

ถ้าข้อมูลมากจริง ๆ ควรทำการแยกข้อมูลเป็นส่วน ๆ ไปตามการใช้งาน
ยกตัวอย่างเช่น

• แยกข้อมูลตามช่วงเวลา เช่น แยกเป็นรายปี รายเดือน เป็นต้น
• แยกข้อมูลตามจังหวัด หรือ ประเทศ หรือ กลุ่มการใช้งาน
• การทำ pre-join หรือ pre-aggregate เพื่อลดการประมวลผล
• ลดการ order by ลงไปให้มาก ๆ เพราะว่า ใช้ resource เยอะมาก ๆ

ในการแยกข้อมูลของ database นั้นมีทั้ง partition และ sharding ที่ควรต้องทำ
เราคงไม่อยากไปดึงข้อมูลบางส่วน จากข้อมูลทั้งหมดที่มีจำนวนเยอะ ๆ หรอกนะ

เรื่องที่ 3 คือ Caching data ลองอ่านเพิ่มเติมได้

เรื่องที่ 4 ข้อมูลที่ส่งไปมาของ API ควรมีขนาดที่เล็ก

การออกแบบข้อมูลให้มีเท่าที่ใช้งานจริง ๆ จึงสำคัญมาก ๆ
รวมทั้งการบีดอัดข้อมูลก่อนส่งทั้ง request และ response
หรือการใช้งานรูปแบบข้อมูลที่เหมาะสม
เช่น

• Plain-text
• Binary

ตัวอย่างหนึ่งที่แนะนำคือ REST VS gRPC เป็นต้น

เรื่องที่ 5 การเลือกใช้ Database model ให้เหมาะสมกับงาน

เนื่องจาก Database model นั้นมีหลายรูปแบบ เช่น

• Relation
• Key-value
• Document
• Column
• Graph
• Search
• Time-series

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

เรื่องที่ 6 ปรับปรุงการเข้าถึงข้อมูล หรือ API หรือ Legacy system จำนวนมาก

ปัญหาที่มักจะพบเจอคือ

• การเข้าถึง database
• การทำ caching
• การ composition ข้อมูล
• การลด latency time ต่าง ๆ
• การลดขนาดของข้อมูล
• การจัดการเรื่อง security

สามารถนำ API gateway, GraphQL และ Load balance มาใช้งานเพิ่มเติมได้
รวมทั้งเรื่องของ CDN (Content Delivery Network) มาช่วยอีกด้วย

การสร้าง Docker image นั้น สามารถสร้าง image แบบ Multi-architecture ได้
โดยทำการ build ผ่าน Buildx
มีขั้นตอนดังนี้

ทำการสร้าง image ผ่าน buildx command ดังนี้

ขั้นตอนที่ 1 ทำการสร้าง Builder ใหม่ก่อน

ขั้นตอนที่ 2 ทำการ build image ตาม architecture และ platform ที่ต้องการ

• linux/amd64
• linux/arm64
• darwin/arm64

ถ้ามีการใช้ Docker image อื่น ๆ ต้องดูด้วยว่า platform ที่ระบุไว้ในการ build มีหรือไม่ด้วย
ยกตัวอย่างเช่น Golang จะทำการ build ตาม architecture ต่าง ๆ ให้อีกด้วย

ขั้นตอนการ build image

ลองดูได้ที่ Docker Hub ว่า image ที่สร้างสนับสนุน platform อะไรบ้าง

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

เพิ่งรู้ว่าตั้งแน่ Go 1.21 นั้น เพิ่ม Go Toolchains เข้ามา
สำหรับการกำหนดว่าจะใช้ go version อะไรได้เลย
ซึ่งเข้ามาช่วยแก้ไขปัญหา

• ถ้าใน project ของเรานั้นใน go.mod มี version ของ go ที่แตกต่างกัน จะทำอย่างไร
• ถ้าอยากเปลี่ยนใช้งาน go version ใหม่ ๆ ทำอย่างไร

จากคำถามหรือปัญหาเหล่านี้
สามารถใช้งาน Go Toolchains มาช่วยได้ ดังนี้

ปัญหาที่ 1 ถ้าใน project ของเรานั้นใน go.mod มี version ของ go ที่แตกต่างกัน จะทำอย่างไร

ในไฟล์ go.mod ใช้งาน go 1.21.1 แต่ในเครื่องเราใช้งาน go 1.21.3
สามารถทำได้ดังนี้

ปัญหาที่ 2 ถ้าอยากเปลี่ยนใช้งาน go version ใหม่ ๆ ทำอย่างไร

เช่นต้องการเปลี่ยนไปใช้ go 1.21.3 ทำได้ดังนี้

เพียงเท่านี้ก็ใช้งานได้แล้ว
แต่ใช้ได้ตั้งแต่ go 1.21 ขึ้นไปเท่านั้น