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

• ให้ความสำคัญของ fast feedback และ คุณภาพที่สูง

แต่ที่เจอมาหลาย ๆ ครั้งมักจะเป็นภาพนี้ !!

มันคือการขับเคลื่อนการพัฒนาในรูปแบบต่าง ๆ

• เริ่มต้นจะเป็นการพัฒนาแบบ DDD (Deadline Driven Development) คือ มีความต้องการที่ไม่แน่ใจ แต่ที่ชัดคือวันส่งมอบ เน้นให้เสร็จ เอาปริมาณมาก่อน คุณภาพรองลงไป
• เมื่อพัฒนามาเรื่อย ๆ จนต้องส่งมอบงานในขั้นตอนต่าง ๆ จะพบว่า สิ่งที่บอกว่าเสร็จแล้ว มักจะไม่เสร็จจริง เมื่อเกิดปัญหาก็ตามแก้ไขไปเรื่อย ๆ มักจะเรียกว่า BDD (Bug Driven Development) ที่สำคัญแก้ bug 1 ตัว มักได้ bugใหม่มาอีกหลายตัว

มันจริงหรือเปล่านะ ?
ไม่น่าจริงหรอกนะ !!

จากการแบ่งปันเรื่อง Microservices design ที่ Skooldio มาบ้าง
คำถามที่น่าสนใจคือ ในทีม หรือ บริษัทนั้น มี software อะไรบ้าง
หรือถามลงไปในรายละเอียดเช่น

• มี service อะไรบ้าง
• แต่ละ service มีใครเป็นเจ้าของ รายละเอียดเช่น API spec เป็นอย่างไร มี relation กับส่วนใดบ้าง

ส่วนอื่น ๆ ก็เช่นกันทั้งระบบงานต่าง ๆ library ที่มี และ data pipeline ต่างๆ
มีรวมไว้ตรงกลาง เพื่อให้เข้าถึง หรือ ใช้งานง่าย ๆ
ไม่ต้องไปถามคนโน้นที คนนั้นที !!
อยากให้เป็น centralize system ได้ไหม
หนึ่งในเครื่องมือที่ใช้ในการจัดการสิ่งเหล่านี้ก็คือ Backstage นั่นเอง

แนวคิดง่าย ๆ ของ Backstage คือ

ทำการสร้าง catalog ขึ้นมาด้วยรูปแบบของไฟล์ YAML
ซึ่งจัดเก็บไว้กับ code ของเราใน version control ไปเลย
จากนั้นทำการสร้าง หรือ register catalog ต่าง ๆ ที่สร้างขึ้นมาไว้ใน Backstage ต่อไป
แสดงดังรูป

โดยใน software catalog นั้น ประกอบไปด้วย entity หลายแบบที่เชื่อมต่อกัน เช่น

• Domain
• System
• API
• Component
• Resource

แสดงดังรูป

เรื่องของ Technical Document ก็มีให้เขียนเช่นกัน

เพื่อเป็นศูนย์กลางของความรู้ในแต่ละ entity อีกด้วย
ซึ่งน่าจะช่วยให้ทีมรู้และเข้าใจการทำงานของระบบงานอีกด้วย
แน่นอนว่าก็เก็บไว้ใน version control ที่เดียวกับ code
น่าจะช่วยให้เปลี่ยนไปตามความจริงไหมนะ !!
สามารถเขียนในรูปแบบ markdown ของ backstage
แสดงนำมาแสดงในรูปแบบของ HTML ต่อไป

ยังไม่พอนะครับ ถ้าเรามีระบบที่ deploy บน Kubernetes cluster แล้ว
ทาง Backstage ก็มี Kubernetes plugin ให้ใช้งาน
และยังมี integration plugins ให้อีกเพียบ

สุดท้ายจะสามารถสร้าง Backstage Software Template ได้อีกด้วย
เพื่อลดการทำซ้ำลงไป

ลองใช้งานดูครับ
น่าจะช่วยเรื่องของการทำงานของทีมต่าง ๆ ได้ง่ายขึ้น

Backstage ได้เตรียมตัวอย่างของไฟล์ YAML ของ entity ต่าง ๆ ไว้ให้ลองศึกษากัน

• Example
• ใครยังมองถาพไม่ออก ลองดู demo ได้ครับ

ใครสนใจลองติดตั้ง และ start server บนเครื่องเราก่อนได้ Let's start

หลังจากอ่านบทความเรื่อง The Value of Socially Driven Architecture
ว่าด้วยเรื่องของ software architecture กับโครงสร้างขององค์กร
พบว่าบ่อยครั้งที่สิ่งที่ดี ๆ จากที่อ่าน แต่เมื่อนำมาใช้งานกลับได้ดี
หรือไม่ได้แก้ไข หรือ ปรับปรุงระบบให้ดีขึ้นเลย
ดังนั้นมาดูกันหน่อยว่าเพราะอะไร ?

สิ่งที่น่าสนใจคือ Architecture ของระบบนั้น
มันไม่ใช่ของใครคนใดคนหนึ่ง
มิเช่นนั้น solution หรือ architecture ที่ได้ จะเป็นสิ่งที่เรัยกว่า Zombie solution !!

แต่มันคือเรื่องของ social หรือ สังคมในองค์กรนั้น ๆ
โดยจะส่งผลออกมาในระบบงานที่พัฒนาออกมานั่นเอง
บ่อยครั้งจะดูได้จากโครงสร้างขององค์กรจากระบบของ HR ได้เลย

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

หรืออาจจะเป็น

และบ่อยครั้งการ transition หรือ handover งานระหว่างทีม
ส่งผลทำให้ flow การทำงานแย่ลงไป ต้องระวังมาก ๆ
ดังนั้นทีมควรมีหน้าที่รับผิดชอบเรื่อง

