Quantcast
Channel: cc :: somkiat
Viewing all 2000 articles
Browse latest View live
↧

มาลองเขียน comment รูปแบบ Markdown ใน Java 23 กัน

June 7, 2024, 10:09 pm
$
0
0

Java 23 ถูกปล่อยออกมาให้ทดลองใช้งาน
โดยที่มีความสามารถหลายตัวที่น่าสนใจ
หนึ่งในนั้นคือ JEP 467 :: Markdown Documentation Comments
ช่วยให้เขียน comment ในรูปแบบของ markdown ได้
ซึ่งสุดท้ายก็ไป generate ออกมาเป็น JavaDoc นั่นเอง
มาลองใช้งานกันดู

ก่อนหน้านี้เขียนในรูปแบบของ HTML ร่วมกับ JavaDoc tag
ซึ่งอาจจะยากต่อการอ่านและเขียน
แต่ถ้าเปลี่ยนมาเขียนในรูปแบบของ markdown จะยากขึ้นไหมนะ
มาเขียนกันดูหน่อย

ก่อนอื่นติดตั้ง Java 23 ก่อนนะ
มาเริ่มเขียนกัน

รูปแบบของการเขียนเป็นดังนี้

  • เริ่มเขียน comment ด้วย /// ในทุก ๆ บรรทัด
  • รูปแบบของ markdown ตาม spec นี้
[gist id="42d503ff8d13e90a169ac6ed4db3849a" file="Demo.java"]

ทำการ generate JavaDoc

[gist id="42d503ff8d13e90a169ac6ed4db3849a" file="1.txt"]

ได้ JavaDoc ในรูปแบบ HTML ดังนี้

ใน Spring Boot ก็มีการเปิด issue เรื่องนี้เข้าไปแล้วด้วย
ลองเล่นกันดูครับ

↧
Search

ทำความรู้จักกับ Grafana Alloy

June 8, 2024, 9:04 am
$
0
0

เห็นทาง Grafana ปล่อย Grafana Alloy ออกมา ซึ่งเปลี่ยนมาจาก Grafana Agent
ซึ่งทำหน้าที่เหมือนกับ OpenTelemetry collector
สำหรับรับ และ ส่งข้อมูลของ telemetry data ทั้ง log, metric และ tracing นั่นเอง
จากนั้นทำการส่งไปยังระบบต่าง ๆ ตามที่ต้องการ
โดยที่ Grafana Alloy นั้นทำงานได้ทั้งแบบ push และ pull
แถมทำการ filter หรือ transform ข้อมูลที่เข้ามาได้อีก
และทำมาแทนที่ OpenTelemetry collector หรือ Grafana agent นั่นเอง

ที่สำคัญสนับสนุนทั้ง on-prem, on-cloud หรือ hybrid ก็ได้
การใช้งานมีหลายรูปแบบ
ยกตัวอย่างเช่น

แบบ centralized service

แบบติดตั้งที่ Host

แบบ sidecar container

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

เริ่มด้วยการติดตั้งผ่าน Docker

[gist id="1026411bd44a1a70dc019191d11744ca" file="docker-compose.yml"]

ทำการ start และเข้าไปยัง dashboard = http://localhost:12345/
แสดง component ต่าง ๆ ดังนี้

ดู graph จากการ config สวย ๆ

จากนั้นก็ไป config ในการใช้งานกับระบบต่อไป ..
ลองใช้งานกันดูครับ

↧
↧

MSTest 3.4 สนับสนุน WinUI และ Playwright แล้ว

June 8, 2024, 10:12 pm
$
0
0

ทาง Microsoft ได้ปล่อย MSTest 3.4 ออกมา สำหรับการทดสอบระบบงาน
โดยเพิ่มความสามารถต่าง ๆ เข้ามา เช่น

  • สนับสนุนการทดสอบกับ WinUI
  • สนับสนุนการทดสอบกับ Playwright ไม่ต้องมา config เอง
  • สนับสนุน Aspire
  • เพิ่ม [Timeout] เข้ามาใน test สำหรับกำหนด timeout ของการทดสอบ หรือใช้ร่วมกับ [ClassCleanup] ได้
  • เพิ่ม STA Thread (Single Thread Apartment) เข้ามาสำหรับการทำ UI test
  • ทำการปรับปรุง MSTest.Analyzers เพื่อช่วยแก้ไขปัญหาของการทดสอบ ให้มีมาตรฐานมากขึ้น ตาม design rules ทั้ง 9 ข้อ

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

เริ่มด้วยการสร้าง project (ใช้งาน dotnet 9 preview 4)

[gist id="62c17d1ea64b0a4af32722f0172a37d4" file="1.txt"]

