จากบทความ Announcing built-in container support for the .NET SDK นั้น
อธิบายว่า .NET นั้นสนับสนุน container แล้ว
ช่วยให้การสร้าง OCI container ได้แบบง่าย ๆ
ผ่านคำสั่ง $dotnet publish

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

โดยปกติการสร้าง OCI container นั้น มีขั้นตอนดังนี้

• สร้าง Dockerfile
• โดยใน Based image ของ .Net
• ใช้งาน Multistage build ใน Dockerfile
• ทำการสร้าง image ผ่าน docker image build

จะเห็นได้ว่ามีขั้นตอนที่เยอะ

มาดูกันหน่อยว่าใน .Net 7 ที่สนับสนุน container ใช้อย่างไร

รวมทั้งใช้งานได้ใน Github Actions ได้อีกด้วย

Reference Websites

• https://github.com/dotnet/sdk-container-builds

เห็นเรื่องการเปลี่ยนจาก Elasticsearch มาเป็นของ Clickhouse
ก็ทำให้ไปอ่านบทความเก่าตั้งแต่ปี 2018
เรื่อง HTTP Analytics for 6M requests per second using ClickHouse
ว่าด้วยเรื่องการวิเคราะห์ traffic ปริมาณสูง
ว่า architecture ของระบบมีวิวัฒนาการอย่างไร
เพื่อให้รองรับข้อมูลที่สูงมาก ๆ
นั่นคือ architecture ของ Data pipeline
มาดูกัน

Architecture ของ Data pipeline แบบเก่า

ซึ่งสร้างมาตั้งแต่ปี 2014 โดยใช้เครื่องมือต่าง ๆ เหล่างนี้

• Apache Kafka สำหรับรับข้อมูล HTTP traffic จากผู้ใช้งานต่าง ๆ เข้ามายัง pipeline
• โดย consumer ของ Apache Kafka นั้น จะนำข้อมูลมาเก็บใน PostgreSQL ซึ่งทำการ aggregate data ตามการใช้งานทั้ง partition, zone รวมทั้งข้อมูลในระดับนาที ชั่วโมง วัน เดือน ทำให้ง่ายต่อการใช้งานต่อไป
• ทำการ scale out ตัว PostgreSQL ด้วย CitusDB เพื่อนำไป analyze ต่อไป
• Analyze API พัฒนาด้วยภาษา Go
• ใช้งานผ่าน PHP API
• Load balance ใช้งาน NGINX

แสดงดังรูป

แสดง Flow การไหลของ traffic ที่เข้ามา ดังรูป

ส่วน CitusDB มีโครงสร้างการทำงานดังรูป

จาก architecture ข้างต้นนั้น ทำงานได้ดี

แต่เมื่อจำนวน HTTP traffic เพิ่มจาก
1 ล้าน request ต่อวินาที มาเป็น 6 ล้าน request ต่อวินาทีแล้ว
ทำให้มีปัญหาเกิดขึ้น
โดยมีจุดอ่อนหรือปัญหาดังนี้

• PostgreSQL และ CitusDB กลายเป็น Single point of failure
• Code มีความซับซ้อนมาก ๆ ทั้ง bash script และ SQL ในการ aggregation ข้อมูล รวมถึง code ที่พัฒนาด้วยภาษา Go ก็เยอะ ทำให้ยากต่อการดูแลรักษา
• มี dependency เยอะเกินไป และผูกมัดกันเกินไป ถ้ามีส่วนใดพังไป ก่อให้เกิดพังทั้ง pipeline
• ค่าใช้จ่ายในการดูแลสูง ทั้งซับซ้อน ข้อผิดพลาดก็เยอะ ใช้เวลาแก้ไขก็นาน

ดังนั้นจึงพยายามปรับปรุง Data pipeline นี้ใหม่
เพื่อรองรับ และ แก้ไขปัญหาต่าง ๆ ที่เกิดขึ้น
ความพยายามแรกคือ การใช้งาน Apache Flink สำหรับ stream processing
ซึ่งใช้กับ project อื่น ๆ มาแล้ว
แต่ก็มีปัญหาเรื่องการ scale ให้รองรับข้อมูลระดับ 6 ล้าน request ต่อวินาที

จากนั้นได้ลองนำเอา pipeline จากทีม DNS ที่ทำ DNS analytic pipeline ที่ทำงานบน ClickHouse

