ทาง Microsoft Azure และ Pivotal จับมือกัน
เปิดบริการใหม่ชื่อว่า Azure Spring Cloud (Private Preview)
ช่วยทำให้เราสามารถ deploy ระบบงานที่พัฒนาด้วย Spring Boot และ Spring Cloud
แน่นอนว่าอยู่ในระบบของ Microsoft Azure
เบื้องหลังของการ deploy นี้จะอยู่บน Kubernetes (AKS)

โดยบริการนี้จะถูก custom มาให้เหมาะสำหรับ production grade

จะมี component หลัก ๆ ดังนี้

• Spring Cloud ทั้ง service registry, client-side load balancing และ circuit breaker
• Kpack คือ resource controller สำหรับ Kubernetes
• Azure Kubernetes Service คือ services Kubernetes บน Microsoft Azure นั่นเอง

การใช้งานก็ไม่ยากเท่าไรนัก

เนื่องตอนนี้อยู่ในสถานะ Private Preview
สามารถไปกรอกข้อมูลเพื่อขอทดลองใช้งานได้ที่นี่

จากนั้นทำการสร้าง Azure Spring Cloud ผ่าน Marketplace ได้
ซึ่งในตอนนี้สนับสนุนในบาง region ประกอบไปด้วย

• Azure West Europe
• Azure East US
• Azure West US 2
• Azure Southeast Asia

จากนั้นจะสามารถเข้าใช้งานได้ผ่าน Portal ของ Azure Spring Cloud

และ deploy ระบบงานผ่าน Azure CLI ได้เลย 
ตัวอย่างของ app ที่ทำการ deploy แสดงดังรูป

ที่น่าสนใจคือ ทาง Azure Spring Cloud
ได้เตรียม Application Map ให้ เหมือนกับการทำ Distributed Tracing ให้กับระบบงานหรือ services ของเรานั่นเอง

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

ดังนั้นลองไปใช้งานกันดูครับ
เป็นอีกหนึ่งแนวทางในการ deploy Spring Boot App ของเรา
ในโลกของ Microservices ให้ง่ายและสะดวกมากยิ่งขึ้น

Reference Websites

• https://content.pivotal.io/blog/azure-spring-cloud-a-new-way-to-run-spring-boot-apps-atop-kubernetes
• https://azure.microsoft.com/en-us/blog/introducing-azure-spring-cloud-fully-managed-service-for-spring-boot-microservices/
• https://docs.microsoft.com/en-us/azure/spring-cloud/

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

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

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

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

ต่อมาเรื่องที่เจอบ่อยมากคือ นักพัฒนาฝึกไม่เพียงพอ

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

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

ที่สำคัญงานของนักพัฒนานั้น ไม่มีอะไรที่ง่ายเลย

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

ช่วงวันหยุดหยิบหนังสือ Remote : Office not required มาอ่านอีกครั้ง
เป็นหนังสือที่เขียนออกมาตั้งแต่ปี 2013 แล้ว
อธิบายถึงการทำงานแบบ Remote หรือบางคนเรียกว่า Work from Home
ซึ่งผมก็มีโอกาสได้ลองทำงานแบบนี้ไป 3 projects
ก็เลยทำการสรุปการอ่านหนังสือเล่มนี้ไว้นิดหน่อย

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

การทำงานแบบ Remote นั้นจะเกิดขึ้นไม่ได้ ถ้า

1. เทคโนโลยีไม่พร้อม

ทั้งช่องทางการติดต่อสื่อสารที่ถูกและสะดวกเช่น
การ share screen และ file การทำ todo-list, task board ต่าง ๆ
การพูดคุยผ่าน messaging tool ต่าง ๆ

2. ผู้ว่าจ้างไม่พร้อม

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

ที่สำคัญยังทำให้เห็นว่า
พนักงานคนไหนแย่ได้ง่ายอีกด้วย
ไม่ต้องมานั่งแอบดูเหมือนการทำงานใน office เลย

ทางผู้ว่าจ้างพร้อมหรือไม่  ?
สำหรับการทำงานแบบ remote แต่บางงานก็จำเป็นต้องทำงานที่ office นะ
ไม่ใช่ว่าทุกงานทุกประเภทจะเหมาะกับการทำงานแบบ remote

3. ผู้ถูกจ้างหรือพนักงานไม่พร้อม

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

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

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

จากที่บอกว่าการทำงานไม่ได้มีเพียงด้านดี แต่ด้านแย่ ๆ ก็มาก

ทั้งเรื่องของการพูดคุยแบบ face-to-face
บางคนบอกว่า เรามี VDO conference นะ
แต่มันก็ไม่เหมือนกันพูดคุยแบบซึ่ง ๆ หน้ากันอยู่ดี
บางครั้งทำให้เกิดการผัดวันประกันพรุ่งขึ้นอยู่บ่อย ๆ
รวมทั้งการทำงานอยู่ที่บ้าน 
อาจจะทำให้มี interrupt จากครอบครัวเยอะกว่าปกติก็เป็นไปได้

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

แต่ก็มีอีกหลายเหตุผลที่
ผู้ว่าจ้างจะยกขึ้นมา เพื่อบอกว่า เราไม่พร้อมจะทำงานแบบ remote
ซึ่งเหตุผลเหล่านั้น มันสมเหตุสมผลเสียด้วย
ทั้งมันไม่เหมาะกับ business ของเรา
ทั้งทำให้ไม่สามารถ management ควบคุมได้เลย
ทั้งเรื่องของ productivity ที่ตกลงอย่างแน่นอน

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

ในหนังสือมีคำแนะนำสำหรับการทำงานร่วมกันแบบ Remote ประกอบไปด้วย

• ถ้ามีการทำงานต่าง timezone กัน ต้องทำให้มั่นใจว่าต้องมีเวลาประมาณ 4 โมงที่ซ้อนทับกัน
• ในการติดต่อสื่อสารและทำงานร่วมกัน ต้องใช้ vdo conference และ share screen ร่วมกันเสมอ
• ข้อมูลการทำงานต่าง ๆ ต้อง share กันให้หมดทั้ง schedule, todo-list และ file ต่าง ๆ
• มีการสร้างห้องพูดคุยกันทั้งงานและเรื่องทั่วไปขึ้นมา
• ต้องมีการแบ่งปันหรือแจ้ง progress ของการทำงานอย่างสม่ำเสมอ ไม่หมกเม็ด
• ในการเริ่มต้นทำงานแบบ remote นั้นให้เริ่มเป็นทีม อย่าเริ่มเพียงไม่กี่คน
• บางครั้งการทำงานสามารถรวมกันได้ทั้ง remote และ office ในทีมเดียวกัน

ต่อไปเรื่องการทำงานแบบ Remote จะสัมพันธ์กับการว่าจ้างอีกด้วย

การทำงานแบบ remote นั้น
จะช่วยให้สามารถหาคนทำงานที่เก่งและเหมาะสมได้ดีกว่ามาก
ทั้งคนในต่างจังหวัด หรือคนจากประเทศอื่น ๆ
โดยที่คนเหล่านี้ยังได้รับผลตอบแทนเหมือนการทำงาน office ปกติ
นั่นคือการแสดงให้เห็นว่า
ทุกคนที่ทำงานมีคุณค่าเช่นเดียวกัน
ส่งผลต่อจิตใจการคนทำงานอย่างมาก
ถ้าคนทำงานมีสภาพจิตใจที่ดี ผลงานที่ออกมาก็จะดีมากอีกด้วย

