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

สรุปสิ่งที่น่าสนใจกับ Technology Radar Vol. 23

$
0
0

https://www.thoughtworks.com/radar

เพิ่งเห็นว่า Technology Radar Vol. 23 ออกมาแล้ว
โดยผลในครั้งนี้ มีสิ่งที่น่าสนใจดังนี้

  • การใช้งาน GraphQL ที่ไม่ถูกต้อง ตามเป้าหมายของมันเอง
  • การพัฒนาระบบทำงานบน Web Browser ที่ยังต้องปรับและแก้ไข ทั้งวิธีการและดทคโนโลยีให้เหมาะสม
  • แสดงสิ่งต่าง ๆ ให้เป็นรูปภาพหรือ Visualization เพื่อให้ง่ายต่อการอธิบายและความเข้าใจ ทั้งข้อมูลและระบบ network และ architecture เป็นต้น
  • เรื่องของ Infrastructure as Code นั้นถูกปรับปรุงจนให้เริ่มใช้งานได้ดีขึ้นมา แต่ก็ยังมีทั้งข้อดีและข้อเสีย
  • ในเรื่องของ programming นั้นมีเครื่องมือพวก low-code ช่วยให้คนที่ไม่มีความรู้ด้าน programming มากนัก สามารถสร้างระบบงานได้ง่ายขึ้น

เรื่องของ GraphQL อย่างไม่ถูกต้อง

ทั้งการ expose ข้อมูลออกมามากจนเกินไป
ทั้งการทำตัวเป็นศูนย์กลางของระบบข้อมูล
ทั้ง ecosystem ที่ใหญ่ขึ้นมากจนเกินไป
จึงแนะนำให้ระมัดระวังต่อการใช้งานอย่างมาก

บ่อยครั้งสิ่งที่ผมเจอมาคือ  GraphQL มันกลายเป็น Store procedure
เพียงแค่เปลี่ยนที่อยู่เท่านั้นเอง
ส่งผลให้ยากต่อการเปลี่ยนแปลง
หรือมีผลกระทบจำนวนมากจากการเปลี่ยนแปลง

เรื่องต่อมาที่น่าสนใจคือ การพัฒนาระบบงานบน Web Browser

ซึ่งยังคงทำการปรับปรุงอย่างต่อเนื่อง
เพื่อให้เหมาะสมกับงานหรือ use case ต่าง ๆ มากยิ่งขึ้น
ทั้ง framework ในการพัฒนาเช่น Svelte, React และ Vue.js
และยังมีเครื่องมือทดสอบใหม่ ๆ
เช่น Playwright และ  Mock Service Worker เป็นต้น

ส่วนของเครื่องมือในการพัฒนาที่น่าสนใจมาก ๆ 

ประกอบไปด้วย

  • Apache Airflow สำหรับจัดการ workflow ของ data processing
  • Dependabot สำหรับการตรวจสอบ dependency ของระบบว่าเป็นอย่างไร ซึ่งจะทำการ integrate เข้ากับ GitHub หรือใช้งาน Renovate กับ GitLab และ BitBicket เป็นต้น
  • Trivy สำหรับการ scan container เกี่ยวกับเรื่องความปลอดภัย
  • Helm คือ package manager สำหรับ Kubernetes
  • Bitrise คือ CI/CD สำหรับ mobile app (Build -> Test -> Deploy)

ปิดท้ายด้วยภาษา program และ framework ที่น่าสนใจและลองใช้งาน

ประกอบไปด้วย

  • Arrow สำหรับสายเขียน Kotlin
  • Jest-when ช่วยให้การ mock function ด้วย Jest ง่ายขึ้น
  • Fastify คือ web framework ที่ทำงานเร็วมาก ๆ เหมาะมากสำหรับสายพัฒนา backend ด้วย Node.js แถมยังสนับสนุน TypeScript อีกด้วย
  • เรื่องของ State management สำหรับ web browser application มีให้เพียบทั้ง Redux, Recoil, XState


Docker Hub ปรับเปลี่ยนนโยบายของการใช้งาน

$
0
0

Docker Hub คือ Docker Registry
สำหรับจัดเก็บ Docker Image ต่าง ๆ (เป็นค่า default)
โดยช่วง 2  เดือนที่ผ่านมา ประกาศนโยบายสำหรับการใช้งานออกมา
เพื่อลดการใช้งาน resource ต่าง ๆ ลงไป (Retention Policy)

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

Docker Image ของ account แบบฟรี ที่ไม่มีการเปลี่ยนแปลง
และการใช้งานใด ๆ เกิน 6 เดือนจะถูกลบทิ้งโดยอัตโนมัติ

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

  • ผู้ใช้งานที่ไม่ทำการ authen จะสามารถ pull image ได้ไม่เกิน 100 images ต่อ 6 ชั่วโมง
  • สำหรับ free account ที่ทำการ authentic จะ pull image ได้ 200 images

ดังนั้นถ้าใครไม่อยากติด limit หรือ ข้อจำกัดในการใช้งาน
ก็ทำการปรับเปลี่ยน subscription ให้เหมาะสมกับงานไป
เช่น Docker Pro และ Team เป็นต้น

https://www.docker.com/pricing

Reference Websites

https://www.docker.com/blog/docker-hub-image-retention-policy-delayed-and-subscription-updates/

PandasGUI :: ทำการวิเคราะห์การทำงานของ Pandas แบบ GUI กัน

$
0
0

สำหรับคนที่ทำงานสาย data ไม่น่าจะพลาด
กับการใช้งาน library ชื่อว่า Pandas
ซึ่งช่วยให้การจัดการข้อมูลเป็นเรื่องที่ง่ายและรวดเร็วขึ้นเป็นอย่างมาก
แถมมี community ที่แข็งแรงและ active อย่างมาก
อีกทั้งยังมีเครื่องมือแวดล้อมถูกสร้างขึ้นมามากมาย ไม่ว่าจะเป็น

  • SweetViz
  • Pandas profiling
  • Bamboolib

แต่มีอีกเครื่องมือหนึ่งที่น่าใช้มาก ๆ คือ PandasGUI

แสดงผลข้อมูล dataframe จาก Pandas
ออกมาในรูปแบบ GUI ซึ่งพัฒนาส่วน GUI ด้วย PyQt5
ทำให้เข้าใจการทำงานง่ายขึ้นอย่างมาก
ประกอบไปด้วย

  • การ plot ข้อมูล
  • การกรองข้อมูล
  • การดูค่าสตถิติต่าง ๆ
  • การแก้ไขข้อมูล
  • การ import ข้อมูลในรูปแบบ CSV แบบ drag&drop

ทำการติดตั้งผ่าน pip ได้เลย
$pip install pandasgui

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

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

อธิบายเกี่ยวกับรูปแบบของ CQRS (Command-Query Responsibility Separation)

$
0
0

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

  • ปัญหาในการแก้ไขข้อมูลทั้งการเขียน แก้ไขและลบ
  • ปัญหาในการอ่านข้อมูล

มักจะแก้ไขข้อมูลโดยไม่คำนึงถึงการใช้งาน เช่นการ ดึงข้อมูลเลย
เก็บ ๆ กันไปก่อน แล้วค่อยไปดึงการทีหลัง !!