• การทดสอบ
• การส่งมอบ
• การจัดการ และ สนับสนุนเรื่องต่าง ๆ หลังส่งมอบ

หัวใจสำคัญของการทำงานคือ การมีส่วนร่วมของ domain ต่าง ๆ ที่เกี่ยวข้อง

เพื่อให้คนต่าง ๆ เข้าใจความต้องการ และ ข้อจำกัดต่าง ๆ ตั้งแต่เริ่มต้น
ดังนั้นการทำงานเชิง Value-Driven Design นั้น ประกอบไปด้วย

• การออกแบบโครงสร้างขององค์กร ให้เอื้อต่อการมีส่วนร่วมของการออกแบบ และ หาแนวทางการแก้ไขปัญหา
• โดยต้องทำควบคู่กันไปทั้งโครงสร้างองค์กร และ ระบบงาน
• มีระบบที่ fast feedback loop จากระบบที่ทำงานจริง ๆ เพื่อนำมาใช้ในการปรับปรุงระบบงาน ดัวนั้นเรื่องของ architecture มันคือสิ่งที่มีชีวิต
• การทำงานต่าง ๆ ต้องมี time-box เสมอ ไม่ใช่ทำไปเรื่อย ๆ
• ว่าด้วยเรื่องของ team-first เป็นการตัดสินใจต่าง ๆ ร่วมกัน ไม่ใช่เพียงคนใดคนหนึ่งเท่านั้น

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

น่าสนใจมาก ๆ

จากการแบ่งปันเรื่องการทดสอบระบบงานด้วย Playwright นั้น
พบว่า update version เป็น 1.42.0 แล้ว !! (บ่อยเหลือเกิน)
ดังนั้นมาดูความสามารถใหม่ ๆ กันดู
จะเป็นการปรับปรุงมากกว่า

เรื่องแรกคือ การใช้ tag ใน test

เพื่อใช้ในการแบ่งกลุ่มของ test
โดยปกติจะใส่ในชื่อ test เป็นเลย เช่น @e2e, @fast และ @feature เป็นต้น
แต่ใน version นี้เปลี่ยนไปแล้ว
ทำการแยก tag ออกมาจากชื่อ test case เพื่อให้จัดการง่ายขึ้น

เรื่องต่อมา เพิ่มรู้ว่าใส่ annotation ได้ด้วย ช่วยได้เยอะมาก ๆ

รวมทั้งสามารถ skip test แบบมีเงื่อนไขได้ เช่น

มาใช้งาน Playwright ในการทดสอบระบบงานกัน
อย่าลืม update กันละ

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

เรื่องแรกคือ Sharing หรือ Reuse มากเกินไป ทำให้เกิดมะเร็ง service

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

ปัญหาเกิดจากเรื่องขอบเขตของหน้าที่รับผิดชอบของ service ไม่ชัดเจน
อาจจะมาจากคำว่า ขอเพิ่มอีกนิดหน่อยได้ไหม !!
หรืออาจจะบอกว่า เรามีเวลาไม่มาก ต้องรีบแล้ว
เลยทำ ๆ ให้เสร็จไปก่อน แล้วค่อยมาแก้ไขทีหลัง (Develop + Test + Deploy)
จะพบว่า ไม่มีการกลับมาแก้ไขเลย (Later === Never)

เรื่องที่สอง แยก service เยอะมาก ๆ ทำให้เกิด overhead ของการติดต่อสื่อสารระหว่าง service

เป็นเรื่องที่เจอเยอะมาก ๆ คือ แบ่งมากจนเกินไป
อะไรที่ต้องทำงานด้วสยกันเสมอ ก็ดันไปแยก (Low cohesion)
หรือ แยกไว้เผื่ออนาคต แต่ว่าปัจจุบันยังไม่รอดเลย
ทำให้เกิดปัญหาตามมามากมาย
เช่น response time สูงขึ้นมา, network ใช้งานเยอะเกินไป เป็นต้น
หนักกว่านั้น เมื่อบาง service มีปัญหาแล้ว
ทำให้ระบบโดยรวมมีปัญหาไปด้วยหมดเลย !! (Cascade failure)
แถมไม่เคยวางแผนเรื่องของการจัดการเมื่อเกิดปัญหาไว้อีกด้วย (Plan for failure)

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

Decomposition != Decoupling นะ

เกิด Distributed monolith ไหมนะ ?

เรื่องที่สามคือ ข้อมูลกระจายหลายที่ เรื่องความถูกต้องก็ขาดหายไป

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

เรื่องที่สี่ คือ ระบบ monitoring หรือ observability ของ service ที่ไม่ดี หรือ เพียงพอ

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

ดังนั้นเรื่อง observability สำคัญมาก ๆ

• Alert system
• Application metric
• Distributed tracing
• Centralized logging
• Exception tracking

น่าสนใจว่า เราแก้ไขปัญหา หรือ สร้างปัญหาขึ้นมา
เรื่องนี้สำคัญมาก ๆ

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

ถ้าเป็นการทำงานปกติทั่วไป มักจะเป็นดังนี้

• ทำการทดสอบใน pipeline ของ CI/CD จะเห็นผลการทดสอบ และ รายละเอียดทันที
• ทำการ import เข้า SonarQube ก็เห็นข้อมูลทั้งหมดเช่นกัน

แต่สิ่งที่อยากได้นั้น แตกต่างกันไป
โดยสิ่งที่ผมต้องการคือ

