ในตอนนี้ทาง Spring  ได้ปล่อย Spring Boot 2.3.0.M1 ออกมา
มีความสามารถที่น่าสนใจคือ

• สร้าง Docker image ด้วย Cloud Native Buildpacks แล้ว
• ทำการ optimized layer  ต่าง ๆ ใน JAR file เพื่อให้สร้างได้ดีและเร็วขึ้น

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

เริ่มต้นด้วยการใช้งานร่วมกับ Buildpacks

โดยจะเพิ่ม task ใหม่เข้ามาทั้ง Apache Maven และ  Gradle

• Apache maven คือ spring-boot:build-image
• Gradle คือ bootBuildImage

เพื่อให้เราสร้าง Docker image ได้เลย
จะช้าในครั้งแรกเพราะว่า ทำการดึง base image
ชื่อว่า cloudfoundry/run:base-cnb จาก Docker Hub
จากนั้นก็เข้าสู่ขั้นตอนการ build ของ buildpacks
ตัวอย่างของ Apache Maven

เมื่อได้ Docker image มาแล้ว ก็นำไปสร้าง container ต่อได้เลย
น่าจะทำให้ชีวิตง่ายขึ้นเยอะ

แต่ความสามารถนี้ ตอนนี้ยังไม่สนับสนุนบน Windows นะ !!
มาถึงตรงนี้น่าจะเป็นจุดเริ่มต้นที่ดี
ว่าในอนาคตจะเดินไปทิศทางใดบ้าง

ต่อมา ลองสร้าง  Layered JAR กัน

ทำการแก้ไข configuration นิดหน่อย
ตัวอย่างใช้งาน Apache Maven ดังนั้นจึงแก้ไขในไฟล์ pom.xml ดังนี้

จากนั้นทำการสร้างไฟล์ JAR ใหม่ 
ทำการดูได้ด้วยว่า แต่และ layer เป็นอย่างไร รวมทั้ง extract ออกมาได้ดังนี้

เมื่อ extract ออกมาแล้วจะมี folder ต่าง ๆ ออกมาดังนี้

• Dependencies จะเก็บ library ทั้งหมดที่ระบบงานใช้งาน ซึ่งเยอะมาก ๆ ที่สำคัญจะไม่ค่อยเปลี่ยน
• Application จะเก็บ class file ต่าง ๆ ของระบบงานที่เราเขียนขึ้นมา พร้อมทั้ง spring loader

Layer ต่าง ๆ ของไฟล์ JAR แล้ว จะมีทั้งที่เป็น static และ dynamic 
ถ้าเราจัดการดี ๆ แล้ว จะช่วยให้การ build เร็วขึ้นอย่างมาก
และเราสามารถสร้าง Docker image
ด้วยการนำ layer ต่าง ๆ มารวมกันใน Dockerfile ของเราได้เลย
ยกตัวอย่างเช่น

ลองใช้งานดูครับ สะดวกขึ้นเยอะเลย

Reference Websites

• https://spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1
• https://buildpacks.io/

เห็นว่า Angular 9 ใกล้จะปล่อยตัวจริงแล้ว
แน่นอนว่า มีการเปลี่ยนแปลงเยอะพอสมควร
ดังนั้นจึงลองเล่น Angular 9 RC กันไปก่อน
เริ่มด้วยการติดตั้งก็แล้วกัน

การติดตั้งก็ง่ายมาก ๆ คือ

เป็นการติดตั้ง Angular CLI ซึ่งจะสร้าง Angular project ใน version 9.0.0-rc.12

จากนั้นทำการสร้าง project และ run ดังนี้

มีถามเกี่ยวกับ Angular Analytic ด้วย

สวัสดีไปกับ Angular 9 RC 12

เห็นความสามารถใหม่ใน Kubernetes ชื่อว่า Ephemeral Containers
เป็น container ชนิดใหม่ 
ซึ่งเราสามารถสร้างขึ้นมาเพื่อทำงานกับ Pods ที่มีอยู่แล้วได้เลย
ช่วยทำให้เราจัดการได้สะดวกมากยิ่งขึ้น
เลยลองมาเล่นดูหน่อย

Ephemeral Containers มีประโยชน์อะไรบ้าง ?

เราสามารถเข้าไป debug หรือดูสิ่งต่าง ๆ ของ container ที่ตายไปแล้วได้
ซึ่ง kubectl exec ไม่สามารถทำได้
นั่นคือ เราสามารถเข้าไปดูปัญหาต่าง ๆ ที่เกิดขึ้นได้

การใช้งานก็ไม่ยากเท่าไร

ใน Kubernetes 1.16 นั้นยังคง alpha version
ซึ่งความสามารถนี้ปิดไว้ ดังนั้นต้องเปิดใน feature-gate ก่อน

ในการใช้งานเล่น ๆ จะใช้งานผ่าน Kind (Kubernetes in Docker)

เริ่มด้วยการสร้าง cluster ของ Kubernetes ขึ้นมา
แน่นอนว่า ต้องเปิด Ephemeral Containers ใน feature-gate ด้วยดังนี้

จากนั้นทำการสร้าง cluster ด้วย Kind
รวมทั้งอย่าลืมทำการ  update kubectl ด้วยนะ

เมื่อ cluster ถูกสร้างเรียบร้อย ก็ทำการสร้าง Pods และ Ephemeral Containers กัน

เริ่มจากสร้าง pods ของ NGINX ก่อน กำหนดชื่อ container = nginx-demo

และทำการกำหนด config ของ Ephemeral Containers ไว้ดังนี้
ตั้งชื่อว่า debugger

ทำการ deploy ดังนี้

