ทางทีมพัฒนา Robot Framework เพิ่งปล่อง version 3.2 RC 1 ออกมา
สิ่งที่น่าสนใจคือ Backwards incompatible
เนื่องจากส่งผลกระทบต่อการใช้งาน
จึงทำการสรุปไว้นิดหน่อย

เรื่องที่ 1 ไม่สนับสนุนการเขียน script ในรูปแบบ HTML และ TSV

เนื่องจากมีการเปลี่ยนแปลง test data parser
ซึ่งสนับสนุนเฉพาะรูปแบบ plain text เท่านั้น
แต่ถ้าใครเขียนในรูปแบบ TSV แล้ว compatibility กับ plain text ก็ยังสามารถใช้ได้อยู่

เรื่องที่ 2 นามสกุลไฟล์ สนับสนุน *.robot โดย default

ส่วนนามสกุลไฟล์อื่น ๆ เช่น *.txt, *.tsv หรือ *.rst
สามารถใช้ได้แต่ต้องเพิ่ม parameter --extension ในการ run คำสั่ง $robot

เรื่องที่ 3 การเขียน FOR loop ถ้าใครใช้งานรูปแบบเดิม จะ deprecated ใน version 3.3

เรื่องที่ 4 การใช้งาน variable ในชื่อ Test case  เปลี่ยนแปลง

เรื่องที่ 5 ชื่อต่าง ๆ แต่ละ section จะเข้มงวดมากขึ้น

นั่นคือทุก ๆ  space มีความหมายมากยิ่งขึ้น (ปกติก็มากอยู่แล้ว)
ช่วยให้การพัฒนาตัว test data parser ง่ายขึ้นนั่นเอง
ยกตัวอย่างที่ไม่สนับสนุนคือ TestCase, TestSetup

มีคำถามในทีมว่า
อยากนำ output จาก OBS(Open Broadcaster Software) ไปแสดงผลใน Zoom
จะต้องทำอย่างไรบ้าง ?
ใน MacOS ด้วยนะ !!

วิธีการง่าย ๆ คือ

ใน OBS community จะมี plugin ชื่อว่า Virtual Camera
แต่โชคไม่ดี ใช้ได้เฉพาะบน Windows OS เท่านั้น
จึงลองไปดูเพิ่มเติม
ก็พบว่ามีคนทำ Virtual Camera for Mac มาให้ใช้ด้วย
แต่ต้องทำการ build ทั้ง plugin และ OBS ใหม่ดังนี้

จากนั้นทำการ Start Virtual Camera ใน OBS ดังนี้

ไปที่ Zoom เลือก Video output เป็น OBS Virtual Camera ที่มาจาก OBS ได้เลย

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

อีกตัวที่ลองใช้งานคือ NDI

คำถาม
ถ้าต้องการทำ auto reload ของระบบ
ที่พัฒนาด้วย Flask framework ต้องทำอย่างไร ?

ยกตัวอย่างเช่น
เมื่อเปลี่ยนแปลง source code ที่เขียนด้วยภาษา Python แล้ว
ต้องการให้ทำการ auto reload ใหม่เอง
โดยที่ไม่ต้อง run ใหม่
ที่สำคัญใช้งานกับ Docker compose ด้วย ต้องทำอย่างไร ?

คำตอบ
เรื่องนี้ไม่ยาก เนื่องจาก Flask ใน debug mode นั้น
จะสนับสนุน auto reload อยู่แล้ว
โดยสามารถกำหนด Flask ให้ run ใน debug mode 
ด้วยการกำหนดค่า environment variable ชื่อว่า FLASK_DEBUG=on
เพียงเท่านี้ก็ได้แล้ว

เมื่อมาใช้งานร่วมกับ Docker compose
ก็เขียนไฟล์ docker-compose.yml ดังนี้

เพียงเท่านี้ก็สามารถใช้งานได้ตามที่ต้องการแล้ว
โดยที่ code ตังอย่างทั้งหมดอยู่ที่  Github::Up1

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

ทาง CEO ของ Zoom คือคุณ Eric Yuan ทำการประกาศออกมาหลายเรื่อง

ยกตัวอย่างการให้สัมภาษณ์ในบทความ
Our First ‘Ask Eric Anything’ Webinar Addresses Users’ Security & Privacy Concerns
รวมไปถึงการออก patch บางเรื่องออกมาแล้ว
เช่นการปิดพวก file sharing ต่าง ๆ 
การใส่ password ในแต่ละการประชุม
และจะแก้ไขปัญหาที่เกิดขึ้นภายใน 90 วัน !!

