หลังจากที่ลองเล่น Libra ไปเล็กน้อย
เห็นเขาบอกว่า สามารถเขียน Smart Contract บน Libra ได้เลย
โดยการเขียนนั้นใช้ภาษา Move นั่นเอง
ดังนั้นลองมาเขียนดูหน่อย

แต่ตอนนี้ยังไม่สามารถ deploy code/module ต่าง ๆ ไปยัง Libra ได้นะ
ดังนั้นจึงต้องทดสอบผ่านการทดสอบที่ Libra มีให้ก่อน
ซึ่งจะทำงานอยู่บน memory ของเครื่องเรานั่นเอง

ปล. เท่าที่ไปอ่านเหมือนมีคนลองทำการ deploy บน Local Validator node ด้วยนะ

เริ่มต้นลองไปดู code ตัวอย่างใน code ของ Libra

อยู่ใน folder language/functional_tests/tests/testsuite
จะมี code ตัวอย่างเพียบเลย
สามารถทดสอบด้วยคำสั่ง

เท่าที่ไปตามแกะดูถ้าต้องการ deploy ไปยัง local หรือใน test network 
น่าจะต้องไปแก้ไขไฟล์  vm/vm_genesis/genesis/vm_config.toml
ให้ค่าของ type เป็น Open ดังนี้

ตัวอย่าง code ของการโอนเงิน ( Libra coin ) ไปยังบัญชี Libra อื่น 

แต่ถ้าไม่มีก็สร้างขึ้นมา (เตรียม function มาให้ครบเลย)

สามารถทำการ compile หรือ Move IR Compiler ได้อีกด้วย
จะทำการสร้าง Move bytecode ให้ สามารถใช้ได้ดังนี้

มาทำการทดสอบกันหน่อย

โดยจะโอนเงินไปยังบัญชีปลายทาง
จากนั้นตรวจสอบ balance ทั้งผู้ส่งและผู้รับว่าถูกหรือไม่
ดังนี้

จากนั้นทำการทดสอบด้วยคำสั่งดังนี้

เพียงเท่านี้ก็ลองทำการทดสอบได้แล้ว
แค่นี้ก็พอเริ่มต้นได้แล้ว
ไว้ลองลงไปดูตัวภาษา กับสิ่งที่ Move เตรียมไว้ให้
ว่าง ๆ ไปอ่าน Paper ของ Move เล่นไปก่อนได้

เห็นใน Go 1.13 beta 1 นั้นทำการกำหนดค่า default ของ GOPROXY ให้
จะวิ่งไปที่ https://proxy.golang.org และ direct (ออกไปยัง GitHub, bitbucket ตรง ๆ)
ที่สำคัญ สามารถใส่ comma(,) ได้ด้วย
นั่นคือกำหนด proxy ได้มากกว่า 1 นั่นเอง
ดังนั้นเรามาลองทำความรู้จักและใช้งานกันหน่อย

ทำไมต้องใช้ GOPROXY ด้วย ?

โดยค่าปกตินั้น Go module นั้น
จะทำการตรวจสอบ module/dependency ที่ใช้
ใน $GOPATH/pkg/mod
ถ้าไม่เจอจะไปที่ github, gitlab, bitbucket และอื่น ๆ ก็ว่าไป

ปัญหาคือ 

ถ้าออก internet ไม่ได้จะทำอย่างไร ?
ยิ่งในโลกของ container ยิ่งลำบากเพราะว่า
ต้องทำการ download module/dependency มาตลอด
เพราะว่าต้องทำการ build ใหม่ตลอด
หรือแก้ไขด้วยการทำ caching ใน container เอาอีก
ซึ่งดูลำบาก
ยิ่งการ scale ทีมหรือ project ก็ยิ่งยาก

ดังนั้นทางทีม Go จึงสร้าง GOPROXY ขึ้นมา

เพื่อแก้ไขปัญหาต่าง ๆ เหล่านี้ นั่นคือ
ให้เราสามารถสร้าง GOPROXY ได้เอง
เพื่อทำการเก็บ cached ของ module ต่าง ๆ ที่ download มาไว้
ทำให้ไม่ต้องทำการ download ใหม่ทุก ๆ ครั้ง
แสดงดังรูป

อยากรู้ว่าการทำงานของ GOPROXY เป็นอย่างไร ?

ว่าแล้วก็เขียน code ด้วยภาษา Go แบบง่าย ๆ
เพื่อ tracking ดูว่าทำงานอย่างไร ดังนี้

จากนั้นทำการ run หรือ start ขึ้นมา จะทำการ port=8080 นะ

เมื่อเรียบร้อยแล้ว สร้างระบบงานตัวอย่าง
โดยระบบงานตัวอย่างจะใช้งาน module color

ทำการ run และดูผลที่เกิดขึ้น
อย่าลืมไปลบ $GOPATH/pkg/mod ด้วย
มิเช่นนั้นจะไม่เห็นผลการทำงานที่ฝั่ง proxy ที่สร้างไว้

แต่ถ้า run ด้วยการไม่กำหนด direct ไปใน GOPROXY 
จะได้ผลคือ  ไม่พบข้อมูลของ module ที่ใช้งานดังนี้

นั่นหมายความว่า proxy จะมีรูปแบบของไฟล์และ folder ตามที่กำหนดด้วย
ประกอบไปด้วย

• List of version ถ้า go ไม่รู้ว่าเราต้องการ version อะไร
• ไฟล์ .mod หรือ Module metadata
• ไฟล์ go.mod ของ module นั้น ๆ
• Zip file ของ module

น่าพอเห็นภาพแล้วว่า GOPROXY ต้อง implement อะไรบ้าง

ไว้ค่อยไปทำต่อไป น่าจะเห็นแนวทาง คิดว่า น่าจะมีคนทำไว้ให้เราใช้แน่ ๆ
ก็ไปเจอ Athens และ JFrog Go Registry

ยังไม่พอนะใน GOPROXY เราสามารถกำหนด path ตรง ๆ ได้เลย

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

น่าจะพอทำให้เห็นประโยชน์ของ GOPROXY กันบ้าง

พอดีต้องเขียนเอกสารอธิบายขั้นตอนการทำงานของระบบงานนิดหน่อย
ถ้าจะเขียนแบบใช้ program มาช่วย มันดูจะลำบากเกินไปหน่อย
เลยคิดว่า
ถ้าเขียนเป็นไฟล์ในรูปแบบ Markdown
แล้วทำการแปลงมาอยู่ในรูปแบบต่าง ๆ ได้เลย
เช่นรูปและ pdf น่าจะสะดวกกว่า
แถมสามารถเก็บไฟล์ Markdown ไว้ใน Version Control System ได้อีกด้วย
จึงลองไปหาดูว่ามีอะไรให้ใช้บ้าง

