ว่าง ๆ มาดูกันว่า Redis มีความสามารถอะไรที่น่าสนใจบ้าง
บางอย่างก็น่ารู้ แต่บางอย่างก็ไม่น่ารู้
ก่อนอื่นต้องทำความรู้จักกับ Redis ก่อนว่า
มันคือ No-SQL database ประเภทหนึ่ง
ซึ่งจะเรียกว่า Key-value database
โดยที่รูปแบบข้อมูลมีทั้ง string, hash, list, set และ sorted set
ทำให้ถูกเรียกว่าเป็น Data Structure Database

การทำงานโดยพื้นฐานข้อมูลจะถูกเก็บลงใน Memory

ทำให้ Redis มีการทำงานที่รวดเร็วมาก ๆ แต่ก็จะมีการบันทึกแบบ snapshot ลงใน file system ด้วย ทำให้เมื่อ shutdown Redis ลงไปแล้ว เมื่อ start ขึ้นมาใหม่ ข้อมูลจะยังคงอยู่ด้วย แต่ให้ระวังเรื่องการกำหนด config ของการ snapshot ด้วย

แต่ Redis ก็มีเรื่องน่ารู้อื่น ๆ พอสมควร เช่น

• Redis 2.0 ขึ้นมา มีรูปแบบการใช้งาน Pub-Sub มาให้ด้วย
• Key ที่จัดเก็บสามารถกำหนดอายุได้ด้วยนะ อย่าลืม !!
• การใช้งาน Redis ควรออกแบบ key ให้ดี รวมทั้งกำหนด memory policy เมื่อ memory จะเต็มด้วย ว่าจะทำการจัดการข้อมูลอย่างไร
• ถ้าต้องการใช้งาน Redis เพื่อจัดเก็บข้อมูลชั่วคราวเพียงอย่างเดียว ต้องปิดขั้นตอนของการบันทึกหรือ snapshot ซะ เพราะมันเกินความจำเป็น
• ถ้าต้องการจัดเก็บข้อมูลง file system แล้ว เช่น AOF และ RDS ควรกำหนด policy ให้เหมาะกับงาน มิเช่นนั้นอาจจะทำให้ Redis ช้าลงอย่างมากได้
• Redis สามารถทำ cluster ได้นะ project มันชื่อ Sentinel
• การติดต่อมายัง Redis server ควรต้องติดต่อผ่าน connection pool
• Redis มาสามารถเก็บข้อมูลได้ 2^32 key หรือ 4,000 ล้าน แต่ถ้าจะให้มีประสิทธิภาพดี ก็อยู่ที่ 250 ล้าน key ต่อ 1 instance
• ข้อมูลที่ถูกจัดเก็บในแต่ละ key มีขนาดได้ถึง 2^32 element
• สามารถเรียนรู้การใช้งานคำสั่งต่าง ๆ ของ Redis ผ่าน web ได้ก่อน
• มี module เสริมใช้งานอีกนะ ทั้ง RedisSearch, RedisJSON และ RedisGraph เป็นต้น

อ่านบทความเรื่อง The 23 Patterns of Software Negligence
พูดถึงรูปแบบของ pattern ของนักพัฒนาที่ไม่สนใจในสิ่งที่ทำ
แน่นอนว่า ก่อให้เกิดปัญหามากมายตามมา
โดยมีรูปแบบที่น่าสนใจดังนี้

The Prototype Promotion pattern
ทำให้เสร็จแบบไว ๆ แล้วเดี๋ยวจะกลับมาแก้ไขในภายหลัง ผลคือ มันก็อยู๋อย่างนั้นแหละ

The Immortality pattern
เมื่อ code มีอายุมาก ๆ แล้ว จะไม่มีใครกล้าแก้ไขหรือปรับปรุง
แต่เมื่อใครกล้าพอที่จะแก้ไข
ผลที่ตามมาคือ ความผิดพลาดมากมาย

Zombie pattern
เป็น code ที่ไม่แก้ไขที่ปัญหา แต่ละแก้ไขแบบ case-by-case ไป

The Random Poke pattern
แก้ไข code ที่ส่วนหนึ่งแล้ว เกิดผลกระทบในส่วนอื่น ๆ

The God Object pattern
ตามชื่อเลย หลาย ๆ อย่างรวมกันอยู่ที่เดียว ซึ่งเยอะมาก ๆ

The Special Case pattern
เป็นรูปแบบของการเพิ่มการทำงานต่าง ๆ เข้ามา
ซึ่งเป็นวิธีการที่ง่ายมาก แต่ผลที่ตามมาคือ ความซับซ้อนจะมากขึ้นเรื่อง