ตลอดจนมีการสรุปเรื่อง การใช้ Zoom ให้ปลอดภัยออกมา

• Beyond the noise — 7 reasons it’s safe to run Zoom
• How to Protect Your Virtual Meetings from Zoombombing

ผมทำการสรุปเรื่องที่น่าสนใจในการใช้อย่างปลอดภัยจากบทความต่าง ๆ  มาไว้ดังนี้

การจัดการผู้เข้าร่วมประชุม

ถ้าการประชุมมีจำนวนผู้เข้าร่วมไม่เยอะ
แนะนำให้ทุกคน login เพื่อเข้าประชุม

แต่ถ้ามีผู้เข้าร่วมประชุมจำนวนมาก 
ให้ผู้ที่จะเข้าประชุมมารอได้ก่อน (Waiting room)
เพิ่มป้องกันคนที่เราไม่ต้องการให้เข้า
มาอยู่ตรงนี้ก่อน จากนั้นเราค่อยจัดการอีกที
ซึ่งลดปัญหา  Zoomboming ไปได้

หรือกำหนดให้ผู้เข้าประชุม เข้ามาดูอย่างเดียว
ทำอะไรไม่ได้ (Participant management)
เพื่อลดเสียงรบกวนต่าง ๆลงไป
หรือทำการ remove ผู้เข้าร่วมบางคนออกไปได้

ทำการ Lock การประชุม (Lock meeting)

นั่นหมายความว่า จะไม่มีใครสามารถเข้าร่วมประชุมได้อีกแล้ว

กำหนด password สำหรับการเข้าร่วมประชุม

เป็นอีกแนวทางที่ลดปัญหาด้านนี้ไป

แต่ทั้ง 3 เรื่องอาจจะไม่ลดปัญหาลงไปทั้งหมด
แต่ก็น่าจะดีกว่าไม่ทำอะไรเลย

Zoom ก็ยังมีคนใช้งานอยู่
เหตุผลคืออะไร ?
ใช้ง่าย ?
ความสามารถมีพร้อมตามที่ต้องใช้งาน ?

หรืออีกวิธีคือ การย้ายไปใช้เครื่องมืออื่น ๆ

จากบทความ Helping our developers stay productive while working remotely ของ Microsoft
เป็นคำแนะนำสำหรับการจัดการ productivity ของ Developer
ที่ต้องทำงานในรูปแบบ Remote กันมากขึ้น หรือ Work From Home
โดยให้คำแนะนำกว้างไปถึงทั้งองค์กร

ซึ่งมีหัวข้อต่าง ๆ ดังนี้

• User identity และ การเข้าใช้งาน environment ต่าง ๆ
• Multi-factor authentication (MFA)
• การจัดการ device ต่าง ๆ ทั้ง PC/Notebook/Mobile รวมไปถึง OS ต่าง ๆ เช่น Windows, Mac, Linux, iOS และ Android รวมไปถึงการสนับสนุน BYOD (Bring Your Own Device)
• Productivity application คือเครื่องมือที่ใช้งานต้องช่วยเพิ่ม productivity ไม่ใช่เป็นคอขวด
• การจัดการเรื่องช่องทางการทำงานร่วมกัน การพุดคุยและการประชุมต่าง ๆ 
• Application และ Service monitoring เนื่องจากมีคนใช้งานแบบ remote จำนวนมาก เรื่องนี้จึงสำคัญมาก ๆ ถ้ามีปัญหาขึ้นมาจะส่งผลกระทบหนักมาก ๆ
• สิ่งที่สำคัญสุด ๆ คือ เรื่องของ culture และ change management

ข้อมูลเกี่ยวกับ Developer productivity ที่ทาง Microsoft เปิดเผยออกมา

คือ การ monitor ดูว่าทีมพัฒนา
ทำการส่งการเปลี่ยนแปลงต่าง ๆ มายังระบบกลาง (commit, pull request)
พบว่ามีจำนวนที่สูงกว่าปี 2019 ดังรูป

ส่วนช่วงเวลาการทำงาน พบว่า

ทีมพัฒนาเริ่มงานเร็วกว่าปกติ และ เลิกงานช้ากว่าปกติ
ส่วนช่วง low peak อยู่ช่วงเที่ยงวัน แสดงดังรูป

ข้อมูลนี้อาจจะแตกต่างกันไปตามแต่ละองค์กร

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

