Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

จากบทความเรื่อง Why hooks are the best thing to happen to React ?
จาก StackOverflow อธิบายเรื่องของ React Hooks ได้อย่างน่าสนใจ
ว่าการพัฒนาระบบงานด้วย React มีหลายแบบ
ทำให้การเปลี่ยนหรือย้ายไปมาทั้ง class และ functional component
เป็นเรื่องที่ไม่ง่ายเลย
ดังนั้นจึงเป็นที่มาของการสร้าง React Hooks
เพื่อให้ง่ายต่อการพัฒนา รวมทั้งการเปลี่ยนไปใช้งาน functional component อีกด้วย

โดยถ้าใครเริ่มด้วย class component

น่าจะต้องมาเรียนรู้เรื่องของ Life cycle ของ React ก่อน
ทั้งการเพิ่มหรือแก้ไขข้อมูลใน DOM ว่าเป็นอย่างไร
จะทำการ mount และ unmount อย่างไร
ทั้งการจัดการ render เมื่อข้อมูลเปลี่ยนแปลง
แน่นอนว่า การจะทำความเข้าใจไม่ง่ายเลย !!
แสดงดังรูป

Image may be NSFW.
Clik here to view.

ดังนั้นจึงสร้าง Hooks ขึ้นมาให้ใช้งาน แต่ต้องใช้งานกับ functional component เท่านั้น

เช่นมี useState และ useEffect ขึ้นมาใน Hooks
แน่นอนว่ายังมี Hooks อื่น ๆ ให้ศึกษาและใช้งานอีกเพียบ เช่น

• useContext
• useRef
• useReducer
• useMemo
• useCallback

เพื่อให้ง่ายต่อการใช้งาน
ยกตัวอย่าง code ของ Hooks
เป็นการดึงข้อมูลจาก API ด้วย axios library
จากนั้นเอาค่ามาแสดงผล
แน่นอนว่า หลาย ๆ คนอาจจะบอกว่า มันคือ magic ที่ซ่อนความซับซ้อนเอาไว้ เช่นกัน

แต่ถ้าใช้ class component แล้ว ต้องมาจัดการผ่าน method ต่าง ๆ ของ class ดังนี้

• componentDidMount()
• componentDidUpdate()
• componentWillUnmount()

แต่ใน Hooks ใช้เพียง useEffect ก็พอ

รวมทั้งข้อมูลการตั้งคำถามเกี่ยวกับ React ใน StackOverflow ก็เพิ่มในทุก ๆ ปี

นั่นน่าจะแสดงให้เห็นอย่างชัดเจนว่า
การพัฒนาด้วย React มีความนิยม
พร้อมกับปัญหาของการพัฒนาที่เยอะด้วย
ซึ่งตรงข้ามกับ Angular เลย !!

Image may be NSFW.
Clik here to view.

ดังนั้น React Hooks น่าจะเข้ามาช่วยให้การพัฒนา React ง่ายและสะดวกขึ้น

แต่เรื่องของ class component ก็ยังคงสำคัญเช่นกัน
ส่วน functional component + Hooks ก็เข้ามาเติมเต็มสิ่งที่ขาดหายไป
หรือใช้งาน functional component โดยไม่ต้องใช้ Hooks ก็ได้
ถ้าเราต้องการในเรื่องของ หน้าที่การทำงานที่ง่าย
เรื่องการ reuse และความยืดหยุ่นของ code

ขอให้สนุกกับการเขียน code ครับ

Image may be NSFW.
Clik here to view.

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

ทาง SoundCloud แบ่ง service ออกเป็น 3 กลุ่ม

• Edge service จะเป็นพวก API gateway และ BFF (Backend For Frontend) สำหรับทำงานตามความต้องการจากฝั่งผู้ใช้งาน
• Value-Added service (VAS) เป็น layer ตรงกลางที่นำข้อมูลจาก service ต่าง ๆ มาประมวลผล หรือ aggregation/orchestrate layer เพื่อให้เหมาะสมต่อผู้ใช้งานนั้น ๆ เป็น service ที่มีความเฉพาะเจาะจงต่อ business domain นั้น ๆ
• Foundation service เป็น low-level services ที่ทำงานเฉพาะเจาะจงไปเลย มีหน้าที่รับชอบหนึ่ง ๆ ไปเลย เกิดมาเพื่อการ reuse โดยเฉพาะ

แสดงดังรูป

Image may be NSFW.
Clik here to view.