ยกตัวอย่างเช่น
ในการบันทึกข้อมูลจะกระจายข้อมูลไปยัง table ต่าง ๆ ของ RDBMS
แต่เมื่อต้องอ่านข้อมูล จำเป็นต้อง join กันใน table จำนวนมาก
ผลคือ เมื่อระบบมีข้อมูลมากขึ้น มีผู้ใช้งานสูงขึ้น 
ส่งผลให้ระบบทำงานช้าลงไปอย่างมาก !!

เราควรแก้ไขปัญหาเช่นนี้อย่างไรบ้าง ?

จึงเป็นที่มาของการอธิบายแนวคิดของ CQRS (Command-Query Responsibility Separation) 
แบบคร่าว ๆ นิดหน่อย
เพื่อให้เห็นแนวทางหนึ่งในการแก้ไขแบบง่าย ๆ

หัวใจหลักของ CQRS คือ

การแยกกันออกแบบและทำงานระหว่าง
การแก้ไขข้อมูล (Command operation)
และการอ่านข้อมูล (Query operation)
แน่นอนว่า ทั้งสองส่วนมีการทำงานที่แตกต่างกัน
ดังนั้นการออกแบบและพัฒนาน่าจะต่างกัน
ทั้งเรื่องของ entity ของข้อมูล
ทั้งเรื่องของ Database model ที่ใช้งานทั้ง Relational และ NoSQL
ทั้งเรื่องของ Database server ที่อาจจะต้องแยกกันหรือไม่
ทั้งเรื่องของระบบที่รองรับก็ต้องแยกกันหรือไม่

แต่ปัญหาที่ตามมาคือ ความซับซ้อนของระบบที่สูงขึ้น
การพัฒนาและดูแลที่ยากขึ้น หรือมี operation สูงขึ้น

https://thenewstack.io/how-cqrs-works-with-spring-tools/

ใน CQRS นั้นก็มีโครงสร้างการทำงานหลาย ๆ แบบ
แต่มีรูปแบบที่ใช้งานบ่อย ๆ 3 แบบดังนี้

แบบที่ 1 ใช้งาน Database เดียวกัน

เป็นรูปแบบของ CQRS ที่เรียบง่ายที่สุด
คือแยกการทำงานใน code ออกจากกัน
ยกตัวอย่างเช่น
การแก้ไขข้อมูลอาจจะใช้ ORM framework เช่น JPA หรือ Hibernate เป็นต้น
ส่วนฝั่งการอ่านข้อมูลใช้งานผ่าน SQL ตรง ๆ ไปเลย

แสดงดังรูป


https://levelup.gitconnected.com/3-cqrs-architectures-that-every-software-architect-should-know-a7f69aae8b6c

แบบที่ 2 แยก database ออกจากกัน

แต่เมื่อมีการแก้ไขข้อมูลแล้ว
จะต้องทำการบันทึกการเปลี่ยนแปลงนั้น ๆ 
ไปยัง database ของการอ่านข้อมูลเสมอ

แสดงดังรูป


https://levelup.gitconnected.com/3-cqrs-architectures-that-every-software-architect-should-know-a7f69aae8b6c

แบบที่ 3 แยก database เช่นกัน แต่นำ Event Sourcing มาช่วยในการ sync ข้อมูล

โดยการ sync ข้อมูลนั้น จะไม่ได้เป็นแบบ synchronous หรือทันที
จะป็นแบบ asynchronous หรือในเรื่องของ consistency
จะเรียกว่า Eventual Consistency นั่นเอง
เพื่อปรับปรุงประสิทธิภาพการทำงานของแบบที่ 2

แสดงดังรูป


https://levelup.gitconnected.com/3-cqrs-architectures-that-every-software-architect-should-know-a7f69aae8b6c

ปล. ทุกแนวทางมีทั้งข้อดีและข้อเสีย
ดังนั้นควรเข้าใจก่อนการเลือก
รวมทั้งเลือกวิธีการให้เหมาะสมกับปัญหารวมทั้งความรู้ความสามารถในการจัดการด้วย

VSCode : ทำการ sync ค่า setting ต่าง ๆ ข้ามเครื่อง

$
0
0

ปัญหาที่เจอในการใช้ VS Code ตอนนี้คือ
ต้องเปลี่ยนไปใช้งานหลายเครื่อง ทำให้ต้อง copy หรือทำการ setting ใน VS Code
ในแต่ละเครื่องหรือ device นั้น ๆ ใหม่หมดเลย
แน่นอนว่า เป็นเรื่องที่น่าเบื่อมาก ๆ

เมื่อไปดูความสามารถใน VS Code พบว่า
มี Settings Sync ให้ใช้งาน เป็น Preview version เท่านั้น
โดยเลือกได้เลยว่าจะ Sync ไปที่ Microsoft หรือ GitHub

หรือถ้าก่อนหน้านี้ก็จะมี Extension ชื่อว่า Setting Sync ให้ใช้งาน
ลองใช้งานดูครับ

แนวทางการนำ Elixir มาใช้พัฒนาระบบ Change.org

$
0
0

จากบทความเรื่อง Delivering social change with Elixir at Change.org นั้น
อธิบายการย้ายระบบ messaging จากใช้ software อื่น ๆ 
เปลี่ยนมาเป็นระบบที่พัฒนาด้วยตนเอง โดยใช้ภาษา Elixir
มีเป้าหมายเพื่อลดค่าใช้จ่ายและความยืดหยุ่น
เพื่อรองรับความต้องการของระบบที่หลายหลายมากขึ้น

โดยในบทความจะอธิบายถึงปัญหาที่พบเจอ
เหตุผลว่าทำไมถึงเลือก Elixir ?
วิธีรองรับ email มากกว่า 1,000 ล้าน email ต่อเดือนกันอย่างไร ?

จาก requirement และการทำงานของระบบ Change นั้น

จะได้รับ event ต่าง ๆ จากการใช้งานในระบบมากมาย เช่น

  • Event ของ campain ต่าง ๆ
  • Event ของการร้องเรียน ต่าง ๆ
  • มีการส่ง email ไปยังส่วนต่าง ๆ ที่เกี่ยวข้องหรือสนใจ

ทีมพัฒนามองหาระบบที่สนับสนุนพวก Event-driven มาจัดการ
ต้องรองรับการใช้งานพร้อม ๆ กันจำนวนมาก
รวมทั้งเรื่องของ fault-tollerance อีกด้วย

ก่อนที่จะเลือกก็ต้องทำ PoC (Proof of Concept) ก่อน

โดยมี 4 ตัวเลือกที่นำมาทดลอง ประกอบไปด้วย

  • JRuby
  • Akka Stream
  • Node.js
  • Elixir

เป้าหมายของการทดลองเพื่อ 
ดูเรื่องของ performance ของการทำงาน ว่าไหวไหม
ประสบการณ์ในการพัฒนา ว่าเป็นอย่างไร
ดูเรื่องของ community ว่า
สามารถสนับสนุนหรือตอบโจทย์ใน use case ต่าง ๆ ที่เจอหรือไม่
รวมทั้งเรื่องของการแก้ไขปัญหาต่าง ๆ
โดยที่ทุก ๆ ทางเลือกต้องทำการประมวลผลข้อมูลประมาณ 100K message
เพื่อนำมาเปรียบเทียบกัน
เป็นวิธีการเลือกที่ดีมาก ๆ แต่หลาย ๆ บริษัทมักจะไม่ทำกัน !!  