สุดท้ายการทำงานแบบ Remote นั้น

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

บางคนอาจจะบอกว่า
แม้มาทำงานที่ office มีการตามงานมากมาย ยังไม่เสร็จเลย !!
แล้วจะไปทำงานแบบ remote จะรอดได้อย่างไร ?

สำหรับบริษัทที่จะเริ่มทำงานแบบ Remote นั้น
ถ้าเป็นบริษัทใหม่ ๆ ให้เริ่มตั้งแต่ต้นไปเลย
แต่ถ้าทำแบบปกติไปแล้ว อยากจะลองแบบ remote
ก็เริ่มให้การทำงานแบบ remote เป็น option ของการทำงานไป

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

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

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

ลองไปอ่านในหนังสือเพิ่มเติมครับ
มีเนื้อหาที่น่าสนใจเยอะมาก ๆ สำหรับการทำงานแบบ remote

จากการอ่านบทความเรื่อง Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database นั้น
มีเรื่องที่น่าสนใจเยอะมาก ๆ
ทั้งจำนวนทีมและ product ที่ต้องทำการย้าย
จากบทความบอกว่ามีมากกว่า 100 ทีมที่ต้องทำการย้าย
ทั้งปัญหาและประโยชน์ที่ได้รับจากการย้ายครั้งนี้

คำถามแรกคือ ย้ายไปไหน ?

คำตอบคือ ก็ย้ายไป AWS services ต่าง ๆ นั่นเอง
ทั้งพวก RDS, DynamoDB, Aurora และ Redshift เป็นต้น
ที่สำคัญทำการย้ายไปยังฐานข้อมูลที่มี data model เหมาะสมกับงานนั้น ๆ
ทั้ง relational หรือเชิงความสัมพันธ์เหมือนกับ Oracle
ทั้ง Document-based
ทั้ง Graph database
ทั้ง Key-value database
ทั้ง In-memory database
ทั้ง Data warehouse

สิ่งที่เราเห็นได้ชัดคือ 
ในแต่ละส่วนงาน
มีความจำเป็นหรือความเหมาะสมในการใช้งาน database ในรูปแบบที่ต่างกัน
ดังนั้นก็เลือกให้เหมาะกับงาน
ไม่ใช่เอาข้อมูลในรูปแบบ tree/graph มาเก็บใน relational
แบบนี้ก็ทำได้ แต่ไม่เหมาะสม
ดังนั้นเรื่องของ Polyglot database เป็นเรื่องที่หนีไม่พ้นแน่นอน

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

สามารถแบ่งรูปแบบของ service กับ database ที่เหมาะสมได้ดังตัวอย่าง

• ถ้าระบบต้องการการจัดการ trannsaction และความถูกต้องของข้อมูลเป็นส่วนหลัก ก็ไปใช้ RDS และ Aurora
• ถ้าระบบต้องการ latency ต่ำ ๆ ก็ไปใช้งาน DynamoDB
• ถ้าต้องการ scale ระบบสูง ๆ กับ non-relational database (NoSQL) ก็ไปใช้ ElastiCache
• ถ้าระบบเกี่ยวกับ Analytic ก็ไปใช้ Redshift และ Cloud data warehouse

แต่เพียงการย้ายไม่เพียงพอ ต้องดูความคุ้มค่าด้วยเสมอ

ทั้งในแง่ของค่าใช้จ่าย ประสิทธิภาพและการดูแลรักษาต่อไป
ผลที่ออกมาจาก blog ก็น่าสนใจคือ

• ลดค่าใช้จ่ายไปกว่า 60%
• ประสิทธิภาพการทำงานเร็วขึ้น ซึ่งลด latency ไปได้ถึง 40%
• การดูแลรักษาง่ายขึ้น ในส่วนนี้ลดไป 70% ไม่รู้เหมือนกันว่าวัดจากอะไร

คำถามต่อมาแล้ว Oracle DBA ละ จะไปทำอะไร ?

ในส่วนนี้สำคัญมาก ๆ  ใน blog ก็อธิบายไว้ว่า ก็จะทำการ training ให้ไปเป็น

• Database migration specialist
• Advisor

เป็นอีกหนึ่งแนวทางที่น่าสนใจของการ migrate ฐานข้อมูลเลยนะ
อีกอย่างบทความนี้มีการใช้บริการ Text-to-Speech ชื่อว่า Amazon Polly ด้วย
ทำให้เราฟังบทความนี้ได้ชิว ๆ เลย

จากบทที่ 1 ของหนังสือ Clean Agile : Back to Basics
ว่าด้วยเรื่อง Introduction to Agile
พูดเรื่องของ the Iron Cross of project management ซึ่งประกอบไปด้วย

• Good คือ คุณภาพต้องดี (Quality)
• Fast คือ ทำการตรงตามเวลา (Time)
• Cheap คือค่าใช้จ่ายไม่แพง (Cost)
• Done คือทำงานเสร็จตามขอบเขตที่ตกลง (Scope)

โดยวิธีการที่มักจะทำกันเมื่อ project มีปัญหา
เช่นทำไม่ทัน มักจะงัดวิธีการต่าง ๆ เหล่านี้มาใช้งาน

1. ขอเปลี่ยนเวลาส่งมอบ

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

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

2. เพิ่มคนเข้ามาในขณะที่กำลังพัฒนากัน

ถ้ามองในแง่ของการจัดการ ถ้า 1 คนได้ 1 งาน
ดังนั้นถ้าเรามี 100 คน ต้องได้ 100 งานแน่ ๆ มันจริงหรือไม่นะ ?

ในหนังสือ The Mythical Man-Month เขียนไว้ว่า
Adding manpower to a late project makes it later.

โดยที่การเพิ่มคนเข้ามา จะมี productivity ตามรูปนี้

3. ลดคุณภาพของการพัฒนาลงไป

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

ในหนังสือเขียนไว้ว่า 
The only way to go fast, is to go well.

4. สิ่งสุดท้ายคือการปรับเปลี่ยน scope หรือขอบเขตของงาน

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

ระหว่างที่นั่งรถไฟฟ้ามาทำงาน
ได้อ่านบทความเรื่อง 7 Great Programming Quotes
ทำการสรุป quote ต่าง ๆ ที่เกี่ยวกับ programming ไว้
เมื่ออ่านไปเรื่อย ๆ พบว่ามีหลาย quote ที่ชอบ
เลยนำมาสรุปไว้นิดหน่อย

1. เป็นการเรียนรู้จากการลงมือทำ

ซึ่งผมเชื่อว่า การลงมือทำจะทำให้เราเรียนรู้ได้ดีขึ้น
ไม่ว่าผลจะออกมาอย่างไร เชื่อว่าดีขึ้นกว่าเดิมแน่นอน

The only way to learn a new programming language is by writing programs in it.
- Dennis Ritchie

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

2. เรื่องนี้ชอบมาก ๆ เพราะว่า programming มันเป็นการรวมเอาทั้งวิทยาศาสตร์ ศิลปะและ craft มาใช้

In some ways, programming is like painting.
You start with a blank canvas and certain basic raw materials.
You use a combination of science, art, and craft to determine what to do with them.
- Andrew Hunt