เมื่อไปดูมาก็พบว่า มีของให้ใช้เพียงเลย

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

• MermaidJS
• Flow chart
• Sequence diagram
• Plant UML
• WaveDrom
• GraphViz

หลังจากที่ลองใช้งานแล้ว ชอบ MermaidJS เป็นการส่วนตัว
เนื่องจากใช้งานง่าย แถมผลที่ออกมาโดน
เลยมาลองใช้กันหน่อย

ตัว MermaidJS ใช้งานได้หลายแบบ

โดยวิธีการที่ผมใช้งานคือ ใช้งานผ่าน Mermaid CLI ดังนี้
ติดตั้งด้วยคำสั่ง

มาลองสร้าง Flow chart

ทำการสร้าง flow chart ออกมาในรูปแบบ png ได้ดังนี้

ได้ผลลัพธ์ออกมาดังรูป

หรือลองสร้าง Sequence diagram ก็สนุกดี

มาลองใช้งานกันดู ง่ายและสะดวกดี

จากที่พูดคุยเรื่อง Memory leak สำหรับการใช้งาน package net/http ในภาษา Go
ซึ่งมี 2 เรื่องคือ

• ถ้าไม่ปิด body ของ request จะเกิดอะไรขึ้น ?
• ถ้าไม่ปิด body ของ response จะเกิดอะไรขึ้น ?

ในข้อแรกนั้นจากเอกสารใน code บอกว่า

ถ้าฝั่ง client side แล้ว
body ของ request เป็น nil เช่นใช้งาน HTTP GET แล้ว
ไม่จำเป็นต้อง close นะ
แต่ถ้าไม่ใช่ nil ก็จำเป็นต้องปิดเอง !!

ในข้อที่สอง ตรงนี้ใน project ใช้บ่อยเลยลองไปดูหน่อยนึง

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

เป็นการไปเรียกข้อมูลมาจาก web/api ต่าง ๆ
ซึ่งในฝั่งเรียกหรืือ client จะใช้งาน Goroutines
พบว่า ถ้าเราไม่ทำการปิด body ของ response พบว่า
จะมี Goroutines ค้างอยู่เพียบเลย มัน leak ไหมนะ !!
ดังนี้

ผลการ run เป็นดังนี้

ดังนั้นจำเป็นต้องแก้ไขด้วยการปิด body ของ response ดังนี้

ผลที่ได้คือ จำนวนของ Goroutines ที่ค้างจะเหลือน้อยมาก ๆ
นั่นคือ มีการคืนหน่วยความจำกลับมาให้ระบบ
ตรงนี้น่าจะลดเรื่อง Memory leak ลงไปได้เยอะเลย

Reference Websites

• https://hackernoon.com/avoiding-memory-leak-in-golang-api-1843ef45fca8
• https://husobee.github.io/golang/memory/leak/2016/02/11/go-mem-leak.html

จากบทความเรื่อง Programmer Test Principles เขียนโดยคุณ Kent Beck
ทำการอธิบายเรื่องของ Programmer Test ไว้น่าสนใจดี
เลยทำการสรุปจากการอ่านไว้นิดหน่อย

จากบทความสรุปไว้สั้น ๆ ว่า Programmer test ควรจะ

• ไม่ต้องเสียเวลาในการรอ นั่นคือ ต้องทดสอบเร็ว (Waiting time == Waste) ดังนั้นเรื่องของ Fast feedback จึงสำคัญมาก
• ยิ่งเร็วมากเท่าไร ยิ่งช่วยลดการ debug ลงไปมากเท่านั้น
• เร็วอย่างเดียวไม่พอ ชุดการทดสอบต้องมีความน่าเชื่อถือด้วย
• ลดความกลัวเมื่อต้อง deploy หรือช่วยให้เรารู้ว่าสิ่งที่เกิดขึ้นหลังจาก deploy เป็นอย่างไร หรือช่วยบอกว่าเราควร deploy ไหม
• ถ้าโครงสร้างเปลี่ยนหรือทำการปรับปรุงแล้ว test ต้องไม่พัง (Refactor)
• ถ้าพฤติกกรมการทำงานเปลี่ยนแล้ว แน่นอนว่า test ต้องพังหรือไม่ผ่าน
• ง่ายต่อการเขียน อ่านและเปลี่ยนแปลง ซึ่งตรงนี้ต้องใช้ประสบการณ์มากพอสมควร ถ้าดูแลไม่ดีแล้วชุดการทดสอบก็จะเป็นภาระเพิ่มมาอีกนะ

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

เมื่อเช้าเห็น timeline ใน facebook มีการ share gitignore.io มา
ซึ่งเป็น website สำหรับช่วยสร้างไฟล์ .gitignore 
สำหรับกรองไฟล์และ folder ที่เราไม่ต้องการออกไป
สำหรับคนที่ใช้ Git จัดการ version ของ source code และเอกสารต่าง ๆ
เห็นว่ามีประโยชน์ เลยนำมาสรุปการใช้งานไว้นิดหน่อย

ปกติในระบบงานใหม่ ๆ หรือ framework ใหม่ ๆ

มักจะมีไฟล์ .gitignore มาให้ตั้งแต่สร้าง project กันแล้ว
ยกตัวอย่างเช่นพวก React, Angular และ SpringBoot เป็นต้น
แต่ถ้าไม่ทำการสร้างให้ เราจำเป็นต้องสร้างเอง
หรือไม่ก็ไป copy มาจาก project อื่น ๆ
หรืออาจจะเข้าไป copy มาจาก GitIgnore template ใน GitHub

แต่พอมาเห็น gitignore.io ก็ทำให้การใช้งานง่ายขึ้น

เพียงแค่เข้าไปหน้า web
จากนั้นก็ค้นหาภาษา program หรือ framework หรือ framework ที่เราใช้งาน
จะได้ข้อมูลในไฟล์ .gitignore มาให้เลย

แต่ถ้าไม่ชอบก็มี commad line ให้ใช้อีก
ก็คือ การเรียกใช้งาน RESTful API ผ่าน curl นี่แหละ
ก็ถือว่าสะดวกดี หรือไปใช้ client library ของภาษาต่าง ๆ ก็มีอีก ไปใช้กัน

แต่ถ้าใครสนใจจะไปตั้ง Server สำหรับทำเรื่องนี้เอง
ก็สามารถทำได้อีก

สุดท้ายแล้ว project นี้ พัฒนาด้วยภาษา Swift
ด้วย framework ชื่อว่า Vapor
ใครสนใจ source code ไปดูกันได้

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

