วันนี้เข้าไปสร้าง Spring Boot Project ผ่าน Spring Initializr
พบว่ามีการเปลี่ยนแปลงดังนี้

• version ของ Spring Boot ต่ำสุดที่มีให้เลือกคือ 3.1.6 โดยค่า default คือ 3.2.0
• version ของ Java มีให้เลือกเพียง 17 และ 21 เท่านั้น

ดังนั้นน่าจะบอกได้แล้วว่า
ใครที่ยังใช้งาน Java ต่ำกว่า 17 และ Spring Boot ต่ำกว่า 3
ควรต้องเปลี่ยนหรือย้ายกันได้แล้วนะครับ

จาก blog เรื่อง สรุปจากบทความ Choosing the best Node.js Docker image
มีคำถามเพิ่มเติมว่า Distroless image มันคืออะไร
ทำไมถึงเล็ก และ มีปัญหาเรื่อง security น้อยกว่า
จึงลงไปดูรายละเอียดเพิ่มเติม
สามารถสรุปสั้น ๆ ได้ดังนี้

Distroless image นั้นจะเป็น Docker image ที่เล็กลงมากว่าเดิม
โดยคิดมาจากทาง Google team นั่นเอง
เนื่องจากจะมีเฉพาะ library และ tool ที่ application ใช้งานเท่านั้น
เช่นพวก package manage และ shell utility ก็ไม่มี
ดังนั้นเรื่องของ OS tool และ shell ต่าง ๆ จะไม่มี หรือ เหลือน้อยมาก ๆ
ไม่ได้ไปลดการทำงานของ OS ลงไป

ส่งผลทำให้

• ขนาดของ image ลดลง
• performance ดีขึ้น
• การโจมตียากขึ้น เพราะว่าทางเข้า หรือ ช่องโหว่น้อยลง แต่เพื่อความมั่นใจต้อง scan image เสมอ

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

ไปเห็น VDO แนะนำความสามารถของ Spring Boot 3.2.0
แล้วพบว่ามีการใช้งาน command uao (unzip and open)
เพื่อทำการ extract zip file และเปิด project ใน IntelliJ IDEA CE ให้เลย
เห็นแล้วอยากทำบ้างเลยลองไปค้นหาดู
พบว่ามีขั้นตอนดังนี้

ขั้นตอนที่ 1 เรียนรู้การเปิด IntelliJ IDEA CE บน Mac ผ่าน command line ก่อน

ขั้นตอนที่ 2 การ unzip ขั้นตอนนี้ทำบ่อย

ซึ่งไฟล์ zip จะทำการสร้างมาจาก Spring Initializr นั่นเอง

ดังนั้นลองเขียน shell script ไว้ใช้งานนิดหน่อย

จากนั้นก็ใช้งานง่าย ๆ

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

ทางบริษัท Canonical ได้ประกาศปล่อย Chiselled Ubuntu containers version GA ออกมาแล้ว
ซึ่งเป็นรูปแบบของ image ที่เน้นในเรื่อง

• Production ready
• Secure by design และทีมงานก็สนับสนุนให้ตลอด
• Ultra small หรือมีขนาดเล็กมาก ๆ เพราะว่าตัดส่วนที่ไม่จำเป็นออกไป โดยใช้ Chisel ซึ่งพัฒนาด้วยภาษา Go สำหรับการทำ package slicing

ตัวอย่าง package slicing ของ Ubuntu

มีแนวทางเหมือนกับ Distroless ของ Google และ chainguard images

โดยที่จะมีการ build image พื้นฐานของภาษาที่ได้รับความนิยม ดังนี้

• .Net 6, 7 และ 8 สนับสนุน AOT (Ahead of Time) ซึ่งทาง Microsoft ก็เขียน blog .NET Chiseled Containers ไว้
• Java 8 และ 17
• Python

แต่ในตอนนี้ยังคงเป็น Work in progress อยู่
ดังนั้นยังอาจจะมีข้อผิดพลาดต่าง ๆ ได้
แต่ก็เป็นอีกทางเลือกที่น่าสนใจมาก ๆ
ลองศึกษาและใช้งานกันดูครับ

จาก blog เรื่อง ว่าด้วยเรื่อง Project CRaC กับ Spring framework
ยังขาดตัวอย่างการใช้งาน
จึงทำการสร้าง project ตัวอย่าง สำหรับการใช้งาน Spring Boot 3 กับ CRaC
เพื่อทำให้เห็นว่าเวลาในการ start up ดีขึ้นอย่างไรบ้าง
มาเริ่มกันเลย

ขั้นตอนที่ 1 สร้าง Apache Maven project และเพิ่ม library crac ใน pom.xml

ขั้นตอนที่ 2 ตอนนี้ CRaC นั้นสนับสนุน Linux OS เท่านั้น และ JDK 17, 21 เท่านั้น

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

• ทำการ Download JDK + CRaC มาใช้งาน
• ทำการ build JAR file ของ Spring Boot project
• ทำการ build docker image และ container
• ในการ run java จะเพิ่ม parameter เพื่อสร้าง checkpoint ของการทำงานไว้คือ java -XX:CRaCCheckpointTo
• จากนั้นทำการบันทึก checkpoint ไว้โดยทำการ commit container มาเป็น image (demo:checkpoint) เพื่อใช้ในการ start ครั้งต่อไป