The Retroactive Formalization pattern
เขียน code ให้เสร็จก่อน แล้วค่อยเขียน spec หรือ test
แน่นอนว่า ยังไงก็ผ่านหรือตรงกัน

The Apology pattern
ทำผิดประจำ เอาแต่ขอโทษในสิ่งที่ทำ ไม่ปรับปรุง

สุดท้ายคือ The It Came From Above pattern
มันเป็นผลมาจากรูปแบบก่อนหน้านี้นะ !!!

ในทุก ๆ ครั้งที่เปิด VS Code ขึ้นมาเพื่อทำการเขียน code ต่าง ๆ นั้น
พบว่าก่อนที่จะเขียน code ต้องมีการทำงานดังนี้

• ย้ายไปยัง develop branch
• ทำการ pull code และ rebase
• ทำการ build project ด้วยคำสั่งต่าง ๆ เช่น npm install
• ทำการ run dev server เช่น npm start

ทำบ่อย ๆ ก็ขี้เกียจ เลยมาเขียน Tasks ใน VS Code ไว้ดีกว่า
เมื่อเปิด VS Code ขึ้นมาแล้ว
จะทำการ run task แบบอัตโนมัติเลย มาสร้างกันดังนี้

ทำการสร้าง folder ชื่อง่า .vscode ขึ้นมาใน workspace

จากนั้นสร้างไฟล์ tasks.json 
โดยที่มีงานต่าง ๆ ที่เราต้องการดังนี้

ทำการ enable การ run task แบบอัตโนมัติ
ด้วยการเปิดที่ Command palette => Manage Automatic Tasks in Folder
และทำการ allow ไปซะ 
จากนั้นทำการเปิด VS Code ใหม่ ก็จะใช้งานได้แล้ว

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

จากเดิมที่ทาง GitHub ได้ปล่อย Package มาให้ใช้
ซึ่งสามารถเก็บ package ต่าง ๆ ได้มากมาย
เช่น Node package และ Docker image เป็นต้น

จากการใช้งานพบว่า พวก Docker image
สำหรับสร้าง container นั้นมันเยอะมาก ๆ
จึงได้ทำการแยกการบริการออกมาในชื่อว่า Container Registry
ช่วยปรับปรุงการทำงานในรูปแบบ container
ตั้งแต่การสร้าง การ deploy และ release ได้ง่ายขึ้น

โดยที่เป็นการร่วมมือกันระหว่างทีมของ Docker และ Microsoft

ในช่วง beta version นี้ สามารถจัดเก็บได้ทั้ง public และ private
ส่วนต่อไปไม่รู้เช่นกัน

โดยที่ domain ของ Container Registry จะแยกออกมาจาก Package

คือ ghcr.io/OWNER/IMAGE_NAME
ดังนั้น image ต่าง ๆ ของเราเอาขึ้นได้เลย

ผลการทำงานเป็นดังรูป

หรือสามารถ integrate เข้ากับ GitHub Action ไปได้เลย

ซึ่งง่ายและสะดวกเข้าไปอีก ด้วย Publish Docker Container

ดูตัวอย่างการใช้งานได้ที่ GitHub::Up1

ปล. GitHub อย่าล่มบ่อยนะ ช่วงหลัง ๆ ล่มบ่อยมาก ๆ !!

จากที่ได้แนะนำเรื่องการพัฒนาและทดสอบระบบงานพวก RESTFul API ไปนั้น
มีคำถามที่น่าสนใจเกี่ยวกับการทดสอบว่า เราจะทำการทดสอบอย่างไรดี ?
จะทดสอบใน level ไหนบ้างเช่น integration, unit และ component เป็นต้น
จึงสรุปคำแนะนำออกมาเป็นข้อ ๆ แบบสั้น ๆ ดังนี้

ปล. คำจำกัดความของการทดสอบใน level ต่าง ๆ นั้น
อ้างอิงมาจาก Testing Strategies in a Microservice Architecture

เริ่มจาก Integration test ก่อนเลย

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

URL ของ API ต้องง่ายต่อการเปลี่ยน

นั่นหมายความว่าทางผู้เรียกใช้งาน API นั้น
ต้องสามารถเปลี่ยน URL ได้ง่าย
ไม่ได้ทำการ hard code เอาไว้

ผลที่ตามมาคือ คนเรียกใช้งาน API สามารถเปลี่ยนไปใช้ server อื่น ๆ ได้ง่าย
เช่น local server เป็นต้น
โดยที่ไม่ต้องมาแก้ไข code อีกต่อไป

ถ้าเป็นการเรียกจากระบบงานของเรา
แล้วทำการเปลี่ยน URL มาเป็น local server
การทดสอบนั้นเราจะเรียกว่า component testing นั่นเอง

