มาดูความสามารถที่น่าสนใจใน Apache Airflow 2.10 ที่เพิ่งปล่อยออกมา
ประกอบไปด้วย

• Hybrid Execution หรือ multiple executor configuration
• Dynamic Dataset Definition
• ปรับปรุง User Interface
• เพิ่ม operator ใหม่ ๆ มีดังนี้ PythonOperator, TaskFlow API และ Object storage API

มาดูรายละเอียดกันนิดหน่อย

เรื่องแรกคือ Hybrid Execution หรือ multiple executor configuration

จากเดิมที่ Airflow นั้น เราสามารถกำหนดได้เพียง executor ชนิดเดียวเท่านั้น
ทำให้เกิดปัญหา หรือ ข้อจำกัดว่า
เรามี task ที่แตกต่างกัน และมี executor ที่เหมาะสมต่างกันไป
แต่กำหนดได้เพียงชนิดเดียวเท่านั้น !!

ดังนั้นใน version นี้สามารถกำหนด executor ให้แต่ละ task ได้เลย
ช่วยให้การใช้งานยืดหยุ่น และ มีประสิทธิภาพที่ดีขึ้น

เรื่องที่สอง Dynamic Dataset ด้วยการใช้ alias

นั่นคือ DataSetAlias สามารถส่งผ่าน outlet และ inlet ของ task และ scheule ต่าง ๆ ใน DAG ได้
โดยจะทำ resolve แบบ dynamic ตอน runtime
ช่วยทำให้ไม่ผูกติดกับ dataset มากเกินไป

อีกอย่างในส่วนของ User Interface นั้น dependency graph ของ DataSet ถูกแยกมาเป็น tab ใหม่

ลองทำการ upgrade และใช้งานกันดู
อย่าปล่อยให้ระบบมันกลายเป็น legacy ละครับ !!

Reference Websites

• Introducing Apache Airflow 2.10

ปัญหาที่พบเจอกับระบบงานง่าย ๆ ที่พัฒนาด้วยภาษา Go เป็นดังนี้

• ระบบทำการดึงข้อมูลจาก MySQL database
• เป็นการดึงข้อมูลมาจาก 2 table และแยก query กัน (table แรกได้ id, table สองได้ detail)
• มีการใช้งาน connection pool

ปัญหาคือ เมื่อมี load จำนวนมากเกินกว่า max connection ใน connectio pool
จึงทำให้เกิด timeout ในการดึงข้อมูลขึ้นมา
จะแก้ไขอย่างไรดี ?

แนวทางการแก้ไขมีหลายวิธีการ

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

• เพิ่ม max connection ใน connection pool ไปสิ (ทำได้ง่ายสุด ๆ แต่มีข้อจำกัดที่ database)
• แทนที่จะดึงแยกกัน 2 query หรือ 2 ครั้ง ทำไมไม่ใน query เดียวไปเลย ใช้การ join นั่นเอง
• ในกรณีนี้ ถ้าทำ pre-join data ไว้ก่อนก็ทำได้นะ เนื่องจากเป็นการดึง detail ของผู้ใช้งานในแต่ละ comment นั่นเอง
• ถ้ายังจะใช้ 2 query เหมือนเดิม ดังนั้นก็ต้องเข้าไป review code กันหน่อย
• ถ้าข้อมูลไม่ค่อยเปลี่ยนแปลง ก็ทำ caching ซะ น่าจะดีกว่า

จากที่แก้ไขมา ทุกแนวทางใช้ได้หมดเลย
นั่นหมายความว่า หนึ่งปัญหามันมีหลายวิธีในการแก้ไขนั่นเอง

แต่จากการ review code แล้วพบสิ่งที่น่าสนใจ
มาดูกันว่าเป็นอย่างไร

เริ่มจาก code เดิม ก็ทำการ load test ง่าย ๆ ก่อน

จะเห็นได้ว่าเกิด timeout ทั้งหมดเลย
เนื่องจากจำนวน concurrent user 50 ซึ่งมากกว่า max connection ใน connection pool นั่นเอง

แก้ไขด้วยการเพิ่ม max connection ก็เสร็จ แต่มันไม่ใช่ root cause !!
ดังนั้นไป review code กันหน่อย
สิ่งที่เจอคือ

ปัญหาคืออะไร ?

• สิ่งที่เจอคือ เป็นการวน loop ของข้อมูล rows.Next()
• ยังไม่พอ ใน loop มีการดึงข้อมูล user ของแต่ละคนอีก

ส่งผลให้ไม่ทำการคืน connection กลับไปยัง pool สักที
ดังนั้นเมื่อนักพัฒนาทดสอบคนเดียว ไม่มีทางเจอ
แต่เมื่อทำ load test ในจำนวนคนใช้งานมากขึ้น
จึงทำให้เกิดปัญหา
ดังนั้นการแก้ไขที่จุดเกิดเหตุคือ เปลี่ยน flow ของ code ซะ
ให้ทำการดึงข้อมูล list comment เสร็จแล้ว และคืน conenction ไปที่ connection pool
จากนั้นจึงทำการดึงข้อมูลของ user อีกที ดังนี้

ก็เร็วขึ้นอยู่นะ
มีหลายวิธีการให้แก้ไข สนุกดีนะครับ

Bun 1.1.25 เพิ่มปล่อยออกมานั้น สนับสนุน node:cluster แล้ว
ดังนั้นสามารถ start process การทำงานตามจำนวน core CPU ได้แบบง่าย ๆ
และ Bun worker ย่อย ๆ สามารถใช้งาน port เดียวกันได้เลย
แถมยังช่วยเพิ่มประสิทธิภาพการทำงานของระบบอีกด้วย

ดังนั้นมาลองสร้าง Web server ง่าย ๆ กันหน่อย

จากนั้นทำการ run

และทดสอบระบบด้วย Ohayou

ซึ่งผลการทดสอบดีเลย
ลองใช้งานกันดูครับ สำหรับ Bun

ในการทดสอบระบบที่พัฒนาด้วย Flutter นั้น
ใน official website นั้นจะมีคำแนะนำดังนี้ (เรียกว่า internal testing)

• Unit test
• Widget test
• Integration test

รวมทั้งสามารถทดสอบผ่าน Appium + flutter driver ได้เช่นกัน
ซึ่งแบบหลังผมมักจะเรียกว่า external testing (มุมมองจากคนภายนอก หรือ คนใช้งาน)