สุดท้ายเข้าใช้งานด้วยคำสั่ง
ซึ่งเข้าไปดู process ต่าง ๆ ของ container ใน Pods ได้เลย

เป็น feature ที่น่าสนใจดีเลย
สามารถไปลองเล่นผ่าน  web ที่ KoadKloud ได้เลย

Reference Websites

• https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190212-ephemeral-containers.md

ในเรื่องของการ scale ระบบนั้น ถือเป็นเรื่องสำคัญ
โดยระบบที่ deploy ด้วย Kubernetes นั้น
สามารถจัดการแบบง่าย ๆ ด้วย Deployment และ ReplicaSet
แต่ก็ยังคงต้องทำแบบ manual

ดังนั้น Kubernetes จึงได้สร้าง Horizontal Pod Autoscaler (HPA) ขึ้นมา
เพื่อช่วยให้การ scale ในระดับ Pod แบบอัตโนมัติได้
โดยค่า default นั้นจะดูค่าจากการใช้งาน resource เช่น CPU เป็นต้น
รวมทั้งยังใช้งานยากพอสมควร

ถ้าสามารถทำการ custom ได้ รวมทั้งทำงานร่วมกับ metric อื่น ๆ ได้ 
น่าจะดีและมีประโยชน์กว่า
นั่นจึงเป็นที่มาของ Kubernetes Event Driven Autoscaling  (KEDA)

โดยที่ Kubernetes Event Driven Autoscaling  (KEDA) นั้น

เป็น opensource project ซึ่งสามารถทำงานร่วมกับ HPA ได้เลย
เราสามารถกำหนดและจัดเก็บ metric ในระดับ application
มาใช้สำหรับพิจารณาการ scale ระบบได้แบบง่าย ๆ

โครงสร้างของ KEDA แสดงดังรูป

สังเกตได้ว่า KEDA นั้นจะทำงานเหมือนกับ Metric server นั่นเอง
โดยที่เราสามารถสร้างและจัดเก็บ metric ของ application
เข้าไปได้จาก External trigger source
และเมื่อข้อมูล metric ใน KEDA เข้ารูปแบบที่กำหนด
ก็จะสั่งให้ HPA ทำงานตามที่ต้องการได้

ดังนั้นเพื่อความเข้าใจ จึงทำการสร้างระบบงานง่าย ๆ

โดยจัดเก็บ metric ของระบบงานไว้ใน Prometheus
ตามจริง KEDA นั้นสนับสนุนทั้ง Redis, Kafka และ RabbitMQ อีกด้วย
แสดงดังรูป

มาเริ่มพัฒนาและใช้งานกัน

ขั้นตอนที่ 1 พัฒนาระบบงาน

ทำการเก็บข้อมูลการใช้งานของระบบงานไว้ใน Prometheus
ก่อนอื่นทำการตั้งโจทย์ว่า
จะทำการเก็บจำนวน request ทั้งหมดของการใช้งาน endpoint ที่ต้องการ
ซึ่งทำการสร้าง  custom metric ชื่อว่า http_requests ขึ้นมา 
ในรูปแบบของ Prometheus ดังนี้

ขั้นตอนที่ 2 การ deploy ระบบงาน และ prometheus บน Kubernetes cluster

แต่ตัวที่สำคัญคือ การ deploy KEDA  เพื่อทำงานร่วมกับ Prometheus
โดยทำการสร้าง resource ชื่อว่า ScaledObject
เป็น custom resource (CRD) ของ KEDA นั่นเอง
เพื่อกำหนดการ scale ของ HPA ตามเงื่อนไขที่เราต้องการ
จากค่าตัวเลขหรือ metric ที่ทำการจัดเก็บไว้    

เช่น ใน 1 นาทีล่าสุดถ้ามี request เข้ามาเกิน 5 request จะเริ่มทำการ scale
คำนวณง่าย ๆ คือ
ถ้ามีค่าเกิน 5 มาเช่น  15 จะทำการ scale Pod มาเพิ่มเป็น 3 (15/5)
แน่นอนว่า เราสามารถกำหนดจำนวนของ Pods ได้เอง

ทำการติดตั้งดังนี้

ขั้นตอนที่ 3 ทดสอบการ scale ด้วยการยิง load test นิดหน่อย

ผลที่ได้คือ ทำการสร้าง Pod ให้ตามที่เรากำหนดไว้เลย
ซึ่งกำหนดไว้สูงสุดที่ 10 Pods แสดงดังรูป

ดู event log ได้ดังนี้

แต่เมื่อหยุดการยิง load test แล้วไปเกิน 1 นาทีแล้ว
พบว่า จำนวน Pod จะลดลงเรื่อย ๆ ไปจนถึง 1 ตามค่า min Pod ที่กำหนดไว้นั่นเอง
แสดงดังรูป

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

Reference Websites

• https://github.com/kedacore/keda
• https://itnext.io/tutorial-auto-scale-your-kubernetes-apps-with-prometheus-and-keda-c6ea460e4642

คำถามที่น่าสนใจเกี่ยวกับ go command ของภาษา Go คือ
มีอะไรให้ใช้บ้าง ?

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

เริ่มจากคำสั่งทั่วไป ใช้บ่อย ๆ

$go env สำหรับการดู  environment variable ต่าง ๆ ของ Go
เราสามารถดูเป็นตัว ๆ ได้ เช่น $go env GOPATH GOARCH

ถ้าอยากรู้ว่าใช้อย่างไรก็ใช้ $go help env จากนั้นก็อ่านให้เข้าใจ และทำตาม
สายอ่าน document ก็ต้อง $go doc นะสิ พลาดไม่ได้

