เพิ่งเห็นว่าทาง ngrok นั้นได้ปล่อย version ใหม่ออกมา
และเขียนสรุปในบทความ Next Generation of ngrok
ซึ่งมีความสามารถใหม่ ๆ เพียบเลย
น่าจะช่วยอำนวยความสะดวกให้นักพัฒนามากยิ่งขึ้น
ซึ่งเป้าหมายของ version นี้ได้เปลี่ยนจาก
การเป็นเพียง developer tool มาเป็น developer platform กันเลย

นั่นหมายความว่า ต้องมีความสามารถเพียบ
แต่ยังคงแนวคิดเดิมคือ ใช้งานผ่าน command line เดียว แบบง่าย ๆ
โดยไม่ใช่แค่สำหรับ local development เท่านั้น
แต่ยังได้เพิ่มเรื่องของ secure production app ด้วย เช่น

• Cloud edge
• Secure tunnels

รวมทั้งความสามารถอีกเพียบ เช่น

• สนับสนุน OAuth 2.0, OpenID connect
• Mutual TLS
• IP restriction
• HTTP header modification
• Load balancing
• Circuit breaker
• Docker image ก็มี update ให้แล้ว

ปล. ส่วน v2 ก็ยังใช้ได้อยู่นะ !!

สามารถดูตัวอย่างการใช้งานจากผู้สร้างได้เลย

ดังนั้นไป Download และ Upgrade ได้เลย

ว่าง ๆ มาดูกันว่า เราจะทำการ export user flow ที่ record จาก Chrome Recorder
มาอยู่ในรูปแบบของ Cypress เพื่อใช้ทดสอบระบบงานต่อไป
โดยสามารถใช้งานผ่าน Cypress Recorder Extension ใน Google Chrome
หรือจะติดตั้งผ่าน NPM/NPX ได้เช่นกัน

ลองใช้งานกันดูหน่อย
โดยทำการทดสอบweb google นี่แหละ
จะได้ผลดังรูป

จากนั้นทำการ copy มาใช้งานได้เลย

ถือว่าเป็นตัวช่วยให้เขียนได้ง่ายขึ้น
ถึงแม้จะยังไม่มี feature มากนักก็ตาม

ตัวอย่างการใช้งานเพิ่มเติม

ส่วน Puppeteer ก็มี Replay ให้ใช้งานเช่นกัน

เพิ่งเห็นว่ามี RK-Boot สำหรับการสร้าง project/service
จาก template ในรูปแบบของ YAML
โดย code ที่ได้มานั้นเป็นภาษา Go
ช่วยทำให้เราสร้าง project ขึ้นมาได้ง่ายและ repeat ได้อีกด้วย
ดังนั้นจึงลองใช้งานกันหน่อย

ขั้นตอนที่ 1 เลือก template ที่ต้องการ

และมี plugins เพิ่มได้อีกด้วย
ผลที่ได้มาคือไฟล์ YAML
หลังจากนั้นทำการ create จะได้ code ของ project มีหน้าตาเป็นดังนี้

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

• Code ภาษา Go และมี dependency ตามที่เราเลือก
• Makefile
• มี Swagger มาให้เลย อันนี้ดีงาม
• ไฟล์ boot.yaml คือ config หลักของ project ที่สร้างด้วย RK-Boot เช่นใช้ dependency อะไร เปิดความสามารถต่าง ๆ หรือไม่ ทั้ง swagger, prometheus และ middleware ต่าง ๆ

จากนั้นลองทำการ build/start ตัว project กัน

ลองใช้งาน Swagger สำหรับดู API Specification กันหน่อย

ดู metric ในรูปแบบของ Prometheus ได้

ส่วน code ในไฟล์ main.go ก็เป็นจุดเริ่มต้นของการทำงานของ project
ซึ่งเราสามารถพัฒนาต่อได้เลย
น่าจะเป็นเครื่องมือให้เราทำ POC ต่าง ๆ ได้ง่ายขึ้น

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

เรื่องที่ 1 การทำงานต่าง ๆ มี feedback loop ที่นานจนเกินไป

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

