วันนี้อ่านบทความเรื่อง Everything you need to know about Caching — System Design อธิบายเรื่องพื้นฐานเกี่ยวกับ caching หรือข้อมูลชั่วคราว ว่าคืออะไร มีการใช้งานใน use case หรือในกรณีอะไรบ้าง รวมทั้ง strategy และ policy การใช้งาน caching ว่าเป็นอย่างไร ผมคิดว่าเป็นเรื่องพื้นฐานที่นักพัฒนาจำเป็นต้องรู้และเข้าใจ เพื่อนำมาประยุกต์ใช้งานได้อย่างมีประสิทธิภาพ จึงทำการสรุปไว้นิดหน่อย
จาก Live กับหนึ่งในทีมพัฒนาของระบบเราไม่ทิ้งกัน จาก page รู้ไม่มากแต่อยากเล่า ที่เปิดให้คนไทยที่ได้รับผลกระทบจาก COVID-19 มาลงทะเบียนเพื่อรับเงินเยียวยา ดังนั้นจึงทำการสรุปสั้น ๆ ไว้หน่อย
บันทึกการนั่งเฝ้าดูระบบ เราไม่ทิ้งกัน.comซึ่งบอกไว้ว่าจะเปิดให้ลงทะเบียนวันที่ 28 มีนาคม เวลา 18.00 น.ผมก็เฝ้ารอดูระบบเลยว่าจะเอาอยู่ไหม ?เรื่อง IT เราสนใจอยู่แล้วมาดูกันเป็น timeline กันเลย
เจอรูปที่น่าสนใจว่า เราให้ความสำคัญกับคำว่า Loose coupling มากจนเกินไปทำให้เกิดระบบแยกกันมาก ๆ ทำการเกิด communication และ relationship กันเยอะไปยิ่งกว่านั้นกลายเป็น dependency ที่เหนียวแน่นมาก ๆ (แยกกัน แต่ตอนทำงานดันติดกันมาก)สุดท้ายก็กลายเป็นระบบที่ Complicate หรือซับซ้อนจนเอาไม่อยู่กันอยู่หรือเปล่านะ
จากบทความเรื่อง The Elephant in the Architecture นั้น ทำการอธิบายถึงที่มาที่ไปของปัญหาต่าง ๆ ที่เกิดขึ้นในการออกแบบ software ว่าเราทำการออกแบบด้วยแนวคิดอย่างไร ? ซึ่งแนวทางนั้นจะเทียบเคียงได้กับสำนวน The Elephant in the room นั่นคือ เราทุกคนนั้นเห็นปัญหา เห็นข้อเท็จจริงต่าง ๆ อย่างชัดเจน แต่ทุกคนหลีกเลี่ยงที่จะพูดถึงมัน เหมือนกับการมีช้างอยู่ในห้อง แต่ทุกคนจะไม่พยายามหรือมองเห็นมันนั่นเอง
หนึ่งในเรื่องที่น่าสนใจจากหนังสือ Monolith to Microservices (Evolutionary patterns to transform your monolith) อธิบายว่า เมื่อจำนวน service ของระบบเพิ่มมากขึ้นแล้ว ปัญหาที่ต้องพบเจอก็มากและแตกต่างกันไป เช่นปัญหาของ service ที่ไม่เกิน 10 service จะแตกต่างจาก 50 หรือ 100 service ดังนั้นสิ่งที่เราควรต้องรู้แล้วเข้าใจคือ จะรับมือหรือแก้ไขปัญหาเหล่านั้นกันอย่างไร
อ่านบทความเรื่อง Taming Complex Systems in Production มีเรื่องที่น่าสนใจเยอะ หนึ่งในนั้นคือ เรื่องเกี่ยวกับการพัฒนาระบบ ให้สามารถ recover กลับมาจากความผิดพลาดได้ด้วยระบบเอง โดยไม่ต้องมีคนเข้าไปยุ่งเกี่ยว ซึ่งสรุปว่าระบบที่จะทำได้จำเป็นจะต้องมีคุณสมบัติดังต่อไปนี้
วันนี้ว่าง ๆ เลยมานั่งอ่าน The InfoQ eMag – Taming Complex Systems in Production เป็น miniBook จากทาง InfoQ แนะนำสำหรับจัดการหรือควบคุมระบบงานที่ยิ่งนานวันยิ่งมีความซับซ้อนมากขึ้นเรื่อย ๆ ยิ่งเมื่อเกิดปัญหาขึ้นมา บ่อยครั้งต้องมีค่าใช้จ่ายสูงมากในการแก้ไขเพื่อให้ระบบกลับมาทำงานได้อย่างปกติ ดังนี้เราควรต้องทำการแก้ไขและปรับปรุงแล้วนะก่อนอื่นเราต้องทำการปรับปรุงในแง่ขององค์กร คน และระบบการทำงาน ให้มีความยืดหยุ่น และสามารถกลับคืนมาสู่สภาวะการทำงานปกติได้ง่าย
จาก VDO เรื่อง Deconstructing the Monolith (Shopify Unite Track 2019) ทำการอธิบายถึง architecture ระบบของ Shopify ว่ามีความเป็นมาอย่างไร ตั้งแต่แบบ Monolith เมื่อระบบมีขนาดใหญ่และซับซ้อน จึงเกิดปัญหาและส่งผลกระทบต่อระบบ บริษัท รวมไปถึง productivity ในการพัฒนาระบบงาน ดังนั้นทาง Shopify จึงต้องทำการแก้ไขและปรับปรุงนั่นเอง
พอดีช่วงบ่ายวันศุกร์เห็น course Domain-Driven Design by Roofimon เด้งขึ้นมาลองไปกดดู ก็มีบัตรว่างด้วย ดังนั้นจึงซื้อตั๋วไปเรียนด้วย เป้าหมายหลัก ๆ เพื่อทำให้รู้และเข้าใจเกี่ยวกับ DDD (Domain-Driven Design) ว่าคืออะไร เป็นอะไร มาเริ่มกันเลย