สัปดาห์ที่ผ่านมา มีอธิบายเรื่องของการทดสอบแบบอัตโนมัติไป
ทั้ง Unit, Component, Contract และ Integration test ไป
มักจะมีคำถามมากมายมาเสมอ ยกตัวอย่างเช่น

• ใครเป็นคนออกแบบ
• ใครเป็นคนเขียน
• ใครเป็นคน run test และ สรุปผล
• ใครต้องมาทำบ้าง
• จะมั่นใจได้อย่างไร ว่ามันทดสอบถูก

และอื่น ๆ อีกมากมาย
คำถามต่าง ๆ ล้วนมาจากคนที่ไม่ทำ ไม่เคยทำ และ จะทำ
ดังนั้นมาลองตอบแบบสั้น ๆ ไว้นิดหน่อย

คำถามใครเป็นคนออกแบบ ทดสอบ และ สรุปผล ?

ตอบด้วยคำถามว่า ออกแบบตอนไหนก่อน สำหรับ test case ?
ส่วนใหญ่ได้คำตอบ 2 แบบ คือ

• ออกแบบหลักจากได้รับ requirement หรือ บางคนเข้าไปคุย requirement ด้วยเลย
• ออกแบบหลักจากที่ทีมพัฒนาส่งมาให้ และ บอกว่า เสร็จแล้ว พร้อมทดสอบ

ทั้งสองแบบมีปัญหาหรือไม่ ?

แบบแรกดูดีมาก ๆ แต่ได้เอาไปให้ทีมพัฒนาดู หรือ ประกบไปกับ requirement หรือ technical spec ไหม ?
ส่วนใหญ่บอกว่า ไม่ เพราะว่า จะรอยิง !!

แบบที่สองนี่ชัดเจนว่า รอยิง !!

ผลที่ตามมาคือ bug เพียบ
แล้วก็บ่น
แล้วก็ด่า
แล้วก็โยนงานกันไปมา
ไม่จบไม่สิ้นสัก

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

คำถามที่ตามมา คือ ใครจะเขียน automated test case ละ ?

คำตอบที่มักจะได้คือ ไม่มีใครทำ
ดังนั้น จ้างเลย หรือ รับสมัครงาน automated tester ไปเลย
คิดว่า จะดีขึ้นไหม ? คิดเอาเอง

ดังนั้นย้อนกลับมาที่จุดเริ่มต้นกันดีกว่า ...

ก่อนจะถามว่าใคร
มาคุย end to end process ของการ delivery software ก่อนไหม
ว่าปัจจุบันเป็นอย่างไร
มีปัญหา หรือ pain point ตรงไหนบ้าง
จะได้ทำการปรับปรุง และ แก้ไขปัญหาได้อย่างถูกจุด
ไม่ต้องมาลีลา หรือ รำไปรำมาเยอะ

เช่น process การทำงานเป็นดังนี้

• คุย requirement แล้วได้เอกสารออกมา เพื่อเอาไป design ต่อ
• ทำการ design ทั้ง architecture และ feature
• ทำการ design ในฝั่ง technical
• ทำการพัฒนา
• ทำการทดสอบ
• ทำการส่งมอบ

ปัญหามีอะไรบ้าง จาก process ข้างต้น

เน้นที่เฉพาะการทดสอบก่อนก็ได้

• ทีมออกแบบ ทีมพัฒนา ทีมทดสอบ มี requirement คนละชุด หรือ คนละ version เพราะว่า ระหว่างทางเปลี่ยนไปเรื่อย ๆ แล้วไม่พูดคุยกัน สนุกเลย !!
• คุณภาพแย่หลังส่งมอบ
• ทดสอบช้า
• ทดสอบซ้ำ ๆ ทั้งหมดไม่ค่อยได้ (regression test)
• ในการพัฒนาเจอ bug เยอะ พอมาทดสอบก็เจอเยอะ วนแก้ไปมาหลายรอบมาก ๆ บางคนแก้ไขและทดสอบจนท้อ
• ทำเอกสารการทดสอบไป ทำเองทดสอบเอง นักเลงพอ

ปัญหาข้างต้นอยากแก้ไขอะไรไหม ?

ยังไม่ต้อง automated test นะ เอา manual test ก่อนนะ
เพื่อให้ปัญหาข้างต้นมันลดลง

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

คุณภาพของ software มันแย่ เช่น bug เยอะ จะแก้ไขอย่างไรดี ?

ทดสอบบ่อย ๆ ได้ไหม ไม่ต้องรอให้เสร็จทุก feature
แบบนี้ทำได้ไหม
มาวางแผนกันไหม
ทั้งคนคุย requirement คนออกแบบ ทั้งคนพัฒนา และ คนทดสอบ

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

อยากทำงานแบบแมวจับหนู หรือ ทำงานเป็นทีม ก็เลือกเอา !!

