วันนี้มีคำถามเกี่ยวกับการจัดการกับ log ต่าง ๆ ของ Docker container
แน่นอนว่า มีการจัดการหลายแบบ ยกตัวอย่างเช่น

• การ map path ของไฟล์ log ออกมา
• ใช้ agent หรือตัว shipper ในการขนออกมา เช่น LogStash, Beats และ Fluentd เป็นต้น

มาดูตัวอย่างของการนำ Fluentd มาใช้กันหน่อย

Docker นั้นมี logging driver ให้อยู่แล้ว

โดยจะมี logging driver ยกตัวอย่างเช่น

• Syslog
• Fluentd 
• Gelf สำหรับ Graylog format
• None คือค่า default  จะออกไปที่ docker logs

การใช้ Fluentd ก็ไม่ยากเลย มีขั้นตอนดังนี้

ขั้นตอนที่ 1

ทำการ start Fluentd
ต้องสร้างไฟล์ config  เพื่อกำหนด input, filter และ output ของ Fluentd ก่อน
ในตัวอย่างจะเป็นการ start Fluentd server/agent ด้วย port 24224
ส่วน output จะให้แสดงไปที่ Standard output ดังนี้

จากนั้นทำการ start Fluentd ด้วย Docker ดังนี้

ขั้นตอนที่ 2

เมื่อทำการสร้าง Fluentd เรียบร้อยแล้ว ก็ลองมาใช้งานกันดู
นั่นคือ ทำการสร้าง container + logging driver ดังนี้

เพียงเท่านี้ก็สามารถเริ่มใช้งาน Fluentd logging driver ได้แล้ว

Reference Websites

• https://www.fluentd.org/guides/recipes/docker-logging
• https://docs.docker.com/config/containers/logging/fluentd/
• https://docs.docker.com/config/containers/logging/log_tags/
• https://docs.docker.com/docker-for-mac/networking/

เห็นใน feed ช่วงนี้มีเรื่องของ coding เยอะมาก ๆ
น่าจะเพราะว่า เป็นภาษาที่สามตามนโยบายของกระทรวงศึกษาธิการนั่นเอง
เหมือนจะมี drama อะไรก็ไม่รู้
แต่สิ่งหนึ่งที่น่าสนใจคือ
การออกมาให้ความคิดเห็นและบทความต่าง ๆ ที่น่าสนใจ
เลยทำการสรุปไว้หน่อย

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

บทความเรื่อง เรื่องเล่าการสอนเขียนโปรแกรมผ่านหนังสือภาพชื่อว่า Hello Ruby
ซึ่งทาง Techsauce ทำการสรุปไว้ได้อย่างน่าสนใจ

เรียน Coding แบบ offline ก็ได้
ไม่จำเป็นต้อง online หรือมีเครื่องมือเยอะเกินไป
ก็เป็นอีกทางหนึ่งที่น่าสนใจ

ทางอาจารย์ ยืน ภู่สุวรรณ 
ทำการอธิบายระหว่าง Coding และ Computer Coding(Programming)
ไว้ใน facebook ได้อย่างน่าสนใจ

ทางหนูเนยก็ยกประเด็น เรียนโค้ดดิ้งโดยไม่ต้องมีคอมพ์ได้มั้ย ?
มาอธิบายได้เห็นภาพชัดมากขึ้น

และอื่น ๆ อีกมากมาย ส่วนผมก็ไม่มีความรู้เรื่องนี้นะครับ

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

ถ้าทำแล้ว ลดการเรียนพิเศษลงได้

ผมว่าน่าจะเป็นตัววัดผลที่น่าสนใจนะครับ !!

วันนี้ลองไปใช้งาน Go Playground เล่นนิดหน่อย
ตอนนี้พัฒนาบน Go version 1.12.7
พบว่ามันสามารถทำงานได้หลายอย่างกว่าที่คิด
ซึ่งมีประโยชน์มาก ๆ
จึงทำการสรุปไว้นิดหน่อย

สามารถเขียน Test ได้

ปกติไม่เคยรู้เลยว่าใน Go Playground สามารถเขียน test ได้
แต่พอไปดูเอกสารของ Go Playground แล้ว
พบว่าสามารถเขียนได้
จึงทำให้การเรียนรู้ภาษา Go ง่ายขึ้นอีกเยอะ

สามารถ import พวก 3-party library ได้

สามารถติดตั้ง Go Playground ในระบบเราเองได้

ทำตามขั้นตอนจาก Go Playground ได้เลย ง่ายมาก

และยังสามารถ Fake สิ่งต่าง ๆ เหล่านี้ได้อีก ทั้ง

• เวลา
• File system
• Network

ทาง InfoQ ทำการสรุปแนวโน้มต่าง ๆ ของ Java ประจำเดือนกรกฎาคม
ทั้ง Java 13
ทั้ง Java 11
ทั้ง Java 8
ตลอดจนภาษา Kotlin, Graal
และพวก Microservice framework ซึ่งแสดงแนวโน้มดังรูป

จากรูปแสดงให้เห็นว่า

• ภาษา Kotlin และ Reactive Java เข้ามาอยู่ในส่วนหลักแล้ว
• ส่วน Java 8, Scala, Test framework และ Spring framework + Spring boot เป็นสิ่งที่ใช้กันเป็นปกติหรือไม่ใช้น่าจะเชย
• ส่วนตัวใหม่ ๆ ที่น่าลองคือ Java 11, Graal, OpenJ9, Helidon, Lagom, MicroProfile และ MicroNut
• ส่วน Java 13 และ Modular มันคืออนาคต

สิ่งที่น่าสนใจคือ พวก non-HotSpot JVMs
ทั้ง OpenJ9 และ Graal  นั้นเกิดมาสำหรับการ deploy ระบบงานบน Cloud
โดยเฉพาะมีการใช้ resource ที่น้อย รวมทั้ง startup ได้อย่างรวดเร็วอีกด้วย
จึงเป็นตัวเลือกที่น่าสนใจมาก ๆ

ลองใช้เป้นแนวทางในการตัดสินใจเลือกดูครับ

มีโอกาสมาแบ่งปันเรื่อง การ shared code ระหว่าง JavaScript project ?
ในงาน BKK.JS Meetup ครั้งที่ 8
โดยมีรูปแบบต่าง ๆ ที่ลองใช้งานและ fail มาแบ่งปัน  ประกอบไปด้วย