จะพบว่าเครื่องมือที่มีอยู่นั้น ก็สามารถใช้งานได้ดี
แต่อาจจะติดขัดเรื่องต่าง ๆ ที่ไม่สะดวกนัก
ดังนั้น Patrol จึงสร้างขึ้นมา ซึ่ง on-top บน testing framework เดิมของ Flutter
ซึ่งเป็น plugin ที่สร้างอยู่บน integration_test นั่นเอง
ดังนั้นเรื่องของ compattible จึงสบายใจได้ !!

โดยความสามารถหลัก ๆ ของ Patrol มีดังนี้

• การเข้าถึง native feature ของแต่ละ platform ที่แตกต่างกัน เช่น permission, notification, app state และ การเปิดปิดการทำงานของ feature ต่าง ๆ เพื่อให้ง่ายต่อการทดสอบในสถานการณ์ต่าง ๆ
• การเข้าถึงแต่ละ element ที่ง่ายขึ้น เขียน code น้อยลง

• ยังมี Hot restart ให้อีกด้วย
• ถ้ามี test case เยอะ ๆ ก็สามารถจัดกลุ่มของ test case เพื่อให้ทดสอบได้ดีขึ้น

ลองใช้งานกันดูครับ
สำหรับการทดสอบระบบที่พัฒนาด้วย Flutter
จะได้ประสบการณ์ที่ดีขึ้นแน่นอน

จากการแบ่งปันเรื่องของ Software Architecture ทั้ง Monolith, SOA และ Microservice นั้น
คำถามที่เจอบ่อย ๆ คือ การจัดการให้ service หนึ่ง ๆ เป็น module/component ให้มันดีก่อน
แต่เมื่อมีการติดต่อสื่อสารกันระหว่าง module แล้ว
จะจัดการ หรือ เลือกแนวทางไหนดี
หนึ่งในแนวทางที่เคยอธิบายไว้แล้วคือ ผ่านตัวกลาง หรือ การติดต่อแบบ indect

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

แบบที่ 1 เรียกกันตรง ๆ ไปเลย

โดยปกติก็ reference ผ่าน code ตรง ๆ ไปเลย
แต่ผลที่ตามมาคือ แต่ละ module ผู้มัดกันไปหมดเลย
หาขอบเขตได้ยากมาก ๆ

ดังนั้นถ้าเรียกตรง ๆ แบบนี้ ต้องจัดการให้ดี
เช่น การสร้าง public interface ของ module นั้น ๆ ขึ้นมา
ถ้าหลักการของ design pattern จะเรียกว่า facade pattern

หรือบ่อยครั้งจะเห็นว่า ติดต่อผ่านระบบ network กันไปเลย
นั่นคือ แต่ละ module ทำงานอยู่ต่าง process กัน
เช่นการติดต่อผ่าน HTTP protocol เป็นต้น
อาจะใช้รูปแบบของ RESTFul API และ gRPC เป็นต้น
แต่ต้องระวังด้วย เพราะว่าการติดต่อผ่านระบบ network มันพร้อมพังมาก ๆ
ต้องระมัดระวังให้ดี
Plan for fail ต้องมาแล้วนะ

แบบที่สอง แบบไม่เรียกตรง ๆ (indirect) หรือ มีคนกลางนั่นเอง

เป็นเหมือนการเพิ่ม hop เข้ามา เช่น

• Gateway ตรงกลาง
• Event-based ผ่าน memory, messaging server
• File system แล้วสร้าง batch process มาทำงานตามเวลาที่เราต้องการ

แน่นอนว่า วิธีการนี้ทำให้แต่ละ module ผูกมัดกันน้อยลง
แต่ความซับซ้อนก็สูงขึ้นเช่นเดียวกัน
ก็ต้องระมัดระวังเช่นเดียวกัน

ลองดูว่า การติดต่อสื่อสารระหว่าง module ของระบบงานควรเป็นอย่างไร
เลือกให้เหมาะสมกับงาน คน เวลา
ขอให้สนุกกับการ coding ครับ

หลังจากที่ Kafka 3.8 ปล่อยมาให้ใช้งานนั้น
มี JBOD (Just a Bunch Of Disks) ซึ่งสนับสนุน KRaft-based cluster นั้น
เปลี่ยนสถานะมาเป็น production mode แล้ว
ทำให้สามารถแยก log ของแต่ละ broker ออกจากกันได้แล้ว
ไม่ต้องเก็บ log ไว้ที่เดียวกันอีกต่อไป
และยังแยก storage ให้เหมาะกับแต่ละ broker ในแต่ละเครื่องได้อีกด้วย

รวมไปถึงเรื่องของการ compress level ข้อมูลแยกตาม
Broker, producer และ topic ได้
ซึ่งจะมี gzip, lz4, และ zstd codec ให้ใช้งาน
ส่วน snappy codec นั้น deprecated ไปแล้ว

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

• ZooKeeper ถูก deprecate ตั้งแต่ Kafka 3.5 และจะถูกเอาออกไปใน version 4.0
• Kafka 3.6 นั้นให้ KRaft-based cluster เป็น production mode แล้ว
• มี Docker image แบบ official ให้แล้ว มีทั้ง JVM-based และ GraallVM หรือ native ให้ใช้งาน มีทั้งแบบแยกหรือรวม controller กับ broker ให้เลือก

กับเรื่องของ Consumer Rebalance Protocol (CRP) ตัวใหม่
ที่พยายามลดความซับซ้อน และผลกระทบต่อ consumer จากการเปลี่ยนแปลง rebalance algorithm อีกด้วย
เข้าสูสถานะ preview แล้ว ไว้รอทดสอบกันดู

ทำการ update cluster กันครับ

Reference Websites

• Introducing Apache Kafka® 3.8
• KIP-975: Docker Image for Apache Kafka

พอดีกำลังลองใช้งาน Gateway API ใน Kubernetes cluster
มีคำถามที่ต้องหาคำตอบหน่อยคือ
ถ้าต้องการแปลงจาก Ingress ไปยัง Gateway API แบบง่าย ๆ บ้างไหม
ไปเจอเครื่องมือจาก IngressToGateway
ซึ่งน่าสนใจดี ดังนั้นมาลองใช้งานกันหน่อย