เป้าหมายหลัก ๆ ของการแบ่งตามนี้คือ แยกการทำงานออกตามหน้าที่อย่างชัดเจน

รวมทั้งช่วยเพิ่ม productivity ของการส่งมอบระบบงานอีกด้วย
แน่นอนว่า มันก็มีข้อเสียเช่นกัน ประกอบไปด้วย

• การเพิ่ม layer ใหม่ขึ้นมา ก็คือความซับซ้อน และ ค่าใช้จ่ายในการดูแลรักษาที่เพิ่มขึ้น รวมทั้ง infrastructure ที่เพิ่มขึ้น monitoring ที่เพิ่มขึ้น
• เป็นการเพิ่ม network latency อีกด้วย
• อาจจะก่อให้เกิดการเรียก service มั่วไปหมดได้ หรือเกิด depednency hell นั่นเอง

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

มาลองดูความสามารถใหม่ใน Google Chrome 97 (Dev channel) ที่ชื่อว่า Recorder
สามารถทำการ record การใช้งาน web นั้น ๆ ไว้
จากนั้นทำการ replay ได้
รวมทั้งสามารถกำหนดความเร็วของระบบ network ที่ใช้งานอีกด้วย
เพื่อวัดผลการทำงานว่าเป็นอย่างไร

สามารถเข้าไปเปิดใช้งานที่ DevTools -> More Tools ดังรูป

Image may be NSFW.
Clik here to view.

จากนั้นก็เริ่มใช้งานด้วยการสั่ง record ดังนี้

Image may be NSFW.
Clik here to view.

ทำการ record ได้ดังนี้

Image may be NSFW.
Clik here to view.

ทำการเลือกความเร็วของ network ได้

Image may be NSFW.
Clik here to view.

อีกทั้งสามารถทำการ replay และ วัดเรื่องของ web performance ได้ดังนี้

Image may be NSFW.
Clik here to view.

ยังไม่พอ ยังสามารถเพิ่ม assertion หรือ การตรวจสอบผลจาก action ต่าง ๆ ได้อีก

Image may be NSFW.
Clik here to view.

ลอง Download มาลองใช้งานกันดู
น่าจะมทีประโยชน์เยอะมาก ๆ สำหรับ web development

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

หลังจากที่ผ่านหนังสือ Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People ไปนั้น
มีเนื้อหาที่น่าสนใจ เป็นพื้นฐานที่ดี
เหมาะตั้งแต่คนที่ไม่มีความรู้ขึ้นมาเลย
เนื่องจากมี algorithm พื้นฐานต่าง ๆ ที่จำเป็นต้องรู้และเข้าใจ
รวมทั้งอธิบายด้วยภาษาที่ง่าย และ รูปภาพประกอบเพียบ
สามารถอ่านเรียงตามบทไปเรื่อย ๆ หรือ จะเลือกอ่านในแต่ละบทที่สนใจได้

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

• Big O Notation สำหรับการวัดประสิทธิภาพการทำงานของ algorithm ต่าง ๆ เพื่อเลือกให้ให้ถูกกับงาน
• Data structure หรือ โครงสร้างข้อมูล สำหรับจัดการข้อมูลต่าง ๆ ทั้ง array, queue, linked list, stack และ hash table เป็นต้น
• Algorithm ซึ่งขาดไม่ได้เลย จำเป็นต้องรู้ algorithm ยอดนิยม ทั้ง Binary search, Selection sort, Quick sort, Breadth-First Search (BFS), Dijkstra, Greedy algorithm และ K-nearest neighbours เป็นต้น
• มีแบบฝึกหัดให้ลองทำ เพื่อทำการเขียน codeเพื่อแก้ไขปัญหา โดย code ตัวอย่างในหนังสือจะใช้ภาษา Python
• สิ่งที่ชอบมาก ๆ คือ มีการวาดรูปอธิบายโดยตลอด ทำให้เข้าใจง่ายขึ้น

Image may be NSFW.
Clik here to view.

ลองหามาอ่านกันดูครับ
อ่านง่าย ถ่ายคล่อง

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ในช่วง 1-2 วันที่ผ่านมา เจอปัญหาของระบบงานที่อยู่บน production
แน่นอนว่า ระบบล่ม เมื่อมีการใช้งานเยอะขึ้น
CPU วิ่งไป 100% แบบพุ่งปรี๊ดดด
จึงลองดูกันหน่อยว่าจะแก้ไข หรือ ทุเลาลงไปได้อย่างไร ?

