มีคำถามในกลุ่มการใช้งาน Robot framework และ SeleniumLibrary
สำหรับการทดสอบระบบ web application ผ่าน Google Chrome ว่า

จะทำการปิด notification เช่น

• Push notification
• Notification เพื่อขอใช้งาน media device ต่าง ๆ

สามารถทำได้อย่างไรบ้าง ?

เริ่มจากเรื่องของ Notification

ตัวอย่างที่มักจะเจอแสดงดังรูป

ถ้าต้องการปิด notification ตัวนี้ใน Google Chrome
สามารถเขียนผ่าน Chrome Driver Options ดังนี้

อีกเรื่องของ Disable พวก Media devices ต่าง ๆ เช่น Camera และ Microphone เป็นต้น

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

จากบทความเรื่อง The SPACE of Developer Productivity
โดยอธิบายถึง Productivity ของนักพัฒนา และ ทีม
ซึ่งมีความซับซ้อนอย่างมาก
การจับวัดเพียงมุมใดมุมหนึ่ง คงไม่ใช่เรื่องที่ถูกต้อง
ดังนั้นจึงแนะนำแนวทางไว้ดังนี้

ก่อนอื่นต้องทำให้ชัดเจนก่อนว่า คืออะไร
มีการวัดอย่างไร
ทั้งบริษัท ทีม manager และ ตัวบุคคล
ซึ่งล้วนส่งผลต่อการส่งมอบ software
ด้านคุณภาพ และ ประสิทธิภาพ

ในการวัดผลนั้นได้นำข้อมูลในหลาย ๆ มุมมอง หรือ หลาย ๆ มิติ
โดยถูกสร้างมาเป็น framework ชื่อว่า SPACE

โดยคำว่า SPACE เป็นคำย่อ ประกอบไปด้วย

• Satisfaction and well-being
• Performance
• Activity
• Communication and Collaboration
• Efficiency and Flow

มาดูรายละเอียดคร่าว ๆ ของแต่ละเครื่อง

Satisfaction and well-being

ว่าด้วยเรื่องความพึงพอใจของนักพัฒนา
ที่มีต่องาน ต่อทีม ต่อเครื่องมือ ต่อวัฒนธรรมขององค์กร
เรื่องของสุขภาพที่ดี แข็งแรง
เรื่องของงานที่ทำว่ามี impact อย่างไร

โดยทั้งสองเรื่องมีส่วนเกี่ยวข้องกับ productivity อย่างมาก

Performance

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

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

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

Activity

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

• มุมมองของการออกแบบระบบ เช่น เอกสาร spec ต่าง ๆ
• มุมมองของการพัฒนาระบบ เช่น การ commit การเปิด PR และการทำ Code review เป็นต้น
• มุมมองเรื่องของ CI/CD เช่น จำนวนการ build, test, deploy และการใช้งาน infrastructure ต่าง ๆ
• มุมมองทางด้าน operation เช่นจำนวน incident/issue ต่าง ๆ ในแต่ละรอบการ deploy, หรือระดับความรุนแรงของปัญหาต่าง ๆ

Communication and Collaboration

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

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

การทำงานร่วมกัน แผนงานควรเป้นเป้นงานเดียวกัน
มีความโปร่งใสต่อกัน
เห็นว่า process การทำงานปัจจุบันเป็นอย่างไร

ตัวอย่างที่ใช้วัดในส่วนนี้ก็ไม่ว่ายเลย ยกตัวอย่างเช่น

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

Efficiency and Flow

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

เพราะมักพบว่า ยิ่งงานมีความซับซ้อนมากเท่าไร
สิ่งรบกวน หรือ สิ่งที่ทำให้ล่าช้า จะเยอะมาก ๆ
หรืออาจจะต้องรอยาวนานไปอีก (waste)

ดังนั้นจึงมีตัวอย่างของการวัดในส่วนนี้ ดังนี้

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

ยกตัวอย่างของ Metric

เป็นอีกหนึ่ง framework ที่น่าสนใจ
และลองนำไปประยุกต์ใช้งานกันดูครับ

หลังจากที่ Robot Framework 6.1 alpha และ beta ปล่อยมาให้ลองทดสอบ
ตอนนี้ได้ปล่อย RC 1 (Release Candidate) ออกมาแล้ว
ซึ่งใกล้ออกตัวจริง ๆ มาให้ลองแล้ว
โดยเคยเขียนอธิบายใน Alpha 1 ไปแล้ว
ว่ามีอะไรที่น่าสนใจบ้าง

มาถึง version นี้น่าจะไม่ต่างจากตัวเต็ม ๆ แล้ว
ที่จะปล่อยออกมาในวันที่ 12 มิถุนายนนี้ (ตามแผนที่วางไว้)

มาดูอีก feature ที่น่าสนใจ และยังไม่ได้อธิบายไปคือ External parser API

