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

เมื่อเกิด Incident ขึ้นมา เราทำอะไรบ้าง ?

$
0
0

หลังจากอ่านเรื่อง Incident response ใน SRE Book
พบว่าเป็นสิ่งที่สำคัญมาก ๆ
เมื่อเกิดปัญหาต่าง ๆ ขึ้นมาบน production server แล้ว
เช่น ทำงานผิดพลาดหรือพัง ระบบ network มีปัญหา และ data หลุด เป็นต้น
เราจะจัดการมันอย่างไร
เนื่องจากยิ่งแก้ได้ช้า ผลกระทบก็ยิ่งมาก
ส่งผลต่อทั้งระบบ การบริการ ลูกค้า และ องค์กร

โดยการจัดการกับ Incident นั้น สามารถแบ่งออกเป็นขั้นตอนดังนี้

  • Detect
  • Response
  • Resolution and Recovery
  • Postmortems

ขั้นตอนที่ 1 Detect

เป็นการหาหรือตรวจพบปัญหา ว่าปัญหาเกิดขึ้นตรงไหน
ตรวจหาอย่างไรกัน
ระบบ monitoring/observability ทำการแจ้งมา หรือ ให้ผู้ใช้งานแจ้งมา
เจอแล้วแจ้งอย่างไร ต้องส่ง email หรือ โทร !!

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

ถ้าเราหา หรือ รับรู้ปัญหา ได้ช้า และ ไม่ชัดเจน
การแก้ไขก็ยิ่งช้า

ขั้นตอนที่ 2 Response

ในขั้นตอนนี้ คือ การวิเคราะห์ปัญหาที่เกิดขึ้น พร้อมหาวิธีการแก้ไขปัญหา
ทั้งแก้ไขแบบ short term และ long term

ขั้นตอนนี้ทำงานกันอย่างไร ?
ต้องเรียกคนที่เกี่ยวข้องมาจัดการไหม
ถ้ามีงานในมืออยู่ก็ทิ้งซะ แล้วมาแก้ไข
ตั้ง War room ขึ้นมา เพื่อมาทำการแก้ไขกัน

หรือว่า ทำการวิเคราะห์จากข้อมูลที่มีก่อน
ทั้ง metric, log ต่าง ๆ ว่าเป็นอย่างไร
ปัญหาน่าจะมาจากสาเหตุอะไรบ้าง
จากนั้นค่อยหาวิธีการแก้ไข และ ลงมือทำ
รวมทั้งการทำงานร่วมกัน สำหรับคนที่ใช่จริง ๆ

ขั้นตอนที่ 3 Resolution and Recovery

เมื่อทำการวิเคราะห์ และ หาต้นเหตุของปัญหาเรียบร้อยแล้ว
ก็ต้องทำการแก้ไข เพื่อให้ระบบกลับมาทำงานได้อย่างปกติ
แน่นอนว่า ต้อการการทำงานร่วมกันในหลายส่วน
ทั้ง การออกแบบ วิเคราะห์ พัฒนา ทดสอบ infra network และ deploy
เพื่อทำให้การทำงาน flow หรือ ไหลลื่นมากที่สุด
ยิ่งมีการทำงานแบบ automation เข้ามาช่วย จะยิ่งดี

ที่สำคัญเลือกคน ให้เหมาะกับปัญหาด้วยละ

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

ขั้นตอนที่ 4 Postmortems

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

สิ่งที่ได้จากขั้นตอนนี้ สามารถนำไปใช้ในการ training ภายในของบริษัทได้อีกด้วย
จะได้ไม่ผิดซ้ำ ๆ ที่เดิม โดยในเอกสารประกอบไปด้วย

  • การวิเคราะห์ปัญหาที่ผ่านมา
  • รูปแบบของปัญหาที่เกิดขึ้น หรือ การหารูปแบบของปัญหาที่อาจจะเกิดขึ้นได้
  • แนวทางปฏิบัติ เพื่อป้องกันปัญหาไม่ให้เกิดขึ้น

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

ลองมาดูที่ระบบของเราก็บ้าง
เมื่อเกิด incident ขึ้นมา เราจัดการอย่างไรบ้าง ?

Reference Websites


Annotation ต่าง ๆ ที่ใช้ใน Spring Boot

$
0
0

ตอบคำถามจากการ share เรื่อง การพัฒนา REST API ด้วย Spring Boot
ว่ามีการใช้ annotation อะไรบ้าง
ซึ่งตอบเลยว่าเยอะมาก ๆ
แต่ไปเจอเอกสารชุดนี้ น่าจะพอช่วยเป็น guide แนะนำให้ได้

สรุปจากบทความ Using ClickHouse as an Analytic Extension for MySQL

$
0
0

