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

สวัสดี Java 11

September 27, 2018, 11:11 am
$
0
0

ผ่านมา 6 เดือนที่ Java 10 ถูกปล่อยออกมา ก็ได้เวลาของ Java SE 11 กันบ้าง (ตามแผนมาก ๆ) ในเรื่องของ feature ต่าง ๆ นั้นก็จัดว่าเยอะอยู่แล้ว เหมือนกับการนำ Java 9 + 10 มานั่นเอง อีกอย่างที่น่าสนใจคือ เรื่องของ Licence และรอบของการ support/release จากทาง Oracle หรือ Long Term Support (LTS) ซึ่งจะมีรอบในการ release ทุก ๆ 6 เดือนนั่นเอง

เริ่มจากการ Download มาใช้งานที่ Oracle หรือ Open JDK

ถ้าไปที่ Oracle จะเจอหน้าแบบนี้ ลองอ่านเพิ่มเติมครับ เรื่องมันยาว
ปล. เพื่อความปลอดภัยในการใช้งาน แนะนำให้ใช้งาน Open JDK ไปครับ เพราะว่ายังใช้ licence เดิม

มาดู feature ที่น่าสนใจดีกว่า

แน่นอนว่ามีของใหม่มา ของเก่าก็ต้องจากไป ยกตัวอย่างของที่ถูกเอาออกไปทั้ง CORBA และ Java EE รวมไปถึง JavaFX ที่ถูกแยกออกไปเป็นอีก module ทำให้สิ่งต่าง ๆ เหล่านี้ถูกแยกออกไปจาก JDK นั่นเอง ส่งผลทำให้การดูแล JDK ง่ายขึ้น เช่นเรื่องของ backward compatability เป็นต้น แต่ตอนนี้ก็เจ็บปวดกันหน่อย เนื่องจากในตอนนี้ Java Module System ถูกนำมาใช้เต็ม ๆ แม้แต่ของใหม่ที่เพิ่มเข้ามาอย่าง Nashorn JavaScript Engine ก็ยัง deprecated เลย แน่นอนว่าในอนาคตโดนถอดออกไปแน่

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

มาดูตัวอย่างการใช้งานในมุมมองนักพัฒนาบ้าง

ตัวอย่างที่ 1 คือ Launch Single-File Source-Code Programs ทำมาเพื่อให้ง่ายต่อการ run program เลย เพียงแค่บันทึกเป็นไฟล์นามสกุล .sh จากนั้นก็ run เลยดังนี้ [gist id="30d39cd5940c638d1505269545854e15" file="Hello.sh"] จากนั้นทำการ run ด้วยคำสั่ง [code] $./Hello.sh Hello java script ... [/code] ตัวอย่างที่ 2 คือ Local-Variable syntax for Lambda parameters [gist id="30d39cd5940c638d1505269545854e15" file="LambdaDemo.sh"]

ลองไปเล่นกันดูครับ ชีวิตปวดหัวกับ licence กันอีกแล้ว

Oracle JDK = commercial OpenJDK = free มันคือ new default หรือหลาย ๆ คนอาจจะใช้มานานแล้ว
อีก 6 เดือน เจอกันกับ Java 12
สุดท้าย ถ้าใครจะศึกษา Java 9, 10 และ 11 แนะนำมาที่ 11 เลยนะครับ
↧
Search

สรุปการอ่านหนังสือ Release It 2nd edition บทที่ 6 เรื่อง Stability Patterns

September 30, 2018, 10:12 am
$
0
0

ในช่วงวันหยุดหยิบหนังสือ Release It 2nd edition มาอ่าน เน้นบทที่ 6 ว่าด้วยเรื่อง Stability Patterns ซึ่งอธิบายถึงรูปแบบของการวางสถาปัตยกรรมของระบบที่ดี เป็นแนวทางในการออกแบบระบบ เพื่อลด ขจัดปัดเป่า จากปัญหาต่าง ๆ ที่อาจจะเกิดขึ้น หรือลดความอันตรายจากข้อผิดพลาดต่าง ๆ ลงไป
ไม่ใช่ต้องตื่นมากดึก ๆ เพื่อมาแก้ไขระบบ ไม่ใช่ต้องยกเลิกงานทั้งหมด เพื่อมาแก้ไขระบบ ถ้าเป็นแบบนี้คงไม่ต้องทำอะไรกันพอดี !!
ดังนั้นมาสร้างระบบดี ๆ กันหน่อย

โดยในหนังสือนั้นมีรูปแบบที่แนะนำมากมาย

ประกอบไปด้วย
  • Timeout
  • Circuit breaker
  • Bulkheads
  • Steady state
  • Failfast
  • Let It crash
  • Test harnesses
  • Decouple middleware
  • Shed load
  • Create back pressure
  • Governor
มันจะเยอะไปไหนเนี่ย ? มาดูรายละเอียดแบบคร่าว ๆ ของแต่ละเรื่องกันหน่อย ซึ่งเลือก Timeout กับ Circuit breaker มาอธิบาย เพราะว่าน่าจะใช้บ่อยสุดแล้ว แต่เรื่องอื่น ๆ ก็น่าสนใจและจำเป็นต้องรู้เช่นกัน มาเริ่มกันดีกว่า

Timeout

น่าจะเป็นเรื่องปกติ ๆ ที่ใคร ๆ ก็ต้องกำหนด timeout หรือเวลาการรอสิ่งต่าง ๆ ยกตัวอย่างเช่น
  • การเชื่อมต่อไปยัง service ต่าง ๆ
  • การเชื่อมต่อผ่านระบบ network
  • การเชื่อมต่อไปยัง remote file system
ซึ่งระบบ network สามารถเกิดข้อผิดพลาดได้เพียบ ทั้งสายสัญญาณพัง ทั้งสายหลุด ทั้งถูกรบกวนการทำงาน ทั้งอุปกรณ์ต่าง ๆ ระหว่างผู้ใช้และผู้ให้บริการมีปัญหา ทั้งทำงานช้า ทั้งผู้ใช้งานเยอะ เยอะไปไหน !!
จากบทความเรื่อง Microservices Aren’t Magic: Handling Timeouts อธิบายเรื่องของ Timeout ได้อย่างน่าสนใจ ลองอ่านเพิ่มเติมได้
ถ้าหมดเวลาที่รอแล้วก็จะโยน error ออกมา จากนั้นก็ทำการจัดการหรือ handle ต่อไป ว่าจะทำอย่างไรต่อไป ขึ้นอยู่กับ use case ของการทำงาน เช่น
  • แจ้งผู้ใช้งานไปว่าระบบมีความผิดพลาด ให้ลองใหม่
  • ระบบทำงาน retry หรือลองทำงานใหม่อีกครั้ง ซึ่งจะมีการกำหนด interval การทำงานหใม่อีกด้วย รวมทั้งมีจำนวนการ retry สูงสุดไว้ด้วย
ดังนั้นเราทำการกำหนด timeout ของการทำงานผ่านระบบ network ไว้หรือยัง เพราะว่าส่วนใหญ่จะไม่กำหนดนะ หรือหนักกว่านั้น ทำการกำหนด timeout ไว้นานมาก ๆ นั่นคือผู้ใช้งานต้องรอไปเรื่อย ๆ หรือ ตลอดไปหรือไงนะ !! ยังไม่พอ ในระบบของเรานั้นมีส่วนจัดการเกี่ยวกับ timeout กี่ที่กันนะ ? ถ้าบอกว่าเยอะ หลายที่เลย หมายความว่า การจัดการลำบากมาก ๆ !! ดังนั้นควรรวมมาไว้ที่เดียวดีกว่านะ ยกตัวอย่างการใช้งาน gateway เพื่อจัดการเรื่อง
  • การจัดการ connection ต่าง ๆ
  • การจัดการความผิดพลาดต่าง ๆ
  • การจัดการการดึงข้อมูลจาก database
  • การจัดการการประมวลผลที่ใช้เวลานาน ๆ
จะทำให้เราจัดการปัญหาต่าง ๆ ที่เกิดขึ้นได้ง่ายขึ้น ด้วยรูปแบบที่เรียกว่า Circuit Breaker ต่อไป

Circuit Breaker

ชื่อมันคุ้น ๆ นะ ตัดก่อนตาย เตือนก่อนวายวอด นั่นมัน Safe-T-Cut นี่หว่า มาดูในส่วนของ software กันบ้าง หลังจากที่เกิดปัญหาขึ้นมาแล้ว เราจะทำอย่างไรกันต่อดี ระบบที่ดีจะมีตัวจัดการ หนึ่งในนั้นคือ Circuit Breaker ซึ่งมันต่างจากการ retry หรือการทำงานซ้ำ เพราะว่า Circuit Breaker จะไม่ทำงานซ้ำในที่ ๆ มันพังอยู่ มาดูการทำงานของ Circuit Breaker หน่อย ปกติจะมี 2 สถานะคือ ปิด กับ เปิด ค่า default คือ ปิด แต่เมื่อเกิดปัญหาขึ้นมา เช่น timeout แล้ว Circuit Breaker จะทำการบันทึกจำนวนปัญหาไว้ เมื่อปัญหาต่าง ๆ ถึงจำนวนที่กำหนดหรือค่า threshold จะเปลี่ยนสถานะจากปิดเป็นเปิด นั่นคือไม่มีใครสามารถเรียกใช้งานการทำงานนั้น ๆ ได้ จนกว่าจะผ่านเวลาที่กำหนดไว้ (Timeout) จากนั้นจะทำการค่อย ๆ เปลี่ยนสถานะของ Circuit Breaker จากเปิดไปเป็นเปิดครึ่งเดียว นั่นคือ อนุญาตให้เรียกใช้งานส่วนงานนั้น ๆ ได้ ถ้าทำงานสำเร็จก็จะเปลี่ยนสถานะไปเป็นปิด นั่นคือใช้งานได้ปกติ แต่ถ้าทำงานผิดพลาดเช่นเดิม ก็จะเปลี่ยนสถานะเป็นเปิด แล้วก็รอวนไป แสดงการทำงานดังรูป ส่วนการใช้งานจริง ๆ ก็แล้วแต่ use case อีกแล้ว อาจจะไม่ต้องรอให้พังก็ได้ แค่ timeout ก็พอ จากนั้นก็ทำการจัดการปัญหาในหลาย ๆ แบบ ทั้งส่งรายละเอียดของปัญหาที่เข้าใจง่ายออกไปให้ผู้ใช้งาน บางระบบ ก็ไปเปิดระบบงานใหม่ขึ้นมา หรือ route การทำงานไปยังที่ใหม่กันก็เป็นไปได้ และมักจะใช้สิ่งที่เรียกว่า Fallback เพื่อส่งค่าสำเร็จล่าสุด หรือ ข้อมูลที่ cache ไว้กลับไป เพื่อลดผลกระทบที่จะเกิดขึ้นต่อระบบ แน่นอนว่ามันกระทบต่อ business แน่นอน ดังนั้นสิ่งที่สำคัญมาก ๆ คือการคุยและตกลงกับเจ้าของระบบว่า ถ้าเกิดปัญหาต่าง ๆ ขึ้นมา หรือ Circuit Breaker อยู่ในสถานะเปิดแล้ว จะต้องจัดการอย่างไรบ้าง ? อย่าให้แต่ทาง IT หรือทีมพัฒนาคิดละ !! อีกอย่าง อย่าลืมเก็บ log การเปลี่ยนสถานะของ Circuit Breaker ด้วยนะ เพื่อทำให้เราและ operation รู้การทำงานด้วย

