พอดีต้องทำการอธิบายงานให้กับลูกค้านิดหน่อย
เลยลองหาดูว่า มีเครื่องมืออะไรให้ใช้งานบ้าง
หนึ่งในเครื่องมือที่ลองใช้แล้ว work เลย คือ
การใช้งาน Live Share Whiteboard
ซึ่งเป็น extension ใน VS Code
ช่วยทำให้สามารถ share session ผ่าน VS Codeได้เลย
แสดงการทำงานดังนี้
ลองใช้งานกันดู แจ่มเลย
จากบทความเรื่อง Watching you, with a Vue to a Kill: Wikimedia developers dismiss React for JavaScript makeover despite complaints
ดูจากหัวข้อแล้วมันก็ดราม่าเลย
แน่นอนว่า สงครามของเหล่า framework ทั้ง Vue และ React ก็ออกมาถกกัน
ซึ่งเป็นเรื่องปกติที่ไม่ปกติ เนื่องจากเกิดเรื่องแบบนี้มานานมาก ๆ
จาก Programming war มาถึง Tool war และ Framework war !!
แต่สิ่งที่น่าสนใจกว่าคือ วิธีคิด วิธีการเลือก
ว่ามีเหตุผลใดบ้าง
จากบทความนั้นได้อธิบายว่า
JavaScript framework นั้นมีหลายตัว
ทั้ง Vue, React, Angular, Ember, Svelte, Inferno, Stimulus.js และ Preact เป็นต้น
โดยที่ Angular และ Ember นั้นยังมีความยืดหยุ่นต่อการใช้งานน้อยไป
ส่วน Svelte, Inferno และ Preact นั้นยังใหม่เกิน และไม่เป็นที่นิยม
Stimulus.js นั้นยังไม่รองรับ server-side rendering
ตัวเลือกจึงเหลือเพียง Vue และ React สองตัวเท่านั้น
โดยที่ทั้งสองเปิดให้นักพัฒนาสามารถสร้าง
ส่วนการแสดงผลแบบ declrative
มีความเป็น reactive อย่างมาก
รวมทั้งเรื่องของแนวทางการออกแบบเป็น component-based
ในส่วนของ core library ก็เล็ก แรง เร็ว
อีกทั้งมี community ที่ใหญ่และแข็งแรง
ทำให้เชื่อใจได้ว่า เป็นตัวเลือกที่เหมาะสม
แต่พอไปมองในมุมของ licence และ กลุ่มที่ดูแลเป็นหลักแล้ว
Vue จะมีข้อดีกว่า คือ licence ที่ชัดเจน ไม่กำกวงเหมือน React
กับกลุ่มที่ดูแลหลักจะไม่ผูกติดเหมือน React กับ Facebook
ซึ่งมีคนตั้งข้อสังเกตไว้
ในมุมมองคนทั่วไป คงไม่คิดอะไรกันมากมั้ง !!
แต่ไม่ใช่สำหรับทีม Wikimedia นะ
ไม่ว่าจะเลือกทางไหน ผมว่า เขาน่าจะมีเหตุผลในหลาย ๆ มิติ
ไม่ใช่เพียงแค่อยากใช้เท่านั้น
ต้องมองด้าน performance, team, community
รวมทั้ง use case ที่จะนำมาใช้งานว่าเหมาะสมหรือไม่
เนื่องจากเครื่องมือทุกตัวมีจุดเด่นและด้อยของมันไป
คนที่เลือกใช้เท่านั้นที่จะรู้ดี
และต้องค่อย ๆ ลงมือทำ และวัดผล เพื่อปรับให้ตรงตามความต้องการ
ส่วนประโยคที่ผมชอบมาก ๆ คือ
There may not be a right answer, but there's always a wrong one.
ทาง Jet Brains ได้ปล่อย IntelliJ IDEA 2020.1 ใน preview version
ออกมาให้ลองใช้งาน ตัวเต็ม ๆ จะปล่อยในเดือนเมษยนนี้
ดังนั้นมาดูกันหน่อยว่า
มีความสามารถอะไรที่โดน ๆ กันบ้าง
น่าจะเพิ่ม productivity ให้นักพัฒนาขึ้นอีกเยอะ
มาเริ่มกันเลย
ก่อนอื่นทำการ Download จากที่นี่
มาดูความสามารถแรกคือ สามารถ Download JDK ใน IDE ได้เลย
ไม่ต้องไป download เองแล้ว ทำให้สะดวกสบายมากยิ่งขึ้น
แน่นอนว่ามีให้เลือกที่มีของ JDK ด้วย
เช่น OpenJDK, Amazon Corretto และ AdoptOpenJDK เป็นต้น
แสดงดังรูป
ต่อมา เป็นการสนับสนุน Java 14 แล้ว
ใครใช้แล้วบ้าง !!
เราสามารถเข้าไปเลือกใน project settings ได้เลย
ทั้ง Switch expression, records และ text blocks
ยกตัวอย่างของ Records เราสามารถสร้างและใช้งานได้เลย
สร้าง Record ได้ประมาณนี้
และลองใช้งาน Text Block ดูนิดหน่อย
ที่ชอบอีกตัวคือ Quick Type Definition
แสดง data type ที่ return จาก method นั้น ๆ ให้เห็นเลย
และยังสามารถแสดง Documentation comment ใน IDE ได้อีกด้วย
ด้วยการไป setting ค่า Render documentation comments on file opening
ใน Editor -> Appearance
ผลการทำงานเป็นดังนี้
ทำให้อ่าน document ได้งสะดวกมาก ๆ
ตัวที่น่าจะชอบกันอีกตัวคือ IDE ใน Light edit mode
คือการเปิดไฟล์ขึ้นมาด้วย คำสั่ง $idea ที่ command line
จะทำการเปิดไฟล์ขึ้นมาด้วย Light edit mode ซึ่งจะเร็วมาก ๆ
แต่ก่อนอื่นต้องสร้าง Command line launcher ก่อน
จากนั้นเปิดไฟล์ด้วยคำสั่ง $idea <filename>
จะเปิด IDE ใน Light edit mode มาดังนี้
ดูความสามารถเพิ่มเติมได้จาก VDO นี้
ช่วงนี้มีงานที่ต้องส่งให้ลูกค้าลองใช้งาน
แต่ไม่อยากลงทุนอะไรมาก
เลยคิดถึงเพื่อนเก่าอย่าง Heroku
พบว่าสามารถ deploy ระบบในรูปแบบ container ได้เลย
(น่าจะมีนานแล้ว แต่ผมไม่สนใจ)
ทำให้ deploy ระบบงานง่ายเลย
เนื่องจากไม่ต้องเปลี่ยนรูปแบบการพัฒนาอะไรเลย
มีขั้นตอนดังนี้
เริ่มจากการสร้าง Project ของเรามาก่อน
แน่นอนว่าต้องมี Dockerfile สำหรับใช้ในการสร้าง Docker image
ยกตัวอย่าง ระบบที่พัฒนาด้วย .Net Core 3.1
เมื่อเราทำการทดสอบบนเครื่องเราเรียบร้อยแล้ว
ทั้งการสร้าง Docker image และสร้าง container ขึ้น
ก็ทำการ deploy ไปยัง Heroku กัน
ขั้นตอนแรกในการ deploy ไปยัง Heroku
ทำการ login และ container login
เพื่อ deploy แบบ container
จากนั้นทำการสร้าง project ดังนี้
ต่อมาทำการ push ระบบงานเข้าไปยัง Heroku
ซึ่งจะทำการ build Docker image จาก Dockerfile
และจะ push Docker image ไปยัง Heroku registry server ดังนี้
เมื่อทุกอย่างเรียบร้อย ก็ release เลยดังนี้
และทดลองใช้งานได้เลย แต่อาจจะรอนิดหน่อยนะ เพราะว่าผมใช้ของฟรี
[gist id="1a57f9aa4dfbc487c71fa90fe63ef08a" file="3.txt"]เพียงเท่านี้ก็ deploy ได้แล้ว ง่ายมาก ๆ
มาทำความรู้จักกับ Gauge เป็น test automation framework
สำหรับการเขียน acceptance test ขึ้นมาในรูปแบบของ Markdown
ช่วยทำให้สามารถเขียนชุดการทดสอบในรูปแบบเอกสารสาร (Documentation)
ตอบโจทย์เรื่องของ Living documentation อย่างมาก
น่าจะเป็นอีกทางเลือกหนึ่งที่น่าสนใจ
มาเริ่มกันเลย
ก่อนจะเริ่มเขียนกันนั้น ต้องเข้าใจโครงสร้างการทำงานก่อน
ชุดการทดสอบด้วย Gauge ประกอบไปด้วย 2 ส่วนหลัก คือ
ในส่วนของ Steps นั้น ถ้าใครเคยเขียนพวก BDD
เช่น Cucumber จะคุ้นเคยอย่างมาก
ดังนั้น Gauge สามารถทดสอบระบบในรูปแบบใด ๆ ก็ได้
ทั้ง Web, Mobile และ API เป็นต้น
เนื่องจากการทดสอบจริง ๆ จะอยู่ในส่วนของ Steps
ซึ่งเราก็ต้องไปหา library/framework/tool มาใช้นั่นเอง
มาติดตั้ง Gauge กัน
Gauge นั้นพัฒนาด้วยภาษา Go
แต่ในการเขียน code ส่วนของ Steps นั้น
จะใช้ได้หลายภาษา program
ทั้ง Go, C#, Java, JavaScript, Python และ Ruby
รวมไปถึงการ config Editor และ IDE อีกด้วย
โดยในเอกสารจัดว่าดีมาก ๆ มีให้เลือกเลย
มันดีต่อคนเริ่มต้นใหม่มาก ๆ ดังนี้เลย
ยกตัวอย่างติดตั้งบน Mac OS ด้วย Home brew ดังนี้
[gist id="c59235d2bf0ac692f3e52341970ff18f" file="1.txt"]จากนั้นทำการติดตั้ง plugin ต่าง ๆ ที่ต้องการใช้งานทั้ง
เมื่อติดตั้งเรียบร้อย ก็ทำการเขียน Specs และ Steps ดีกว่า
ทำการสร้าง project ขึ้นมาก่อน
ตัวอย่างสร้าง project ด้วยภาษา JavaScript
ได้ผลดังนี้
จากนั้นลองเขียน Specs ง่าย ๆ กันหน่อย
ซึ่งเขียนในรูปแบบ Markdown
สามารถสร้างไฟล์ที่มีนามสกุล .md หรือ .spec ก็ได้
ซึ่งอยู่ใน folder specs ดังนี้
คำอธิบาย
ส่วนความสามารถอื่น ๆ
ก็มีทั้ง การใส่ tag เพื่อกำหนดกลุ่มของการทดสอบ
นำไปใช้งานร่วมกับการ run แบบ parallel ได้ดีมาก ๆ
การทดสอบแบบ data-driven นั่นคือใส่ข้อมูลเยอะ ๆ ในรูปแบบ table ได้
ส่วน comment คือข้อความใด ๆ ที่ไม่มีสัญลักษ์ต่าง ๆ ที่อธิบายมานะ
นั่นคือ ส่วนของการอธิบายการทดสอบนั่นเอง
ยังไม่พอ เมื่อเขียน Spec เรียบร้อยแล้ว ยังไม่สามารถทำงานได้
จะต้องเขียน Step definition ด้วยภาษา program ที่ต้องการ
จากตัวอย่างจะเขียนด้วยภาษา JavaScript Code
ส่วนนี้จะอยู่ในไฟล์ tests/step_*.js ดังนี้
จะเห็นได้ว่า เป็น code ที่ mapping Step จากไฟล์ Spec
ในรูปแบบ Markdown นั่นเอง
แน่นอนว่า ต้องมีความสามารถในการเขียน code หน่อยนะ
ดังนั้นจะทำการทดสอบแบบอัตโนมัติแล้ว จะหนีการ coding ไม่ได้เลย !!
มาลอง Run Spec ที่เขียนกันดีกว่า
ต้องติดตั้ง plugin ชื่อว่า html-report ด้วยนะ
[gist id="c59235d2bf0ac692f3e52341970ff18f" file="3.txt"]ได้ผลรายงานในรูปแบบ HTML ดังนี้
เพียงเท่านี้ก็สามารถใช้งานได้แล้วนะ
ลองใช้งานกันดู เป็นอีกเครื่องมือที่น่าสนใจ
เครื่องมือนั้นสำคัญ แต่ที่สำคัญกว่าคือ การทำงานเป็นทีม
วันนี้ได้รับ email เรื่องเกี่ยวกับ Architecture จาก InfoQ
ทำการสรุปสถาปัตยกรรมที่เปลี่ยนไปของ Istio 1.5
ซึ่งเปลี่ยนจากแนวคิดที่แบ่งเป็น component ย่อย ๆ
ใน control plane ตามแนวทาง Microservices
มาเป็น component เดียว หรือ Monolithic นั่นเอง
สิ่งที่น่าสนใจคือ เหตุผลของการเปลี่ยนแปลง
มาดูว่าเป็นอย่างไรกันบ้าง
จาก Istio 1.4 นั้น ในส่วนของ Control plane จะแยกการพัฒนาออกเป็น component ย่อย ๆ ดังนี้
แต่ใน Istio 1.5 นั้น รวมเข้าด้วยกันเป็น Istiod ดังรูป
เหตุผลของการเปลี่ยนแปลงคืออะไร ?
ทั้ง ๆ ที่ Istio นั้น ถูกสร้างขึ้นมาเพื่อ
ใช้จัดการการติดต่อสื่อสารระหว่าง service หรือ Microservices นั่นเอง
ทำให้การออกแบบช่วงเริ่มต้นแยกเป็น service หรือ component ย่อย ๆ
เพื่อจัดการในแต่ละเรื่อง
นั่นคือมีหน้าที่รับผิดชอบเรื่องเดียวไปเลย
แต่ทำไมถึงต้องเปลี่ยน ?
ด้วยการนำมารวมกันเป็น component เดียวคือ Istiod ด้วยละ
มันดูย้อนแย้งไหม
นี่คือ คำถามที่ถูกถามอย่างมาก
เหตุผลของการเปลี่ยนแปลง กลับไปที่เป้าหมายของ Istio
เป้าหมายเพื่อช่วยจัดการงานที่ยาก ๆ ให้ง่ายขึ้น
คือการติดต่อสื่อสารระหว่าง service
แต่การสร้างตัวจัดการให้ง่ายนั้นกลับไปง่าย
แถมยังมีความซับซ้อนเป็นอย่างมาก
เนื่องจาก Istio นั้นมีหลาย component ที่แยกกัน
ทำให้มี Working group ที่เยอะ แค่เห็นนี่ก็เหนื่อยเลย
แต่ข้อดีคือ แยกกันพัฒนาไปเลย
แสดงดังรูป
แต่สุดท้ายแล้วจะใช้งานต้องติดตั้ง component ต่าง ๆ ที่ต้องการใช้งานไปด้วยเสมอ
มันไม่เป็นมิตรต่อการใช้งาน
รวมทั้งการ release ต่าง ๆ ของ Istio ทำได้ยาก
เพราะว่า ต้องรอกันในหลาย ๆ component
(แสดงว่าแต่ละ component มีความสัมพันธ์กัน แล้วแยกกันไปทำไมนะ)
การจะ install และ upgrade ก็ไม่ง่ายเลย
เพราะว่าต้องทำให้ครบทุก component
หรือเมื่อเกิดปัญหา ก็ทำการ debug หรือหายากอีก
การติดต่อสื่อสารระหว่าง component ก็มี overhead อีก
จึงเกิดคำถามว่า แยกไปทำไม ?
ติดตั้งที่เดียวได้ครบเลยดีไหม
น่าจะส่งผลดีต่อ Istio มากกว่าหรือไม่
นั่นคือ ที่มาของการเปลี่ยนแปลงนั่นเอง
สิ่งที่เห็นได้ชัดจากการเปลี่ยนแปลงนี้คือ
การรู้ตัวที่รวดเร็ว และเข้าใจว่าต้องการอะไรนั่นคือ เป้าหมายหลัก
ไม่ใช่บอกว่า Microservices หรือ Monolithic นั้นผิด
มันอยู่ที่คนนำมาใช้งานมากกว่า
ว่านำมาใช้แล้วสร้างประโยชน์หรือโทษกันแน่ ( Value to Complexity )
อีกเรื่องที่น่าสนใจคือ
ถ้ารู้ว่าผลจากการตัดสินใจ
มันทำให้เรามีปัญหาแล้วก็น่าจะต้องกลับมาคิด และ ปรับปรุง
ดีกว่าทน ๆ ทำไปเหมือนเดิมนะ จริงไหม ?
แล้วคุณละ ทำไมถึงเปลี่ยน หรือ ไม่เปลี่ยน ?
Reference Websites
บันทึกการนั่งเฝ้าดูระบบ เราไม่ทิ้งกัน.com
ซึ่งบอกไว้ว่าจะเปิดให้ลงทะเบียนวันที่ 28 มีนาคม เวลา 18.00 น.
ผมก็เฝ้ารอดูระบบเลยว่าจะเอาอยู่ไหม ?
เรื่อง IT เราสนใจอยู่แล้ว
มาดูกันเป็น timeline กันเลย
เวลา 18.00 น. เข้ามาเจอเลยคือ Error XML แบบนี้
ตอนแรกเหมือนใช้งาน S3 เลย แต่พอไปดูเพื่อน ๆ พี่ ๆ บอกมาว่าใช้งาน Google Cloud Storage
แต่สักพักปัญหานี้ก็หายไป สงสัยเอาไฟล์ key ขึ้นผิดมั้ง
ต่อมากดเข้าไปลงทะเบียนก็พบ Error นี้ขึ้นมา
ลองไป inspect ดู network ใน Google Chrome พบว่า
มี API 2 ตัวที่มีปัญหาคือ
แต่ตัวที่น่าจะหนักสุดคือ api/captcha/getcaptcha
ซึ่งส่งผลให้เราไม่สามารถใช้งานระบบได้
เนื่องจากขึ้น error ดังภาพบนตลอดเวลา
ในส่วนนี้น่าจะทำงานไม่ทันกับ request ที่เข้ามาเยอะ ๆ
เป้าหมายของ api นี้น่าจะเอาไว้ป้องกัน bot ยิง
แต่ดันทำงานไม่ทัน จึงเป็นคอขวด
เลยเอาออกไปก่อนในหน้าแรก
แต่ไม่นานประมาณ 1-2 ชั่วโมงระบบก็สามารถใช้งานได้
โดยที่เราสามารถเข้าหน้าเงื่อนไข
และไปยังหน้า form ที่มีให้กรอกและขั้นตอนเยอะ
มีคนบ่นเยอะ แต่ก็นะทน ๆ กันหน่อย
ส่วนผมเห็นแล้วท้อมาก ๆ (คุณสมบัติผมไม่ผ่านนะ)
ปัญหาที่ตามมาคือ มี API บางตัวพังอีกคือ api/inquiry-geo/zipcode
เนื่องจากใน form มีให้กรอกรหัสไปรษณีย์
จากนั้นจะไปดึงข้อมูลตำบล อำเภอและจังหวัด มาให้
คิดว่าตรงนี้ข้อมูลน่าจะเก็บใน Key-value database มากกว่า
หรือ load ใน memory ไว้รอเลย
ที่มีปัญหาน่าจะเรื่องของ scaling มากกว่ามั้ง !!
หลังจากนั้นก็ใช้งานได้ปกตินะ แต่ก็ดันมาติดปัญหาที่การส่ง OTP อีก
จากที่เคยทำระบบนี้มา มันมี 2 ขั้นตอนคือ
ผมก็ไม่แน่ใจว่า มีปัญหาตรงไหนนะ
แต่เท่าที่ดูใน timeline ก็จะบอกว่าเป็นทั้งสองขั้นตอน
ตอนนี้ระบบทำงานได้ คิดว่าน่าจะตัดขั้นตอนนนี้ออกไป
แล้วทยอยส่งสร้างและส่ง OTP code กันใหม่
เท่าที่ติดตาม พบว่าแก้ปัญหาได้เร็วมาก ๆ
รวมทั้งการ scale ระบบให้รองรับคนเยอะ ๆ ก็ทำได้ดีเลย
ติดตรงที่ First impression นี่แหละ ที่เข้ามา Error เลย
ส่วนที่เหลือก็ให้กำลังใจทีมที่ทำครับ น่าจะงานร้อนน่าดู
ส่วนตอนนี้ที่เข้าไปดูเวลา 23.58 น.
พบว่า มีคนลงทะเบียนเข้ามาเกิน 8 ล้านคนแล้ว
พรุ่งนี้เช้าน่าจะทะลุ 10 ล้านหรือเปล่านะ !!
แน่นอนว่า ต้องรอ verify คุณสมบัติกันอีกรอบ
ขอเป็นกำลังใจให้กับทีมงานครับ
เพิ่มเติมจากทีมพัฒนาระบบใน 2 ชั่วโมงแรกของการแก้ไข และ monitor ระบบยันเที่ยงคืน
สรุปแนวทางในการพัฒนาต่าง ๆ ของระบบ
การ share code ให้สวย ๆ นั้น เครื่องมือมีเยอะเลย
แต่เครื่องมือที่ใช้บ่อย ๆ ก็ทำการ capture หรือ copy จาก IDE และ Text Editor เลย
แต่ถ้าอยากให้สวย ๆ ก็มีเครื่องมือแนะนำเช่นกัน
หนึ่งในเครื่องมือคือ Carbon
สามารถเข้าไปใช้ผ่าน web ของ Carbon ได้เลย
จากนั้นก็เลือก theme, format และ สี ใส่ code ที่ต้องการ share
สุดท้ายก็ share หรือ export เป็นรูปภาพได้เลย
หรือลง Extension ใน VS Code ก็ได้เช่นกัน
ลองใช้กันดูครับ สะดวกดี
จาก Live กับหนึ่งในทีมพัฒนาของระบบเราไม่ทิ้งกัน จาก page รู้ไม่มากแต่อยากเล่า
ที่เปิดให้คนไทยที่ได้รับผลกระทบจาก COVID-19 มาลงทะเบียน
เพื่อรับเงินเยียวยา
ดังนั้นจึงทำการสรุปสั้น ๆ ไว้หน่อย
โดยทำการสรุปในส่วนที่ผมสนใจไว้นิดหน่อย
คำถามแรก สาเหตุที่ระบบล่มในช่วงแรก
ทำให้คนใช้งานเจอ popup ไม่สามารถใช้งานได้นั่นเอง
เกิดจากการ generate captcha จริง ๆ
เนื่องจากการ generate captcha จะสร้าง image ขึ้นมา
ซึ่งใช้ CPU จำนวนมาก
นั่นส่งผลต่อการทำงานโดยรวมของระบบเลย
ระบบงานทำการเตรียม Node จำนวน 1,000 node ใน Kubernetes cluster
และเตรียมการ scale ไว้แบบอัตโนมัติ
ทีมงานเคยมีประสบการกับ ชิม ช้อบ ใช้มาแล้ว
โดยมองว่าระบบ เราไม่ทิ้งกัน ต้องเยอะกว่าแน่นอน
ดังนั้นเตรียมไว้ 10 เท่าไปเลย
ก่อนเปิดระบบงานพบว่ามีคนมารอกว่า 20 ล้าน request
ทั้งหมดนี้เข้ามาตอนเปิดระบบเลย
นั่นทำให้ระบบไม่สามารถรองรับได้
ระบบรวนไปหมด
ทีมงานพยายามแก้ไขประมาณ 10-20 นาที
แต่ปัญหายังไม่หาย
ทีมพัฒนาจึงตัดสินใจที่จะ reset ระบบเพื่อแก้ไข
จากนั้นค่อย ๆ แก้ไข
โดยเริ่มจากการพูดคุยกับทีมพัฒนา
ทำการอธิบาย business flow
เพื่อให้ทีมทั้งหมดเข้าใจ ทำให้เห็นปัญหาที่แท้จริง
จะได้แก้ไขได้ถูกต้อง
จากนั้นก็ค่อย ๆ recovery ระบบแบบค่อยเป็นค่อยไปตาม business flow
โดยสิ่งที่สำคัญคือ ระบบ monitoring ที่ทำการ monitoring ทุกจุด
ทำงานกันเป็นทีมทั้งภายในและภายนอกที่สนับสนุนอยู่
ในการ scale ทำแบบ manual กันไปเลย
เพื่อให้เหมาะสมตามการใช้งานจริง ๆ ซึ่งเหมาะสมกว่าแบบ auto
ปัญหาต่อมาคือเรื่องของการส่ง OTP
ซึ่งจะส่งผ่าน TRUE แน่นอนว่าเต็มที่ของการส่งแล้ว
โดยทำการ scale ไปจนถึง 5,000 TPS ก็ยังรับไม่ไหว
ต่อมาสรุปเรื่องของ Stack การพัฒนาระบบมีอะไรบ้าง ?
หลัก ๆ เป็นดังนี้
แสดงดังรูป
เทคโนโลยีที่ใช้พัฒนา
แยกการพัฒนาเป็น service ย่อย ๆ
ต่อไปยัง external service จะทำงานแบบ Asynchronous ผ่าน Queue/Messaging
ปิดท้ายด้วย Lesson learn ของการพัฒนาระบบนี้ มีอะไรบ้าง ?
ดูย้อนหลังได้จาก
โดยใน Angular 9.1 นั้นเป็นการปรับปรุงและแก้ไขเป็นส่วนใหญ่
สิ่งที่น่าสนใจและที่กระทบกับที่ผมใช้งาน
ประกอบไปด้วย
ตัวที่ชอบมาก ๆ และใช้เลยคือ
ในการ run End-to-End test นั้น
สามารถใส่ option grep และ invertGrep ได้
เพื่อทำการเลือก test case ที่จะ run ได้ด้วย ชื่อในรูปแบบที่ต้องการ
แน่นอนว่าสนับสนุน Regular expression
ทำให้การทดสอบมีคงวามยืดหยุ่นมากยิ่งขึ้น
ยกตัวอย่างเช่น
จะ run test case ที่ไม่มีคำว่า welcome
Reference Website
วันนี้ทดลองสร้าง board สำหรับจัดการงาน หรือ Kanban board ใน VS Code
พบว่ามี extension ชื่อว่า CodDX
โดยเราสามารถสร้าง Kanban board ด้วยการเขียนในรูปแบบ Markdown อีกแล้ว
ซึ่งไฟล์ Markdown นั้นจะเขียนตามรูปแบบของ TODO.md
มาลองใช้งานกันดู
เริ่มด้วยการสร้างไฟล์ Markdown ในรูปแบบของ TODO.md
ซึ่งทำการสร้างได้เลย
แสดงผลของ Task board ดังนี้
ที่สำคัญสามารถเปลี่ยนสถานะ และลากย้าย task ไปมาในแต่ละสถานะได้เลย
สามารถสร้างไฟล์ Markdown เพิ่มได้นะ
เป็นอีกเครื่องมือที่น่าสนใจ ใช้กันเลยครับ
อ่านบทความจากการทำแบบสำรวจเมื่อปี 2018 (เก่าแล้ว แต่น่าจะมีโยชน์)
เป็นเรื่อง Developer Team Performance :: Why your team slows down and What to do about it
จากการสำรวจได้ข้อมูลที่น่าสนใจมากมาย
เนื่องจากมีสาเหตุมากมายที่ส่งผลให้ทีมช้าลง ทั้งจากภายนอกและภายใน
ล้วนนำไปสู่การส่งมอบงานที่ล่าช้าและไม่ตรงตามที่คาดหวัง
แน่นอนว่า มันเกิดขึ้นบ่อยมาก !!!
คำถามคือ เมื่อเรารู้ต้นเหตุแล้ว เราจะลงมือแก้ไขอย่างไรดี ?
ตรงนี้น่าจะเป็นประเด็นหลักมากกว่า
เริ่มจากอะไรบ้างที่ทำให้ทีมช้าลง ?
แยกออกมาตามตำแหน่ง
อีกเรื่องคือ Technology stack ที่ใช้งาน ก็เป็นปัญหาอีก
บางส่วนมีการทำงานแบบอัตโนมัตินะ
แต่ปัญหาคือ ทำงานช้า ได้รับ feeback ช้ามาก ๆ
จากผลการสำรวจ ไม่น่าแปลกใจอะไรเลย
เพราะว่าเป็นปัญหา classic ที่ไม่แก้ไขกันใช่ไหม ?
จากบทความบอกว่า จะทำอะไรหรือแก้ไขปัญหาใด ๆ ต้องใช้ข้อมูลเป็นหลัก
เพื่อจะได้รับรู้ปัญหาที่แท้จริง
ยกตัวอย่างเช่น
การพูดคุยกับทีมงาน ให้ทำการ tracking เวลาที่ใช้จริง ๆ
ในแต่ละวัน เป็นเวลา 2-3 สัปดาห์
มันอาจจะเป็นงานที่ยากหรือน่าเบื่อสำหรับทีม
แต่มันเป็นวิธีการที่ให้ได้ข้อมูลที่ง่ายและมาจากคนทำงานจริง
น่าจะเชื่อถือได้ดี
โดยแนะนำให้ใช้เครื่องมือง่าย ๆ
ยกตัวอย่างเช่น Excel หรือ Google Spreadsheet ไปเลย
กำหนดลงไปเลยว่า แต่ละวันทำงานอะไรบ้าง ใช้เวลาเท่าไร
ให้ลงทั้งเวลาการทำงาน และเวลารอจากคนอื่นด้วย
ข้อมูลอาจจะไม่ถูกต้อง 100% แต่ก็ทำให้เราเห็นปัญหาได้ดี
หรืออีกวิธีการคือ การพูดคุยแบบหนึ่งต่อหนึ่งกับแต่ละคนไปเลย
เพื่อสอบถามว่า อะไรคือต้นเหตุให้ทีมช้าลง
น่าจะทำให้เราเข้าใจปัญหาเชิงลึกมากขึ้น
แต่ก็ใช้เวลานานมากเช่นกัน
เมื่อได้ข้อมูลแล้ว ก็ไปดูว่าการทำงานของทีมเป็นอย่างไร ?
Product หรือ project ที่ทำนั้น มีเป้าหมายอย่างไร ?
ต้องใช้ Technology อะไรบ้าง ที่จะทำให้ไปถึงเป้าหมายที่ตั้งไว้ ?
ก่อนงานที่จะเข้ามานั้น มีการจัดการ prioritize หรือไม่ ?
(ไม่ใช่ด่วนและด่วนมากนะ หรือ จะเอาเดี๋ยวนี้)
อีกอย่างต้องดู capacity ของทีมด้วย ว่าตอนนี้เป็นอย่างไร ?
ถ้า capacity ของทีมเต็มแล้ว สิ่งที่จะเข้ามาต้องรอในคิวเสมอ !!
การพูดคุยก็เช่นกัน ต้องเป็นการพูดคุยที่มีประสิทธิภาพ
ไม่ใช่การมาตาม progress หรือ รายงาน progress งาน
แต่ต้องเป็นการพูดคุยแบบสองทาง
เปิดเผยการเปลี่ยนแปลงต่าง ๆ
เปิดเผยปัญหาต่าง ๆ ที่พบเจอ
เพื่อให้ทีมรับทราบ และช่วยกันแก้ไข
ต่อมาก็เรื่องของ feedback loop หรือการ review performance แบบเป็นระยะ
หรือเป็นช่วงระยะเวลาแบบต่อเนื่องเป็น feedback
แบบ 2 ทางคือ ทั้งให้และรับ
รวมถึงการพูดคุยแบบหนึ่งต่อหนึ่งมันช่วยทำให้เราเห็นผลการปรับปรุงที่ดีขึ้น
เรื่องของการประชุมก็เช่นกัน ควรมีการเพิ่มหรือลดให้เหมาะสม
ประชุมอะไรที่เข้าไปแล้วไปนั่งฟังเฉย ๆ ก็ไม่ควรเข้า
ประชุมอะไรที่ไม่มี objective และ agenda เลย ก็ควรยกเลิกไป
ประชุมควรมี objective และขอบเขตเวลาที่ชัดเจน
ทุกการประชุมต้องมี action plan เสมอ
รวมทั้งมีการกำหนดให้เลยว่า ใครต้องไปทำมาบ้าง
มิฉะนั้น มันจะเป็นการประชุมเพื่อประชุมครั้งต่อไป ซึ่งเปลืองมาก ๆ !!
The Golden Rule of meetings, says Cohen, is to “make sure you have a clearly defined purpose for each one."
เรื่องสุดท้ายคือ Technology ที่ใช้งาน
ในส่วนนี้ควรมีการ update เรื่องนี้กันบ่อย ๆ
ทั้งเรื่องความรู้ความเข้าใจ
ทั้งเรื่องสิ่งที่ใช้งานมีปัญหาหรือไม่ อย่างไร
ทั้งเรื่องสิ่งที่ใช้มัน out-of-date หรือยัง ควรทำงาน upgrade ไหม
ทั้งเรื่องควรเปลี่ยนไปใช้ technology ใหม่ ๆ หรือไม่
เพราะว่า มันอาจจะเป็นสิ่งที่ทำให้ช้าลง
หรือเป็น technical debt ก็ได้
หรือของใหม่ ๆ อาจจะก่อให้เกิดปัญหาก็ได้เช่นกัน
ดังนั้นการเลือกก็สำคัญ เช่น
สุดท้ายแล้ว เราควรต้องรู้และยอมรับก่อนว่า เรามีปัญหาอะไรบ้าง ?
ที่ทำเราให้ช้าลง จากนั้นแนะนำให้ค่อย ๆ แก้ทีละปัญหา
ดูผลการแก้ไข และ ปรับปรุงอย่างต่อเนื่อง
ทาง Facebook ได้ปล่อย Messenger app
สำหรับชาว Mac และ Windows มาให้ใช้
โดยจากทางข่าวบอกว่า จะเปิดตัวในงาน F8
แต่ว่าเกิด COVID-19 เลยต้องยกเลิกไป
เป็น Desktop application ให้ใช้งานกันเลย
แน่นอนว่า ใช้ได้ทั้งคุยผ่านตัวอักษร เสียงและ VDO เหมือนเดิม
แต่ทำให้การใช้งานง่ายขึ้น และมีความสามารถเหมือนผ่าน browser เลย
ความสามารถของ Messenger app นั้น
สามารถทำมาใช้ conference เหมือน Zoom, Meet ได้เลย
แต่ว่ายังมีข้อจำกัดเยอะกว่ามาก
ทั้งใน 1 กลุ่ม vdo call มีสมาชิกได้เพียง 8 คน
ทั้งไม่สามารถ share screen ได้ หรือ share link ให้คนอื่น ๆ เขามาร่วมกลุ่ม ก็ไม่มี
เนื่องจากเป้าหมายที่แตกต่างกันมากกว่า
แต่ถ้าอยากใช้งาน ต้องไปใช้ Facebook workplace แทน
คิดว่าใน Messenger น่าจะมีการเพิ่มความสามารถนี้เข้ามาเร็ว ๆ นี้มั้ง
ลองใช้งานกันดูให้
เปิดให้ download กันแล้ว
มาใช้งานบนจอที่ใหญ่ขึ้น กัน
เห็น VDO ใน YouTube ของคุณ Kent Beck
เรื่อง Understanding Legacy Code with TCR (test && commit || revert)
แต่สิ่งที่สนใจคือ แนวคิดและแนวปฏิบัติที่ใช้งาน
คือ TCR (Test && Commit || Revert) มันคืออะไรนะ และทำอย่างไร ?
แนวคิด TCR (Test && Commit || Revert) คืออะไร
ตามไปอ่าน blog เรื่อง Test && Commit || Revert
แนวคิดตามชื่อเลย ตรงๆ นั่นคือ
เมื่อนักพัฒนาทำการแก้ไข code
จากนั้นทำการ run ชุดการทดสอบทั้งหมด
ถ้าผลการทดสอบผ่านแล้ว จะทำการ commit ให้เลย ($git commit -am)
แต่ถ้าไม่ผ่าน จะทำการลบการเปลี่ยนที่ทำทั้งหมดทิ้งไป ($git reset --hard)
นั่นหมายความว่า
ให้นักพัฒนาค่อย ๆ เขียน code เป็นเรื่อง ๆ
นั่นคือการพัฒนาแบบ incremental และมีคุณภาพ
สิ่งที่เปลี่ยนแปลงไปต้องไม่กระทบต่อระบบงานโดยรวม
โดยถ้าใช้งานจริง ๆ ก็เพียงเขียน command line เลย
ถ้าใช้ Text Editor หรือ IDE ก็ให้ตรวจสอบการเปลี่ยนแปลงเลย
เช่น ถ้าทำการบันทึกแล้ว ทำการ run คำสั่งนี้เลย (Run on Change)
น่าสนใจมาก ๆ มาลองกันดีกว่า
เพิ่มเติม
ปัญหาที่เจอบ่อยมาก ๆ สำหรับการทดสอบแบบ End-to-End
ยิ่งทดสอบผ่าน User Interface หรือ ระบบที่ต้องทำงานผ่านระบบ network
คือ ทดสอบผ่านบ้าง ไม่ผ่านบ้าง โดยที่ code ไม่เปลี่ยนแปลงใด ๆ เลย !!
ปัญหานี้จะถูกเรียกว่า Flakiness testing
ปัญหานี้จะรบกวนจิตใจของทีมทดสอบและพัฒนาอย่างมาก
บ่อยครั้งการแก้ไขปัญหาจะเป็นการแก้ที่ปลายเหตุทั้งนั้น
โดยไม่แก้ไขที่ต้นเหตุเลย
ยกตัวอย่างเช่น
ให้การทดสอบรอนาน ๆ ด้วย keyword พวก Waiting, Timeout หรือ Delay
ผลที่ตามมาคือ การทดสอบช้ามาก ๆ
ส่งผลให้กระบวนการทำงานช้าเพิ่มเข้าไปอีก
ถึงแม้ว่าจะมีชุดการทดสอบอัตโนมัติ และมีระบบ Continuous Integration ก็ตาม
ยิ่งปัญหานี้เกิดขึ้นบ่อย ๆ
สิ่งที่อาจจะทำต่อไปคือ Ignore test เหล่านั้น
หรือหนักสุดคือ ลบชุดการทดสอบทิ้งไปเลย !!
ทำให้ความน่าเชื่อและความไว้เนื้อเชื่อใจลดลงไปอย่างมาก
แสดงดังรูป
ค่าใช้จ่ายของ Flakiness test เยอะมาก ๆ
เนื่องจากประกอบไปด้วย
ต้นเหตุของ Flakiness test มาจากอะไรบ้าง
ดังนั้นสิ่งที่เราควรต้องทำคือ
ลดจำนวนของ Flakiness test ลง
แน่นอนว่า ต้องมีการ monitoring การทดสอบด้วยเสมอ
ว่ามีปัญหาตรงไหนบ้าง ตรงนี้สำคัญมาก ๆ
ถ้าปลายทางมีปัญหา ก็ต้องแก้ไขที่ปลายทาง มิใช่แก้ไขที่ต้นทาง !!
จากนั้นต้องทำการแก้ไขอย่างรวดเร็ว
ส่วนระบบต่าง ๆ จำเป็นต้องทำให้มันเสถียรและน่าเชื่อถือ
หนึ่งในการแก้ไขคือ ลดการใช้งาน Waiting หรือ ให้รอนาน ๆ
พบว่า ถ้าเราใส่เวลาให้รอไป 5 วินาทีแล้วยังไม่พอ
สิ่งที่แก้ไขคือ เพิ่มเวลาไปให้นานกว่าเดิมอีก ไม่น่ามีใครทำ ใช่ไหม ?
ยกตัวอย่างการทดสอบระบบงานด้วย Cypress
ผมจะเจอ code การทดสอบแบบนี้บ่อยมาก ๆ
[gist id="653262fd4b8932eb2d667a1faba6b19e" file="1.js"]คำอธิบาย
ในขั้นตอนการค้นหานั้น ต้องไปดึงข้อมูลจาก RESTful API มา
ซึ่งปัญหาอยู่ตรงนี้ เดี๋ยวช้าเดี๋ยวเร็ว
ส่งผลให้ผลการทดสอบผ่านบ้าง ไม่ผ่านบ้าง
ดังนั้นเราจึงแก้ไขด้วยการใส่ wait(5000)
คือให้รอไป 5 วินาที ไม่ว่าจะทำงานเร็วก็ไม่สนใจ
ใน Cypress จะมีการจัดการ Assertion ของ Network request ให้เลย
ซึ่งจะรอไปจนกว่า จะเรียก RESTFul API และได้ response เรียบร้อย ดังนี้
[gist id="653262fd4b8932eb2d667a1faba6b19e" file="2.js"]เป็นอีกแนวทางหนึ่งที่น่าสนใจ สำหรับการแก้ไข Flakiness testing
เนื่องจากช่วงนี้แถวที่พักมีเสียงรบกวนจากรถและการก่อสร้าง
บางครั้งเปิดพัดลมหรือแอร์ก็มีเสียงรบกวนเข้ามา
ในขณะที่กำลังพูดคุยหรือประชุมผ่าน VDO Call ต่าง ๆ
ดังนั้นจึงอยากจะลดเสียงรบกวนพวกนี้ลงไป
จึงลองหาวิธีการแก้ไขปัญหาว่ามีอะไรบ้าง ?
แบบแรกที่เจอคือ ซื้อไมโครโฟนเลย เอาที่มันเก็บเสียงใกล้ ๆ เท่านั้น
ส่วนพวกเสียงรอบข้างไม่เก็บ แต่ไปดูราคาแล้วแพงจริงจัง
ต่อมาไปดูว่ามีโปรแกรมช่วยไหม
พบว่าพวก OBS ที่ใช้ในการ Live หรือบันทึก VDO
สามารถใส่ filter เรื่องการลด noise หรือเสียงรบกวนได้
แต่ก็ลำบากน่าดู เพราะว่า จะคุยกันที ต้องเปิดโปรแกรม OBS ขึ้นมา
แล้วทำการสร้าง Virtual camera เพื่อไปคุยกับโปรแกรมอื่น ๆ เช่น Zoom เป็นต้น
ก็เลยไปหาดูโปรแกรมอื่น ๆ ดู ก็เจอ Krisp
เป็นโปรแกรมช่วยลดเสียงรบกวนที่ไม่ใช่เสียงพูด
ใช้ได้ทั้ง sound, speaker กันเลย
จากการลองใช้งานพบว่า ใช้งานง่าย ลดได้จริง
มีให้ลองใช้ฟรี 120 นาทีต่อสัปดาห์
ก็เลยคิดว่าน่าจะเหมาะกับตัวผมเลย
ก็กดซื้อมาซะในราคา 3.3 USD ต่อเดือน
ใครสนใจลองดูนะครับ สำหรับผมชีวิตดีขึ้นเยอะเลย
อ่านบทความเรื่อง Evolution of Finding Views by ID in Android
ทำให้เราเห็นวิวัฒนาการของ Find View by ID ในการพัฒนา Android app
มีความเป็นมาที่ยาวนานและน่าสนใจจริง ๆ
จึงเขียนสรุปสิ่งที่ได้จากบทความนี้ไว้หน่อย
ถ้าไม่มี ID ใน view ของ Android app ก็ยากที่จะทดสอบแบบอัตโนมัติอย่างมาก
ในการพัฒนา Android app นั้น
นักพัฒนาทุกคนจะทำการเข้าถึง element ต่าง ๆ ในไฟล์ XML Layout
จะต้องใช้งานผ่าน method findViewById() อย่างแน่นอน
มันดูง่ายมาก ๆ นะ
แต่เมื่อเรามี element จำนวนมาก แน่นอนว่า App ต้องมี element ต่าง ๆ เยอะสิ
มันจึงทำให้สิ่งที่ดูเหมือนง่าย กลับกลายเป็นสิ่งที่รบกวนจิตใจอย่างมาก
กลายเป็น code ขยะหรือไร้ความจำเป็นอย่างมาก แต่ก็ต้องเขียน !!
ในบทความอธิบายว่า
นี่คือหนึ่งในความผิดพลาดที่แพงมาก ๆ ที่เกิดจากผู้สร้างมันขึ้นมา
แต่เมื่อวันเวลาผ่านไป ทีมผู้สร้างก็เข้าใจว่า
สิ่งที่สร้างมามันผิดพลาดจริง ๆ
ดังนั้นเราจึงเห็นวิวัฒนาการต่าง ๆ
เริ่มต้นด้วย 3-party library เข้ามาลด code ก่อนเลย
ประกอบไปด้วย
แต่เมื่อการมาถึงของภาษา Kotlin
ได้กลายมาเป็น First-class language สำหรับการพัฒนา Android app
มาพร้อมกับ Kotlin Extension method เลย
ทำ auto-generated ให้เลย
นักพัฒนาเรียกใช้งานตาม ID ที่กำหนดในไฟล์ Layout XML ได้เลย สะดวกมาก ๆ
แต่ใช้ได้เฉพาะภาษา Kotlin เท่านั้น
ส่วนภาษา Java นั้นไม่สามารถใช้ได้
แต่ว่า method findById() ไม่ต้องทำการ cast type
ทำให้ไม่เกิดปัญหา ClassCastException อีกต่อไป
แต่ก็ยังต้องใช้งาน method findById() อยู่นะ !!
ตามจริงก่อนหน้านี้จะมีความสามารถที่ไม่ค่อยเป็นที่นิยมมากนัก
แต่มาจาก Android เลยก็คือ Data binding library
ทำให้ทำการ binding element ต่าง ๆ ในไฟล์ Layout XML เข้ากับ Data sources ได้
ซึ่งทำได้ในไฟล์ Layout XML นั่นเอง
จากนั้น Android Studio จะทำการ generate class จากไฟล์ Layout XML ให้อัตโนมัติ
เช่น activity_main.xml จะ generate class ActivityMainBinding มาให้
ใช้งานได้ทั้ง Java และ Kotlin
แน่นอนว่าปัญหา ClassCastException และ NullPointerException หายไป
แต่ก็เพิ่มเวลาในการ build มากขึ้นไปด้วย !!
ตัวล่าสุดคือ View Binding มาพร้อมกับ Android Studio 3.6 ขึ้นมา
เป็นความสามารถหนึ่งใน Data Binding นั่นเอง
แต่ถูกแยกออกมาเพื่อทำงานกับส่วนของ View เท่านั้น
เพื่อปรับปรุงประสิทธิภาพของการทำงานให้ดีขึ้นนั่นเอง
นั่นคือไม่ส่งผลกระทบต่อเวลาในการ build
ซึ่งจะไม่มี annotation ใด ๆ หรือทำการเขียนอะไรเพิ่มในไฟล์ Layout XML เลย
และทำงานแบบ one-way binding เท่านั้น
ไม่ใช่ 2-way binding เหมือนกับ Data Binding
แต่ default แล้ว View Binding ไม่ได้เปิดให้ใช้งาน
เราต้องไปเปิดความสามารถนี้ในไฟล์ /app/build.gradle
ใช้งานได้ทั้ง Java และ Kotlin
จากบทความนั้นอธิบายว่า ถ้าให้ตัดสินใจใช้งานจะใช้อะไรดี ?
คำตอบคือ View Binding เป็นทางเลือกที่ดีที่สุดในตอนนี้
แต่อาจจะไม่เหมาะสมกับคุณก็ได้นะ !!!
ว่าง ๆ ทำการสรุปผลการทำ Performance testing จาก JMeter
ไปแสดงแบบสวยๆ ใน Grafana นิดหน่อย
แน่นอนว่า มีคนใจดีทำ dashboard ส่วน ๆ ใน Grafana ไว้ให้แล้ว
ดังนั้นบันทึกขั้นตอนไว้นิดหน่อย
มาเริ่มกันเลย
ขั้นตอนที่ 1 ทำการสร้าง Test plan ใน JMeter
โดยทำการเพิ่ม Listenter ชื่อว่า Backend Listener เข้ามา
จากนั้นทำการเลือก Backend Listener implementation เป็น visualizers.backend.Influxdb
หรือเราสามารถเลือกใช้ตัวอื่นได้ เช่น Graphite และ Elasticsearch
แต่สิ่งที่ผมใช้คือ InfluxDB
โดยที่ InfluxDB คือ Time series database
สำหรับเก็บข้อมูลผลการทดสอบจาก JMeter
เราสามารถกำหนด InfluxdbUrl ได้เลย ว่า
InfluxDB server อยู่ที่ไหน และ database ชื่ออะไร
จากตัวอย่าง
ผมใช้ localhost และ database ชื่อว่า JMeter ไปเลย ตามค่า default
ขั้นตอนที่ 2 ก่อนที่จะทำการทดสอบ ต้องไปสร้าง database ชื่อ JMeter ใน InfluxDB ก่อน
ห้ามลืมเด็ดขาด !!!
ขั้นตอนที่ 3 ทำการแสดงผลการทดสอบที่เก็บใน InfluxDB แบบสวย ๆ ด้วย Grafana
โดยเราสามารถใช้ Dashboard #5496 ได้เลย
และอย่าลืมเพิ่ม Datasource ให้มาดึงข้อมูลที่ InfluxDB ด้วย
ขั้นตอนที่ 4 ทำการทดสอบผ่าน JMeter เลย
ผลการทดสอบใน Grafana แบบสวย ๆ เป็นดังนี้
เท่านี้ก็ใช้งานได้แล้วครับ ง่ายมาก ๆ
ลองนำไปใช้งานดู
ทาง Apple และ Google ร่วมมือกันสร้าง COVID-19 contact tracing technology
เป็นอีกวิธีการหนึ่งเพื่อช่วยให้สังคมกลับคืนมาและอยู่ด้วยกันได้ดีขึ้น
จากการระบาดของไวรัส COVID-19 ทั่วทั้งโลก
สามารถอ่าน Specification ของ project นี้ได้
แยกออกเป็น 3 เรื่องใหญ่ ๆ คือ
การออกแบบจะอยู่บนพื้นฐานของ user privacy และ ความปลอดภัยเป็นหลัก
แน่นอนว่าต้องสามารถใช้งานได้ทั้ง Android และ iOS
ทาง Google เขียนสรุปไว้คร่าว ๆ ดังนี้
มีขั้นตอนการทำงานดังนี้
ขั้นตอนที่ 1 แลกเปลี่ยนข้อมูลด้วย Anonymous identify ผ่าน bluetooth
ขั้นตอนที่ 2 เมื่อเราไปตรวจแล้วพบว่า ผลเป็นบวก จะบันทึกผลลงระบบ
ขั้นตอนที่ 3 มือถือคนอื่น ๆ ก็จะทำการ download ข้อมูลของคนใน region ที่มีผลตรวจเป็นบวกมาที่เครื่อง
จากนั้นจะตรวจสอบให้มาตรงกับ key หรือ Identifier ที่แลกมาจากขั้นตอนที่ 1 หรือไม่
ขั้นตอนที่ 4 ถ้าผลว่าตรงกัน หรือ เคยไปเจอหรือใกล้ชิดกัน จะมี notification มาแจ้ง
เพื่อบอกว่าจะต้องทำอะไร อย่างไรต่อไปนั่นเอง
โดยแผนของการพัฒนาของโครงการเป็นดังนี้
เป็นอีกหนึ่งแนวทางจาก Technology company ที่ร่วมมือกันเพื่อแก้ไขปัญหาที่เกิดขึ้น
Reference Websites
เพิ่งไปแบ่งปันเรื่อง Performance testing ด้วย JMeter มานิดหน่อย
สิ่งหนึ่งที่ยังไม่ได้แนะนำไป คือ Distributed performance testing
เพื่อทำการขยายเครื่องที่สร้าง workload หรือ จำนวนผู้ใช้งาน
เพื่อส่งไปยังระบบที่ต้องการทดสอบ
จึงทำการเขียนสรุปไว้นิดหน่อย
เครื่องมือที่ใช้งานประกอบไปด้วย
โดยสิ่งที่จะทำคือ Distributed Testing ด้วย JMeter
และทำการขยายเครื่องสร้าง workload หรือเครื่อง worker/slave ด้วย Docker Swarm
แสดงโครงสร้างการทำงานดังนี้
จากรูปนั้น สิ่งที่เราจะสร้างขึ้นมาคือ JMeter server หรือ worker จำนวน 4 เครื่องขึ้นมา
เครื่องมือที่ใช้จัดการคือ Docker Swarm
(ส่วน Kubernetes ก็ทำได้ง่าย ๆ แต่จะซับซ้อนขึ้นมาหน่อย ไว้อธิบายแยกไปอีก blog)
มาเริ่มสร้างกันเลย
ขั้นตอนที่ 1 สร้าง Docker Image ของ JMeter กันก่อน
โดยใช้ base image ของ OpenJDK 11 (JRE)
และทำการ download JMeter 5.2.1 มาใช้งาน ดังนี้
จากนั้นทำการสร้าง Docker image ตามที่กำหนด
โดยผมสร้างชื่อว่า somkiat/jmeter
ขั้นตอนที่ 2 ทำการ deploy JMeter Slave จำนวน 4 เครื่องด้วย Docker Swarm
สามารถจัดการด้วย docker-compose.yml นี่แหละ
จากนั้นทำการ deploy ด้วย Docker Swarm ดังนี้
จากนั้นทำการดู IP ของแต่ละ container ว่าเป็นอะไร
เพื่อเอามาใช้งานในขั้นตอนที่ 3
ขั้นตอนที่ 3 สร้าง JMeter Master สำหรับควบคุม worker ทั้ง 2 เครื่อง
นั่นคือการสร้าง JMeter container ขึ้นมา
จากนั้นสั่งการให้ทั้ง 2 เครื่องสร้าง workload
เพื่อส่งไปยังระบบที่ต้องการทดสอบ
โดยทำการสร้าง container จาก image ที่สร้างจากขั้นตอนที่ 1 นั่นเอง
เพียงเท่านี้ก็สามารถขยายชุดการทำ Performance testing แบบง่าย ๆ ได้แล้ว
แน่นอนว่ายังมีเครื่องมือตัวอื่น ๆ อีก
ไว้จะมาเขียนอธิบายต่อไป
