เห็นใน Go community ทำการการแนะนำ GoFr
คือ framework สำหรับพัฒนา service หรือ mocroservice ด้วยภาษา Go
โดยที่ build-in library ต่าง ๆ ที่จำเป็นต่อการใช้งานเข้ามาให้เพียบ (เยอะไปหรือเปล่านะ)
แต่คิดว่าน่าจะช่วยลดงานต่าง ๆ ลงไปได้เยอะ
ทำให้นักพัฒนาไป focus ที่ business logic มากยิ่งขึ้น

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

• REST by default แต่ก็สนับสนุน gRPC ให้ด้วย ส่วน WebSocket ก็มีให้เช่นกัน
• Observability ทั้ง 3 เรื่องคือ Metric, Trace และ Log ไม่ต้องเขียน code
• สนับสนุน circuite breaker
• ในการเชื่อมต่อ database และ database migration ก็มีให้ มีทั้ง SQL และ NoSQL
• พวก Messaging ทั้ง Queue และ Pub/Sub
• Support swagger หรือ OpenAPI documentation
• อีกทั้งยังสามารถ custom ในส่วนต่าง ๆ ได้อีกด้วย

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

ลองสวัสดีกันหน่อย download ของมาให้เพียบ

ลอง go mod tidy ของมาเพียบ !!

ขอให้สนุกกับการ coding ครับ
ตัวอย่างมี test ให้หมดอีกด้วย ชอบเลยแบบนี้

ปล. ค่า default ทำการเปิด log มาที่ console นั้น ทำให้ performance แย่มาก ๆ อย่าลืมปิดละ !!

หนึ่งใน UI framework ที่น่าสนใจที่คล้าย ๆ กับ Streamlit และ Gradio
สำหรับการสร้างระบบงานแบบง่าย ๆ ยิ่งในส่วน Prompt engineer แล้ว
ยิ่งน่าจะคุ้นเคยสำหรับการสร้าง UI ให้ใช้งานง่าย ๆ
ด้วยการ coding ที่ไม่เยอะมากนัก
เพื่อให้ทำการทดสอบ หรือ ทดลองได้ง่ายขึ้น
โดยตัวที่น่าสนใจอีกตัวคือ Google Mesop

สิ่งที่น่าสนใจ ประกอบไปด้วย

• พัฒนาด้วยภาษา Python ดังนั้นต้องติดตั้ง Python ก่อน โดยที่ทำงานอยู่บน Flask
• Open source
• ช่วยให้การสร้าง UI ง่ายและรวดเร็วขึ้น แต่อยู่ใน template ที่กำหนด

Mesop จะมี components ให้ดังนี้

• High level component จะเป็น ready-to-use ให้เลย เช่น Chat interface, text-to-text และ text-to-image เป็นต้น
• Low-level component จะเป็น component เล็ก ๆ หรือ element ต่าง ๆ ในหน้า web เช่น text box, text area, button และ markdown editor เป็นต้น อีกทั้งยังเปิดให้ทำการ custom ได้อีกด้วย

ยังมี demo ให้ศึกษาเพิ่มเติมอีกด้วย

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

ทำการติดตั้ง Mesop ก่อน จะได้ทั้ง library และ command line tool ในการ run server ขึ้นมา

จากนั้นทำการเขียน code โดย copy มาจาก offiicial web เลย

ทำการ run เพื่อใช้งาน (มี hot reload ให้ด้วย ดีมาก ๆ)

เมื่อเปิดหน้า web ผ่าน browser แสดงผลดังนี้

เป็นหน้าตา UI แบบ text-to-text นั่นเอง

หรือถ้าต้องการ UI แบบ Chat ก็ลองเล่นได้เลย เช่น

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

จากเหตุการณ์ BSOD (Blue Screen of Death) ใน Windows OS นั้น
ที่เกิดจากการ rollout ของ CrowdStrike
ซึ่งส่งผลกรพทบต่อบริษัทต่าง ๆ จำนวนมาก
ในมุมมองของ Software Developer นั้นได้เรียนรู้อะไรจากเหตุการณ์นี้บ้าง ?

เรื่องแรกที่สำคัญมาก ๆ คือ แนวทางในการทดสอบ

ควรต้องจำลอง environment การทดสอบให้คล้ายหรือเหมือนจริงให้ได้มากที่สุด
test case ให้ครอบคลุมในส่วนต่าง ๆ
แต่ใช้ชีวิตจริงเป็นอย่างไร ตรงนี้น่าจะต้องทำการปรับปรุงให้ดียิ่งขึ้น
ที่สำคัญเรื่องของ strategy ของการทดสอบก็สำคัญ
โดยต้องสร้างสมดุลระหว่าง คุณภาพที่สูง กับความเร็วในการส่งมอบ เช่น

• Unit test
• Integration test
• Component test
• Contract test
• End-to-end test

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

มีคำพูดที่น่าสนใจคือ Quality is not important util the software is important

เรื่องต่อมาคือ เรื่องของการ rollout

เป็นเรื่องของ deployment strategy ที่น่าสนใจ เพื่อลดปัญหาลงไปบน production
เช่น

• Big bang
• Blue-green deployment
• Canary release
• Stage rollout เช่น canary (nightly), dev, beta และ stable เป็นต้น