โดยสรุป

ความผิดพลาดของระบบมันเป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่เราสามารถควบคุมพื้นที่ของความผิดพลาดให้เล็กได้ด้วยเทคนิคต่าง ๆ บางครั้งความหวาดระแวงหรือตื่นตระหนกก็เป็นสิ่งที่ดี ถ้าอยู่บนพื้นฐานของความมีเหตุมีผล เพื่อทำให้เราสามารถเตรียมวิธีการรับมือไว้ ในวันหนึ่ง ๆ ระบบงานของเรามีจำนวน request เข้ามาเยอะเท่าไร นั่นคือโอกาสที่เกิดข้อผิดพลาดก็เยอะมากขึ้นเท่านั้น วันนี้คุณรับมือกับปัญหาต่าง ๆ ของระบบกันอย่างไร ? หรือตามแก้ไขไปวัน ๆ
↧
↧

สรุปจากบทความ Code: Align the happy path to the left edge

October 5, 2018, 11:29 pm
$
0
0

เห็นบทความเรื่อง Code: Align the happy path to the left edge ที่กลุ่ม Golang Thailand ผู้พูดคือ คนเขียนหนังสือ Go Programming Blueprints นั่นเอง ซึ่งพูดในงาน Golang UK Conference ตั้งแต่ปี 2016 เห็นว่าน่าสนใจจึงนำมาสรุปไว้นิดหน่อย มาเริ่มกันเลย จากชื่อของบทความน่าจะบอกได้อย่างชัดเจน นั่นคือส่วนการทำงานหลัก หรือ happy path ให้อยู่ทางด้านซ้ายมือของเรา เหมือนกับหนังสือที่เรา ๆ อ่านกันนั่นเอง แน่นอนว่า อ่านง่าย อย่าซ่อนการทำงานไว้ใน if-else if - else ที่ซับซ้อน นั่นคือ อย่าเป็นลูกอีช่าง if มากนัก ไม่ใช่ให้ code ที่เราต้องการอยู่ซ้ายมือแบบลึกสุดใจดังรูป ซึ่งผมมักจะเรียกว่า arrow function !! ในแต่ละ function ต้อง Fail Fast และ Return First หมายความว่า ในแต่ function ควรทำการตรวจสอบสิ่งที่ไม่ต้องการ หรือ ไม่เป็นที่ต้องการในการทำงาน ให้ทำการตรวจสอบและจัดการตั้งแต่แรกเลย จากนั้นจึงทำการ return ผลการทำงานกลับไป แต่ถ้าผ่านเงื่อนไขต่าง ๆ แล้ว ก็ทำงานตาม happy path มันจะทำให้ code ของเราอ่านง่ายขึ้นอีกเป็นกอง ดังนั้นอย่าเอา logic หลาย ๆ อย่างมารวมกัน แต่ให้ทำเป็นกลุ่ม ๆ แทน จะลดการเขียน if ซ้อนกันหลาย ๆ ชั้นลงไปได้เยอะเลย (Nest if) ยังไม่พอนะ ถ้ามีเงื่อนไขการตรวจสอบเยอะ ๆ หรือ ยาวหลายบรรทัด หรือมี indent ทางขวามือมาก ๆ แล้ว น่าจะได้เวลาที่ควรแยกออกไปเป็น method ใหม่ได้แล้ว (Extract to new method) มันยิ่งทำให้เราอ่านเข้าใจง่ายขึ้น ที่สำคัญชื่อ method ก็สำคัญด้วยเช่นกัน โดยรวมแล้วมันคือหลักการ Clean Code และ Coding for Human มาก ๆ วันนี้ code ของเราเป็นอย่างไรนะ ? ดูเพิ่มเติมได้จาก Youtube https://www.youtube.com/watch?v=yeetIgNeIkc
↧

Golang :: จดบันทึกการใช้งาน Go Module

October 11, 2018, 4:34 am
$
0
0

จากบทความเรื่อง Introduction to Go Modules in Go v1.11, Goodbye GOPATH! ไม่ต้องทำการกำหนด environment ชื่อ GOPATH แล้ว รวมทั้งสามารถพัฒนาระบบนอก GOPATH ได้โดยไม่ต้องกำหนดค่าอะไรเพิ่มเติม ซึ่งเป็นปรับปรุงเรื่องการจัดการ dependency ให้ดีและง่ายขึ้นนั่นเอง ดังนั้นจึงสรุปการใช้งานไว้นิดหน่อย กันลืม

ขั้นตอนที่ 1 ต้องมั่นใจว่า เราไม่ได้กำหนด GOPATH เอง

ดังนั้น unset GOPATH ก่อนเลย [code] $unset GOPATH [/code]

ขั้นตอนที่ 2 ทำการสร้าง project ของเรา หรือสร้าง module นั่นเอง

[code] $go mod init hello [/code] จะได้ไฟล์ชื่อว่า go.mod ขึ้นมา เป็นไฟล์ configuration หลักของ module เรานั่นเอง

ขั้นตอนที่ 3 ทำการเพิ่ม dependency ที่จะใช้งานใน module เราเข้าไป

ยกตัวอย่างเช่น Gin เข้ามายัง module [gist id="b08f4d1f43ebcd45fa1a1445c6ecdf5e" file="go.mod"] แต่สิ่งที่สำคัญมาก ๆ ของการใช้งาน dependency ต่าง ๆ คือ เรื่องของ version ซึ่งต้องอยู่ในรูปแบบของ Semantic Versioning ด้วย แน่นอนว่า dependency หลาย ๆ ตัวสำหรับภาษา Go ยังไม่เปลี่ยนทั้งหมด แต่คาดว่าในอนาคตอันใกล้น่าจะปรับแน่นอน ดังนั้นไม่ต้องกลัว ส่วนเราถ้าต้องการสร้าง dependency ต่าง ๆ ขึ้นมาก็ใช้ Go module ซะ

ขั้นตอนที่ 4 ก็ build project ซะ

แต่อย่าลืมสร้างไฟล์หลักของ module เราก่อนละ [gist id="b08f4d1f43ebcd45fa1a1445c6ecdf5e" file="main.go"] ทำการ build ด้วยคำสั่ง [code] $go build [/code] จะทำการ download dependency มาให้แบบอัตโนมัติ ซึ่งจะเก็บ depedency ของ Gin ไว้ที่ GOPATH ที่เป็น default ของภาษา go ในแต่ละ platform ซึ่งสามารถดูด้วยคำสั่ง go env โดยเครื่องผลเป็น Mac OS จะอยู่ที่ GOPATH/pkg/mod/cache/ นั่นเอง และจะได้ binary ที่เราต้องการไปใช้งานต่อไปแล้ว เท่านี้ก็ใช้งาน Go module แบบง่าย ๆ ได้แล้ว มาเขียน code กันเถอะ Reference Websites https://www.melvinvivas.com/go-version-1-11-modules/ https://github.com/golang/go/wiki/Modules
↧

สวัสดี GoodFORM

October 14, 2018, 8:29 pm
$
0
0

หลังจากที่ทาง Redis Labs ทำการเปลี่ยน licence ของ module ต่าง ๆ ใน Redis ส่งผลให้สิ่งที่ฟรีและ open source หมดไป และส่งผลโดยตรงกับชาว Debian และ Fedora เนื่องจากมี module ที่ใช้งาน module จาก Redis Labs ดังนั้นทาง
  • Chris Lamb, the Debian Linux project leader
  • Nathan Scott, a Fedora developer
จึงทำการสร้าง GoodFORM ขึ้นมา เป็นการรวม source code ต่าง ๆ ของ Redis Module ก่อนที่จะเปลี่ยน licence เพื่อให้สามารถใช้งานได้แบบ free และ open source ต่อไป รวมทั้งเปิดให้คนทั่วไปสามารถแก้ไขและเพิ่มความสามารถต่าง ๆ ได้เลย เป็น community สำหรับ Redis Module นั่นเอง Reference Websites https://goodformcode.com/ https://www.zdnet.com/article/redis-labs-and-common-clause-attacked-where-it-hurts-with-open-source-code/
↧
↧

Go module :: มาลองสร้าง module ใช้เองแบบ Local

October 16, 2018, 5:06 am
$
0
0

มีคำถามว่า ถ้าต้องการทำ module ใช้เอง โดยใช้แบบ local หรือบนเครื่องเราเอง ต้องทำอย่างไรบ้าง ? ที่นี่มีคำตอบแบบง่าย ๆ มาดูกัน

แนวคิดและสิ่งที่ต้องการเป็นดังนี้

ต้องการสร้าง module ใช้เองชื่อว่า module1 จากนั้นทำการเรียกใช้งานจาก module หลักของเรา ซึ่งจะตั้งชื่อว่า demo ซึ่งมีโครงสร้างของ project ดังนี้

มาดู module1 กันก่อน ซึ่งเป็นตัวอย่างของ module ที่ต้องการสร้างเองใช้เอง

เริ่มด้วยไฟล์ go.mod ของ module1 กัน [gist id="9b65b0b20f830ec43261d00a5c6e418f" file="module1_go.mod"] ส่วนการทำงานของ module1 ก็ง่าย ๆ คือ มี function ชื่อว่า SayHi() ทำการ return string กลับไปดังนี้ [gist id="9b65b0b20f830ec43261d00a5c6e418f" file="module1_main.go"] ในส่วนนี้ไม่มีอะไร

มาถึงส่วนการใช้งาน module1 จาก demo ของเรา

