ปัญหา
เมื่อวานมีคนถามมาว่า ใช้งาน Docker for Mac แล้ว
เจอ error exit code ว่า 137
ทำให้ container ที่ run อยู่มันตายไป
เป็นแบบนี้ตลอดเวลา เกิดขึ้นเพราะว่าอะไร ?

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

จากภาพนั้น ค่า default ของ Docker for Mac จอง memory ไว้ 2 GB
แต่ว่า container ที่สร้างขึ้นมานั้น รวมกันแล้ว
ใช้งาน memory ไปเกินที่จองไว้
จึงทำให้ Docker ต้องไป kill container นั่นเอง

การแก้ไขง่าย ๆ คือ เพิ่มการจอง memory หรือไม่ก็สร้าง container น้อย ๆ ไปนะ

จากผลรายงานจาก GitHub :: The 2020 State of the OCTO-VERSE นั้น
โดยแบ่งออกเป็น 3 เรื่องใหญ่ ๆ คือ

• Finding balance between work and play == Productivity
• Empowering healthy communities == Community
• Securing the world's software

มีสิ่งที่น่าสนใจดังต่อไปนี้

เรื่องแรกที่ได้ยินกันเยอะ ๆ คือ Top ของ programming language

ซึ่ง Python ขึ้นมาอยู่ในอันดับที่สอง โดยที่แซง Java ขึ้นมา
ส่วนอันดับ 1 คือ JavaScript
แต่อีกภาษาที่แรงมาก ๆ คือ TypeScript
ส่วนที่ตกลงมาก็คือ Java, PHP, C++, Shell 
และที่ตกลงมามาก ๆ คือ Ruby นั่นเอง

เมื่อไปดูในรายละเอียดจะพบว่า
ใน GitHub นั้นจะมี repository ที่พัฒนาด้วย
ภาษา JavaScript และ Python จำนวนมาก
ที่สำคัญ community ก็ active ด้วย

ในปีที่ผ่านมา python package ที่มีจำนวน contributor เยอะ ๆ เป็นดังนี้
สังเกตได้ว่า เป็น package เกี่ยวกับ Data Science เยอะเลย

การทำงานเป็นแบบ Remote เยอะขึ้นมาก

ยิ่งในช่วง Lockdown ยิ่งเยอะไปอีก
การหาสมดุลระหว่างการทำงานที่บ้าน + remote + การใช้ชีวิต ให้ดีขึ้น

สิ่งที่เห็นเพิ่มเติมคือ คนใช้งานมีความหลากหลายขึ้นมาก
ยิ่งในสายการศึกษา การเรียนการสอน ก็เข้ามาใช้งานมากยิ่งขึ้น
รวมทั้ง repository ที่เกี่ยวกับ COVID-19 ด้วยเช่นกัน ก็เยอะมาก ๆ

เรื่องของความปลอดภัยของ software ก็สำคัญเช่นกัน

โดยมักจะมาพร้อมกับขั้นตอนการทำงานแบบอัตโนมัติ
เพื่อให้ระบุปัญหาได้อย่างรวดเร็ว
ซึ่งใน gitHub ก็มี bot (Dependabot)
ในการตรวจสอบ dependency ในแต่ละ repository ใช้งาน
ซึ่งพบมาก ๆ ดังนี้

• JavaScript 
• Ruby
• .NET
• PHP
• Java

และส่วนมากที่พบปัญหานั้น ๆ มาจากความผิดพลาดของทีมพัฒนาเยอะมาก
ทาง GitHub ทำการตรวจสอบจากข้อมูลของ 6 ภาษา
เริ่มด้วยการดูจำนวน dependency จาก lock file

จากข้อมูลตัวอย่าง จะพบปัญหาจาก package ของภาษาต่าง ๆ ดังนี้

โดยที่ npm และ maven นำโด่งมาเลย
ส่วน composer ของ PHP และ PyPI ของ python ตามมา

ลงไปในรายละเอียดให้เห็นถึงระดับความรุนแรงของปัญหา
พบว่า npm จะนำโ่งในเรื่องของ critical และ hign

ถ้านับจากการ alert ของ Dependabot แล้ว

