เห็นทาง InfoQ ทำการสรุป Culture & Methods Trends Report March 2023 ออกมา
มีสิ่งที่น่าสนใจหลาย ๆ เรื่อง เช่น

• การปลดคนจากบริษัท IT ขนาดใหญ่ ส่งผลต่ออย่างมาก
• การมาของ Generative AI ที่ได้รับความนิดยิมอย่างสูงในเวลาอันสั้น เช่น ChatGPT, ChatGPT plus และ Github Co-pilot เป็นต้น
• การทำงานแบบ remote, hybrid และ asynchronous เป็นที่ยอมรับและใช้งานกันแพร่หลาย เพราะว่าเป็นแนวทางที่มีประโยชน์อย่างมาก ช่วยให้การทำงานร่วมกันคล่องตัวและยืดหยุ่นมากยิ่งขึ้น
• เรื่องของ tech ไม่ใช่แค่เพียงทำตามกฏหมายต่าง ๆ เท่านั้น ยังต้องใส่ใจต่อสังคมด้วย เพื่อทำให้ทั้งลูกค้าและพนักงานอยากใช้งาน อยากทำงาน และ เป็นลูกค้า จะเรียกว่า DevSusOps

สิ่งที่น่าสนใจคือ Generative AI ในสายงานการพัฒนา ?

จะเข้ามาช่วย หรือ มาแทนที่ ?
เป็นหัวข้อที่น่าสนใจมาก ๆ
เนื่องจากมีทั้งคนมองว่าจะมาแทนที่
หรือเข้ามาช่วยเพิ่ม productivity เพราะว่าเข้ามาช่วยทำงานต่าง ๆ ให้ เช่น

• Automated code generation
• Documentation และ comment generation
• Data collection
• Error checking
• Testing
• Collaboration กับทีม

ดังนั้นช่วยให้นักพัฒนามีเวลาไปใช้ความคิดสร้างสรรค์มากขึ้น
รวมทั้งการเรียนรู้เพิ่มเติมที่จะเป็น Prompt engineering

แต่เหรียญมี 2 ด้านเสมอ
ทั้งด้านเรื่องความเสี่ยงของข้อมูลที่ได้
หรือสามารถสร้าง malware ต่าง ๆ ต่าง ChatGPT ได้

เนื่องจากมีการทำงานแบบ Hybrid มากยิ่งขึ้น ทำให้ Team Topology มีการเปลี่ยนแปลง

ดังนั้นบริษัทจึงต้องมีรูปแบบการทำงานและโครงสร้างของทีมที่สอดคล้อง
เพื่อให้ทีมทำงานร่วมกันได้ดีขึ้น
เพิ่ม productivity ให้สูงขึ้น

Reference Websites

• Boost Your Productivity as a Developer with OpenAI's ChatGPT
• 8 Ways ChatGPT Helps You Boost Your Programming Productivity

จากการแบ่งปันเรื่อง Observability ของระบบงาน
ใน Course Microservices workshop ที่ Skooldio มานั้น
โดย Observability นั่นประกอบไปด้วย 3 ส่วนหลัก ๆ คือ

• Application metric
• Distributed tracing
• Log aggregation

ต่อจากนั้นก็เอาไปทำ dashboard และ alert system ได้อีก
เพื่อช่วยให้เราสามารถดูได้ว่า application ทำงานอย่างไร
มีปัญหาตรงไหนบ้าง ?
หรือมีสัญญาณของปัญหาที่อาจจะเกิดขึ้นไหม ?
ถ้าเจอแล้ว สามารถเข้าถึงจุดเกิดเหตุได้ง่ายและรวดเร็วมากยิ่งขึ้น

จากแนวคิด นำมาสู่วิธีการจัดการ นั่นคือเครื่องมือที่ใช้งาน
หนึ่งในชุดของเครื่องมือที่แนะนำกันมาคือ Grafana platform
ประกอบไปด้วย

• Grafana สำหรับ dashboard
• Loki สำหรับเก็บ logging
• Tempo สำหรับเก็บ tracing
• ใช้งาน Prometheus สำหรับ data source ที่จัดเก็บข้อมูล metric

ตัวใหม่ที่น่าสนใจคือ Tempo

ใช้ในการจัดการ distributed tracing
แสดงการทำงานดังรูป

โดยที่ตัว Agent นั้น สามารถกำหนดได้ว่า exporter หรือปลายทางที่เก็บคืออะไร
เช่น

• OTLP (http, grpc)
• Zipkin
• Jaeger (http, grpc)

ตัว Tempo นั้น สร้างมาเพื่อเป้าหมายของ high-scale distributed tracing backend
นั่นคือ เลือก data storage ได้เยอะขึ้น ทั้ง local และ remote
ช่วยให้เก็บได้ทั้ง 100% ดีขึ้น ลดพื้นนที่ในการจัดเก็บ
สนับสนุน TraceQL สำหรับการดึงข้อมูล tracing
และใช้งานได้ง่าย

เพื่อความเข้าใจมาดูการใช้งาน Grafana platform กับ Spring Boot 3 กัน

แสดงโครงสร้างการทำงานดังรูป

ใน Sprint Boot นั้นทำงานเรื่อง Tracing เหมือนเดิม
เพิ่มเติมคือ จะมี Grafana Agenet สำหรับ Java เข้ามา เข้ามา
เพื่อทำการส่งข้อมูลจากเครื่องที่ service ของ Spring Boot ทำงานอยู่
ไปเก็บที่ Tempo นั่นเอง