การแก้ไขปัญหาเฉพาะหน้า และ หาต้นเหตุของปัญหา

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

เมื่อแก้ไขปัญหาเฉพาะหน้าแล้ว ก็มาหาปัญหาและแก้ไขกันหน่อย

• มีการเชื่อมต่อ database ทุก ๆ ครั้งที่เข้าระบบ ไม่ว่าจะต้องดึงข้อมูลจาก database หรือไม่ ตรงนี้โหดมากต้องแก้ไข แต่ยังทำไม่ได้ เพราะว่าต้องแก้ไข code ทั้งระบบ ความเสี่ยงสูง
• ไม่มีการใช้ caching ใด ๆ ต่อ database ตรงอย่างเดียว เช่นเดียวกันต้องแก้ทั้งระบบ ง่ายในการทำแต่เยอะเท่านั้นเอง
• ดูจาก log การใช้งานผ่าน Load balance พบว่ามีส่วนงานจำนวนมาก ที่ทำงานช้ามาก ๆ ตรงนี้คือต้นเหตุแรก !!
• ปัญหาคือใช้งาน database เป็นหลัก ดังนั้น เน้นไปตรงนี้ก่อน

เมื่อลองไปดู log ก็เจอทันทีว่า มีส่วนงานอะไรที่ช้าบ้าง

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

เมื่อลงไปดูต้นเหตุของปัญหา พบว่า

• ไม่ทำ index ใน table ซึ่งตรงนี้จะยังไม่มีปัญหา ถ้าจำนวนข้อมูลไม่มากพอ และ traffic ไม่มากพอ
• มี operation ที่ทำงาน update ข้อมูลใน database จำนวนมาก ทั้ง ๆ ที่ใน business logic จริง ๆ ไม่ได้ต้องการแบบนั้น เมื่อข้อมูลมากขึ้นเรื่อย ๆ การ update ข้อมูลตามเงื่อนไขของนักพัฒนาก็มากขึ้น และเมื่อถึงวันโชคดีก็โดนกันไป

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

การแก้ไขปัญหาทั้งสองข้อไม่ยาก

เพียงทำ index ไปซะ และไปเปลี่ยน condition ให้การ update น้อยลงไป
จาก update ข้อมูลครั้งละ 10,000-50,000 record ต่อ request
แน่นอนว่า ช่วง peak traffic พุ่งสูงมาก !!!
หลังจากแก้ไข เหลือ update ข้อมูลครั้งละไม่เกิน 10-20 record เท่านั้น

แน่นอนว่ายังมีปัญหาอื่น ๆ และที่ยังไม่รู้ รอระเบิดออกมา

ต้องแก้ไขกันต่อไป
ทั้งการ monitor การทำงานของทุก ๆ request ว่าช้าหรือเร็วอย่างไร
ทั้งการปรับเปลี่ยนโครงสร้างของ database server
ทั้งการปรับเปลี่ยน flow การทำงานของ code
ทั้งการนำ caching data เข้ามาช่วย เพื่อลดภาระและค่าใช้จ่ายของ database ลงไป
เพื่อช่วยให้ business ยังคงเดินหน้าต่อไปอย่างราบรื่น

จะเห็นได้ว่า การตัดสินใจใด ๆ ใน architecture ของระบบ

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

Image may be NSFW.
Clik here to view.

หลังจากที่ Java 17 ปล่อยออกมานั้น
ก็กลายเป็น version ที่เป็น Long Term Support (LTS) ใหม่ แทน java 11
ดังนั้นจึงกลายเป็น version ที่น่าจะต้องเตรียม migrate
จาก Java 11 มายัง Java 17 กันได้แล้ว

ตั้งแต่ Java 12-17 นั้นมี feature ใหม่ ๆ ออกมาดังนี้

• Switch expression
• Text blocks
• Record
• instanceof
• Sealed classes
• Pattern matching ใน switch-cases

แสดงดังรูป

Image may be NSFW.
Clik here to view.

โดยใน Spring Initializr นั้น ก็มีให้เลือก version ของ Java 8, 11 และ 17 เช่นกัน
ดังนั้นวันนี้เตรียมพร้อมกันหรือยัง ?

Reference Websites

• New features in Java 17

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