พบว่า Ruby เยอะสุด แต่ JavaScript ก็ตามมาติด ๆ 
ทั้งสองก็อยู่สูงกว่าค่าเฉลี่ย

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

เห็นทาง Kubernetes ประกาศ deprecated Docker แล้วใน Kubernetes 1.20.0 rc
ซึ่งก็มีบทความมาอธิบายเพียบ
หนึ่งในนั้นก็คือบทความจากทาง Docker
เรื่อง What developers need to know about Docker, Docker Engine, and Kubernetes v1.20

สิ่งที่หลาย ๆ คนกังวลคือ ไม่สนับสนุน docker ?
คำตอบคือไม่ใช่ เพียงแต่ deprecated Dockershim เท่านั้น

นั่นหมายความว่าเรายังสามารถใช้งาน

• Docker image build
• Docker image push
• Docker container run

ได้เช่นเดิม

อีกอย่างมาคนวาดภาพอธิบายให้เข้าใจง่าย ๆ ดังนี้

Understanding Kubernetes: part 38 – Kubernetes is deprecating Docker

Build != Runtime

โดยที่ docker ทำการสร้าง Image ตามมาตรฐานของ OCI อยู่แล้ว

สถาปัตยกรรมของ Kubernetes ที่ทำงานกับ Docker เป็นแบบนี้

ปัญหาที่เจอมาตลอดคือ
ความซับซ้อนของ Docker ที่มี compoponent จำนวนมาก
ยากต่อการดูแล รวมทั้งเรื่องของ security

ดังนั้น Kubernetes จึงเปลี่ยน architectureใหม่ เป็นดังนี้

โดยมีที่มาจาก Architecture improvement

Mock Service Worker คือ library สำหรับการจำลองงาน
ฝั่ง backend ที่ทางฝั่ง frontend เรียกใช้งาน
พัฒนาด้วยภาษา JavaScript
สามารถจำลองได้ทั้ง REST API และ GraphQL API

Library ตัวนี้จะใช้งาน Service Worker API ใน modern web browser
โดยทำการ intercept หรือดักจับ request ต่าง ๆ ที่ออกจาก browser นั่นเอง

ขั้นตอนการทำงานของ MSW เป็นดังรูป

ทำให้การทดสอบระบบ web application ได้ง่ายขึ้น
ไม่ว่าจะพัฒนาด้วย React, Angular หรือ Vue ก็ตาม

การใช้งานก็ง่ายมาก ๆ มีขั้นตอนดังนี้

• Import mock utility ของ MSW
• ทำการกำหนด request และ response ที่ต้องการจำลอง
• ทำการ start mock server

จากนั้นลองดูผลการดักจับ request จาก URL ที่วิ่งไปยัง GitHub.com ดังนี้

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

เพิ่งทำการ update Deno 1.6.1 มา
พบว่ามีความสามารถที่ชอบมาก ๆ คือ
Build self contained, standalone binaries
นั่นคือ output ที่ได้จากการ compile จาก Deno
จะเป็นไฟล์ binary เพียง 1 ไฟล์เท่านั้น

แน่นอนว่า ก็เป็น binary ตามแต่ละ OS นั้น ๆ ไป
ทำให้ Deno มาเครื่องมือการพัฒนาครบเลยตั้งแต่

• deno fmt
• deno lint
• deno compile

โดยขนาดของไฟล์ binary ยังมีขนาดใหญ่
จากตัวอย่างประมาณ 40 MB
แน่นอนว่า ในอนาคตมีแผนที่จะลดขนาดของไฟล์ binary ลงไปอีก
น่าจะเป็นความสามารถที่สำคัญของ Deno ต่อไป

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

สวัสดี

นั่งอ่านบทความสรุปจากผลการสำรวจ Developer survey 2020 ของ Angular
ผลที่ออกมาน่าสนใจมาก ๆ
ซึ่งน่าจะส่งผลต่อ roadmap ต่าง ๆ ของ Angular
ที่จะออกมาใน version ต่อ ๆ ไปอีกด้วยมาดูกันนิดหน่อย

สิ่งที่นักพัฒนาให้ความสนใจอย่างมาก
ประกอบไปด้วย

เรื่องแรกคือ เอกสารที่ดี ทั้ง document, article, guide และ tutorial ต่าง ๆ
เพื่อให้ง่ายต่อการเริ่มต้นศึกษา
รวมทั้งทำให้เข้าใจส่วนการทำงานได้ดียิ่งขึ้น