กลุ่มที่สองคือ ใช้ในการพัฒนา

มีให้เยอะมาก ๆ เรียงลำดับดังนี้

• สร้าง project ด้วย $go mod init ตามด้วยชื่อ module
• ส่วน $go get สำหรับ download dependency ต่าง ๆ ที่ต้องใช้งาน คงไม่ค่อยได้ใช้แล้ว ถ้ามช้ Go module
• ทำการ clear cache ต่าง ๆ ที่ผ่าน Go module ด้วย $go clean -modcache
• ทำการจัดการ format ของ code ด้วย $go fmt ในการทำงานจริงเอาไปใส่ใน git hook  ก่อนการ commit ไว้เลยนะ ง่ายสุด ๆ
• เรื่องของการตรวจสอบรูปแบบ  หรือ style การเขียนก็ใช้ $golint ไป
• ตรวจสอบ static code analysis ด้วย $go vet
• พวก dependency ที่ไม่ใช้งานก็ $go mod tidy ไปด้วย มันเปลือง อ้อ เพื่อความมั่นใจก็ $go mod verify สำหรับคนที่ใช้  Go module นะ ใครบ้างละที่ไม่ใช้ ใช้หมดนั่นแหละ
• จากนั้นก็ลอง run ด้วย $go run
• แต่ถ้างานจริง ๆ เราก็ต้อง build ออกมาเป็น binary file ตามแต่ละ OS สิ ด้วย $go build
• ถ้าใครไม่รู้ว่า Go สนับสนุน  OS และ Architecture อะไรบ้าง ให้ใช้ $go tool dist list

กลุ่มที่สาม ใช้ในการทดสอบ

เขียนภาษา Go แล้ว ไม่เขียน test นี่บาปมาก ๆ ว่าป่ะ !!

เริ่มด้วย $go test ./.. นั่นเอง
หรือเพิ่ม flag เกี่ยวกับ rece condition detector หน่อย $go test -race

เนื่องจาก $go test นั้นจะทำการสร้าง  cached file ขึ้นมา
เพื่อปรับปรุงความเร็วของการทดสอบ
ดังนั้นถ้าต้องการ clear cache เหล่านี้ก็ใช้คำสั่ง $go clean -testcache

ถ้าทดสอบแล้วเกิดไม่ผ่าน อยากให้หยุดการทดสอบ ก็ใช้ failfast คือ $go test -failfast

อยากดู code/test coverage ก็ $go test -cover
แน่นอนว่า code coverage สามารถนำมาสร้าง report ไฟล์ html ได้
ด้วย $go tool cover

ยังมีอีกกลุ่ม แต่จะลึกหน่อยคือ พวก profiling tool ต่าง ๆ 

เช่น 

• pprof ใช้งานผ่าน $go tool pprof
• Trace ใช้งานผ่าย $go tool trace

เท่าที่เคยใช้ก็มีเท่านี้แหละครับ สำหรับมือใหม่

แต่ตามจริงมันมีอีกเยอะนะ
ลองไปใช้ดูกัน $go help
โดยที่ภาษา Go เขาเตรียมมาให้เยอะและครบเครื่องจริง ๆ นะ

จากคำถามในกลุ่ม QA and Tester Thailand
ว่าด้วยเรื่อง การทดสอบ API และส่งผลการทดสอบไปยังช่องทางต่าง ๆ
เช่น Slack และ LINE เป็นต้น
ซึ่งจะพบว่าคำถามนี้ สามารถแยกออกได้เป็น 2 งานใหญ่ ๆ คือ

1. การทดสอบ API
2. การส่งผลการทดสอบไปยังช่องทางต่าง ๆ ที่ต้องการ

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

เริ่มจากเรื่องแรกคือ การทดสอบ API

ตรงนี้ก็แล้วแต่ใครจะใช้เครื่องมือหรือ framework หรือ library อะไรก็ได้
ที่มันคุ้นชิน คุ้นมือก่อน จากนั้นค่อยไปใช้สิ่งที่มีประสิทธิภาพสูงขึ้น
เพื่อให้เราได้รับ feedback ที่เร็วและมีคุณภาพ

สิ่งที่เลือกใช้คือ Postman ก็แล้วกัน ง่ายดี มีในเครื่องด้วย
จากนั้นทำการ export collection ออกมาในรูปแบบของ JSON
สามารถทำการ run ไฟล์ที่ export ออกมาด้วย newman
อย่าลืมเขียน test ใน Postman ด้วยละ 

ทำให้เรา run test ที่สร้างด้วย Postman ใน command line ได้
เพื่อให้เราสามารถทำงานแบบอัตโนมัติได้ชิว ๆ มากขึ้น
ใครไม่เคยใช้ ใช้ซะ
รวมทั้งสามารถกำหนดให้ report จากการ run อยู่ในรูปแบบที่เราต้องการ
ทั้ง cli, json, junit และ html เป็นต้น

เมื่อทำการ run test และได้ผลการทดสอบแล้ว ก็ทำการส่งผลไปยังช่องทางต่าง ๆ

เอาง่าย ๆ ก็ Slack นี่แหละ เพราะว่าผมใช้งานทุกวัน
โดยที่ Slack อนุญาตให้เราสามารถสร้าง App ได้
เราก็สร้าง  App ขึ้นมา
จากนั้นก็เพิ่ม Webhook ให้ซะ (Enable  incomming webhook)
เพื่อส่งผลการทดสอบไปยัง Slack ของทีมไงละ

เมื่อทำการเปิดเราก็จะได้ URL ของ webhook
เพียงเท่านี้เราก็สามารถส่งผลการทดสอบไปยัง Slack ได้แล้ว
อย่าลืมทดสอบส่งก่อนละ !!

