จากบทความเรื่อง Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

ทำการอธิบายสำหรับการย้ายระบบที่อยู่ในรูปแบบของ distributed Microservices
มาเป็น Monolith หรือถ้าพูดให้ตรง ๆ คือ ย้ายออกจาก AWS Lambda นั่นเอง

ซึ่งผลที่ได้รับกลับมาคือ

• Scale ระบบได้สูงขึ้น
• ระบบมีความ Resilience คือ เมื่อมีปัญหาสามารถ recovery กลับมาทำงานปกติได้ดี
• ที่สำคัญลดค่าใช้จ่ายไปมากกว่า 90%

ดังนั้นมาดูกันว่าทาง Prime Video ทำอย่างไรบ้าง ซึ่งน่าสนใจมาก ๆ

โดย service ที่ทำการเปลี่ยนแปลงคือ Audio/Video Monitoring Service

ทำหน้าที่ดังนี้

• Monitor ในแต่ละ stream ที่ผู้ใช้งานดู ซึ่งทำงานแบบอัตโนมัติ สำหรับการตรวจสอบคุณภาพของ Video จากนั้นก็จะ trigger เข้าสู่กระบวนการแก้ไขต่อไป
• มีทีม Video Quality Analysis (VQA) คอยดูคุณภาพของเสียงและภาพของ Video

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

"โดยเป้าหมายหลักเพื่อลดค่าใช้จ่าย และการ scale"

มาดู Architecture และ Technology ที่ใช้กันหน่อย

หลัก ๆ จะใช้ AWS Lambda จะแยกส่วนการทำงานเป็นแต่ละ component
นั่นคือ จะมี serverless แยกกันไปเพียบ ตามที่จะแบ่งกันไป (Distributed component)
ประกอบไปด้วย component ดังนี้

• Media conversion ตรงนี้ทำงานร่วมกับ Amazon S3 ดังนั้นเมื่อมีการดูเยอะ ๆ ก็ดึงข้อมูลจาก S3 เยอะ แพงไหนนะ ?
• Defect detector เมื่อผ่านการ convert มาแล้วจะ trigger มาทำงานที่นี่ เพื่อทำการตรวจสอบคุณภาพ ก็อ่านจาก S3 อีกนั่นเอง !! ถ้าเจอปัญหาก็ trigger ไปยัง Notification เพื่อแจ้งต่อไป ส่วนปัญหาที่พบเจอเก็บใน S3 อีก bucket หนึ่ง
• Realtime Notification ใช้งาน Amazon SNS (Simple Notification Service)

และมีตัวจัดการ หรือ orchestrator คือ AWS Step Functions
ซึ่งเป็นตัวการใหญ่ของปัญหาในระบบนี้

โดย architecture นี้ถูกสร้างมาเพื่อให้เริ่มต้นพัฒนาได้ง่ายและรวดเร็ว
และในทางทฤษฎี แต่ละ component มีความเป็นอิสระแก่กัน
น่าจะทำให้การ scale ง่าย !!

แต่ในความเป็นจริงพบว่า scale ยาก
แถมค่าใช้จ่ายโดยรวมก็สูงขึ้นมาก มากจนยอมรับไม่ได้ !!

มี 2 ส่วนหลัก ๆ ที่เป็นปัญหาคอขวด และ มีค่าใช้จ่ายสูงมาก ๆ คือ

• AWS Step Functions หรือตัว orchestrate นั่นเอง เนื่องจากมี component เยอะ การใช้งานสูง ทำให้เกิด state transition เยอะ และก็คิดค่าใช้จ่ายตามจำนวน state transition ด้วย (เรื่อง cost estimation ต้องคิดไหมนะ) ใช้จนเกิน limit ของ account นั่นก็ยิ่งทำให้ค่าใช้จ่ายสูงแบบโหดร้ายอีก

• ส่วนที่สองคือ การเก็บข้อมูลเพื่ออ่านเขียน video frame หรือ รูปภาพ ใน Amazon S3 นั่นเอง เพื่อให้แต่ละ component มาใช้งาน พบว่าการใช้งาน S3 แบบ Tier 1 จาก AWS Lambda นั้นมีค่าใช้จ่ายที่สูงมาก ๆ

แสดง Architecture แรกเริ่มดังรูป

จากปัญหาข้างต้น จึงนำมาสู่ Architecture ใหม่

ที่ต้องการลดปัญหาคอขวดของการ scale และ ลดค่าใช้จ่าย
ด้วยการตัด AWS Lamba และ Amazon S3 ที่เก็บ video frame ออกไป
เรื่องจากพบว่าใน use case นี้ ระบบแบบ distributed นั้นไม่ได้ตอบโจทย์