จะเห็นได้ว่าปัญหาดังกล่าวมาจากการ rollout แบบ Big bang
ที่สำคัญเรื่องการทดสอบก็ไม่ค่อยดีด้วย จึงทำให้เกิดปัญหาอันยิ่งใหญ่
มีคำพูดที่ตลกร้ายคือ ระบบปกติมา 365 วัน แต่มีปัญหาวันเดียว คนจะจดจำ 1 วันนั้นเสมอ !!
ที่สำคัญคือ ผลกระทบจากปัญหานั่นเอง ว่ามันร้ายแรงอย่างไรต่อธุรกิจ

ดังนั้นในการ rollout ควรจะค่อย ๆ ปล่อยออกมาเช่น

• เริ่มจากการ Eat Your Own Dog Food ก่อน นั่นคือ rollout ใช้ภายในองค์กรก่อนว่ามีปัญหาอะไรหรือไม่
• จากนั้นค่อย rollout แบบ canary release ไป เช่น 10%, 30%, 50% และ 100% ในที่สุด หรือจะแบ่งตามกลุ่มผู้ใช้งานก็ได้ ในแต่ละขั้นตอนก็ monitor ดูว่ามีปัญหาเกิดขึ้นหรือไม่

เรื่องสุดท้าย เมื่อเกิดข้อผิดพลาดขึ้นแล้ว ไม่ใช่มานั่งหาว่าใครผิด

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

ตอนนี้ Spring Boot 3.4.0 นั้นยังอยู่สถานะของการพัฒนาและทดสอบเท่านั้น
แต่ก็มีความสามารถหลาย ๆ ตัวที่น่าสนใจ
หนึ่งในนั้นที่น่าจะทำให้นักพัฒนาและการดูแลระบบง่ายขึ้น
นั่นก็คือ Structured Log นั่นเอง
ทำให้ log อ่านเข้าใจง่ายขึ้น มีรูปแบบที่ชัดเจนคือ JSON format

โดยที่จะมี format ของ login ที่ build-in มาให้เลยคือ

• Elastic Common Schema (ecs)
• Logstash (logstash) formats
• Custom format ได้ผ่าน interface StructuredLoggingFormatter

การใช้งานก็ง่ายมาก ๆ เพียงแค่กำหนดในไฟล์ application.properties หรือ yml ได้เลย ดังนี้

ผลการทำงานเป็นดังนี้ ได้ log สวย ๆ มาแล้ว

ลองใช้งานเล่นกันดูครับ
อ่าน Release notes เพิ่มได้

Microcks คือเครื่องมือสำหรับการทดสอบระบบงาน และ สร้าง API Mocking ขึ้นมาแบบง่าย
โดยสนับสนุน protocol หรือ tool ที่หลากหลาย ทั้ง HTTP/HTTPs, gRPC, AMQP, MQTT, Apache Kafka
ช่วยให้จำลอง API server (Mock server) ได้ง่าย
ช่วยให้สร้าง automation test ได้ง่ายขึ้น
สามารถทำงานร่วมกับ CI/CD tool ต่าง ๆ ได้อีก
นั่นคือช่วยอำนวยความสะดวกตั้งแต่การพัฒนา ทดสอบ ไปถึงการ deploy ระบบงานเลย
ดังนั้นมาลองใช้งานกันดูนิดหน่อย

เริ่มต้นการใช้งาน Microcks นั้น รองรับเอกสารในรูปแบบต่าง ๆ ที่ใช้ในปัจุบัน

• Swagger หรือ OpenAPI
• AsyncAPI
• GraphQL
• Postman
• gRPC
• SOAP UI

สามารถทำการ import มาใช้ใน Microcks ได้เลย
ซึ่งสะดวกมาก ๆ

จากนั้นสามารถสร้าง Mock server สำหรับ API ในรูปแบบต่าง ๆ ได้เลย

ดังนั้นมาลองใช้งานเพื่อสร้าง Mock server จาก Postman collection กันดู

เพื่อให้เข้าใจมากยิ่งขึ้น

เริ่มด้วยการติดตั้งผ่าน Docker compose กันเลย
ซึ่งติดตั้ง software หลายตัว ทั้ง MongoDb, KeyCloak และ Postman runtime (ทำงานร่วมกับ Postman ได้เลย)

เข้าใช้งานกันดูผ่าน web browser

• http://localhost:8080
• user=admin
• password=microcks123

เข้ามายังระบบดังรูป

จากนั้นทำการเพิ่ม APIs/Services เข้ามาได้เลย เช่น OpenAPI หรือ AsyncAPI
หรือเพิ่มความง่ายไปยังส่วนของ Microcks Hub ได้ เพื่อติดตั้งจากตัวอย่างได้เลย

ซึ่งในตัวอย่างทำการเลือก Petstore API เข้ามาเล่น (Postman collection)
เมื่อเข้าไปดูข้างในจะพบว่า Microcks นั้นจะสร้าง Mock API ให้เลยดังนี้
ถ้ามี example response ของแต่ละ case จะขึ้น tab แยกใน mocks section ให้เลย

เพียงเท่านี้ก็ใช้งานได้แล้ว
อีกอย่างเราสามารถเพิ่ม testing คือการ call api ตามที่เราต้องการใน Microcks ได้อีกด้วย

ใช้งานง่ายมาก ๆ ที่สำคัญยังมีความสามารถอื่น ๆ อีก
ลองเล่นกันดูครับ

