จากบทความเรื่องของ DevOps และ Cloud Trend 2021 นั้น
มีเรื่องหนึ่งที่น่าสนใจมาก ๆ คือ
Cloud-Native Is about Culture, Not Containers
ซึ่งทำการอธิบายว่า เครื่องมือและเทคโนโลยีมันเปลี่ยนไปเร็วมาก
แต่สิ่งหนึ่งที่มักจะละเลยคือ culture ของทีม
ว่าเรากำลังทำอะไรกัน ทำไปทำไม มีประโยชน์อะไร
มากกว่าเราใช้เครื่องมืออะไร หรือ ซื้ออะไรมาใช้ดี ?

ยกตัวอย่างเช่น ทำไมถึงต้องใช้ Cloud ?

• Cost คือค่าใช้จ่ายลดลง
• Elasticity คือการ scale ขึ้นหรือลงตามการใช้งาน ซึ่งช่วยลดค่าใช้จ่าย
• Speed คือความเร็วของการทำงาน และความเร็วของ hardware

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

หรือบางครั้งก็เปลี่ยน Architecture มาใช้ Microservices

ทำให้เกิดปัญหาในการพัฒนา การทดสอบ และการ deploy
ตลอดจนการ monitoring ที่นากลำบากขึ้นมาก ( Observability)
พังมาหาที่ผิดไม่เจอกันเลย
ต่างทีมก็ดูแลแต่ service ของตนเอง
ไม่ได้สนใจภาพรวม
คำถามคือ ใช้เพื่อแก้ไขปัญหา หรือ สร้างปัญหากันแน่ ?
ต้นเหตุของปัญหาคืออะไร

หรือใช้งาน CI/CD system ก็เริ่มต้นด้วยคำถามว่า ใช้เครื่องมืออะไร ทำ CI/CD ?

ทำไมไม่เริ่มจากคำถามว่า ทำไมเราถึงต้องมี CI/CD ?
ปัญหา หรือ ความต้องการคืออะไร
ก่อนที่จะคุยกันเรื่องของ คน ขั้นตอนการทำงาน และเครื่องมือต่อไป
หนักกว่านั้น มี buzz word ต่าง ๆ เพิ่มเข้ามาอีก
ทั้ง DevOps, DevSecOps, GitOps, MLOps, DataOps และอื่น ๆ อีกมากมาย
เยอะไปหมด เราเข้าใจไหมว่า ทำไม ?
ต้องพูดคุย และ สื่อสารกันให้เข้าใจก่อนไหม ?
น่าคิดนะ ...

มีโอกาสได้แบ่งปันประสบการณ์ ของการเขียน program อีกครั้ง
จึงคิดว่า จะแบ่งปันเรื่องพื้นฐานดีกว่า (พอดีทำเป็นแต่เรื่องพื้นฐาน)
นั่นก็คือ การเขียน code ที่น่าจะดีขึ้นกว่าเดิม ไม่มากก็น้อย
ประกอบด้วยแนวคิดต่าง ๆ เหล่านี้
น่าจะพอมีประโยชน์บ้าง

เรื่องที่ 1 ในแต่ละ method พยายามเขียน code ให้ชิดซ้าย

นั่นคือลดการเขียน code ที่มี condition ซ้อนกันไปเรื่อย ๆ
หรือมี indentation ลึกเข้ามาเรื่อย ๆ
ทำให้แต่ละ method ทำงานไม่เยอะ
น่าจะทำให้อ่านเข้าใจง่ายมากยิ่งขึ้น

เรื่องที่ 2 อย่าใช้ . เยอะ เช่น A.B.C ไปเรื่อย ๆ

แบบนี้จะมีปัญหาเยอะมาก ๆ เมื่อมีการเปลี่ยนแปลง
นั่นคือ เพื่อให้ลดผลกระทบ
รวมทั้งเป็นการซ่อน implementation ที่ดี

เรื่องที่ 3 เรื่องการตั้งชื่อ ต้องสื่อสารให้ชัดเจน

แน่นอนว่า ชื่อหรือคำ ต้องสัมพันธ์กับ requirement หรือ business

เรื่องที่ 4 ขนาดของ file/class/method ต้องไม่เยอะ

อาจจะต้องกำหนดร่วมกัน เช่น
ถ้าเกิน 100 บรรทัด มันเริ่มมีปัญหาไหม ?

เรื่องที่ 5 ควรต้องใช้ fail fast หรือ early return ใน method

