ทาง StackOverflow เขียนบทความและสรุป Q/A ต่าง ๆ ที่น่าสนใจในทุก ๆ สัปดาห์
โดยในสัปดาห์ที่ผ่านมา
มีบทความที่น่าสนใจเรื่อง DevOps
นั่นก็คือเรื่อง The rise of the DevOps mindset

มีคำที่น่าสนใจคือ DevOps เป็นคำที่หลาย ๆ คนเข้าใจไม่ตรงกัน
แต่ผลการสำรวจในต้นปี 2020 ของ StackOverflow 
บ่งบอกว่ามันมีความสำคัญต่อหลาย ๆ องค์กรอย่างมาก

ในบทความนี้จึงนำมาอธิบายและสรุปให้เข้าใจกัน
มาเริ่มกันเลย

เรื่องแรก What is DevOps and why is it so popular?

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

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

ความซับซ้อนที่มากมาย
บางครั้งมาจากปัญหาคอขวดในบางส่วนงาน
ก่อให้เกิดปัญหามากมายตามมา
โรคเลื่อนก็เกิดขึ้นบ่อย
ยิ่งเรื่องของคุณภาพยิ่งไม่ต้องพูดถึง ไปวัดกันบน production เลย !!

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

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

• ปรับปรุงการ deploy ให้บ่อยขึ้น
• ลดข้อผิดพลาดต่าง ๆ ลง
• ทันต่อความต้องการของตลาด

มีคำพูดที่น่าสนใจจาก CPO ของ StackOverflow คือ

The right DevOps culture ultimately makes the product you deliver better

เรื่องที่สอง Which problems is DevOps trying to solve?

ปัญหาที่แนวคิด DevOps พยายามที่จะแก้ไข จากหัวใจหลักของแนวคิดนี้ ประกอบไปด้วย

• Communication
• Automation
• Measurement

มาดูสิ่งที่ DevOps พยายามแก้ไขให้ดีขึ้นกัน ประกอบไปด้วย 6 เรื่องดังนี้

1. From silos to One-team-thinking เรื่องนี้ยากมาก ๆ เพราะว่าบ่อยครั้งเรามักจะมีอีกทีมคือ DevOps ทีม ทำให้ปัญหาไม่หายไป ลด ละ เลิกการแยก แต่ให้มีการคิดและทำงานร่วมกัน เป้าหมายเดียวกัน บางคนมี KPI ควรใช้ร่วมหรือ share กัน
2. No more ‘hell month’ during releases ถ้าทำตามแนวคิด DevOps แล้วยังคงกลัวการ release ทุกครั้ง พังทุกครั้ง เป็นช่วงเวลาที่เครียดทุกว่า แบบนี้ไม่น่าจะได้นำแนวคิดมาใช้ แต่น่าจะเปลี่ยนแค่ชื่อ
3. Standardizing tech stacks and lazy paths เรื่องของเทคโนโลยีที่ใช้งานก็น่าสนใจ ควรมีแนวทางที่ชัดเจนว่าจะใช้อะไรบ้าง เพื่อให้ง่านต่อการเรียนรู้และการทำระบบ automation อีกด้วย
4. From finger pointing to feedback loops แทนที่จะบอกว่าใครผิด ตรงไหนผิด เปลี่ยนมาเป็น feedback loop ที่รวดเร็วดีกว่า feedback ที่ดีที่สุดคือ มาจากลูกค้าหรือผู้ใชงานจริง ๆ
5. Making friends with failure เรื่องความผิดพลาดกลายเป้นเรื่องปกติ แต่เรารู้ความผิดพลาดได้รวดเร็วเพียงใด เท่านั้นเอง และเรียนรู้ไปกับมัน
6. DevOps as self-service นี่คือเป้าหมายปลายทางคือ คนใช้งานสามารถใช้ได้เลย

เรื่องที่สามคือ Tools: What are the defining  tools?

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

จาก DevOps Tags Top 30 ใน StackOverflow ประกอบไปด้วย

สามารถสรุปได้ดังนี้

• การ tracking งาน มี Asana, Monday และ Jira
• การจัดการ source code มี Git, GitHub, GitLab, BitBucket และ TFS
• CI/CD มี Jenkins, Team City และ GitHub Actions
• การวิเคราะห์ Source code มี SonarQube
• การจัดการพวก Artifact ต่าง ๆ มี Artifactory และ Docker Container Registry
• Configuration management มี Terraform, Ansible, Puppet และ Chef
• การจัดการ container มี Docker และ Kubernetes
• การ monitoring มี Prometheus

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