สิ่งที่สำคัญคือ ในการเรียกใช้งาน module ต่าง ๆ ต้องเป็นไปตามรูปแบบที่กำหนด ยกตัวอย่างเช่น github.com/up1/module1 v0.0.0 แต่ว่า module1 ของเราอยู่ที่ local !! ดังนั้นจำเป็นต้องใช้การ replace ไปดังนี้ [gist id="9b65b0b20f830ec43261d00a5c6e418f" file="demo_go.mod"] จากนั้นก็เขียน code เรียกใช้ซะ [gist id="9b65b0b20f830ec43261d00a5c6e418f" file="demo_main.go"] เมื่อทุกอย่างพร้อม ก็ run สิครับ [code] $cd demo $go build go: finding github.com/up1/module1 v0.0.0 $./demo Say hi from module 1 [/code] เท่านี้ก็สร้าง module ใช้งานเองได้แล้ว ขอให้สนุกกับการเขียน code นะครับ Reference Websites https://github.com/golang/go/wiki/Modules#how-to-use-modules
↧

ว่าด้วยเรื่อง Effective > Productive

October 17, 2018, 9:42 am
$
0
0

จากหนังสือ It Doesn't Have to Be Crazy at Work นั้น แบ่งเนื้อหาออกเป็นหัวข้อย่อยสั้น ๆ ทำให้อ่านง่ายมาก ๆ ที่สำคัญแต่ละเรื่องก็มีความสนุก น่าสนใจ จึงทำการบันทึกการอ่านหนังสือเล่มนี้ไว้นิดหน่อย ซึ่งแบ่งตามหัวข้อที่ชอบเป็นการส่วนตัว มาเริ่มกันเลยกับเรื่องแรก Effective > Productive (หน้า 50 และ 51 อยู่ในกลุ่ม Defend Your Time) คนส่วนใหญ่มักจะสนใจเกี่ยวกับ Hacking productivity Improve หรือ ปรับปรุง productivity ในแต่ละวัน มีทั้งวิธีการ มีทั้งเครื่องมือที่หลากหลายอย่างมากมาย แต่คำถามที่น่าสนใจคือ จะปรับปรุง productivity ไปเพื่อไร ?
เราพยายามหาวิธีให้สามารถทำงานได้มากกว่าเดิม ในเวลาเท่าเดิมกันหรือไม่ ?
เนื่องจาก productivity นั้นมันใช้สำหรับเครื่องจักร ไม่ได้ใช้หรือเหมาะสำหรับคนเลย เครื่องจักรนั้นสามารถทำงานได้ตลอดเวลาหรือ 24x7 ส่วนคนนั้นไม่สามารถทำได้ ดังนั้นจะเพิ่มหรือปรับปรุง productivity ไปทำไม ยิ่งเราเน้นไปที่ productivity มากเท่าไร สิ่งที่ได้กลับมาคือ ความยุ่ง เนื่องจากเราจะมีงานทำอยู่ตลอดเวลา ไม่ว่างเลย ที่น่ากลัวคือ ยิ่ง productivity ดีขึ้นมากเท่าไร งานก็จะเยอะมากขึ้นเท่านั้น มันไม่ใช่ less is more เลยนะ !! ซึ่งเรื่อง productivity นั้น ที่ Basecamp จะไม่เชื่อเรื่องนี้เลย แต่สิ่งที่ให้ความสำคัญมาก ๆ คือ เรื่องของ Effective นั่นคือ การให้ความสำคัญกับสิ่งที่ทำ ทำอย่างไรให้งานที่ทำมันเล็กลง ? ทำอย่างไรเราถึงจะลดสิ่งที่ไม่จำเป็นออกไป ? ดังนั้น แทนที่จะทำการเพิ่มงานเข้ามา กลับเน้นไปที่การลดงานที่ไม่จำเป็นออกไป หรือ การเพิ่ม to-don’t list เข้ามานั่นเอง ดังนั้นสิ่งที่ควรจะเกิดขึ้นคือ คุณต้องไม่ยุ่ง มีเวลาไปทำอย่างอื่น เช่น ไปดูหรือหาสิ่งอื่น ๆ ทำบ้าง มีเวลาพักผ่อน ผ่อนคลายบ้าง หรือเอาไปทำเรื่องไร้สาระดูบ้าง หรือถ้าจะให้แจ่มไปเลย คือ ไม่ต้องทำอะไรเลย !! ถ้าในแต่ละวันคุณมีงานต้องทำประมาณ 3 ชั่วโมงก็พอแล้วนะ ไม่ต้องเพิ่มไปถึง 5 ชั่วโมง หรือคิดว่าเพิ่มเพื่อให้ productivity สูงขึ้น เพราะว่ามันจะทำให้คุณยุ่งมากเกินไป ดังนั้นอย่าทำ !!
ปล. แต่ไม่ได้หมายความว่าจะไม่ทำอะไรเลยนะ แต่การจะทำสิ่งใดก็ตาม มันต้องคุ้มค่า กับเวลาที่คุณสูญเสียไป
วันนี้เราเน้นสิ่งใดมากกว่ากัน หรือทำ ๆ มันไปเหอะ เขาสั่งมาแล้ว ปล. ซึ่งถ้าใครอ่านหนังสือเรื่อง Remote และ Rework มาน่าจะคุ้นเคยดี
↧

สรุปสิ่งที่แบ่งปันจากงาน RobotFramework Meetup ครั้งที่ 2

October 19, 2018, 9:13 am
$
0
0

สรุปสิ่งที่แบ่งปันในงาน RobotFramework Meetup ครั้งที่ 2 ของกลุ่ม RobotFramework66 โดยที่เนื้อหาหลักใน meetup คือ การเปลี่ยนแปลงของ RobotFRamework 3.1 alpha 2 มีสิ่งที่น่าสนใจดังต่อไปนี้

เริ่มต้นด้วยการติดตั้งและ update RobotFramework 3.1 alpha 2

[code] $pip install --pre --upgrade robotframework หรือทำการระบุ version ไปเลย $pip install robotframework==3.1a2 [/code]

มาดูสิ่งที่เพิ่มเติมและเปลี่ยนแปลงกันบ้าง

อย่างแรกที่พูดถึงกันเยอะคือ การสนับสนุน Robotic Process Automation (RPA) คือขั้นตอนการทำงานแบบอัตโนมัติซึ่งออกแบบให้คนเราใช้งาน โดย RobotFramework ก็ทำงานได้ดี แต่คำต่าง ๆ มันเป็นจะเฉพาะเจาะจงกับการทดสอบมากเกินไป ยกตัวอย่างเช่นคำว่า Test Case ดังนั้นเพื่อให้สามารถนำไปใช้งานที่กว้างขึ้น ไม่ผูกติดกับการทดสอบ จึงทำการสร้างคำใหม่ขึ้นมาชื่อว่า Task หรือ Tasks แต่การทำงานยังเหมือน Test Case นั่นเอง มาดูตัวอย่างกัน [gist id="9d34ba3f4245d466d41d083c95e26bb1" file="1.robot"]
ปล. ประกาศพร้อมกันไม่ได้ ต้องเลือกเอาสักอย่าง ต่อไปคิดว่า คำว่า Test Case อาจจะหายไปก็เป็นได้

เพิ่มนามสกุลไฟล์ *.resource เข้ามา

ใช้สำหรับเก็บชุดของ resource ที่ใช้งานร่วมกัน ยกตัวอย่างเช่น Keyword, Variable และ Setting ทำให้การจัดการชุดการทดสอบต่าง ๆ ง่ายขึ้น ไม่สับสนอีกด้วย ไม่ต้องมาใช้นามสกุล robot หรือ txt อีกต่อไป ส่วนการใช้งานยังเหมือนเดิม

Script pybot ถูกลบทิ้งไปแล้ว

มี scipt ในการ run test data ของ RobotFramework โดนลบออกไป
  • pybot
  • jybot
  • ipybot
  • jyrebot
  • ipyrebot
เหลือไว้เพียง robot กับ rebot เท่านั้น พร้อมกับไม่รอรับ Python 2.6 และ Python 3.3 แล้วนะ ใครใช้งานสิ่งเหล่านี้ก็จะโดดนะครับ ถ้าใครยังเขียน RobotFramework ด้วยรูปแบบ TSV และ HTML แล้ว ขอบอกเลยว่า โดน deprecated แล้ว ดังนั้นอย่าไปใช้เลยนะ สามารถอ่านรายละเอียดเพิ่มเติมได้จาก Release note ส่วน slide ก็อยู่ที่นี่ https://www.slideshare.net/up1/robotframework-meetup-at-thailand-2 ขอให้สนุกกับการเขียน code นะครับ
↧
Search

สรุปบทความเรื่อง Microservices Architecture ของ Medium.com Part 1

October 23, 2018, 6:38 am
$
0
0

ทาง Medium.com ได้เขียนสรุปเกี่ยวกับแนวทางการนำ Microservice Architecture มาใช้งาน ซึ่งช่วยทำให้ทีมพัฒนาสามารถพัฒนาและส่งมอบระบบงานได้เร็วขึ้น พร้อมกับคุณภาพที่สูงขึ้น รวมทั้งยังช่วยทำให้แต่ละ service แยกกันพัฒนาและลดผลกระทบต่าง ๆ อีกด้วย ดังนั้นเรามาดูกันหน่อยว่า ทีมพัฒนาของ Medium.com เขาทำกันอย่างไรบ้าง ? จึงทำการสรุปจากบทความไว้นิดหน่อย

ระบบเก่าที่เป็น Monolith !!

เป็นระบบที่พัฒนาด้วย Node.js ตั้งแต่ปี 2012 แน่นอนว่า ยิ่งนานวันระบบยิ่งมีขนาดใหญ่ขึ้น ยิ่งนานวันสมาชิกของทีมพัฒนายิ่งมากขึ้น ยิ่งนานวันความซับซ้อนของระบบยิ่งยุ่งเหยิงขึ้น การดูแลรักษารวมทั้ง operation ต่าง ๆ ยิ่งยากขึ้นมา และหลาย ๆ ส่วนการทำงานเริ่มเกิดปัญหาคอขวด ดังนั้นในปี 2018 ทางทีมพัฒนาจึงเริ่มนำแนวคิดของ Microservices มาใช้งาน เพื่อลดปัญหาต่าง ๆ ที่พบเจอ มาดูกันว่าขั้นตอนการนำแนวคิด Microservices เป็นอย่างไรบ้าง ซึ่งนับว่าเป็นประสบการณืที่น่าศึกษาเป็นอย่างมาก

ก่อนอื่นทีมต้องเข้าใจก่อนว่า Microservices คืออะไร ?

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

