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

เริ่มที่การติดตั้งเลย

ติดตั้งผ่าน rustup แบบง่าย ๆ
แถมมี Cargo สำหรับจัดการ dependency ต่าง ๆ ให้ครบ
ที่สำคัญยังทำให้เขียนชุดทดสอบและ benchmark ได้ง่ายอีกด้วย
พร้อมแบบนี้เหมือน go เลย
ดังนั้นติดตั้งและใช้งานกันดีกว่า
ที่สำคัญมีหนังสือให้อ่านฟรี ๆ และ ทำตามกันอีกคือ Rust By Example

ไม่ต้องคิดอะไรมากสำหรับมือใหม่อย่างเรา
สร้าง project ด้วย Cargo ไปเลย

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="1.txt"]

เมื่อสร้างมาแล้วไฟล์คุ้น ๆ มันเหมือนกับ Golang dep เลย
ทำให้เข้าใจโครงสร้างได้ไม่ยาก

ส่วน IDE และ Editor ที่ใช้ก็เลือกเอาตามที่สบายใจ
ทั้ง VS Code, IntelliJ, Sublime, Atom, Vim เป็นต้น

ทาง Rust ยังแนะนำให้ลง component ผ่าน rustup อีก2 ตัวคือ

• Rustfmt สำหรับจัด format ของ code
• Clippy เป็น Lint tool ช่วยตรวจสอบ code

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

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="3.txt"]

หลังจากที่สร้าง project เรียบร้อย ก็มาเริ่มศึกษากัน

แต่การศึกษาภาษา Rust ในแบบผม คือ การทดสอบ
ไปดูเอกสารเรื่อง Automation Testing ได้ 
ดังนั้นมาเริ่มด้วย $cargo test

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="2.txt"]

ก่อนอื่นเลยไปอ่านเอกสารของ Rust ก่อนว่า เขียนชุดการทดสอบอย่างไร ?

ไปพบว่ามีการทดสอบ 3 แบบหลัก ๆ คือ

• Unit test
• Integration test
• Documentation test อารมณ์เดียวกับ Docstring ใน Python เลย

พอจะเริ่มด้วยการเขียน test คำถามแรกเลยโครงสร้าง project ต้องเป็นอย่างไร ?

ไปอ่านเอกสารก็งง ๆ 
ดังนั้นมาเริ่มที่ unit test ก่อนเลย สร้างไฟล์ชื่อว่า hello.rs ขึ้นมา
ในไฟล์นี้มีทั้ง production code และ test code เลย
ปลายทางได้แบบนี้

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="hello.rs"]

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

ต่อมาเรื่องของการตั้งชื่อ function ต้องเป็น sneck case นะ
ส่วนตัวแปรที่เป็น local ให้ขึ้นต้นด้วยเครื่องหมาย underscore (_)
มิเช่นนั้นจะทำการเตือนดังนี้
ชีวิตดีมาก ๆ มีเครื่องมือช่วย

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="4.txt"]

ยังไม่พอนะ function say_hi() ที่อยู่ใน module/package hello นั้น
ต้องเป็น public เพื่อให้เรียกจาก main.rs ได้อีกด้วย
ในภาษา Rust ใช้ตัวย่อว่า pub (มันจะย่อไปไหน ?)

[gist id="23368cc4079f4f499bf34dd8c83436a6" file="main.rs"]

สิ่งที่เขียนมานั้นคือ Unit test นะ

ส่วนการ build ก็เพียง $cargo build

จะได้ ไฟล์ binary มาให้เลย ชิวมาก ๆ
โดยที่ไฟล์ binary อยู่ที่ /target/debug/<project name>

วันนี้เราได้เริ่มหัดเรียนรู้ภาษาใหม่ ๆ กันบ้างหรือยัง ?

มีโอกาสไปร่วมงาน Meetup ของทาง ThoughtWorks Tech Talks ประจำเดือนมีนาคม
ในหนังข้อเรื่อง CI/CD pipeline :: The Good and The Bad
ซึ่งมีหลายเรื่องที่น่าสนใจ เพื่อนำมาประยุกต์ใช้งาน
จึงทำการสรุปไว้นิดหน่อย

ทุกสิ่งทุกอย่างมันเริ่มต้นจากปัญหา

ดังนั้นเราต้องรู้ปัญหาก่อนว่า คืออะไร ?
แต่บางครั้งเราอาจจะเจอปัญหาอยู่
แต่ปัญหามันดันเป็นข้อจำกัด หรือ ความเคยชินก็เป็นไปได้ !!
ดังนั้นเราต้องมองไปที่ Business goal/value
นั่นคือทำอย่างไรที่บริษัทจะส่งมอบ product ไปถึงมือ customer ให้เร็วและมีคุณภาพที่ดี นั่นคือเรื่องของ time-to-market และส่งมอบบ่อย ๆ
แต่ในบาง business ก็ไม่ต้องการส่งมอบบ่อย ๆ นะ !!

เน้นไปที่เรื่องของคุณภาพของการพัฒนาและส่งมอบ

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

เมื่อเห็นปัญหาแล้ว สิ่งที่ต้องเริ่มทำหรือหาคือ pipeline ของการทำงาน

เน้นในส่วนของการพัฒนาไปจนถึงการ deploy มามีขั้นตอนอะไรบ้าง ?
เช่น

• การ build
• การทดสอบ
• การ package software
• การ deploy

จากนั้นพยายามแทนที่การทำงานแบบ manual ด้วยการทำงานแบบอัตโนมัติ
มีประโยคที่น่าสนใจคือ

"Automate what your care about "

อะไรที่คุณใส่ใจแล้วให้มันทำงานแบบอัตโนมัติซะ
เพราะว่าคนเรามักทำความผิดพลาดได้เสมอ

คำถามที่น่าสนใจคือ แล้วในขั้นตอนหรือ pipeline นั้นต้องมีอะไรบ้าง ?

มันมีหลายมุมมองเช่น Risk profile ของระบบงาน ว่ามีความเสี่ยงอะไรบ้าง
ค่าของ MTBF (Mean Time Between Failure)
คือเวลาตั้งแต่สร้างจนถึงเวลาที่รู้ว่ามัน fail  หรือผิดพลาดนานเพียงใด ยิ่งนานยิ่งแย่ 
ดังนั้นจำเป็นต้องลง เพื่อให้เราแก้ไขได้อย่างรวดเร็ว
นั่นคือ pipeline ที่ดีต้องให้ feeback ที่เร็วและมีคุณภาพ

ใน meetup ยกตัวอย่างของ pipeline ของระบบงานมีขั้นตอนดังนี้

• Code linting
• Unit test
• Security scan เช่น dependency check
• Build/package
• Deploy to Dev
• End-to-end test / UI test
• Performance test
• Pen test
• Deploy to production

ปัญหาที่ตามมาของขั้นตอนต่าง ๆ ข้างต้นคือ

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

• อะไรบ้างที่ต้องทำเมื่อทำการ commit/push code ซึ่งต้องเร็ว
• อะไรที่ไม่จำเป็นต้องทำทุก ๆ การเปลี่ยนแปลง เพราะว่าช้า เช่น End-to-End test, performance test และ Pen test ให้ทำงานเป็น schedule ซะ เช่นทุกชั่วโมง ทุกวัน เป็นต้น

ทุกอย่างที่บอกมา มันดีนะ แต่ว่าเรายังไม่พร้อม !!!

เป็นข้ออ้างที่เจอบ่อยมาก ๆ
ทั้งไม่มีชุดการทดสอบ
ทั้งไม่มีการ deploy แบบอัตโนมัติ
ทั้ง ... เยอะแยะไปหมด

สิ่งที่แนะนำคือ ให้เริ่มจากสิ่งที่ทีมใช้ก่อน