Dockerfile เป็นดังนี้

การทำการอยู่ในไฟล์ entrypoint.sh

จากนั้นทำการ run เพื่อสร้าง image ของการ checkpoint ไว้

ขั้นตอนที่ 3 ทำการ run container เพื่อดูผลจากการบันทึก checkpoint ด้วย CRaC

จะเห็นได้ว่า เวลาในการ start จะเร็วมาก ๆ
ปกติที่เครื่องจะใช้เวลา 0.6 วินาที แต่พอใช้ CRac จะเหลือเพียง 0.039

Reference Websites

• https://openjdk.org/projects/crac/
• https://github.com/up1/demo-springboot-crac

จากการเปลี่ยนแปลงสิ่งต่าง ๆ ใน Spring Boot 3.2 นั้น
หนึ่งสิ่งที่น่าสนใจคือ Distributed Tracing
โดยเป็นการเปลี่ยนแปลงจาก Spring Boot 2.x แบบหน้ามือหลังมือ
ไม่สามารถใช้งานร่วมกันได้
จึงทำการสรุปการใช้งานไว้นิดหน่อย

เรื่องแรก คือ dependency ที่ใช้งานใน project

ซึ่งจะใช้งาน dependency ต่าง ๆ ดังนี้

• Spring Boot Actuator ใช้งานปกติ
• Micro meter กับ OpenTelemetry สำหรับการแปลงข้อมูล tracing ให้อยู่ในรูปแบบของ OpenTelemetry
• Exporter สำหรับจัดเก็บข้อมูล tracing โดยในตัวอย่างเลือกใช้งาน Zipkin
• การสร้าง custom span ใน code ของ project จะใช้แนวคิดของ AOP (Aspect Oriented Programming) มาใช้งาน

ถ้าสร้างเป็น Apache Maven project ในไฟล์ pom.xml เป็นดังนี้

เรื่องที่ 2 การ config เพื่อใช้งานในไฟล์ application.properties

เรื่องที่ 3 สร้าง custom span ใน code

เริ่มด้วยการสร้าง configuration สำหรับการสร้าง span ด้วย code ใน Spring Boot

จากนั้นทำการสร้าง span ด้วยการใช้ @Observered ได้เลย

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

Reference Websites

• https://spring.io/blog/2022/10/12/observability-with-spring-boot-3
• https://www.baeldung.com/spring-boot-3-observability

เช้านี้เห็นว่าทาง Google ได้ปล่อยให้ใช้งาน Gemini Pro แบบฟรี ๆ
แต่มีจำกัดนะครับ คือ 60 query ต่อนาที
It’s time for developers and enterprises to build with Gemini Pro
ซึ่งง่ายสุด ๆ คือ การใช้งานผ่าน Google AI Studio
มาลองใช้งานเล่นกันนิดหน่อย

การใช้งานก็ง่าย ๆ เข้าไปใน Google AI Studio แล้วก็เขียน prompt กันเลย

เลือกว่าจะสร้าง project แบบไหน เช่น

• Free form prompt
• Structured prompt
• Chat prompt

ตัวอย่างทำการเลือกแบบ Free form prompt

จากนั้นก็สร้าง API key และ Get Code ตัวอย่างเอามาใช้งานได้เลย

ทั้ง curl, JavaScript, Python, Android (Kotlin) และ Swift

เท่าที่ลองนั้น ข้อมูลล่าสุดคือ เดือนเมษายน ปี 2023 เท่านั้น

ลองเล่นกันดูครับ

ดู Pricing เพิ่มเติมได้

ทาง InfoQ ได้ปล่อย InfoQ Java Trends Report - November 2023 ออกมา
ทำการสรุป trend ของภาษา Java ว่าเป็นอย่างไรบ้าง
โดยหัวข้อที่น่าสนใจมีดังนี้

• Java 17 น่าจะเป็น base line ไปแล้ว และมีการนำมาใช้งานที่สูงมาก ๆ
• การเปลี่ยนแปลงหลาย ๆ อย่างใน Java เพื่อให้ผู้เริ่มต้นศึกษาได้ง่ายขึ้น เช่น Unnamed Classes and Instance Main Methods (Preview) และ Implicitly Declared Classes and Instance Main Methods (Second Preview)
• ส่วน Java 21 นั้นมีของดีคือ Virtual Thread ที่จะเข้าเปลี่ยน และ ปรับปรุงประสิทธิภาพของระบบงานอย่างสูง
• GraalVM แลพ CRaC (Coordinated Restore at Checkpoint) มีความน่าสนใจ และควรต้องทดลองใช้งานในการลด resource และ fast startup ยกตัวอย่างเช่น Spring Native, Micronaut และ Quarkus เป็นต้น
• ในโลกของ Generative AI นั้นก็มี library และ SDL สำหรับภาษา Java มากขึ้น เช่น Semantic kernel, Deeplearning4j เป็นต้น
• มี Spring Modulith ออกมาสำหรับจัดการ modular ให้ดีขึ้น เป็นอีกทางเลือกที่น่าสนใจ
• การทำงานบน container ยังคงใช้งานและพูดถึงเยอะมากขึ้นเรื่อย ๆ

วันนี้ใช้ Java version อะไรกัน ?

