ไปเจอว่าทาง Postman ได้จัด live ด้วยเรื่อง How secure are your APIs?
ว่า APIs ที่ดีควรจัดการเรื่องความปลอดภัยพื้นฐานอะไรบ้าง
ลองไปดูกันนะ

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

• การตรวจสอบขั้นพื้นฐานของ API เช่น CORS, Header, Authentication และ SQL Injection เป็นต้น
• Environment scanner
• Domain expire

ลองเล่นกันดูครับ น่าจะพอมีประโยชน์

ใน web go.dev นั้นได้ปล่อย tutorial ของ Generic และ Fuzzing ออกมาแล้ว
เพื่อช่วยให้เราเข้าใจว่า จะเขียน code และ ใช้งานอย่างไร
โดยทั้งสองเรื่องนี้มาใน Go 1.18 ตัวเต็ม
ดังนั้น Go developer ไม่น่าพลาดที่จะเรียนรู้

• Getting started with generics
• Getting started with fuzzing

ทางทีมพัฒนาของ Spring ได้ปล่อย Spring Boot 3.0.0-M1 ออกมาแล้ว
ยังคงเป็น Milestone version เท่านั้น
นั่นคือปล่อยให้เรามาทดลองนั่นเอง
โดยสิ่งที่น่าสนใจประกอบไปด้วย

• ใช้งาน Java 17 ขึ้นไปเท่านั้น !!
• สิ่งที่แจ้ง deprecated ไว้ใน Spring Boot 2.x จะถูกเอาออกไปทั้งหมด
• ถ้าใครใช้งาน JavaEE API แล้ว จะต้องเปลี่ยนไปใช้ package ของ Jakarta EE เช่น servlet จะต้องเปลี่ยนไปใช้ package jakarta.servlet และ JPA เปลี่ยนมาใช้ jakarta.persistence เป็นต้น แน่นอนว่าจะกระทบกับ 3-party library อีกด้วย
• จากการเปลี่ยนแปลงที่มาใช้งาน Jakarta EE ทาง spring boot starter paakage จะจัดการให้ทั้งหมด แต่ถ้าทำการเพิ่มเอง ก็ต้องแก้ไขเองนะ

ทดลองกันดูครับ
และสามารถอ่าน Release note เพิ่มเติมได้

หลังจากที่ได้ invited code และติดตั้ง Warp terminal ไว้สักพักแล้ว
แต่ยังไม่มีโอกาสมาลองใช้งาน
วันว่าง ๆ จึงลองมาใช้งานกันหน่อย ว่าเป็นอย่างไร
มาเริ่มกันเลย สำหรับสัมผัสครั้งแรก !!

โดยที่ Warp เป็น teminal ที่บอกว่าทำงานเร็วมาก ๆ
ซึ่งพัฒนาด้วยภาษา Rust นั่นเอง

วันนี้มี update ใหม่มาให้ติดตั้งใช้งานกันอีกแล้ว

เริ่มที่หน้าตาก็ดำ ๆ นี่แหละ ไม่มีอะไรมาก
ใช้งานได้เหมือน terminal อื่น ๆ ส่วนใหญ่ผมใช้ iTerm + zsh เป็นประจำ
สิ่งที่เห็นชัด ๆ คือ มีการแสดงคำสั่งล่าสุด
หรือแสดง history ของคำสั่งที่เราใช้มาให้
หรือมันคือ auto suggestion นั่นเอง
ตรงนี้ก็สบายดี

กับอีกเรื่องคือ ในแต่ละคำสั่งที่เราพิมพ์ไปใน terminal จะแยกเป็น block ไป
ก็แปลกใจว่าทำไมแยกเป็น block ด้วย
แต่มาสังเกตว่า แต่ละ block เราสามารถ share ไปให้คนอื่นได้อีกด้วย
ตรงนี้ชอบเลย

แถมมี Shortcut ต่าง ๆ ให้ใช้งานอีกด้วย

ยกตัวอย่างเช่นเรื่อง Completion ก็เพียงกดปุ่ม Tab ก็ขึ้นมาให้แล้ว

ไปอ่านดูพบว่าเรื่อง session management และ restore data
ของ terminal นั้นมันทำอย่างไร ?

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

ส่วนพวก Theme, Command Palette, Split pane, Full screen ก็มีให้ใช้งานเป็นปกติ