ยกตัวอย่างเช่น
การ build ให้เริ่มจากการทำ script การ build ก่อน
การ deploy ให้เริ่มจาก deploy script ไปยัง Dev server ก่อน
เช่นการเขียน Ansible playbook เป็นต้น

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

อีกประเด็นที่น่าสนใจคือ เมื่อเกิดปัญหาหรือ pipeline 

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

ดังนั้นจาก Principle ข้อหนึ่งของ Continuous Integration (CI) คือ
เมื่อเกิดข้อผิดพลาดแล้วให้ทุกคนในทีมหยุด และมาช่วยกันแก้ไข
เป็นสิ่งหนึ่งที่ขาดไม่ได้เลย
ดังนั้นจำเป็นต้องสร้างข้อตกลงกันนะ

เรื่องต่อมาคือ ความน่าเชื่อถือของ Pipeline

เมื่อระบบงานใหญ่ขึ้น Code มากขึ้น
ชุดการทดสอบมากขึ้น
ขั้นตอนมากขึ้น
ปัญหาที่ตามมาคือ  การทำงานของ pipeline ไม่เสถียร
คือทำงานผ่านบ้างไม่ผ่านบ้าง ทั้ง ๆ ที่ยังไม่ทำอะไรเลย
ยกตัวอย่างเช่น ทดสอบไม่ผ่าน
ยิ่งเป็นการทดสอบที่มี dependency เยอะ ๆ ยิ่งมีปัญหาบ่อย
รวมทั้งทำงานช้าอีกด้วย
เรื่องของการทดสอบจึงต้องให้ความสำคัญกับ Test Pyramid ให้มาก

แต่ถ้าทำแบบไม่เข้าใจมันจะเกิดปัญหาดังรูป Cupcake
คือเกิด Silo ในการทำงานน
นั้นคือแต่ละทีมก็ต่างคนต่างทำไป
ทำให้เกิดชุดการทดสอบซ้ำกันมากมาย

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

สุดท้ายสิ่งที่เราควรทำก่อนคือ

หาเส้นทางไปยังการ deploy สู่ production ให้เจอ
จากนั้นเริ่มออกแบบสร้าง pipeline  ของเราขึ้นมาแบบ incremental
แต่ pipeline ที่สร้างต้องมี feedback loop ที่สั้นและเร็ว
รวมทั้งต้องมีคุณภาพอีกด้วย

เห็นมีการ share บทความเกี่ยวกับ Helidon Project จากทาง Oracle 
ซึ่งปล่อย version 1.0 ออกมาแล้ว
บอกว่ามันคือ Lightweight Java Microservice framework
ดังนั้นจึงมี library ที่จำเป็นสำหรับการพัฒนาระบบตามแนวคิด Microservices ไว้ให้เลย

โดยเบื้องหลังของ web server คือ Netty เป้าหมายหลัก ๆ คือ

• ความเรียบง่าย
• ความเร็ว
• สนับสนุน MicroProfile
• Reactive Web server
• เตรียมเรื่องของ health check, metric, tracing และ tolerance ให้
• พร้อมสำหรับการ integrate กับ Prometheus, Zipkin และ Kubernetes
• เตรียมเรื่องของ security ไว้ให้ เช่น Authentication, Authorization, Outbound security และ การ Audit

มาดูรายละเอียดและลองใช้งานกันดู

ที่มาของ project นี้ ก็อธิบายไว้ดีและชัดเจนคือ

เนื่องจาก Microservices เป็นแนวคิดที่ได้รับความนิยม
รูปแบบการพัฒนาก็จำเป็นต้องมีการเปลี่ยนแปลงเช่นกัน
เมื่อมองในสิ่งที่มีอยู่ของ Oracle คือ Java EE ซึ่งมันเป็นเทคโนโลยีที่ดีและเสถียร
แต่ว่ามี legacy technology มากมาย
การที่จะพัฒนาระบบตามแนวคิด Microservices บน Java EE คงไม่ใช่สิ่งที่ดี
ดังนั้นเราจำเป็นต้องมี framework ใหม่ที่ออกแบบมาเพื่อ Microservices โดยเฉพาะ
นั่นคือที่มาของ Helidon project

เรื่องของ Architecture

จะมีอยู่ 2 ส่วนหรือ version คือ

• Helidon SE (Standard Edition) คือ core หลักของ project ซึ่งไม่มี magic หรือพวก DI แปลก ๆ รวมทั้งไม่มี class loader อะไรมากมาย มันคือการเขียนด้วย Java SE ทั่วไปเลย
• Helidon MP (MicroProfile) เป็นส่วนที่สร้างอยู่บน Helidon SE

มีการเปรียบเทียบกับ Microservice framework อื่น ๆ ให้เข้าใจง่ายขึ้น
สังเกตว่าจะมีขนาดที่เล็กกว่า Spring Boot ด้วยนะ

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

เริ่มง่าย ๆ กับ hello world นี่แหละ การเขียนก็ไม่ยากเท่าไร
เพราะว่าเอกสารมีตัวอย่างครบ ซึ่งทำการพัฒนา RESTful API ดังนี้

[gist id="549e55fa27bce2343dca73ee00738a0b" file="HelloWorld.java"]

คำอธิบาย
ทำการสร้าง Web server ขึ้นมาซึ่ง run ที่ port 8080 (Reactive Web Server) 
แน่นอนว่า Web server คือ Netty นั่นเอง ทำการกำหนด routing ของ API   
หน้าตามันคุ้น ๆ เหมือน NodeJS เลย
เนื่องจากได้แรงบันดาลในมานั่นเอง

ตัวอย่าง source code ของ Project อยู่ที่ Github::Hello 
ไว้ว่าง ๆ มาลองสร้าง Microservices ด้วย Helidon แบบเต็ม ๆ กันดู

Reference Websites https://github.com/oracle/helidonhttps://www.infoq.com/news/2018/10/oracle-introduces-helidon
https://www.infoq.com/news/2019/03/helidon-v1-api-stability
https://blogs.oracle.com/developers/microservices-from-dev-to-deploy-part-1-getting-started-with-helidon

ตั้งแต่ StackOverflow เปิดตัวตั้งแต่ปี 2008 เป็นต้นมา
พบว่าคำถามเรื่องวิธีการออกจาก Vim edit นั้น
มีจำนวนครั้งเข้ามาดูมากกว่า 1.8 ล้านครั้ง
แบบนี้มันหมายความว่าอะไรบ้างนะ ?

:wq
:q!

https://twitter.com/StackOverflow/status/1105649774504669184

วันนี้ว่าง ๆ ช่วงรอ speaker ขึ้นพูดในงาน Beta Conference
เลยลองเขียนและ deploy Google Cloud Function ด้วยภาษา Go นิดหน่อย
ได้ยินมานานว่าสนับสนุน Go 1.11 แล้ว
เวลามีน้อย มาลองกันดีกว่า

ก่อนอื่นไปเปิด Account ที่ Google Cloud ก่อน
ช่วงนี้ได้ฟรี 300 USD หรือ 1 ปี ชิว ๆ ไปครับ

เริ่มต้นด้วยการพัฒนา Function ง่าย ๆ ด้วยภาษา Go

ซึ่งมี function 2 รูปแบบคือ

1. HTTP function คือ function ที่เรียกผ่าน HTTP นั่นเอง
2. Background function คือ function ที่จะถูกเรียกเมื่อเกิด event ขึ้นมา

โดยตัวอย่างที่เลือกเขียนคือ HTTP function

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="hello.go"]

คำอธิบาย
ก็ไม่มีอะไรมาก ตามชื่อเลยคือ function เป็นแบบ public ด้วย
เป็น function ที่รับ request และ response ผ่าน net/http package เลย

ต่อมาทำการ deploy ไปยัง Google Cloud Function กัน

ตามจริงสามารถทดสอบบน localhost หรือเครื่องเราได้ก่อนนะ !!
แต่แวลามีน้อยก็ deploy ผ่าน gcloud command line กันเลย