เห็นว่าใน Go 1.18 นั้นกำลังพัฒนากันอยู่
เห็น feature ที่น่าสนใจคือ Go Workspace สำหรับ Multi-module development
ซึ่งปกติแล้วก็ทำได้ผ่านไฟล์ go.mod ดังที่เคยเขียนไว้
แต่ปัญหาที่ตามมาคือ
ถ้าเราต้องการ develop บน local โดยใช้ multi module บนเครื่อง
แต่เมื่อ production ก็ไปใช้ของจริง
ดังนั้นจึงมีแนวคิดด้วยการสร้างไฟล์ go.work ขึ้นมา
เพื่อให้ง่ายต่อการพัฒนาแบบ multi-module บน local ได้ง่าย

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

ก่อนอื่นทำการติดตั้ง Go 1.18 ซึ่งเป็น development version กันหน่อยดังนี้

เพิ่งรู้ว่ามีวิธี download Go ใน version development มาใช้ด้วย gotip !!

จากนั้นทำการสร้างไฟล์ go.work ขึ้นมา

เพื่อ reference หรือใช้งาน module ต่าง ๆ ที่ต้องการบน local

การใช้งานสามารถ run และ build ได้ปกติ
แต่ถ้าไม่ต้องการใช้งาน Go workspace ตอน build ก็ใช้ -workfile-off ได้

ปล. ส่วนไฟล์ go.work ก็ไม่แนะนำให้เอาเข้า version control ด้วย

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ในการทดสอบระบบงานพวก RESTful API นั้น ๆ
เราสามารถทดสอบได้หลายวิธี ไม่ว่าจะเป็น

• API testing tools เช่น Postman
• Unit, Integration, Component และ End-to-End testing

แต่อีกตัวที่น่าสนใจคือ Contract Testing
สำหรับการทดสอบการทำงานร่วมกันระหว่าง services ต่าง ๆ

พอดีมี project ต้องใช้งาน
จึงลองสรุป Contract testing ด้วย Spring Cloud Contract ไว้
โดยสามารถดูเพิ่มเติมใน Spring Cloud Contract Reference
จะสนับสนุนทั้ง HTTP และ messaging
มาเขียนกันเลย

ขั้นตอนที่ 1 เริ่มจากการออกแบบการทำงานของผู้ใช้งาน(Consumer)และผู้ให้บริการ (Provider)

โดยติดต่อกับผ่าน HTTP protocol ปกติด้วย REST + JSON
ซึ่งทั้ง consumer และ provider จะต้องมาสรุปรูปแบบของการติดต่อสื่อสาร
ว่าจะต้องมีรูปแบบอย่างไร
มันคือ API specification นั่นเอง
จะเรียกว่า Contract หรือสัญญาระหว่างกัน
ดังนั้นถ้ามีการเปลี่ยนสัญญาจะรู้ได้ทันที

ขั้นตอนที่ 2 ทำการสร้าง Contract ขึ้นมา ซึ่งสามารถ execute ได้ ไม่ใช่เป็นเพียงไฟล์เอกสารที่โยนไปมา

โดยสามารถสร้าง contract ได้หลายรูปแบบ
จะเรียกว่า Contract DSL ประกอบไปด้วย

• Java
• Groovy
• Kotlin
• YAML

ตัวอย่างของ Contract ที่เขียนด้วยภาษา Groovy

ขั้นตอนที่ 3 ในฝั่ง provider ทำการเขียน test โดยนำข้อมูลจาก Contract ที่สร้างไว้มาใช้

จะเรียกว่าการสร้าง Contract test
ในส่วนนี้เราจะเขียนเพียง Based-test class เท่านั้น
เพื่อระบุว่าเป็น class หลักของการทดสอบด้วย Contract ดังนี้

จากนั้นทำการ run test ผ่าน gradle ได้คำสั่ง

โดยคำสั่งนี้จะทำการ generate test case class จาก contract
ที่อยู่ใน folder contract ให้แบบอัตโนมัติ
และทำการทดสอบให้อีกด้วย

ขั้นตอนที่ 4 เมื่อฝั่ง provider ทำการทดสอบผ่านแล้ว ทำการสร้าง stub server และ upload ไปยังตรงกลาง

การสร้าง stub server จาก Contract นั่นเอง
เพื่อให้ทางฝั่ง consumer หรือผู้ใช้งานนำไปใช้
เพื่อใช้ในการทดสอบ หรือ มันคือ Mock API server นั่นเอง
ถูกสร้างมาให้ทุกครั้งเมื่อมีการเปลี่ยนแปลง