พอชุดการทดสอบเยอะ ๆ น่าจะมีปัญหาเรื่องการทดสอบทั้งหมดซ้ำ (regression test)

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

แล้วจะกลับไปที่คำถามแรก เรื่อง ใครทำอีกที !!!

ใน NodeJS 20.4.0 ซึ่งเป็น current version นั้น
มี experiment feature ออกมาคือ MockTimers
มาช่วยในการทดสอบระบบงานให้เสถียรมากขึ้น และ คาดเดาได้
เมื่อต้องทำงานกับ setTimeout() และ setInterval()
โดยการจำลอง (mock) พฤติกรรมการทำงานให้เป้นไปตามที่ต้องการ
ทั้ง success และ failure case ต่าง ๆ ขึ้นมาได้
โดยไม่ต้องไปรอตามเวลาที่ต้องกำหนดจริง ๆ

ตัวอย่างการใช้งานเป็นดังนี้

ผลการทดสอบ

ลอง download หรือ update มาใช้งานกันดูครับ

จากบทความของ Elastic เรื่อง Pruning incoming log volumes with Elastic
อธิบายถึงการเก็บข้อมูลใน Elastic stack ว่า
ข้อมูลที่จัดเก็บนั้นมีจำนวนที่เยอะ รูปแบบที่หลากหลาย
ส่งผลให้ระบบมีปัญหาในการจัดเก็บ การประมวลผล หรือ ใช้งาน
ดังนั้น สิ่งหนึ่งที่เราควรทำก่อนคือ
รู้ว่าข้อมูลอะไรบ้างที่ใช้ และ ไม่ใช้งานบ้าง
เพื่อที่จะเก็บเท่าที่ใช้งานเท่านั้น มิใช่เก็บไปเสียทุกอย่าง

ดังนั้นมาดูกับว่าในบทความข้างต้นแนะนำวิธีการอย่างไรบ้าง ?

• Beats
• Logstash
• Elastic Agent
• Ingest pipeline
• OpenTelemetry collector

ตัวอย่างที่ 1 Beats

ในส่วนของ processor สามารถทำการ drop หรือลบพวก event และ field/property ต่าง ๆ ได้
เช่น

ตัวอย่างที่ 2 Logstash

ใน Logstash จะมีส่วนการทำงาน filter สำหรับกรองข้อมูลต่าง ๆ
ทั้งเพิ่ม เปลี่ยน และ ลบ รวมทั้งการ transform ข้อมูลไปยังรูปแบบต่าง ๆ ที่ต้องการ
หรือจำนวน % ข้อมูลที่จะจัดเก็บได้อีกด้วย
แต่ Logstash นั้นจะใช้ resource เช่น CPU และ Memory เยอะมาก ๆ ต้องใช้อย่างระมัดระวัง

ตัวอย่างที่ 3 Ingest Pipeline

เป็นอีก feature ของ Node ใน Elasticsearch
สามารถเขียน ingest pipeline ได้ หรือ เทียบง่าย ๆ คือ store procedure ใน database นั่นเอง
ซึ่งสามารถเขียนในส่วนของ processor โดยเขียนด้วย Painless script ดังนี้

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

เห็นเอกสารเรื่อง The Way Of Testivus ทำการ share ใน feed
เห็นน่าสนใจดีเลยนำมาสรุปในสิ่งที่ชอบไว้นิดหน่อย
โดยพูดถึงเรื่องของการเขียน unit test
เพื่อแนะนำให้นักพัฒนาได้เข้าใจ
แต่ผมคิดว่า
มันใช้ได้กับทุก ๆ คนที่เกี่ยวข้องกับการส่งมอบ software นะ
ต้องรู้และเข้าใจว่า ทำ หรือ ไม่ทำ เพราะว่าอะไร
และมีข้อดี และ ข้อเสียอะไรบ้าง

มาดูว่าในเอกสารนี้เขียนอะไรไว้บ้าง