ตัวอย่างการกำหนดค่าใน docker compose ของ Spring Boot 3

• ทำการกำหนด Grafana agent และกำหนด environment variable ได้อีก
• เก็บ trace ผ่าน OTLP
• ที่จัดเก็บ trace คือ Tempo server ผ่าน HTTP protocol

มาดูตัวอย่างการ config Tempo และ Grafana กัน

ผลการทำงาน เมื่อมีการ access เข้า Spring Boot 3 application
ข้อมูล trace จะเข้าไปที่ Tempo และแสดงผลผ่าน Grafana Explore ดังรูป

ชุดเครื่องมืออื่น ๆ ประกอบไปด้วย

• Application metric => Prometheus, Grafana Loki
• Distributed tracing => Zipkin, Jaeger และ Grafana Tempo
• Log aggregation => ELK stack

Reference Websites

• ทำความรู้จักกับ Loki
• Spring Boot 3 Observability with Grafana
• Auto-instrumenting a Java Spring Boot application for traces and logs using OpenTelemetry and Grafana Tempo
• Project Demonstrating Observability For NodeJs Applications
• Springboot, OTEL and Tempo

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

สิ่งรบกวนที่เจอกันมาก ๆ ในการทำงานทั้ง remote หรือ onsite
ประกอบไปด้วย

เรื่องแรกคือ การประชุม ที่หลาย ๆ คนชอบ !!

ยิ่งตอนนี้หลาย ๆ ที่ประชุม online/remote กันเยอะมาก ๆ
ส่งผลให้ไม่ต้องจองห้องประชุมกันแล้ว
ทำให้หลาย ๆ คน ต้องเข้าประชุมพร้อม ๆ กันหลายประชุม
นั่นคือ เน้นเข้าร่วม ไม่เน้นการมีส่วนร่วม
หรือเข้ามาเพื่อ check ชื่อเท่านั้น

บางประชุมสร้างมาเพื่อเข้ามาพูดคุยเรื่องทั่วไป
บางประชุมสร้างมาทำไม
บางประชุมสร้างมา เพื่อประชุมครั้งต่อไป
บางปประชุมคนที่เข้าร่วมไม่ได้เตรียมตัวอะไรมาเลย

ดังนั้นในแต่ละการประชุมควรมีการกำหนดหัวข้อ เป้าหมาย รายละเอียกให้ชัดเจน
รวมทั้ง invite คนที่เกี่ยวข้องเท่านั้น
และส่งรายละเอียดให้คนเข้าประชุม เพื่อเตรียมตัว
หลังการประชุมควรสรุป หาข้อตกลง หรือ action ที่ต้องทำต่อไปเสมอ
หรือแม้กระทั่งรับ feedback หลังการประชุม เพื่อใช้ในการปรับปรุงต่อไป

เรื่องที่สองคือ พวก communication tools ต่าง ๆ ที่เยอะเกินไป

ยกตัวอย่างเช่น Discord, Slack, LINE และ Team เป็นต้น
ส่วนถ้าแต่ก่อนก็ email หรือ โทร กันตรง ๆ เลย

ปัญหาที่ตามมาคือ

• จำนวน channel และ ห้องการพูดคุยเยอะมาก ๆ
• จำนวน message เยอะมาก ๆ มีทั้งเรื่องส่วนตัว เรื่องของทีม ของ project และ Bug/incident ต่าง ๆ มั่วไปหมด
• ทำให้เกิด notification ทั้งวัน
• การใช้งานมันเป็นแบบ async นั่นหมายความ อาจจะไม่มี response กลับมาทันทีนะ ดังนั้นงานอะไรที่เร่งด่วน คงไม่ใช้งานผ่านเครื่องมือนี้นะ ควรโทรนะ !!

ดังนั้นควรลดจำนวนของ public chat group ลงไป
กำหนดช่วงเวลาในการเข้ามาดู หรือ ตอบเรื่องต่าง ๆ
อะไรที่เร่งด่วนก็โทรตรง ๆ เลย
อะไรที่ไม่สำคัญก็ mute channel นั้นไปก่อน

อีกเรื่องที่เจอบ่อย ๆ คือ งานด่วน

ไม่ว่าจะเป็น incident task จาก production หรือ business issue
ไม่ว่าจะเป็นงานด่วนจากเบื้องบน
ไม่ว่าจะเป็นคำถาม หรือ ปัญหาจากลูกค้า

สิ่งเหล่านี้คือ unplan work หรือ งานที่ไม่ได้วางแผนรับมือไว้
ทำให้เกิดงานงอก งานแทรก เยอะมาก ๆ

ดังนั้นสิ่งที่ควรทำไว้คือ

• ในแต่ละวันหรือสัปดาห์ ควรแบ่งเวลาไว้สำหรับ unplan work ไว้
• ใน request ต่าง ๆ ควรมีรายละเอียดชัดเจน เช่น สรุปปัญหาว่าเป็นอย่างไร ขั้นตอนการ reproduce ปัญหา ผลกระทบทาง bussiness ที่เกิดขึ้น
• ต้องมีแนวทางในการจัดการ prioritize ของงานต่าง ๆ เสมอ

ใน Docker Desktop 4.18 นั้นมีความสามารถที่น่าสนใจทั้ง