ช่วงวันหยุดทำการอ่านหนังสือ Tidy First ? (A personal Exercise in Empirical Software Design)
ก่อนหน้านี้ติดตามอ่านจาก SubStack::Tidy First ของคุณ Kent Beck
ในหนังสือเล่มนี้ทำการอธิบายถึงแนวปฏิบัติในการพัฒนา software ที่ดี
นั่นคือการลด code ที่ไม่ดี หรือ ผูกมัดกันมาก ๆ
ด้วยการจัดการและปรับปรุง code ให้ดียิ่งขึ้น (Refactoring หรือ Tidying) นั่นเอง
เพื่อช่วยทำให้ code อ่านง่ายขึ้น
ง่ายต่อการแก้ไข และ ลดผลกระทบต่างการเปลี่ยนแปลงลงไป

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

โดยแนวทางของหนังสือจะทำตามแนวคิด Software design ที่ดี ดังนี้

• Coupling
• Cohesion
• Discounted cash flows
• Optionality

เนื่องจาก cost ของ software นั้นมาจาก cost ของการเปลี่ยนแปลง
cost ของการเปลี่ยนแปลง มาจาก cost ของการเปลี่ยนแปลงขนาดใหญ่
cost ของการเปลี่ยนแปลงขนาดใหญ่ มาจาก coupling ของระบบที่สูง
ดังนั้น cost ของ software จะมาจาก cost ของ coupling นั่นเอง
จึงทำให้เรื่องของการ Decoupling/No coupling หรือ Loosely coupling จึงเป็นเรื่องที่สำคัญ

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

ลองหามาอ่านกันดูครับ

ปิดท้ายด้วยความหมายของคำว่า Tidy First

• ทำการจัดการ code ก่อนที่จะแก้ไข หรือ เพิ่ม
• การจัดการต้องมีประสิทธิภาพ และ ปลอดภัย
• การจัดการที่ดี ต้องรู้ว่าจะหยุดทำเมื่อไร ไม่ใช่ทำไปเรื่อย ๆ เพราะว่าทุกอย่างมีค่าใช้จ่ายเสมอ
• การเปลี่ยนแปลงทีละเล็กละน้อย
• ต้องเข้าใจพื้นฐานของ Software design ที่ดี เพื่อช่วยให้เกิดการจัดการที่ดีอย่างสม่ำเสมอ

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

ปกติในการทำ API testing ด้วย JavaScript และ NodeJS นั้น
มักจะใช้งาน library ต่าง ๆ เช่น Jest และ SuperTest
รวมไปถึง library/framework อื่น ๆ เช่น cypress และ playwright
แต่ก็มีอีกตังที่น่าสนใจคือ Vitest
ที่เพิ่งปล่อย version 1 ออกมาเมื่อเดือนที่ผ่านมา
ซึ่งเบื้องหลังการทำงานคือ Vite ที่เร็วมาก ๆ
ดังนั้นมาลองใช้งานเล่น ๆ กันดู

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

• ทำงานเร็วมาก รวมทั้งใช้ memory น้อยกว่าตัวอื่น ๆ เช่น Jest เป็นต้น
• ใช้ config เดียวกับ Vite
• สนับสนุน JavaScript, TypeScript และ ESM รวมทั้ง JSX ด้วย
• สนับสนุน Jest
• มี watch mode น่าจะเป็น default ไปแล้ว
• เริ่มต้นใช้งานแบบ zero configuration
• สำหรับการ assrtion จะมี Chai มาให้เลย รวมทั้งมี assertType ให้อีกด้วย
• ส่วนการ run test นั้นจะทำงานแบบ parallel มาให้เลย แต่ก็สามารถปิดการใช้งานได้
• มี benchmark ให้เลย ชิวมาก
• มี Vitest UI สำหรับแสดงผล report การทดสอบแบบสวย ๆ
• ทดสอบได้ทั้ง UI test, API test และ Snapshot test
• มี Mocking มาให้ใช้
• มี in source testing คือเขียน test case ใน production code ได้เลย ตรงนี้ไม่ค่อยชอบเท่าไร

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

เริ่มด้วยการเขียน test และ run แบบปกติ (watch mode)

สำหรับไฟล์ package.json เป็นดังนี้

• Test with watch mode
• Test แล้วจบ พร้อม coverage
• UI mode

ทำการแสดงผลการทดสอบแบบ html สวย ๆ ใน UI mode

มาลองทำ API testing ด้วย Vitest กันดีกว่า

ลองใช้งาน API จาก JsonPlaceHolder
โดยสิ่งที่ต้องการทดสอบประกอบไปด้วย

• Response status code
• Response content type
• Body response ต้องเป็น object
• JSON ของ response ต้องมี schema ตามที่ต้องการ

สามารถเขียนง่าย ๆ ได้ดังนี้

ผลการทดสอบเป็นดังนี้

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

เนื่องด้วยปลายปีต้องไปแนะนำการพัฒนาระบบงานด้วยภาษา Go นิดหน่อย
สิ่งหนึ่งที่โดนถามตลอดคือ
สำหรับผู้เริ่มต้นต้องเรียนรู้อะไรบ้าง
มีอะไรที่น่าสนใจบ้าง
จึงทำการสรุปไว้นิดหน่อย
ซึ่งเป็นแนวทางในการพัฒนาตลอดปี 2023 ที่ผ่านมา (ในมุมมองคนเริ่มต้นเช่นเดียวกัน)
มาเริ่มกันเลย