ในการเขียน code แต่ละ method นั้น
เพื่อแยกส่วนการทำงานระหว่าง
การทำงานหลัก และ การตรวจสอบ (validation) ออกจากกัน
แนะนำให้ทำการตรวจสอบสิ่งที่ไม่ตรงเงื่อนไขออกไปก่อน
สุดท้ายเหลือไว้เพียง การทำงานหลัก

เรื่องที่ 6 จำนวน instance variable ของแต่ละ class ต้องไม่เยอะ

ยกตัวอย่างเช่น ไม่เกิน 2-3 ตัว
เป้าหมายเพื่อลดจำนวนของ dependency ของ class นั้น ๆ ลงไป

ปัญหาที่พบเจอสำหรับการจัดเก็บข้อมูลใน Redis
นั่นก็คือ การเลือก data structure ที่ไม่เหมาะสมกับการใช้งาน
ส่งผลให้การทำงานในแต่ละ operation สูงขึ้น
ส่งผลให้ Redis รับงานได้น้อยลง
เนื่องจาก Redis ทำงานแบบ Single Thread นะ (แต่ก็ปรับปรุงมาเยอะ)
ดังนั้นจึงกลับมาดูที่ต้นเหตุ รวมทั้งความรู้พื้นฐานกันหน่อย

โดยปกติข้อมูลที่เก็บใน Redis จะมี Data model แบบ Key-value

ซึ่ง value สามารถมีรูปแบบของข้อมูลหลัก ๆ ดังนี้

• Primitive data type เช่น string และ number
• Data structure ประกอบไปด้วย List, Set, Hash, SortedSet เป็นต้น

โดยส่วนใหญ่เราจำเป็นต้องทำความเข้าใจว่า
ระบบงานของเรานั้น ต้องการใช้ข้อมูลอย่างไร
เพื่อให้เลือก data structure ได้อย่างเหมาะสม
เนื่องจากการเข้าถึงข้อมูลใน Redis นั้น
จะมีการบอกและอธิบายไว้ชัดเจนว่ามี Big O เท่าไร

ยกตัวอย่างเช่น การทำงานของ SORT operation

จะมี Big O คือ O(N+M*(log M)) นั่นคือ
มีการทำงานตามจำนวนข้อมูลเป็นอย่างต่ำ

ดังนั้นจะดีกว่าไหม ถ้าเราลดเวลาการทำงานลงไป
ด้วยการเก็บข้อมูลที่ไม่ต้องมา SORT แบบนี้
หรือเป็นการเก็บข้อมูลแบบที่ SORT ให้เลยตั้งแต่แรก
นั่นคือการใช้ SortedSet
จากนั้นดึงข้อมูลก็ใช้ ZRANGE operation
ที่มี Big O เพียง O(M*(log M))
ซึ่งน่าจะงานได้มีประสิทธิภาพกว่าไหม ?

ดังนั้นเรื่องของการออกแบบ ต้อง สัมพันธ์การ use case ของระบบ

ไม่ใช่เพียงแค่เก็บในสิ่งที่ทำงานได้รวดเร็วเท่านั้น
เพราะว่า แทนที่จะทำงานได้เร็ว กลับกลายเป็นคอขวด
เพราะว่าจะเก็บอย่างเดียว
โดยไม่ได้สนใจการนำมาใช้งาน ว่ามี operation cost มากเพียงใด

ใน Elasticsearch 7.14 นั้นได้เพิ่ม field type ใหม่ขึ้นมา
ชื่อว่า match_only_text
สร้างขึ้นมาเพื่อนำมาใช้เก็บข้อมูล log ต่าง ๆ โดยเฉพาะ
สามารถ query ได้เหมือนกับ type text
เพียงแต่ไม่สนับสนุนการ sorting/scoring
แต่ก็มีข้อจำกัดเช่นกัน ในการใช้บาง query เช่น span query
หรือใช้แล้วช้ากว่า type text เช่น phase และ interval query
ในส่วนการ aggregation บางอย่าง ก็มีข้อจำกัด

match_only_text มีเป้าหมายเพื่อ

• ลดเนื้อที่จัดเก็บข้อมูลใน Disk ลง นั่นคือการลกค่าใช้จ่าย
• ลดการทำ indexing ซึ่งใช้ CPU เปลืองมาก ๆ และขนาดจอง index จะเล็กลง
• ลดเวลาในการ query ลงไป เนื่องจากไม่ต้องคำนวณ score ที่มีขั้นตอนเยอะ แต่ไปใช้ timestamp มาจัดเรียงแทน (จากใหม่ไปเก่า)