เรื่องที่ 1 อะไรคือ Microservices

ในบทความจะยึดแนวปฏิบัติ 3 ข้อคือ
  1. Single purpose แต่ละ service มีเป้าหมายการทำงานเดียว และ ทำให้มันดี หรือจบในตัวเอง
  2. Loose coupling แต่ละ service ควรตัดขาดหรือรู้จักแต่ละ service เพียงนิดเดียว มันจะช่วยลดผลกระทบเมื่อ service ต่าง ๆ มีการเปลี่ยนแปลง รวมไปถึงการติดต่อสื่อสารระหว่าง service ควรเกิดขึ้นผ่านทาง public service interface เท่านั้น
  3. High cohesion แต่ละ service ต้องซ่อนทั้ง behaviour และ data ที่เกี่ยวข้องหรือใช้งานไว้ในตัวเอง ดังนั้นถ้าต้องการสร้าง service ขึ้นมาใหม่ก็ควรที่จะเปลี่ยนภายใน service เท่านั้น ไม่ควรไปกระทบ service อื่น ๆ มิเช่นนั้น service ต่าง ๆ จะกลายเป็น distributed monolith system ไปนะ ต้องระวังด้วย
แสดงความสัมพันธ์ดังรูป

เรื่องที่ 2 อะไรบ้างที่ไม่ใช่ Microservices

ไม่ใช่ service ที่มีจำนวน Line of Code น้อย ๆ หรือ ไม่ใช่ micro task ไม่ใช่ service ที่พัฒนามาจาก teachnology ใหม่ ๆ เสมอ แต่ microservices อนุญาตให้ทีมได้ลองของใหม่ ๆ ได้ง่ายเท่านั้นเอง และจะดีมากถ้าพัฒนาด้วย technology เดิม เพราะว่าทีมจะได้ประโยชน์จากการแยก service เป็นอย่างมาก ไม่ใช่ service ที่สร้างมาใหม่ตั้งแต่เริ่มต้น สิ่งที่ควรเกิดขึ้นคือ ถ้าระบบเดิมของเราที่เป็น monolith นั้น ทำการแยกเป็น modular ที่ดีอยู่แล้ว มันจะง่ายต่อการแยกออกมาเป็น service เล็ก ๆ โดยไม่ต้องพัฒนาใหม่เลย ดังนั้นอะไรก็ตามทีไม่ใช่ Microservices แสดงว่า จะไม่เป็นไปตามแนวคิด 3 ข้อจากข้างต้นนั่นเอง  

เรื่องที่น่าสนใจอีกคือ ทำไมต้องทำตอนนี้ด้วยละ ?

เพราะว่า เมื่อใดก็ตามที่มีการถามคำถามนี้แล้ว มันจะเกิดข้อจำกัดมากมายขึ้นมา ทั้งผลกระทบที่จะเกิดขึ้น ? ทั้งค่าใช้จ่ายต่าง ๆ ? ทั้ง overhead จากงานแทรกต่าง ๆ ? และเรื่องอื่น ๆ อีกมากมาย !! แต่ข้อดีของคำถามนี้คือ มีคำตอบเยอะมาก ดังนั้นก็ทำการจัดเรียงความสำคัญมันซะ !! ยากนะแต่ต้องทำ เหตุผลหลัก ๆ ของทาง Medium.com ที่ต้องลงมือทำนั้น เนื่องจากระบบเดิมที่พัฒนาด้วย Node.js นั้นมีขนาดใหญ่ กลายเป็นปัญหาคอขวด ทั้งเรื่องของ performance ที่ Node.js จะมีปัญหาเมื่อมีการใช้ I/O สูงมาก ๆ ดังนั้นการ scale ระบบใหญ่ ๆ ถูกพิสูจน์แล้วว่า วิธีการต่าง ๆ ไม่ทำให้ดีขึ้นเลย ยิ่งระบบใหญ่ขึ้น feature มากขึ้น ทีมก็ส่งมอบงานได้ช้าลง ประสิทธิภาพก็แย่ลงไปเรื่อย ๆ ยังไม่พอนะ เมื่อพัฒนา feature ใหม่ ๆ มันต้องกระทบกับส่วนอื่น ๆ ไปหมด ไม่สามารถย้ายหรือลบส่วนงานบางส่วนออกไปได้ เพราะว่าไปกระทบส่วนอื่น ๆ ทีมไม่กล้าที่จะแก้ไขหรือทำการเปลี่ยนแปลงระบบที่มีขนาดใหญ่ได้ เพราะว่าไม่สามารถระบุผลกระทบที่เกิดขึ้นได้เลย ส่งผลต่อการพัฒนาระบบงานอย่างมาก ยิ่งทำยิ่งช้า ส่วนการ scale ระบบยิ่งไม่ต้องพูดถึงยากมาก ๆ รวมทั้ง task ต่าง ๆ ที่ใช้ในการจัดการ resource บาง feature มี task ที่ง่าย บาง feature มี task ที่ซับซ้อน บาง feature ใช้ resource มากน้อยแตกต่างกัน ยังมีเรื่องอื่น ๆ อีกมากมาย ยกตัวอย่างเช่น ทีมไม่สามารถทดลอง technology ใหม่ ๆ ได้ เพราะว่าต้องผูกมัดกับ technology เก่าให้ได้ ซึ่งยากมาก ๆ จากเหตุผลต่าง ๆ เหล่านี้ น่าจะเพียงพอที่ทำให้ทีมพัฒนาต้องหาทางที่ดีกว่าเดิม
สิ่งที่น่าสนใจมาก ๆ คือ ขั้นตอนของการนำ Microservices มาใช้งาน ซึ่งในบทความสรุปไว้ 7 ข้อ จะทำการสรุปใน blog ต่อไป
Reference Websites https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f
↧
↧

สรุปแนวทางการนำ Microservices มาใช้งานของ Medium.com Part 2

October 30, 2018, 2:41 am
$
0
0

จาก Part ที่ 1 สรุปปัญหาและการนำแนวคิดของ Microservices มาใช้งานและแก้ไขปัญหา มาใน Part ที่ 2 มาดูแนวทางการใช้งานกัน ซึ่งทางทีมพัฒนาของ Medium.com ได้แบ่งแนวทางการนำ Microservices มาใช้ ออกเป็น 7 ข้อ มาดูกันว่าแต่ละข้อเป็นอย่างไรบ้าง ?

ข้อที่ 1 Build new services with clear value

เนื่องจากการสร้าง service ใหม่ มันมีค่าใช้จ่ายเสมอ รวมทั้งอาจจะต้องหยุดพัฒนาของเก่าอีกด้วย ถ้าหยุดพัฒนาของเก่าเป็นเวลานาน ๆ ไม่น่าจะส่งผลดีต่อ business แน่ ๆ ดังนั้น การเขียนใหม่ ออกแบบใหม่ทั้งระบบไม่น่าจะเป็นทางเลือกที่ถูก
Service ที่สร้างขึ้นมาใหม่นั้น มันมีคุณค่าชัดเจนหรือไม่ เอาให้ชัด ว่ามีคุณค่าต่อ business/product หรือ engineer แต่ถ้าการลงแรงทำไป มันไม่ได้ให้คุณค่าอะไรเลย ก็อย่าไปทำเลย ให้มันอยู่ของมันไป
ดังนั้นแนะนำให้เริ่มที่ monolith ก่อน จากนั้นมันจะช่วยให้เราง่ายต่อการนำ Micorservices มาใช้งาน

ข้อที่ 2 Monolithic persistent storage considered harmful

ปัญหาของการนำ Microservices ไปใช้งานคือ นักจะแยกออกเป็น service ย่อย ๆ ตาม model/domain ก็ว่าไป แต่สิ่งที่พบเจอมากสุด ๆ คือ Monolithic persistent Monolithic persistent คือ ทุก ๆ service ใช้งานที่จัดเก็บข้อมูลเดียวกัน เนื่องจากมันง่ายต่อการพัฒนาและให้แต่ละ service ทำงานร่วมกัน แต่ผลที่ตามมาคือ
  • แต่ละ service ผูกมัดกันอย่างแรง (Tight coupling)
  • เมื่อมีการแก้ไขที่จัดเก็บข้อมูล จะส่งผลกระทบในทุก ๆ service
แสดงตัวอย่างของ Monolithic persistent ดังนั้นควรต้องแยก persistent ออกมาในแต่ละ service ดังรูป

ข้อที่ 3 Decouple "building a service" and "running services"

การสร้าง service ที่ว่ายากแล้ว การ deploy/run service จะยากยิ่งกว่า เพราะว่าถ้าแต่ละ service ที่เราทำการ deploy/run ขึ้นไปนั้น มันต้องไปยุ่งเกี่ยวกับ service อื่น ๆ มากเท่าไร ก็จะทำให้ทีมช้าลงไปมากเท่านั้น ดังนั้นสิ่งที่ควรทำคือ ถ้าแยกแต่ละ service ออกกันอย่างชัดเจนแล้ว ควรต้องแยกตอนที่มันทำงานด้วย นั่นคือแต่ละ service ต้องแยกออกกันอย่างชัดเจนทั้งตอนสร้างและทำงาน สิ่งที่ต้องเตรียมการประกอบไปด้วย เรื่องของ network เรื่องของ communication protocol เรื่องของการ deploy เรื่องของการ monitoring ที่ Medium.com นั้นจัดการเรื่องต่าง ๆ ตามนี้
  • จัดการ network ด้วย Istio และ Envoy
  • ใช้ gRPC สำหรับให้แต่ละ service ติดต่อสื่อสารกัน
  • การ deploy จะใช้ AWS ECS และ Kubernetes

ข้อที่ 4 Thorough and consistent observability

สิ่งที่สำคัญมาก ๆ ในการพัฒนาระบบงานหรือ service คือ เรารู้ไหมว่าระบบงานหรือ service ของเรานั้นทำงานอย่างไร ? เรารู้หรือไม่เมื่อเกิดปัญหา ? เรารู้จุดที่เกิดปัญหาหรือไม่ ? ดังนั้นเรื่องของ logging, tracing, metric, alert และ dashboard ขาดไม่ได้เลยนะ ยิ่งในโลกของ Microservice ที่มีจำนวน service เยอะยิ่งจำเป็นต้องมีเสมอ และควรมีระบบต่าง ๆ เหล่านี้ตั้งแต่เริ่มต้น และควรใช้เครื่องมือที่เหมือน ๆ กันในทุก ๆ service และทีม ยกตัวอย่างที่ Medium.com จะใช้งาน
  • DataDog สำหรับการเก็บ log และ dashboard ต่าง ๆ
  • LightStep สำหรับการดู performance ของระบบ