การพัฒนา mobile app นั้นมีหลากหลายแนวทางมาก
ทั้ง native app development ด้วยภาษา Kotlin และ Swift
หรือจะเป็นพวก cross-platform หรือ hybrid app development
ด้วย Flutter, ReactNative และ Kotlin multiplatform (KMP)
แต่เพิ่งเห็นอีกหนึ่งแนวทางคือ Skip tool

แนวคิดของ Skip คือ

สามารถพัฒนา mobile app ด้วย Swifit และ SwiftUI บน XCode ปกติ
จากนั้นทำการแปลงผ่านตัว transpiler ของ Skip มาเป็น Android app ให้เลย
โดยแปลงมาเป็น Kotlin และ Jetpack compose นั่นเอง
ช่วยลดงานลงไปอย่างมาก แต่ว่าง่ายไหมอันนี้ไว้ลองต่อไป

Software requirments

• macOS 13+
• XCode 15+
• Android Dtufio 2023
• Homebrew

ติดตั้ง Skip ผ่าน Homebrew

จากนั้นทำการตรวจสอบ software บนเครื่องว่ามีครบไหม ?

จากนั้นก็ลองสร้าง project และลองใช้งานกันดูครับ
เป็นอีกแนวทางที่น่าสนใจ
ตอนนี้ลองใช้แบบ free trail ได้เลย

บทความเรื่อง How the Medium iOS team works effectively with legacy code
อธิบายถึงแนวทางในการทำงานกับ Legacy code
ในฝั่งของ iOS App team ของ Medium.com ว่าเป็นอย่างไรบ้าง ?
โดยแนวทางการทำงานจะอ้างอิงมาจากหนังสือ Working effectively with legacy code
มาเริ่มกันเลย

"Legacy Code is code without tests"

เริ่มจากที่มาของ iOS app ของ Medium.com นั้นมีอายุมากกว่า 10 ปีแล้ว
ซึ่ง code หลาย ๆ ส่วนตั้งแต่เริ่มต้น ยังคงถูกในงานใน app ปัจจุบัน
ดังนั้นในทุกวัน ทีมพัฒนายังต้องทำงานกับ code เก่า ๆ
โดยทีมพัฒนาทำการสรุปว่ามีแนวทางในการจัดการ code เก่า ๆ เหล่านี้อย่างไรบ้าง ?

เริ่มต้นด้วยเรื่องของการเปลี่ยนแปลง

แน่นอนว่า ยังต้องแก้ไข และ เพิ่มความสามารถต่าง ๆ เข้ามาใน app อย่างต่อเนื่อง
แถมต้องไม่ส่งผลกระทบ หรือ ส่งผลต่อระบบน้อยมาก ๆ ด้วย
หรือช่วยทีมพัฒนาสามารถส่งมอบ feature ให้ทาง business ได้อย่างสม่ำเสมอ

ยกตัวอย่างเช่นการระบบการ render ของ app
ที่ทำการ rewrite ไปบางส่วน
แต่วันดีคืนดีต้องทำการเพิ่มความสามารถใหม่ ๆ เข้าไป
ดังนั้นจำเป็นต้องไปแก้ไข code เก่า ๆ
ทำอย่างไรที่จะลดการแก้ไข code เก่า ๆ ที่มีความซับซ้อนลงไป
หนึ่งในวิธีการที่เลือกใช้จากหนังสือข้างต้น คือ Sprouts (Sprout method or Sprout class)

แนวทางที่ทีมพัฒนาใช้งานคือ
สร้างส่วนการทำงานใหม่ขึ้นมา จากนั้นค่อย embedded ส่วนใหม่เข้าไป
โดยในส่วนใหม่จะพัฒนาด้วย SwiftUI
สร้างเป็น SPM module (Swift Package Manager)
จากนั้นก็เรียกใช้งาน แล้ว render ด้วย UIKit ของระบบ render ที่สร้างเอาไว้
ซึ่งช่วยให้ง่ายต่อการเพิ่มความสามารถใหม่ ๆ และลดผลกระทบลงไป
แถมได้ใช้ technology ใหม่ ๆ อีกด้วย

ปัญหาต่อมาคือ ไม่เข้าใจ code เก่า ๆ เหล่านั้นดีพอ ก่อนที่จะแก้ไขมัน

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

ปัญหาต่อมาคือ App ไม่มีโครงสร้างที่ชัดเจน !!

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

ปัญหาต่อมาคือ ถ้า class มันใหญ่มากแล้ว ยังจะเพิ่ม code เข้าไปอีกหรือ ?

โดยโครงสร้าง หรือ code ของระบบงานมันอาจจะทำงานได้ดี
มี function การทำงานต่าง ๆ ครบ
แต่ว่ามันเอื้อต่อการพัฒนาต่อไปหรือไม่ ?

ดังนั้นแนวทางคือ เรื่องของ responsibility หรือ หน้าที่รับผิดชอบ
ว่ามีหน้าที่รับผิดชอบเยอะเกินไปไหม
ถ้าใช่ ก็พยายามแยกออกมาจากกัน

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

ไม่ไปทำให้ code หรือ การทำงานส่วนอื่น ๆ ไม่พัง หรือ กระทบ !!
เพราะว่ามันคือ การ refactor code นะ

วิธีการที่ใช้งานประกอบไปด้วย

• Preserve signature
• Lean on the compiler

เรื่องสุดท้ายคือ To rewrite or not to rewrite

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