โดยแนวทางใหม่ก็รวมแต่ละ component มาอยู่ใน process เดียวกันไปเลย
ซึ่งทำงานอยู่บน Amazon Elastic Container Service
ย้ายข้อมูล video frame ที่เก็บใน S3 มาอยู่ใน Memory แทน

ตารางเปรียบเทียบระหว่าง Container กับ Serverless

แนะนำเพิ่มเติมคือ  Amazon EC2 compute saving plans สำหรับการลดค่าใช้จ่าย

แสดง Architecture ใหม่ ดังรูป

จาก architecture ใหม่ก็ช่วยแก้ไขปัญหาที่ตั้งไว้ แต่ก็มีปัญหาใหม่ ๆ ตามมา เช่น

การ scale ของ Defect detector นั้น จะทำการ scale แบบ vertical แทน
ทำไปจนถึง limit ของ instance ที่จะมีให้
จนต้องทำการ scale ด้วยการ copy code มายัง instance ใหม่
จากนั้นก็ทำ layer กลางขึ้นมา
เพื่อกระจาย request ของผู้ใช้งานไปตาม instance ต่าง ๆ นั่นเอง
เป็น AWS Lambda นั่นเอง

สิ่งที่ได้เรียนรู้กับแนวทางนี้มีอะไรบ้าง ?

• ในแต่ละ use case มีแนวทางเหมาะสมที่แตกต่างกันไป จะเห็นได้ว่า เป็นแนวทางที่เริ่มได้ง่ายและรวดเร็ว แต่เมื่อถึงจุดหนึ่งก็จะเกิดปัญหาที่ต้องเลือกทางแก้ไข ดังนั้นระบบงานควรต้องปรับปรุงอยู่อย่างสม่ำเสมอ ไม่ควรใช้คำว่าเดี๋ยวก่อน หรือ ใช้เงินเพื่อแก้ไขปัญหาอย่างเดียว
• ในการย้ายระบบมาตัวใหม่ทำได้เร็ว เนื่องจากของเดิมทำการแบ่ง component ออกมาอย่างชัดเจน ทำให้การ reuse หรือ migrate มาระบบใหม่ง่ายและรวดเร็วขึ้น ตรงนี้น่าสนใจมาก ๆ
• ไม่ว่าจะ Microservices, Serverless นั้นมันคือ tool ที่ช่วยเหลือทางด้านการ scale แต่ใช่ว่าจะแก้ไขได้ทุก use case ดังนั้นต้องเข้าใจถึงปัญหาและความต้องการก่อนเสมอ
• สิ่งที่สำคัญคือ การปรับปรุงแต่ละครั้ง เรามีตัวชี้วัดอะไรบ้าง

Reference Websites

• Even Amazon can't make sense of serverless or microservices
• So many bad takes — What is there to learn from the Prime Video microservices to monolith story
• Lambda pinball

หลังจากที่ลงชื่อใน waiting list เพื่อเข้าใช้งาน Mojo Playground
ซึ่งเป็น Jupyter Notebook นั่นเอง
โดยทำการอธิบายตัวภาษาโปรแกรมของ Mojo
ที่ออกแบบมาให้เป็น superset ของภาษา Python
ทำให้ feature และ function ต่าง ๆ คล้ายหรือเหมือนกับ Python เลย
รวมทั้งใช้งาน library ของภาษา Python ได้อีกด้วย

หน้าจอของ Mojo Playground เป็นดังนี้

โดยแต่ละคนสามารถสร้างหรือลบไฟล์ของ code ได้เลย

เนื้อหาใน Playground ประกอบไปด้วย

• พื้นฐานของภาษา Mojo เช่น การประกาศตัวแปร, struct type
• เรื่อง Strong type checking
• สนับสนุน overload function และ method

โดยที่ใน Mojo จะมี struct แทน class ใน Python
ซึ่ง struct type จะเป็น static
นั่นหมายความว่า ไม่สามารถเพิ่ม method ในขณะ runtime ได้
เนื่องจาก Mojo เน้นเรื่องของ performance และ ความปลอดภัยเป็นหลัก

ส่วนพวก data type ต่าง ๆ จะเป็น

• Int
• Boolean
• String
• Tuple

ทาง Mojo สร้างมาเพื่อแทนการทำงานของ primitive data type ของ Python นั่นเอง
ด้วยเหตุผลเรื่อง ความง่าย เร็ว และทำงานกับ hardware ต่าง ๆ ได้ดีขึ้น

ถ้าสังเกต จะเห็นได้ว่าใช้ fn แทน def ในการประกาศ function นะ
แต่สามารถใช้ร่วมกันได้
และอีกอย่าง ถ้าลืม return ค่าจาก function จะม่ค่า default คือ None

ยังมีอีกหลายเรื่องทั้ง