วันนี้เพิ่งเห็นว่า ใน Elasticsearch 8 จะมี feature หลาย ๆ อย่าง
ที่อาจจะทำให้ระบบงานมีปัญหาขึ้นมาได้
หนึ่งในนั้นคือ action.destructive_requires_name มีค่าเป็น true
นั่นคือ ไม่สามารถลบ index แบบ wildcard ได้อีกแล้ว โดย default
ยกตัวอย่างเช่น DELETE * เป็นต้น

หรือบางระบบอาจจะมีการลบ index ด้วย widecard เช่น
การลบ index ของเดือนสิงหาคม ด้วย DELETE logstash-202108*
ทำให้ไม่สามารถใช้งานได้ด้วยค่า default

วิธีการแก้ไข อาจจะต้องมาแก้ค่าให้เป็น false
หรือไปใช้งาน Index Lifecycle Management แทนกันได้แล้ว

ลองไปดู Release Note ใน Alpha version ก่อนได้
จะได้เตรียมตัวรับมือได้ทัน

วันนี้เขียน Mobile app ด้วย Flutter เลยไปเจอ code ส่วนหนึ่งที่เกิดปัญหา
คือ เมื่อมีการเปลี่ยน state แล้วพบว่า app ทำการ render ใหม่ทั้งหน้า
แน่นอนว่า ทำให้การ render ช้า หรือ performance แย่ลง
ทีมพัฒนามองว่าเป็นเรื่องปกติแต่ผมคิดว่า ไม่น่าจะเป็นเรื่องที่ปกติ
ดังนั้นจึงมาแก้ไขกันหน่อย

เริ่มต้นมาดูระบบก่อนว่า ทำงานอย่างไร ?

• ในหน้าจะมี state หลายส่วน ซึ่งทำการดึงข้อมูลจาก API มาแสดงผล
• โดยทำการเรียก API 4-5 ตัว (ไม่รู้จะเรียกเยอะไปไหน)
• การทำงานจะทำการดึงข้อมูลมาทั้งหมดก่อน แล้วจึงทำการ render

ผลที่ตามมาคือ กว่าจะ render หน้านี้เสร็จ ใช้เวลานานมาก
หรือเมื่อมีการแก้ไขบาง state ก็จะ render ทั้งหน้า

ดังนั้นจึงทำการแก้ไขปัญหานี้นิดหน่อย

ถ้าไม่คิดอะไรมาก ก็ปรับเปลี่ยน API ให้น้อยลง และให้ทำงานเร็วขึ้น !!
แน่นอนว่า ไม่ทำ ซึ่งจะอ้างว่า มันใช้เวลาเยอะ !!
ดังนั้นมีทางเดียวที่ทำได้คือ ฝั่ง mobile app ที่ใช้ Flutter นั่นเอง

โดยทำการเปลี่ยนมาใช้งาน StreamBuilder และ FutureBuilder Widget ไปเลย
เพราะว่าทั้งสองตัวนี้ ออกแบบมาให้ทำงานกับข้อมูล
ที่มาแบบ asynchronous และ stream
ที่สำคัญคือ จะทำการ render เฉพาะ Widget นั้น ๆ ด้วย
ไม่ได้ทำการ render ทั้งหน้าแบบเดิม
รวมทั้งไม่ต้องรอให้ดึงข้อมูลเสร็จก่อน render อีกด้วย

คำถามที่ตามมาคือ ใช้อะไรดีระหว่าง StreamBuilder vs FutureBuilder Widget ?

ตามจริงทั้งคู่มีพฤติกรรมการทำงานเหมือนกัน
คือจะ listen การเปลี่ยนแปลงของข้อมูล
ถ้ามีการเปลี่ยนแปลงก็จะทำการ build และ render widget ใหม่
แต่ต่างกันดังนี้

• FutureBuilder จะรับข้อมูลกลับมาเพียงครั้งเดียว เช่นข้อมูล API เป็นต้น
• ส่วน StreamBuilder มากกว่า 1 ครั้ง เพราะว่าข้อมูลจะค่อย ๆ มา เช่นข้อมูล Location, VDO, Sound เป็นต้น

เพียงเท่านี้ก็สามารถแก้ไขปัญหาที่เจอได้แล้ว