Gateway API จะมี resource ต่าง ๆ ดังนี้

• GatewayClasses
• Gateways
• Routes -> HTTPRoute, TCPRoute, TLSRoute, UDPRoute

แสดงดังรูป

ตัว IngressToGateway นั้นจะสนับสนุน provider ต่าง ๆ ดังนี้

• Ingress NGINX
• Kong
• APISIX
• Istio
• GCE
• OpenAPI

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

ลองทำการแปลงจาก Ingress NGINX กันหน่อย

ไฟล์ Ingress ที่ใช้งาน

จากนั้นลองทำการแปลงและแสดงผลของ Gateway API มาใช้ดังนี้

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

นั่งอ่าน paper เรื่อง Refactoring vs Refuctoring
กับการนำ LLM (Large Language Model) เข้ามาใช้ว่าเป็นอย่างไร ?
ในการ generate code และ การปรับปรุงโครงสร้างของ code (Refactoring)
ซึ่งใน paper นี้จะช่วยแสดงให้เห็นว่าการทำงานเป็นอย่างไร
มีข้อจำกัดอะไรบ้าง
ผลที่ได้มีความน่าเชื่อถืออย่างไร
มีความผิดพลาดอย่างไรบ้าง
มาดูกัน

จากการทดลองในงานจริง ๆ ใน paper นั้นบอกไว้ว่า

• หลังจากที่ให้ AI ทำการ refactor code แล้วนั้น มีเพียง 37% ที่ทำให้ code ไม่พัง หรือ ทำงานได้เช่นเดิม
• เมื่อ refactoring ผ่านแล้วพบว่า code ถูกปรับปรุงจริง ๆ มีความน่าเชื่อถือสูง ทั้งจากคนและเครื่องมือ ซึ่งช่วยลดงานลงไปได้เยอะมาก ๆ และลด technical debt ลงไป

โดย metric ที่ใช้ในการวัดคุณภาพของ code ที่ generate ออกมา
ใช้งาน Code Health Metric ของ CodeSense

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

ปล. ส่วน GPT-4o ยังไม่ได้ทดสอบในตอนนั้น

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

• ไม่สนใจพวก branch condition ต่าง ๆ หรือ if-else ซึ่งทำให้เกิด bug ขึ้นได้ เช่นการ validate input เป็นต้น
• Invert boolean condition
• การ refactoring code ด้วยการแยกเงื่อนไขที่ซับซ้อนใน function ไปยัง function ย่อย ๆ ก่อให้เกิด bug ได้เช่น

ดังนั้นก็ต้องระมัดระวังอย่างมาก ๆ
เรื่องของผู้ช่วยนั้นดี แต่ความไว้ใจนั่นอาจจะไม่ ต้องตรวจสอบอยู่เสมอ
เครื่องมือดี แต่ต้องระมัดระวัง

อีกอย่างคือ ขั้นตอนในการตรวจสอบคุณภาพของ code ที่ refactor มานั้น

จะมีขั้นตอนดังนี้

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

Reference เรื่อง Refuctoring

สองวันที่ผ่านมามีโอกาสในการแบ่งปัน
เรื่องการนำ Generative AI มาใช้ในการพัฒนา software
ตั้งแต่การคิด ออกแบบ พัฒนา ทดสอบ และ ส่งมอบงาน
โดยหนึ่งในเครื่องมือที่แนะนำและทำ workshop ไปคือ Aider

โดยอธิบายว่ามันคือ
Aider is AI pair programming in your terminal

Pair programming น่าสนใจมาก ๆ
ผ่านทาง command line กันเลย ทั้งการ

• Generate code ทั้ง production และ test
• Refactor code
• Debug code
• อธิบาย code
• ทำการ run เพื่อทดสอบ
• จัดการเรื่อง commit ใน git ให้เลย

การทำงานของ Aider นั้นจะทำงานร่วมกับ LLM provider ที่ต่าง ๆ เช่น

• OpenAI
• Antropic
• Ollama
• DeepSeek

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

เริ่มจากการติดตั้งและ config นิดหน่อย

ถ้า project ของเรายังไม่อยู่ใน git repository ก็จะสร้างให้เลย

จากนั้นก็เริ่มใช้งานกันเลย
เช่น ต้องการสร้างไฟล์ index.js สำหรับสร้าง REST API ด้วย NodeJS และ express library กันหน่อย

ก่อนจะทำงานใด ๆ Aider จะทำการสรุปขั้นตอนการทำงานก่อนว่าต้องทำอะไรบ้าง เช่น

• การสร้าง project
• ติดตั้ง library
• เขียน code
• สร้าง route

จากนั้นทำการสร้างไฟล์ที่ต้องการ และทำการ add และ commit ให้เลย
แถม commit message ไปรูปแบบ Conventional Commits

สิ่งที่ Aider ไม่ได้ทำให้คือ การสร้าง หรือ initial project ให้ เราต้องทำเอง
ติดตั้ง library ต่าง ๆ เอง
รวมทั้งเก็บ hisotry ของการทำงานตั้งแต่เริ่มไว้ให้ด้วย

ช่วยทำงานในหลาย ๆ เรื่องให้นักพัฒนา
ซึ่งน่าสนใจมาก ๆ ลองเล่นกันดู
มีความสามารถอีกมาก ลองใช้งานกันครับ

หลาย ๆ คนที่ใช้ Claude AI อยู่ น่าจะใช้งาน feature Artifacts กันหมดแล้ว
เพราะว่าไม่ได้อยู่ใน preview feature อีกต่อไปแล้ว
ซึ่งจะทำการแสดงผลหรือ preview ข้อมูลต่าง ๆ ออกมาให้เห็นเลย เช่น

• Developer จะแสดง architecture diagram จาก code
• Designer จะแสดง prototype ออกมาเป็นรูป หรือ visualize ให้เลย
• Product สามารถสร้าง interactive prototype ให้ได้เลย เพื่อทดลองหรือใช้ feature นั้น ๆ

ซึ่งอำนวยความสะดวกอย่างมาก
แถมเราสามารถ chat เพื่อปรับปรุงส่วนต่าง ๆ หรือ ให้อธิบายส่วนต่าง ๆ ได้อีกด้วย

แต่สิ่งที่ผมสนใจคือ How Anthropic built Artifacts
ทีมงานพัฒนา feature กันอย่างไร มีแนวคิดอย่างไรบ้าง ?