จากบทความเรื่อง Using ClickHouse as an Analytic Extension for MySQL
ซึ่งเขียนโดย Percona นั้น
ทำการอธิบายการนำข้อมูลจาก MySQL ไปวิเคราะห์ผ่าน ClickHouse
โดยใช้งาน extension สำหรับ MySQL นั่นเอง
ที่สำคัญไม่ใช่เอามาแทนที่ แต่เอามาทำงานตาม use case ที่เหมาะสม

สิ่งที่บทความอธิบายคือ ทำไมถึงต้องมีตัวช่วยสำหรับการ Analytic ด้วย ?

แน่นอนว่า MySQL ไม่สนับสนุน หรือ ไม่เหมาะสม เป็นดังนี้

  • จำนวน table มากขึ้น รวมทั้งข้อมูลบเป็นแบบไม่เปลี่ยนแปลง (Immutable data) และที่น่ากลัวคือ transaction data/table
  • ต้องการทำ aggregation query ที่หนัก ๆ เราจะเจอได้จากพวก having, group by นั่นเอง ยิ่งทำบนข้อมูลขนาดใหญ่ ยิ่งสนุกสนาน

เมื่อเจอข้อมูลและความต้องการเหล่านี้
ทำให้การ process ข้อมูลช้า รอนาน
หรือต้องเปลี่ยนไปทำงานแบบ baching ไป
จะเห็นได้ว่า สิ่งที่เป็นอยู่ น่าจะไม่เหมาะสมหรือไม่ ?

หนึ่งในคำตอบของความต้องการข้างต้น คือ ClickHouse
ที่ได้เตรียมการทำงานกับข้อมูลที่ไม่ปลี่ยนแปลง
การทำ aggregation ที่รวดเร็ว ดังนั้นทำงานแบบ realtime ได้เลย

ปล. ClickHouse มันถูกออกแบบมาเพื่อ analytic processing โดยเฉพาะ
ข้อมูลจัดเก็บในรูปแบบ colume-based และทำงานแบบ parallel อีกด้วย

แต่ ClickHouse ไม่ได้ support ACID แบบเต็มรูปแบบ
ดังนั้นเรื่องของ use case ที่ต้องการความถูกต้องจริงจัง ก็อาจจะไม่เหมาะนะ
รวมทั้งการ update/delete เยอะ ๆ ก็ไม่เหมาะ

ดังนั้น ใช้ให้ถูกกับงานด้วยนะ !!

รูปแบบการ integrate ClickHose กับ MySQL

มีอยู่ 3 รูปแบบคือ

รูปแบบที่ 1 ทำการดึงข้อมูลจาก MySQL ผ่าน ClickHouse

โดยใช้งานผ่าน MySQL database engine

รูปแบบที่ 2 ทำการย้ายข้อมูลจาก MySQL ไปยัง ClickHouse

โดยไม่ต้องมาดึงข้อมูล หรือ load มายัง MySQL เลย
ให้ใช้งานผ่าน ClickHose ตรง ๆ เลย สำหรับการ analytic

ใช้งานผ่าน MergeTree table engine

รูปแบบที่ 3 ทำการ mirror หรือ snapshot ข้อมูลจาก MySQL ไปยัง ClickHouse

โดยทำการ replicate ข้อมูลที่เปลี่ยนแปลงใน MySQL ไปเท่านั้น
ใช้งานผ่าน ReplacingMergeTree

เป็นอีกแนวทางที่น่าสนใจ ในการออกแบบระบบงาน
เพื่อให้ตอบโจทย์ทาง business

Reference Websites

Node 18.11.0 :: เพิ่ม watch mode เข้ามา

$
0
0

ใน Node 18.11.0 นั้น มี feature ต่าง ๆ เพิ่มเข้ามา
รวมทั้งการแก้ไข bug เพียบเลย
โดย feature ที่น่าสนใจ สำหรับการพัฒนา ประกอบไปด้วย

เพิ่ม Watch mode เข้ามา แบบ experiment ให้แล้ว

จะทำการ restart ให้เมื่อไฟล์ใน project มีการเปลี่ยนแปลง
โดยใช้งานด้วย --watch และ --watch-path
ทำให้ไม่ต้องใช้ nodemon กัน

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

[code] node --watch index.js (node:15179) ExperimentalWarning: Watch mode is an experimental feature. This feature could change at any time (Use `node --trace-warnings ...` to show where the warning was created) Example app listening on port 3000 [/code]

ส่วนของการ test ที่เพิ่มเข้ามาใน Node
ก็ปรับปรุงและแก้ไขเยอะมาก ๆ เช่น

  • การแปลง report ของ test จาก JSON ไปเป็น JUnit report ช่วยให้ integrate กับ CI หรือ เครื่องมืออื่น ๆ ได้ง่ายขึ้น
  • ใน test runner เอาการเตือนเรื่อง runtime experiment ออกไป และใช้งาน --inspect ด้วยได้แล้ว