• Copy and Paste code
• สร้าง function, class, module ขึ้นมา เช่น common, shared และ utility เป็นต้น
• ใช้งาน NPM package มาช่วย ทำให้การออกแบบเป้น modular มากขึ้น
• ใช้งาน Monorepo เช่น Lerna
• ใช้งาน Git sub-modules
• ใช้งาน Bit.dev สำหรับการ shared existing module/utility/ui components

เริ่มตั้งแต่เรื่องของ code ที่ซ้ำ ๆ ใน project (duplication code)

เพียง project เดียวยังมี code ที่ซ้ำ ๆ กันพอสมควร
ยิ่งถ้าระหว่าง project แล้ว code ที่ซ้ำ ๆ ยิ่งสูงมากมาย
ยกตัวอย่างเช่น
การดู duplication code จาก repository ที่ได้รับความนิยมใน GitHub
พบว่าเกิด duplication code จำนวนมาก แสดงดังรูป

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

อ่านเอกสารเรื่อง The Road to DevTestOps แล้วน่าสนใจดี
ซึ่งมีการพูดเรื่อง DevTestOps Manifesto ประกอบไปด้วย

• Continuous testing over testing at the end
• Embracing all testing activities over only automated functional testing
• Testing what gives value over testing everything
• Testing across the team over testing in silos testing department
• Product coverage over code coverage

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

จากที่ DevOps ได้รับความนิยม

ทำให้หลาย ๆ องค์กรเริ่มนำแนวคิดนี้
มาช่วยปรับปรุงขั้นตอนการทำงานและส่งมอบ software ให้ดีขึ้น
ทำงานเป็น working group มากกว่าต่างทีมต่างทำกันไป
ดังจะเห็นได้ว่ามีแนวคิดอื่น ๆ ตามมา เช่น
DevSecOps, BizDevOps, UXOps เป็นต้น

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

เนื่องจากการพัฒนา software ส่วนใหญ่นั้น

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

แต่ก็มีบางอุตสาหกรรมที่ยอมให้ช่วงของการ testing ยาวนานได้
ยกตัวอย่างเช่น สายการแพทย์และพวก aerospace เป็นต้น

จากปัญหาดังกล่าวของการ testing

เมื่อเรื่องของ Automation testing เข้ามา
เราก็เอามาช่วยการทดสอบในส่วนของ functional เป็นหลัก
เช่น UI testing และ API testing บ้าง

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

หนักกว่านั้น การ testing ยังเป็นหน้าที่ของทีม QA/Tester อีก

ฝั่งหนึ่งสร้าง ฝั่งหนึ่งทดสอบ แยกกันไป
หรือเราเรียกการทำงานแบบนี้ว่า Silo
ก็ให้เกิดปัญหาและ overhead สูงมาก ๆ

หลาย ๆ องค์กรเริ่มนำแนวทางการพัฒนาแบบ Iterative and Incremental มาใช้

นั่นคือทำงานเป็นรอบสั้น ๆ
แต่ก็พบว่าการ testing มักอยู่ช่วงท้ายของรอบการทำงานเช่นเดิม
หรือเรามักเรียกว่า การทำงานแบบ mini-waterfall
ดังจะเห็นได้จาก board การทำงานว่า
จะมีชื่อว่า waiting to test, ready to test หรือ tested เป็นต้น
แน่นอนว่า ปัญหาไม่ได้หายไป แต่กลับหนักกว่าเดิม !!

จากปัญหาต่าง ๆ ที่เกิดขึ้นมานั้น

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

ในเอกสารได้กำหนด Principle ของ DevTestOps ไว้ดังนี้

• Platform ของการ test ต้องง่ายต่อการสร้างและดูแลรักษา
• Test ต้องพร้อมรับต่อการเปลี่ยนแปลง ดังนั้นชุดการทดสอบต้องไม่ผูกมักกับ technology ของระบบ
• Test ต้องสามารถ scale ได้ หรือนำไปทำงานบน cloud ได้
• สามารถ integrate หรือทำงานใน Delivery process ได้ดีและเร็ว เพื่อให้ได้รับ feedback ที่เร็ว
• คำว่าคุณภาพต้องได้รับการกำหนดและพัฒนาขึ้นอย่างต่อเนื่อง
• การ testing ต้องถูกฝังหรือรวมเป็นหนึ่งกิจกรรมของทีม ไม่ใช่เฉพาะใครหรือกลุ่มใดกลุ่มหนึ่งเท่านั้น รวมทั้งผลการทดสอบทีมต้องได้รับรู้อย่างสม่ำเสมอ เช่นส่งเข้า communication tool ของทีมเป็นต้น อย่าแอบ

มาถึงตรงนี้น่าจะทำให้เห็นว่า DevTestOps นั้น

ไม่ใช่เรื่องใหม่อะไร
เพียงสร้างอีกคำขึ้นมา เพื่ออธิบายให้ชัดเจนยิ่งขึ้น
เข้าใจของการทำงานร่วมกันเป็นทีมหรือ Whole Team Approach นั่นเอง

เพื่อช่วยเติ่มเติมช่องว่าระหว่าง
Business, Stakeholder, Development, Operation และอื่น ๆ อีกมากมาย
เป้าหมายหลักคือ ส่งมอบ software ได้อย่างรวดเร็วและมีคุณภาพสูงนั่นเอง
และอีกอย่างหนึ่งคือ การ testing จะเกิดขึ้นอย่างต่อเนื่องและตลอดเวลา
นั่นคือ Continuous Testing และ Keep testing visible ครับ

หลังจากก่อนหน้านี้
เขียนอธิบายการทำ Integration test ด้วย TestContainer กับภาษา Java
ตอนนี้ทางผู้พัฒนาได้เพิ่มสำหรับภาษา Go เข้ามาให้แล้ว
ชื่อว่า TestContainer Go
จะรอช้าทำไม ลองไปใช้งานกันหน่อย

เรื่องของ Integration test นั้น เป็นการทดสอบที่จำเป็นอย่างมาก

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

ก่อนอื่นก็ต้องติดตั้ง Docker ก่อนนะ

