มุมมองของ Dev อยากได้อะไรจาก Support

หลายครั้งที่ดูงาน MA ในฝั่งของ Dev เองที่เป็นส่วนสุดท้ายที่ได้รับงานจาก Support มาแล้ว อย่างที่ บ ผม Support แยกเป็น 3 Tier App CS> Senior CS และสุดท้าย Developer นั้นเองครับ แต่การทำงานจริง Forword เมล์แบบไม่มีข้อมูลอะไรเลยมาแทน หรือไม่ดองจนวินาทีสุดท้ายที่ลูกค้าไม่จ่าย MAแล้วส่งต่อ อันหลัง ถ้าผ่านมาหลายเดือนและ หลักฐานพวก Log อะไรหายไปหมดแล้ว หรือคนที่แจ้งย้ายหน่วย อาจจะเสียชีวิตไปแล้วก็มีนะ ทางผมเองได้มีปรับ App และ Pattern มาให้ 2 Tier ก่อนหน้าให้ความเมตตาในการขอข้อมูลเตรียมไว้ หรือ กรอกไว้ เพื่อช่วยทาง Support Tier App CS > Senior CS สอบถาม End User (ลูกค้า) เพื่อลด Ticket Ping-Pong / Ticket Dancing / Mail Loop ส่งถามกันไปกันมา กว่าจะเข้าสาระอีกที 20-30 Hop และรอกันไปมา จนลูกค้าหงุดหงิด โดย Pattern ของผมจะประมาณนี้ครับ Pattern ในการเตรียมข้อมูลส่งให้ Developer – Step Action / Step to Reproduce สิ่งที่ควรถามเพิ่ม เมื่อพอได้ Setup แล้ว ทาง Support เองสามารถลอง Proof ได้ หรือ ได้ Keyword ค้น KM ข้างในองค์กร / Glossary…

The Cloud Camp Week#12 (Observability#1)

Week นี้ merge จบแล้วมั้ง สำหรับการ Merge ที่ใช้ Resource แบบเยอะมาก และเวลาประมาณ 2 Week จากงานเข้าใน Blog ตอนก่อน ใน Week นี้ระหว่างเก็บงาน Merge ฟังที่เรียนไปด้วยครับ โดยจะมีหัวข้อ ดังนี้ Observability Observability = Observe(การสังเกต) + ability (ความสามารถ) Observability = ความสามารถในการสังเกต ต่อยอดมาจากแนวคิด Control Theory ที่ติดตามสิ่งที่สนใจให้อยู่ในสภาพที่พร้อมใช้ (Desire State) จาก Output ทื่มันบอกมา อาทิ เช่น พวก Metric ยกตัวอย่างรถยนต์ มี Speed Meter / Engine Temperature เป็นต้น เพื่อให้รู้พฤติกรรมของระบบ (behavior of the system) มุมของ IT ตัว Observability เอามาใช้ autoscaling แต่การทำเรื่องนี้ต้องรู้สถานะของระบบก่อน (keeping track) ในตอนที่ Load เยอะ หรือ ตอน Error ถ้าอยากรู้ว่าเราต้องเอาตัว Observability มาใช้ไหม ให้ดูจากคำถามของ CNCF Guideline/Measure ตามนี้ Goal: เอา Data ที่ได้มาวิเคราะห์ เพื่อตอบคำถามที่อยากรู้ด้าน Observability และทำให้เกิด feedback loops มาปรับระบบให้สอดคล้อง CNCF Landscape V2 สำหรับ CNCF Landscape V2 ที่ออกออกมาแล้ว มีการจัดกลุ่มเครื่องมือสำหรับงานด้าน Observability…

เรื่องวุ่นๆของเงื่อนไขใน Jenkins Pipeline