ข้อที่ 5 Not every new service needs to be built from scratch

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

ข้อที่ 6 Respect failures because they will happen

ทุกสิ่งทุกอย่างมันทำงานผิดพลาดได้เสมอ ยิ่งในระบบการทำงานแบบกระจายยิ่งมีโอกาสเกิดขึ้นบ่อยมาก ๆ ดังนั้นการจัดการระบบงาน เมื่อเกิดข้อผิดพลาดต่าง ๆ ขั้นมา จึงเป็นสิ่งจำเป็นมาก ๆ คิดให้มาก ทดสอบให้มาก และจัดการกับปัญหาได้ดี ทุก ๆ ส่วนสามารถเกิดปัญหาได้เสมอ ดังนั้นอย่างแรกต้องทำใจก่อน จากนั้นต้องมีระบบ logging/tracing/alert เพื่อแจ้งหรือแสดงผลเมื่อเกิดปัญหาขึ้นมา ทำการทดสอบระบบหรือ service ใหม่ ๆ อยู่อย่างเสมอ ในปัจจุบันจะมีการทดสอบแบบ fail ๆ เช่นลองสุ่มปิดเครื่องหรือ service เช่นลองสุ่มตัด network
สิ่งที่ควรจะเกิดขึ้นมา หลังจากที่เกิดข้อผิดพลาดขึ้นมา คือ ระบบต้องสามารถ auto-recovery กลับมาให้ได้

ข้อที่ 7 Avoid "microservice syndromes" from day one

Microservice นั้นไม่ใช่จะมาช่วยแก้ไขปัญหาทุกอย่าง แต่มันแก้ไขได้บางอย่างเท่านั้น บ่อยครั้งอาจจะมีความคิดว่า ถ้าเราไม่คิดตาม Microservice ตั้งแต่แรกแล้ว มันจะทำให้ระบบยุ่งเหยิงมาก ๆ และ cost หรือค่าใช้จ่ายที่ตามมาสูงมาก ๆ ดังนั้นมันจะทำให้เราคิดเยอะมาก ๆ ออกแบบเยอะมาก ๆ ถ้าเป็นลักษณะนี้ แสดงว่าเรากำลังอยู่ในอาการ Microservice Syndromes ถ้าไม่ชัด มาดูตัวอย่างของอาการนี้กัน
  • เราจะแยก service ให้เยอะ ๆ เข้าไว้
  • อนุญาตให้แต่ละ service สามารถใช้ technology ที่หลากหลายได้ ซึ่งมันกลับส่งผลต่อการจัดการและดูแลรักษาอย่างมาก ทำให้แต่ละทีมแยกกันตาม technology อีกด้วย
  • การสร้างและการ run services ขึ้นมา จะเพิ่มความซับซ้อนรวมทั้งทำให้เราช้าลง
  • ที่จัดเก็บข้อมูลยังรวมกัน อันนี้ไม่น่ามีใครทำ
  • Service เยอะมาก ๆ แต่ขาดเรื่องของ tracing, logging ทำให้ยากต่อการหาจุดผิดพลาด

สิ่งที่น่าสนใจมาก ๆ จากกรณีของ Medium.com คือ

It is fine to start with a monolithic architecture, but make sure to modularize it and architect it with the above three microservice principles (single purpose, loose coupling and high cohesion), except that the “services” are implemented in the same tech stack, deployed together and run in the same process.
นั่นคือการทำ monolithic ให้ดีนั้นสำคัญและจำเป็นอย่างมาก ดังนั้นก่อนอื่นกลับมาดูระบบของเราก่อนว่าเป็นอย่างไร Referecen Websites https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f http://www.somkiat.cc/microservices-architecture-at-medium-part-1/
↧

เมื่อใดควรทำการ upgrade version ของภาษา Go

November 5, 2018, 5:58 pm
$
0
0

ไปอ่านเจอบทความที่น่าสนใจคือ When Should You Upgrade Go ? ทำการอธิบายว่า เมื่อใดควรที่จะทำการ upgrade version ใหม่ ๆ ของภาษา Go ซึ่งทำการอธิบายเข้าใจง่ายดี แน่นอนว่า ในตอนนี้ Go 1.11.2 ออกมาแล้ว จากนั้นก็ 1.11.3 เพื่อรอ release ถัดไปคือ 1.12 คำถามคือ ในตอนนี้เราควร upgrade ไปยัง 1.11.2 เลยดีไหม ? จากบทความอธิบายด้วยภาพดังนี้ นั่นหมายความว่า ถ้าคุณยัง run ระบบงานด้วย 1.10.5 แล้วก็ไม่ต้อง upgrade อะไร แต่ถ้าต่ำกว่านั้นก็รีบ upgrade เป็น 1.11.2 ซะ
ปล. วันนี้ใช้ Go version อะไรกันอยู่ ?
 
↧

ว่าด้วยเรื่อง Independencies

November 7, 2018, 5:10 am
$
0
0

จากหนังสือ It Doesn't Have to Be Crazy at Work นั้น อ่านมาถึงหน้าที่ 150 เรื่อง Independencies เป็นหัวที่น่าสนใจมาก ๆ เพราะว่าทีมพัฒนาส่วนใหญ่มักจะมีปัญหาเรื่องนี้เสมอ ยกตัวอย่างเช่น ฝั่ง Frontend ต้องไปเรียกใช้งานที่ฝั่ง Backend แต่ฝั่ง Backend ยังพัฒนาไม่เสร็จ คำถามคือ ฝั่ง Frontend จะทำอย่างไร ? โดยฝั่ง Backend นั้นจะเรียกว่าเป็น dependency ของฝั่ง Frontend นั่นเอง มาดูเนื้อหาในหนังสือกันว่าเป็นอย่างไรบ้าง ? แต่ละบริษัทมักจะเคลื่อนที่ไปข้างหน้าไปพร้อมกัน ดังนั้นแต่ละทีมที่เกี่ยวข้องกันต้องมีการ sync กันตลอด ดังจะเห็นได้จาก chart หรือ รายงานต่าง ๆ ที่มักจะดูดีและสวยงาม โดยที่มักจะไม่สนใจว่า แต่ละส่วนงานต้องเกี่ยวกันหรือขึ้นต่อกันหรือไม่ ออกแนวโลกสวย !!
สิ่งที่มักเกิดขึ้นคือ ถ้าบางทีมยังไม่พร้อม หรือ ทำยังไม่เสร็จ ก็รอกันต่อไป !!
ดังนั้นแต่ละอย่างควรมีการเตรียมพร้อมที่เหมาะสม มากกว่าผูกมัดกันเกินไป ลองดูสิว่า มีอะไรบ้างที่เราต้องรอ รอ รอ !! ทั้งทีม กลุ่มคน บางคน บางอย่าง ถ้าเจอแล้ว สิ่งที่ต้องทำคือ แก้ไขซะ เพราะว่า มันทำให้เราช้าลงไปอย่างมาก ในหนังสือบอกว่า ถ้าคุณเป็นบริษัทที่ทำด้านการผลิตเครื่องบิน หรือ โรงงานที่มีสายการผลิตชัดเจนแล้ว เรื่องของการรอเป็นเรื่องปกติ แต่ก็พยายามลดการรอลงนะ แต่ส่วนใหญ่สิ่งที่เราทำคือ การพัฒนา software การรอจึงไม่น่าเกิดขึ้น หรือ น้อยมาก ๆ ยกตัวอย่างเช่น ถ้าเราต้องพัฒนาระบบงาน web app และ mobile app แล้ว เมื่อต้องการเพิ่ม feature ใหม่ ๆ บน web app แต่ไม่สามารถ deploy/release หรือ เปิดใช้งานได้ เพราะว่า ต้องรอให้ Android และ iOS app ทำการ deploy/release feature ใหม่ก่อน ทำให้เราช้าลงเข้าไปอีก ยังไม่พอนะ Android app จะยังไม่ deploy/release ถ้า iOS ยังไม่ได้รับการ deploy/release และ approve ก่อน ยิ่งทำให้เราช้าลงไปอีกมาก
คำถามคือ ผู้ใช้งานแต่ละส่วนทั้ง Web, Android และ iOS นั้น สนใจหรือเปล่าว่า ต้องมี feature ใหม่ขึ้นมาพร้อม ๆ กัน ? มันจำเป็นไหม ?
หนักกว่านั้น ถ้ารอนาน ๆ ดังนั้นแต่ละรอบการ deploy/release จะมีงานที่ขึ้นเยอะมาก ๆ แถวบ้านเรียกว่า เป็นการ deploy/release แบบ bigbang คือ ใหญ่ ๆ ปัญหาที่เกิดตามมาคือ ยิ่งเยอะ ปัญหา หรือพวก defect ก็เพียบ การแก้ไข และ หาปัญหาไม่ง่ายเลย นั่นคือ ความเสี่ยงต่อ business อย่างแรง
ดังนั้นสิ่งที่หนังสือ บอกไว้คือ ถ้า Web พร้อม ก็ deploy/release เลย ถ้า Android พร้อม ก็ deploy/release เลย ถ้า iOS พร้อม ก็ deploy/release เลย
ดังนั้น ลด ละ เลิก หรือจัดการเรื่องของ dependency ซะ
↧

Robolectric ถูกเพิ่มเข้ามาใน AndroidX Testing แล้ว

November 10, 2018, 1:23 am
$
0
0

หลังจากที่ AndroidX Testing ถูกเพิ่มเข้ามาใน JetPack แล้ว Version ล่าสุดของ AndroidX Testing คือ 1.0.0 ซึ่งมีการเปลี่ยนแปลงที่น่าสนใจดังนี้
  • เพิ่ม Robolectric 4.0 เข้ามา
  • ค่าของ minSdkVersion เป็น 14 และ targetSdkVersion เป็น 28
  • สนับสนุน Instant apps แล้ว

ตัวที่น่าสนใจสุดน่าจะเป็น การเพิ่ม Robolectric 4.0 เข้ามา

เนื่องจากสามารถทำให้ทดสอบส่วนการทำงานที่อยู่ใน Android SDK ได้ เช่น Activity, Context เป็นต้น โดยไม่ต้องการ device หรือ emulator อีกด้วย ส่งผลให้การทดสอบเร็วขึ้นเป็นอย่างมาก แต่ไม่ได้บอกว่าต้องเปลี่ยนมาใช้ Robolectric หมดเลยนะ เนื่องจากควรต้องมีการทดสอบแต่ละ layer หรือแต่ละส่วนเสมอ ตามแนวคิดของ Pyramid testing นั่นเอง เพื่อทำให้เรามีความั่นใจต่อ app ที่พัฒนา