เมื่อเรียบร้อยแล้วก็มาเขียนชุดการทดสอบด้วยภาษา Go กัน
เป็นตัวอย่างของการสร้าง web server ด้วย NGINX

คำอธิบาย

ทำการ Download Docker Image ของ NGINX จาก Docker Hub
โดยรูปแบบชื่อของ Image คือ name:tag นั่นเอง
ที่สำคัญมี waiting ให้ด้วย
นั่นคือ จะรอจนกว่า NGINX จะ start เสร็จเรียบร้อย
จากนั้นจึงทำการทดสอบต่อไป
ซึ่งทำให้การจัดการ Integration test สะดวกและง่ายขึ้น

ดู VDO แนะนำได้จากงาน Docker Conf 2019

Reference Websites

• https://blog.docker.com/2019/07/maintainable-integration-tests-with-docker/
• https://www.testcontainers.org/modules/databases/

เพิ่งเห็นว่าทาง OWASP (Open Web Application Security Project)
ได้ปล่อยหนังสือเกี่ยวกับ Web Application Secure Coding Practice ด้วยภาษา Go ออกมา
โดยเนื้อหายังรวมไปถึงการพัฒนา web application ด้วย ดังนี้

• Input validation
• Output encoding
• Authentication and password management
• Session management
• Access control
• Cryptographic practice
• Error handling and logging
• Data protection
• Communication
• Database/File/Memory management

คิดว่าน่าจะมีประโยชน์ครับ ลอง Download มาอ่านได้ครับ
ไว้ว่าง ๆ จะสรุปแต่ละเรื่องไว้อ่านต่อไป

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

1. Daily 2.0

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

2. JSON Formatter

สำหรับแสดงข้อมูลในรูปแบบ JSON แบบสวยงาม
จะคล้าย ๆ กับ JSON Viwer

3. Octotree

สำหรับแสดงข้อมูลใน Github repository ในรูปแบบ tree
ทำให้เข้าดู repository ได้ง่ายและสะดวกขึ้น
แถมยังใช้งานใน Bitbucket และ Gitlab ได้อีกด้วย

4. Refined GitHub

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

ลองใช้งานกันดูครับ
น่าจะมีประโยชน์กันบ้าง

หลังจากที่ service ต่าง ๆ ที่ให้บริการลักษณะเดียวกับ GitHub
ทั้ง Bitbucket และ GitLab มี CI/CD ให้ใช้งาน
ในตอนนี้ทาง GitHub ได้เปิด GitHub Actions ใน beta version ให้ใช้งาน
แต่ต้องไปลงทะเบียนเพื่อรอคิวใช้งานกันที่ SignUp for Beta

เป้าหมายเพื่อช่วยให้ workflow ของการพัฒนาระบบงานสะดวกสบายขึ้น

สามารถกำหนดขั้นตอนการทำงานแบบอัตโนมัติได้ง่ายขึ้น
ตั้งแต่ build, test และ deploy บนระบบปฏิบัติการต่าง ๆ ได้
ทั้ง Linux, MacOS และ Windows
อีกทั้งยังสามารถ run บน Container หรือ VM ก็ได้อีก

ภาษาโปรแกรมและ framework ที่สนับสนุนประกอบไปด้วย

• Node.js
• Python
• Java
• PHP
• Ruby
• C/C++
• .Net
• Android
• iOS

อีกทั้งยังมีตัวอย่าง workflow ของระบบต่าง ๆ ให้อีก

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

ยังไม่พอนะ

ถ้าระบบงานมีการทำงานมากกว่า 1 container
เช่นระบบงานประกอบไปด้วย frontend, backend และ database
ก็สามารถนำ docker-compose มาใช้งานได้อีก
ซึ่งตรงนี้ยิ่งทำให้น่าสนใจ และอยากลองใช้งานมาก ๆ

ส่วนการทำงานต่าง ๆ ของ Actions นั้น
จะถูก trigger ให้ทำการทั้ง build, test และ deploy
ผ่าน event ต่าง ๆ ของ GitHub ได้อีกด้วย

ส่วนราคาก็ตามนี้

ตอนนี้ก็ไป SignUp เพื่อเข้าคิวเพื่อใช้งานกันครับ

วันนี้ทำการแนะนำเรื่องของ Automation testing  ในฝั่ง frontend
ซึ่งพัฒนาด้วย Angular 8
จึงลองพาทำความเข้าใจเกี่ยวกับการทดสอบ
รวมทั้งแนวคิดและลงมือเขียนขึ้นมา เป็นดังนี้

เริ่มต้นจากการอธิบายการทดสอบแต่ละแบบ

ยึดตามแนวทางของ Microservices Testing 
ซึ่งการทดสอบประกอบไปด้วย

• Unit testing
• Integration testing
• Component testing
• Contract testing
• End-to-end testing

โดยใน workshop เน้นไปที่ Unit testing

แสดงดังรูป

จากรูปแสดงโครงสร้างของระบบงาน

ที่แบ่งออกเป็นส่วน ๆ ตามหน้าที่รับผิดชอบอย่างชัดเจน ยกตัวอย่างเช่น

• Resources คือส่วนที่ผู้ใช้งานทำการติดต่อสื่อสาร เช่นรับ request ที่ส่งเข้ามา และส่ง response หรือผลลัพธ์กลับไป
• Service layer คือส่วนควบคุม flow การทำงาน
• Gateways คือส่วนติดต่อสื่อสารไปยัง external service
• Repositories คือส่วนการจัดการข้อมูลกับ data store หรือที่จัดเก็บข้อมูล

โดยแต่ละส่วนต้องสามารถทดสอบได้ว่า
ทำงานตามที่ต้องการหรือคาดหวังหรือไม่
ทั้ง success และ failure cases
จากนั้นจึงทดสอบในภาพรวมหรือการทดสอบชนิดอื่น ๆ ต่อไป

กลับมาที่การทดสอบ Unit testing สำหรับ Angular 8 กัน

สิ่งที่ Angular เตรียมไว้ให้สำหรับการทดสอบคือ TestBed
ทำหน้าที่ดังนี้

• ทำการ config และ initial สิ่งแวดล้อมต่าง ๆ สำหรับการทำ Unit test
• เตรียม method ต่าง ๆ สำหรับการสร้าง component และ service ต่าง ๆ ที่ต้องใช้งานใน Unit test