โดยหลังจากที่ผ่านการทดลองมาแล้วได้เลือก Elixir นั่นเอง
ที่น่าสนใจคือ ทีมพัฒนามีจำนวนเพียง 3 คน
มีเวลา 18 เดือนในการพัฒนาและนำมาแทนที่ของเดิม

แนวทางในการเรียนรู้ Elixir ของทีม

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

ส่วนการ migrate นั้น ก็จะค่อย ๆ ทำไปในแต่ละส่วนงาน
ค่อย ๆ ย้ายมาในแต่ละ use case
เพื่อทำให้มั่นใจว่า สามารถทำงานได้ถูกต้องและมีประสิทธิภาพ เช่น

  • ระบบจัดการ email
  • ระบบ analytic

โดยการ migrate ระบบต่าง ๆ มายังระบบใหม่นั้น ใช้เวลาประมาณ 1 ปี

ส่วนการรองรับผู้ใช้งานจำนวนมาก ๆ

พบว่าสามารถรองรับได้มาก โดยที่ใช้จำนวนเครื่องลดลง
จาก 8-10 เครื่อง เหลือเพียง 2 เครื่องเท่านั้น

Library ที่ใช้งาน ประกอบไปด้วย

ตัวอย่างของ service ที่พัฒนา

ในตอนนี้ Elixir คือ
ภาษาโปรแกรมหลักของการพัฒนาระบบ  backend ของ Change
โดยปัจจุบันมีมากกว่า 20 project ที่พัฒนาไปแล้ว

ว่าง ๆ มาลอง custom JRE ด้วย Java Linker กันหน่อย

$
0
0

ตั้งแต่ JDK 9 ขึ้นมานั้น จะมี Java Linker มาให้ ซึ่งเป็น command line tool 
ช่วยให้เราสามารถทำการ custom JRE (Java Runtime Environment) 
เหมาะสมกับ application ของเราได้เอง
โดยจะทำงานร่วมกับแนวคิดของ module นั่นเอง

ก่อนอื่นต้องเข้าใจก่อนว่า

ตั้งแต่ Java 8 ขึ้นมานั้น
แนวคิด Module หรือ Project Jigsaw ถูกนำเข้ามาใช้งาน
ทำให้เราสามารถเลือกหรือจัดการ JRE ตามรูปแบบการใช้งานได้
ช่วยทำให้ Software ที่ส่งมอบมีขนาดเล็กลง
ใช้ resource ต่าง ๆ น้อยลง
ทำให้   run ระบบงานได้หลากหลายมากขึ้น

เราสามารถดู module ต่าง ๆ จาก JRE ที่ใช้งานอยู่ในปัจจุบันด้วยคำสั่ง

[gist id="2ce1a60122081e6de0c78bac0ab5cd5f" file="1.txt"]

และใน Java 9 ก็มี command line ชื่อว่า jlink
ช่วยให้เราสามารถ custom JRE ได้ง่ายขึ้น
เพื่อให้เข้าใจง่าย ๆ มาลองกับ Hello World ดีกว่า

[gist id="2ce1a60122081e6de0c78bac0ab5cd5f" file="Hello.java"]

ทำการกำหนดให้ code ตัวอย่างอยู่ใน module ชื่อว่า demo.module

[gist id="2ce1a60122081e6de0c78bac0ab5cd5f" file="module-info.java"]

ซึ่งถ้าเราใช้ JRE แบบ default นั้นจะพบว่ามีจำนวน module มากมาย
มีขนาดมากกว่า 200 MB ซึ่งเยอะเกินความจำเป็น
เนื่องจาก code ตัวอย่างของเรานั้น
จะใช้เพียง Object, String และ System class เท่านั้น
แถม code น่าจะมีขนาดเพียง 1 KB เท่านั้นเอง
ดังนั้นมา custom JRE ให้เหมาะสมกับระบบงาน Hello World ของเราดีกว่า

ทำการ compile และ run โปรแกรมในรูปแบบของ Module ได้ดังนี้

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

โดย Hello World นั้นจะใช้งานเพียง base module ของ JRE ที่มีมาให้เท่านั้น
ดังนั้นเราจึงทำการสร้าง JRE ให้เหมาะสมด้วยการใช้งานผ่าน jlink ดังนี้

[gist id="2ce1a60122081e6de0c78bac0ab5cd5f" file="3.txt"]

ผลที่ได้คือ JRE ใหม่ที่เหมาะสมกับระบบงานของเราเท่านั้น
ซึ่งขนาดของ JRE ที่ได้จะมีขนาดเพียง 40 MB เท่านั้น !!
น่าจะเป็นอีกแนวทางหนึ่งในการพัฒนาระบบด้วย Java ให้มีประสิทธิภาพสูงขึ้น

ตัวอย่าง code ทั้งหมดอยู่ที่ GitHub::Demo Custom JRE

TED rule เพื่อการเขียน code ที่ดีขึ้น

$
0
0

วันนี้กลับไปดูเรื่อง Wrting Code for Humans อีกรอบ
เพื่อสรุปประเด็นที่น่าสนใจเพิ่มเติม
หนึ่งในนั้นคือ แนวทางในการเขียน code ที่ดี
เพื่อลดสิ่งรบกวน หรือ code แย่ ๆ รูปแบบต่าง ๆ ใน code ลงไป
นั่นคือแนวทางที่เรียกว่า TED rule

T = Terse  =  code ที่เขียนต้องสั้น กระชับ ได้ใจความ
E = Expressive = code ต้องชัดเจน อธิบายถึงสิ่งที่ต้องการสื่อสารและสิ่งที่ทำงาน
D = Do one thing = code ต้องมีหน้าที่การทำงานชัดเจน หรือ ทำเรื่องหนึ่ง ๆ ให้ดีไปเลย

จะสังเกตได้ว่า TED rule นั้น

มีเป้าหมายเพื่อช่วยปรับปรุงคุณภาพของ code ให้ดีขึ้น
เพื่อในวันหน้าเมื่อเรากลับมาดูหรือแก้ไข code แล้ว
จะทำให้ชีวิตง่ายขึ้น
มิฉะนั้นแล้ว code ที่แย่ ๆ  อาจจะทำให้คนในองค์กรหรือทีมไม่อยากอยู่ทำงานก็เป็นไปได้

ยกตัวอย่างของสิ่งรบกวนใน code ที่มักเกิดขึ้นประจำ

  • ความซ้ำซ้อน
  • Class/file มีขนาดใหญ่
  • Method ยาว ๆ
  • ความซับซ้อนของ code สูง
  • การตั้งชื่อที่ไม่สื่อถึงการทำงาน
  • การ comment code ที่ไร้ประโยชน์ บางครั้งไม่ตรงกับการทำงานจริง ๆ ของ code
  • เกิด Zombie code หรือ code ที่ถูก comment แต่ไม่ได้ถูกลบออกไป บางครั้งมีเอากลับมาใช้ด้วย !!!

ลองกลับไปดู code ที่เราเขียนหน่อยว่า
เป็นไปตาม TED Rule หรือไม่ ?


บันทึกการวิ่ง trail 100 กิโลเมตรครั้งแรกที่โป่งแยง 2020 (PYT)

$
0
0

ในกลุ่มนั่งวิ่ง trail บอกว่า
วิ่ง 100 กิโลเมตร สามารถวิ่งได้หลายครั้ง
แต่การวิ่ง 100 กิโลเมตร ครั้งแรก มีได้เพียงแค่ครั้งเดียว