จากนั้นเข้าไปดู config ของ project จะทำการ enable Playwright มาให้เลย
เปลี่ยนมาใช้ version 3.4 ด้วย

[gist id="62c17d1ea64b0a4af32722f0172a37d4" file="demo.csproj"]

ปิดด้วยการเขียน test case กันเลย

[gist id="62c17d1ea64b0a4af32722f0172a37d4" file="DemoTest.cs"]

จากนั้นทำการ run test
แต่ต้องติดตั้ง Powershell ก่อนนะครับ
เนื่องจากใช้สำหรับการติดตั้ง Playwright และ Driver + Web Browser ในการทดสอบ

[gist id="62c17d1ea64b0a4af32722f0172a37d4" file="2.txt"]

เพียงเท่านี้ก็ใช้ได้แล้วครับ
ลองใช้งานกันดู สำหรับการทดสอบแบบง่าย ๆ

↧

สรุปจากการอ่านบทความเรื่อง Redesigning Pinterest’s Ad Serving Systems with Zero Downtime

June 9, 2024, 10:12 pm
$
0
0

หลังจากการอ่านบทความเรื่อง Redesigning Pinterest’s Ad Serving Systems with Zero Downtime
เป็นการ redesign และ rewrite ระบบ Ads-serving platform ของ Pinterest
เป็นระบบที่สร้างรายได้ให้บริษัทอย่างมาก
แต่ระบบที่ใช้งานมี technical debt เยอะ และ ซับซ้อนสูงมาก ๆ
ทำให้ระบบมีปัญหาต่อการ scale อย่างมาก ล่มบ่อย
รวมทั้ง business goal ที่เยอะขึ้น

ปัญหาหลัก ๆ ของระบบ ประกอบไปด้วย

  • Infrastructure และ business logic ผูกมัดกันอย่างมาก ดังนั้นยากต่อการเปลี่ยนแปลง
  • การจัดการโครงสร้างของระบบไม่ดี ไม่มีการจัดการ module ที่ดี ทำให้เกิด conflict ในการแก้ไข รวมทั้งการก่อให้เกิด bug ได้ง่าย ๆ
  • ไม่การันตีเรื่องความถูกต้องของข้อมูล
  • มีปัญหาในการทำงานแบบ multi-thread เพราะว่าไม่มี framework ที่ชัดเจน ทั้งเรื่อง error handling และ race condition เมื่อเกิดปัญหาทำให้ยากต่อการจัดการ

ดังนั้นจึงตัดสินใจที่จะทำการเขียนระบบขึ้นมาใหม่ !!
โดยมี working group เข้ามาช่วยกันคิด และ ตัดสินใจว่า

  • ทำการเขียนใหม่ด้วย Java ดีกว่าการ refactor code เดิม
  • ใช้ Java เนื่องจากระบบส่วนใหญ่ก็ใช้

ในการพัฒนาระบบใหม่นั้นมีสิ่งที่น่าสนใจคือ Engineering Design Principles

เพื่อสร้างระบบที่ช่วยให้ business โตอย่างรวดเร็ว
และลดปัญหาที่เกิดขึ้นบน production
ซึ่งมีแนวทางดังนี้

  • ง่ายต่อการเพิ่มส่วนขยาย (Extensible) และง่ายต่อการ deprecated หรือเอาส่วนที่ไม่ใช้งานออกไป (Design-for-deprecation)
  • Separation of Concern ทำการแยก infrastructure กับ business logic ออกจากกัน ด้วยการกำหนด high level abstraction ขึ้นมา รวมทั้งแยกแต่ละส่วนเป็น module ให้แต่ละทีมดูแล แยกกันอย่างชัดเจน
  • Safe-by-design การออกแบบต้องปลอดภัยจากเรื่องของการทำงานแบบ concurrency และ ความถูกต้องของข้อมูลเป็นหลัก ทำให้มั่นใจว่าจะไม่เกิด race condition รวมทั้งการจัดการ log ของการทำงาน
  • Development velocity กอบการทำงานใหม่ต้องสนับสนุนการพัฒนา มี environment ที่ดีต่อการพัฒนา รวมทั้งมีเครื่องมือในการ debug และ analyze การทำงานและปัญหาแบบง่ายๆ อีกด้วย (สำคัญมาก ๆ)

ต่อการเรื่องของ Design Decision มีการวางแนวทางไว้ดังนี้

เริ่มด้วยการตอบ 2 คำถามนี้ก่อนคือ

  • จัดการ code ของแต่ละทีมอย่างไร ไม่ให้กระทบทีมอื่น ๆ
  • จัดการข้อมูลอย่างไร ให้ข้อมูลยังคงความถูกต้อง