• Parameterization: compile time meta-programming
• Advanced Mojo features
• ตัวอย่างการ implement ด้วยภาษา Mojo
  • Low-Level IR in Mojo
  • Matrix multiplication in Mojo
  • Fast memset in Mojo

เป็นอีกภาษาที่น่าสนใจ และ ลองเรียนรู้กันดูนะครั
ขแให้สุกกับการ coding

ปกติในการ scan docker image เพื่อหาช่องโหว่ใน image
จะใช้งานผ่าน docker scan
ให้ทำการเปลี่ยนมาใช้ docker scout แทน
ใน Docker Desktop ก็สามารถใช้ผ่าน User Interface แบบง่าย ๆ ได้เลย

ส่วนใน command line เมื่อใช้งาน docker scan จะเจอ error message แบบนี้

ในตรวจดู Docker image ก็จะเป็นแบบนี้

ถ้าใครซื้อ subscription แบบ pro/team/business น่าจะมีรายละเอียดเยอะกว่านี้

ในงาน Google I/O 2023 นั้น มีการแนะนำ Android Studio Bot ด้วย
ซึ่งอยู่ใน Developer Keynote in 5 minutes

เป็น feature ที่อยู่ในขั้นการทดลองเท่านั้น
สามารถใช้งานได้แบบฟรี ๆ แต่ต้องอยู่ใน US เท่านั้น
และใช้งานได้บน Android Studio Hedgehog (canary version)

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

• ช่วยตอบคำถามต่าง ๆ ได้
• ช่วย generate code ตามแนวปฏิบัติที่ดี
• ช่วยหา resource ต่าง ๆ ที่เกี่ยวข้อง
• ช่วยหา หรือ แนะนำปัญหา วิธีการแก้ไข จาก code และ logging

รูปตัวอย่างของการใช้งานผ่าน error ใน logcat

ถามตอบใน Android Studio กันไปเลย

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

ข้อมูลจาก Technology Radar 28 นั้น มีหลายสิ่งที่น่าสนใจ
ทั้งเรื่องลอง AI tool ที่ได้รับความนิมยมสูงมาก ๆ
นั่นคือ ChatGPT, GitHub Copilot
จึงได้เกิดแนวคิด หรือ แนวปฏิบัติ ที่นำเอาไปประยุกต์ใช้งาน
ยิ่งในวงการพัฒนา Software นั้น ยิ่งมีความสำคัญมาก ๆ
เพื่อช่วยเพิ่ม productivity ต่าง ๆ ให้สูงขึ้น

ในเรื่องของ Quality นั้นไม่ใช้ optional
แต่มันคือควร build-in เข้าไปในการทำงานเสมอ
ยกตัวอย่างเช่น Applying continuous delivery significantly reduces effort, risk and costs of iterating on our ML solutions

รวมทั้งเรื่องของ CI/CD infrastructure as a service
เริ่มเข้ามาเป็นสิ่งที่มีหลักแล้ว
เพราะว่า การ setup เองภายในองค์กร อาจจะมีขั้นตอนที่เยอะ หรือ ช้ามาก ๆ
ดังนั้นเรื่องการใช้งาน CI/CD บน Cloud หรือ Platform ข้างนอก ก็น่าใช้งาน
แต่ต้องระวังเรื่องของ Security ด้วยเช่นกัน (Zero trust security for CI/CD)

พอพูดถึงเรื่อง Cloud แล้ว
เรื่องที่ตามมาก็คือ การคำนวณค่าใช้จ่าย ที่ต้องชัดเจน
เพื่อจะได้ไม่เป็นภาระในอนาคต
ยกตัวอย่างเครื่องมือ เช่น InfraCost

ในฝั่งของ Data ก็มีชื่องแปลก ๆ ออกมา คือ Lakehouse Architecture !!

มันคือการรวมเอาความสามารถที่ดีของ Data Lake และ Data Warehouse เข้าด้วยกัน
นั่นคือเรื่องการ ระบบที่ scaleได้ง่าย และ performance ในการใช้งานนั่นเอง
ช่วยทำให้องค์กร สามารถจัดเก็บ และ วิเคราะห์ข้อมูลขนาดใหญ่
อยู่บน platform เดียวไปเลย

แต่ก็มีหลาย ๆ อย่างที่ให้หยุด หรือ ใช้อย่างระมัดระวัง