• เมื่อใคร ๆ ก็ตามทดสอบแล้ว ให้ส่งผลการทดสอบมาตรงกลาง โดยอ่านผลการทดสอบจากไฟล์รูปแบบต่าง ๆ เช่น junit และ json เป็นต้น
• ทำการแสดงผลการทดสอบบน Grafana แบบสวย ๆ
• สามารถทำการ alert ได้เมื่อเจอผลการทำงานที่สนใจ เช่น Prometheus alert manager เป็นต้น

เมื่อได้ requirement ที่ชัดเจนแล้ว ก็มีลองสร้างแบบง่าย ๆ ขึ้นมากัน

ขั้นตอนที่ 1 ทำการอ่านข้อมูลผลการทดสอบจากไฟล์ xml ซึ่งเป็น junit format

ตรงนี้สบายหน่อย มี library ของแต่ละภาษาให้ใช้งานเลย
หรือเขียนเองแบบง่าย ๆ
เพราะว่าเป็นไฟล์ XML ที่เป็นมาตรฐาน
แต่ชอบ json มากกว่า

ขั้นตอนที่ 2 จะจัดเก็บข้อมูลอย่างไร รูปแบบไหนดี ?

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

• จะใช้งาน OpenTelemetry สำหรับรูปแบบของข้อมูล metric
• ทำการส่งข้อมูลไปยัง Otel Collector
• เก็บข้อมูลใน Prometheus ​โดยให้ไปดึงข้อมูลมากจาก Otel Collector
• แสดงผลข้อมูลจาก Prometheus ใน Grafana dashboard

แสดงการทำงานดังรูป

โครงสร้างการทำงานของ Otel Collector เป็นดังรูป

ขั้นตอนที่สาม มาลองเขียน code แบบง่าย ๆ กันด้วย

เลือกใช้ภาษา Go ในการพัฒนา เพื่อสร้าง metric และส่งข้อมูลไปยัง Otel Collector
มาดูตัวอย่างของการสร้าง metric แบบง่าย ๆ

ในส่วนของ Otel Collector นั้นก็ทำการ config ง่าย ๆ
เพื่อให้ export ออกไปในรูปแบบของ prometheus ได้เลย (Prometheus exporter)

ขั้นตอนสุดท้าย ทำการสร้าง Prometheus และ Garana

จะได้ข้อมูลดังนี้

ค้นหา metric ใน Prometheus

ทำการสร้าง Grafana dashboard เพื่อแสดงผลการทดสอบแบบง่าย ๆ

เพียงแค่นี้ก็เก็บข้อมูล และ แสดงผลข้อมูลการทดสอบ แบบง่าย ๆ ได้แล้ว
ขอให้สนุกกับกับการ coding ครับ

บ่าย ๆ เห็นหนังสือน่าสนใจแจ้งมาทาง email
คือ Head First Software Architecture: A Learner's Guide to Architectural Thinking
เป็นหนังสือเกี่ยวกับพื้นฐานของ Software Architecture นั่นเอง
เขียนมาสำหรับนักพัฒนา software
ที่ต้องการเพิ่มความรู้ด้านการออกแบบและว่าง architecture ที่ดีของระบบ

"Software architecture is fundamental to the success of your system"

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

• ความรู้พื้นฐานของ Software Architecture ว่ามีความสำคัญอย่างไร
• มุมมองต่าง ๆ ของ Software Architecture เช่น คุณสมบัติต่าง ๆ ที่จำเป็น เช่น performance, scalability, testability และ availability เป็นต้น
• การตัดสินใจต่าง ๆ เพราะว่ามันมีทั้งข้อดีและข้อเสีย การแยกส่วนการทำงานต่าง ๆ รวมถึงการกำหนดรูปแบบของระบบงาน
• ควรมองถึงการแก้ไขปัญหาและการจัดการด้วยเสมอ เช่น business value, technical และ cost of operation

• แยกอธิบายชัดเจนเกี่ยวกับ architecture, design, relationship และ code รวมทั้งรูปแบบต่าง ๆ ของ architecture
• ใน architecture รูปแบบต่าง ๆ มีการยกตัวอย่าง อธิบายตามรูปแบบของ Head First series
• มีการพูดถึง Strategic design vs Tactical design ที่อยู่ใน Domain-Driven Design
• บ่อยครั้งที่มักจะเหิด over-engineering ซึ่งต้องระวังอย่างมาก
• อธิบายเรื่องของ Architectural Decision Record (ADR) สำหรับการบันทึกทุก ๆ การตัดสินใจ ว่ามีเหตุผลอะไรบ้าง มีข้อจำกัดอะไรบ้าง เพื่อให้มีความเข้าใจมากยิ่งขึ้น

ตัวอย่างของการออกแบบส่วนต่าง ๆ ของระบบ

ลงไปจนถึงโครงสร้างของ code

แล้วก็ลงไปจนถึงความสัมพันธ์ต่าง ๆ ในเชิง code

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

ยังมีหัวข้ออื่น ๆ ที่น่าสนใจ เช่น

• Microservices
• Event-Driven Architecture (EDA)

ลองหามาอ่านกันดูครับ อ่านสนุกเพลินมาก ๆ ครับ
เป็นอีกหนึ่งความรู้ที่น่าสนใจมาก ๆ

หลังจากที่ facebook ล่มไปนั้น
ก็ไปเจอหน้า login ของ facebook ที่ไม่ได้เห็นนานมาก ๆ
เลยได้เห็นว่า ใน html tag นั้นมีการใส่ data-testid เข้ามาเป็น attribute หนึ่งด้วย
ซึ่งถ้าในแง่ของการทดสอบ UI test นั้น
มันคือหนึ่งในแนวทาง ในการเข้าถึง element แบบไม่ผูกมัดกับ UI มากนัก
ซึ่งช่วยลดการพังง่ายของการทดสอบนั่นเอง

โดยถ้าอ้างอิงจาก Testing Guilde Principles นั้น