ขั้นตอนที่ 5 ในฝั่ง consumer ก็ทำการเขียน test case เพื่อใช้งาน Contract test + Stub server

ทำการใช้งาน stub server ที่สร้างจาก provider
และถูกจัดเก็บไว้ใน Apache Maven Repository แบบ local
เขียนได้ดังนี้

จากนั้นก็ทดสอบแบบปกติ
เพียงเท่านี้เราก็สามารถเริ่มต้นทำ Contract testing
ด้วย Spring Cloud Contract ได้แล้ว
เป็นอีกแนวทางในการทดสอบและการทำงานร่วมกันที่น่าสนใจ
ส่วนเครื่องมืออื่น ๆ ก็เช่น Pact เป็นต้น

ขอให้สนุกกับการ coding ครับ

ดูตัวอย่าง code แบบเต็ม ๆ ได้ที่ GitHub:Up1

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

จากที่เคยเขียน blog อธิบายความสามารถที่น่าสนใจของ .NET 6 preview
ในช่วงต้นเดือนพฤศจิกายนทาง Microsoft ปล่อย .NET 6 ตัว final
มาให้ใช้งานบน production กันแล้ว
โดยมีความสามารถใหม่ ๆ ดังนี้

• เรื่องแรกคือ performance ที่ดีมาก ๆ ถึงกับบอกว่าเป็น version ที่เร็วที่สุด
• มีการใช้งาน CPU, Memory และ I/O น้อยลง
• ปรับปรุงเรื่อง performance ด้วย Dynamic Profile-guided Optimization (PGO)
• จะทำการ support ไปอีก 3 ปี
• สนับสนุน C# version 10 เช่น record struct, file-scopes namespace
• สนับสนุน F# 6
• สนับสนุน Hot reload ที่นักพัฒนาชอบ ทั้งใน Vistual Studio และ CLI
• สนับสนุน HTTP 3
• สนับสนุน OpenSSL 3
• มีระบบการ monitor และ debug ที่ดีขึ้น ช่วยให้หาจุดที่มีปัญหาได้รวดเร็วขึ้น เพื่อแก้ไขได้ง่ายขึ้น
• Default ของ console logger สำหรับ container จะเป็น JSON format
• สนับสนุน OpenTelemetry สำหรับเรื่องของ distributed tracing

ลองอ่านเพิ่มเติมได้ที่ Announcing .NET 6 — The Fastest .NET Yet

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ใน Docker Desktop 4.2 นั้น ทำการเพิ่ม feature ที่น่าสนใจเข้ามา
คือ การ pause/resume ของ Docker Desktop เมื่อไม่ถูกใช้งาน
จะช่วยประหยัด resource บนเครื่องที่ใช้งาน
ทั้ง CPU และ memory
นั่นหมายความว่า ส่งผลต่อการใช้งาน battery ของเครื่องอีกด้วย
แต่ยังเป็นการทดลองเท่านั้นนะ

ลองทำการ update กันดู

Image may be NSFW.
Clik here to view.

และเพิ่มเติมเกี่ยวกับการ update docker desktop ด้วย
จะไม่มี popup ขึ้นมาอีกแล้ว
โดยสามารถเข้าไป setting ได้เลย

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

เพิ่งคุยเรื่องการใช้งาน Stored procedure ที่เขียนใน database
ว่าระบบ legacy หลาย ๆ ตัวใช้งานกัน
และยังคงดูแลรักษา เพิ่ม feature ต่าง ๆ มาจนถึงปัจจุบัน
ตลอดจนก็สรรเสริญถึงมันเยอะมาก ๆ !!
ว่าแต่ปัญหามันคืออะไรกันแน่ ?
มันไม่ดีใช่ไหม ?

ก่อนอื่นต้องมาดูข้อดีของ Stored procedure ก่อนว่ามีอะไรบ้าง

เนื่องจากถ้ามันไม่ดีแล้ว จะมีใน database ต่าง ๆ ทำไมกัน
ข้อดีมีดังนี้

• ความเร็วในการจัดการข้อมูลที่สูงมาก ๆ เพราะว่าไม่ต้องส่งข้อมูลข้ามระบบ network ดังนั้น network latency น้อยมาก ๆ
• ง่ายต่อการจัดการ เพราะว่า อยู่ที่เดียวคือ database
• ซ่อนการทำงานต่าง ๆ จากผู้ใช้งาน เราสามารถซ่อนความซับซ้อนได้ง่าย ๆ คนใช้งานก็ง่าย
• สามารถใช้งานความสามารถอื่น ๆ ของ database ได้ง่าย