• ถ้าเขียน code ก็ต้องเขียน test ด้วย
• จะหยุดเขียน test เมื่อใด คำตอบคือ เมื่อหยุดเขียน code
• จะหยุดเขียน code เมื่อใด คำตอบคือ เมื่อไปเป็น manager
• จะเป็น manager เมื่อใก คำตอบคือ เมื่อหยุดเขียน test
• อย่าไปยืดติดมากนัก ต้องมีความยืดหยุ่น ปรับให้เข้ากับสถานการณ์ และ ความต้องการ แต่ยังอยู่บนเป้าหมายเดียวกัน คือ ความรวดเร็ว และ คุณภาพที่สูง
• Code และ test ให้คิดว่ามันคือสิ่งเดียวกัน ไม่แยกออกจากกัน ทำสิ่งหนึ่งต้องคิดถึงอีกสิ่งหนึ่งเสมอ ไม่ใส่เดี๋ยวค่อยทำ
• Test นั้นสำคัญกว่า unit test ดังนั้นเรื่องของการ test จึงสำคัญ ไม่ว่าจะเป็นอะไร เน้นที่เขียนหรือสร้างมันขึ้นมาก่อน มีย่อมดีกว่าไม่มี ไม่ใช่ unit test ก็ไม่เป็นไร มันยังมี test อยู่ใช่ไหม และเราก็เชื่อมั่นอีกด้วย
• เวลาที่เหมาะสมมาก ๆ ของการเขียน test คือ ช่วยที่ code ยังใหม่ ๆ อยู่ ระหว่างของสด ๆ กับขอค้างคืนจนเน่า ชอบอะไร มันจะช่วยให้ง่ายต่อการเปลี่ยนแปลง การทดสอบก็ง่ายขึ้น และทำให้ทั้ง code และ test มีความน่าเชื่อถือมากขึ้น
• มี test แล้วไม่ยอม run ก็ไร้ค่า ดังนั้น run บ่อย ๆ
• วันนี้ test อาจจะไม่สมบูณณ์แบบ ไม่เป็นไร ยังดีกว่าไม่มี ทำให้ดีขึ้นเรื่อย ๆ ดีกว่าทำให้สมบูรณ์แบบในครั้งเดียว ทุกอย่างต้องมีการพัฒนาเสมอ
• เครื่องมือต่าง ๆ ล้วนสำคัญ ถ้ามันช่วยลดงานต่าง ๆ ลงไปได้ ไม่ใช่ต้องทำด้วยตัวเองทั้งหมด เอาเวลาเหล่านั้นไปทำอย่างอื่นที่ดีกว่า
• ถ้า test ที่มีrunแล้วผ่านหมดตลอด นั่นหมายความว่า ถึงเวลาที่ต้องเขียน test ที่ดีกว่าแล้วนะ

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

ใน course Microservices ที่ Skooldio นั้น
มีคำถามเรื่องเกี่ยวกับรูปแบบของการแลกเปลี่ยนข้อมูลระหว่าง service
ว่า CDC (Change Data Capture) และ Outbox pattern มันเป็นอย่างไร
จึงทำการอธิบายพร้อมตัวอย่าง code และเครื่องมือ
ที่ผมมีโอกาสใช้งานในงานมาบ้าง
เลยทำการสรุปและบันทึกแนวทางไว้นิดหน่อย

ในการแลกเปลี่ยนข้อมูลระหว่าง service นั้นมีหลายรูปแบบ เช่น

• การเรียกหรือส่งข้อมูลแบบตรง ๆ จาก service ไปเลย บ่อยครั้งมีรูปแบบเป็น synchronous ต้องระวังเรื่องของ cascade failure ไว้ด้วย
• เป็น Event-based ในรูปแบบของ one-to-one หรือ one-to-many ก็ว่าไป มีรูปแบบเป็น asynchronous ต้องสร้าง code ทั้งสองฝั่งขึ้นมา เพื่อส่งและรับข้อมูล เช่น producer/consumer หรือ publisher/subscriber เป็นต้น
• Share database กันไปเลย หรือ replicate database ออกมา !! แต่ต้องการข้อมูลทั้งหมดนั้นจริง ๆ ไป

หรือทำการ replicate data แต่แบบเลือกได้
นั่นคือ เมื่อเกิดการเปลี่ยนแปลงใน data ที่เราสนใจใน database (Event/Change logs)
จะทำการจับการเปลี่ยนแปลง ทำการ transform ข้อมูลให้อยู๋ในรูปแบบที่ต้องการ
จากนั้นก็ทำการส่ง หรือ บันทึกไว้อีกที่ที่ต้องการใช้งาน
โดยไม่ต้องไปทำในฝั่งของ app/service
และทำงานร่วมกับ Event-based ก็เป็นอีกทางเลือกหนึ่ง
ซึ่งจะเรียกวิธีการนี้ว่า Change Data Capture (CDC)

โดยเครื่องมือที่ใช้งานเช่น Debezium

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

การทำงานนั้น Debezium จะทำการอ่าน event หรือการเปลี่ยนแปลงใน database แต่ละชนิด
เช่น

• MySQL จะทำการอ่านจาก binlog
• Postgresql จะทำการอ่าจาก logical replication stream

ซึ่งจะมี connector ไปยัง database อื่น ๆ ให้อีกเพียบ
จากนั้นเราสามารถ custom สิ่งที่ต้องการได้อีกด้วย
ด้วยการเขียนตัว transformer data ได้อีก หรือดักบาง event หรือบาง table ก็ได้

ยกตัวอย่างการเขียน transformer เพื่อจัดการกับ event การสร้างเท่านั้น จาก Pogresql database

จากนั้นก็อยู่ที่ว่าจะทำการ config เพื่อให้ข้อมูลที่เราดักจับนั้นไปไว้ที่ไหน
โดย Debezium นั้นสามารถส่งข้อมูลไปยัง messaging ได้ เช่น Apahe Kafka
เพื่อให้ใครก็ได้มา subscribe เพื่อนำข้อมูลต่าง ๆ เหล่านี้ไปใช้งานต่อไป
แสดงดังรูป

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