• เริ่มต้นโดยไปที่ go.dev นะครับ มีทุกอย่างที่นี่ ตั้งแต่การติดตั้ง และ เอกสารต่าง ๆ
• แนะนำการเรียนรู้เลยที่ go.dev/learn
• IDE หลัก ๆ ที่ผมใช้คือ VS Code และ Go extension

ส่วน go command line tools ที่ใช้ตลอด ประกอบไปด้วย

• go mod init สำหรับการสร้าง module ซึ่งเป็นค่า default ของ go project ไปแล้ว
• go mod tidy สำหรับ download และ prune พวก library/dependency ที่ใช้งานใน project
• gp work สำหรับการสร้าง workspace สำหรับ multi-module อันนี้สะดวกสบายมากขึ้น
• go fmt สำหรับการจัดการ format ของ code ใน project
• go lint cli สำหรับช่วยทำ static code analysis
• go build สำหรับการสร้าง single binary ของระบบงาน
• go test สำหรับทดสอบระบบงาน
• ทำการ scan code เพิ่อหาพวก secret ในระบบ ใช้งาน git Leak
• ทำ profiling อย่าลืม pprof นะครับ ของดี
• ถ้าไม่ใช้งานกับ Docker น่าจะยังประบได้อีกนะ
• สำหรับเริ่มมือในแปลง JSON ใน Struct นั้นใช้งาน json-to-go หรือ Paste JSON as Code ได้เลย

เพิ่มเติมสำหรับการ build single binary ตามแต่ละ OS และ CPU

ทำการ config environment variables ชื่อว่า GOOS และ GOARCH ดังตัวอย่าง

• GOOS=darwin GOARCH=amd64
• GOOS=windows GOARCH=arm64

ทำการ trim การ build ด้วยคำสั่ง

• go build -ldflags="-s -w"

หรือถ้าง่าย ๆ แนะนำให้ใช้งาน Go Releaser

ในส่วนของ library/package ที่น่าสนใจ

• testing ก็ต้อง testify
• web framework จะมี go gin, echo เป็นต้น
• logging ปกติจะมี zap, zerolog และ logrus แต่ตอนนี้ใน go มี standard library ชื่อว่า log/slog ออกมา ทำให้ง่ายไปอีก
• และอื่น ๆ อีกมากมายตาม requirement ของระบบ แนะนำดูที Awesome Go

ส่วนเรื่องความรู้ของภาษา Go ก็ต้องทำความเข้าใจ

หลัก ๆ ผ่าน go.dev/learn นั่นเอง เช่น Go Tour และ Effective go
จากนั้นเรื่องที่ต้องทำความเข้าใจก่อน สำหรับผมประกอบไปด้วย

• เรื่องของ go tool ตั้งแต่การพัฒนา ทดสอบ จนถึงการ deploy เขียนแค่ hello world ก็ได้
• syntax ก็ช่วยให้เราไปได้เร็วขึ้น ตัวภาษาอาจจะแปลก ๆ หน่อย เลยต้องทำความเข้าใจ ลงมือทำเยอะ ๆ
• ไปเรียนรู้ทั้งหมดไม่ได้ แนะนำให้หาปัญหา หรืองานที่จะทำ จากนั้นเรียนรู้ภาษาตามการแก้ไข จะทำให้สนุกมากยิ่งขึ้น
• สิ่งที่ต้องเข้าใจ หลัก ๆ ที่ของแนะนำเช่น struct, interface และ error handling จากนั้นไปดูที่โครงสร้างการทำงานของระบบงาน
• ภาษา go มีแนวทาง และ แนวคิดของตัวเอง จำเป็นต้องเรียนรู้และเข้าใจด้วย จะช่วยให้เราพัฒนาตัวเองขึ้นไปอีกทาง
• แนะนำให้ stay update go อยู่อย่างสม่ำเสมอ อย่ามีข้ออ้าง !!
• ChatGPT และ Chat Copilot เป็นเพื่อคู่คิด ขาดไม่ได้เลย แนะนำให้ลองนำมาใช้งานดูครับ

จงเรียนรู้อย่างต่อเนื่อง
ของให้สนุกกับการ coding ครับ
ตอนที่เขียน blog นี้ใช้งาน go 1.21.5

จากการแบ่งปันการพัฒนา RESTful API ด้วยภาษา Go
มีคำถามว่า ในการจัดการข้อมูลใน database ควรใช้อะไรดี ?
จะใช้งาน ORM หรือ Native SQL ดี ?
จึงทำการสรุปคำตอบไว้นิดหน่อย

มาดูในภาษา Go หรือภาษาอื่น ๆ จะมีแนวทางจัดการข้อมูลใน database ดังนี้

• Native SQL คือ เขียนชุดคำสั่ง SELECT, INSERT, UPDATE และ DELETE เอง
• SQL Builder จะเป็น library ช่วยให้สร้างชุดคำสั่ง SQL ง่าย ๆ
• ORM เป็นตัวช่วยในการ mapping ระหว่าง table ใน database กับ Data/Entity class ในภาษาต่าง ๆ เช่น Go ก็คือ Struct ส่วนใน Java ก็เป็น Class หรือ record นั่นเอง เช่น GORM และ XORM