อ่านบทความเรื่อง Why optimizing for MTTR over MTBF is better for business ?
จากบริษัท Grafana โดยทำการอธิบายว่า
ได้นำค่าของ MTTR (Mean Time to Recovery) มาใช้สำหรับการวัดผลการทำงาน
นั่นคือ เวลาในการแก้ไขปัญหารวมไปถึงทำให้ระบบงานกลับมาใช้งานได้นั่นเอง

โดยที่ค่า MTTR นั้นใช้สำหรับช่วยทำให้ระบบที่เราพัฒนาและดูแล

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

เนื่องจากเมื่อมีการเปลี่ยนแปลงใด ๆ แล้ว

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

MTTR นั้นจะวัดค่าได้ดีขึ้น เมื่อเราทำการ release บ่อย ๆ
นั่นคือสิ่งที่เราได้รับกลับมา แต่ถ้าเรากลัวการ release ก็จะได้ผลตรงกันข้าม
เนื่องจากเราจะไม่ได้เรียนรู้มากนักนั่นเอง

ดังนั้นถ้าเราเลือก MTTR แล้ว ก็มีความแนะนำในการปรับปรุงดังนี้

• ควรมีเครื่องมือในการ deploy และ release ที่ดี ยิ่งสามารถทำงานแบบอัตโนมัติได้ยิ่งดี เพราะจะทำให้เราทำงานได้บ่อย ๆ ยกตัวอย่างเช่น Kubeernetes เป็นต้น
• ควรมีเครื่องมือในการ monitoring ระบบที่ดีและเหมาะสม รวมทั้งยังช่วยเสริมสร้างความมั่นใจให้เราได้ด้วย เช่นเกิดปัญหาบน production แล้วสามารถระบบจุดหรือต้นเหตุของปัญหาได้เลย เช่น Grafana, Prometheus แบะ Loki เป็นต้น
• ควรมีเครื่องมือในการ track ในการ release ได้ รวมทั้ง integrate เข้ากับ feature และ issue ได้อีกด้วย
• ควรทำงานเป็นแบบ iteration เพื่อให้เราทำงาน release บ่อย ๆ อย่างต่อเนื่อง

เรียนรู้จากความผิดพลาด เพื่อพัฒนาและปรับปรุงให้ดีขึ้น

แต่ไม่ใช่ผิดที่เดิมแล้วซ้ำเล่านะครับ
ขอให้สนุกกับการ coding

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

• End-to-End testing
• Cross-browser automation library สนับสนุน web browser หลัก ๆ ทั้ง Google Chrome, Firefox และ Microsoft Edge ตัวใหม่
• สามารถทำงานได้บน device ต่าง ๆ ได้ ทั้ง desktop, mobile และ tablet
• เขียนชุดการทดสอบที่ทำงานได้เร็ว และ เสถียร มีความน่าเชื่อถือ ซึ่งเข้ามาช่วยแก้ไขปัญหาของการทดสอบบน weeb browser ต่าง ๆ ที่ช้าและไม่ค่อยเสถียร
• ใช้ API เดียวสำหรับทุก ๆ  browser ได้เลย

โดย library จะพัฒนาด้วย TypeScript + JavaScript เป็นหลัก

ทำการติดตั้งดังนี้

มาดูความสามารถที่น่าสนใจของ Playwright กัน

เมื่อมีการทำงานกับระบบที่ทำงานแบบ asynchornous แล้ว
บ่อยครั้งการเขียน test จะต้องใช้ wait, delay หรือ timeout มาใช้งาน
เพื่อรอไปการทำงานของหน้า web
ซึ่งแนวทางนี้ ก่อให้เกิดผลการทดสอบที่ไม่เสถียร 
นั่นคือ ได้บ้าง ไม่ได้บ้าง

ดังนั้น Playwright จึงทำการแก้ไขด้วยการจัดการเรื่องนี้ให้เอง
ทำให้คนเขียน test ไม่ต้องมาสนใจส่วนนี้
ให้ไปสนใจที่ scenario ที่ต้องการจะทดสอบไปเลย
ส่งผลให้การดูแลรักษา test ง่ายและสะดวกขึ้น
ไม่ต้องมาห่วงหน้าพะวงหลังอีกต่อไป

โดยที่ Playwright ถูกสร้างขึ้นมาตามแนวคิด Event-driven architecture นั่นคือ
จะค่อยดักฟัง event ที่เกิดขึ้นใน browser 
เช่น DOM, network request และ console log ต่าง ๆ
ส่วน protocol ที่ใช้งานก็ใช้ตาม developer tool ใน browser นั่นเอง