แนวคิดง่าย ๆ คือ เมื่อมีการเปลี่ยนแปลงของ database เกิดขึ้น
ใน app/service จะทำการเขียน code เพื่อบันทึกลง table หนึ่ง ๆ ไว้
จากนั้นเมื่อทำการส่งข้อมูลไปยัง messaging เรียบร้อยแล้ว
ก็จะทำการ update หรือลบข้อมูลนั้น ๆ ใน table ไป
โดย table นี้เราจะเรียกว่า outbox table

ดังนั้นถ้าเรากำหนดไว้ว่า เมื่อส่งข้อมูลเสร็จแล้ว ข้อมูลต้องโดนลบออกไปเสมอ
ถ้าทำงานได้อย่างถูกต้องใน outbox table ต้องไม่มีข้อมูลเหลือ

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

จากนั้นเราก็ทำการ config ใน Debezium ว่า
ให้สนใจเฉพาะการเปลี่ยนแปลงใน outbox table ก็พอ
ทำให้ง่าย และ สะดวกต่อการใช้งานอีกด้วย

ตัวอย่างของการ config แบบง่าย ๆ

เพียงเท่านี้ก็สามารถใช้งาน Debezium + Apache Kafka
สำหรับการแลกเปลี่ยนข้อมูลระหว่างระบบ หรือ service ได้แล้ว !!

สุดท้ายแล้ว วิธีการเหล่านี้มีความซับซ้อนสูงมาก ๆ

แต่ก็มีประโยชน์มากเช่นกัน
ดังนั้นก่อนใช้งานควรต้องรู้และเข้าใจ
ว่าทำไมเราต้องใช้งาน
มีวิธีการอื่น ๆ ไหม
ที่เหมาสมต่อปัญหา และ ทีม
รวมทั้งเรื่องของการ monitoring และ troubleshooting ต่าง ๆ ด้วย
ทุกอย่างล้วนมี tradeoff ทั้งสิ้น
ใช้อย่างมีสติ
นำมาแก้ไขปัญหา ไม่ใช่นำมาใช้เพื่อสร้างปัญหา

Reference Websites

• What is change data capture (CDC) ?
• Kafka :: What is Change Data Capture ?
• Rethink the Way You Share Data Between Microservices with Change-Data-Capture
• Reliable Microservices Data Exchange With the Outbox Pattern

ในการจัดการ Docker image นั้น เราจะจัดเก็บไว้ใน Docker registry server
ไม่ว่าจะเป็น Docker Hub หรือ ตามระบบต่าง ๆ
ทั้ง public และ private
ทั้ง on-premise และ on-cloud

แต่มันก็ก่อให้เกิดความยุ่งยากในการจัดการเช่น

• ค่าใช้จ่ายของ infrastructure และ network ต่าง ๆ ที่ใช้งาน
• การ configuration เช่น authentication และ authorization
• ทั้งเรื่องของ availability ของระบบ ล่มไม่ได้นะ เดี๋ยวกระทบต่อการทำงาน
• ต้องจัดการเรื่องการ cleanup สิ่งที่ไม่ใช้งานออกไป
• และอื่น ๆ อีกมากมาย

ดังนั้นจึงเกิด ttl.sh ออกมา

โดยมีความสามารถดังนี้

• ไม่มีการ login เพื่อใช้งาน
• ดังนั้นใคร ๆ ก็สามารถทำการ push และ pull image ได้เลย
• แต่ image ทุกตัวที่ push เข้ามา จะมีเวลา default คือ 1 ชั่วโมง หลังจากนั้นจะถูกลบออกไป รวมทั้งเราสามารถกำหนดเวลาได้เอง ด้วยการกำหนดใน tag ของ image เช่น :5m คือ 5 นาที, :100s คือ 100 วินาที
• ข้อมูล image จะถูกกั้นด้วย cloudflare ทำให้ pull ได้เร็วขึ้น

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

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

คำถาม ในการพัฒนาระบบงานด้วย Spring Boot

ถ้าเราต้องการแยกการทำงานต่าง ๆ ใน process เดียวกัน
โดยไม่ต้องการ messaging server เป็นตัวกลาง
จะต้องทำอย่างไรบ้าง

คำตอบง่าย ๆ คือ
หนึ่งในวิธีการที่ใช้งานคือ EventPublisher ใน Spring framework ได้เลย

โดยขั้นตอนการใช้งาน จะมี 3 ขั้นตอนดังนี้

ขั้นตอนที่ 1 ทำการสร้าง class EventPublisher เอาไว้ส่งหรือสร้าง event

ขั้นตอนที่ 2 ทำการส่ง message/event