Good design should be a goal for all of us, but in legacy code, it is something that we arrive at in discrete steps.

ลองนำไปประยุกต์ใช้งานกันดูครับ
ขอให้สนุกกับการ coding

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

ฝั่งคนใช้งาน คงไม่แก้ไขด้วยการเพิ่ม timeout หรอกนะ ?
ไม่มีใครเขาทำกัน !!

จากการเข้าไป review architecture และ source code
รวมถึงการปรับปรุงไปนิดหน่อย
จึงทำการสรุปไว้ดังนี้

• ทำ caching และ pre-caching ในทุก ๆ level ทั้ง frontend, backend, data (denormalization), network, file, CDN
• ทำ caching แล้วอย่าลืมเรื่องของการ purge data ด้วย หรือเรื่อง expired time
• ออกแบบ business process flow ให้ชัดเจน ไม่ยาวจนเกินไป หรือ ไม่โดยน flow ของภายใน ออกไปให้ลูกค้า หรือ ผู้ใช้งานมารอ ให้รอเท่าที่จำเป็นเท่านั้น
• จากเรื่อง business process flow นั้น อาจจะต้องออกแบบ UX/UI flow ใหม่ด้วย เพื่อปรับเปลี่ยนพฤติกรรมการทำงานของระบบ
• ถ้าแยกเป็น frontend/backend/micoroservice อย่าให้ผูกมันกันมากนัก อาจจะกันด้วย api gateway, load balancing, service discovery ไว้ด้วย ทำให้เอื้อต่อการเปลี่ยนแปลง หรือ จัดการง่ายเมื่อมันพัง
• การติดต่อสื่อสารระหว่างส่วนงานต่าง ๆ อาจจะต้องปรับเปลี่ยนไปใช้งาน asynchonous communication หรือ processing อีกด้วย แต่อย่าลืมว่า ช้า === ล่มนะ ถึงแม้ทาง IT จะบอกว่าไม่ล่ม แต่ส่ง responseไปยังลูกค้าช้า !! ดังนั้นต้องมองให้ครบแบบ end-to-end
• การทำงานกับ database ถ้ามันช้าก็จัดการหลาย ๆ ส่วน ทั้ง design for read และ design for write, normalization vs normalization, indexing ให้เหมาะสม, data sharding/partition, เลือกใช้ databasae model ให้เหมาะกับงานด้วย อย่าลืมดู slow log กันด้วย
• เมื่อพูดถึงเรื่อง data ก็อย่าลืมบีบอัดข้อมูลที่ส่งไปมาผ่านระบบ network กันด้วย รวมทั้ง connection ด้วยว่าต้องใช้ keep-alive นานเท่าไร อย่างไร ในแต่ละ usecase
• วาด flow การทำงานของระบบด้วยในแต่ละเรื่องด้วย เพื่อให้เข้าใจว่าทำงานอย่างไร
• เรื่องของ observability ของระบบขาดไม่ได้เลย เช่น metric, trace และ log เป็นต้น อีกตัวที่ชอบใช้คือ exception tracking
• เรื่องของการ write log ของระบบ เจอว่ายังทำงานแบบ synchพonous อยู่เลย ตรงนี้แก้ได้แก้เลย

ปล. ระบบทำงานเร็วอย่างเดียวยังไม่เพียงพอ

ต้องทำงานได้อย่างถูกต้องด้วย ดังนั้น
เรื่องของ การทดสอบ จึงสำคัญ
เรื่องของ observability จึงสำคัญ
และรับ feedback จากผู้ใช้งาน ยิ่งสำคัญมาก ๆ
ดังนั้น feedback loop ยิ่งเร็วยิ่งดี

ทาง docker ได้ปล่อย Docker Desktop 4.33 ออกมา
พร้อมกับ Docker build check ที่มีมาตั้งแต่ buildx version 1.50
ซึ่งช่วยทำการตรวจสอบ Dockerfile ให้เองแบบอัตโนมัติ
ตาม best practice ของการเขียนนั่นเอง
ที่สำคัญสามารถนำไปใส่ใน pipeline ของการ build หรือใน CI/CD ได้อีกด้วย

โดย Docker build check นั้น จะเตรียม rule ต่าง ๆ มาให้ เช่น

• JSONArgsRecommended
• MaintainerDeprecated
• StageNameCasing

เพื่อช่วยป้องกันปัญหาที่อาจจะเกิดขึ้นจาก Dockerfile ทั้ง

• การ maintain
• การ scan bug หรือปัญหาต่าง ๆ
• การดูแลเรื่อง performance

แถมช่วยลดเวลาของการหาปัญหา และ แก้ไขลงไปอีกด้วย
เพื่อความเข้าใจมาลองใช้งานกันดู

เริ่มจาก Dockerfile แบบปกติ ใช้งานได้เลย

ลองทำการ build ปกติผ่าน command line
จะทำการ scan และบอกว่ามีปัญหาตรงไหนบ้าง

ถ้าต้องการให้แสดงบรรทัดหรือจุดที่มีปัญหา

ทั้งสองแบบนั้น จะ return แค่ warning ออกมาเท่านั้น
แต่เมื่อนำขั้นตอนนี้ไปใส่ใน CI/CD จะได้ signal success เสมอ
ดังนั้นเราต้องเปลี่ยนนิดหน่อย เพื่อให้แจ้งหรือส่ง signal กลับมาว่า error
ด้วยการแก้ไขไฟล์ Dockerfile ดังนี้