ถ้าจะตองคำถามเหล่านี้ได้ จำเป็นต้องรู้และเข้าใจ
ในเรื่องของ business logic ของระบบ
ในเรื่องการจัดการข้อมูลที่จำเป็นต่อการใช้งาน
รวมทั้ง high level ของ abstraction layer เพื่อลดผลกระทบต่าง ๆ ลงไป
จึงทำให้เกิด design decision ขึ้นมา 2 ข้อคือ

  • Code ของระบบจะมีการสร้าง Directed Acyclic Graph (DAG) จาก graph framework ที่สร้างขึ้นมา เพื่อแสดงความสัมพันธ์ของ code เพื่อแสดงความสัมพันธ์ของ code ซึ่งช่วยในการตัดสินใจอย่างมาก และเห็นผลกระทบที่ชัดเจน
  • ทำการสร้าง data model เพื่อส่งเข้าไปยังระบบ graph ที่ทำงานแบบ thread-safe (อ่านแล้วไม่แน่ใจว่าเป็นแบบไหน)

ผลจากการ rewrite ระบบใหม่นั้น พบว่า

  • สามารถ deliver product ได้รวดเร็วขึ้น และ ปลอดภัยมากยิ่งขึ้น
  • ความพึงพอใจของทีมพัฒนาดีขึ้นอย่างมาก
  • ระบบงานสามารถ run บน infrastructure ที่ดี ซึ่งช่วยลดค่าใช้จ่ายไปได้เยอะ

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

↧

Tips :: การจัดการ tab ใน web browser ด้วย Cypress

June 11, 2024, 2:02 am
$
0
0

คำถามเกี่ยวกับการใช้งาน Cypress

ถ้าในระบบ web application ที่ทำการทดสอบแบบอัตโนมัติด้วย Cypress
มีการกด link หรือ ปุ่ม แล้วระบบทำการเปิด window หรือ tab ใหม่ขึ้นมา
เราจะทำการตรวจสอบการทำงานอย่างไรได้บ้าง ?

คำตอบเป็นดังนี้

ก่อนอื่นต้องดูก่อนว่าทำการเปิด window หรือ tab เหล่านั้นอย่างไรบ้าง
ยกตัวอย่างเช่น เป็นการเปิด link แบบเปิดหน้าใหม่ขึ้นมา คือ target=blank
ซึ่งถามเขียน test case แบบปกติ จะเกิด error
เนื่องจาก cypress ไม่ได้ switch หรือเปลี่ยนไปยัง tab ใหม่ !!
เขียนได้ดังนี้

[gist id="291123784047e236542416dffe56d197" file="1.txt"]

การแก้ไขง่าย ๆ คือ การ remove attribute target ออกไปก่อนทำการ click เท่านั้นเอง
แก้ไขปัญหาแบบน่าเกลียดสุด ๆ แต่ทำได้ง่าย ๆ ดังนี้

[gist id="291123784047e236542416dffe56d197" file="2.js"]

ถ้าเป็นการกดปุ่ม แล้วเปิด tab/window ใหม่ ทำอย่างไร ?

สามารถทำได้หลายแบบ เช่น
ทำการตรวจสอบว่า หลังจากที่กดปุ่มแล้ว ทำการเปิด tab หรือ window ใหม่หรือไม่
ด้วยการทำ stub ของ window.open() นั่นเอง
ขึ้นอยู๋กับการ implement อีกด้วย
จากนั้นตรวจสอบว่า ถูกเรียกหรือไม่ และเปิดไปยัง url ของหน้าที่ต้องการหรือไม่
ซึ่งไม่ทำการเปิดขึ้นมาจริง ๆ

[gist id="291123784047e236542416dffe56d197" file="3.js"]

Reference Websites

↧
↧

ใช้งาน PostgreSQL สำหรับการทดสอบ ใน Spring Boot

June 16, 2024, 6:20 am
$
0
0

คำถามเกี่ยวกับการทดสอบระบบงานใน Spring Boot 3

ถ้าต้องการทดสอบระบบที่ใช้งาน PostgreSQL database
นั้นสามารถทำได้อย่างไรบ้าง ?

โดยคำตอบที่แนะนำไปเป็นดังนี้

วิธีที่ 1 ใช้งาน in-memory database

ในการทดสอบไปเลย นั่นคือ H2, HSQL or Derby database
ง่าย สะดวก แต่ไม่เหมือนจริงทั้งหมด

วิธีที่ 2 ใช้งาน Embedded PostgreSQL

ใช้งานผ่าน library :: Java embedded PostgreSQL component for testing

วิธีที่ 3 ใช้งาน Test container with PostgreSQL

ซึ่งมี module ให้ใช้งานง่าย ๆ โดยใช้งานร่วมกัย Docker

วิธีที่ 4 ใช้งานผ่าน database จริง ๆ ไปเลย

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