ขั้นตอนที่ 3 ทำการรับ event ที่ส่งมาผ่าน EventListener

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

ทาง InfoQ ได้ปล่อย DevOps and Cloud InfoQ Trends Report – July 2
ซึ่งมีหลาย ๆ เรื่องที่น่าสนใจ
จึงทำการสรุปไว้นิดหน่อย ประกอบไปด้วยเรื่องต่าง ๆ ดังนี้

• การใช้งาน cloud นั้นเข้ามาเป็นเรื่องปกติ การ migrate ระบบงานมายัง cloud เพื่อลดงานของทีม รวมทั้งเรื่องการ scale resource ต่าง ๆ ได้ดีขึ้น
• เรื่องของ FinOps หรือการจัดการค่าใช้จ่ายต่าง ๆ บน cloud ให้มีประสิทธิภาพ เป็นสิ่งที่น่าสนใจ โดยทาง Google และ Microsoft ได้ตั้ว FinOps foundation ขึ้นมาด้วย
• ในฝั่ง DevOps มีการนำ AI และ LLMs มาใช้งานเพื่อช่วยลดงาน และ จัดการงานต่าง ๆ ให้ง่ายขึ้น โดย cloud provider ต่าง ๆ เริ่มนำมาใช้งานใน product และ service ต่าง ๆ แล้ว
• เหล่า Low code/No code ต่าง ๆ ก็ได้นำ AI และ ChatGPT มาสร้างระบบงาน ช่วยให้การทำงานระหว่าง business และ development ดีขึ้น
• เน้นเรื่อง Platform engineering มากขึ้น โดยเน้นที่ value delivery และนำแนวคิด Platform-as-a-Service มาประยุกต์ใช้งาน เพื่อลด หรือ ซ่อนความซับซ้อนของการจัดการ infrastructure เปลี่ยนมาเป็น service provider แทน ทำให้เน้นที่ความพึงพอใจของผู้ใช้งาน และ คุณค่ามากขึ้น
• มีการนำ OpenTelemetry มาเป็นมาตรฐานของข้อมูล observability ของ service เช่น metric, tracing และ log เป็นต้น ซึ่ง Cloud provider ต่าง ๆ ก็สนับสนุนแล้วเช่นกัน

เพิ่งแบ่งปันความรู้เรื่อง performance testing ไป
ซึ่งหนึ่งในเครื่องมือที่นำมาใช้งานและแนะนำคือ K6
พบว่ามีการเปลี่ยนแปลงเยอะเลย
เช่น Result output หรือผลของการทดสอบ

สามารถเก็บได้หลาย ๆ รูปแบบ ยกตัวอย่างเช่น

• ออก command line
• ออกเป็นไฟล์ เช่น CSV และ JSON
• เก็บข้อมูลแบบ realtime ไปยัง database ประเภทต่าง ๆ เช่น influxdb, prometheus, elasticsearch และ apache kafka เป็นต้น

โครงสร้างการทำงาน

และข้อมูลที่เก็บไว้ใน database ต่าง ๆ
สามารถนำมาแสดงผลในรูปแบบของ dashboard สวย ๆ ผ่าน Grafana ได้อีกด้วย
ซึ่งสนับสนุน datasource ที่เก็บใน database จากข้างต้นไว้
จากที่ลองใช้งานหลาย ๆ ตัวพบว่า
การใช้งานร่วมกับ Prometheus remote write จะง่าย และ update ที่สุด
เพราะว่าพวก dashboard มีการสร้าง และ update ให้ตลอด
แถมเป็นแบบ official ด้วย
แต่ยังอยู่ในขั้นตอนของ experiment นะครับ

ส่วนการใช้งานกับ influxdb นั้นจะมีทั้ง version 1 และ 2
พบว่า dashboard ต่าง ๆ ยังไม่สนับสนุน หรือ update ตาม

การใช้งาน K6 + Prometheus remote write ก็ไม่ยาก

ทำดังนี้

ขั้นที่ 1 ทำการ build k6 กับ xk6-output-prometheus-remote

ขั้นที่ 2 ทำการ run และส่งผลไปยัง Prometheus

ผลที่ได้

เพียงเท่านี้ก็ได้ dashboard สวย ๆ
และมีประโยชน์ต่อการทดสอบอีกด้วย

เห็นว่าเพิ่มมีการเปิดตัว NativePHP ออกมา
ซึ่งมีเป้าหมายสำหรับสร้าง native application ใน OS ต่าง ๆ
โดยเขียนด้วยภาษา PHP 8.1 และใช้งานผ่าน Laravel framework 10+ นั่นเอง
และใช้ web technology ต่าง ๆ เช่น HTML, CSSS และ JavaScript ได้
ชาว PHP น่าจะได้รับผลประโยชน์ไปเต็ม ๆ
ยังอยู๋ในสถานะ alpha เท่านั้น !!

เมื่อไปดูเครื่องมือต่าง ๆ ของ NativePHP นั้น
จะประกอบไปด้วย