เป็น database แบบ column-base
ซึ่งพบว่าเหมาะกับงาน และ จำนวน traffic นี้มาก ๆ
ช่วยให้ scale out และลดปัญหาไปได้เยอะ
ทำให้ระบบมี up time ที่ดี
รวมทั้ง performance ที่ดี

ตัวอย่างข้อมูลที่จัดเก็บมีมากกว่า 100 columns

เรื่องการออกแบบ schema ของข้อมูล สำคัญมาก ๆ

เพื่อทำให้มั่นใจว่า เหมาะสมต่อการจัดเก็บและใช้งาน
จากนั้นทำ benchmark เพื่อดูผลการทำงาน

โดยจากการออกแบบและสร้าง จะได้ data pipeline ใหม่

ประกอบไปด้วยเครื่องมือดังนี้

• Apache Kafka เพื่อรับ request เช่นเดิม
• ผลการทำงานจาก Kafka consumer จะเก็บไว้ที่ ClickHouse แทนที่ PostgreSQL และ CitusDB
• คนใช้งานวิ่งมาที่ Analytic API ที่พัฒนาด้วยภาษา Go ได้เลย

จาก architectureใหม่ สามารถรองรับได้มากกว่า 7 ล้าน request ต่อวินาที

แสดงดังรูป

อีกเรื่องคือรูปแบบของข้อมูลที่ใช้งาน จะใช้ Cap'n Proto

ซึ่งเล็กและเร็วกว่า Protobuf อีกนะ
น่าสนใจมาก ๆ

ข้อดีของ Data pipeline ตัวใหม่ ประกอบไปด้วย

• ไม่มี Single point of failure
• Fault-tolerant ตายใครตายมัน ไม่ส่งผลต่อส่วนอื่น ๆ
• Scale ได้ง่ายขึ้น
• ลดความซับซ้อนลงไปมาก
• ปรับปรุงในเรื่องของ throughput และ latency ของ API
• ง่ายต่อการดูแลรักษา และ จัดการ
• ที่สำคัญสุด ๆ ลดปัญหา หรือ incident นั่นคือระบบมีความเสถียร และ น่าเชื่อถือขึ้นมาก

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

จาก tweet เรื่อง What does API gateway do? นั้น
ทำการอธิบานการทำงานของ API gateway ว่าทำอะไรบ้าง
โดยเขียน diagram แบบเข้าใจง่าย ๆ ไว้อีกด้วย
มาดูกัน

โดยสิ่งที่น่าสนใจคือ ขั้นตอนที่ 8 Protocol conversion

ทำการ transform request ไปยัง protocol ที่เหมาะสม
เพื่อเรียกไปยัง service ปลายทางอีกต่อ
เช่นจาก HTTP ไปเป็น gRPC เป็นต้น

ว่าง ๆ นั่งเปลี่ยน logger จากที่ใช้งาน logrus มาเป็น zap
โดยสิ่งที่ต้องการให้เหมือนเดิมคือ

• Log message ในรูปแบบของ JSON
• Log ออกไปทั้ง file แบบแยกรายวัน และออกที่ console
• เก็บเฉพาะ log level = error เท่านั้น

Code ที่เขียนออกมาของ log ตัวนี้ ประกอบไปด้วย

• LogFactory เป็น interface ช่วยให้เปลี่ยน implementation ของ log ได้ง่าย
• มี method NewLogger() สำหรับสร้าง logger จาก zap โดยส่ง path ของ log file เข้าไปได้
• กำหนด log level = error ขึ้นไป จะเรียกว่า high priority
• ใช้งาน JSONEncoder สำหรับกำหนดรูปแบบของ logg message ในรูปแบบ JSON

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

ตัวอย่างของ log message

ใช้งานง่าย ๆ กับ zap
แต่มี feature อื่น ๆ อีกเยอะเลย ไว้ลองใช้งานต่อไป
เนื่องจากงานใช้เท่านี้เอง

ปล. เห็นเขาว่าเร็ว และ ใช้ resource น้อย แต่ไม่ได้จับวัดนะ

ทาง Postman นั้น ได้เปิดให้ลงชื่อเข้าใช้งาน Postman 10 แบบ Eary access กัน
โดยใน version นี้มี feature ใหม่ ๆ และปรับปรุงมาเยอะเลย
ยกตัวอย่างเช่น