↧

Docker Desktop :: เพิ่งเห็น extension ชื่อว่า Disk usage

June 18, 2024, 7:20 am
$
0
0

เพิ่ง update Docker Desktop ไป ก็ไปเห็นว่ามี extension ชื่อว่า Disk usage
ไม่แน่ใจว่าติดตั้งเองไหม แต่ว่าดูแล้วมีประโยชน์ดี
สำหรับดูการใช้งาน disk ของ Docker ว่า
ใช้งานอะไรบ้าง เช่น

  • Image
  • Container
  • Local volume
  • Build cache
  • Dangling

จากนั้นก็ไม่คิดอะไรมาก Reclaim space กันไปเลย

คำสั่งดูการใช้งานของ docker

[code]$docker system df -v[/code]

แล้วใน Docker Desktop for Mac มี feature host networking มาด้วย
แต่เป็น beta feature นะ
ลองใช้งานกันดู

↧

Tips :: เปลี่ยน version ของ .NET

June 18, 2024, 11:00 pm
$
0
0

ปัญหา เราจะจัดการ version ของ .NET ในการสร้าง project ได้อย่างไร
เนื่องจากแต่ละ project ก็ใช้ version แตกต่างกันไป
เมื่อเจอปัญหานี้จะจัดการอย่างไร ?

จากที่ใช้งานมานั้นใช้ทำดังนี้
เป็นการใช้งานใน command line ทั้งหมด
มาเริ่มกันเลย

ขั้นตอนที่ 1 ดูก่อนว่าในเครื่องมี version อะไรบ้าง ?

[gist id="b677a94c0b19160702756e6ad837b2bf" file="1.txt"]

ขั้นตอนที่ 2 สร้าง global.json สำหรับกำหนด version ของ .NET

[gist id="b677a94c0b19160702756e6ad837b2bf" file="2.txt"]

เพียงเท่านี้ก็จะการ version ของ .NET บนเครื่องแบบง่าย ๆ ได้แล้ว

↧
Search

ทำความรู้จักกับ TypeSpec สำหรับการออกแบบ API

June 20, 2024, 8:01 am
$
0
0

เห็นทาง Microsoft ได้ปล่อย TypeSpec ออกมา
เป็นภาษาในการออกแบบ API (Application Programming Interface)
อีกทั้งยังทำงานร่วมกับ OpenAPI, JSON Schema และ Protobuf ได้
รูปแบบของภาษานั้นจะคล้าย ๆ กับ TypeScript และ C# นั่นเอง

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

  • ทำการออกแบบ API ด้วย TypeSpec
  • ทำการสร้าง TypeSpec ได้ใน VS Code และ Visual Studio หรือลองใช้งานผ่าน Playgroud ได้
  • ใช้งาน TypeSpec compiler ในการแปลงไปยังเอกสารอื่น ๆ เช่น schema, API Spec, client/server code เป็นต้น

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

เริ่มด้วยการติดตั้งและสร้าง project ของ TypeSpec

[gist id="fab65907e5a7ffd46df068da7c2147bf" file="1.txt"]

ต่อมาทำการออกแบบ REST API ในไฟล์ main.tsp

สามารถใช้ extension ใน VS Code ได้เลย

[gist id="fab65907e5a7ffd46df068da7c2147bf" file="main.tsp"]

ทำการ compile ไปเป็น OpenAPI
หรือใช้งานผ่าน playgroud ได้เลย

เพียงเท่านี้ก็สามารถใช้งานได้เลย
ลองใช้งานเล่น ๆ กันดูครับ

↧
↧

ลบ node_modules ในเครื่องด้วย NPKILL

June 25, 2024, 8:56 am
$
0
0

เห็นใน feed มีวิธีการลบ folder node_modules ทั้งเครื่องมาอีกแล้ว
แต่จำยากมาก ๆ เลยแนะนำว่า
ลองใช้เครื่องมือชื่อว่า NPKILL ดูหน่อย

ใช้งานมาก ๆ ด้วยคำสั่ง

[code] $npx npkill [/code]

จะทำการค้นหา folder node_modules ทั้งหมดในเครื่องมา
จากนั้นเราก็ทำการเลือก folder ที่ต้องการลบ
เป็นอันจบสิ้น แบบง่าย ๆ
ลองใช้กันดู

↧

Playwright 1.45 เพิ่ม Clock API เข้ามาแล้ว

June 28, 2024, 9:25 am
$
0
0

ใน Playwright 1.45 นั้น ได้เพิ่ม Clock API เข้ามาในการทดสอบ
เพื่อช่วยให้สามารถควบคุมการทำงานของเวลาได้
ยกตัวอย่างเช่น

  • กำหนดเวลาในระหว่างการทดสอบได้ตามที่ต้องการ
  • หยุดเวลา หรือ เพิ่มเวลา ตามที่ต้องการได้