จากบทความสรปสั้น ๆ ไว้ว่า ใช้เวลาในการพัฒนา feature นี้ภายใน 3 เดือน !!

แบ่งเป็นหัวข้อต่าง ๆ ดังนี้

1. From the drawing board to shipping Artifacts

เริ่มจากการใช้งานผ่าน ClaudeAI ของตัวเอง ที่เพื่อปล่อง model ตัวใหม่ออกมา
จากนั้นใส่ prompt เข้าไป ได้รับ HTML ออกมา
จากนั้นก็ copy ไปใน Editor เพื่อบันทึกลงไฟล์ HTML
จากนั้นก็เปิดใน web browser เพื่อดูผล
ทำแบบนี้วนไป

จากแนวคิดแบบนี้ ก็เริ่มเกิดเป็น prototype ภายในของบริษัท
มีการ pitch product ภายในขึ้นมา

เมื่อทุกอย่างผ่านแล้ว ก็เริ่มลงมือพัฒนาภายในเพื่อทดลองประมาณ 1-2 สัปดาห์
โดยสิ่งที่ทำให้น่าสนใจมาก ๆ คือ การลองสร้าง Game 8 Bit ออกมา

2. Tech stack

ในช่วงแรกของการทำ prototype จะใช้งาน Streamlit เจ้าเดิม
ซึ่งพัฒนาด้วยภาษา Python นั่นเอง
ช่วยให้การสร้าง prototype เร็วมาก

ใน version ต่อมาเริ่มพัฒนาเป็นระบบจริง ๆ ด้วย NodeJS
ฝั่ง frontend พัฒนาด้วย React + Next.js และ Tailwind CSS

ในการพัฒนาจะต้องระมักระวังเรื่องของ security มาก ๆ
เพราะว่า ต้องทำการแสดงผลจาก code ที่อาจจะมีปัญหาก็เป็นไปได้
จึงใช้งาน iFrame sandboxes with full-site process isolation
และใช้งาน strict Content Security Policies (CSPs) อีกด้วย

3. Using Claude to build Artifacts faster

ในการพัฒนาก็ใช้งาน ClaudeAI เพื่อช่วยพัฒนานั่นเอง
เป็นการทดสอบ product ของตัวเองไปในตัว

เป็นแนวทางที่น่าสนใจมาก ๆ
ลองอ่านเพิ่มเติมกันได้ครับ
สำหรับแนวคิด แนวทาง ของการสร้าง product/feature หนึ่ง ๆ ออกมา

ว่าง ๆ มาทำความรู้จักกับ Semantic Kernel จาก Microsoft กันหน่อย
ซึ่งเป็นชุดเครื่องมือช่วยในการพัฒนา (SDK = Software Development Kit)
และสร้าง AI Agent และ multiple agent แบบ open source ด้วย
สามารถทำงานร่วมกับ AI model ต่าง ๆ จาก provider ต่าง ๆ ได้เลย
เช่น OpenAI, Azure OpenAI และ Ollama
เขียน code ได้ทั้ง C#, Python และ Java
ดังนั้นเรามาลองใช้งานกันหน่อย

โดยที่ Semantic Kernel นั้นแยกการทำงานเป็น component ต่าง ๆ ดังนี้

• Kernel เป็นส่วนหลักของ SDK เพื่อนำแต่ละ component มาทำงานร่วมกัน โดยจะมีการจัดการ log และ telemetry ต่าง ๆ ในการ observe การทำงานของ Agent ที่สร้าง เพื่อปรับปรุงการทำงานต่อไป
• Memory ทำการจัดเก็บ history data ต่าง ๆ เอาไว้ เหมือนความจำของมนุษย์นั้นเอง เก็บได้ทั้งรูปแบบ vector, key-vale และจัดเก็บลงหน่วยความจำ database หรือ file system ก็ได้
• Planner เป็นส่วนของการวางแผนจาก user prompt ว่าจะต้องทำงานอะไรบ้าง ซึ่งมีการเตรียมไว้ให้แล้วด้วย เช่น SequencialPlanner, BasicPlanner และ ActionPlanner เป็นต้น
• Connector เป็นส่วนที่ให้แต่ละ component ทำการเชื่อมต่อ และ แลกเปลี่ยนข้อมูลกัน ทั้ง database ในรูปแบบต่าง ๆ และ AI model จาก provider ต่าง ๆ ในส่วนของ ventor database ตอนนี้ยังคงเป็น experiment feature เท่านั้น
• Plugin หรือ Skill ที่สามารถเพิ่มเติมได้ตามที่ต้องการ

เริ่มด้วยการเขียน code ด้วย C# เล่น ๆ ดีกว่า
เป็น code ตัวอย่างจากเอกสารของ Semantic Kernel นั่นเอง

ขั้นตอนที่ 1 สร้าง Project

ขั้นตอนที่ 2 สร้างระบบงานตัวอย่าง เป็นการเปิดปิดไฟนั่นเอง

โดยจะใช้งานผ่าน OpenAI API มีขั้นตอนดังนี้

• ทำการ Connect ไปยัง OpenAI API ใช้งาน gpt-4o model อย่าลืมใส่ API KEY
• ทำการสร้าง Kernel ซึ่งเราจะสร้างเป็น chat app
• ทำการเพิ่ม plugin เข้ามา คือ LightsPlugin ที่จะสร้างเอง
• ทำการเปิด planner โดยใช้แบบ auto
• ทำการเก็บ history data
• เริ่มคุย ...

ไฟล์ Program.cs

จากนั้นทำการสร้าง LightsPlugin.cs ขึ้นมา

โดยจะมีไฟอยู่ 3 ดวง

จากนั้นลอง run ดู

ลอง run แบบเปิด log ดูหน่อยสิ ว่าตัว Kernel มันทำอะไรบ้าง ?

ลองใช้งานกันดูครับ มีอะไรน่าสนใจเยอะเลย
และเหมือนจะไปทำงานร่วมกับ AutoGen ได้ด้วยนะ

ส่วนใน VSCode นั้นก็มี extension ให้ด้วย ลองใช้งานกันดู
และเข้าไปดู code ต่าง ๆ เพิ่มเติมได้ที่ GitHub :: Semantic Kernel

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

Source Code ตัวอย่างที่ GitHub:Up1