เป็นการปรับปรุงให้ test ใน Node ดีขึ้นเรื่อย ๆ

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

หนังสือใหม่ Go in Action, Second Edition

$
0
0

เพิ่งเห็นว่า Go in Action, Second Edition เพิ่งปล่อยออกมา
ในรูปแบบ MEAP แล้ว ซึ่งเป็นการปรับปรุงจาก edition แรก
โดยเน้นที่การนำไปใช้งาน real use case ต่าง ๆ
และ ปรับปรุงตามความสามารถใหม่ ๆ ของภาษา Go

จากที่อ่าน preview บท ที่เป็นเรื่องพื้นฐานของภาษา Go

  • การทำงานของ Go เช่น Memory management, Type system และ Go routine, channel
  • การสร้าง project ใช้งาน Go module แล้ว
  • ตัวอย่าง code พร้อมอธิบาย ให้เข้าใจเกี่ยวกับภาษา รวมทั้งพวก defer, error handling

คิดว่า น่าสนใจ ตั้งแต่ผู้เริ่มต้นเลย
อีกทั้งยังมีเรื่องของ Testing, Generic และ Fuzzing อีกด้วย

มาแล้ว Robot Framework 6

$
0
0

วันนี้ Robot Framework 6.0 ถูกปล่อยออกมาแล้ว
แน่นอนว่า หนึ่งใน feature ที่น่าสนใจคือ
สามารถเขียน test script ในส่วนของ Header, Setting ต่าง ๆ
ด้วยภาษาต่าง ๆ ได้ หนึ่งในนั้นคือ ภาษาไทย

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

[gist id="4c9d43da64c6c38aaf6db97120482dfb" file="1.robot"]

ปล. ใครใช้แล้ว มันแปลก ๆ
ลองทำการ contributed ใน repository ของ Robot framework ได้ครับ

สรุปจากบทความ Choosing the best Node.js Docker image

$
0
0

วันหยุดอ่านบทความเรื่อง Choosing the best Node.js Docker image
ทำการวิเคราะห์ว่า Docker Image ของ Node.js แต่ละตัวที่มีให้ใช้เป็นอย่างไร
ในแง่มุมต่าง ๆ ยกตัวอย่างเช่น

  • Base image หรือ OS ที่ใช้งาน ว่าเป็นอย่างไร
  • เรื่องการ maintain ต่าง ๆ
  • เรื่องขนาดของ image
  • เรื่องความปลอดภัย ทำการตรวจสอบผ่าน Image scanner

เริ่มจากสิ่งที่ไม่แนะนำคือ การเขียน Dockerfile แบบนี้

รวมทั้งไม่ใช้งาน latest tag ด้วยนะ !!

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

ในบทความทำการสรุป Docker Image แต่ละตัวไว้ดังนี้

จากการสรุปนั้น node:alpine นั้นมีขนาดเล็ก มี dependency น้อย

แถมเจอปัญหาด้าน security น้อย
แต่ในความจริงคือ เครื่องมือตรวจสอบยังไม่สนับสนุน Alpine นั่นเอง
รวมทั้ง Alpine นั้นทำการ implement library ภาษา C ด้วย musl
ซึ่งแตกต่างจากตัวอื่น ๆ ที่ใช้งาน glibc

ผลที่ตามมาคือ ทำให้ระบบงานที่นำมา run บน Alpine เกิดปัญหาแปลก ๆ
หรือปัญหาที่ไม่ควาดฝันเยอะ

นั่นหมายความว่า เป็น image ที่ไม่ใช่ official nodejs runtime
ซึ่งไม่แนะนำให้ใช้บน production
ให้ใช้ในการพัฒนา หรือ ทดลองเท่านั้น

ส่วนที่ไม่แนะนำให้ใช้อีกคือ node:buster

เนื่องจากเป็น image ที่ใช้งาน Debian 10
ซึ่งสิ้นสุดการ maintain เมื่อเดือนสิงหาคม 2022 ที่ผ่านมา
ดังนั้นในทางเลือกที่ดีกว่า ควรใช้งาน node:bullseyes (Debian 11)

และแนะนำให้ใช้งาน node:bullseyes-slim
ทั้งเป็นตัวใหม่ และมีขนาดเล็กกว่า ปัญหาน้อยกว่า
เป็นตัวเริ่มต้นที่ดี

ส่วน image ที่มี tag LTS และ Current ไม่แตกต่างกันมากนัก

และอีกตัวที่แนะนำให้ใช้งานคือ Image จาก Google distroless