พอดีได้วนกลับมาแก้ไข JenkinsFile เลยคิดว่าไหนๆก็มาแก้อีกรอบแล้ว มาเขียน Blog สรุปเลยดีกว่าใน Jenkins Pipeline ในตัว JenkinsFile เราสามารถเขียนเงื่อนไข หรือ Condition ได้กี่แบบ สำหรับผมจะแบ่งได้ 2 กลุ่ม ดังนี้ เงื่อนไข เพื่อให้ Stage นั้นทำงาน (ถูก Execute) สำหรับในกลุ่มเงื่อนไขที่ที่บอกให้ Stage ทำงานขึ้นมาจะใช้คำสั่ง when โดยมีรูปแบบการใช้งานได้ ดังนี้ จริงๆมันมีอีกหลายตัวเลยครับที่ใช้ได้ใน When ลองดูได้จาก Link นี้เพิ่มเติมได้ครับ แต่ส่วนตัวที่ใช้หลักๆ expression / allOf / anyOf / branch และ Environment คำสั่ง when ในตัว Pipeline ถูก Execute หลังจาก คำสั่ง agent / input / options ทำงานเรียบร้อยแล้ว ถ้าต้องการทำในส่วนของ when ก่อนก็ใช้ตัว beforeAgent / beforeInput / beforeOptions โดยกำหนดเป็น true ก่อนครับ เงือนไขใน Step สำหรับเงื่อนไขแต่ละ Step เขียนได้ 2 แบบ อ๋อ และก็เงื่อนไขแบบนี้นอกจากในส่วนของ Step ยังมาเขียนใน Post Action ได้ด้วย เช่น ในกรณี Sucess ให้ส่ง Notify เข้า mattermost และ TestReport เข้าเมล์ เป็นต้น Reference

The Cloud Camp Week#11 (ฺGitOps)

สัปดาห์งาน Merge โคตร Branch เข้ามา และมีได้ข่าวอีกว่ามีเอา App Ver pre-alpha ไปส่งลูกค้าด้วย ซึ่งมันพอดีกับ Week นี้ ที่เรียนเรื่อง SemVer พอดีแบบนัดกันมาอีก 555 สำหรับหัวข้อที่เรียนใน Week นี้ตามนี้เลยครับ Semantic Versioning (Semver) แนวทางการบอกระดับของการเติบโตของ Software โดยมีรูปแบบ ดังนี้ MAJOR.MINOR.PATCH+LABEL สำหรับใน Blog ผมเรื่อง SemVer จะมีเขียนไว้แล้วในส่วนตอนเตรียมสอบ [AZ-400] Design and implement a dependency management strategy (Implement a versioning strategy) หรือจะไปดูเอกสารของ Semantic Versioning (semver.org) Git Conventional Commits รูปแบบ <type>[optional scope]: <description>[optional body][optional footer(s)] Sample Ref: Conventional CommitsTools: commitlint – Lint commit messages / typicode/husky: Git hooks made easy  woof! (github.com) Git Workflow Workflow = Guideline บอกรูปแบบการทำงาน เพื่อให้การทำงานในทางเดียวกัน และต่อเนื่องได้ – Centralized Workflow ทำงาน Branch เดียว Trunk Base ไม่มีการแตก Branch เพิ่มใช้ร่วมกัน PRO & CON – Feature…

C# Return multiple values from method

C# Logo

ช่วงนี้พยายามจะ Refactor Code เดิมที่ทำขึิน โดยพยายามแตก Code ให้ได้ Method ที่เล็กที่สุด และอยากให้มันทำ Test Coverage ง่ายด้วย ไม่อยากจะเจอภาพแบบนี้อีกแล้ว พอที่นี้พอจะ Extract Method ดันไปเจอว่า Code มันคำนวณ 2 ค่า ใช้เงื่อนไขเดียวกัน ไม่อยากไปแยก 2 Method ตอนนี้มี 2 ทางเลือก ตอนเรียกใช้ก็ประมาณนี้ครับ แล้ว Access แต่ละ Property เรียกใช้ Item1 / Item2 …. ซึ่งมันไม่สื่อเลย แต่ในลองหาข้อมูลใน C# 7 มันเปลี่ยนแล้ว มีตัว named parameters ช่วยให้ใช้งานได้ง่ายมากขึ้นเลย ลองมาปรับ Code กันครับ ตอนเรียกใช้ก็สามารถใช้งานแบบนี้ได้เลย ค่าที่ได้จาก Method sumLeftRightSide จะอยู่ตัวแปร sumAmtRightSide/sumAmtLeftSide เอาไปใช้งานต่อได้เลยครับ ไม่ต้องมาทำเป็น เรียกใช้ Item1 / Item2 …. ซึ่งมันไม่สื่อเลย Reference

The Cloud Camp Week#10 (CI/CD – GitHub Action)