เป็น AP ใหม่ที่สร้างขึ้นมาเพื่อให้เราสามารถ custom ตัว parser
ของ Robot Framework script หรือเรียหว่า test data นั่นเอง
ช่วยให้เราสามารถขยายหรือเพิ่มความสามารถใหม่ ๆ เข้ามาได้เองง่ายขึ้น

หรือสามารถเขียน code เพื่อสร้าง script ขึ้นมาได้เอง
ถือว่าเป็น developer tool อีกตัวที่น่าสนใจ

การใช้งาน สามารถระบุ parser ผ่าน command line ตอน run test ได้

ส่วนการปรับปรุงเพิ่มเติม เช่น WHILE loop ไม่ต้องใส่ condition ได้แล้ว
เพียงแค่กำหนด limit หรือจำนวนรอบการทำงานลงไปได้เลย

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

สำหรับใครที่ upgrade หรือ install Robot Framework + Selenium Library
แล้วอาจจะเจอปัญหาหรือ error นี้

TypeError: WebDriver.__init__() got an unexpected keyword argument 'service_log_path'

ซึ่งมี issue ใน SeleniumLibrary #1835

ปัญหาเกิดจาก Selenium 4.10 นั่นเอง
ให้ลอง $pip list ดูก่อน

จากนั้นถ้าต้องการแก้ไขปัญหาเฉพาะหน้า ก็ให้ทำการ downgrade Selenium ลงมาที่ 3.9 ไปก่อน

วันนี้ทางทีมพัฒนา Robot Framework version 6.1 ออกมาแล้ว
โดยสามารถดู feature ที่น่าสนใจ
จาก blog ต่าง ๆ ดังนี้

• Robot Framework 6.1 rc 1
• Robot Framework 6.1 alpha 1

ความสามารถที่แนะนำให้ลองใช้คือ
การบันทึก test case ไปเป็นไฟล์ JSON
และ convert กลับคืนได้ด้วย

สามารถ download ใช้งานได้แล้ว

อีกอย่างจากปัญหาของ SeleniumLibrary
ตอนนี้มีการแก้ไขปัญหาเฉพาะหน้าสำหรับ selenium 4.10
โดยการเปลี่ยน dependency ตัวนี้มาใช้ selenium 4.8.2
สำหรับ SeleniumLibrary 6.1.0

สามารถทำได้ดังนี้

ทางทีมพัฒนา Google Chrome นั้น
ได้ปล่อย Chrome for Testing (CfT) ออกมา
มีเป้าหมายเพื่อการทดสอบ web และ automation testing โดยเฉพาะ
ไม่เหมาะสำหรับใช้งานทั่วไป

โดยทางทีมพัฒนาได้รับรู้ถึงปัญหาที่ถูกแจ้งเข้ามา
สำหรับปัญหาของการทดสอบมนกรณีต่าง ๆ
ดังนั้นจึงได้สร้าง Chrome ใน version ที่มีความสามารถดังนี้ออกมา

• ไม่ทำ auto-update ซึ่งเป็นปัญหาหลักเกี่ยวกับความน่าเชื่อถือของ test
• เป็นอิสระจาก Google Chrome แบบปกติ
• จะมี ChromeDriver และ Puppeteer มาให้ใน Chrome for Testing เลย ตรงนี้สะดวกขึ้นเยอะ
• สนับสนุนทั้ง Linux, MacOS และ Windows

Download มาใช้งานกันดีกว่า

ตรวจสอบ version ของ Chrome for Testing ได้ที่นี่

ลอง Download และเปิดมาใช้กัน

มี icon สวย ๆ ว่า Test เลย

ขอให้สนุกกับการ test ครับ !!

มีคำถามเกี่ยวกับการใช้งาน Chrome for Testing กับ Selenium
ว่าใช้งานอย่างไร ?
เนื่องจาก code หรือ test script เดิมนั้น ยังไปเปิด Google Chrome แบบปกติ

คำตอบคือ

ในการ Download นั้น จะมี ChromeDriver
ให้ตาม version ของ Chrome for Testing เลย
ดังนั้นให้ทำการ download มาด้วย
จากนั้นก็กำหนด environment ชื่อว่า PATH
ให้ชี้ไปยัง directory ที่เก็บ ChromeDriver นั่นเอง
เพียงเท่านี้ test script ของเราก็จะไปเปิดใช้งาน Chrome for Testing แล้ว

ส่วน puppeteer ก็เช่นเดียวกัน

มีโอกาสมาร่วมงาน Agile Thailand 2023
ซึ่งครั้งนี้จัดที่ True Digital Park
โดยมีทั้งหมด 6 ห้อง แบ่งเป็น 20 นาที และ 45 นาทีอย่างละครึ่ง
ในช่วงเช้ามีหัวข้อที่น่าสนใจเยอะมาก ๆ
แต่ผมก็ไม่ค่อยรู้เรื่องเท่าไร เลยจดและสรุปจากที่ฟังไว้นิดหน่อย

ปล. หลบมาสรุปนิดหน่อย แล้วค่อยไปฟังต่อ

เริ่มจากการเข้าในหลาย ๆ ห้องสลับไปมา