เนื่องจากมีขนาดเล็ก dependency น้อย ปัญหาน้อย
แถม update glibc และ node version ให้เองตลอด เนื่องจากใช้งาน Debian นั่นเอง
แต่จะไม่มี package manager หรือ เครื่องมือในการพัฒนาใด ๆ
เนื่องจากเป้าหมายคือ การ run Node.js app เท่านั้น

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

[gist id="c78905201e5ec18c50cf00a7f2dd7d15" file="Dockerfile2"]

ดังนั้นลองพิจารณาดูกันนะครับ ในการเรื่อง Docker image ที่เหมาะสมกับเรา
โดยมองในมุมต่าง ๆ ทั้ง

  • ขนาดของ image
  • จำนวน dependency
  • ปัญหาด้าน security
  • การ maintain
  • ประสิทธิภาพการทำงาน

Reference Websites

น่าสนใจกับ Tauri :: framework สำหรับการพัฒนา Desktop application

$
0
0

เจอ framework ชื่อว่า Tauri
สำหรับการพัฒนา Desktop application แบบ multi-platform
โดยสร้างด้วยภาษา Rust

เป้าหมายของ framework นี้ เพื่อปรับปรุงให้การพัฒนาดีขึ้นดังนี้

  • ปรับปรุงประสิทธิภาพการทำงานให้ดีขึ้น ด้วยการทำงานของภาษา Rust
  • ขนาดของ app ที่ได้เล็กลงอย่างมาก เมื่อเทียบกับตัวอื่น ๆ เช่น Electron, Qt และ flutter เป็นต้น
  • แสดงผลตาม OS นั้น ๆ ได้ดี เช่นมี Webview Render Library (WRY) โดยทำการ implement เพื่อครอบการทำงานของ webView ตามแต่ละ OS แยกกันไป
  • multi-platform ด้วย FFI
  • เตรียม API interface สำหรับการเข้าถึง native app ผ่าน JavaScript

ลองทดลองกันดูครับ จากที่ลองใช้งานไม่ยากสำหรับการเริ่มต้น


แนะนำ Coverage Gutters ใน VS Code สำหรับ Continuous testing

$
0
0

ในการพัฒนาระบบงานต่าง ๆ บน VS Code นั้น
เมื่อเราเขียน test แล้ว อยากให้ทำการทดสอบแบบอัตโนมัติ
โดยไม่ต้องไปทำอะไร และแสดงผลการทดสอบใน VS Code เลย
ไปเจอว่าใน VS Code นั้นมี extention สำหรับการ watch การเปลี่ยนแปลง
ชื่อว่า Coverage Gutters

จากนั้นทำการ run คำสั่งทดสอบตาม project ต่าง ๆ
ผ่าน Views -> Command Palette ได้เลย

Reference Websites

สวัสดี Python 3.11

$
0
0

จากที่ Python 3.11 ถูกปล่อยออกมานั้น
พบว่ามีการเปลี่ยนแปลงไปในทางที่ดี ๆ มาก
ยิ่งเรื่องของ performance ยิ่งดีขึ้นมาก
จึงทำการสรุปไว้หน่อยว่ามีอะไนบ้าง
มาเริ่มกันเลย

เรื่องแรกคือ Performance ที่ดีขึ้นจาก version 3.10 ถึง 10-60% กันไปเลย

หลัก ๆ ทำการเปลี่ยนแปลงมาจาก Faster CPython Project
ค่าเฉลี่ยของ performance สูงขึ้นประมาณ 25% จาก version 3.10
โดยเน้นไปที่ 2 เรื่องคือ Fast startup และ Faster runtime
รวมทั้งการติดต่อสือสารกับภาษา C

เรื่องที่ 2 การปรับปรุง Error message

บอกปัญหาและจุดของปัญหาให้เลย

เรื่องที่ 3 Grouped exceptions

ทำการเพิ่ม except* เข้ามา เพื่อให้การจัดการ exception ต่าง ๆ ง่ายและยืดหยุดขึ้น
ทำให้สามารถสร้าง grouped exceptions

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