ตัวอย่าง code

ความสามารถต่อมา คือ ความเร็วในการทำงาน

โดยที่สามารถทำงานแบบ parallel ได้เลย
สามารถทำทำการทดสอบด้วย browser หลาย ๆ ตัว พร้อมกันได้
เนื่องจากมีความสามารถที่ชื่อว่า multi-page emulation scenario นั่นคือ
แต่ละการทดสอบจะแยกเป็นอิสระแก่กัน
รวมทั้งยังสามารถกำหนดค่าต่าง ๆ ได้เองอีกด้วยผ่าน context object เช่น

• การกำหนด device ที่จะ run test
• ขนาดหน้าจอของ device
• การขออนุญาตต่าง ๆ เช่น location เป็นต้น
• กำหนดตำแหน่ง location ของ device ได้
• กำหนดค่า locale ได้
• Network interception
• Web worker

ตัวอย่าง code เป็นดังนี้

น่าจะเป็นอีก library ในการทดสอบระบบงานบน Web browser ที่ดี
น่าจะพอมีประโยชน์นะครับ

สำหรับใครที่เขียน test ด้วย RobotFramework แล้ว
ก็มีคนทำ library ไว้ให้ชื่อว่า RobotFramework-Browser

ไหน ๆ ก็ลองใช้  Playwright ในการทำ End-to-End testing บน web browser แล้ว
ก็อยากลองทำการบันทึก VDO การทดสอบหน่อย
ก็ไปเจอว่ามี module ชื่อว่า playwright-video ให้ใช้งาน
ซึ่งทำงานร่วมกับ ffmpeg มาลองใช้งานกัน
ปล. ใน Cypress มามาให้เลย ไม่ต้องทำอะไร

เริ่มจากการติดตั้ง

จากนั้นลองเขียนชุดการทดสอบง่าย ๆ ดังนี้

ผลการทำงานบันทึกเป็นไฟล์ VDO ดังนี้

วิธีการจัดการ template ของ commit message ใน Git
เพื่อเป็นแนวทางในการเขียน commit message
โดยการใช้งานมีขั้นตอนดังนี้

ขั้นตอนที่ 1 สร้างไฟล์ template สำหรับกำหนดรูปแบบที่ต้องการ

ขั้นตอนที่ 2 ทำการ config template เข้าไปใน git config

เท่านี้ก็ใช้งานได้แล้ว
ลองกำหนดรูปแบบของ commit message ดูครับ
น่าจะเป็นประโยชน์ต่อการทำงาน

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

อย่างแรกในการเรียนรู้นั้น น่าจะเกิดจาก

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

ดังนั้นการ focus จึงสำคัญมาก ๆ

ลงมือด้วยตัวเราเอง 

ยกตัวอย่างเช่น
ทำการติดตั้งด้วยตัวเอง
ทำการสร้าง project ด้วยตนเอง
ทำการเขียน code ด้วยตนเอง
พยายามอย่างเรียนทางลัด

ยกตัวอย่างเช่นการ copy and paste เป็นต้น
อย่าทำถ้ายังไม่เข้าใจมันจริง ๆ ยิ่งเรียนรู้จาก course online ด้วยแล้ว
มักจะมี code ตัวอย่างให้ ซึ่งให้ระวังอย่างมาก

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

ปิดท้ายด้วยวินัยของการเรียนรู้อย่างสม่ำเสมอ

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

จะให้ดีกว่านี้คือ ทำการสอนเรื่องที่เราศึกษาให้คนอื่น
ยิ่งทำให้เรารู้และเข้าใจเรื่องนั้น ๆ ได้ดีขึ้นอีกเยอะเลย

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

ขั้นตอนการใช้งานเป็นดังนี้

ขั้นตอนที่ 1 สร้าง Team Workspace

จะเรียกว่าเป็น producer หรือเจ้าของ API นั่นเอง
โดยที่ workspace จะเป็นจุดเริ่มต้นของการทำงานเป็นทีม

จะเรียกว่าเป็น producer หรือเจ้าของ API นั่นเองโดยที่ workspace จะเป็นจุดเริ่มต้นของการทำงานเป็นทีม

ขั้นตอนที่ 2 ทำการสร้าง Postman Collections ใน Workspace

ทำการสร้าง collection เป็นแบบ blueprint
ซึ่งชื่อของ collection จะใส่ #blueprint
และสร้าง API ต่าง ๆ รวมทั้งใช้งาน Example อีกด้วย

โดยที่ทีมสามารถพูดคุยและใส่ comment ต่าง ๆ ได้อีกด้วย