ถ้ามาถึงตรงนี้ แสดงว่างาน 2 งานที่เราแยกทำนั้น เป็นอันเรียบร้อยแล้ว

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

เพียงเท่านี้ก็ใช้งานแบบง่าย ๆ ได้แล้ว

ต่อจากนี้ก็ไปกำหนดการทำงานต่อว่า
จะให้ run ไฟล์นี้เมื่อใดก็เท่านั้นเอง
หรือบางคนอาจจะบอกว่า ก็ไปสร้างอีก Request ใน Postman
แล้วบันทึกใน collection เดียวกันสิ ดีกว่าไหม
ก็ได้นะ แล้วแต่จินตนาการได้เลย

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

จากหนังสือ Monolith to Microservices นั้น
มีเรื่องเล็ก ๆ อธิบายเรื่อง Reuse ? หรือแปลว่า การใช้ซำ้

เราใช้ซ้ำเมื่อใด และเมื่อใดเราถึงใช้ซ้ำ
และเราสร้างส่วนที่ใช้ซ้ำตอนไหน ?

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

การ reuse นั้น เกิดจากความเชื่อ ความหวังที่ว่า

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

ลองกลับมาที่เป้าหมายกันก่อน

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

มาดูตัวอย่างของการ reuse กันบ้าง

ในกรณีที่เรามี Customer service เพื่อจัดการเกี่ยวกับ customer
ซึ่งต้องการสร้าง report ในรูปแบบของ PDF
แน่นอนว่าในระบบงานของเราก็มี  Report service ให้ใช้งานอยู่แล้ว
เพียงแค่เราต้องไปติดต่อทีมที่ดูและ Report team 
เพื่อให้สร้าง report ตามที่เราต้องการเท่านั้นเอง

ปัญหาที่มักตามมาคืออะไร ?

Customer service นั้นจะต้องยก logic ของการออก report ไปให้ Report service
ดังนั้น ถ้าจะทำอะไร ก็ต้องติดต่อและพูดคุยกับทีม Report service เสมอ
ที่น่าสนใจคือ
ใคร ๆ ก็ใช้ Report service
ดังนั้นตารางงานของทีมนี้ก็ยุ่ง
ไม่ค่อยเป็นไปตาม timeline ของ Customer service
มันคือปัญหาของ coordination กันไหมนะ ?
มันทำให้เราพัฒนาและส่งมอบงานได้เร็วจริงตามเป้าหมายหรือไม่นะ ?
ลดค่าใช้จ่ายจริง ๆ ไหมนะ 
ทั้งเวลาติดต่อ 
ทั้งเวลาที่รอ 
ทั้งเวลาที่ integrate กัน 
ทั้งการแก้ไข ที่กระทบไหมนะ
มันคือค่าใช้จ่ายที่สูงทั้งหมดไหมนะ

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

ดังนั้นถ้าเรากำลังสนใจเรื่องของการพัฒนาและส่งมอบที่รวดเร็วขึ้น

น่าจะเอางานส่วนของ PDF report มาทำเองใน Customer service เลยดีไหม
แต่ถ้าสนใจเรื่องของ reuse ก็เอาไปไว้ใน Report service เช่นเดิม !!

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

อ้างอิงจาก SOA Manifesto ก็น่าสนใจ

การใช้ VSCode สำหรับพัฒนา software นั้น
ถ้าใครจัดการ version ของ source code ด้วย git
นักพัฒนาทุกคนไม่น่าพลาดกับการติดตั้ง extension ชื่อว่า GitLens

มีความสามารถที่โดนใจหลาย ๆ อย่าง
ทั้งดู history ของการแก้ไขแต่ละบรรทัดหรือแต่ละไฟล์
แถมดูความเปลี่ยนแปลงได้เลย (diff)
อีกทั้งยังเปรียบเทียบในแต่ละ branch ได้อีก
คิดว่าไม่น่ามีใครพลาดที่จะไม่ติดตั้ง extension นี้นะ
ใครยังไม่ติดตั้ง ติดตั้งซะ แล้วใช้งานกัน

Extension ดี ๆ จึงมาบอก ใช้ซะ

ทางทีมพัฒนา Cypress ได้ปล่อย  version 4.0.0 ออกมาแล้ว
โดยความสามารถที่คนใช้งานเฝ้ารอก็ออกมาแล้วคือ
สนับสนุนทั้ง Firefox
และ Microsoft Edge (Chromium based) บน Windows OS เท่านั้นนะ
มาลองใช้งานกันหน่อย

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

เปิดขึ้นมาด้วยคำสั่ง $npx cypress run เจอ error เลย

แสดงดังรูป

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

ต่อมา cypress บน MacOS นั้น จะมีเพียง Firefox เพิ่มเข้ามาเท่านั้น

ส่วน Microsoft Edge จะมีบน Windows OS เท่านั้น
แสดงดังรูป

บน Windows OS

ลองทดสอบด้วย Firefox  กันนิดหน่อย

จากนั้นทำการ run แบบจริง ๆ จังหน่อย

พบว่าทำงานเหมือนกับ Google Chrome เลย
แน่นอนว่า มีการบันทึกผลการทดสอบเป็น VDO ให้ด้วยนะ สบาย ๆ เลย

ส่วนสาย Docker ก็มี Docker image มาให้เลย

แต่มีเพิ่เข้ามาแต่ Firefox นะ
ไปใช้งานที่นี่เลย Cypress Docker Image

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

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

โดยการแก้ไขนั้นประกอบไปด้วย