ตัวอย่างของการใช้งาน

[gist id="37e5cb5a46ece32150616a636517f386" file="test.js"]

สามารถอ่านเอกสารการใช้งานได้เพิ่มที่ Playwright :: Clock

↧

Go :: ความแตกต่างระหว่าง go mod tidy กับ go mod download

July 1, 2024, 6:44 pm
$
0
0

คำถามจากการ share เรื่องการพัฒนาระบบด้วยภาษา Go
โดยใน Dockerfile พบว่า ทำการ download package ที่ใช้งาน
ด้วยคำสั่ง go mod download
แต่ในการพัฒนานั้น เรามักจะใช้งานด้วยคำสั่ง go mod tidy มากกว่า
ดังนั้นทั้งสองคำสั่งนี้ต่างหรือเหมือนกันอย่างไร ?

คำตอบง่าย ๆ ก็ไปดูเอกสารเอาสิ !!

ตัวอย่างของ Dockerfile เป็นดังนี้

[gist id="c568ac1b44e71caf7eb4bc9094f60396" file="Dockerfile"]

คำอธิบายเป็นดังนี้

  • ทั้งคู่จะทำการ download package หรือ dependency ที่ใช้งาน
  • go mod download จะทำการอ่านข้อมูลของ package ต่าง ๆ จากไฟล์ go.mod เท่านั้น โดยไม่ทำการแก้ไขไฟล์ เหมือนกับ npm install ใน NodeJS นั่นเอง
  • go mod tidy จะทำการ scan จาก code ของเราว่าใช้งาน package อะไรบ้าง จากนั้นจะทำการ download และแก้ไขไฟล์ go.mod เสมอ เมื่อมีการเปลี่ยนแปลง ทั้งการเพิ่มและลบสิ่งที่ไม่ได้ใช้งานใน code ออกไป

ดังนั้นในการพัฒนาเรามักจะใช้งาน go mod tidy นั่นเอง เพราะว่าเปลี่ยนแปลงบ่อย
ส่วนในการ deploy มักจะใช้งาน go mod download จากสิ่งที่กำหนดไว้แล้วเท่านั้น
แต่ถ้าไม่คิดอะไรมากก็ go mod tidy ไปเลย !!

ขอให้สนุกกับการเขียน code ครับ

↧

สวัสดี Swift Testing

July 5, 2024, 9:36 pm
$
0
0

ทาง Apple ได้เปิดตัว Swift Testing ซึ่งเป็น unit test framework ตัวใหม่
ซึ่งมาพร้อมกับ Xcode 16
โดยที่มี syntax และรูปแบบการใช้งานที่ง่ายและสะดวกขึ้น
มีการ assert ที่ดีขึ้น
อีกทั้งยังมี parameterized testing เป็นต้น
ดังนั้นมาทำความรู้จักและลองใช้งานกันหน่อย

ก่อนหน้านี้ในการเขียน test ด้วย Swift บน Xcode นั้น
จะใช้งาน XCTest ซึ่งเป็น test framework ที่เก่ามาก ๆ
เทียบกับ JUnit 3 ได้เลย
โดยชื่อ test case ต้องขึ้นด้วยคำว่า test

ใน Swift Testing เขียนง่าย ๆ ได้แบบนี้
แต่ละ test case ขึ้นต้นด้วย @test
และสามารถใส่ชื่อที่อธิบายได้ง่าย ๆ เช่น @test("human readtable")
ทำไมมันเหมือน ๆ Junit 5 เลย
ในส่วนของการ assert จะใช้ #assert
เป็น feature ใหม่ ชื่อว่า Expression macros

รวมทั้งยังแบ่งกลุ่มของ test case ด้วย tag แบบง่าย ๆ ได้อีก (ไม่ใช่ของใหม่อะไรเลย)
ดังนี้

[gist id="75065e64e58acf4928105a8d40996af4" file="1.swift"]

ในการ run นั้น จะเป็นการ run แบบ parallel โดย default
นั่นหมายความว่าแต่ละ test case/method จะถูก run แยก instance กัน
ดังนั้นทำให้แต่ละ test case/method ทำงานเป็นอิสระแก่กันไปเลย

ถ้าต้องการทดสอบพวก Exception ต่าง ๆ ทำได้ดังนี้

[gist id="75065e64e58acf4928105a8d40996af4" file="2.swift"]

สำหรับการทดสอบด้วย data-driven testing หรือ parameterized นั้น
ก็สามารถทำได้ง่าย ด้วยการใส่ arguments เข้าไปใน @Test ได้เลย

[gist id="75065e64e58acf4928105a8d40996af4" file="3.swift"]