หลัง ๆ มาเริ่มใช้งาน GitHub Actions เยอะขึ้น
แต่การแก้ไข pipeline และใช้งานไม่สะดวกเท่าไร
รวมทั้งยังมี limit ของเวลาการ run อีกด้วย
ดังนั้นเพื่อลดปัญหาและข้อจำกัดลงไป
จึงทำการ run GitHub Actions บน local ก่อนดีกว่า
ซึ่งเครื่องมือที่ใช้งานคือ Act

ปล. ในการ run Act นั้นต้องมี Docker deamon ด้วยเสมอนะ !!

โดยการใช้งานง่ายมาก ๆ

เพียงทำการติดตั้ง Act
จากนั้นทำการสร้างไฟล์ pipeline ของ GitHub Actions
โดยในตัวอย่าง ทำการสร้าง pipeline ของระบบงานที่พัฒนาด้วยภาษา Go ดังนี้

ทำการ run ดังนี้

เพียงเท่านี้ก็สามารถ run ได้แล้ว
ถือว่าตรงกับความต้องการมาก ๆ

ตัวอย่างของ source code

ลองไปดูระบบของ PopCat.click แล้ว เห็นว่าใช้งาน

• Local storage
• Session storage
• Cookies

สำหรับจัดเก็บข้อมูลต่าง ๆ ของระบบ
สิ่งที่สงสัยคือ Local storage ต่างจาก Session storage อย่างไรบ้าง ?

จากเอกสารอธิบายว่า ทั้งคู่นั้นจะ implement มาจาก interface ชื่อว่า Storage
ใช้สำหรับจัดเก็บข้อมูลต่าง ๆ ในรูปแบบของ Key-value
โดยข้อมูลเหล่านี้จะไม่ถูกส่งไปยัง server
แยกเก็บตาม protocol ที่เข้าใช้งานทั้ง HTTP และ HTTPS
บน modern browser เท่านั้น

โดยที่ความต่างคือ Session storage จะเป็นข้อมูลที่มาอายุ (expire data)
และจะถูกลบออกไปเมื่อทำการปิด browser หรือ ปิด tab นั้น ๆ ไป
ดังนั้นข้อมูลจะจัดเก็บในแต่ละ browser/tab ก็จะแยกกันไป
ส่วน Local storage จะตรงข้ามกันเลย

ปล. ทั้งคู่ไม่ควรเก็บข้อมูลพวก sesitive data เพราะว่าไม่ปลอดภัย !!

จากการแบ่งปันความรู้เรื่องพื้นฐานของ Docker ไป
มีคำถามที่น่าสนใจเรื่องของ Docker Restart Policy
ที่กำหนดในการสร้าง container ทั้งใน command line และ Docker compose file
ว่ามันคืออะไร จึงทำการสรุปแบบคนใช้งานพื้นฐานไว้นิดหน่อย

จากเอกสารของ Docker อธิบายไว้ว่า

• No คือค่า default นั่นหมายความว่า จะไม่ restart แบบอัตโนมัติเมื่อ container อยู่ในสถานะ Exit
• On-failure จะทำการ restart ถ้า container อยู่ในสถานะ exit พร้อมกับ exit code ไม่เท่ากับ 0 นั่นคือ exit แบบมีปัญหานนั่นเอง โดยสามารถกำหนดค่าของ max retry ได้อีกด้วย
• Always จะทำการ restart container เมื่ออยู่ในสถานะ exitให้เสมอ หรือทำการ restart Docker deamon แล้วก็จะ start containerให้ด้วย
• Unless-stopped จะเหมือน Always แต่จะไม่รวม container ที่ทำการ stop ก่อนการ restart หรือ stop Docker deamon นั่นเอง

ดังนั้นลองกำหนดค่า Restart policy ให้ตรงตามที่ต้องการได้

เพิ่งเห็นว่า Go 1.17 ตัวเต็ม ๆ ถูกปล่อยออกมาแล้ว
ก็เลยทำการ update ดู
จากนั้นทำการ run test ก็ผ่านทั้งหมด
และสิ่งที่เห้นได้ชัดเจนคือ ขนาดของ binary file ที่ได้จากการ build
มีขนาดเล็กลงไปอีกแล้ว

โดยทดลองกับ Echo จะพบว่า
มีขนาดเล็กลงมาจาก Go 1.16.7 ซึ่งมีขนาด 7.1 MB
ลดลงมาเหลือ 6.5 MB ใน Go 1.17
น่าสนใจมาก ๆ

ไป Download มาใช้งานกันได้แล้ว