ถ้าแนะนำจากประสบการณ์นิดหน่อยที่ผ่านมานั้น

ให้เริ่มจากการใช้งานแบบ Native SQL ก่อน
เพื่อให้ให้รู้และเข้าใจว่าแต่ละขั้นตอนเป็นอย่างไร
ประกอบไปด้วย

• การ config พวก database driver
• การสร้าง database connection ไปจนถึงพวก connection pool
• การสร้าง statement สำหรับทำการ execute ชุดคำสั่ง SQL ทั้ง CRUD
• การดึงข้อมูลใน table มาอนู่ในรูปแบบของ data class และ struct
• การจัดการ transaction ของการทำงาน เพื่อให้เข้าใจ boundary ของ transaction
• การคิด resource ต่าง ๆ ที่สร้างออกมา เช่น database connection เป็นต้น

โดยตอนนี้เราสามารถมีเครื่องมือช่วยเหลือ
ทั้ง DBML และ sqlc

ต่อมาจึงเริ่มมาที่ SQL Builder และ ORM ต่อไป

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

• การจัดการความสัมพันธ์ หรือ relation ของแต่ละ table/entity
• การดึงข้อมูลจาก table ที่มีความสัมพันธ์กันว่าดึงอย่างไร เยอะไหม เช่น eager และ lazy loading เป็นต้น
• อย่าลืมดูชุดคำสั่งที่ ORM ทำการ generate ออกมาด้วยเสมอ
• เมื่อมีข้อมูลเยอะขึ้น อย่าลืมทำการทดสอบ เพื่อดูเรื่อง performance ด้วย
• เรื่องของ explain หรือ analyze SQL ก็สำคัญมาก ๆ
• ยิ่งมีความซับซ้อนมากขึ้น ยิ่งต้องระวัง

อีกอย่างการใช้งาน ORM ต้องเข้าใจแนวคิดด้วย

ว่าพยายามให้เป็นการออกแบบ table ต่าง ๆ ด้วย code-first
จากนั้นทำการ generate ไปยัง database server อีกที
แต่สิ่งที่เจอบ่อยมาก ๆ มักจะตรงข้ามคือ
คนออกแบบ table ก็ไปทำที่ database server ไป
ส่วน developer ก็เขียน mapping เอาเอง
ต่างฝ่ายต่างทำ ทำให้ปัญหาเกิดขึ้นเยอะ !!

ลองศึกษาเพิ่มเติมกันดูครับ
เดี๋ยวนี้มีให้เลือกเยอะมาก ๆ
หรือดู library ของภาษา Go เพิ่มได้ที่ Awesome Go

Reference Websites

• Comparing SQL, query builders, and ORMs

สิ่งหนึ่งที่น่าสนใจของการพัฒนาระบบงานคือ
เรื่องของ Unique Id หรือ id ของ object ต่าง ๆ ที่ไม่ซ้ำ
เพื่อระบุถึง object นั้น ๆ ในระบบงาน
ยกตัวอย่างเช่น

• user id
• transaction id
• order id
• short url

คำถามคือ เรามีวิธีการสร้าง unique id กันอย่างไรบ้าง
ดังนั้นลองจดสรุปสิ่งที่เคยทำมาบ้างไว้นิดหน่อย
มาเริ่มกันเลย

วิธีที่ง่ายที่สุด คือ ใช้ id จาก table ของ database ไปเลย

เช่น

• sequence, auto increment จาก RDBMD (อย่าดึงมาแล้วเอามาบวก 1 ใน code ละครับ เดี๋ยวชน)
• UUID หรือ Object Id ของ document ใน MongoDB

ต่อมามีความต้องการเพิ่มเติมว่า unique id นั้นต้อง readable
หรืออ่านแล้วตีความได้ง่าย
เพื่อนำไปใช้งานต่อไปทางด้าน operation

เช่น order id
ต้องการให้รู้ว่า order สร้างวันไหน เวลาอะไร ดังนั้นต้องเป็น timestamp หรือ date ที่มี format
แต่อาจจะเกิดการซ้ำได้ ถ้ามีคนเข้ามาสร้าง order พร้อม ๆ กัน
ดังนั้นต้องเพิ่ม sequence id และ random number เข้ามาอีก !!
น่าคิดว่า ถ้า scale เครื่องเยอะ ๆ performance จะเป็นอย่างไร ?
และแนวทางที่เลือกจะมีโอกาสซ้ำไหม ?
ถ้าซ้ำแล้วจะทำ หรือ จัดการอย่างไร ?
เพื่อให้ระบบงานทำงานต่อได้

อาจจะต้องเพิ่ม prefix เข้ามาใน id ของแต่ละเครื่อง
สำหรับการ id ที่ generate ออกมา ถ้าใช้ sequence

ลองไปอ่านเกี่ยวกับ UUID หรือ GUID เพิ่มเติม พบว่า

มี UUID หลาย version มาก ๆ เช่น

• Version 1 Time-based MAC ใช้ mac address และ current time ของเครื่องนั้น ๆ
• Version 2 DCE Security เหมือนกับ type 1 แต่เพิ่ม POSIX UID หรือ GID เข้ามา
• Version 3 Name-based md5 เพิ่ม string เข้ามา แล้วผ่าน md5
• Version 4 Randomness เพิ่ม random data เข้ามา
• Version 5 Name-based SHA1 เปลี่ยนจาก md5 มาเป็น SHA1
• Version 5 Reordered Time
• Version 7 Unix Epoch Time ซึ่งมีตัว TypeID ที่ implement ตาม v7
• Version 8 Custom