เห็นทาง Google Cloud ประกาศออกมาว่า
ในตอนนี้ได้ปล่อย Plugin Jenkins สำหรับ deploy ระบบงานบน GKE  มาแล้ว
ทำให้เราสามารถกำหนดขั้นตอนการ deploy workload หรือระบบงานของเรา
ไปยัง Kubernetes cluster ใน GKE ได้สะดวกขึ้น
หลังอ่านเอกสารแล้ว เรามาลองใช้กันหน่อยดีกว่า

เริ่มด้วยการสร้าง GKE cluster ก่อน ไว้สำหรับ deploy ระบบงาน

ต่อมาทำการติดตั้ง plugin ของ GKE ใน Jenkins

โดยที่เราสามารถติดตั้งใน GKE cluster ก็ได้นะ
ดูเอกสารการใช้งานเพิ่มเติมได้ที่ Tutorial :: Jenkins in GKE

แต่ในตัวอย่างนี้จะทำการติดตั้ง Jenkins บนเครื่อง local หรือ server ชุดอื่น
จากนั้นเข้าไปติดตั้ง plugin ในส่วนของ Jenkins -> Plugin manager ดังนี้

ปล. Plugin ตัวนี้ใช้ได้บน Jenkins 2.164.2 ขึ้นไปเท่านั้น
และมี dependency plugin ต่าง ๆ ดังนี้

• WMI Windows Agents
• OAuth Credentials
• Google OAuth Credentials

ติดตั้งแล้วยังใช้ไม่ได้นะ ต้องทำการ Enable APIs และสร้าง IAM credential ใน Google Cloud ก่อน

มันไม่ได้ง่ายแบบข่าวหรอกนะ แน่นอนว่ามีขั้นตอนการติดตั้งที่ Documentation

การใช้งานบน Jenkins ทำได้ 2 แบบคือ

1. Freestyle project
2. Pipeline

มาดูแบบแรกใช้งาน Freestyle project พอละ

สามารถเพิ่มการ deploy ไปยัง GKE cluster ด้วย
การเพิ่มในส่วนของการ build ดังรูป

จากนั้นทำการ config ค่าต่าง ๆ ดังนี้

• Service Account Credentials
• Project ID
• Cluster
• Namespace
• Kubernetes Manifests คือ path ที่เก็บไฟล์ YAML ของการ deploy นั่นเอง

ตัวอย่างทำการ deploy services ก่อน
จากนั้นจึงทำการ deploy พวก deployment/pods ต่าง ๆ

เท่านี้ก็เรียบร้อยของการเริ่มต้น
ที่เหลือก็เขียนขั้นตอนการ deploy สิรออะไร
ลองไปตรวจสอบผลการ deploy บน GKE cluster แสดงผลดังนี้

และ services ของ frontend และ backend 

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

ตัวอย่างของไฟล์ deploy อยู่ที่ GitHub

นั่งดู VDO จาก session ต่าง ๆ ของงาน WWDC 2019 มันเยอะมาก
หนึ่งในนั้นมี session ที่ชอบมาก ๆ ซึ่งคิดว่ามันคือพื้นฐานของการพัฒนามาก ๆ 
นั่นก็คือ Great Developer Habits สำหรับการพัฒนาระบบงาน
โดยเฉพาะ iOS Developer นั่นเอง
มาดูกันว่ามีอะไรบ้าง

ใน session นี้แบ่งออกเป็น 8 เรื่อง

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

1. Organize 
2. Track
3. Document
4. Test
5. Analyze
6. Evaluate
7. Decouple
8. Manage

ในแต่ละเรื่องนั้น จะยกตัวอย่างจากพัฒนา iOS app
แน่นอนว่าเน้นไปที่ XCode นั่นเอง
ผมคิดว่าเป็น VDO ที่ iOS Developer น่าจะต้องดู
และลองตรวจสอบดูว่า
เราได้ทำตามนี้หรือใช้งานหรือไม่ ?

1. Organize

ว่าด้วยเรื่องการจัดการ project และ workspace ใน XCode ให้ดี
รวมถึงเรื่องโครงสร้าง project ใน XCode
ให้ใช้งาน group ใน XCode สำหรับจัดการ
ที่สำคัญโครงสร้างใน XCode ต้องเหมือนกับโครงสร้างใน file system ที่จัดเก็บด้วย
ไม่ใช่แค่การ reference ใน Xcode เท่านั้น

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

การใช้งาน storyboard ก็เช่นกัน
คงไม่มีใครนำ UI ทั้งหมดไว้ใน storyboard เพียงตัวเดียว
แนะนำให้ใช้งาน storyboard reference

รวมถึงให้ไปใช้งาน New Build System

2. Track

ระบบงานที่พัฒนาต้องใช้งาน version control แน่นอน
คงไม่มีใครที่ไม่ได้ใช้
ที่สำคัญ ตอนที่เราสร้าง project ใน XCode นั้น
จะมีให้เราเลือกด้วยว่า จะใช้งาน version control หรือไม่ ?

ในแต่ละ commit นั้น
ต้องมีขนาดเล็ก หรือ การเปลี่ยนแปลงไม่เยอะ
ต้องมีคำอธิบายชัดเจน
เนื่องจากตำอธิบายมันจะช่วยบอกเราว่ามีอะไรเกิดขึ้นมาบ้าง
คงไม่มีเพียงคำว่า Update, Create, Delete, Fixed เท่านั้น 
ซึ่งไม่ได้บอกสิ่งที่มีประโยชน์เลย

3. Document

สิ่งหนึ่งที่ใน session นี้พูดคือ
เพียงเขียน code ให้อธิบายตัวมันเองไม่น่าจะพอ
นักพัฒนาที่ดีควรเขียนเอกสารอธิบายด้วยว่า
Code เหล่านั้นทำงานอย่างไรบ้าง
ทำไม code ชุดนั้นจึงถูกเขียนหรือสร้างขึ้นมา
รวมไปจนถึง API Documentation

4. Test

เรื่องของการเขียน test ยิ่งมีความสำคัญ
เพื่อเป็นการบอกว่า code ที่เขียนขึ้นมาถูกใช้งาน
และยังคงทำงานได้ตามที่เราคาดหวัง
โดยใน session จะพูดถึง unit test เยอะ
ถ้ามีจำนวน test ที่มากพอ
จะมีประโยชน์มาก ๆ สำหรับการทำ regression test
มันช่วยทำให้นักพัฒนาเดินไปข้างหน้าได้อย่างมั่นคง

