เจอใน Tweet ใน Twitter เกี่ยวกับการตรวจสอบ array
ในภาษา PHP ว่าเป็นค่าว่างหรือไม่ ?
ซึ่งคุยกันว่า มันเขียนแบบนี้ได้ด้วยหรือ ?
เพราะว่า หลาย ๆ คนน่าจะต้องตรวจสอบผ่าน

• function empty()
• ตรวจสอบขนาดของ array ว่าเป็น 0 หรือไม่ ด้วย function count(), sizeof()

แต่พอมาเจอ code ชุดนี้ ใช้แค่นี้ก็ได้แล้ว

ซึ่งต้นทางก็ไม่รู้ว่า มันทำได้ตั้งแต่ version ไหน ?
แต่ที่ลองใช้งานคือ 7
ใครรู้ช่วยบอกที !!

แต่ก็มีคนมาบอกว่าในเอกสารของ PHP เรื่อง Boolean มีเขียนอธิบายไว้ว่า
สำหรับ array จะแปลงค่าเป็น false ให้เมื่อไม่มี element ใน array นั่นเอง

เป็นอีกความรู้ที่น่าสนใจ
เลยจดเอาไว้หน่อย
ขอให้สนุกกับการเขียน code

เพิ่งเห็นว่าทาง OWASP นั้นได้ทำ project ด้าน security ของ CI/CD ออกมา
นอกจากจะมี Web, API, Mobile และ Docker Security
เนื่องจาก CI/CD ได้รับความนิยม หรือ เรียกได้ว่าเป็นสิ่งที่ต้องทำเป็นปกติ
ทั้ง environment
ทั้ง process การทำงาน
ทั้งระบบงาน และ pipeline การทำงาน
เพื่อให้สามารถส่งมอบระบบงานได้อย่างรวดเร็ว และ มีคุณภาพ

แต่ในการสร้าง CI/CD ขึ้นมานั้น พบว่าต้องมี

• Technology stack ที่หลากหลายวิธีการ ทั้งจากภาษาโปรแกรม framework ต่าง ๆ ที่อยู่ในการสร้าง pipeline หลัง ๆ ก็มีพวก GitOps เข้ามา หรือไปในทาง container อีก ทั้ง docker และ Kubernetes เป็นต้น
• ในส่วนของ Infrastructure ก็ต้องทำ automation ผ่านพวก Infrastrure as Code (IoC) อีก
• มีการใช้งาน 3-party library/service/system เพื่อให้สามารถทำงานร่วมกับระบบอื่น ๆ ได้
• มีพวก Pipeline as Code มาอีก เขียน code อีกแล้ว

จากสิ่งต่าง ๆ เหล่านี้ทำให้สามารถทำงาน
ส่งมอบได้อย่างรวดเร็ว ยืดหยุ่น และ หลากหลาย
แต่ก็ทำให้มีจุดอ่อนทางด้าน security ซึ่งทำให้โดนโจมตีหรือบุกรุกได้ง่ายขึ้น
ยิ่งเป็นระบบ CI/CD ที่เป็นพวก public service ยิ่งมีความเสี่ยงสูง

ดังนั้นจึงทำการสรุป Top 10 ออกมาให้ ดังนี้

• CICD-SEC-1: Insufficient Flow Control Mechanisms
• CICD-SEC-2: Inadequate Identity and Access Management
• CICD-SEC-3: Dependency Chain Abuse
• CICD-SEC-4: Poisoned Pipeline Execution (PPE)
• CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
• CICD-SEC-6: Insufficient Credential Hygiene
• CICD-SEC-7: Insecure System Configuration
• CICD-SEC-8: Ungoverned Usage of 3rd Party Services
• CICD-SEC-9: Improper Artifact Integrity Validation
• CICD-SEC-10: Insufficient Logging and Visibility

CICD-SEC-1: Insufficient Flow Control Mechanisms

ว่าด้วยเรื่องของ permission ของระบบต่าง ๆ ใน pipeline ของ CI/CD
ว่ามีสิทธิ์เข้าใช้งานอย่างไรบ้าง
ทั้ง Source Control Management (SCM)
ทั้ง CI system
ทั้ง Artifact server
ทั้ง server ต่าง ๆ เป็นต้น

หรือบ่อยครั้งทำการ push code ที่มีปัญหาเข้ามา
ดังนั้นอาจจะต้องมีกระบวนการ scan code และ approval process เพิ่มเข้ามา

CICD-SEC-2: Inadequate Identity and Access Management

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

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

• Local user
• Username/Password
• LDAP
• OAuth
• SSH
• Plugins
• RBAC ที่หลากหลาย
• ใช้ user ส่วนตัว
• Shared user/account

CICD-SEC-3: Dependency Chain Abuse

ขั้นตอนการ build ใน CI/CD
จะต้องทำการ download dependency ที่ใช้งานและเกี่ยวข้อง
บ่อยครั้งมักจะไปใช้ dependency ที่อาจจะมีปัญหา
และสุ่มเสี่ยงต่อปัญหาทางด้าน security
เช่นไป download จาก remote repository เป็นต้น
ดังนั้นต้องระวังอย่างมาก

ต้องสร้าง local repository ในองค์กรขึ้นมาไหม
การตรวจสอบ checksum ของ dependency
ระบุ version ของ dependency ที่ต้องการใช้งานเสมอ
มีการ scan dependency เสมอ

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

ในการเขียน pipeline ปัจจุบันจะเป็น Pipeline as Code เป็นหลัก
ทำการเก็บไว้ใน source control เลย
ดังนั้นถ้าสามารถเข้าถึง source control server ได้แล้ว
ก็สามารถแก้ไข pipeline ให้ไป run code ที่ต้องการได้
จากนั้นก็รอดูผลงาน !!