ตอนนี้เป็น native application ในแต่ละ OS
ซึ่งเห็นใน feature ต่อไป จะใช้งานใน web browser ได้ด้วย
ก็น่าสนใจดี
รวมทั้งมีเรื่อง realtime collabolation ที่จะเพิ่มเข้ามาอีก

โดยรวม ๆ แล้วถือว่า แปลกใหม่ดี ทางด้านแนวคิด

กับเรื่องการใช้งานก็ง่าย ๆ ไม่ยุ่งยาก
หรือเพราะว่าผม ไม่ค่อยได้ใช้ feature อะไรแปลก ๆ ด้วย
จึงไม่ค่อยว้าวเท่าไร
แต่ไว้ลองใช้ไปเรื่อย ๆ น่าจะเห็นอะไรว้าว ๆ ขึ้นบ้าง

แต่ใช้ resource น้อยนะ
ยกตัวอย่างเช่น iTerm 2 ใช้ memory ไป 150 MB
ส่วน Warp ใช้ไปเพียง 50 MB เท่านั้นเอง
ตรงนี้แหละที่ชอบสุด ๆ

สุดท้ายลองไปอ่านเรื่อง How Warp Works ?
ได้ความรู็เกี่ยวกับการทำงานของ Warp ดีมาก ๆ

หลาย ๆ คนน่าจะเล่นเกมส์ Wordle กันในทุก ๆ วัน
สำหรับการเดาคำศัพท์ความยาว 5 ตัวอักษร จำนวน 6 ครั้ง
ในตอนนี้เจ้าของได้ประกาศออกมาแล้วว่า
ทาง New York Times ได้ซื้อแล้ว และกำลังจะย้าย domain
แต่การใช้งานทุกอย่างยังฟรีและไม่มีโฆษณาเหมือนเดิม

จากสถิติการเล่น Wordle นั้น
พบว่ามีจำนวนผู้เล่นสูงมาก ๆ จาก 300,000 คน จนมาถึงหลายล้านคน
ในช่วงปลายเดือนมกราคมที่ผ่านมา

An update on Wordle pic.twitter.com/TmHd0AIRLX

— Josh Wardle (@powerlanguish) January 31, 2022

ลองมาดูผลการเล่นและ share ผ่าน Twitter กันหน่อย

#Wordle 225 2022-01-30
294,687 results found on Twitter.
11,524 hard mode players.

1: 0%
2: 2%
3: 🟩🟩🟩🟩 18%
4: 🟩🟩🟩🟩🟩🟩🟩🟩🟩 39%
5: 🟩🟩🟩🟩🟩🟩 27%
6: 🟩🟩🟩 12%
X: 2%#Wordle225

— Wordle Stats (@WordleStats) January 31, 2022

มีคำถามมาว่า ถ้าต้องการติดตั้ง Docker บน Mac (Intel)
จะต้องทำอย่างไรได้บ้าง ?

โดยวิธีการที่ง่าย ๆ คือ การใช้งาน minikube และ Docker ปกติ

ขั้นตอนง่าย ๆ ดังนี้

• ทำการ uninstall Docker Desktop for Mac ออกไป
• ทำการติดตั้ง Docker ผ่าน brew ด้วยคำสั่ง $brew install docker
• ทำการติดตั้ง Hyperkit ผ่าน brew ด้วยคำสั่ง $brew install hyperkit
• ทำการติดตั้ง minikube ผ่าน brew ด้วยคำสั่ง $brew install minikube

เมื่อทำการติดตั้งแล้ว ให้สร้างและ start minikube cluster บน hyperkit ดังนี้

จากนั้นกำหนดให้ Docker ทำการ access เข้า cluster ของ minikube

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

เท่าที่ดู Hyperkit ยังไม่สนับสนุนบน Mac M1 นะ !!

Reference Websites

https://itnext.io/goodbye-docker-desktop-hello-minikube-3649f2a1c469

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

สิ่งที่ควรจะต้องมีประกอบไปด้วย