พออ่าน UUID แล้วไปเจอว่าสามารถ convert ไปใช้ ULID ได้อีก
ULID (Universally Unique Lexicographically Sortable Identifier)
ซึ่งเรียงลำดับให้เลย แถมสั้นลง ไม่ค่อยซ้ำ ตรงนี้ต้องทดสอบ
เยอะไปไหน !!

ซึ่งเท่าที่เห็นจะใช้ UUID กันเยอะ ไม่ค่อยซ้ำ เพราะว่า ยาวตั้ง 128 bit
แต่ยากต่อการจดจำ และ ไม่สามารถเรียงลำดับได้

ตัวอื่น ๆ ที่เห็นมา เช่น

• Snowflake ID
• Sonyflake
• CUID
• NanoId

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

Reference Websites

• RFC 4122 UUIDs
• How to Generate Unique IDs in Distributed Systems: 6 Key Strategies
• Why you should never use an UUID as the primary key in SQL Databases
• The Wild World of Unique Identifiers (UUID, ULID, etc)
• What is Sqids
• UUID/GUID, CUID & NanoID: What's The Difference?
• UUID Generator
• Shopify increased their write throughput by 50% moving one of their MySQL keys from UUID to ULID. But How?

ทำการสรุป VDO เรื่อง Build in Observability While Developing จากงาน KubeCon
ทำการอธิบายถึง observability ของระบบว่า
ช่วยให้เราเข้าใจสิ่งที่กำลังเกิดขึ้นในระบบงาน หรือบน production
แต่มักจะพบว่า ในการพัฒนาและส่งมอบ feature นั้น
มักจะแยกระหว่าง code กับพวก observability (log, trace, metric) ออกจากกัน

หรือมาทำในภายหลังก่อนขึ้น production
ทำให้สิ่งที่ทำเพิ่มเข้ามานั้น ไม่ตรงกับสิ่งที่ต้องการ !!
ส่งผลต่อความเชื่อมันที่มีต่อระบบ และ พวก observability หรือไม่นะ ?

ดังนั้นใน VDO นี้จึงได้พยายามอธิบายว่า
observability นั้น ก็เหมือนการทดสอบ
ที่แต่ละ feature ก่อนจะส่งมอบต้องทดสอบเสมอ
ดังนั้น observability ก็เช่นกัน ต้องมาพร้อมกับ feature นั่นเอง
นั่นคือ มันอยู่ใน development process/workflow ไปเลย

โดยเรื่องของ observability นั้น แนะนำให้ไปใช้งาน OpenTelemetry กัน

คำแนะนำให้ VDO บอกว่า ถ้าคุณ log ได้ ก็ trace ได้

เริ่มจาก log การทำงานเป็น plain text ปกติ
จากนั้นเริ่มเรียงด้วยเวลาของการทำงาน
จากนั้นเริ่มสร้าง log ที่มีโครงสร้างชัดเจน ง่ายต่อการ process
เช่น JSON format เป็นต้น
ซึ่งจะเรียกว่า Structured log นั่นเอง

จากนั้นก็เริ่มใส่ trace id และ span id
เพื่อให้เห้นความพันธ์ของ log และละตัวนั่นเอง
ยกตัวอย่างเช่น

คำแนะนำในการเริ่มต้น

• ค่อย ๆ เพิ่ม ไม่ใช่ทำทีเดียวทั้งระบบ (start small)
• โดยเริ่มจาก automatic instrumentation ก่อน ซึ่งยังไม่ต้องเขียน code
• แต่ถ้าต้องการ insight ของการทำงานใน code จำเป็นต้องเขียน code เพิ่มเติม
• ทำการเรียนรู้จากการใช้งานในระบบ เพื่อดูว่าอะไรควรเก็บหรือไม่ควรเก็บ
• สิ่งที่ควรเก็บคือ ได้ใช้งานเมื่อมีปัญหานั่นเอง มิใช่เก็บทั้งหมด มันเปลือง
• ทำการปรับปรุงอย่างต่อเนื่อง ไม่ใช่เก็บแล้วจบนะ

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

Reference Websites

• Observability Is About Confidence
• Ask Miss O11y: To Metric or to Trace ?

ทาง Deno KV ได้ปล่อย npm สำหรับการใช้งานผ่าน NodeJS มาแล้ว
โดยที่ Deno KV นั้นเป็น serverless database
มีความสามารถหลัก ๆ ดังนี้

• Key-value database เป็น structure ที่ทำให้การอ่านและเขียนเร็ว
• สนับสนุน key แบบมีอายุ
• สนับสนุน ACID โดย default ดังนั้นเรื่องของ transaction และความถูกต้องของข้อมูลจึงน่าเชื่อถือ
• มีการใช้งาน queue สำหรับงานที่มี traffic สูง ๆ แล้วอาจจะกระทบต่อ reponse time
• สนับสนุนการทำงานแบบ batching หรือ job schedule
• ออกแบบมาให้สามารถ run แบบ localhost ได้ ซึ่งใช้งาน sqlite นั่นเอง ทำให้ง่ายต่อการพัฒนาและทดสอบ
• มีเป็นแบบ open source ให้มาติดตั้งใช้งานเองอีกด้วย
• มี watching mode สำหรับระบบที่ทำงานแบบ realtime