จึงทำการสรุปประสบการณ์ที่เจอด้วยตนเองไว้นิดหน่อย
โดยสนามที่เลือกคือ โป่งแยง (PYT :: Pong Yaeng Trail)
มาเริ่มกันเลย

สรุปผลการวิ่งกันก่อน

  • ระยะทางจากทางสนามคือ 109.8 กิโลเมตร
  • ความชันสะสมขาขึ้น 5,220 เมตร
  • ความชันสะสมขาลง 5,010 เมตร
  • ใช้เวลาวิ่งไปทั้งหมด 25 ชั่วโมง 22 นาที 45 วินาที
  • เริ่มวิ่งประมาณตี 4.15 จนเข้าเส้นชัย ตี 5.38 ของอีกวัน

ข้อมูลจากนาฬิกาที่ใส่วิ่ง

Gain จากนาฬิกามันมั่ว ระยะก็มากกว่าความเป็นจริง

Zone ที่วิ่ง

ผลการแข่ง

บันทึกในแต่ละ station ของการวิ่ง เขียนเท่าที่จำได้

1. Start ไปถึง A0 แม่ขิ

เริ่มต้นวิ่งเวลาตี 4.15 อยู่ใน block B
ออกมาจากจุด Start ก็เป็นทางถนนปูนยาวไป
ความชันไม่มากนัก แต่ยาวไปเรื่อย ๆ
วิ่งท่ามกลางความมืด ก็สนุกดี  ได้ warmup กล้ามเนื้อไปในตัว

ในช่วงแรก ๆ ที่เริ่มวิ่ง รู้สึกว่าขาตึงนิดหน่อย เลยวิ่งเบา ๆ ไป
ช่วงนี้เพื่อนนักวิ่ง วิ่งเกาะกลุ่มใหญ่กันไปเรื่อย
พอเข้าถึง A0 แม่ขิ อยู่ก่อนเข้าทาง trail จริง ๆ ที่เป็นป่าแล้ว
ถึงตรงนี้ขาที่ตึงหายไปหมดแล้ว
นั่นแสดงว่า น่าจะ warm up มาไม่ดี
แวะล้างหน้า เติมน้ำนิดหน่อย  ก็วิ่งต่อกันเลย
มาถึงตรงนี้ใช้เวลาไป 2 ชั่วโมง กับระยะ 13 กิโลเมตร
ถือว่าใช้ได้เลย

2. A0 แม่ขิ ถึง A8 แม่ปะ

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

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

พอออกจากป่าก็เข้าถึงหมู่บ้านเพื่อเข้าไป A8 แม่ปะ
ช่วงนี้ระยะ 10 กิโลเมตร แต่ใช้ไป 2 ชั่วโมง
เข้ามา A8 ฟ้าก็สว่างแล้ว ได้กินน้ำร้อน ๆ
แต่มีแต่กาแฟ เลยกินได้แค่น้ำร้อน
กับข้าวราดแกงจืด จัดว่าอร่อยเลย
รวมกับได้กินข้าวต้มมัดด้วย อร่อยมาก ๆ

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

อยู่ในแต่ละ station ให้น้อยที่สุด แต่ก็ไม่รีบเร่งมาก

3. A8 แม่ปะ ถึง W1 (Water station)

ช่วงนี้ไม่มีอะไรมาก ทางไม่ยาก เหมือนวิ่งให้อาหารย่อยมากกว่า
รวมทั้งเป็นช่วงเช้า ๆ ด้วย ร่างกายเพิ่งตื่นตัว
กับระยะทางประมาณ 6 กิโลเมตร ใช้เวลาไป 1.10 ชั่วโมง
เมื่อถึง W1 ก็ล้างหน้าล้างตานิดหน่อย แล้วไปต่อเลย

ต่อจากนี้ได้ดึงไม้เท้าเอามาใช้แล้ว !! ซึ่งใช้ตลอดจนจบ

4. W1 (Water station) ถึง A9 สะเมิง

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

หลาย ๆ คนขาพลิก
เจ็บ ITB กันเพียบ
เจ็บเท้า
ที่สำคัญคือ ที่ A9 เป็น station ใหญ่
หลาย ๆ คนพร้อมใจกับ DNF เพียบ

รู้สึกได้เลยว่า station นี้ไม่ควรอยู่นาน
เพราะว่า ยิ่งอยู่นาน ใจมันเริ่มห่อเหี่ยว

ลืมบอกไปว่า สิ่งที่อร่อยมาก ๆ ในทุกstation คือ ส้มเขียวหวาน
ขอบอกว่า มันสุดยอดมาก ๆ
กินเวลาง่วง
กินเวลาเหนื่อย
กินเวลาท้อ
มันช่วยได้เยอะมาก ๆ

จากนั้นก็เติมน้ำให้เต็มก่อนออกไป W2 
ช่วงนี้ระยะประมาณ 11 กิโลเมตร ใช้เวลาไป 2 ชั่วโมง
ขาเริ่มตึง ๆ ขึ้นมา จึงทำการยืดเหยียด และทายานวดนิดหน่อย
ที่ station นี้มีถังไอติมให้ตักเองด้วย แต่ยังไม่ค่อยอร่อยเท่าไร

5. A9 สะเมิง ถึง W2 (Water station)

หลังจากหนีความหดหู่ที่ A9 ออกมาประมาณ 1 กิโลเมตร
ก็ได้เวลาขึ้นเขากันอีกแล้ว
เป็นทางปูนสลับกับลูกรังไปเรื่อย ๆ
ความ peak ของทางช่วงนี้คือ แดด และ ความชันที่มันขึ้นไปเรื่อย
แถมมีหลายช่วงที่ชันมาก และ ยาวมาก ๆ วนไปเรื่อย ๆ

เส้นทางมีความโหดร้าย ระดับบ่นกันว่า เมื่อไรมันจะถึง W2 !!

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

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

ยิ่งเราเดินไปเรื่อย เป้าหมายมันก็ใกล้เข้ามาเรื่อย ๆ นั่นเอง
ไม่ต้องถามว่าเหลือระยะอีกเท่าไร
เพราะว่า เมื่อมันถึงก็ได้หยุดเอง
ช่วงนี้ระยะทางประมาณ 10 กิโลเมตร ใช้เวลาไป 2.17 ชั่วโมง

6. W2 (Water station) ถึง A10 กองแหะ

ที่ station นี้เป็นจุดที่คนน้อยกว่าที่ A9 มาก
หลาย ๆ คนเริ่มเหนื่อย ท้อ และ ท้อมาก
ทำได้แต่นั่งคุย ให้กำลังใจกันไปต่อ

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

ส่วนผมก็ขอทำธุระกับเติมพลัง เพื่อไปต่อดีกว่า
ก่อนออกมามีรถขายไอติมไผ่ทองมาด้วย
เลยซื้อไป 1 ชิ้น อร่อยมาก ๆ
เดินออกจาก station ด้วยไอติมแสนอร่อย

แต่ว่า เดินไปได้สักพักก็ขึ้นเนินชัน ๆ กับ วิวสวย ๆ
ที่กินมาเมื่อกี้ หมดไปโดยทันที !!
เป็นเส้นทางที่ปีที่แล้วเคยมาที่เป็นขาเดียว
แต่ปีนี้วิ่ง 100 กิโลเมตร ต้องวิ่งไปกลับ
ขอบอกว่าโหดร้ายมาก ๆ
ขึ้นสุดลงสุดไม่ต่ำกว่า 6 เนินชัน ๆ
เป็นทางปูนครึ่งทาง เป็นทางป่าอีกครึ่ง