เช่นให้ทำการอ่าน credential และส่งออกไปยังที่กำหนด แสดงดังรูป

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

ปัญหาต่อเนื่องคือ กำหนดการเข้าถึง pipeline ไม่ดี
ในแต่ละขั้นตอนควรต้องกำหนดสิทธิ์การทำงานให้ชัดเจน
ทั้งการอ่าน เขียน และ execute
ตั้งแต่

• การเข้าถึง source code
• การ build
• การ test
• การดึง secret/credential จากที่ต่าง ๆ ทั้ง local และ remote
• การสร้าง และ deploy artifact ใน environment ต่าง ๆ

CICD-SEC-6: Insufficient Credential Hygiene

ปัญหาเรื่องจัดการการเข้าถึง secret/credential ต่าง ๆ ใน pipeline ไม่ดี เช่น

• hard code ไว้ใน code
• เก็บไว้ใน version control ที่เดียวกับ code อาจจะมีในบาง branch
• ระบบการจัดการ secret/credential ที่ไม่ปลอดภัย
• มีการ print secret/credential ออกมาทาง console เลย
• ไม่ทำการ rotate ส่วนมากใช้แบบ static เป็นหลัก

CICD-SEC-7: Insecure System Configuration

ส่วนการทำงานต่าง ๆ configuration ไม่ดี
ยิ่งด้าน security ยิ่งแย่
รวมทั้งไม่ทำ hardening ของระบบต่าง ๆ อีกด้วย
ทำให้ถูกเจอะและโจมตีได้ง่ายมาก ๆ
ทั้ง OS, Network, Software เป็นต้น

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

ปัญหาในการกำหนดการเข้าถึงพวก 3-party services หรือ external service ต่าง ๆ
เนื่องจากใน pipeline มีการใช้งาน service ต่าง ๆ เหล่านี้บ่อยมาก เช่น

• GitHub/GitLab/Bitbucket
• OAuth application
• การสร้าง Access token ในการเข้าถึง
• การสร้าง SSH key ในการเข้าถึง

CICD-SEC-9: Improper Artifact Integrity Validation

ทั้ง code และ artifact ที่มีในระบบ ควรต้องทำการตรวจสอบเสมอ
เพราะว่ามีหลายคน หลายระบบที่เกี่ยวข้อง และ ทำงาน
ทั้งจากภายในและภายนอก
ดังนั้นทั้ง code และ artifact ที่มี อาจจะถูกโจมตีได้
ส่งผลให้การทำงานผิดพลาดได้
หรือหนักกว่านั้นคือ การส่งมอบระบบงานที่มีปัญหาเชิง security ออกไปยังผู้ใช้งาน
แน่นอนว่า ไม่ดีแน่นอน

ดังนั้นควรทำเรื่องของ code signing, artifact verification และ configuration drift detection เป็นต้น

CICD-SEC-10: Insufficient Logging and Visibility

ปัญหาเกิดจากการจัดเก็บ log ที่ไม่เพียงพอหรือไม่ดีของ CI/CD
ที่จะช่วย detect และ investigate ปัญหาด้าน security ได้
ต่างจาก Server, Network และ Application ที่มีครบ !!

สามารถอ่านเพิ่มเติมได้ที่
GitHub :: Top 10 CI/CD Security Risks
Other resource

จากงาน Flutter Forward นั้น มี session เกี่ยวกับ Dart 3
ว่ามี feature อะไรที่น่าสนใจบ้าง โดยหลัก ๆ ประกอบไปด้วย

• สนับสนุน Null safty เท่านั้น ดังนั้น project เก่า ๆ พังหมดแน่นอน เนื่องจากการสนับสนุนทั้งสองแบบ ทำให้เกิดความซับซ้อน และ overhead อย่างมากในการออก feature ใหม่ ๆ
• จากสถิติการใช้งานนั้น 85% เป็น Null safety ดังนั้นที่เหลือ migrate ซะ
• ความสามารถที่น่าสนใจคือ record และ pattern

สิ่งที่ผมสนใจมาก ๆ ที่สุดคือ Record

ดูล้วเหมือน tuple ใน Python เลย
หรือ multiple return ใน Go อีกต่างหาก
ช่วยทำให้สามารถ composition ข้อมูลได้ง่ายขึ้น
ยิ่งเป็น data structure แบบ local ก็ยิ่งสะดวก ไม่ต้องสร้าง type ขึ้นมา

ในตอนนี้สามารถลอง Download Dart 3 จาก Dev Channel ได้เลย

อีกอย่างใน pub.dev จะมี tag ชื่อว่า Dart 3 Ready
เพื่อบอกว่า package นั้น ๆ สนับสนุน Dart 3 แล้วนั่นเอง

Reference Websites

• https://medium.com/dartlang/dart-3-alpha-f1458fb9d232
• https://medium.com/dartlang/the-road-to-dart-3-afdd580fbefa

Postman Flow นั้นคือเครื่องมือที่ทาง Postman สร้างขึ้นมา
เพื่อช่วยให้การสร้าง API ง่ายยิ่งขึ้น
ซึ่งสามารถสร้างในรูปแบบ visual ไปเลย
ช่วยให้ง่ายต่อการสร้าง request
เชื่อมต่อการทำงานระหว่าง request
การรับส่งข้อมูลระหว่าง request

ใน Postman Flow จะมี building block ต่าง ๆ ดังนี้

• Task block ประกอบไปด้วย task ในการทำงานเช่น HTTP request เป็นต้น
• Data block จัดการข้อมูลในชนิดต่าง ๆ รวมทั้งข้อมูล JSON โดยจะทำการส่งไปยัง block ต่าง ๆ นั่นเอง
• Logic block เช่น if, switch, loop