• การ build และ bundle app นั้นจะใช้งาน Electron หรือ Tauri
• สำหรับการ build static binary จะใช้งาน Static php cli

ความสามารถต่าง ๆ ที่ NativePHP เตรียมไว้ให้

เพื่อช่วยให้ง่ายต่อการพัฒนาระบบงาน
ประกอบไปด้วย

• Window management
• Menu management
• File management
• Database คือ SQLite และ migration process
• Native notification
• Clipboard

เริ่มต้นการใช้งานได้จากที่นี่ Getting start with NativePHP

มีคนแนะนำ Hono มาให้ลองใช้งาน
เป็น web framework ที่เล็ก และ เร็วมาก ๆ
รวมทั้งยังทำงานร่วมกับ JavaScript runtime ต่าง ๆ ได้อีกด้วย
และมี middleware ต่าง ๆ ให้ใช้งานกัน
ดังนั้นมาลองใช้งานกันหน่อยว่าเป็นอย่างไร ?

ขั้นตอนที่ 1 ทำการสร้าง project

สามารถเลือกได้ว่าจะใช้ template หรือ ทำงานร่วมกันอะไร
เช่น aws lambda, cloudflare, bun, nodejs และ deno เป็นต้น

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

ขั้นตอนที่ 2 ลองสร้าง router ได้ดังนี้

โดยจะทำการสร้างด้วย RegExpRouter ซึ่งเป็น library ที่ทำงานเร็วมาก ๆ

ยิ่งไป run บน Bun ก็ยิ่งแรงส์

เป็นอีก framework ที่น่าสนใจ

เพิ่งเห็นว่าตั้งแต่ Visual Studio 2022 เป็นต้นมานั้น
สนับสนุนไฟล์ .http แล้ว นั่นก็คือ REST Client Extension เหมือนใน VS Code นั่นเอง
ช่วยทำให้เราสามารถทดสอบ REST API ใน Visual Studio ได้เลย
ไม่ต้องไปใช้ external tool เช่น Postman, Swagger และ insomnia อีกแล้ว
แต่ยังเป็น preview feature นะ
ดังนั้นมาดูคร่าว ๆ กันหน่อยว่าเป็นอย่างไร

ใน Visual Studio นั้น เตรียม UI ไว้ให้ใช้งานดังนี้

• สร้าง และ แก้ไขไฟล์นามสกุล http
• ทำการส่ง request ตามที่กำหนดไว้
• ทำการแสดงผล response ที่ได้กลับมา

ช่วยให้เราสามารถทดสอบ API ต่าง ๆ ไปพร้อมกับการ coding ได้เลย
รวมทั้งจัดการ version ได้ง่าย ๆ อีกด้วย

แสดงดังรูป

แสดงผลการส่ง request ไปยัง url ที่กำหนดไว้ในไฟล์ http

แต่ยังไม่เห็นว่ามีการเขียน test case เพื่อตรวจสอบผลการทำงาน
ว่า response ที่ได้กลับมานั้น
ตรงตามที่เราคาดหวังไว้หรือไม่
ซึ่งต้องรอดูว่า ตัวเต็ม ๆ จะมีหรือไม่
จะไม่มีจะเสียดายของมาก ๆ เพราะว่า มันเกือบจะครบแล้ว นั่นเอง

ตัวอย่างของ Product.http

ซึ่งมีรูปแบบคล้าย ๆ กับ markdown เลย

ลองศึกษากันเพิ่มเติมดูครับ
น่าสนใจพอสมควร .HTTP ใน Visual Studio

เห็นใน feed มีการ share เครื่องมือในการทำ Database migration ชื่อว่า Atlas
สิ่งที่น่าสนใจคือ มีรูปแบบการทำงาน 2 แบบ คือ

• Declarative
• Versioned หรือ change-based migration

ตัวอย่างการทำงานแบบ Declarative แสดงดังรูป

มีขั้นตอนดังนี้

• Schema loader
• Schema inspection
• Diffing and planning

โดย Atlas จะทำการตรวจสอบ schema ของ database
ระหว่าง schema ในการพัฒนาล่าสุด กับ schema ใน database ปลายทาง
จากนั้นจะทำการตรวจสอบการเปลี่ยนแปลงให้
และจะทำการ update ให้ตามการเปลี่ยนแปลงนั้น ๆ ให้เอง
ซึ่งถือว่าสะดวกมาก ๆ

โดยรูปแบบของ schema นั้น รองรับทั้ง SQL และ HCL (HashiCorp Configuration Language)
ซึ่ง HCL เป็นการจัดการเชิง declarative
ที่มีรูปแบบเดียวกับการจัดการ Infrastructure หรือ IaaS เช่น terraform นั่นเอง
ช่วยลด gap ตรงนี้ลงไป น่าสนใจกับแนวคิดมาก ๆ
และยังทำงานร่วมกับ Terraform ได้อีกด้วย