จากประสบการณ์ที่ใช้งาน Angular มาพบว่าเอกสารก็ดีและละเอียดมาก ๆ ด้วย

เรื่องที่สองคือ ปรับปรุงเรื่อง performance ของการทำงาน
รวมทั้ง load time ด้วย
แน่นอนว่า ในทุก ๆ version ที่ปล่อยออกมาทางทีมพัฒนา Angular
ก็ทำการปรับปรุงอย่างต่อเนื่องยกตัวอย่าง
เช่น How we make Angular fast ?
รวมทั้งเครื่องมือช่วยเหลือด้วยเช่น Angular DevTool

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

• ใช้งาน EXISTS แทน COUNT หรือ IN ไปเลย สำหรับการตรวจสอบข้อมูลว่ามีหรือไม่
• ทำการดึงข้อมูลเท่าที่จะใช้เท่านั้น ดังนั้นหลีกเลี่ยงการใช้งาน SELECT * ไปซะ
• ใช้ SELECT DISTINCT เท่าที่จำเป็นเท่านั้น หรือไม่ใช่เลยจะดีมาก ๆ เพราะคำสั่งนี้ใช้ resource เยอะมาก ๆ
• แนะนำให้ใช้ INNER JOIN มากกว่า Cross JOIN ใน Where clause เพื่อลดปัญหาเรื่อง performance สำหรับข้อมูลขนาดใหญ่
• ลดการใช้ sub-query สำหรับข้อมูลที่เกี่ยวข้องกันลงไป ให้ไปใช้การ JOIN แทน เช่น LEFT JOIN เป็นต้น
• หลีกเลี่ยงการใช้งาน wild card สำหรับการค้นหาทั้ง prefix และ suffix พร้อมกัน เช่น %keyword% บอกเลยว่าบรรลัยแน่นอน
• ลดการใช้ HAVING สำหรับกรองข้อมูลในแต่ละกลุ่มจากการ aggregation โดยให้ไปใช้ใน Where clause แทน
• ลดการ JOIN ของข้อมูลลงไป ด้วยการออกแบบในมุมมองของการใช้งานเป็นหลัก หรือลดปัญหาด้วยการทำ pre-processing หรือ data pre-stage ไว้ก่อน สำหรับพวกการทำ report ต่าง ๆ
• ในการออกแบบก็อย่า normalize มากจนเกินไป
• การเลือก data type ของแต่ละ column ให้เหมาะสม เพราะว่า ส่วนใหญ่มักจะเผื่อ เช่นพวก char, varchar และ text เป็นต้น ต้องรู้และเข้าใจก่อนว่า ข้อมูลที่เราจะจัดเก็บเป็นอย่างไร มิเช่นนั้นแล้วมันเปลือง resource
• ระมัดระวังการใช้งาน พวก data type ชนิด nchar, nvarchar เพราะว่าจะทำการจัดเก็บข้อมูลเพิ่มเป็น 2 เท่าจากปกติ
• เรื่องของ Index นั้นสำคัญมาก ๆ สร้างและต้องวัดประสิทธิภาพด้วยว่า ดีไหม ใช้เพื่อที่เยอะไหม รวมทั้งอะไรที่ไม่ได้ใช้ก็ลบไปด้วย
• ตอนที่เขียน SQL query มานั้น อย่าลืม EXPLAN query ด้วยเสมอ อย่าไปทำก่อน deploy ละ !!!
• อย่าลืมดู slow sql log และแก้ไข

เป็นคำแนะนำเล็ก ๆ น้อย ๆ
ค่อย ๆ แก้ไข ค่อย ๆ ปรับปรุง
แล้วจะดีขึ้นเองครับและอย่าลืมวัดผลด้วย

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

เรื่องแรกคือ การ commit และ pull request ที่มีขนาดใหญ่