• ช่องทางการพูดคุยกัน และ เวลาการพูดคุยที่ชัดเจน
• มีการทำ Virtual lunch และ coffee break ร่วมกัน
• พักการทำงาน ออกไปเดินเล่น ยืดเส้นยืดสาย หรือโทรคุยกันภายในทีมและระหว่างทีม
• มีการ conference call สำหรับทำกิจกรรมอื่น ๆ ที่ไม่ใช่งาน เพื่อการผ่อนคลาย เช่น เกมส์ หรือ กิจกรรมร่วมกัน เป็นต้น
• มีการ update กับในทุก ๆ วัน ไม่ใช่ทุก ๆ ชั่วโมงนะ

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

สิ่งสุดท้ายที่สำคัญคือ การดูแลสุขภาพของตัวเราเอง

แต่ก็อย่าลืมว่า การทำงานแบบ remote นั้น

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

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

การให้ requirement หรือ specification ที่ไม่ชัดเจน
ก็อาจก่อให้เกิดปัญหาหนัก
หรือเราเริ่มทำกันเมื่อยังไม่ชัด
หรือทำไปแก้ไขไป
หรือเปลี่ยนไปเปลี่ยนมา
แบบนี้ไม่น่าจะดีเลยนะ

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

• CI/CD คือ Actions (2,000 นาทีต่อเดือน)
• Project management
• Code review
• Package

ปล. และหวังว่า GitHub จะไม่มีปัญหามากขึ้นนะ

ดู Price plan แบบฟรีได้

มาสร้างทีมกันเลย

ส่วนใครใช้แบบเสียเงิน ก็ลดราคาลงอีกด้วย
มาใช้งานกันครับ

มีคำถามเกี่ยวกับการทดสอบ performance ของ MQTT messaging
ซึ่งส่วนใหญ่จะใช้ทำงานร่วมกับพวกอุปกรณ์ IoT ต่าง ๆ 
ว่าต้องทำอย่างไรได้บ้าง ?

ก่อนอื่นต้องเข้าใจก่อนว่า MQTT protocol คืออะไร ?

MQTT ย่อมาจาก Message Queue Telemetry Transport
มันเกิดมาสำหรับโลกของ IoT
มีขนาดของ message ที่เล็ก ตัวมันเองก็เช่นกัน
แน่นอนว่า เป็น open protocol
ความสามารถหลัก ๆ ประกอบไปด้วย

• เป็น Application level protocol ซึ่งทำงานบน TCP/IP ด้วย port 1883 (default port) หรือ SSL ใช้ port 8883
• เป็น Asynchronous protocol 
• มีรูปแบบการทำงานแบบ publisher/subscriber
• ขนาดของ message มีขนาดเล็ก ซึ่งประกอบไปด้วย 3 ส่วนคือ fixed header, ข้อมูล header และ body
• สามารถทำงานได้บน network ที่ไม่เสถียร

คำตอบคือ ทำได้หลายวิธี หนึ่งในนั้นคือ การทดสอบด้วย JMeter

แต่ต้องติดตั้ง plugin เพิ่มเติมชื่อว่า MQTT JMeter Plugin
โดยทำการ copy ไฟล์ mqtt-xmeter-1.0.1-jar-with-dependencies.jar
ไปไว้ที่ %JMETER_HOME%/lib/ext
จากนั้นทำการ start JMeter ขึ้นมา

MQTT จะอยู่ใน Sampler ของ JMeter 

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

• MQTT connect สำหรับการเชื่อมต่อไปยัง MQTT server
• MQTT Pub/Sub Sampler สำหรับการ subscribe และ publish ไปยัง topic ใน MQTT server

แสดงดังรูป

การใช้งานนั้น ก็ตามที่เราต้องการเลยว่า จะทดสอบอะไร

ถ้าเป็นเรื่องของ connection ก็ใช้งาน MQTT Connect ได้เลย
โดยสามารถกำหนดค่า parameter ต่าง ๆ ได้ 
เพื่อดูผลการทำงานว่า มี idle client เท่าไร มี waiting เท่าไร

หรือจะทดสอบการ publish ข้อมูลไปยัง topic ก็ได้

จากนั้นดูผลการทำงานด้วยการเพิ่ม Listerner เช่น view Result Tree มาดูก็ได้ดังนี้

น่าจะเป็นอีกแนวทางหนึ่งในการทดสอบ
ขอให้สนุกกับการทดสอบ performance  ครับ

มีคำถามที่น่าสนใจจากกลุ่ม Thai Elastic User Group ว่า
ค้นหาข้อมูลภาษาไทยที่จัดเก็บใน Elasticsearch แล้ว
ผลของการค้นหาไม่ถูกต้องตามที่คาดหวัง
โดยที่ข้อมูลที่จัดเก็บประกอบไปด้วย ภาษาไทยและตัวเลข
ยกตัวอย่างเช่น กส1234

