Deno 1.11 ถูกปล่อยออกมาแล้ว
ซึ่งมีทั้ง Docker Image ที่เป็น official ซึ่งมีทั้ง

• Alpine
• Debian
• Centos
• Ubuntu
• Distroless

Deno lint ที่ stable แล้ว ซึ่งทำงานเร็วกว่า ESLint 100%

ทำการ update ได้แล้วนะครับ

อีกอย่างคือ extension ของ Deno ใน VS Code

ซึ่งสามารถ run test ได้แล้ว

หลังจากทำการ review code ระบบงานที่พัฒนาด้วยภาษา JavaScript
พบว่ามีคำถามที่ทำให้งง ๆ ไปพักใหญ่ ๆ คือ

• Double quote ( "" )
• Single quote ('')
• Backtick (``)

ทั้งสามอย่างนี้มันต่างกันอย่างไร
เราควรใช้อะไรดี

ปกติที่ใช้งาน จะทำการ auto format ด้วย Prettier plugin ใน VS Code

ซึ่งจะใช้งาน Double quote โดย default เลย
จะมีค่าเดียวกับ ESLintแต่ตัวอื่น ๆ ก็มีใช้ Single quote เป็นค่า default เช่นกัน
และเราก็สามารถ config ได้เองอีกด้วย

การใช้งานนั้น แนะนำให้เป็นไปในทิศทางเดียวกัน
ไม่ใช่ต่างคนต่างใช้งานตามอารมณ์

แต่ละตัวใช้งานกันอย่างไร ในกรณีไหนบ้าง ?

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

ถ้าข้อมูลเป็นแบบ multiline หรือหลาย ๆ บรรทัด

หรือ template ต่าง ๆ จะใช้งาน Backtick ดังนี้

ถ้าเป็นการเชื่อมต่อ string ชอบใช้ Double quote และ +

แต่หลัง ๆ มาก็เริ่มใช้งาน Backtick ด้วย ดังนี้

ว่าง ๆ ลองทำ benchmark ของการใช้ทั้ง 3 แบบ

เพื่อ assign ข้อมูลว่าเป็นอย่างไร
ผลที่ได้คือ Backtick เร็วสุด
ว่าแต่จะทำไปทำไมนะ 555 ว่างจัดจริง ๆ

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

ในการพัฒนา Flutter App นั้น เรื่องของการทำงานร่วมกัน
ของคนในส่วนต่าง ๆ อย่างราบรื่น ทั้ง tech และ non-tech
หนึ่งในแนวทางคือ BDD (Behaviour Driven Development)
ด้วยการสร้างหรือกำหนดภาษาในการทำงานร่วมกัน
ทั้งส่วนของทีม business, product, development และ QA/Tester
รูปแบบที่เรามักจะเห็นบ่อย ๆ คือ Given-When-Then

ดังนั้นจึงไปดูว่ามี library อะไรให้ใช้ใน Flutter บ้าง ?

ก็ไปเจอ library ชื่อว่า Ogurets
ซึ่งสนับสนุน Null-safty แล้วอีกด้วย ตั้งแต่ version 4.0.0
ทำให้สามารถเขียน test ในรูปแบบของ Gherkin ได้เลย

โดยที่ library จะเตรียม annotation รูปแบบเดียวกับภาษา Java ไว้ดังนี้

• @Given
• @When
• @Then
• @And
• @But
• @Before และ @After สำหรับ Hook ใน test หรือ Test Life Cycle นั่นเอง

ในการพัฒนายังคงแยกเป็น 2 ไฟล์ เช่นเดิมคือ

• Feature file
• Step definition (Stepdef)

สิ่งที่สำคัญคือ การ run test ที่เขียนขึ้นมานั่นเอง

เพียงเท่านี้ก็เขียนชุดการทดสอบแบบง่าย ๆ ได้แล้ว

วันนี้เจอปัญหาเรื่อง _id field ของ document ใน ElasticSearch
พบว่าในการย้ายเอกสารจาก version ที่ต่ำกว่า 5.0 มายัง version เกิน 5.0
อาจจะทำการ dump หรือ reindex ก็ได้
จะเจอ error ที่น่าสนใจคือ "id is too long, must be no longer than 512 bytes but was: 513"