พบว่ามีรูปแบบที่น่าสนใจคือ

• Fast feedback
• Learn -> Do/Try -> Feedback -> Change และ repeat วนไป
• PDCA (Plan Do Check Act)

ดังนั้นการเรียนรู้ ใช้งานจริง รับฟัง feedback
เพื่อนำมาใช้ปรับปรุงอย่างต่อเนื่อง
เพื่อช่วยปรับให้เข้ากับองค์กรต่าง ๆ

ต่อมาเจอคำที่น่าสนใจอีก คือ Innovation framework

แสดงดังรูป

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

ส่วนการสร้าง persona นั้นเน้นจากการทำงานร่วมกันของทุก ๆ คนที่เกี่ยวข้อง
หรือเป็นการทำงานแบบ Cross-functional team นั่นเอง
เพื่อช่วยให้เห็นมุมมองต่าง ๆ อย่างครบถ้วน
แต่ก็ขึ้นอยู่กับบริบทขององค์กรนั้น ๆ ด้วย !!
โดย persona นี้จะช่วยนำมาสร้าง Product backlog ต่าง ๆ ออกมา
จากนั้นก็ทำการส่งมอบให้ถึงมือผู้ใช้งาน

ในการสร้าง persona นั้น มักจะมีองค์ประกอบต่าง ๆ เยอะมาก
เช่น demography, Psycho เป็นต้น
แต่สิ่งที่ต้องให้ความสนใจคือ
องค์ประกอบเหล่านั้น เราใช้เพื่ออะไร รู้แล้วได้อะไร
มันจำเป็นต่อ business นั้น ๆ หรือไม่ อย่างไร
จากนั้นทำการเก็บผลและสรุป เพื่อนำมาใช้ต่อไป
เพื่อ mapping ความต้องการกับ technology ได้อย่างเหมาะสม

แต่เพียง persona ยังไม่เพียงพอ
จำเป็นต้องมีการทำ journey ด้วย
ไม่ว่าจะเป็น user หรือ customer journey ก็ตาม
จะเรียกว่า journey นั่นเอง

ใช้งาน journey เพื่อให้เห็นตามมุมมองของผู้ใช้งาน (backbone) ว่าเป็นอย่างไร
ทั้งจาก mental/emotional model และ pain point ต่าง ๆ
เพื่อทำให้เข้าใจได้ดี และนำมาวิเคราะห์ต่อไป

Session ต่อมาก่อนออกมาสรุป คือ Real PO (Product Owner)

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

เริ่มจาก Anti-pattern ต่าง ๆ ที่มักพบเจอ
หรือรูปแบบที่ไม่ดี แต่มักได้รับความนิยม สำหรับตำแหน่ง PO

รูปแบบแรก Team Output Owner (TOO)

มีหลาย ๆ PO หรือ PO per team
พอมี PO เยอะ ก็แยก Product Backlog กันอีก
ต่างคนต่างทำ
มีการรายงาน progress ของการทำงาน
PO คือเจ้าของ product แล้วจะไป report ใคร ?
แสดงว่าต้องมีคนกลางเข้ามา ?
มีการทำงานที่ over มากไป (over-production)
ส่งผลให้ feedback ล่าช้าลงไป !!! (delay feedback)

ดูเพิ่มเติมได้ที่ How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It

ยังมีรูปแบบอื่น ๆ อีกเช่น

• Component Owner ทำให้แต่ละ component เสร็จ แต่ยังไม่ integrate กัน แสดงว่ายังไม่เสร็จ !! PO มักจะมาจาก development team
• Scribe มาจาก SA/BA มักจะทำเอกสารเยอะ ต้องทำตามที่ออกแบบไว้ มักจะพูดว่าทีมยังไม่เร็วพอ อ่านมากกว่าลงมือทำ ไม่สนใจ feedback ของทีม เพราะว่าต้องทำให้ตรงอย่างเดียว สนใจแต่ tool ทำให้ทีมสนใจหรือมีความรู็หรือเรียนรู้ business ได้น้อยลง การปรับตัวก็ยาก
• ผลแปลก ๆ ที่มักออกมาอีก เช่น ไม่ได้เป็นเจ้าของ budget ไม่สามารถตัดสินใจใด ๆ ได้ เกิด conflict ในภาพรวมขององค์กร
• มักจะมี committee เพิ่มเข้ามา แต่ไม่ได้ทำงานเป็นทีม และลงเอยด้วยการ Vote !!

ดังนั้นกลับมาที่คำว่า Real PO ?

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

• PO :: Can kill product ?
• PO :: No status/progress report ? ทำการพูดคุยเรื่อง value ของสิ่งที่ดีกว่าไหม
• PO :: Priority flow สามารถตัดสินใจ และจัด priority ต่าง ๆ เองได้
• PO :: Own the budget

กลับไปฟังต่อดีกว่า ....