ขั้นตอนที่ 3 สามารถทำการพัฒนาไปพร้อม ๆ กันด้วย Mock Server

ขั้นตอนที่ 4 ทำการทดสอบด้วย API Testing ได้

ขั้นตอนที่ 5 Continuos Testing ด้วย newman

สามารถทำการทดสอบหลาย ๆ collection + testing ด้วย NewMan
โดยรวมแล้วจะมีขั้นตอนการทำงานดังรูป

บันทึกการอ่านบทความเรื่อง How Django can handle 100 millions of requests per day
มีหลาย ๆ แนวคิดที่น่าสนใจ เพื่อให้ระบบมีประสิทธิภาพสูงขึ้น
จึงทำการบันทึกสิ่งที่น่าสนใจไว้
มาเริ่มกันเลย

เรื่องที่ 1 Infrastructure ที่ดี

บ้านจะดีไม่ได้เลย
ถ้าอยู่ในพื้นที่ไม่ดี
ถ้าไม่มีรากฐานที่ดี
ระบบงานก็เช่นกัน Instratructure ก็ต้องดี
ต้องเอื้อต่อการ scale เมื่อถึงจุดที่ระบบที่รับไม่ได้
รวมไปถึง application ก็เช่นกัน
สิ่งที่น่าสนใจคือ

• แบ่งเป็น service ย่อย ๆ แต่ให้พิจารณาเรื่องของการติดต่อสื่อสารระหว่าง service และการ sync ข้อมูล ซึ่งจะใช้ resource และค่าใช้จ่ายมากขึ้น
• จัดการ container ด้วย Docker
• ถ้าจำนวน container เยอะ ๆ แนะนำให้จัดการผ่าน Kubernetes
• ออกแบบ infrastructure ให้ง่ายต่อการ maintain เช่นไม่มี downtime เมื่อทำการ upgrade ระบบเป็นต้น
• เรื่องของ metric และ monitoring สำคัญมาก ๆ เก็บข้อมูลที่จำเป็นต่อการหาและตรวจสอบหาปัญหา

เรื่องที่ 2 Database เลือกให้เหมาะกับงาน

ระบบงานส่วนใหญ่นั้น จะช้าหรือเร็วก็ขึ้นอยู่กับ database นี่เอง
ดังนั้นเลือกที่มีความเร็วสูง (IOPS)
การจัดการ index และดู slow query ก็สำคัญมาก ๆ
แต่การมี index มากจนเกินไปมันก็แย่
ดังนั้นถ้ามี index ที่มันซ้ำซ้อนและไม่ได้ใช้งานก็ลบทิ้งไป

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

เรื่องที่ 3 ลบสิ่งที่ไม่ได้ใช้ออกไป

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

เรื่องที่ 4 แนะนำให้ใช้งาน Bulk query

คือการส่งหลาย ๆ query ไปยัง database พร้อม ๆ กันในครั้งเดียว
ซึ่งช่วยลดการเชื่อมต่อไปยัง database อีกด้วย

เรื่องที่ 5 ลดขนาดของข้อมูลที่ส่งไปมาในระบบงาน

เช่นการดึงข้อมูลของ application layer ไปยัง data layer
หรือระหว่างผู้ใช้งานกับ API ก็เช่นกัน
ให้ดึงข้อมูลเท่าที่จำเป็นต่อการใช้งานเท่านั้น ไม่ต้องเผื่อ !!
จะช่วยเรื่องของ response time ที่เร็วขึ้น

สิ่งที่สำคัญมาก ๆ คือ การ monitoring และ metric ต่าง ๆเพื่อใช้ในการแก้ไขและปรับปรุงอย่างต่อเนื่อง

จากบทความเรื่อง How Stack Overflow hires engineers ? 
ทำการสรุปขั้นตอนการรับคนเข้าทำงานของ Stack Overflow (Engineer)
ว่าเป็นอย่างไรบ้าง ซึ่งน่าสนใจมาก 

โดยที่แนวทางของการรับสมัครจะเป็นดังนี้

• Transparency ขั้นตอนต้องมีความโปร่งใส
• Full team involvement สมาชิกในทีมสามารถเข้าร่วมการสัมภาษณ์ได้เลย  สามารถทำการสัมภาษณ์แบบ remote ได้
• Brand identity เรื่องความเป็นตัวตนขององค์กรต้องชัดและแข็งแรง
• Having a clear idea of who we’re looking for ในการประกาศรับสมัครนั้น ควรระบุคุณสมบัติที่ต้องการให้ชัดเจน ไม่ต้องกว้างแบบครอบจักรวาล