การค้นหาใช้งานผ่าน Match query

แล้วได้ผลไม่เป็นไปตามที่ต้องการ
นั่นคือ ค้นหาค่าอะไร ต้องคือ document นั้น ๆ เลยสิ
แสดงดังตัวอย่าง

คำถามคือ ปัญหานี้เกิดจากอะไร แก้ไขปัญหาได้อย่างไรได้บ้าง ?

เพื่อให้ค้นหาข้อมูลได้ตามที่ต้องการ

วิธีการแรก ทำความเข้าใจกับ Match query ก่อน

โดยที่ Match query นั้นมันมีขั้นตอนการทำงานดังนี้

1. ทำการ analyze ข้อมูลก่อน เพื่อให้ได้คำหรือ term เพื่อนำไปค้นหา
2. ทำการค้นหาจาก term ต่าง ๆ ที่ได้จากข้อ 1 
3. นำผลการค้นหาแต่ละ term มารวมกัน โดยค่า default คือการ union
4. ส่งผลการค้นหากลับออกมา

โดยที่การ Analyze นั้น ค่า default จะเรียกว่า default analyzer 
ซึ่งเราทำการทดสอบได้ดังนี้

จะเห็นได้ว่าจะมี 2 คำ หรือ 2 term นั่นเป็นที่มาของผลการค้นหาที่ออกมา !!
ถ้าเราเข้าใจว่า Elasticsearch ทำงานอย่างไร

จากปัญหาดังกว่า ถ้าเราไม่แก้ไขอะไรเลย

สิ่งที่ต้องทำคือ การปรับเปลี่ยน Query นั่นเอง
โดยถ้ายังใช้งาน Match query แล้ว
สามารถเปลี่ยนการรวมผลการค้นหาจากแต่ละ term
จาก union เป็น intersection (OR -> AND) ดังนี้

หรือถ้าผมไม่อยากใช้ Analyzer ละ ได้ไหม ?

เนื่องจากการ analyze ไม่เป็นไปตามที่ต้องการ
แน่นอนว่า ทำได้ด้วยการกำหนด mapping ของ document ให้ไม่ทำการ analyze
จากนั้นทำการเพิ่มข้อมูล และค้นหาด้วย Match query ปกติ 
ใช้ค้นหาได้ข้อมูลตามปกติ

ลองทำความเข้าใจดูครับ

สำหรับใครที่ใช้โปรแกรม Discord สำหรับการพูดคุย หรือ ประชุมต่าง ๆ ในช่วงนี้นั้น
ตอนนี้ทาง Discord ร่วมกับ Krisp เปิดให้ใช้งานใน beta version แบบฟรี ๆ แล้ว
โดยที่ Krisp คือโปรแกรมที่ช่วยตัดเสียงรอบกวนทั้ง input และ output

โดยเข้าไปเปิดใช้งาน feature นี้ได้ที่ Discord ดังนี้

ไปที่เมนู App Settings -> Voice and Video -> Advanced -> Noise Suppression beta ดังรูป

ช่วยทำให้การใช้ Discord มีประสิทธิภาพทางเสียงมากยิ่งขึ้น

ช่วงสัปดาห์นี้ตั้งแต่วันที่ 13-19 เมษายน ทาง Vue Mastery
เปิดให้เรียนฟรีใน course ที่เกี่ยวกับการพัฒนาระบบด้วย Vue.js ทั้งหมด
โดยที่ course แรกที่ผมลงเรียนคือ Unit testing
ประกอบไปด้วยหัวข้อดังต่อไปนี้

• What to test และ What not to test
• การเขียน Unit test ด้วย Jest และ Vue test utils
• การทดสอบการส่งข้อมูลผ่าน props และ user interaction เช่นการ click และ กรอกข้อมูลต่าง ๆ
• การทดสอบสำหรับการ submit form
• การทดสอบส่วนที่ติดต่อกับ API ต่าง ๆ

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

ใน course เริ่มจากการอธิบายว่า ทำไมจึงต้องเขียน test ด้วย

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

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

จากนั้นอธิบายว่า อะไรบ้างที่ควรไม่ควรทดสอบของระบบที่พัฒนาด้วย Vue.js

สามารถอธิบายได้ด้วยภาพนี้

• ควรทำสอบพวก props ต่าง ๆ ที่ส่งเข้ามา ว่าได้ output อย่างไร ตามที่คาดหวังหรือไม่
• ทำการทดสอบในแต่ละ component แน่นอนต้องใช้แนวคิด Test double เช่น stub, mock มาช่วย ซึ่งตรงนี้มีเครื่องมือครบ
• ส่วนที่ไม่ควรทดสอบ เช่น thrid-party library ต่าง ๆ , รายละเอียดของ implementation และการ validate ค่าใน props