มี workspace ตัวอย่างให้อีกด้วย

ใครสนใจลองใช้งาน ไปลงทะเบียนได้เลย Postman Flow Early Access

หนึ่งใน feature ของการจัดการ Error ใน Go 1.20 นั้น
คือการจัดการ multiple error ด้วย function Join() ใน errors package
และสามารถตรวจสอบด้วย function Is() ด้วย
น่าจะช่วยให้การจัดการ error สะดวกขึ้น
มาดูตัวอย่างการใช้งานง่าย ๆ

ในแต่ละ function การทำงานนั้น
เราสามารถตรวจสอบและเพิ่ม error ต่าง ๆ เข้าด้วยกัน
โดยใช้ function Join()
ทำให้เราเพิ่ม error เข้ามาไว้ก่อน
จากนั้นผู้ใช้งานหรือคนเรียกใช้งาน ทำการตรวจสอบ error ว่า
มี error อะไรบ้าง เพื่อทำการจัดการหรือ handle ต่อไป
ด้วย function Is() ดังตัวอย่าง

จากความสามารถ Virtual Thread ใน Java 19 นั้น
เลยลองนำมาใช้งานร่วมกัน Spring Boot 3 ที่เพิ่งปล่อยออกมา (JDK 17 ขึ้นไป)
เพื่อดูว่า performance เป็นอย่างไร

ก่อนอื่นต้องทำการเปลี่ยน thred pool ของ Tomcat embedded
มาเป็น Worker pool (Fork and Join) ด้วย Virtual thread
และเปลี่ยน JDK จาก 17 มาเป็น 19 ดังนี้

จากนั้นลองยิง load test เข้าไปพบว่า
จำนวน Thread ที่สร้างขึ้นมาของ Tomcat จะมีลักษณะเดียวกับ WebFlux เลย
นั่นคือจไมีจำนวนน้อย แต่ยังคงรับ request จำนวนเท่ากันได้เป็นปกติ
แถมยังใช้ memory น้อยกว่าอีกด้วย
การทดสอบใช้ concurrency = 200
แสดงดังรูป

จากการทดลองทั้งการต่อ database และ external API
ในรูปแบบเดิม จำนวน max thread = 200 นั้น
จะได้ concurrency ไม่เกิน 200
แต่ Virtual thread นั้นเกินไปตามจำนวน concurrency ที่กำหนด
เช่น 500 และ 1,000 เป็นต้น โดยไม่ต้องเพิ่ม max thread แต่อย่างไร

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

ระบบการทำงานที่ต้องติดต่อสื่อสารกันผ่านระบบ network
ไม่ว่าจะเป็น HTTP/HTTPs, Messaging protocol ต่าง ๆ
มีคำถามที่น่าสนใจคือ
เราจะตรวจสอบการทำงานได้อย่างไร
ว่าทำงานได้อย่างถูกต้องตามที่เราต้องการ

จากคำถามข้างต้น ก็มีวิธีการมากมาย เช่น

• Test-Driven Development
• มีการทดสอบใน Level ต่าง ๆ เช่น API testing เป็นต้น

ในการพัฒนาและทดสอบ ถ้ามี 3 service เช่น A ->B ->C

สิ่งที่อาจจะต้องทำคือ

• แต่ละ service ต้องทดสอบตัวเองก่อน หรือ เรียกว่า component testing ซึ่งจะต้องจำลอง service ที่ต้องไปเรียกเสมอ เช่น ทดสอบ A ก็ต้องจำลอง B เป็นต้น
• เมื่อแต่ละ service ทำงานได้ตามที่ต้องการ ก็ทำการทดสอบแบบ End-to-end ต่อไป

ในการทดสอบแบบ End-to-end นั้น ถ้ามีปัญหาขึ้นมา?

จะรู้ได้อย่างไรว่า มีปัญหาตรงส่วนไหนของระบบ
ต้องมานั่ง debug ไหม
ต้องมาดู log ไหม
ต้องไปดูระบบ alert ไหม
ต้องไปดู dashboard ไหม
ต้องมาดู tracing ไหม

หนึ่งในวิธีใหม่ ๆ ที่น่าสนใจคือ การใช้งาน Tracing มาช่วยทดสอบ

โดยเราต้องใส่ tracing ด้วย OpenTelemetry ใน code ก่อน
จะนั้นก็กำหนด exporter เพื่อนำข้อมูล tracing ไปเก็บ
จากนั้นสิ่งที่มีเพิ่มเติมคือ ทำการ query ข้อมูลของ traceing ที่เก็บ
มาตรวจสอบว่า ทำงานหรือมีพฤติกรรมตามที่เราสนใจหรือไม่
นั่นคือเครื่องมือที่ชื่อว่า TraceTest

โดยที่ TraceTest จะเป็นที่จัดเก็บ tracing หรือ tracing server ให้

กำหนด url ของ server ได้ใน exporter เลย
จากนั้นจะมี User Interface ให้เราดู
และมีการ query ของมูลของ tracing ผ่านภาษา TractTest Selector Language
เพื่อทำการทดสอบว่ามีข้อมูลตามที่เราสนใจหรือไม่

แน่นอนว่า เราสามารถเขียน assertion ได้เลย
ตรงนี้แจ่มมาก ๆ ทำให้เราตรวจสอบพฤติกรรมการทำงานได้ง่ายมาก ๆ

ยังไม่หมด เราสามารถ export ข้อมูลออกมาเป็นไฟล์ YAML ได้อีก

เพื่อนำมาจัดเก็บไว้ใน version control
จากนั้นก็ run file YAML ผ่าน TraceTest CLI ได้อีกด้วย
นั่นหมายความว่า เราสามารถนำไปใส่ใน pipeline ของ CI/CD ได้แบบชิว ๆ อีกด้วย