คำถามคือ มีสาเหตุมาจากอะไร ?
เมื่อไปดูเอกสารใน Elasticsearch :: _id field
ก็บอกไว้ว่า ความยาวของ _id ต้องไปเกิน 512 bytes
ดังนั้นถ้ายาวเกิน 512 จะถูก reject

เมื่อไปดูใน source code ก็พบว่าทำการ hard code ไว้เลย

คำถามคือ จะแก้ไขปัญหานี้อย่างไร ?

การแก้ไขไม่ยากคือ การลบ _id ทิ้ง หรือ ทำการ กำหนด _id ให้เป็น null ก่อน
จากนั้นจึงทำการ dump หรือ reindex นั้นเอง
ยกตัวอย่างการเขียน painless script ได้เลย

Reference Websites

https://www.joshmlwood.com/elasticsearch-ids-are-hard/
https://discuss.elastic.co/t/reindexing-failed-validation-failed-1-id-is-too-long-must-be-no-longer-than-512-bytes-but-was-672/185650/4

คำถามที่น่าสนใจเกี่ยวกับ RabbitMQ คือ
แต่ละ message นั้นมีขนาดสูงสุดไม่เกินเท่าไร ?

จำได้ว่าเคยเจอว่า max size น่าจะ 2 GiB
แต่เมื่อไปดูพบว่า มีการเปลี่ยนแปลงตั้งแต่ version 3.8 ขึ้นมา
จะเปลี่ยน max size เป็น 512 MiB
โดยมีค่า default เป็น 128 MiB
ซึ่งสามารถกำหนดได้ใน configuration ชื่อว่า rabbit.max_message_size

ถ้ากำหนดค่า rabbit.max_message_size มากกว่า 512 MiB แล้ว
จะใช้ค่า max size โดยอัตโนมัติ

ทาง Microsoft ได้ปล่อย Visual Studio 2022 Preview 1 ออกมา
โดยใน release นี้จะมีเฉพาะ 64 bit เท่านั้น
ให้ลองใช้งานและเรื่องของ scalability ของ software
เช่นการทำงานกับ project ที่มีความซับซ้อน และใช้งานเป็นเวลานาน ๆ

ลองไป Download มาลองกันดู
และสามารถดู Road Map ได้อีก

วันนี้เห็นหนังสือที่น่าสนใจคือ 100 Go Mistakes: How to Avoid Them
ทาง email โดยช่วงนี้ลด 40% อีกด้วย
ว่าด้วย 100 เรื่องที่มักจะใช้งานผิดพลาดในภาษา Go
เพื่อช่วยให้ Go Developer ได้เรียนรู้
เพื่อรู้และเข้าใจ รวมทั้งหลีกเลี่ยงความผิดพลาดที่อาจะเกิดขึ้นได้

ผู้เขียนหนังสือเล่มนี้ เริ่มจากการเขียนบทความเรื่อง
The Top 10 Most Common Mistakes I’ve Seen in Go Projects

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

Basics:

• Unintended variable shadowing
• Ignoring logging side effects
• Comparing values incorrectly
• JSON handling mistakes
• Formatting network addresses for IPv4 solely
• Handling enums incorrectly
• Not using defer
• Ignoring how defer arguments and receivers are evaluated
• Not closing resources
• Creating confusion with octal literals
• Neglecting integer overflows
• Not understanding floating-points
• Not using linters

Code organization:

• Writing nested code
• Misusing init functions
• Always using getters and setters
• Interface pollution
• Interface on producer-side
• Returning interfaces
• interface{} says nothing
• Not using the functional options pattern
• Project misorganization
• Creating utility packages
• Ignoring package name collisions
• Missing code documentation

Data structures:

• Not understanding slice length and capacity
• Inaccurate slice initialization
• Creating conflicts using slice append
• Not making slice copy correctly
• Slice and memory leaks
• Being confused about nil vs. empty slice
• Not properly checking if a slice is empty
• Inaccurate map initialization