แต่ปัญหาที่มักเกิดขึ้นคือ

• นำ business logic, validation, logging, traction ของระบบที่ซับซ้อน ไปใส่ไว้ใน stored procedure มันสามารถทำได้ แต่การดูแลไม่ง่ายเลย
• แต่ละ stored procedure ทำการเรียก stored procedure อื่น ๆ ไปมา ทำให้แก้ไขที่หนึ่ง ดันไปกระทบอีกที่หนึ่ง
• การจัดการ versioning ของ store procedure ยาก
• เจอระบบแบบกระจายตามแต่ละ business/service ยิ่งลำบาก รวมถึงการจัดการ transaction
• การทดสอบไม่ต้องพูดถึง ไม่ง่ายเลย
• เกิดการ lock กับ database นั้น ๆ ทำให้เปลี่ยน หรือ scale ได้ยาก
• ขาดคนที่มีความรู้และเข้าใจกับ database และ stored procedure ทำให้ค่าใช้จ่ายในการดูแลรักษาสูงขึ้น

ดังนั้น อย่าไปเขียน business logic ไว้ใน stored procedure จะดีกว่า
ไม่ใช่ว่า ไม่ใช้เลย ซึ่งก็ไม่ถูกต้อง
ยิ่งถ้าเป็นการทำงานกับระบบที่รวม database ไว้ด้วยกัน
stored procedure จะเหมาะสมมาก ๆ ในการจัดการ เช่น ETL (Extract, Transform, Loader)

ดังนั้นสิ่งต่าง ๆ เหล่านี้มันคือ การตัดสินใจ

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

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

เพิ่งได้รับ email แจ้งว่ามีหนังสือใหม่ออกมา ชื่อว่า Git Apprentice
เป็นหนังสือที่มีเนื้อหา เหมาะสำหรับผู้เริ่มต้นกันเลย
ใช้งานใน command line ล้วน ๆ
ตั้งแต่แนวคิด การสร้าง repostory, การจัดการใน local และ remote
ซึ่งครบถ้วนต่อการเริ่มต้นมาก ๆ
ใครสนใจ ลองไปอ่านกันได้
แต่ว่าอ่านได้ไม่หมดนะ เพราะว่า ต้องเป็นสมาชิกด้วย

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

เช้านี้เจอคำถามที่น่าสนใจจาก Twitter ของ Pragmatic Programmer
สอบถามเกี่ยวการ tracking bugs ของระบบงาน
ว่าทำกันอย่างไรบ้าง ?

มีคำตอบที่น่าสนใจเยอะเลย ยกตัวอย่างเช่น

• แก้ไขทันที จะเก็บไปทำไม
• จะเก็บในระบบ ถ้ามาจากผู้ใช้งาน
• ให้ project manager เก็บ
• ทำการ tracking แยกตามแต่ละ environment
• เก็บได้ แต่ขอให้ได้ feedback loop ที่รวดเร็ว
• อย่าสร้าง bug สิ
• Divide and conquer

ใครมีวิธีการ หรือ เครื่องมือที่น่าสนใจสำหรับ bug tracking
สามารถแนะนำกันได้ครับ

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ช่วงค่ำมีพูดคุย User Flow
เพื่ออธิบายและคุยระบบงานกับ product ที่ทำนิดหน่อย
เลยเห็นว่าใน Miro มี User Flow template ให้ใช้งาน
เลยลองนำมาใช้งานดู
ปกติมักจะไม่ใช้ template มากเท่าไร จะสร้างเองมากกว่า

User flow นั้นช่วยทำให้เราเข้าใจว่า
ผู้ใช้งานในแต่ละกลุ่มใช้งานระบบงานเราอย่างไร
ตั้งแต่ต้องจนจบ
ช่วยทำให้เราออกแบบและวางแผนได้อย่างถูกต้อง
และทุกคนในทีมมีภาพของเป้าหมายร่วมกัน
ถ้าผิดก็ผิดไปด้วยกัน

โดยใน template ตัวนี้ จะมี element หรือสัญลักษณ์การใช้งานดังนี้

• จุดเริ่มต้นและสิ้นสุดของ flow การใช้งาน
• Process การทำงาน หรือ action ที่เกิดจากผู้ใช้งาน
• จุดที่ตัดสินใจ ว่าจะไปทิศทางไหน

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

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

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

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