• Partner workspace
• API governance
• API security
• สนับสนุน Git
• Integrate กับ test automation และ ทำงานกับ CI/CD
• สนับสนุน gRPC

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

วิธีการแรก ใช้ caching data สำหรับการอ่านข้อมูล

เพื่อช่วยลดการอ่านข้อมูลจาก database ตรง ๆ
แสดงการทำงานดังรูป

ปัญหาของการใช้งาน caching data คือ ความถูกต้องของข้อมูล
ถ้าข้อมูลใน database มีการเปลี่ยนแปลง
ข้อมูลใน caching ต้องเปลี่ยนแปลงด้วยเช่นกัน
มิเช่นนั้นอาจจะก่อให้เกิดปัญหาตามมาได้

วิธีการที่สอง Denormalization

ปกติข้อมูลมักจะออกแบบในรูปแบบ normalization
ซึ่งมีประโยชน์ต่อการจัดเก็บ
แต่ในเรื่องของการอ่าน จะทำให้อ่านจากหลาย ๆ ตาราง
หรือแยกกันหลาย ๆ ที่
ทำให้การอ่านช้าลงอย่างมาก
ยิ่งมีการใช้งานมากขึ้น และ จำนวนข้อมูลสูงขึ้น
ดังนั้น จะดีกว่าไหม ถ้ารวมข้อมูลไว้ที่เดียวกัน

ยกตัวอย่างการสร้างข้อมูลสำหรับการอ่านขึ้นมาแบบ synchornous

หรืออาจจะทำการ replication ข้อมูลแบบ asynchronous ก็ได้

มีวิธีการเพียง เช่น

• CQRS
• ETL
• CDC
• Streaming

วิธีการที่สาม Async Request/Response

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

จะทำการส่ง event จาก request ต่าง ๆ ไปยัง event handler
เพื่อลดความกดดันจาก request ปริมาณมาก ๆที่เข้าใช้งาน database
ถ้าเป็นแบบปกติคือ synchronous เมื่อมี request มาเยอะ ๆ
ระบบจะทำการสร้าง thread ขึ้นมา เพื่อรองรับ request เหล่านั้น
ซึ่งอาจจะส่งผลต่อ performance นั่นเอง
ดังนั้น ถ้าแยกออกมา และ ติดต่อสื่อสารแบบ asynchronous
น่าจะช่วยลดปัญหาลง
แต่การทำงานต้องไม่ช้า หรือ ส่งผลต่อผู้ใช้งานมากจนเกินไป
หรืออาจจะต้องมีการออกแบบ process การใช้งานให้เหมาะสมอีกด้วย

การเปลี่ยนแปลงใน Robot Frameowrk 5.1 นั้น เยอะมาก ๆ
แต่สิ่งที่คนใช้งานต้องสนใจมาก ๆ
คือ deprecated feature นั่นเอง
ที่จะถูกเอาออกไปใน version 6 ต่อไป
ดังนั้นควรหลีกเลี่ยงการใช้งาน
มาดูกันว่ามีอะไรบ้าง ?

• Force Tags และ Default Tags สองตัวนี้ผมไม่เคยใช้งานเลย ใช้แต่ Tags ใน Test cases
• พวก Singular section เช่น Test Case, Setting, Keyword, Task ให้ไปใช้แบบ plural ให้หมด เช่น Test Cases, Settings, Keywords, Tasks
• การใช้งาน regular expression ใน variable ของ embedded arguments ของ keyword ต่าง ๆ
• เปลี่ยนการ alias ชื่อ จาก WITH NAME มาเป็น AS
• Python 3.6 !! ไปใช้งาน Python 3.11 แทน

Java 19 ตัวเต็มถูกปล่อยออกมาให้ใช้งานแล้ว
มีการเปลี่ยนแปลงและปรับปรุง feature จำนวนมาก
โดยบอกไว้ว่า มาจาก community ทั้งโลกอีกด้วย
หลัก ๆ จะประกอบไปด้วย JEPs (JDK Enhancement Proposals) 7 ตัว
ซึ่จะเป็น preview feature นั่นเอง

รวมทั้งสนับสนุนการทำงานบน Cloud มากยิ่งขึ้น

มาดู feature สำคัญ ๆ ของ Java 19 กัน