จะมีการจัดการลำดับความสำคัญของการเข้าถึง element ต่าง ๆ ของ UI ไว้ดังนี้

• Queries Accessible to Everyone เช่นพวก getByRole ตาม web accessibility
• Semantic Queries เป็นการเข้าถึงตามมาตรฐานของ HTML5 และ ARIA compliant selectors
• Test IDs ซึ่งจาก guilde นั้น แนะนำให้ใช้เมื่อ 2 ข้อแรกไม่สามารถใช้งาน

แต่ในการใช้งานหลัก ๆ ที่ผ่านมานั้น
ผมมักจะนิยมใช้ Test IDs เป็นหลัก
เพราะว่า วางแผนได้ง่าย และ ไม่ผูกมัดกับการพัฒนาฝั่ง UI มากไป
โดยพวกเครื่องมือต่าง ๆ ก็สนับสนุนทั้ง cypress และ playwright เป็นต้น

แต่ก็ลองศึกษาและลองใช้งานเพิ่มเติมกันดู
ขอให้สนุกกับการทดสอบ

ใน Spring Boot 3.2 นั้นมี RestClient ออกมาให้ใช้งาน
สำหรับเรียนกใช้งาน external service ผ่าน HTTP protocol
โดยก่อนหน้านี้น่าจะเคยใช้งาน

• RestTemplate สำหรับ synchronous call
• WebClient สำหรับ Spring WebFlux หรือการทำงานแบบ asynchronous และ non-blocking I/O

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

RestClient นั้นจะถูกสร้างมาโดยทำงานอยู่บน WebClient
ซึ่งสามารถใช้ทดแทนทั้ง RestTemplate และ WebClient ได้เลย ไม่ต้องแยกกันอีกต่อไป
รวมทั้งยังช่วยลด code ที่ไม่จำเป็นต่อการใช้งานใน RestTemplate ออกไป

ตัวอย่าง code

ส่วนการสร้าง RestClient นั้นทำได้ดังนี้

ลองใช้งานกันดูครับ
สำหรับ Spring Boot 3.2
ขอให้สนุกกับการ coding

เพิ่งเห็นข่าวของ Bruno เป็นเครื่องมือสำหรับทดสอบ REST API หรือ API Client
ที่เหมือนกับ Postman และ Insomnia หรือจะพวก REST Client ต่าง ๆ นั่นเอง
โดยที่ Bruno นั้นจะเน้นที่

• Offline-first ไม่มี sync ไปยัง cloud system นั่นคือเป็น file system นั่นเอง
• ทำงานเร็ว
• ทำงานร่วมกับ Git โดย default
• เป็น open-source

ตอนนี้มี Golden Edition ที่เสียเงินด้วยนะ ลองไปดูกัน

ส่วนผมจะลองใช้งาน Opensource Edition ดู
มาเริ่มกันเลย

เริ่มที่ไป Download และติดตั้งได้เลยง่าย ๆ ไม่ต้องอธิบาย
หน้าตาเป็นดังนี้

จะเห็นได้ว่ามีการ Import collection ด้วย ซึ่งทำการ import มาจาก

• Bruno เอง ก็ต้องได้สิ
• Postman
• Insomnia
• OpenAPI version 3

มาลองทำการสร้าง Collection ใหม่กันดู

ทำการตั้งชื่อ และ ที่จัดเก็บ collection ให้เรียบร้อย
จากนั้นทำการสร้าง Request ใหม่ ยกตัวอย่างดังรูป

สนับสนุนทั้ง HTTP และ GraphQL หรือ ใช้ผ่าน cURL ได้ด้วย
ถ้า GRPC, Websocket, SocketIO, MQTT ต้องเป็น Golden edition นะ !!

ลองทำการสร้าง Request และ ทดสอบได้เช่นเดียวกันกับ Postman

สามารถทำการทดสอบ Request ได้เป็นปกติ ไม่ยากเท่าไร
อาจจะต้องศึกษา Testing และ Assertion เพิ่มนิดหน่อย
รวมทั้งยังมีส่วนของ variable และ script ที่ดีมาก ๆ
สำหรับใครที่ของเขียน code ด้วย JavaScript จะชอบมาก ๆ
เนื่องจาก custom ได้เยอะและง่ายดี เมื่อเทียบกับ Postman ที่ยากหน่อย
น่าจะเพราะว่า เป้าหมายของเครื่องมือมากกว่า
โดยในส่วนของ Script มีทั้ง pre และ post response ให้เลย
อีกทั้งมีส่วนของ assert แยกออกมาจาก test
ซึ่งช่วยให้ง่ายต่อการตรวจสอบ response แบบไม่ต้องเขียน code
แต่แอบ technical หน่อยนะครับ

ต่อมาลองไปดูต่อว่าไฟล์ที่จัดเก็บจะเป็นนามสกุล Bru

โดย Bru จะเป็นรูปแบบของไฟล์ที่กำหนดจาก Bruno นั่นเอง
จะเป็นของแต่ละ request
ตัวอย่างเป็นดังนี้

และยังสามารถ run collection/request ผ่าน command-line ได้อีกด้วย

ด้วยเครื่องมือที่ชื่อว่า Bruno-cli
ทำการติดตั้งและใช้งานได้เลย ดังนี้

มีความสามารถอื่น ๆ อีกเพียบ เช่น

• การใช้งาน environment variable
• ทำการสร้าง test report ด้วย JSON และ JUNIT ได้

มี Extension ใน VS Code ให้ด้วยนะ

อีกทั้งมีความสามารถที่น่าสนใจที่ยังไม่ได้ใช้งาน เช่น

• Secret management
• การเขียน Script