Control structures:

• Ignoring that elements are copied in range loops
• Ignoring how arguments are evaluated in range loops
• Ignoring the impacts of using element pointers in range loops
• Making wrong assumptions during map iterations
• Ignoring how the break statement work
• Using defer inside a loop
• Forgetting about the switch fall through behavior

String:

• Not understanding the concept of rune
• Inaccurate string iteration
• Misusing trim functions
• Under-optimized strings concatenation
• Useless string conversion
• Substring and memory leaks

Functions and methods:

• Not knowing which type of receiver to use
• Not using named result parameters
• Unintended side-effects with named result parameters
• Returning a nil receiver
• Using a filename as a function input

Error management:

• Panicking
• Ignoring when to wrap an error
• Comparing an error type inefficiently
• Comparing an error value inefficiently
• Handling an error twice
• Ignoring an error
• Not handling defer errors

Concurrency:

• Mixing concurrency and parallelism
• Concurrency isn’t always faster
• Misunderstanding Go contexts
• Not understanding what a race condition is
• Append is not always race free
• Goroutines and loop variables
• Channel receive/send and context
• Not using directional channels
• Not using notification channels
• Closing channels inaccurately
• Buffered channel capacity and magic number
• Not using nil channels
• Passing a struct containing a sync field
• Exporting concurrency primitives
• Not using sync.RWMutex
• Misusing sync.WaitGroup
• Forgetting about sync.Cond
• Not using errgroup package
• Not using runtime.NumCPU()
• time.After and memory leak
• Ignoring false sharing

Testing:

• Forgetting to fail a test
• Not using table-driven tests
• Not using test build flags
• Not using the race option
• Not checking goroutines leaks
• Writing inaccurate benchmarks

Optimization:

• Byte slice and map key
• Pointers everywhere
• Expecting that a pointer address is constant
• Structure alignment
• Inlining

Production:

• Using the default http client and server
• Go and Docker
• Not exposing a pprof endpoint
• Generating random numbers in security-sensitive applications

ลองหาอ่านกันดูครับ
น่าจะมีประโยชน์สำหรับการพัฒนาระบบด้วยภาษา Go

มีคำถามเกี่ยวกับการทำอะไรซ้ำ ๆ เพื่อปรับปรุงการทำอะไรบางอย่าง
จึงนึกถึงเรื่องของการปรับปรุงเพิ่มขึ้นทุกวันเพียง 1 %
หรือเราจะต่อรอง หรือ หยวน ๆ ไม่ทำไปเรื่อย ๆ

ซึ่งเขาแนวทางของ 1.01 กับ 0.99

1.01 คือ เพิ่มเพียง 0.01 ต่อวัน ในทุก ๆ วัน
หรือจะ 0.09 คือ ลดเพียง 0.0.1 ต่อวัน ในทุก ๆ วัน

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

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

คำแนะนำประกอบไปด้วย

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

วันนี้ดีขึ้นกว่าเมื่อวานหรือไม่ ?

ในการพัฒนาระบบงาน มักจะมีการใช้งาน service อื่น ๆ
ผ่าน HTTP protocol ด้วยเสมอ
เราจะเรียก service เหล่านั้นว่า dependency

บ่อยครั้งที่การ integration test มักจะมีปัญหา
ดังนั้นจึงต้องทำการจำลอง service เหล่านั้นขึ้นมา
เพื่อให้เราสามารถพัฒนาและทดสอบไปได้อย่างราบรื่น
หนึ่งในเครื่องมือที่น่าสนใจและลองใช้งานหน่อยคือ Smocker

Smocker นั้นสามารถทำได้ดังนี้

• Static mock server
• Dynamic mock server
• Proxy

โดยที่ Smocker มี use case ในการใช้งานดังนี้

1. ทำตัวเป็น API gateway

เพื่อทำการจำลอง service ที่ต้องการ
รวมทั้งสามารถเรียกใช้งาน service จริงได้อีก