ต่อมาถ้าเราทดสอบแบบ integration test ได้แล้ว น่าจะต้องบันทึกการเรียกใช้งานได้

เพื่อความง่ายต่อการทดสอบแล้วนั้น
เราต้องพิจารณาการบันทึก request และ response
ของ API ที่เราเรียกใช้งานไว้ด้วยเสมอ
เพื่อนำมาใช้ประโยชน์ของการทดสอบ
ทั้งดูการเปลี่ยนแปลง
ทั้งนำมาจำลองใน local server
ทั้งนำมาใช้ในการทดสอบระดับอื่น ๆ

เน้นเรื่องของ Convention over configuration

นั่นคือเน้นไปที่ข้อตกลงในการทำงานมากกว่าการ configuration
เพราะว่าการ configuration มันใช้เวลาที่เยอะ รวมทั้งเกิดข้อผิดพลาดได้สูง

สุดท้าย สำหรับส่วนการทำงานที่มีความซับซ้อน

แนะนำให้เขียน Unit test เสมอ 
อย่าหลีกเลี่ยงมัน ด้วยการบอกว่าเรามี integration test แล้ว

มาเขียนชุดการทดสอบกัน

จากบทความเรื่อง 5 Shocking Habit of the Most Effective Programmers
พูดถึงเรื่อง 5 นิสัยของ Effective Programmer ที่ควรจะมี
เป็นคำแนะนำที่น่าสนใจ เนื่องจากมันเป็นเพียงเส้นบาง ๆ เท่านั้นเอง

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

นิสัยที่ 1 เล็งเห็นความสำคัญของการพิมพ์แบบสัมผัสและ shortcut key ต่าง ๆ

การพิมพ์แบบสัมผัสและ shortcut key ต่าง ๆ นั้น
จะช่วยให้การเขียน code ลื่นไหลมากขึ้น
ไม่ต้องมากังวลว่าจะพิมพ์ตรงไหน ด้วย key อะไร
มันจะเป้นไปเองโดยธรรมชาติ
แน่นอนว่า ต้องการเวลาฝึกฝน

ปล. ข้อนี้ผมก็ทำไม่ค่อยได้ เพราะว่าขี้ลืมมาก ๆ แถมไม่ขยันฝึก ไม่ขยันซ้อมซะด้วย

นิสัยที่ 2 เรียนรู้สิ่งใหม่ ๆ อยู่อย่างสม่ำเสมอ

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

ในแต่ละวันเรามีเวลาให้กับการเรียนรู้สิ่งใหม่ ๆ กันบ้างหรือไม่ ?

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

นิสัยที่ 3 เขียน code ที่ง่ายต่อการอ่านและทำความเข้าใจ

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

นิสัยที่ 4 เตรียม guildline ไว้ให้กับคนอื่น ๆ รวมทั้งอย่ากลัวที่จะถามหรือขอความช่วยเหลือจากคนอื่น

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

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

นิสัยที่ 5 พยายามอ่านและทำความเข้าใจ code ของคนอื่นด้วย

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

มาลงปรับปรุงนิสัยกันดู วันละเล็กละน้อย
น่าจะช่วยให้เราเป็นนักพัฒนาที่ดีขึ้นไม่มากก็น้อย
ขอให้สนุกกับการ coding 

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

จากบทความ 5 Key Takeaways From My Experience with Microservices
ทำการสรุปจากประสบการณ์การนำแนวคิด Microservices มาใช้งาน
ว่ามันมีข้อดีข้อเสีย ข้อระมัดระวังรวมทั้งความเข้าใจ
จึงทำการสรุปไว้นิดหน่อย น่าจะพอมีประโยชน์บ้าง

เรื่องที่ 1 ทำการสร้างและพัฒนา Product ไม่ใช่ Project

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

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

แต่เมื่อเวลาผ่านไป กลับทำให้แต่ละ product นั้น
พัฒนายาก ดูแลยาก เกิดการพูดคุยข้าม service/system เยอะมาก ๆ
เนื่องจากความรู้ของระบบงานกระจายตามแต่ละส่วนงาน
นี่คือปัญหาหรือ overhead ของการพัฒนาหรือไม่ ?

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

• ทั้งการออกแบบเผื่อมาก ๆ
• ขั้นตอนการทำงานที่เทอะทะ ทำงานแบบ centralize
• กระบวนการ build -> test -> deploy แบบ manual