• ไม่สามารถ detect พวก Microsoft Edge (Chromium based) ใน MacOS ได้
• มีปัญหากับการ Firefox Nightly build ใน MacOS
• ปัญหาต่าง ๆ เกี่ยวกับ Firefox ทั้งเช่นการบันทึก VDO เป็นต้น

แก้ไขเร็วแบบนี้ สบายใจได้เลยสำหรับคนใช้งาน

นั่งดูข้อมูลรายงานจาก HackerRank Developer Skills Report 2020
มีผลการสำรวจในหลาย ๆ มุมมองที่น่าสนใจ เกี่ยวกับการพัฒนา software
แบ่งออกเป็น 3 ส่วนคือ

1. Learning
2. Skills
3. Tools

มาดูกันว่าเป็นอย่างไรบ้าง ?

แต่ละคนเรียนรู้และพัฒนาความสามารถในการ coding อย่างไร ?

โดยแบ่งออกตาม generation ของกลุ่มคน
พบว่าการเรียนรู้ก็แตกต่างกัน
ยกตัวอย่างเช่น
Baby boomer จะเรียนรู้จากหนังสือและ on-the-job training สูงมาก ๆ
ส่วน Gen Z, Millennial นั้นจะเรียนรู็จาก YouTube, Bootcamps, Mentor 

บริษัทขนาดใหญ่ก็ยังรับคนที่จบปริญญาเยอะ

ส่วนบริษัทเล็ก ๆ จะไม่เน้นเรื่องนี้

ภาษาโปรแกรมที่มีความต้องการสูง

ยังคงตามปกติของรายงานอื่น ๆ คือ 

• JavaScript 
• Python
• Java
• C#
• C++
• PHP

ส่วนภาษาโปรแกรมที่นักพัฒนาต้องการเรียนรู้มากที่สุด

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

• Go
• Python
• Kotlin
• TypeScript
• R
• Scala
• Swift
• Rust
• Ruby

ภาษาโปรแกรมที่มีเงินเดือนเพิ่มสูง ๆ

ที่น่าสนใจคือ Perl สูงสุด คนมีอายุเท่านั้นที่จะรู้จัก
ภาษาอื่น ๆ ประกอบไปด้วย

• Scala
• Go
• Ruby
• Objective-C
• Swift
• Pascal

สิ่งที่ professional ควรมีคือ ความสามารถในการเรียนรู้สิ่งใหม่ ๆ

เวลาว่างของนักพัฒนาคืออะไร นอกจากการ coding

สูงสุดคือ การฟังเพลงและเล่น web
อื่น ๆ ประกอบไปด้วย

• กินดื่ม
• พักผ่อน
• ออกกำลังกาย

สามารถ Download ข้อมูลมาวิเคราะห์เองได้ด้วย

• https://www.kaggle.com/fccuser/datasets
• https://research.hackerrank.com/developer-skills/2020

ทางทัม Fabric นั้นได้แจ้งมาว่า
ในวันที่ 31 มีนาคม 2563 นี้จะผิดตัวระบบแล้วนะ
ดังนั้นแนะนำให้ระบบที่ใช้งาน ทำการ migrate ไปยัง Firebase กันเลย
เนื่องจาก product ทุกตัวมีให้ใช้งานบน Firebase หมดแล้ว
ถ้าใครยังไม่ทำการmigrate ก็จัดซะ แต่น่าจะไม่ใช้กันนานแล้วมั้ง !!

มาลองสร้าง Diagram หรือแผนภาพแสดงโครงสร้างของระบบต่าง ๆ
ไม่ว่าระบบทำการ implement บน AWS, Azure, GCP และ Kubernetes นั้น
สามารถสร้างง่าย ๆ ด้วยการเขียน code ภาษา Python
โดยใช้งาน library ชื่อว่า  Diagrams
มาลองใช้งานกัน

ขั้นตอนแรกต้องติดตั้งก่อน

การ render  ของ Diagrams นั้นใช้งาน Graphviz
ดังนั้นต้องทำการติดตั้งก่อน

มาเขียน code นิดหน่อยเพื่อสร้าง Diagram กัน

ทำการ run ด้วย python

จะได้รูปของ diagram ดังรูป

ลองใช้งานดูครับ
อ่านเพิ่มเติมได้ที่ Documentation เลย

ทางทีมของ Microsoft ได้สร้าง Scalar ออกมา
เป็นเครื่องมือเพิ่มเติมของ Git เพื่อจัดการ monorepo ขนาดใหญ่
ด้วย VFS for Git (GVFS)
โดยพัฒนาด้วยภาษา C# โดยใน project นี้มีเป้าหมายเพื่อ

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

ทางทีมพัฒนาได้เขียนอธิบาย
แนวทางการออกแบบและพัฒนา
แนวทางการใช้งาน ไว้ที่ Introducing Scalar: Git at scale for everyone

สามารถเริ่มติดตั้งได้จากที่นี่
พบว่ามีให้ติดตั้งได้เพียงบน Windows และ Mac OS เท่านั้น
ลองใช้งานดูครับ

อ่าน feed ข่าวเจอเรื่อง NODE.JS IS DEAD – LONG LIVE DENO!
เป็นบทความที่ล่อเป้ามาก ๆ 
แต่สิ่งน่าสนใจกว่าคือ 
Deno คืออะไร ?
Deno มีเป้าหมายอย่างไร ?
Deno ต่างกับ Node อย่างไร ?
มาดูกันนิดหน่อย

Deno คืออะไร ?