ระยะเพียง 8 กิโลเมตร แต่ใช้เวลาไปเกือบ 2 ชั่วโมง
โดยใน station นี้จะมี drop bag หรือถุงใส่ของให้เปลี่ยนได้
แต่ผมไม่ได้ใช้เลย เพราะว่าไม่รู้จะใช้อะไร

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

7. A10 กองแหะ ถึง A11 แม่ขนิลเหนือ

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

ช่วงนี้จัดว่ายาวมาก ๆ กว่า 17 กิโลเมตร ใช้เวลาไปกว่า 4 ชั่วโมง
เนื่องจากขาลงทางลื่นใช้ได้เลย
และอีกอย่างความมืดกลับมาอีกครั้ง
นั่นหมายความว่า วิ่งมาแล้วไม่ต่ำกว่า 13-14 ชั่วโมงจากตอนเริ่มต้น
ถามว่าง่วงไหม ตอบเลยว่าไม่ !! มันเหนื่อยจนไม่มีเวลามาง่วง

8. A11 แม่ขนิลเหนือ ถึง A12 นิลประภา

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

ช่วงนี้มี buddy วิ่งด้วยแล้ว เพราะว่าแอบเกาะเขามาตั้งแต่ช่วงมืด ๆ
จากนั้นก็เดิน เดินวิ่งสลับวิ่งช้า ๆ ตามมาห่าง ๆ
ทำให้การวิ่งสนุกขึ้นเยอะ

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

แต่เตือนกับตัวเองตลอดว่า 
อย่าลืมกินน้ำทุก ๆ กิโลเมตร
อย่าลืมเติมเหลือทุก ๆ 30 นาที
ทำแบบนี้ไปเรื่อย ๆ ช่วยทำให้ระบบร่างกายไม่รวนมาก

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

9. A12 นิลประภา ถึง A13 ตาดครก

พอออกจาก A12 ได้ไม่เท่าไร
ก็ขึ้นอีกแล้ว มันขึ้น แล้วก็ขึ้น แล้วก็ขึ้น แล้วก็ขึ้น
จำได้อย่างเดียวว่า ค่อย ๆ เดินไป ค่อย ๆ เดินไป
นับก้าวไป 1 2 3 4 5 แบบช้า ๆ
ใช้ไม้เท้าช่วยดันไปข้างหน้า
ไม่ต้องสนใจว่าจะชัน หรือ ไกลเพียงใด
ก้าวไปข้างหน้าเรื่อย ๆ
พอถึงทางราบก็เดินเร็ว
ถึงตรงนี้ไม่ค่อยกล้าวิ่งแล้ว เพราะว่า ทางไม่ชินเลย
แต่รู้สึกได้ว่า ตัวเองไปได้เร็วขึ้น กับสภาพร่างกายที่ยัง ok อยู่

ช่วงนี้ระยะทางเพียง 8.5 กิโลเมตร ใช้เวลาไปกว่า 2 ชั่วโมง
ลืมบอกไปว่า ช่วงนี้ผมทิ้ง buddy ที่วิ่งมาด้วยกัน 1 ช่วงแล้ว
เพราะว่า ผมเดินไปข้างหน้าอย่างเดียวช่วงขึ้นเขา
พอหันมาข้างหลังแล้วไม่เห็นใคร
ผมเลยเดินไปข้างหน้าต่อเลย
ต้องขออภัยด้วยครับ
ช่วงนั้นกำลัง focus กับการเดินไปข้างหน้าอย่างมาก

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

จุดนี้ออกมาจากหมู่บ้านนิดหน่อย เป็น station ที่ใช้เวลาอยู่น้อยที่สุดแล้ว
เพราะว่า ใจอยากจะไปให้ถึงเร็ว ๆ แล้ว
อีกอย่างใน station บอกว่า
อันดับที่ 91 เพิ่งออกไป
ตอนนี้มีโอกาสติด Top 100 คนนะ
ได้ยินก็เข้า mode แข่งขัน เอาวะ ลองหน่อยสิ จะไปได้ไกลเท่าไร ?

สูดหายใจยาว ๆ สักหน่อย แล้วบอกกับตัวเองว่า
ไปต่อกัน ถ้ากายกับใจมันไปด้วยกันได้ ก็ไปต่อได้...

10. A13 ตาดครก ถึง W3 (Water station)

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

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

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

พอมาถึง W3 นักวิ่งเริ่มเบาบาง บางคนนอนหลับที่นี่เลย
สำหรับผมก็เช่นเคย ใช้เวลาใน station ให้น้อย เติมน้ำ นวดขาแล้วออกไปเลย
แต่ถึงตรงนี้ การนวดขาไม่ช่วยอะไร
แค่ยืนเฉย ๆ มันเริ่มชาแล้ว
ดังนั้นขยับตัวดีกว่า ไปต่อกันเลย
เพื่อเข้าเส้นชัย กับระยะที่แถมกว่า 9 กิโลเมตร  !!!

11. W3 (Water station) ถึง Finish ลานผานกกก

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

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

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

ส่วนผมก็ค่อย ๆ เดิน ค่อย ๆ วิ่งเบา ๆ 
ตอนลงก็เสียว ๆ เหมือนกัน

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

พอถึงเส้นชัยเท่านั้นแหละ 

ทุกอย่างที่เราซ้อมมา เตรียมมา มันช่วยทำให้เราถึงเส้นชัย
สามารถวิ่ง trail 100 กิโลเมตรแรกได้แล้ว
โดยใช้เวลาไปทั้งหมด 25 ชั่วโมง 22 นาที 45 วินาที

แต่สิ่งที่ peak ใน peak อีกคือ ต้องขึ้นไปรับเหรียญ
ยังต้องขึ้นเนินชัน ๆ ไปรับเหรียญอีก สุดจริง ๆ บอกเลย
++

แต่เป็นความยากลำบากที่มีความสุข

ไม่ได้คิดว่า เรามาวิ่ง 100 กิโลเมตร แต่ค่อย ๆ ไปทีละ station
บางครั้งก็มี mode ชิว ๆ
บางครั้งก็มี mode งอแงกับตัวเอง
บางครั้งก็มี mode การแข่งขัน
มันแปลก ๆ ยังไงก็ไม่รู้
แต่ก็ได้อยู่กับตัวเอง
พากายและใจไปพร้อม ๆ กัน
ไม่ฝืนหรือขัดแย้งกัน

ซึ่งน่าจะเป็นรางวัลที่ได้จากการซ้อม

ซ้อมอย่างไร ก็วิ่งอย่างนั้น
ไม่มีเขาลูกไหน สูงกว่าเขาในใจเรา ถ้าเราซ้อมมานะ !!
ไปให้ใกล้เป้าหมายให้ได้มากที่สุด แล้วเราจะถึงเป้าหมายนั้นเอง

รูปในงานออกมาแล้ว

มาลองใช้งาน Digital Ocean App Platform

$
0
0