มาดูตัวอย่างการใช้งานแบบง่าย ๆ

มีขั้นตอนการใช้งานร่วมกับ docker ได้ดังนี้

ตัวอย่างของ HCL ที่ได้จากการ export ออกมาจาก database

จากนั้นทำการ migrate database โดย Atlas จะตรวจสอบการเปลี่ยนแปลงให้

ในตัวอย่างจะทำการเพิ่ม table ใหม่เข้ามา

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

เพิ่งเห็นว่าทาง Go นั้นได้ปล่อย gonew
ซึ่งเป็น experiment project สำหรับการสร้าง project ของภาษา Go
โดยจะทำการ copy template project มาใช้งานได้เลย
น่าจะช่วยให้การเริ่มต้นสร้าง project ง่ายขึ้น
อีกทั้งยังมีรูปแบบเดียวกันอีกด้วย
น่าจะเป็นอีกหนึ่งทางเลือกของการพัฒนา

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

เริ่มต้นด้วยการติดตั้ง gonew ก่อน

จากนั้นทำการสร้าง project จาก template ได้เลย

โดยในเอกสารจะมี template ให้ใช้ 2 ตัวคือ

• hello
• helloserver

การสร้าง project จาก template ผ่าน gonew ทำดังนี้

ได้ code มาดังนี้

ส่วนของ template นั้นเราสามารถพัฒนาเองได้
โดยมีตัวอย่างของ template ที่สร้างขึ้นมาเรื่อย ๆ เช่น

• Google Cloud
• Service Weaver

ลองใช้งานกันดูครับ ใช้งานง่าย ๆ
หลัก ๆ มันคือการ copy นั่นเอง

Reference Websites

• gonew: templates for new modules

ทาง Postman นั้นได้ปล่อย Postbot ออกมา (Open beta version)
ซึ่งเป็น AI assistant สำหรับการช่วยเขียน test case ใน Postman (ในตอนนี้)
และต่อไปจะมีความสามารถอื่น ๆ เพื่อเข้ามา เช่น

• เขียนเอกสารของ API และ Collection
• สรุปข้อมูลจาก test report เพื่อช่วยชี้เป้าของปัญหาต่าง ๆ
• ช่วย debug การเรียก API ต่าง ๆ
• ค้นหาข้อมูลได้ง่าย และ สะดวกมากยิ่งขึ้น

โดยตอนนี้สามารถใช้งานได้เลย
ในส่วนของ Test ของ request ต่าง ๆ
ซึ่งทำการ generate test caseให้เราแบบง่าย ๆ

ในส่วนของ Collections ก็สามารถ Generate tests ได้เช่นกัน

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

จากที่เคยเขียนอธิบายเรื่อง Migrate database ด้วย Atlas
เป็นเครื่องมือที่น่าสนใจมาก ๆ
แต่ก็พบว่าใน Atlas version ใหม่ คือ v0.13.1 นั้น
สามารถทำการสร้าง ER diagram จาก GORM model (ORM for Go)
สำหรับทำเอกสารอธิบายโครงสร้างของ table ง่าย ๆ
ดังนั้นมาลองใช้งานกัน

ขั้นตอนที่ 1 ทำการติดตั้งหรือ upgrade Atlas ก่อน

ขั้นตอนที่ 2 ทำการสร้าง Go project เพื่อใช้งาน GORM ดังนี้

ทำการสร้าง data model ที่ใช้ใน GORM

ขั้นตอนที่ 3 ทำการ config Atlas สำหรับทำงานร่วมกับ GORM

จากนั้นทำการสร้างไฟล์ tools.go ขึ้นมา เพื่อเพิ่ม dependency ใน project

ทำการ download dependency

ขั้นตอนที่ 4 ทำการสร้าง config สำหรับการทำงานของ Atlas กับ Go, GORM และ Database

ด้วยการสร้างไฟล์ atlas.hcl ดังนี้

ขั้นตอนที่ 5 เมื่อทุกอย่างเรียบร้อย ก็ทำการสร้าง ER diagram

ซึ่งจะทำการสร้างในระบบ cloud ของ Atlas เลย ทั้งแบบ public หรือ private
โดยผมทำการเลือกแบบ public ดังนี้

ผลที่ได้คือ link ของ public cloud นั่นเอง
แสดงตามรูป

ซึ่งสวยงามเลย น่าสนใจมาก ๆ
มีการดูการเปลี่ยนแปลงของ database schema ให้อีก
ลองใช้งานกันดูครับ

วันนี้เข้าไป download Chrome Driver ใหม่
พบว่าตั้งแต่ Google Chrome 115 ขึ้นไปนั้น
จะให้ไป download driver จาก Chrome for Testing แล้ว