นั่งดูการสัมภาษณ์เรื่อง Scaling Rails & Postgres to Millions of Users at Microsoft: Lessons & Takeaways
ซึ่งเป็นผู้เขียนหนังสือ High Performance PostgreSQL for Rails

เล่าถึงประสบการณ์ในการพัฒนาระบบงานด้วย Rails
และการ scale PostgreSQL database
เพื่อรองรับการใช้งานของผู้ใช้งานจำนวนมาก
ทั้งการ monitoring และระบบที่ซับซ้อน
มาดูว่ามีเรื่องอะไรที่น่าสนใจบ้าง ?

ในการพัฒนาระบบงาน monolithic ด้วย Rails นั้น

ช่วยให้นักพัฒนาไม่ต้องไปสนใจการจัดการ database มากนัก
เพราะว่าใช้งานผ่าน Active Record ไปเลย
ทำให้การพัฒนามีความ productive สูงมาก
แต่เมื่อมีคนใช้งานมากขึ้น เกิด concurrency มากขึ้น มีการเปลี่ยนแปลงมากยิ่งขึ้น
จึงทำให้เราต้องเข้ามาทำความเข้าใจมากยิ่งขึ้น
ว่า Active Record มันทำงานอย่างไร

จากเดิมรูปแบบของทีมไม่ได้แบ่งเป็นตำแหน่งที่ชัดเจน
ทุกคนช่วยดูแลทั้งหมด
เมื่อเกิดปัญหาที่ database ขึ้นมา
ทีม developer จำเป็นต้องเข้ามาจัดการและ tuning database
ว่า code ที่ตัวเองเขียนนั่น สร้างปัญหาอะไร และจะแก้อย่างไร ?

แนวทางในการจัดการเรื่อง Architecture และ Database หลัก ๆ เป็นดังนี้

• เริ่มดูว่าระบบงานมีอัตราการ read และ write เป็นอย่างไร เพื่อแบ่งกลุ่มของงาน เช่น content, comment และ like เป็นต้น
• PostgreSQL มีข้อดีด้วยการการันตีความถูกต้อง เมื่อเกิด concurrency แต่ก็แลกมาด้วย overhead ด้าน performance ที่สูงเช่นกัน
• สร้างความเข้าใจให้ application developer เข้าใจเกี่ยวกับ database performance ว่าสิ่งที่สร้างขึ้นมานั้น ส่งผลต่อการทำงานของ database อย่างไร เพื่อจะไม่เลือกแนวทางที่แย่เข้ามาในระบบงาน
• เมื่อมี traffic เข้ามาเยอะ ๆ จะเริ่มเกิดการแบ่ง traffic ออกตามรูปแบบการใช้งาน เช่น แยก read และ write ไปตามแต่ละ instance ไปเลย เพื่อทำการ optimize การทำงานง่ายและเหมาะสมขึ้น
• จึงทำให้ต้องมาสนใจเรื่อง replication มากขึ้น
• แต่เมื่อข้อมูลใน table หนึ่ง ๆ ใหญ่เกินไป ก็ต้องมาเรียนรู้และใช้งานการทำ sharding data ดังนั้นเรื่องของ monolithic architecture ก็ต้องพึงระวังด้วยว่าได้เวลาปรับปรุงแล้วหรือยัง
• โดยความรู้ต่าง ๆ เหล่านี้ต้อง share ความรู้ให้ทั้งทีม ไม่ได้ผูกติดกับคนใดหนึ่งเท่านั้น
• การจัดการ connection pool, monitoring สำคัญมาก ๆ เพื่อให้รู็ถึงปัญหาต่าง ๆ อย่างรวดเร็ว เพื่อให้แก้ไขได้เร็ว
• จะใช้อะไรก็ต้องเข้าใจมันด้วย เช่น ใช้งาน PostgreSQL ก็ต้องเข้าใจ operation model ของมันด้วย เพื่อช่วยลดข้อผิดพลาดในการใช้งาน

ลองนำไปประยุกต์ใช้งานกันดูครับ

เห็น share VDO เรื่อง Moving IO to the edges of your app: Functional Core, Imperative Shell
มีหลายเรื่องที่น่าสนใจ เช่น

• การจัดการเกี่ยวกับ dependency เช่น I/O ควรทำอย่างไร
• เรื่องของ pure functio ในส่วนของ business logic
• Function code และ Imperative shell มันคืออะไร

มาดูกันหน่อย แบบมั่ว ๆ ไป ตามที่เข้าใจ

สิ่งที่ชอบมาก ๆ คือรูปนี้ น่าจะอธิบายได้ดีมาก ๆ

• ในส่วนของ business logic นั้น ควรเป็นอิสระจากส่วนอื่น ๆ ไม่ออกไปข้างนอกเลย เช่น I/O, database เป็นต้น
• ในส่วนของ business logic นั้น สามารถทำ unit test ได้ง่าย ๆ
• ไม่ควรมีการ injection พวก dependency เข้ามาใน business logic เลย หรือ มีเท่าที่จำเป็น มิเช่นนั้นก็จะ injection กับมากมาย เยอะไป ลำบากอีก ทำได้กับทำแล้วดี มันคนละเรื่อง
• ถ้าต้องการทำงาน หรือ ทดสอบกับพวก I/O ต่าง ๆ หรือ dependency ต่าง ๆ ควรทำ Integration test หรือ ต่อไปจริง ๆ เลยดีกว่า เนื่องจาก technology ในปัจจุบันมันเอื้อมากยิ่งขึ้น (คำว่าต่อจริงนั้น คือ ใช้ของจริง หรือ ของเหมือนจริงก็ได้ เช่น ใช้ Test container เข้ามาช่วย)

หรือเป็น Domain centric นั่นเอง รูปมันคุ้น ๆ เหมือนพวก hexagonal หรือ clean architecture ไหมนะ

แต่ในการทำงานจริง ๆ เรามักจะเน้นทำให้เสร็จกันไว้ก่อน
ทำให้ logic การทำงาน รวมไปกับ dependency ต่าง ๆ มากมาย
ส่งผลให้เกิดปัญหามากมายตามมา เนื่องจากมี side effect เยอะ
รวมทั้งเรื่องการทดสอบก็ทำได้ยากตามมาอีกด้วย
ยากไม่ได้บอกว่าทำไม่ได้ แต่ถ้าเข้าใจปัญหาตั้งแต่ต้นจะได้จัดการได้ถูกต้อง