เพิ่งเห็นทาง DigitalOcean ปล่อย PaaS (Platform as a Service) ใหม่ออกมา
ในชื่อว่า DigitalOcean App Platform
ช่วยทำให้ผู้ใช้งานสามารถ deploy ระบบงานได้ง่ายและสะดวกมากขึ้น
โดยมีแนวคิดง่าย ๆ  คือ Focus on Code, Not Servers
ดังนั้นมาลองใช้งานกันหน่อยว่า ง่ายจริงไหม ?

ขั้นตอนที่ 1 ทำการสร้าง DigitalOcean Application

ขั้นตอนที่ 2 ทำการเชื่อมต่อกับ Repository ใน GitHub

โดยใน repository คือระบบงานท่ีจะทำการ deploy ไปยัง DigitalOcean App Platform นั่นเอง

ดังนั้นต้องทำการ push code ของระบบไปยัง GitHub ก่อน
ยกตัวอย่างเช่น ทำการสร้าง REST API ด้วยภาษา Go ซึ่ง code
ตัวอย่างอยู่ที่ GitHub:Up1
และเลือก Repository ที่ต้องการใช้งาน

ขั้นตอนที่ 3 ทำการเลือก Region และ Branch ที่ต้องการ deploy

โดยที่มีเพียง 3 ประเทศเท่านั้น !!
ที่สำคัญเราสามารถเลือกได้ว่า จะให้ auto-deploy เมื่อ code เปลี่ยนแปลงหรือไม่อีกด้วย

จากนั้นจะตรวจสอบเจอว่า เป็น Application แบบไหนเอง ตัวอย่างคือ 

  • Go
  • Type = Web Service
  • Command ที่จะ run คือ bin/server

รวมทั้งสามารถเลือก Database ได้อีกด้วย มันสบายมาก ๆ เลยนะเนี่ย !!

ขั้นตอนที่ 4 เลือก Plan สำหรับ server ได้เลย

ลองไปดู pricing กันเอง

ขั้นตอนที่ 5 ทำการ deploy ระบบงาน

ผลการ deploy เรียบร้อย

ขั้นตอนสุดท้าย ทำการเปลี่ยนแปลง code และ push ไปยัง GitHub

สิ่งที่ DigitalOcean App Platform ทำให้คือ Auto-Deploy นั่นเอง
เพียงเท่านี้ก็สามารถใช้งานได้แบบง่าย ๆ แล้ว
ลองไปดูการทำงานพบว่า
คือการสร้าง Docker Image และ Container นั่นเอง

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

คำถาม :: ทำการ Reload ระบบงานที่พัฒนาด้วยภาษา Go กับ Docker ?

$
0
0

มีคำถามที่น่าสนใจคือ ถ้าเราพัฒนาระบบด้วย Go ร่วมกับ Docker แล้ว
ต้องการทำให้ระบบงาน reload อัตโนมัติ เมื่อทำการเปลี่ยนแปลง code
โดยไม่ต้อง restart Docker container ใหม่
ต้องทำอย่างไร ?

คำตอบง่าย ๆ คือ

จาก blog เรื่อง Live reload ก็เลยนำบางตัวมาใช้ร่วมกับ Docker นิดหน่อย
ตัวที่ลองนำมาใช้คือ Compile Deamon
จากนั้นทำการสร้าง Dockerfile ดังนี้

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

จากนั้นสร้างไฟล์ docker-compose.yml มา เพื่อใช้งานง่ายขึ้น

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

สุดท้ายทำการ run ด้วย $docker-compose up
ลองเปลี่ยนแปลง code และ refresh
จะพบว่าระบบงานที่พัฒนาด้วย Go จะเปลี่ยนไป
โดย code ตัวอย่างอยู่ที่ GitHub::Up1

เพิ่งเห็นว่า .NET Docker เปลี่ยนชื่อแล้ว

$
0
0

หลังจากที่ .NET 5 ตัวเต็มถูกปล่อยออกมาแล้ว
สิ่งหนึ่งที่ตามมาคือ การเปลี่ยนชื่อ repository ของ .NET Docker Image
เนื่องจากชื่อเดิมเป็น .NET Core อย่างเดียว
แต่ architecture ใน .NET 5.0 เปลี่ยนแปลง จึงต้องเปลี่ยนชื่อใหม่เพื่อให้เข้าใจง่ายขึ้น
แน่นอนว่า กระทบกับการพัฒนาแน่นอน
ดังนั้นอย่าลืมไปเปลี่ยนกันนะ
และอีกอย่างแนะนำให้ใช้ tag 5.0 นะ อย่าใช้ tag latest

VS Code :: Jupyter notebook ก็ใช้งานได้

$
0
0

VS Code เป็นทุกอย่างให้แล้วจริง ๆ
หนึ่งในนั้นคือ Jupyter Notebook
ทำให้สามารถเขียน code, share code
และความสามารถต่าง ๆ ที่ทำได้ใน notebook
น่าจะเป็นอีก extension ที่มีประโยชน์

สิ่งที่เปลี่ยนแปลงใน Scrum Guide 2020

$
0
0

เพิ่งเห็นว่า Scrum Guide 2020 เพิ่งถูกปล่อยออกมา
จึงทำการลองอ่านและพบว่ามีสิ่งที่เปลี่ยนแปลงและปรับปรุงไปพอสมควร
เลยทำการสรุปไว้นิดหน่อย ตามที่เข้าใจ
มาเริ่มกันเลย

การเปลี่ยนแปลงที่เกิดขึ้นมานั้น

เป็นการสร้างความเข้าใจ เน้นย้ำ ทำให้ชัดเจนมากยิ่งขึ้น
ทั้งเรื่องของ event ต่าง ๆ
ทั้งเรื่องของ cross-functional team
ทั้งเรื่องของ artifact ต่าง ๆ
ทั้งเรื่องของเป้าหมาย และให้ชัดใน Definition of Done (DoD)
โดยยังคงพื้นฐานเช่นเดิม

สิ่งที่เห็นได้ชัดมาก ๆ คือ จะไม่เน้นไปเพียงการพัฒนา software เท่านั้น

เนื่องจากมีการประยุกต์ไปใช้งานในสายงานอื่น ๆ มากขึ้น
เนื่องจากเป็นปัญหาที่มีความซับซ้อน
ทั้งด้าน business และ marketing เป็นต้น

ทั้งให้ความสำคัญกับ Cross-functional team

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

เมื่อมีหลาย ๆ ทีมทำงานใน product เดียวกัน

สิ่งที่เน้นย้ำมาก ๆ คือ ต้องมี Product goal เดียวกัน
ต้องใช้ Product backlog เดียวกัน
ต้องมี Product owner เดียวกัน
แน่นอนว่า มันอาจจะส่งผลต่อโครงสร้างขององค์กรเลย

อีกเรื่องคือ Event ต่าง ๆ ใน Scrum จะให้มีเท่าที่จำเป็นเท่านั้น

พยายามลด meeting ที่ไม่จำเป็นลงไป
รวมทั้ง Event ต่าง ๆ มันคือการทำงานกับ product
เพื่อให้สามารถส่งมอบ working software ที่ดีและมีคุณภาพออกไป
ตามเป้าหมายที่ตั้งไว้
ไม่ใช่การ update status ต่าง ๆ !!

ใน Sprint planning นั้นจะเน้นไปที่ Why -> What -> How

Why => Sprint goal
What => Product backlog ในแต่ละ Sprint
How => Actionable plan สำหรับการส่งมอบ

ให้ความสำคัญต่อการแบ่งแยกงานใหญ่ ๆ ออกเป็นงานย่อย ใน Product backlog