• การ confirm requirement จากลูกค้า หรือ การตัดสินใจต่าง ๆ
• การทดสอบระบบงานที่ยาวนาน และ ทำบ่อยไม่ได้
• การเปิดขอ environment ต่าง ๆ
• การ review code ที่รวมศูนย์ และไม่บ่อย ส่งผลให้แต่ละครั้งใช้เวลายาวนาน
• การเปิด ticket ต่าง ๆ บ่อยครั้งมีคนมาจัดการแทนทีมอีกต่างหาก แบบนี้เป้นปัญหาไหมนะ ?
• เวลาในการ build และ deploy นาน ๆ

การทำงานต่าง ๆ เหล่านี้ เราลดเวลาการรอหรือการทำงานได้ไหม ?

เรื่องที่ 2 การประชุมเพื่อแก้ไขปัญหา

เมื่อเกิดัญหาหนึ่ง ๆ ขึ้นมา
ที่สิ่งที่ต้องคุยหรือประชุมกันคือ หาทางแก้ไข
ไม่ว่าจะเป็น workaround หรือ solution ก็ได้

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

เรื่องที่ 3 การทำงานระหว่างทีม

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

ลองดูกันหน่อยว่า ปัจจุบันเรามีปัญหาตรงไหนบ้าง ?
บ่อยครั้งพบว่า ปัญหาต่าง ๆ เหล่านี้มันดันกลายเป็นเรื่องปกติอีกต่างหาก !!

จากเรื่องของ Microservices patterns จาก microservices.io
ใช้สำหรับเป็นแผนท่ีนำทางในการพูดคุย ศึกษาเกี่ยวกับ Microservices
ประกอบไปด้วย

• Application patterns
• Infrastructure patterns
• Application-Infrastructure patterns

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

• แยก service อย่างไร
• ติดต่อสื่อสารกันอย่างไร
• หา service กันอย่างไร
• ผู้ใช้งานเข้าใช้งาน service อย่างไร
• deploy service อย่างไร
• service เข้าถึงข้อมูลอย่างไร

จากงาน meetup IN PERSON! Apache Kafka® Meetup Bangkok- June 2022
ซึ่งจัดที่ตึก True Digital Park นั้น มี 2 หัวข้อ ประกอบไปด้วย

• Speedtest: Benchmark Your Apache Kafka®
• How We Applied Apache Kafka® in Sunday

โดยทำการสรุปความรู้ที่ได้รับไว้ดังนี้

เรื่องแรก Speedtest: Benchmark Your Apache Kafka®

เป็นการทำ benchmark สำหรับ Apache Kafka ว่า
สามารถรองรับการใช้งานได้อย่างไร ทั้ง

• Producer เรื่องของ ack (all, 0, 1), ขนาดของ data, การ compression data
• Consumer, consumer group, multi-thread
• Broker
• Topic และ partition

ตัวอย่างของการทำ benchmark อยู่ที่ github

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

• docker-compose.yml สำหรับสร้าง Apache Kafka cluster
• produce_maxMBSec เป็น bash script สำหรับการทำ benchmark ผ่าน command tool เช่น kafka-producer-perf-test และ kafka-consumer-perf-test เป็นต้น

ในทำทำ benchmark หรือ performance นั้น
จะต้องดูความต้องการทาง business เป็นหลักว่าเป็นอย่างไร เช่น

• Throughput เยอะเท่าไร เช่น logging และ IoT
• Latency น้อย ๆ หรือไม่ เช่น offer/promotion/discount
• Durability สำคัญสุดหรือไม่ เช่น payment
• Availability สุด ๆ ไหม 24x7 เช่น centralized kafka

เรื่องที่สอง How We Applied Apache Kafka® in Sunday

เป็นการอธิบายที่การนำ Apache Kafka มาใช้ในระบบงาน
มีการปรับเปลี่ยน architecture ของระบบจาก monolith มายัง microservices อย่างไร
โดยเป็นการอธิบายจากความผิดพลาดหรือปัญหาที่พบเจอ
จากสิ่งที่ได้สร้างขึ้นมา หรือการลองผิดลองถูกนั่นเอง
ซึ่งทำให้เห็นมุมมองการออกแบบ การพัฒนา และ วิธีการแก้ไข