จากนั้นก็ run ใหม่อีกรอบ ได้ผลดังนี้

ใช้งานง่ายมาก ๆ

ปล. ลืมไปว่า ก็ผลใน Docker Desktop เพิ่มได้ด้วย
สำหรับใครที่ชอบแบบ UI นั่นเอง

ผลการสำรวจ Developer survey 2024 จาก StackOverflow ออกมาแล้ว
โดยส่วนใหญ่เขียน JavaScript และ Python
ส่วน Rust ยังคงได้รับความสนใจมากขึ้น
และใช้งาน database คือ PostgreSQL
แต่สิ่งที่น่าสนใจมาก ๆ คือ ให้ความสำคัญกับ Technical Debt มากที่สุด

โดยที่นักพัฒนาเรียนรู้การเขียน code จากผ่านทาง online เช่น

• Technical documentation
• StackOverflow
• Tutorial
• Blog
• VDO
• Online book
• AI

โดยที่มีการใช้ AI คงที่ ไม่เพิ่มขึ้นจากปีที่แล้ว
ซึ่งยังมองว่า AI เหมาะกับงานที่ไม่ซับซ้อน
และมีความกังวลกับข้อมูลที่ผิดพลาด ซึ่งได้จาก AI นั่นเอง
การใช้ AI มาช่วยในเรื่องของ การเขียน code, ค้นหา, debug และ อธิบาย code

ปัญหาที่นักพัฒนาเจอ และ ส่งผลให้เกิดปัญหาอย่างมาก

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

• Technical debt
• Technology stack ที่ซับซ้อน
• ความน่าเชื่อถือของเครื่องมือ และ ระบบงาน

สิ่งที่น่าสนใจมาก ๆ เกี่ยวกับการหาความรู้หรือข้อมูลในองค์กร มักจะมีปัญหา เช่น

• การรอคำตอบที่นาน ซึ่งทำให้การทำงานล่าช้า
• ความรู้ที่แบ่งตาม silo หรือตามแผนก หรือ กลุ่มงาน ทำให้การแบ่งปันความรู้ข้ามแผนกเป็นไปได้ยากมาก ๆ

Process และเครื่องมือที่ทีมพัฒนานำมาใช้ในองค์กร ประกอบไปด้วย

• CI/CD
• DevOps
• Automated testing
• Microservices
• Knowledge sharing community
• Observability tool
• AI-assist

สามารถอ่านสรุปได้เลยที่นี่
อ่านง่ายดี

มาทำความรู้จักกับ FastHTML กันหน่อย
โดยมีเป้าหมายเพื่อสร้าง web application ด้วยภาษา Python กันไปเลย
และยังใช้งาน CSS และ JavaScript ต่าง ๆ ได้
ทำการสร้างบน technology stack ต่าง ๆ เหล่านี้

• HTMX
• HTTP และ HTML 5
• ASGI (Asynchronous Server Gateway Interface)

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

มาดู hello world กัน

ลอง run ดูหน่อย

โดยจะนำความสามารถของ FastAPI มาใช้ด้วย
ทั้งเรื่องของ log และ hot reload ให้เลย สะดวกสบายสุด ๆ

ตัวอย่างต่อมาคือ TODO App แบบมี database เป็น file

ก็พอดูได้เลย สร้าง Form สร้าง HTML และ interact ต่าง ๆ ใน code กันไปเลย

ในการ deploy ก็ต้อง deploy บน server ที่สนับสนุน Python

ยกตัวอย่างการ deploy บน Vercel ก็มี template ให้ใช้งาน
ตอนนี้ยังเป็น experimental feature ด้วยนะ !!

ตัวอย่างของ app ที่ deploy ยน Vercel

ผู้สร้างทำการอธิบายไว้ใน Twitter
ลองเขียนเล่นดูครับ
ขอให้สนุกกับเขียน code

สรุปจากการแบ่งปันเรื่อง Automated testing with Cypress เป็นเวลา 2 วัน
เป็นการเขียน test script ด้วย Cypress เป็นภาษา JavaScript
โดยสิ่งที่แบ่งปันเป็นดังนี้

เริ่มด้วยการติดตั้ง และ สร้าง repository สำหรับเก็บ test script

ประกอบไปด้วย 2 แนวทางคือ

• แยก repository ออกมาจาก code
• ใช้ repository เดียวกันกับ code ไปเลย

ขึ้นอยู่กับแนวทางที่ตกลงร่วมกัน
แต่ที่แนะนำคือ รวมกันไปเลย

ต่อมาทำการสร้าง project ด้วย cypress ปกติ

และแนะนำความสามารถของ Cypress UI หรือ Studio
ว่ามีความสามารถอะไรบ้างที่สำคัญ เช่น