3. การทดสอบนั้น จะบอกว่าเราผิดพลาดตรงไหน ซึ่งนำมาสู่ความเข้าใจ

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

Testing leads to failure,
and failure leads to understanding.
- Burt Rutan

4. การจัดการ error ที่ดี

จากบทความนั้น ยก quote มาดังนี้

The best error message is the one that never shows up.
- Thomas Fuchs

แต่ก็มีการพูดคุยกันนิดหน่อยกับ quote นี้
บางคนตีความไปว่า ก็ซ่อน error ไว้ไงละ
บางคนตีความไปว่า error message ไม่ควรชัดเจน เพราะว่าเรื่องความปลอดภัย

แต่มีการอธิบายที่น่าจะตรงกว่าคือ

Don't write better error messages,
write code that doesn't need them.
- Jason C. McDonald

หมายความว่า พยายามเขียน code ที่ปลอดภัย หรือจัดการ error ต่าง ๆ ไว้ให้ดีก่อน
ส่วน error message ไว้เป็นเรื่องรอง

5. เรื่องของการเปลี่ยนแปลง เป็นเรื่องธรรมชาติ

ดังนั้น programmer/developer ก็ต้องเรียนรู้
ที่จะรับมือและจัดการการเปลี่ยนแปลงอยู่อย่างเสมอ
อย่าไปกลัวการเปลี่ยนแปลง
มิฉะนั้น ตัวเราเองจะไม่พัฒนาขึ้นเลย

The most damaging phrase in the language is..
it's always been done this way
- Grace Hopper

ดังนั้นอย่าไปกลัวนะครับ (ถึงอย่างไรมันก็น่ากลัว)

There are only two things software professionals dislike:
the way things are, and change.”
- Tobias Mayer

6. เรื่องของความซับซ้อน (complexity)

ความซับซ้อนนั้นเกิดจาก สร้างสิ่งหนึ่งให้ทำงานมากกว่า 1 อย่าง

So much complexity in software comes from
trying to make one thing do two things.
- Ryan Singer

ปิดด้วยเรื่องตลกร้าย

Yesterday it built.
No change; today it does not.
The code has feelings.
- Pete Goodliffe

มีอีกเพียบเลยที่นี่ Good reads :: Programming Quotes
ใครมี quote ที่ชอบหรือสนใจ แนะนำกันมาได้นะ

หลังจากที่ Spring Boot 2.2.0 ออกด้วย final ออกมาให้ใช้งาน
มีการปรับปรุงหลาย ๆ อย่าง
หนึ่งในนั้นคือ การปรับปรุงประสิทธิภาพของการทำงานให้เร็วขึ้น
นั่นก็คือ Lazy initialization
ช่วยลดเวลา startup ของ application นั่นเอง
รวมทั้งยังลดจำนวนการใช้งานหน่วยความจำอีกด้วย
น่าจะทำให้การพัฒนา service ดีขึ้นอีกด้วย

มาดูการใช้งานกันหน่อย

ซึ่งไม่ได้ยากอะไรเลย เพียงแค่เพิ่ม configuration เข้าไปเท่านั้นเอง

แต่การใช้งาน Lazy initialization ก็มีข้อเสียเช่นกัน

เนื่องจากไม่ได้สร้าง instance ของ bean ต่าง ๆ ใน application ของเราขึ้นมา
ทำให้ exception ที่ต้องเกิดขึ้นตอน startup หายไป
แต่ไปเจอตอนใช้งานแทน
การส่ง HTTP request เข้ามาครั้งแรก จะใช้เวลานานขึ้น
เนื่องจากต้องไป instance ของ bean ที่ต้องใช้งานขึ้นมานั่นเอง

ใน Spring Boot 2.2.0 ยังมีความสามารถอื่น ๆ อีก

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

• สนับสนุน Java 13
• Immutable binding
• สนับสนุน RSocket
• สามารถจัดกลุ่มใน Healhcheck ผ่าน actualtor ได้ง่ายขึ้น ทำให้แยกกลุ่มระหว่าง liveness และ readiness ได้ง่าย

Reference Websites

• https://spring.io/blog/2019/10/16/spring-boot-2-2-0

จากเอกสารเรื่อง Blowing Up the Monolith: Adopting a Microservices-Based Architecture 
จากทาง KongHQ ทำการอธิบายเกี่ยวกับการนำแนวคิด Microservices
มาปรับใช้สำหรับการปรับปรุงระบบเดิมที่มีลักษณะแบบ Monolith ให้ดีขึ้น
ว่าควรพิจารณาในเรื่องใดบ้าง
รวมทั้งควรมี strategy ในเรื่องต่าง ๆ ที่ชัดเจน
หนึ่งในนั้นคือ Transition strategy

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

Transition strategy คือรูปแบบในการนำแนวคิดมาปรับใช้กับองค์กรและระบบงาน
โดยแบ่งออกเป็น 3 รูปแบบคือ

1. Ice cream scoop
2. Lego
3. Nuclear option

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

รูปแบบที่ 1 Ice cream scoop

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

รูปแบบที่ 2 Lego

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

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

รูปแบบที่ 3 Nuclear option

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

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

จากรูปแบบการย้ายไป Microservices ทั้ง 3 แบบ

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

เนื่องจากทาง Katalon ได้ปล่อย version 7 ออกมา
ซึ่งพบว่ามีการเปลี่ยนรูปแบบของ product ไปหลายตัวและหลายอย่าง
นั่นทำให้ใครก็ตามที่ใช้งานมาจนถึง version 6 อาจจะกระทบได้
เพราะว่า สิ่งที่เคยใช้ฟรีอาจจะต้องเสียเงินกันเลย
มาดูกันว่ามีอะไรเปลี่ยนแปลงบ้าง

ความสามารถใหม่ ๆ ใน Katalon Studio

• Smart Wait ช่วยแก้ไขปัญหาสำหรับการทดสอบ Web UI ด้วย selenium ซึ่งใช้งานได้ฟรีและเปิดโดย default
• เพิ่มการทดสอบ Desktop application บน Windows 10 มาให้ แน่นอนว่าสามารถ Record และ Spy ได้เช่นเดิม
• สามารถ import/export พวก test artifact ต่าง ๆ ได้ เช่น test case, test object, profile และ keyword ได้ ช่วยให้ทำงานสะดวกขึ้น
• Test suite collection สามารถกำหนดให้ run ได้ทั้งแบบ sequential และ parallel รวมทั้งเรื่อง environment ที่จะ run test และสามารถสร้าง report ได้อีกด้วย
• รวม Data test มาจากหลาย ๆ data source ได้ ซึ่งตรงนี้เสียเงิน

แต่ความสามารถต่าง ๆ เหล่านี้ ใช่ว่าจะใช้ได้ฟรีหมด
เพราะว่ามีการแยก product ออกมา คือ
Katalon Studio (KS) แบบใช้ฟรี และ Katalon Studio Enterprise (KSE) ดูได้ตามนี้

ไม่พอยังทำการแยก Katalon Runtime Engine (KRE) ออกมา

เป็น engine สำหรับการ run test ผ่านระบบ CI/CD
หรือ run  ผ่าน command line นั่นเอง
ซึ่งสามารถ activate licence ได้ทั้ง online และ offline
แต่ต้องเสียเงินนะครับ
จากเดิมที่ฟรี
ตอนนี้ต่อเดือนก็ประมาณ 50 USD !!