ปล. ยังมีเรื่องอื่น ๆ อีก แต่ยังไม่ publish ออกมา
ทั้งการทดสอบ Child component
ทั้งการจัดการ state ด้วย Vuex และ Vue router

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

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

คำถามนี้ผมก็ไม่แน่ใจ เลยลองไปดูเอกสารของ Grafana หน่อย

เรื่องแรกที่อยากรู้คือ default database 

สำหรับเก็บ configuration ต่าง ๆ ของ Grafana คืออะไร
พอไปดูก็ถึงบางอ้อคือ ใช้งาน sqlite นั่นเอง
โดยสามารถเข้าไปดูในไฟล์ $GRAFANA_HOME/conf/default.ini ดังนี้

ดังนั้นเราสามารถแก้ไขและเปลี่ยนไปใช้ database อื่น ๆ เช่น MySQL และ PostgreSQL ได้เลย

ไปดูเพิ่มเติมพบข้อมูลน่าใจคือ

• ข้อมูลต่าง ๆ จะถูกลบทิ้งไปทุก ๆ 24 ชั่วโมง
• ไฟล์ที่เก็บของ sqlite ชื่อว่า $GRAFANA_HOME/data/grafana.db
• สามารถเปลี่ยน remote cache ไปใช้ redis หรือ memcached ได้ แต่ค่า default คือ database

และไปเจอ blog ของ Grafana เขียนเรื่อง How to migrate your configuration database

อธิบายขั้นตอนการ migrate ข้อมูลของ Grafana จาก sqlite
ไปยัง MySQL และ PostgreSQL database
หรืออาจจะใช้เครื่องมืออื่น ๆ ได้ เช่น

• Convert sqlite to mysql online
• Grafana migrator

ดู Live จากงาน React Summit มีการ demo code ด้วย VS Code
แล้วพบว่า มีการแสดงผลการทำงานของ code ที่พัฒนาด้วยภาษา JavaScript
แบบ realtime ใน editor เลย
ก็เลยลองไปหาดูว่า เขาใช้ extention ตัวไหนกัน
ก็ไปเจอ extension ชื่อว่า Quokka.js

จากนั้นก็ลองใช้งาน

เมื่อเขียน code จะแสดงผลการทำงานแบบนี้เลย
เพิ่งรู้ว่ามี extension แบบนี้ด้วย

ถ้าสังเกตในส่วนของ output จะทำการ start server ทิ้งไว้ให้

ไปดูเพิ่มเติมก็มี extension สำหรับ JavaScript Continuous Testing ด้วย

ชีวิตสบายขึ้นอีกเป็นกองเลย

วันนี้มีการพูดคุยเรื่องปัญหาการจัดการข้อมูล
ชนิด Floating-point ในภาษา JavaScript

ปัญหาคือ
การเปรียบเทียบค่า หลังจากทำการประมวลผลแล้ว ไม่ถูกต้องตามที่คาดหวัง
ยกตัวอย่างเช่น
0.1 + 0.2 น่าจะต้องเท่ากับ 0.3
แต่ที่เจอใน JavaScript กลับไม่ใช่ !!

แสดงตัวอย่างของปัญหาดังนี้

จะแก้ไขปัญหานี้อย่างไรดี ?

ลองไปอ่านเอกสารตัวนี้ดูกันก่อนไหม ? ยาวมาก ๆ

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• What Every JavaScript Developer Should Know About Floating Points

การแก้ไขปัญหาขั้นพื้นฐานใน JavaScript

จะมี function ของตัวแปรชนิดตัวเลขที่ใช้งาน 2 function คือ

• toFixed()
• toPrecision()

แต่ต้องระมัดระวังในการใช้งานด้วย
ทั้งค่าที่ใส่ใน parameter
กับผลที่ออกมาจะมีชนิดเป็น string จำเป็นต้องแปลงกลับมาด้วย

แต่ถ้าใช้งานจริง ๆ จัง ๆ แนะนำให้ไปใช้ libary จัดการดีกว่า

เหมือนการจัดการ datetime นิยมใช้งาน moment.js
ยกตัวอย่าง library การจัดการตัวเลยทั้ง Money และ Currency

• Dinero.js
• Money.js
• Currency.js

หรืออีกหนึ่งแนวทาง คือการเก็บข้อมูลเป็นจำนวนเต็มไปเลย ยกตัวอย่างเช่น