• Docker init (beta version) สำหรับการสร้างไฟล์ต่าง ๆ ที่ต้องใช้งานให้เลยผ่าน $docker init
• Container file explorer (GA)
• Docker Scout
• Docker Compose watch command (experiment)

ตัวที่น่าสนใจคคือ Docker Compose watch command (experiment)

ช่วยให้เราสามารถคอยดูการเปลี่ยนแปลงของ file ต่าง ๆ
ในระหว่างการพัฒนาได้ง่ายขึ้น
โดยใช้งานผ่าน option ชื่อว่า x-develop ในไฟล์ docker-compose.yml ได้เลย

คำอธิบาย

ในการใช้งาน watch นั้น สามารถกำหนเได้ทั้งการ sync และ rebuild image ได้

• ทำการ sync ที่ /app/web ใน container เมื่อมีการเปลี่ยนไฟล์ต่าง ๆ ใน folder ./web ที่ host
• ทำการ rebuild image เมื่อมีการเปลี่ยนแปลงไฟล์ package.json ที่ host และทำการสร้าง container สำหรับ service ให้ใหม่เองอีกด้วย

ลองใช้งานกันดูครับ
มันยังเป็นเพียง experiment feature นะ

ใน Docker นั้นมี management command ใหม่ชื่อว่า init
ซึ่งอยู่ในสถานะ beta
สร้างมาเพื่อให้ง่ายต่อการสร้าง project ที่ต้องใช้งาน Docker
โดยจะทำการสร้างไฟล์ต่าง ๆ ที่จำเป็นให้ ประกอบไปด้วย

• Dockerfile
• docker-compose.yml
• .dockerignore

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

เริ่มที่ตรวจสอบ docker ก่อนว่ามี init command ไหม

จะมี init* อยู่

ต่อมาลองใช้งานกัน

จะมีให้เราเลือกใช้งานกัน 3 ส่วนคือ

• สร้าง Dockerfile และ Docker compose สำหรับระบบที่พัฒนาด้วยภาษา Go
• สร้างสำหรับ project ทั่วไป
• ทำการส่ง request ไปยังทีมพัฒนา ว่าต้องการให้มี template ของอะไรเพิ่มบ้าง

มาดูตัวอย่างของ Dockerfile สำหรับ project ทั่วไป

เป็นแบบ multi-stage build กันไปเลย
พร้อมคำอธิบายของแต่ละขั้นตอน

ในส่วนของ docker-compose.yaml ก็เช่นกัน

ถือว่าเหมาะมากสำหรับผู้เริ่มต้นใช้งาน Docker
ลองใช้งานและ feedback กลับไปกันดู

จากหนังสือเรื่อง Learn Prompting นั้น
มีเรื่องที่น่าสนใจเยอะมาก ๆ
หนึ่งในนั้นคือ เรื่องการ Prompt hacking ประกอบไปด้วย

• Prompt Injection
• Prompt Leaking
• Jailbreaking
• Defensive Measures

ชื่อที่คุ้น ๆ คือ Prompt Injection !!

ซึ่งเคยได้ยินจากเรื่องของ web security เช่น

• SQL Injection
• Command Injection

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

โดยที่ Prompt Injection ก็เช่นกัน
นั่นคือ อาศัยความเข้าใจขั้นตอนการทำงานของ ChatGPT
จากนั้นก็ส่งชุดคำสั่ง หรือ การพูดคุย เข้าไป
ทำให้ตัว ChatGPT ทำการ hack หรือ โจมตีตัวเองได้เลย
เป็นเรื่องที่น่าสนใจมาก ๆ

และยังมี Indirect Prompt Injection อีก

ต่อไปอาจจะมีตำแหน่ง Prompt Security Engineering อีกไหมนะ

Reference Websites

• Reverse Prompt Engineering for Fun and (no) Profit
• You can’t solve AI security problems with more AI
• The prompt report
• 'Indirect prompt injection' attacks could upend chatbots

เห็นมีการพูดถึง Auto-GPT จึงลองไปดูหน่อยว่าเป็นอะไร
และลองใช้งานกันหน่อย
เริ่มจากมันคือ open source project ที่อยู่บน GitHub
และเป็น experiment project เพื่อนำ GPT-4 และ GPT 3.5 มาใช้งาน
เพื่อให้ทำงานแบบอัตโนมัติ โดยเพียงกำหนดเป้าหมาย (goal)
ของสิ่งที่ต้องการ (ให้กำหนดเป้าหมาย 5 เรื่อง)
จากนั้นก็ลงมือสร้างและใช้งานกันเลย
ชีวิตจะง่ายไปแล้วจริง ๆ !!

ในเชิง technical แล้ว Auto-GPT นั้น พัฒนาด้วย

• ภาษา Python 3.11
• ใช้งาน Pytorch สำหรับการทำ GPT model training แบบอัตโนมัติให้

ขั้นตอนการติดตั้ง

เนื่องจาก master branch ยังไม่นิ่ง เนื่องจากมีการเปลี่ยนแปลงสูงมาก ๆ
ดังนั้นทางทีมพัฒนาแนะนำให้ใช้ latest release ไป ตอนนี้ V0.2.1
ให้ทำการ download และ extract ได้เลย

การติดตั้งมี 2 แบบคือ

• ติดตั้งปกติ ผ่านการ run ไฟล์ run.sh
• ติดตั้งผ่าน Docker

ซึ่งผมเลือกใช้แบบ Docker เพราะว่าสะดวกและง่ายดี