คำอธิบาย

• Entrypoint คือ ชื่อ function
• Runtime ในตอนนี้สนับสนุน Go version 1.11
• กำหนดเป็น HTTP function ด้วย trigger-http

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

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="1.txt"]

ลืมไปหนึ่งเรื่องคือ
Google Cloud Function จะสนับสนุนเฉพาะในบาง region เท่านั้นคือ 

• us-central1 
• us-east1
• europe-west1
• asia-northeast

เมื่อทำการ deploy เรียบร้อยแล้ว

ซึ่งจะใช้เวลานานนิดหน่อย สามารถเข้าไปดูผลที่ Google Cloud Console ได้เลย
แจ้งรายละเอียดพร้อม URL ของการเข้าใช้งาน function มาให้เรียบร้อย

มาลองทำการทำ performance test ตัว function ที่ deploy กัน

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

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="2.txt"]

ผลการทำงานก็ดูดีเลยนะ
ลองไปดูผลการทำงานที่ Dashboard ของ function ใน google cloud ได้เลย

ถึงตรงนี้ก็พบว่า มันเขียนและ deploy ง่ายดีนะ
ไว้ต้องเอางานจริงมา deploy กันบ้าง
มาเริ่มเรียนรู้กันผ่าน Quick Starter 
ขอให้สนุกกับการ coding ครับ

ปัญหาอย่างหนึ่งในภาษา Java คือ
เมื่อเกิด error ที่ว่า NullPointerException (NPE) แล้ว 
หรือการ access ไปยัง object ที่เป็น Null
จะไม่ได้แจ้งรายละเอียดเลยว่า มีสาเหตุมาจากอะไร ?

ยกตัวอย่างเช่น A.getB().getC().getD() เมื่อเกิด NullPointerException แล้ว
คำถามคือ มันเป็นตรงไหนละเนี่ย ?

ปัญหานี้กำลังจะถูกแก้ไข 

เมื่อในกลุ่ม community ของ OpenJDK ได้พูดคุยกันใน 2 เดือนที่ผ่านมา
ว่าน่าจะเพิ่มรายละเอียดเข้าไปใน NullPointerException ได้แล้ว

แน่นอนว่า มีการทำ Demo สำหรับ NullPointerException มาให้ดูด้วย

ว่ามันน่าจะแจ้งปัญหาประมาณนี้นะ มาดูกันว่าเป็นอย่างไร

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

ถ้าแสดงรายละเอียดของปัญหาได้ชัดเจนแบบนี้แล้ว
มันน่าจะมีประโยชน์ต่อการแก้ไขปัญหาหรือป้องกันได้ง่ายขึ้นไปอีกนะ

ดังนั้นต้องรอว่า เมื่อใดถึงจะเพิ่มเข้ามาใน Java กัน !!

จาก Post ของพี่ Supphachoke Suntiwichaya ใน facebook
เกี่ยวกับการประกาศตัวแปรด้วย keyword const ใน JavaScript 
นั่นหมายความว่าตัวแปรนั้น จะไม่สามารถแก้ไขข้อมูลได้ (Immutable data)
แต่ดันสามารถแก้ไขข้อมูลได้ !!

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

โดยปกติใน JavaScript นั้น

เรามักจะประกาศตัวแปรพร้อมค่า  หรือใช้ keyword var ไปเลย
แต่ใน ES2015 มานั้นจะมี keyword let และ const สำหรับประกาศตัวแปร

โดยที่ keyword const นั้น
หลังจากที่ประกาศและกำหนดค่าไปแล้ว 
จะไม่สามารถประกาศซ้ำและเปลี่ยนแปลงค่าได้
ซึ่งจะเป็นจริงกับ primitive datatype เท่านั้น
แต่จะไม่เป็นจริงกับ non-primitive datatype เช่น object ต่าง ๆ
ยกตัวอย่างกับปัญหาที่เจอจาก Post ต้นทาง

คำธิบาย
ตัวแปรนั้นจะทำการเก็บค่าตำแหน่งใน memory ซึ่งชี้ไปยังตำแหน่งเก็บข้อมูลจริง ๆ
โดยประกาศด้วย keyword const นั่นหมายความว่า
ไม่สามารถประกาศตัวแปร numbers ซ้ำได้อีก
ทำให้ค่าของตัวแปรซึ่งเป็นตำแหน่งใน memory ไม่เปลี่ยน (Pass by Reference)
แสดงดังรูป

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

แต่ถ้าต้องการไม่ให้แก้ไขค่าจริง ๆ
สามารถใช้งาน Object.freeze() และ immutable.js  ยกตัวอย่างเช่น

มีเรื่องต่าง ๆ ให้ศึกษาอีกเพียบเลย
ขอให้สนุกกับการเขียน code กันนะ

Reference Websites

• https://mariusschulz.com/blog/constant-variables-in-javascript-or-when-const-isnt-constant
• https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0
• https://stackoverflow.com/questions/23436437/why-can-i-change-value-of-a-constant-in-javascript
• https://medium.com/launch-school/javascript-es6-var-let-const-9645f543f7cb
• https://dzone.com/articles/es6-const-is-neither-constant-nor-immutable
• https://mathiasbynens.be/notes/es6-const

เจอ VDO จากงาน London Gophers Meetup 
ซึ่งมีหัวข้อน่าสนใจดังนี้

• Warning data race exit status 66
• Go three months in
• Absolute Unit (Test)
• Decoding binary network protocol

สามารถดู VDO ของหัวข้อต่างได้ที่ Youtube 
แต่หัวข้อที่จะทำการสรุปคือ Absolute Unit (Test) พูดโดยคุณ Dave Cheney
มีหลายเรื่องที่น่าสนใจ
มาเริ่มกัน

เริ่มจาก TDD (Test Driven Development) คืออะไร ?

ก็ไปค้นจาก google เอานะ แล้วจะเจอแบบนี้ !!!

มีพูดถึงผู้สร้างแนวคิด TDD และกฎ 3 ข้อของ TDD

แต่เรื่องที่สำคัญคือ แนวทาง TDD ของคุณ Dave Cheney ที่มีต่อภาษา Go

นั่นคือ
ถ้ารู้ว่าจะเขียนอะไร จะเริ่มที่เขียน test ให้ fail ก่อนเสมอ
แต่ถ้าไม่รู้ว่าจะเขียนอะไร ค่าใช้จ่ายสำหรับการลองหรือทดลองมันจะเริ่มที่ 200%
เพราะว่าต้องเสียเวลาไปกับการแก้ไข code และแก้ไข test

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

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

สิ่งที่เรากำลังทดสอบนั่นคือ SUT (System Under Test)

นั่นหมายความว่ามันไม่ใช่ class หรือ ไฟล์ใดไฟล์หนึ่ง
แต่มันคือระบบทั้งระบบ

อธิบายว่า
Go package นั้นมีแนวคิดมาจาก UNIX philosophy
คือการที่แต่ละ package จะติดต่อกันผ่าน interface เสมอ
ทำให้ program หรือระบบงานคือ การนำ package ต่าง ๆ มารวมกันเพื่อทำงานด้วยกัน
แน่นอนว่า แต่ละ package จะไม่ผูกมัดไปที่ implementation
แต่จะสนใจไปที่พฤติกรรมหรือ behavior ของการทำงานมากกว่า
ซึ่งนี่คือที่มาว่า

The unit of software in Go is the package

โดยที่ public API ของแต่ละ package นั้น
จะประกาศว่าทำอะไรได้บ้าง (What) นั่นคือพฤติกรรมนั่นเอง
แต่จะไม่บอกว่าทำงานอย่างไร (How) หรือ implementation
ส่งผลให้ถ้าแต่ละ package ทำการเปลี่ยน implmentation แล้ว
จะไม่กระทบต่อการใช้งานเลย
เป็นอีกหนึ่ง feature ของภาษา Go