เป็นเครื่องมือที่ครบมาก ๆ
มาลองใช้งานกันดูครับ

หลาย ๆ คนน่าจะเคยใช้เครื่องมือในการจัด format ของ code ให้ดี และ เหมือนกัน
ด้วยเครื่องมือต่าง ๆ เช่น Pretier และ ESLint เป็นต้น
แต่ครั้งนี้เห็นใน Hacker News พูดถึง Shittier
เป็นเครื่องมือที่ตรงกันข้ามเลย
นั่นคือ ช่วยจัด format ให้อ่านยาก มั่วเข้าไว้

ปล. ขำ ๆ นะครับ อย่านำมาใช้งานจริงละครับ !!

แถมมีคนเข้ามาขอ feature อื่น ๆ อีกเยอะเลย เช่น

• Random space และ tab
• เพิ่ม trailing space ให้
• ใช้ indentation แบบหลากหลาย
• ใส่ {} ให้กับ code ที่เป็น block
• ทำการ random เพื่อใส่ suffix ในชื่อ class
• รูปแบบการตั้งชื่อแบบรวมกันทั้ง camel case, snack case เป็นต้น
• ทำการเพิ่ม comment แบบสุ่ม และ ไม่ตรงกับ code

ยังไม่พอ มีคนทำ Spaghettify ขึ้นมาอีก
แถมมี extension ใน VS Code อีกด้วย
ลองหามาเล่นแบบขำ ๆ กันดูได้นะ

วันว่าง ๆ ลองเล่นกันดูครับ แก้เบื่อไปได้เยอะมาก ๆ
อย่าลืมไปเปิด PR ด้วยนะ !!

เพิ่มไปอีกกับการเขียน Unmaintainable code !!

เห็นมีแนะนำ JSON Crack ใน timeline
เป็น editor สำหรับการการแสดงผล JSON เป็นรูปแบบสวย ๆ และ เข้าใจง่าย
เลยลองใช้งานกันดูหน่อย
โดยสามารถใช้งานได้ทั้งผ่านระบบของเขาเลย
และสามารถจ่ายเงินเพื่อเพิ่มความสามารถได้
หรือจะใช้งานด้วยการ clone code มา run เองก็ได้เช่นกัน

โดยผมเลือกใช้วิธีการ clone มาจาก GitHub

ทำการ build ผ่าน Docker ก็เจอปัญหาเลย
เนื่องจาก Dockerfile ที่ให้มา ไม่มี pnpm อีก
เลยแก้ไข และ ส่ง PR ไปยังต้นทางนิดหน่อย

จากนั้นทำการ run พบว่าถ้า JSON มีขนาดใหญ่จะใช้ไม่ได้
ต้องไปซื้อแบบ premium ขึ้นมาแบบนี้

เลยแก้ไข code ในไฟล์ src/store/useUser.ts
โดยเปลี่ยนค่าของ premium : true ดังนี้

ผลการทำงานเป็นดังนี้ มี 5,000 items

ลองใช้งานกันดูครับ
ใช้ memory เยอะจริง ๆ

OpenTelemetry นั้นเป็น project ที่ได้รับความนิยมขึ้นมา
จากเรื่องของ Distributed tracing และยังขยายเป็นเรื่อง metric กับ log ด้วย
โดยที่ตัวมันเองประกอบไปด้วยส่วนการทำงานต่าง ๆ เช่น

• Instrument
• Collector
• Exporter

ในฝั่งของ Grafana ก็มี LGTM stack
แน่นอนว่าต้องสนับสนุน OpenTelemetry อย่างแน่นอน
และเพื่อให้ง่ายต่อการใช้งาน ทาง Grafana จึงได้สร้าง Docker image ออกมา
ในชื่อ grafana/otel-lgtm
ดังนั้นมาลองใช้งานกัน

โดยเป้าหมายของ image ตัวนี้คือ
ใช้งานการ demo, development และ testing environment เท่านั้น

ใน image ตัวนี้ประกอบไปด้วย

• OpenTelemetry collector สำหรับการรับข้อมูลเข้ามาผ่าน port 4317 คือ gRPC และ 4318 คือ HTTP
• ทำการ forward ข้อมูลแต่ละชนิดไปยังปลายทางของ exporter ต่าง ๆ
• Log ส่งไปยัง Loki
• Metric ส่งไปยัง Prometheus
• Tracing ส่งไปยัง Tempo
• ทำการดูข้อมูลต่าง ๆ ผ่าน dashboard ของ Grafana ด้วย port 3000
• ในการดึงข้อมูลก็ต้องเรียนรู้ PromQL, TraceQL และ LogQL กันด้วย

เป็นการ configuration พื้นฐานที่ไม่ต้องมาทำเองอีกแล้ว
ก็สบายขึ้นเยอะ

มาลองใช้งานกันดู ผ่าน docker compose ดีกว่า

ทำการ start กันหน่อย
Image ขนาด 1.4 GB กันเลย

จากนั้นก็ยิงข้อมูลเข้ามาง่าย ๆ แล้ว
ลองใช้งานกันดูครับ

Reference Websites

• An OpenTelemetry backend in a Docker image: Introducing grafana/otel-lgtm

ใน PostgreSQL 16 มีความสามารถใหม่ ๆ และการปรับปรุงที่เยอะเลย
ดังนั้นจึงทำการสรุปไว้นิดหน่อย
มีทั้งความสามารถทางด้วย development และ operation
มาดูกันว่ามีอะไรบ้าง ?

ในฝั่งของ Development