ดัวนั้นในการเขียน code ที่ดีควรจะต้อง

• รับ input เท่าที่ต้องการใช้งานเท่านั้น และส่งผลลัพธ์ออกมา
• input เหมือนเดิม ต้องได้ output เหมือนเดิมเสมอ
• ไม่มี side effect ใด ๆ

Function code และ Imperative shell (FCIS) มันคืออะไร ?

ทำไมรูปมันคุ้น ๆ

• Function core คือส่วนการทำงานหลัก เช่น business logic, rule ต่าง ๆ และ data processing เป็นต้น ซึ่งเป็น pure function ไม่มี side effect ใด ๆ นั่นคือไม่ส่งผลต่อส่วนอื่น ๆ หรือ ส่วนอื่น ๆ ไม่ส่งผลต่อการทำงาน
• Imperative shell คือส่วนของระบบงานที่ต้องเจอ side effect ต่าง ๆ ว่าระบบงานจะ handle หรือจัดการอย่างไร เช่น การเชื่อมต่อ database, การเรียก service ผ่าน HTTP protocol, จัดการ logging และทำงานร่วมกับพวก 3-party ต่าง ๆ มันคือตัวกลางเชื่อมต่อระหว่าง Function core ไปยังส่วนงานภายนอกนั่นเอง

ตัวอย่างการทำงานของ FCID

น่าสนใจมาก ๆ สำหรับการออกแบบระบบ และ จัดการตามแนวคิดนี้

Reference websites

• For Cleaner Domains, Move IO to the Edges of Your App
• Building modern architectures: Functional Core, Imperative Shell revamp

เพิ่งเห็น library ที่พัฒนาด้วยภาษา Python ชื่อว่า ell
เป็น library สำหรับ prompt engineering แบบง่าย ๆ
ให้เขียน prompt ด้วย code แบบง่าย ๆ ผ่าน API ของ OpenAI และ Anthropic
รวมทั้งมีเครื่องมือสำหรับการจัดการ versioning, tracing และ monitoring ให้
รวมทั้งการ visualization แบบสวย ๆ ผ่าน ell studio
มาลองใช้งานกันดู

เริ่มด้วยการเขียน Hello World กันดู

โดยที่ใช้งาน OpenAI เล่นดู และเปิด verbose mode คือการ debug

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

ต่อมาทำการ custom รูปแบบของ prompt เพิ่มเติม
แบบละเอียดมากยิ่งขึ้น

ทำการ run ดูผล

ต่อมา ell สามารถเก็บ version ของ program หรือ prompt ที่เขียนได้

จะเรียกว่า Language Model Program (LMP)
โดยสามารถบันทึกลงไฟล์ได้เลย เช่น

จะทำการสร้างไฟล์ ell.db ใน folder ชื่อว่า logdir

จากนั้นทำการเปิดไฟล์ที่สร้างขึ้นมาใน version 1 ด้วย ell studio ดังนี้

เข้า web browser ไปดูกัน
โดยที่ ell studio พัฒนาด้วย ReactJS

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

ลองเขียน program Chat กันนิดนึง จากตัวอย่างใน official web นั่นเอง

ทำการ run เล่นนิดหน่อย

ลองใช้งานกันดู ง่ายและสะดวกดี

สำหรับใครที่จัดเก็บข้อมูล tracing ของระบบงาน
เป็นหนึ่งในข้อมูลที่สำคัญของระบบ observability
น่าจะเคยเห็นและใช้งาน Jaeger กันมาบ้าง
โดยตอนนี้ทางทีมพัฒนาใกล้ปล่อย version 2 ออกมาให้ใช้งานกันแล้ว
มาดูว่ามีอะไรที่น่าสนใจกันบ้าง ๆ ?

เรื่องของ Observability ประกอบไปด้วย 3 + 1 ส่วนหลัก คือ

• Metric
• Trace
• Log
• เพิ่มอีก หนึ่งตัวคือ profiling นั่นเอง

ในส่วนของ Jaeger สำหรับเก็บข้อมูลของ trace
Jaeger = Tracing data (Storage + User Interface)
ทำการแสดงผลสวย ๆ ดังรูป

โดยที่สนับสนุน OpenTelemery ด้วยการมี jaeger collector
เพื่อรับข้อมูลจาก Otel Collector ในรูปแบบของ OpenTelemtry
โดย jaeger จะรับข้อมูลประเภท trace เท่านั้น
และจัดเก็บไป storage ต่อไป
แสดง flow การทำงานดังรูป

จากรูปจะพบว่าทาง Jaeger collector นั้น
จะต้องทำการแปลงของมูลจาก Otel collector มาเป็นข้อมูลที่ Jaeger สนับสนุน (OTEL-to-Jaeger)
เป็นส่วนงานที่มีปัญหาเพราะว่า ต้องมี component หรือ งานเพิ่มเติม
ดังนั้นใน Jaeger 2 นั้น จะไม่มีตัวแปลงอีกต่อไป
แต่ละเป็น Native OpenTelemetry ไปเลย (สนับสนุน OpenTelemetry Protocol)
ช่วยให้ performance ดีขึ้นอีกด้วย
รวมทั้งยังสนับสนุน Jaeger 1 ด้วยเช่นกัน

และยังมีความสามารถอื่น ๆ เช่น

• Batch processing
• ยังคงใช้งาน code/library เดิมได้
• ใช้งาน feature ต่าง ๆ ของ Otel collector

ลองใช้งานเล่น ๆ กันดู Jaeger 2.0 rc0

Reference websites

• Towards Jaeger v2 💥💥💥 Moar OpenTelemetry!

จากการแบ่งปันเรื่องการทดสอบ Mobile app ในรูปแบบต่าง ๆ
ทั้งจาก native ตามภาษาของแต่ละ app เช่น Kotlin และ Swift
รวมทั้งพวกที่พัฒนาด้วย Flutter + Dart
ซึ่งภาษาต่าง ๆ เหล่านี้ล้วนมี library ของการทดสอบให้ทั้งหมด เช่น

• Android + Kotlin จะมี Instrumentation test และ Espresso/UIAutomator
• iOS + Swift จะมี XCUITest
• Flutter + Dart จะมี integration test