เป็นปัญหาหลักของนักพัฒนาเลย รวมทั้งผมด้วย
เนื่องจากบ่อยครั้ง เรามักจะแก้ไขปัญหาจำนวนมากหรือใหญ่ ๆ พร้อม ๆ กัน
ทำให้มีการเปลี่ยนแปลงจำนวนมาก
และกว่าจะทำการ commit หรือส่ง pull request นั้น
ใช้เวลานานมากส่งผลให้การเปลี่ยนแปลงมีขนาดใหญ่
หรือบางคนก็จะทำวันละครั้งเท่านั้นเอง
ปัญหามักจะตามมามากมายไม่ว่าจะเป็นการ conflict
ไม่ว่าจะเป็น compile
ไม่ผ่านไม่ว่าจะเป็น ไปทำให้ระบบการ build หรือ CI/CD พังได้ง่าย

เรื่องที่สอง เขียน code วกไปวนมา

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

เรื่องที่สาม ทำหลาย ๆ งาน พร้อม ๆ กัน (Multi-tasking)

เป็นปัญหาระดับชาติกันเลยทีเดียว
ทำได้ทุกอย่าง แต่ไม่ดีสักงาน
การไม่ focus กับสิ่งที่ทำ มันก่อให้เกิดปัญหาตามมามากมาย
แต่ทำไมยังทำกันนะ ?

เรื่องที่สี่ ไม่เรียนรู้จากข้อผิดพลาด

บ่อยครั้งเรามักจะบอกว่าเราต้องเรียนรู้จากความผิดพลาด
แต่มักพบว่า เราชอบผิดซ้ำแต่เรื่องเดิม ๆ
ไม่เคยแก้ไข เรียนรู้ ปรับปรุงเลยผิดซ้ำผิดซ้อนผิดอยู่อย่างนั้น
บางครั้งก็ไม่ยอมรับ feedback จากคนอื่นอีกด้วย

เรื่องที่ห้า แทนที่จะทำงาน กลับเอาเวลาไปทำเรื่องส่วนตัว

เป็นปัญหาที่น่าปวดหัวมาก ๆ
ทั้งการเล่น social, game, shopping หรือการ trade ต่าง ๆ ในระหว่างเวลางาน !!
มันเป็นการบ่งบอกถึงความรับผิดชอบเราอย่างมาก

เรื่องที่หก ไม่เรียนรู้สิ่งใหม่ ๆ ยังยึดติดกับสิ่งหรือวิธีการเก่า ๆ

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

จากการสอนและแนะนำเรื่องการออกแบบ API (Application Programming Interface) ที่ดี
ไม่ว่าจะเป็น code ไม่ว่าจะเป็น RESTFul API ก็ตาม
API เหล่านั้นควรมีคุณสมบัติต่าง ๆ ดังนี้

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

เมื่อลงไปในรายละเอียดของ API ที่ดี
ก็มีเรื่องที่คุยกันพอสมควร
ยกตัวอย่างเช่น

API หนึ่ง ๆ ควรทำงานอย่างเดียวไปเลย (Single Responsibility)
และแน่นอนว่า ต้องทำงานให้ดีไปเลย
ทำให้ขนาดของ API นั้น ๆ เล็กลงไปด้วย

พยายามให้มี parameter น้อย ๆ หรือมีเท่าที่จำเป็นก็พอ
รวมทั้งเรื่องของข้อมูลที่ return กลับมาจาก API
ก็ต้อง return ข้อมูลที่ไม่ส่งผลต่อการทำงาน
ยกตัวอย่างเช่น
ถ้าต้อง return เป็น list กลับมาแล้ว
ในกรณีที่ไม่พอข้อมูล น่าจะส่ง empty list กลับมาดีว่า null มาก ๆ เป็นต้น

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

การตั้งชื่อก็สำคัญมาก ๆชื่อที่ดี
ย่อมทำให้ผู้ใช้เข้าใจง่าย ไม่สับสน

"เรื่องของความปลอดภัยและความเร็วในการทำงานเป็นเรื่องที่ละเลยไม่ได้เลย"

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

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

ไปเจอ web อธิบายเรื่อง Load Balancer ด้วยรูปการ์ตูนจาก Cloud for Geeks
เห็นว่าน่าสนใจ จึงนำมาฝาก

เริ่มด้วยการทำงานแบบ Client-Server

โดยถ้ามีผู้ใช้งานมาเพียง 2 คน จะไม่ทำให้เกิดปัญหา