• แนวทางในการทดสอบทั้ง unit, integration และ end-to-end test เพื่อให้เข้าใจ strategy ของการทดสอบ
• โครงสร้างของ Cypress project ว่าเป็นอย่างไร
• รูปแบบของการทดสอใน Cypress เช่น End-to-End, Component, API, Snapshot, Visual testing
• Auto testing
• การ debug
• การ record test script ผ่าน Cypress Studio ที่ยังคงเป็น experiment feature เท่านั้น แต่ใช้งานได้ดี
• การใช้งาน cypress playground เพื่อช่วยให้การ inspect และเขียน test script ง่ายขึ้น
• ตัวอย่างของ cypress ที่มือใหม่ต้องเรียนรู้ คือ example.cypress.io
• ปรับปรุงให้ test step ใน UI และ report สวย ๆ อ่านง่าย เป็น step-by-step ด้วยการใช้งาน cypress-plugin-steps
• การ configuration ที่น่าสนใจในไฟล์ cypress.config.js/ts
• การทดสอบผ่าน command line รวมทั้ง parameter ต่าง ๆ
• การจัดการ network request เพื่อทำการ stub request ต่าง ๆ ที่ต้องการ

จากนั้นเริ่มให้ test script ด้วยภาษา JavaScript

• เขียนแบบปกติ โดยใช้ cypress playground และ ตัว recorder ทั้งใน Cypress Studio และ extension ใน Google Chrome
• เริ่มทำการ refactor code ของ test script ด้วยการไปใช้ test life cycle, แยกเป็น function ย่อย ๆ, แยกไปเป็น class และ แยกไปเป็น command ต่อไป
• เพื่อให้ test script อ่านง่าย และเป็นมิตรขึ้นมา ด้วยการใช้งาน Cypress Cucumber ด้วยรูปแบบของ Gherkin มาช่วย ด้วย library ชื่อว่า cypress-cucumber-processor ซึ่งเปลี่ยนคน maintain แล้ว
• การจัดการ selector หรือ element บนหน้า web ที่ดีกว่าเป็นอย่างไร ลดการผูกมักกับหน้า web ลงไป
• การ assert หรือตรวจสอบผลการทำงาน ว่าเป็นไปตามที่เราคาดหวังหรือไม่
• การจัดการ test case เพื่อลด flaky test ลงไป
• การจัดกลุ่มของ test case ด้วย Cypress tags
• การสร้าง test report ในรูปแบบต่าง ๆ ทั้ง build-in, Mocha custom, JUnit, Allure และ Cucumber เป็นต้น

ทำการสร้าง pipeline ของ CI/CD

• ออกแบบ pipeline ของขั้นตอนการทำงาน
• สร้าง pipeline โดยทำการทดสอบด้วย Cypress
• ใช้งาน Cypress + Docker สำหรับการทดสอบระบบงานตาม test case ที่เขียน

เป็นการแนะนำสำหรับก้าวแรกของการใช้งาน Cypress
สำหรับเขียน test script เพื่อช่วยการทดสอบให้ง่ายและสะดวกขึ้น
ต่อจากนี้คือ การลงมือทำ เพื่อฝึกฝน และเพิ่มประสบการณ์ต่อไป
แต่เหนือสิ่งอื่นใดคือ
จะทดสอบอะไรบ้าง ?
เพิ่มความมั่นใจที่มีต่อระบบหรือไม่ ?

ขอให้สนุกกับการทดสอบ และ coding

ในการเขียน code นั้นมีแนวปฏิบัติ และ เครื่องมือหลาย ๆ อย่าง
ที่ช่วยให้เราเขียน code ให้มีระบบระเบียบ มาตรฐานที่ดีขึ้น
ทั้ง coding style, lint ต่าง ๆ
รวมทั้งการดูความสัมพันธ์ต่าง ๆ ของ code (dependency graph) ว่าเป็นอย่างไร
แยกเป็น module ชัดเจน หรือ รวมกันเป็น god file หรือไม่
เพื่อช่วยให้การดูแลรักษา code และการขยายง่ายยิ่งขึ้น
โดยหนึ่งในเครื่องมือที่น่าสนใจคือ dep-tree

ตัว Dep-tree นั้นมีความสามารถดังนี้

• Entropy เพื่อสร้าง dependency graph ของ code เป็นภาพ 3D โดยเราสามารถ config ในไฟล์ .dep-tree.yml เช่นไฟล์เริ่มต้ย ไฟล์ที่ต้องการหรือไม่ต้องการให้ตรวจสอบ และ circular dependency เป็นต้น
• Explain สำหรับการแสดง dependency ระหว่างไฟล์
• Tree สำหรับเลือกไฟล์หลักของการสร้าง depenedncy graph
• Check ทำการตรวจสอบ code ว่าไม่ผูกมัดกันมากไป ตามที่กำหนดไว้ ซึ่งใช้ใน pipeline ของระบบ CI นั่นเอง

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

ใน Spring Boot 3.4 ที่กำลังจะออกมานั้น
ทำการแจ้ง deprecated @MockBean และ @SpyBean แล้ว
ซึ่งมาจากการเปลี่ยนแปลงของ Spring framework 6.2 นั่นเอง
นั่นหมายความว่าใน version ต่อไปจากนี้จะมีการลบออกไป
ดังนั้นนักพัฒนาระบบงานด้วย Spring Boot และเขียน Test ด้วย
ต้องเตรียมรับมือกับการเปลี่ยนแปลงครั้งนี้เช่นกัน

การแจ้งเตือนใน IntelliJ IDEA เป็นดังนี้

โดยการเปลี่ยนแปลงนี้ สามารถใช้งานของใหม่ได้ดังนี้

ในการทดสอบด้วย SpringBootTest
สามารถจำลองด้วย @MockitoBean และ @MockitoSpyBean ได้เลย
มาจากเทคนิค override bean ใน test นั่นเอง