แต่ตัวที่น่าสนใจคือ Mobile app ที่พัฒนาด้วย Flutter + Dart นั้น

หลาย ๆ ที่มักจะทดสอบด้วยเครื่องมือที่ชื่อว่า Appium
โดยต้องทำการสร้างไฟล์ APK หรือ IPA/APP มาก่อน
หรือติดตั้ง app ที่ที่ device ก่อนทดสอบ
ซึ่งผมจะเรียกการทดสอบแบบนี้ว่า External testing
เพราะว่า เป็นการทดสอบมุมมองของผู้ใช้งาน
แน่นอนว่า ช้าแน่ ๆ และ test case พังบ่อยมาก ๆ
แต่การทดสอบมีความน่าเชื่อสูง

ปัญหาของทดสอบ Flutter app ด้วย Appium นั้นคือ ไม่สามารถ inspect ได้ !!

แต่จาก version ใหม่ ๆ พบว่า Appium inspector
สามารถทำการ inspect app ที่พัฒนาจาก Flutter ได้เลย
ทั้งฝั่งของ Android และ iOS
ไม่ต้องติดตั้ง Flutter driver ใน Appium server อีกต่อไป

แต่ปัญหาที่ตามมาคือ การเข้าถึงแต่ละ element บนหน้าจอนั่นเอง จะทำอย่างไร ?

สิ่งที่สามารถทำได้ประกอบไปด้วย

• by Key
• by Text (ไม่ดี)
• by Semantics Label

สามารถเพิ่มเข้าไปในแต่ละ element ได้
จากนั้นต้องทำการ inspect ใน Appium inspector อีกที
ว่า app บน Android และ iOS นั้นได้ผลเหมือนหรือต่างกันอย่างไร
เพราะว่า เรื่องนี้สำคัญมาก ๆ สำหรับการทดสอบแบบ external นั่นเอง
ไม่ง่าย แต่ก็ไม่ยาก และ ต้องระวังให้มาก ๆ

การทดสอบควรมีทั้ง internal และ external testing เสมอ
เพื่อสร้างความมั่นใจให้ทั้งทีมพัฒนา และ ผู้ใช้งานนั่นเอง

Java 23 ถูกปล่อยออดมาแล้ว โดยมีการปรับปรุงความสามารถมา 12 ตัว เช่น

• การเขียน markdown format ใน comment
• การเพิ่ม Oracle GraalVM JIT compiler (Graal JIT) เข้ามาใน Oracle JDK 23 เป็นต้นไป แถว support SBOM อีกด้วย
• Scoped Values (Third Preview)
• Implicitly Declared Classes and Instance Main Methods (Third Preview)
• Flexible Constructor Bodies (Second Preview)
• Primitive Types in Patterns, instanceof, and switch (Preview)
• Module Import Declarations (Preview)
• Structured Concurrency (Third Preview)
• Deprecated class sun.misc.Unsafe แล้ว

ใน Spring Initializer ก็ support Java 23 แล้วด้วย

อย่าลืม Update และลองใช้งานกันดูครับ

Reference Websites

• Including the Graal JIT in Oracle JDK 23
• Java 23 Release Notes
• The Arrival of Java 23
• Java 23 and GraalVM for JDK 23 Released - JVM Weekly vol. 100

จากการอ่านบทความเรื่อง 10 Habits of Great Software Engineers
มีหลายเรื่องที่น่าสนใจ และ แปลก ๆ
สิ่งที่สนใจ และ ชอบตั้งคำถามบ่อย ๆ คือ
เราจะทำอย่างไร ?
เมื่อเจอ code มี warning ขึ้นมา หรือ ขึ้นพวก deprecated code
ทั้งจากใน editor และ build/compile process

ก็เลยตั้ง post ถามใน facebook เล่น ๆ
ไว้นิดหน่อย

ซึ่งคำตอบก็มีหลากหลาย เช่น

• ไม่ต้องแก้ไข เพราะว่า มันยังทำงานได้ ปล่อยไป อย่าไปยุ่งกับมัน
• ถ้ามี deprecated ก็อย่าไป upgrade หรือ downgrade ไปยัง version ที่มันไม่ขึ้น warning
• Disable มันไปใน editor หรือ config ของการ build/compile
• หรือใน code ก็ใส่ให้ ignore ไปเลยก็ได้
• ต้องแก้ไขสิ อย่าปล่อยไว้

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

ถ้าต้องการไปเร็ว ๆ ก็ปิดทุกสิ่งอย่างไปเลย
เน้นทำให้เสร็จ ทำงานได้ ส่งได้ จบ

บางครั้งก็ disable บาง rule เพื่อให้เหมาะสมก็ได้
บางครั้งก็ ignore ใน code ไปบ้าง

แต่ถ้าในแง่ของการ maintain ก็น่าจะต้องแก้ไข
หรือเลิกสร้าง code เหล่านั้นขึ้นมา
นั่นคือสิ่งที่นักพัฒนาต้องทำ

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

Do it Now or Later or Never !!

ทาง Anthropic ซึ่งเป็นเจ้าของ Claude.AI นั่นเอง
ได้เขียนบทความเรื่อง Introducing Contextual Retrieval
อธิบายเรื่องของการปรับปรุงความสามารถของ AI Model ต่าง ๆ
ด้วยแนวคิด Retrieval-Augmented Generation (RAG)

โครงสร้างของ RAG เป็นดังนี้

โดยในบทความได้แนะนำสำหรับ Anthropic ไว้ดังนี้

แบบที่ 1

ถ้าข้อมูลที่ต้องการเพิ่ม หรือ knowledge ไม่มากนัก
ซึ่งไม่เกิน 200,000 token หรือเอกสาร 500 หน้า
สามารถตรวจสอบผ่าน Token counter ได้เลย
ทำการส่งข้อมูลเหล่านี้ไปในส่วนของ context ใน user prompt ปกติได้เลย

แต่ถ้ากลัวว่าถ้ามีหลาย ๆ prompt ที่ใช้ข้อมูลเดิม
สามารถใช้งานผ่าน feature Prompt caching
ที่ทาง Anthropic เพิ่งปล่อยออกมาใน beta version
สามารถช่วยลดค่ายใช้จ่ายลงไปได้เยอะมาก ๆ
โดยที่อื่น ๆ เช่น Gemini ก็มีให้ใช้งานด้วย