ส่วน Code coverage คือ guide นำทาง

ว่า code ส่วนไหนถูกทดสอบหรือไม่
ถ้าไม่ทดสอบน่าจะลบทิ้งไป 
เนื่องจากไม่ถูกใช้งาน
รวมทั้งช่วยให้เรารู้ว่าส่วนไหนที่ต้องเพิ่ม test เข้าไป
แต่ถ้าค่า Code coverage สูง แนะนำให้เพิ่ม fuzzy testing เข้ามา
เพื่อช่วยตรวจสอบว่า edge case มันครอบคลุมหรือไม่

มี Guideline ให้ด้วย (Not Rules)

• ควรเขียน test
• ควรเขียน test ไปพร้อม ๆ กับการเขียน production code
• แต่ละ Go package คือ unit ของการทำงาน
• Test หรือชุดการทดสอบ ควรตรวจสอบพฤติกรรมการทำงานของ package ไม่ใช่ไปตรวจสอบ implementation
• การออกแบบ package นั้นควรเริ่มว่า package นั้นมีพฤติกรรมการทำงานอะไรบ้าง ไม่ใช่ลงไปว่าทำอย่างไร

สามารถ Download Slide ของ VDO เรื่องนี้ได้เลย

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

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

1. แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง
2. แบ่งเป็น service ย่อย ๆ แต่เรื่องของ data กลับไปแยก
3. เกิดระบบที่เรียกว่า Frankenstein

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

แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง

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

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

ผลที่ตามมาจากการแยกเป็น service ย่อย ๆ 

กลับไม่เป็นไปตามที่คิดที่ฝันคือ
มันกลายเป็นว่าแต่ละ service คือ Monolith เช่นเดิม !!
แถมทำให้การ deploy, testing และ ดูแลรักษายากและนานขึ้นอีก
หนักกว่านั้น
เปลี่ยนแปลงการทำงานของ service หนึ่ง
กลับส่งผลกระทบต่อภาพรวมของระบบ
แถมหาปัญหายากกว่าเดิมอีก

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

แบ่งเป็น service ย่อย ๆ ยกเว้น data กลับไม่แยก

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

• แยก database ออกมาใน server เดียวกัน
• แยก database ตามแต่ละ server ไปเลย

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

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

เกิดระบบที่เรียกว่า Frankenstein

เป็นสิ่งที่ตามมาจากข้อที่ 1 และ 2 นั่นคือ
แยกเป็น service ย่อย ๆ แล้วก็มีทีมทำ
ที่สำคัญคือ แต่ละทีมก็ต่างทีมต่างทำไป
ไม่มีแผนงานที่มา sync กัน ไม่คุยกันมากพอ

แต่ละส่วนทำงานได้
บ่อยครั้งแต่ละ service ก็มีงานที่ซ้ำซ้อนกันอีก
หนักกว่านั้น ไม่รู้ว่าต้องมาทำงานร่วมกัน
เมื่อต้องทำงานร่วมกันก็จะปะผุไปเรื่อย ๆ
เหมือนกับ Frankenstein นั่นเอง

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

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

ในการพัฒนา software นั้น
เราน่าจะชอบขั้นตอนการทำงานที่ ทำซ้ำได้ง่าย (Repeatable)
มีความน่าเชื่อถือสูง (Reliable)
มีความยืดหยุ่น (Flixible)
เมื่อมีปัญหาสามารถคืนสภาพกลับมาปกติได้เร็ว (Resilient)

Software ที่แจ่มมักจะจะมาจาก คนที่แจ่ม ขั้นตอนที่เหมาะสม
แต่ทำไมการพัฒนา software มักจะไม่เป็นดังที่หวัง
จนมีคนพูดติดตลกไว้ว่า

"First we build them, Then we pray"

มันไม่น่าเป็นเรื่องจริงหรือเปล่านะ !!
เมื่อเราคิดจะสร้าง software ขึ้นมา ก็ต้องทำให้มันดีสิ
มีหรือที่ก่อนจะ deploy ขึ้น production server แล้วจะต้องมานั่งสวดมนต์
ขอให้ระบบทำงานราบรื่นทุกครั้งไป
แต่ทุกครั้งก็มีปัญหาเกิดขึ้นเสมอ !!

Software ที่ดีมันต้องมีองค์ประกอบที่เหมาะสม
เหมือนต้นไม้ที่โตอย่างแข็งแรง
ต้องอยู่บนดินที่ดีไม่พอต้องเหมาะสมด้วย
ต้องการการดูแลที่เหมาะสม 
บางต้นต้องการน้ำเยอะ บางต้นต้องการน้ำน้อย
บางต้นต้องการแสงเยอะ บางต้นต้องการแสงน้อย
ดังนั้นสิ่งแวดล้อมรอบข้างต้องยืดหยุ่นไปได้ตามพันธ์ของต้นไม้

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

ดังนั้นก่อนที่จะปรับปรุงน่าจะต้องรู้และเข้าใจปัญหาก่อนหรือไม่

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

ยิ่งถ้าลงไปในขั้นตอนการพัฒนา software 

เราน่าจะมี checklist หรือแนวทางที่บอกว่า
เราน่าจะต้องทำ เพื่อลดปัญหากันบ้าง ใช่ไหม ?
ถามว่า มีแล้วต้องทำไหม ?
คำตอบคือ มีไว้ให้อ่าน และคิดว่า เราต้องทำไหม ?
ถ้าไม่ทำแต่ก่อให้เกิดปัญหาอะไร แล้วจะป้องกันอย่างไร ?
ถ้าทำจะได้ประโยชน์อะไร เท่านั้นเอง
อารมณ์เหมือนกับตรงประตูจะมีป้ายบอกว่า Push หรือ Pull นั่นแหละ
มาดูว่าควรจะมีอะไรบ้าง

พยายามทำทุกอย่างให้มันทำงานแบบอัตโนมัติ

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

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

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

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

พยายามเก็บทุกสิ่งอย่างไว้ใน version control ซะ

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

พยายามทำงานที่ยาก ๆ ให้บ่อยขึ้น

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

เรื่องของคุณภาพต้องมาก่อนสำหรับทุกสิ่งอย่าง

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

คำว่าคุณภาพต้องอยู่ในทุก ๆ ส่วนของการทำงาน
ไม่ต้องรอให้ใครมานั่งตรวจสอบ
ดังนั้นคำว่าคุณภาพมันคือ

"Quality means doing it right when no one is looking"

ทุกคนต้องรับผิดของผลที่ออกมาเสมอ

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

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

อ่านบทความเรื่อง Scaling Unsplash with a small team
อธิบายว่าทีมพัฒนาระบบ Unsplash นั้นเป็นอย่างไร 
ทำงานและคิดกันอย่างไร ซึ่งเป็นอีกมุมมองที่น่าสนใจดี
จึงทำการสรุปไว้

ระบบUnsplash รองรับจำนวนการใช้งานประมาณนี้

• เรียกใช้งาน API กว่า 10 ล้าน request ต่อวัน
• มีการ process event ต่าง ๆ มากกว่า 60 ล้านครั้ง
• ให้บริการรูปภาพกว่า 60 ล้านรูป

ทีมพัฒนานั้นมีขนาดเล็กมาก ๆ ประกอบไปด้วย

• Designer 2 คน
• Fronend 3 คน พัฒนาด้วย React + Webpack และ Express สำหรับทำ Server-sider rendering และ proxy ไปยัง API
• Backend 3 คน พัฒนาด้วย Rails
• Data engineer 1 คน

เขียน test ในทุกสิ่งทุกอย่างที่ต้องการหรืออยากรู้

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