2. ทำตัวเป็น http proxy ก็ได้

อีกอย่างที่น่าสนใจคือ พัฒนาด้วยภาษา Go นะ

แถมมีหน้า UI ในการจัดการแบบง่าย ๆ อีกด้วย

การติดตั้งก็มีแบบง่าย ๆ หลายแบบ

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

ลองสร้าง Mock API ในรูปแบบของ YAML แบบง่าย ๆ
ซึ่งเป็นแบบ Static mock server

นำไปใส่ผ่าน UI ใน port 8081 ได้เลย

สามารถใช้งานผ่าน port 8080 ได้ดังนี้

ใช้งานง่ายดี ไว้ไปลองแบบ dynamic และ proxy กันบ้าง
น่าจะตอบโจทย์หลาย ๆ เรื่องได้อีกมาก

ปัญหาที่พบเจอ หรือ use case ที่ต้องทำในระบบงาน เป็นดังนี้
ต้องการข้อมูลของ Top 10 user ที่ทำการสั่งซื้อสินค้ามากที่สุด
โดยการทำงานปกติมีขั้นตอนดังนี้

• ทำการเพิ่มข้อมูลการสั่งซื้อของผู้ใช้งาน
• ทำการนับจำนวน order ของผู้ใช้งานแต่ละคนไปเรื่อย ๆ โดยใน counter
• ทำการดึงข้อมูลผู้ใช้งานที่สั่งมากที่สุด 10 คน (Top 10 และ sorting)

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

ดูเหมือนว่าจะปกติ แต่พบว่ามีปัญหาเมื่อจำนวนคนใช้งานมากขึ้น

ต้องดึงข้อมูลมากขึ้นdatabase ถูกใช้งานมากขึ้น
ดังนั้นจึงลองหาวิธีอื่น ๆ มาแก้ไขหน่อย
หนึ่งในวิธีที่ชอบใช้คือ Redis มาเก็บข้อมูล

แนวคิดในการใช้งานคือ

ทุกครั้งที่มีการเพิ่ม order เข้ามาของแต่ละ user
ต้องทำการเพิ่มจำนวนการสั่งซื้อของ user ด้วยเสมอ
นั่นคือ 2 operation เกิดขึ้นด้วยการเรียก Redis ครั้งเดียว
เพราะว่า ไม่ต้องการส่ง command มายัง redis 2 ครั้ง
จึงคิดว่า เขียน Lua script ไปใน Redis กันไปเลย
จะช่วยให้การทำงานง่ายขึ้นมา

โดยสามารถ Run หรือ เก็บ Lua script ใน Redis ได้เลย
แต่การเก็บไว้ใน Redis จะมี performance ดีกว่า

ตัวอย่างการใช้งานเป็นดังนี้

Data structure ที่ใช้ใน use case นี้คือ Sorted Set
เพื่อเก็บข้อมูลที่ไม่ซ้ำกัน รวมทั้งทำการเรียงลำดับจากมากไปน้อยให้เลยโดยที่ command ที่ใช้คือ

• ZADD สำหรับเพิ่มข้อมูล
• ZRANGE สำหรับดึงข้อมูล
• เมื่อเพิ่มข้อมูลก็ทำการ INCR เพื่อนับจำนวนไปเลย

เขียน Lua script ง่าย ๆ ได้ดังนี้

คำอธิบาย

• ทำการส่ง 2 มา 2 key ประกอบไปด้วย ข้อมูลของ order และ counter ของแต่ละ user
• ถ้าเพิ่ม order ใหม่เข้ามา จะทำการเพิ่มข้อมูลด้วย ZADD และเพิ่มข้อมูลจำนวน order ด้วย INCR

ลองใช้งานผ่าน docker นิดหน่อย

เพียงเท่านี้ก็สามารถจัดการปัญหาด้วย Redis ได้แล้ว
ได้ลองเขียน Lua script เพิ่มด้วย สนุกดี