แบบที่ 2

ถ้าข้อมูลมีขนาดที่ใหญ่มาก ๆ เกินแบบที่ 1
สามารถทำการ pre-processing ข้อมูลก่อน มีขั้นตอนดังนี้

• ทำการแบ่งข้อมูลเป็น chunk เล็ก ๆ
• สร้าง embedding model จาก check เล็ก ๆ เพื่อจัดเก็บใน Vector database
• สร้าง TF-IDF(Term Frequency Inverse Document Frequency of records เพื่อจัดเก็บในการค้นหา หรือ ranking ข้อมูล
• เมื่อต้องส่ง user prompt ไปจะนำข้อมูลจากทั้งสองที่ไปใส่ เพื่อให้ได้ผลลัพธ์ที่ถูกต้องมากยิ่งขึ้น
• เมื่อได้ผลลัพธ์กลับมา จะทำการ ranking หรือ เรียงลำดับกลับออกมา

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

โดยที่ทาง Anthropic ได้เสนอแนวทางปรับปรุงออกมา คือ Contextual Retrieval

ทำการสร้าง Prompt template ออกมาให้ใช้งาน
โดยมีโครงสร้างดังนี้

จากนั้นทางระบบจะจัดการข้อมูลต่าง ๆ ใน pre-processing ให้อัตโนมัติ
และมีการทำ prompt caching ให้เลย
ค่าใช้จ่ายประมาณ 1.02 USD ต่อ 1 ล้าน token
ดังรูป

ตัวอย่างของการสร้าง Prompt พร้อมใช้งาน caching

โดยแนวทางนี้ช่วยปรับปรุงความถูกต้องของผลลัพธ์มากขึ้น
รวมทั้ง performance ที่ดีขึ้น
เป็นอีกแนวทางที่น่าสนใจมาก ๆ

มีโอกาสไปแบ่งปันความรู้เรื่องการทดสอบระบบ web ที่พัฒนาด้วย Vue และ NuxtJS
ในงาน Vue ไทย Conf 2024 ครั้งที่ 1
โดยพูดเรื่อง Better testing with Vue application
ซึ่งมีเนื้อหาหลัก ๆ ดังนี้ มาเริ่มกันเลย

เริ่มจากเรื่องการพัฒนาระบบงาน

ถ้ามีเวลาจำกัด เราจะเลือกอะไร ระหว่าง ปริมาณ กับ คุณภาพ
เป็นทางเลือกที่โหดร้ายมาก ๆ
ไม่ว่าจะเลือกทางไหน ก็มี trade off เสมอ
สิ่งที่ควรทำคือ การ balance ทั้งสอง
และสร้างความเชื่อมั่นในการพัฒนาและส่งมอบระบบงาน

โดยหนึ่งในวิธีการสร้างความเชื่อมั่น

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

ไม่ใช่ว่าทดสอบแล้ว ครอบคลุมเยอะมาก ๆ (test coverage สูงมาก)
แต่กลับยังมีปัญหาต่าง ๆ มากมายอยู่
แบบนี้คือ การทำให้มี แต่ไม่ดีและไม่มีประโยชน์มากนัก
ดังนั้นเรื่องคุณภาพ และ ความเชื่อมั่นจึงสำคัญ

การทดสอบที่ดี ควรมีคุณสมบัติคร่าว ๆ ดังนี้

• ทำงานได้รวดเร็ว
• เป็นอิสระต่อส่วนต่าง ๆ ที่ต้องการ
• ต้องสามารภทดสอบซ้ำ ๆ ได้ตลอดเวลา
• มีการตรวจสอบที่เชื่อถือได้
• ชุดการทดสอบสามารถเข้าใจได้ง่าย ไม่ต้องมานั่งตีความ

และสุดท้ายคือ การทดสอบจะเกิดขึ้นใน คือ

• Test-first คิดก่อนทำ
• Test-last ทำแล้วค่อยคิดจะทดสอบ
• Test-later ทำเยอะ ๆ แล้วค่อยคิดจะทดสอบ

หลังจากออกทะเลไปไหล กลับมาที่ Vue กันบ้าง

เริ่มจากโครงสร้างของ Vue project ที่ควรจัดการให้ดี ๆ
หนึ่งในแนวทางที่แนะนำคือ การลดขนาดของ project เพื่อลดการ build
ระบบที่ดีควรเลือก feature/domain ที่ต้องการจะ build ได้
จึงแนะนำการแบ่งเป็น feature/domain
เมื่อจะทำการ build ก็ทำการ add เข้ามาได้ (extend หรือ module)

ต่อมาในการทดสอบ มีหลายรูปแบบทั้ง

• Unit test
• Component test
• UI test
• Visual test
• Snapshot test

หนึ่งในแนวทางที่แนะนำไปคือ UI test ด้วย Playwright และ Vitest + Testing library with Vue
ซึ่ง test ที่ดีควรมีคุณสมบัติดังนี้

• ไม่ผูกมัดกับ implementation หรือ UI มาเกินไป เช่นการใช้ test id เข้ามาช่วย
• ไม่ผูกมัดกับ test framework โดยเราสามารถสร้าง driver interface เพื่อให้ test framework มา implement ตาม driver interface ไว้ได้เลย จากตัวอย่าง เราสามารถเปลี่ยนไปมาระหว่าง Playwright และ Vitest ได้ โดยใช้ test case เดียวกันได้เลย อาจจะมองว่ามัน over engineer มากเกินไป แต่ก็เป็นแนวทางที่น่าสนใจอย่างหนึ่ง รู้ไว้ไม่เสียหาย !!
• ควรต้องอ่านเข้าใจได้ง่าย ไม่ technical มากจนเกินไป

ปิดท้ายด้วย Component test สำหรับแต่ละ component ใน Vue นั่นเอง
ช่วยให้เรามั่นใจกับการทำงานของแต่ component
ก่อนที่จะนำ component ต่าง ๆ ไปทำงานร่วมกัน

ทั้งหมดนี้ เป็นส่วนหนึ่งของการสร้างความมั่นใจ ให้เพิ่มขึ้น
และเพิ่มคุณภาพของระบบงานให้มากขึ้น

หลังจากนี้ไม่รู้เรื่องแล้ว เมาาาาาาา

ตัวอย่างของ code ที่ใช้ อยู่ที่ GitHub:Up1