• Parallel joins ซึ่งปกติจะทำการบน worker เดียว ทำให้เกิดปัญหาคอขวดและประสิทธิภาพที่แย่ เมื่อ database มีขนาดใหญ่ขึ้น ดังนั้นจึงทำการเพิ่มเรื่องการ join แบบ distributed และ parallel เข้ามา
• สนับสนุน FULL OUTER JOINS แล้ว
• เพิ่ม function สำหรับการทำงานทั้ง SQL/JSON มาให้เลย เช่น json_array() และ  json_object() ช่วยให้ทำงานกับข้อมูลทั้ง SQL และ JSON ร่วมกันได้ ช่วยให้การทำงานสะดวกมากยิ่งขึ้น
• เพิ่ม Incremental sort เข้ามา ทำให้การดึงข้อมูล และ เรียงข้อมูลรวดเร็วขึ้น (เริ่มมีมาให้ลองใช้ตั้งแต่ verion 13)
• ทำการ custom collation rules ได้ ช่วยให้เรา custom ข้อมูล เพื่อให้ทำการเรียงลำดับตามแต่ละภาษาได้

ในฝั่งของ Operation

• เพิ่ม option load_balance_hosts เข้ามา สำหรับกระจาย load ไปยังเครื่องต่าง ๆ ได้
• ทำ Logical Replication ได้จากเครื่องที่ standby ไปยัง server อื่น ๆ ได้เลย ซึ่งลด workload ลงไปได้เยอะ
• การ monitor database ได้เพิ่ม pg_stat_io สำหรับดูการใช้งาน I/O เข้ามา และปรับปรุง pg_stat_all_tables สำหรับดูการใช้งานของแต่ละ table ใน database
• เพิ่ม GENERIC_PLAN เข้ามาสำหรับการ analyze ชุดคำสั่ง SQL ให้รับ parameter ได้
• เรื่อง security เพิ่ม require_auth เข้ามาสำหรับ client connection เพื่อเปิดการใช้งาน (Simple Authentication Secure Layer) สำหรับ non SSL และ SCRAM-SHA-256 authentication modes

ดูเพิ่มเติมได้ที่ Release Note PostgreSQL 16
ลอง Download มาใช้งานกันดูครับ

Problem

จาก course API First development นั้น มีคำถามดังนี้
มี JSON Schema สำหรับใน validate ข้อมูลในรูปแบบ JSON แล้ว
ต้องการสร้าง test data จาก JSON Schema ได้หรือไม่
เพื่อให้ในการสร้าง mock data และ data test ของระบบงาน

Solutions

จากที่ทำมานั้นมีหลายวิธีการมาก ๆ โดยวิธีการที่แนะนำ
เป็นวิธีการง่าย ๆ ดังนี้

วิธีแรก ใช้ผ่าน UI เลย คือ JSON Schema Faker

วิธีต่อมา คือ การเขียน code ซึ่งยังใช้ json-schema-faker เช่นเดิม

ทำการ run ได้ผลที่ต้องการแล้ว

วิธีที่สาม ไหน ๆ ก็ใช้งาน Postman กันแล้ว ก็จัดหน่อย

โดยในการสร้าง Collection นั้น จะมี Generate fake test data ให้ใช้
ลองใช้งานกันดูนะครับ ง่ายจริง ๆ

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

เพิ่งเห็นข่าวที่ทาง Microsoft ปล่อย Garnet 1.0 ออกมา
ซึ่งมีแนวทางการใช้งานเหมือนกับ Redis ที่เพิ่งเปลี่ยน licence การใช้งานไป
โดยที่พัฒนาบน Redis serialization protocol (RESP) ของ Redis
เป็น open source 100%
และมี feature เป็น subset ของ Redis แถวเร็วกว่าด้วย
ในปัจจุบันยังไม่เทียบเท่า แต่ก็เพิ่มเรื่อย ๆ
ยังชวนให้นักพัฒนาเข้ามาร่วม contribute ด้วย
ดูเพิ่มเติมได้ที่ API compatability

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

Garnet ยังคงสนับสนุน data structure ที่หลายหลายเช่นเดิม

• String
• List/Set
• Hash
• SortedSet
• Geolocation
• Pub/Sub

ในส่วนของการ scale มาพร้อมกับ cluster, replication และ sharding data

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

ขั้นตอนการติดตั้งจาก source code

ในส่วนการ config นั้น
สามารถทำผ่านไฟล์ garnet.conf หรือ redis.conf ได้เลย

ต่อมาลองเขียน code เพื่อใช้งาน Garnet server

โดยใช้งานผ่าน Go-redis library สำหรับภาษา go
ตัวอย่าง code เป็นดังนี้

• ทำการ connect ผ่าน port=3278
• ใช้งานผ่าน set/get operation ของ string แบบปกติ

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

Reference websites

• Introducing Garnet – an open-source, next-generation, faster cache-store for accelerating applications and services

วันนี้มีโอกาสไปแบ่งปันประสบการณ์การใช้งานโปรแกรม Postman
ใช้สำหรับการทดสอบระบบงานพวก REST API ผ่าน HTTP protocol
โดยใช้ชื่อว่า Postman in the Right Way ใน 1 วัน
เป็นคำแนะนำสำหรับการใช้งานที่คิดว่า น่าจะมีประโยชน์
มาจากประสบการณ์ใช้งานที่พอมีมาบ้าง

มีเป้าหมายว่า เครื่องมือถูกสร้างมาเพื่อลดงาน มิใช่เพิ่มงาน !!

สิ่งที่แบ่งปันประกอบไปด้วยเรื่องต่าง ๆ ดังนี้

เริ่มด้วยขั้นตอนการพัฒนาระบบ API เช่น REST API เป็นดังนี้