คำถามที่น่าสนใจ สำหรับผู้เริ่มต้น programming ที่มักจะพบเจอประกอบไปด้วย

• เริ่มอย่างไรดี
• เริ่มด้วยภาษา program อะไรดี
• สิ่งที่เลือกมันดีหรือไม่ มันยากหรือง่าย

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

การเรียนรู้มีทั้งการเรียนรู้ด้วยตัวเอง หรือ เรียนจากผู้อื่น

บางคนก็ลงเรียนผ่าน course online ที่มีอยู่อย่างมากมาย
หรืออ่านจาก tutorial หรือบทความต่าง ๆ บน internet
ซึ่งเริ่มได้แบบฟรี ๆ ไม่เสียเงิน
เสียเพียงเวลาที่ต้องลงไปกับมัน
แต่เรียนอย่างเดียวก็ได้รู้เท่านั้น
จำเป็นต้องลงมือทำกับงานจริง ๆ อีกด้วย
เพื่อให้ได้เห็นมุมมองอื่น ๆ ซึ่งมันคือการเก็บประสบการณ์

แต่ว่าไม่ใช่ต้อง programming เพียงอย่างเดียว

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

ต่อมาคำถาม เริ่มด้วยภาษา program อะไรดี

ตอบได้ยากมาก ๆ
เพราะว่า ตอนที่ผมเริ่มเรียนก็เรียนตามที่อาจารย์สอนก็เรียน ๆ ไป
ตามหลักสูตร หรือ ตามรายวิชานั้น ๆ
แต่ปัจจุบันมีให้เลือกเยอะมาก ๆ
เช่น Python, JavaScript, Go, Rust, Java, C# เป็นต้น
จะเลือกภาษาไหน อาจจะต้องตั้งเป้าหมายก่อน
ซึ่งไม่ใช่แค่ภาษา แต่ต้องคิดถึงว่า เราต้องการหรือแก้ไขปัญหาอะไร

เช่น อยากทำระบบการลงทะเบียนผ่าน web

ดังนั้นน่าจะต้องเริ่มที่เรื่องของ HTML + CSS + JavaScript ก่อนไหม
เพื่อสร้างระบบ web application เพื่อลงทะเบียนก่อน
จากนั้นค่อยมาดูว่า จะจัดเก็บข้อมูลการลงทะเบียนใน database อะไร
จะใช้ภาษาอะไรที่ เช่น Node.JS ไหม
นี่คือการตั้งเป้าหมายหรือปัญหา

เมื่อตั้งเป้าหมายที่ชัดเจนแล้ว
ก็ลงมือศึกษาในแต่ละส่วนเพื่อแก้ไขปัญหา
ยังไม่จำเป็นต้องเรียนรู้ภาษา program ทั้งหมด
เรียนหรือศึกษาเท่าที่จะแก้ไขปัญหาให้ได้ก่อน
มันน่าจะตอบโจทย์มากกว่า

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

ฝึกให้เยอะ คิดให้บ่อย ลงมือทำอย่างต่อเนื่อง
มีพื้นฐานที่ดี การต่อยอกหรือไปศึกษาเพิ่มเติมจะง่ายขึ้นอย่างมาก

ปล. ส่วนจะใช้เครื่องอะไร นั่นก็แล้วแต่กำลังที่มีเลยครับ

เพิ่งคุยกับทีมพัฒนา Mobile App ด้วย Flutter มา
เรื่องของแนวทางการปรับปรุงการพัฒนา App นิดหน่อย
โดยปัญหาที่เริ่มเห็นกันมาก ๆ และส่งผลรุนแรงขึ้น
คือการดูแลรักษา App
ทั้งในเรื่องของการเพิ่ม แก้ไขความสามารถต่าง ๆ
รวมทั้งแก้ไข issue หรือ bug ที่เจอหรือรับแจ้งเข้ามา
แน่นอนว่า ต้องการ feedback ที่รวดเร็วพร้อมกับคุณภาพที่สูง
ดังนั้นจึงพูดคุยหาแนวทางกันหน่อย

ปัญหาแรกที่เจอคือ แก้ไขแล้วไม่รู้ว่าไปกระทบการทำงานส่วนไหน ?

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

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

ดังนั้นเรื่องต่อมาคือ การปรับปรุงโครงสร้างของ App ให้ดูแลง่ายขึ้น

ซึ่งตรงนี้จะมีทั้งการแบ่งส่วนต่าง ๆ ตามหน้าที่การทำงานยกตัวอย่างเช่น