• JEB 405 คือ Record pattern
• JEB 427 คือ Pattern matching for Switch
• JEP 424 คือ Foreign Function and Memory API
• JEP 426 คือ Vector API
• JEP 425 คือ Virtual Threads
• JEP 428 คือ Structured Concurrency
• JEP 422 คือ Linux/RISC-V Port

รูปแสดงการแก้ไข bug จากบริษัทต่าง ๆ

Reference Websites

• The Arrival of Java 19!
• Java 19 Delivers Features for Projects Loom, Panama and Amber

อ่านหนังสือเกี่ยวกับ Kubernetes ก็ไปเจอหนังสือหลายเล่มที่น่าสนใจ
หนึ่งในนั้นคือ Kubernetes Patterns
โดยอธิบาย 5 ส่วน หลักของการจัดการ container ดังนี้

• Foundation ว่าด้วยเรื่อง principle และ practice ในการสร้างและพัฒนาเกี่ยวกับ container
• Behavioral แนวคิดและแนวทางในการจัดการ containerใ นรูปแบบต่าง ๆ รวมทั้งการจัดการ platform เพื่อรองรับ
• Structural ช่วยในการจัดการ containerใ น Pods ของ Kubernetes ว่าควรมีโครงสร้างอย่างไร
• Configuration ว่าด้วยเรื่องของการ config dการจัดการภายในของ app ที่จะ run ใน Kubernetes cluster ได้อย่างเหมาะสม
• Advance เป็นเรื่องของการ extend Kubernetes นั่นเอง เช่น การสร้าง operator เป็นต้น

ลอง download มาอ่านกันได้แบบฟรี ๆ

ทาง Postman ได้ปล่อย Postman CLI ออกมา
ซึ่งเป็นคนละตัวกับ newman นะ
แต่มีเป้าหมายเดียวกันคือ ช่วยให้ง่ายต่อการทำ automation testing
และสามารถนำไปอยู่ใน pipline ของระบบ CI/CD ได้

แต่สิ่งที่แตกต่างคือ Postman CLI จะเป็น closed system
ส่วน newman นั้นเป็นระบบเปิด

ซึ่งดูแลโดย Postman เท่านั้น
ในการใช้งานต้อง login เข้าไปใช้เสมอ
รวมทั้งยังมีการตรวจสอบ API lining และ security check ให้อีกด้วย
จะทำการเพิ่มเข้ามาใจ Postman 10 แสดงดังรูป

ส่วนการใช้งาน CLI จะใช้ผ่าน $postman นั่นเอง

จากบทความเรื่อง Principles of Container-based Application Design
ทำการอธิบายถึงแนวคิด 7 ข้อ
สำหรับการออกแบบระบบงานด้วย Container
หรือตามแนวทางของ Cloud Native Application นั่นเอง
ซึ่งมีรายละเอียดดังนี้

โดยแบ่งออกเป็น 2 กลุ่มคือ

กลุ่มที่ 1 Build time

• Single concern แต่ละ container ควรทำงานอย่างใดอย่างหนึ่งไป และทำให้มันดีไปเลย
• Self-containment แต่ละ container จะทำงานบน kernel เป็นหลัก ดังนั้นพวก library ต่าง ๆ ควรนำมาใส่ตอน build time เพื่อลด dependency ลงไป
• Image immutable แต่ละ application container ที่ถูกสร้างขึ้นมานั้น ต้องไม่สามารถแก้ไขหรือเปลี่ยนแปลงได้ เพื่อให้สามารถ deploy ได้ในทุก ๆ environment โดยไม่ต้องทำการ build ใหม่

กลุ่มที่ 2 Runtime

• High Observability ทุก ๆ container ควรที่จะมี API และระบบที่คอยดูแลและจัดการการทำงานของ app ได้ ทั้ง health check, metric, tracing และ logging
• Lifecycle Conformance แต่ละ container ควรทำการรับหรือตรวจสอบ event ต่าง ๆ จาก platform ต่าง ๆ เพื่อนำมาคิดและประมวลผล ทำให้ container ทำงานได้อย่างถูกต้องและเหมาะสม
• Process Disposability แต่ละ container ต้อง start/stop ได้อย่างรวดเร็ว และง่าย เป็นอิสระต่อ dependency อื่น ๆ ส่งผลให้เมื่อเกิดปัญหาขึ้นมา สามารถลบและสร้างใหม่ได้เลย
• Runtime Confinement แต่ละ container ต้องสามารถประกาศการใช้งาน resource ได้แบบง่าย ๆ เช่น limit ของ cpu, memory, config และ storage ซึ่งช่วยทำให้เราสามารถ build app ใน container ในขอบเขตที่เหมาะสม และ สะดวกต่อการเปลี่ยนแปลงมากยิ่งขึ้น