ที่สำคัญใน XCode ก็สนับสนุนเรื่องนี้อยู่แล้ว ตั้งแต่การสร้าง project เลย
และใน XCode 11 มี feature ช่วยให้การเขียนและจัดการ test ได้ดีขึ้นอีกด้วย

5. Analyze

ใน Xcode นั้นมีเครื่องมือมากมายสำหรับการวิเคราะห์เรื่องต่าง ๆ เช่น

• Network Link Conditioner
• Debug
• Instrument
• Sanitizer
• Checker

6. Evaluate

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

หนึ่งในนั้นคือ การทำ code review
เพื่อช่วยทำให้เข้าใจของการเปลี่ยนแปลงแต่ละอย่าง
ก่อนที่จะทำการ build, test ต่อไป
เป็นสิ่งที่ทีมพัฒนาควรจะต้องทำ
มันคือการเรียนรู้อย่างต่อเนื่องของทีมอีกด้วย

7. Decouple

ในระบบงานหนึ่ง ๆ มักจะมีขนาดใหญ่ขึ้นเรื่อย ๆ
ส่งผลให้การจัดการยากขึ้น
ส่งผลให้การ build ยากและนานขึ้น
ดังนั้นเราควรต้องทำการแยก code ต่าง ๆ ออกจากกัน
ทั้งการใช้งาน package และ framework ทำให้ง่าย
ต่อการ reuse และ shared code กัน

แต่สิ่งที่จำเป็นมาก ๆ 
ถ้าเราแยก code ออกจากกันนั่นก็คือ เอกสารหรือ document ตามข้อ 3 นั่นเอง

8. Manage

การใช้งาน dependency ต่าง ๆ เป็นสิ่งที่มีประโยชน์และขาดไม่ได้เลย
แต่ก่อนจะใช้งานแต่ละ dependency นั้น
คุณควรต้องเข้าใจก่อนว่า ข้างในมันทำงานอย่างไร
ทำงานอย่างไรต่อข้อมูลใน app หรือ device
มันคือเรื่องความปลอดภัยของ app เรามาก ๆ
ยิ่งถ้า dependency นั้น ๆ ไม่ถูก maintain แล้ว จะทำอย่างไร ?
ต้องวางแผนให้ดีอีกด้วย

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

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

เปิดไปเจอเอกสารเรื่อง Payment Request API  จาก w3c
อธิบายว่าเป็นชุดของ API ที่ web browser ใหม่ ๆ จะมีมาโดย default
ช่วยทำให้ร้านค้า online ต่าง ๆ รวมไปถึงระบบ e-commerce
สามารถ integrate เข้ากับ payment หรือการชำระเงินช่องทางต่าง ๆ ได้ง่ายขึ้น
นั่นคือ ขั้นตอนการชำระเงินจากผู้ใช้งานไปยังร้านค้าสะดวกขึ้น

เป้าหมายหลัก ๆ เพื่อความเป็นมาตรฐาน

ในการจ่ายเงินในรูปแบบต่าง ๆ
ลดแนวทางการ implement ที่ต่างกัน นั่นคือลดความผิดพลาดลงไป

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

การใช้งานก็ง่ายมาก ๆ

นั่นคือจะมี PaymentRequest() ให้ใช้งาน โดยใน constructor จะประกอบไปด้วย

• methodData กำหนดช่องทางการชำระเงิน เช่น credit และ debit เป็นต้น
• details กำหนดข้อมูลของการสั่งซื้อ

ปล. API นี้จะทำได้เฉพาะบน HTTPS นะ
แต่มีบาง web browser จะสนับสนุนหมดเลยทั้ง HTTP/HTTPS
ยกตัวอย่างเช่น Google Chrome เป็นต้น

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

มาลองเขียน code กันหน่อย

แสดงผลรายละเอียดการสั่งซื้อดังนี้

จากนั้นทำการเพิ่ม Payment method แสดงดังนี้

จะเห็นได้ว่าช่วยทำให้การ implement ง่ายและสะดวกยิ่งขึ้น !!

ลองไปดูว่า Web browser อะไรสนับสนุนบ้าง ?

จากที่ลอง Google Chrome จะสนับสนุนเลย
ส่วนพวก Firefox ต้องไป enable ใน setting ก่อน
เนื่องจากค่า default จะปิดไว้
ลองดูเพิ่มเติมได้ที่

ลองมาดูกันต่อไปว่า API ตัวนี้จะมีอนาคตอย่างไร ?

Reference Websites

• https://medium.com/better-programming/what-is-the-native-payments-request-api-905c60a996e8
• https://developers.google.com/web/fundamentals/payments/

ว่าง ๆ มาลองเล่น Spring Cloud Gateway กันหน่อย
สายเขียน code เพื่อสร้าง API Gateway กันเองน่าจะชอบ
ซึ่งก่อนหน้านี้คือ Zuul สร้างจาก Netflix
ส่วนตอนนี้ใน Spring Cloud น่าจะเริ่ม migrate project ต่าง ๆ จาก Netflix มากันแล้ว
เนื่องจากเป็น roadmap ที่วางกันไว้นั่นเอง มาเริ่มกันเลย

การทำงานของ Spring Cloud Gateway 

แสดงดังรูป

สังเกตว่ามีส่วนของ filter เอาไว้ทำการกรอง
หรือใส่เงื่อนไขต่าง ๆ ของแต่ละ request ที่ส่งเข้ามา
ก่อนที่จะส่งไปยัง service ปลายทาง

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

โดยทางทีม spring เขียนอธิบายไว้ที่ Blog :: Getting start
สิ่งที่สำคัญคือ 
จำเป็นต้องเขียน code เพื่อเพิ่ม routing และ filter ต่าง ๆ ที่ต้องการเอง !!

คำอธิบาย
ทำการ mapping path /get ไปยัง http://httpbin.org:80
ส่วนของ filter จะเพิ่มข้อมูลใน HTTP Header
ซึ่งใช้งานง่ายกว่า Zuul เยอะเลย !!

แต่ถ้าใครใช้งาน API Gateway หรือ API management แบบ configuration มา
อาจจะไม่ค่อยชอบเท่าไรนะ
แต่ก็เป็นอีกแนวทางหนึ่งของสาย Java หรือ Spring Cloud

อย่าเอาไปเทียบ performance กับ Nginx, Kong, Kragken, Tyk และ LinkreD นะ

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

ลองไปดูเมื่อปีที่แล้ว ก็มีคนทำ performance test ไว้นะ
ซึ่งยังเป็น Spring Cloud Gateway ตัวเก่า

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