• ส่วนของการแสดงผลที่แยกเป็นชิ้น ๆ ตามหน้าที่การทำงาน เพราะว่าปัจจุบันพวก god class/method เยอะมาก ๆ
• อะไรที่ใช้ซ้ำ ๆ ก็แยกออกมา เช่นพวก string, coloe code และ style

เมื่อไปดูโครงสร้างของ App ก็พบว่า มีปัญหาเรื่องของการจัดการ state อีก

ทำให้ทีมต้องมาช่วยกันดูว่า
App ที่กำลังพัฒนาและดูแลกันนั้น ควรจะจัดการ state รูปแบบไหนดี
และยอมรับกันแล้วว่า ที่เป็นอยู่ ยิ่งก่อให้เกิดปัญหา
ตรงนี้ยังฟันธงไม่ได้ว่าจะใช้วิธีการไหน
แต่ให้ทุกคนช่วยกันทำ POC มาในแต่ละตัวที่เลือกกันมา
จากนั้นมา demo และลอง implement กันอีกที
แล้วค่อยมาเลือกกันต่อไป !!

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

ไปเจอรูปอธิบายการทำงานของ Web
เมื่อเราทำการกรอก URL ใน web browser
จากนั้นทำการกดปุ่ม enter มันเกิดอะไรขึ้นบ้าง
ก่อนที่เราจะเห็นผลของการทำงาน
ซึ่งนำมาจากที่ Dev.to

ไปเขียนใน Go community พูดถึงเรื่องของ
HTTP Response Status Code 418 :: I'm a teapot
ซึ่งมีการ implement ไว้ใน package net/http ด้วย
เลยไปดูหน่อยว่า RFC ตัวนี้มันเป็นมาอย่างไร ?

ได้ความว่ามันคือ RFC 7168 ที่ออกมาในวัน April Fool Day นั่นเอง
ซึ่งไม่ได้ตั้งใจให้ใครไป implement เพื่อสนับสนุน
ดูแล้วจริงจังกันมาก ๆ
แต่ในภาษา Go สนับสนุนด้วย
ส่วนภาษาอื่น ๆ ยังไม่ได้ไปดูว่าสนับสนุนไหม

ตัวอย่าง Easter Egg ใน google คือ Teapot

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

ปล. พบว่าไม่ทำ caching กันด้วยนี่สิ !!
สงสัยว่า จังหวัดเปลี่ยนบ่อย

คำถามที่น่าสนใจ
จากทีมที่เริ่มนำแนวทางของการทดสอบแบบอัตโนมัติมาใช้งาน
ทั้ง Unit testทั้ง API testทั้ง UI test
หรือจะเป็น integration, component และ contract test ก็ตาม
ปัญหาที่มักจะพบเจอประกอบไปด้วย

• ใช้เวลาในการทดสอบเยอะขึ้นเรื่อย ๆ เนื่องจากจำนวน test เยอะขึ้น
• มี test case จำนวนมากที่ผ่านบ้าง ไม่ผ่านบ้าง ทั้ง ๆ ที่ไม่ได้เปลี่ยนแปลงอะไร (Flaky test)

เราจะแก้ไขและปรับปรุงอย่างไรดี ?

ปัญหาที่จะแก้ไขคือ เวลาการทดสอบเยอะ

สาเหตุมาจากจำนวนการทดสอบในส่วนของ functional test เยอะเกินไป
ทั้ง UI, API และ integration test ต่าง ๆ
ดังนั้นจำเป็นต้องกลับมาดูว่า
test case อะไรบ้างที่จำเป็น และ ไม่จำเป็นต้องมีก็ได้
หรือทดสอบใน level ต่ำลงมา
เช่น component, contract และ unit test มากขึ้น

รวมทั้งการปรับปรุงการทดสอบให้เร็วขึ้น

ทั้งเรื่องของ การเขียน script
ทั้งเรื่องของ การ run test ทั้ง parallel และ distributed testing

อีกปัญหาที่พบมาก ๆ คือ การเตรียมระบบ
เพื่อทำการทดสอบทั้ง infrastructure, software และ data ที่ต้องใช้
ใช้เวลาไปเกือบ 50% ของการทดสอบ
ดังนั้นจึงต้องปรับเปลี่ยนรูปแบบของการเตรียมระบบ
ทั้งเรื่องของ architecture ที่เล็กลง ซับซ้อนน้อยลง เป็นต้น

ถึงแม้ว่าจะลดจำนวนของ test cae ลงไป

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