เช่น เรื่อง Lambda pinball
เป็นหนึ่งใน Serverless architecture ซึ่งเป็นวิธีการหนึ่งในการแก้ไขปัญหา
แต่พบว่าเริ่มก่อให้เกิดความซับซ้อนขึ้นมา
จากการใช้งานหรือออกแบบที่ผิดเป้าหมายของเครื่องมือ
แทนที่จะเป็นอิสระแก่กัน
กลับทำให้ผูกมัดกันมากขึ้น กลายเป็น distributed mololish แบบใหม่ขึ้นมา
เกิด boundary ของ service/component ที่ไม่ชัดเจน
หรือทำงานร่วมกันเยอะจนเกินไป
จะทดสอบกันอย่างไร
จะทำการ debug และ deploy อย่างไร
ดังนั้นควรต้องใช้งานอย่างระมัดระวัง

หรือในการวางแผนงาน ไม่ควรทำการวางแผนแบบ Full utilization

นั่นคือ ควรทำการเผื่อเวลาให้ทีมไว้ทำอย่างอื่นบ้าง
เพื่อรองรับงานที่เราไม่คาดฝัน เช่น production issue เป็นต้น
เพื่อช่วยให้เราเน้นที่คุณภาพมากขึ้น
เพื่อช่วยให้มีเวลาไปปรับปรุง หรือ แก้ไขของเดิมให้ดียิ่งขึ้น
ไม่ใช่ทำการอัดงานเข้ามามาก ๆ ในทุก ๆ รอบของการทำงาน

ทาง กกต นั้นทำการสร้างระบบ ECT Report ขึ้นมา
(ระบบรายงานผลคะแนนการเลือกตั้งอย่างไม่เป็นทางการ)
เพื่อรวบรวมคะแนนการเลือกตั้งจากทั้งประเทศ
สามารถดูผ่านทางเว็บ ectreport.com กันได้เลย มีให้ดูดังนี้

• แสดงผลการนับคะแนน
• จำนวนผู้มาใช้สิทธิ์
• ดูในแต่ละจังหวัด
• ดูผลตามพรรค

ดังนั้นสำหรับนักพัฒนา ลองมาส่องดูหน่อยว่าระบบนี้เป็นอย่างไร ?

จากที่เข้าไปดูพบว่าระบบ Single Page Application (SPA)
น่าจะพัฒนาด้วย ReactJS

พวกข้อมูลต่าง ๆ ที่แสดงในหน้า web นั้น
จะดึงข้อมูลในรูปแบบ JSON ตรง ๆ
ซึ่งวางไว้บน CDN ของ Cloudflare นั่นเอง
ทำการเก็บ cached ไว้

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

• ข้อมูลจังหวัดจำนวน 77 จังหวัด
• ข้อมูลหน่วยเลือกตั้งทั้งประเทศ จำนวน 400
• ข้อมูลพรรคการเมือง เพิ่งรู้ว่ามีถึง 70 พรรค !!
• ข้อมูลผู้ลงสมัคร 4,781 คน
• ข้อมูลคะแนนแบบแยกรายหน่วย รายพรรค

ทางหลังบ้านน่าจะค่อย ๆ generate JSON แล้ว ค่อย update cache บน Cloudflare อีกรอบ

ลองดูผล Performance ผ่าน Lighthouse นิดหน่อย

คำถาม
ถ้าเราไม่ต้องการให้ Selenium Library
ทำการ capture หน้าจอแบบอัตโนมัติ เมื่อการทดสอบเกิด failure ขึ้นมา
จะต้องทำอย่างไร ?

คำตอบ

ในการ import ตัว library เข้ามาใช้งานนั้น
เราสามารถทำการเปลี่ยน argument ต่าง ๆ ของ SeliniumLibrary ได้เลย
ซึ่งมี argument ต่าง ๆ เพียบ
แต่ถ้าเกี่ยวกับการ capture screen ประกอบไปด้วย

• run_on_failure ทำงานเมื่อเกิด failure ขึ้นมา ด้วยการใช้งาน keyword ชื่อว่า Capture Page Screenshot ที่ทำการ capture screen นั่นเอง
• screenshot_root_directory ทำการกำหนด directory สำหรับเก็บไฟล์รูปที่ทำการ capture มา โดยค่า default=None นั่นคือ ใช้ current directory ที่ run นั่นเอง

ดังนั้นถ้าเราต้องการไม่ให้ capture sceen เมื่อเกิด failure ตอนการ run test
แค่เพียงเปลี่ยนค่า run_on_failure=None เท่านั้นเอง

หลังจากที่ Angular 16 ถูกปล่อยออกมานั้น
มีความสามารถใหม่ที่ออกมาคือ Angular Signals
ซึ่งผมก็ไม่เคยใช้งาน
ดังนั้นมาลองทำความรู้จัก ด้วยการลองใช้งานกันดีกว่า
มาเริ่มกันเลย

ขั้นตอนแรกทำการ install/upgrade Angular 16 ก่อน

ขั้นตอนที่สอง ลองสร้าง project และใช้งาน Sinals กันหน่อย

App component ใช้งาน Signals