ดังนั้นจากที่ลอง review ก็คร่าว ๆ
แนวทางของ Observability-Driven Development เป็นอีกทางเลือกที่น่าสนใจ
สำหรับการทดสอบ service-to-service ของระบบงาน

Reference Websites

• TraceTest.io

จากที่เคยไปเรียน Domain Driven Design by Roofimon มาตั้งแต่ปี 2019
ซึ่งสรุปไว้ 3 part ดังนี้

• [Part 1] สรุปจากการไปเรียน Domain-Driven Design by Roofimon
• [Part 2] สรุปการเรียน Domain-Driven Design ในเรื่องของการออกแบบ
• [Part 3] ว่าด้วยเรื่องของรูปแบบความสัมพันธ์ระหว่าง Boundary context ใน DDD

โดยในครั้งนี้ก็ได้ไปเรียนอีกรอบหลังจาก COVID-19 จางไป
มีสิ่งที่น่าสนใจเพิ่มเติม และ เติมเต็มหลายอย่าง
มาดูกันว่ามีอะไรบ้าง ?

เริ่มจากกระบวนการสมัคร

เป็นการส่งใบสมัครด้วยการเขียนบทความที่เกี่ยวกับการ
พัฒนา ออกแบบ ทดสอบ software
ไปเพื่อให้ทำการเลือก เผื่อจะมีโอกาสไปเรียนบ้าง
ก็เลยเขียนและส่งบทความไป
ถ้าจำไม่ผิด ผมน่าจะส่งเรื่องของ Race condition problem ไป

มาถึงวันเรียนวันแรก

มาสายเลย !!!

เริ่มด้วยการ unlearn ของสิ่งที่รู้หรือทำมาก่อน
เพื่อให้เราสามารถเรียนรู้สิ่งใหม่ ๆ หรือ อาจจะเก่า เข้าได้ง่ายขึ้น
ลดการนำไปเปรียบเทียบกับสิ่งต่าง ๆ ที่เรารู้มา
เพราะว่า สิ่งที่เราเรียนรู้ครั้งนี้คือ DDD แบบ classical
เป็นความรู้ที่ถูกคิดและสร้างมานานแล้ว
อาจจะมีหลายอย่างที่ดู out-of-date ไป
แต่สิ่งที่เราต้องการคืออะไร ? มันคือแนวคิดและวิธีการในการ tackle หรือ เข้าใจและแก้ไขปัญหานั่นเอง

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

แต่ว่า สำหรับคนที่จะหาวิธีแก้ไขปัญหา มีความรู้อะไรบ้าง ?

มีประสบการณ์ ?
อ่านหนังสืออะไรกันบ้าง ?
เช่นเรื่อง DDD อ่านหนังสืออะไร ทำอะไร ?

โดยใน course นี้มีหนังสือแนะนำคือ Learning Domain-Driven Design

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

ที่น่าสนใจคือ ไม่ว่าจะเรื่องของ Microservices และ Security ต่าง ๆ นั้น
มักจะมีการอ้างถึงในเรื่องต่าง ๆ
ทั้ง การจัดการ Organization, Technology
และมีเรื่องของ DDD เพื่อทำความเข้าใจกับปัญหาเสมอ
ดังนั้นจึงเป็นสาเหตุว่า ทำไมเราต้องรู็และเข้าใจ DDD นั่นเอง

ในวันแรกจะชี้ให้เห็นว่า สิ่งที่เราต้องเข้าใจว่าตอนนี้เรากำลังทำอะไร
แบ่งเป็น 2 ส่วนของ

• Problem space
• Solution space

โดยเราจะเริ่มที่ Problem space หรือเข้าใจปัญหาก่อนนั่นเอง
ถ้าใน DDD มันก็คือ Strategic design
ส่วน Solution space คือ Tactical design นั่นเอง
เห็นไหมว่า มันคือเรื่องเดียว
ต่างแค่ชื่อเรียกและวิธีการเท่านั้นเอง

ดังนั้นจึงเริ่มด้วยการทำความเข้าใจปัญหา

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

• การจดสรุป เช่น minute meeting
• การเขียน diagram ต่าง ๆ ทั้ง UML, ER เป็นต้น
• การเขียนเป็น flow/journey ต่าง ๆ
• การเขียนใน digital tool ต่าง ๆ
• ดารเขียนเอกสาร

ในแต่ละปัญหาควรมี modeling หลาย ๆ แบบ
เพื่อทำให้เห็นและเข้าใจถึงปัญหานั้น ๆ ในหลาย ๆ มุมมอง
พร้อมแนวทางในการแก้ไขปัญหา
เรียกว่า Model-Driven Design (MDD)

DDD จะเน้นไปที่ 3 เรื่องคือ

• Domain modeling
• Boundary context
• Ubiquitous Language (UL)

เพื่อทำให้เข้าใจ จึงลงมือทำ workshop ทั้งสองวัน มีขั้นตอนดังนี้