Dart 2.14 นั้นถูกปล่อยออกมาพร้อมกับ Flutter 2.5
ซึ่งมีความสามารถที่น่าสนใจเพิ่มเติมและปรับปรุง
จึงทำการสรุปไว้นิดหน่อยยกตัวอย่างเช่น

• สนับสนุน Apple silicon
• Standard lint สำหรับการทำ code analysis, code style และ format
• ปรับปรุงความเร็วของ Pub tool สำหรับจัดการกับ dependency ต่าง ๆ
• จากการปรับปรุงการทำงานของ Pub tool ช่วยทำให้การทดสอบผ่าน $dart test เร็วขึ้น
• การ build ก็ทำการแบบ parallel อีกด้วย

ส่วนความสามารถใหม่ ๆ นั้นไม่เยอะ

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

• เพิ่ม tripple shift operator (>>>)
• ใน argument ของ function สามารถส่ง Annotation type ได้

และยังมีสิ่งที่ไม่สนับสนุนหรือเอาออกไปแล้ว

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

• ไม่สนับสนุน ECMAScript5
• สำหรับ dartfmt และ dart2native ทำการแจ้ง deprecated
• สำหรับ Dart VM native extension ทำการแจ้ง deprecated เนื่องจาดใช้งาน Dart FFI แทน

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

ปัญหาแรกคือ รีบทำจนเกินไป

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

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

ปัญหาต่อมาคือ ออกแบบโดยไม่สนใจคนใช้งานเลย

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

ดังนั้นควรต้องรับ feedback มาปรับปรุงหรือไม่
หรือต้องย้อนกลับไปตั้งแต่การออกแบบก่อนไหม
ทั้งเรื่องของรูปแบบ request/response ที่มีโครงสร้างที่ดี

อีกปัญหาคือ พยายามเพิ่ม feature เข้ามาเรื่อย ๆ

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

จากบทความของ Slack เรื่อง How we design out APIs at Slack
ทำการสรุปแนวทางในการออกแบบ API ของระบบออกมาว่าเป็นอย่างไรบ้าง
เพื่อช่วยทำให้ผู้ใช้งานหรือ developer ใช้งานง่ายขึ้น
อีกทั้งช่วยให้การดูแลรักษา API ง่ายขึ้นด้วย
ซึ่งควรต้องคิดตั้งแต่การออกแบบกันเลยทีเดียว
มิเช่นนั้นแทนที่จะได้ API ที่ดีมีประโยชน์ กลับได้ของที่แย่ ๆ ออกมา
โดยมีแนวทางของการออกแบบดังนี้

1. So one thing and do it well

เมื่อเริ่มต้นออกแบบ API นั้น
อาจจะมีหลาย ๆ ปัญหาให้แก้ไข
ซึ่งอาจจะทำให้เกิดความซับซ้อน และ ยากต่อการทำความเข้าใจ
ดังนั้นแนะนำให้เลือกจาก use case หนึ่งมาทำ
เพื่อให้ focus มากยิ่งขึ้น

2. Make it fast and easy to get started

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

โดยจะเริ่มตั้งแต่การใช้งานภายใน
เช่นพนักงานใหม่เข้ามา ให้ลองทำการเปิดและลองใช้งาน API ดูว่า
ใช้งานเป็นอย่างไร เริ่มง่ายไหม เร็วไหม

3. Strive for intuitive consistency

API ต้องความสอดคล้องไปในทิศทางเดียวกันและช่วยให้เข้าใจหรือพอเดาได้ว่า API ทำงานอะไร ใช้งานอย่างไรโดยแทบจะไม่ต้องอ่านเอกสารเลยด้วยซ้ำทั้งจากชื่อของ endpointทั้งจากชื่อของ input parameterทั้งจาก output response

โดยเรื่องของ consistency จะมีอยู่ 3 level คือ

Level 1 :: Consistency with Industry standard
Level 2 :: Consistency with your product
Level 3 :: Consistency with your other API methods

4. Return meaningful errors

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

5. Design for scale and performance

เรื่องการ scale และ performance ที่ดี ก็สำคัญไม่น้อยยก
ตัวอย่างเช่น

• ของการทำ paging กับข้อมูลจำนวนมาก ๆ
• ข้อมูลที่ return กลับไปต้องไม่ซับซ้อนมากนัก หรือ ขนาดไม่ใหญ่จนเกินไป
• เรื่องการทำ rate limit ที่สมเหตุสมผล เพื่อช่วยป้องกันระบบงานให้ยังคงทำงานได้ดี