จากงาน Android Bangkok Conference 2019 ที่ผ่านมา
มี session อธิบายถึงการทำงานของ Gradle
ซึ่งเป็น build tool ของ Android project 
ไม่ว่าจะเขียนด้วยภาษา Java หรือ Kotlin ก็ตาม
ปัญหาที่ปวดหัวของนักพัฒนาคือ
เวลาในการ build ของ Gradle ที่นานนั่นเอง

ประเด็นหลัก ๆ คือ 

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

1. Initial คือทำการดูว่าจะ build project อะไรบ้าง อย่างไร
2. Configuration คือการดูว่าใน build.gradle นั้นมี plugin และ task อะไรบ้าง
3. Execution ทำการ run ทุก ๆ task ที่เกี่ยวข้อง

ถ้าเป็นแต่ก่อนเราจะใช้งาน profile ใน gradle 

เพื่อดูว่าแต่ละขั้นตอนของการ build เป็นอย่างไร
ยกตัวอย่างเช่น

ผลการทำงานเป็นดังนี้

ตอนนี้ใน gradle ก็มีเพิ่มมาอีกตัวคือ scan

เป็นความสามารถที่มากับ Gradle Enterprise
แต่ใน Gradle community ก็ใช้ได้
ข้อมูลต่าง ๆ จะอยู่ในระบบของ Gradle น่าจะบน Cloud นะ
เพราะว่าหลังจากที่ทำงานเสร็จ เราจะได้ link เพื่อเข้าไปดูผลดังนี้

แสดงผลดังนี้

ดูเป็น Timeline ของแต่ละขั้นตอนได้เลย
ละเอียดมาก ๆ

จาก session นั้นได้แนะนำอีกตัวที่ทำขึ้นมาเองคือ Talaiot

ทำขึ้นมาเพื่อให้ใช้งานได้ง่ายขึ้น
สามารถดูรายละเอียดได้ชัดเจนขึ้น
ที่สำคัญสามารถเก็บผลต่าง ๆ ไว้ใน Time-serie database ได้อีกด้วย

ผลการทำงานเป็นดังรูป

อีกทั้งยังทำ dependency graph สวย ๆ ให้อีกด้วย น่าลองใช้นะ

ดังนั้นก่อนที่จะปรับปรุงการ build ของ Gradle
ควรเข้าใจการทำงานของมันก่อนนะ

ปัญหาที่เจอ
ต้องการทดสอบการทำงานของ Activity ใน Android project ด้วย Robolectric
แต่ว่า Activity นั้นต้องดึงค่าที่เก็บไว้ใน SharedPreference เพื่อนำมาใช้งาน
ดังนั้นจะทำการกำหนดค่าใน SharedPreference อย่างไร ?

วิธีการแก้ไขปัญหา

คำอธิบาย

• ทำการสร้าง SharedPreference ด้วย Robolectric.RuntimeEnvironment.application
• ถ้าใน androidx จะต้องไปใช้ ApplicationProvider.getApplicationContext
• จากนั้นทำกาบันทึกข้อมูลที่ต้องการลงไป
• ทำการเปิด Activity ที่ต้องการ
• จบการทำงาน

เพิ่งเห็นว่ามีการปล่อย Wails ใน version beta
เป็น framework สำหรับสร้าง Desktop application
ด้วยภาษา Go และ web technology ต่าง ๆ ได้เลย
ที่สำคัญสิ่งที่ได้ออกมาคือ ระบบงานที่อยู่ในไฟล์ binary เดียวเท่านั้น
ดังนั้นลองมาทำความรู้จักกันหน่อย

ก่อนอื่นทำการติดตั้ง

ทำการสร้าง project เล่น ๆ ชื่อว่า hello

มีให้เราเลือกด้วยว่า จะพัฒนาฝั่ง frontend ด้วยอะไรทั้ง

• Angular
• React
• Vue

โครงสร้างของ project เป็นดังนี้

จะเห็นได้มามี Go และ folder frontend ให้

ที่สำคัญ Wails จะสร้างไฟล์ binary ของ project ให้ชื่อว่า hello
ตามที่กำหนดในการสร้าง project นั่นเอง
เอาไปใช้งานได้เลย ดังนั้นลอง run ดูหน่อย แสดงผลดังนี้

มีคำสั่งอื่น ๆ ให้ใช้งาน เหมือนกับการพัฒนา frontend ทั่วไปเลย

หลังจากติดตั้งและใช้งานกันแล้ว มาดูแนวคิดของ Wails กัน

แนวคิดหลัก ๆ คือ ส่วนของ frontend นั้น
จะใช้แนวคิดการ binding และ  Event ไปยังฝั่ง backend ที่พัฒนาด้วยภาษา Go
โดยที่ Wails จะเตรียมระบบการจัดการ Event ที่คล้ายกับ Event ใน Native JavaScript
นั่นหมายความว่า
ทั้งสองฝั่งสามารถติดต่อสื่อสารกันผ่าน Event นี้ได้เลย

ตัวอย่างของ backend พัฒนาด้วยภาษา Go

ฝั่ง frontend พัฒนาด้วย Vue
ทาง Wails จะสร้าง bridge ไว้ให้
เพื่อรับ event จากผู้ใช้งาน และ binding กับฝั่ง backend

ลองเล่นดูแล้วน่าสนใจดีนะครับ
ใครว่าง ๆ ลองเล่นกันดู
ตอนนี้ยังอยู่ในสถานะ beta น่าจะมีการปรับเปลี่ยนอีกเยอะ

เช้านี้นั่งอ่านบทความเรื่อง Scaling Appsec at Netflix
เป็นอีกเรื่องที่สำคัญใน application ต่าง ๆ ของบริษัท
หน้าที่หลัก ๆ ของเหล่า engineer คือสร้าง product ที่มีคุณค่าต่อลูกค้า
แต่ถ้า application เหล่านั้นไม่ปลอดภัย
ก็น่าจะเป็นปัญหาใหญ่ที่กระทบต่อ business ของบริษัทได้
ดังนั้นทาง Netflix จึงพยายามจัดการเรื่องนี้ให้ดี

โดยที่ทาง Netflix นั้นขึ้นชื่อเรื่องของ

• Context not Control
• Freedom and responsibility

เห็นได้จาก technology ที่หลากหลาย
ขนาดและจำนวนของทีมที่โตอย่างมาก
ดังนั้นการจัดการเรื่องของ security จึงไม่ง่ายเลย
มาดูกันว่า เขาทำอย่างไรกันบ้าง

ในบทความข้างต้น อธิบายว่าจะมี 3 ส่วนสำหรับเรื่อง security คือ

1. Operational Appsec capabilities
2. Appsec Automation
3. Security Partnerships

มาดูรายละเอียดกัน