การทำงานส่วนใหญ่ของ Stack Overflow เป็นแบบ remote อยู่แล้ว

ดังนั้นการสัมภาษณ์ก็ทำแบบ remote เช่นกัน
โดยมีขั้นตอนของการรับสมัครหรือเลือกคนสมัครดังนี้

• Resume review  แน่นอนว่ายังทำการ review จาก resume ก่อนเสมอ ดังนั้นถ้าใน resume ไม่เข้าตา ก็ไม่น่าจะถูกเลือก
• Initial screen ทำการสัมภาษณ์ผ่านโทรศัพท์ก่อน เพื่อพูดคุยเรื่องต่าง ๆ รวมทั้งความคาดหวังในกระบวนการสัมภาษณ์ต่อไป
• Code screen เขียน code นั่นเอง ไม่มีอะไรซับซ้อน ว่าคนสมัครเขียน code ได้ไหม
• Full interviews เมื่อผ่านทั้ง 3 ขั้นตอนแล้วก็ได้คุยกันจริง ๆ ซึ่งประกอบไปด้วยเรื่อง algorithm, architecture และ PM
• Manager interview เป็นด่านสุดท้ายแล้ว

ทาง Stack Overflow ในตอนนี้นั้น ทำงานแบบ remote 100% แล้ว
ดังนั้นขั้นตอนการรับคนเข้าทำงานจึงต้อง
มั่นใจว่าจะรับคนที่ใช้คำว่า Smart
และทำงานได้ดีไม่ว่าจะอยู่ที่ใดในโลกนี้ก็ตาม

ฟังเรื่องนี้ผ่าน Podcast จาก Stack Overflow ได้เลย

จากการสำรวจเรื่อง The Pandemic Programming นั้น
เพื่อเป็นการสำรวจว่า COVID-19 นั้น
ส่งผลกระทบต่อ software developer อย่างไรบ้าง
รวมทั้งมีการจัดการและได้รับการช่วยเหลืออย่างไรบ้าง

ผลสรุปของการสำรวจนี้ประกอบไปด้วย

• Software developer ได้รับผลกระทบทั้งทางด้ายสุขภาพ ความเป็นอยู่ และ productivity
• เรื่องของสุขภาพและความเป็นอยู่ที่ดี และ productivity มีความสัมพันธ์กันอย่างมาก
• ในการทำงานที่บ้านนั้น ถ้าที่บ้านมีความพร้อมที่ดี จะส่งผลให้ productivity ที่สูง
• ครอบครัวและคนรอบข้างมีผลต่อ productivity อย่างมาก
• แต่ละคนต้องการการสนับสนุนที่แตกต่างกันไป

จากผลสรุปนั้น จึงมีคำแนะนำที่ควรช่วยเหลือ Software developer ดังนี้

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

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

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

มาดูวิธีที่น่าจะดีและยั่งยืนกว่ากันบ้าง มาเริ่มกันใหม่

ขั้นตอนที่ 1 ต้องเริ่มจากการทำความเข้าใจกับปัญหาก่อน

ว่าปัญหาที่เราเจอนั้นเป็นอย่างไร
มีเรื่องอะไรที่เราไม่รู้และไม่เข้าใจบ้าง
เหมือนเป็นการหา keyword เพื่อจะตามหานั่นเอง

ขั้นตอนที่ 2 พื้นฐานสำคัญมาก ๆ

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

อย่าเริ่มด้วยการอ่าน tutorial จากที่อื่น ๆ 
เพราะว่า ส่วนใหญ่จะเป็น How-to มากกว่าแนวคิด
ซึ่งหลาย ๆ คนชอบด้วยนะสิ !!

ขั้นตอนที่ 3 ให้แบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาเล็ก ๆ

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

บ่อยครั้งพบว่า การแก้ไขปัญหาใหญ่ ๆ ก็จะเหมือนการพายเรือในอ่าง

ขั้นตอนที่ 4 มาถึงตรงนี้คุณพร้อมที่จะค้นหาจาก google และ stackoverflow แล้วนะ

เมื่อเรามีข้อมูลที่ครบถ้วน
เมื่อเรารู้ว่าปัญหาที่แท้จริงคืออะไร
การค้นหาจาก Google ก็จะมีประสิทธิภาพมาก ๆ
รู้อะไรไม่สู้รู้ keyword

ขั้นตอนที่ 5 ถามคนอื่น หรือ หาคนช่วย

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

ปล. อย่าจมกับปัญหานานเกินไปด้วย ดังนั้นการกำหนดกรอบเวลาหรือ timebox ก็สำคัญมาก ๆ รวมทั้งการหยุดเพื่อพักผ่อนด้วย