ซึ่งเพียงพอต่อการใช้งาน
ดังนั้นมาลองเขียนกันหน่อย

ส่วนที่ 1 Unit test สำหรับ Component ต่าง ๆ

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

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

• ทำการ config และ initial ของ object หรือ dependency ต่าง ๆ ที่ต้องใช้งาน ยกตัวอย่าง Component, Service, Module ที่ใช้งาน
• ทำการสร้าง component ที่ต้องการทดสอบและใช้งาน
• ทำการสร้างและ stub การทำงานของ service ต่าง ๆ ใน component ใช้งาน
• ถ้ามีการทำงานร่วมกับ service หรือส่วนงานที่ทำงานแบบ Asynchronous ก็จำเป็นต้องทดสอบด้วย fakeAsync(), async()  และ tick()
• ทำการสร้าง Test double สำหรับ dependency ต่าง ๆ เพื่อควบคุมการทำงานตามที่ต้องการ
• ทำการทดสอบและตรวจสอบผลการทำงาน

ตัวอย่าง code ทดสอบในส่วน Component ที่ใช้งาน service เป็นดังนี้

ส่วนที่ 2 Unit test สำหรับ Service ที่ทำงานกับ Http Client

จากตัวอย่างที่ใช้งานนั้น
จะเป็น Service ที่ทำการดึงข้อมูลจาก RESTFul API ผ่าน HTTP Client
โดยในการ implement จะใช้งานผ่าน HttpClientModule ที่ Angular เตรียมไว้ให้

ตัวอย่าง code ทดสอบในส่วน Service ที่ใช้งาน HTTP client เป็นดังนี้

คำอธิบาย
การทดสอบจะคล้าย ๆ กับ Component ในแง่ของการ config และ initial
สิ่งต่าง ๆ ที่ต้องใช้งานในการทดสอบ
แต่เพิ่มเข้ามาด้วย HttpTestingController
เพื่อจำลองการทำงานของ HTTP ทั้ง request และ response
ทำให้สะดวกต่อการตรวจสอบการทำงานผ่าน HTTP Client

นี่คือแนวทางหนึ่งสำหรับการทดสอบใน Angular 8
ที่นักพัฒนาน่าจะต้องมีความรู้และเข้าใจด้วยเช่นกัน
ขอให้สนุกกับการ coding ครับ

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

• Frontend เป็น web application พัฒนาด้วย Angular 8
• Backend เป็น RESTFul API พัฒนาด้วยภาษา Go

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

ดังนั้นในการพัฒนาระบบครั้งนี้
ต้องการที่จะลดค่าใช้จ่ายลงไปให้มากที่สุดหรือ 0 บาทไปเลย
โดยที่ไม่เปลี่ยนหรือกระทบการพัฒนามากนัก
มาเริ่มกันเลย

หนึ่งในแนวทางที่คิดไว้คือ

การใช้งาน Firebase Hosting และ Google Cloud Run เป็นดังนี้

• Frontend ทำการ deploy บน Firebase Hosting
• Backend ทำการ deploy บน Google Cloud Run

ป.ล.
เรื่องของ Google Cloud Run เคยเขียนอธิบายไว้แล้ว

ก่อนที่จะใช้ความสามารถนี้ต้องเปลี่ยน price plan ของ Firebase ไปที่ไม่ free นะ
เพราะว่าการเชื่อมต่อกับ Google Cloud Run
มิเช่นนั้นจะ deploy ระบบงานไปยัง Firebase Hosting ได้
จากที่ไปดู price plan แล้วพบว่า การใช้งานของระบบใช้ไม่ถึงแน่ ๆ 
ดังนั้นไม่เสียเงินแน่นอน

ปัญหาที่ต้องแก้ไขก่อนคือ

การติดต่อสื่อสารระหว่าง Fronend กับ Backend
ซึ่งปกติใช้ reverse proxy มาช่วย โดยใช้งาน NGINX นั่นเอง
แต่เมื่อเปลี่ยนมาใช้ Firebase Hosting แล้ว
ก็พบว่า สามารถกำหนด rewrite ของ URL ในฝั่ง Firebase Hosting
เพื่อทำการ redirect ไปยัง service ของ Google Cloud Run ได้

แต่มีข้อจำกัดว่า service ที่ deploy บน Google Cloud Run

ต้องเป็น type=manage เท่านั้น
ยังไม่สนับสนุน GKE นะ

ทำการ config ในไฟล์ firebase.json ดังนี้

คำอธิบาย

• ถ้าในฝั่ง frontend เรียกใช้งาน /api1 แล้ว จะทำการ redirect request ไปยัง service ใน Google Cloud Run 
• URL ในฝั่งของ Google Cloud Run  จะเป็น /api1 เช่นกัน

เพียงเท่านี้ ก็ได้วิธีการที่ช่วยให้ deploy ระบบงานตามที่ต้องการได้
แถมค่าใช้จ่ายเริ่มที่ 0 บาทเท่านั้น
มาลองใช้งานกันดูครับ ไม่ยากเลย

จากการมานั่งคุยและแบ่งปันเรื่องของการทดสอบระบบ web แบบอัตโนมัตินั้น
หนึ่งในเครื่องมือที่ลองนำมาใช้งานกันคือ Cypress
จากการลองใช้งานพบว่า
ไม่ยากแต่ก็ไม่ง่ายนัก เพราะว่า ต้องเขียน test script ในภาษา JavaScript
แต่ถ้าพูดถึงความสามารถต้องบอกว่า ดีมาก ๆ
ทั้งความเร็วในการทำงาน
ทั้ง report ของการทดสอบ ทั้ง
VDO ของการทดสอบ (ได้เฉพาะ browser เป็น electron เท่านั้น)

แต่ความสามารถที่ผมต้องการมากที่สุดคือ Test double

เพื่อจำลอง dependency ต่าง ๆ  สิ่ง Cypress สนับสนุนอยู่แล้ว คือ

• Stub, Spy และ Clock
• Network request

จากระบบงานที่ลงมือทำนั้น

ระบบ web จะทำการดึงข้อมูลจาก backend ผ่าน RESTful API
ดังนั้นสิ่งที่ต้องการคือ
การจำลองข้อมูลจาก backend ทั้งข้อมูลในกรณี success และ failure