โดยทำการสรุปแนวทางที่แบ่งปันไว้เป็นเรื่อง ๆ ไว้ดังนี้

• เริ่มต้นด้วยการอย่าเพิ่งแยก service ออกมา ให้เพิ่ม feature ใน service ที่มีอยู่ก่อน ทำให้เป็น module ที่ดีก่อน หรือ อาจจะเป็น library ก็ได้
• ถ้าจะแยก service ออกมา ต้องมีเหตุผลที่ดีและถูกต้อง หลัก ๆ คือมี business value อย่างไร
• การแยกต้องมีการ migrate หรือการย้ายทั้งข้อมูลและการใช้งาน ซึ่งต้องค่อย ๆ ทำแบบ incremental อย่าทำแบบ big bang
• เริ่มที่ปัญหาก่อนเสมอ
• ทำการปรับปรุงอย่างต่อเนื่อง ไม่มีความว่าจบหรือเสร็จสิ้น
• ที่สำคัญมันคือ การแก้ไขปัญหา ดังนั้นถ้าทำแล้วมีปัญหามากกว่าเดิม น่าจะเดินผิดทางแน่ ๆ ลองย้อนกลับมาที่จุดเริ่มต้น แล้วเริ่มต้นใหม่

ขอให้สนุกกับการปรับปรุงและแก้ไขปัญหา

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ไปเจอ tweet ใน Twiter เกี่ยวกับ การตรวจสอบว่า
คุณเป็น Web Developer จริง ๆ หรือไม่
โดยให้เราทำการอธิบายว่า
เรื่องต่าง ๆ เหล่านี้คืออะไร อย่างไร
ถ้าไม่รู้จักแสดงว่าคุณไม่น่าจะเป็น Web Developer จริง ๆ !!
มาลองทดสอบตัวเองดู

• Closures
• Hoisting
• Reduce
• this in JS
• Prototypal inheritance
• IIFE
• Promises
• SPA
• Virtual DOM
• Webpack
• REST
• Lazy loading
• JWT
• CSRF
• XSS
• CORS

พอลองดูแล้ว ตอบได้เลยว่า ผมไม่ใช่ Web Developer แน่ ๆ

ปล. ต้องรู็และเข้าใจเรื่องอะไรอีก แนะนำกันได้นะครับ ?

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

คำถาม
ต้องการกำหนด version ต่าง ๆ ของ binary file
ที่ build มาจากภาษา Go จะทำได้ไหม ?

คำตอบคือ ทำได้
แล้วทำอย่างไร ?

ในการ build binary file ด้วย Go นั้น
สามารถส่งข้อมูลเข้าไปผ่าน parameter --ldflags เข้าไป
เพียงเท่านี้ก็สามารถจัดการได้แล้ว
ไม่ต้องไปกำหนดผ่าน environment variable หรือพวก config file ใด ๆ ทั้งสิ้น

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

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

ส่วนใน Go 1.18 สามารถใช้ add version จาก git commit ได้เลย

Image may be NSFW.
Clik here to view.

จากบทความเรื่อง Scaling productivity on microservices at Lyft (Part 2): Optimizing for fast local development
ทำการอธิบายถึงการเพิ่ม productivity ของการพัฒนาระบบของ Lyft
ซึ่งมีโครงสร้างของระบบตามแนวคิด Microservicesว่าทำอย่างไร
จึงจะช่วยให้ developer experience ดีขึ้น
โดยสามารถทำงานได้บนเครื่อง local หรือเครื่องนักพัฒนาแต่ละคนให้ได้มากที่สุด
มาดูกันว่าทางทีมของ Lift ทำอย่างไรกันบ้าง ?

เริ่มที่ขั้นตอนการพัฒนาจะประกอบด้วย 2 ส่วนคือ

• Inner dev loop คือการแก้ไขและ run test บนเครื่อง local ของนักพัฒนา
• Outer dev loop คือ CI/CD process นั่นเอง ซึ่งอยู่ในอีกระบบหนึ่ง จะทำงานเมื่อตรวจสอบการเปลี่ยนแปลงใน version control ที่กำหนดไว้

แสดงดังรูป

Image may be NSFW.
Clik here to view.