การใช้งานอื่น ๆ ยังคงเหมือนเดิม
เพื่อเติามสามารถใช้งาน Chrome for Testing ได้เลย
เป็นอีกการเปลี่ยนแปลงที่แก้ไขปัญหาในการทดสอบไปอีกขั้น

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

จากการมาลองใช้งาน Podman เล่น
พบว่ามี project ที่ชื่อว่า Podman compose
พัฒนาด้วยภาษา Python
อธิบายง่าย ๆ คือ Docker compose ที่ทำงานบน Podman นั่นเอง
ซึ่งเราสามารถนำไฟล์ docker compose มา run ได้เลย
แต่ไม่ได้ครอบคลุมทั้งหมด มีแต่พื้นฐานเท่านั้น
แต่ก็ยังเป็นเครื่องมือที่อำนวยความสะดวกอย่างหนึ่งเช่นกัน

ก่อนอื่นทำการติดตั้งและ start Podman ก่อน
จากนั้นทำการติดตั้ง Podman compose
โดยติดตั้งผ่าน PIP ดังนี้

จากนั้นทำการเขียนไฟล์ YAML สำหรับอธิบาย service
สามารถใช้ชื่อว่า docker-compose.yml ได้เลย
หรือชื่ออื่น ๆ ก็ได้ ยกตัวอย่างเช่น

• ทำการ start container ของ NGINX

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

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

ปล. Podman แนะนำให้ใช้ manefest file ของ K8s จะดีกว่านะ

จากที่ Postman เปิดให้ลงชื่อใช้งาน performace testing ไปนั้น
ตอนนี้เปิดเป็น public แล้ว
ส่งผลให้ผู้ใช้ทั่วไปสามารถใช้งาน feature นี้ได้แล้ว
ดังนั้นมาดูรายละเอียดกันหน่อย

ปล. ใช้ได้กับ Postman deskktop app เท่านั้น

โดยพื้นฐานนั้น API performance testing นั้น

จะช่วยตอบคำถามต่าง ๆ เหล่านี้

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

ความสามารถนี้ถูกเพิ่มเข้ามาใน Postman collection
สามารถกำหนดค่าต่าง ๆ ได้ เช่น

• Virtual user หรือจำนวนผู้ใช้งาน ที่ใช้งานระบบพร้อม ๆ กัน
• Test duration คือ เวลาที่ใช้ทำการทดสอบ
• Load profile คือ รูปแบบของการ load ว่าเป็นอย่างไร ซึ่งกำหนดได้ 2 แบบคือ fixed และ ramp up

ใน free plan นั้น สามารถกำหนดได้ถึง 100 virtual user
และ run ได้ 25 ครั้งใน 1 เดือน

ผลการทดสอบ API performance testing จะมีค่าต่าง ๆ ดังนี้

• Average response time คือ เวลาเฉลี่ยของ response time ของทุก ๆ request ยิ่งค่ามากยิ่งไม่ดี
• Request per second หรือ throughput คือ จำนวน request หรือ งานที่ทำงานสำเสร็จ หรือ งานที่ทำงานต่อวินาที ถ้ามีจำนวนที่สูงแสดงว่า API ของเราทำงานได้ดี
• Error rate คือ จำนวน error ที่ตรวจสอบจาก HTTP response code ที่ไม่ใช่ 2xx นั่นเอง ถ้ามี error เกิดขึ้นควรหยุดทดสอบ หรือ ปรับปรุง API ให้ดีขึ้น

Reference Websites

• Documentation
• ลองไปดู price plan กันเพิ่มได้

ทาง Stack Overflow นั้น ได้ออกมาเปิดเผยข้อมูลการใช้งาน
โดยบอกว่าเป็นข้อมูลที่ถูกต้องกว่าที่มาจาก
บทความเรื่อง The Fall of Stack Overflow
ที่เป็นข้อมูลที่ไม่ถูกต้องมากนัก
เนื่องจากข้อมูลต่าง ๆ จะลดลง แต่ไม่ได้เยอะเหมือนในบทความข้างต้น

โดยข้อมูลที่ตกลงเป็นสิ่งที่ทาง Stack Overflow เห็นแนวโน้มเช่นกัน
ซึ่งมีผลมาจากหลายส่วนทั้ง การใช้งาน
และการเปลี่ยนแปลงนโยบายของการเก็บข้อมูลการใช้งาน
ตาม privacy ของผู้ใช้งาน จาก Google Analytic 4

ข้อมูลจากทาง Stack Overflow อธิบายว่า
การใช้งานลดลงจริง แต่ไม่มาก ซึ่งลดลงประมาณ 5% เท่านั้น เมื่อเทียบกับปี 2022
โดยยังมีการใช้งานตามสถานการณ์ที่เกิดขึ้น เช่น

• ช่วยทำการ Work from home หรือ remote เยอะ ๆ การถามเรื่อง cloud และ security จะเยอะ
• ในช่วงเดือนเมษายน ที่ ChatGPT ออกมา การใช้งานจะลดลงไป 14%

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

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