กว่า 3 ปีที่ทีมพัฒนาทำการปรับปรุงและทดลองสิ่งใหม่ ๆ
จนได้ principle ที่น่าจะตอบโจทย์ของทีมและบริษัท
ประกอบไปด้วย

1. Build boring, obvious solutions

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

ยกตัวอย่างเช่นฝั่ง Backend 
มักจะมีปัญหากับการใช้เครื่องมือพื้นฐานต่าง ๆ
ทำให้ระบบทำงานได้ไม่ดีอย่างที่ต้องการ
แต่ก็พยายามแก้ไขด้วยการทำ caching, batching
รวมไปถึงการทำงานแบบ asynchronous
เพื่อทำให้ระบบทำงานได้ดียิ่งขึ้น

2. Focus on solving user problems, not technology problems

ที่บริษัท Unsplash นั้นคือ product company ไม่ใช่ technology company
ดังนั้นเงินลงทุนต่าง ๆ จะมีเป้าหมายไปที่
การแก้ไขปัญหาของ product และ marketing เป็นหลัก
ว่าผู้ใช้งานมีปัญหาอะไร ก็แก้ไขตามนั้น

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

ดังนั้นจะเห็นว่าระบบของ Unsplash จะใช้ 3-party service เยอะมาก ๆ

เพื่อใช้จัดการปัญหาและงานต่าง ๆ เช่น 

• Web Server ก็ใช้งาน Heroku
• CDN caching ก็ใช้ Fastly
• Elasticsearch cluster ก็ใช้ Elastic cloud
• เรื่องของ feed data และnotification ก็ใช้ Steam
• รูปต่าง ๆ ก็ไปเก็บที่ Imgix

ส่วนของ Monitoring system ก็ใช้

• Centralize logging ใช้ Loggly
• Metric และค่าต่าง ๆ ของระบบ ใช้ New Relic
• Exception และ error ต่าง ๆ ใช้ Sentry, StatusPage

3. Throw money at technical problems

ง่าย ๆ คือ ใช้เงินแก้ไขปัญหา technical ไปเลย
โดยจะจ่าย service ต่าง ๆ ที่ใช้งานแบบ premium ไปเลย
เหมือนจะเป็นเครื่องที่ตลก แต่มันเป็นจริงมาก ๆ
เพราะว่า แก้ไขปัญหาที่เกิดซ้ำแล้วซ้ำเล่าทาง technical ได้ดีมาก ๆ
ส่งผลทำให้ทีมพัฒนาไป focus กับงานหรือปัญหาจากผู้ใช้งานได้เต็ม ๆ
ทำให้ระบบโตขึ้นสูงมาก ๆ
ส่วนการ optimize ค่าใช้จ่ายต่าง ๆ
ก็เป็นอีกปัญหาหนึ่งที่ต้องทำและแก้ไข เช่นกัน แต่ใครจะสนใจละ !!

Reference Websites

• https://medium.com/unsplash/scaling-unsplash-with-a-small-team-fbdd55571906
• https://medium.com/unsplash/what-does-unsplash-cost-in-2019-f499620a14d0

วันนี้ว่าง ๆ ช่วงรอ speaker ขึ้นพูดในงาน Beta Conference
เลยลองเขียนและ deploy Google Cloud Function ด้วยภาษา Go นิดหน่อย
ได้ยินมานานว่าสนับสนุน Go 1.11 แล้ว
เวลามีน้อย มาลองกันดีกว่า

ก่อนอื่นไปเปิด Account ที่ Google Cloud ก่อน
ช่วงนี้ได้ฟรี 300 USD หรือ 1 ปี ชิว ๆ ไปครับ

เริ่มต้นด้วยการพัฒนา Function ง่าย ๆ ด้วยภาษา Go

ซึ่งมี function 2 รูปแบบคือ

1. HTTP function คือ function ที่เรียกผ่าน HTTP นั่นเอง
2. Background function คือ function ที่จะถูกเรียกเมื่อเกิด event ขึ้นมา

โดยตัวอย่างที่เลือกเขียนคือ HTTP function

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="hello.go"]

คำอธิบาย
ก็ไม่มีอะไรมาก ตามชื่อเลยคือ function เป็นแบบ public ด้วย
เป็น function ที่รับ request และ response ผ่าน net/http package เลย

ต่อมาทำการ deploy ไปยัง Google Cloud Function กัน

ตามจริงสามารถทดสอบบน localhost หรือเครื่องเราได้ก่อนนะ !!
แต่แวลามีน้อยก็ deploy ผ่าน gcloud command line กันเลย

คำอธิบาย

• Entrypoint คือ ชื่อ function
• Runtime ในตอนนี้สนับสนุน Go version 1.11
• กำหนดเป็น HTTP function ด้วย trigger-http

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

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="1.txt"]

ลืมไปหนึ่งเรื่องคือ
Google Cloud Function จะสนับสนุนเฉพาะในบาง region เท่านั้นคือ 

• us-central1 
• us-east1
• europe-west1
• asia-northeast

เมื่อทำการ deploy เรียบร้อยแล้ว

ซึ่งจะใช้เวลานานนิดหน่อย สามารถเข้าไปดูผลที่ Google Cloud Console ได้เลย
แจ้งรายละเอียดพร้อม URL ของการเข้าใช้งาน function มาให้เรียบร้อย

มาลองทำการทำ performance test ตัว function ที่ deploy กัน

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

[gist id="83f3e96db40d7dd0372b0d2c505e1783" file="2.txt"]

ผลการทำงานก็ดูดีเลยนะ
ลองไปดูผลการทำงานที่ Dashboard ของ function ใน google cloud ได้เลย

ถึงตรงนี้ก็พบว่า มันเขียนและ deploy ง่ายดีนะ
ไว้ต้องเอางานจริงมา deploy กันบ้าง
มาเริ่มเรียนรู้กันผ่าน Quick Starter 
ขอให้สนุกกับการ coding ครับ

ปัญหาอย่างหนึ่งในภาษา Java คือ
เมื่อเกิด error ที่ว่า NullPointerException (NPE) แล้ว 
หรือการ access ไปยัง object ที่เป็น Null
จะไม่ได้แจ้งรายละเอียดเลยว่า มีสาเหตุมาจากอะไร ?

ยกตัวอย่างเช่น A.getB().getC().getD() เมื่อเกิด NullPointerException แล้ว
คำถามคือ มันเป็นตรงไหนละเนี่ย ?

ปัญหานี้กำลังจะถูกแก้ไข 

เมื่อในกลุ่ม community ของ OpenJDK ได้พูดคุยกันใน 2 เดือนที่ผ่านมา
ว่าน่าจะเพิ่มรายละเอียดเข้าไปใน NullPointerException ได้แล้ว

แน่นอนว่า มีการทำ Demo สำหรับ NullPointerException มาให้ดูด้วย

ว่ามันน่าจะแจ้งปัญหาประมาณนี้นะ มาดูกันว่าเป็นอย่างไร

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

ถ้าแสดงรายละเอียดของปัญหาได้ชัดเจนแบบนี้แล้ว
มันน่าจะมีประโยชน์ต่อการแก้ไขปัญหาหรือป้องกันได้ง่ายขึ้นไปอีกนะ

ดังนั้นต้องรอว่า เมื่อใดถึงจะเพิ่มเข้ามาใน Java กัน !!

จาก Post ของพี่ Supphachoke Suntiwichaya ใน facebook
เกี่ยวกับการประกาศตัวแปรด้วย keyword const ใน JavaScript 
นั่นหมายความว่าตัวแปรนั้น จะไม่สามารถแก้ไขข้อมูลได้ (Immutable data)
แต่ดันสามารถแก้ไขข้อมูลได้ !!

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

โดยปกติใน JavaScript นั้น

เรามักจะประกาศตัวแปรพร้อมค่า  หรือใช้ keyword var ไปเลย
แต่ใน ES2015 มานั้นจะมี keyword let และ const สำหรับประกาศตัวแปร