เริ่มตั้งแต่ monolith และนำ Apache Kafka มาใช้แบบ shared topic

แน่นอนว่าง่ายและสะดวก เพราะว่า message/event ต่าง ๆ จะอยู่ที่เดียว
consumer หรือ service ไหนที่สนใจก็สามารถกรองข้อมูลที่ต้องการไปได้เลย

ต่อมาในแต่ละ service ไม่ได้ต้องการ message ทั้งหมด ต้องการบางเรื่อง
จะต้องทำการกรอง ตรวจสอบ type ของ message ที่ต้องการ
ทำการ transform data อีก
จึงทำการสร้าง consumer/service X มาคั่นตรงกลาง
เพื่อทำหน้าที่ข้างต้น เป็นเหมือนการแก้ไขปัญหาเฉพาะหน้าไปก่อน

จะเห็นได้ว่าทุก ๆ message/event เข้าไปที่ share topic เลย
ส่งผลให้เมื่อมีจำนวน service เยอะ มีจำนวนหรือชนิดของ message เยอะ
การจัดการ format ของ message ก็ยากขึ้น
เมื่อมีปัญหาในบาง message อาจจะทำระบบโดยรวมช้าลงไป
การ monitoring ก็ยากขึ้นอีก
ดังนั้นจึงทำการแก้ไขด้วยการแยก topic ตามแต่ละ domain ให้ชัดเจน
รวมทั้งลดการสร้าง Service X หรือผมจะเรียกว่า ACL (Anti-Corruption Layer) ทิ้งไป
ช่วยทำให้การพัฒนา จัดการ และ ดูแลรักษาง่ายยิ่งขึ้น
แต่ต้องระมัดระวังเรื่องของ ความสัมพันธ์ระหว่าง topic ด้วย ว่าแยกกันชัดเจนหรือไม่ ?

ปัญหาต่อ ๆ มา ก็น่าสนใจมาก และมักจะผิดกันเยอะ เช่น

• การกำหนด message key หรือ key สำหรับการ routing message ไปยัง partition ต่าง ๆ ใน topic ไม่ถูกต้องตามที่ต้องการ หรือ ตามการใช้งานจริง ๆ เช่น ใช้ชื่อ type หรือ event name มา ทำให้มีบาง consumer ทำงานหนักเกินไป ในกรณีที่มี event name นั้นเข้ามาใน topic เยอะ ๆ ดังนั้นต้อง monitoring อยู่อย่างเสมอ
• การจัดการ message schema ตรงนี้สำคัญมาก ๆ เพราะว่า message ใช้สำหรับการติดต่อสื่อสาร เหมือนกับ REST API ก็ต้องมี API specification ที่สำคัญต้องตรวจสอบเรื่องของ backward/forward compatability ได้อีกด้วย โดยใน Apache Kafka จะใช้งานผ่าน Schema Registry หรือจะทำเองก็ได้ มีทั้ง JSON Schema, Avro และ Protobuf เป็นต้น
• ในแต่ละ Topic ไม่ควรมี message/event ที่หลากหลาย format
• อีกเรื่องที่น่าคิดคือ อย่าจัดการ Apache Kafka Cluster เอง ถ้าไม่ชำนาญ เพราะว่าแทนที่จะได้ประโยชน์ กลับต้องมานั่งแก้ไขปัญหา และไม่ดีต่อ business แน่ ๆ ดังนั้นต้องดูในแต่ละที่แล้วว่าสถานการณ์เป็นอย่างไร
• การจัดการเรื่องการเข้าถึงข้อมูลใน topic จะมีเรื่องของการใช้ Token/API key ในการตรวจสอบสิทธิ์ว่า สามารถอ่านหรือเขียนข้อมูลได้ ดังนั้นจึงมีตัวกลางในการจัดการอีกที
• รูปแบบข้อมูลที่ทาง Sunday ใช้งานคือ JSON เพราะว่าในการตรวจสอบยังง่าย ส่วนเรื่องของตรวจสอบ schema ยังทำหรือหาวิธีที่ดี แต่คิดว่าน่าจะใช้งาน JSON Schema สำหรับการเริ่มต้น
• ถ้าในแต่ละ consumer มีปัญหาในการทำงาน เช่น ทำงานช้า ส่งผลให้ message ใน topic ค้าง สิ่งที่แนะนำคือ ใน consumer ให้ทำการแก thread การทำงานออกมา ทำให้ไม่ต้องรอกัน หรือ ส่ง ack กลับไปตั้งแต่ได้รับ message มาแล้ว จากนั้นจึงทำงาน ถ้าทำงานไม่ผ่านค่อยทำการ retry หรือส่งกลับไปเข้า topic ใหม่ (แนว ๆ dead letter แบบทำเอง) หรือ ทำการสั่งย้อนกลับไปยัง offset ก่อนหน้า
• ถ้าต้องการเปลี่ยนแปลงจำนวน partition ของ topic แนะนำให้สร้าง topic ใหม่ไปเลย (Static over Dynamic)
• ทางด้วยเรื่องของ security ก็มีการทำ authentication, authorization, SSL communication และ Data encryption ใครจะทำเยอะกว่านี้ก็ต้องดูถึงความคุ้ม และ performance ด้วย