มาดูตัวอย่างการใช้งานกันดีกว่า

เครื่องมือที่ใช้งานคือ Android Studio 3.4 Canary 3 นะ จากนั้นก็สร้าง project และเลือก AndroidX Library ไปด้วยดังนี้

จากนั้นก็แก้ไขไฟล์ /app/build.gradle กันหน่อย

เพื่อทำการเพิ่ม depedency ต่าง ๆ ของ AndroidX Testing เข้าไป เนื่องจาก Android Studio จะมีเพียง JUnit, Espresso core และ Espresso runner เท่านั้น แน่นอนว่า มันยังไม่พอสำหรับเรา ดังนั้นทำการแก้ไขดังนี้ [gist id="e026dcd5c9d29bc66ce7b2df6ad4b155" file="build.gradle"] คำอธิบาย ทำการใส่ dependency สำหรับการทดสอบแบบ Unit testing และ Android testing โดยสิ่งที่ต้องการคือ การนำชุดการทดสอบจาก Android testing มาทดสอบใน Unit testing ด้วย Robolectric แต่ข้อจำกัดของ Robolectric นั้นจะทำการทดสอบได้ Activity เดียวเท่านั้นนะ ไม่สามารถข้าม Activity ได้

จากนั้นก็เขียนชุดการทดสอบ

[gist id="e026dcd5c9d29bc66ce7b2df6ad4b155" file="MainActivityTest.kt"] คำอธิบาย ในการเปิด Activity ขึ้นมานั้นจะใช้งาน ActivityScenario แน่นอนว่า ใช้งานง่ายกว่า ActivityTestRule เยอะมาก ๆ รวมทั้งสามารถช่วยจัดการ state ต่าง ๆ ของ Activity ได้อีกด้วย นั่นคือ เราสามารถทดสอบใน state ต่าง ๆ ของ Activity ได้ง่ายอีกด้วย มาลองใช้งานกันดู ที่น่าสนใจคือ ถ้า run ชุดการทดสอบนี้ใน Unit testing แล้ว จะทำการเรียกใช้งาน Robolectric ขึ้นมาให้แบบอัตโนมัติ และใช้งานได้เหมือนกัน แต่ทำงานเร็วกว่า แค่นั้นเอง ตัวอย่าง source code ของ project ตัวอย่างอยู่ที่ Github:Up1::Demo สุดท้ายแล้ว AndroidX Testing Library นั้น open source แล้วนะ ลองไปดูและศึกษากันได้
วันนี้นักพัฒนา Android App เขียน test กันไหมนะ ? ถ้ายังไม่เขียน ก็เขียนซะ !!!
Reference Websites https://medium.com/androiddevelopers/write-once-run-everywhere-tests-on-android-88adb2ba20c5 https://developer.android.com/training/testing/release-notes https://developer.android.com/training/testing/
↧
↧

สวัสดี Amazon Corretto

November 15, 2018, 1:44 am
$
0
0

ในวันที่ 14 พฤศจิกายนที่ผ่านมา ทาง Amazon ได้ประกาศปล่อย Amazon Corretto ออกมาให้ใช้งาน ซึ่งเป็น Preview version เพื่อให้ลองทดสอบใช้งานกันเล่น ๆ ส่วนตัว stable ต้องรอช่วง Q1 ของปีหน้า เป็น OpenJDK (Open Java Development Kit) ที่ทาง Amazon Web Server (AWS) ใช้งานภายใน แน่นอนว่า ใน OpenJDK ตัวนี้ ทำการแก้ไขและปรับปรุงเพื่อให้สามารถรองรับการใช้งานที่หนัก ๆ ได้ ทั้งในมุมของ scaling ทั้งในมุมของ performance ทั้งในมุมของ security ที่สำคัญกว่านั้นคือ เรื่องของการ support แบบ LTS (Long Term Support) ทั้งหมดนี้ใช้ฟรี ไม่มีค่าใช้จ่าย

คนที่ประกาศเปิดตัว Amazon Corretto ในงาน Devoxx ก็ไม่ใช่ใครที่ไหน

คือคุณ James Gosling หรือบิดาของภาษา Java และตัว Amazon Corretto จะถูกนำไปใช้งานใน Amazon Linux 2ในปี 2019 ต่อไป

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

ใน Preview version นี้สามารถติดตั้งได้ดังนี้
  • Amazon Linux 2
  • Microsoft Windows
  • MacOS
  • Docker
มาลองใช้งานผ่าน Docker กัน โดย image มีขนาด 600MB [gist id="715219136895e99c6290f710f9589cda" file="1.txt"] ยังไม่พอนะ source code ของ Amazon Corretto ก็มีให้อีกด้วย ลองใช้งานกันดูนะครับ ของดีเลยตัวนี้ ทำให้ OpenJDK น่าใช้ขึ้นเป็นกอง Reference Websites https://twitter.com/errcraft/status/1062641930205622273 https://aws.amazon.com/blogs/opensource/amazon-corretto-no-cost-distribution-openjdk-long-term-support
↧

แก้ปัญหา env: bash\r: No such file or directory

November 23, 2018, 11:05 pm
$
0
0

ปัญหาที่พบเจอ มี shell script บางตัวที่ทำการ run แล้วจะเจอ error ดังนี้
env: bash\r: No such file or directory
จะทำการแก้ไขอย่างไรดี ? ก่อนอื่นต้องทำความเข้าใจปัญหาก่อนว่า มันคืออะไรกันแน่ มิเช่นนั้นไม่น่าจะหาวิธีแก้ไขได้ จาก error message นั้น บอกว่าในไฟล์ของเรานั้นมีอักขระพิเศษคือ \r ซึ่งโดยปกติแล้วจะเพิ่มเข้ามาสำหรับ การบอกสิ้นสุดบรรทัดใน Windows OS (\r\n) ดังนั้นก็น่าจะพอเดาได้ว่า ไฟล์ที่ได้รับมานั้น น่าจะถูกเปิดและแก้ไขบน Windows OS มาก่อน เมื่อนำไฟล์มา run บน OS อื่นๆ เช่น Linux และ Mac OS จึงเกิดปัญหาขึ้น ดังนั้นการแก้ไขปัญหาที่ง่ายที่สุดคือ การลบ \r ออกไปซะ ด้วยคำสั่งง่าย ๆ ดังนี้ [code] $sed $'s/\r$//' ./source-file > ./target-file [/code] หรือถ้าใช้งานผ่าน Git แล้วก็ไปกำหนดให้ใช้รูปแบบของ Unix ซะดังนี้ [code] $git config --global core.autocrlf false [/code] เพียงเท่านี้ปัญหาก็จะหมดไป Reference Website https://stackoverflow.com/questions/29045140/env-bash-r-no-such-file-or-directory
↧
Search

พื้นฐานของการ monitor สิ่งต่าง ๆ ใน Docker

November 25, 2018, 7:58 pm
$
0
0

ในการจัดการ container ด้วย Docker นั้น เรื่องหนึ่งที่สำคัญมาก ๆ คือ การ monitoring นั่นเอง เราจะรู้ได้อย่างไรว่า Docker ทำงานอะไรบ้าง ? เราจะรู้ได้อย่างไรว่า แต่ละ container ใช้งาน CPU, Memory และ I/O เท่าไร ? สิ่งต่าง ๆ เหล่านี้เป็นคำถามที่ผู้ใช้งานใหม่ ๆ ต้องตอบให้ได้ ดังนั้นมาดูกันหน่อย ว่าทำอย่างไรได้บ้าง ?

เริ่มต้นด้วยวิธีการง่าย ๆ คือ Command line นี่เอง

โดย Docker ได้เตรียมชุดคำสั่งมาให้แล้ว คำสั่งแรกคือ [code] // ดูการทำงานทั้งหมด ประกอบไปด้วย CPU/Memory และ I/O แบบ realtime $docker container stats // หรือสามารถดูรายละเอียดของแต่ละ container ก็ได้ $docker container stats <id/name> // หรือสามารถเรียกใช้งานผ่าน Docker Remote API ได้เลย $curl --unix-socket /var/run/docker.sock http://localhost/containers/<id/name>/stats // หรือถ้าต้องการดู event หรือการทำงานภายในของ Docker ก็ใช้ $docker system events [/code]

วิธีการที่สอง ทำการ monitor ผ่าน Metric ด้วย Premetheus

โดยค่า default นั้นปิดไว้ ดังนั้นเราจำเป็นต้องเปิดใช้งานก่อน ในแต่ละ OS นั้นก็มีการ configuration ที่ต่างกันดังนี้
  • Linux แก้ไขที่ไฟล์ /etc/docker/daemon.json
  • Windows Server แก้ไขที่ไฟล์ C:\ProgramData\docker\config\daemon.json
  • Docker for Mac / Docker for Windows ไปที่ Docker icon เลือก Preferences => Daemon และกด Advanced
จากนั้นทำการแก้ไขและ restart Docker ดังนี้ [code] { "metrics-addr" : "0.0.0.0:1337", "experimental" : true } [/code] จากนั้นสามารถเข้าใช้งานผ่าน url = http://localhost:1337/metrics เมื่อทุกอย่างเรียบร้อยก็ติดตั้งและ configuration ค่าของ Premetheus ซะ ส่วน graph สวย ๆ ก็ไปใช้งาน Grafana ก็พอไปวัดไปวาได้

วิธีการที่สาม ใช้งานผ่าน cAdvisor

ไม่ต้องทำอะไรมาก เพียงสร้าง container มาเลย ดังนี้ [code] $docker run \ -d \ --name=cadvisor \ -p 8080:8080 \ --volume=/var/run:/var/run:rw \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ google/cadvisor:latest [/code] จากนั้นก็เข้าไปใช้งานผ่าน url = http://localhost:8080 เพียงเท่านี้เราก็สามารถ monitor การทำงานของ Docker แบบง่าย ๆ ได้แล้วครับ
↧

Technology Radar Vol. 19 มาแล้วนะ

December 3, 2018, 12:14 am
$
0
0

มาช้าดีกว่าไม่มา สำหรับ Technology Radar Vol. 19 ซึ่งจะทำการ update ปีละ 2 ครั้ง ที่บอกว่าช้าคือ ผมนี่แหละ ที่ทำการสรุปช้าหน่อย โดยในครั้งนี้จะมีเรื่องสำคัญ ๆ 4 เรื่องคือ
  1. Sticky cloud
  2. Lingering Enterprise Antipatterns
  3. Enduring Engineering Practices
  4. Pace = Distance / Time