• ทำความเข้าใจเกี่ยวกับ flow หรือ journey ของระบบงานแบบ end-to-end เพื่อให้เห็นภาพรวมของการทำงาน
• ตรงนี้แต่ละทีมก็ต้อง modeling สิ่งที่ได้รับมา เพื่อให้เข้าใจและทำการ review ต่อไป
• ทำการแบ่งกลุ่มของขั้นตอนต่าง ๆ ใน flow ที่ทำการ modeling ขึ้นมา วิธีการแบ่งกลุ่มแบบง่าย ๆ คือ actor หรือผู้ใช้งาน และ UL ที่ใช้งานนั่นเอง
• จากนั้นทำการแยกแยะว่าส่วนงานต่าง ๆ ใน flow นั้น อะไรคือ core, generic และ supporting domain เพื่อช่วยให้เรา focus ถูกจุด โดยกลุ่มแรกคือ core domain เป็นสิ่งที่เราสนใจ แต่ต่อไปแต่ละกลุ่มอาจจะเปลี่ยนไปได้ ตาม business ที่เปลี่ยนไปนั่นเอง
• ในแต่ละ domain เราสามารถดูรูปแบบในการติดต่อสื่อสารกันได้ โดยมีหลายรูปแบบ จะเรียกว่า context mapping เช่น separate way, customer-supplier, conformist, anti-corruption layer(ACL), open-host และ publish language
• ในส่วนของ core domain เราก็มาลงรายละเอียดกัน โดยเริ่มจากการวาดรูปของ wireframe หรือหน้าจอของการทำงาน เพื่อให้ทุกคนในทีมเข้าใจได้ง่ายขึ้น
• แนะนำให้เขียนคำหรือภาษาที่ในแต่ละ core domain ใช้งานกัน หรือ UL นั่นเอง เพื่อให้ตรงกับกลุ่มคนจริง ๆ พูดง่าย ๆ คือ business language นั่นเอง เพื่อให้แต่ละฝ่ายในทีมคุยในภาษาเดียวกัน ดังนั้นในทีมควรมี Domain expert ด้วยเสมอ
• ทำการเขียน command และ event ต่าง ๆ ออกมา เพื่อให้เห็นว่า แต่หน้าหน้าจอนั้น ผู้ใช้งานทำ action อะไร และเกิดอะไรขึ้นมาบ้าง ใน core domain นั้น ๆ
• จากนั้นในแต่ละ command, event จะต้องใช้งาน model หรือข้อมูลอะไรบ้าง จากนั้นหา aggregate root ของ model ยกตัวอย่างเช่น ใบสั่งซื้อ เป็น aggregation root ประกอบไปด้วย entity ต่าง ๆ เช่น seller, buyer, product และ payment เป็นต้น โดยในแต่ละ aggregate root นั้นจะจบในตัวเอง ไม่ผูกมัดกับใคร มันคุ้น ๆ ไหม เหมือนอะไร
• ในแต่ละ aggregate root นั้นเราสามารถมองได้ทั้ง logical view หรือ physical view ได้ เช่นกัน นั่นคือ อาจจะรวมกันเป็นรูปแบบของ modular หรือ แยก service ออกจากกันก็ได้ อยู๋ที่การตัดสินใจเลือก ซึ่งมีทั้งข้อดีและข้อเสีย
• การติดต่อสื่อสารของ aggregate root ก็สามารถนำ context mapping มาใช้ได้อีกเช่นเดียวกัน
• ในแต่ละ aggregate root เราสามารถนำมาเพิ่มต่อในส่วนของ tactical design ว่าจะสร้างอย่างไร มีโครงสร้างอย่างไร เช่น MVC, Hexagonal หรือ Clean architecture รวมทั้งจะเข้าใช้งานผ่าน interface อะไร เช่น REST/gRPC หรือ Pub/Sub รวมทั้งการติดต่อไป external database และ service ต่อไป

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

ปล. ยังมีรายละเอียด และ คำถามต่าง ๆ ใน workshop ที่น่าสนใจอีกเยอะเลย

เช้านี้เพิ่มได้รับ email จาก Postman
มีการแจ้งว่า Postman กำลังพัฒนา VS Code extension ขึ้นมา
ซึ่งเป็นอีกหนึ่ง feeback จากกลุ่มผู้ใช้
ที่ใช้งาน VS Code เป็น editor ในการเขียน code จำนวนมาก
ดังนั้นน่าจะดีไม่น้อย ถ้าสามารถใช้งาน Postman ใน VS Code ได้

โดยในตอนนี้ทาง Postman ได้เปิดให้ลงทะเบียนที่นี่ (Join waiting list)

มาดูความสามารถของ extension ตัวนี้กันหน่อย

UI เหมือนกันแปะ ๆ เลย
น่าจะง่ายต่อการใช้งาน

อย่าลืมไปลงทะเบียนใช้งานกัน

บันทึกการ migrate ระบบงานที่พัฒนาด้วย Spring Boot + Spring Cloud
มายัง container-based ทั้ง Docker และ Kubernetes ไว้นิดหน่อย
เนื่องจากมีบางอย่างที่เราสามารถตัดทิ้งออกไปได้
เพราะว่ามีอยู่ใน Docker และ Kubernetes แล้ว

โดยปกติระบบงานที่พัฒนาด้วย Spring Boot + Spring Cloud

จะใช้งาน library ต่าง ๆ ดังนี้

• Service discovery และ registry จะใช้งาน Spring Cloud Netflix ชื่อว่า Eureka
• จัดการ config แบบ centralize configuration ด้วย Spring Cloud Config
• จัดการ routing ต่าง ๆ ผ่าน API gateway โดยใช้งาน Spring Cloud Gateway หรือใช้งาน Zuul
• ทำการ expose ข้อมูลต่าง ๆ ของ service รวมทั้ง health check ผ่าน Spring Actuator ทำงานรวมกับ Micrometer + Prometheus + Grafana ก็ว่ากันไป
• ทำการ tracing การทำงาน service-to-service ด้วย Spring Cloud Sleuth
• สาย logging ก็ใช้ logback แล้วเขียนลงไฟล์ หรือ เอาไปลง ELK (Elasticsearch, Logstash, Kibana) + Beats หรือพวก EFK (Elasticsearch, Fluentd, Kibana)

แต่เมื่อ migrate มายัง Docker และ Kubernetes ก็ได้ลดหลาย ๆ อย่างลงไป

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