วันนี้ลองใช้งาน ECMAScript Private Fields ดูหน่อย
พบว่ามีความรู้สึกแปลก ๆ มาก
เนื่องจากใช้ # มาใส่ข้างหน้า field/property นั้น ๆ
ซึ่งทั่วไปมักจะเป็น comment ในภาษาหรือเครื่องมืออื่น ๆ

โดยที่ private field/property

• ไม่สามารถเข้าถึงจากภายนอก class ได้
• ไม่สามารถ override ได้
• ต้องทำการประกาศก่อนใช้งานเสมอ

ตัวอย่างการใช้งาน private field/property ใน class

ทางทีมพัฒนาจาก Spring.io เพิ่งปล่อย Spring Cloud Square M1 (Milestone 1)
ออกมาให้ทดลองใช้งาน
โดยเป็นความสามารถใน project Spring Cloud LoadBalancer (Client-side LoadBalancer )
ทำงานได้แบบทั้ง Round-Robin และ Random

ซึ่งนำ library จาก square มา integrate ประกอบไปด้วย

• OkHttp
• Retrofit

ทั้งคู่เป็น HTTP client library นั่นเอง
โดยสนับสนุนการทำงานแบบ non-blocking IO
นักพัฒนา Mobile app ด้วย Android น่าจะคุ้นเคยกันดี
ซึ่งลด code ที่ต้องเขียนมาเป็นแบบ declaration มากยิ่งขึ้น
อารมณ์คล้าย ๆ การใช้งาน Spring Data project

แต่ก่อนหน้านี้ทางสาย Spring Developer น่าจะคุ้นเคยกับ

• RestTeamplate
• Feign หรือ OpenFeign

ตัวอย่างการใช้งานแบบง่าย ๆ

Reference Websites

• Introduction to Spring Cloud Square

พอดีเจอปัญหาในการใช้งาน package
ในระบบงานที่ใช้ภาษา Go
โดยเป็น package มาจาก module อื่น ๆ
ซึ่งแยกออกไปเป็นอีก project หนึ่ง
ดังนั้นเพื่อให้ง่ายต่อการใช้งาน
จึงอยากจะทำแบบ Local package ไปเลย

แน่นอนว่าสำหรับ Go module เตรียมวิธีการไว้ให้เราแบบง่าย ๆ
จึงจดบันทึกการทำได้นิดหน่อย

ทำการ config ในไฟล์ go.mod ของ project หลัก
เพื่อทำการ reference และ replace ไปยัง package/module นั้น ๆ
แบบตรง ๆ ไปได้เลย ดังนี้

ตัวอย่างของการอ้างถึง package จาก module group02

เพียงเท่านี้ก็สามารถใช้งานได้แล้ว
ง่ายมาก ๆ

พอดีเห็น Diagram สวย ๆ ซึ่งอยู๋บนพื้นฐานของ AWS diagram
จึงลองไปค้นหาว่าทำมาอย่างไร จากที่ไหน
ก็เลยไปเจอว่า เขาสร้างจาหห Cloudcraft

โดยสามารภใช้งานผ่าน web ได้เลย มี editor สำหรับการออกแบบง่าย ๆ
แต่อยู๋บนพื้นฐานของ AWS นะ
น่าจะช่วยลดเวลาในการสร้างเอกสารลงไปได้เยอะพอสมควร
ลองใช้กันดู

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

เรื่องแรก การตั้งเป้าหมายที่ชัดเจน

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

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

เรื่องที่สอง ต้องรู้ว่าจะหาคำตอบในปัญหา หรือ คำถามต่าง ๆ อย่างไร ?

คงไม่ต้องสอนแล้วว่า ต้องไปหาที่ไหน
ทั้ง google, stack overflow, facebook, twitter และ reddit เป็นต้น
แต่สิ่งที่สำคัญคือ keyword ในการหา

รวมทั้งภาษาอังกฤษ สำคัญมาก ๆ
เพราะว่าเอกสารต่าง ๆ ที่ update สุด ๆ คือภาษาอังกฤษนี่แหละ
อย่าไปรอหรืออ่านแต่ภาษาไทย
เพราะว่า อาจจะช้าหรือไม่ update แล้วก็ได้