สุดท้าย อย่าลืมการเรียนรู้เพิ่มอยู่อย่างสม่ำเสมอ
เตรียมตัวเราเองให้พร้อมอยู่เสมอ

ใครมีวิธีการดี ๆ แนะนำมาได้นะครับ

ช่วงที่ผ่านมาเห็นหลาย ๆ คนเริ่มทำการปรับปรุง GitHub Profile
ด้วยการเขียนในไฟล์ README.md
เมื่อลองไปดูพบว่า มีเครื่องมือหลาย ๆ ตัวให้ใช้งาน
จึงทำการสรุปไว้นิดหน่อย

ก่อนอื่นต้องสร้างไฟล์ README สำหรับ GitHub Profile ของเราก่อน

โดยให้ทำการสร้าง repository ชื่อเดียวกับ username ของเรา
ยกตัวอย่างเช่น username=up1
ให้ทำการสร้างหรือเปลี่ยนชื่อ repository เป็น up1
จากนั้นสร้างไฟล์ README.md
เท่านี้ก็เป็นจุดเริ่มต้นของ profile ของเราแล้ว

ตัวอย่างที่ทำเช่น

เนื่องจากเราเขียนได้ในไฟล์ README.md ซึ่งใช้ Markdown format

ดังนั้นจึงสามารถนำเอา code ต่าง ๆ มาใส่ได้เพียบเลย
ทั้ง HTML, ภาพ vdo และเพลงต่าง ๆ
ข้อมูลการใช้งาน repository ต่าง ๆ ใน GitHub

รวมทั้งเป็น repository ใหม่
ทำให้เราสามารถ integrate การสร้างและแก้ไข README.md 
ผ่านระบบ CI/CD ได้เลย
ทั้ง GitHub action, CircleCI และระบบอื่น ๆ ได้เลย

มีคนรวบรวมแนวทางดี ๆ สำหรับการเขียนไฟล์ README ไว้ที่
GitHub Awesome README

อีกทั้งยังมี Template ให้ใช้อีก

ลองสร้าง GitHub profile กันดูครับ

ในช่วง 2-3 เดือนที่ผ่านมานั้น มีโอกาสได้แลกเปลี่ยนความรู้และประสบการณ์
เกี่ยวกับการนำแนวคิด Microservices มาใช้งาน
ผ่านทางการพูดคุย สอน แบ่งปันแบบ Remote/Online
ทำให้ได้เห็นแนวทางที่ชัดเจนขึ้นว่า

เราต้องเข้าใจในปัญหา หรือ ความต้องการก่อน

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

การแบ่งระบบงานออกเป็น service ย่อย ๆ (Decomposition)

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

• แยกตาม business หรือ feature ไป บ่อยครั้งแยกให้แต่ละทีมทำไปเลย เช่น logging, monitoring และ user management เป็นต้น
• แยกตาม domain ตามแนวคิดของ Domain-Driven Design

เมื่อแยกเป็นหลาย ๆ  service แล้วจะค้นหากันอย่างไร (Service Discovery) ?

แน่นอนว่า ต้องเตรียมคำตอบหรือวิธีการไว้เสมอ

ต่อจากนั้นเรื่องของ การติดต่อสื่อสารระหว่าง service ก็ตามมาอีก

ว่าจะมีรูปแบบอย่างไร ?
ทั้ง Remote Procedure Invocation เช่น REST, RPC เป็นต้น
ทั้ง Messaging ที่ติดต่อสื่อสารกันแบบ  asynchronous หรือเป็น protocol เฉพาะทาง

บ่อยครั้งจะพบว่า แยก service แล้ว
แต่รูปแบบการติดต่อสื่อสารกันยังผูกมัดกัน !!
มันเป็นผลมาจากการเลือกที่ไม่เหมาะสมหรือไม่ ?

สิ่งที่ขาดไม่ได้เลยคือ Service Observation 

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

• Log aggregation
• Application Metrics
• Distributed tracing
• Health check
• Log deployment and change

อีกส่วนที่มักพลาดกันเยอะคือ Database management

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

• Shared database
• Database per service
• Hybrid database

เรื่องที่คุยกันท้าย ๆ คือ Testing และ Deployment

เราจะทดสอบกันอย่างไร เราจะ deploy กันอย่างไร
จำเป็นต้องมีการออกแบบและเตรียมระบบ CI/CD ไว้เสมอ
เพื่อให้เรามีความมั่นใจต่อระบบ
เพื่อให้เราสามารถ deploy ได้บ่อยตามที่ต้องการ
เพื่อให้เรากลัวการผิดพลาดน้อยลง