เท่าที่ดู update กันโหดมาก ๆ

การเตรียมสิ่งที่ต้องใช้ในการ run

• API Keys ของ OpenAPI ขอบอกว่าใช้เยอะมาก ๆ ระวังเกิน limit นะ
• ทำการ config ในไฟล์ .env ให้ทำการ copy จากไฟล์ .env.template
• ทำการ config backend/storage ในการเก็บข้อมูล เพื่อใช้ในการเก็บประวัติต่าง ๆ เพื่อใช้สำหรับการสร้างผลลัพธ์ที่ถูกต้องมากยิ่งขึ้น ซึ่งเป็น Memory-based มีให้เลือกคือ local เป็นค่า default, redis, pinecone, milvus และ weaviate
• ทำการ config พวก image generator provider เช่น dalle, huggingface
• ทำการ config อื่น ๆ อีกเพียบเช่น audio to text provider, git provider, search provider, social (twitter)
• หรืออ่านจาก text file ปกติที่ local ก็ได้

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

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

ยังมี project อื่น ๆ อีก เช่น

• BabyAGI
• AgentGPT
• Godmode
• Do Anything Machine
• Microsoft’s JARVIC or HuggingGPT
• CAMEL
• GPTRPG

Reference Websites

• Auto GPT: Explained, Demo, How to Install & Use
• AutoGPT: A Comprehensive Guide to Generating Text with GPT Models
• Understanding Auto GPT: The Next Evolution in AI Technology
• Auto-GPT Unmasked: The Hype and Hard Truths of Its Production Pitfalls
• Introducing "🤖 Task-driven Autonomous Agent"
• An Overview Of Autonomous Agents: BabyAGI, Auto-GPT, CAMEL, and Beyond
• Robo-GPT, a variant of #AutoGPT
• The Birth of AI Operating Systems

เพิ่งเห็นว่าใน Go.dev นั้นมีบทความใหม่
เรื่อง Developing a RESTful API with Go and Gin
เป็น tutorial ของการพัฒนา RESTful API ด้วย Gin web framework
ซึ่งเหมาะมาก ๆ สำหรับมือใหม่สาย Go
มาดูกันว่ามีเนื้อหาอะไรบ้าง ?

เนื้อหาจะเป็นแบบพื้นฐานมาก ๆ ประกอบไปด้วย

• การออกแบบ API endpoint ของระบบงาน ถ้าจะให้ดีควรออกแบบเป็น API spec ดี ๆ ไปก่อนเลย (ถ้าเป็น Design-First จะสวยมาก ๆ)
• ทำการสร้าง project เป็นแบบ Go module ซึ่งเป็นท่ามาตรฐาน
• การพัฒนาเริ่มด้วยการออกแบบ data model ว่าเป็นอย่างไร ในรูปแบบของ JSON และ struct ใน Go เป็นการออกแบบรูปแบบของข้อมูลที่จัดเก็ย รวมไปถึง input/output ของ request/response อีกด้วย
• จากนั้นทำการสร้าง handler และ rounter ต่าง ๆ ด้วย Gin web framework แบบง่าย ๆ
• ทำการ run เพื่อทดสอบในแต่ละ endpoint ไปเรื่อย ๆ แต่ไม่มีตัวอย่างของการเขียน test case นะ ถ้ามีด้วยจะแจ่มมาก ๆ

ถือว่าเหมาะมาก ๆ สำหรับการเริ่มต้น

อีกอย่างสามารถเรียนรู้และเขียนแบบ online ได้เลย
ผ่าน Google Cloud Shell Editor
ทำตามแบบ step-by-step ได้เลย

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

จากที่เคยเขียนเรื่อง ลองใช้งาน Native AOT (Ahead of Time) ของ .NET 8
ที่เป็น preview 1 มาตอนนี้เป็น preview 3 พบว่า

• ขนาดของไฟล์ลดลงจาก 8.3M เหลือ 7.9M
• ถ้าเทียบกับ .NET 7 ก็ลดลง 50%
• การ publish มีค่า default เป็น release เลย ไม่ใช่ debug แล้ว ส่วนการ build ยังเป็น debug

ตัวอย่างการ build, publish และ publish แบบ Debug

ส่วนของ Docker image ก็มีเตรียมไว้ให้
คือ mcr.microsoft.com/dotnet/sdk:8.0-preview
หรือดูเพิ่มเติมได้ที่ Microsoft Artifact Registry

ใน Docker Image ของ .NET 8 ประกอบไปด้วย

• ใช้ Debian 12
• Non-root user
• เปลี่ยน default port จาก 80 เป็น 8080 หรือกำหนดค่าผ่าน environment variable ชื่อว่า ASPNETCORE_HTTP_PORTS
• มี Chiseled Ubuntu images ให้ใช้
• Build multi-platform container images

ลองทดสอบใช้งานกันเล่นดูนะ

จาก paper เรื่อง Towards an Ontology of Terms on Technical Debt
นั้นทำการสรุปชนิดของ technical debt ออกมาได้อย่างน่าสนใจ
รวมทั้งตัวชี้วัดของแต่ละชนิด
จึงทำการบันทึกไว้นิดหน่อย
น่าจะมีประโยชน์ สำหรับการการปรับปรุงคุณภาพของ software ให้ดีขึ้น

ชนิดของ Technical Debt ใน paper มีดังนี้