แต่ก่อนถามควรทำการบ้านมาให้ดี
เขียนอธิบายให้ชัดว่าทำอะไรมาบ้าง
ติดปัญหาอะไรบ้าง
ถ้ามี code, config หรือ error message อะไร
รวมทั้ง environment ต่าง ๆ ที่ใช้งาน
ก็เขียนไปให้ครบถ้วน

หรือต้องรู้ว่าจะต้องถามใคร เมื่อใด และ อย่างไร
ตรงนี้ต้องฝึกฝน

เรื่องที่สาม การแบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ

เนื่องจากปัญหาใหญ่ ๆ มันแก้ไขยากไป
ดังนั้นหัดแบ่งออกมาเป็นปัญหาย่อย ๆ
เพื่อให้ง่ายต่อการแก้ไข
และช่วยให้ focus กับงานหรือปัญหานั้น ๆ

เมื่อเจอปัญหาต้องเข้าไปให้ถึง root cause เสมอ
รวมไปถึงการตัดสิ่งที่ไม่จำเป็นออกไปด้วยเช่นกัน

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

เรื่องที่สี่ ปรับปรุงเรื่องของการสื่อสาร รวมทั้งการแบ่งปัน

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

เรื่องที่ห้า เรียนรู้อยู่อย่างสม่ำเสมอ

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

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

เมื่ออ่านแล้ว ก็ลงมือทำได้แล้ว
ถ้าไม่ลงมือทำ จะพัฒนาได้อย่างไร

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

GitOps คืออะไร

เป็นรูปแบบหนึ่งของการสร้างระบบ Continuous Delivery (CD)
สำหรับ cloud native application
มีเป้าหมายหลักคือ developer-centric experience
นั่นคือใช้เครื่องมือที่ทีมพัฒนาถนัดหรือใช้งานอยู่แล้ว
ทั้ง Git และ CD tool ต่าง ๆ

แนวคิดหลักคือ การเก็บสิ่งต่าง ๆ ที่จำเป็นต่อการสร้าง

• Infrastructure
• Environment
• Automation process

ไว้ใน Git repository
ดังนั้นถ้าต้องการ deploy ระบบงานใน version ใหม่
ก็เพียงทำการ update ข้อมูลใน Git repository เท่านั้น
จะ trigger ให้การทำงานแบบอัตโนมัติขึ้นมาตาม pipeline ที่กำหนดไว้

ทำไมต้องใช้งาน GitOps

• ง่ายต่อการ deploy ทำให้ deploy ได้เร็วและบ่อยขึ้น
• เมื่อเกิดปัญหา สามารถ recovery กลับมาได้ง่ายและเร็วขึ้น (git revert)
• ง่ายต่อการจัดการเรื่องของ credentail ต่าง ๆ เพราะว่า GitOps จะทำงานใน environment นั้น ๆ เลย ส่วนทีมพัฒนาไม่สามารถเข้าถึง environment ต่าง ๆ ได้
• ทุก ๆ การเปลี่ยนแปลงจะอยู่ใน Git repository ทำให้เราเก็บ history ของการ deploy ไว้ได้ทั้งหมด ตอบโจทย์เรื่องของการ audit อย่างมาก และรู้ทั้งหมดว่าเกิดอะไรขึ้นบ้าง
• สิ่งต่าง ๆ จะอยู๋ใน Git repository ทำให้สามารถ share ความรู้เกี่ยวกับการทำงานได้เลย ไม่ต้องกระโดดไปมาหลาย ๆ ที่ หลาย ๆ ระบบ

GitOps ทำงานอย่างไร

เริ่มจากการทำงานจะทำงานผ่าน Git repository
แบ่งออกเป็น 2 repository คือ

• application คือ source code ต่าง ๆ ของระบบงาน และ manifest file ต่าง ๆ ในการ deploy ระบบ
• environment configuration คือ configuration สำหรับการสร้าง infrastructure ของ environment ที่ใช้ deploy ระบบงาน เช่น messaging broker และ monitoring tool เป็นต้น รวมไปถึงเรื่องการจัดการ version อีกด้วย