Jib เป็นเครื่องมือช่วยสร้าง Docker และ OCI image
สำหรับระบบงานที่พัฒนาด้วย Java
โดยที่ไม่ต้องติดตั้งหรือมี Docker deamon 
รวมทั้งไม่ต้องเขียน Dockerfile อีกด้วย

โดยที่ Jib จะมี plugin มาให้ทั้ง Apache Maven และ Gradle เลย
หรือจะใช้งานผ่าน Jib-CLI ก็ได้

เป้าหมายของ Jib ประกอบไปด้วย

• Fast คือทำงานได้อย่างรวดเร็ว จะทำการ build เฉพาะ Layer ที่เปลี่ยนแปลงเท่านั้น โดยจะแยก layer ต่าง ๆ ไว้ให้คือ  Dependency, Java class เป็นต้น ส่วน default base image จะใช้จาก Distroless/java
• Reproducible ถ้าไม่มีการเปลี่ยนแปลงใด ๆ ก็จะไม่มีการ build อะไรให้ในขั้นตอนการสร้าง image
• Deamonless ลด dependency ต่าง ๆ ของ CLI ลงไป ทำให้สามารถใช้งานผ่าน build tool เช่น Apache Maven และ Gradle ได้เลย ไม่ต้องมี Docker deamon อีกด้วย

แสดงขั้นตอนการทำงานของ Jib เมื่อเทียบกับ Docker workflow ปกติ

Docker workflow

Jib workflow

จะเห็นได้ว่า ช่วยให้เราพัฒนาและใช้งานได้ง่ายขึ้น
รวมทั้งง่ายต่อการ integrate ไปกับ pipeline ของ CI/CD อีกด้วย
แต่แนะนำว่า ควรเข้าใจการทำงานของทั้ง 2 workflow ก่อน

ตัวอย่างการใช้งาน Jib ร่วมกับ Spring Boot application

โดยที่สร้าง project ในรูปแบบ Gradle project
ให้เพิ่ม plugin ของ Jib เข้าไปในไฟล์ build.gradle ดังนี้

จากนั้นทำการ build Image และ push ไปยัง Image registry
ที่เราต้องการทั้ง public และ private ได้เลย

ยกตัวอย่างเช่นทำการ push Image ไปยัง Docker Hub

ต้องทำการ configuration username และ password ก่อน
หรือกำหนดผ่าน secret/credential tools (Docker credential helper) ต่าง ๆ ได้
เช่น

• osxkeychain
• secretservice
• wincred
• pass

ตัวอย่างการใช้ username/password ง่าย ๆ

จากนั้นใช้คำสั่ง run ดังนี้

หรือถ้าต้องการ build ไปยัง Docker deamon ก็ใช้คำสั่ง

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

ใน VS Code มี extension ชื่อง่า REST Client
สำหรับใช้ทดสอบ RESTFul API ด้วยการส่ง HTTP Request และดู response
ใน VS Code ตรง ๆ แบบง่าย ๆ ได้เลย
ทำให้เราไม่ต้องไปใช้เครื่องมืออื่น ๆ อีกแล้ว

ใครสนใจลองทำการติดตั้งได้เลยครับ

สำหรับการจัดการพวกค่า configuration ต่าง ๆ ของระบบงาน
จาก 12-factor นั้นแนะนำให้จัดการผ่าน environment variable
เพื่อแยกระหว่าง code และ configuration ต่าง ๆ ออกจากกันในแต่ละ environment
และช่วยลดปัญหาเรื่อง security อีกด้วย

ปล. ถ้ามีการใช้งานผ่านไฟล์ configuration ก็อย่าเอาขึ้น version control ละ
เดี๋ยวจะไม่ปลอดภัยอีก !!

ในการพัฒนาระบบด้วยภาษา Go นั้น

สามารถจัดการข้อมูลผ่าน environment variable ได้หลายแบบ
ประกอบไปด้วย

• Package os ที่เป็น standard library ซึ่งง่ายที่สุด
• ใช้งานผ่าน 3-party library อื่น ๆ เช่น godotenv และ viper เป็นต้น

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

เช่น 

• Camel case
• Pascal case
• Snake case
• Kebub

ว่าจะแบ่งหรือคั่นคำในชื่อ ทำอย่างไร เช่น

• Hypen หรือ ( - )
• Underscore  หรือ ( _ )
• ใช้ตามรูปแบบของการตั้งชื่อเลย

จากคำถามนี้มีคนตอบน่าสนใจเยอะเลย