สิ่งที่ควรปรับเปลี่ยนคือ Project -> Product
นั่นคือใน product หนึ่ง ๆ นั้น คนที่เกี่ยวข้อง
ทั้ง business, development, operation ต้องมีเป้าหมายร่วมกัน เข้าใจร่วมกัน
ไม่ใช่ต่างฝ่ายต่างมีเป้าหมายที่ต่างกัน
ทำให้มีความสัมพันธ์ที่ดีต่อกัน
ผลที่ได้คือ ได้ product ที่ดีต่อผู้ใช้งานหรือลูกค้า

ยิ่งเป็นแนวทาง Microservices คือ การแบ่งออกเป็น service เล็ก ๆ
ซึ่งแต่ละ service นั้นมีการทำงานที่เป็นอิสระ หรือไม่ยืมจมูกคนอื่นหายใจ
ตั้งแต่การจัดการ requirement, design, develop, testing, deploy และดูแลรักษา
เพื่อให้การทำงานของแต่ละ service เป็นไปอย่างคล่องตัว

คำถามคือ เราจะทำการปรับเปลี่ยนหรือไม่ ? หรือเพียงแค่เปลี่ยนชื่อเท่านั้นเอง ?

เรื่องที่ 2 แยก services แล้วชีวิตต้องดีขึ้น

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

ดังนั้นก่อนแยก services ควรเข้าใจการทำงานแบบ end-to-end ก่อนว่าเป็นอย่างไร
เพื่อทำให้เข้าใจภาพรวม ทั้ง business flow, operation flow

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

เรื่องที่ 3 อย่าลืมว่าเราแก้ไขปัญหาอะไร เพื่ออะไร

การเปลี่ยนแปลงนั้น มันต้องดูผลในระยะยาว
อย่าลืมว่า ทำการแยกเพราะว่าอะไร ?
นั่นคือเรามีปัญหาอะไร ต้องเข้าใจ
ยกตัวอย่างเช่น
ต้องการแยกเพราะว่า ต้องการให้การทำงาน A สามารถรองรับผู้ใช้งานได้เยอะ
ก็ต้องเน้นไปที่เรื่องของการ scale เฉพาะในระบบ A
โดยที่ต้องไม่ไปกระทบส่วนอื่น ๆ ด้วย
ดังนั้นทั้งการพัฒนา, operation, infrastructure ต้องสนับสนุนด้วยเสมอ

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

การเตรียมพร้อมก่อนจะเริ่มจึงสำคัญมาก ๆ

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

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

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

จากการแนะนำเรื่องของ Continuous Integration และ Continuos Delivery นั้น
มีการพูดคุยถึงคุณสมบัติที่ดีของระบบเหล่านี้
ว่าควรจะมีอะไรบ้าง
เพื่อให้เราไม่หลงทางในการนำมาใช้งาน

ข้อที่ 1 ทำงานได้อย่างรวดเร็ว

ในขั้นตอนการทำงานของ CI/CD หรือ pipeline นั้น
จะต้องทำงานได้อย่างรวดเร็ว ตั้งแต่การ build, test และ deploy
เพื่อช่วยทำให้เราได้รับ feedback ต่าง ๆ จากการเปลี่ยนแปลงได้รวดเร็ว

ถ้าทำงานช้ามาก ๆ
ก็ต้องรอนาน หรือไม่อยากใช้งานไปในที่สุด
อย่าลืมเป้าหมายหลังของ CI/CD

ข้อที่ 2 มีความน่าเชื่อถือ

ความเร็วอย่างเดียวยังไม่เพียงพอ แต่ต้องมีความน่าเชื่อถือหรือเสถียรด้วย
ไม่ใช่ทำงานผ่านบ้าง ไม่ผ่านบ้าง โดยที่ไม่แก้ไขอะไรเลย
มันทำให้ขาดความน่าเชื่อถือ
รวมทั้งยังรองรับการ scale และรองรับ use case ต่าง ๆ มากขึ้นด้วย

ข้อที่ 3 environment ต่าง ๆ ควรมีรูปแบบเดียวกัน

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

ข้อที่ 4 ควรอธิบายให้ทีมและส่วนงานที่เกี่ยวข้องเกี่ยวกับ CI/CD

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

เมื่อ Dart 2.10 ออกมา อ่านว่า สองจุดสิบ
สิ่งหนึ่งที่เปลี่ยนแปลงและชอบมาก ๆ คือ dart command นั่นเอง
โดยเป้าหมายเพื่อให้ใช้ dart command เดียวจบเลย
ทำให้ไม่ต้องไปใช้เครื่องมือหรือ command อื่น ๆ เช่น dartfmt, dartanalyzer เป็นต้น
แน่นอนว่า เป็นแนวทางเดียวกับ flutter

ใครที่ยังไม่ update Dart ก็จัดได้เลยนะ