โดยสิ่งที่ขาดหายไปใน Inner Dev Loop คือ
การทำให้เหมือนหรือคล้าย Outer Dev Loop นั่นคือ
การมีเรื่องของ CI/CD process นั่นเอง
ถ้าสามารถทำได้บนเครื่อง local ของนักพัฒนาก่อน
น่าจะช่วยลดเวลาของการตรวจสอบจากการเปลี่ยนแปลงต่าง ๆ ได้ดี

โดยการ run บน local นั้น ทางทีมไม่ได้ใช้งาน Container เช่น Docker

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

• Python จะใช้ AActivator
• Node จะใช้ Nodeenv

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

ขั้นตอนของการ run service เป็นดังนี้

• ทำการตรวจสอบ environment ว่ามี software และ configuration ตามที่กำหนดไว้หรือไม่
• ทำการสร้าง virtual environment ขึ้นมา
• ทำการ start data store หรือ database ขึ้นมา
• ทำการ start proxy app ขึ้นใช้สำหรับจัดการการเรียกข้อมูลจาก service อื่น ๆ ทำให้ง่ายต่อการ mock นั่นเอง
• ทำการ initial ข้อมูลใน database จาก script ที่สร้างไว้
• สุดก็ทำการ run server ขึ้นมา เพื่อทำการมดสอบหรือใช้งานต่อไป

โดยที่ Proxy app แสดงการทำงานดังรูป

Image may be NSFW.
Clik here to view.

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

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

จากปัญหาของ Log4j core ที่มีช่องโหว่ในการโจมตี จาก CVE-2021-44228
ซึ่งทาง Spring ได้ออกมาอธิบาย
รวมทั้งวิธีการตรวจสอบ แก้ไขต่าง ๆ ไว้ดังนี้

หลัก ๆ ปัญหานี้ถูกแก้ไขแล้วใน Log4J version 2.15.0

สำหรับคนที่ใช้งาน Spring Boot แบบ default ในการพัฒนา
จะไม่ได้รับผลกระทบ เพราะว่าไม่ได้ใช้งาน Log4j-core นั่นเอง

แต่ถ้าใครเปลี่ยน default logging มาเป็น Log4j
แน่นอนว่าได้รับผลกระทบแน่นอน
ซึ่งจำเป็นต้อง upgrade ไปใช้ log4j version 2.15.0

สำหรับ project ที่ใช้งานผ่าน Apache Maven
ให้ทำการตรวจสอบ version ของ log4j ดังนี้

ส่วน Gradle ก็ตรวจสอบดังนี้

สำหรับ project ที่ไม่สามารถแก้ไข code หรือ dependency ได้

ก็ให้แก้ไข environment variable ในไฟล์ property

หรือใน environment variable ดังนี้

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

ใน Go 1.18 นั้น จะมีความสามารถใหม่ ๆ ที่น่าสนใจเพิ่มเข้ามา เช่น

• Type parameters (Generic)
• Workspace
• Fuzzing test

โดยสิ่งที่จะอธิบายใน blog นี้คือ Fuzzing test
เพิ่มเข้ามาใน testing library นั่นเอง
แน่นอนว่ายังเป็น beta version อยู่

ความสามารถหลัก ๆ ของ Fuzzing test คือ

ช่วยทำการสร้าง input แบบ random ขึ้นมา
ตาม type ของ method ที่ทดสอบผ่าน unit test นั่นเอง
ทำให้ลดปัญหาเรื่อง edge case ที่นักพัฒนาอาจจะพลาดไปได้เยอะ
ทำให้มี data test ที่หลากหลาย รวมทั้งเรื่องของ security อีกด้วย
ซึ่งบางคนอาจจะเคยได้ยินเรื่อง Mutation testing
ดังนั้น Fuzzing test น่าจะมีประโยชน์มาก ๆ สำหรับนักพัฒนา
มาลองใช้งานกันดีกว่า

จากเอกสารของ Go นั้น เราเพียงใช้ prefix ของ test case ชื่อว่า Fuzz

ในการ run test นั้นก็ใช้งานผ่าน go test เหมือนเดิม ดังนี้

แน่นอนใช้เวลาในการ run นาน
เพราะว่า จะทดสอบแบบ sub-test ซึ่งมี test case จำนวนมาก ๆ

แถม CPU นี่พุ่งปรี๊ดมาก ๆ

Image may be NSFW.
Clik here to view.

ลองศึกษาและใช้งานกันดูครับ
ให้ทำหลังจากทดสอบ function การทำงานปกติผ่านแล้วนะครับ