• ทำการออกแบบ API Specification ในรูปแบบของเอกสารต่าง ๆ เช่น spreadsheeet เป็นต้น
• ทำการประชุมเพื่ออธิบาย
• ทำการพัฒนา API
• ทำการ generate API document จากการพัฒนา เช่น Swagger หรือ OpenAPI ออกมา โดยเอกสารตัวนี้ใช้ทำอะไร ใครใช้บ้าง !!
• ทำการทดสอบ API ด้วยเครื่องมือต่าง ๆ เช่น Postman เป็นต้น
• มีการแนะนำ Bruno ให้ด้วย เผื่อจะสนใจ

คำถามที่น่าสนใจคือ มีเอกสารเรื่องเดียวกันดี่ชุด กี่ที่ กี่คนดูแล
เมื่อมีการแก้ไขในส่วนใดส่วนหนึ่งแล้ว
เอกสารทุก ๆ ตัวที่สร้างขึ้นมา ถูกแก้ไข หรือ เปลี่ยนแปลงตามไหม ?
ถ้าไม่ นั่นคือ มีปัญหาแน่นอน !!

หนึ่งแนวทางในการแก้ไขปัญหา ที่แนะนำคือ ทำใน Postman กันไปเลย

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

• ทำการออกแบบใน Postman ไปเลย สร้าง workspace -> collection -> request ต่าง ๆ ไป
• ทำการสร้าง folder ในแต่ละ collection มากเกินไปไหม ?
• ในแต่ละ request ทำการสร้าง response แต่ละแบบด้วยการเพิ่ม example เข้ามา
• ในแต่ละ collection และ request สามารถเขียน API documentation ได้เลย ในรูปแบบ Markdown นั่นเอง
• ต่อมาในแต่ละ request สามารถเขียน test case ที่ต้องการตรวจสอบได้เลย
• อีกทั้งเมื่อทำการออกแบบเรียนร้อยแล้ว สามารถสร้าง Mock Server ขึ้นมาจาก collection ที่ทำการออกแบบได้เลย
• ดังนั้น เราจะได้ทั้ง API specification, API documentation, Test case และ Mock Server หลังการคุย หรือ ประชุมกันเรียบร้อย โดยที่ยังไม่ได้ทำการเขียน code ใด ๆ เลย

จากนั้นเราสามารถทำการ convert จาก Postman's collection ไปยังเอกสารต่าง ๆ ได้อีกด้วย

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

• ไปเป็น Swagger หรือ OpenAPI ได้เลย มีคำแนะนำเกี่ยวกับ AsyncAPI ด้วย
• ไปเป็น Apache JMeter และ K6 ได้เลย สำหรับการทำ performance testing ต่อไป

ต่อมาทำการแนะนำความสามารถต่าง ๆ ในการทดสอบด้วย Postman

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

• การเขียน Test case ของแต่ละ request ซึ่งมีทั้ง snippet code และ PostBot ให้ใช้งาน
• ในการเขียน test case จะเน้นในเรื่องของการตรวจสอบ response ในรูปแบบ JSON ด้วย JSON Schema
• จากนั้นเราสามารถ generate data test จาก JSON Schema ได้อีกด้วย
• ต่อมาสิ่งที่แนะนำเพิ่มเติมคือการเขียน script ใน pre-request script ด้วย สำหรับช่วยในการ reuse การทำงานในการทดสอบ ที่มักจะเกิดจากการ duplicate request ขึ้นมา
• การใช้งาน environment ใน Postman ทั้ง Global, collection และ request นั้น ๆ
• การใช้งาน data ในการทดสอบของ collection ด้วย CSV และ JSON
• แนะนำ performance testing ใน Postman ที่เพิ่มเข้ามาอีกด้วย สามารถกำหนดรูปแบบของการสร้าง Virtual user ได้ 4 แบบคือ Fixed, Ramp up, Spike และ Peak

ทำการปรับเปลี่ยนจาก manual test มาเป็น automated test ด้วย newman

• ทำการติดตั้ง
• ทำการ run ด้วย option ต่าง ๆ ทั้ง folder, environment และ report เป็นต้น
• การทำงานบน pipeline ของ CI/CD

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

เห็นมีการ share เครื่องมือต่าง ๆ เกี่ยวกับ Docker
ซึ่งช่วยลด pain point ต่าง ๆ ของการใช้งานลงไป
ทั้งการเขียน Dockerfile
ทั้งการสร้างไฟล์ Docker compose
ตาม application ต่าง ๆ
มาดูกันว่ามีเครื่องมืออะไรที่น่าสนใจกันบ้าง ?

ตัวแรกคือ Dockerizer

ช่วยสร้าง Dockerfile ของ application ชนิดต่าง ๆ หรือจาก framework ต่าง ๆ ได้เลย
เช่น nodejs + express และ reactjs เป็นต้น
รวมทั้งสามารถเลือก version ต่าง ๆ ได้อีกด้วย

ตัวที่สองคือ Dockge

ช่วยให้การเขียน Docker compose ง่าย และ interactive มากยิ่งขึ้น
ลองใช้แล้วสนุกมาก ๆ แต่ยังไม่สนับสนุน Windows นะครับ

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

คำถามจากการแบ่งปันเรื่อง Postman ว่า

ถ้าต้องการทำการ mock data ขึ้นมาใน response ของแต่ละ request
จะทำได้ไหม ?
ถ้าทำได้ต้องทำอย่างไร

คำตอบคือ ทำได้ และมีหลายวิธี

วิธีการแรก ทำการเขียนใน blog เรื่องการใช้งาน JSON SChema Faker

อีกวิธีการที่น่าสนใจคือ การใช้งาน feature ใน postman ไปเลย
ซึ่งจะมี faker-js package ซึ่ง build-in มาให้เลย
สามารถใช้งานง่าย ๆ ดังนี้

สามารถใส่ได้ทั้งในส่วนของ request body และ response ได้เลย
มันคือ template นั่นเอง