การทำงานมีทั้งแบบ Push และ Pull deployment

Push deployment

คือรูปแบบการทำงานปกติของ CI/CD tool ต่าง ๆ เช่น

• Jenkins
• CircleCI
• TravisCI
• Cloud build ใน GKE

การทำงานง่าย ๆ คือ
เมื่อ Git repository มีการเปลี่ยนแปลงก็จะ trigger ให้ pipeline ทำงาน
ไปจนถึง trigger ให้ทำการ deploy
มีขั้นตอนการทำงานดังรูป

ตัวอย่างการทำงานของ Google cloud build

Pull deployment

มีความต่างตรงการ deploy
แทนที่จะทำการ trigger เพื่อ deploy เมื่อมีการเปลี่ยนแปลง
จะใช้แนวคิดของ operator เข้ามาช่วยในการทำงาน

ซึ่ง Operator จะคอยเฝ้าดูว่า
state หรือ version ของ environment repository
กับ state ของระบบที่ทำงาน deploy นั้น
เหมือนหรือต่างกันหรือไม่
ถ้าต่างกันก็จะทำการ deploy ให้ทันที

รวมทั้ง operator จะอยู่ใน enviroment เดียวกันกับการที่จะ deploy นั่นเอง
เพื่อลดปัญหาเรื่องของ permission แบบไม่ปกติ
จาก push deployment (God-mode !!)
อีกทั้งตัดปัญหาเรื่องการจัดการ credential ไปได้
แสดงดังรูป

และช่วยให้ง่ายต่อการ deploy ระบบงานในหลาย ๆ Enviroment อีกด้วย

จากแนวคิดต่าง ๆ เหล่านี้ ทำให้เกิด implementation ต่าง ๆ ตามมา

เช่น GitOps operator ใน Kubernetes cluster เช่น

• ArgoCD
• FluxCD
• Jenkins operator

ตัวอย่าง GitOps บน Kubernetes cluster ซึ่งเป็น Pull deployment

DevOps คือการเปลี่ยน culture ขององค์กร เพื่อช่วยให้คนทำงานร่วมกันได้ดีขึ้น

ส่วน GitOps คือเทคนิคในการสร้างระบบ Continuous Delivery
โดยทั้งคู่จะมีแนวคิดเหมือนกันคือ

• Automation process
• Self-service infrastructure

ดังนั้นการสร้าง GitOps workflow จะง่ายขึ้นเมื่อนำ DevOps มาปรับใช้งานแล้ว

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

Delta Lake คืออะไร ?

เป็น open-source storage layer ที่จะทำงานอยู่บน existing database/data store
ไม่ว่าจะเป็น data lake, RDBMD และ NoSQL ใด ๆ ก็ตาม
เพื่อเพิ่มความสามารถอื่น ๆ ที่จำเป็นต่อการใช้งาน
ยกตัวอย่างเช่น
กลุ่มงานสาย AI และ Machine Learning เป็นต้น

รวมทั้งรองรับข้อมูลทั้งแบบ realtime, stream และ batch processing
พยายามสนับนุน ACID อีกด้วย
แต่ยังคงประสิทธิภาพของการดึงข้อมูล

โดย Delta Lake จะมี schema 2 รูปแบบคือ

• Schema-on-read
• Schema-on-write

แสดงดังรูป

เป้าหมายของ Delta Lake มีอะไรบ้าง

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

รวมทั้งเรื่องความถูกต้องของข้อมูลขาเข้า
ทั้งจาก batching และ stream ซึ่งเป็นแนวทางของ Lambda architecture เลย
เมื่อมีการเขียนทับข้อมูลเดิม (ลบและเขียน) แล้ว
แต่เกิดข้อผิดพลาดขึ้นมาข้อมูลเหล่านั้นจะไม่เห็นในการดึงหรือ query ข้อมูล