โดยที่ keyword const นั้น
หลังจากที่ประกาศและกำหนดค่าไปแล้ว 
จะไม่สามารถประกาศซ้ำและเปลี่ยนแปลงค่าได้
ซึ่งจะเป็นจริงกับ primitive datatype เท่านั้น
แต่จะไม่เป็นจริงกับ non-primitive datatype เช่น object ต่าง ๆ
ยกตัวอย่างกับปัญหาที่เจอจาก Post ต้นทาง

คำธิบาย
ตัวแปรนั้นจะทำการเก็บค่าตำแหน่งใน memory ซึ่งชี้ไปยังตำแหน่งเก็บข้อมูลจริง ๆ
โดยประกาศด้วย keyword const นั่นหมายความว่า
ไม่สามารถประกาศตัวแปร numbers ซ้ำได้อีก
ทำให้ค่าของตัวแปรซึ่งเป็นตำแหน่งใน memory ไม่เปลี่ยน (Pass by Reference)
แสดงดังรูป

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

แต่ถ้าต้องการไม่ให้แก้ไขค่าจริง ๆ
สามารถใช้งาน Object.freeze() และ immutable.js  ยกตัวอย่างเช่น

มีเรื่องต่าง ๆ ให้ศึกษาอีกเพียบเลย
ขอให้สนุกกับการเขียน code กันนะ

Reference Websites

• https://mariusschulz.com/blog/constant-variables-in-javascript-or-when-const-isnt-constant
• https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0
• https://stackoverflow.com/questions/23436437/why-can-i-change-value-of-a-constant-in-javascript
• https://medium.com/launch-school/javascript-es6-var-let-const-9645f543f7cb
• https://dzone.com/articles/es6-const-is-neither-constant-nor-immutable
• https://mathiasbynens.be/notes/es6-const

เจอ VDO จากงาน London Gophers Meetup 
ซึ่งมีหัวข้อน่าสนใจดังนี้

• Warning data race exit status 66
• Go three months in
• Absolute Unit (Test)
• Decoding binary network protocol

สามารถดู VDO ของหัวข้อต่างได้ที่ Youtube 
แต่หัวข้อที่จะทำการสรุปคือ Absolute Unit (Test) พูดโดยคุณ Dave Cheney
มีหลายเรื่องที่น่าสนใจ
มาเริ่มกัน

เริ่มจาก TDD (Test Driven Development) คืออะไร ?

ก็ไปค้นจาก google เอานะ แล้วจะเจอแบบนี้ !!!

มีพูดถึงผู้สร้างแนวคิด TDD และกฎ 3 ข้อของ TDD

แต่เรื่องที่สำคัญคือ แนวทาง TDD ของคุณ Dave Cheney ที่มีต่อภาษา Go

นั่นคือ
ถ้ารู้ว่าจะเขียนอะไร จะเริ่มที่เขียน test ให้ fail ก่อนเสมอ
แต่ถ้าไม่รู้ว่าจะเขียนอะไร ค่าใช้จ่ายสำหรับการลองหรือทดลองมันจะเริ่มที่ 200%
เพราะว่าต้องเสียเวลาไปกับการแก้ไข code และแก้ไข test

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

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

สิ่งที่เรากำลังทดสอบนั่นคือ SUT (System Under Test)

นั่นหมายความว่ามันไม่ใช่ class หรือ ไฟล์ใดไฟล์หนึ่ง
แต่มันคือระบบทั้งระบบ

อธิบายว่า
Go package นั้นมีแนวคิดมาจาก UNIX philosophy
คือการที่แต่ละ package จะติดต่อกันผ่าน interface เสมอ
ทำให้ program หรือระบบงานคือ การนำ package ต่าง ๆ มารวมกันเพื่อทำงานด้วยกัน
แน่นอนว่า แต่ละ package จะไม่ผูกมัดไปที่ implementation
แต่จะสนใจไปที่พฤติกรรมหรือ behavior ของการทำงานมากกว่า
ซึ่งนี่คือที่มาว่า

The unit of software in Go is the package

โดยที่ public API ของแต่ละ package นั้น
จะประกาศว่าทำอะไรได้บ้าง (What) นั่นคือพฤติกรรมนั่นเอง
แต่จะไม่บอกว่าทำงานอย่างไร (How) หรือ implementation
ส่งผลให้ถ้าแต่ละ package ทำการเปลี่ยน implmentation แล้ว
จะไม่กระทบต่อการใช้งานเลย
เป็นอีกหนึ่ง feature ของภาษา Go

ส่วน Code coverage คือ guide นำทาง

ว่า code ส่วนไหนถูกทดสอบหรือไม่
ถ้าไม่ทดสอบน่าจะลบทิ้งไป 
เนื่องจากไม่ถูกใช้งาน
รวมทั้งช่วยให้เรารู้ว่าส่วนไหนที่ต้องเพิ่ม test เข้าไป
แต่ถ้าค่า Code coverage สูง แนะนำให้เพิ่ม fuzzy testing เข้ามา
เพื่อช่วยตรวจสอบว่า edge case มันครอบคลุมหรือไม่

มี Guideline ให้ด้วย (Not Rules)

• ควรเขียน test
• ควรเขียน test ไปพร้อม ๆ กับการเขียน production code
• แต่ละ Go package คือ unit ของการทำงาน
• Test หรือชุดการทดสอบ ควรตรวจสอบพฤติกรรมการทำงานของ package ไม่ใช่ไปตรวจสอบ implementation
• การออกแบบ package นั้นควรเริ่มว่า package นั้นมีพฤติกรรมการทำงานอะไรบ้าง ไม่ใช่ลงไปว่าทำอย่างไร

สามารถ Download Slide ของ VDO เรื่องนี้ได้เลย

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

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

1. แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง
2. แบ่งเป็น service ย่อย ๆ แต่เรื่องของ data กลับไปแยก
3. เกิดระบบที่เรียกว่า Frankenstein

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

แบ่งเป็น service เล็กมาก ๆ แทนที่จะดีขึ้นกลับแย่ลง

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

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

ผลที่ตามมาจากการแยกเป็น service ย่อย ๆ 

กลับไม่เป็นไปตามที่คิดที่ฝันคือ
มันกลายเป็นว่าแต่ละ service คือ Monolith เช่นเดิม !!
แถมทำให้การ deploy, testing และ ดูแลรักษายากและนานขึ้นอีก
หนักกว่านั้น
เปลี่ยนแปลงการทำงานของ service หนึ่ง
กลับส่งผลกระทบต่อภาพรวมของระบบ
แถมหาปัญหายากกว่าเดิมอีก

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

แบ่งเป็น service ย่อย ๆ ยกเว้น data กลับไม่แยก

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

• แยก database ออกมาใน server เดียวกัน
• แยก database ตามแต่ละ server ไปเลย

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

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

เกิดระบบที่เรียกว่า Frankenstein

เป็นสิ่งที่ตามมาจากข้อที่ 1 และ 2 นั่นคือ
แยกเป็น service ย่อย ๆ แล้วก็มีทีมทำ
ที่สำคัญคือ แต่ละทีมก็ต่างทีมต่างทำไป
ไม่มีแผนงานที่มา sync กัน ไม่คุยกันมากพอ

แต่ละส่วนทำงานได้
บ่อยครั้งแต่ละ service ก็มีงานที่ซ้ำซ้อนกันอีก
หนักกว่านั้น ไม่รู้ว่าต้องมาทำงานร่วมกัน
เมื่อต้องทำงานร่วมกันก็จะปะผุไปเรื่อย ๆ
เหมือนกับ Frankenstein นั่นเอง

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

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