ทั้งในแง่ของรูปแบบที่ดี ทั้งในแง่ของ SEO
ทั้งในแง่ของความง่ายในการพัฒนา
ทั้งจากหนังสือต่าง ๆ ที่แนะนำ

ถ้าดูจาก URI ของ StackOverflow จะใช้

• อักษรตัวเล็กทั้งหมด
• คั่นด้วย Hypen

โดยส่วนตัวผมจะใช้  Snake case เป็นหลักเลย
เพื่อน ๆ นักพัฒนาและออกแบบใช้อะไรบ้างครับ
อย่าบอกนะว่า ใช้คนอื่น !!

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

จากนั้นทำการ run ผ่าน command line ของ DataHelix
เพื่อกำหนดจำนวนข้อมูลที่ต้องสร้าง
ผลการทำงานจะได้ข้อมูลในรูปแบบของ CSV (Comma-Separated Value)

ตัวอย่างของ configuration 

จากนั้นทำการ run คำสั่งของ DataHelix
ได้ข้อมูลในรูปแบบ CSV ดังนี้

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

ทาง Elastic เพิ่งปล่อย Elastic stack 7.9 ออกมาให้ใช้งาน
มีสิ่งที่น่าสนใจเยอะมาก (จะเยอะไปไหน)
หนึ่งในนั้นคือ Elasticsearch ซึ่งเป็นหัวใจหลักของ Elastic stack เลย
เนื่องจากเป็นที่จัดเก็บข้อมูลทุก ๆ อย่างของระบบนั่นเอง
ดังนั้น การปรับปรุงและการเพิ่มเติม feature ของ Elasticsearch
จึงส่งผลกระทบอย่างมาก

ใน Elasticsearch 7.9 มี feature ใหม่ ๆ ที่น่าสนใจดังนี้

• Data stream
• Wildcard data type เป็นชนิดข้อมูลใหม่ ช่วยทำให้การค้นหาข้อมูลเจอง่ายขึ้น มาพร้อมกับ performance ที่ดีขึ้น

Data Stream คืออะไร

เป็นแนวคิดใหม่ของการจัดการข้อมูลในรูปแบบของ time-serie
หรือข้อมูลที่มาจากระบบ Logging, monitoring และ IoT ต่าง ๆ นั่นเอง
เพื่อช่วยให้ง่ายต่อการ scale, เก็บ, ค้นหา
แน่นอนว่า ช่วยลดค่าใช้จ่ายของการจัดเก็บและจัดการ
โดยที่ได้นำแนวทางของ ILM (Index Lifecycle Management) มาใช้งานด้วย
ทำให้ Data stream เป็นชื่อใหม่ของการจัดการข้อมูลใน Elasticsearch

โดยที่ index ของ DataSteam จะมีรูปแบบดังนี้

ในการค้นหาจะไปดึงข้อมูลจาก index ต่าง ๆ

ส่วนการ index data จะไปยัง index ล่าสุด

เพิ่มชนิดข้อมูล wildcard ขึ้นมาใหม่

ช่วยทำให้การค้นหาสะดวก ง่ายและรวดเร็วขึ้น
โดยเฉพาะการใช้งานสำหรับข้อมูลด้าน security, monitoring และ log
เนื่องจากข้อมูลชนิด text และ keyword ไม่ตอบโจทย์เรื่องเหล่านี้

การทำงานภายในของ wildcard data type 
จะใช้หลักการทำงานของ n-gram สำหรับการค้นหา
โดยใช้งาน 3-gram
และเก็บข้อมูลของ doucment นั้น ๆ ด้วย binary doc value

ตัวอย่างการใช้งาน
ต้องทำการกำหนด mapping ของ field ที่ต้องการก่อนเสมอ
และทำการ indexing และ query ด้วย widecard query นั่นเอง

แถมยังมี flow การตัดสอนใจว่า เมื่อใดต้องใช้งาน

ลองใช้งานดูนะครับ ส่วน Kibana ได้ข่าวว่า
ทำการเปลี่ยนแปลง architecture ด้วย

ทาง Postman เพิ่งประกาศปล่อย Postman บน web browser
ใน beta version ให้ใช้งาน โดยมีเป้าหมายเพื่อ

• เข้าใช้งานได้ง่าย โดยไม่ต้องติดตั้ง program บนเครื่องผู้ใช้งาน
• งานต่อการ link ต่าง ๆ ภายในทีม
• การใช้งานบน browser จะมีข้อจำกัดเยอะ ดังนั้นถ้าต้องการส่ง request เยอะ ๆ ต้องติดตั้ง Postman Agent เพิ่มเติม