• Architecture Debt ว่าด้วยเรื่องของ architecture ของระบบ ที่ส่งผลต่อการพัฒนา ทดสอบ และ ส่งมอบที่ยากหรือนานขึ้น
• Build Debt ในการพัฒนานั้นจะมีขั้นตอนของการ build ทั้งการ compile code, download dependency ซึ่งช้าลงเรื่อย ๆ
• Code Debt เรื่องของ source code ที่ไม่ตรงตามหลักการเขียน หรือ code smell ต่าง ๆ
• Defect Debt เรื่องของ defect ที่มักจะแก้ช้า หรือ จัดลำดับความสำคัญไว้ทีหลัง
• Design Debt เรื่องของโครงสร้างของ code ที่วิเคราะห์ออกมาพบว่า ไม่เป็นไปตามแนวปฏิบัติที่ดี เช่น แต่ละ class ผูกมัดกันมากจนเกินไป
• Documentation Debt พบเจอบ่อย ๆ ที่เอกสารไม่สามารถอธิบายการทำงานของระบบปัจจุบันได้ ไม่ update หรือ ไม่เพียงพอต่อการใช้งาน
• Infrastructure Debt เช่นเรื่องความล่าช้าของการสร้าง หรือการ update/fix/patch ต่าง ๆ
• People Debt มีคอขวดที่คนบางคน ส่งผลให้เกิดปัญหา หรือ ส่งมอบล่าช้า
• Process Debt ขั้นตอนการทำงานที่เยอะ หรือ ไม่จำเป็น หรือ ต้องรอนานเกินไป
• Requirement Debt ต้องมีทั้งจาก business และ technical รวมทั้ง functional และ non-functional เสมอ
• Test Automation Debt เรื่องของ fast feedback ของ development life cycle รวมทั้งความเชื่อมั่นที่น้อยลงเรื่อย ๆ
• Test Debt เช่นการทดสอบไม่ครอบคลุม หรือ ไม่เสร็จจริง ๆ ตามที่วางแผนไว้

ในระบบของเราของ Technical Debt อะไรกันบ้างนะ ?

Node.js 20 ถูกปล่อยออกมาให้ใช้งานแล้ว
มีสิ่งที่น่าสนใจดังนี้

• ปรับปรุง performance ให้ startup time เร็วขึ้น
• มี permission model เพิ่มเข้ามา เหมือนกับ Deno เลย แต่เป็นเพียง experiment นะ เช่นการอ่านเขียนไฟล์ และ เข้าถึง process ต่าง ๆ เป็นต้น
• ใช้งาน V8 version 11.3
• Test runner นั้นเป็น stable version แล้ว โดย test case ใช้ได้ทั้ง describe, it/test, mocking, watch mode และ parallel testing
• มีการเปลี่ยนแปลงของการสร้าง Single executable applications (SEA)
• ปรับปรุง debugger

เรื่องของ Test runner ก็น่าสนใจ

ดูเพิ่มเติมใน Release note

สำหรับใครที่สนใจ ReactJS มีอีกที่คือ React.gg
ทำการอธิบายเรื่องของ ReactJS จาก official documentation
ในรูปแบบที่เข้าใจได้ง่าย
ดูได้จากที่นี่ React => visualized

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

• Learning path แบบเกมส์งูมาเลย
• อธิบายเรื่องของ ประวัติของ React
• The react way
• การส่งข้อมูลระหว่าง component ผ่าน props
• การจัดการ state
• การ render
• การจัดการ effect

น่าจะช่วยให้การเรียนรู้สนุกขึ้น

ทาง Storybook (SB) เพิ่งปล่อย version 7.0 ออกมาให้ใช้งานแล้ว
ซึ่งเป็น major version ที่ออกมาในรอบ 2 ปีกันเลย
ดังนั้นจึงมาการเปลี่ยนแปลงมากมาย
มาดูกันว่ามีอะไรบ้าง ?

• เปลี่ยน UI ใหม่
• สนับสนุน Vite โดย default
• สนับสนุน NextJS และ SvelteKit
• ปรับปรุงรูปแบบของ Component Story (Component Story Format 3 : CSF3)
• เอกสารสนับสนุน MDX2
• ปรับปรุงเรื่องของการ testing และ test coverage อีกด้วย

โดย Storybook ยังคงเน้นในเรื่องของ

• Component-driven development
• Documentation ของ component เช่น Doc Block
• การทดสอบแต่ละ component
• Integrate เข้ากับ Continuous Integration แบบง่าย ๆ

สิ่งที่ชอบมาก ๆ คือ testing และ coverage