แต่เมื่อผู้ใช้งานมีจำนวนมาก ๆ แล้ว แน่นอนก่อให้เกิดปัญหาต่อระบบ

เช่นทำงานช้าลง ไม่สามารถรองรับการใช้งานได้

การแก้ไขปัญหามีหลายแนวทาง เช่น

• การขยายเครื่อง ด้วยการเพิ่ม resource ต่าง ๆ เช่น CPU, Memory และ Network เป็นต้น
• การเพิ่มเครื่อง server เข้ามาช่วยกันทำงาน

โดยวิธีการที่ใช้งานบ่อย ๆ คือ การเพิ่มเครื่อง serverเข้ามาช่วยกันทำงาน

ทั้งลดปัญหาเรื่อง Single Point of Failure (SPoF)
ทั้งลดปัญหาเรื่อง downtime
ทั้งช่วยเพิ่มประสิทธฺภาพการทำงานของระบบ
ทั้งยังช่วยป้องกันการโจมตีระบบ
จากนั้นจึงต้องมีสิ่งที่เข้ามาช่วยกระจายงานจาก client ไปยัง server ต่าง ๆ
อาจจะมองว่าเป็นการแก้ไขปัญหา ด้วยการเพิ่มปัญหามาอีกตัว !!
นั่นก็คือ Load Balancer นั่นเอง

ต่อจากแนวคิดพื้นฐานของ Load Balancer นั้นยังมีแนวคิดอื่น ๆ เพิ่มเข้ามาอีก

ยกตัวอย่างเช่น Health Check ของ server หรือ service

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

ต่อมาคือ เทคนิคในการกระจายงานของ Load Balancer

ซึ่งมีหลายเทคนิคให้เลือกใช้งาน ตามความต้องการหรือตามแต่ละ usecase
มีดังนี้

• Random selection
• Round Robin
• Weighted Round Robin Method
• Least connection
• Least response time
• Source IP hashing

Reference Websites

https://codeburst.io/system-design-basics-load-balancer-101-adc4f602d08f

https://avinetworks.com/what-is-load-balancing

เห็นใน timeline ช่วงปีใหม่
ก็เจอรูปที่ share เกี่ยวกับชีวิตของ Programmer/Developer
จึงทำการสรุปไว้นิดหน่อย

เริ่มที่การฉลองในเทศกาลต่าง ๆ

การแก้ไขปัญหา !!

สิ่งที่แต่คนคิดว่า Programming ทำอะไร ไม่ต้องคิดมาก ทำแบบนี้

ในวันทำงาน vs วันหยุด

สิ่งที่เปลี่ยนไปของ Programmer !!

เมื่อมีคนมารับงานต่อ !!

ปีนี้พักผ่อนกันเยอะ ๆ ครับมีอีกหลายสิ่งอย่างที่ต้องเผชิญ

Reference Websites

https://www.quora.com/q/programmingmemes
https://www.thecoderpedia.com
https://twitter.com/programmersmeme

ไปเจอ error message ของ software ในยุคเก่า ๆ
มีความน่าสนใจมาก ๆ
เพราะว่า มันคืออีกหนึ่งหน้าประวัติศาสตร์ของ software เลยนะ
ซึ่งถ้าใครเคยเห็นหรือเข้าใจ
แสดงว่า คุณอายุไม่น้อยแล้วนะ !!

รูปแรกหา Keyboard ไม่เจอ

รูปที่สอง Bios error !!

รูปที่สาม Task fail successfully !!!

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

What is Diskette ? รู้จัก Drive A ไหม ?

สุดท้าย มันมีจริงใช่ไหม ?

ว่าง ๆ ลองมาทำการ Load testing ด้วย K6 กันหน่อย
โดยที่ K6 นั้นสามารถเขียน script การทำงานด้วยภาษา JavaScript
ทำให้ง่ายต่อการสร้าง scenario ของการทดสอบอย่างมาก
จึงลองสรุปการใชงานไว้นิดหน่อย

สิ่งที่ใช้งานนั้นประกอบไปด้วย

• แน่นอนต้องมี K6 สิ
• Docker และ Docker compose เพื่อให้ง่ายต่อการใช้งานและทำซ้ำ
• InfluxDB เป็น data store สำหรับเก็บผลการทดสอบ
• Grafana เป็น visiualization toll สำหรับแสดงผลของการทดสอบที่เก็บไว้ใน InfluxDB