พบว่า Cypress ทำได้ง่ายมาก ๆ นั่นคือ Network request นั่นเอง
ซึ่งทำให้การทดสอบสะดวกขึ้นมาก
ส่งผลให้ผมสามารถทดสอบแบบ Component testing ได้แบบง่าย ๆ

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

คำอธิบาย

ก่อนทำการทดสอบ จะสร้าง Mock API server ขึ้นมา
นั่นหมายความว่า ถ้าระบบทำการเรียก API ด้วย path /api1 แล้ว
(ไม่สนใจว่าจะไป Host อะไร)
จะ return ค่าจาก API ที่ mock ขึ้นมาทันที

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

สุดท้ายแล้ว เครื่องมือมันดีนะ
แต่คำถามคือ เราเขียนชุดการทดสอบนี้ตอนไหนมากกว่า !!  

เนื่องจากถ้าเขียนหลังจากพัฒนาเสร็จแล้ว น่าจะก่อให้เกิดปัญหามากกว่าหรือไม่ ?

หลังจากทำรวมรู้จักกับ GitHub Actions และลงทะเบียนขอใช้งานไป
วันนี้ก็รับ email แจ้งว่า สามารถเข้าลองใช้งานได้แล้ว
เมื่อไปดูใน repository ของเราที่ GitHub
ก็จะมี menu ชื่อว่า Actions ขึ้นมาดังนี้

ลองเข้าไปใช้งานกันดู

ขั้นตอนแรกต้องทำการสร้าง Workflow ของการทำงาน
แน่นอนว่า เพื่อความง่ายและสะดวกต่อการเริ่มใช้งาน
จึงมี template หรือตัวอย่างของ project แต่ละประเภทและภาษาให้เลย

โดยจาก repository ที่ทดลองใช้งานเป็น Java + Gradle project

ทำการ setup workflow กันเลย

จะทำการสร้างไฟล์ gradle.yml ใน folder .github/workflows ขึ้นมาดังนี้

ต่อจากนี้ต้องทำการออกแบบ Workflow CI/CD ของ project กัน

ว่าจะมีขั้นตอนการทำงานอย่างไรบ้าง ยกตัวอย่างเช่น

• ทำการ build เมื่อมีการ push มายัง branch ที่กำหนด ค่า default คือ branch master
• ให้ build บนระบบปฏิบัติการอะไร เป็น VM และสามารถกำหนดเป็น matrix ได้อีกด้วย มีให้เลือกดังนี้
  • Ubuntu 
  • Windows
  • MacOS
• กำหนด steps หรือขั้นตอนการ build ตามที่ต้องการ เช่น
  • compile
  • testing
  • packaging
  • deploy

สามารถเขียน Workflow ได้ดังนี้

โดย syntax ของการเขียน workflow สามารถดูได้จาก
Workflow syntax for GitHub Actions

เมื่อทำการ push code มาที่ repository แล้ว

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

รายละเอียดของการ build เป็นดังนี้

เพียงเท่านี้ก็ใช้งานได้แล้ว

ยังไม่พอนะ สามารถออกแบบ workflow ในรูปแบบ visualize ได้อีกด้วย
เพียงสร้างไฟล์นามสกุล workflow มาเท่านั้น
จะสามารถใช้งานได้ดังรูป

แต่ย้ำว่า GitHub Actions ยังอยู่ในสถานะ beta เท่านั้น

ดังนั้นยังมีการเปลี่ยนแปลงไปได้อีกมากมาย
แต่ถึงอย่างไรก็มาลองใช้งานกันดูครับ

จาก post ที่ Share ในกลุ่ม Clojure in Thai นั้น
เป็นข้อมูลที่น่าสนใจมาก ๆ สำหรับการพัฒนา software
แต่สิ่งที่น่าสนใจคือ
วิธีการให้ได้มาซึ่ง visualization สวย ๆ แบบใน post
ก็เลยลองตามไปใน Twitter ก็พบที่มาคือ

• Hercules
• Git of Theseus

โดยในต้นทางนั้นจะใช้ Hercules
ดังนั้นไปดูการสร้าง การทำงานของมันหน่อย

จากที่ไปดูในเอกสารของ Hercules

จะมีการทำงาน 2 ขั้นตอนคือ

ขั้นตอนที่ 1 ผ่านคำสั่ง hercules

ทำการอ่าน history ทั้งหมดจาก Git repository
มาสร้างเป็นข้อมูลในรูปแบบกราฟแบบ DAG (Directed Acyclic Graph)
เพื่อให้ง่ายต่อการวิเคราะห์
โดยขั้นตอนนี้จะพัฒนา program ด้วยภาษา Go

ขั้นตอนที่ 2 ผ่านคำสั่ง labours
ทำการแสดงผลข้อมูลที่จัดเก็บจากขั้นตอนที่ 1
โดยขั้นตอนนี้จะพัฒนา program ด้วยภาษา Python

มาลองใช้งานกันดู

ผมใช้งานผ่าน Docker Image ที่ทางทีมพัฒนา Hercules เตรียมไว้
แน่นอนว่า ไปลองกับ repository ของ Clojure ใน GitHub
ใช้เวลาการทำงานนานใช้ได้เลย
ผลเป็นดังนี้

เป็น project ที่น่าสนใจดี

ลองนำใช้งานกันดูได้ ที่สำคัญมีรูปแบบในการ visualize มากกว่านี้นะ เช่น

• เรื่องของไฟล์
• เรื่องของคนที่ contribute
• เรื่องของ Code ownership
• เรื่อง Coupling ของ code
• เรื่องอัตราการเปลี่ยนแปลง
• แถมยังสามารถเขียน plugin เพิ่มได้อีกด้วย

เท่าที่ลองก็มีหลาย ๆ project ไม่สามารถวิเคราะห์ได้
ก็ช่วยกันส่ง issue เข้าไปได้ครับ

เห็นเพื่อน ๆ ทำการ share บทความจาก Dev.to 
เรื่องเกี่ยวกับนิสัยที่ไม่ดีของนักพัฒนา software คือ

• 5 Bad Habits of Software Developers
• 7 Bad Habits of a Successful Developer

เห็นว่าน่าสนใจดีและน่าจะมีประโยชน์
จึงทำการสรุปไว้นิดหน่อย