สรุปง่าย ๆ คือ

• Katalon Studio โดยความสามารถพื้นฐานยังคงฟรีและต้อง activate แบบ online เช่นเดิม
• Katalon Runtime Engine เป็น product ใหม่ที่ถ้าใครต้องการ run ผ่าน command line กับความสามารถอื่น ๆ ที่เป็นทีมมากขึ้นจะต้องจ่ายเงิน
• Katalon Studio Enterprise เป็น product สำหรับบริษัทหรือทีมใหญ่

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

Reference Websites

• https://www.katalon.com/resources-center/blog/katalon-studio-7-release/

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

เรื่องที่ 1 การจัดการข้อมูลใน database

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

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

เรื่องที่ 2 การ composition services

แต่ละ service นั้นบ่อยครั้งต้องทำงานร่วมกัน
ดังนั้นเราจะจัดการอย่างไร ?
แน่นอนว่า แต่ละ service ยังคงเป็นอิสระแก่กัน
การทำงานแบบเดิม ๆ เช่น synchronous หรือเรียกต่อ ๆ กันไป
และรอรับ response ไม่น่าจะรอด !!
น่าจะมีวิธีอื่นที่ดีกว่าไหม ?  เช่น

• ให้ผู้ใช้งานทำการร้อย flow การทำงานของแต่ละ service เอง
• นำแนวคิดของ Event sourcing มาช่วย

เรื่องที่ 3 Dependency hell !!

เป้าหมายของ Microservices นั้น
ต้องการให้แต่ละ service สามารถ deploy และ release ได้แบบอิสระ
ไม่ยืมจมูกคนอื่นหายใจ
ดังนั้นถ้าในแต่ละ service มี dependency เยอะ
ผลที่ตามมาคือ ประโยชน์ของ Microservices จะหมดไป !!

สิ่งที่ต้องคุยกันคือ
ในระบบงานมีการทำหรือสร้างพวก service dependency graph ขึ้นมาหรือไม่
เพื่อทำให้เรารู้ว่า dependency เป็นอย่างไรบ้าง ?
ดังนั้นในการจัดการควรต้องมองเรื่องของ versioning
รวมไปถึงเรื่องของ backward และ forward compatibility

โดยรวมแล้วนั้นเป้าหมายของ Microservices เพื่อแยกการทำงานแต่ละส่วนออกจากกัน

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

• จะทำการจัดการข้อมูลที่ share กันระหว่าง service อย่างไร ?
• แต่ละ service จะปรับปรุง API หรือ interface อย่างไร โดยยังคงความเป็นอิสระของแต่ละ service ?
• ทำการจัดการเรื่อง security อย่างไร ?
• แต่ละ service จะทำงานร่วมกันอย่างไร ?

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

ช่วงวันหยุดได้รับ email แจ้งว่า ทาง O’Reilly และ Nginx
ร่วมมือกันปล่อยหนังสือฟรี
เรื่อง Monolith to Microservices :: Evolutionary Patterns to Transform your Monolith
จำนวน 274 หน้าออกมา
เขียนโดยคุณ Sam Newman
ซึ่งเขียนหนังสือเรื่อง Building Microservices
จากเท่าที่อ่านคร่าว ๆ น่าสนใจดีครับ
ลอง download ไปอ่านกันดู

โดยหนังสือประกอบไปด้วยเรื่องต่าง ๆ ดังนี้

• ความรู้พื้นฐาน
• ข้อดีและข้อเสียของ Monilith
• แนวคิดการออกแยยระบบงานที่ดี
• พูดถึงแนวคิด Domain-Driven Design เท่าที่จำเป็นเช่น Aggregate และ Bounded context
• การวางแผนสำหรับการย้ายไปยัง Microservices เนื่องจากต้องปรับเปลี่ยนหลายส่วน
• รูปแบบของการแยก service ออกมาจาก Monolith
• รูปแบบการแยก database
• ปัญหาของการแบ่ง service นั่นคือยิ่งมากยิ่งมีปัญหาให้แก้ไขมากขึ้น ดังนั้นต้องทำอะไรบ้าง

ตั้งแต่ Elasticsearch 6.7 ขึ้นมานั้น
มี feature ชื่อว่า Index Lifecycle management (ILM) เพิ่มเข้ามา
ใช้สำหรับการจัดการ index ใน elasticsearch
ซึ่งทำให้เราสามารถจัดการ index ได้ง่ายขึ้น
ทั้งเรื่องของขนาดข้อมูล
ทั้งเรื่องของระยะเวลาในการเก็บข้อมูล
ทั้งเรื่องการกำหนดนโยบายของ index ว่าควรทำงานและใช้งานอย่างไร
ดังนั้นคนใช้งานและดูแล Elasticsearch ควรรู้และเข้าใจ
มาดูกัน

เริ่มแรกด้วย Hot-Warn-Cold architecture ของ ILM

เป็นรูปแบบของการจัดการข้อมูลแบบ time series
เช่น logging, metric ข้อมูลจากพวก sensor ต่าง ๆ
แน่นอนว่า การใช้งานข้อมูลประเภทนี้สามารถแบ่งกลุ่มได้ดังนี้

• กลุ่มที่ 1 ถูกใช้งานตลอดเวลา เช่นข้อมูลในวันนี้และในสัปดาห์นี้ จะเรียกว่า Hot 
• กลุ่มที่ 2 อาจจะมีการใช้งานบ้างแต่ไม่บ่อย เช่นในสัปหา์ก่อนหน้านี้หรือภายในเดือนนี้ จะเรียกว่า Warm
• กลุ่มที่ 3 ข้อมูลที่ไม่ถูกใช้เลยหรือนาน ๆ ครั้ง เช่นข้อมูลของเดือนก่อน 3 เดือนย้อนหลัง จะเรียกว่า Cold
• กลุ่มที่ 4 คือ Delete !!

แสดงดังรูป

แน่นอนว่า ข้อมูลทั้ง 3 กลุ่มถูกใช้งานต่างกัน
ดังนั้นการเก็บไว้ด้วยกัน มันส่งผลต่อประสิทธิภาพของการทำงานแน่นอน
ยกตัวอย่างเช่น 
เรามีข้อมูลจำนวน 1,000 ล้าน document
แต่ข้อมูลที่เราสนใจมีเพียง 1 ล้าน document
นั่นแสดงว่า เราเสียค่าใช้จ่ายและเวลาเพื่อไปหาข้อมูลเพียง 1 ล้านจาก 1,000 ล้าน
เป็นสิ่งที่สิ้นเปลืองมาก ๆ
ดังนั้นแนวคิดนี้ จึงจะเข้ามาช่วย
ให้เรากำหนดนโยบายของ index ใน Elasticsearch ได้ว่า
จะทำการแยกข้อมูลไปใน index แต่ละประเภทอย่างไรนั่นเอง

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

• Hot จะใช้เครื่องที่มี CPU, memory และ I/O สูง ๆ
• Warm, Cold เน้นไปที่ขนาดของ Disk มากกว่า

สามารถกำหนดประเภทของ node ได้ดังนี้

ต่อมาเราสามารถทำการกำหนดนโยบายของ Index ได้