ทำการใช้งาน title ใน HTML ของ component

ขั้นตอนที่ 3 ทำการ update Signals ผ่าน method update()

ขั้นตอนที่ 4 ทำการ mutate หรือแก้ไขข้อมูลบางส่วน โดยไม่ต้องส่งหรือ update ทั้งหมด

ยกตัวอย่างเช่นเปลี่ยนข้อมูลบาง property ของ object
จะใช้ผ่าน mutate() ดังนี้

ขั้นตอนที่ 4 ทำการใช้งาน Compute() สำหรับการ update ข้อมูลของ Signals อื่น ๆ

ในกรณีที่มีการ update ค่าหนึ่ง ๆ แล้ว
ให้ทำการ update ค่าใน Signals อื่น ๆ ที่เกี่ยวข้องด้วยแบบอัตโนมัติ
โดยไม่ต้องใช้งานผ่าน update()
สามารถใช้งาน compute() ได้ดังนี้

Reference Websites

• Angular v16 is here!

ทาง OpenAI ปล่อย ChatGPT บน iOS ออกมาแล้ว
สามารถทำการ Download ได้แล้วใน Apple Store
แต่มีแต่ใน US เท่านั้นนะ
ส่วนประเทศอื่น ๆ ตอนนี้ยังไม่มี แต่น่าจะมีเพิ่มเติมในสัปดาห์ต่อ ๆ ไป

ปล. ในตอนนี้ใครไปหาใน Apple Store ก็ระวังด้วยนะครับ
เพราะว่า App spam เยอะมาก ๆ

ส่วนฝั่ง Android ก็รอไปก่อน จะมาเร็ว ๆ นี้

วันนี้ทำการแบ่งปันเรื่องการพัฒนา Microservices ด้วย Spring Boot และ GraalVM Native Support
พบว่าใน Spring Initializr นั้นเพิ่ม Spring Boot 3.1.0 มาแล้ว
เลยมาดูกัยหน่อยว่าใน minor version นี้มีอะไรที่น่าสนใจกันบ้าง ?

• การจัดการ external api/service ในขั้นตอนการพัฒนาและทดสอบ ด้วย Testcontainers และ docker compose
• ใช้ Testcontainer ในการทำ integration test ได้สะดวกขึ้น เช่นการจัดการ version ของ library และการ inject prooperty เข้าไป เป็นต้น น่าจะเป็นอีกเครื่องมือที่น่าสนใจ โดยเพิ่ม task/goal ใหม่ใน maven คือ spring-boot:test-run ส่วน gradle คือ bootTestRun
• ทำการ upgrade HttpClient จาก version 4 เป็น 5 ช่วยให้การจัดการ error ง่ายขึ้น
• ใช้งาน Mockito 5.3
• ส่วน Spring Cloud นั้นจะออกมาในวันที่ 23 พค หรือ วันนี้นั่นเอง ช้าหน่อยแต่มานะ

ดูเพิ่มเติมได้ที่ Release note

ปัญหาที่เจอ สำหรับการใช้ newman ในการทดสอบ
Postman collection ผ่าน command line
ใน posrmant request ใช้ URL คือ localhost
เมื่อ run แล้วจะเจอ error ดังนี้
"Invalid IP address: undefined"
จะแก้ไขอย่างไรดี ?

เท่าที่ดูนั้น software ที่ใช้เป็นดังนี้

• newman 5.3.2
• NodeJs 20+

จากที่ไปดูนั้นพบว่า ปัญหานี้มาจาก NodeJS 20+ นั่นเอง
ซึ่งเป็นปัญหาที่เจอใน issue
เกิดจาก net.connect ใน NodeJS นั่นเอง
ดังนั้นทำได้แค่รอไปก่อน

หรือสามารถแก้ไขได้ดังนี้

• ทำการ downgrade NodeJS เป็น version 18 ก็ใช้ได้
• หรือทำการเปลี่ยนจาก localhost มาเป็น 127.0.0.1

ช่วงกลางเดือนมีโอกาสไปแบ่งปันการพัฒนาระบบงานด้วยภาษา Go จำนวน 2 วัน
โดยเป็นการแบ่งปันแบบ onsite ครั้งแรกเลยก็ว่า
เพราะว่าก่อนหน้านี้จะเป็นแบบ online เกือบหมด

ในครั้งนี้ทำการปูพื้นฐานสุด ๆ เพื่อช่วยให้นำไปต่อยอดได้ง่าย
ซึ่งมีเนื้อหาดังนี้

เรื่องแรกคือ development process กับเครื่องมือของ Go

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