วันนี้ทำการ review code ที่เขียนด้วยภาษา Go กับทีม
พบว่ามี pattern แปลก ๆ มาใน code ด้วย
อาจจะเรียกได้ว่าเป็น B.A.D code ก็ได้
ซึ่งขึ้ยอยู่กับ use case ด้วยเช่นกัน
เลยทำการสรุปไว้นิดหน่อย เพื่อใช้ในการปรับปรุงต่อไป

เรื่องแรก เจอเยอะมาก ๆ คือ การใช้งาน function init()

โดยที่ init() นั้นจะใช้สำหรับการ initial ต่าง ๆ ที่ต้องการใช้งาน
ใน package นั้น ๆ เนื่องจากจะถูกเรียกใช้งานแบบอัตโนมัติ
บ่อยครั้งพบว่า ใน init() นั้นจะมี logic ต่าง ๆ เยอะ
ส่งผลให้จากต่อการทำความเข้าใจ
เกิดความผูกมัดมากยิ่งขึ้น
ยิ่งถ้ามีการเรียกใช้ข้าม package ก็จะมีขั้นตอนการทำงานเพิ่มเข้ามา
เป็นรูปแบบการเขียน code ที่เพิ่มความซับซ้อนเข้ามา
และทำให้การทดสอบยากขึ้นอีกด้วย
ดังนั้น ถ้าต้องการใช้งานต้องคิดดี ๆ

เรื่องที่สอง เจอการใช้งาน Global variable เยอะมาก ๆ

เนื่องจาก global variable นั้น
ช่วยให้ง่ายต่อการ share ข้อมูล หรือ state ต่าง ๆ ของการทำงาน
แต่ถ้าจัดการไม่ดี อาจจะก่อให้เกิดปัญหามากขึ้นตามมา เช่น

• เกิด race condition คือการอ่านและเขียนพร้อม ๆ กัน จากหลาย ๆ process เช่น การใช้งานจาก go routine ทำให้เกิดปัญหาที่ไม่คาดฝันขึ้นมาได้ ซึ่งหาปัญหายากมาก ๆ
• ทดสอบยากขึ้น
• การแยกในระดับ module และ package หรือการ reuse จะยากมาก ๆ

ดังนั้นสิ่งที่ดีคือ ควรแยกให้ชัด ๆ ของ module และ package
เพื่อจัดการ scope ได้อย่างถูกต้องและเหมาะสม

เรื่องที่สาม มักจะไม่ใช้งาน defer และ recovery

บ่อยครั้งมักจะเจอว่า ไม่ค่อยใช้ defer ในการคืน resource ที่ขอใช้งาน
เช่นการเปิดอ่านไฟล์ หรือ เชื่อมต่อ database เป็นต้น
อักอย่างคือ ใช้ defer แต่ไม่ได้ตรวจสอบว่า resource เหล่านั้นขอใช้งานได้หรือไม่ !!

รวมทั้งไม่ได้ใช้งาน recovery สำหรับจัดการ panic() ต่าง ๆ ที่เกิดขึ้น
ในขณะ runtime ส่งผลทำให้ระบบพังง่ายมาก ๆ
ซึ่งตรงนี้ต้องระมัดระวังอย่างมาก

เรื่องที่สี่ ชอบ ignore error ต่าง ๆ ที่ส่งกลับมาจาก function ต่าง ๆ

ปกติ function ต่าง ๆ มักจะ return error กลับมา
เพื่อบอกว่า ผลการทำงานของ function นั้น ๆ มี error หรือไม่
แต่บ่อยครั้งพบว่า จะ ignore ด้วย _ ในการรับ error นั้น ๆ
ซึ่งอาจจะทำให้ระบบทำงานผิดพลาดก็ได้
ดังนั้นควรระวังให้มาก ๆ

เรื่องที่ห้า จะเจอเกือบทุกภาษาคือ nest if หรือ if ซ้อน if ซ้อน if

ตรงนี้ลดละเลิกเถอะนะ เพราะว่า อ่าน และ แก้ไขยากมาก ๆ

มีอีกอย่างคือ ใน switch case ชอบไม่ใช้ default case อีก
ตรงนี้อาจจะทำให้เกิดปัญหาที่ไม่คาดหวังเกิดขึ้นได้
ดังนั้น จำเป้นต้องเขียน code ให้ปลอดภัยกันด้วยนะ

เพิ่มอีกหน่อย คือ ไม่ยอมเขียน comment อีก
มีบางระบบจำเป็นต้องสร้าง document ขึ้นมาจาก code
เพื่อช่วยให้ทีมเข้าใจ code มากยิ่งขึ้น ว่าทำงานอะไร อย่างไร

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

ก่อนนี้เคยอธิบายเรื่อง proposal ของ Structured Logging มาแล้ว
ซึ่งตอนนี้ได้เพิ่มเข้ามาใน Go 1.21 ที่จะออกมาในเดือนสิงหาคมนี้
ดังนั้นเรามาลองใช้งานกันหน่อย ซึ่งประกอบไปด้วย package ดังนี้

• log/slog
• testing/slogtest สำหรับ validate slog handler

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