ถ้าในการทำ unit test สามารถใช้ผ่าน @TestBean ได้เลย
เป็นการเปลี่ยนแปลงใหม่ใน Spring framework 6.2
ช่วยให้สามารถ override bean ต่าง ๆ ได้ง่ายขึ้น
และไม่ผูกติดกับ library ใด ๆ เช่น Mockito เป็นต้น

นักพัฒนา RESTFul API ด้วย Spring Boot นั้นมักจะ return ข้อมูลที่ error กลับมา
ในรูปแบบที่หลากหลายแล้วแต่จะออกแบบไป
แต่หนึ่งในแนวทางที่น่าสนใจคือ ProblemDetail
ซึ่งมีรูปแบบตาม RFC 9457
ดังนั้นมาลองทำความรู้จักและใช้งานกันดู
เพื่อช่วยให้ error message เข้าใจได้ง่ายขึ้น

สิ่งที่ต้องเข้าใจก่อนคือ การจัดการ error ที่ไม่ดีเป็นดังนี้

• Error ที่ส่งกลับไปไม่เป็นประโยชน์ เข้าใจยาก
• สื่อสารกลับไปแบบผิด ๆ
• ชอบซ่อน information ของ error ไว้มากเกินไป
• ชอบส่ง stack trace กลับไปทั้งหมด แบบนี้ก็เยอะเกินไป อาจจะเกิด data leak ได้ง่าย ๆ
• แต่ละทีม แต่ละ product ก็มีรูปแบบของ error message ที่แตกต่างกันไป !!

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

ดังนั้นหนึ่งในแนวทางเพื่อช่วยลดปัญหาคือ จัดการรูปแบบของ error ให้เป็นมาตรฐาน
โดยหนึ่งในแนวทางนั้นคือ Problem Detail นั่นเอง

โดยที่ Problem Detail มีโครงสร้างดังนี้

• type บอกชนิดของปัญหา หรือ URL
• status คือ HTTP status code
• title คือ ชื่อสั้น ๆ ที่คนอ่านเข้าใจได้ง่าย
• detail คือ รายละเอียดเพื่ออธิบายปัญหานั้น ๆ
• instance คือ URI ของ request นั้น ๆ
• extension คือ field ที่เพิ่มเข้าในแต่ละส่วนง่าย ทำการ custom ได้เลย

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

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

วิธีการแรก เปิดใช้งานด้วยการ config ไฟล์ application.properties ไปเลย

ตัวอย่างเมื่อ return HTTP status code = 404

วิธีการที่สอง จัดการใช้ ControllerAdvice ได้เลย

เพียงเท่านี้ก็คุยกันง่ายขึ้นแล้ว
ขอให้สนุกกับการ coding ครับ

Reference Websites

• Problem Details (RFC 9457): Doing API Errors Well
• Returning Errors Using ProblemDetail in Spring Boot

ก่อนนอนพบว่า Go 1.23 ตัว final เพิ่งปล่อยออกมา เลยลอง update มาใช้กันหน่อย
โดยใน version นี้มี package ใหม่ ๆ และ feature ใหม่ ๆ เพิ่มเข้ามาดังนี้

• iter
• slices
• maps
• structs
• unique

หลัก ๆ เริ่มจาก package iter หรือ iterators ของ พวก type Seq และ Seq2
ซึ่งสามารถสร้างมาจากข้อมูลประเภท slice และ map นั่นเอง

• Seq คือ sequence ของ value เท่านั้น
• Seq2 คือ sequence ของ Key, Value นั่นเอง จึงเป็นที่มาของ 2

มาดูตัวอย่าง code กันหน่อย

เริ่มจากการ upgrade Go 1.23 กันก่อน

ใช้งาน iter และ slices package แบบง่าย ๆ

จากนั้นเขียน sort ตัวเลขจากน้อยไปมากกันหน่อย

ลองศึกษาและนำไปใช้กันดู
ขอให้สนุกกับการ coding ครับ

Grafana Beyla เป็นเครื่องมือสำหรับจัดการข้อมูล observability ของ application แบบง่าย ๆ
เช่น application metric และ distributed tracing
ด้วยการสร้าง auto-instrumentation เพื่อดึงข้อมูลจาก eBPF (Extended Berkeley Packet Filter) ได้เลย
ทำให้ในฝั่ง application ไม่ต้องเพิ่ม code ใด ๆ เข้าไป
โดยใน Grafana Beyla นั้นสนับสนุน multi-process
จึงส่งผลให้ดึงข้อมูลของแต่ละ process ที่อยู่บนเครื่องเดียวกันได้

แสดงดังรูป

ดังนั้นเพิ่มความเข้าใจ จึงลองเขียน code และใช้งานกันหน่อย

โดยตัวอย่างของ application ที่สร้างมานั้น ประกอบไปด้วย

• พัฒนา web application ด้วยภาษา go
• ทำการ build และ run ตัวอย่างด้วย Docker compose

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

ขั้นตอนที่ 1 สร้าง web application ด้วยภาษา go แบบปกติ

ขั้นตอนที่ 2 ทำการ build และ run ด้วย Docker compose

โดยทำการ config เพื่อใช้งาน Grafana Beyla
เพื่อดึงข้อมูล metric และ trace ของระบบงาน
ผ่านด้วยการระบุชื่อ container ไปได้เลยแบบง่าย ๆ ดังนี้

ขั้นตอนที่ 3 ทำการ run และดูผล