เริ่มด้วยการเขียน script สำหรับการทดสอบระบบด้วย K6

โดยสามารถ run ได้เลย

แต่เพื่อความง่ายและสะดวกจึงใช้งาน Docker compose ดีกว่า
และทำการเก็บผลการทดสอบไว้ใน InfluxDB
อีกทั้งแสดงผลการทดสอบใน Grafana ไปเลย ดังนี้

เมื่อทุกอย่างเรียบร้อยก็ทำการ run

จากนั้นทำการ run script สำหรับทำ Load testing ระบบงาน ดังนี้

ดูผลการทำงานใน Grafana ดังรูป

เพียงเท่านี้ก็สามารถทำ Load testing ด้วย K6 แบบง่าย ๆ
ดูดีมี style ได้แล้วนะ

ตัวอย่าง code อยู่ที่ GitHub::Up1

Reference Websites

K6 + InfluxDB + Grafana

ใน Go 1.16 นั้นจะมี core library ใหม่เพิ่มเข้ามา ชื่อว่า Embedded files
โดยจะอยู่ใน package embed
และมี package ใหม่ชื่อว่า io/fs สำหรับการอ่านไฟล์แบบ read-only
ในการเข้าถึงไฟล์ง่าย ๆ ด้วยการใช้ directive go:embed
เพื่อความเข้าใจ มาดู codeกัน

การใช้งานเบื้องต้น

ลองทำการสร้าง File server ใช้งานนิดหน่อย

โดยใช้งานผ่าน struct embed.FS ดังนี้

จากที่ใช้งานมาง่ายดีนะ
แต่ไม่ค่อยชอบการใช้ directive เลยนะสิ !!
แต่อย่างไรก็ตาม ลองใช้งานกันดูครับ

ลองไปดู Draft Design เพิ่มเติมได้ที่ Reddit

เพิ่งเห็นว่า JupyterLab 3 ออกมาแล้ว ตอนนี้ 3.0.2 นะ
มีความสามารถใหม่ ๆ ที่น่าสนใจ ดังนี้

• Debugger ด้วยการใช้ kernel เพิ่มเติม เช่น xeus-python
• มี Table of content หรือสารบัญให้ใช้งานง่าย ๆ
• สนับสนุนการแสดงผลในภาษาต่าง ๆ ด้วยการติดตั้ง Language Pack

ความสามารถที่น่าสนใจที่สุดคือ Dubugger

ซึ่งสามารถใช้งานได้กับ kernel ที่สนับสนุน
ทำให้สามารถเพิ่ม breakpoint
และแสดงค่าต่าง ๆ ใน Visual Debugger แบบสวย ๆ ดังนี้

อีกเรื่องคือ Table of content ที่เพิ่มเข้ามาใน core ของ JupyterLab แล้ว

ทำให้การใช้งาน notebook ง่ายและสะดวกขึ้นอย่างมาก

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

คำถาม

ในการใช้งาน Postman นั้น
บางครั้งต้องทำการอ่านค่าจาก environment variable ของ OS
เลยจึงเกิดคำถามว่าต้องทำอย่างไรบ้าง ?

คำตอบ

โดยปกติแล้วใน Postman จะมีส่วนการจัดการ environment ภายในให้อยู่แล้ว
แต่ยังไม่มีการอธิบายสำหรับคำถามนี้

ดังนั้นจึงขออธิบายสำหรับการอ่านข้อมูลจาก environment variable ของ OS ไว้นิดหน่อย

วิธีการใช้งานมี 2 แบบคือ

1. ใช้งานผ่าน Global variable ซึ่งเขียน code อ่านข้อมูล
2. ทำการส่งข้อมูลผ่าน parameter ชื่อว่า --global-var ของ newman

Code สำหรับการอ่านข้อมูลจาก environment variable ของ OS ใน request

ส่งข้อมูลผ่าน parameter ของ newman ได้ดังนี้

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

หรืออ่านเพิ่มเติมได้จาก e-Book :: Postman in the right way

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

เล่มที่ 1 และ 2 :: Atomic Habits และ วิชาจิ๋ว

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

เล่มที่ 3 :: Accelerate: The Science of Lean Software and DevOps