ข้อที่ 1 ไม่มี code structure และ coding standard ที่ชัดเจน

เป็นเรื่องที่น่าสนใจมาก ๆ สำหรับการพัฒนา software
ถ้าระบบงานไม่ใหญ่ ทีมงานไม่เยอะ
เรื่องของโครงสร้างและ coding standard อาจจะไม่มีผลเท่าใดนัก

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

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

ข้อที่ 2 ยังทำงานกันหามรุ่งหามค่ำ

เป็นเรื่องที่นักพัฒนาทุกคนต้องทำและเคยทำอย่างแน่นอน
สาเหตุหลักของการทำงานหามรุ่งหามค่ำ
นั้นมีหลากหลายเหตุผล

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

แต่ productivity มันจริงไหมนะ ?
งานที่ทำในตอนกลางคืนนั้น ต้อง rework หรือไม่ 
บ่อยครั้งต้องทิ้งชิ้นงานเหล่านั้นหรือไม่

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

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

ข้อที่ 3 ขาดการเขียนเอกสารที่ดี

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

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

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

คำถามที่น่าสนใจคือ วันนี้นักพัฒนาเขียนเอกสารกันแล้วหรือยัง

ข้อที่ 4 ชอบ copy-and-paste โดยไม่เข้าใจ

การ copy-and-patse นั้นจะไม่มีปัญหาเลย
ถ้านักพัฒนารู้และเข้าใจว่า code เหล่านั้นทำงานอย่างไร
แต่บ่อยครั้งกลับพบว่า
นักพัฒนาชอบไปค้นหา solution ใน google
จากนั้นก็ไป copy solution มาใส่ใน project
ถ้าทำงานได้ตามที่คาดหวังก็ถือว่า งานจบแล้ว
แต่ไม่ได้ทำความเข้าใจต่อ code ชุดนั้นจริง ๆ

ดังนั้นถ้าเจอปัญหาลักษณะเดิมอีกครั้ง
ก็จะค้นหาเหมือนเดิม
และ copy-and-paste แบบเดิม
ซึ่งไม่น่าจะเป็นพฤติกรรมของนักพัฒนาที่ดีหรือไม่

คำถามที่น่าสนใจคือ
Code ที่นักพัฒนา copy มาใช้ เข้าใจมันจริง ๆ แล้วหรือยัง

ข้อที่ 5 ไม่เขียน Test

เป็นเรื่องที่ถูกพูดคุยกันเยอะมากขึ้นเรื่อย ๆ
ว่า code ที่นักพัฒนาเขียนขึ้นมานั้น

• ทำงานตามความคาดหวังหรือไม่
• ไม่สร้างผลกระทบต่อส่วนงานอื่น ๆ ใช่หรือไม่

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

ข้อที่ 6 ทำงานหลาย project พร้อม ๆ กัน

ปัญหาที่เจอเยอะมาก ๆ คือ งานมากกว่าคน แต่ทุกงานสำคัญหมด
ส่งผลให้นักพัฒนาแต่ละคน มีงานอยู่ในมือจนล้น
ทั้ง project เดียว
ทั้งมีมากกว่า 1 project
ผลที่ตามมาคือ
ไม่เสร็จสัก project !! หรือหนักกว่านั้นคือ bug เพียบ

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

หนึ่งในความสามารถ GitHub ที่น่าสนใจคือ Navigate code (beta version)
หรือการดูว่า method ต่าง ๆ ใน repository ที่เป็น public นั้น ๆ
ถูกประกาศจากที่ไฟล์ไหน ?
ถูก reference หรือใช้งานจากที่ไหนบ้าง ?

ความสามารถนี้สร้างมาจาก project Semantic ของ GitHub นั่นเอง
สนับสนุนภาษาโปรแกรมต่าง ๆ ดังนี้

• Go
• JavaScript
• PHP
• Python
• Ruby
• TypeScript

ลองใช้งานใน Repository ที่พัฒนาด้วยภาษา Go
ดู Definitions ดังนี้

ดู References

ทางทีมงานพัฒนาระบบ SoundCloud และ DigitalOcean
ทำการอธิบายเพิ่มเติมเรื่องสิ่งที่จำเป็นหรือต้องเตรียมพร้อม
ก่อนเข้าสู่โลกของ Microservices
ซึ่งยังคงอ้างอิงไปยังบทความ Microservice Prerequisites ของคุณ Martin Fowler

จากบทความข้างต้นอธิบายเพิ่มเติมในสิ่งที่ขาดหายไป

หลังจากที่ทำงานย้ายจากระบบเดิมที่เป็น Monolith มาเป็น Microservices
ประกอบไปด้วย 7 เรื่องดังนี้

1. Rapid provisioning of compute resources
2. Basic monitoring
3. Rapid deployment
4. Easy to provision storage
5. Easy access to the edge
6. Authentication/Authorisation
7. Standardised RPC

มาดูรายละเอียดในแต่ละข้อกัน

1. Rapid provisioning of compute resources

การเตรียม resource ต่าง ๆ สำหรับระบบงานนั้น
อาจจะเป็นทั้งเครื่อง server จริง ๆ
อาจจะเป็นทั้ง VM
อาจจะเป็นทั้ง container
อาจจะเป็นทั้ง function
หรืออาจจะรวมหลาย ๆ อย่างเข้าด้วยกัน

เพื่อใช้สำหรับการ deploy ระบบงานหรือ service ที่ออกแบบและพัฒนาขึ้นมา
ยิ่งทำการแยกเป็น service เล็ก ๆ ตามแนวคิดของ Microservices ด้วยแล้ว
ยิ่งก่อให้เกิดความซับซ้อน (Complexity) มากยิ่งขึ้น

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

2. Basic monitoring

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

ดังนั้น เรื่องระบบ Monitoring ของระบบเป็นสิ่งที่ขาดไม่ได้เลย
ทั้ง centralize logging
ทั้ง infrastructure monitoring
ทั้ง network monitoring
ทั้ง distributed tracing
ทั้ง dashboard เพื่อสรุปข้อมูลเชิงตัวเลขของระบบ (Metric)
ทั้ง alert system ที่คอยแจ้งปัญหา หรือ จุดที่อาจจะก่อให้เกิดปัญหาในอนาคตอันใกล้
เพื่อเตรียมรับมือนั่นเอง