สามารถดูข้อมูลเพิ่มเติมได้ที่

• Apache Kafka Performance
• Optimize Apache Kafka Deployment
• Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines)
• Monitoring Kafka performance metrics
• How to Choose the Number of Topics/Partitions in a Kafka Cluster ?
• Using Apache Kafka as a Scalable, Event-Driven Backbone for Service Architectures
• Replication tools

จาก Cypress 10 นั้นได้เพิ่ม component testing ใน beta version
ออกมาให้ลองใช้งาน ตอนนี้เป็น 10.1.0 แล้วนะ
ซึ่งสนับสนุนระบบที่พัฒนาตามแนวทางของ Component Driven User Interface
ยกตัวอย่างเช่น React และ Vue เป็นต้น
ดังนั้นมาลองใช้งานกันดู

ก่อนอื่นต้องเข้าใจขอบเขตของ Component testing ก่อน

โดยใน framework อื่น ๆ การทดสอบแบบนี้จะเป็นแบบ non-ui
คือไม่เห็นว่า UI แสดงผลอย่างไร
แต่สามารถทดสอบการทำงานของ component ต่าง ๆ
ว่าทำงานถูกต้อง มีพฤติกรรมการทำงานถูกต้องตามที่กำหนดและคาดหวังหรือไม่
เป็นการตรวจสอบก่อนจะนำ แต่ละ component มาทำงานร่วมกันต่อไป

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

แต่ไม่ได้การันตีว่า ทั้งระบบจะทำงานได้นะ
ดังนั้นจำเป็นต้องมี End-to-End testing ด้วย แต่มีเท่าที่จำเป็น

Component testing นั้เหมาะสมกับใคร ?

ตอบง่าย ๆ คือ นักพัฒนา และ นักออกแบบนี่เอง
ดังนั้น Definition of Done (DoD) ควรมี component testing มาด้วยไหม ?

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

ยกตัวอย่างของการสร้างระบบงานด้วย React
โดยจะมี component UserList สำหรับแสดงข้อมูลรายชื่อผู้ใช้งาน
ซึ่ง component นี้ดึงข้อมูลจาก REST APIs มาแสดง

จากนั้นเรามาดูกันว่า จะเขียน Component test อย่างไรด้วย Cypress ++

เริ่มด้วยถ้าเป็น project เดิมที่เคย run ด้วย Cypress version เก่า

จะมีการ migrate ให้ทันที เพราะว่า มีการเปลี่ยนชื่อ folder, file และ config ใหม่นั่นเอง

ต่อมาเลือกว่าจะทำ Component testing beta กัน

ตัว Cypress ทำการ detect ให้เองว่า ใช้ framework และ bundler อะไร
และทำการเพิ่ม config ในไฟล์ cypress.config.js และ cypress/support/component.js, commands.js ให้
เพียงเท่านี้ก็เริ่มเขียน test และ run กันได้แล้ว ง่ายมาก ๆ
โดยไฟล์ต่าง ๆ ของ component test จะอยู่ใน folder cypress/cpmponent