ศึกษาเพิ่มเติมได้ที่

GitHub :: Swift Testing
Getting started
WWDC24 Developer Tools guide
Swift Testing – A New Unit Testing Framework

↧
↧

แนะนำการใช้งาน tRPC

July 7, 2024, 10:10 am
$
0
0

จากการแบ่งปันเรื่องการพัฒนาระบบงานด้วย TypeScript
ทั้งส่วนของ frontend และ backend นั้น
โดยปกติจะติดต่อสื่อสารผ่าน HTTP
ซึ่งมักจะเป็น RESTful APIs นั่นเอง
แต่มักจะมีปัญหาเรื่องของการเปลี่ยนแปลง
นั่นคือเมื่อฝั่งของ backend ทำการเปลี่ยนแปลงรูปแบบของ request หรือ response แล้ว
มักจะส่งผลกระทบต่อฝั่ง frontend เสมอ ถ้าไม่ทำการแจ้งการเปลี่ยนแปลง
จึงแนะนำอีกรูปแบบคือ tRPC (TypeScript Remote Procedure Call)

โดยที่ tRPC นั้นเป็นหนึ่งใน implmentation ของ RPC
ซึ่งถูกออกแบบมาสำหรับ TypeScript โดยเฉพาะเท่านั้น
และทั้ง frontend และ backend ต้อง share code ร่วมกัน หรืออยู่ใน Monorepo

ขั้นตอนการใช้งาน tRPC ในการพัฒนาระบบเป็นดังนี้

ขั้นตอนที่ 1 ทำการสร้าง tRPC server ขึ้นมา

เพื่อสร้าง procudure สำหรับการใช้งานจากฝั่งของ client ขึ้นมา
โดยปกติจะกำหนดเป็น HTTP request/response ของ RESTful API
แต่ใน tRPC นั้นจะกำหนดเป็นชื่อ procedure แบบ public
จากนั้นกำหนด data type ของ procedure ต่าง ๆ
ซึ่งจะใช้ package zod สำหรับตรวจสอบโครงสร้างของข้อมูล

ตัวอย่างของ code

[gist id="c670cb4478219698ce305e15a55c00b4" file="app-router.ts"]

คำอธิบาย

  • ในแต่ละ procedure นั้น ถ้าต้องการดึงข้อมูลจะใช้ query ส่วนการ update ข้อมูลใช้ mutation
  • ทำการจัดกลุ่มของ procedure ต่าง ๆ ด้วย AppRouter
  • การตรวขสอบข้อมูลหรือ validation จะทำในการเรียกใช้งานจากฝั่งของ client ดังนั้นถ้ามีการเปลี่ยนแปลงฝั่ง server แล้ว ทาง client จะรู้ผลกระทบทันที

ขั้นตอนที่ 2 ทำการพัฒนาส่วนของ Server ด้วย package express เพื่อให้ client ใช้งาน

ทำการ expose AppRouter ที่สร้างไว้ให้สามารถเข้าถึงผ่าน HTTP protocol

[gist id="c670cb4478219698ce305e15a55c00b4" file="server.ts"]

ขั้นตอนที่ 3 สร้างส่วนของ Client เพื่อเรียกใช้งาน

[gist id="c670cb4478219698ce305e15a55c00b4" file="client.ts"]

เพียงเท่านี้ก็สามารถใช้งาน tRPC แบบง่าย ๆ ได้แล้ว
หรือสามารถเรียกผ่าน curl ได้ดังนี้

[gist id="c670cb4478219698ce305e15a55c00b4" file="1.txt"]


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

↧

Tips :: ทำการ wrap Error ในภาษา Go

July 8, 2024, 12:31 am
$
0
0

คำถามที่น่าสนใจเกี่ยวกับการจัดการ error ในภาษา Go
ว่าถ้าต้องการโยน error หลายตัวกลับมาจาก function แบบง่าย ๆ
ทำแบบไหนได้บ้าง ?

ก่อนหน้านี้แนะนำ Multiple errors ไปแล้ว ด้วย errors.Join()
มาดูอีกวิธีกันดู
เลือกเอาที่ความชอบไปเลย

คำตอบ
เป็นแนวทางที่ผมใช้บ่อย ๆ คือ
การ wrap error กลับมาแบบตัวอย่างใน code

[gist id="31fbcd47baf8f289bdf68728fbd845a6" file="demo-error.go"]

คำอธิบาย

  • ทำการสร้าง error type ของแต่ละเรื่องขึ้นมาก่อน
  • ใน function ทำการ return error กลับมา โดย wrap หรือห่อ error ต่าง ๆ ไว้ ผ่าน fmt.Errorf("%w")

จากนั้นทำการ run ดูผล