Deno มาจาก Node หมุนเอา !!
Deno มันคือ runtime ใหม่สำหรับ JavaScript และ TypeScript
สร้างโดยคุณ Ryan Dahl เป็นผู้สร้าง Node.js นั่นเอง
ซึ่งสร้างขึ้นมาเพื่อแก้ไขปัญหาต่าง ๆ ของ Node.js

สามารถดูเพิ่มเติมได้จาก VDO นี้

ปล. ในช่วงแรกของ Deno จะพัฒนาด้วยภาษา Go
แต่ตอนนี้เขียนด้วยภาษา Rust แทนแล้ว
ส่วน Event loop ใช้ Tokio ซึ่งเขียนด้วยภาษา Rust

Deno ต่างกับ Node อย่างไร ?

มีเป้าหมายเดียวกัน แต่ต่างที่วิธีการ
โดยที่ Deno จะใช้ ES module
ส่วน external library/dependency จะใช้งานผ่าน URL เลย
ดังนั้นจึงไม่มี package manager และ centralize registry
ทำให้สามารถใช้งานได้จากที่ที่มี internet

สนับสนุน TypeScript โดย default
ดังนั้นไม่ต้องทำการติดตั้งหรือ config ใด ๆ เพิ่มเติม
รวมทั้งยังมี test runner, code formatter และ bundler มาให้พร้อมเลย
ถือว่าสะดวกขึ้น

สิ่งที่สำคัญมาก ๆ ของ Deno คือ security by design

หมายความว่า code ต่างๆ จะถูก execute ใน sandbox นั่นคือ
runtime จะไม่สามารถ
เข้าถึง file system ได้
เข้าถึงระบบ metwork ได้
ทำการ execute script อื่น ๆ ได้
ไม่สามารถใช้งาน environment variable ได้
ถ้าจะใช้งานต้องได้รับการอนุญาตเสมอนะ

ยกตัวอย่างเช่น ลองสร้าง Web server แบบง่าย ๆ

ทำการ run หน่อย
จะเจอ error เกี่ยวกับ permission ดังนี้

ดังนั้นต้องอนุญาตก่อนดังนี้

น่าสนใจเหมือนกันนะสำหรับ Deno
มาดูกันว่าอนาคตจะเป็นอย่างไรต่อไป ...

เป็นครั้งที่ 3 สำหรับการมาวิ่งงาน Ultra Trail Unseen Kohchang
โดยสองครั้งที่ผ่านมาลงวิ่งระยะ 34 กิโลเมตร
ส่วนครั้งนี้ลองมาลงระยะ 70 กิโลเมตรดูบ้าง 
ว่าจะรอดหรือไม่ ?

มาดูก่อนว่าเส้นทางวิ่งเป็นอย่างไรบ้าง ?

กับความชันสะสม ที่บอกเลยว่า ตัวเลขมันหลอกมาก ๆ ?

ถึงแม้ว่าความชันสะสมจะไม่มากนัก
แต่ของจริงนั้น ขึ้นลงชัดสุด ๆ  ไม่มีลีลาอะไรเลย

มาวิ่งกันดีกว่า เริ่มออกวิ่งวันเสาร์ เวลา 16.00 น.

อากาศกำลังดีเลย ยังไม่วิ่งเหงื่อออกเยอะมาก !!
โดยช่วงแรกจะเป็นการวิ่งบนถนนไปประมาณ 5 กิโลเมตร
ก่อนไปถึง SP 1 สำหรับเติมน้ำ ก่อนขึ้นเขาลูกแรกอันโหดร้าย
ช่วงนี้ก็รีบวิ่งไปกัน ยังมีแรง

จำได้ว่าครั้งที่ผ่านมา ทางขึ้นเขาแคบมาก ๆ แซงไม่ได้ ต้องต่อคิวขึ้นเขา
เลยวิ่งกันเร็วมาก ๆ ก็เลยขอตามตูดแบบไกล ๆ ไปด้วย 
ด้วย pace เฉลี่ยตามรูป วิ่งไปกันได้ไงหว่า ?

หลังจากนั้นก็ขึ้นเขากันเลย

ความสนุกของเขาแรกนั้นคือ
หิน ต้นไม้ขวาง รากไม้ เถาวัลย์ อีกอย่างความดิบของป่า (เหมือนกันทุกเขา !!)
แถมความร้อนจากหินบนภูเขาออกมาเยอะเลย
วิ่งไปเหงื่อไหลเป็นทาง
แต่ยังมีแรงอยู่ก็วิ่ง ๆ เดิน ๆ กระโดดไปเรื่อย ๆ

ความโหดร้ายมันเริ่มจาก SP2 ออกไปหาดหวายแฉกนี่แหละ

ถ้าระยะ 34 กิโลเมตรจะเลี้ยวซ้ายมือ
ส่วน 70 และ 100 กิโลเมตรแล้วขวามือ
แค่เพียงแล้วขวามือเท่านั้น
ปีนเขาชัน ๆ ยาว ๆ ทันที
ช่วงขาปีนขึ้นใช้เวลาเฉลี่ย pace 16-20 กันไปเลย !!

ที่สำคัญยังคงมีความรก รากไม้ เถาวัลย์เช่นเดิม
กว่าจะดันขึ้นไปได้
แถมช่วงขาลงก็ลงกันจริงจังมาก ๆ

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

เดินสลับวิ่งมาจนถึง SP3 ที่หาดหวายแฉก

ได้กินน้ำมะพร้าวหอมหวาน อร่อยมาก ๆ (ไม่เจอ pretty นะ -|-)
ตรงนี้ขอกินแบบไม่ยั้งเลย
กินให้หายอยากไปเลย กับพักเหนื่อยนิดหน่อย
ระยะได้ 20 กิโลเมตร