• การสร้าง project ด้วย Go module (go mod)
• การใช้งาน Go workspace สำหรับการทำงานร่วมกันหลาย ๆ module (go work)
• ในการพัฒนา ผมจะเน้นเรื่อง learn by test ดังนั้นการเขียน test ด้วย Go จึงสำคัญมาก ๆ (go test) และเรื่อง test coverage + report
• จากนั้นเรื่องของการจัดการ format ของ code การตรวจสอบ code ก็เป็นสิ่งที่น่าสนใจ และขาดไม่ได้ เช่น Static code analysis, Lint, Vet
• รวมทั้งยังมีเรื่องของ Security scanning ที่หลาย ๆ ทีมขาดไป หรือ ลืมไป เช่นการใช้งาน Go leak เป็นต้น
• ขั้นตอนการ build และ install package
• การใช้งาน Docker เข้ามาช่วยให้ส่งมอบงานได้ง่ายและสะดวกมากยิ่งขึ้น
• ขั้นตอนการทดสอบพวก API testing ทั้งจาก external tool เช่น Postman และ internal tool ผ่าน package net/http/httptest
• การจำลอง dependency รอบข้าง ที่ระบบงานต้องการใช้งาน หรือ ทำงานร่วม เช่น Database และ External API เป็นต้น

สิ่งที่ลืมไป คือ การ build binary file ตามแต่ละ OS และ CPU Architecture
เลยเพิ่มไว้หน่อย

เรื่องที่สองคือ Learn by test

ในส่วนนี้พยายามให้เริ่มการแก้ไขปัญหา จากการเขียน test
ซึ่งใน Go จะอยู่ใน package testing ประกอบไปด้วย

• Testing
• Benchmark
• Example
• Fuzzing

รวมไปถึงการจัดการ tag หรือ กลุ่มของการทดสอบ
ผ่าน //go:build tagname อีกด้วย

โดยการทดสอบจะแบ่งเป็น

• Unit testing
• Component testing
• Contract testing ด้วย Pact

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

ที่เน้นมาก ๆ คือ

• Component test จะใช้งานร่วมกับ Gock และ Test containers
• Contract test ให้เข้าใจแนวคิด ขั้นตอนของการสร้าง contract จัดเก็บ และการ vertify หรือ ตรวจสอบ contract ด้วยเครื่องมือชื่อว่า Pact + Pack broker และ Docker

เรื่องที่สามคือ Project structure

ในส่วนนี้พยายามอธิบายให้เห็นถึง
วิวัฒนาการของ project เพื่อทำให้เข้าใจมากยิ่งขึ้น
โดยเริ่มตั้งแต่ Flat structure
เริ่มมาที่ Layer structure (responsibility) ว่าเป็นมาอย่างไร มีข้อดีข้อเสียอย่างไร
ต่อไปก็แนวทางแบ่งตามกลุ่มการทำงาน เช่น domain, function, use case เป็นต้น
รวมทั้งชี้ให้เห็นแนวคิดอื่น ๆ ที่ชอบใช้งาน หรือ พูดคุยกัน
เช่น Clean architecture และ Hexagonal architecture เป็นต้น

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

เป็นสามเรื่องพื้นฐานที่จะเน้นเสมอ จากนั้นก็ลงมือทำ workshop แต่ละเรื่องไป
เพื่อทำการฝึก เรียนรู้ กันต่อไป

สำหรับใครที่ใช้งาน ChatGPT ไม่น่าจะพลาด course นี้
คือ ChatGPT Prompt Engineering for Developers
เป็น course ที่มีความยาวเพียง 1 ชั่วโมงเท่านั้น และเรียนฟรีด้วย
ดังนั้น เรียนเลย และ สรุปเรื่องที่เรียนไว้ดังนี้

โดยหัวข้อหลัก ๆ คือ

• การเรียนรู้การเขียน prompt ที่ดีสำหรับการพัฒนาระบบงาน
• การเรียนรู้ และ การใช้งาน LLMs (Large Language Model) รวมถึงการประยุกต์ใช้งานใน Chatbot
• ทำการเขียน code เพื่อใช้งานผ่าน Open API ด้วยภาษา Python ซึ่งมี Jupyter nodebook ด้วย

ในการใช้งานผ่าน Open API นั้น จะมี task ให้ทำดังนี้

• Summarize เช่น การสรุปข้อมูลออกมาแบบสั้น ๆ
• Infer เช่น เรื่องของ sentiment classification และ การ extract หัวข้อต่าง ๆ ออกมา
• Transform เช่น การแปล และ การตรวจสอบ grammar เป็นต้น
• Explain เช่น การเขียน email แบบอัตโนมัติ

ทำการอธิบายเรื่องของ Principles of Prompting

Principle ข้อที่ 1
Write clear and specific

Principle ข้อที่ 2
Give the model time to think

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