1. Operational Appsec capabilities

ในส่วนนี้ยังคงเป็นทีมและขั้นตอนการจัดการ security แบบเดิม เช่น

• bug bounty triage
• pentesting
• threat modeling
• vulnerability management
• product security incident response

ซึ่งมีคุณค่าและประโยชน์แน่นอน
แต่ก็มีข้อเสียตรงที่มักไปขัดจังหวะการทำงานของทีมพัฒนา application
ส่งผลต่อการ scale ของทีมและ product อย่างมาก

ดังนั้นจึงทำการสร้างอีก 2 ทีมขึ้นมา
เพื่อช่วยแก้ไขปัญหาต่าง ๆ จากการขยายทีม คือ 
Security Partnerships และ Appsec Automation
โดยที่ทีม Operational Appsec จะทำการร่วมกับ 2 ทีมนี้
เหมือนทีม Operational Appsec เป็นทีมช่วยเหลือและให้คำปรึกษา

2. Appsec Automation

มีเป้าหมายและหน้าที่เพื่อเตรียม guildline ต่าง ๆ
เรื่องการจัดการด้าน security ให้ทีมพัฒนา
ทั้งเรื่องการจัดการปัญหาว่าทำอย่างไร
ทั้งเรื่องของ self-service ต่าง ๆ ที่ทำได้เอง
ทำให้ทุก ๆ การกระทำของทีมพัฒนายังคงมีความปลอดภัยเสมอ (Secure by default)
โดยทีมนี้พยายามจะสร้างและเตรียมเครื่องมือไว้ให้ใช้งาน

ยกตัวอย่างเช่น Spinnaker 
เป็น Continuous Delivery platform 
ช่วยให้ทีมพัฒนาสามารถส่งมอบ product ได้อย่างรวดเร็ว
โดยที่ไม่ต้องมาจัดการ resource ต่าง ๆ ที่ใช้งานเอง
แน่นอนว่า เรื่องการจัดการด้าน security ก็เช่นกัน
ไม่ต้องมาจัดการเองทั้ง authentication, authorization และ secret storage เป็นต้น
ซึ่งช่วยจัดการและลดความเสี่ยงไปได้อย่างมาก

โดยก่อนหน้านี้จะลงทุนด้านการทำ Security scan แบบอัตโนมัติ
ในขั้นตอนต่าง ๆ ของการพัฒนา หรือเรียกว่า DevSecOps เช่น

• Static code scanning
• Dynamic testing
• ค้นหารูปแบบต่าง ๆ ที่ผิดปกติใน code และ configuration ต่าง ๆ

เป็นการทำงานในแต่ละ application ไม่ตอบโจทย์ของการขยายทีม
จึงทำการปรับเปลี่ยนมาเป็น The Security Paved Road Practice
เพื่อช่วยให้ระบบ automation ปัจจุบันมีความสามารถในการจัดการด้าน security ดีขึ้น

3. Security Partnerships

การจัดการความปลอดภัยเชิงลึกนั้น
แน่นอนว่าเป็นเรื่องที่ไม่ง่ายเลย
ดังนั้นการมี partnership จึงเป็นสิ่งที่สำคัญมาก ๆ
ซึ่งในบทความก็ได้อธิบายว่า นี่คือการปรับปรุงในอนาคตต่อไป

นี่น่าจะเป็นหนึ่งในแนวทางของการจัดการด้าน security ของ application
มีเป้าหมายเพื่อให้แต่ละ application มี security by default
โดยระบบ ขั้นตอนและเครื่องมือที่สร้างขึ้นมานั้น
ต้องมีประโยชน์ต่อทีม application และ business
รวมทั้งต้องมีความ transparency อีกด้วย
จะได้ช่วยให้เห็นข้อมูล ปัญหาและแนวทางการแก้ไขต่อไป

มีโอกาสไปสอนและแบ่งปันเกี่ยวกับการเขียนภาษา Java ขั้นพื้นฐานมา 6 วัน
มีหลายเรื่องที่น่าสนใจ  สำหรับ feature ใหม่ ๆ ของภาษา Java (Modern Java)
เลยทำการสรุปไว้กันลืมนิดหน่อย

ภาษา Java เป็นภาษาที่น่าจะเก่าแล้ว

แต่ก็ยังมีการ update และออก version ใหม่ ๆ กันอยู่
โดยปัจจุบันก็วิ่งมาถึง Java 12 และกำหลังจะออก 13 กันแล้ว
แต่จากที่เจอมานั้น หลาย ๆ บริษัทในไทยยังคงใช้งาน Java 8 หรือ 1.8 กันอยู่
หนักกว่านั้นก็ลงไปถึง Java 1.4 ที่ผมเริ่มเขียนเมื่อ 20 ปีที่แล้ว !!

แต่ไม่ว่าด้วยเหตุผลใด ๆ ก็ตาม 

นักพัฒนาภาษา Java ก็ควรที่จะมีความรู้พื้นฐาน
รวมทั้งความสามารถใน version ใหม่ ๆ อีกด้วย
เพื่อทำให้รู้และเข้าใจว่า ทำไมถึงมีความสามารถต่าง ๆ เหล่านั้นขึ้นมา
บางคนอาจจะเรียก Java ใหม่ ๆ ว่า Modern Java
ซึ่งน่าจะหมายถึง Java 8/1.8 ขึ้นมานั่นเอง

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

ถ้าต้องทำการแสดงจำนวนที่เป็นเลขคู่ ไม่น่าจะมีใครเขียน code แบบนี้แล้ว

น่าจะต้องเขียนแบบนี้หรือเปล่า ?

หรือจะเป็นการประกาศตัวแปร ไม่ต้องมากำหนด type แล้วนะ

ใช้ var ไปได้เลย นั่นหมายความว่า
ตัวแปรเหล่านั้นจะมี type ตามค่าแรกที่กำหนดให้นั่นเอง

หรือจะเป็น Switch expression ใน Java 12 ก็ทำให้ code อ่านง่ายขึ้น

หรือถ้าใครคุ้นเคยกับ Promise ใน JavaScript

สำหรับการทำงานแบบ Asynchronous แล้ว
ใน Java ก็มี completableFuture ให้ใช้

อีกทั้งยังมี JShell มาให้ใช้งาน

หรือ feature ใหม่ ๆ ที่อาจจะเพิ่มเข้ามาในอนาคต

ยกตัวอย่างเช่น หนึ่งใน Project Amber
นั่นก็คือ data class and sealed type for Java
บางคนเรียกว่า Record เพราะว่าใช้ keyword ชื่อว่า record นำหน้า class นั่นเอง ดังนี้