กำหนดนโยบายของ index แต่ละประเภทผ่าน ILM API ได้เลย
แน่นอนว่า เราสามารถกำหนดรูปแบบการ rolling data ได้เลย ตามความต้องการ เช่น

• ตามขนาดหรืออายุของข้อมูล เพื่อสร้าง index ใหม่ขึ้นมา
• กำหนดจุดหรือเวลาของ index ที่ไม่ถูกทำการแก้ไขได้
• ทำการกำหนดจุดหรือเวลาให้ลบ index ไปเลย

มาดูตัวอย่างของการใช้งาน ILM API

สำหรับกำหนด Hot index ให้สร้าง index ใหม่
เมื่อ Index มีขนาดใหญ่กว่า 50GB
และข้อมูลมีอายุไม่เกิน 30 วัน
และจะทำการลบเมื่อข้อมูลไม่ถูกใช้งานเกิน 90 วันขึ้นไป
เขียนคำสั่งได้ดังนี้

สำหรับใครใช้งาน Elasticsearch ใหม่ ๆ 

จะพบว่า ILM เปิดใช้งานอยู่แล้วนะครับ
จะมี index มี suffix แปลก ๆ ออกมาก็ไม่ต้องตกใจ
เพราะว่า นั่นคือค่า default นั่นเอง
ลองเรียนรู้และใช้งานกันดูครับ มีประโยชน์มาก ๆ

หลังจากก่อนหน้านี้ Microsoft Azure จับมือกับ Pivotal
ทำการเปิดบริการ สำหรับการ deploy spring Boot application
บน Microsoft Azure ได้ ภายใต้ชื่อบริการ Azure Spring Cloud
ซึ่งทำงานอยู่บน Kubernetes cluster

ในตอนนี้ได้เปิดบริการเป็น public preview version
นั่นหมายความว่าเราสามารถลองเข้าไปใช้งานได้แล้ว
ดังนั้นมาลองใช้งานกันดู

โดยที่บริการนี้จะมีสิ่งต่าง ๆ ให้ใช้งาน