รองรับการทำงานพร้อม ๆ กันได้ดีกว่าแนวทางของการ lock หรือ optimistic lock
อีกอย่างมีการตรวจสอบ schema ของข้อมูลอีกด้วยหรือ schema validation นั่นเอง
จะทำงานก่อนจะ commit ข้อมูลนั้น ๆ
ทำให้ไม่ทำการเขียนทับข้อมูลที่มี schema ต่างกันกัน

แต่ก็สนับสนุนเรื่องของ schema evolution
นั่นคือ การเปลี่ยนแปลง schema-on-write
จะทำการ configuration เพื่อให้สามารถทำการ merge schema ได้

ในส่วนการจัดการ version ของ data ได้นำ Time travel เข้ามาช่วย

เป็นอีกแนวทางที่น่าสนใจ
ศึกษากันไว้ดูครับ

Reference Websites

https://towardsdatascience.com/why-is-delta-lake-becoming-increasingly-popular-1e45c29cc7d2

ตั้งแต่ปีที่แล้ว ทาง GitHub ได้แจ้งมาว่า
จะยกเลิกการ authentication ด้วย password เข้าใช้งาน GitHub
โดยไปใช้งาน token-based authentication แทน
ยกตัวอย่างเช่น

• Personal access
• OAuth
• GitHub App

จะเริ่มตั้งแต่วันที่ 13 สิงหาคมนี้
ดังนั้นเตรียมจัดการได้แล้ว

ผลกระทบที่เกิดขึ้นคือ

• Git command line
• Desktop application ที่ใช้งาน Git แต่ GitHub Desktop ยังใช้ได้
• App และ service ต่าง ๆ ที่เข้าใช้งาน GitHub ด้วย password

ไปใช้งาน authentication เหล่านี้แทน

• Two-factor authentication
• SSH-based authentication

ในการสร้าง Dashboard ใน Grafana นั้นต้องสร้างในรูปแบบของ JSON
ซึ่งมีตัวอย่าง และ community ให้เยอะมาก ๆ
แต่ปัญหาคือ การสร้าง ทดสอบ และดูแลไม่ง่ายเลย

จัดการ version ของ dashboard น่าจะอยู่ใน version control ด้วย
ควรต้องมีการ review code ของการสร้าง dashboard
สามารถ integrate กับระบบ CI/CDได้ง่าย
สามารถ reuse ในรูปแบบ component ได้

แนวทางแก้ไขปัญหาของ Grafana dashboard ที่น่าสนใจคือ

Dashboard as a Code ด้วย Grafonnet
ซึ่งใช้งานร่วมกับ

• jsonnet คือ JSON template language
• grafonnet คือ Grafana jsonnet library

ทำการติดตั้งตามเอกสาร
จากนั้นทำการสร้าง project ของ dashboard ดังนี้

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

ขั้นตอนที่ 2 สร้างไฟล์ run.sh สำหรับส่งไฟล์ JSON ของ dashboard ไปยัง Grafana server

ขั้นตอนที่ 3 ทำการสร้างไฟล์ JSON จาก grafannet

จากนั้นไปดูผลการทำงานที่ Grafana server
จะเจอ Dashboard ที่เราสร้างขึ้นมา ดังรูป

น่าจะสนกับ Dashboard as a Code มาก ๆ

จาก release note ของ Vs code version 1.58
ที่ปล่อยออกมาเมื่อเดือนที่ผ่านมานั้น
พบว่ามีความสามารถที่น่าสนใจ และ รบกวนการใช้งาน
ยกตัวอย่างเช่น การใช้งาน Teminal ใน editor ได้เลย
ไม่ต้องไปสร้าง tab ในส่วนของ terminal อีกต่อไป

โดยสามารถเข้าไปที่ส่วนของ Command Palette...
และค้นด้วยคำว่า Create Terminal in Editor Area
เท่านี้ก็สร้าง terminal ได้แล้ว
แสดงตัวอย่างการใช้งานดังรูป

ส่วน feature ที่รบกวนมาก ๆ คือ Workspace Trust นั่นเอง
แต่จากปัญหานี้ ได้เพิ่มการ setting ในส่วนนี้ให้เพิ่ม
ช่วยลดการรบกวนไปได้เยอะ