ใน project นั้น ผมใช้ Vite ในการสร้าง
พบว่าเจอ issue นี้ใน cypress :: > Unexpected token '<' error w/ cypress component testing
แก้ไขด้วยการเปลี่ยนชื่อไฟล์ของ component test เป็น .jsx ก็ใช้งานได้

ผลการทำงานผ่าน Cypress เป็นดังนี้

ก็น่าจะพอเริ่มต้นได้แล้วนะ
ดูท่าน่าจะสนุกมาก ๆ สำหรับ Cypress Component Testing

Reference Websites

• Testing types in Cypress

Spring Boot 2.7 นั้นถูกปล่อยออกมาให้ใช้งานแล้ว
เป็น version สุดท้ายของ version 2.x
ก่อนจะก้าวเข้าสู่ยุดใหม่ของ Spring Boot 3 ในปลายปีนี้
ซึ่งเปลี่ยนไปอย่างมากมาย !!

โดย feature หลัก ๆ ที่น่าสนใจ ประกอบไปด้วย

• สนับสนุน Spring for GraphQL 1.0
• สนับสนุน Podman container engine เป็นอีกตัวเลือกแทน Docker Engine สำหรับการสร้าง image ด้วย buildpack
• สนับสนุน Cache2k

จากเอกสาร release ของ Spring Boot
แนะนำให้ทำการ upgrade เป็น vesion 2.7 ก่อนเลย
ก่อนที่จะไปต่อกับ Spring Boot 3 นะครับ

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

• API List.fun
• รายชื่อของ API
• Pokemon Go API
• News API
• JSONPlaceHolder

ใครมี API ที่น่าสนใจ แนะนำมาได้ครับ

จากกลุ่มสมาคม programmer นั้น มีคำถามเกี่ยวกับการเก็บข้อมูลรูป
ว่าทำอย่างไรดี โดยทางเลือกที่แนะนำกันมา ประกอบไปด้วย

• ทำการ encode ข้อมูลรูปก่อน จากนั้นค่อยเก็บ
• เก็บเป็น binary ลง database เช่น BLOB (Binary Large OBject)
• เก็บรูปลง disk แล้วเก็บเฉพาะ path และชื่อรูปลง database
• ใช้งาน CDN (Content Delivery Network)

คำถามที่น่าสนใจคือ ทำไมถึงเก็บข้อมูลรูปลง database ?

ไม่ว่าจะ encode หรือ binary หรือจะ encrypt เลยไหม
เพราะว่าเป็นการเพิ่มภาระงานให้กับ database และ server สูงมาก ๆ
ยิ่งมีคนใช้งานเยอะ ๆ ยิ่งหนัก
รวมทั้งยากต่อการ scale อีก
ยิ่งใช้งาน disk เยอะอีก
ตอนเข้ามาใช้งานก็ต้อง อ่านจาก database แปลงข้อมูล เก็บลง memory
แล้ว return กลับไป เยอะไหมนะ ?
มันดีไหมนะ ?

หนักกว่านั้น ในระบบต้องทำการ resize รูปอีกไหมนะ ?
เพราะว่าใช้ข้อมูลรูปแบบ original บ่อยครั้งจะไม่เหมาะสม
ทั้งขนาด ทั้ง bandwidth ของ network เป็นต้น

แต่ถ้าไม่ใช่ วิธีการนี้อาจจะไม่ถูกต้องเท่าไร !!

แต่การเลือกวิธีการมันก็ขึ้นอยู่กับการตัดสินใจ
บนพื้นฐานของ skill และความต้องการเป็นหลัก

ถ้ายังเก็บข้อมูลรูปลง database คือการ write แล้ว
ในส่วนของการอ่านหรือ read ไม่ควรอ่านจาก database
นั่นคือ การแยกกันระหว่าง write vs read

ในการ read ข้อมูลรูป ไม่ควรอ่านจาก database ทำอย่างไรได้บ้าง ?

ยกตัวอย่างเช่น ในขั้นตอนของการ write
เมื่อบันทึกข้อมูลลง database เสร็จแล้ว
ให้ทำการสร้างรูปสำหรับการ read ต่อเลย
รวมทั้งการ resize รูปอีกด้วย
ต้องเอา messaging มาคั่น และแยก resize image server ออกมาอีกไหม
ให้เป็น file ปกตินี่แหละ อยู่ที่ว่าจะเป็น format อะไร
จากนั้นการเข้าถึงให้ผ่าน CDN เช่น Cloudflare
หรือ caching ของพวก API Gateway/ cache server ไปเลย
ทำให้เราแยกการ write และ read
รวมทั้งลดภาระงานของ server และลดการใช้งาน bandwitdth อีกด้วย