• 100.12345 จะทำการเก็บเป็น 10012345 ไปเลย

มี VDO อธิบายเรื่อง number ใน JavaScript ที่น่าสนใจ

มีคำถามเกี่ยวกับการเขียนโปรแกรมด้วยภาษา Java
ว่าการใช้ for-loop ปกติกับการใช้ Stream API นั้น
อะไรที่มี performance ดีกว่ากัน

ตอบได้เลยว่า for-loop เร็วสุด ๆ
แต่อาจจะต้องมองมุมอื่นด้วย ทั้งเรื่องของ readable, safety, maintain
รวมไปถึงความต้องการของงานต่าง ๆ

แต่เพื่อให้ชัดเจนมาทำ benchmark เพื่อวัดระสิทธิภาพการทำงานดีกว่า

โดยถ้าสาย JVM น่าจะต้องใช้เครื่องมือที่มีให้เลย
คือ JMH (Java Microbenchmark Harness)
จะทำการสร้างชุดการทดสอบ ทดสอบ และวิเคราะห์และสรุปผลให้
เป็นเครื่องมือที่พลาดไม่ได้เลย

โดยที่ JMH ก็เตรียม plugin สำหรับเครื่องมือต่าง ๆ ไว้ให้ครบ 

เช่น

• Gradle Plugin
• Scala SBT Plugin
• IntelliJ IDEA Plugin

ยกตัวอย่าง ผมใช้งานร่วมกับ Gradle

มี code ตัวอย่างดังนี้

คำอธิบาย

• ในทุก ๆ method ที่จะทำการ benchmark จะต้องใส่  annotation ชื่อว่า Benchmark
• กำหนดให้ทุก ๆ  method วัดความเร็วการทำงานในหน่วน manosecond
• Mode การ run ใช้แบบค่า average หรือค่าเฉลี่ย

ทำการ run ด้วย Gradle
จะใช้เวลาทดสอบนานใช้ได้เลย ได้ผลการทำงานดังนี้

คำอธิบาย

• For-loop แบบปกติทำงานเร็วที่สุด
• ส่วน Stream แบบ parallel จะรองลงมา

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

ส่วน code ตัวอย่างอยู่ที่ GitHub::Up1

สำหรับสาย Node.JS เรื่องของ dependency check เป็นสิ่งที่สำคัญมาก ๆ
ว่า dependency หรือ npm package ต่าง ๆ ที่เราใช้งานใน project นั้น
มีความปลอดภัยหรือไม่
โดย extension ที่ขอแนะนำใน VS Code คือ Vuln Cost

จะทำการตรวจสอบ dependency ต่าง ๆ ที่ใช้งานแบบ realtime ให้
ตอนนี้สนับสนุน dependency ที่เก็บไว้ที่

• unpkg.com
• ajax.googleapis.com
• cdn.jsdelivr.net
• cdnjs.cloudflare.com
• code.jquery.com
• maxcdn.bootstrapcdn.com

ในปัจจุบัน npm ก็มีการ audit หรือครวจสอบให้
หรือใน GitHub ก็มีการตรวจสอบให้อีกด้วย
ลองใช้งานกันดูครับ
เป็นอีกวิธีการที่ช่วยจัดการเรื่องความปลอดภัยให้

มีคำถามเกี่ยวกับ การเพิ่ม productivity ในการทำงานว่า
มีตัวช่วยอะไรบ้างไหม ?
เนื่องจากการทำงานแบบ Work From Home นั้น
มีสิ่งรบกวนเยอะเหลือเกิน

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

หรือถ้าอยากมีเครื่องมือช่วยก็มีนะ

ทั้ง pomodoro ในการกำหนด timebox การทำงานต่าง ๆ
หรืออาจจะใช้งานเครื่องมือชื่อว่า Forest app ก็ได้
ใช้สำหรับ block website และ app ต่าง ๆ ในเวลาที่กำหนด
เพื่อลดสิ่งรวบกวนจาก web หรือ app ที่เกี่ยวกับ Social network ต่าง ๆ
ที่สำคัญ สามารถเพิ่มรายชื่อ app และ web เพิ่มได้อีกด้วย

โดยค่า default คือ 25 นาที แต่ถ้าเราไปกด unlock ก่อนจะหมดเวลา

ต้นไม้ที่ปลูกไว้ก็จะตาย
ดังนั้น ถ้าทำบ่อย ๆ คุยจะสามารถปลูกป่าได้เยอะเลย
นั่นหมายความว่า คุณ focus กับงานมากขึ้นนั่นเอง