เป้าหมายเพื่อลดเวลา MTTR (Mean Time To Recovery)
นั่นคือเวลาที่แก้ไขปัญหานั่นเอง ยิ่งน้อยยิ่งดี
โดยที่ใน MTTR ประกอบไปด้วย

• Mean Time To Detection คือเวลาการหาจุดที่ผิด
• Mean Time To Recovery คือเวลาการแก้ไขให้กลับสู่สภาวะปกติ

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

3. Rapid deployment

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

ถ้าระบบงานเป็นแบบ monolith แล้ว
การ deploy จะเป็นแบบ manual หรือใช้คนทำเป็นหลัก
เพราะว่าระบบมีความซับซ้อนสูง
มีการเปลี่ยนแปลงเยอะ
มีผลกระทบมากมาย
ทำงานร่วมกันกับหลาย ๆ ทีม หลาย ๆ คน

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

4. Easy to provision storage

ส่วนใหญ่ระบบ Monolith ที่เปลี่ยนมายัง Microservices นั้น
มักพบว่าใช้ database ขนาดใหญ่ร่วมกัน (Shared database/storage)
เพราะว่าจัดการและดูแลง่าย
เมื่อมีคนใช้จำนวนมาก จึงต้องทำการ replica ขึ้นมา
เพื่อลดความเสี่ยงของการล่มและข้อมูลหาย
แต่ปัญหาจะตามมา
เมื่อต้องทำการแก้ไขโครงสร้างของ table ใน database แล้ว
เราต้องมั่นใจว่า การแก้ไขนั้นต้องไม่กระทบต่อการทำงานของทั้งระบบ

เมื่อย้ายมายัง Microservices แล้ว
service ที่ดีนั้น จำเป็นต้องมีที่จัดเก็บข้อมูลแยกกันไป
นั่นคือลดการ JOIN ข้อมูล
แน่นอนว่า มีทั้งข้อดีและข้อเสีย
ข้อดีคือ ข้อมูลจัดเก็บแยกกันและเก็บเท่าที่ใช้งาน
ข้อเสียคือ การจัดการความถูกต้องของข้อมูล
เมื่อมีการทำงานข้าม service จะจัดการ transaction อย่างไร ?
อีกอย่างคือ อาจจะเกิดข้อมูลซ้ำซ้อนระหว่าง service จะจัดการอย่างไร ?

การจัดการที่จัดเก็บข้อมูลจึงสำคัญมาก ๆ
แต่ส่วนใหญ่มักจะหลงลืม
ไปสนใจแต่การ deploy และ provisioning server มากกว่า
ดังนั้นจึงต้องมีจัดการเรื่องนี้ที่ดี
ทั้งการ replica
ทั้งการ backup
ทั้งการจัดการเรื่องความปลอดภัย
ทั้งการ tuning
ทั้งการ monitoring และ metric ต่าง ๆ ด้วยเสมอ

แต่ถ้าทีมในบริษัทไม่มีความรู้เรื่องต่าง ๆ เหล่านี้
ก็อาจจะต้องหาผู้เชี่ยวชาญมาช่วย
หรือไปใช้บริการจาก Cloud provider ต่าง ๆ

5. Easy access to the edge

ในแต่ละ service ที่พัฒนาด้วยแนวทางของ Microservices
มักจะมีขนาดเล็ก ทำงานจบในตัวเอง
ทีมพัฒนามักจะมีขนาดไม่ใหญ่
ทดสอบได้ไม่ยาก
Deploy ก็เร็วขึ้น

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

• Rate limit
• Access log
• Feature-flag หรือ feature toggle
• Security
• Monitoring
• Metric
• Alert system
• Request routing

วิธีที่แบบง่าย ๆ คือ เปิดให้เข้าใช้แบบปกตินั่นเอง
เข้าถึงตรง ๆ เลยดังรูป

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

จากบทความต้นฉบับอธิบายว่า
เริ่มต้นด้วยการใช้ระบบ Monolith มาเป็น Gateway ก่อน แสดงดังรูป

แต่เมื่อมีจำนวน service เยอะขึ้นอีก
ทำให้การเพิ่ม service และการ deploy Monolith มีความลำบากมากยิ่งขึ้น
รวมถึง technology ที่ใช้พัฒนาก็ไม่รองรับการใช้งานจำนวนมาก ๆ ได้
ดังนั้นจึงทำการเปลี่ยนไปใช้ Gateway ที่เหมาะสมกว่า
โดยอาจจะใช้ API Gateway ที่ทำงานเรื่องนี้ได้ดีมาใช้
หรือจากบทความจำสร้าง Gateway ขึ้นมาตาม BFF pattern (Backend-For-Frontend)

6. Authentication/Authorisation

เรื่องสำคัญต่อมาของแต่ละ service คือ
ใครที่สามารถใช้งาน service ได้บ้าง ?
คำถามคือ เราจะจัดการเรื่องนี้อย่างไร ?

ในบทความจะเริ่มจากให้แต่ละ service
ตรวจสอบสิทธิ์ในการเข้าใช้งานจาก Authentication system แสดงดังรูป

ปัญหาที่เกิดขึ้น มีการทำงานส่วนการตรวจสอบสิทธิ์การใช้งานซ้ำ ๆ กันเยอะมาก
รวมทั้งเกิด overhead ในการติดต่อไปยัง  Authentication system สูงมาก ๆ
แต่เมื่อเปลี่ยนมีใช้ Gateway แล้ว
ข้อมูลต่าง ๆ จะจัดเก็บไว้ใน memory ที่ Gateway
ทำให้ไม่ต้องไปดึงข้อมูลจาก Authentication system บ่อยเกินไป
ถ้าตรวจสอบ request แล้วว่ามีสิทธิ์ใช้งานแล้ว
Gateway จะทำการ redirect request ไปยัง service ที่อยู่หลัง Gateway ดังรูป

7. Standardised RPC