ช่วยทำให้เราสามารถสร้างและทดสอบ UI component ที่มีความซับซ้อนได้ง่ายมากขึ้น
ทั้งการดึงข้อมูล การเปลี่ยน state และ การ render UI
รวมทั้งการ interact กับ component นั้น ๆ
โดยการใช้งาน library จะคล้ายกั[ Testing Library
ส่วนการทดสอบนั้นเป็นแบบ parallel testing อีกด้วย

และยังมี coverage report ให้อีก ตรงนี้สบายเลย

ลองใช้งานกันดูครับ
เปลี่ยนแปลงเยอะน่าดู

บันทึกการอ่านเรื่องของปรับปรุง architecture ของระบบ Twitch
ซึ่งทำการปรังปรุงระบบ Monolith มายัง Microservice
โดยมีขั้นตอนการปรับปรุงที่น่าสนใจ
ทำการเขียนใน blog 2 ตัวคือ

• Breaking the Monolith at Twitch: Part One
• Breaking the Monolith at Twitch: Part Two

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

เริ่มต้นทาง Monolith ทุกอย่างรวมกันที่เดียว

ง่ายต่อการพัฒนา ส่งมอบ
แน่นอนว่า เร็ว และ ดีต่อทีมที่มีขนาดเล็กในช่วงเริ่มต้น (Startup)
ทั้ง Web, database , file system
พัฒนาด้วย Ruby On Rails (RoR)

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

• ทำงานร่วมกันมาเกินไป (Coordination)
• Resilience
• Scalability

โดยที่ Twitch นั้นมีปัญหาคอขวดของการ scale เป็นหลัก !!
เช่น

• ระบบ chat
• ระบบ VDO
• ระบบ Search

ดังนั้นจึงเริ่มมีแนวคิดที่จะพยายามแยกส่วนต่าง ๆ ออกมา
จากเดิมที่พัฒนาด้วย Ruby On Rails อย่างเดียว
เริ่มทำงานแบบ background ด้วย Sidekiq
แต่พบว่ายังอยู่ใน codebase เดิมซึ่งใหญ่ จึงพยายามแยกออกมา

ความพยายามแรกคือ พัฒนาส่วนใหม่ด้วย NodeJS
แต่ก็เจอปัญหาตอนการ scale
ในบทความบอกคร่าว ๆ ว่าเป็น ปัญหาที่ core ของ NodeJS
ซึ่งตอนนั้น NodeJS ยังใหม่มาก ๆ
จึงไม่ได้นำมาใช้งาน

ความพยายามที่สองคือ Python + Tonado
โดยได้พัฒนาระบบ chat ตัวใหม่ขึ้นมา

จากนั้นได้เริ่มนำภาษา Go มาลองสร้างเครื่องมือในระบบงาน
เช่นระบบ pubsub ที่เขียน code ไม่กี่ร้อยบรรทัด
เพื่อใช้ในการแลกเปลี่ยนข้อมูลในระบบ
หรือการ mock service เพื่อช่วยตรวจสอบ bug ในระบบ
ซึ่งเป็นการทดลองใช้ Go

เป็นจุดเริ่มต้นของการนำภาษา Go มาใช้งาน
และใช้เป็นภาษาหลักของระบบต่อมานั่นเอง

ในส่วนของ Frontend ก็เปลี่ยนแปลงเช่นกัน

จาก jQuery -> Ember.js มาจนถึง React.js

ขั้นตอนการย้ายระบบเก่ามาใหม่

จะเป็นการทำงานแบบขนานกันไป
โดยจะมี proxy มากั้น request เพื่อแยกไประบบเก่าและใหม่
ทำให้สามารถ redirect traffic ได้ง่ายขึ้น
ซึ่งใช้ NGINX ดังรูป

การเปลี่ยนแปลงครั้งนี้ จะกระทบเยอะมาก ๆ

ทั้งเรื่องของโครงสร้างของบริษัท
ทั้งเรื่องการเขียน code ใน repository เยอะ ๆ
เพื่อทำการส่งมอบ feature เดียวกัน
จะ deploy อย่างไร

การ provisioning infrastructure บน Cloud provider
ด้วยภาษา Go

การเรียกกันข้าม service ผ่านระบบ network
ซึ่งก่อนนี้จะเป็นแบบเรียก functiom/method
ทำให้เกิดปัญหาใหม่ ๆ ขึ้นมา เช่น

• Error handling
• Monitoring
• Circuit breaker
• Rate limit
• Request tracing
• API versioning
• Service-to-service security
• Authorization
• Integration test

ซึ่งหลาย ๆ อย่างมักจะทำการ copy-and-paste กันในแต่ละ service
ดังนั้นทีมจึงทำการสร้าง Twirp framework มาใช้งาน
สำหรับ service-to-service communication

ในตอนนี้จะใช้ภาษาโปรแกรมเยอะ

แยกตามไปแต่ละส่วนงาน
เช่น Go, TypeScript, Python, C++, Java/Kotlin และ ObjectiveC/Swift
และแต่ละทีมก็มี account สำหรับ Cloud provider แยกกัน
ส่งผลให้แต่ละส่วนงานมีความเป็นอิสระมากขึ้น
แต่ละทีมสามารถเข้ามา contribute ได้เลย

และเมื่อทีมแข็งแรงขึ้น จะเริ่มเกิด standard ต่าง ๆ ขึ้นมา
เกิด framework ต่าง ๆ ขึ้นมา
เกิด tool ต่าง ๆ ขึ้นมา
เพื่อช่วยให้การพัฒนา deployment และ operation มีประสิทธิภาพที่ดีขึ้น

พอดีต้องทำงานกับ Vector Database ทั้ง
Pinecone, Milvus, Redis, Elasticsearch และ pgvector
เกิดคำถามว่าคืออะไร ทำงานอะไรได้บ้าง
เนื่องจากปกติ NoSQL จะรู้จักแค่ key-value, column, document และ graph
พอมาเจอ Vector ก็เลยงง ๆ
ดังนั้นทำความรู้จักกันหน่อย

เนื่องจากระบบมีความซับซ้อนมากยิ่งขึ้น
ข้อมูลก็มีหลายหลายชนิด (Variety)
ทั้ง structure และ unstructure
ทำให้การจัดการยากลำบากมากขึ้น

ในโลกของ Machine Learning (ML) ก็มีแนวคิดในการจัดการข้อมูลที่ซับซ้อน
ด้วยการแปลงหรือ transform ข้อมูลในรูปแบบของ vector embedding
ซึ่งนำเสนอในรูปแบบของตัวเลขในมิติต่าง ๆ

จากนั้นก็ต้องทำเก็บข้อมูลเหล่านี้ไว้ใน database
เพื่อให้สามารถนำไปใช้งานได้ต่อไป

ช่วยจะทำการสร้าง index ไว้ให้
ทำให้การค้นหา หรือ similarity search ได้ดีขึ้น
การทำ CRUD ได้อยู่แล้ว
การ filter หรือ กรองข้อมูลมีประสิทธิภาพสูง
ง่ายต่อการ scale แบบเพิ่มเครื่อง หรือ Horizontal scaling

โดย use case ของ Vector embedding นั้นมีเยอะ เช่น

• Semantic search
• Similarity search เช่น รูปภาพ เสียง VDO หรือ JSON
• ทำระบบ ranking หรือ คำแนะนำต่าง ๆ
• การตรวจสอบ duplication ของข้อมูล หรือ การตรวจลิขสิทธิ์

เป็นอีก database model ที่น่าสนใจมาก ๆ
และจำเป็นต้องรู้และเข้าใจ

Reference Websites

• Tutorial: ChatGPT Over Your Data
• What is a Vector Database ?
• What are Vector Embeddings ?

และแล้วก็มาสำหรับ API performance testing จาก Postman
ช่วยให้เราสามารถทำ performance testing ของ API ได้เลย
ไม่ต้องไปใช้เครื่องมืออื่น ๆ
ทำให้ ecosystem ใหญ่ขึ้นอีกแล้ว

โดยที่จะมีความสามารถพื้นฐานต่าง ๆ ดังนี้

• ทำการสร้าง Virtual User (VU) ขึ้นมา เพื่อจำลองผู้ใช้งานขึ้นมา และมีการแสดงรูปแบบของการสร้าง VU ให้ดูแบบง่าย ๆ
• สามารถทดสอบ และดูผลการทดสอบในมุมมองต่าง ๆ เช่น response time, error rate และ request per second เป็นต้น เหมือนกับ Apache JMeter เลย

แต่ก่อนใช้งาน ต้องไปลงชื่อเพื่อเข้าคิวขอใช้งานกันได้เลย ที่นี่

Vercel ได้ปล่อย Vercel storage มาให้ลองใช้งาน (Beta version)
ลงชื่อใน waiting list ได้
ออกแบบมาสำหรับ web application เลย (JavaScript และ TypeScript)
โดยประกอบไปด้วย

• Vercel KV (Key-value) คือ severless Redis อยู่บน Upstash
• Vercel Postgres (Relational) คือ serverless PostgreSQL อยู่บน Neon
• Vercel Blob (Binary) สำหรับ upload และ serve file ต่าง ๆ ผ่าน Cloudflare R2

ทำให้การพัฒนา web frontend ได้ง่ายขึ้นมาก ๆ (open, easy และ scale)
ทั้งการอ่านเขียนข้อมูลจาก database และ file ต่าง ๆ
ไปลงชทาอใช้งานกันครับ
ไว้กลับมา review กันต่อหลังได้การ approve แล้ว !!

สามารถดู VDO แนะนำได้ที่นี่

Reference Websites

• Vercel Storage (KV, SQL, Blob): first impressions

ทาง Microsoft ทำการ fork React Native
ที่สามารถพัฒนา mobile app และ windows app ด้วย JavaScript + ReactJS
มาเพิ่มความสามารถคือ สร้าง macOS app ได้ด้วย
โดยที่ทำอยู่บน React Native 0.71

สิ่งที่ Microsoft เลือกที่พัฒนาคือ การแยกออกมาทำสำหรับ MacOS เลย
เนื่องจาก code เดิมที่ทำงานบน iOS นั้น สามารถมาเป็น MacOS ได้
แต่เพิ่มขึ้นตอนให้ซับซ้อนขึ้น
ยากต่อการดูแลรักษามาก ๆ หรือ การเพิ่ม feature ใหม่ก็ยาก
เลยแยกออกมาทำโดยเฉพาะเลยดีกว่า

โดยใน release นี้เป็นเพียง experiment preview version เท่านั้น
แน่นอนว่ายังเป็นเพียงการทำ Proof of concept เท่านั้น ซึ่งยังไม่ stable

การใช้งานกำหนเ flag ต่าง ๆ เหมือนกับ iOS เลย

ใครที่สนใจสามารถเข้าไปได้ที่ GitHub

Reference จาก Twitter

เนื่องจากได้ใช้งาน ChatGPT ในงานมาพอสมควร
ทั้งในมุมมองของ Prompt Engineering
ทั้งในมุมมองของการขยายความสามารถด้วยการ coding
เพื่อช่วยให้เราทำงานได้ง่าย และ เฉพาะเจาะจงง่ายขึ้น
ด้วยการใช้งานผ่าน Library ชื่อ LangChain + Python
จึงทำการสรุปสิ่งที่แบ่งปันไว้นิดหน่อย

เริ่มด้วยคำถามว่า เราได้นำ ChatGPT ไปใช้งานของเราบ้างหรือยัง ?

• ถ้ายังไม่ใช้ จงเรียนรู้ที่จะใช้
• ถ้าใช้แล้ว เราใช้ทำอะไรบ้าง มีอะไรบ้างที่ใช้งาน มีเทคนิคอะไรบ้างที่น่าสนใจ

ในส่วนนี้จะเป็นเรื่องของ Prompt Engineering มาก

โดยมากแล้วเรื่องนี้ถูกประยุกต์ใช้งานเยอะมาก ๆ ในแต่ละวงการ
ยิ่งสายการพัฒนา software สามารถทำมาใช้งานได้หลายหลายสุด เช่น

• การ generate code
• การอธิบาย code
• การทดสอบ code
• การ debug code
• การปรับปรุง หรือ refactoring code

ใน community การใช้งาน ChatGPT นั้น ก็มีคำแนะนำ
สำหรับรูปแบบการของพูดคุยว่าควรต้องมีรูปแบบไหนบ้าง
ยกตัวอย่างเช่น

ซึ่งมีหลายสำนัก หลายรูปแบบ ให้ลองเรียนรู้ และ ลองนำไปใช้งาน
เพื่อดูว่าแบบไหนที่เราชอบ และได้ผลตามที่ต้องการ

หรือไปดูตามที่ต่าง ๆ ดังนี้

• Best Practice for Prompt engineering
• Awesome ChatGPT prompts
• Awesome Prompt engineering

หรือสามารถดูเพิ่มเติมได้ในเรื่อง AI-aided test-first development
เป็นอีกหนึ่งรูปแบบการนำมาใช้งานสำหรับการพัฒนา software
ตั้งแต่ requirement ไปจนถึงการ coding และ ทดสอบ

หรือสาย Data Analysis ก็สามารถใช้งานได้เช่นกัน

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

• Analyzing Data Made Effortless Using ChatGPT

แต่เมื่อข้อมูลใหญ่ขึ้นจะใช้ไม่ได้ผ่าน ChatGPT แล้ว
เพราะว่ามีจำนวน data หรือ token จำกัด
สามารถตรวจสอบจำนวน token ได้ที่ OpenAI Tokenizer

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

เพื่อส่งไปยัง OpenAI ผ่าน API นั่นเอง (จำเป็นต้องมี API Key)
โดย library ที่นิยมใช้งานและช่วยจัดการข้อมูลต่าง ๆ
รวมทั้งการพูดคุยแบบง่ายผ่าน library ชื่อว่า LangChain นั่นเอง

ใน LangChain ใช้งานง่าย รวมทั้งมี use case ต่าง ๆ ให้เป็นตัวอย่างด้วย
เช่น

• Agents ต่าง ๆ
• ตอบคำถามต่าง ๆ จากเอกสารของเรา เช่น user manual เป็นต้น
• Chatbot
• ให้คำแนะนำแบบส่วนตัว

แน่นอนว่าต้องการ coding skill มากขึ้น
แต่ก็ทำให้เราสร้างระบบงานได้ง่ายขึ้น
นำข้อมูลที่เราต้องการมาใช้งานได้ง่าย
แสดงตัวอย่างระบบถามตอบดังรูป

ตัวอย่างง่าย ๆ เช่น การอ่าน user manual จาก PDF ที่มีขนาดใหญ่เขามาทำ index ซะ
ซึ่งเป็น embedding vector นั่นเอง
จะเก็บไว้แบบ local หรือ vector database ก็ได้

จากนั้นก็ถามสิรออะไร !!

เพียงเท่านี้เราก็สามารถนำไปต่อยอดใช้งานได้อีกมากมายแล้ว
ต่อจากนี้ก็คือ การเรียนรู้ต่อไป

จากงานเดิมใช้งาน RediSearch เกี่ยวการค้นหาข้อมูล (Full text search) ไปแล้ว
ต่อมามี use case ต้องทำการค้นหาข้อมูล Geolocation (lat,lng) นั่นเอง
โดยมีความต้องการดังนี้

• ยังค้นหาแบบ full text search ในข้อมูลจาก property ต่าง ๆ ได้
• หาข้อมูลที่อยู่ใกล้
• เรียงลำดับจากใกล้ไปไกลได้
• กำหนดจำนวนข้อมูลที่ต้องการ

มาดูกันว่าทำอย่างไรได้บ้างใน Redis นั่นเอง

ขั้นตอนการออกแบบและทดลองใน Redis เป็นดังนี้

ขั้นตอนที่ 1 ทำการเตรียมข้อมูลที่ต้องการค้นหา

ประกอบไปด้วย property ต่าง ๆ ที่ต้องการเก็บเพื่อค้นหา และ กรองข้อมูล
รวมทั้งข้อมูล location (lat, lng) นั่นเอง
แต่ใน Redis + GEO type นั้นเป็น lng, lat นะ ตรงนี้ต้องระวัง

ในส่วนนี้เก็บข้อมูลในรูปแบบของ HASH ดังนี้

ขั้นตอนที่ 2 ทำการสร้าง index เพื่อทำการค้นหา

ขั้นตอนที่ 3 ทำการค้นหาผ่าน FT.SEARCH

ตรงนี้จะซับซ้อนขึ้นมาหน่อย เนื่องจากต้องการ

• ค้นหา location ที่อยู่ในระยะทางที่ต้องการ
• ทำการเรียงลำดับตามระยะทางได้ด้วย

เพียงเท่านี้ก็ใช้งาน RediSearch สำหรับ use case นี้ได้แล้ว