หรือแม้กระทั่ง Project Loom

ก็มี feature ใหม่ ๆ ที่น่าสนใจทั้ง

• Fibers (lightweight user-mode threads)
• Delimited continuations
• Tail-call elimination

ดังนั้น น่าจะพอทำให้เห็นว่า Java นั้นก็มีการปรับปรุงและเปลี่ยนแปลงตลอดเวลา

ถึงแม้จะช้าหรือมี drama เยอะหน่อย
แต่ก็ปฏิเสธไม่ได้ว่า ยังคงเป็นภาษาที่หลาย ๆ องค์กรยังใช้งาน (เยอะมาก)
ดังนั้นการเรียนรู้ความสามารถใหม่ ๆ ของภาษาจึงเป็นเรื่องที่จำเป็น

แต่คำถามที่น่าจะต้องตอบกันก่อนคือ
บนเครื่องของนักพัฒนาหรือบน server ใช้ Java version อะไรกันอยู่ ?

จากบทความเรื่อง  Intro Guide to Dockerfile Best Practices
แนะนำการเขียน Dockerfile ที่ถูกต้อง
แน่นอนว่า มันช่วยทำให้เราเข้าใจกลไกการทำงานของมันมากยิ่งขึ้น
โดยที่ Dockerfile มันคือไฟล์ที่ใช้สร้าง Docker image อีกที
หรืออาจจะเรียกว่า คู่มือหรือสูตรของการทำงานอาหาร
แต่อาหารในที่นี่คือ Docker image

ก่อนหน้านี้เรื่องของการเขียน Dockerfile นั้น
ทาง Docker ก็มีในเอกสารมาให้เลยคือ Best practices for writing Dockerfiles
ถ้าจำไม่ผิด มีคนแปลเป็นภาษาไทยเพียบ
ถ้าใครเคยอ่านและเข้าใจ 
จากนั้นก็นำไปใช้ จะชิวมาก ๆ 
เพราะว่าบทความนี้ก็ใช้ความรู้เหล่านี้นั่นเอง

ในบทความนี้แบ่งออกเป็นกลุ่มหลัก ๆ ดังนี้

กลุ่มที่ 1 Incremental build time

ในการพัฒนานั้น เรามักจะมีการเปลี่ยนแปลง Dopckerfile บ่อย ๆ
นั่นหมายความว่า
ถ้าเราไม่เข้าใจกลไกการทำงานแล้ว
อาจจะทำให้ขั้นตอนการ build Docker image จาก Dockerfile ช้ามาก ๆ

ยกตัวอย่างเช่น ทำการลบ Dockerfile ทิ้งแล้วสร้างใหม่
ผลที่ได้คือ ช้ามากมาย

ดังนั้นมาปรับปรุงกัน

เรื่องที่ 1 คือ เรื่องของ caching 

แต่ละบรรทัดของ Dockerfile นั้นคือ 1 layer
ซึ่งแต่ละ layer จะมีการทำ caching ของการ build ไว้ตามลำดับของแต่ละบรรทัด
ดังนั้นถ้าบรรทัดใดทำการแก้ไขแล้ว
Caching การ build ตั้งแต่บรรทัดนั้นไปจนถึงบรรทัดสุดท้ายจะถูกลบไปหมด
นั่นคือ ทำการ build ใหม่นั่นเอง

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

เรื่องที่ 2 การใช้งานคำสั่ง COPY

ต้องทำการ copy เฉพาะสิ่งที่ต้องการใช้เท่านั้น
ไม่ใช่ copy ของที่ไม่จำเป็นเข้าไป
เพราะว่า มันจะส่งผลให้ caching ถูกลบไป
นั่นก็ส่งผลต่อเวลาการ build เช่นกัน
สามารถกรองสิ่งที่ไม่ต้องการด้วยการใช้งาน .dockerignore ได้อีกด้วย

เรื่องที่ 3 การ update หรือ install library ควรอยู่ด้วยกัน

ไม่ควรแยกบรรทัดกัน
เพราะว่า อาจจะทำให้เกิดปัญหาการใช้ library ผิด version หรือไม่ update นั่นเอง
รวมทั้งให้เรื่องนี้อยู่ใน caching ตัวเดียวกัน    

กลุ่มที่ 2 Reduce image size

ลดขนาดของ Docker image เป็นสิ่งที่สำคัญมาก ๆ
ทั้งช่วยลดขนาดของ Disk ที่ใช้จัดเก็บ
ทั้งช่วยเรื่องเวลาในการ deploy ที่รวดเร็วขึ้น
ดังนั้นมาปรับปรุงกัน

เรื่องที่ 1 อะไรที่ไม่จำเป็นก็ไม่ต้องเอาเข้ามา

ยกตัวอย่างเช่นพวก library ต่าง ๆ นั่นเอง
แต่ถ้าต้องการใช้งาน อาจจะติดตั้งภายหลังและลบทิ้งไป

เรื่องที่ 2 ลบพวกไฟล์ และ folder cache ต่าง ๆ จากการติดตั้ง library ต่าง ๆ

รวมทั้งยังสามารถนำ Multi-stage build มาช่วยได้อีก

กลุ่มที่ 3 Maintainability

การดูแลรักษาที่ง่ายขึ้น
เป็นอีกเรื่องที่ไม่ยากต่อการทำและเข้าใจ
แต่มักจะผิดบ่อย ๆ ดังนี้

เรื่องที่ 1 แนะนำให้ใช้ Official Docker image

นั่นหมายความว่า
ก่อนที่จะใช้งาน Docker image อะไรให้ดูว่ามาจาก official website หรือต้นน้ำหรือไม่
เพื่อทำให้เรามั่นใจว่า จะได้รับการดูแลรักษาอย่างดี
สามารถเข้าไปดูได้ใน Docker Hub จะบอกหมดว่าเป็น Image ประเภทไหน

เรื่องที่ 2 กรุณาระบุ tag ของ Docker image ที่จะใช้งาน

แต่ห้ามระบุ tag ชื่อว่า latest นะ
เพราะว่า tag นี้จะเปลี่ยนไปเรื่อย ๆ
มิเช่นนั้นขั้นตอนของการ build จะพังเรื่อย ๆ แบบงง ๆ

เรื่องที่ 3 พยายามเลือก Docker image ที่มีขนาดเล็ก

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

กลุ่มท่ี 4 Reproducibility