ข้อมูล log message จะอยู่ในรูปแบบของ struct Record ประกอบไปด้วย

ใช้งานแบบ Text และ JSON

สามารถจัดการข้อมูลของ log ในรูปแบบ key-value ผ่าน attribute ได้เลย
รวมทั้งยังสามารถจัดกลุ่มของ log ได้เช่น
ต้องการ log ในรูปแบบนี้

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

ตัวอย่างของ log message ที่ได้ออกมา

Reference Websites

• A consistent logging format for Go
• Go 1.21 Release Notes

มาดูความสามารถใหม่ ๆ ที่น่าสนใจใน Docker 24.0.2 กัน
ประกอบไปด้วย

• Docker init เพิ่ม template ของภาษา NodeJS และ Python เข้ามา (beta)
• Docker compose สามารถใช้ dry-run ได้เลย เพื่อทดสอบ (final release)
• Docker compose สามารถใช้งาน sync file ใน watch mode ได้

Docker init ทำการเพิ่ม NodeJS และ Python

ใช้งาน Watch command ใน Docker compose ได้เลย

สำหรับตรวจสอบการเปลี่ยนแปลงไฟล์ต่าง ๆ ใน project
จากนั้นจะทำการ sync และ reload ให้ทันที
ซึ่งเป็น experiment feature ที่น่าสนใจ

อย่าลืม Download มาใช้งานกัน

Reference Websites

• Docker Compose Experiment: Sync Files and Automatically Rebuild Services with Watch Mode
• Docker Desktop 4.19: Compose v2, the Moby project, and more

ทาง Oracle ได้ปล่อย Oracle GraalVM for JDK 17 และ 20 แบบฟรีออกมาให้ใช้งาน
โดยของเดินมันคือ Oracle GraalVM Enterprise นั่นเอง
ดังนั้นจะได้รับการ update ต่าง ๆ แบบเดียวกัน และ ฟรี
อยู่ภายใต้ licence  GraalVM Free Terms and Conditions (GFTC)
นั่นคือ ใช้ได้ฟรีทุกคน รวมทั้งการใช้งาน production ด้วย

สามารถเข้า download ผ่าน Oracle JDK ได้เลย
จะมี tab GraalVM เพิ่มเข้ามาให้เลือก

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

เจอปัญหาแปลก ๆ ในการ start web app บน MacOS Ventura
ซึ่งต้องการใช้ port 5000 แต่ก็ไม่ได้สนใจอะไร
ก็เลยเปลี่ยน port ไปก็ใช้ได้
แต่เจอบ่อย ๆ ก็งง ๆ ว่ามันมี process อะไรนะที่ใช้
ก็เลยลองไปดู ...

ขั้นตอนแรก ก็ใน MacOS ก่อนว่ามี process อะไรใช้งาน ?

เจอว่ามี process ชื่อว่า ControlCe ใช้งาน
พยายามลบตาม PID ที่ขึ้นมาทิ้งไป แต่ก็สร้างขึ้นมาใหม่ !!!

ขั้นตอนที่สอง ลองไปค้นหาดูก็ไม่เจออะไรมากนัก
โดยใน community อธิบายไม่ค่อย clear เท่าไร
แต่บอกว่าไปดู AirDrop ดู ว่าเปิดหรือปิดไหม ?
พอไปดูก็เข้าใจ ว่า Airdrop receiver มันเปิดนั่นเอง (ปกติปิดไว้ !!!)
ตายน้ำตื้นมาก ๆ !!!

ดังนั้นปิดแล้ว ก็ใช้งานได้ปกติแล้ว !!

มีโอกาสแบ่งปันประสบการณ์เรื่องของ API-First development (Design-First)
ซึ่งจะตรงข้ามกับ Code-First ที่มักจะมีขั้นตอนการทำงานดังนี้

• ทำการออกแบบ API Specfication ในรูปแบบของ spreadsheet โดยคนออกแบบเช่น SA/BA
• ทำการพัฒนาตาม API Specification โดยนักพัฒนา
• ทำการ generate API Documentation จาก code ที่เขียนโดยนักพัฒนา
• จากนั้นก็มาคิดว่าจะทดสอบอย่างไร จะทำการจำลองเพื่อทดสอบใช้งานอย่างไร

แต่แนวทางของ API-First development จะแตกต่างออกไปดังนี้

ขั้นตอนเป็นดังนี้

ขั้นตอนที่ 1 ทำการออกแบบ API Specification ในรูปแบบที่เป็นมาตรฐานกลาง

ยกตัวอย่างรูปแบบที่ใช้งาน

• Swagger หรือ OpenAPI
• Postman collection และ request
• API Blueprint

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

ขั้นตอนที่ 2 ทีมทำการ review สิ่งที่ออกแบบมาว่าเป็นอย่างไร

จากนั้นทำการคิดว่า

• จะทำการทดสอบอย่างไร (API Testing) ทั้งในแง่ของ functional และ non-functional
• คนใช้งานจะใช้งานอย่างไรในการพัฒนา เช่น ทำการ Mock/Stub API ได้ไหม อย่างไร
• ทำการ generate API Documentation อย่างไร ในรูปแบบที่ต้องการ