มาดูรายละเอียดกัน

1. Sticky cloud

การผูกติดกับ Cloud provider ต่าง ๆ ไม่ว่าจะเป็น AWS, GCP และ Azure เมื่อเราใช้ไปเรื่อย ๆ จะพบว่ายิ่งผูกมัดมาก ๆ บ่อยครั้งจะกลับไปสู่จุดเดิมที่เคยเป็นคือ ย้ายไปไหนไม่ได้ แต่ถ้าเราได้ข้อเสนอจาก Cloud provider อื่น ๆ ที่น่าสนใจ เช่น ดีกว่าและถูกกว่า เราจะทำอย่างไร ? ดังนั้นในรายงานครั้งนี้จะเน้นเรื่องของการ portability ของระบบ เพื่อให้ระบบงานของเราย้ายไปยังที่อื่นได้ง่ายขึ้น เช่น โดยในรายงานชุดนี้แนะนำเครื่องมือในการจัดการระบบงานบน cloud 2 ตัวคือ Terragrunt และ Pulumi

2. Lingering Enterprise Antipatterns

ในองกรค์ขนาดใหญ่ที่เรามักเรียกว่า Enterprise นั้น ไม่ว่า technology จะเปลี่ยนแปลงไปอย่างไร หรือเร็วเพียงใด ก็มักจะสร้าง antipattern ขึ้นมาอย่างสม่ำเสมอ หรือจริง ๆ แล้ว มันคือการพยายามต่อต้านกับการเปลี่ยนแปลงนั้นเอง แต่ว่าจะไม่ทำก็ไม่ได้ ก็เลยต้องใช้ของใหม่ ๆ แต่ก็ยังคิดแแบบเดิม ๆ งงไหมละ ? ยกตัวอย่างของ Enterprise Antipatterns ที่เกิดขึ้น ซึ่งไม่แนะนำให้ทำ แต่ละเรื่องมันออกแนว Centralize และพวก Drag & Drop ทั้งนั้นเลย
อย่าลืมว่า เราทำการออกแบบระบบใหม่ เพื่อแก้ไขปัญหาเดิมที่เกิดขึ้น ดังนั้นจำเป็นต้องเลือกเครื่องมือและวิธีการที่เหมาะสมกับปัญหา รวมทั้งต้องระวังกับการนำแนวคิดเดิม ๆ ที่สร้างปัญหามาใช้ในการแก้ปัญหาด้วยละ เพราะว่า ผลสุดท้ายก็จะได้ปัญหาแบบเดิม ๆ ในร่างใหม่ ๆ มาอีก !!

3. Enduring Engineering Practices

เมื่อเทคโนโลยีมีอัตราการเปลี่ยนแปลงที่สูงขึ้น ดังนั้นองค์กรก็ต้องมีคนที่มีความสามารถ ตลอดจนต้องมี engineering practice ที่ดี เพื่อช่วยทำให้สามารถนำเทคโนโลยีใหม่ ๆ เข้ามาใช้งานได้อย่างถูกต้องและเกิดประโยชน์สูงสุด ยกตัวอย่างเช่น พวก container, reactive frontend และ machine learning เป็นต้น แต่ถ้าองค์กรยังไม่แน่ใจในเทคโนโลยีใหม่ ๆ ก็จำเป็นต้องทำให้แน่ใจ เข้าใจมันก่อน ว่าจะใช้ได้หรือไม่ นั่นคือการทำ research นั่นเอง โดยองค์กรต่าง ๆ จำเป็นต้องลงมือในสองรูปแบบนี้อย่างต่อเนื่อง เพื่อทำการต่อยอดและปรับปรุงอยู่ตลอดเวลา การเรียนรู้ ไม่ใช่การนำมาใช้งาน แต่มันคือการทำความเข้าใจ รู้จักข้อดีข้อเสีย ประโยชน์ของมัน เมื่อเราเจอปัญหาจะได้เลือกนำมาใช้แก้ไขอย่างเหมาะสมและทันท่วงที

4. Pace = Distance / Time

การพัฒนา software นั้นมีการเปลี่ยนแปลงอยู่ตลอดเวลา โดยที่เวลานั้นน่าจะเป็นค่าคงที่ไปแล้ว เพราะว่าจากการรายงานเรื่องของ technology จะคงที่ ไม่เปลี่ยนแปลงมากนัก แต่ในส่วนของ Distance ของการสร้าง เรียนรู้ศึกษา ใช้งาน technology ต่าง ๆ กลับเพิ่มมากขึ้น นั่นหมายความว่า ความเร็วในการเปลี่ยนแปลงของ technology มันสู'ขึ้นอย่างต่อเนื่อง ส่งผลทำให้การเลือกมาใช้งานต้องทำอย่างระมัดระวังและรอบคอบ

ลองไปดูบางอย่างที่น่าสนใจในแต่ละกลุ่มกันหน่อย

  • Techniques ที่น่าสนใจคือ Event Storming เป็นเทคนิคหนึ่งสำหรับการทำ domain modeling สำหรับ Microservices นั่นเอง
  • Tools ที่น่าสนใจคือ UI dev environments ที่มาพร้อมกับคำว่า DesignOps ช่วยทำให้ UX/UI/Designer/Developer ทำงานร่วมกันได้ดีมากยิ่งขึ้น โดยเครื่องมือที่ใช้งานก็เช่น Storybook, React-styguidist, Compositor และ MDX เป็นต้น
  • Languages and Frameworks ที่น่าสนใจคือ MMKV เป็น Key-value stage สำหรับ Mobile app ที่สร้างจาก WeChat
สามารถอ่านเอกสารเผยแพร่ภาษาไทยได้ เป็นเอกสารสั้น ๆ นะ หรือถ้าต้องการแบบเต็ม ๆ ก็ [PDF] Technology Radar Vol. 19 เลยครับ  
↧
↧

สิ่งที่น่าสนใจจากหนังสือ Make Time: How to Focus on What Matters Every Day

December 3, 2018, 6:17 am
$
0
0

หลังจากอ่านหนังสือ Make Time: How to Focus on What Matters Every Day ไปนิดหน่อย ก็มีเรื่องที่น่าสนใจหลายอย่างเลย หนึ่งในนั้นคือ วิธีการแก้ปัญหาเรื่อง Mobile Addict หรือโรคติดโทรศัพท์มือถือนั่นเอง แน่นอนว่า มันทำให้เราสูญเสียเวลามากมายไปกับมัน คำถามที่น่าสนใจคือ เราจะทำการควบคุมอย่างไร ? ต้องรอให้มีใครสร้างเครื่องมือจัดการมาให้หรือไม่ ?
ในหนังสือนั้นได้บอกว่า อย่าไปรอเลย โทรศัพท์มือถืออยู่ในมือเราเอง ดังนั้นเราเองนั่นแหละที่ต้องแก้ไขมันเอง
คำถามต่อมา ต้องทำอย่างไรดีละ ? ในหนังสือได้แนะนำให้ทดลองทำสิ่งต่อไปนี้ สัก 2 ชั่วโมง จากนั้นคุณลองถามตัวเองสิว่า รู้สึกอย่างไรบ้าง ? เป็นการทดลองก่อนทำจริง ๆ ในระยะยาว มาเริ่มกันดีกว่า ขั้นตอนที่ 1 ต้องตอบให้ได้ก่อนว่า เหตุใดคุณถึงจะลอง ? เช่น เพื่อให้เวลาแก่คนรอบข้างมากขึ้น เพื่อให้เวลากับการทำงานมากขึ้น ขั้นตอนที่ 2 กำหนดความคาดหวัง เช่นการประกาศให้เพื่อน ๆ รู้ไปเลยว่า เรากำลังจะทำอะไร ยกตัวอย่างเช่น เราอาจจะตอบสิ่งต่าง ๆ ช้าลงไปมาก เพราะว่า กำลัง focus กับงานอยู่ ถ้ามีเรื่องเร่งด่วน ช่วยโทรมาเลยนะ ขั้นตอนที่ 3 ลบพวก social media app ลบให้หมดในทุก ๆ device ที่ใช้งาน ขั้นตอนที่ 4 ลบพวก news app หรือข่าวต่าง ๆ ขั้นตอนที่ 5 ลบพวก VDO และ Game app ซะ ขั้นตอนที่ 6 ลบพวก browser app ทิ้งไป หายหมด ขั้นตอนที่ 7 ลบพวก email, messaging, chat หรือ productivity tool ทิ้งไป ขั้นตอนที่ 8 ไปปิด notification ของทุก ๆ app ไปด้วยเลย

จากนั้นลองดูว่า ภายใน 2-3 ชั่วโมง คุณรู้สึกอย่างไร

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

สรุปการใช้งาน Docker ในการพัฒนาระบบงานไว้นิดหน่อย

December 8, 2018, 7:48 am
$
0
0

พอดีในวงกินเบียร์มีการพูดคุยเรื่องการใช้งาน Docker สำหรับการพัฒนาระบบงาน ซึ่งมันมีทางเลือกในการใช้งานหลากหลายแนวทางมาก ๆ ดังนั้นจึงสรุปไว้กันลืมนิดหน่อย ว่าคุยอะไรไปบ้าง (เท่าที่จำได้น่าจะคุยและ demo ให้ดูประมาณไม่เกิน 10 นาที) มาเริ่มกันเลย

เริ่มจากปัญหาคือ Work on my machine

นักพัฒนานั้นก็จะทำการเขียน code ติดตั้ง library/dependency ทำการ build/compile จัดการข้อมูลต่าง ๆ ใน database แน่นอนว่า ทุกอย่างมัน work หรือทำงานได้ตามที่คาดกวังบนเครื่องนักพัฒนา แต่เมื่อไปติดตั้งสิ่งต่าง ๆ ที่พูดมาข้างต้นแล้ว บนเครื่องอื่น ๆ ยกตัวอย่างเช่น CI server, Dev/Test/Staging/Production กลับไม่ได้ !! ต้องใช้เครื่องมือและวิธีการที่ต่างออกไป สุดท้ายก็ไม่เหมือนกันอีกแล้ว มันยังไงกันนะ !! ยกตัวอย่างของปัญหา เครื่องนักพัฒนาใช้ Mac OS พัฒนาระบบงานด้วยภาษา Go จัดการ dependency ด้วย go mod ทำการ compile และ build เป็น binary file ทำการทดสอบทั้ง Unit test และ Integration test ทำการ deploy และติดตั้งระบบงานด้วยการนำ binary file ไป run เพียงเท่านี้ก็จบแล้ว ปัญหาที่พบเจอบ่อย ๆ คือ
  • Version ของภาษา Go ที่ต่างกัน
  • Binary file ที่สร้าง และ deploy ใน environment ต่าง ๆ มีปัญหา เพราะว่าใช้ OS ต่างกัน
  • การทำ integration test ยากมาก ๆ