รวมทั้งข้อมูลของ trace ที่พ่นออกมาเป็น text ใน log อีกด้วย
เป็นไปตามมาตฐานของ W3C Trace Context
ถ้า request ที่เรียกไม่มีข้อมูลการ trace ก็จะสร้างให้ใหม่นั่นเอง

เพียงเท่านี้ก็ได้ข้อมูล metric และ trace ของ web application มาแบบง่าย ๆ แล้ว
ไม่ต้องมาเขียน code เพิ่มแต่อย่างใด
ลองใช้งานกันดูครับ น่าสนใจดี

เพิ่มเติมรูปการทำงานนิดหน่อย

Reference Websites

• Demo code :: GitHub:Up1
• Grafana Beyla 1.0 release: zero-code instrumentation for application telemetry using eBPF

เห็นในกลุ่ม Firebase Data Connect กำลังพูดถึง postgres.new
ซึ่งเป็นการใช้งาน Postgres database บน web browser
โดยที่ข้อมูลจะเก็บใน IndexedDB นั่นเอง
ทำให้สามารถสร้างกี่ instance ก็ได้
รวมทั้งมี AI Assistance ให้อีกด้วย
ลองใช้งานเล่นกันดูครับ

สามารถใช้ prompt ช่วยสร้าง database ได้เลย
มีทั้ง ER diagram และ script การสร้าง table ให้ด้วยแบบง่าย ๆ

และยังมีความสามารถอื่น ๆ เช่น

• Import ไฟล์ CSV ได้
• สร้าง report และ chart ต่าง ๆ ได้

โดยที่เทคโนโลยีด้านหลังคือ PGlite นั่นเอง

Dependency Track คือระบบที่ทำการวิเคราห์ข้อมูล SBOM (Software Bill of Materials)
ของระบบงานต่าง ๆ ซึ่งสนับสนุนโดย OWASP นั่นเอง
โดยจะช่วยตรวจสอบว่า component หรือ library ที่เราใช้ในระบบงานนั้น
มีปัญหา หรือ ช่องโหว่ใดบ้าง
ซึ่งจะตรวจสอบจากฐานข้อมูลต่าง ๆ เช่น CVE Database เป็นต้น
และแสดงผลในรูปแบบที่เข้าใจง่าย และ tracking ได้ง่าย

แถมเรายังสามารถ integrate เข้ากับ pipeline ของระบบ CI/CD ได้อีก
จึงช่วยให้ทีมงานรู้ปัญหาได้ตลอดเวลา
ไม่ต้องมาเสียเวลาหา หรือ scan ในช่วงก่อนการส่งมอบ
ซึ่งมันเสียเวลาไปอย่างมาก
ดังนั้นมาลองใช้งานกันดู

เริ่มจากการติดตั้ง

มีหลายวิธีการ โดยวิธีการที่เลือกใช้คือ Docker compose

ต้องรอสักพักนะ เพราะว่าจะทำการ download ข้อมูลของพวก CVE ต่าง ๆ ลงมา
จากที่ดูใน Docker volume นั้นมีขนาดประมาณ 10GB กันเลยทีเดียว

ต่อมาทำการสร้าง project และไปหา API Key มา เพื่อ upload ข้อมูล SBOM เข้าระบบ

เนื่องจาก dependency track นั้นแบ่งเป็น frontend และ backend ให้ใช้งาน
ดังนั้นเราสามารถ upload ข้อมูลของระบบงาน
เข้าไปยัง dependency track ผ่าน API ของ Backend ได้เลย
หรือถ้าใช้พวก CI/CD tool ก็มี plugin ให้ใช้งาน
ทั้ง Jenkins และ GitHub Actions ลองหากันดู

ส่วนในตัวอย่างผมยิงผ่าน curl ไปเลย ง่ายดี
โดยเป็น SBOM ในรูปแบบของ CycloneDX
ซึ่งสร้างมาจากระบบงานที่พัฒนาด้วย Spring Boot 3.3 ดังนี้

จากนั้นไปดูผลการวิเคราะห์ผ่าน frontend ได้เลย ดังนี้

จะช่วยวิเคราะห์ให้ว่า dependency ตัวไหน มีปัญหาบ้าง

ดูง่ายและสะดวกดีมาก ๆ
ลองใช้งานกันดูนะครับ
มันคือเรื่องของ transparency อย่างหนึ่งของการพัฒนาระบบงาน

ยังไม่หมด ยังสามารถดึงข้อมูลจากระบบอื่น ๆ ได้อีก เช่น

• National Vulnerability Database (NVD)
• GitHub Advisories
• Sonatype OSS Index
• Snyk
• Trivy
• OSV
• VulnDB from Risk Based Security

Puppeteer เป็น library สำหรับควบคุมการทำงานบน web browser
ซึ่งใน version 23 สนับสนุน Firefox แล้ว
ดังนั้นช่วยให้นักพัฒนาสามารถใช้งานได้ทั้ง Chrome และ Firefox
โดยที่ทำงานผ่าน WebDriver BiDi
ไม่ได้ทำงานแบบ request/response เหมือนกับ WebDriver
แต่ทำงานแบบ bi-directional ซึ่งทำงานเร็วมาก ๆ

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

ทำการ config browser ที่ใช้งาน

จากนั้นทำการติดตั้ง browser และ run ดังนี้

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

Reference Website

• WebDriver BiDi - The future of cross-browser automation