Reference Websites

• 7 Design Principals for Containers

จากที่ Google Cloud Function ปล่อย 2 gen ออกมาใหม่นั้น
ทำการปรับปรุงเรื่อง instance ที่ใหญ่ขึ้น
การรองรับ request ที่ทำงานนาน ๆ
รับ event source จาก Eventarc
เช่นเดียวกันกับทาง .Net 6 ก็สนับสนุน Cloud Function เช่นเดียวกัน
ดังนั้นเรามาลองใช้งานกันนิดหน่อย

มาลองสร้าง project ด้วย .Net 6 กัน

เริ่มด้วยการติดตั้ง .Net 6 ก่อน
จากนั้นทำการ install ของตัว project template ที่เตรียมไว้ให้
ซึ่งประกอบไปด้วย 3 ตัวคือ

• Google Cloud Functions CloudEvent Function
• Google Cloud Functions CloudEvent Function (Untyped)
• Google Cloud Functions HttpFunction

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

ลองทำการสร้าง project แบบ Google Cloud Functions HttpFunction เล่นดู

โดยจะพบว่าตัว project ยังสนับสนุน .Net Core 3.1 อยู่ !!
ดังนั้นสามารถเปลี่ยนมาเป็น 6 ได้ดังนี้

เพียงเท่านี้ก็สามารถพัฒนาและ deploy ได้แล้ว

Reference Websites

• Cloud Functions 2nd gen is GA, delivering more events, compute and control
• .NET 6 on Cloud Functions (2nd gen)

จากบทความเรื่อง 6 strategic ways to level up your CI/CD pipeline
ที่เขียนใน blog ของ GitHub นั้น
ทำการแนะนำ 6 แนวทางในการปรับปรุง CI/CD ให้ดีขึ้น
ประกอบไปด้วยสิ่งต่าง ๆ ดังนี้

เรื่องที่ 1 เพิ่ม performance, device compatibility และ accessibility testing เข้าไปด้วย

ปัญหาที่มักเจอบ่อยมาก ๆ ใน CI/CD pipeline คือ เรื่องของการทดสอบ
ทั้งขาดการทดสอบที่ดี หรือ ไม่มีเลยก็เพียบ
ดังนั้นถ้าเพิ่มการทดสอบต่าง ๆ เข้ามา
น่าจะช่วยเรื่องความมั่นใจต่อ product ได้
รวมทั้งยังช่วยให้เจอปัญหาได้รวดเร็วอีกด้วย
แต่สิ่งที่ต้องคิดคือ ความเร็วของการทดสอบ ต้องไม่ช้าด้วย
นั่นคือ เรื่องของเครื่องมือก็จำเป็นมากเช่นกัน

จากบทความแนะนำเครื่องมือต่าง ๆ ดังนี้

• Playwright
• Pa11y

เรื่องที่ 2 เพิ่ม security testing เพิ่มเข้ามา ระหว่างการพัฒนา

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

ซึ่งในปัจจุบันก็มีเครื่องมือออกมาให้ใช้มากมาย
ยกตัวอย่างเช่น
GitHub ก็มีพวก depndabot, code scan, และ secret scan ให้ใช้แบบง่าย ๆ

ดังนั้นการหาปัญหาตั้งแต่เนิ่น ๆ น่าจะเป็นประโยชน์มากขึ้น
โดยจะเห็นได้จากแนวคิด DevSecOps นั่นเอง
รวมทั้งยังช่วยให้มีการทำงานเป็นทีมมากยิ่งขึ้น
ไม่ใช่โยนงานกันไปมา ปวดหัวเปล่า ๆ

เรื่องที่ 3 เพิ่มขั้นตอนของการ testing เข้ามา

การทดสอบที่ดีคือ ต้องทำได้บ่อย ๆ รวดเร็ว และน่าเชื่อถือ
ในมุมมองทั้ง developer, tester/QA, business, deployment
ดังนั้นควรว่า strategy ของการ testing ด้วยเสมอ
เพราะว่ามันสำคัญมาก ๆ
ต้องเปลี่ยนจาก should have เป็น MUST have เลย