• Health check ของ service น่าจะต้องเป็นค่า default ไปแล้ว เพื่อช่วยบอกว่า service ยังทำงานได้ปกติหรือไม่ ทั้ง liveness และ readiness
• Alert system ที่ทำงานแบบ realtime และควรแจ้งทั้งปัญหา หรือ รูปแบบที่อาจจะก่อให้เกิดปัญหา ควรเตือนก่อนจะเกิดปัญหา ถ้าแจ้งตอนเกิดปัญหา มันจะตั้งตัวไม่ทัน ในการ alert ควรแบ่งแยกด้วยว่าจะส่งหรือแจ้งผ่านช่องทางไหนที่เหมาะสม
• Logging สำหรับ error เท่านั้น บ่อยครั้งเรามักจะเก็บ log เยอะมาก ๆ ทั้ง success และ failure มันทำให้หาปัญหาได้ยากมาก ๆ รวมทั้งเปลือง resource ของการเก็บมาก ๆ รวมทั้งระบบ logging ควรทำงานแบบ Asyncchronous ด้วย เพื่อลดปัญหาที่จะเกิดขึ้นกับ service
• Distributed tracing สำหรับระบบงานที่มีการเรียกใช้หลาย ๆ service แล้ว จะขาดการ tracing ไม่ได้เลย จะช่วยให้เราเห็นภาพได้ชัดเจนว่า แต่ละ service ทำการติดต่อสื่อสารกันอย่างไร และตรงไหนที่เกิดปัญหากันแน่

ถ้าในแต่ละ service ของเรามีข้อมูลต่าง ๆ เหล่านี้
น่าจะช่วยให้เราสามารถแก้ไขปัญหาได้อย่างรวดเร็ว
และช่วยลดผลกระทบต่อผู้ใช้งานและ business ได้อย่างมาก

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

มาดูเรื่องราวกันหน่อย
เริ่มจากระบบงานมีการทำงานต่าง ๆ ด้วยกัน มี database เดียวกัน
จากนั้นทำการแยกออกเป็น class หรือ file การทำงานตามหน้าที่รับผิดชอบ
เช่น

• Entity หรือ model สำหรับติดต่อกับ database
• Service สำหรับส่วนของ business logic

แต่ละ Entity จะเชื่อมต่อหรือมีความสัมพันธ์กันแบบโยงไปทั่ว
ส่วนของ service ก็ใช้งาน Entity และเรียกใช้งาน service อื่น ๆ ด้วยเช่นกัน
เป็นการเรียกใช้แบบเรียกผ่าน method ต่าง ๆ นั่นเอง

เมื่อเวลาผ่านไป เราพบว่าการดูแลรักษาและพัฒนายากมาก ๆ

เราจึงพยายามหาวิธีการแก้ไขปัญหา
วิธีการที่มักจะใช้คือ การแยกการทำงานออกมาเป็นส่วนย่อย ๆ
ซึ่งก็คิดง่าย ๆ คือ เรามี Entity และ Service อยู่แล้ว
ยกตัวอย่างเช่น
UserService, OrderService และ ProductService และอื่น ๆ อีกมากมาย

ดังนั้นเราจึงทำการแยก class/file ต่าง ๆ เหล่านี้ออกมาเป็น service เล็ก ๆ
แต่ service เหล่านั้นยังต้องเรียกใช้งาน service หรือ entity อื่น ๆ อีก
ดังนั้นจึงต้องเรียกใช้งาน
จากเดิมที่เป็นเรียกผ่าน method
ก็เปลี่ยนมาเป็นผ่าน network (remote call) เช่น HTTP protocol เป็นต้น
ซึ่งแบบนี้เราจะเรียกว่า Distributed Monolith
คำถามคือ มันดีกว่าเดิมอย่างไรนะ ?

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

และเราก็ทำแบบนี้ซ้ำแล้วซ้ำเล่า
แล้วก็บอกว่า ยิ่งทำยิ่งสร้างปัญหา
เอาวิธีการใด ๆ มาใช้ก็ไม่ได้หรอกนะ
ถ้าเรายังไม่ปรับไม่เปลี่ยนวิธีการคิด !!

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

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

• Pods โดยจะมี error status ต่าง ๆ มากมาย นอกเหนือจาก up/running
• Services สำหรับการ route traffic ไปยัง Pods
• Ingress สำหรับการ route traffic จากภายนอก cluster เข้ามา

โดย diagram เป็นดังนี้

จากหนังสือ Clean Architecture ในบทที่ 1
ว่าด้วยเรื่องของการออกแบบและ architecture
มีหลายเรื่องที่สะกิดใจและน่าสนใจ
จึงทำการสรุปไว้นิดหน่อย

โดยเป้าหมายหลักของหนังสือเล่มนี้คือ
ลดความสับสนหรือเข้าใจผิดเกี่ยวกับคำว่า design vs architecture
ถ้าอธิบายง่าย ๆ