เพื่อให้แต่ละ item นั้นสามารถทำได้ภายใน 1 วันหรือน้อยกว่านั้น
มันเป็นสิ่งที่สำคัญมาก ๆ ในการวางแผนงาน

สิ่งที่ยังคงชัดเจนคือ  Focus on the delivery of value

คำถามที่น่าสนใจเรื่อง gRPC และ Messaging

$
0
0

เห็นคำถามและการพูดคุยที่น่าสนใจ ในกลุ่ม Golang Thailand
เกี่ยวกับ Messaging vs gRPC ว่าแบบไหนที่ performance ดีกว่ากัน ?
รวมทั้งข้อดีและข้อเสีย
จึงทำการสรุปการตอบต่าง ๆ ไว้นิดหน่อย

https://www.facebook.com/groups/584867114995854/permalink/1807309942751559

เรื่องแรกน่าจะเป็นเรื่องของรูปแบบ communication หรือการติดต่อสื่อสาร

  • gRPC นั้นจะทำงานแบบ synchronous (Remote Procedure Call)
  • Messaging นั้นจะทำงานแบบ asynchronous (Fire and Forgot) ยกตัวอย่างเครื่องมือที่ใช้งาน RabbitMQ, ActiveMQ และ Apache Kafka เป็นต้น

ดังนั้น use case การใช้งานจะแตกต่างกันไป
แน่นอนว่าในระบบหนึ่ง ๆ หรือ flow หนึ่ง ๆ
สามารถมีการทำงานทั้งสองแบบอยู่ด้วยกันได้เสมอ

อีกเรื่องคือ รูปแบบของ interact ระหว่าง service หรือระหว่าง consumer และ producer นั้น

จะมีทั้งแบบ 

  • one-to-one
  • one-to-many

โดยปกติแล้ว gRPC จะเป็นแบบ one-to-one
ส่วน messaging นั้นสามารถทำได้ทั้ง one-to-one (Queue) และ one-to-many (Topic)

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

ใครสนใจลองไปพูดคุยกันได้ครับ
ความรู้ต่าง ๆ จะให้ดีต้องนำมาแบ่งปันกัน


เรื่องที่น่าสนใจจาก State of DevOps Report ปี 2020

$
0
0

ผลการสำรวจเรื่อง DevOps ปี 2020 จาก Puppet ถูกปล่อยออกมาแล้ว
โดยผลในปีนี้ พบว่ามีการปรับปรุงการนำ DevOps มาใช้งานเยอะมากขึ้น
รวมทั้งมีสิ่งที่เปลี่ยนแปลงมากมาย หนึ่งในนั้นคือ 

  • Self-service internal platform
  • การจัดการ change ให้มีประสิทธิภาพมากยิ่งขึ้น ด้วยการทำงานแบบ automation
  • Security integration

จากผลการสำรวจจะเห็นได้ว่า

ในแต่ละองค์กรที่นำแนวคิด DevOps มาใช้งานและปรับปรุงอย่างต่อเนื่อง
เริ่มด้วยการใช้เครื่องมือที่มีอยู่แล้ว หรือ ที่พัฒนาจากนอกองค์กรก่อน
จาก manual process มาเป็น automation process
แต่เมื่อนำมาใช้งานก็พยายามปรับปรุงให้เข้ากับองค์กร
ผลที่ตามมาคือ การสร้าง platform ขึ้นมาใช้งานเอง
ส่งผลให้เกิด self-service สำหรับ development มากขึ้น
ประกอบไปด้วย

  • CI/CD workflow
  • Internal infrastructure
  • Development environment
  • Monitoring and alert system
  • Development pattern
  • Database provisioning
  • Audit logging
  • Public cloud infrastructure

ส่งผลให้ flow การทำงานไหลลื่นมากยิ่งขึ้น
แต่การสร้าง internal platform ก็แลกมาด้วยกับ
เรื่องของเวลาในการสร้าง
เรื่องของความเป็นมาตรฐาน
เรื่องของความสามารถของคนในทีมและองค์กร

อีกเรื่องคือ การมองในแง่ของ product มากกว่า project

อีกเรื่องที่หนีไม่พ้นคือ การ integrate security เข้ามายัง development process

เพื่อสร้างความเชื่อมั่นต่อ product มากยิ่งขึ้น
โดยเข้ามาในรูปแบบ self-security security
ตามแนวคิด DevSecOps

มีการทำแนวคิดของ DevOps ไปใช้ในส่วนอื่น ๆ นอกจาก Dev และ Ops

เนื่องจาก DevOps นั้น จะเน้นไปที่
การทำงานร่วมกัน การติดต่อสื่อสาร
การทำงานเป็นรอบสั้น ๆ 
การนำ feedback ต่าง ๆ มาใช้เพื่อปรับปรุงอย่างต่อเนื่อง
การเรียนรู้อยู่ตลอดเวลา

ทำการสรุปเรื่องของ DevOps Evolution Model ไว้ 5 stage ดังนี้

  • Normalization
  • Standardization
  • Expansion
  • Automated infrastructure delivery
  • Self-service

แสดงดังรูป

เรื่องของ Change management แสดงดังรูป

ต้นเหตุของปัญหาท่ีมักเกิดเมื่อมีการเปลี่ยนแปลง

ว่าด้วยเรื่อง Intercept ใน Cypress 6.0

$
0
0

ใน Cypress 6.0 ที่เพิ่งปล่อยออกมานั้น มีเรื่องที่น่าสนใจ
เพราะว่าผมก็ใช้งานเป็นประจำ
นั่นก็คือ cy.intercept ที่จะเข้ามาแทน cy.route
สำหรับทำการจำลองการทำงานของ network หรือ Network stub นั่นเอง

ที่สำคัญทาง Cypress ก็เขียน blob มาอธิบายเรื่องนี้อีกด้วย
ลองไปอ่านกันดู 
Introducing cy.intercept - Next Generation Network Stubbing in Cypress 6.0

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

เรื่องแรกคือ ไม่ต้องตกใจ เพียงแค่ deprecated เท่านั้นสำหรับ cy.route

ยังสามารถใช้งานได้เป็นปกติ
เนื่องจากจะเอาออกไปใน major version ถัดไปคือ 7 นั่นเอง
แต่ให้ดีก็ migrate กันซะ

เรื่องที่สองความแตกต่างระหว่าง cy.intercept กับ cy.route ที่เห็นได้ชัด

ปกติการใช้ cy.route ต้องทำการ start และ stop server ก่อน (cy.server)
แต่ใน cy.intercept ไม่ต้องทำเองอีกแล้ว สบายขึ้นเยอะ

เรื่องที่สาม cy.intercept นั้นโดย default จะรับ request จากทุก ๆ  HTTP Method เลย

จะลดความปวดหัวในการดักหรือ intercept request ไปได้เยอะขึ้น
แต่เราก็สามารถระบุ HTTP Method ในแต่ละ intercept ได้

โดยรวม ๆ แล้วง่ายและสะดวกขึ้นเยอะครับ
ใครยังไม่ใช้ ก็ลองใช้ดู
ส่วนใครที่ใช้อยู่ก็ update ซะ

ความสามารถใหม่ ๆ ใน Elasticsearch 7.10

$
0
0