ในการพัฒนา software นั้น
เราน่าจะชอบขั้นตอนการทำงานที่ ทำซ้ำได้ง่าย (Repeatable)
มีความน่าเชื่อถือสูง (Reliable)
มีความยืดหยุ่น (Flixible)
เมื่อมีปัญหาสามารถคืนสภาพกลับมาปกติได้เร็ว (Resilient)

Software ที่แจ่มมักจะจะมาจาก คนที่แจ่ม ขั้นตอนที่เหมาะสม
แต่ทำไมการพัฒนา software มักจะไม่เป็นดังที่หวัง
จนมีคนพูดติดตลกไว้ว่า

"First we build them, Then we pray"

มันไม่น่าเป็นเรื่องจริงหรือเปล่านะ !!
เมื่อเราคิดจะสร้าง software ขึ้นมา ก็ต้องทำให้มันดีสิ
มีหรือที่ก่อนจะ deploy ขึ้น production server แล้วจะต้องมานั่งสวดมนต์
ขอให้ระบบทำงานราบรื่นทุกครั้งไป
แต่ทุกครั้งก็มีปัญหาเกิดขึ้นเสมอ !!

Software ที่ดีมันต้องมีองค์ประกอบที่เหมาะสม
เหมือนต้นไม้ที่โตอย่างแข็งแรง
ต้องอยู่บนดินที่ดีไม่พอต้องเหมาะสมด้วย
ต้องการการดูแลที่เหมาะสม 
บางต้นต้องการน้ำเยอะ บางต้นต้องการน้ำน้อย
บางต้นต้องการแสงเยอะ บางต้นต้องการแสงน้อย
ดังนั้นสิ่งแวดล้อมรอบข้างต้องยืดหยุ่นไปได้ตามพันธ์ของต้นไม้

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

ดังนั้นก่อนที่จะปรับปรุงน่าจะต้องรู้และเข้าใจปัญหาก่อนหรือไม่

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

ยิ่งถ้าลงไปในขั้นตอนการพัฒนา software 

เราน่าจะมี checklist หรือแนวทางที่บอกว่า
เราน่าจะต้องทำ เพื่อลดปัญหากันบ้าง ใช่ไหม ?
ถามว่า มีแล้วต้องทำไหม ?
คำตอบคือ มีไว้ให้อ่าน และคิดว่า เราต้องทำไหม ?
ถ้าไม่ทำแต่ก่อให้เกิดปัญหาอะไร แล้วจะป้องกันอย่างไร ?
ถ้าทำจะได้ประโยชน์อะไร เท่านั้นเอง
อารมณ์เหมือนกับตรงประตูจะมีป้ายบอกว่า Push หรือ Pull นั่นแหละ
มาดูว่าควรจะมีอะไรบ้าง

พยายามทำทุกอย่างให้มันทำงานแบบอัตโนมัติ

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

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

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

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

พยายามเก็บทุกสิ่งอย่างไว้ใน version control ซะ

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

พยายามทำงานที่ยาก ๆ ให้บ่อยขึ้น

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

เรื่องของคุณภาพต้องมาก่อนสำหรับทุกสิ่งอย่าง

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

คำว่าคุณภาพต้องอยู่ในทุก ๆ ส่วนของการทำงาน
ไม่ต้องรอให้ใครมานั่งตรวจสอบ
ดังนั้นคำว่าคุณภาพมันคือ

"Quality means doing it right when no one is looking"

ทุกคนต้องรับผิดของผลที่ออกมาเสมอ

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

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

จากงาน Beta Conference ครั้งที่ 1 ซึ่งจัดโดย skooldio
มีหลายเรื่องที่น่าสนใจมาก ๆ  หนึ่งในนั้นที่ยังพอจำได้คือ
การขับเคลื่อนองค์กรด้วยข้อมูล (Data Driven Organization)
ไม่ตัดสินใจจากความรู้สึก (บางครั้งก็ต้องใช้บ้าง)
เริ่มต้นด้วยสิ่งที่เรียบง่าย ด้วยประโยคสั้น ๆ แต่ชัดเจนคือ

"If you can’t measure it, you can’t improve it"

ปล. ผมชอบแนวคิดนี้ตั้งแต่อ่านบทความคล้าย ๆ เรื่องนี้จาก
Measure Anything, Measure Everything

เริ่มง่าย ๆ คือ เราจะวัดค่าจากอะไร อย่างไร ?

ต้องเริ่มจาก data หรือ ข้อมูลนั่นเอง มีขั้นตอนดังนี้

• Metric หรือเรียกว่า ยอด หรือ ตัวเลขนั่นเอง เรามักเรียกข้อมูลเหล่านี้ว่า Historical data คือข้อมูลที่เกิดมาแล้ว เพื่อใช้วิเคราะห์ต่อไป
• Insight หรือการเข้าใจอย่างถ่องแท้จากข้อมูล เพื่อให้สามารถแข่งขันกับคู่แข่งได้
• Data Product หรือหารสร้าง product มาจากสิ่งที่เข้าใจและมีคุณค่าต่อลูกค้าอย่างแท้จริง มันคือการ Transformation ที่แท้จริงนั่นเอง

ฟังดูเหมือนจะดี
เมื่อกลับไปดูองค์กรต่าง ๆ ประกาศออกมาว่า
เราเป็นหรือจะเป็น Data-Driven Company นะ
เราเป็นหรือจะเป็น AI First นะ
เราเป็นหรือจะเป็น Analytic centric นะ
แต่จากการสำรวจพบว่า มีเพียง 30% เท่านั้นที่ทำได้จริง ๆ !!!

ส่วนใหญ่มักจะขับเคลื่อนด้วย Powerpoint !!
หรือเพียงแค่การนำเสนอบน presentation
หนักกว่านั้นคือ
มีข้อมูลแล้วเราไม่เชื่อ
เราจะเชื่อในสัญชาตญาณของคนตัดสินใจ !!
แต่บอกว่าเราคือ Data-Driven Company หรือ AI First นะ มันยังไงกันนะ !!
น่าจะเป็นเรื่องเล่าตลก ๆ ขำ ๆ
ไม่น่าจะมีจริงหรอกนะ ผมว่า !!

การทำให้องค์กรขับเคลื่อนด้วยข้อมูลได้นั้น

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

ยกตัวอย่างเช่น  ข้อมูลที่ต้องไป query หรือดึงจากฐานข้อมูล
เพื่อเอามาใส่ใน slide เพื่อ present ในที่ประชุม

หนักกว่านั้น เมื่อพูดถึงเรื่องของ Data

ก็พาไปถึงการจ้างงานในตำแหน่ง Data Science
เราต้องการ Data Science ที่เก่งเรื่อง Computer Science
เราต้องการ Data Science ที่เก่งเรื่องคณิตศาสตร์และสถิติ
เราต้องการ Data Science ที่เก่งเรื่อง Business Domain
เมื่อเอาความสามารถทั้งสามส่วนมาก็พบว่า มันคือ set ว่าง หรือไม่มีนั่นเอง !!

สิ่งที่ต้องเข้าใจคือ ไม่ใช่หาคน
แต่ต้องรู้และเข้าใจก่อนว่า 
จะนำข้อมูลอะไรมาช่วยในการตัดสินใจ
จากนั้นค่อยลงไปหาว่า
ในแต่ละสิ่งที่ต้องการมีไหม
และใครช่วยได้บ้าง
นั่นแหละจึงจะเริ่มเจอคนที่เราต้องการจริง ๆ
เรื่องเหล่านี้มันทำคนเดียวไม่ได้
ไม่มีใครเก่งไปทุกเรื่อง
มันต้องทำงานกันเป็นทีมทั้ง
Business, Developer, Engineer, Data Science และ Business Domain Expert เป็นต้น

มาดูปัญหาในองค์กรกันดีกว่า ว่าเมื่อประกาศว่าเราต้องขับเคลื่อนด้วยข้อมูลนะ

ปัญหาแรกเรื่องที่มาของข้อมูล

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