6. Avoid braking changes

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

โดยที่ Slack จะมีแนวคิดคือ
อะไรที่มัน work ในเมื่อวาน วันพรุ่งนี้ยังต้อง work อยู่เสมอ
ไม่ใช่แค่ case ปกติเท่านั้น
เรื่องของ case อื่น ๆ หรือพวก exception ต่าง ๆ ก็ต้องระวังไว้ด้วย

การแจ้งเรื่องของการเปลี่ยนแปลงต่าง ๆ
จึงต้องวางแผน และ ประกาศ หรือ ติดต่อสื่อสารให้ชัดเจนเสมอ

อีกทั้งสรุปขั้นตอนการออกแบบ API ไว้ดังนี้

ขั้นตอนที่ 1 เขียน API spce ก่อน

เริ่มจากการตั้งปัญหาที่ต้องการแก้ไขและกำหนด use case ของ API ให้ชัดเจน
จากนั้นเริ่มเขียน API spec
เพื่อทำการอธิบายสิ่งที่จำเป็นสำหรับ API
เพื่อทำให้เข้าใจสิ่งที่จะสร้างอย่างชัดเจน
ประกอบไปด้วย

• Method name
• เป้าหมายของ API
• ตัวอย่างของ request และ response รวมทั้ง error ต่าง ๆ ที่สามารถเกิดขึ้นได้

โดยการทำงานจะเป็นทีม ไม่ใช่ทำงานคนเดียว

ขั้นตอนที่ 2 ทำการ review ภายในกันเอง

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

ขั้นตอนที่ 3 ได้รับ feedback แต่เนิ่น ๆ จาก partner

จะทำการส่ง API spec ไปให้กับ partner
เพื่อให้ review และได้รับ feedback ที่เป็นประโยชน์มาก ๆ
ว่าในมุมมองของ partner นั้น API spec เหล่านี้เป็นอย่างไร
เข้าใจหรือใช้งานง่ายไหม
โดยการทำงานจะเป็นรอบสั้น ๆ ไป
เพื่อให้การออกแบบและพัฒนา API ดีขึ้นอย่างต่อเนื่อง

ขั้นตอนที่ 4 มีการทำ Beta testing

ก่อนที่จะปล่อยให้ใช้งานแบบ public
จะต้องทำ beta testing ก่อน
นั่นคือจะเลือก partner มาใช้งานก่อน (Early access)
เพื่อลองทำการ integrate และใช้งานจริง
เพื่อให้ได้ feedback กลับมาเพื่อแก้ไขและปรับปรุงต่อไปอีก

สุดท้ายแล้ว แนะนำให้ของนำไปใช้และประยุกตืให้เข้ากับ use case และทีม

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

จากการปรับเปลี่ยนโยบายการใช้งาน Docker Desktop ใหม่
สามารถอ่านรายละเอียดเพิ่มเติมได้จาก
Docker is Updating and Extending Our Product Subscriptions
ซึ่งกำหนด price plan ของ subscription
รวมทั้งเงื่อนไขต่าง ๆ ของการใช้งาน
แสดงดังรูป

แต่ผมก็ไม่แน่ใจว่าทาง Docker จะตรวจสอบจากอะไรบ้าง ?
ถ้าเราใช้งานไม่ถูกกับ subscription ที่เราเลือกใช้ !!

ก่อนหน้านี้ Docker Hub ก็เปลี่ยนโยบายการใช้งานเช่นกัน

การเปลี่ยนแปลงครั้งนี้ จะไม่กระทบกับการใช้งาน

• Docker CLI
• Docker compose

ดังนั้นใช้บน Linux ก็ยังฟรีเป็นปกติ
เพราะว่า ไม่ได้ใช้งาน Docker Desktop อะไรเลย
ส่วน Windows ก็ใช้งานบน WSL 2 ก็ไม่เสียค่าใช้จ่ายเช่น

แต่ก็มีคำถามว่า มี software อื่น ๆ มาใช้แทนที่ Docker Desktop ไหม ?

ตอบได้ง่าย ๆ คือ มี
ยกตัวอย่างเช่นพวก minikube และ portainer เป็นต้น

และเมื่อไปลองค้นหาดู ก็เจอคำแนะนำเยอะใช้ได้
ประกอบไปด้วย

• Podman
• Kind
• Lima-vm for Mac
• Rancher desktop
• Code ready container