• Service discovery และ registry ไม่ต้องใช้งาน Eureka แล้ว ไปใช้งาน service ของ Kubernetes ได้เลย หรือใช้ service ใน docker compose และยังทำหน้าที่เป็นเหลือ load balancer ให้อีกด้วย
• ใช้งาน Config Map และ Secret ใน Kubernetes แทน Spring Cloud Config หรือเปลี่ยนไปใช้ Vault ได้
• ใช้งาน Ingress ใน Kubernetes แทน Spring Cloud Gateway และ Zuul ไป
• เริ่มเอา Spring Native ซึ่งตอนนี้เปลี่ยนเป็น GraalVM Native Support มาใช้งานในการสร้าง container image ที่มีขนาดเล็ก และใช้งาน resource น้อยลง แต่แลกมาด้วย build time ที่สูงขึ้น

ลดไปหลายอย่าง แต่ก็เพิ่งสิ่งใหม่ ๆ ให้เรียนรู้เช่นกัน

ปัญหาที่เจอคือ
ชุดการทดสอบ User Interface ผ่าน Web browser ด้วย Cypress มันช้าขึ้นเรื่อย ๆ
ทำให้ได้รับ feedback ที่ช้าเกินไป
ดังนั้นมาปรับปรุงกันหน่อย

วิธีการปรับปรุงแบบง่าย ๆ ประกอบไปด้วย

• เริ่มจากการอ่าน Best practice จาก Cypress ก่อนเลย
• ควรทดสอบเป็น flow หรือ scenario ไปเลย เพราะว่าถ้าแบ่งเป็น test case เล็ก ๆ จำนวนมาก ๆ จะทำงานช้า ยิ่งในแต่ละ test case ต้องมีการ setup data/state อีก ก็ยิ่งช้า
• Validate ฝั่ง UI ไม่ต้องมาทำนะ หรือทำเท่าที่จำเป็นพอ จะทำอะไรกันเยอะแยะ !!
• ปรับจากการ setup data/state จาก beforeEach มาใช้ before จะดีกว่า แต่ต้องดู use case ด้วย
• ลด ละ เลิก การใช้งาน wait() ซะ !! เจอบ่อยมาก ๆ ทำไมชอบใช้กันนะ ?
• ค่า default ของ Cypress จะใช้งาน I/O เยอะ ทั้งการบันทึก VDO และ screenshot ต่าง ๆ ดังนั้นให้ปิดไปซะ
• ในการจัดการ test case ต่าง ๆ ควรแบ่งกลุ่มของการทดสอบด้วยพวก tag เช่นการใช้งาน Grep plugin ก็จะสะดวกมาก ๆ ทั้งการการทดสอบตาม tag ที่กำหนด หรือจะแยกทดสอบแบบ distributed test และ parallel test ก็สามารถทำได้เลย

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

เห็นว่ามี library ชื่อว่า Pythagora มันอ่านว่าอะไรนะ ?
เป็น library สำหรับการช่วยทำ integration test
สำหรับระบบงานที่พัฒนาด้วย Node.JS + express
ซึ่งมีแนวคิดดังนี้

• ทำการบันทึกชุด activity หรือการใช้งานระบบไว้ ทั้ง request และ response
• จากนั้นทำการทดสอบสิ่งที่บันทึกไว้ ซึ่งบันทึกไว้ในไฟล์ JSON
• ผลการทดสอบจะมีทั้งการทดสอบว่าผ่านหรือไม่ผ่าน รวมทั้ง code coverage ให้ด้วย

มาดูขั้นตอนการใช้งานดู

ขั้นตอนที่ 1 ใน project ก็ติดตั้ง Pythagora ไปปกติ

จากนั้นก็เพิ่ม code ของ Pythagora เข้าไป
เพื่อทำการบันทึกผลจาก activity การใช้งานระบบ

ขั้นตอนที่ 2 ทำการ start server ด้วย Pythagora ใน mode การบันทึก (capture)

โดยข้อมูลจะอยู่ใน folder ชื่อว่า pythagora_data

ขั้นตอนที่ 3 ทำการ run test จากสิ่งที่บันทึกเอาไว้ พร้อมทั้งดู code coverage ไปด้วยเลย

ปล. ตรงนี้ในเอกสารจะเขียนไม่ถูก ต้องเพิ่มนิดหน่อย

ตัวอย่างของ code coverage report ในรูปแบบ HTML

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

ทางทีมพัฒนา Go ได้ปล่อย Go Vulnerability Management ออกมาเมื่อปลายปี 2022
ซึ่งมีเป้าหมายเพื่อตรวจสอบความปลอดภัยของ code
ที่เขียนด้วยภาษา Go รวมทั้ง 3-party library ต่าง ๆ
ว่าอาจจะเสี่ยงหรือมีช่องโหว่ในการโจมตีหรือไม่
โดยได้ปล่อย CLI tool ทซึ่งเป็น opensource มาให้ใช้งาน
ชื่อว่า vulncheck

โดยเบื้องหลังการทำงานของ vulncheck นั้น
จะทำการดึงข้อมูลจาก Go Vulnerability Database มาเพื่อใช้ตรวจสอบ
ซึ่งจะถูกดูแลและจัดการข้อมูล จากทางทีมของ Go นั่นเอง
นำข้อมูลจากทั้งภายใน
ข้อมูลจาก National Vulnerability Database
ข้อมูลจาก GitHub Advisory Database
ดังนั้นน่าจะทำให้มีความน่าเชื่อมากยิ่งขึ้น
อีกทั้งยังง่ายต่อการ integrate เข้ากับขั้นตอนในการพัฒนาและส่งมอบระบบงาน
แสดงดังรูป

มาดูการใช้งานกันบ้าง

ใช้ง่ายมาก ๆ คือ

จะได้ผลลัพธ์การ scan ออกมาแบบง่าย ๆ
ลองใช้งานกันดูครับ