เนื่องจากการ testing ต้องมีการวางแผนมากมาย
ทั้ง test level strategy ว่าต้องมีอะไร อย่างไร
ทั้ง test environment
ทั้ง test data management
ทั้งการเปิดปิด feature เพื่อทดสอบใน feature ที่ต้องการ
จะช่วยให้การทำ regression test ง่ายขึ้น และ บ่อยขึ้นด้วย

เรื่องที่ 4 ในการ deploy ควรลงทุนกับ Blue Green deployment

จะช่วยให้เราสามารถ deploy ระบบงาน version ใหม่ได้อย่างปลอดภัยมากขึ้น
รวมทั้งลด downtime หรือ ปัญหาที่อาจจะเกิดขึ้น
ทำให้เราสามารถ rollout และ rollback ได้อย่างมั่นใจ
แต่เราจำเป็นต้องลงทุนเสมอ
รวมทั้งต้องมองในเรื่องของความคุ้มค่าต่อ business ด้วย

เรื่องที่ 5 ให้นำแนวคิด Infrastructure as Code (IaC) เข้ามาใช้ด้วย

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

ดังนั้นถ้าใน pipeline ของเรา มีการ provisioning ทุกครั้ง
ก็จะช่วยทำให้เห็นปัญหาของการ provisioning ได้อีกด้วย
จะได้แก้ไขได้อย่างทันท่วงทีนั่นเอง

รวมทั้งยังสามารถเขียน code เพื่อการ deploy แบบ Blue Grren deployment ได้อีกด้วย

เรื่องที่ 6 อย่าลืมสร้าง checkpoint สำหรับการ rollback แบบอัตโนมัติด้วย

ในการ deploy ระบบงาน อาจจะเกิดปัญหาขึ้นมาได้เสมอ
ดังนั้น ควรปลอดภัยไว้ก่อน ถึงแม้จะมีการ deploy แบบ Blue Green ก็ตาม
สิ่งที่ควรทำคือ จุด checkpoint ของการ deploy
เพื่อให้เราสามารถ rollback ไปยังจุดนั้น เมื่อเกิดปัญหาได้
ซึ่งเป็น metric อย่างหนึ่งขององค์กรที่นำแนวคิดเหล่านี้มาใช้
deploy บ่อยตามที่ต้องการมันยังไม่พอ
ต้องแก้ปัญหาได้รวดเร็วด้วยเช่นกัน

น่าลองเอาไปปรับใช้งานกันนะครับ
น่าจะช่วยทำให้ CI/CD pipeline ของเรามีประสิทธิภาพและน่าเชื่อถือขึ้น

เมื่อเช้าเจอ SQLFlow เป็นเครื่องมือสำหรับการ visualize ชุดคำสั่ง SQL
ในรูปแบบ Entity/Table และ ความสัมพันธ์แบบสวย ๆ
น่าจะช่วยทำให้เข้าใจการทำงานของ SQL นั้น ๆ มากยิ่งขึ้น

เห็นว่า Axios นั้นได้ปล่อย version 1 ออกมา
จากนั้นก็เห็นว่ามีปัญหาเพียบ
สามารถดู issue ได้ที่ Axios issues
ตอนนี้แก้ไขมาจนถึง version 1.1.2 แล้ว
จึงลองมาใช้งาน โดย migrate มาจาก version 0.27.2
พบว่า ใช้งานได้ปกตินะ
เนื่องจาก code ที่เขียนไม่ได้มีอะไรซับซ้อนมาก

เริ่มด้วยการใช้งานเรียก API แบบ HTTP GET

ต่อมาลอง HTTP GET ไปยัง API ของ GitHub นิดหน่อย

มีการใส่ค่าใน HTTP Request Header

ใช้งาน interceptor แบบง่าย ๆ ในการดัก error

ปล. เอกสารของ verison 1.x ยังไม่ออกมาเลย
ก็คงได้แต่รอต่อไปนะครับ
ส่วน issue ที่เปิดมานั้น เยอะมากมาย !!

ทาง Spring ได้ปล่อยเครื่องมือใน version ทดลอง
สำหรับ Spring Boot Migrator (SBM)
เพื่อทำหน้าที่ migrate ระบบงานที่พัฒนาด้วย Spring Boot 2.7 ไปยัง version 3
เนื่องจากใน version 3 นั้นมีการเปลี่ยนแปลงที่เยอะ