ทั้งสองขั้นตอนนี้ ยังไม่ได้เริ่มพัฒนา และ ทดสอบ นะ
เป็นเพียงขั้นตอนการออกแบบ เพื่อให้พร้อมต่อการพัฒนาและทดสอบต่อไป

ขั้นตอนที่ 3 ลงมือสร้างจากสิ่งที่ต้องการ จากขั้นตอนที่ 2

ยกตัวอย่างการออกแบบ API ด้วย Swagger หรือ OpenAPI
สามารถทำสิ่งต่าง ๆ ได้ดังนี้

• ใช้งาน Swagger Editor ทำการออกแบบ
• ใช้งาน Swagger Codegen สำหรับการสร้าง API Documentation, Mock/Stub API และ code ฝั่ง client
• หรือใช้งาน Redocly ในการสร้าง API Documentation
• หรือทำการ Mock/Stub API ด้วย OpenAPI Mocker

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

น่าสนใจดีกับ KIP-932: Queues for Kafka
KIP (Kafka Improvement Proposal) นี้ทำการใช้งาน queue ใน Kafka นั่นเอง
โดยปกติถ้าต้องจัดการ message ที่เข้า Topic ให้ตามรูปแบบของ Queue คือ

• FIFO (First In First Out)
• แต่ละ message ที่เข้ามาต้องทำงานเพียงครั้งเดียว

ที่สำคัญก็ยังต้อง scale ได้ง่าย

ใน Kafka นั้นมักจะทำดังนี้ ยกตัวอย่างเช่น

• ให้ topic มี partition เดียวพอ เพราะว่าถ้ามีหลาย ๆ partition จะไม่การันตีการทำงานตามลำดับข้าม partition ได้
• แต่ละ consumer ต้องกำหนด consumer group เข้ามา

ถ้าจะ scale ต้องทำอย่างไร ?

จำเป็นต้องมีหลาย ๆ partition ก็ต้องทำการเพิ่ม message key
เพื่อทำการ route message ที่มี message key เดียวกัน
ไปยัง partition เดียวกัน นั่นคือเข้าทำงานที่ consumer หรือ consumer group เดียวกัน
เพื่อการันตีว่า จะต้องทำงานเรียงลำดับกัน แซงคิวกันไม่ได้
ซึ่ง Kafka จะทำงานแบบนี้ เรียกว่า partition-based ordering

ผลที่ตามมาคือ มีบาง partition จะมี message เข้ามาเยอะเกินไป
จะเรียกว่า over-partition

ดังนั้นจึงคิดว่า น่าจะมีรูปแบบอื่นที่เหมาะสม จึงเกิดแนวคิดของ Queue for Kafka เสนอออกมา

ตอนนี้อยู่ในขั้นตอนการพูดคุยในประเด็นต่าง ๆ เท่านั้น

แนวคิดหลัก ๆ คือ การเพิ่มสิ่งที่เรียกว่า Share group เข้ามา
ให้มีทางเลือกมากขึ้นสำหรับฝั่งของ consumer ในการใช้งานรูปแบบต่าง ๆ
ฝั่ง producer สามารถส่ง message เข้ามายัง topic โดยไม่ต้องสนใจว่าจะเข้าไปยัง partition ไหน
เพราะว่าฝั่ง consumer ที่อยู่ใน share group เดียวกัน
จะมองเห็น message ในมุมมองของ Queue แบบปกติเลย
แสดงดังรูป

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

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

Reference Websites

• Queues for Kafka
• From Twitter

ทาง Go นั้นทำการปล่อย Go 1.21 RC 2 ออกมาให้ใช้งานแล้ว
จากที่เคยแนะนำไปใน blog ก่อนหน้านี้
เช่น standard package ใหม่ ๆ ดังนี้

• log/slog
• slices
• maps
• cmp

รวมทั้งมี build-in function ใหม่ ๆ มาให้อีก คือ min, max และ clear

แต่ก็มี preview feature ที่น่าสนใจ ที่จะเพิ่มเข้ามาใน Go 1.22 นั่นเอง

ซึ่งถือว่า เข้ามาเปลี่ยนตัวภาษา Go เลย
นั่นก็คือ Loop variable
เพื่อไม่ให้ทำการ share variable ข้ามรอบของ loop !!
รวมทั้ง loop กับ go routine อีก
โดยมีกรณีที่ก่อให้เกิดข้อผิดพลาดตาม Common Mistakes

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

เป็นการเขียน test เพื่อตรวจสอบค่าเป็นเลขคู่ หรือ คี่
แล้วให้ run แบบ parallel

จะพบว่า ผ่านทั้งหมด ซึ่งไม่ถูกต้อง

การแก้ไขง่าย ๆ ก็เพียงสร้างตัวแปรมารับ เพราะว่าใน IDE ก็จะแจ้งเตือนด้วยนะ !!