ปัญหาที่สองคือ มีข้อมูลแต่ไม่ใช้

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

ปัญหาที่สามคือ ไม่เข้าใจว่าจะใช้ข้อมูลอย่างไร

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

ปัญหาทั้งสามเรื่องนี้จำเป็นต้องรีบแก้ไขปละปรับปรุงให้ดีขึ้น

แบ่งเป็น 3 เรื่องคือ

• Right data คือการเก็บข้อมูลที่ถูกต้องหรือจำเป็นต่อการใช้งาน เยอะไม่ใช่ว่าจะดีเสมอไป
• Data access and tools คือการเข้าถึงข้อมูล แน่นอนว่าเครื่องมือก็สำคัญเช่นกัน แต่ต้องเข้าใจว่านำมาใช้เพราะว่าอะไร
• Data education คือการให้ความรู้เกี่ยวกับคนในองค์กรถึงการนำข้อมูลมาใช้งานและช่วยในการทำนายผลและตัดสินใจ

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

Right data 

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

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

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

Data access and tools 

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

มี dashboard สำหรับการแสดงข้อมูลของการทำงาน (operational data)
เพื่อทำให้เราเห็นการทำงานและภาพรวมของระบบ
เพื่อใช้ในการตัดสินใจอย่างรวดเร็ว

เรื่องของเครื่องมือที่ใช้งานกับข้อมูลก็สำคัญ
อย่าลืมว่าคนใช้งานมีทั้ง non-technical และ technical
ดังนั้นเครื่องมือจึงต้องเลือกที่เหมาะสมด้วย
ส่วนใหญ่ที่เจอคือ  เป็นเครื่องมือสำหรับคนในสาย technical เท่านั้น 
ทำให้คนอื่น ๆ นอก IT ไม่สามารถใช้งานได้
นี่คือปัญหาที่ต้องแก้ไข Data education 

Data education 

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

เป็นการสร้างความเข้าใจร่วมกันว่า 
เราต้องการอะไร
เราจะใช้ข้อมูลอะไร
เราจะใช้เครื่องมืออะไรต่อไป

เมื่อปัญหาต่าง ๆ เริ่มถูกแก้ไขแล้ว
องค์กรจะเริ่มนำข้อมูลมาใช้ในการตัดสินใจมากขึ้น

วันนี้องค์กรของเราเป็นอย่างไรกัน ?

เห็นใน page ของ InfoQ ใน facebook 
ทำการ post รูป Possible Code Content จาก MonkeyUser.com
เป็นรูปอธิบายรูปแบบต่าง ๆ ของการพัฒนา software ยกตัวอย่างเช่น

• TODO
• Bug
• Missing feature
• Hidden feature
• Duplication code
• Complexity
• Code from stackoverflow
• Do not touch code

เลยเอามาเก็บไว้หน่อย

ก็เลยไปดูเรื่องอื่น ๆ บ้าง ก็เจอรูปที่น่าสนใจดังนี้

เรื่องของ Architecture อันนี้ เจ็บมาก ๆ
ใครกำลังทำหรือสร้างแบบนี้อยู่บ้าง !!

เรื่องของ Code reuse !!

เรื่องของ Requirement vs Implementation !!!

ว่าจะเรื่องของ Restrospective เอาผลที่ได้ไปไว้ไหนกัน ?
จะได้ปรับปรุงและแก้ไขไหมเนี่ย

เรื่องของ HTTP Status code แบบเข้าใจง่าย ๆ

การหา root cause ของปัญหา !!!

Testing vs Production Environment !!

เก็บไว้ใช้กันครับ คิดว่าน่าจะมีประโยชน์บ้าง

กลายเป็นธรรมเนียมไปแล้วสำหรับ Stack Overflow Developer Survey
ที่ต้องมีในทุก ๆ ปี ซึ่งครั้งนี้เป็นปีที่ 9 แล้ว
ผลจากการสำรวจได้ออกมาเช่นกัน มาจากนักพัฒนากว่า 90,000 คนทั่วโลก
มาดูสิ่งที่น่าสนใจหันนิดหน่อย

เริ่มที่ภาษาโปรแกรมกัน

ภาษา JavaScript ยังคงได้รับความนิยมสูงสุดติดต่อกันเป็นปีที่ 7
ภาษา Python คือภาษาที่ร้อนแรงที่สุด
ภาษา Rust คือภาษาที่นักพัฒนาชอบหรือรักมากที่สุด

ภาษาที่ใช้กันเยอะ ๆ ก็ยังคงเดิมคือ
JavaScript, Python, Java, C#, PHP, C/C++, Ruby และ Go ตามลำดับ

ภาษาที่ต้องการคนมาก ๆ สุด คือ
Python, JavaScript, Go, Kotlin, Rust, C++ และ Java ตามลำดับ

ไปดูฝั่ง database พบว่าใช้สาย opensource เป็นหลักคือ
MySQL, PostgreSQL, SQLite, MongoDB, MariaDB, Redis และ Elasticsearch
ซึ่งมีทั้ง RDBMS และ NoSQL เพื่อใช้งานตาม usecase ต่าง ๆ นั่นเอง
ส่วนฝั่ง commercial ก็มี MS SQL Server และ Oracle เป็นต้น

ผลการสำรวจพบว่ามากกว่า 50% นั้น เริ่มเขียน code ตั้งแต่อายุ 16 ปี

ที่สำคัญกว่านั้นคือ
เมื่อมีปัญหาแล้วมักจะเข้ามาหาวิธีการแก้ไขจาก Stack Overflow ประจำ
ช่วยลดเวลาหารแก้ไขปัญหาไปได้ 30-90 นาทีต่อสัปดาห์
ดังนั้นถ้า Stack Overflow ล่มไปนี่
ไม่ต้องพูดถึงเลยว่าจะเกิดอะไรขึ้นบ้าง
มีประมาณ 60% ที่เข้า Stack Overflow อย่างน้อยวันละครั้ง

นักพัฒนาส่วนใหญ่มองว่า เรื่องของการเขียน Unit test และ Code review
เป็นเรื่องปกติที่พึงกระทำ
เพราะว่ามันคือหนึ่งในแนวปฏิบัติที่จะช่วยทำให้การพัฒนาระบบงานสำเร็จ

ปัญหาหลัก ๆ เรื่อง productivity ของนักพัฒนายังไม่แต่เรื่องเดิม ๆ คือ

• มีสิ่งรบกวนหรือพวกงานแทรก
• การประชุม
• งานที่ไม่เกี่ยวกับการพัฒนา
• คนไม่พอกับงาน
• ขาดการสนับสนุนจากฝ่าย management
• เครื่องมือไม่ดีพอ
• ปัญหาการเมืองในบริษัท

มาคำถามเกี่ยวกับการนำ Blockchain มาใช้งานในองค์กร

พบว่ากว่า 80% ยังไม่นำมาใช้งาน
จากรายงานพบว่า
นักพัฒนาที่มาจากประเทศอินเดีย จะตอบว่าองค์กรนำ Blockchain มาใช้มากที่สุด

ในมุมมองของนักพัฒนาส่วนใหญ่
มองว่า Blockchain นั้นมีประโยชน์มากในหลาย ๆ domain
ไม่ใช่แค่เรื่องการเงินและแลกเปลี่ยนเท่านั้น

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

ประมาณ 30% บอกว่าทำงานไม่ได้มี schedule ที่ชัดเจน
เพราะว่าต้องทำงานที่มันสำคัญหรือด่วนมาก ๆ ก่อนเสมอ
และมีเพียง 20% เท่านั้นที่มีการวางแผนงานและคนทำงานแต่ละส่วนทำงานกันอย่างใกล้ชิด

Reference Websites

• https://insights.stackoverflow.com/survey/2019
• https://stackoverflow.blog/2019/04/09/the-2019-stack-overflow-developer-survey-results-are-in/