Reference Websites

• Generate mock responses using variables and templates
• Dynamic variables in Mock Servers

วันนี้มีโอกาสได้เข้าร่วมฟัง meetup เรื่อง MongoDB Data Modeling
จากกลุ่ม MongoDB Thailand User Group
ซึ่งมีหัวข้อต่าง ๆ เหล่านี้

• แนะนำ MongoDB ว่าเป็นอย่างไร มีเป้าหมายอะไรบ้าง ความเข้าใจผิดต่าง ๆ จากการใช้งาน
• อธิบายเรื่อง Replication และ Sharding
• แนะนำเรื่อง Data modeling pattern โดยเป็นรูปแบบตามรูปแบบการใช้งานของ application

ทำการสรุปจากสิ่งที่ได้ฟังดังนี้
มาเริ่มกันเลย

เริ่มที่แนะนำ MongoDB สักเล็กน้อย เช่น

• Flexible schema ทำให้มีความยืดหยุ่นสูง หรือ change friendly แต่ก็ต้องทำ schema validationไว้ด้วย
• No-locking column
• ง่ายต่อการดึงและวิเคราะห์ข้อมูล
• ง่ายต่อการ horizontal scale ด้วย sharing

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

• Normalize ข้อมูลเหมือนกับการออกแบบใน RDBMS
• ไม่ออกแบบตามการใช้งาน ทั้ง Read และ Write
• ไม่ทำการ shading ข้อมูล

ต่อมาเรื่องของ MongoDB Design

• Replication ทำการเพิ่มเครื่องเข้ามา จากนั้นทุก ๆ เครื่องก็ทำการ sync ข้อมูลไปเหมือน ๆ กัน เพื่อช่วยเพิ่มเครื่องมาช่วยงาน และช่วยเครื่อง High avaliability (HA) โดยเครื่อง prinary สำหรับ read และ write ส่วนเครื่อง secondary นั้น read-only
• Sharding ทำการกระจายข้อมูลตาม shard key ที่กำหนด เช่น hash และ range เป็นต้น หรือเรียกว่า collection sharding ไม่จำเป็นต้อง sync ข้อมูลเหมือนกันทุกเครื่อง โดย shard ยังคงมีการ replicate data อยู่นั่นเอง ใน MongoDB 7 นั้นจะมีเครื่องมือทำ sharding analytic มาให้ด้วย

การติดตั้งแบบ replication จะง่ายกว่า sharding

เรื่องสุดท้ายคือ Data modeling pattern สำหรับ MongoDB

โดยจะมีหลายรูปแบบมาก ๆ ขึ้นอยู่กับรูปแบบของการใช้งาน
ทั้ง read และ write
รวมทั้งยังต้องลดการ join หรือ ดึงข้อมูลหลาย ๆ ครั้ง
เนื่องจากจะถูกจัดการผ่าน application มากกว่า เช่นการ application join เป็นต้น
ซึ่งถ้าทำเยอะ ๆ ก็จะทำให้ประสิทธิภาพแย่ลง

ใน meetup ครั้งนี้ จะทำการอธิบายถึง pattern ที่ใช้งานบ่อย ๆ ดังนี้

• Computed pattern ทำการสรุปข้อมูลที่จะถูกใช้งานหรืออ่านบ่อย ๆ ไว้ก่อน เช่นการ count, summary, average หรือ grouping เป็นต้น
• Inheritance pattern หรือ Polymorphic นั่นเอง ถ้าต้องการเก็บข้อมูลที่หลากหลายใน collection เดียวกัน แล้วมีข้อมูลที่คล้าย ๆ กัน ดังนั้นทำเป็น parent/child ไปเลย ช่วยให้เก็บง่าย ดึงง่าย เช่น single view app, content management เป็นต้น
• Extended pattern ถ้าต้องใช้ข้อมูลจากหลาย ๆ collection มักต้องทำการ join ดังนั้นทำการเพิ่มข้อมูลที่ต้องการใช้ใน document ของ colelction หลักไปเลย เอาเท่าที่ใช้มานะ เพื่อลดการ join ทำให้เร็วต่อการอ่าน แต่ระวังเรื่องขนาดของ document ต้องไม่เกิน 16 MB
• Schema versioning pattern สำหรับจัดการ version ของ document ด้วยการเพิ่ม property version เข้ามา ทำให้ฝั่ง application จัดการกับข้อมูลตาม version ได้ง่าย ลด downtime ลงไป อาจจะเป็น zero-downtime ได้ อย่าลืมทำ schema validate ไว้ด้วย
• Subset pattern คล้ายกับการ extened แต่ว่าด้วยเรื่องของขนาดข้อมูลที่อาจจะใหญ่เกินไป ดังนั้นจึงให้เก็บเท่าที่จะใช้งานก่อน เช่นถ้าเป็น paging ก็เก็บ page แรกไว้ หรือ top 100 เป็นต้น
• Bucket pattern เป็น pattern ที่คิดออกมาสำหรับจัดการข้อมูลแบบ time-series, real-time analytic และ IoT เป็นต้น ทั้งการอ่านและเขียนข้อมูลปริมาณมาก ๆ เนื่องจาก disk และ memory มีจำกัด เป็นการนำเอาแนวคิดของ computed และ subset มาใช้งาน โดยใน MongoDB 5.0 ได้สร้าง Time-series collection ออกมา เพื่อให้ใช้งานง่ายขึ้น

สามารถดู pattern อื่น ๆ เพิ่มได้ที่ Building with Patterns: A Summary

Reference Websites

• Slide ของ meetup ครั้งที่ Download ได้เลย
• MongoDB Data Encryption
• Practical MongoDB Aggregations Book