ใน Elasticsearch 7.10 ที่เพิ่งปล่อยออกมานั้น
เท่าที่ดูแล้ว พบว่ามีความสามารถต่าง ๆ ที่น่าสนใจออกมาเยอะใช้ได้เลย
จึงทำการสรุปไว้นิดหน่อย 
เริ่มจากเรื่องของประสิทธิภาพในการ indexing data ที่เร็วขึ้น 20%

สิ่งที่น่าสนใจต่อมาคือ การจัดการที่จัดเก็บข้อมูลของแต่ละ index

เริ่มจากการบีบอัดข้อมูลที่ดีขึ้นจาก Apache Lucene 8.7
ส่งผลให้ใช้งานพื้นที่จัดเก็บน้อยลงไปกว่า 0-10%
จะส่งผลดีอย่างมากกับข้อมูลที่ซ้ำกันมาก  
ยกตัวอย่างข้อมูลพวก log และ metric ต่าง ๆ นั่นเอง

เรื่องใหม่อีกตัวคือ Data tier

โดยจะแบ่ง hardware ต่าง ๆ ของแต่ละ Node ตามชนิดของ data tier นั้น ๆ
ช่วยทำให้เราสามารถลงทุนและจัดการค่าใช้จ่าย
ของที่จัดเก็บได้ตรงกับชนิดของข้อมูลมากที่สุด
แบ่งเป็นดังนี้

  • Content tier คือ node ที่ใช้ indexing และ query ข้อมูล
  • Hot tier คือ node ที่ใช้ indexing ข้อมูลที่เป็น stream หรือ time-series เช่น log และ metric รวมทั้งข้อมูลใหม่และเข้าถึงล่าสุด
  • Warm tier คือ node ที่เก็บข้อมูล time-series เช่นกัน แต่เป็นข้อมูลที่ถูกใช้ไม่บ่อย หรือทำการแก้ไขไม่บ่อย
  • Cold tier คือ node ที่เก็บข้อมูล time-series เช่นกัน แต่นานจะถูกใช้งาน หรือไม่มีการแก้ไขเลย

แน่นอนว่า สามารถ config การทำงานร่วมกับ Index Lifecycle Management(ILM) ได้แน่นอน

สำหรับการค้นหาข้อมูล เพิ่มเรื่อง Point in Time (PiT) เข้ามา

ที่น่าสนใจมาก ๆ จะนำมาอธิบายในบทความต่อไป

ส่วน Breaking change ที่ควรต้องรู้ไว้บ้าง เช่น

  • การเข้าถึงข้อมูล index ของ system ถูก deprecated แล้ว ซึ่งตอนนี้จะแสดง warning message ออกมา โดยจะถูกนำออกไปใน version ต่อ ๆ ไป
  • การ boost ใน mapping ของแต่ละ field/property ถูก deprecated แล้ว จะถูกนำออกไปใน version 8 โดยให้ไปใช้ boost ใน query แทนได้

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

Elasticsearch :: ว่าด้วยเรื่อง Node role ที่จะเยอะไปไหน ?

$
0
0

ใน Elasticsearch 7.10 นั้น มีความสามารถเรื่องการจัดการข้อมูล
ให้เหมาะสมกับการใช้งานมากขึ้น
แน่นอนว่า มันกระทบต่อ Node role หรือบทบาทหน้าที่การทำงาน
ของแต่ละ node ใน cluster ด้วยเช่นกัน
สำหรับใครที่ลอง start Elasticsearch จะพบว่า
ค่า default ของ node มี role ต่าง ๆ ดังนี้ cdhilmrstw
อาจจะทำให้ตกใจได้ว่า มันคืออะไร อย่างไร ?
จึงทำการสรุปแล้วของ node role ไว้นิดหน่อย

เริ่มจากความหมายของ Node role แต่ละตัว

  • c = cold node สำหรับใช้งานกับ Data tier
  • d = data node สำหรับเก็บข้อมูล
  • h = hot node สำหรับใช้งานกับ Data tier
  • i = ingest node สำหรับทำงาน ingest
  • l = machine learning node สำหรับการใช้งาน feature ของ ML
  • m = master-eligible node สำหรับ node ที่มีสิทธิ์เป็น master ทำหน้าที่ดูแลการทำงานของ cluster
  • r = remote cluster client node สำหรับการติดต่อข้าม cluster
  • s = content node สำหรับใช้งานกับ Data tier
  • t = transform node สำหรับทำการแปลงข้อมูล ให้สามารถวิเคราะห์ได้ง่ายขึ้น
  • w = warm node สำหรับใช้งานกับ Data tier
  • v = voting-only node สำหรับใช้งานการ voting เช่น การเลือก master node เป็นต้น
  • - = coordinating node only สำหรับใช้รับ request ของการค้นหาข้อมูล เพื่อกระจายการทำงานไปยัง node ที่เก็บข้อมูล

แค่นี้ก็จำไม่ไหวกันแล้ว เยอะจริง ๆ !!

การแยก Node Role ใน Elasticsearch นั้นมีไว้สำหรับ

การกำหนดบทบาทหน้าที่การทำงานของแต่ละ node ว่าควรทำอะไร แต่ละ node ควรทำหน้าที่อย่างใดอย่างหนึ่งไปเลย เพื่อให่ง่ายต่อการดูแลรักษา เพื่อให้ง่ายต่อการ scale เพื่อให้ง่ายต่อการกำหนด spec ของ hardware ที่ต้องใช้งานทั้ง CPU, Memory และ Storage การกำหนด node role จะเหมาะสมกับ cluster ที่มีขนาดใหญ่ขึ้น
ซึ่งค่า default นั้น ทุก ๆ node จะเป็น

  • master
  • data
  • ingest
  • Machine learning ถ้าเปิดใช้งาน
  • transform สำหรับ data node

VS Code :: สร้าง Mock API Server ด้วย EasyMock

$
0
0

ปกติการจำลอง API Server หรือพวก Mock/Fake API Server นั้น จะมีเครื่องมือให้ใช้เยอะมาก ๆ ทั้ง

  • Stubby
  • mbtest
  • jsonserver
  • WireMock

แน่นอนว่าใน VS Code ก็มี extension ให้ใช้งานเช่นกันนั่นคือ EasyMock
โดยด้านหลังคือ lib ที่ชื่อว่า mockjs (ภาษาจีน)

รวมทั้งยังมีความสามารถในการ generate ข้อมูลให้อีกด้วย (Fake data)

  • String
  • Number
  • Email
  • IP
  • Phone
  • URL

ยังไม่พอ สามารถเขียน function เพื่อการทำงานที่ยืดหยุ่นขึ้นอีกด้วย
การใช้งานก็ไม่ยาก เปิด workspace ใน VS Code ขึ้นมา
ทำการ Run Easy Mock ดังนี้

ผลคือจะทำการสร้าง folder ชื่อว่า mock และมีไฟล์ example.js
ซึ่งเป็น code ตัวอย่าง  แน่นอนว่า เราสามารถแก้ไขได้

โดยที่จะ start server ขึ้นมาใน port = 9999 ดังนี้

ปล. เป็นภาษาจีน ก็อย่าลืมใช้ Google Translate ด้วยละ
เป็นอีกทางเลือกของ Mock API Server แบบง่าย ๆ
และจากที่ลองใช้พบว่า
ยังไม่ค่อย stable สักเท่าไร !!
แต่ชอบในความสามารถที่มีมาให้

Viewing all 2000 articles
Browse latest View live