เรื่องสุดท้ายคือ รูปแบบของการติดต่อสื่อสารระหว่าง service
เหมือนภาษาในการพูดคุยว่าเป็นอย่างไร
ยกตัวอย่างเช่น
การติดต่อสื่อสารผ่าน HTTP และข้อมูลอยู่ในรูปแบบ JSON
แต่ไม่ได้อธิบายถึง
การส่งข้อมูลของการ authentication และ authorisation
การจัดการเรื่อง paging ของข้อมูล
การจัดการเรื่อง tracing ของ request ต่าง ๆ
การจัดการเมื่อเกิดปัญหาขึ้นมา
ดังนั้น ควรต้องกำหนดรูปแบบที่เป็นมาตรฐานของ service ของเรา

ในบทความอธิบายว่า 
รูปแบบการติดต่อสื่อสารที่ใช้นั้น เมื่อมีการใช้งานมากขึ้น
ก่อให้เกิดปัญหาเรื่อง performance
ดังนั้นจึงเปลี่ยนไปใช้ protocol ที่เหมาะสมเช่น  
ถ้ามีการส่งข้อมูลจำนวนมาก จะไปใช้งาน Apache Thrift
หรืออาจจะไปใช้ gRPC สำหรับการติดต่อสื่อสารภายในหรือแบบ private

ทั้ง 7 เรื่องนี้เป็นสิ่งสำคัญมาก ๆ ก่อนที่จะก้าวเข้าสู่ Microservices อย่างยั่งยืน

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

จาก session เรื่อง Flutter + Kotlin-multiplatform
ในงาน Mobile Conference Thailand 2019
เป็นเรื่องที่น่าสนใจ เนื่องจากมีทั้งข้อดีและข้อเสีย
ดังนั้นมาทำความเข้าใจกับ ปัญหาที่อาจจะต้องใช้แนวทางนี้

การทำงานของ Flutter ซึ่งพัฒนาด้วยภาษา Dart

จะพบว่า Flutter จะติดต่อไปการทำงานต่าง ๆ บน device หรือ Native นั้น
ผ่านช่องทางที่เรียกว่า Platform Channel

• Android ผ่าน MethodChannel
• iOS ผ่าน FlutterMethodChannel

แสดงดังรูป

โดยปกติแล้วนั้น Flutter ก็ทำงานได้อย่างดี

แต่ก็มีงานบางอย่างที่ Flutter ไม่สามารถใช้งานได้ (ไม่สนับสนุน)
ตัวอย่างที่เจอมาก ๆ คือ 3-party SDK
ยิ่งเป็นมือถือที่มาจากประเทศจีนยิ่งมีปัญหามาก ๆ
ส่งผลให้นักพัฒนาต้องเขียน Native code เฉพาะ platform นั้น ๆ ไปเช่น
Android จะมีปัญหามากกว่า

ดังนั้นถ้ามีปัญหาเหล่านี้แล้ว
จึงต้องการแนวทางการเขียน code เหล่านี้เพียงที่เดียวก็พอ
นั่นจึงเป็นที่มาของการนำ Kotlin Multiplatform มาใช้งาน
เป็น project ที่มีเป้าหมายเพื่อ share code ระหว่าง plateform ต่าง ๆ นั่นเอง

ปล.
ถ้าไม่มีปัญหาเหล่านี้ ก็ไม่จำเป็นต้องใช้
สามารถใช้งาน Flutter + Dart แบบปกติได้เลย

โครงสร้างของ Flutter + Kotlin Multiplatform

จะมีส่วนของ common code หรือ shared code ที่พัฒนาด้วย Kotlin
แสดงดังรูป

การ setup project ก็ไม่ง่ายนะ

แต่ก็มีอธิบายอยู่คือ

• สร้าง Flutter project แบบปกติ ($flutter create -i swift -a kotlin)
• สร้าง Kotlin multiplatform ของ Android และ iOS ขึ้นมาตามเอกสาร 

ไว้มาลองสร้าง project กันดู
ฝาก link ของ GitHub จากงาน Mobile Conference Thailand
แต่เพื่อความสนุก เดี๋ยวกลับมาสร้าง project HelloWorld กันต่อไป

ปัญหาหลัก ๆ สำหรับ End-to-End testing ด้วย XCUITest

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

• Dependencies ซึ่งจัดการและควบคุมได้ยากมาก ๆ
• Concurrency คือการทดสอบพร้อม ๆ กัน
• Repeatability ไม่สามารถทดสอบซ้ำ ๆ ยิ่งกว่านั้นผลการทำงานไม่ค่อยเหมือนเดิมหรือไม่เสถียรเอาซะเลย
• ส่งผลให้ยากต่อการเขียนชุดการทดสอบ !!

จาก Pyramid Testing สามารถจับคู่กับการทดสอบใน iOS app ได้ดังนี้

• End-to-End test หรือ UI จะใช้งาน CXUITest
• Unit test จะใช้งาน XCTest
• Integration test จะใช้งาน Mobile contract test และ Mock response test เพื่อช่วยให้สามารถควบคุม dependency ต่าง ๆ ได้

แสดงดังรูป

ในส่วนของ Integration test นั่นเอง ที่ Localhost ถูกสร้างขึ้นมา

โดยพัฒนาด้วยภาษา Swift
การใช้งาน Localhost มีขั้นตอนดังนี้

• L  คือ Localhost นั่นคือการ setup in-memory server และกำหนด port ของ server ได้เลย (random ก็ได้)
• A คือ API สำหรับทำการ redirect request ไปยัง in-memory server (ทำโดยไม่แก้ไข code ในส่วน production code)
• I คือ Info.plist ทำการ config ค่าต่าง ๆ ในไฟล์นี้ ช่วยทำให้ไม่ต้องแก้ไข production code และสามารถเรียก localhost ได้
• M คือ Mock ทำการ mock response ของ in-memory server ตาม test case ที่ต้องการ

จากนั้นก็เริ่มเขียน test กันไปเลย
โดย Localhost ที่สร้างขึ้นมาและปิดไปของแต่ละชุดการทดสอบ
การทำงานของ Localhost แสดงดังรูป

ส่วน code ตัวอย่างจะอยู่ที่ GitHub :: iOS Movie App

มาดู code ตัวอย่างนิดหน่อย

จากที่ลองใช้งานหลังจากที่ฟัง

พบว่า ทำให้นักพัฒนาสามารถทดสอบ iOS app กับ API
เช่น RESTFul API ได้ง่ายขึ้น
เหมือนกับสามารถ Android ที่ใช้งาน MockWebServer เลย

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