ปัญหาที่เจอ ในการทดสอบ component testing ด้วย Cypress
โดยสิ่งที่ใช้งานประบกอบไปด้วย

• Vite + ReactJS + TypeScript
• มีใช้งาน styled component !!

เมื่อสร้างและ run component testing จะเจอปัญหาดังรูป

การแก้ไขปัญหาเบื้อต้น จะมีใน ISSUE # 22678
มีแนวทางการแก้ไขที่แนะนำมา 2 วิธี ดังนี้

วิธีที่ 1 เพิ่มการอ่าน environment ใน cypress

ด้วยการเพิ่มในไฟล์ cypress/support/component.ts

วิธีที่ 2 ทำการเพิ่ม config ใน vite.config.ts

ทำการติดตั้ง dependency ชื่อว่า vite-define-envs-plugin
และเพิ่มการอ่าน environment ได้เลย ดังนี้

เพียงเท่านี้ก็แก้ไขได้แบบอ้อม ๆ
หวังว่าทางต้นทางจะแก้ไขให้นะ

ใน Node 19.7.0 ที่ออกมาเป็น current version ของ NodeJS นั้น
มีความสามารถที่ยังอยู่ในขั้นทดลองที่น่าสนใจคือ
Single executable app นั่นคือ
เราสามารถสร้าง single binary ของระบบที่พัฒนาได้เลย
ทำให้ต่อไปในการ deploy ไม่ต้องติดตั้ง NodeJS อีกแล้ว
เป็นอีกหนึ่งความสามารถที่น่าสนใจ
มาลองใช้งานกันดูหน่อย

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

ขั้นตอนที่ 1 สร้างระบบงานปกติ

โดยในตอนนี้ยังสนับสนุนเพียง CommonJS module เท่านั้น
ดังนั้นจึงเขียนได้แบบใช้ buildin ทั่วไป

ขั้นตอนที่ 2 ทำการ copy ตัว run ของ NodeJS เข้ามา

ขั้นตอนที่ 3 ทำการ build binary ออกมา ซึ่งแบ่งเป็น MacOS และ อื่น ๆ

ในการสร้าง single binary นั้น
จะทำการ inject พวกไฟล์และ dependency ต่าง ๆ เข้าไป
ด้วยเครื่องมือชื่อว่า postject

Feature นี้ไม่ใช่แนวคิดใหม่อะไร
เนื่องจากมีวิธีการอื่น ๆ ก่อนหน้านี้อยู่แล้ว
ยกตัวอย่างเช่น

• Pkg จาก Vercel
• Boxednode จาก MongoDB
• Nexe
• Node-sea
• NectarJS

อ่านรายละเอียดเพิ่มเติมได้ที่

Initiative: Single Executable Application #43432

ความสามารถนี้ถูกปล่อยออกมาตั้งแต่ .NET 7
ทำให้สามารถ deploy ระบบที่พัฒนาโดยไม่ต้องมี .NET Runtime ใด ๆ
โดยทำการ compile ไปเป็น native codeให้เลย
หรือเรียกว่า Self-contained app
ผลที่ตามมาคือ

• Startup time เร็วขึ้น
• ใช้ memory น้อยลง

ดังนั้นเหมาะมากต่อระบบที่ต้องการรับ load เยอะ ๆ
เพื่อให้ scale ได้ง่าย ด้วย resource ที่ใช้น้อยลงอีก
รวมทั้ง environment ที่มี resource จำกัดหรือน้อย เช่นพวก Serverless เป็นต้น
แต่ก็ยังมีข้อจำกัดในเรื่องของ library/dependency ที่ใช้งานได้อยู่

ใน .NET 8 preview 1 ที่เพิ่มปล่อยออกมาให้ทดลองใช้งานนั้น
ก็ได้ทำการปรับปรุงการ build
ทำให้ขนาดของไฟล์ที่ได้นั้น มีขนาดเล็กลงไปอีก

ข้อจำกัดของ native AOT มีคร่าว ๆ ดังนี้

• ตอนนี้ใช้ได้กับ console app เท่านั้น ดังนั้นพวก web, api ยังไม่ได้นะ รอไปก่อน
• ไม่ support เรื่องต่าง ๆ เช่น dynamic loading, c++, runtime code generation

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

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

ขั้นตอนที่ 2 ทำการเพิ่ม config ใน profile file เพื่อทำการ publish แบบ AOT

ขั้นตอนที่ 3 ทำการ build และ publish ได้เลย ขนาดของไฟล์ที่ได้จากตัวอย่างนี้ คือ 8.3 MB

เพียงเท่านี้ก็ทำการ publish .NET project แบบ AOT ได้แล้ว

Reference Websites

• AoT in serverless .NET

อ่านบทความเรื่อง Partially-Implemented Interfaces in Go
เลยเพิ่งรู้ว่า เราสามารถ implement function บางตัวใน interface ได้
ไม่จำเป็นต้น implement ให้ครบทุก ๆ function
เป็นอีกความรู้หนึ่งที่น่าสนใจ
เนื่องจากมีปัญหานี้ตอนทำการ mock หรือ test double บ่อย ๆ

โดยวิธีการง่ายดี คือ การใช้งาน embedded interface นั่นเอง
แสดงว่า ผมอ่านเอกสารไม่ดีเอง หรือ ใช้งานไม่เป็นเอง 555
ตัวอย่างการใช้งานเป็นดังนี้

เริ่มเขียน code แบบที่ไม่รู้เรื่องนี้

หลังจากที่รู้ จะเขียนได้ดังนี้

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

Reference Websites

• Embedding Interfaces in Go