[gist id="31fbcd47baf8f289bdf68728fbd845a6" file="1.txt"]

เพียงเท่านี้ก็ส่งกลับมาแบบง่าย ๆ ได้แล้ว
ส่วนผู้ใช้งานก็ไปตรวจสอบ type กันเองด้วย errors.As() ต่อไปนั่นเอง

ปล. errors.As() ใช้สำหรับการตรวจสอบ type ของ error เท่านั้น ไม่สนใจ value ของ error

↧
Search

ตอบคำถามจาก Microservices design :: เรื่องของ Software Architecture ที่เปลี่ยนไป

July 13, 2024, 9:30 pm
$
0
0

จากการแบ่งปันเรื่องการออกแบบระบบงานด้วยแนวคิด Microservices นั้น
มีคำถามที่น่าสนใจเกี่ยวกับ software architecture ที่เปลี่ยนไปว่า
ทำไมมันถึงมีพวกเครื่องมอื หรือ วิธีการแปลก ๆ เข้ามาเรื่อย ๆ
ทั้ง Microservices, Function as a Service
ทั้ง Apache Kafka
ทั้ง Docker และ Kubernetes
ทั้ง Caching ในส่วนต่าง ๆ
ซึ่งเยอะไปหมด เราต้องใช้มันด้วยหรือ ?

คำตอบคือ เราต้องการสิ่งเหล่านี้จากข้างต้นทั้งหมดจริง ๆ หรือไม่ ?