คำถามที่น่าสนใจมาก ๆ ที่ถูกถามเป็นประจำคือ
ทำไมต้องมี API Gateway ด้วย ? ไม่ใช้ได้ไหม ?
พอดีซื้อมาแล้ว ก็ต้องใช้ ?
คนออกแบบกำหนดว่าต้องให้มี ?

แต่ก็มักตอบกลับด้วยคำถามคือ ใช้ API Gateway ไปทำไม ?
ทำไมต้องใช้ ?
ไม่ใช้ได้ไหม ?
การใช้หรือไม่ใช้ มีข้อดีและข้อเสียอะไรบ้าง ?

ยิ่งพูดถึงบริบทของ Microservices ก็ยิ่งมีการพูดถึงหรือใช้งาน API Gateway มาก

แต่ก่อนอื่นเรามาดูก่อนว่า ถ้าไม่มีการใช้งาน API Gateway จะเป็นอย่างไร
ไปเจอรูปจากบทความ Why do microservices need an API Gateway?
อธิบายด้วยรูปนี้

คำอธิบาย

ในแต่ละ service จะมีการทำงานต่าง ๆ มากมาย ทั้ง function การทำงานหลัก ทั้ง function การทำงานอื่น ๆ ที่ไม่ใช่ส่วนหลัก แต่เป็นส่วนเสริม เช่น

• Authentication และ Authrorization
• การจัดการ CORS (Cross-Origin Resource Sharing)
• การจัดการเรื่อง Traffic และ Rate limit
• การ Monitoring ระบบงาน
• การจัดการ Logging
• การจัดการ Request termination
• การจัดการเรื่องของ caching data

ทำให้แต่ละ service หรือ ระบบงาน มีการทำงานเยอะจนเกินไป
หรือมีการทำงานที่ผูกมัดจนเกินไป (Tight coupling)
เกิดงานที่ทำซ้ำ ๆ จนน่าเบื่อ
การที่จะเปลี่ยนแปลง อาจต้องเปลี่ยนแปลงในหลาย ๆ ที่

ดังนั้นจะดีกว่าไหม ถ้ามีส่วนการจัดการสิ่งต่าง ๆ เหล่านี้

นั่นคือ การสร้างอีกส่วนงานหรือ layer ขึ้นมา
ซึ่งจะเรียกว่า API Gateway หรือบางคนเรียกว่า Backen for Frontend (BFF)
ทำให้ระบบงานหลักกับส่วนงานซ้ำ ๆ ออกจากกัน
ทำให้ไม่ผูกมัดกันมากนัก (Loose Coupling)
ที่สำคัญทำให้ แต่ละส่วนงานทำหน้าที่ของมันไป (Single Responsibility)
แสดงดังรูป

แต่เมื่อแยกออกมาแล้ว ไม่ใช่จะมีเพียงข้อดี แต่ก็ยังมีข้อเสียที่ต้องเข้าใจ

เพื่อที่จะได้หาวิธีแก้ไขและป้องกัน
ทั้งเรื่องของการเปลี่ยนแปลง
ทั้งเรื่องของการ configuration
ทั้งเรื่องปัญหาคอขวด
ทั้งเรื่องของปัญหา Single Point of Failure ที่อาจจะเกิดขึ้น
ทั้งเรื่องของการ scale เพื่อรองรับการใช้งานที่มากขึ้น
รวมทั้งการมีจำนวน hop/layer เพิ่มเข้ามา  อาจจะส่งผลต่อ rsponse time ที่สูงขึ้น

อีกอย่าง เราชอบทำการร้อยเรียง service ต่าง ๆ ใน API Gateway

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

การใช้งาน API Gateway นั้นมักจะใช้ใน traffic ที่เรียกว่า North-South traffic

ซึ่งเป็นการติดต่อสื่อสารระหว่างระบบภายในและภายนอก
หรือการติดต่อจาก public zone มายัง private zone
ซึ่งจะผ่านตัว API Gateway ก่อนเสมอ
เปรียบได้กับ ตม. เข้าประเทศนั่นเอง

สุดท้ายลองตอบคำถามให้ได้ก่อนว่า

ทำไมคุณถึงใช้งาน API Gateway มิใช่เพียงบอกว่า
เราหรือเขาบอกว่าต้องใช้งาน
มิเช่นนั้น ของที่มีประโยชน์อาจจะกลายเป็นโทษก็ได้

คำถาม 
ใน Postman นั้นจะทำการตรวจสอบโครงสร้างของ JSON Response ได้อย่างไรบ้าง ?

คำตอบ
ใน Postman สามารถตรวจสอบรูปแบบของ JSON Response  ผ่าน library ที่ชื่อว่า 

• Tiny validator library หรือ tv4
• Another JSON Schema หรือ Ajv