วันหยุดอ่านบทความเรื่อง Go back to coding, engineering leader
แนะนำว่า สำหรับ technical/engineering leader นั้น
ควรต้องกลับมาให้ความสำคัญต่อการเขียน code กับทีมด้วย
เป็นเรื่องที่ต้องให้ความสำคัญและสร้างสมดุล
เพื่อช่วยทำให้เข้าใจทีมมากยิ่งขึ้น
โดยในบทความ มีคำแนะนำที่น่าสนใจดังนี้

ขั้นตอนที่ 1 ทำการ run code ของ project บนเครื่องให้ได้

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

ยิ่งมีคนเข้ามาใหม่ จะได้รู็ว่าควรต้องเตรียมอะไร อย่างไรอีกด้วย

ขั้นตอนที่ 2 เข้ามา contribute หรือมีส่วนร่วมกับทีมบ้าง

ไม่ว่าจะเป็นเรื่องเล็ก ๆ น้อย ๆ
ไม่ว่าจะเป็นการแก้ไข bug ต่าง ๆ
เพื่อเป็นการแสดงให้ทีมเห็นว่า ต้องทำอย่างไรบ้าง
ลงมือทำให้ดู มากกว่าแค่พูดหรือบอกกล่าว (Lead by Example)

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

ทำการ paring ก็สนุกนะ เปลี่ยนบรรยากาศในการทำงาน
ได้เรียนรู้ซึ่งกันและกัน

ขั้นตอนที่ 3 ให้ลองทำการสร้างบางสิ่งบางอย่างใหม่ตั้งแต่ศูนย์

เหมือนเป็นการสร้าง prototype ของระบบหรือ feature หนึ่ง ๆ ขึ้นมา
เพื่อช่วยให้เราเรียนรู้สิ่งต่าง ๆ เพิ่มเติม
ทั้งเรื่องของเครื่องมือ
ทั้งเรื่องของภาษา และ library ต่าง ๆ
รวมทั้งการค้นหา
หาตั้วช่วยเหลือในการเขียน code
ยกตัวอย่างเช่น การใช้งาน

• prototype tool
• github copilot
• chatgpt

ไม่จำเป็นต้องเขียน code ได้ดี
แต่ต้องสามารถ share idea ต่าง ๆ ให้กับทีมได้
รวมทั้งได้รับรู้ว่าทีมต้องเจออะไร
มีสถานะอย่างไรบ้าง

จงอย่าใช้แต่ปาก จงลงมือทำด้วยมือของตนเองบ้าง
ขอให้สนุกกับการ coding

ปัญหาที่เจอหลังติดตั้ง Flutter ไปคือ
"Unable to find bundled Java version"
สำหรับการตรวจสอบผ่าน flutter doctor
โดย software ที่ใช้งานประกอบไปด้วย

• MacOS Ventuta 13
• Android Studio 2022.1
• Flutter 3.7.5

เลยลองหาวิธีแก้ไขดูหน่อย

เริ่มที่ปัญหาผ่าน flutter doctor

เท่าที่ไปดู issue ของ Flutter ก็มีปัญหากันนะ เช่น

• #106674
• #118502
• #119801

เลยพอได้แนวทางการแก้ไขปัญหานี้มา
ถ้าไม่อยากทำอะไรเลยก็ไปใช้ Flutter 3.8 beta ก่อนเลย
เพราะว่า ปัญหานี้ถูกแก้ไขไปแล้ว

แต่ถ้ายังใช้ stable version อยู่ ให้ทำการแก้ไขดังนี้

ง่ายสุดคือการสร้าง symbolic link ไปยัง folder jbr ด้วยชื่อ jre ซะ
เป็น folder ที่อยู่ใน Android Studio นั่นเอง

หรือจะทำการ copy ข้อมูลจาก folder jbr มายัง jre ก็ได้

หรือจะเข้าไปแก้ไขใน Android Stuidio ก็ได้
เพื่อแก้ไข JDK ของ Gradle นั่นเอง

ผลที่ได้คือ ทุกอย่างผ่านอย่างสวยงาม

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

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

เรื่องแรกที่เป็น breaking change เลยคือ Jakarta EE 9

ส่งผลให้ package เปลี่ยนไป ทั้ง
พวก servlet จาก javax.servlet ไปเป็น jakarta.servlet
พวก JPA จาก javax.persistence ไปเป็น jakarta.persistence
แต่ข้อดีคือ สามารถ find and replace แล้วใช้งานได้เลย
หรือทำผ่าน Spring Migrator เลย

เรื่องที่สอง GraalVM native support

จากเดิมชื่อว่า Spring Native นั่นเอง
โดยสามารถเพิ่มเข้ามาใน project ได้แบบง่าย ๆ
แนะนำให้ทำผ่าน Spring Initializr
แต่ว่าไม่ support พวก lazy loading และ profile annotation นะ

เรื่องที่สาม การเปลี่ยนแปลงใน Spring Data

พวก CRUD interface นั้น ค่าต่าง ๆ ที่ return เป็น iterator
จะเปลี่ยนเป็น List เป็นทั้งหมด
พวก delete by id จะไม่ throw exception เมื่อไม่พบข้อมูลที่จะลบ

เรื่องที่สี่ มี HTTP interface เพิ่มเข้ามา

สำหรับการเรียกใช้งาน external API ผ่าน HTTP protocol
แต่ต้องใช้งานร่วมกับ WebFlux เท่านั้นนะ
การใช้งานเหมือนกับ Retrofit และ OpenFiegn เลย
แต่เพียงตัวนี้มาพร้อมกับ Spring 6 เลย

ตัวหลัก ๆ ที่น่าสนใจคือ Java 17 ขึ้นไป
ดังนั้นใช้งาน virtual threads ได้ด้วย
และ Spring framework 6

พร้อมหรือยังสำหรับการเปลี่ยนแปลง !!