บางรูปต้องมีการตรวจสอบการเข้าถึงด้วย
เช่นมีการใช้งาน token ใด ๆ มาด้วยเสมอ
ตรงนี้ก็เป็นอีกประเด็น

ปล. การเก็บข้อมูลลง database อาจจะมีเหตุผลที่ไม่อาจปฏิเสธได้ก็เป็นได้
ตรงนี้มันขึ้นอยู่กับข้อจำกัดของแต่ละที่แล้ว
แต่ถ้าไม่เก็บได้ก็จะดีกว่านะ จะได้ scale และจัดการรูปได้ง่ายขึ้น

เผื่อใครที่ใช้ Cloud Flare นั้น เรื่องนี้จะถูกแก้ไขหรือลดการทำซ้ำด้วย Cloudflare Image
ครบจบในที่เดียว ทั้งการ resize และ caching ให้เลย

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

วันนี้เป็นวันที่ Microsoft ประกาศว่าจะหยุดการสนับสนุน Internet Explorer หรือ IE
ที่มีอายุใช้งานมากกว่า 27 ปี
แนะนำให้ไปใช้งาน Microsoft Edge นั่นเอง
และยังมี Legacy mode ที่สนับสนุน IE ด้วยนะ

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

จากการแบ่งปันเรื่องการพัฒนา software นั้น
มีเทคนิคหนึ่งที่ใช้งานบ่อย ๆ และแนะนำไป คือ
การแก้ไขปัญหาใหญ่ ๆ ด้วยการแบ่งเป็นปัญหาเล็ก ๆ ออกมา
เพื่อแก้ไขทีละปัญหา และเมื่อแก้ไขจนครบ
จะช่วยให้เราแก้ไขปัญหาใหญ่ ๆ ได้
หรืออาจจะเรียกว่าการทำ work break down นั่นเอง

โดยในการพัฒนา software นั้น เรามักจะมีข้อมูลในระบ feature มาก่อน
ว่าต้องการที่จะทำอะไรบ้าง ทำไปเพื่ออะไร แก้ไขปัญหาอะไร
และได้มาซึ่ง business value อย่างไรบ้าง

จากนั้นก็ทำการแบ่ง feature นั้น ๆ ออกมาเป็น story หรือ flow แบบ end-to-end
ในมุมมองของผู้ใช้งาน ทั้ง customer, admin หรือแม้แต่ system ก็ตาม
เพื่อให้เห็นว่าเกิดอะไรขึ้นบ้าง
เพื่อทำให้เห็นภาพใหญ่ และไม่หลุดกรอบของการทำงานนั้น ๆ
ยกตัวอย่างเช่น เราจะคุยในแง่ของ

• Success flow มีกี่ flow​ ?
• Failure flow มีกี่ flow ?

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

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

หรือบางคนอาจจะบอกว่า ต้องลองทำก่อนถึงจะรู้ว่า ต้องทำอะไรบ้าง !!
ฟังแล้วดูแปลก ๆ ไหมนะ

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

หลังจากที่ GitHub Copilot ปล่อย technical preview ให้ไปขอลองใช้งาน
โดยมี developer มากกว่า 1.2 ล้านคน ใน 1 ปีที่ผ่านมา
ซึ่งตอนนี้ได้ปล่อยตัวเต็มเป็น public ออกมาให้ใช้งานแล้ว
แต่ ...

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

ของดีแบบนี้ เสียเงินก็ไม่แปลกใจ
จะแปลกใจมากกว่า ถ้าให้ใช้งานแบบฟรี ๆ

Reference Websites

• GitHub Copilot is generally available to all developers

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

สิ่งที่ใช้งานประกอบไปด้วย