• Design คือ low-level สำหรับการตัดสินใจต่าง ๆ เช่นโครงสร้างของระบบงานนั้น ๆ
• Architecture คือ high-level

อยากอ่านโดยละเอียดก็ไปดูในหนังสือเพิ่มเติมนะครับ

สิ่งที่น่าสนใจคือ

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

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

แสดงดังรูป ยิ่ง release ยิ่งทำให้ productivity ลดลง

แบบนี้ดีไหมนะ ?
ทีมพัฒนาทำงานกันหามรุ่งหามค่ำ แต่ผลที่ออกมากลับตรงกันข้าม
ส่งงานก็ไม่ทัน
ถึงทันก็ bug เยอะ

ส่วนในแง่ของการบริหาร ทำไมค่ามช้จ่ายสูงขึ้นเรื่อย ๆ นะ

ดังนั้นกลับมาดู architecture ของระบบเราหน่อยสิ ว่าเป็นอย่างไร ?

Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy.

The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.

จากที่พูดคุยกันเรื่องการออกแบบ service
ว่าแต่ละ service นั้น
มักจะมี coupling หรือผูกมัดกับ depedency อื่น ๆ ไม่ว่างทางใดก็ทางหนึ่ง
ดังนั้นเราควรพยายามลด coupling เหล่านั้นลง
จาก tight coupling มาเป็น loose หรือ no coupling ไปเลยจะยิ่งดี
มิเช่นนั้น อาจจะเกิด Distributed Monolith ขึ้นมาแทนก็ได้

ดังนั้นมาดูกันหน่อยว่า coupling ในการออกแบบ service มีเรื่องอะไรบ้าง ?

• Database coupling คือ ที่จัดเก็บข้อมูลจะ share กัน หรือจะแยก ซึ่งทั้งคู่ก็มีปัญหาของมันไป
• Communication coupling คือการติดต่อสื่อสารจะเป็นแบบ sync หรือ async หรือจะใช้แบบ pull/push ซึ่งบ่อยครั้งจะเจอแบบ sync ต่อกันไปเรื่อย ๆ คำถามคือ แยกออกมาทำไม มีปัญหาเยอะไหม ตรงนี้ต้องคิด ไม่ใช่ว่าไม่ดีนะ แต่ต้องใช้ให้เหมาะสม
• Code coupling คือ มีบางส่วนงานที่มี logic การทำงานเหมือนกัน เรามักจะเรียกว่า common code หรือ reuse code ดังนั้นทำเป็น library แล้ว share กันไปใช้งานในทุก ๆ service แบบนี้ดีไหมนะ ?
• Test Environment coupling คือชอบใช้ environment เดียวกัน deploy ที่เดียวกัน ทดสอบที่เดียวกับ database เดียวกัน ปัญหาตามมาอีกเพียบไหมนะ
• Domain coupling คือแยกกันตาม domain หรือการทำงานไปแล้ว แต่ก็ยังเรียกใช้งานกันข้าม domain คำถามคือ สิ่งที่ return กลับมา ยังเป็นข้อมูลที่ผูกติดกับ doamin นั้น ๆ ไหม ถ้าใช่มันส่งผลไหม เมื่อมีการเปลี่ยนแปลงจากภายใน ถ้าใช่ต้องรวังเรื่องของ encapsulation ของ data ให้ดี หรือ return กลับเท่าที่จำเป็นเท่านั้น

ทาง GitHub ได้ประกาศออกมากบทความ
Include diagrams in your Markdown files with Mermaid
ว่าสามารถเขียน diagram ด้วยรูปแบของ Mermaid
ในไฟล์ Markdown ได้แล้ว

โดยสามารถเขียน inline code ใน GitHub Repository ได้เลย
ยกตัวอย่าง

ผลที่ได้เป็นดังนี้

จากที่ทดสอบพบว่าใน Wiki และ Gist ยังใช้ไม่ได้ !!

ลองใช้งานกันดูครับ
ทำให้เราสามารถเขียนเอกสารอธิบายระบบงานได้ดีและสะดวกมากขึ้น

ปัญหาที่พบเจอบ่อย ๆ
มีบาง process ที่ run ค้างไว้ ทั้ง ๆ ที่ลบ process แม่มันไปแล้ว
โดยในแต่ละ OS ก็มีการดูและจัดการต่างกัน