การแก้ไขปัญหาพื้นฐานคือ การคุยและตกลงร่วมกัน ส่วนการ build และ deploy ก็เขียนMakefile และ shell script ไว้ใน project ให้ทุกคนใช้งานร่วมกัน เพียงเท่านี้ก็แก้ไขปัญหาได้แล้ว แต่พวก Makefile และ shell script ต่าง ๆ ต้องรับค่าต่าง ๆ จากผู้ใช้งานด้วย เช่น นักพัฒนาต้องการ build บน Mac OS ก็ต้องค่าพวก platform/architecture ของ Mac เข้าไป ผลที่ออกมาคือ ยังมีข้อผิดพลาด ส่วนเรื่องของ version ของภาษา Go ก็ยังเกิดขึ้น แต่ไม่ค่อยส่งผลมากเท่าไร

จากปัญหาต่าง ๆ ที่ยังเกิดขึ้น เลยมีการพูดถึงการนำ Docker มาใช้งาน

ซึ่งการใช้งานต้องแบ่งออกเป็นขั้นตอนแยกกันดังนี้ อย่าเอามารวมกันนะ ไม่งั้นมั่วแน่นอน
  1. Docker สำหรับการพัฒนาบนเครื่องของนักพัฒนาแต่ละคน
  2. Docker สำหรับการทดสอบ
  3. Docker สำหรับการ deploy

1. Docker สำหรับการพัฒนาบนเครื่องของนักพัฒนาแต่ละคน

เริ่มง่าย ๆ คือ ติดตั้ง Docker ก่อนนะ กินทรัพยากรมากพอดู ดังนั้นเครื่องนักพัฒนาต้องแรงพอตัว เมื่อเครื่องพร้อมก็ไปเลือก Docker Image ของภาษา Go ที่ต้องการจาก Docker Hub ใช้งานง่าย ๆ ด้วย command line ดังนี้ ตัวอย่างใช้ภาษา Go version 1.11.2 บน Alpine OS Code ตัวอย่างที่พอจะเขียนได้ตอนนั้น [gist id="3575eca14ac0cd64d44d5526d9e66f09" file="hello.go"] ทำการ compile และ run ด้วย Docker ดังนี้ [code] # Run $docker container run --rm -w /xxx -v $(pwd):/xxx golang:1.11.2-alpine3.8 go run hello.go # Build binary file และ Run $docker container run --rm -w /xxx -v $(pwd):/xxx golang:1.11.2-alpine3.8 go build -o ./app $docker container run --rm -w /xxx -v $(pwd):/xxx golang:1.11.2-alpine3.8 ./app [/code] แต่ถ้าเบื่อ command line เยอะ ๆ ก็สร้าง Dockerfile มาใช้ซะ เริ่มจากสร้างไฟล์ Dockerfile_dev สำหรับทำการ compile/build/run ระบบงาน [gist id="3575eca14ac0cd64d44d5526d9e66f09" file="Dockerfile_dev"] ทำการ run ด้วยคำสั่ง [code] $docker image build -t demo -f Dockerfile_dev . $docker container run --rm demo [/code]

2. อย่าลืมเพิ่มส่วนของการทดสอบ และพวกการจัดการ library/dependency เข้าไปด้วยนะ

เริ่มด้วยการเขียน Dockerfile_testing ขึ้นมา [gist id="3575eca14ac0cd64d44d5526d9e66f09" file="Dockerfile_testing"] ทำการ run ด้วยคำสั่ง [code] $docker image build -t demo -f Dockerfile_testing . $docker container run --rm -t demo [/code]

3. อีกส่วนคือการใช้ Docker สำหรับการ deploy

สิ่งที่แนะนำไปคือ การใช้งาน Multi-stage build สำหรับการสร้าง Docker Image เพื่อให้ได้ Docker Image ที่มีของเท่าที่จำเป็น เนื่องจากตอนนี้ Docker Image ของระบบจากขั้นตอนที่ 1 และ 2 มันใหญ่มาก เพราะว่ามีทั้ง Go และอื่น ๆ อีกมากมาย แต่ในการ deploy ระบะบบงานของเรานั้น ต้องการเพียงนำ binary file ไปติดตั้งบน OS ที่ต้องการเท่านั้น ดังนั้นมาใช้งาน Multi-stage build กัน ทำการสร้าง Dockerfile ดังนี้ [gist id="3575eca14ac0cd64d44d5526d9e66f09" file="Dockerfile"] ทำการ run ด้วยคำสั่ง [code] $docker image build -t demo -f Dockerfile . $docker container run --rm -t demo [/code] ส่งผลทำให้ขนาดของ Docker Image ของระบบงานเราเล็กลงไปอย่างมาก จากตัวอย่างนี้ลดจาก 431 MB เหลือเพียง 6.92 MB เท่านั้นเอง ตัวอย่าง code อยู่ที่ Github:Up1:Demo with Go
เพียงเท่านี้เราก็สามารถนำ Docker มาใช้ในการพัฒนาระบบงานได้อย่างแจ่มแล้วนะครับ ถ้าไม่อยากเขียนเยอะ ๆ ก็ไปใช้ Docker Compose ต่อไปนะ ขอให้สนุกกับการ coding ครับ
↧

ไปอ่านเจอ ว่าด้วยเรื่อง Microservices 4.0 !!!

December 10, 2018, 7:59 am
$
0
0

ไปอ่านเจอใน feed จาก Twitter แบบผ่าน ๆ เจอว่ามีการพูดถึง Microservices 4.0 ด้วย (หา link ต้นทางไม่เจออีก) แบบนี้แสดงว่า 4.0 นี่ไม่ได้ฮิตในบ้านเราเท่านั้นนะ (ไม่น่าเกี่ยวข้องกัน) เลยนำมาสรุปแบบคร่าว ๆ ไว้หน่อย น่าจะพอมีประโยชน์กันบ้าง
ปล. แค่เรื่อง Microservices ก็ยังงง ๆ กันแล้ว นี่มีทั้ง 1.0, 2.0, 3.0 และ 4.0 จะไม่งงได้อย่างไร !!

เริ่มด้วยประวัติความเป็นมาก่อน

โดยเล่ามาตั้งแต่ Continuous Integration(CI) และ Continuous Delivery (CD) มาถึง Agile ต่อด้วยเข้าสู่ยุคของ Cloud คือ Amazon EC2 จากนั้น J2EE (แก่จริง ๆ) ก็มา ตามด้วย DevOps ติด ๆ แต่ที่โด่งดังมาก ๆ คือ AWS + Netflix นั่นเอง ซึ่งหลังจากนี้เริ่มเข้าสู่ยุค Microservices 1.0

โดยทาง Netflix ได้พัฒนาระบบตามแนวคิดเหล่านี้

แถมยังปล่อยของชุดใหญ่ออกมา ยกตัวอย่างเช่น
  • Service registry คือ Eureka
  • API Gateway คือ Zuul
  • Client-side Load Balancer คือ Ribbon
ยังไม่พอนะ Spring Boot + Spring Cloud มาอีก ยิ่งทำให้ทุกอย่างมันเหมาะเจาะพอดี ดังนั้นสาย Java จึงมักจะพัฒนาตาม stack ของเทคโนโลยีเหล่านี้ แต่ยังผูกติดกับภาษาและเทคโนโลยี แถมต้องเพิ่ม code ในเรื่องต่าง ๆ เข้ามาในระบบงานของเราอีก ซึ่งมันดูขัด ๆ กับแนวทางและคุณสมบัติของ Microservices นะ !!

ดังนั้นจึงมาแนวคิดว่า ถ้าแยกส่วนการทำงานต่าง ๆ ออกมาจาก code

ยกตัวอย่างเช่น Service registry, API Gateway หรือเรื่อง routing รวมไปถึงเรื่องของการ deploy และ scale ออกมา ลดเรื่องของการผูกติดกับภาษาและเทคโนโลยี รวมทั้งไม่ยึดติดกับ Cloud provider อีกด้วย นั่นคือจึงเป็นที่มาของ Kubernetes + Docker ทำให้เข้าสู่ยุค Microservices 2.0

แต่ปัจจุบันเริ่มพูดถึง Service Mesh มากยิ่งขึ้น

นั่นคือจำนวนของ service เริ่มมากขึ้น การติดต่อสื่อสาร การจัดการเรื่อง Authentication การจัดการเรื่อง logging การจัดการเรื่อง tracing ซึ่ง Kubernetes ยังไม่ตอบโจทย์มากนัก จึงทำให้เกิด Istio ขึ้นมา เพื่อจัดการหรือตอบโจทย์สิ่งเหล่านี้ ทำให้แยกส่วนการทำงานเหล่านี้ไปให้ Istio ดูแลให้เราเลย แต่แน่นอนว่า ได้บางอย่างก็ต้องเสียบางอย่างไปเสมอ นั่นคือ overhead ของการเรียนรู้สิ่งใหม่ ๆ นั่นเอง นี่คือ Microservices 3.0

จะเห็นได้ว่า เป้าหมายของการสร้างสิ่งต่าง ๆ ออกมา

เพื่อแก้ไขปัญหาทั้งสิ้น ส่งผลให้ code ของระบบงานนั้น มีเฉพาะสิ่งที่จำเป็นจริง ๆ ส่วนอื่น ๆ แยกออกไปให้เป็น platform/infrastructure ดีกว่า แต่ก็แลกมาด้วย overhead รวมทั้งต้องเรียนรู้ของอีกหลาย ๆ อย่างมาแทนเช่นกัน แสดงดังรูป

สุดท้าย ... ไม่ใช่สิ คือ ล่าสุด Microservices 4.0

ทำไมคุ้น ๆ กับประเทศเรานะ !! มันคือเรื่องของสิ่งที่พูดกันเยอะมาก ๆ คือ Function as a Service (FaaS) หรือ Serverless นั่นเอง
ก่อนอื่น จะนำอะไรมาใช้ตอบให้ได้ก่อนว่า เรามีปัญหาอะไร ?
↧
Viewing all 1997 articles
Browse latest View live
Search