• Taskfile สำหรับเขียน step การทำงาน ซึ่งดูง่ายกว่า Makefile มาก
• DBML (Database Markup Language) สำหรับการออกแบบ table ต่าง ๆ และ generate มาเป็นคำสั่ง sql ได้เลย ง่ายมาก ๆ
• sqlc สำหรับการสร้าง code เป็นภาษา Go จากคำสั่ง sql

มาดูการใช้งานกัน

ขั้นตอนการทำงานเป็นดังรูป

โดยใน Taskfile จะเขียนดังนี้

ทำการ run ตามนี้

ตัวอย่างของ code ที่ generate ได้เป็นดังนี้

เพียงเท่านี้ก็ได้ process การทำงานที่ automate มากขึ้น
ช่วยลดภาระงานไปได้เยอะเลย
เพียงแค่ออกแบบ table ใน DBML เท่านั้นเอง

สามารถดูตัวอย่าง code เพิ่มเติมได้ที่ GitHub::Up1

ระหว่างการ review code ของระบบงาน
สิ่งที่พบเจอบ่อยมาก ๆ คือ N+1 problem
ฟังแล้วอาจจะงง ๆ ว่าคืออะไร
มาดูตัวอย่างกัน

การดึงข้อมูลจาก database/service

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

น่าแปลกว่า จะเจอปัญหาแบบนี้เยอะมาก ๆ
ที่สำคัญมักจะส่งผลต่อระบบงานในเชิงลบอย่างมาก
และชอบแก้ไขด้วยการเพิ่ม CPU/MEMORY ของระบบอีกต่างหาก !!
ทำไมนะ ?

เพิ่งเห็นว่าเราสามารถสร้าง Golang package server ได้เอง
สำหรับการจัดการ package และการเขียนเอกสารต่าง ๆ ได้แบบง่าย ๆ
โดย source code อยู่ที่ Pkgsite ใน GitHub

การใช้งานนั้นจะต้องใช้

• Go 1.19
• Go 1.18 ใน commit id = 9ffe8b928e4fbd3ff7dcf984254629a47f8b6e63
• Go 1.17 ใน commit id = 4d836c6a652cde92f433967680dfd6171a91ec12

การติดตั้ง

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

การจัดการ resource ต่าง ๆ ใน Kubernetes นั้น
เรื่องของ resource limit และ request ในการใช้งาน
ไม่ว่าจะเป็นแต่ละ pod แต่ละ node
ซึ่งเราสามารถตรวจสอบง่าย ๆ ด้วย Kube-capacity CLI

โดยที่เครื่องมือตัวนี้จะดูได้ทั้ง CPUและ Memory
ว่าถูกใช้งานไปเท่าไรบ้าง
รวมไปถึงเรื่องของ utilization อีกด้วย
เพิ่มเติมสามารถเรียงลำดับของการใช้งาน resource
และกรองข้อมูลตาม label, namespace ได้เช่นกัน
ซึ่งง่ายต่อการใช้งานมาก ๆ

ลอง Download และใช้งานกันดูครับ

เพิ่งมีเวลาว่างมาดู Angular 14 ที่ถูกปล่อยออกมาเมื่อต้นเดือน
ซึ่งมี feature หลายตัวที่น่าสนใจ
แต่มีตัวหนึ่งที่ติดตามมาเรื่อย ๆ ตั้งแต่เปิด RFC
คือ Standalone Component
ดังนั้นเรามาทำความรู้จัก และลองใช้งานกันนิดหน่อย

ปล. ในตอนนี้ยังเป็น feature ที่อยู่ใน developer preview เท่านั้น
ดังนั้นอาจจะเปลี่ยนแปลงอีกมาก เมื่อปล่อยตัว stable ออกมา
ดังนั้นก็ลอง ๆ ไว้ก่อน อย่าเพิ่มเอาไปใช้งานจริง

เป้าหมายหลักของ Standalone Component

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

มาเริ่มใช้งานกันดีกว่า

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

จากนั้นทำการแก้ไขไฟล์ main.ts เพื่อลบการใช้งาน Module ทิ้งไป

ในไฟล์ AppComponent นั้นต้องกำหนดให้เป็น standalone component
นั่นคือ standalone: true
และ import Module, Component และ Directive ต่าง ๆ ที่จะใช้งาน
เช่น CommonModule และ RouterModule เป็นต้น