พอดีไปเจอ project ที่ชื่อว่า FKILL cli
ช่วยแก้ไขปัญหานี้ได้

ทำการติดตั้งและใช้งานผ่าน NPM ได้เลย ดังนี้

หลังจากที่ทาง Elastic ปล่อย Elastic 8.0 ออกมา
แน่นอนว่าก็ update กันทั้ง stack ประกอบไปด้วย

• Elasticsearch
• Kibana
• Beat
• Logstash

โดยใน version นี้จะเน้นไปที่ performance ของการทำงาน
ลดการใช้ resource ทั้ง CPU, memory และ Dis ที่เก็บข้อมูล
รวมถึงความสามารถต่าง ๆ ที่มาใน Elasticsearch
และเพิ่มเติมคือเรื่องของ Machine Learning ที่อยู่ใน commercial version

ความสามารถใน Elasticsearch ที่เพิ่มหรือปรับปรุงเข้ามาในการค้นหา

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

• Date histogram
• Search aggregation
• Page caching
• Pre-filter search

อีกความสามารถที่เพิ่มเติมเข้ามาตั้งแต่ version 7 คือ Native vector search (Technical preview) ช่วยเรื่องของ relevance search ได้ดีและรวดเร็วขึ้น

โดยใน version 8 ได้ปรับปรุงและเติมเต็มการค้นหา
เพื่อเปิดโลกเข้าสู่ NLP (Natural Language Processing)

ทำการ Download มาใช้งานได้แล้ว Start with Elastic

คำถามที่เจอจากการปรับปรุงการทำงานของระบบที่พัฒนาด้วย Spring Boot
ว่าจะลดเวลาของการ start up และการใช้งาน memory ลงอย่างไรบ้าง ?

โดยแนวทางก็มีหลายอย่างทั้ง

• ลดจำนวน bean ของการ initial ตอน load ซึ่ง load เท่าที่จะใช้งาน
• เปลี่ยนไปใช้ GraalVM หรือ Spring Native ไปเลย
• เปลี่ยนจากทำงานแบบ request-response model มาเป็น Reactive เช่น WebFlux, Vert.x เป็นต้น
• เปลี่ยนมาใช้ JDK ตัวใหม่ ๆ
• เปลี่ยนภาษาเลยดีไหม ซึ่งก็ได้ทำ performance test เปรียบเทียบไปแล้ว

มีอีกวิธีที่น่าสนใจคือ เปลี่ยน JVM จาก Hotspot มาเป็น OpenJ9

โดยที่ OpenJ9 นั้นถูกพัฒนามาจาก community
ซึ่งตอนนี้อยู่ภายใต้ Eclipse foundation
มีเป้าหมายเพื่อปรับปรุง JVM
ให้ทำงานได้อย่างมีประสิทธิภาพมากกว่า HotSpot ของ Oracle
ทั้งความเร็วและการใช้ resource ต่าง ๆ
ช่วยให้ระบบที่พัฒนาเหมาะสมต่อการ deploy บนระบบ cloud มากยิ่งขึ้น

ในการใช้งานนั้นสามารถ Download ง่าย ๆ ได้จาก AdoptionOpenJDK

หรือจะใช้งานผ่าน Docker Image ได้เลย
ซึ่งผมเคยทำการสรุปไว้แล้วที่ มาใช้งาน OpenJ9 + Docker

แต่ก็ยังมีตัวอื่น ๆ ถูกพัฒนาเพิ่มเข้ามา เช่น SubstrateVM
เป็น internal project ที่อยู่ด้านหลังของ GraalVM อีกที
ที่ลดการใช้งาน memory ไปมากอีกด้วย

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

ปัญหาหนึ่งที่มักเจอมาก ๆ ในการพัฒนาระบบงานคือ
การเปลี่ยนแปลง schema หรือ โครงสร้างของข้อมูลที่ใช้แลกเปลี่ยนกัน
ทำให้เกิดปัญหาเรื่อง compatibility ของข้อมูล
บ่อยครั้งจะเกิด breaking change จากที่ตั้งใจหรือไม่ตั้งใจก็ตาม
โดยเครื่องมือที่ได้รับความนิยมในการจัดการเรื่องนี้คือ Apache Avro
ปล. ใครที่ใช้งาน Apache Kafka น่าจะรู้จักเป็นอย่างดี