ก็เริ่มออกวิ่งกลับไปยัง  SP2

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

จำได้ว่าส่วน SP4 นั้นช่วงแรกเป็นสวนยางวิ่งกันชิว

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

เมื่อได้ยินหลาย ๆ คนตะโกนในป่าเมื่อไร
เลยคิดว่าเป็นสัญญาณบอกว่า ถึงยอดแล้วแน่ ๆ แต่ไม่ใช่เลย
กลับบอกมาว่า ยังมีขึ้นต่ออีก เป็นแบบนี้ไปเรื่อย ๆ !!
มีบางช่วง pace 20-30 กันไปเลย
จนไปถึง SP4 ได้ระยะรวมไป 33 กิโลเมตรละ
มีการตรวจอุปกรณ์บังคับด้วยนะ !!

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

ในช่วงไป SP5 นี้ พบว่าเจอเขาสูงและชันมาก ๆ 

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

แต่พอมาถึง SP5 พบว่า นักวิ่งกองกันอยู่ที่นี่เพียบเลย

มีทั้งคนที่ DNF แล้ว ซึ่งคลุมผ้าห่มฉุกเฉินอยู่
มีทั้งคนที่มานั่งพักกาย ทำใจ พักผ่อน นอน เติมพลัง
คนดูแล SP บอกว่า นักวิ่งมาถึงตรงนี้ 77 คนละ

คิดในใจแล้วที่ออกมาพร้อมกัน 200 คน ไปไหนกันหมดละ ?
ตรงนี้เข้าก่อนเวลา cutoff ประมาณ 3-4 ชั่วโมง
ถ้าจำไม่ผิดจะถึง SP นี้ประมาณ  ตี 2-3 แน่นอน
ถามว่าง่วงไหม ตอบเลยว่าไม่เลย กำลังตื่นตัวเลย !!

ก่อนที่จะเข้าป่าไปอีกประมาณ  12  กิโลเมตร (ระยะรวม 52 กิโลเมตร)
เพื่อไปยัง SP ต่อไปที่น้ำตกธารมะยม
ซึ่งเป็น SP ที่นักวิ่งจะไปฝากของไว้
ถือว่าเป็นระยะที่ยาวไกลมาก ๆ

มาถึงตรงนี้ผมก็หาของร้อน ๆ กินหน่อย

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

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

ออกจากป่าตอนเช้าคือ 6 โมงเช้าพอดีเลย

นั่นแสดงว่าช่วงนี้เดินไปประมาณ  3-4 ชั่วโมงนั่นเอง
ช่วงนี้เดินหนักมาก ๆ  ช้ามาก ๆ ไว้ปรับปรุงใหม่
ออกมาเจอวิวแบบนี้

เมื่อเจอแสงแดด อาการง่วงเริ่มมาแล้วสิ
เลยรีบลงเขาเข้าไปยัง SP6 ซึ่งระยะรวมก็มาถึง 51 กิโลเมตรแล้ว

เหลืออีก 20 กิโลเมตร เหมือนจะง่ายแต่ไม่ง่ายเลย แถมตะคริวเหมือนจะมาเยือน !!!

เมื่อเข้า SP6 แล้วก็ทำการเปลี่ยนถุงเท้า
เก็บของที่ไม่จำเป็นสำหรับการวิ่งบนถนนใส่กระเป๋า
เข้าห้องน้ำล้างตัวสักรอบ เพราะว่าอาการง่วงเริ่มมาเยือน
เจอน้ำเย็น ๆ ไปตื่นตัวขึ้นเยอะ
นวดขาที่ตึง ๆ จากบนเขาอีกรอบ
เติมพลังให้เต็ม
จากนั้นออกวิ่งเบา ๆ ตามถนนไปเรื่อย ๆ วิ่งได้ประมาณ  5 กิโลเมตร
แบบชิว ๆ  pace 8-12 ได้

แต่เมื่อต้องเลี้ยวซ้ายขึ้นเขาแถว Flukie's house

คำถามแรกคือ ทำไมต้องเลี้ยวเข้าไปละเนี่ย ?
ก็วิ่งไป ขึ้นเข้านิดหน่อย ไม่มีอะไรมาก
ต้นไม้เยอะ ไม่ค่อยมีทางวิ่งเท่าไร ไม่ค่อยชันเท่าไร

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

จนออกถนนไปเจอ SP7

เพื่อกินข้าวเช้ากัน รวมระยะได้ 61 กิโลเมตร
เหลืออีก 9 กิโลเมตรเท่านั้น (cutoff 4 โมงเย็น โน้น ชิว ๆ)

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

เหลืออีกแค่ 9 กิโลเมตรไปกันต่อเลย

ต้องไป SP8 ก่อน ประมาณ  3 กิโลเมตร เป็นช่วงสั้น ๆ บนถนน
แต่เต็มไปด้วยแสงแดดอันร้อนแรง
เดินอย่างเดียวเลย เป็นการเดินประมาณ pace 10 ได้

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

พอมาถึง SP8 ก็เจอนักวิ่งระยะ 100 กิโลเมตรกำลังเข้าเยอะเหมือนกัน

ส่วนใหญ่ก็มานั่งพัก เติมพลังก่อนวิ่งเข้าป่าอีก 5 กิโลเมตรก่อนเข้าเส้นชัย
ป่าช่วงนี้ไม่ค่อยยากเท่าไร รกหน่อย แต่ไม่ชันมาก
แต่ด้วยที่เป็นช่วงใกล้เที่ยงวันแล้ว ทำให้ไม่ค่อยอยากวิ่งเท่าไร

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

เมื่อออกจากป่าเจอทางโล่ง ๆ เหมือนจะวิ่งได้

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