• Container registry เอาไว้เก็บ Container Image นั่นเองเหมือนกับ Google Cloud Registry และ Docker Hub นั่นเอง
• Service Registry ก็เอาไว้เก็บรายชื่อและรายละเอียดของ service ต่าง ๆ ใครอยากใช้งานก็มาค้นหาหรือ Discover` เอาได้เลย นี่มันเหมือน Eureka หรือ Service ใน Kubernetes นั่นเอง
• Config Server ชื่อตรง ๆ ตัวคือ เอาไว้เก็บ configuration ต่าง ๆ ของระบบงาน ถ้าเป็นพวกข้อมูลที่ private มาก ๆ ไปใช้ Azure Key Vault ได้
• ใช้งาน Data service ของ Azure ได้แน่นอน
• ยังมี Circuit Breaker Dashboard ให้อีกด้วย นี่มันคือ Hystrix ใช่ไหม ?
• มีพวก Monitoring ให้ทั้ง Alert, Metric, Logging และ Tracing

แสดงดังรูป

ก่อนอื่นก็ไปเปิดให้บริการก่อนที่ Azure Spring Cloud

จากนั้นมาเริ่มต้นการ deploy ระบบงานที่พัฒนาด้วย Spring Boot กัน

ใน blog นี้จะใช้งานผ่าน Azure CLI ดังนั้นไปติดตั้งก่อนได้เลย

ขั้นตอนที่ 1 สร้าง application ผ่าน Azure Spring Cloud

ในตัวอย่างจะสร้าง application ดังนี้

• App name  = hello-microservice
• Java environment = Java 8  (มีให้เลือก Java 11 อีกอัน)

หรือจะสร้างผ่าน Azure CLI ก็ได้ ในขั้นตอนที่ 3

ขั้นตอนที่ 2 สร้างระบบงานตัวอย่างง่าย ๆ ผ่าน Spring Initilzer 

ถ้าใครต้องการ feature ขั้นเทพ
ก็ไปเพิ่ม dependency ได้ แต่ผมต้องการแค่ hello world พอละ ไม่คิดมาก

ใช้คำสั่งสร้าง project ได้ดังนี้

ขั้นตอนที่ 3 สร้าง RESTFul API ง่าย ๆ และ deploy กัน

สร้าง JAR file และ deploy ผ่าน Azure CLI ต่อไปดังนี้

เมื่อทุกอย่างเรียบร้อย ก็ใช้งานกันเลย
มีของให้เล่นและใช้งานเพียบ ทั้ง

• Monitoring  เช่น Alert, Metric, Logging และ Distributed tracing
• Health check
• Config server

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

ปล. ใจเย็น ๆ หน่อย มิเช่นนั้นจะเจอ Error แบบนี้

วันนี้ว่าง ๆ เลยมานั่งอ่าน The InfoQ eMag - Taming Complex Systems in Production
เป็น miniBook จากทาง InfoQ
แนะนำสำหรับจัดการหรือควบคุมระบบงาน
ที่ยิ่งนานวันยิ่งมีความซับซ้อนมากขึ้นเรื่อย ๆ
ยิ่งเมื่อเกิดปัญหาขึ้นมา บ่อยครั้งต้องมีค่าใช้จ่ายสูงมากในการแก้ไข
เพื่อให้ระบบกลับมาทำงานได้อย่างปกติ

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

โดยเนื้อหาในหนังสือนี้ ประกอบไปด้วยเรื่องย่อย ๆ ดังนี้

• An Engineer’s Guide to a Good Night’s Sleep
• Designing Chaos Experiments, Running Game Days, and Building a Learning Organization
• Sustainable Operations in Complex Systems with Production Excellence
• Unlocking Continuous Testing: The Four Best Practices Necessary for Success
• Testing in Production—Quality Software Faster

ใน blog นี้มาดูเรื่อง An Engineer’s Guide to a Good Night’s Sleep กัน

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

ปล. สิ่งที่ตลกร้ายก็คือ
หลาย ๆ องค์กรมักจะมี environment เยอะมาก ๆ 
ทั้ง Dev, QA, SIT, SUT, UAT, Staging และ Production
เราจะพบว่าทุก ๆ environment จะทำงานผ่านหมด ทดสอบผ่านหมด
แต่เมื่อทำการ deploy ขึ้น Production แล้วกลับเกิดข้อผิดพลาดขึ้นมา
ลองคิดดูสิว่า มันมีอะไรแปลก ๆ ไหมนะ ?

จากหนังสือแนะนำ 5 วิธีการที่จะช่วยลดการโทรตามให้ทีมเข้ามาช่วยแก้ไขบน Production

มาดูในแต่ละวิธีการว่าเป็นอย่างไร ?

วิธีที่ 1 Enable the engineer

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

ไม่ใช่สักแต่สร้าง  แล้วมาดูกันว่าจะ operate มันอย่างไร ? 
แบบนี้มีแต่พังกับพัง !!
หลังจาก deploy ต้องมานั่งเฝ้าระบบ แก้ไขระบบเอง
นอนก็ไม่ค่อยจะหลับ เพราะว่าหวาดระแวง !!

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

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

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

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

วิธีที่ 2 Avoid out-of-hours calls, by catching more in-hours calls

หลีกเลี่ยงการโทรนอกเวลาการทำงาน
แน่นอนว่า หลาย ๆ คนบอกว่า ไม่ได้นะ
เพราะว่าระบบงานต้องทำงานได้ 24*7
ดังนั้นถ้าเกิดข้อผิดพลาดก็ต้องแก้ไขทันที !!

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

ปรับปรุงกระบวนการ Release
เป็นไปได้ยากมากที่ในแต่ละครั้งที่เรา release ระบบงานไปนั้นจะไม่มีข้อผิดพลาด
ดังนั้นทุก ๆ  release หรือ ทุก ๆ การเปลี่ยนแปลงนั้น
ก่อให้เกิดความเสี่ยงต่อการโทรมาหาเราแน่นอน !!

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

อีกประเด็นคือ เราจะลดความเสี่ยงนี้ไปได้อย่างไร ? ไม่ต้อง release เลยดีไหม ?

ระบบงานใดก็ตามที่กลัวการ release มาก ๆ
นั่นเป็นอาการของความไม่เชื่อมันต่อคนและระบบ
คำถามคือ เราไม่ทำการแก้ไขปัญหาเหล่านี้กันหรือไง ?
ถ้าการ release มันใหญ่ ก็ลดขนาดให้เล็กลง
ถ้าการ release ต้องมีงาน manual เยอะ ก็ปรับเปลี่ยนไปเป็น automated มากขึ้นไหม

ถ้าระบบต่าง ๆ ชอบมีปัญหาบ่อย ๆ
ดังนั้นควรต้องมีวิธีการทดสอบบน production ก่อนที่จะ release ไหม

หรือว่าควรมีวิธีการเปิดหรือปิด feature ต่าง ๆ กันไหม
เพื่อช่วยเพิ่มความมั่นใจในการจัดการ
หรือว่ามีวิธีการ replay request ที่ก่อให้เกิดปัญหาได้หรือไม่

สิ่งต่าง ๆ เหล่านี้คือ คำถามที่เราควรหาวิธีการเพื่อตอบให้ได้

ลดการทำงาน Batch job ลงไป
ให้เหลือเฉพาะงานที่จำเป็นจริง ๆ
งานอะไรที่ทำแบบ realtime ได้ ก็ปรับไปซะ
ยกตัวอย่างเช่น
ในทุก ๆ คืนจะต้องทำการ transform ข้อมูลขนาดใหญ่
เพื่อโยนข้อมูลไปให้อีกระบบหนึ่งทำงาน
เช่นการทำ reconcile เป็นต้น
ดังนั้นแทนที่จะทำการ transform ข้อมูลเป็น batch job
ก็แปลงมาเป็นแบบ realtime ซะเลย
ส่วนขั้นตอนการ reconcile ก็เป็น batch job ไป

วิธีที่ 3 Automate failure recovery wherever possible

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

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

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

• Graceful shutdown/terminate
• การจัดการ transaction
• Clean restart
• การจัดการเรื่องของ queue
• การทำงานต้องมีคุณสมบัติ Idempotency
• Stateless

อีกสิ่งหนึ่งที่ต้องเข้าใจคือ ระบบพังได้เสมอ
ดังนั้นโครงสร้างของระบบงานต้องมีระบบสำรองเสมอ
เช่นการทำงานแบบ Active-Active และ Active-Standby เป็นต้น

วิธีที่ 4 Understand what your customers care about
วิธีที่ 5 Break things and practice
ไว้มาเขียนต่อ มันยาวเกินไปแล้ว !!!

หลังจากทาง RedHat จะปล่อย Quarkus 1.0 ออกมา
พบว่าน่าสนใจดี มีความสามารถให้เล่นให้ใช้เยอะเลย
น่าจะเป็นอีกหนึ่งทางเลือกของเครื่องไม้เครื่องมือในการพัฒนาระบบงาน
ยิ่งพูดเรื่องของ Cloud Native แล้ว น่าจะโดนมิใช่น้อย
ดังนั้นเรามาทำความรู้จักกันนิดหน่อย

Quarkus คืออะไร ?

Quarkus is a Kubernetes Native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards.

เป้าหมายของ Quarkus คืออะไร ?

ทำให้ระบบงานที่พัฒนาด้วยภาษา Java (สนับสนุน Java 8, 11 และ 13)
สามารถทำการ deploy บน Kubernetes และ Serverless environment ได้ง่าย (Cloud Native)
โดยสนับสนุนการเขียน program ทั้งแบบ imperative และ reactive (Vert.x)

ดังนั้นแนวคิดแรกของ Quarkus คือ Container first นั่นเอง

มีขนาดของ software package ที่เล็กลงไปมาก ๆ  
(Native ด้วย GraalVM นี่ยิ่งเล็กมาก ๆ)
มี startup time เร็วมาก ๆ ใช้ resource ต่าง ๆ น้อยลงเช่น Memory เป็นต้น
ทำให้ง่ายต่อการ scale มากยิ่งขึ้น
แสดงผลการทำงานดังรูป

ในแง่ของการพัฒนา 

ก็มีเรื่องของ configuration ที่เป็นมาตรฐาน 
สามารถเริ่มต้นด้วย Zero-configuration
รวมทั้งสามารถทำงานร่วมกับเทคโนโลยีต่าง ๆ ได้ง่าย
เช่นพวก Spring framework เป็นต้น
แถมมี Live reload ด้วยนะ  

ใส่ MicroProfile OpenTracing เข้ามา
เพื่อใช้สำหรับการ tracing การติดต่อสื่อสารระหว่าง service ต่าง ๆ อีกด้วย
นี่มันเอาไปใส่ Zipkin และ Jaeger ได้เลย

รวมทั้ง  MicroProfile Metric สำหรับนำข้อมูลตัวเลขต่าง ๆ จาก JVM ออกมา
ซึ่งสามารถนำข้อมูล metric ไปเก็บไว้ยังระบบข้างนอกได้ เช่น Prometheous เป็นต้น

อธิบายเยอะไป ไม่เห็นภาพ มาลองใช้งานกันหน่อย

ขั้นตอนที่ 1 ทำการสร้าง project starter จาก https://code.quarkus.io/

มี library และรูปแบบการพัฒนาให้เลือก และทำการ generate มาใช้ได้เลย

จากรูปทำการสร้าง RESTFul API ง่าย ๆ นี่แหละ
โดย Quarkus จะเลือกใช้ JAX-RS มาเป็นตัว default
ส่วนการจัดการกับ JSON จะมีทั้ง JSON-B และ Jackson
สามารถเลือกภาษา Kotlin หรือ Scala เพิ่มได้ ยังเป็น preview version อยู่
ส่วน build tool ก็มีทั้ง Apache Maven และ Gradle (Preview version)

ขั้นตอนที่ 2 เมื่อสร้างเรียบร้อยก็ download มาและเปิดใน IDE กันเลย

ทำการ download library นิดหน่อยแค่เพียง … เยอะ !!!
พบว่าสร้างสิ่งที่เราต้องการใช้งานมาให้ครบเลย เช่น Dockerfile
ไม่ต้องมานั่งเขียนเองอีกแล้ว
แถมมีตัวอย่างของ Test ด้วยใช้งาน REST Assured นั่นเอง

รูปแบบของ RESTFul API ก็จะ ... หน่อย
เพราะว่าใช้ JAX-RS แต่ถ้าใครชอบก็น่าจะรักเลยมั้ง
พอดีผมชอบ Spring มากกว่าเท่านั้นเอง

ทำการ run ด้วยคำสั่ง

จากนั้นทดสอบ RESTFul API ผ่าน browser หรือ curl ก็ได้ เช่น

อย่าลืม feature Hot Reload ด้วยละ
ลองเปลี่ยน code เล่นดู  หรือสร้าง class ใหม่ขึ้นมาใช้งาน
พบว่า มันเปลี่ยนจริง ๆ นะ 
โดยไม่ต้องทำการ restart server ใด ๆ เลย
อันนี้สิแจ่มเลย

ส่วนการ packing software ก็ทำเช่นเดิมคือ
ทำการสร้าง JAR file ซึ่งจะเป็น executable jar file เหมือนกับ Spring Boot นั่นเอง

โดยที่ JAR file มีขนาด 205 KB เท่านั้นเอง

ขั้นตอนที่ 3 ส่วนถ้าใครสาย Native คือมี GraalVM แล้ว

ก็สามารถ build ได้เลย ด้วยคำสั่ง

ระหว่างนั่งรอเครื่องบินเข้ากรุงเทพ
อ่านบทความเรื่อง The Current and Future State of Testing: a Conversation with Lisa Crispin
พูดคุยเรื่อง สถานะปัจจุบันของการทดสอบ software ว่าเป็นอย่างไร ?
ยิ่งปัจจุบันมีการพัฒนาระบบงานเป็นรอบสั้น ๆ ด้วยแล้ว
การทดสอบจะเป็นอย่างไร ?
ยังคงทำงานในรูปแบบเดิม คือรอให้พัฒนาเสร็จทั้งหมดก่อน
แล้วจึงทำการทดสอบเพื่อหาข้อผิดพลาดอยู่ไหม ?
การทำสอบควรเป็น manual หรือ automation ?
มาดูกันเลย

การทดสอบระบบงานในโลกที่การพัฒนาระบบงานเป็นแบบรอบสั้น ๆ ( Iteration and Incremental )

หรือจะเรียกว่า Agile Testing
ซึ่งมีหนังสืออยู่ 2 เล่มคือ Agile Testing และ More Agile Testing
(แนะนำให้ไปหาอ่านกัน)
พยายามอธิบายว่า
การทดสอบนั้นจำเป็นต้องไปเกี่ยวข้องกับสิ่งต่าง ๆ เหล่านี้

• Organization
• People
• Process
• Tool
• Communication และ Collaboration

ปัญหาอย่างหนึ่งของการนำการทำงานแบบเป็นรอบสั้น ๆ มาใช้งานคืออะไร ?

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

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

แต่ถ้าฝ่าย management ไม่เข้าใจและไม่สนับสนุนเรื่องเหล่านี้
สนใจแต่ time, cost และต้องเสร็จเท่านั้น
ก็จะทำให้ทีมไม่สนใจในเรื่องของคุณภาพ !!
สนใจแต่สร้าง feature ให้เสร็จ ๆ ไป
สุดท้ายผลที่ออกมาคือ 
ทำไมยังมี bug เยอะอีกนะ
ทำไมยังทำไม่ทันเหมือนเดิม
แสดงว่า การทำงานแบบรอบสั้น ๆ ไม่ work สิ
เลิกทำดีกว่า กลับไปทำเหมือนเดิมซะ !!

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

ดังนั้น การสนใจและใส่ใจในคุณภาพนั้น 
มันคือการวางแผลและลงทุนในระยะยาว
อย่ามองอะไรเพียงสั้น ๆ มิเช่นนั้นชีวิตเราก็จะสั้นเช่นกัน

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

มีอีกกลุ่มคำถามที่น่าสนใจคือ

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

บ่อยครั้งพบว่า Automated test นั้นมีทั้ง test case ที่มีและไม่มีคุณค่า ?

แบบนี้เราจะจัดการมันอย่างไรดี ?
เพราะว่า การทดสอบนั้นเป็นหนึ่งขึ้นตอนในระบบ CI/CD นะ
ถ้า test case อะไรที่ไม่มีคุณค่า ก็ไม่น่าจะอยู่นะ
เพราะว่าเสียทั้งเวลาและค่าใช้จ่ายในการสร้างและดูแลมัน !!

การที่จะสร้างและดูแล Automated test นั้น
ทางที่ดีกว่าคือ ให้ทางนักพัฒนาทำงานร่วมกับ Tester
เพื่อสร้างชุดการทดสอบเหล่านั้นขึ้นมา
ทั้งแบบ manual และ automation เลย
โดยที่นักพัฒนาจะสร้างขึ้นมา
และ Tester จะช่วยออกแบบ test case และ test data ว่าเป็นอย่างไร
ซึ่งการทำงานร่วมกันแบบนี้ 
จะทำให้เราได้ชุดการทดสอบที่ดีและทำให้มั่นใจกว่ามาก
เหมือนการเดินไปข้างหน้าทีละก้าวอย่างมั่นคง

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

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

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

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

การจะทำให้ test case มันมีความน่าเชื่อถือ
จำเป็นต้องพูดคุย และ ทำงานร่วมกับผู้เชี่ยวชาญด้านอื่น ๆ ด้วย
เช่น infrastructure และ database administrator เป็นต้น
ทำให้เรื่องของ communication และ collaboration
เป็นความสามารถพื้นฐานที่ทุก ๆ คนต้องมี

มีคำถามเรื่องอัตราส่วนระหว่างจำนวนของนักพัฒนากับ Tester ว่าเป็นอย่างไร ?

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

ยกตัวอย่างที่เจอมาคือ
ทีมนั้นจะ focus ไปที่คุณภาพเสมอ
การเขียน test case แบบอัตโนมัติเป็นเรื่องปกติของทีมพัฒนา
ดังนั้นอัตราส่วนของ Tester ต่อ Developer เป็น 2-3 คนต่อ 30 คน
หรือบางครั้งอาจจะไม่ต้องการ Tester เลยก็ได้

มีคำถามเกี่ยวกับ AI และ Machine Learning มาช่วยในการทดสอบระบบงาน ?

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

คำถามสุดท้าย มีคำแนะนำสำหรับ Tester มือใหม่อะไรบ้าง ?

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

พบว่า 20% ของปัญหามาจากการ coding
และ 80% ของปัญหามาจากการพูดคุยติดต่อสื่อสาร

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

จะสังเกตุว่า เรื่อง soft skill สำคัญมาก ๆ
และก็อย่าลืมและฝึกฝน technical/testing skill ด้วยเสมอ

สรุปหนังสือและ link ต่าง ๆ ที่น่าสนใจ

• Agile Testing
• More Agile Testing
• Agile Testing Condensed :: A Brief Introduction
• DevTestOps
• Modern Testing Principle
• Start with a DevOps Transformation - You’ll Find Agile Along the Way

วันที่ 10 พฤศจิกายนที่ผ่านมา ครบรอบ 10 ปีของภาษา Go
ทำให้นึกถึงวันแรกที่ภาษา Go ถูกปล่อยออกมาให้ใช้งาน
ซึ่ง blog แรกที่ทางทีมพัฒนาภาษา Go เขียนขึ้นมา คือ Hey! Ho! Let's Go!
ใครยังจำได้บ้าง ?

โดยใน blog แรกนี้อธิบายว่า
ภาษา program ควรทำงานได้อย่างรวดเร็ว
ภาษา program ควรต้องเพิ่ม productivity ในการพัฒนา
ภาษา program ควรต้องมีความสนุก
นี่คือเป้าหมายหลักของภาษา Go

ภาษา Go นั้นนำความดีงามมาจากภาษาต่าง ๆ
เรื่องความเร็วของการพัฒนา เอามาจากภาษา program แบบ dynamic เหมือนกับภาษา Python
เรื่องของ performance ที่ดี เรื่องของ type safty เหมือนกับภาษา C หรือ C++
และ code ที่ถูก compile แล้ว ต้องมีความเร็วใกล้เคียงกับภาษา C
นั่นหมายความว่า ภาษา Go จะช่วยทำให้เราไปได้เร็วขึ้น

สามารถดู VDO แนะนำภาษา Go ได้อีกด้วย

จากบทความเรื่อง Microservices Testing ทั้ง 3 parts จาก InfoQ นั้น ประกอบไปด้วย

• Part 1 12 เทคนิคในการทดสอบ
• Part 2 ข้อดีข้อเสียของทั้ง 12 เทคนิค
• Part 3 เป็นกรณีศึกษาจากระบบต่าง ๆ

เป็น 3 บทความที่ทำให้เราเห็นแนวทาง
ของการทดสอบระบบงานที่ออกแบบตามแนวคิด Microservices
จึงทำการสรุปแนวทางคร่าว ๆ ไว้ดังนี้
มาดูสิ่งที่สำคัญมาก ๆ ว่ามีอะไรบ้าง ?

การจัดการกับ dependency ต่าง ๆ ที่ service ต้องใช้งาน

น่าจะเป็นปัญหาหลักของการทดสอบ
ยิ่งเป็นการทดสอบที่ใกล้ชิดกับผู้ใช้งานเท่าไร
การจัดการและควบคุม dependency ต่าง ๆ ยิ่งยากและมากขึ้นเท่านั้น
โดย dependency ก็ประกอบไปด้วย database, Web Service, API เป็นต้น

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

การทดสอบที่เพิ่มเติมเข้ามาในโลกของ Microservices คือ Contract testing

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

แต่ละทีมควรต้องทำการพูดคุยและวางแผนกันว่า

จะจัดการ dependency ต่าง ๆ อย่างไร
เช่นการทำการ Mock, Stub, Fake, Container, Virtualization อะไรก็ว่าไป
หรือในส่วนของ API ก็จะมี API Mocking Tool เพียบให้ใช้งาน

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

แน่นอนว่า การทำงานต้องเป็นทีม
ประกอบไปด้วย Architect, Developer, QA, Tester, Infrastructure  เป็นต้น
ทีมต้องเข้าใจเป้าหมายร่วมกัน จากนั้นลงมือสร้างมันขึ้นมา

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

การทดสอบระบบงานผ่าน Web browser นั้น
ส่วนใหญ่มักจะใช้งานผ่านเครื่องมือที่ชื่อว่า Selenium
ซึ่งมี library ในภาษาโปรแกรมต่าง ๆ มากมาย
แต่ปัญหาของ Selenium คือ 
เมื่อมีจำนวนของชุดการทดสอบเยอะ ๆ แล้ว
ทำให้การทดสอบช้า
การแก้ไขมักจะต้องเริ่มทำการทดสอบแบบ parallel
โดยทาง Selenium ก็มี project ชื่อว่า Selenium Grid 
ทำให้เราสามารถ scale การทดสอบผระบบด้วย Selenium ได้ดีขึ้น

คำถามคือ Zalenium สร้างมาทำไม เพื่อแก้ไขปัญหาอะไร ?

เป้าหมายของ Zalenium คือ

• Scale Selenium Grid ได้ง่าย ให้สามารถเพิ่มจำนวน node ขึ้นลงได้ตามจำนวนการใช้งาน (Elastic scaling)
• ทำงานใน Container ทำให้สะดวกต่อการใช้งาน
• ช่วยจัดการเรื่องของ driver version ในแต่ละ brower ให้เลย
• ทำการบันทึกผลการทดสอบไว้ในรูปแบบ VDO (สบายมาก ๆ)
• มี Live view ให้ของการทดสอบให้ดู
• มี dashboard แสดงการทดสอบทั้งหมดไว้ให้ รวมทั้งมีเรื่องของ authentication ไว้ให้ด้วย

ด้วยความสามารถเหล่านี้
ทำให้เราสามารถติดตั้งและดูแล Selenium Grid
ใน environment ของเราเองได้ง่ายขึ้น

การใช้งานก็ไม่ยาก ถ้ามี Docker

จากนั้นก็เข้าใช้งานผ่าน url ดังนี้

• Dashboard ของ Zalenium
• Dashboard ของ Selenium Grid
• Live view

จากนั้นก็ส่งการทดสอบไปยัง Selenium Hub
ก็สามารถใช้งานได้แล้ว  ผลการทำงานใน Dashboard ของ Zalenium เป็นดังนี้

อ่านบทความเรื่อง Test Desiderata ของคุณ Kent Beck
ซึ่งบทความนี้แปลง่าย ๆ คือ คุณสมบัติที่จำเป็นของ test นั่นเอง
โดยทำการสรุปไว้ 12 เรื่อง
จึงทำการแปลและสรุปตามความเข้าใจไว้นิดหน่อย

Isolated

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

Composable

ถ้าผ่านข้อ Isolated มาได้แล้ว
ไม่ว่าจะจัดกลุ่มการทดสอบอย่างไร
ผลการทดสอบก็ยังคงเหมือนเดิม

Fast

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

Inspiring

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

Writable

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

Readable

ชุดการทดสอบต้องอ่านเข้าใจได้ง่าย ในมุมมองผู้ผู้อ่านนะ ไม่ใช่ผู้เขียน

Behavioral

ถ้ามีการเปลี่ยนพฤติกรรมการทำงานของ production code แล้ว
ชุดการทดสอบต้องโดนผลกระทบจากการเปลี่ยนด้วยเสมอ
นั่นคือผลการทดสอบต้องเปลี่ยนไปตามพฤติกรรมที่เปลี่ยนไป

Structure-insensitive

ถ้ามีการเปลี่ยนแปลงโครงสร้างการทำงานของ production code แล้ว
ชุดการทดสอบต้องไม่กระทบจากการเปลี่ยนแปลงด้วยเสมอ
นั่นคือผลการทดสอบต้องไม่เปลี่ยนแปลงไปตามโครงสร้างของ code ที่เปลี่ยนไป
การเปลี่ยนแปลงในรูปแบบนี้ มันคือการ refactoring ชัด ๆ

Automated

การทดสอบควรทำงานแบบอัตโนมัติทั้งหมด ไม่มีคนเข้าไปยุ่งเกี่ยว

Specific

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

Deterministic

ถ้าไม่มีการเปลี่ยนแปลงใด ๆ เกิดขึ้นเลย ผลการทดสอบก็ต้องไม่เปลี่ยนเช่นกัน

Predictive

ถ้าการทดสอบผ่านทั้งหมดแล้ว
นั่นแสดงว่า product code ในขณะนั้น
เหมาะสมที่จะนำขึ้นไป deploy บน production ได้แล้ว

ปิดท้ายด้วย VDO อธิบายด้วย
ไปดูกันครับ ตัวอย่างใน VDO เป็นภาษา Ruby