แต่ก่อนใช้งานควรทำความเข้าใจกับ JSON Schema กันก่อนนะ

จากการใช้งานพบว่า library Ajv ใช้งานง่ายและสะดวก

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

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

คำถาม Framework ต่างกับ Library อย่างไร ?
คำตอบ สะกดต่างกันไงละ !!

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

แต่ถ้าอธิบายให้เห็นภาพก็คือ

Library นั้นคือสิ่งที่ code ของเราไปเรียกใช้งาน

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

• การจัดการ log เช่น log4j
• การจัดการ JWT เช่น jsonwebtoken 

ดังนั้น code ของเราเป็นส่วนหลักของการทำงานและจัดการ
จากนั้นจึงไปเรียก library ต่าง ๆ มาใช้งาน

ส่วน Framework หรือกรอบการทำงาน จะตรงข้ามกับ Library

นั่นคือ framework จะกำหนดว่า code เราควรเป็นอย่างไร อยู่ตรงไหน
โดยรูปแบบของ framework จะมีทั้ง

• Configuration-based
• Convention over Configuration

แล้ว code ของเราจะทำงานได้ตามที่กำหนดไว้
ซึ่ง framework จะเชื่อม code ต่าง ๆ ของเราเข้าด้วยกัน
ตามชื่อ กรอบการทำงานมาก ๆ

สิ่งที่แตกต่างอีกคือ การแก้ไข

ในส่วนของ Framework นั้นเราไม่สามารถแก้ไขส่วนการทำงานหลักหรือ core ได้
(ทำได้นะ แต่อย่าหาทำ)
แต่สามารถทำการ extend หรือสร้างส่วนขยายได้
ส่วนของ Library นั้นอยากทำอะไร ทำได้เลย
หรือบ่อยครั้งเปลี่ยนไปใช้ library อื่น ๆ ได้ง่ายมาก ๆ

สุดท้าย Framework นั้นมักจะช่วยให้เกิดคำว่า standard หรือมาตรฐานในการทำงานขึ้นมา

ส่วนของ Library เกิดมาเพื่อช่วยให้การพัฒนางง่ายขึ้น
ทั้งเรื่องของ DRY (Don’t Repeat Yourself) และการ reuse นั่นเอง

สรุปได้สวยดี จาก DiffereceBetween

ปล. จะรู้ไปทำไมว่ามันต่างกันอย่างไร ?

วันนี้ทำการ upgrade Deno 1.4 มาใช้งาน
พบว่ามีการเปลี่ยนแปลงที่น่าสนใจ
ในส่วนของการพัฒนาและทดสอบดังนี้

• สนับสนุน Web Standard WebSocket API
• เพิ่มการ watch เมื่อ code เปลี่ยนแปลงรวมทั้งการทดสอบด้วย (development mode) ($deno run --watch)
• เพิ่ม code coverage เข้ามา แต่ยัง unstable โดยผลที่ได้อยู่ในรูปแบบไฟล์ json และ lcov ($deno test --coverage)
• ใช้ CSS ใน console.log ได้แล้ว แจ่มมาก ๆ

มาทำการ upgrade Deno กันครับ

ชอบมาก ๆ กับ CSS ใน console.log

เห็นเพื่อน ๆ ทำการ share เรื่อง Data Oriented Programming (DO) ใน timeline
ก็เลยลองไปอ่านดู พบว่าน่าสนใจดี
จึงลองตั้งเป้าการอ่านขึ้นมาอีกเรื่องของเดือนนี้ (ช่วงวันหยุด)
โดยที่หนังสือ Data Oriented Programming (DO)
น่าจะถูกปล่อยออกมาในปีหน้า
มาดูเนื้อหาที่อ่านในครั้งแรกกันหน่อย

จากรายชื่อหัวข้อต่าง ๆ
ทำการอธิบายให้เห็นว่า Object-Oriented Programming เป็นอย่างไร
มีอะไรที่ก่อให้เกิดปัญหาบ้าง
แล้ว DO เข้ามาช่วยแก้ไขหรือลดปัญหาเหล่านั้นอย่างไร
แน่นอนว่า ก็ย่อมมีทั้งข้อดีและข้อเสียเช่นกัน

Data Oriented Programming (DO) คืออะไร ?

มันคือแนวทางที่เรียบง่ายและไม่ก่อให้เกิดความซับซ้อนจนเกินไป
แน่นอนว่า เป็นอีกแนวทางของการพัฒนาที่ไม่ค่อยมีการสอนหรือพูดถึงเท่าไร
โดยที่จะเรียนรู้ DO นั้นควรที่จะ unlearn
หรือลืมสิ่งที่เรียนและรู้มาไปก่อน

ในการออกแบบตามแนวทางของ DO นั้น