ช่วง 2 ปีที่ผ่านมา จะลงมือทำในเรื่อง
การปรับปรุงการพัฒนาและส่งมอบ software เป็นหลัก
ทั้งการทำความเข้าใจกับ requriement
ทั้งการวิเคราะห์และออกแบบ
ทั้งการพัฒนาและทดสอบ
ทั้งการส่งมอบ
พยายามทำให้ขั้นตอนการทำงานสั้นที่สุด
เพื่อให้ได้ feedback กลับมาเพื่อใช้เรียนรู้และปรับปรุงบ่อย ๆ
และทำซ้ำได้เรื่อย ๆ ตลอดเวลาเมื่อมีการเปลี่ยนแปลง

เล่มที่ 4 :: Steal Like an Artist: 10 Things Nobody Told You About Being Creative

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

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

สองวันที่ผ่านมา มีโอกาสไปแบ่งปันเรื่อง
พื้นฐานสำหรับการพัฒนาระบบงานด้วยภาษา Go
เพื่อช่วยทำให้รู้และเข้าใจเกี่ยวกับภาษา
เพื่อช่วยให้รู้ว่า ตัวภาษานั้นมีเครื่องมือช่วยในการพัฒนาและ deploy อย่างไรบ้าง

เริ่มด้วยการเข้าใจเรื่องพื้นฐานของภาษา Go

โดยผมมักจะเริ่มด้วย How to write Go code ?
เป็นเอกสารสำหรับการเริ่มต้นเขียน code รวมทั้งสิ่งต่าง ๆ ที่สำคัญต่อการพัฒนา เช่น

• Go module ทั้งการใช้งาน การสร้าง และ publish ให้ใช้งาน
• การ run, build, install และ testing

สิ่งที่ชอบแนะนำคือ ไปเริ่มต้นด้วย Go Tour กันด้วย

ต่อมาว่าด้วยเรื่องของ Development workflow

โดยภาษา Go เตรียมเครื่องมือต่าง ๆ ไว้ให้ใช้งานครบครัน
รวมทั้งการใช้งานร่วมกันเครื่องอื่น ๆ เป็นดังนี้

• Editor ที่ใช้งานการพัฒนาคือ VS Code และ extension
• การจัดการ format ของ code ด้วย go fmt
• ทำการตรวจสอบ code และเรื่องของ check style ต่าง ๆ ด้วย go lint, go vet เป็นต้น
• ทำการ build และ install ด้วย go build และ go install สำหรับการส่งมอบระบบงานในรูปแบบ binary file
• ในการ build นั้นก็ใช้ร่วมกับ go environment ด้วยเช่น GOOS และ GOARCH เป็นต้น
• ทำการทดสอบด้วย go test ซึ่งมี benchmark และ code coverage มาให้ใช้งานด้วย รวมทั้งเรื่องของการตรวจสอบ race condition
• การทำงานร่วมกับ Docker และ Docker compose รวมทั้งการสร้าง Dockerfile แบบ multi-stage build

ความรู้พื้นฐานที่ควรจะต้องรู้และเข้าใจ

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

• Repository, module และ package
• การใช้งาน variable และเรื่องของ type system
• Array, Slice และ Map ซึ่งเป็น data structure พื้นฐาน
• พวก control flow ต่าง ๆ ทั้ง if-else, switch-case, for เป็นต้น
• เรื่องสำคัญคือ Pointer, Struct, Interface

เพิ่มเติมก็คือ เรื่องของ Dependency Injection และเรื่องของ Testale code

ต่อมาทำการเริ่มพัฒนา REST API ด้วยภาษา Go

ซึ่งมี library ให้ใช้งานหลากหลาย ประกอบไปด้วย

• net/http package
• Gin
• Echo
• Fiber

โดยเน้นไปที่ของ performance และ development productivity

ในส่วนนี้จะเน้นไปที่การพัฒนาระบบงาน