เรื่องที่ 4 สำหรับการ build-in parser สำหรับ TOML (Tom's Obvious Minimal Language)

การเปลี่ยนแปลงครั้งนี้ สาย Data Science ต้องชอบแน่ ๆ
เพราะว่า performance ดีขึ้นอย่างมาก

ปิดท้ายด้วยรูปฮา ๆ

สิ่งที่น่าสนใจจาก Global CIO Report

$
0
0

หลังจากที่ดูข้อมูลจาก Global CIO Report นั้น
มีสิ่งที่น่าสนใจมาก ๆ สำหรับแนวทางการปรับปรุงการทำงานร่วมกันให้ดีขึ้น
ระหว่างหน่วยงานต่าง ๆ เช่น Business และ IT เป็นต้น
มาดูว่ามีอะไรบ้าง ?

เรื่องแรกคือ business และลูกค้า ใช้งานผ่าน online service มากยิ่งขึ้น

ผลที่ตามมาคือ IT จำมีความสำคัญมากขึ้น
งานมากขึ้น
ความกดดันสูงขึ้น
เนื่องจากมีความต้องการจาก business มากขึ้น
และต้อง scale ได้อีกด้วย

ดังนั้นจะส่ิงผลต่อการทำงาน ที่ส่วนใหญ่จะทำงานแยกกัน งานใครงานมัน
นั่นคือการทำงานแบบ silo team(Traditional operation)
ดังนั้นจำเป็นต้องปรับปรุงและเปลี่ยนแปลงอย่างแน่นอน

เรื่องที่สอง การทำงานแบบ silo team นั้น ทำให้องค์กรไปสู่ความสำเร็จได้ยาก

แนวทางการทำงานที่แยก ๆ ก่อให้เกิดปัญหาอื่น ๆ ตามมาเสมอ เช่น

  • สิ้นเปลืองเวลาใน war room ทั้งการพูดคุย การ blame กัน การหาคนผิด แทนที่จะเรียนรู้และปรับปรุง
  • ยากต่อการหาจุดเกิดเตุของปัญหาต่าง ๆ หรือ ใช้เวลาหาสูงมาก ๆ
  • IT stack เข้าใจได้ยาก
  • ขาดความเข้าใจว่า business และ ลูกค้าต้องการอะไร

ดังนั้นจึงเกิดข้อที่ 3 คือ องค์กรต้องการเปลี่ยนแปลงรูปแบบการทำงานให้ดีขึ้น

นั่นคือลดหรือให้การทำงานไม่เป็น silo team อีกต่อไป
ให้ทำงานร่วมกัน
ใช้คำพูดหรือคุยภาษาเดียวกัน
มีเป้าหมายร่วมกัน
ใช้ data ในการขับเคลื่อนการตัดสินใจ

บันทึกการฟัง :: POS/ERP Architecture ของถูกดี

$
0
0

ระบบที่ TD หรือ ถูกดี ดูแลคือ การสร้างระบบ POS (Point of Sales)
สำหรับร้านค้าโชว์ห่วยเล็ก ๆ
ซึ่งมีมากกว่า 100,000 ร้านค้า
ดังนั้นถ้าคิดง่าย ๆ ถ้าแต่ละร้านมี transaction วันละ 100
ก็ตีง่าย ๆ คือ ต้องรองรับ 1,000,000 transaction ต่อวัน
นี่คือ ความท้าทายที่ทีมต้องจัดการให้ได้

เป็นที่มาของ session นี้คือ The 3 years journey behind POS and ERP that handle s 1M+ transactions per day

ย้อนกลับไปเมื่อ 4 ปีที่แล้ว เริ่มต้นจากไม่มีอะไรเลย

ดังนั้นจึงเริ่มทำการออกแบบระบบ ERP โดยแยกมา 12 ตัว
เรียกว่า 12 monkey service หรือ ลิง 12 ตัว

การติดต่อสื่อสารระหว่าง service ใช้งาน Apache Kafka
เพื่อลดการติดต่อสื่อสารไปยัง service ต่าง ๆ
ทำให้ระบบมาเป็น Event-based architecture

แต่ก็ยังมีปัญหาในเรื่องของการ performance และ scaling
เนื่องจาก service นั้นแยกกัน แต่ Data source ยังมีรวมศูนย์
ทำให้ถ้ามีบ้างร้านมีการใช้งานสูง
อาจจะส่งผลต่อระบบโดยรวมด้วย

โดยในปี 2021 นั้น ทาง TD ได้ทำงานปรับปรุงเรื่อง performance ไปถึง 2 ครั้ง
เพื่อทำให้ระบบรองรับกับการใช้งานที่สูงขึ้น

ระบบ monitoring ที่กระจัดกระจายไปในแต่ละทีม
ส่งผลให้มีหลากหลายระบบ แน่นอนว่าแตกต่างกัน
ทำให้เมื่อมีปัญหาจะ detect ยากมาก ๆ
ดังนั้นจำเป็นต้องมีการจัดการระบบ monitoting ใหม่ต่อไป

ระบบงานมีการจัดการเรื่องของ CI/CD
ใช้งาน containerization ตัวจัดการคือ Kubernetes
ใช้งานระบบ cloud น่าจะเป็น Google Cloud
ผสมผสานกับระบบงาน legacy ที่มีอยู่

ในส่วนของหน้าบ้าน หรือ เครื่อง POS จะเป็น Android app ด้วย Kotlin

มีการเปลี่ยนแปลง ปรับปรุงทั้ง software ที่พัฒนา และ hardware ที่มีประสิทธิภาพดีขึ้น
ใน app สามารถทำงานแบบ offline ได้
ดังนั้นจึงต้องมีเชการเก็บข้อมูลบน device ของ POS ด้วย
ซึ่งปัจจุบันใช้งาน SQLite
ก่อนหน้านี้ใช้งาน Realm
รวมทั้งมีการเก็บ log การทำงานต่าง ๆ ซึ่งใช้งาน Hyperloglog

ปัญหาการจัดการเรื่องของเวลา ที่ Android ไม่ได้ sync time กันตลอด
ทำให้เวลาไม่ตรงกัน ทำให้มีปัญหาเกี่ยวกับเวลาของการสร้าง transaction ต่าง ๆ

การโอนเงินไปให้ partner ตามต่างจังหวัด ก็ต้องโอนเงินให้สะดวกอีกด้วย
ตรงนี้ไม่ง่าย ตอนนี้ไปทำงานร่วมกับ KBANK สำหรับ bill payment

การ deploy POS ตามแต่ละที่ จะเริ่ม deploy ผ่าน Play Store
แต่ปัญหาคือ ต้องมีกระบวนการสำหรับการ verify
ซึ่งช้า และ ใช้เวลานาน (ช่วงปี 2021 COVID)

และเมื่อ POS แต่ละเครื่องมีปัญหาก็ต้องรู้และจัดการให้รวดเร็วอีกด้วย

เท่าที่ฟังฝั่ง POS App มี issue ต่าง ๆ เยอะมาก ๆ !!
ทั้งการทำงานแบบ offline
ทั้งการ sync data กับระบบกลาง
ทั้งการเพิ่ม feature ใหม่ ๆ เช่น multiple cashier เป็นต้น

ตอนนี้ใช้งาน Kotlin multiplatform
ดูในเรื่องของ SQLDelight สำหรับ generate SQL statement

ในปีต่อไป ทางทีมกำลังทำ Evolutionary of Architecture กันต่อไป
เพื่อปรับปรุงให้ดีขึ้น เพื่อแก้ไขปัญหา และ รองรับกับความต้องการที่สูงขึ้น

ใช้งาน HTTP Interface ใน Spring framework 6

$
0
0

ใน Spring framework 6 (snapshot/RC) นั้น
มีการเพิ่มเติมและปลี่ยนแปลงหลาย ๆ อย่าง
หนึ่งในนั้นคือ HTTP interface
สำหรับการเรียกใช้งาน external service ผ่าน HTTP protocol
ซึ่งก่อนนี้จะมี

  • RestTemplate สำหรับ request-response model
  • WebClient สำหรับ WebFlux
  • ใช้ Spring Cloud OpenFeign และ Retrofit + OkHttp

โดยการเรียกใช้งาน external service เช่น REST API นั้น
จะให้เราพัฒนาเชิง declarative
ด้วยการสร้าง interface และ annotation ต่าง ๆ

ตัวอย่างเรียกใช้งาน Get user by id จาก JsonPlaceholder

จะเขียน interface ได้ดังนี้

[gist id="a7e40e518f46bf3b67338145b65634fc" file="JsonPlaceHolderGateway.java"]

ต่อมาทำการสร้าง Bean สำหรับสร้าง HTTP Client
ด้วย WebClient จาก Spring WebFlux

[gist id="a7e40e518f46bf3b67338145b65634fc" file="Config.java"]

ทำการเรียกใช้งานแบบง่าย ๆ

[gist id="a7e40e518f46bf3b67338145b65634fc" file="Main.java"]

จะเห็นได้ว่า เป็นแนวทางเดียวกับ Spring Cloud OpenFegint และ Retrofit นั่นเอง

ดู VDO เพิ่มเติมได้

แนะนำหนังสือ Infrastructure as Code, Patterns and Practices

$
0
0

หนังสือที่น่าสนใจเรื่อง Infrastructure as Code, Patterns and Practices
ทำการอธิบายแนวคิดและแนวปฏิบัติสำหรับ Infrastructure as Code
โดย IoC เป็นแนวทางของการจัดการ infrastructure ด้วยเทคนิคของการ coding
ซึ่งเป็นหนึ่งในแนวปฏิบัติของ DevOps
เพื่อช่วยให้สามารถส่งมอบ infrastructure ที่เหมาะสมกับการ run ของระบบงาน
ได้อย่างรวดเร็ว น่าเชื่อถือ ทำซ้ำได้ และขยายได้ง่ายขึ้น

แนวคิดของ IaS นั้นประกอบไปด้วย

  • Idempotency
  • Immutability

แนวปฏิบัติประกอบไปด้วย

  • เก็บทุกอย่างไว้ใน source control
  • ออกแบบ และ สร้างในรูปแบบ mudular/layer และมีการจัดการเรื่อง version
  • มีเอกสารอธิบายเสมอ
  • มีการทดสอบทั้ง manual และ อัตโนมัติ
  • มีการจัดการเรื่อง security และ compliance
  • มีการทำงานแบบอัตโมัติ และใส่ใน CI/CD pipeline

มีการอธิบายเพิ่มเติมเกี่ยวกับ strategy ในการทดสอบด้วย

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

  • Static analysis เช่น unit และ contract test เป็นการทดสอบในแต่ละส่วน เช่น module หรือ layer
  • Dynamic analysis เช่น integration และ end-to-end test เป็นการทดสอบ configuration ต่าง ๆ ของแต่ละ environment ว่าสามารถทำงานร่วมกันได้หรือไม่

เป็นหนังสือที่น่าสนใจมาก ๆ ของอ่านกันดูครับ
น่าจะมีประโยชน์ต่อการพัฒนาระบบงาน

Reference Websites

Golang :: มาแล้วสำหรับ Proposal: Structured Logging

$
0
0

เพิ่งเห็นว่าใน Go มี proposal ที่น่าสนใจคือ Structured logging
ทำให้เราสามารถเขียน log ในรูปแบบที่มีโครงสร้างได้ง่ายขึ้น
รวมทั้งเลือกได้ด้วยว่าจะให้มีโครงสร้างในรูปแบบใด
เช่น text และ JSON เป็นต้น

ตัวอย่าง code

[gist id="06acde0dbdec0b6c70a3acd312357df5" file="1.go"]

ทำให้เราไม่ต้องไปใช้ logging library อื่นอีกแล้ว ไหมนะ !!

เป้าหมายของ proposal ตัวนี้ ประกอบไปด้วย

  • ง่ายต่อการใช้งาน
  • มีประสิทธิภาพการทำงานที่สูง ใช้งาน memory น้อย
  • สามารถ integrate กัับ runtime tracing ได้ด้วย ตรงนี้น่าสนใจมาก ๆ
https://twitter.com/inancgumus/status/1588260579055132674?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1588260579055132674%7Ctwgr%5E4185c4cd72e97b76b6047dadca2471e426accf64%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Fpublish.twitter.com%2F%3Fquery%3Dhttps3A2F2Ftwitter.com2Financgumus2Fstatus2F1588260579055132674widget%3DTweet

จดบันทึกแนวทางในการทดสอบฝั่ง Frontend ไว้หน่อย

$
0
0

จาก Post นี้ใน facebook ก็เลยมาเขียนสรุปหน่อยว่า
ในฝั่ง Frontend นั้น ผมทำการพัฒนาและที่สำคัญคือ ทดสอบอย่างไรบ้าง
โดยปกติจะเริ่มต้นอธิบายให้เข้าใจถึงโครงสร้างก่อน
ซึ่งแสดงดังรูป เพื่อให้เห็นว่าระบบงานของเราเป็นอย่างไรบ้าง

จะเห็นได้ว่ามีส่วนการทำงานต่าง ซึ่งต่างมีหน้าที่การทำงานชัดเจน
ยกตัวอย่างเช่น

  • Component จะเป็น component ฝั่งของ frontend ตามแต่ละ framework ที่ใช้งาน เป็นการแสดงผลและรับ action ต่าง ๆ จากผู้ใช้งาน ในการทดสอบจะเป็น component test ในแต่ละตัว สามารถเชื่อมต่อกันได้ ไม่มีประเด็นอะไร ตามความต้องการเลย
  • Service/Gateway/Business เป็นส่วนของ business logic การทำงานในฝั่ง frontend นั่นเอง ในส่วนนี้ เขียน unit test ปกติได้เลย อาจจะมีการ mock พวก dependency ได้ หรือ จะต่อ integration หรือ จะ fake ก็ได้ตามความต้องการ
  • ส่วนพวก External service ที่ฝั่ง frontend ที่ต้องเรียกใช้งานนั้น เราสามารถต่อจริงได้ หรือ จำลองให้เหมือนจริง (Fake external service) ได้ เพื่อให้เราสามารถทดสอบซ้ำได้ง่ายขึ้น ในส่วนนี้ผมชอบใช้ cypreess + network request มาก ๆ

หรืออาจจะทดสอบในฝั่ง UI แบบทั้งมุมมองของ developer และ QA/Tester ได้
ซึ่งก็มีเครื่องมือให้ใช้เยอะ ทั้ง

  • Cypress
  • Selenium
  • Playwright
  • Puppeteer

หัวใคสำคัญคือ ความเข้าใจร่วมกัน ก่อนที่จะเริ่มพัฒนามากกว่านะ
เพื่อไม่ให้หลงทางกันไปไกล

แนะนำ NCrunch สำหรับ Live Testing ใน .NET

$
0
0

วันนี้ลองเรื่องการทำ Live หรือ Continuous Testing ใน Microsoft Visual Studio
ไปเจอว่ามี NCrunch ให้ใช้งานตามที่ต้องการ
ช่วยให้เราเห็นผลการทดสอบแบบ real time เมื่อมีการบันทึก code
รวมทั้งแสดง code coverage ใน IDE ให้อีกด้วย
เป็นเครื่องมือที่น่าสนใจมาก ๆ
ลองติดตั้งและใช้งานกันดูครับ ง่ายมาก ๆ

รวมทั้งสามารถจัด category ของการทดสอบได้ด้วย
ว่าเราจะ run test ที่อยู่ใน category ไหน
ซึ่งทำให้การทดสอบมีความยืดหยุ่นมากยิ่งขึ้น

แก้ไขปัญหา ‘stdlib.h’ file not found ของ Go บน MacOS

$
0
0

ปัญหาที่พบเจอหลังจากทำการ upgrade MacOS ใหม่
พบว่าภาษา Go จะเจอปัญหาว่า
"'stdlib.h' file not found"

ส่งผลทำให้ไม่สามารถ download หรือ test หรือ ทำอะไรไม่ได้เลย

[code] runtime/cgo _cgo_export.c:3:10: fatal error: 'stdlib.h' file not found [/code]

สาเหตุหลัก ๆ มาจากการยังไม่ติดตั้ง XCode และ Command line tool
แต่หลังจากที่ทำการติดตั้งและ upgrade XCode
และติดตั้ง Command line tool ผ่านคำสั่ง $xcode-select --install
ก็ไม่สามารถแก้ไขได้

จึงลองไปทำการ Download Command Line Tools for Xcode - Apple Developer
มาติดตั้งเอง เพียงเท่านี้ก็แก้ไขได้แล้ว

บันทึกการใช้งาน DBML ในการออกแบบและพัฒนาระบบ

$
0
0

มี project ต้องการใช้งาน DBML (Database Markup Language)
สำหรับการออกแบบและพัฒนาระบบงาน
จึงทำการสรุป flow การทำงานไว้นิดหน่อย


ซึ่งช่วยให้

  • การออกแบบง่ายและยืดหยุ่น
  • มีเอกสารที่ update ตลอดเวลา
  • สามารถทำการสร้าง table ต่าง ๆ ได้ทันที เมื่อมีการเปลี่ยนแปลง
  • สามารถ generate code ในส่วนของ model/entity ได้เลย

ขั้นตอนการทำงานเป็นดังนี้

  • ทำการออกแบบ table และความสัมพันธ์ต่าง ๆ ด้วย DBML code
  • ทำการเก็บ DBML code ไว้ใน version control system เช่น Git เพื่อให้สามารถ track และจัดการ version ได้ง่าย
  • DBML สามารถแสดงผลได้ง่าย ๆ ผ่าน DB Diagram
  • เรื่องการจัดทำเอกสาร ก็ใช้งาน DB Docs ได้เลย
  • ทำการ generate SQL schema หรือ DLL ของ table จาก DBML ด้วย CLI :: dbmltosql ซึ่งสนับสนุน database ต่าง ๆ เยอะเลย
  • ทำการ generate model/entity ได้เลย

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

Spring Boot 3 กับ GraalVM == Native Java

$
0
0

เพิ่งเห็นว่า Spring Boot RC2 ถูกปล่อยออกมาแล้ว
โดยสิ่งที่เพิ่มเข้ามาเป็นค่า default คือ Native Java ด้วย GraalVM นั่นเอง
ทำการแปลงจาก bytecode มาเป็น native machine code (executable หรือ native image) ให้
ทำให้สามารถ run ระบบงานโดยไม่ต้องใช้งาน JVM

ประโยชน์ที่ได้รับ ประบกอบไปด้วย

  • ระบบงาน start ได้เร็วขึ้น
  • Latency น้อยลง
  • ใช้ memory และ CPU น้อยลง

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

สำหรับการ build ด้วย Gradle

ปล. อย่าลืมติดตั้ง
GraalVM :: Native Image และตรวจสอย $JAVA_HOME และ $GRAALVM_HOME

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

ทำการ build native image กันจาก Gradle

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

เปรียบเทียบการ run แบบเดิมกับ native ว่าต่างกันอย่างไร
สำหรับ start up time

[gist id="b33e694a9ac992d1a2374b0ddc88bd48" file="3.txt"]

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

Reference Websites

  • https://blogs.oracle.com/java/post/go-native-with-spring-boot-3-and-graalvm
Viewing all 2000 articles
Browse latest View live