จาก Schema registry ของ Confluent จะมี compatibility types ต่าง ๆ ของ schema ดังนี้

• BACKWARD
• BACKWARD_TRANSITIVE
• FORWARD
• FORWARD_TRANSITIVE
• FULL
• FULL_TRANSITIVE
• NONE

มาลองใช้งาน Apache Avro ในการจัดการจาก use case นี้กันดู

เริ่มต้นด้วย data model ของ Employee

เปลี่ยนจาก version 1 มาเป็น version 2 ดังนี้

โดยทำการออกแบบในรูปแบบของ Avro IDL (Interface Description Language)
ช่วยให้ออกแบบและเขียนตามการ coding ของภาษาต่าง ๆ ได้ง่ายนั่นเอง
รวมทั้งไม่ถนัดออกแบบในรูปแบบของ Avro Schema ที่เป็น JSON !!

เราสามารถทำการ generate file ของ Avro Schema ที่มีรูปแบบ JSON ได้ด้วย Avro tool

ตัวอย่างการใช้งาน Avro tool 1.10

จากนั้นทำการตรวจสอบหรือ validate ว่า schema ที่เราต้องการมัน compatible กันหรือไม่

ซึ่งตอบได้เลยว่า ไม่แน่นอน มี braking change เพียบ
ดังนั้นในการใช้งาน จะต้องมีขั้นตอนการเปลี่ยนแปลงเข้ามา
ยกตัวอย่างเช่น

• ถ้ามีการ remove field ควรกำหนดค่า default ให้ด้วย และเป็นค่าที่แจ้งว่าจะยกเลิก เช่น DEPRECATED เป็นต้น เพื่อให้ backward compatibility
• ถ้าเพิ่ม field เข้ามา ก็ต้องกำหนดค่า default เช่นกัน เพื่อให้ forward compatibility

จากตัวอย่างจะพบว่า
ต้องทำการเปลี่ยนจาก name ที่มีค่าเป็น string
มาเป็น name ที่มีชนิดเป็น record
หรือข้อมูลที่ประกอบไปด้วย firstname และ lastname
มันคือ การ ลบและเพิ่ม field นั่นเอง

ดังนั้นถ้าเราต้องการให้ Forward transitive แบบสวย ๆ จะได้

แต่เมื่อทำการแปลงมาเป็น Avro Schema ด้วย avro-tool 1.10 แล้วไม่ผ่าน !!

เจอ error แถมไปเจอว่าอยู่ใน PR 1562

สิ่งที่ต้องทำคือ ทำการ clone code จาก PR ดังกล่าวมา build เอง
จะได้เป็น version 1.12 ซึ่งแก้ไขแล้วนั่นเอง
ส่วน official ยังไม่มีนะ
ชีวิตจะเศร้า ๆ หน่อย

จากนั้นทำการ validate ง่าย ๆ ด้วยการเขียน test

หรือจะให้ง่ายขึ้นไปอีกด้วยการใช้งานผ่าน Avro Cli ไปก็ได้

จะเห็นว่า PASS คือ compatibility นั่นเอง
เพียงเท่านี้ก็ได้แนวทางของการตรวจสอบ Compatibility ของ Schema แบบง่าย ๆ แล้ว

ใน Elasticsearch 8 นั้น ถ้าใครลองทำการ download และมาติดตั้ง
จะพบว่ามีการ enable ระบบ security มาให้เลยโดย default
โดยในการ start ครั้งแรกแบบอัตโนมัติ

มีความสามารถดังนี้

• ในไฟล์ $ES_HOME/config/elasticsearch.yml เพิ่ม config เรื่อง security มาให้เลย
• ทำการสร้าง certificate และ key ให้ โดยอยู่ใน folder $ES_HOME/config/certs/
• สร้าง Password สำหรับเข้าใช้งานด้วย user=elastic
• สร้าง Enrollment token สำหรับการเข้าใช้งานผ่าน Kibana

ถ้าต้องการ re-generate password ของ user=elastic ใหม่

สามารถใช้คำสั่ง

สร้าง enrollment token ใหม่ ด้วยคำสั่ง

ส่วน config เกี่ยวกับ security ในไฟล์ $ES_HOME/config/elasticsearch.yml

เมื่อทำการ start Elasticsearch server ขึ้นมา

จะพบกับข้อมูล default เอาไว้ใช้งานดังนี้