Dockerfile นั้นคือคู่มือสำหรับการสร้าง Docker image
ดังนั้นเรื่อง consistency หรือความถูกต้องในทุก ๆ ครั้งที่ทำการสร้าง
หรือสามารถ reproduce Docker image ซ้ำ ๆ ได้อย่างถูกต้อง
ถ้าขาดเครื่องนี้ไป
การใช้งาน docker หรือโลกของ containerization ก็น่าจะไร้ประโยชน์สุด ๆ
ดังนั้นมาทำให้มันทำงานได้ซ้ำ ๆ กัน

เรื่องที่ 1 ทำการ build จาก source code เลย

ไม่ควรทำการ build artifact หรือ software package จากข้างนอก
จากนั้นทำการ copy เข้าไปยัง Docker image อาจจะก่อให้เกิดปัญหาได้
เช่น build ผิด version หรือผิด OS เป็นต้น
ดังนั้นสิ่งที่ควรทำคือ ทำการ copy source code เข้ามา build ใน Dockerfile เลย
ทำให้เราสามารถควบคุมสิ่งแวดล้อมรอบข้างได้เลย
แน่นอนว่า ทำซ้ำได้

เรื่องที่ 2 แยกขั้นตอนของการ download และติดตั้ง dependency/library ออกมา

ปัญหาหลัก ๆ ของการ build Docker image ของระบบงานคือ
การ download และติดตั้ง dependency/library นั่นเอง
ดังนั้นเราควรแยกขั้นตอนนี้ออกมา
เพื่อช่วยให้จัดการเรื่อง caching ได้ดียิ่งขึ้น
นั่นหมายความว่า
ถ้าเราไม่ทำการเปลี่ยนแปลงหรือเพิ่ม dependency/library แล้ว
ขั้นตอนการสร้าง Docker image ก็ควรใช้งาน caching ที่เก็บไว้
ซึ่งมีความสำคัญอย่างมาก

ดังนั้นสิ่งที่ควรคิดคือ
แยกขั้นตอนการติดตั้ง dependency/library 
ออกจากการ build/compile ของระบบงานออกจากกัน

เรื่องที่ 3 แนะนำให้ใช้งาน Multi-stage build เลย

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

เรื่องของ Docker นั้นน่าจะเป็นสิ่งที่ทุกองค์กรต้องมีความรู้อยู่แล้ว
ทำให้ปัญหาที่ตามมาเยอะขึ้นคือ Security หรือความปลอดภัย
แน่นอนว่า 
โลกของ container นั้นยังใหม่
ทำให้มีช่องโหว่ให้โจมตีเยอะเลย
ส่งผลให้เกิดเครื่องมือต่าง ๆ ด้วย security ขึ้นมาเพียบ
หนึ่งในนั้นคือ  Vulnerablecontainers.org

ตัวอย่างของปัญหาเรื่อง  Security ในโลก container

• Blank password for root account
• Unprotected root account

Vulnerablecontainers.org เป็น web ที่ทำการ scan
มากกว่า 1,000 Docker container ที่ได้รับความนิยมจาก Docker Hub
โดยใช้เครื่องมือในการ scan ชื่อว่า Trivy

ข้อมูลที่น่าสนใจคือ
Docker container ที่สร้างมาจาก Official Docker Image กว่า 60%
มีช่องโหว่ให้โจมตี
ลองไปดูผลได้ครับ จะได้ปิดช่องโหว่เหล่านี้ได้ทัน

ทาง Google Cloud เขียนบทความเรื่อง 
To run or not to run a database on Kubernetes: What to consider
ทำการอธิบายแนวทางในการตัดสินใจ
เรื่องของการ deploy Database บน Kubernetes หรือไม่ ?

โดย database นั้นเป็นได้ทั้ง RDBMS และ NoSQL
เป็นแนวทางการ deploy บน Google Cloud ซึ่งมีการ deploy 3 แบบคือ

1. Fully managed databases
2. On VM 
3. On Kubernetes

สรุปการตัดสินใจเป็น Flow chart ดังรูป
น่าจะนำมาใช้ในการตัดสินใจได้ง่ายขึ้น

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

วิธีการแก้ไขก็มีเยอะมากมากทั้ง

• ปรับปรุงระบบที่ทำการทดสอบ
• จัดการโครงสร้างของชุดการทดสอบ
• ทำการทดสอบแบบ parallel และ distributed testing

และอื่น ๆ อีกมากมาย

หนึ่งในวิธีการที่น่าสนใจคือ Distributed testing

นั่นหมายความว่า เราจะต้องสร้าง Google Chrome browser ขึ้นมา
ตามจำนวนที่ต้องการ (session) บนเครื่องใด ๆ ก็ตาม
โดยเราสามารถ
นำ Docker Image ของ Google Chrome จาก browserless มาใช้ได้เลย ดังนี้

จากนั้นเขียน code การ initial session ของ Google Chrome ขึ้นมา

โดยการ connect ไปยัง Google Chrome ที่สร้างขึ้นมา

คำอธิบาย
ทำการเปิด Google Chrome ด้วย user-data-dir
เพื่อบันทึกข้อมูล cookie และข้อมูลต่าง ๆ ไว้
ทำให้ไม่ต้องมา initial ใหม่
ผลที่ตามมาคือ การทำงานจะรวดเร็วขึ้น

จากที่ลองทดสอบนั้น
จากเดิมที่ run ประมาณ 16 วินาที ปรับมาเหลือเพียง 3 วินาที

Source code และการใช้งานอยู่ที่ GitHub::Up1

วันนี้เห็นใน JavaScript Weekly แนะนำ Smashtest มา
เป็นอีกภาษาและเครื่องมือใหม่ ๆ สำหรับ

• การเขียน test case ที่อ่านและเข้าใจได้ง่าย
• การ run test case ได้แบบ parallel ตามต้องการ
• สนับสนุกการทดสอบระบบ Web UI และ APIs
• สนับสนุน browser หลาย ๆ ตัว รวมทั้งผ่าน mobile เพราะว่าใช้งานผ่าน driver ของแต่ละ browser นั่นคือ selenium
• มี report ให้เลย แถมเป็น Live report อีกด้วย

แถมขี้โม้ว่า เร็วมาก ๆ ด้วย ดังนั้นมาลองใช้งานกันดีกว่า

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

จากนั้นทำการเขียน test case ตามรูปแบบของ Smashtest

การทดสอบระบบไหว้ครูคือ Google นั่นเอง
เปิดบน browser Google Chrome และ FireFox
เขียนดังนี้

ทำการ run สิ รออะไร

อย่าลืมกำหนด path ของ browser driver นะ !!

มาดู report กันหน่อย มันหรูหรามาก ๆ 

มาถึงตรงนี้ เป็นเครื่องมือและ framework ที่น่าสนใจ
สำหรับการสร้าง Automation testing
ลองเล่นกันดูครับ