เน้นไปที่ data collections
ประกอบไปด้วย data ที่ไม่สามารถถูกแก้ไขหรือเปลี่ยนแปลงได้ (immutable data)
ส่วน data นั้นจะถูกจัดการผ่าน function หนึ่ง ๆ 
ซึ่งภายใน function นั้น ๆ สามารถใช้งาน data collection อื่น ๆ ได้
ไม่จำเป็นต้องทำงานกับ data หนึ่ง ๆ ไป
จะเรียก function เหล่านี้ว่า generic function

สิ่งที่ DO ให้ความสำคัญมาก ๆ คือ

• Mutation of data คือ การแก้ไขหรือเปลี่ยนแปลง data
• The coupling of code and data คือ การผูกมัดระหว่าง code ที่ทำงานกับ data

ถ้า data มีการเปลี่ยนแปลง และ code กับ data ผูกมัดกันอย่างมาก
ผลที่ตามมาคือ ความซับซ้อนของระบบนั่นเอง
ทั้งกระบวนการทำการแก้ไขข้อมูล  ว่าต้องเป็นอย่างไร
ใครบ้างที่ได้รับอนุญาต
ยิ่งการทำงานแบบ multi-thread แล้ว ยิ่งต้องสร้างตัวจัดการมาอีกมากมาย
จะดีกว่าไหม ถ้าไม่ให้เปลี่ยนแปลงไปเลย

ข้อมูลพื้นฐานของ DO คือ entity

ซึ่งมันคือ data collection ที่เป็น immutable
โดย collection มันก็คือ dictionary data structure
ที่ประกอบไปด้วย key กับ value
ยกตัวอย่างเช่น

ข้อมูลชุดนี้ จะถูกจัดการผ่าน generic function
แน่นอนว่า ข้อมูลชุดนี้ไม่ต้องมี blueprint ในการสร้าง

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

หลาย ๆ คนที่ผ่าน DO อาจจะบอกว่ามันคือ Functional Programming(FP) ชัด ๆ
แน่นอนว่า มันใกล้เคียงกัน
เพราะว่าใช้แนวคิดเดียวกัน
แต่ใน DO ไม่จำเป็นต้องมี function
เนื่องจากเน้นไปที่ data เป็นหลัก
ที่สำคัญ DO สามารถนำไปใช้ได้กับภาษาต่าง ๆ ทั้ง OO และ FP ได้เลย

แนวคิดหรือ Principles ของ DO ประกอบไปด้วย

• Separate code from data คือการแยก code ทำงานออกจาก data
• Model entities with generic data structure
• Data is immutable คือ data จะไม่มีการเปลี่ยนแปลงหรือถูกแก้ไขนั่นเอง
• Data is comparable by value
• Data has a literal representation

โดยจะสรุปแต่ละเรื่องในบทความต่อไป

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

ไม่ใช่โลกนี้ไม่ได้มีคำตอบเดียว
แต่รู้ว่าบาง คำถาม ก็ไม่มีคำตอบ
ถ้ามัวแต่นั่งนิ่ง ๆ แล้วคิดหาคำตอบ
จะไม่เจอ

การลงมือทำ อาจจะนำมาซึ่งคำตอบ
ตอบว่า อย่าถามเลย
ลงมือทำดีกว่า

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

ถ้าใครติดตามข่าวของ GitHub เรื่องการเปลี่ยน branch หลัก
จาก master มาเป็น main มาบ้าง
จะรู้ว่าในตอนนี้ทาง GitHub ได้ทำการ rollout ระบบออกมาแล้ว
ดังนั้นทุก ๆ repository จะมี branch หลักชื่อว่า main ให้โดย default แล้ว

ถ้าใครรู้สึกเบื่อกับการสร้าง Gist ผ่าน web แล้ว มาลองสร้างผ่าน GitHub CLI กัน ?
โดยที่ Gist นั้นคือ หนึ่งบริการสำหรับ share code แบบง่าย ๆ ของ GitHub
ที่สำคัญสามารถสร้างได้แบบ private หรือ public
สามารถ share/fork/comment ได้หมด
แถมยังนำไปใส่ใน blog/article ต่าง ๆ ได้อีกด้วย
ถือว่าเป็นเครื่องมือที่นักพัฒนาไม่ควรพลาด

แต่การสร้างผ่าน web ดูจะธรรมและน่าเบื่อไปหน่อย !!
จึงแนะนำให้ลองมาใช้ผ่าน GitHub CLI กัน
การใช้งานก็ง่ายสุด ๆ คือ

เพียงเท่านี้ก็สร้าง Gist ได้แล้ว จากไฟล์ที่เรามีบนเครื่อง