แต่ถ้าไม่แก้ไข code ก็ทำการเปลี่ยน experimemt feature ไปเลย คือ loopvar ดังนี้

และยังมี Profile Guided Optimization (PGO) ที่เป็น preview feature ใน Go 1.20
ตอนนี้คือตัว final แล้ว

ลอง Download มาใช้งานกันดูครับ
หรือผ่าน command line ก็ได้

ปัญหาที่เจอคือ
ต้องการให้ REST API ทำการ return ข้อมูลในรูปแบบของ JSON
โดย property ที่มี data type คือ float
ต้องการให้มีหลักหลังจุดทศนิยมตามที่เรากำหนด
จะต้องทำอย่างไร

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

• 50 => 50.00
• 50.0 => 50.00
• 50.1 => 50.10

ตัวอย่างของข้อมูลที่ return จาก REST API เป็นดังนี้

ดังนั้นจึงต้องเขียน code มาเพื่อแก้ไขปัญหานี้หน่อย

ปกติถ้าเป็น float นั้น ถ้าเรากำหนดค่า 50.10 ไป ผลที่ได้ใน JSON คือ 50.1
แน่นอนว่า ทำงานไม่เป็นไปตามที่เราต้องการ

ดังนั้นจึงทำการแก้ไขด้วยการ implement MarshalJSON() จาก interface Marshaler
สำหรับ type ต่าง ๆ นั่นเอง
เพื่อกำหนดรูปแบบของ float นั่นเอง
ยกตัวอย่างเช่น

จากนั้นก็ลองใช้งาน type Amount กันดู แบบง่าย ๆ
เพื่อจัดรูปแบบของ float ให้มี 2 ตำแหน่งหลังจุดทศนิยมเสมอ

เป็นอีกหนึ่งแนวทางง่าย ๆ ที่น่าสนใจ

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

ปัญหาที่พบเจอใน Spring Boot 3 + WEbFlux
เมื่อมีการใช้งาน WebClient เพื่อเรียกใช้งาน external API
พบว่าข้อมูลของ tracing ไม่ถูกส่งไปยัง external API
ทำให้ข้อมูลของ tracing ระบบไม่ถูกต้องตามที่คาดหวัง

ตัวอย่างของ code ที่ใช้งาน และ เกิดปัญหาข้างต้น

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

บันทึกการสอน และ แบ่งปันความรู้เรื่องของ Microservices ที่ Skooldio
ตั้งแต่การออกแบบ การพัฒนา การทดสอบ และ การ deploy
รวมไปถึงการ operate เรื่องต่าง ๆ เช่น monitoring และ observability
จำนวน 4 วัน โดยครั้งนี้เขาบอกว่าเป็นรุ่นที่ 13 แล้ว
จึงทำการสรุปการแบ่งปันไว้นิดหน่อย

เริ่มด้วย 2 วันแรก จะลงรายละเอียดของการออกแบบ

โดยเป้าหมายของ 2 วันนี้ คือ

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

ดังนั้นจึงได้เริ่มสร้างความเข้าใจในแนวคิดต่าง ๆ เข้ามา ยกตัวอย่างเช่น

• DevOps, DevSecOps
• Continuous Integration และ Continuous Deployment/Delivery
• Software architecture เช่น Monolith, Modular, Layer, Tier, SOA, Microservices และ Function-as-aService
• Containerization

โดยสิ่งที่เน้นย้ำในการแบ่งปันครั้งนี้ คือ Software Architecture
ซึ่งล้วนมี trade-off ที่เราต้องพิจารณาเสมอ
เนื่องจากไม่ได้มีเพียงข้อดีเท่านั้น
มันยังมีข้อเสียที่เราต้องรู้และเข้าใจ รวมทั้งต้องเตรียมวิธีการรับมือเสมอ
บ่อยครั้งจะพบว่า เราแก้ไขปัญหา ด้วยการเพิ่มปัญหาใหม่ ๆ !!

กลับมาที่ Microservices นั้น จะแนะนำให้มอง 4 มุมเป็นอย่างน้อยเสมอ

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

• การสร้าง service จะเพิ่มเข้าไป หรือ แยกออกมา มีเหตุผลอะไร อย่างไร
• การออกแบบ interface หรือ การเข้าถึง service นั้น ๆ เป็นอย่างไร สนใจเรื่อง compatability และ ใช้งานง่ายหรือไม่
• การทดสอบ คิดไหมว่า จะทดสอบอย่างไร
• การ operate คิดหรือไม่ว่าจะดูแล จัดการอย่างไร deploy อย่างไร monitoring/observability เป็นอย่างไร ถ้าเกิดปัญหาต่าง ๆ จะจัดการอย่างไร หรือ ระบบสามารถ react ต่อปัญหาได้หรือไม่ อย่างไร

ยิ่งทำการแยกกันออกมา มีข้อดีหรือข้อเสียมากกว่ากัน

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