แต่ยังอยู่ใน beta version นะครับ !!

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

เริ่มที่ติดตั้งก่อน

จากนั้นลองใช้งานแบบ dev mode หรือ localhost

จะทำการสร้างไฟล์ database บนเครื่องของเรานั่นเอง

ถ้าต้องการใช้งานผ่าน Deno KV บน Cloud

ต้องไปสมัครใช้งานก่อน เพื่อให้ได้ API Key มาใช้งาน
โดยที่ใน free tier นั้น จะสามารถใช้ Deno KV ได้ที่

• อ่าน 450,000 ครั้งต่อเดือน
• เขียน 300,000 ครั้งต่อเดือน

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

ก่อนหน้านี้เคยเขียนอีกตัวคือ Vercel KV ซึ่งเป็น database ชนิดเดียวกัน

เช้านี้มีโอกาสได้แลกเปลี่ยนแนวคิดของคิดว่า programmer และ product developer
บางที่เรียกว่า product engineer
ว่าทั้งสองอย่างนี้ มีแนวคิดต่างกันอย่างไร
ทำไมต้องเรียกต่างกันด้วย
จากที่นั่งฟังเลยสรุปไว้นิดหน่อยดังนี้

มุมมองของ Programmer !!

• เน้นที่ code เป็นหลัก ให้เสร็จตามที่มอบหมาย
• สนใจเฉพาะในงานของตนเอง ไม่ต้องดูภาพรวม บางคนยังไม่รู้เลยว่าสิ่งที่ตนเองพัฒนามันอยู่ตรงไหนของ product
• ไม่ต้องสนใจที่ business value หรือ สิ่งที่ทำจะมีประโยชน์หรือไม่
• ไม่ค่อยได้ทำงานร่วมกับคนให้ requirement โดยตรง มักจะทำงานผ่านคนกลาง !! และคนกลางจะเป็นคนบอกว่าให้ทำอะไรบ้าง
• ในการวางแผน บ่อยครั้งมีคนมาวางแผนให้ว่า ต้องทำอะไรเสร็จในช่วงเวลาไหนบ้าง
• มีการเข้าร่วมการ review งานนะ แต่คนที่เข้า review มีแต่คนในฝั่ง IT กันเอง ส่วนเข้าของ requirement ไม่เขาด้วย

มุมมองของ Product developer

• เข้าร่วมในการพูดคุยเรื่องเป้าหมายของการพัฒนา product ด้วยว่ามีเป้าหมายอย่างไรบ้าง เพื่อให้เห็นภาพรวมของ product ทั้ง long-term และ short-term
• มีการ share idea ของ feature ให้ชัดเจน ก่อนลงมือทำ ว่ามี value อะไรบ้าง หรือ ตัดสิ่งที่ไม่จำเป็นออกไป
• ทำงานร่วมกับคนให้ requirement อย่างใกล้ชิด
• มีการร่วมกัน clear requirement กันเรื่อย ๆ แบ่งงานใหญ่ออกมาเป็นงานเล็ก ๆ เพื่อให้ง่ายต่อการ deliver
• มีการ review product อย่างต่อเนื่อง กับคนให้ requirement เพื่อรับ feedback โดยตรง ว่าอะไร work หรือ ไม่ work เพื่อใช้ในการวางแผนต่อไป
• มีเป้าหมายเพื่อส่งมอบ feature ที่มี value ร่วมกับคนให้ requirement ซึ่งมีทั้งฝั่ง business และ technical value

สิ่งที่น่าสนใจคือ เราจะทำอย่างไร
เพื่อช่วยปรับเปลี่ยนมุมมองจาก programmer ไปยัง ptoduct developer ได้
ไม่ใช่แค่ตัวเราเองอย่างเดียว
แต่สิ่งแวดล้อมรอบข้างต้องเอื้อด้วยเช่นกัน

วันนี้เราคืออะไรนะ ?

ถ้าเป็น Developer แล้ว เราน่าจะต้องมีการพัฒนาอย่างต่อเนื่องสินะ !!

เพิ่งเห็นว่าภาษา Gleam นั้นใกล้จะปล่อย version 1.0 ออกมาแล้ว
เลยมาลองเล่นนิดหน่อย
ซึ่งเป็นภาษาโปรแกรมที่ run อยู่บน BEAM (Erlang Virtual Machine)
โดยที่ complier ของภาษา Gleam ถูกพัฒนาด้วยภาษา Rust
จะทำการแปลง code ไปเป็นภาษา Erlang และ JavaScript ให้
ได้รับแรงบันดาลใจมาจากภาษา ELM อีกด้วย

สิ่งที่ Gleam เตรียมไว้ให้สำหรับการเริ่มพัฒนาใหม่ ๆ หรือย้ายมา
คือเครื่องมือต่าง ๆ ที่จำเป็นต่อการพัฒนา
ทั้งการสร้าง project
ทั้งการ run
ทั้งการ test
ทั้งการ build
มาลองใช้งาน Gleam กันแบบง่าย ๆ กัน

ขั้นตอนที่ 1 ทำการติดตั้ง Gleam ก่อน