มีให้ใช้ทั้งในมือถือและ browser เลยนะครับ

ลองใช้งานกันดู มาปลูกป่าแข่งกัน
เป็นอีกเครื่องมือที่น่าจะเพิ่ม productivity ได้ดีขึ้น
หรือจะยอมแพ้ !!!

ช่วงเย็น ๆ เห็นภาษา Crystal ผ่าน ๆ ทาง Social networking
ว่า syntax ของภาษาได้รับแรงบันดาลใจมาจากภาษา Ruby
ซึ่งผมชอบภาษา Ruby อยู่แล้ว ที่เขียนง่ายและอ่านง่าย
เลยลองเข้าไปดูหน่อย
แนวคิดของภาษานี้คือ "A language for humans and computers"

ไม่ต้องอ่านอะไรมาก ติดตั้งและเขียน code กันเลยดีกว่า

การติดตั้งก็ไม่ยาก ตามแต่ละ OS ไปเลย
สำหรับผมใช้ MacOS ก็ติดตั้งผ่าน Home Brew ไปเลย
ใช้เวลานานพอสมควร !!

จากที่อ่านมาคร่าว ๆ พบว่า

สามารถทำการ run และ build ระบบงานออกมาในรูปแบบ binary ไฟล์เดียวได้เลย
ทำให้ชีวิตง่ายขึ้นมาก

ดังนั้นมาเขียน code ทำ RESTFul API แบบง่าย ๆ กันหน่อย
ซึ่งมี library build-in ทั้ง HTTP server และ JSON มาให้อยู่แล้ว
ที่สำคัญ สร้าง projectได้เลย  ด้วยคำสั่ง

จากนั้นเขียน code ง่าย ๆ สำหรับสร้าง RESTFul API + JSON response 
โดยจะ run ที่ port 8080 ดังนี้

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

ลองทดลองยิงด้วย wrk นิดหน่อย ได้ผลดังนี้

ทำการเร็วใช้ได้เลย

มาลองเรียนรู้ภาษาใหม่ ๆ กันครับ ผมชอบ syntax ของมันนะ

CodePen น่าจะเป็นอีก website ที่นักออกแบบและนักพัฒนาฝั่ง Frontend ใช้งานกัน
ซึ่งตอนนี้สามารถ run Flutter ได้แล้ว
น่าจะช่วยอำนวยความสะดวกต่อการทดลอง โชว์ code
และแลกเปลี่ยนแนวทางในการพัฒนาได้อีกเยอะเลย
ไปลองใช้งานกันดู

ตัวอย่างของ Flutter editor ใน CodePen
โดยระบบด้านหลังของการทำงานคือ Dart service
ซึ่งเป็น open-source project เอาไปใช้งานได้ฟรี ๆ เลย
พัฒนาจากทีมของ DartPad

วันนี้อ่านบทความเรื่อง Everything you need to know about Caching — System Design
อธิบายเรื่องพื้นฐานเกี่ยวกับ caching หรือข้อมูลชั่วคราว ว่าคืออะไร
มีการใช้งานใน use case หรือในกรณีอะไรบ้าง
รวมทั้ง strategy และ policy การใช้งาน caching ว่าเป็นอย่างไร

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

ถ้าเราเข้า website หนึ่ง ๆ ด้วยความเร็วที่แตกต่างและมีข้อจำกัด

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

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

ถ้าอธิบายง่าย ๆ ให้เห็นภาพในช่วง Work From Home กัน

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

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

แต่ถ้าเป็นในไทยน่าจะเป็นแบบนี้

กลับมาที่ระบบงานหรือ software ของเรากัน

เป็นระบบ Backend ไปดึงข้อมูลหรือจัดการข้อมูลใน Database
ก่อนที่จะส่งข้อมูลเหล่านั้นกลับไปให้ผู้ใช้งานต่อไป
น่าจะมีการทำงานปกติดังรูป

การอ่านข้อมูลจาก Database นั้นใช้ resource และเวลานานใช้ได้เลย
ทั้ง Network ที่ใช้งาน
ทั้ง I/O ที่เกิดขึ้นจากการไปดึงข้อมูลที่อยู่ใน file system
ทั้ง Connection ของ database ที่มีอยู่อย่างจำกัด

ดังนั้นจะดีกว่าไหม
ถ้าเรามีระบบ caching มาช่วย เพื่อลดการเรียกใช้งานมายัง Database
ที่สำคัญที่จัดเก็บข้อมูลของ caching ก็ต้องเร็วและใช้ resource น้อยด้วยเช่นกัน
ยกตัวอย่างเช่น การใช้งาน Key-value database แสดงดังรูป