สัปดาห์นี้ Slide Event ของ DevOcean แยกร่างไม่ทัน ตอนแรก Plan จะได้วันเดียว ได้ไป 2 งานซะงั้น Architecture (plan) / Backend (Unplan) และมีเรื่องวุ่นวายในที่ทำงานพอสมควรเลย หัวร้อน และงานเข้า > ง่วงมากกก Application Delivery Source code เป็น intellectual property (ทรัพย์สินทางปัญญา มีมูลค่าทางธุรกิจ) มันสำคัญ เลยมีการ Keep Version เช่น Git ตอนทำงานมีการแยกกิ่ง(Branch) เพื่อความปลอดภัย ฮ่าๆ CI/CD Continuous Deployment – Continuous Integration + Continuous Delivery Note Step Build / Test อาจจะสลับกันได้ แล้วแต่ภาษา ทั้ง CI/CD ต้องเป็น Automate เพื่อให้เกิด Fast Feedback Loop โดยเชื่อมกับตัว Version Control เพื่อให้มี Event มา Trigger CI+CD ทำงาน นอกจากตัวความถูกต้องในตัว CI/CD ยังมีตรวจเรื่องอื่นๆ security + compliance checks โดยในตอนนี้มี Keyword ใหม่ DevSecOps Popular CI/CD: Github Action / Spinnaker (เหมาะกับระบบใหญ่) / GitLab / Jenkins / Jenkins X (For K8S…

สรุป Backend Meetup 2023

งานวันนี้จัดที่ ARIS ครับของกินพร้อม หัวข้อประมาณนี้ครับ Backend Responsibility สำหรับ Session นี้เป็น Session แห่ง Keyword ครับ ว่า Backend มีอะไรที่เกี่ยวข้องบ้าง – GraphQL มาแก้ API เรื่องเดียวกัน แต่มีหลายแบบ web / mobile มี ซ้ำซ้อน graphQL มาให้ Client มาขอ Field ที่ต้องการได้เองเลย- gRPC – lightweight soap contract สรุป อาจจะไม่ต้องมารู้ทั้งหมดก็ได้ – ไม่ได้จำเป็นต้องเลือกใช้ทุกอย่าง ตามบริบทที่เจอ – แล้วตอนลงมือทำ ไม่แตะหมด อาจจะแบ่งตาม Role / Responsibility ในองค์กร สิ่งที่สำคัญ: การเก็บองค์ความรู้ (Business Domain) ที่ตัว Backend ขมวด และจัดไว้ มันที่มูลค่าทางธุรกิจ ซึ่งหลายทีจะประสบปัญหาในการดูแล เพราะ คนออก เป็นต้น Slide: BackEnd Resposibilities เรื่อง log เรื่องเล็กเรื่องไม่ log เรื่องใหญ่ ที่มาของ log: มาจาก ship’s log ที่ใช่่คำนวณความเร็วเรือ/การเส้นทางในการเดินทาง พอนานเข้าเอามาปรับใช้เรื่อง IT โดยตัว log เรื่องง่ายๆ แต่ทำปวดหัว ตอนที่ต้องมาหาสาเหตุ Is Logging a requirement?Ans: ไม่ แต่ต้องมีหลักฐานตอนทำงาน เอาไว้สืบคดี แต่ถ้าเยอะไปก็ไม่ดี Choose the Right Log Level (Ref: What…

สรุป Software Architecture Meetup 2023

จะบอกว่าไปผิดตึกด้วย 55 นึกว่าอยู่ฟอร์จูน เลยมาดูใน Event Pop อีกที เดินมา G Tower หัวข้อประมาณ ดังนี้ Architecture Kata, Learning Software Architecture by doing Pain point Software Architecture KATA – Learn by doing ทำให้ซ้ำๆจดจำ ถ้าฝั่ง Dev Code Kata เช่น โจทย์เดียวกัน แต่ท่าไม่เหมือนกัน มี constraint เช่น ห้ามใช้ if เพื่อฝึกจะได้พร้อมตอนใช้จริง – Architecture Kata Architecture Kata คิดโดย Ted Neward มาฝึก เพื่อมาลองผิด ถูกในการทำ Architecture โดยเป็นการจับกลุ่มเล็ก แบ่งกลุ่มย่อยๆ มาลองออกแบบ โดยมี Benefit Activities Key ไม่มีผิด ถูก เน้น disscussion ได้อิสระ – Architecture Session Preparation Kata Activity Resource: Architectural Katas: Practicing Architecture Saga Pattern 101: Orchestrating Distributed Transactions SAGA pattern สำหรับ distribute Architecture มีหลาย action เกิดขึ้นต่อเนื่องกัน และมีความสัมพันธ์กัน เช่น ซื้อตั๋ว และ จองโรงแรม และ จองเครื่องบิน ถ้าสำเร็จหมด ถือว่าจองทริปสำเร็จ…