เป้าหมายของ SBM นั้น สามารถใช้ได้ทั้ง Spring Boot และ Non-Spring Boot ด้วย
โดยในประกอบไปด้วย JAX-RS, EJB และ JMS

ใน project นี้จะเตรียม JAR file มาให้
สามารถ download ได้จากที่นี่

จากนั้นใช้งานผ่านคำสั่ง

จะมีชุดคำสั่งให้ใช้งาน เช่น scan
เพื่อตรวจสอบว่าใน project ของเรามีการใช้งาน library ใดบ้าง
เพื่อทำการ migrate มายัง version ใหม่

จากนั้นใช้คำสั่ง apply สำหรับการ migrate ต่อไปของแต่ละ library

ในตอนนี้ยังสนับสนุนเพียง Apache Maven Project เท่านั้น !!

สามารถอ่านเอกสารกสนใช้งานได้ที่ Document :: Spring Boot Migrator

พอดีมีการพูดคุยเรื่องของ Playwright กันนิดหน่อย
สิ่งที่น่าสนใจคือ โครงสร้างหรือ architecture ของ Playwright ว่าเป็นอย่างไร
รวมทั้งการแก้ไขปัญหาที่มักเกิดขึ้นจาก end-to-end testing
นั่นก็คือ Flaky test หรือการทดสอบที่พังง่าย และ หาปัญหาได้ยากมากๆ
ทำให้ชุดการทดสอบไม่น่าเชื่อถือ

จึงทำแก้ไขออกมาด้วย feature ของ Playwright นั่นเอง
ประกอบไปด้วย

• Auto-wait ทำการรอให้แบบอัตโนมัติ หรือจพ config เรื่องของ timeout และ retry ได้
• Tracing ทำการเก็บ log ทั้ง message, รูปภาพ และ VDO การทดสอบไว้ให้อีก
• HTML report ก็มีมาให้เลย
• Test generator
• Playwright inspector และ Debug mode
• Authentication สามารถทำงาน login และนำ session นั้นมาใช้ซ้ำได้อีก โดยไม่ต้อง login ใหม่ ลดเวลาไปได้เยอะมาก ๆ รวมทั้งสามารถสร้าง session ได้มากกว่า 1 session
• API testing ก็ทำได้
• ทำ Visual testing ได้อีกด้วย

โครงสร้างหรือ architecture ของ Playwright ว่าเป็นอย่างไร ?

อีกเรื่องคือ ต่างจาก Selenium อย่างไร

เริ่มจาก Selenium นั้น จะทำงานผ่าน HTTP protocol
สำหรับการส่งคำสั่งต่าง ๆ หรือ command ไปยัง Selenium server
ดังนั้นถ้ามีหลาย ๆ คำสั่ง ก็จะทำการสร้าง HTTP connection ใหม่เสมอ
นั่นคือหนึ่งในปัญหาของความช้า
ต่อมาคือ จะไปยัง browser ใด ๆ ต้องผ่าน Driver อีก
แต่ละ driver ต้องจัดการเรื่อง version อีกด้วย

ส่วน Playwright นั้นจะทำงานผ่าน WebSocket

ดังนั้น command ต่าง ๆ ใน test case นั้น ๆ
จะใช้ connection เดียวกันทั้งหมด
ลดการสร้าง connection ส่งผลให้ทำงานได้รวดเร็วขึ้น
รวมทั้งลดจุดที่ก่อให้เกิดปัญหาลงไป

แสดงการทำงานของ HTTP และ WebSocket ดังรูป

รูปแสดงการทำงานของ Selenium และ Playwright

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

น่าสนใจสำหรับ IDE ใหม่จาก JetBrains ชื่อว่า Fleet
ตอนนี้ออกมาเป็น public preview version แล้ว
เป็น IDE ที่ออกมาเพื่อแก้ไขปัญหาหลาย ๆ อย่าง
ตัวอย่างเช่น กิน resource ของเครื่องอย่างมาก
ทำให้ใช้ไปแล้ว ยิ่งทำงานช้าไปเรื่อย