ในช่วง 5 กิโลสุดท้ายไปเกือบชั่วโมงครึ่ง เดินกันยับเลย !!

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

โดยรวมชอบเลยครับ ต้องฝึกซ้อมให้ดีกว่านี้
คิดว่าน่าจะวิ่งไว้สนุกและดีกว่านี้
เวลารวมทั้งหมดจัดไป 20 ชั่วโมง 15 นาที !!

เช้านี้เจอคำถามที่น่าสนใจจาก StackExchange
เรื่อง Result object vs throwing exceptions
ว่าเราจะเลือกแนวทางใด
สำหรับการส่งผลการทำงานกลับมาจาก function/method/module
ระหว่างส่งผลการทำงานเป็น result object ทั้ง  success และ failure
หรือทำการโยน exception กลับมาถ้าการทำงาน failure
ซึ่งมีคำตอบที่น่าสนใจ น่าคิด

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

ให้ทำการส่งเป็น result object กลับมา สำหรับกรณีต่าง ๆ
ออกมาทั้ง success และ failure
เช่น user valid, password invalid และ user not found เป็นต้น

และให้โยน error และ exception ออกมา
ในกรณีที่ไม่คาดหวังกลับมา
เพื่อบอกหรือแจ้งให้ผู้เรียกรู้
เช่น database connection error, network problem เป็นต้น

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

อีกมุมมองคือ ตามแต่ละวัฒนธรรมของภาษาโปรแกรมและเทคโนโลยีนั้น ๆ

บางภาษาไม่มีการโยน exception ออกมา 
ดังนั้นให้ return error มาทาง return object เช่นภาษา Go

บางภาษาทำการส่งค่ากลับมาผ่าน Out parameter เช่นภาษา C#

บางภาษาทำการโยน error กลับมาเลยเช่น Java

บางภาษาแยก flow การทำงานของ error ออกมาได้เลย เช่น Python

ในฐานะนักพัฒนานั้น คุณเลือกอย่างไร ?

หลังจากที่ JDK 14 RC แรก ๆ ถูกปล่อยออกมาให้ลองทดสอบเล่น ๆ
แน่นอนว่า feature ต่าง ๆ อาจจะมีการเปลี่ยนแปลงอีกเยอะ
แต่ว่าก็มีความสามารถที่น่าสนใจให้เล่นกัน ไม่ว่าจะเป็น

• Switch expression เปิดให้ใช้ได้เลย ออกจาก preview feature แล้วนะ
• การปรับปรุง  error message ของ NullPointerException (NPE) จาก JEP 358
• มี Record มาเป็น preview feature จาก JEP 359

ตัวที่ผมสนใจคือ การปรับปรุง error message ของ NPE

จากที่ลองพบว่า อธิบายปัญหาได้ชัดเจนขึ้นมาก
ยกตัวอย่างเช่น

ทำการ run เพื่อดู error ดังนี้ ดังนี้

ลอง Download มาเล่นกันดูครับ
หรือใช้ผ่าน Docker Image ก็ได้

Reference Websites

• https://www.infoq.com/articles/java-14-feature-spotlight/
• https://medium.com/better-programming/whats-new-in-java-14-a472ec291c05

ปัญหา ต้องทำการเก็บและใช้งาน Go module แบบ private
แน่นอนว่า มีทั้งภายในและภายนอกองค์กร
ปัญหาที่เจอคือ ทำอย่างไรดี ?

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

เนื่องจาก Go นั้น สามารถกำหนด url ของ proxy server สำหรับ Go module ได้
โดยค่า default นั้นจะไปที่ https://proxy.golang.org,direct
แต่เราสามารถกำหนดให้ไปยัง server ของ Git repository ของเราได้
ด้วยการกำหนดค่าผ่าน environment ชื่อว่า GOPRIVATE

จากนั้นก็ให้ส่ง credential หรือพวก token ของ user ใน Git repository ไปด้วย
เพื่อให้สามารถเข้าใช้งานได้นั่นเอง
เพียงเท่านี้ก็สามารถใช้งานได้แล้ว
ยกตัวอย่าง การทำงานด้วย Docker ดังนี้

มีคำถามเกี่ยวกับการสร้าง repositry
สำหรับจัดเก็บชุดการทดสอบ (Automated testing) ว่าควรทำอย่างไรดี
ซึ่งปัจจุบันนั้นมักจะสร้าง repository แยกออกไปจาก source code ของทีมพัฒนา
ด้วยเหตุผลเรื่องความเป็นเจ้าของและง่ายต่อการดูแล
คิดว่ามีปัญหาหรือไม่ ?

ก่อนอื่นต้องกลับมาดูเป้าหมายก่อนว่า เราต้องการอะไร ?

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

ถ้าเราทำการแยกที่จัดเก็บ มันหมายถึงแยกส่วนการทำงานและดูแลหรือไม่
ต่างฝ่ายต่างมี repository ของตนเอง
ดังนั้นการทำงานร่วมกันจะดีไหมนะ ต่างฝ่ายต่างทำแยกกันไป
มันคือการทำงานแบบ silo หรือไม่
ตอบโจทย์หรือเป้าหมายหรือไม่

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

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

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

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

รวมทั้งยังช่วยลดชุดการทดสอบที่ซ้ำซ้อนในแต่ละ test level ได้อีกด้วย
และทั้งทีมพัฒนาและทดสอบ
สามารถนำ code มา run และทดสอบบนเครื่องของเราได้อีกด้วย
ช่วยสร้างความมั่นใจก่อนที่จะ commit และ push การเปลี่ยนแปลงไปยัง repository