ดังนั้นใครที่ใช้งาน Elasticsearch 8 แล้ว ก็ไม่ต้องตกใจไปนะครับ

เพิ่งกลับมา upgrade และใช้งาน Logstash อีกรอบ
พบว่า Elasticsearch output plugin มีการเปลี่ยนแปลงนิดหน่อย
ทั้งต้องเชื่อมต่อไปยัง Elasticsearch ที่เปิด security by default
ซึ่งการ configuration ใน output ก็ต้องเพิ่มอีก เช่น

• user/password
• ssl
• ssl verification mode
• cacert

รวมทั้งค่า default ต่าง ๆ ที่เปลี่ยนไป เช่น

• ชื่อ index ที่ขึ่นอยู่กับ ECS (Elasticsearch Common Schema)
• ถ้าไม่สนใจ ก็ต้องกำหนด index ไปเองเลยก็ได้

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

เป็นอีกเรื่องอาจจะกระทบ เมื่อทำการ upgrade มายัง Elastic 8 นั่นเอง

เนื่องด้วยเพิ่งเข้าไปดูและแก้ไขปัญหาของ Redis server
จึงทำการสรุปแนวทางการแก้ไว้นิดหน่อย

ฝั่งของ server ทำการ configuration ดังนี้

• กำหนด max memory เนื่องจากค่า default คือ unlimit ยิ่งเป็น redis แบบ replica/cluster ด้วยแล้วยิ่งต้องกำหนด เพราะว่าต้องเผื่อให้กับ output buffer การทำงานระหว่างเครื่อง และของ system อีกด้วย
• กำหนด max client เนื่องจากค่า default = 10,000
• กำหนดค่า tcp backlog กำหนดขนาดของ complete connection queue มีค่า default = 511 ซึ่งสามารถเพิ่มได้
• ถ้าใช้งาน replica แล้ว ให้กำหนดการเขียนเฉพาะใน master/primary server เท่านั้น ส่วนเครื่อง replica/slave กำหนดให้อ่านเท่านั้น slave-read-only yes
• ในระดับ OS ก็ต้องกำหนดด้วย ทั้ง disable virtual memory และ จำนวนของการเปิดอ่าน file (file descriptor limit)
• ปรับปรุง policy การทำ save snapshot ให้เหมาะสมกับการใช้งาน
• อย่าลืมกำหนดค่า slow log ด้วย ทั้ง slowlog-log-slower-than และ slowlog-max-len
• log ต่าง ๆ ของ redis สามารถให้พ่นออก syslog ได้เลย เพื่อให้ส่งไปยัง centralized log server ได้ง่าย ๆ กำหนดดังนี้ syslog-enabled yes

ฝั่งของ client

• อย่าลืมใช้ connection pool
• อย่าลืมใช้งาน pipelining เพื่อปรับปรุงการดึงข้อมูลให้เร็วขึ้น

ชุดคำสั่งที่น่าสนใจ ใน redis-cli

• redis-cli --bigkeys สำหรับดู key ที่มีขนาดใหญ่หรือ item เยอะ ๆ
• redis-cli --memkeys สำหรับดู key ที่มีใช้ memory เยอะ ๆ
• redis-cli MONITOR สำหรับดูการใช้งานคำสั่งต่าง ๆ แบบ realtime/stream
• redis-cli slowlog <size>

มีคำถามเกี่ยวกับ ความแตกต่างระหว่าง @Mock กับ @InjectMocks ใน Mockito
ว่าใช้งานเหมือนหรือต่างกันอย่างไร ?

ก่อนอื่นต้องทำความรู้จักกับ @InjectMocks ก่อน

เป็น annotation ที่เพิ่มเข้ามาใน Mockito ตั้งแต่ version 1.8.3
ตอนนี้ Mockito version 4.3.1
ใช้สำหรับการสร้าง object ของ class ที่จะทดสอบ
พร้อมทั้ง inject หรือส่ง dependency ต่าง ๆ เข้าไปยัง class ที่จะทดสอบแบบอัตโนมัติ
ทั้ง constructor, field หรือ setter injection ก็ตาม

ส่วน @Mock เป็นเพียงการสร้าง instance ของ dependency เท่านั้น

อ่านแล้วงง มาดูตัวอย่าง code ดีกว่า

จาก code ตัวอย่าง จะใช้งานง่ายขึ้น
และมี magic เข้ามา คือ การ inject dependency เข้าไปให้แบบอัตโนมัติ

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