• การกำหนด router ของ API
• การสร้าง handler/controller ของการทำงาน
• การจัดการกับ configuration ต่าง ๆ ของระบบงาน
• แบ่งการทำงานออกเป็นส่วน ๆ หรือพูดคุยเรื่องของ project structure ในรูปแบบต่าง ๆ ทั้ง flat, layer, module/domain, clean architecture เป็นต้น
• การพัฒนาระบบให้เป้นไปตามที่ต้องการ รวมทั้งเรื่องของ การดูแลรักษา พัฒนาและ testable อีกด้วย
• การทำงานร่วมกับ depednency ต่าง ๆ เช่น database เป็นต้น ซึ่งได้พูดคุยและลงรายละเอียดของ Dependency Injection
• การทดสอบก็จะมีการใช้งาน library เพิ่มเติมชื่อว่า Testify

จากนั้นก็ลงมือทำ workshop เพื่อช่วยทำให้เข้าใจมากยิ่งขึ้น

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

จากบทความเรื่อง Engineering For Failure
ทำการอธิบายถึงระบบงานที่มีความซับซ้อนมากขึ้น
แต่ละส่วนงานแยกกันทำงาน
ยกตัวอย่างเช่น service, database และ caching ต่าง ๆ

แน่นอนว่า การติดต่อสื่อสารกันผ่านระบบ network
อาจจะเกิดข้อผิดพลาดในการติดต่อสื่อสารได้
ดังนั้นเป็นสิ่งที่ต้องคิดและหาวิธีการจัดการ
เมื่อเกิดข้อผิดพลาดขึ้นมา (Design for failure)

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

วิธีการที่ 1 Retrying

เมื่อมีปัญหาของการส่ง request ขึ้นมา
ก็ทำการ retry หรือพยายามส่ง request นั้นไปใหม่
โดยมีการกำหนด timeout ที่เหมาะสม
สำหรับการส่ง request ต่าง ๆ
เป็นวิธีการที่มักใช้กันบ่อย ๆ

แต่การ retry นั้นก็ก่อให้เกิดจำนวน load ที่มากขึ้นเช่นกัน
ยกตัวอย่างเช่น
ในช่วงเวลาหนึ่ง ๆ มี request ที่ fail จำนวน 10,000 request
นั่นหมายความว่าจะมีการ retry ใหม่อีก 10,000 request !!!
จะทำแบบนี้ไปเรื่อย ๆ หรือไม่นะ ?

ดังนั้นแนวทางนี้อาจจะต้องมีพร้อมกับ Circuit breaker ด้วย

วิธีการที่ 2 Prefetching

ทำการดึงข้อมูลจากระบบปลายทางมาเก็บไว้ก่อน
โดยทำงานแบบ background process
แน่นอนว่า จะไม่กระทบต่อการทำงานหลักของระบบ
เป็นอีกวิธีการที่แยกออกไปจากการทำงานหลักไปเลย

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

วิธีการที่ 3 Best effort

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

วิธีการที่ 4 Falling back to previous or estimated results

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

วิธีการที่ 5 Delay a response

ในบางกรณีนั้น เมื่อเกิดปัญหาแล้ว
ให้ทำการบันทึก request นั้น ๆ ไว้ใน messaging server หรือพวก queue
จากนั้นจึงทำการ process ในภายหลัง
และทำการส่งผลการทำงานนั้น ๆ กลับไปยัง consumer

วิธีการที่ 6 Implement simplified fallback logic

ในบางครั้ง อาจจะต้องมีการพัฒนาส่วนของ logic เพิ่มเติม
ในฝั่ง consumer หรือผู้เรียกใช้งาน
อาจจะไม่เทียบเท่าของจริง แต่ยังสามารถทำงานได้
เพื่อช่วยทำให้ request ต่าง ๆ ทำงานเสร็จสมบูรณ์

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

วันนี้มีคำถามเรื่องการทำ reload ระบบที่พัฒนาด้วยภาษา Go
เหมือนกับ NodeMon สำหรับ NodeJS
ว่าต้องทำอย่างไรบ้าง ?

ตามจริงเคยเขียนเรื่องนี้ไปแล้ว
แต่คิดว่า น่าจะใช้ NodeMon กับ Go ได้เลย
ซึ่งพบว่ามันก็ใช้ได้จริง ๆ

โดยเพียงกำหนด parameter ที่ต้องการ run ให้ NodeMon เท่านั้นเอง
ก็ใช้งานได้ ดังนี้

ผลการทำงานเมื่อมีการเปลี่ยนแปลง