ปัญหาที่เจอในการ run คำสั่งใน commandline คือ
ในการแสดงผล output จะมี % ออกมาที่ท้ายบรรทัดเสมอ
จะแก้ไขอย่างไรดี

การแก้ไขปัญหา
ทำการกำหนด environment variable ดังนี้

จบ !!

ใน VS Code นั้นมีปัญหาหนึ่งของทีมคือ
การ configuration ค่าต่าง ๆ ใน VS Code ให้เหมือนกัน
หนึ่งในวิธีการที่ใช้งานแล้วชอบมาก ๆ คือ EditorConfig
ช่วยทำให้สามารถจัดการ configuration ต่าง ๆ ได้ง่ายและสะดวกขึ้น
สามารถติดตั้งและใช้งานเลย EditorConfig for VS Code

ใน JUnit 5 นั้นได้เพิ่มความสามารถมากมาย
ช่วยทำให้การเขียนชุดทดสอบด้วยภาษา Java ง่ายขึ้นเยอะ
จึงทำการสรุปความสามารถที่น่าสนใจไว้นิดหน่อย
ที่น่าจะใช้งานกันเยอะ ประกอบไปด้วย

• @DisplayName
• @Disabled
• @Nested หรือ Nested test
• @Tag
• @ParameterizedTest
• Assertion

มาดูรายละเอียดเรื่องกัน

เรื่องที่ 1 Display Name

ใช้สำหรับการตั้งชื่อของ test case ผ่าน anotation ชื่อว่า @DisplayName
ช่วยทำให้เราสามารถตั้งชื่อ test case ได้ง่ายและสะดวก
รวมทั้งสามารถเขียนอธิบายในรูปแบบของการเล่า
และอธิบายเรื่องราวของ test case นั้น ๆ ได้ชัดเจนมากยิ่งขึ้น

สุดท้ายชื่อ test case ในส่วนนี้
จะแสดงผลในส่วนของ test report อีกด้วย
อีกอย่างสามารถใส่พวก space bar, emoji และ สัญลักษ์ต่าง ๆ ได้

เรื่องที่ 2 Disable Test

คือการใส่ annotation ชื่อว่า @Disabled
สำหรับการบอกว่า ไม่ทำการทดสอบ
ใส่ได้ทั้งระดับ class (test suite) และ method (test case) ได้เลย
ที่สำคัญ สามารถใส่เหตุผลของการใส่ Disable ได้อีกด้วย
ทำให้ทีมเข้าใจว่าทำไมถึง disable  !!

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

เรื่องที่ 3 Nested test

Nested test/class หรือ inner class นั้น
ช่วยให้เราสามารถจัดกลุ่มของ test class ที่เกี่ยวข้องกันอยู่ด้วยกัน
ทำให้ทำความเข้าใจกับชุดการทดสอบได้ง่ายขึ้น
โดยใช้งานผ่าน annotation ชื่อว่า @Nested

Nested test สามารถเข้าถึงตัวแปรระดับ class จาก class หลักได้
นั่นคือการ share data ระหว่างกัน

เรื่องที่ 4 Tag

Tag นั้นสร้างมาเพื่อแทนที่ Category ใน JUnit 4
เพื่อทำการแบ่งกลุ่มของการทดสอบ
ทั้งในระดับ class และ method ใช้งานผ่าน annotaion ชื่อว่า @Tag

เรื่องที่ 5 Assertion

Assertion นั้นใช้สำหรับการตรวจสอบว่า
ผลการทำงานเป็นไปตามที่เราคาดหวังหรือไม่
ซึ่งในทุก ๆ test case ต้องมีเสมอ

โดยที่ JUnit 5 นั้นได้ทำการสร้าง assertion ขึ้นมาใหม่
และสามารถใช้งานร่วมกับ Lambda สำหรับ Java 8 ขึ้นไปอีกด้วย
ช่วยปรับปรุงประสิทธิภาพของการทดสอบให้ดีขึ้น
รวมทั้งยังมี assertion ใหม่ ๆ ที่ปรับปรุงมาจาก JUnit 4 เช่น

• assertionThat()
• assertionTimeout()
• assertionTimeoutPreemptively()
• assertThrow()

เรื่องที่ 6 Parameterized test

สำหรับการทดสอบแบบ Data-Driven นั้น
ใน JUnit 5 ได้เปลี่ยนแปลงให้ใช้งานง่ายขึ้นกว่า JUnit 4 มาก
สามารถกำหนดข้อมูลสำหรับการทดสอบในแต่ละ test case ได้เลย

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

ลองมาเขียนชุดการทดสอบด้วย JUnit 5 กัน
วันนี้คุณเขียน test แล้วหรือยัง ?