หรือเราใช้เพราะว่า มัน cool
หรือเราใช้เพราะว่า เขาบอกว่าต้องใช้ (เขาคือใคร

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

ดังนั้นต้องตั้งสติก่อน start เพราะว่า ทุกสิ่งทุกอย่าง
มันถูกคิด ถูกสร้าง ขึ้นมา เพื่อแก้ไขปัญหาหนึ่ง ๆ
ดังนั้น เราต้องทำความเข้าใจมันก่อน (Know problems first, context is the king)
จากนั้นมาดูว่า ปัญหาของเรา และ เครื่องมือมันตรงกันไหม
ถ้าไม่แล้ว แทนที่จะเข้ามาแก้ไขปัญหา กลับมาสร้างปัญหาใหม่ก็ได้ !!

เหตุผลอยู่เหนืออารมณ์เสมอ

ขั้นตอนของการเลือกมีขั้นตอนดังนี้

  • Simplicity เริ่มจากความเรียบง่าย แต่มันก็ไม่ง่าย มีเป้าหมาย เพื่อส่งมอบงานให้เร็วที่สุด แต่ยังคงคุณภาพที่สูงนะ
  • Maintainability ต่อจากนั้นถ้าระบบงานเริ่มใหญ่ขึ้น ความซับซ้อนที่สูงขึ้น ทีมใหญ่ขึ้น การจัดการก็ต่างออกไป แก้ไขที่หนึ่งแล้วไปกระทบอีกหลาย ๆ ที่หรือไม่ ทั้งเรื่องของ feature, code และ ทีม เพื่อเตรียมตัวสำหรับการโตไปอีกขั้นของระบบ เช่น modular monolith เป็นต้น
  • Decoupled to small services หรือ Microservices เมื่อผ่านทั้ง simplicity และ maintainability มาแล้ว ก็เริ่มแบ่งเป็น service ออกมาจากกันทั้งในรูปแบบของ physical server หรือ container ก็ว่าไป รวมทั้งการ deploy และ scale ที่ต้องแยกออกจากกัน ทำให้เกิดความเป็นอิสระต่อกัน ... และแน่นอนว่า ก็มีปัญหาอื่น ๆ ตามมาที่ต้องคิดและวางแผน เพื่อรองรับมัน ทั้งการทำงานร่วมกัน ทั้งการติดต่อสื่อสารระหว่างกัน ทั้งเรื่องของ performance ที่อาจจะ drop ลงไหม !! รวมทั้งเรื่อง error handling ต่าง ๆ (Plan for failure !!) ที่มีโอกาสเกิดขึ้นเยอะกว่าเดิม เพราะว่ายิ่งแยก ยิ่งเกิดความซับซ้อน

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

↧

MarkMap :: ทำการเขียน Mindmap ด้วย Markdown format

July 15, 2024, 1:22 am
$
0
0

ในการเขียนระบบเพื่อสร้าง Mindmap สวย ๆ
พบว่าวิะีการหนึ่งที่น่าสนใจคือ การเขียนได้ Markdown format
จากนั้นก็ทำการ render ออกมาเลยด้วยภาษา JavaScript
ด้วยการใช้ library ชื่อว่า MarkMap

เราสามารถเขียนในรูปแบบ markdown ใน editor ทั่วไปได้เลย
จากนั้นสามารถ export ออกมาเป็น HTML หรือ SVG ได้เลย
อีกอย่างใน VSCode ก็มี extension ให้ด้วย สบายมาก ๆ

ลองใช้งานดูครับ สามารถนำไปใช้ได้ชิว ๆ เลย

↧
↧

มาลองใช้งาน sqlite ใน Node v22.5 ที่กำลังจะออกมา

July 17, 2024, 6:51 pm
$
0
0

เห็นว่าใน Node v22.5 ที่กำลังจะออกมานั้น (Work in progress)
กำลังเพิ่ม SQLite module ทั้ง server และ client เข้ามาเลย
ไม่ต้องไป download มาใช้งานอีกแล้ว
ซึ่งทำให้นักพัฒนาสะดวกขึ้นเยอะเลย
ดังนั้นมาลองดูตัวอย่างการใช้งานกันว่าเป็นอย่างไร ?

[gist id="c3511341a019e1f4eeb52e6005c0a7f9" file="demo-sqlite.js"]

ตอนนี้ทำการ run ผ่าน node nightly build ได้แบบนี้

[gist id="c3511341a019e1f4eeb52e6005c0a7f9" file="1.txt"]

ลองใช้งานเล่นกันดูครับ
Node มีของเล่นมาให้เรื่อย ๆ
ขอให้สนุกกับการ coding

ปล. สำหรับชาว Mac M1,M2,M3 จะมีปัญหากับ node nightly นิดนึง
ให้ไปแก้ไข file index.js นิดหน่อย

[gist id="c3511341a019e1f4eeb52e6005c0a7f9" file="index.js"]
↧

อย่าเพิ่ง upgrade ไปใช้ Node 22.5.0 กันนะ

July 18, 2024, 8:22 pm
$
0
0

ทางทีมพัฒนาของ Node ได้ออกมาแจ้งทาง Twitter ว่า
อย่างเพิ่ง upgrade ไปใช้ version 22.5.0 (Current) ที่เพิ่มปล่อยออกมานะ
เนื่องจากมี bug หลัก ๆ จาก V8 Fast API นั่นเอง
แต่จากเท่าที่อ่าน comment พบว่า หลาย ๆ คนยังไม่ใช่ version 22 เลย ++!

↧

ว่าด้วยเรื่องการติดต่อสื่อสารระหว่าง Module

July 18, 2024, 9:05 pm
$
0
0

ในการแบ่งปันเรื่อง Microservices design และ develop นั้น
มักจะแนะนำเสมอว่า เริ่มจาก modular ให้มันดี ๆ ก่อน (process เดียวกัน)
เริ่มด้วยการแบ่งการทำงานต่าง ๆ เป็น module หรือกลุ่มการทำงานก่อน
จากนั้นดูการติดต่อสื่อสารระหว่าง module ว่าเป็นอย่างไร ?
มันทำให้แต่ละ module ผูกมัดกันมากไปหรือไม่ ? (Tight coupling)

ดังนั้นในการทำ workshop จึงแนะนำหนึ่งแนวทางในการจัดการ module

และการติดต่อระหว่าง mnodule แบบไม่ผูกมัดกันมากนัก (Loose coupling)
เพื่อลดผลกระทบจากการแก้ไขใน module ต่าง ๆ ลง

หนึ่งในวิธีการที่แนะนำคือ นำแนวคิดของ Event-based เข้ามาช่วยงาน

หรือ Mediator pattern จาก design pattern นั่นเอง
แสดงดังรูป

อธิบายการทำงานคร่าว ๆ เป็นดังนี้

  • เมื่อ module A ทำงานเรียบร้อยแล้ว ปกติจะต้องเป็นฝั่งที่เรียกใช้งาน module B เองต่อไป แต่ในแนวทางนี้ไม่ใช่
  • module A ทำการสร้าง event ขึ้นมาจากนั้น publish ออกไป
  • ทาง module B จะทำการสร้าง event handler สำหรับคอยรับ event type ที่ต้องการ
  • เมื่อมี event ที่ต้องการเกิดขึ้นมา ทาง module B ก็จะทำงานต่อไปเองแบบอัตโนมัติ ทำให้ทั้งสอง module ไม่ผูกมัดกันมากนัก
  • โดยทั้งสอง module ทำงานใน process เดียวกัน ดังนั้น event ก็จะอยู่ภายในนั่นเอง
  • อีกอย่าง แนวคิดนี้มันก็เอื้อต่อการแยกในอนาคตอีกด้วย !!

ตัวอย่างของการพัฒนาจะมีดังนี้

ลองนำไปเล่นกันดูครับ เป็นอีกหนึ่งแนวคิดที่น่าสนใจ

Reference websites

↧
Viewing all 2000 articles
Browse latest View live
Search