• การติดต่อสื่อสาร เช่น แยกกันแล้ว แต่ต้องติดต่อสื่อสารกันเสมอ คำถามคือ แยกกันทำไม ตรงนี้ตอบได้ไหม
• การ deploy และ scale ต้องรอกันไหม ? ถ้ารอ แล้วไหนบอกว่า service ต้องเป็นอิสระแก่กัน
• การแก้ไข พบว่าเมื่อทำการเปลี่ยนแปลง ต้องไปแก้ไขหลาย ๆ ที่ หรือ หลาย service แบบนี้คือ duplication ไหมนะ น่าคิด
• เมื่อมีบาง service พัง หรือ ช้าไป แล้วก่อให้ service อื่น ๆ ที่เกี่ยวข้องมีปัญหาไปด้วย แบบนี้เป็นอิสระไหมนะ ไม่น่าใช่หรือเปล่านะ ?

ปิดท้ายด้วยแนวคิดของการออกระบบ ต้องมองให้รอบด้าน

มีหลสยมุมมอง ดังนั้นต้องการคนที่มี skill หลากหลาย
หรือเป็นการทำงานเป็นทีมนั้นเอง เช่น

• แนวทางการแยก (decomposition)
• แนวทางในการจัดเก็บข้อมูล จะรวม หรือ แยกกัน รวมกันมากไปก็ไม่ได้ แยกมากก็ไม่ได้
• พอแยกหลาย ๆ service และ data ต้องทำการนำมารวมกัน จะทำอย่างไร
• พอแยกหลาย ๆ service และ data จะจัดการเรื่องของ transaction อย่างไร
• แต่ละ service จะติดต่อสื่อสารกันอย่างไร ผูกมัดกันเกินไปไหม ? เป็นอิสระต่อกันไหม ?
• เรื่องของการทดสอบทำอย่างไร
• เรื่องของ observability ของ service และภาพรวมเป็นอย่างไร
• เมื่อเกิดปัญหาแล้ว ค่าของ MTTR (Mean-Time-to-Recovery) เป็นอย่างไร ช้า หรือ เร็ว
• การ deploy ทำอย่างไร คิดก่อนทำหรือไม่ หรือทำไปแล้วค่อยไปคิดทีหลัง ?
• สนใจ Zero downtime หรือไม่
• ระบบงาน react ต่อปัญหาอย่างไร
• ทำแต่ service ที่เป็น backend เคยสนใจฝั่ง fronend บ้างไหม ว่ามีปัญหาอะไรไหม ทำงานยากกว่าเดิมไหม

สิ่งเหล่านี้จำเป็นต้องได้รับคำตอบไหมนะ ?

ต่อมาในอีก 2 วัน ว่าด้วยเรื่องของ develop -> testing -> deploy

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

• การออกแบบ interface ของ service เช่น REST API ทำอย่างไร โดยจะแนะนำเรื่องของ Design-first ด้วยเครื่องมือต่าง ๆ เช่น Postman, Swagger/OpenAPI และ API blueprint
• การจัดการปัญหาเรื่อง service to service communication นั่นคือการใช้งาน Circuit breaker ร่วมกับระบบ alert system เพื่อทำให้เรารู้ปัญหาทันที รวมทั้งการจัดการปัญหาเฉพาะหน้า เพื่อลดปัญหาไม่ให้ขยายวงกว้าง จนไปกระทบต่อส่วนอื่น ๆ
• การใช้งาน API gateway แบบพื้นฐาน โดยครั้งนี้แนะนำ APISIX ดูบ้าง
• การจัดการ Observability ของ service ประกอบไปด้วย Application metric, Distributed tracing และ Log aggregation ด้วยภาษาโปรแกรม และ เครื่องมือต่าง ๆ ที่หลากหลาย
• การติดต่อสื่อสารระหว่าง service แบบ asynchronous ว่าเป็นอย่างไร ลงมือทำเพื่อให้เข้าใจ
• การทดสอบ service to service ทำอย่างไร โดยลงมือทำ workshop 2 รูปแบบคือ component testing และ contract testing
• การออกแบบ pipeline ของการส่งมอบ service รวมไปถึง product ว่าควรมีอะไรบ้าง เพื่อทำให้เรามั่นใจในคุณภาพ พร้อมกับความรวดเร็ว

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

ทาง Spring ได้ Spring Modulith 1.0 M1 ออกมาแล้ว
ซึ่งเป็นแนวทางของการเข้าสู่การเป็น official project ของ Spring
เนื่องจาก project นี้เริ่มจาก experimental project นั่นเอง
ซึ่งมีการเปลี่ยนแปลงหลัก ๆ ดังนี้

• เปลี่ยนชื่อ package มาเป็น org.springframework.modulith
• สนับสนุน Spring Boot 3.1 ขึ้นไป
• Endpoint ของ actuator จะเปลี่ยนเป็น application-modules
• ส่วนของ deprecated ไปก่อนนี้ จะถูกเอาออกไป เช่น JDBC configuration เป็นต้น

สามารถดูการใช้งานเพิ่มเติมมได้ที่
มาเขียน code กับ Spring Modulith กันบ้าง