ส่วนแนวทางการสร้าง prompt ที่ดีนั้น
จะใช้แนวทางของ iterative process
เพื่อใช้ในการเรียนรู้ และ รับ feeback มาเพื่อปรับปรุง
และทำซ้ำไปเรื่อย ๆ ตรงนี้ดีมาก ๆ

ซึ่งเหมาะมาก ๆ สำหรับมือใหม่ที่ต้องการเริ่มต้นใช้งาน
ทั้งผ่าน ChatGPT บน web
และผ่าน OpenAPI APIs

หลังจากที่ Spring Boot 3.1 ปล่อยออกมานั้น
มีเรื่องที่น่าสนใจคือ การทำงานร่วมกับ Testcontainers
โดยมีความสามารถดังนี้

• แน่นอนว่า ในการทดสอบ สามารถใช้งานได้เลย
• อีกตัวที่น่าสนใจคือ สามารถ Run ใน test mode ได้ ช่วยให้นักพัฒนาง่ายขึ้น

มาดูกันว่าเป็นอย่างไร ?

ก่อนใช้งานบนเครื่องต้องมี

• Docker
• JDK 17

จากนั้นทำการสร้าง project ดังรูป

เรื่องแรกใช้ Testcontainers ใน Test case

โดยในการทดสอบนั้น สามารถทำการจำลองหรือสร้าง MongoDB
ผ่าน Testcontainers ได้เลย
จากนั้นก็ทำการ start test case กันได้เลย
ซึ่งทำงานร่วมกับ SpringBootTest ได้ปกติ
ตัวอย่าง code ดังรูป

ในการทดสอบจะทำการสร้าง container ใน Docker ขึ้นมา
เมื่อทดสอบเสร็จแล้ว จะทำการลบ container ให้อัตโนมัติ

เรื่องที่สอง ใช้ Testcontainers ในการ run test mode

ในการพัฒนาปกติ จะทำการ start project ผ่าน IDE หรือ command line ก็ได้
เช่น

ส่วนใน Spring Boot 3.1 และ Testcontainers ได้เพิ่ม task ใหม่เข้ามาคือ

แต่ใน Test นั้นจะต้องเพิ่ม class TestApplication เข้ามา
เพื่อทำการ custom Main class ของการทดสอบนั่นเอง
รวมทั้ง configuration ของ Testcontainers สำหรับ MongoDB
ยกตัวอย่างเช่น

เพียงเท่านี้ก็สามารถใช้งาน Testcontainers ใน Spring Boot 3.1 กันแบบง่าย ๆ ได้แล้ว

ใน Java 21 นั้น
มี JEP 445: Unnamed Classes and Instance Main Methods (Preview) เพิ่มเข้ามา
มีเป้าหมายเพื่อปรับปรุงการเขียน class และ main method ให้ง่ายขึ้น
ช่วยให้ง่ายต่อนักพัฒนา Java ใหม่ ๆ หรือ เป็นมิตรมากยิ่งขึ้นนั่นเอง
มาดูกันว่าเป็นอย่างไร ?

เริ่มจากการเขียน HelloWorld ปกติ

แค่จะแสดงคำว่า Hello World ต้องเขียนเยอะมาก ๆ

ดังนั้นจึงมีแนวคิดว่า ถ้าเขียนสั้น ๆ ง่าย ๆ
จะดีกว่าไหม ?
ยกตัวอย่างเช่น

หรือเขียน method แบบนี้ไปเลย
ไม่ต้องทำการเขียน class และ method main() อะไรเลย

ลองทำการ compile และ run กันหน่อย

สามารถ Download JDK 21 (Early Access Preview) มาลองเล่นได้

เพิ่งสังเกตเห็นว่า Spring Boot 3.1 ที่ออกมานั้น
สนับสนุน Docker compose แล้ว
ทำให้การ build, develop, testing, deploy กับ Docker ง่ายขึ้น
โดยทำดังนี้

ทำการเพิ่ม dependency เข้ามาใน project

โดย dependency ตัวนี้ จะทำงานดังนี้

• ทำการค้นหาไฟล์ compose.yml หรือ docker-compose.yml ใน project
• ถ้าเจอแล้ว จะทำงาน $docker compose up เพื่อสร้าง container ต่าง ๆ ขึ้นมา
• เมื่อจำการทำงานหรือ shutdown server จะทำงาน $docker compose down เพื่อลบ container ต่าง ๆ ที่สร้างขึ้นมาให้

สามารถเปลี่ยนชื่อไฟล์ docker compose ได้ด้วย

มีเรื่องของ readiness ด้วย เพื่อให้ทำการรอจนกว่า container จะพร้อม

แต่ถ้าต้องการปิดทำได้ดังนี้

ด้วยการเพิ่ม org.springframework.boot.readiness-check.tcp.disable: true