เพียงเท่านี้ก็สามารถใช้งานได้แล้ว
รวมทั้งสามารถลบ AppModule ทิ้งไปจาก project ได้เลย

ส่วนการสร้าง Standalone component อื่น ๆ ก็ใช้งานผ่าน ng generate ได้เลย

และได้ code ออกมาแบบนี้

เพียงเท่านี้ก็พอใช้งานได้แล้ว
จะเห็นได้ว่าเรียบง่ายขึ้นนะ !!!

เป็นคำถามที่น่าสนใจว่า การ Refactor code ควรหรือไม่ ที่จะอยู่ใน backlog
บ่อยครั้งเราจะพบว่า

• ทำ ๆ ให้มันเสร็จไปก่อน เดี๋ยวไม่ทันส่ง
• เดี๋ยวเราค่อยกลับมาแก้ไขให้มันดีขึ้นกัน

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

ดังนั้นเรามักจะเห็นว่าใน backlog ของหลาย ๆ product
อาจจะมีงานใบโต ๆ หรือ เล็ก ๆ เขียนว่า recfactor/improvement code !!
และมักจะมี priority ต่ำ ๆ ด้วย
นั่นคือ ไม่ถูกนำมาเข้าทำงานสักที !!
หรือพอนำเข้ามาทำงาน ก็ต้องใช้เวลา ความพยายาม และ คนเยอะมาก ๆ
แบบนี้ดีไหมนะ ?
มันคือ การเพิ่มงานโดยไม่จำเป็นหรือไม่ ? น่าคิดนะ

ดังนั้นแทนที่จะรอ refactor ให้เปลี่ยนมา refactor code อย่างต่อเนื่อง
แบบทีละเล็กละน้อย หรือ ทำให้ดีขึ้นเรื่อย ๆ ดีกว่าไหม
จะเรียกว่า Continuous Rectoring

ไม่ต้องมาดู code เยอะ ๆ
ไม่ต้องมาเสียเวลาเยอะ
ลงมือทำทันที fix it now vs fix it later !!
น่าจะทำให้การเพิ่มหรือแก้ไข feature ในระบบงานง่ายขึ้นไหม

แนวคิดหลัก ๆ พยายามลด ไม่ใช้พยายามสร้าง

จากกลุ่ม Golang Thailand มีคำถามเกี่ยวกับการทดสอบ
ระบบงานที่พัฒนาด้วยภาษา Go
โดยในคำถาม จากที่เข้าใจเป็นดังนี้

• ระบบงานพัฒนาด้วย Gin web framework
• ทำการ post data ด้วย Form data
• ต้องการทดสอบผ่าน Test mode ของ Gin + HttpTest

แต่จาก code ตัวอย่างที่ทางผู้ post ได้ใส่ link มา
ซึ่ง code นั้นจะ run ไม่ได้
จึงลองเอามาลองเขียน code เพิ่มเติมนิดหน่อย
เพื่อให้ compile และ run ได้

ผลที่ได้คือ

• ทางผู้เขียนน่าจะเข้าใจผิด เพราะว่า code ที่พัฒนานั้น เป็นการรับค่าจากการ POST ผ่านการ submit form
• ส่วนในการ testing นั้น ทำการ POST ด้วย JSON body
• ทำให้การทดสอบไม่ผ่าน

การทดลองขั้นพื้นฐาน ก็ทำแบบ integration test ผ่าน API testing ด้วย Postman

เพื่อทำให้เข้าใจก่อนว่า code จริง ๆ ทำงานอย่างไรกันแน่ !!

แสดงดังรูป

จากนั้นจึงลงมือเขียนการทดสอบใน test mode ของ gin
ร่วมกับการทดสอบด้วย package net/http/httptest
ซึ่งแก้ไขนิดเดียว คือ ข้อมูลที่ส่งไปนั่นเอง
โดยเปลี่ยนเป็น key=value ที่ submit form นั่นเอง
ดังนี้

เพียงเท่านี้ก็ได้แล้ว
ส่วนการส่ง JSON ก็ดูเพิ่มเติมได้ใน GitHub::Up1 ได้
น่าจะพอมีประโยชน์นะครับ