สามารถทำการติดตั้งตามขั้นตอน
จากนั้นทำการตรวจสอบด้วยคำสั่งดังนี้

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

โดยใน project จะประกอบไปด้วย

• src สำหรับเก็บ code ของ project
• test สำหรับเก็บ test ของ project
• มีไฟล์ gleam.toml สำหรับจัดการ dependency ของ project
• มี Github Actions มาให้ด้วย

ตัวอย่าง code ของ project ที่พัฒนาด้วยภาษา Gleam (Hello World)

มี gleamunit และ gleamunit/should สำหรับเขียน unit test และการ assert ให้ด้วย

ทำการทดสอบนิดหน่อย

ขั้นตอนที่ 3 ทำการ build ไปยัง Erlang และ JavaScript

ด้วยคำสั่ง

ค่า default จะทำการสร้าง code ภาษา Erlang ออกมาให้

หรือจะทำการสร้าง JavaScript ก็ทำตามนี้

ขั้นตอนต่อไป คือ การศึกษาเพิ่มเติม

ซึ่งมีหลายสิ่งอย่างที่ต้องศึกษา ประกอบไปด้วย

• Gleam package/dependency
• เรียนภาษา Gleam เบื้องต้นที่ Language Tour
• ใน Github ของ Gleam-lang มีหลายอย่างให้ใช้งาน ทั้ง OTP/HTTP lib และ Awesome Gleam

มาลองศึกษากันดูครับ
ขอให้สนุกกับการ coding

ก่อนหน้านี้เขียนสรุป feature ใหม่ ๆ ใน Robot Framework 7 alpha ไป
ตอนนี้ทีมพัฒนาได้ปล่อย version 7.0 ตัว final ออกมาแล้ว
โดยมีความสามารถที่น่าสนใจดังนี้

• ปรับปรุง Listener interface เพื่อใช้สำหรับดูการเปลี่ยนแปลงต่าง ๆ ขณะการทดสอบ ทั้งการเปลี่ยนแปลง data และ result ต่าง ๆ
• เพิ่ม VAR เข้ามาในการประกาศตัวแปร
• สนับสนุนการใช้งาน embedded arguments และ normal arguments ในการสร้าง keyword ได้เลย
• ใน report ของผลการทดสอบ จะเพิ่มไฟล์ JSON เข้ามา
• Test report สนับสนุน dark mode

ไปทำการ download และ update ได้แล้ว

วันนี้เห็น issue ใน Playwright เกี่ยวกับการทำงานร่วมกับ Bun
ซึ่งพบว่าทาง Playwright ไม่ได้ merge การเปลี่ยนแปลงเข้าไป
เนื่องจากเป็นปัญหามาจาก Bun นั่นเอง
ซึ่งใน Bun 1.0.22 นั้นทำการแก้ไขปัญหาแล้ว
ทำให้เราสามารถ

• สร้าง test project ด้วย bun
• ทำการ run test ของ Playwright ผ่าน bun command ได้

มาลองใช้งานกัน

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

นั่งอ่านบทความเรื่อง 12 Software Architecture Pitfalls and How to Avoid Them
ทำการสรุป 12 ข้อที่ควรหลีกเลี่ยงหรือระมัดระวังสำหรับ Software architecture
ซึ่งหลัก ๆ แล้วจะพูดถึงเรื่อง

• คนที่ตัดสินใจด้าน architecture ของระบบ ควรเป็นคนในกลุ่มที่ลงมือทำ อย่าเชื่อใจหรือเชื่อมั่นคนอื่นที่ไม่รู้บริบทขององค์กร หรือ งานนั้น ๆ
• คนที่ลงมือทำ จะมีความรู้ความเข้าใจเกี่ยวกับความต้องการของระบบ และ ข้อจำกัดต่าง ๆ เป็นอย่างดี เพื่อให้รู้ ข้อดีและข้อเสียของการตัดสินใจนั้น ๆ ซึ่งปรับปลี่ยนได้ตลอด
• พูดถึงเรื่อง Quality Attribute Requirements (QARs) ของการออกแบบ architecture เพื่อให้ได้คุณภาพที่ดี ซึ่งการยกเว้นบางอย่าง อาจจะส่งผลให้เจอความล้มเหลวได้ง่าย ๆ คุณภาพต่อรองไม่ได้ ดังนั้นควรต้องกำหนก QARs ของระบบไว้ก่อนเสมอ
• อย่า copy จากที่อื่นมาใช้งาน หรือ ระมัดระวังการ resuse เพราะว่า แต่ละอย่างถูกสร้างมาเพื่อแก้ไขปัญหาที่แตกต่างกัน
• การ evaluate ที่ดีที่สุดคือ การลงมือสร้างและทดสอบ เพื่อให้ได้ feedback ที่รวดเร็วจากผู้ใช้งานจริง ๆ จะดีกว่าการออกแบบให้ perfect แต่ใช้เวลานาน ซึ่งเป็นแนวทางสู่ความล้มเหลว ดังนั้นการพัฒนาแบบ small increment เป็นสิ่งที่จำเป็นอย่างมาก เพื่อลดความเสี่ยงและสิ่งที่ไม่มีประโยชน์ออกไป

ตัวอย่างของ Quality Attribute Requirements trade-off

ลองนำแนวคิดเหล่านี้มาปรับใช้งานดูครับ