โดยที่ในการพัฒนาระบบงานนั้น

จะมี caching เยอะมาก ๆ
ทั้งจาก database
ทั้งจากระบบ network
ทั้งจาก data caching
ทั้งจาก browser
ทั้งจาก web server
หรือลงไปในระดับ CPU ก็ยังมี cache level ต่าง ๆ อีกด้วย

สิ่งที่ต้องพึงระวังคือ ข้อมูลชุดเดียวกันอาจจะอยู่หลาย ๆ ที่
ดังนั้นอาจจะทำให้ข้อมูลชุดเดียวกัน
แต่มีรายละเอียดต่างกัน หรือไม่ update (Data inconsistency)
เรื่องนี้ต้องจัดการให้ดี

แนวคิดของ caching นั้นจะมีวงจรชีวิตด้วย

ขึ้นอยู่กับ use case ที่ต้องการใช้งาน ยกตัวอย่างเช่น

• อยู่ตลอดไป
• มีอายุตามที่กำหนด (Expire time)

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

• LRU (Least Recently Used) ข้อมูลชุดไหนที่ถูกใช้น้อย ๆ จะถูกลบไปก่อน 
• LFU (Least Frequently Used) ข้อมูลชุดไหนที่ถูกแก้ไขน้อย ๆ จะถูกลบไปก่อน
• MRU (Most Recently Used)  ข้อมูลที่มีอายุนาน และใช้น้อย ๆ จะถูกลบไปก่อน ไม่งั้นมันจะเน่า

โดยระบบ caching ต่าง ๆ ยังมีนโยบายอีกเพียบ
ยกตัวอย่างเช่น Redis จะมี policy ให้เราเลือกใช้ดังนี้

ในบทความอธิบายเรื่องของชนิดของ caching ไว้ดังนี้

โดยจะแยกตามรูปแบบการจัดการ caching กับ database หลัก
ว่ามีการใช้งานอย่างไร

ชนิดที่ 1 Write Through Cache

เป็นการบันทึกข้อมูลไปที่ระบบ caching ก่อน
จากนั้นทำการบันทึกข้อมูลชุดเดียวกันไปยัง database หลัก
ทำให้ข้อมูลทั้งสองที่ตรงกันเสมอ

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

ชนิดที่ 2 Write Back Cache

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

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

ชนิดที่ 3 Write Around Cache

ทำการบันทึกข้อมูลลง database หลักเลย ไม่ลง caching
แต่ถ้ามีการอ่านข้อมูลจะอ่านข้อมูลจาก caching
แน่นอนว่า ครั้งแรก ๆ จะไม่พบ (cache miss)
ดังนั้นต้องไปดึงข้อมูลจาก database มา
แล้วทำการสร้างข้อมูลใน caching ขึ้นมาเรื่อย ๆ

โดยรวมแล้วเรื่องของ caching เข้ามาช่วยแก้ไขปัญหาให้

แต่ก็มีข้อเสียเช่นกัน ดังนั้นควรเข้าใจด้วยว่า มีข้อเสียอะไร
จะได้เตรียมการรับมือไว้
การแก้ไขปัญหารูปแบบนี้ จะถูกเรียกว่า แก้ไขปัญหาด้วยการเพิ่มปัญหา (N+1 problem)

สิ่งที่ต้องควรพิจารณาของการนำ caching มาใช้ 

• การทำงานทั้ง read/write ว่าเป็นอย่างไร
• Storage รวมไปถึง database model ที่ใช้งาน
• การ sync ข้อมูล
• ความเร็วในการทำงาน
• Availability ของระบบ
• การ Scale
• Security
• Operation 

มาถึงตรงนี้ น่าจะทำให้เข้าใจเรื่องพื้นฐานของ caching มากขึ้นนะครับ

ตอนนี้ทาง Google Cloud ได้ปล่อยบริการที่ชื่อว่า Service Directory
เป็น beta version ให้ลองใช้งานกันแบบฟรี ๆ แล้ว
แนวคิดง่ายมากคือ เป็นระบบกลางสำหรับการจัดการ service ต่าง ๆ นั่นเอง
ทำให้การจัดการ service เป็นแบบ centralize
อีกทั้งยังสนับสนุนพวก Google Compute Engine และ Google Kubernetes Engine
รวมไปถึงแบบ on-prem อีกด้วย

น่าจะเป็น feature ที่คนใช้งาน Google Cloud รอคอยกันอยู่
ส่วนพวก audit log และ access log ก็ไปใช้งาน Google Logging เลย