เช่น

รวมทั้งยังสามารถกำหนด timeout เพิ่มได้

เพียงเท่านี้ก็สามารถใช้งาน Docker compose ได้แบบง่าย ๆ และสะดวกขึ้น

จากการแบ่งปันเรื่อง Architecture มานิดหน่อย
หนึ่งในนั้นคือ การใช้งาน API Gateway ด้วย
ทำให้เกิดการแนะนำ Apache APISIX นิดหน่อย

ดังนั้นเพื่อช่วยทำให้เข้าใจ
ก็ลองเล่นใช้งานง่ายแบบง่าย ๆ หน่อย
มาเริ่มกันเลย

Software Requirement แบบง่าย ๆ ที่ใช้ทดลอง

• Docker
• Docker image :: APISIX

สิ่งที่ลองทำคือ

• ทำการ start ขึ้นมาใช้งาน
• ทำการ config ตัว Service และ Route ของ service ต่าง ๆ
• ทำการ config plugin ที่จะใช้งานแบบง่าย เช่น proxy-rewrite และ opentelemetry + jaeger สำหรับ distributed tracing

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

ขั้นตอนที่ 1 ทำการกำหนด service เพื่อเชื่อมต่อกับ service ต่าง ๆ

โดยใน config จะเป็นการกำหนด upstream นั่นเอง

ขั้นตอนที่ 2 ทำการสร้าง Route เพื่อเชื่อมต่อไปยัง service ในขั้นตอนที่ 1

โดยตรงนี้จะทำการ rewrite url จากการใช้ plugin ชื่อว่า proxy-rewrite

ขั้นตอนที่ 3 ทำการ config พวก Plugin ต่าง ๆ เช่น proxy-rewrite และ Opentelemetry + Jaeger

รวมทั้งการ config ต่าง ๆ จะใช้งานในรูปแบบ YAML prodiver

จากนั้นก็ทำการ start และลองใช้งานแบบง่าย ๆ แล้ว
จากนี้ก็เข้าสู่การนำไปใช้งาน

เห็นข่าวในบอกว่า Rust ถูก fork ออกมาในชื่อว่า Crablang
ซึ่งเป็น community fork ออกมา
โดยบอกว่า จะยังคงความสามารถเดิม
เพิ่มเติมคือ Now with 100% less bureaucracy!

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

น่าสนใจกับการ fork ครั้งนี้มาก ๆ
ไว้ติดตามไปเรื่อย ๆ

จากงาน Spring I/O 2023 นั้นในส่วนของ Keynote
ทำการแนะนำความสามารถใน Spring Framework 6.1
ที่จะสนับสนุนกับ Project CRaC (Coordinated Restore at Checkpoint) แล้ว
ซึ่งช่วยทำให้ startup timeเร็วขึ้นอย่างมาก
เนื่องจากมีการบันทึก state ของการทำงานไว้ก่อนจะ stop การทำงาน
จากนั้นถ้าทำการ start ขึ้นมาจะอ่านค่าจาก state ที่บันทึกไว้มานั่นเอง

มีการเปรียบเทียบให้ดูด้วย

แต่ใช้งานได้กับ JDK 17 ขึ้นไปเท่านั้นนะ

สามารถ Download มาใช้งานได้จากที่นี่

• Release page ของ CRac
• JDK ของ Azure

ใครที่ใช้งาน Robot framework สำหรับการทดสอบระบบงาน
ไม่ว่าจะเป็น Web, API หรือ Mobile ก็ตาม
เรื่องของรายงานผลการทดสอบก็สำคัญเช่นกัน
ปกติจะออกมาในรูปแบบของ XML และ HTML เท่านั้น
แต่ใน community ก็พยายามให้ผลการทดสอบอยู่ในรูปแบบอื่น ๆ ด้วย
หนึ่งรูปแบบที่น่าสนใจคือ Grafana dashboard

โดยรูปแบบนนี้มีขั้นตอนการทำงานดังนี้

• ทำการทดสอบ ซึ่งได้ผลการทดสอบในรูปแบบ XML (output.xml)
• สร้างตัว parser หรือตัวอ่านข้อมูลจาก XML มา
• ทำการบันทึกผลการทดสอบไปที่ PostgreSQL ซึ่งเป็น Relational database ด้วย TestArchiver
• ทำการติดตั้ง Grafana และทำการ config Datasource ไปยัง PostgreSQL
• ทำการสร้าง Dashboard เพื่อแสดงผลข้อมูล โดยมี Dashboard พร้อมให้แล้ว

ใครสนใจสามารถทำตามนี้ได้เลย
เป็นอีกแนวทางที่น่าสนใจ
CQE - Robot Framework Grafana Dashboard