โดยที่ Fleet นั้น รองรับทั้งการทำงานแบบ standalone
และทำงานร่วมกันเป็นทีมได้อีกด้วย
พร้อมทั้งการเชื่อมต่อกับ environment ต่าง ๆ ได้เลย
อีกทั้งสนับสนุนหลากหลายภาษาอีกด้วย
เห็นในอนาคตจะเชื่อมต่อ cloud ได้

ลอง download มาใช้งานกันดูครับ
น่าสนใจมาก ๆ

เมื่อวันที่ 13 ตุลาคมที่ผ่านมา PostgreSQL 15 ปล่อยออกมาแล้ว
โดยหลัก ๆ เป็นการปรับปรุง performance ของตัว database
เพื่อให้สามารถรองรับการใช้งานที่สูงขึ้น
รวมทั้งความสามารถที่ช่วยให้นักพัฒนาใช้งานได้ง่ายขึ้น

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

• คำสั่ง MERGE ช่วยให้การ insert, update และ delete ข้อมูลง่ายขึ้น

• ปรับปรุงในการบีบอัดข้อมูลของการ backup ทั้งฝั่ง server และ client
• รูปแบบของ log เป็น JSON
• ใช้ ICU collation เป็นค่า default
• เรื่องของ logical partition ทำได้ทั้งระดับ row และ column

มีประโยคที่น่าสนใจด้วย

we can deliver to our users a database that is great for application development and safe for their critical data."

Reference Websites

• PostgreSQL 15 – New Features to Be Excited About

มีเรื่องของ Data architecture ที่ต้องทำ
เลยสรุปเรื่องของ Data architecture ไว้หน่อย
ว่ามีความเป็นมาอย่างไรบ้าง
เราอยู่ตรงไหน และจะไปทางไหนต่อ

เริ่มต้นจากทุกอย่างรวมศูนย์ (Centralized data)

ใครอยากให้งาน data ก็มาเชื่อมต่อ เพื่อนำไปใช้
บ่อยครั้งส่งผลกระทบต่อ performance ของระบบอีก
จึงต้องทำการ scale ด้วยการเพิ่ม หรือ ขยายเครื่อง ก็ว่าไป

แต่การใช้งานดูยุ่งยาก ดูแลยาก จัดการยาก
ทำให้เกิดแนวคิดใหม่ ๆ เพิ่มเข้ามา

ทำระบบ Batching ไปเลย เพื่อดึงข้อมูลที่ต้องการมาใช้งาน

เป็นรูปแบบที่ได้รับความนิยมสูงมาก ๆ
ทีประสิทธฺภาพในการทำงาน ทั้งการ pre-processing และ การจัดเก็บข้อมูล
ให้ตรงตามความต้องการของระบบปลายทาง
และทำงานในช่วงเวลาที่ไม่กระทบต่อต้นทาง

แต่ปัญหาที่ตามมาคือ เรื่องการจัดการโครงสร้างของข้อมูลต้นทาง
ถ้าต้องการเปลี่ยนแปลง จะกระทบต่อ batching ทั้งหมด
และไม่สามารถทำงานแบบ real time ได้
ซึ่งส่งผลต่อความต้องการในปัจจุบัน ที่อยากทำการวิเคราะห์ข้อมูลแบบ real time นั่นเอง

ดังนั้นจึงต้องมีวิธีการแก้ไขออกมาอีก

ระบบที่ทำงานแบบ Real time คือ Streaming system

นั่นคือ เมื่อต้นทางมีการเปลี่ยนแปลงข้อมูล
จะทำการส่งการเปลี่ยนแปลงนั้นออกมา ในรูปแบบที่กำหนด
นำไปไว้ในระบบกลาง เช่น messaging server
จากนั้นระบบใด ๆ ที่ต้องการนำไปใช้งาน
ทั้งแบบ batching และ real time processing

โดยที่จากแนวทางนี้ สามารถนำไป integrate เข้ากับระบบอื่น ๆ ได้ง่ายขึ้น
ทั้ง internal และ external

ส่วนชุดของเครื่องมือ ก็แล้วแต่ว่าต้องการอะไรต่อไปนั่นเอง
ทั้ง Apache Kafka และ Apache Airflow เป็นต้น
หรือเป็นแนวทางของ Big data architecture
ยกตัวอย่างเช่น Lambda architecture ที่มีทั้ง batching และ real time ไปเลย

Reference Websites

• Evolutionary Data Infrastructure
• Big data architecture style